Security Week 39: злом Yahoo, брутфорс бекапов iOS 10, макромалварь ховається від дослідників

Наша взаимовыгодная связь https://banwar.org/

Що трапилося з Yahoo? Як любить писати британське видання The Register , У Yahoo! на! Минулого! тижні! вкрали! півмільярда! паролів! ( новина ! офіційне! Заява! Yahoo !) В попередньої серії я коротко згадав цю подію, вважаючи його масштабним, але не настільки значущим, щоб додатково розтікатися мислію по древу.

Але ж ні. І справа не в тому, що вкрали дуже багато паролів: імовірно злом інфраструктури Yahoo! трапився! (Ось, знову) в 2014 році, а зараз бази надійшли у вільний продаж в Дарквебе. На тлі інших зломів кількісні характеристики хака вражають, але все ж давно в курсі, що парольний захист - застарілий і неефективний інструмент .

Цікаво те, як Yahoo і інші реагували на даний інцидент. В процесі обговорення злому розкрилося багато цікавих деталей, дослідники звернули увагу на нинішній стан інфраструктури, видимої з боку, і визнали, що там все не так добре, як хотілося б ( новина цього тижня). У витекла базі крім паролів зберігалися номери телефонів та інша особиста інформація, а частина паролів була захешірована визнаним ненадійним алгоритмом MD5.

Але найцікавіше в цій історії - наслідки кіберінцідента для великої і публічної компанії. Виникли справедливі закиди в тому, що в самій Yahoo могли знати про інцидент і приховували цю інформацію (останнє могло статися і по мільйону поважних причин). Позавчора New York Times з посиланням на анонімних інсайдерів повідомила , Що в компанії банально економили на засобах безпеки, включаючи системи виявлення злому.
Список попередніх серій тут .

Дійшло до того, що витік паролів обговорюють в американському конгресі, адже в самій Yahoo припускають, що атака була спонсорувала державою. Ряд експертів, втім, це припущення переконливо оскаржують - характер атаки нагадує аналогічні зломи LinkedIn і MySpace, в обговоренні яких політики було набагато менше.

Як би там не було, історія Yahoo стає показовою з точки зору методів реагування на кіберінціденти. Зломи рано чи пізно трапляються, і очевидно, що потрібні стратегія і інструменти їх виявлення і нейтралізації. Чим швидше, тим краще - менше буде витрат.

Але справа не тільки в цьому. Якийсь соціальний протокол розкриття інформації про зломи також не опрацьований, але ж було б непогано. Судячи з напрацьованого досвіду, максимальна відкритість по частині деталей злому (хороший приклад можна подивитися тут ) І кроків по вирішенню проблеми сприймається найбільш позитивно всіма причетними, включаючи можливих постраждалих.

І ще. Якщо описана в New York Times ситуація дійсно мала місце, виходить, що менеджмент Yahoo не тільки економив на інвестиціях в безпеку. Приймалися рішення, в яких пріоритет віддавався не захистові, а зручності користувачів, питань збереження клієнтської бази та подібного. Бюджет - це справа тонка, грошей ніколи багато не буває, але стратегія «від нас все підуть, якщо ми будемо скидати паролі при кожному підозрі на злом», вже точно приречена на неминучий провал. До речі, піду-но я пароль поміняю.

Apple знизила стійкість резервних копій до Брутфорс в iOS 10. Ніхто не знає навіщо

новина . Стаття в блозі Elcomsoft.

З незрозумілих причин компанія Apple знизила захищеність бекапов для недавно випущеної версії iOS 10. Йдеться про резервної копії всіх даних з iPhone або iPad, яка зберігається на комп'ютері користувача через iTunes. Вже досить давно бекапи шифруються, і в даному випадку якість шифрування не викликає сумнівів. Сумніви викликає стійкість резервних копій до перебору паролів.

Диспут між Apple і ФБР на початку цього року дав зрозуміти, що зламати сам iPhone, якщо він захищений допомогою звичайних методів тестування, досить складно. Бекап є очевидне уразлива ланка: він зберігається на комп'ютері, який в більшості випадків легше зламати, ніж сам телефон (навіть якщо це Mac), і, на відміну від телефону, що не самознищується при спробі його розібрати протиправними методами. А дані там збережені абсолютно всі, включаючи паролі з системи зберігання KeyChain.

Так ось, за словами фахівця компанії Elcomsoft Олега Афоніна, проблема полягає в прив'язці бекапов iOS 10 до алгоритму хешування паролів SHA-256 з єдиною итерацией. В iOS 9 використовувався більш стійкий до перебору алгоритм PBKDF2 SHA-1 з 10 000 ітерацій.

Elcomsoft спеціалізується на розробці ПЗ для обходу захисту різних пристроїв і софта, і, за їхніми даними, зміна алгоритму дозволяє радикально збільшити швидкість перебору паролів - з 150 тисяч до 6 млн в секунду. В результаті бекап теоретично можливо зламати за дві доби з 80-90-відсотковою ймовірністю, і це якщо пароль встановлено більш-менш складний. Якщо зовсім простий - і того швидше. Ніякого іншого пояснення такому «апгрейду», крім помилки, експерти не придумали. Що, загалом, і визнала сама Apple, пообіцявши в майбутньому повернути стійкість на місце.

КапітанІсследователь повідомляє про макротрояне, який намагається сховатися від аналізу

новина .

Найпопулярніша новина на Threatpost за тиждень розповідає про шкідливу програму, що розповсюджується через заражені документи Word, яка досить базовими методами намагається приховати своє реальне призначення. Дослідник з компанії SentinelOne (стаття у них в блозі ) Описує досить стандартну ситуацію: користувачеві приходить лист з вкладенням, відкривається офісний документ, з'являється пропозиція включити макроси, користувач (звичайно ж) говорить «Так» або, в залежності від локалі, «I do». Далі починається трохи більше цікаве.

По-перше, запустився шкідливий код намагається через зовнішній сервіс пробити IP машини, на якій запущений, а також назва організації, з якою асоційований IP. Якщо назва збігається з даними з зашитого всередину списку (в якому в основному імена виробників захисного ПЗ, причому «Лабораторії» там немає), то далі нічого не відбувається.

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

Це цікаві деталі сучасної малварі з булки і сірників, але, відверто кажучи, спроба якимось чином піти від виявлення - це абсолютно поширена і багаторічна практика письменників шкідливого коду. Єдиним значущим моментом є використання макросів в Word в комбінації з такими фокусами. Макромалварь була відносно недавно піднята з небуття письменниками кріптолокеров. В даному випадку викуп ніхто не вимагає, але це хоч якесь ускладнення досить простий загрози, яка блокується будь-яким пристойним рішенням на раз - так хоча б на етапі спроби завантажити кейлоггер.

Насправді такі прийоми навряд чи збентежать досвідченого або просто наполегливого дослідника. Більш цікаві приклади приховування істинного призначення коду можна подивитися в історії про Lurk . Рано чи пізно таємне стає явним.

Набагато важливіше виявляти і блокувати мімікрують малваре автоматизованими засобами. Тут використовується маса вельми оригінальних рішень, які, на жаль, зазвичай залишаються непублічними (ось, наприклад, одне виняток ) - як через глибоко технічної специфіки, так і з-за небажання ділитися з кіберзлочинцями методами детектування шкідливий з підвищеною хитрістю.

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

«Typo-867»

Нерезидентний небезпечний вірус. Стандартно вражає .COM-файли. Після закінчення роботи зараженого файлу залишає в пам'яті невелику резидентную програму, яка підміняє деякі знаки, що вводяться з клавіатури. На час роботи зараженого файла встановлює на себе переривання 16h, 20h, 21h.

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

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