Security Week 07: Apple проти ФБР, глобальна уразливість в glibc, криптолокеры та медицина

Тиждень з гаком робочим днем видалася насиченою і збалансованою. Події навколо суперечки між Apple і американськими держорганами в особі ФБР і Мін'юсту продовжують розвиватися, але вже зараз ясно, що вони серйозно вплинуть на розвиток індустрії безпеки в частині захисту особистої інформації. На відміну від цієї суто політичної історії, критична уразливість в бібліотеці glibc являє собою новину абсолютно технічну, але, прямо або побічно, теж зачіпає всіх.

Хочеться сказати, що на цьому тижні активізувався спір за можливість впливати на розвиток технологій: між, так би мовити, технарями і гуманітаріямиполітиками. Перші керуються можливістю реалізувати ту чи іншу функціональність в софті і залозі, другі — необхідністю домовлятися з різними зацікавленими сторонами. Насправді сперечаються не про це. Технології завжди розвиваються незалежно від того, згодні з цим навколишні чи ні. Виводячи свій спір з ФБР в громадський простір, Apple бореться за те, щоб залишатися в авангарді цього самого технічного розвитку. Іншими словами, якщо Apple програє, і реальна (а то і уявна!) захищеність пристроїв компанії якимось чином постраждає, це не означає, що за всіма нами обов'язково буде стежити великий брат. Це означає, що умовний вимпел з написом «найбезпечніший смартфон» перехопить якась інша компанія.

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

Apple проти ФБР: справа про заблокованому айфоне, тероризмі і законі 1789 року.
Новость.

Другого грудня 2015 року в Сан Бернардіно, штат Каліфорнія стався теракт. Американський громадянин пакистанського походження разом із спільницею розстріляв своїх колег з окружного департаменту здоров'я. Нападникам вдалося втекти, але їх заблокували в трьох кілометрах від місця злочину. В послідувала перестрілці злочинці були застрелені. В ході розслідування було виявлено телефон злочинця: Apple iPhone 5c, корпоративний смартфон, який офіційно належить роботодавцю. Ймовірно, Apple за запитом держорганів надала резервну копію даних з телефону з хмарного сервісу з iCloud. Але в хмарі була застаріла копія даних, датована 19 жовтня, після чого, знову ж таки, імовірно, власник телефону відключив функцію резервного копіювання.

Намір ФБР отримати абсолютно всі дані зі смартфона виразилося в судовому приписі до компанії Apple (ісходник выложила EFF), в якому досить чітко прописано, що компанія повинна зробити, щоб допомогти слідству. А саме: (1) відключити функцію, яка знищує дані на телефоні після десяти неправильних спроб введення пасскода (2) забезпечити можливість введення пасскода електронним способом (3) відключити затримку між спробами введення.



Іншими словами, ФБР хоче підібрати пасскод перебором, і вимагає від Apple обійти всі вбудовані обмеження, які роблять підбір неможливим. У матеріалі The Intercept зазначають, що успіх такого сценарію залежить від довжини пароля: на чотиризначний пінкод підуть секунди, на семизначний — до дев'яти днів, на десятизначний — 25 років. Але це якщо Apple підкориться, але поки компанія цього робити не хоче. звернення клієнтам компанії CEO Apple Тім Кук заявив, що компанія передала держорганам всі дані, які у неї були, і які могли допомогти слідству. А «план по перебору» справедливо назвав бекдорів: «Уряд США попросило нас дати те, чого у нас просто немає і зробити те, що ми вважаємо дуже небезпечним».



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

Чим обґрунтована вимога до Apple з точки зору законодавства США?
Дуже цікаве питання, дякую. Вимога грунтується на акті 1789 року, відомому як All Writs Act. Він входить до складу закону, який власне і створив всю судову систему США, після підписання Джорджем Вашингтоном, першим президентом країни. Загалом, це сталося ще в ті часи, коли Каліфорнія, де через двісті з гаком років буде знаходитися штаб-квартира Apple і відбудеться згаданий теракт, разом з Мексикою була колонією Іспанії, і в склад США не входила. Якщо все гранично спростити, акт залишало лазівку для недосконалої законодавчої системи молодої американської держави: давав судам свободу приймати необхідні рішення, не посилаючись на вже прийняті закони.

У детальному огляді законодавчої частині цієї історії, Gizmodo приводит судову практику із застосуванням даного акта. Зараз, коли з законодавством начебто проблем немає, All Writs Act задіюється не часто, але регулярно. Наприклад, у 1977 році, телекомунікаційну компанію зобов'язали допомогти відстежити переговори кримінальної банди, що займалася рекетом. Тобто виходить, що давній закон застосовується тому, що правила злому смартфонів ніде не прописані. Якщо Конгрес США не перейнявся підбиттям такої практики в порядок, то суду доводиться використовувати такі от шорткаты. У матеріалі Gizmodo наводиться і рідкісний випадок, коли суддя відмовився застосовувати даний акт, поставивши справедливе питання (правда по іншій справі та іншого приводу): законодавчої бази немає, тому що Конгрес не встиг її створити, або тому, що не захотів?

Чому ФБР просить Apple зламати iPhone, а не робить це самостійно?
Очевидно, тому, що самостійно федерали цього зробити не можуть. Вся ситуація говорить про те, що методи захисту інформації, вбудовані Apple працюють. Є ще один нюанс, який сплив буквально вчора. Apple организовала конференц-дзвінок з журналістами, на якихось небачених раніше умовах. Представники компанії поділилися своїм баченням проблеми, при цьому журналістам було заборонено їх цитувати дослівно! Більш того, навіть імена представників компанії не були розкриті. На думку анонімних співробітників Apple, ФБР вистрілила собі в ногу, випадково скинувши пароль до облікового запису iCloud, до якої був прив'язаний смартфон. Якби цього не сталося, телефон, будучи включеним, але все ще заблокованим, сам би синхронізувався з iCloud, звідки дані, імовірно, можна було добути з допомогою компанії. Після скидання така можливість була упущена: пароль на телефоні неправильний, а який правильний, ніхто не знає і впізнати не може.

Які взагалі позиції сторін?
Apple озвучила свою позицію 16 лютого: запропоноване рішення еквівалентно створення бекдор, це ставить у небезпеку всіх наших клієнтів, ми це робити не хочемо. Причому заяву було зроблено в публічному полі. Представники держави відповіли 19 лютого, і не публічно, а у вигляді заяви в суд по даній справі. На думку представників Департаменту Юстиції, Apple має технічну можливість реалізації системи перебору паролів, але не бажає підкорятися, віддаючи перевагу не Законом, а «маркетингової стратегії». «Не бажає підкорятися» в даному випадку може мати прямі юридичні наслідки в суді, і звучить як погроза.



А Apple взагалі може обійти систему захисту?
Невідомо. Заяву Тіма Кука чіткої відповіді на це питання не містить: «це небезпечно», «вони просять щось, чого у нас ні» і так далі. Зрозуміло, що Apple, як розробник і софта, і заліза для айфонів, може багато чого. Головне питання: чи буде компанія підкорятися?

На думку опонентів Apple, особливої небезпеки немає. В судовому заяві прямо прописано, що компанія може прив'язати цей брудний хак до єдиного телефону, більше того — вона не зобов'язана передавати виготовлений для перебору паролів софт державі. З іншого боку, навіть знання про те, що Apple змогла реалізувати подібний сценарій, теоретично може дати можливість державі або зловмисникам створити власний бекдор. Природно, сприйняття захищеності смартфонів Apple постраждає, якщо компанія підкориться. Всі будуть знати, що, в разі чого, держава до ваших даних добереться.

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

Програш Apple не буде означати, що сильна криптографія виявиться недоступною або під забороною. Просто вона стане менш поширена, а в подальшому розвитку технологій захисту даних такі компанії, як Apple, Google, Facebook, Twitter (останні три поддержали Apple в спорі) будуть грати меншу роль. А їм, зрозуміло, хотілося б цього уникнути.

Вишенька на тортику: Джон Макафі вызвался зламати айфон безкоштовно, за три тижні, використовуючи «переважно методи соціальної інженерії». Інтернет задається питанням, як саме Макафі збирається застосовувати методи соціальної інженерії до власника телефону, застреленному три місяці тому.

Виявлена критична уразливість в glibc
Новость.

В бібліотеці GNU C Library (glibc) виявилася критична уразливість, яка зачіпає всі версії, починаючи з 2.9, яка була випущена в 2008 році. Винною виявилася функція getaddrinfo(), що відповідає за запит до DNS-серверу. Проблема полягає в тому, що до відповіді від сервера можна дописати довільний код, і, викликавши, переповнення буфера, виконати його на системі жертви. Уразливість обнаружили дослідники в Google, причому випадково — їх увагу привернули постійні падіння SSH-клієнта з segmentation fault при зверненні до певного серверу. Тобто, щоб провести атаку з використанням цієї уразливості, потрібно певним чином налаштувати DNS-сервер і якимось чином змусити жертву зробити запит. Це не так вже складно, і може бути реалізовано, наприклад, у процесі атаки man-in-the-middle, коли замість легітимного DNS-сервера на шляху запиту виявляється підставний.

Щодо того, наскільки просто запустити довільний код, думки різняться. Перешкодити цьому можуть технології захисту, такі як ASLR, але зовсім не обов'язково, що на всіх пристроях вони працюють — наприклад в роутерах з традиційно мінімалістичним linux-оточенням всіх необхідних захистів може і не бути. В детальному описі уразливості, зроблене співробітниками Red Hat, зазначено, що реалістичні сценарії запуску довільного коду існують.



Серйозність уразливості полягає в тому, що glibc використовується повсюдно. В якості ілюстрації не можу не привести цей твіт:



Бібліотека стандартних функцій є залежністю для величезної кількості програм і пакетів для Linux. Відповідно, важко правильно оцінити, які програми і яким чином схильні даної уразливості. Наприклад, Android (система сама по собі) — не схильна, так як в ній замість glibc там використовується альтернатива Bionic, розроблена Google. Це не означає, що не піддаються всі рідні додатки для Android. Попередня серйозна уразливість в glibc, відома як GHOST, викликала такі ж питання, хоча там можливостей для реальної віддаленої експлуатації було менше. Результат: маса проблем для розробників і адміністраторів величезної кількості софту і заліза. Примітно, що дослідники в Google і Red Hat виявили баг незалежно один від одного. Більше того, з'ясувалося, що мейнтейнери glibc дізналися про проблему ще в липні 2015 року. Поки не ясно, чому проблему не закривали так довго, і як взагалі вийшло, що уразливість з'явилася. Але на відміну від історії Apple, обговорювати тут нічого, насамперед треба накочувати патчі. Багато патчів в найнесподіваніших місцях в софті і залозі.

Голлівудська лікарня заплатила викуп після атаки криптолокера
Новина.

Ну і на закуску, історія зі світу звичайного шкідливого ПО. Індустрія троянців-шифрувальників, на жаль, приносить мільйонні збитки, але типовою жертвою такого кібер-розлучення стають прості користувачі. Все значно складніше, коли атакують компанії. В даному випадку жертвою став госпіталь в Голлівуді (тому самому). Судячи з усього, зловмисники змогли зашифрувати всі або майже всі дані, після чого зажадали від керівництва лікарні рекордний викуп — три мільйони доларів (точніше 3,4 млн або 9000 биткоинов). Чи не вимагали — повідомлення з місць суперечливі, а офіційне заявление організації спростовує факт запиту такої величезної суми.



Тим не менш, викуп шахраї отримали, хоча і менший — 17 тисяч доларів. У лікарні заявили, що це був єдиний спосіб оперативно відновити працездатність IT-систем лікарні. Сумно, але зрозуміло, що насамперед атаку шифрувальників потрібно не допускати. А якщо вона відбувається — зробити так, що збиток буде обмежений даними на одній системі (а не на всіх мережевих папках відразу). Новина привернула велику увагу із-за специфіки організації, яка потрапила під удар — ніхто не бажає витоку найбільш чутливих даних про своє здоров'я. Лікарняні комп'ютерні мережі, між тим, залишаються вразливими не тільки і не стільки перед звичайними троянцями. На конференції Security Analyst Summit про це рассказывал наш експерт Сергій Ложкін: досить простими інструментами він зміг виявити доступне з інтернету вразливе спеціалізоване ПО, таке, наприклад, як софт для МРТ.

Давнину:
«Typo-Boot»

Небезпечний вірус, методом «Brain» вражає Boot-сектора вінчестера і флоппі-дисків при читанні з них. На диску розташовується стандартним способом. Працює тільки на комп'ютерах IBM PC/XT, так як містить команду 'MOV CS,AX' (міжсегментний JMP), яка виконується тільки процесором 8086. Перехоплює int 13h, 17h. Підміняє знаки, які виводяться на принтер.

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

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

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

0 коментарів

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