android
На этой неделе по ландшафту угроз бурным потоком разлилась река политики. Тема безопасности и так политизирована донельзя, но если вам вдруг кажется, что уже как-то многовато, то спешу вас расстроить: все только начинается. 13 августа анонимы, скрывающиеся под псевдонимом ShadowBrokers, выставили на продажу арсенал инструментов, предположительно использовавшихся в кибершпионской кампании The Equation.
Напомню, исследование этой атаки опубликовали в феврале прошлого года эксперты «Лаборатории Касперского», назвав ее «Звездой смерти из галактики вредоносного ПО». Было за что: впечатляют длительность кампании (с 2001 года, а может, и раньше), сложность и широкая функциональность инструментов для взлома и кражи данных. Ну и технический уровень заодно, вплоть до помещения вредоносного кода в прошивку жестких дисков.
Распродажа устроена по лучшим стандартам коммерческого делопроизводства: «Шлите деньги, а мы подумаем». Но помимо обещаний в Сеть был выброшен набор файлов, явно вырезанный из чьей-то среды разработки: немножко кода, немножко скриптов, документации и так далее. Если не вестись на поводу у СМИ, которые всю неделю обсуждают версии авторства утечки — то, что априори невозможно подтвердить фактами, — про ShadowBrokers можно определенно сказать следующее.
Много хардкорной мякотки про Equation — ту самую группу, которая заражала жесткие диски на самом низком уровне: http://t.co/SYtfQiDqNZ
— Kaspersky (@Kaspersky_ru) February 24, 2015
Во-первых, имплементация алгоритмов шифрования RC5 и RC6 в утечке совпадает с таковой у The Equation. Это позволяет с определенной долей уверенности говорить, что связь между, строго говоря, кодом, обнаруженным в Сети сейчас и пару лет назад, имеется… Подробнее с примерами тут. Во-вторых, в утечке обнаружены реальные уязвимости в устройствах Cisco (очень подробно написано у них в блоге) и Fortinet.
Все остальное по теме можно свести к одном слову «непонятно». Утечку ShadowBrokers можно поставить в один ряд с прошлогодним взломом компании HackingTeam: и в том, и в другом случае были опубликованы опасные вредоносные инструменты. Даже самые сложные и дорогие разработки такого плана имеют тенденцию к быстрому удешевлению и попаданию не в те руки. Единственный способ предотвратить это — по возможности не создавать кибероружие, вне зависимости от целей. Вредоносного кода и так хватает.
Все выпуски дайджеста — тут.
Хакеры обсудили уязвимость механизма Secure Boot с Microsoft. Хакеры: «Все плохо». Microsoft: «Все нормально»
Secure Boot — это концепция, предусматривающая запуск только авторизованного кода на самом ответственном этапе загрузки системы — после BIOS. В данном случае речь идет о реализации Secure Boot компанией Microsoft — она впервые была выпущена в продакшен вместе с Windows 8 в 2012 году.
Тогда же MS получила очередную порцию проклятий от приверженцев открытого исходного кода: с помощью Secure Boot ведь можно заблокировать запуск сторонних ОС (рассказать бы им тогда про Ubuntu внутри Win10 — не поверили бы). Собственно, на ARM-устройствах Microsoft так и сделано, а что касается обычных ПК — официально здесь решение остается за вендором. Случаев агрессивного попрания прав линуксоидов за четыре года зафиксировано не было, но Ричард Столлмэн все равно против.
Microsoft по ошибке (наверное) слила ключ от Secure Boot, фактически позволив загружать произвольный код: https://t.co/3DVdXrI4QJ
— Kaspersky (@Kaspersky_ru) August 15, 2016
Подробнее про Secure Boot можно почитать на сайте Microsoft, а лучше — посмотреть сюда в документацию Fedora. Собственно, основной задачей Secure Boot является не притеснение свободолюбивых кодеров, а защита от вредоносного ПО, конкретно — от буткитов. Здесь даже Столлмэн согласен, что таки да, такая защита необходима.
Двое хакеров, известных как my123 и slipstream, исследовали методы работы Secure Boot и обнаружили странное: при разработке Windows 10 Redstone были добавлены новые правила (policies), с отключенными проверками кода (на наличие сертификата и/или привязку к конкретному устройству).
Изменение было внесено в код файла bootmgr.efi. Через эту дыру можно как протащить неавторизованный код, так и отключить Secure Boot полностью. В двух патчах (MS16-094 и MS16-100) проблему пытались решить, отозвав определенные версии данного файла, но, как утверждают хакеры, проблема не была решена полностью.
Возможно, она никогда не будет решена, так как, по словам исследователей, забанить абсолютно все загрузчики Microsoft не сможет, например, из-за необходимости сохранить работоспособность определенных образов системы. Подробнее — в отчете здесь (берегите глаза и уши, там музыка и верстка из 1994-го, а еще буквы прыгают).
Что неделя прошедшая нам принесла: как минимум, проект Саурон и уязвимость в iOS: https://t.co/41Gif6hPTO pic.twitter.com/RDKezPCbCu
— Kaspersky (@Kaspersky_ru) August 15, 2016
Позиция Microsoft по поводу исследования сдержанная. Исследователям дали понять, что уязвимостью это не считается. В комментарии для Threatpost в компании отметили, что эксплуатация «проблемы» требует физического доступа к ARM-устройствам и не распространяется на корпоративные системы. В целом они правы: пока исходя из того, что нам известно, это не самая ужасная в мире уязвимость. Поэтому главное в этой истории не фактура, а мораль.
Если разработчики Microsoft действительно совершили ошибку, то проблема не в ошибке, а в самой возможности ее совершения. Системы безопасности в идеале надо разрабатывать так, чтобы в них не было бэкдоров, даже легальных, чтобы в принципе не было возможности что-то потерять, случайно или в результате кражи.
Это еще и запоздавший довод к февральскому диспуту между Apple и ФБР. Тогда позиция федералов заключалась в том, что им даже не нужно знать метод взлома iPhone, Apple достаточно его разработать и применить. По мнению Apple, сам факт разработки отмычки уже представлял большую опасность. Тайное всегда становится явным.
Уязвимость в реализации протокола TCP затрагивает Linux-системы и 80% Android-устройств
Новость. Вторая новость. Научное исследование.
Что может быть хуже уязвимости в ядре операционной системы? Только уязвимость в реализации одного из фундаментальных протоколов. Но нет, не только. Еще хуже, когда уязвимость заложена в спецификациях протокола. Судя по всему, именно это произошло со спецификацией RFC 5961, направленной на повышение безопасности протокола TCP. В ядре Linux эти нововведения были реализованы начиная с версии 3.6, выпущенной в 2012 году.
Исследователи из Калифорнийского университета под руководством Юи Цао нашли способ эксплуатации единственной особенности реализации новой спецификации в Linux — общего лимита на пакеты типа Challenge ACK. Детальная схема атаки находится за пределами моих когнитивных способностей, поэтому за подробностями прошу обращаться к оригинальному исследованию. Здесь же я просто картинку оттуда покажу:
Я все понял.jpg!
Потенциал у уязвимости огромный: появляется возможность определить, что два адресата в сети передают друг другу TCP-пакеты, инициировать разрыв связи между ними и даже перехватить данные (или внедрить собственные в процесс передачи). Все это — с высокой вероятностью успеха и с низкими требованиями по времени на создание условий для эксплуатации (десятки секунд). Для реализации атаки также не нужно занимать позицию man-in-the-middle, достаточно знать адреса отправителя и реципиента и иметь возможность подмены собственного IP.
Помимо десктопов и серверов на Linux (для ядра уже выпущен патч) уязвимости оказались подвержены до 80% Android-устройств. Причем в данном случае по иронии неподверженными оказались старые смартфоны (с Android 4.3 и более ранними версиями). Новые подвержены все, включая бета-версии Android 7.0.
Ждем апдейтов.
Gmail начинает идентифицировать недоверенных отправителей
Новость. Анонс в блоге Google.
Добавим минутку позитива. В ближайшее время Google начнет сообщать пользователям о том, что отправителю письма не стоит доверять. Для таких сообщений будет демонстрироваться нестандартная иконка рядом с адресом отправителя, примерно так:
Условие для утраты доверия: несоответствие требованиям стандартов Sender Policy Framework и DKIM. Не думаю, что иконка со знаком вопроса остановит незадачливого пользователя от прочтения и реагирования на хитрое фишинговое письмо, но, судя по тактике Google, непроверяемые сообщения в будущем будут отфильтровываться все более активно. Кроме того, в Gmail внедрили уже давно используемую в браузерах Chrome функцию безопасного серфинга, которая предупреждает о подозрительных и вредоносных ссылках.
Что еще произошло:
Довольно тривиальному методу спуфинга адресной строки оказались подвержены Chrome и Firefox.
Эксперты «Лаборатории Касперского» рассказывают о таргетированной кампании Operation Ghoul, с жертвами преимущественно на Ближнем Востоке.
Сразу несколько гостиничных сетей в США рапортуют об утечке данных кредитных карт через взлом POS-терминалов.
Исследователи придумали как слить информацию с компьютера, полагаясь на издаваемые жестким диском звуки: https://t.co/Czm3KfQUWd
— Kaspersky (@Kaspersky_ru) August 17, 2016
Еще один интересный метод кражи данных из не подключенных к Сети систем: через анализ жужжания жесткого диска (все плавно переходят на SSD).
Древности:
«Printer-778»
Опасный резидентный вирус, стандартно поражает .COM- и .EXE-файлы, кроме COMMAND.COM. У COM-файлов заменяет начало на команды: MOV BX, Loc_Virus; JMP BX. При работе с принтером (int 17h) переводит выводимую на него информацию в код ASCII-7 (обнуляет старший бит). В результате принтер отказывается «говорить» по-русски и печатать псевдографику. Вирус перехватывает int 17h, 21h.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 80.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Советы