facebook
В тот момент, когда елка уже стоит, но салаты еще не нарезаны, самое время в последний раз в этом году поговорить о новостях безопасности. На прошлой неделе я отчитался о «нестандартных» лучших новостях года, и, в общем-то, за оставшееся время ничего особенного не произошло.
Хотя нет, есть одна новость, которая достойна отдельного повествования. Обнаруженные 17 декабря два бэкдора в ПО для сетевых устройств Juniper могли бы пополнить длинный, но невыдающийся список багов, эксплойтов и некорректных конфигураций в маршрутизаторах и домашних роутерах. Но позднее выяснилось, что в этой истории есть масса нюансов, она затрагивает не только тему безопасного кодинга, но и шифрование, и даже появились намеки на участие спецслужб.
Наконец-то собрали нестандартный топ событий в сфере IT-безопасности 2015: https://t.co/DV1hgHcV6V pic.twitter.com/fAJyRUDyJK
— Kaspersky (@Kaspersky_ru) December 24, 2015
В общем, интересное получилось окончание года. Ну а если не брать Juniper, то еще две популярные новости больше уходят в тему околобезопасной политики. Традиционные правила: каждую неделю редакция новостного сайта Threatpost выбирает три наиболее значимые новости, к которым я добавляю расширенный и беспощадный комментарий. Все эпизоды сериала можно найти по тегу. Первый эпизод нового года выйдет на экраны страны 8 января!
В устройствах Juniper обнаружили два бэкдора: нетривиальный и совсем нетривиальный
Новость. Шокирующие подробности. Вновь открывшиеся обстоятельства. Статья в Knowledge Base Juniper.
17 декабря на сайте Juniper появляется сообщение об успешном закрытии двух серьезных уязвимостей в операционной системе ScreenOS — проприетарной ОС, под управлением которой работают сетевые файерволы enterprise-класса NetScreen. Это такие высокопроизводительные железки, обеспечивающие фильтрацию трафика, VPN, защиту от DDoS на каналах с пропускной способностью от 10 Гбит/с и выше. Обе уязвимости очень опасные, но каждая в отдельности угрожает безопасности передаваемых данных по-своему. Поэтому разделить их можно на «просто нетривиальную» и «совсем нетривиальную».
Просто нетривиальная уязвимость
Лог здорового человека и лог курильщика
Найдите десять отличий. Единственное отличие нормального логина от несанкционированного в имени пользователя — во втором случае появляется запись о входе от имени юзера system. Не самый лучший индикатор взлома, тем более что, как правильно замечают в Juniper, эти две строчки злоумышленник потрет в первую очередь. То есть речь идет о закладке в коде, позволяющей авторизоваться пользователю, которого администратор устройства не создавал, — это достаточно типичная ситуация.
По факту все несколько сложнее, ну или проще — это как посмотреть. Собственно, в сообщении Juniper деталей и не было: «Мы нашли две дыры, вот патчи, спасибо». Учитывая опасность уязвимостей, нельзя винить Juniper в попытке скрыть какую-то информацию. Сравнить код двух версий «до патча и после» и выяснить, как именно работает бэкдор, особой проблемы не составляет.
Интересно, хотя и немного сложное в понимании, продолжение истории с расшифровкой VPN-трафика: https://t.co/PcuUNyLURw
— Kaspersky (@Kaspersky_ru) December 24, 2015
Такой анализ сделали многие, в том числе компания Rapid7. Оказалось, что речь не идет о секретной паре «юзернейм – пароль», а только о пароле, причем закодированном так, что при просмотре исходного кода он выглядит то ли как комментарий, то ли как отладочный код. В общем, если уязвимый сетевой экран виден «снаружи», то подключиться к нему с правами полного доступа не составляет труда. Приводятся данные из специализированного поисковика Shodan: всего на момент публикации исследования он видел 26 тыс. устройств NetScreen (но необязательно уязвимых), к которым можно подключиться по SSH снаружи. Бэкдор доступен предположительно с 2013 года — именно тогда была выпущена версия, в которой появилась данная закладка.
Совсем нетривиальная уязвимость
Вторая уязвимость присутствует в ScreenOS несколько дольше — с 2012 года, и она позволяет расшифровывать VPN-трафик. Что это означает для компаний, использующих комплексы NetScreen для защищенной связи между подразделениями по открытым сетям, думаю, объяснять не нужно. Как справедливо отмечается в изначальном сообщении компании, определить, была ли использована данная уязвимость, не представляется возможным. Как так получилось? Чтобы разобраться, придется снова погрузиться в дебри вопросов шифрования. Нормальный человек в этих дебрях выглядит примерно так:
Но я все же попробую разобраться, опираясь на пост Мэтью Грина, известного криптографа. Начинается статья позитивно: «Не будем сильно вдаваться в детали». Ага, не будем. Суть в том, что в ScreenOS используется алгоритм псевдослучайной генерации Dual_EC_DRBG. О том, что данный алгоритм ненадежен при определенной реализации, я уже писал ранее, в истории про коммюнике (уии!) АНБ касательно алгоритмов шифрования, стойких к квантовым вычислениям. Процитирую:
«Есть в нем бэкдор или нет, до конца неизвестно, но в начале 2000-х NSA активно агитировала за стандартизацию алгоритма, в 2007-м появились подозрения в наличии бэкдора, а в 2013-м утечки Сноудена подтвердили, что какая-то программа то ли по внедрению закладок, то ли по пропаганде заведомо ослабленных алгоритмов существовала. Относилось ли это к конкретному шифру — непонятно, но осадочек остался».
Разносторонний Java-баг, жизнь криптолокеров, 17 заплаток Adobe Flash — выжимка за неделю: https://t.co/53nH1sJWTC pic.twitter.com/yBQqAM5CBB
— Kaspersky (@Kaspersky_ru) November 13, 2015
В ответ на уже много лет высказываемые сомнения в стойкости алгоритма Juniper в свое время выпустила заявление: даже если и так, то ScreenOS уязвимостям не подвержена, так как использует собственную реализацию алгоритма, в которой вывод Dual_EC_DRBG передается для дальнейшей обработки другому алгоритму — FIPS/ANSI X.9.31 PRNG.
По словам Мэтью Грина, такой конвейер действительно снимает все вопросы об уязвимости, но с одним условием: если атакующая сторона не имеет доступа к изначальной последовательности чисел, генерируемой с помощью Dual_EC_DRBG. Причем вся последовательность не требуется — достаточно первых 30 байт или около того. Так вот, добытая путем анализа и реверс-инжиниринга патчей информация указывает на то, что именно это (сырой вывод первых 32 байт алгоритма) и происходит! Получив 32 байта вывода, взломщик может предсказать, что с этими данными дальше произойдет, и в конце концов получить ключ к шифрованному трафику.
Мэтью Грин не делает выводов относительно «заказчика» бэкдоров, но еще раз поднимает тему опасности намеренного ослабления криптографии. Тот, кто оставляет (внедряет без ведома вендора или при его помощи, не важно) лазейку только для себя, не может гарантировать, что ею не смогут воспользоваться другие. Добавлю, что в документах, полученных от Эдварда Сноудена, и алгоритм Dual_EC_DRBG, и конкретно устройства Juniper с каким-то бэкдором упоминаются не по одному разу.
Такие дела.
Новая порция документов из «утечки Сноудена» пролила свет на то, как АНБ расшифровывает перехваченные данные: https://t.co/9FTdA2mfK4
— Kaspersky (@Kaspersky_ru) October 20, 2015
Oracle договорилась с торговой комиссией США, что безопасность у Java так себе
Oracle заключила мировое соглашение с Федеральной торговой комиссией (ФТК) США по диспуту о безопасности платформы Java. Казалось бы, где Java, а где ФТК и почему местный минторг вообще волнуют уязвимости в софте? Хотя таки да, есть о чем поволноваться, вот традиционная подборка новостей за год: раз, два, три и так далее.
Java регулярно соревнуется с Adobe Flash за звание самого эксплуатируемого взломщиками софта, и в последнее время Flash выигрывает (то есть проигрывает) — его атакуют чаще всего. По нашей статистике, в 2015 году Java-уязвимости использовались в 13% атак с применением эксплойтов, хотя годом ранее было 45%. Практически во всех эксплойт-паках Java теперь не используется вовсе. В общем, вроде бы все не так плохо?
Java держит марку и остается самым опасным приложением в уходящем году! http://t.co/fwul3YH6OJ pic.twitter.com/nnwH7zBmjn
— Kaspersky (@Kaspersky_ru) December 12, 2014
Ну так и новость не про это. ФТК — это все же госструктура, и реагирует на стремительно меняющийся ландшафт угроз она… не быстро. Речь в разбирательстве шла о старых версиях Java и о заявлениях Oracle: ну, когда компания призывает пользователей обновляться для того, чтобы себя обезопасить.
Как минимум до августа 2014 года обновление Java работало так, что «обезопашивало» пользователей не до конца: в некоторых случаях старые версии Java оставались где-то в недрах системы и по-прежнему могли быть атакованы. Проблема решалась только полным удалением старой версии перед установкой новой. Многим известно, насколько «удобно» и «прозрачно» были реализованы апдейты до недавнего времени. В общем, договорились о том, что компания будет уведомлять пользователей «более лучше».
Важным нюансом новости является отсылка к некой внутренней переписке Oracle, проанализированной в ходе расследования. Из нее стало известно, что проблемы с апдейтами секретом для сотрудников не были, но сделать с ними что-то полезное компания долго не могла. Не могу не напомнить в связи с этим про августовский PR-провал Oracle, когда их CSO рекомендовал независимым исследователям и клиентам держать свой дизассемблер при себе — дескать, «вендор сам справится» с аудитом безопасности.
Facebook обвинила исследователя в аморальном баг-хантинге
Новость. Блог исследователя.
Ничто не предвещало беды, когда эксперт по безопасности Уэсли Вайнберг отправил в Facebook информацию об уязвимости в серверной инфраструктуре Instagram. На его сообщение отреагировали, поблагодарили и сообщили, что он квалифицирован на получение $2500 в рамках программы bug bounty. Дальше события развивались нестандартно: Вайнберг продолжил исследования, умудрился сломать чуть ли не весь Instagram — в том смысле, что он добрался до серверов с исходным кодом и данными пользователей, — а Facebook обвинила его в неэтичном поведении.
Показания участников противоречат друг другу. По словам Вайнберга, он откопал целую серию уязвимостей, благодаря чему смог получить доступ к виртуальным серверам Instagram в Amazon S3. По мнению CSO Facebook Алекса Стамоса, точка входа была одна, спасибо Вайнбергу за репорт, но лезть дальше было неэтично: нельзя, мол, ломать серверы, красть данные сотрудников и пользователей — и называть это исследованием безопасности. Возмущенный Стамос позвонил работодателю Вайнберга, в компанию Synack, и таким образом добавил в историю новых участников и драмы. Сам Вайнберг в ответ намекнул, что Facebook пыталась задержать публикацию информации об уязвимостях, что является священным правом исследователя.
https://twitter.com/alexstamos/status/677615723145994241
В общем, сложно разобрать, кто в этой истории прав, а кто нет. Понятно только, что каких-то определенных правил взаимодействия исследователей и вендоров как не было, так и нет, не говоря уж о таких неалгоритмизируемых задачах, как этический код. И было бы неплохо эти правила придумать. Во-первых, это пойдет на пользу индустрии в целом — ведь 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Советы