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

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

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

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

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

У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но кажется мы к такому уже привыкли. Тем более, что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections. HTTPoxy (сайт уязвимости ^[6]) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI ^[7]. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python, и соответственно, реализованные на них веб-приложения и скрипты. Таких существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.

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

Fun fact на закуску: уязвимости 15 лет. Впервые ее обнаружили и пофиксили в библиотеке libwww_perl в марте 2001 года. В апреле того же года исправили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации ^[9]). В 13-м и 15-м годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил «наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.

Oracle закрывает 276 уязвимостей в своих продуктах
Новость ^[10].

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

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

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

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

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

Древности:
«V-1260»

Нерезидентный безобидный вирус-«призрак». Поражает .COM-файлы по алгоритму вирусов «Vienna». Зашифрован, при этом использует два интересных алгоритма. Первый алгоритм реализует свойство «призрака», благодаря чему два штамма этого вируса с большой вероятностью не будут совпадать ни на одном байте. Основное тело вируса шифруется в зависимости от таймера по 16777216 вариантам, а расшифровщик выбирается из более чем 3,000,000,000,000,000,000,000 вариантов (длина расшифровщика — 39 байт). Второй алгоритм достаточно успешно мешает трассировке вируса — используется динамическое рас/зашифрование кодов вируса при помощи int 1 и int 3.

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

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

Автор: «Лаборатория Касперского»

Источник ^[16]