Хочется сказать, что на этой неделе активизировался спор за возможность влиять на развитие технологий: между, так сказать, технарями и гуманитариямиполитиками. Первые руководствуются возможностью реализовать ту или иную функциональность в софте и железе, вторые — необходимостью договариваться с различными заинтересованными сторонами. На самом деле спорят не об этом. Технологии всегда развиваются независимо от того, согласны ли с этим окружающие или нет. Выводя свой спор с ФБР в общественное пространство, 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, обсуждать тут нечего, прежде всего надо накатывать патчи. Много патчей в самых неожиданных местах в софте и железе.
Голливудская больница заплатила выкуп после атаки криптолокера
Новость.
Ну и на закуску, история из мира обычного вредоносного ПО. Индустрия троянцев-шифровальщиков, увы, приносит миллионные убытки, но типичной жертвой такого кибер-развода становятся простые пользователи. Все значительно сложнее, когда атакуются компании. В данном случае жертвой стал госпиталь в Голливуде (том самом). Cудя по всему, злоумышленники смогли зашифровать все или почти все данные, после чего потребовали от руководства больницы рекордный выкуп — три миллиона долларов (точнее 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий