Проблемы начнутся, когда «компьютеров» с аналогичным подходом к разработке и развитию, когда типичный софт и железо устаревают максимум за 2-3 года, будет несколько десятков в каждой отдельно взятой квартире — от счетчика электроэнергии до чайника и электроплиты. Заметный упор в сторону «умных» бытовых приборов на CES (пока в основном довольно странных и безумно дорогих холодильников и стиральных машин) показывает, что это произойдет довольно скоро. В нынешнем виде такие устройства могут работать десятилетиями. А в будущем? Представьте себе экосистему Android, распространенную на утюги и кофемолки. Получатся небезопасные устройства, которые надо обновлять, небезопасные устройства, которые не поддерживаются производителем, небезопасные устройства, о которых даже сам производитель не знает, что они небезопасные.
Какая-то не очень радужная перспектива, но пока я не вижу других вариантов развития. Производителям «умных вещей», увы, придется набить те же шишки на лбу, которые для производителей «больших» операционных систем давно пройденный этап. Все выпуски дайджеста — тут.
Методы прикручивания бэкдора к дешевой веб-камере D-Link
Новость. Исследование.
Уязвимости в сетевых веб-камерах всегда вызывают большой интерес. Понятно почему: в голове сразу появляется картинка, как злоумышленник подглядывает за вами и вашими близкими. Исследование компании Vectra Networks вскрывает хоть и серьезную, но не самую ужасную проблему с такими устройствами. Купив одну из самых дешевых камер D-Link, эксперты разобрали ее прошивку и обнаружили, что вставить в нее бэкдор (в данном случае — кусок кода, который стучится на сервер потенциального вуайериста атакующего) — несложно. Ну как несложно: надо все же получить доступ к устройству, слить прошивку, залить новую. Или не надо получать доступ, если убедить владельца камеры скачать зараженное «обновление». Впрочем, тоже маловероятно.
Основная претензия исследователей к D-Link заключается в том, что аутентичность кода нигде в устройстве не проверяется. Вполне резонно, но с веб-камерами случаются и более серьезные вещи по части безопасности. Достаточно вспомнить позапрошлогодний взлом веб-камер Foscam, в котором и взлома-то особого не было — просто камеры с настройками по умолчанию и без всякой защиты были доступны из сети.
Кстати о Foscam. На этой неделе в США появилась новость о том, что некто не только взломал baby-монитор этого производителя, но еще и пугал трехлетнего ребенка, разговаривая с ним по ночам страшным голосом. Родители ребенка в интервью СМИ сообщили, что теперь безопасность — это их самый главный приоритет. Ну хоть у кого-то так.
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, с поправкой на популярность плагина. Уязвимость позволяет выполнять произвольный код на атакуемой машине. В общем-то вполне рядовая дыра, но есть одно «но»: в исследовании экспертов «Лаборатории Касперского» подробно рассказывается история обнаружения, с такими деталями, которые обычно остаются «за кадром», по разным причинам.
А история интересная. Все началось с печально известного взлома и утечки архивов компании HackingTeam в прошлом году. В самом архиве были обнаружены эксплойты для ранее неизвестных уязвимостей, в частности в Adobe Flash. Но отправной точкой для поиска уязвимости в Silverlight стала переписка HackingTeam с «охотником за эксплойтами» — она была проаналазирована в этом материале издания ArsTechnica. Помимо прочего там мелькали цифры вознаграждения для тех, кто предпочитает работать в «серой» зоне и сотрудничать с компаниями типа HackingTeam (или упомянутой мной в прошлом выпуске Zerodium) — например, 20 тысяч долларов за информацию об уязвимости с работающим proof of concept. То есть какой-то эксплойт был отправлен, деньги за него получены, но это все вводные, которые были в наличии.
Поиск по имени «охотника» дал информацию о другой уязвимости в Silverlight: на сайте PacketStorm тем же Виталием Топоровым размещено описание и, что важно, proof of concept. PoC — это безвредная демонстрация уязвимости, обычно исследователи показывают, что с помощью бреши можно сделать все, что угодно, запуская штатный калькулятор Windows. Предположив, что стиль программирования в известном proof of concept и неизвестном эксплойте, написанными одним автором, может совпадать, эксперты создали YARA-правило, выглядящее вот так:
Здесь все просто — есть текстовые строки, которые предположительно могут быть в эксплойте, нужно их найти. Для поиска использовалась как облачная сеть «Лаборатории» Kaspersky Security Network, так и возможности сервиса VirusTotal. В конце ноября наживка сработала: сначала в KSN, а через несколько часов на VirusTotal был загружен вредоносный файл. Дальше осталось проанализировать этот файл, определить параметры уязвимости и сообщить информацию в Microsoft — выяснилось, что это все же новая уязвимость, ранее неизвестная. Интересно, что файл был скомпилирован всего через 2 недели после утечки архивов HackingTeam — то есть кто-то вероятно внимательно проанализировал архивы, не будучи ограниченным законодательством, этикой или чем-то еще.
Исследование примечательно тем, что в корне отличается от большинства других. Обычно они начинаются с момента получения исполняемого файла и его анализа. А здесь дается пример, что добыть экзешник — тоже обычно довольно сложная задача. Но не безнадежная, даже при наличии самого минимума вводных. Подробнее здесь.
Что еще произошло:
17 уязвимостей закрыто в Adobe Reader и Acrobat.
Арестованы участники группировки, похищавшей деньги из банкоматов при помощи вредоносной атаки Tyupkin.
Древности:
«Feist-760»
Резидентный опасный вирус, стандартно поражает COM- и EXE-файлы при их запуске и открытии. Записывает свою TSR-копию по адресу 9800:0000, ничего не меняя в полях MCB, что может вызвать зависание системы. Перехватывает int 21h.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страница 67.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий