Security Week 52-53: бекдор у Juniper товстим шаром криптографії, вінтажна Java, гопо-bug bounty

В той момент, коли ялинка вже стоїть, але салати ще не нарізані, саме час в останній раз в цьому році поговорити про новини безпеки. Минулого тижня я відзвітував про «нестандартних» кращих новинах року, і загалом за час, що залишився, нічого особливого не сталося. Хоча ні, є одна новина, яка гідна окремої розповіді. Виявлені 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: Дана колонка відображає лише приватна думка її автора. Воно може збігатися з позицією компанії «Лабораторія Касперського», а може і не збігатися. Тут уже як пощастить.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.