14 июля в Canonical узнали, что кто-то владеет (возможно и пытается продать) базой логинов и паролей двух миллионов пользователей форумов Ubuntu. Расследование быстро показало, что информация похожа на правду, после чего форумы были просто временно отключены. Надо сказать, это очень правильный ход, хотя в другой компании и в другой ситуации на него могли бы и не решиться: как же так, ведь все узнают, что у нас проблемы с безопасностью, а так может никого и не взломают. Собственно, мы все это знаем благодаря подробному описанию инцидента на сайте разработчиков Ubuntu, так что вроде бы все закончилось хорошо.
Или нет? Утечка (подробное описание событий в этой новости) началась со эксплуатации уязвимости в плагине Forumrunner, установленного на vBulletin, при помощи SQL-инъекции. Атака стала возможной из-за использования устаревшей версии плагина. Инъекция открыла доступ на чтение ко всей базе данных форума, но, как утверждает Джейн Сильбер, директор Canonical, взломщику удалось скачать только часть пользовательской базы с «устаревшими» паролями, которые к тому же были захешированы с солью.
В том, что актуальные пароли не утекли, в Canonical уверены. Также там предполагают, что взломщику не удалось развить атаку и получить доступ к чему-то еще. При всем образцовом поведении компании данном случае, нельзя не отметить эту общую неуверенность. Иными словами — убедились там, где это позволяли сделать логи, а дальше — ну кто ж его знает. Вроде бы все хорошо, тем более, что прежде чем поднимать форум, его чуть ли не переустановили с нуля. История с хэппи-эндом, но пожалуй с чем нужно бороться в сфере ИБ, так именно с подобной неуверенностью. Ну и узнавать о взломе хочется не от доброжелателей, а самостоятельно, и сразу, но тут уж как повезет.
HTTPoxy: уязвимость в реализации интерфейса CGI затрагивает большое количество сетевого софта
Новость.
У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но кажется мы к такому уже привыкли. Тем более, что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections. HTTPoxy (сайт уязвимости) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python, и соответственно, реализованные на них веб-приложения и скрипты. Таких существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.
А суть уязвимости довольно простая. В ситуации, когда требуется задать рабочему окружению в Linux прокси-сервер для доступа к сети, для этого часто используется переменная HTTP_PROXY. В некоторых реализациях интерфейса CGI описывается заголовок Proxy, который может быть передан серверу во время обмена данными, и на стороне сервера эта информация сохраняется в переменную HTTP_PROXY. Собственно все, проблема как раз конфликте имен, и это позволяет во многих ситуациях направлять данные через прокси-сервер, который был задан снаружи. Кем угодно, что ведет к атаке типа Man in the middle. Что интересно, спецификации на переменную нигде толком (например в документе RFC 3875) не прописаны. Решение очевидно: нужно заблокировать передачу такого заголовка. Но это для начала, а вообще надо править реализацию обработки данной переменной везде, где только можно.
Fun fact на закуску: уязвимости 15 лет. Впервые ее обнаружили и пофиксили в библиотеке libwww_perl в марте 2001 года. В апреле того же года исправили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации). В 13-м и 15-м годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил «наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.
Oracle закрывает 276 уязвимостей в своих продуктах
Новость.
В январе этого года Oracle выпустила рекордный кумулятивный патч, закрыв одним махом 248 уязвимостей. В июле рекорд побит с запасом: ежемесячный security-апдейт закрывает 276 уязвимостей в 84 продуктах. Зная, как сложно тестировать сразу много продуктов в разных сценариях, эту новость нужно безусловно оценить как в положительную, хотя в конце года вендор наверняка попадет в очередной некорректный список самых небезопасных разработчиков. Впрочем, выявленные проблемы от этого проще не становятся: из 276 уязвимостей 159 могут быть эксплуатированы удаленно, 19 (в девяти продуктах) оценены в 9,8 балла по шкале CVSS.
Впрочем, в Java, некогда самой часто атакуемой программе, а ныне уступившей сомнительное лидерство Adobe Flash, обнаружено и закрыто всего 13 уязвимостей, из них 9 с возможностью удаленной эксплуатации. Это третья на сегодня новость с эффектом «ложечки нашлись, осадочек остался». Oracle, конечно, молодцы. Но не думаю, что администраторы корпоративного софта Oracle будут сильно рады необходимости все бросить и накатывать столь гигантские патчи. А ведь придется.
Что еще произошло:
Развивается тема поведенческого анализа и блокирования криптолокеров по характеру изменения шифруемых данных. Исследователи из двух американских университетов разработали алгоритм, который задетектировал все из 500 (не так уж много для серьезного теста) сэмплов троянов-вымогателей. Но, увы, с потерей файлов, видимо, по причине того, что алгоритм распознавал характерные изменения не сразу. В каждом из тестов трояны что-то, да успевали зашифровать. В зависимости от ситуации терялись от 3 до 29 файлов.
Закрыта уязвимость в сетевых устройствах Juniper.
В дарквебе нашли супердешевый троян-вымогатель, всего 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Или нет? Утечка (подробное описание событий в этой новости) началась со эксплуатации уязвимости в плагине Forumrunner, установленного на vBulletin, при помощи SQL-инъекции. Атака стала возможной из-за использования устаревшей версии плагина. Инъекция открыла доступ на чтение ко всей базе данных форума, но, как утверждает Джейн Сильбер, директор Canonical, взломщику удалось скачать только часть пользовательской базы с «устаревшими» паролями, которые к тому же были захешированы с солью.
В том, что актуальные пароли не утекли, в Canonical уверены. Также там предполагают, что взломщику не удалось развить атаку и получить доступ к чему-то еще. При всем образцовом поведении компании данном случае, нельзя не отметить эту общую неуверенность. Иными словами — убедились там, где это позволяли сделать логи, а дальше — ну кто ж его знает. Вроде бы все хорошо, тем более, что прежде чем поднимать форум, его чуть ли не переустановили с нуля. История с хэппи-эндом, но пожалуй с чем нужно бороться в сфере ИБ, так именно с подобной неуверенностью. Ну и узнавать о взломе хочется не от доброжелателей, а самостоятельно, и сразу, но тут уж как повезет.
HTTPoxy: уязвимость в реализации интерфейса CGI затрагивает большое количество сетевого софта
Новость.
У нас еще одна уязвимость с привлекательным брендом и даже логотипом, но кажется мы к такому уже привыкли. Тем более, что уязвимость заслуживает внимания широченным охватом подверженного софта. Как правило такие универсальные дыры обнаруживаются в многократно используемых библиотеках: можно вспомнить прошлогодний пример с Apache Commons Collections. HTTPoxy (сайт уязвимости) круче по радиусу поражения, так как это уязвимость не в софте, а в реализации интерфейса CGI. Это, например, стандартные библиотеки для языков программирования PHP, Go и Python, и соответственно, реализованные на них веб-приложения и скрипты. Таких существует огромное количество, как готовых, так и самописных, и лучшее решение — заблокировать возможность эксплуатации уязвимости для всего сразу, внеся изменения в конфиги Apache, NGINX, lighttpd и прочего софта.
А суть уязвимости довольно простая. В ситуации, когда требуется задать рабочему окружению в Linux прокси-сервер для доступа к сети, для этого часто используется переменная HTTP_PROXY. В некоторых реализациях интерфейса CGI описывается заголовок Proxy, который может быть передан серверу во время обмена данными, и на стороне сервера эта информация сохраняется в переменную HTTP_PROXY. Собственно все, проблема как раз конфликте имен, и это позволяет во многих ситуациях направлять данные через прокси-сервер, который был задан снаружи. Кем угодно, что ведет к атаке типа Man in the middle. Что интересно, спецификации на переменную нигде толком (например в документе RFC 3875) не прописаны. Решение очевидно: нужно заблокировать передачу такого заголовка. Но это для начала, а вообще надо править реализацию обработки данной переменной везде, где только можно.
Fun fact на закуску: уязвимости 15 лет. Впервые ее обнаружили и пофиксили в библиотеке libwww_perl в марте 2001 года. В апреле того же года исправили аналогичную проблему в утилите curl. В 2012 году избежали уязвимой реализации стандарта разработчики Ruby (и написали об этом в документации). В 13-м и 15-м годах, по данным исследователей HTTPoxy, компании VendHQ, проблема несколько раз всплывала на форумах и в почтовых рассылках. В одном случае топикстартер был настолько поражен банальностью беды, что добавил «наверняка я здесь что-то упустил». Но нет. Хорошая история про особое направление в безопасности: правильный сбор, обработка и интерпретирование доступной всем (годами!) информации.
Oracle закрывает 276 уязвимостей в своих продуктах
Новость.
В январе этого года Oracle выпустила рекордный кумулятивный патч, закрыв одним махом 248 уязвимостей. В июле рекорд побит с запасом: ежемесячный security-апдейт закрывает 276 уязвимостей в 84 продуктах. Зная, как сложно тестировать сразу много продуктов в разных сценариях, эту новость нужно безусловно оценить как в положительную, хотя в конце года вендор наверняка попадет в очередной некорректный список самых небезопасных разработчиков. Впрочем, выявленные проблемы от этого проще не становятся: из 276 уязвимостей 159 могут быть эксплуатированы удаленно, 19 (в девяти продуктах) оценены в 9,8 балла по шкале CVSS.
Впрочем, в Java, некогда самой часто атакуемой программе, а ныне уступившей сомнительное лидерство Adobe Flash, обнаружено и закрыто всего 13 уязвимостей, из них 9 с возможностью удаленной эксплуатации. Это третья на сегодня новость с эффектом «ложечки нашлись, осадочек остался». Oracle, конечно, молодцы. Но не думаю, что администраторы корпоративного софта Oracle будут сильно рады необходимости все бросить и накатывать столь гигантские патчи. А ведь придется.
Что еще произошло:
Развивается тема поведенческого анализа и блокирования криптолокеров по характеру изменения шифруемых данных. Исследователи из двух американских университетов разработали алгоритм, который задетектировал все из 500 (не так уж много для серьезного теста) сэмплов троянов-вымогателей. Но, увы, с потерей файлов, видимо, по причине того, что алгоритм распознавал характерные изменения не сразу. В каждом из тестов трояны что-то, да успевали зашифровать. В зависимости от ситуации терялись от 3 до 29 файлов.
Закрыта уязвимость в сетевых устройствах Juniper.
В дарквебе нашли супердешевый троян-вымогатель, всего 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Поделиться с друзьями
Комментарии (4)
Warezovvv
22.07.2016 17:07Интересно, а сегодня есть актуальная (более-менее) качественная литература по вирусам и троянам? Навеяло фоткой книги Евгения. Что люди у вас в лаборатории читают?)
dmx102
При чем здесь PHP, Go и Python в заголовке, если проблема в самом протоколе?
В добавок CGI это уже прошлый век.
nokimaro
То есть php-fpm (FastCGI) не затрагивает? В PHP 7 уязвимость пофиксили, но я так и не понял как на практике (в каких приложениях) эта уязвимость может быть реально опасна?
dmx102
На сколько мне известно, основное отличие FastCGI от CGI в том, что первый держит пул процессов и направляет данные запроса на обработку. Во втором процесс запускается при каждом запросе, что существенно снижает производительность. И первый вместо STDIN использует сокеты.
В остальном если отличия и есть, то они минимальны.