Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

В интернете появились новости о критической уязвимости CVE-2021-44228 в библиотеке Apache Log4j (уровень опасности 10 из 10 по шкале CVSS). Эта библиотека используется миллионами Java-приложений для регистрации сообщений об ошибках. Что еще хуже, злоумышленники уже активно используют эту уязвимость в атаках. Поэтому Apache Foundation рекомендует всем разработчикам обновить библиотеку до версии 2.15.0, а если это невозможно, воспользоваться одним из методов, описанных на странице Apache Log4j Security Vulnerabilities.

Чем опасна уязвимость CVE-2021-44228

Уязвимость CVE-2021-44228, также получившая названия Log4Shell и LogJam, относится к классу Remote Code Execution. Если злоумышленникам удастся проэксплуатировать ее на одном из компьютеров, то они смогут исполнять на нем произвольный код. Потенциально это позволит им захватить полный контроль над системой.

Что делает CVE-2021-44228 особенно опасной — это простота эксплуатации: успешную атаку через эту уязвимость может осуществить даже неопытный хакер. По словам исследователей, злоумышленникам достаточно заставить приложение записать в лог всего одну строку, в результате чего им удастся подгрузить в приложение собственный код из-за функции message lookup substitution.

В Интернете уже можно найти рабочие доказательства осуществимости (PoC) атак при помощи CVE-2021-44228. Поэтому неудивительно, что различные компании, работающие в сфере кибербезопасности, уже регистрируют массовое сканирование сети в поисках уязвимых приложений, а также атаки на ханипоты.

Обнаружена уязвимость исследователем Ченом Жаожуном (Chen Zhaojun) из Alibaba Cloud Security Team.

 

View the full article

Опубликовано
Quote

и как защитить серверы от атак?

Господи божечки, ну и рекомендация. Если речь про сервер, то действия выполняет не разработчик, а пользователь ПО, например админ. Он не может скачать новую версию "на страничке проекта". То есть скачать то может, но потом ему её себе в одно место вставить можно, больше ни на что это не годится. Устранять уязвимость должны авторы ПО, которые используют эту либу.

 

То есть последовательность действий такая:

1. Авторы ПО обновляют либу на новую версию

2. Выкладывают обновления

3. Потребители ПО подтягивают новую версию

 

А теперь какая последовательность действий  на самом деле:

1. Авторы ПО никогда ничего не обновят, потому что:

1.1. Кто-то уже просто умер

1.2. Кто-то забил на развитие этого ПО

1.3. Кто-то не может себе позволить такую роскошь, как обновление на нестабильные версии. Ведь релиз вышел меньше суток назад: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.15.0 (до этого были релиз кандидаты). Классно звучит - затаскивать либу, которая не прошла полный цикл тестирования и может разломать работу продукта. Сначала подождите, когда выйдет пару патчей на либу (её наспех делали). Затем ждите пару недель минимум, пока QA прогонят тесты ПО, в которую, наконец, затянут фикс. А потом ещё месяц-два, потому что будут найдены проблемы и их надо устранить

2. Админы до последнего не будут ставить апдейты ПО, потому что:

2.1. Они не знают, где используется эта либа

2.1.1. А ещё какой она вообще версии в тех ПО, в которых всё-таки используется

2.2. Боятся, что обновление ПО на серваке приведёт к выводу его из строя, потому что "работает - не трогай". Сюда же вот такое: обновление ПО занимает время и сервер будет недоступен к нормальному использованию, что означает остановку некоторых техпроцессов

2.3. Ждут инструмент, который бы им сказал, какое же ПО уязвимо, чтобы решить, можно ли его безболезненно обновить или же обновление будет запланировано на длинные выходные, если это возможно

 

Пока не выйдет инструмент обнаружения - а текущие инструменты - это наколенные поделки, которые делают проверку через атаку и через чтение логов - чесаться будут либо фирмы с бесконечным запасом денег, либо мелкие команды, потому что у них на серваке ничего критичного и за полдня можно новый развернуть, так что сломать не страшно.

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      Автор KL FC Bot
      Экспериментами по обходу ограничений в ответах ИИ, установленными создателями языковых моделей, технологические энтузиасты начали заниматься практически с самого начала широкого распространения LLM. Многие из этих приемов были весьма оригинальны — например, сказать ИИ, что у вас нет пальцев, чтобы он помог дописать код, попросить его «просто пофантазировать», когда прямой вопрос приводит к отказу, или предложить ему принять роль умершей бабушки и поделиться запретными знаниями, дабы утешить скорбящего внука.
      Большинство таких трюков давно известны, и со многими из них разработчики LLM научились успешно бороться, но сама битва между ограничениями и попытками их обойти никуда не делась — уловки просто стали сложнее и изощреннее. Сегодня поговорим о новой технике джейлбрейка ИИ, которая эксплуатирует уязвимость чат-ботов… к поэзии — в самом прямом смысле этого слова. В свежем исследовании ученые показали, что формулирование промптов в виде стихов значительно повышает вероятность небезопасного ответа моделей.
      Эту технику они проверили на 25 популярных моделях от Anthropic, OpenAI, Google, Meta*, DeepSeek, xAI и других разработчиков. Ниже — подробности о том, какие ограничения есть у моделей, откуда у них вообще берутся запретные знания, как проходило исследование и какие модели оказались наиболее «романтичными» — в смысле, восприимчивыми к стихотворным запросам.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Новая недавно обнаруженная уязвимость WhisperPair позволяет превратить Bluetooth-наушники и гарнитуры многих известных фирм в трекинговые маячки для слежки за их владельцами, вне зависимости от того, подключены ли эти аксессуары к iPhone, Android-смартфону или даже ноутбуку. И несмотря на то, что технология, особенности реализации которой производителями гарнитур сделала возможной данную уязвимость, разработана в Google для Android-устройств, риски слежки оказываются куда выше у тех, кто использует уязвимые гарнитуры с устройствами под управлением других ОС — iOS, macOS, Windows или Linux — а владельцев iPhone это касается в первую очередь.
      Первичное подключение Bluetooth-наушников к Android-смартфонам стало проще и быстрее, когда Google внедрила технологию быстрого сопряжения Fast Pair, которую взяли на вооружение десятки производителей аксессуаров. Чтобы сопрячь со смартфоном новую гарнитуру, поддерживающую эту технологию, достаточно включить ее и поднести к смартфону. Если тот достаточно современный (произведен после 2019 года), на его экране всплывет окошко с предложением подключиться к гарнитуре и загрузить фирменное приложение для наушников, если оно существует. Одно касание — и дело сделано.
      К сожалению, многие производители гарнитур, видимо, неправильно прочитали инструкцию к этой технологии, поэтому их аксессуары можно за считаные секунды подключить к чужому смартфону, даже если гарнитура не находится в режиме сопряжения. В этом суть уязвимости WhisperPair, недавно найденной исследователями из Лёвенского университета и получившей номер CVE-2025-36911.
      Вредоносное устройство — обычный смартфон или ноутбук атакующего — транслирует запросы Google Fast Pair и пытается соединиться с BT-устройствами в радиусе 14 метров. Как выясняется, на эти запросы, даже не находясь в режиме сопряжения, откликаются многие наушники Sony, JBL, Redmi, Anker, Marshall, Jabra, OnePlus и даже Pixel Buds 2 от Google. На атаку в среднем требуется 10 секунд.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Миллионы ИТ-систем, включая индустриальные и IoT, начнут непредсказуемо вести себя 19 января. Среди возможных сбоев: проблемы в обработке карточных платежей, ложные срабатывания систем безопасности, некорректная работа медицинского оборудования, сбои систем автоматизированного освещения, отопления и водоснабжения и тысячи более безобидных ошибок. Правда, произойдет это в 2038 году, но это не повод расслабляться — времени на подготовку уже недостаточно. Причиной вороха разных проблем станет переполнение переменных, в которых хранится дата и время. Хотя первопричина ошибки проста и понятна, ее устранение потребует обширных и систематизированных усилий, причем как от государств и международных структур, так и от конкретных организаций и частных лиц.
      Негласный стандарт «эпохи» Unix
      Unix Epoch — это система отсчета времени, принятая в операционных системах Unix и ставшая популярной в ИТ-индустрии. Отсчет ведется с момента 00:00:00 UTC 1 января 1970 года, который принят за нулевую точку. Любой момент времени представляется как количество секунд, прошедших с этой даты. Для дат ранее 1970 года используются отрицательные значения. Этот подход был выбран разработчиками Unix для простоты — вместо хранения года, месяца, дня и времени по отдельности достаточно одного числа, с которым удобно проводить манипуляции вроде сортировки или определения промежутка между датами. Сегодня Unix Epoch используется далеко за пределами Unix-систем: в базах данных, языках программирования, сетевых протоколах, в смартфонах на iOS и Android.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Жизнь современного директора по ИБ (также известного как CISO, Chief Information Security Officer) — это не только борьба с хакерами, но и бесконечный квест под названием «соответствие требованиям». Регуляторы закручивают гайки, стандарты растут как грибы, и головной боли только прибавляется. И самое «веселое» тут то, что отвечать приходится не только за свой периметр, но и, фигурально выражаясь, «за того парня». За всю вашу цепочку поставок (supply chain), за всех подрядчиков и за весь тот «зоопарк» софта, на котором крутятся ваши бизнес-процессы. Логика тут железная и, увы, беспощадная: если дыра найдется у вашего поставщика, а проблемы начнутся у вас — спросят-то в итоге с вас! Распространяется эта логика и на защитное ПО.
      В былые времена компании редко задумывались, что там внутри ИБ-решений и продуктов, которые они использовали. Сейчас бизнес, особенно крупный, хочет знать: а что там внутри этой «коробки»? А кто код писал? А оно не обвалит нам какую-нибудь важную функцию или, например, вообще все (а то прецеденты всякие случались, см. случай с обновлением CrowdStrike 2024 года)? Где и как обрабатываются данные? Это абсолютно правильные вопросы!
      Проблема в том, что пока они часто повисают в воздухе. Почти все заказчики производителям доверяют, очень часто вынужденно, просто потому, что другого варианта нет. Конечно, более зрелый подход в нынешней киберреальности — проверять.
      На корпоративном языке это называется доверие к цепочкам поставок (supply chain trust), и решать эту задачку самостоятельно — та еще головная боль. Тут нужна помощь производителя. Ответственный вендор готов показывать, что под капотом решений, открывать исходный код партнерам и заказчикам для проверки — в общем, заслуживать доверие не красивыми слайдами, а «железобетонными» практическими шагами.
      Кто уже делает это, а кто застрял в прошлом? Отвечает свежайшее, фундаментальное исследование от коллег из Европы. Его провели уважаемый тестер AV-Comparatives, Экономическая палата Австрии (WKO), бизнес-школа MCI The Entrepreneurial School и юридическое бюро Studio Legale Tremolada.
      Короткий вывод исследования: эпоха черных ящиков в кибербезе закончилась. RIP. Аминь. Будущее — за теми, кто не прячет исходные коды и отчеты об уязвимостях и дает клиентам максимум выбора при настройке продукта. И в отчете четко написано, кто не только обещает, но и реально делает. Угадайте кто?
      Правильно, мы!
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      В 2025 году исследователи кибербезопасности обнаружили несколько открытых баз данных различных ИИ-инструментов для генерации изображений. Уже этот факт заставляет задуматься о том, насколько ИИ-стартапы заботятся о приватности и безопасности данных своих пользователей. Но куда большую тревогу вызывает характер контента в этих базах.
      Большое количество сгенерированных картинок в этих базах данных — изображения женщин в белье или вовсе обнаженных. Часть из них явно была создана на основе детских фотографий или же предполагала омоложение и оголение взрослых женщин. И наконец, самое неприятное. Некоторые порнографические изображения были сгенерированы на основе совершенно невинных фотографий настоящих людей, вероятно, взятых из соцсетей.
      Сегодня поговорим о том, что такое секс-шантаж и почему из-за ИИ-инструментов его жертвой может стать любой, опишем содержание обнаруженных открытых баз данных, а также дадим советы, как не стать жертвой секс-шантажа в эпоху ИИ.
      Что такое секс-шантаж
      Секс-шантаж в эпоху Интернета превратился в настолько распространенное явление, что даже обрел в мире собственное название – sextortion (сочетание слов sex и extortion – вымогательство). Разные его виды мы уже подробно рассматривали в посте Пятьдесят оттенков секс-шантажа. Напомним, что при этой разновидности шантажа жертву запугивают публикацией интимных изображений или видео, чтобы заставить выполнить какие-то действия или выманить деньги.
      Ранее жертвами секс-шантажа обычно становились работницы индустрии для взрослых или женщины, поделившиеся интимным контентом с ненадежным человеком.
      Однако активное развитие искусственного интеллекта и особенно технологии преобразования текста в изображения (text-to-image) коренным образом изменило ситуацию. Теперь жертвой секс-шантажа может стать буквально любой человек, выложивший в публичный доступ свои самые невинные фотографии. Все дело в том, что генеративный ИИ дает возможность быстро, легко и достаточно правдоподобно «оголить» людей на любых цифровых изображениях или за несколько секунд подставить к голове человека сгенерированное обнаженное тело.
       
      View the full article
×
×
  • Создать...