Security Week 02: уязвимые веб-камеры, продолжение истории с Juniper, zero day в Silverlight и как ее нашли

Новости Угрозы
Security Week 02: уязвимые вебкамеры, продолжение истории с Juniper, Zero-Day в Silverlight и как его нашли

На этой неделе одной из самых обсуждаемых новостей стало окончание поддержки Microsoft Internet Explorer 8, 9 и 10. Данные версии браузеров перестанут получать обновления даже в случае обнаружения серьезных уязвимостей. Новость достаточно очевидная, чтобы не тратить на нее много места в дайджесте, но она наводит меня еще на одну мысль. Тем, кто пользуется IE 8, уже давно пора обновиться, и, возможно, прекращение поддержки наконец-то подтолкнет их к этому шагу. Обновиться достаточно просто. Кому-то, конечно, придется для этого купить новый компьютер, но и это — не большая проблема.

Проблемы начнутся, когда «компьютеров» с аналогичным подходом к разработке и развитию, в которых типичный софт и железо устаревают максимум за два-три года, будет несколько десятков в каждой отдельно взятой квартире — от счетчика электроэнергии до чайника и электроплиты. Заметный упор на «умные» бытовые приборы на CES (пока это в основном довольно странные и безумно дорогие холодильники и стиральные машины) показывает, что это произойдет довольно скоро. В нынешнем виде такие устройства могут работать десятилетиями. А в будущем? Представьте себе экосистему Android, распространившуюся на утюги и кофемолки. Получатся небезопасные устройства, которые надо обновлять, небезопасные устройства, которые не поддерживаются производителем, небезопасные устройства, о которых даже сам производитель не знает, что они небезопасные.

Какая-то не очень радужная перспектива, но пока я не вижу других вариантов развития. Производителям «умных вещей», увы, придется набить такие же шишки на лбу, которые для производителей «больших» операционных систем — давно пройденный этап. Ладно, едем дальше. Все выпуски дайджеста — тут.

Методы прикручивания бэкдора к дешевой веб-камере D-Link

Новость. Исследование.

Уязвимости в сетевых веб-камерах всегда вызывают большой интерес. Понятно почему: в голове сразу появляется картинка, как злоумышленник подглядывает за вами и вашими близкими. Исследование компании Vectra Networks вскрывает хоть и серьезную, но не самую ужасную проблему с такими устройствами. Купив одну из самых дешевых камер D-Link, эксперты разобрали ее прошивку и обнаружили, что вставить в нее бэкдор (в данном случае — кусок кода, который стучится на сервер потенциального вуайериста атакующего) несложно. Ну как несложно: надо все же получить доступ к устройству, слить прошивку, залить новую. Или не надо получать доступ, если убедить владельца камеры скачать зараженное «обновление». Впрочем, это тоже маловероятно.

Security Week 02: уязвимые вебкамеры, продолжение истории с Juniper, Zero-Day в Silverlight и как его нашли

Основная претензия исследователей к D-Link заключается в том, что аутентичность кода нигде в устройстве не проверяется. Вполне резонно, но с веб-камерами случаются и более серьезные вещи по части безопасности. Достаточно вспомнить позапрошлогодний взлом веб-камер Foscam, в котором и взлома-то особого не было — просто камеры с настройками по умолчанию и без всякой защиты были доступны из Сети.

Security Week 02: уязвимые вебкамеры, продолжение истории с Juniper, Zero-Day в Silverlight и как его нашли

Кстати о Foscam. На этой неделе в США появилась новость о том, что некто не только взломал видеоняню этого производителя, но еще и пугал трехлетнего ребенка, разговаривая с ним по ночам страшным голосом. Родители ребенка в интервью СМИ сообщили, что теперь безопасность — это их самый главный приоритет. Ну хоть у кого-то это так.

Juniper решила удалить уязвимый протокол DUAL_EC_DRBG. Аудитория в недоумении

Новость.

В заключительном дайджесте прошлого года я предположил, что история с обнаружением бэкдора и уязвимости, позволяющей расшифровывать трафик, в устройствах Juniper обязательно получит продолжение. И угадал. В начале года тема получила развитие, хотя нельзя сказать, что стало понятнее. Напомню: расшифровка трафика стала возможной благодаря: а) использованию в коде алгоритма DUAL_EC_DRBG; б) некорректной реализации вывода этого алгоритма. Предположительно некое «неавторизованное» изменение в коде сделало расшифровку трафика возможной, но возникает справедливый вопрос: а зачем этот алгоритм генерации псевдослучайных чисел вообще вставили в код? Тем более в таком странном виде, когда вывод этого алгоритма дополнительно обрабатывается другим, более безопасным.

На конференции Real World Crypto представительная группа исследователей тоже не смогла ответить на этот вопрос, но поделилась результатами анализа кода разных версий ScreenOS — системы, под управлением которой работают устройства NetScreen. Выяснилось, что алгоритм появился там в 2008 или 2009 году — не очень важно, когда именно, но важно, что точно после того, как в 2007 году стало окончательно ясно: в DUAL_EC что-то не так. До ScreenOS версии 6.2 в системе использовался только алгоритм ANSI X9.31. В этой же версии вместе с данным алгоритмом начал использоваться DUAL_EC, причем вывод последнего был увеличен с 20 байт до 32 — именно этот нюанс сделал атаку возможной.

То есть все еще возможно, что это была серия непреднамеренных ошибок, но слишком уж много совпадений для того, чтобы дальше придерживаться этой версии. Впрочем, с этого места уже начинаются домыслы и ничем не подтвержденные гипотезы, наиболее подробно описанные в этом материале Wired. Собственно, новость этой недели заключается в том, что в Juniper решили полностью отказаться от использования сомнительного алгоритма, таким образом окончательно закрыв уязвимость. Поскольку патч, выпущенный в декабре, проблему решал не до конца.

Microsoft закрывает дыру в Silverlight, а эксперты «Лаборатории Касперского» рассказывают, как нашли уязвимость

Новость. Исследование.

Еженедельный апдейт Microsoft, закрывающий вновь обнаруженные уязвимости в продуктах, на этой неделе включал патч для Microsoft Silverlight — плагина, реализующего примерно те же задачи, что и Adobe Flash. Уязвимости в нем так же опасны, как и многочисленные «дыры» во Flash, с поправкой на популярность плагина. Рассматриваемая уязвимость позволяет выполнять произвольный код на атакуемой машине. В общем-то, вполне рядовая дыра, но есть одно но: в исследовании экспертов «Лаборатории Касперского» подробно рассказывается история обнаружения, с такими деталями, которые по разным причинам обычно остаются «за кадром».

А история интересная. Все началось с печально известного взлома и утечки архивов компании Hacking Team в прошлом году. В самом архиве были обнаружены эксплойты для ранее неизвестных уязвимостей, в частности в Adobe Flash. Но отправной точкой для поиска уязвимости в Silverlight стала переписка между Hacking Team и «охотником за эксплойтами» — она была проанализирована в этом материале издания ArsTechnica. Помимо прочего там мелькали цифры вознаграждения для тех, кто предпочитает работать в «серой» зоне и сотрудничать с компаниями типа Hacking Team (или упомянутой мною в прошлом выпуске Zerodium), — например, $20 тыс. за информацию об уязвимости с работающим proof of concept. То есть какой-то эксплойт был отправлен, деньги за него получены, но это все вводные, которые были в наличии.

Поиск по имени «охотника» дал информацию о другой уязвимости в Silverlight: на сайте PacketStorm тем же Виталием Топоровым размещены описание и, что важно, proof of concept. PoC — это безвредная демонстрация уязвимости; обычно исследователи показывают, что с помощью бреши можно сделать все что угодно, запуская штатный калькулятор Windows. Предположив, что стиль программирования в известном proof of concept и неизвестном эксплойте, написанных одним автором, может совпадать, эксперты создали YARA-правило, выглядящее вот так:

Security Week 02: уязвимые вебкамеры, продолжение истории с Juniper, Zero-Day в Silverlight и как его нашли

Здесь все просто: есть текстовые строки, которые предположительно могут быть в эксплойте, — нужно их найти. Для поиска использовалась как облачная сеть «Лаборатории» Kaspersky Security Network, так и возможности сервиса VirusTotal. В конце ноября наживка сработала: сначала в KSN, а через несколько часов на VirusTotal был загружен вредоносный файл. Дальше осталось проанализировать этот файл, определить параметры уязвимости и сообщить информацию в Microsoft — выяснилось, что это все же новая уязвимость, ранее неизвестная. Интересно, что файл был скомпилирован всего через две недели после утечки архивов HackingTeam, то есть кто-то, вероятно, внимательно проанализировал архивы, не будучи ограниченным законодательством, этикой или чем-то еще.

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

Что еще произошло:
17 уязвимостей закрыто в Adobe Reader и Acrobat.

Арестованы участники группировки, похищавшей деньги из банкоматов при помощи вредоносной атаки Tyupkin.

Security Week 02: уязвимые вебкамеры, продолжение истории с Juniper, Zero-Day в Silverlight и как его нашли

Древности:

«Feist-760»

Резидентный опасный вирус, стандартно поражает COM- и EXE-файлы при их запуске и открытии. Записывает свою TSR-копию по адресу 9800:0000, ничего не меняя в полях MCB, что может вызвать зависание системы. Перехватывает int 21h.

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

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