В тот момент, когда елка уже стоит, но салаты еще не нарезаны, самое время в последний раз в этом году поговорить о новостях безопасности. На прошлой неделе я отчитался о «нестандартных» лучших новостях года, и в общем-то за оставшееся время ничего особенного не произошло. Хотя нет, есть одна новость, которая достойна отдельного повествования. Обнаруженные 17 декабря два бэкдора в ПО для сетевых устройств Juniper могли бы пополнить длинный, но невыдающийся список багов, эксплойтов и некорректных конфигураций в маршрутизаторах и домашних роутерах. Но позднее выяснилось, что в этой истории есть масса нюансов, она затрагивает не только тему безопасного кодинга, но и шифрование, и даже появились намеки на участие спецслужб. В общем, интересное получилось окончание года. Помимо Juniper, еще две популярные новости больше уходят в тему околобезопасной политики. Традиционные правила: каждую неделю редакция новостного сайта Threatpost выбирает три наиболее значимых новости, к которым я добавляю расширенный и беспощадный комментарий. Все эпизоды сериала можно найти по тегу. Первый эпизод нового года выйдет на экраны страны 8 января!
В устройствах Juniper обнаружили два бэкдора: нетривиальный и совсем нетривиальный
Новость. Шокирующие подробности. Вновь открывшиеся обстоятельства. Статья в Knowledge Base Juniper.
17 декабря на сайте Juniper появляется сообщение об успешном закрытии двух серьезных уязвимостей в операционной системе ScreenOS — проприетарной ОС, под управлением которой работают сетевые фаерволы enterprise-класса Netscreen. Это такие высокопроизводительные железки, обеспечивающие фильтрацию трафика, VPN, защиту от DDoS на каналах с пропускной способностью от 10 гигабит в секунду и выше. Обе уязвимости очень опасные, но каждая в отдельности угрожает безопасности передаваемых данных по своему. Поэтому разделить их можно на «просто нетривиальную» и «совсем нетривиальную».
Просто нетривиальная уязвимость
Лог здорового человека и лог курильщика
Найдите десять отличий. Единственное отличие нормального логина от несанкционированного в имени пользователя — во втором случае появляется запись о входе от имени юзера system. Не самый лучший индикатор взлома, тем более, как правильно замечают в Juniper, эти две строчки злоумышленник потрет в первую очередь. То есть речь идет о закладке в коде, которая позволяет авторизоваться пользователю, которого администратор устройства не создавал — это достаточно типичная ситуация. По факту все несколько сложнее, или проще — это как посмотреть. Собственно, в сообщении Juniper деталей и не было: «мы нашли две дыры, вот патчи, спасибо». Учитывая опасность уязвимостей, их нельзя винить в попытке скрыть какую-то информацию. Проблема в том, что сравнить код двух версий «до патча и после» и выяснить, как именно работает бэкдор, особой проблемы не составляет.
Такой анализ сделали многие, в том числе компания Rapid7. Оказалось, что речь не идет о секретной паре «юзернейм-пароль», а только о пароле, причем закодированном так, что при просмотре исходного кода он выглядит то ли как комментарий, то ли как отладочный код. В общем, если уязвимый сетевой экран виден «снаружи», то подключиться к нему с правами полного доступа не составляет труда. Приводятся данные из специализированного поисковика Shodan: всего на момент публикации исследования он видел 26 тысяч устройств NetScreen (но не обязательно уязвимых), к которым можно подключиться по SSH снаружи. Бэкдор доступен предположительно с 2013 года — именно тогда была выпущена версия, в которой появилась данная закладка.
Совсем нетривиальная уязвимость
Вторая уязвимость присутствует в ScreenOS несколько дольше — с 2012 года, и она позволяет расшифровывать VPN-трафик. Что это означает для компаний, использующих комплексы NetScreen для защищенной связи между подразделениями по открытым сетям, думаю объяснять не нужно. Как справедливо отмечается в изначальном сообщении компании, определить, была ли эксплуатирована данная уязвимость, не представляется возможным. Как так получилось? Чтобы разобраться, придется снова погрузиться в дебри вопросов шифрования. Нормальный человек в этих дебрях выглядит примерно так:
Но я все же попробую, опираясь на пост Мэтью Грина, известного криптографа. Начинается статья позитивно: «не будем сильно вдаваться в детали». Ага, не будем. Суть в том, что в ScreenOS используется алгоритм псевдослучайной генерации Dual_EC_DRBG. О том, что данный алгоритм ненадежен при определенной реализации, я уже писал ранее, в истории про коммюнике (уии!) АНБ касательно алгоритмов шифрования, стойких к квантовым вычислениям. Процитирую:
«Есть в нем бэкдор или нет, до конца неизвестно, но в начале 2000-х NSA активно агитировала за стандартизацию алгоритма, в 2007-м появились подозрения в наличии бэкдора, а в 2013 утечки Сноудена подтвердили, что какая-то программа то ли по внедрению закладок, то ли по пропаганде заведомо ослабленных алгоритмов, существовала. Относилось ли это к конкретному шифру — непонятно, но осадочек остался.»
В ответ на уже много лет высказываемые сомнения в стойкости алгоритма, Juniper в свое время выпустила заявление: даже если и так, то ScreenOS не подвержена, так как использует собственную реализацию алгоритма, в которой вывод Dual_EC_DRBG передается для дальнейшей обработки другому алгоритму — FIPS/ANSI X.9.31 PRNG. По словам Мэтью Грина такой конвейер действительно снимает все вопросы об уязвимости, но с одним условием: если атакующая сторона не имеет доступа к изначальной последовательности чисел, генерируемой с помощью Dual_EC_DRBG. Причем вся последовательность не требуется — достаточно первых 30 байт или около того. Так вот, добытая путем анализа и реверс-инжиниринга патчей информация указывает на то, что именно это (сырой вывод первых 32 байт алгоритма) и происходит! Получив 32 байта вывода, становится возможным предсказать, что с этими данными дальше произойдет, и в конце-концов получить ключ к шифрованному трафику.
Мэтью Грин не делает выводы относительно «заказчика» бэкдоров, но еще раз поднимает тему опасности намеренного ослабления криптографии. Тот, кто оставляет (внедряет без ведома вендора, или при его помощи, не важно) лазейку только для себя, не может гарантировать, что ей не смогут воспользоваться другие. Добавлю, что в документах, полученных от Эдварда Сноудена, и алгоритм Dual_EC_DRBG, и конкретно устройства Juniper с каким-то бэкдором упоминаются не по одному разу.
Такие дела.
Oracle договорилась с Торговой Комиссией США, что безопасность у Java так себе
Новость.
Oracle заключила мировое соглашение с Федеральной Торговой Комиссией США по диспуту о безопасности платформы Java. Казалось бы, где Java, а где FTC, и почему местный минторг вообще волнуют уязвимости в софте? Хотя таки да, есть о чем поволноваться, вот традиционная подборка новостей за год: раз, два, три, и так далее. Java регулярно соревнуется с Adobe Flash за звание самого эксплуатируемого взломщиками софта, и в последнее время Flash выигрывает (то есть проигрывает) — его атакуют чаще всего. По нашей статистике, в 2015 году Java-уязвимости использовались в 13% атак с применением эксплойтов, хотя годом ранее было 45%. Практически во всех эксплойт-паках Java теперь не используется вовсе. В общем, вроде бы все не так плохо?
Ну так и новость не про это :) FTC — это все же госструктура, и реагирует на стремительно меняющийся ландшафт угроз она… не быстро. Речь в разбирательства шла о старых версиях Java, и о заявлениях Oracle: ну, когда компания призывает пользователей обновляться для того, чтобы себя обезопасить. Как минимум до августа 2014 года обновление Java работало так, что «обезопашивало» пользователей не до конца: в некоторых случаях старые версии Java оставались где-то в недрах системы, и по-прежнему могли быть атакованы. Проблема решалась только полным удалением старой версии перед установкой новой. Многим известно, насколько «удобно» и «прозрачно» были реализованы апдейты до недавнего времени. В общем, договорились о том, что компания будет уведомлять пользователей «более лучше».
Важным нюансом новости является отсылка на некую внутреннюю переписку Oracle, проанализированную в ходе расследования. Из нее стало известно, что проблемы с апдейтами секретом для сотрудников не были, но сделать с ними что-то полезное компания долго не могла. Не могу не напомнить в связи с этим про августовский PR-провал Oracle, когда их CSO рекомендовал независимым исследователям и клиентам держать свой дизассемблер при себе — дескать «вендор сам справится» с секьюрити-аудитом.
Facebook обвинила исследователя в аморальном баг-хантинге
Новость. Блог исследователя.
Ничто не предвещало беды, когда эксперт по безопасности Уэсли Вайнберг отправил в Facebook информацию об уязвимости в серверной инфраструктуре Instagram. На его сообщение отреагировали, поблагодарили и сообщили, что он квалифицирован на получение 2500 долларов в рамках программы bug bounty. Дальше события развивались нестандартно: Вайнберг продолжил исследования, умудрился сломать чуть ли не весь Instagram — в смысле добрался до серверов с исходным кодом и данными пользователей — а Facebook обвинил его в неэтичном поведении.
Показания участников противоречат друг другу. По словам Вайнберга, он откопал целую серию уязвимостей, благодаря чему смог получить доступ к виртуальным серверам Instagram в Amazon S3. По мнению CSO Facebook Алекса Стамоса, точка входа была одна, спасибо Вайнбергу за репорт, но лезть дальше было неэтично: нельзя, мол, ломать серверы и красть данные сотрудников и пользователей, и называть это секьюрити ресерчем. Возмущенный Стамос позвонил работодателю Вайнберга, компании Synack, и таким образом добавил в историю новых участников и драмы. Сам Вайнберг в ответ намекнул, что Facebook пыталась задержать публикацию информации об уязвимостях, что является священным правом исследователя.
В общем, сложно разобрать, кто в этой истории прав, а кто нет. Понятно только, что каких-то определенных правил взаимодействия исследователей и вендоров как не было, так и нет, не говоря уж о таких неалгоритмизируемых задачах, как этический код. И было бы неплохо эти правила придумать. Во-первых, это пойдет на пользу индустрии в целом — ведь Instagram в итоге закрыл дыру до того, как ей смогли воспользоваться злоумышленники. Во-вторых, лучше индустрии придумать эти правила самостоятельно, пока за них не взялись профессиональные законодатели — при таком раскладе, сами понимаете, всякое может произойти.
Древности:«Stone-a,-b,-c,-d»
При загрузке с зараженного флоппи-диска с вероятностью 1/8 на экране появляется сообщение «Your PC is now Stoned!». Помимо указанной, содержат строку «LEGALISE MARIJUANA!». Вирус «Stone-c» при заражении MBR винчестера уничтожает таблицу разбиения (Disk Partition Table), после этого компьютер можно загрузить только с флоппи-диска. «Stone-d» 1-го октября уничтожает информацию на винчестере.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страница 97.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
