Распродажа устроена по лучшим стандартам коммерческого делопроизводства: «шлите деньги, а мы подумаем». Но помимо обещаний, в сеть был выброшен набор файлов, явно вырезанный из чьей-то среды разработки: немножко кода, немножко скриптов, документации и так далее. Если не вестись на поводу у СМИ, которые всю неделю обсуждают версии авторства утечки — то, что априори невозможно подтвердить фактами, про ShadowBrokers можно определенно сказать следующее. Во-первых, имплементация алгоритмов шифрования 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 так и сделано, а что касается обычных ПК — официально здесь решение остается за вендором. Случаев агрессивного попирания прав линуксоидов за четыре года зафиксировано не было, но Ричард Столлмэн все равно против.
Подробнее про Secure Boot можно почитать на сайте Microsoft, а лучше — посмотреть сюда в документацию Fedora. Собственно, основной задачей Secure Boot является не притеснение свободолюбивых кодеров, а защита от вредоносного ПО, конкретно — от буткитов. Здесь даже Столлмэн согласен, что таки да, такая защита необходима. Двое хакеров, известные как my123 и slipstream исследовали методы работы Secure Boot и обнаружили странное: при разработке Windows 10 Redstone были добавлены новые правила (policies), с отключенными проверками кода (на наличие сертификата и/или привязку к конкретному устройству). Изменение было внесено в код файла bootmgr.efi. Через эту дыру можно как протащить неавторизованный код, так и отключить Secure Boot полностью. В двух патчах (MS16-094 и MS16-100) проблему пытались решить, отозвав определенные версии данного файла, но как утверждают хакеры, проблема не была решена полностью. Возможно она никогда не будет решена, так как, по словам исследователей, забанить абсолютно все загрузчики Microsoft не сможет, например из-за необходимости сохранить работоспособность определенных образов системы. Подробнее — в отчете здесь (берегите глаза и уши, там музыка и верстка из 1994-го, и буквы прыгают).
Позиция 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-устройств. Причем в данном случае, по иронии, неподверженными оказались старые смартфоны (c Android 4.3 и более ранними версиями). Новые подвержены все, включая бета-версии Android 7.0.
Ждем апдейтов.
GMail начинает идентифицировать недоверенных отправителей
Новость. Анонс в блоге Google.
Добавим минутку позитива. В ближайшее время Google начнет сообщать пользователям о том, что отправителю письма не стоит доверять. Для таких сообщений будет демонстрироваться нестандартная иконка рядом с адресом отправителя, примерно так:
Условие для утраты доверия: несоответствие требованиям стандартов Sender Policy Framework и DKIM. Не думаю, что иконка со знаком вопроса остановит незадачливого пользователя от прочтения и реагирования на хитрое фишинговое письмо, но судя по тактике Google, непроверяемые сообщения в будущем будут отфильтровываться все более активно. Кроме того, в GMail внедрили уже давно используемую в браузерах Chrome функцию безопасного серфинга, которая предупреждает о подозрительных и вредоносных ссылках.
Что еще произошло
Довольно тривиальному методу спуфинга адресной строки оказались подвержены Chrome и Firefox.
Эксперты «Лаборатории» рассказывают о таргетированной кампании Operation Ghoul, с жертвами преимущественно на Ближнем Востоке.
Сразу несколько гостиничных сетей в США рапортуют об утечке данных кредитных карт через взлом POS-терминалов.
Еще один интересный метод кражи данных из air-gapped систем: через анализ жужжания жесткого диска (все плавно переходят на 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (0)