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

Що сталося з 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, якщо він захищений стандартними засобами системи, досить складно. Бекап являє собою очевидне уразливу ланку: він зберігається на комп'ютері, який у більшості випадків легше зламати, ніж сам телефон (навіть якщо це Мак), і, на відміну від телефону, не самознищується під час спроби його розібрати протиправними методами. А дані збережені абсолютно все, включаючи паролі з системи зберігання KeyChain.


Так от, за словами фахівця компанії Элкомсофт Олега Афоніна, проблема полягає в прив'язці бекапів iOS 10 до алгоритму хешування паролів SHA-256 з єдиною ітерацією. У iOS 9 використовувався більш стійкий до перебору алгоритм PBKDF2 SHA-1 з 10,000 ітераціями. Элкомсофт спеціалізується на розробці ПЗ для обходу захисту різних пристроїв, софту, і, за їхніми даними, зміна алгоритму дозволяє радикально збільшити швидкість перебору паролів: з 150 тисяч до 6 мільйонів у секунду. В результаті бекап теоретично можливо зламати за дві доби з 80-90% ймовірністю, і це якщо пароль встановлено мало-мальськи складний. Якщо зовсім простий — і того швидше. Ніякого іншого пояснення такому «апгрейду» крім помилки експерти не придумали. Що, загалом, і визнала сама Apple, пообіцявши в майбутньому повернути стійкість на місце.

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

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


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

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

Давнину
«Typo-867»

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

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

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

0 коментарів

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