1. Методи прикручування бекдора до дешевої веб-камері D-Link
2. Juniper вирішила видалити уразливий протокол DUAL_EC_DRBG. Аудиторія в подиві
3. Microsoft закриває дірку в Silverlight, а експерти «Лабораторії Касперського» розповідають, як знайшли уразливість
4. Старожитності:

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

Якась не дуже райдужна перспектива, але поки я не бачу інших варіантів розвитку. Виробникам «розумних речей», на жаль, доведеться набити такі ж шишки на лобі, які для виробників «великих» операційних систем - давно пройдений етап. Гаразд, їдемо далі. Всі випуски дайджесту - тут .

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

новина . дослідження .

Уразливості в мережевих веб-камерах завжди викликають великий інтерес. Зрозуміло чому: в голові відразу з'являється картинка, як зловмисник підглядає за вами і вашими близькими. Дослідження компанії Vectra Networks розкриває хоч і серйозну, але не найжахливішу проблему з такими пристроями. Купивши одну з найдешевших камер D-Link, експерти розібрали її прошивку і виявили, що вставити в неї бекдор (в даному випадку - шматок коду, який стукає на сервер потенційного вуайериста атакуючого) нескладно. Ну як нескладно: треба все ж отримати доступ до пристрою, злити прошивку, залити нову. Або не треба отримувати доступ, якщо переконати власника камери завантажити заражене «оновлення». Втім, це теж малоймовірно.

Основна претензія дослідників до D-Link полягає в тому, що автентичність коду ніде в пристрої не перевіряється. Цілком резонно, але з веб-камерами трапляються і більш серйозні речі по частині безпеки. досить згадати позаторішній злом веб-камер Foscam, в якому і злому особливого не було - просто камери з настройками за замовчуванням і без будь-якого захисту були доступні з Мережі.

До речі про 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-правило , Що виглядає ось так:

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

Дослідження примітно тим, що в корені відрізняється від більшості інших. Зазвичай вони починаються з моменту отримання виконуваного файлу і його аналізу. А тут дається приклад, що добути exe-файл - теж зазвичай досить складне завдання. Але і не безнадійна, навіть при наявності самого мінімуму вступних. Детальніше тут .

Що ще сталося:
17 вразливостей закрито в Adobe Reader і Acrobat.

заарештовано учасники угруповання, яке викрадає гроші з банкоматів за допомогою шкідливої ​​атаки Tyupkin .

Старожитності:

«Feist-760»

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

Цитата по книзі «Комп'ютерні віруси в MS-DOS» Євгена Касперського. 1992 рік. Сторінка 67.

Disclaimer: Ця колонка відображає лише приватна думка її автора. Воно може збігатися з позицією компанії «Лабораторія Касперського», а може і не збігатися. Тут уже як пощастить.