Flash-изъян открыл взломщикам путь в сеть RSA

Flash-изъян открыл взломщикам путь в сеть RSA

Внутреннее расследование, которое проводит RSA Security по факту мартовского проникновения злоумышленников в ее локальную вычислительную сеть, начинает приносить некоторые плоды, которые можно продемонстрировать публике. Так, компания сообщила, что киберпреступная операция началась с успешной атаки с использованием уязвимости в проигрывателе Flash от Adobe.


Речь идет о хронологически последней ошибке безопасности, известия о которой появились в середине марта; Anti-Malware.ru писал об этом изъяне. На тот момент, когда взломщики предпринимали нападение на RSA, соответствующих исправлений для опасной уязвимости еще не существовало. Сообщается, что злоумышленники направили двум небольшим группам сотрудников компании электронные письма со вредоносными вложениями - книгами Microsoft Excel, в которые были внедрены особые Flash-объекты; их запуск приводил к установлению удаленного контроля над пораженным компьютером.

Усилия киберпреступников увенчались успехом: один из работников заинтересовался файлом под названием "План найма сотрудников на 2011 год" и открыл его. Эксплуатация изъяна во Flash-проигрывателе позволила взломщикам внедрить в компьютер жертвы инструментарий удаленного управления Poison Ivy и извлечь аутентификационные сведения для доступа к некоторым информационным активам RSA. Затем злоумышленники провели поиск важных сведений и получили копии тех данных, которые их заинтересовали.

Похоже, что на персональных компьютерах в локальной сети компании использовались устаревшие версии офисных пакетов Microsoft: в наиболее актуальном на данный момент выпуске Office 2010 имеется встроенная защита от подобных атак. Во-первых, там используется механизм предотвращения исполнения данных (DEP), а во-вторых, внедренные объекты, равно как и прочее потенциально опасное содержимое, запускаются в безопасной среде. Office 2003 и 2007 такими средствами борьбы с угрозами не располагают.

В то же время RSA так до сих пор и не сообщила, какие именно информационные активы попали в руки злоумышленников. Официальные лица компании признают, что эти данные "имели отношение" к системам двухфакторной аутентификации SecurID, но и не более того. Формулировка эта довольно расплывчата и может обозначать практически все, что угодно - от эскизов дизайна аппаратных ключ-меток до корневых криптоалгоритмов мандатного контроля; неудивительно, что клиенты RSA Security и поныне пребывают в тревоге, а конкуренты оперативно разворачивают миграционные акции.

Computerworld

Письмо автору

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru