Червь Stuxnet эксплуатирует четыре 0-day уязвимости

Червь Stuxnet эксплуатирует четыре 0-day уязвимости

Исследователи в области безопасности выяснили, что червь Stuxnet, нацеленный на инфицирование промышленных систем управления, осуществлял атаки на четыре уязвимости ОС Windows, относящиеся к типу "0-day". Хотя это вредоносное программное обеспечение было впервые обнаружено еще в июле, основное внимание на протяжении прошедших месяцев уделялось уязвимости в обработке ярлыков, на данный момент уже закрытой. Теперь же оказалось, что червь использует не одну, а несколько уязвимостей, причем две из них все еще не исправлены.



"Если бы меня попросили назвать наиболее интересный факт относительно этой вредоносной программы (а выделить какой-то один факт довольно сложно), то я бы, пожалуй, назвал именно эксплуатацию червем сразу четырех ранее не известных уязвимостей," - отметил ведущий антивирусный эксперт североамериканского подразделения "Лаборатории Касперского" Роул Шоуэнберг. - "Но в целом интеллектуальный труд, продуктом которого стал Stuxnet, не менее удивителен и примечателен. Четыре 0-day уязвимости, два краденых цифровых сертификата, прекрасное знание систем SCADA - все было тщательно спланировано и приведено в исполнение".


Помимо ошибки в механизме обработки ярлыков, червь использовал уязвимость в службе Диспетчера очереди печати (Print Spooler), закрытую Microsoft буквально вчера, а также две по-прежнему не исправленные уязвимости, эксплуатация которых приводила к эскалации привилегий и установлению контроля над инфицированными системами. По сообщению представителя Microsoft, первой из этих двух уязвимостей подвержена Windows XP, в то время как вторая существует в Windows Vista, 7, Server 2008 и Server 2008 R2; специалисты компании работают над обновлениями, позволяющими ликвидировать уязвимости.


Напомним, что червь был впервые обнаружен аналитиками компании ВирусБлокАда; целью Stuxnet было программное обеспечение Simatic WinCC и PCS 7, используемое в промышленных системах управления на предприятиях Siemens. Роул Шоуэнберг указал, что в Индии за месяцы, прошедшие с момента обнаружения червя, количество пораженных им компьютеров постоянно росло, в то время как в Иране и Индонезии, напротив, снижалось. 


"К счастью, большинство операторов систем управления отделяют свою сеть от ЛВС предприятия и сетей общего доступа", - прокомментировал ведущий аналитик NetWitness Майк Сконзо. - "Это существенно снизило степень распространенности инфекции. Основными способами размножения червя были самокопирование на USB-носители, а также, по новым данным, распространение через ресурсы сети; замкнутость последней, равно как и ограничения, накладываемые на использование USB-приводов операторами систем управления, уменьшило потенциальную опасность вредоносной программы".


"Вряд ли эта первая таргетированная атака на промышленные системы окажется и последней", - добавил г-н Сконзо. - "Даже этот начальный опыт целевого нападения, направленный только против определенных систем, сумел достичь вполне заметных результатов".


eWeek

" />

Новая атака на кеш 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