ISACARuSec – Telegram
ISACARuSec
2.27K subscribers
1.77K photos
13 videos
303 files
5.64K links
Канал направления ИБ Московского отделения ISACA

Направление канала новости ISACA, новости в области управления ИБ в России и мире, обмен лучшими практиками.

https://engage.isaca.org/moscow/home

Связь с администрацией
@popepiusXIII
Download Telegram
Chapter_Content_Letter_December_2021.docx
19.9 KB
Дайджест ссылок и новостей ISACA за декабрь.

Chapter_Content_Letter_December_2021
Forwarded from SecAtor
Подтянулась тяжелая артиллерия: настоящий Jam, как мы и прогнозировали, еще впереди.

Все это даже после того, как CVE-2021-44228 была исправлена еще 6 декабря с выпуском Log4j 2.15.0, а вызванная этим патчем последующая CVE-2021-45046 (позволявшая эксплуатировать log4shell в некоторых нестандартных конфигурациях с возможностью атак с отказом в обслуживании) также была устранена выпуском самой последней версии Log4j 2.12.2 и 2.16.0, удаляющей функцию поиска сообщений и по умолчанию блокирующей доступ к JNDI.

Тем не менее, более 70 образцов, использующих эксплойт, обнаружено, что достаточно небольшой показатель по сравнению с тем, что, вероятно, уже присутствует в дикой природе.

Но что еще хуже, Bitdefender заметили, что за Log4Shell взялись первые вымогатели. Злоумышленники пытаются использовать ошибку для загрузки двоичного файла .NET с удаленного сервера, который шифрует файлы на целевой машине c расширением khonsari. Записка с требованием выкупа «КАК ПОЛУЧИТЬ СВОИ ФАЙЛЫ BACK.TXT» добавляется на рабочий стол.

Первый инцидент был зафиксирован 11 декабря, когда на уязвимый хост был загружен вредоносный двоичный файл с hxxp://3.145.115.94/zambo/groenhuyzen.exe. Это новое семейство программ-вымогателей, получивших название благодаря своему расширению в зашифрованных файлах. В реальности свое ПО хакеры нарекли именем владельца антикварного магазина в Луизиане. Почему – не ясно.

После запуска Khonsari сканит все диски и шифрует системные папки с документами, видео, изображениями, загрузками и рабочий стол. При этом не шифруются файлы с расширениями .ini и .lnk. Вредоносная программа использует AES 128 CBC с поддержкой алгоритма PaddingMode.Zeros для шифрования. Кроме того, как выяснили BitDefender в более поздних атаках хакеры использовали тот же сервер для распространения RAT Orcus.

Не обошлось и без китайских и иранских АРТ, следы которых выявили спецы из Mandiant. Воспользовавшись ситуацией всеобщего хаоса, АРТ занимались решением традиционных для них задач по кибершпионажу, но помимо прочего иранские субъекты выстраивались и под более агрессивные действия, преследуя подрывные цели. Представители Mandiant отказались сообщать подробную информацию о том, какие конкретно связанные АРТ принимали участие в атаках.

Согласно данным телеметрии Check Point с 44% корпоративных сетей обнаружено более 1,3 миллиона попыток использования уязвимости, большинство из которых были совершены известными вредоносными группами. Всеобщий хакерский ажиотаж и хаос во всем технологическом мире не вызывают удивления, исследование Wiz показывает, что более 89% всех сред имеют уязвимые библиотеки Log4j, разработчики которых в некоторых случаях даже не догадываются об этом. Настоящая черная пятница для хакеров всех мастей.

Учитывая, что Microsoft уже фиксировали имплантаты Cobalt Strike, не стоит считать первый пример эксплойта Log4j, непосредственно устанавливающего ransomware, последним. Вероятно, более увесистые акторы уже вовсю эксплуатируют Log4 Jam, но пока сосредоточены более на максимально широком таргетинге. А по истечении пары тройки недель мест на DLS, судя по всему, не будет хватать, чтоб упорядочить всех новых жертв ransomware.

Тем временем к настоящему моменту помимо исправления уязвимости, перед специалистами по ИБ стоит куда более сложная задача: выявить вероятного злоумышленника в сети.
Forwarded from SecAtor
​​Вызванная Log4Shell киберпандемия в сфере инфосек набирает новые обороты.

Наряду с выявленными более 1,8 млн. попыток эксплуатации первоначальной уязвимости CVE-2021-44228 в Log4j, хакеры начинают использовать вторую и третью уязвимости.

Это все при том, что выявлено более 60 использующих багу семейств malware, которые охватывают весь спектр вредоносных воздействий от майнеров и троянов удаленного доступа до ботнетов и веб-оболочек. И, что еще хуже, по данным MSTIC, брокеры первоначального доступа использовали уязвимость Log4Shell для проникновения в целевые сети, лазейки в которые затем были реализованы вымогателям.

Не менее активны оказались АРТ, связанные с Китаем (Hafnium), Ираном (APT 35 aka Phosphorus), Северной Корей и Турцией, в интересах которых отработать как можно больше уязвимых в моменте систем, начиная от интеграции уязвимости до развертывания полезных нагрузок в реальных условиях.

А теперь Cloudflare сообщают, что буквально вчера злоумышленники переориентировались на вторую CVE, обнаруженную в широко используемой утилите ведения журналов Log4j.

Уязвимость CVE-2021-45046 затрагивает все версии Log4j от 2.0-beta9 до 2.12.1 и от 2.13.0 до 2.15.0 и возникла неполного исправления Apache Software Foundation предыдущей CVE в некоторых нестандартных конфигурациях, отличных от настроек по умолчанию. Неполный патч для CVE-2021-44228 может быть использован для создания вредоносных входных данных с использованием шаблона поиска JNDI, что приводит к атаке типа отказ в обслуживании (DoS). В свою очередь, разработчики ее оперативно пофиксили в Log4j версии 2.16.0.

Еще большую тревогу вызывает исследование Praetorian, в котором исследователи предупреждают о третьей уязвимости в Log4j версии 2.15.0, которая дает возможность кражи конфиденциальных данных при определенных условиях. Технические подробности уязвимости не разглашаются, дабы предотвратить дальнейший коллапс, и, вероятно, еще и потому, что новая версия 2.16.0, по всей видимости, не содержит ее исправлений.

Можете сами оценить, как происходит эксфильтрация конфиденциальных данных в Log4j 2.15.0.
Версия 2.15 log4j уязвима не только к DoS но к RCE.

А теперь стало известно что версия 2.16 тоже уязвима к DoS.

Ряд экспертов указывают, что активные атаки с использованием уязвимостей log4j продлятся еще несколько лет.

https://issues.apache.org/jira/browse/LOG4J2-3230