Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

В этом выпуске Константин Гончаров рассказывает об утечке миллионов паролей у разработчиков Ubuntu, о недавно найденной дыре в реализации CGI, которой уже 15 лет, а также о мега-патче Oracle, закрывающем 276 уязвимостей одним махом

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

14 июля в Canonical узнали, что кто-то владеет базой логинов и паролей 2 миллионов пользователей форумов Ubuntu (а возможно, и пытается ее продать). Расследование быстро показало, что информация похожа на правду, после чего форумы были просто временно отключены.

Надо сказать, это очень правильный ход, хотя в другой компании и в другой ситуации на него могли бы и не решиться: как же так, ведь все узнают, что у нас проблемы с безопасностью, а так, может, никого и не взломают. Собственно, мы все это знаем благодаря подробному описанию инцидента на сайте разработчиков Ubuntu, так что вроде бы все закончилось хорошо.

Или нет? Утечка (подробное описание событий в этой новости) началась с эксплуатации уязвимости в плагине Forumrunner, установленном на vBulletin, при помощи SQL-инъекции. Атака стала возможной из-за использования устаревшей версии плагина. Инъекция открыла доступ на чтение ко всей базе данных форума, но, как утверждает Джейн Сильбер, директор Canonical, взломщику удалось скачать только часть пользовательской базы с «устаревшими» паролями, которые к тому же были захешированы с солью.

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

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

HTTPoxy: уязвимость в реализации интерфейса CGI затрагивает большое количество сетевого софта

Новость.

У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но, кажется, мы к такому уже привыкли. Тем более что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило, такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections.

HTTPoxy (сайт уязвимости) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python и, соответственно, реализованные на них веб-приложения и скрипты. Их существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

А суть уязвимости довольно простая. В ситуации, когда требуется задать рабочему окружению в Linux прокси-сервер для доступа к Сети, для этого часто используется переменная HTTP_PROXY. В некоторых реализациях интерфейса CGI описывается заголовок Proxy, который может быть передан серверу во время обмена данными, и на стороне сервера эта информация сохраняется в переменную HTTP_PROXY.

Собственно, все: проблема как раз в конфликте имен, и это позволяет во многих ситуациях направлять данные через прокси-сервер, который был задан снаружи. Кем угодно, что ведет к атаке типа Man in the middle. Что интересно, спецификации на переменную нигде толком (в частности, в документе RFC 3875) не прописаны. Решение очевидно: нужно заблокировать передачу такого заголовка. Но это для начала, а вообще надо править реализацию обработки данной переменной везде, где только можно.

Забавный факт на закуску: уязвимости 15 лет. Впервые ее обнаружили и исправили в библиотеке libwww_perl в марте 2001 года. В апреле того же года устранили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации).

В 2013 и 2015 годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил: «Наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.

Oracle закрывает 276 уязвимостей в своих продуктах

Новость.

В январе этого года Oracle выпустила рекордный кумулятивный патч, закрыв одним махом 248 уязвимостей. В июле рекорд побит с запасом: ежемесячный security-апдейт закрывает 276 уязвимостей в 84 продуктах.

Зная, как сложно тестировать сразу много продуктов в разных сценариях, эту новость нужно безусловно оценить как положительную, хотя в конце года вендор наверняка попадет в очередной некорректный список самых небезопасных разработчиков. Впрочем, выявленные проблемы от этого проще не становятся: из 276 уязвимостей 159 могут быть эксплуатированы удаленно, 19 (в девяти продуктах) оценены в 9,8 балла по шкале CVSS.

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

Впрочем, в Java, некогда самой часто атакуемой программе, ныне уступившей сомнительное лидерство Adobe Flash, обнаружено и закрыто всего 13 уязвимостей, из них 9 — с возможностью удаленной эксплуатации. Это третья на сегодня новость с эффектом «ложечки нашлись, осадочек остался». Oracle, конечно, молодцы. Но не думаю, что администраторы корпоративного софта Oracle будут сильно рады необходимости все бросить и накатывать столь гигантские патчи. А ведь придется.

Что еще произошло:

Развивается тема поведенческого анализа и блокирования криптолокеров по характеру изменения шифруемых данных. Исследователи из двух американских университетов разработали алгоритм, который задетектировал все из 500 (не так уж много для серьезного теста) сэмплов троянов-вымогателей. Но, увы, с потерей файлов: видимо, по причине того, что алгоритм распознавал характерные изменения не сразу. В каждом из тестов трояны что-то да успевали зашифровать. В зависимости от ситуации терялись от 3 до 29 файлов.

Закрыта уязвимость в сетевых устройствах Juniper.

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

Security Week 29: утечка на форуме Ubuntu, прокси-уязвимость в PHP, Go и Python, 276 заплаток Oracle

Древности:

«V-1260»

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

Основное тело вируса шифруется в зависимости от таймера по 16 777 216 вариантам, а расшифровщик выбирается более чем из 3 000 000 000 000 000 000 000 вариантов (длина расшифровщика — 39 байт). Второй алгоритм достаточно успешно мешает трассировке вируса — используется динамическое рас/зашифрование кодов вируса при помощи int 1 и int 3.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 90.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Советы