Веб-мастеры оказались невосприимчивы к предупреждениям специалистов по безопасности

Веб-мастеры оказались невосприимчивы к предупреждениям специалистов по безопасности

...

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



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


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


Ведущий вирусный аналитик Sophos Фрэйзер Говард рассказал о своеобразном эксперименте, итоги которого он подвел на днях. В течение полутора лет специалист собирал данные о реакции веб-мастеров на письменные уведомления об инфекциях или взломах, и результат оказался неутешителен. "Заключение было очевидно: абсолютное большинство адресатов просто мне не поверило", - пишет г-н Говард.


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


В целом у специалиста сложилось ощущение, что многих разработчиков и администраторов волнует только доступность их Интернет-узла и нормальное отображение его страниц; к фоновым же процессам и прочей закадровой деятельности ответственные лица определенно не проявили никакого заметного интереса.


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


Softpedia

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