Обновить
64K+
333

Пользователь

134,8
Рейтинг
1 177
Подписчики
Отправить сообщение
Да, она будет опубликована после того, как мы все рисёчи опубликуем. Уже немного осталось :)
NetBIOS Name Service Spoofing и WPAD hijacking — техники, действительно старые, но суть не в этом. С выходом уязввимости стало известно, что отвечать на NBNS-запросы можно из внешней сети, и теперь злоумышленнику не надо ломать периметр, чтобы сделать MiTM
Несколько каналов делают для улучшения помехоустойчивости, их количество не так важно по сравнению с разносом каналов подальше друг от друга так, чтобы при активной работе одного канала WiFi все продолжало работать.

Главный вопрос при реализации тру рандома — алгоритм восстановления, для подобных систем потеря 90% пакетов не должна приводить к потере управления. Лучше использовать больше каналов, широкий диапазон, непредсказуемую схему переходов, кодирование с исправлением ошибок, передачу с максимально возможной частотой, ну и конечно же — шифрование.
Да, данные передаются исключительно в одном направлении, и это нормальная практика для подобных устройств.
Вы неправильно поняли посыл, мы не жалуемся, а констатируем факт, который подтверждает то, что безопасность мира IoT держится на отсутствии внимания к нему.
*от одного байта адреса
DJI Lightbridge имеет три логических канала (управление, видео, телеметрия), и два физических (туда и обратно), в трех словах не рассказать как они передают данные. Кроме этого у них есть и другие уязвимые места.
Да, пульт сначала выполняет процедуру bind на другом канале, где передает адрес по которому будет осуществляться работа в дальнейшем, также в зависимости одного байта адреса выбираются каналы на которых будет осуществляться передача. Но перехватить процедуру bind в эфире значительно сложнее, т.к. обычно она слишком кратковременная.

В Syma используется чип BK2423 который содержит второй банк регистров, которые активируются командой 0x53, к оригинальному nRF это не имеет никакого отношения, именно их Вы наблюдали на шине SPI
DeviationTX – проект opensource пульта, который позволяет не ревёрсить протоколы конкретных дронов, мы надеялись на то, что кто-то из участников конкурса его найдет)
>Intel ME и AMT это не одно и то же. AMT является лишь программной
составляющей, т.е. она аппаратно-поддержана подсистемой Intel ME.

В презентации об этом сказано, сам Intel допускает определенную фривольность (видимо исторический фактор).

>А вы проверяли наличие скрытого сервисного раздела?

В «живой природе» выловить такое не удалось, видимо это вопрос времени,
но патент и настройки для этой функции в Flash Image Tool для PCH есть
уже сейчас.

>То, что, ME UMA кэшируется не означает, что это память подкачки (swap).
ME SRAM тоже кэшируется.

Тут имелось ввиду, что UMA используется как swap бортовой SRAM. Кеш для
ME — это сам SRAM.

>Один из исследователей подсистемы Intel ME (и людей, нашедших
уязвимость в чипсете Q35), Joanna Rutkowska, посмотрев вашу презентацию,
отметила, что, представленные в презентации способы «отключения ME»:

  • либо приводят к DoS всей платформы;
  • либо являются запросом к подсистеме Intel ME на отключение самой себя.

Таким образом, если мы доверяем тому, что Intel ME отключила сама себя,
то почему бы не доверять этой подсистеме в целом и прекратить попытки её
«вырезать»?
От себя добавлю, что судить об отключении Intel ME только по отвалившемуся сетевому интерфейсу (в демке) неправильно. С чего вы
взяли, что эта подсистема действительно не функционирует? Представленный в статье аргумент не понятен. Если, у ME-контроллера нет внешней памяти (UMA), он использует внутреннюю SRAM. Где здесь отключение?

Тут есть несколько тонких моментов:

1. В прошивках, которые были исследованы, SPI активно используется в процессе работы. При обновлении ME вынужден блокировать доступ к Flash, что приводит к отключению критических для ME функций.

2. Сбой Dram Init Done на самом деле не является запросом к ME на отключение, а просто имитирует аппаратный сбой, что заставляет ME
переходить в режим бездействия.

3. Режим Manufacture Mode — специальный режим, который предназначен для отладки оборудования при производстве, опять таки те прошивки, которые попадались действительно выключали ME, не только KVM, но и устройство перестает отвечать на любые запросы и еще много косвенных доказательств.

4. Возвращаясь к UMA и выключению канала. Как сказано в презентации, сам по себе этот способ убивает машину через не более чем 40 секунд,
но его можно использовать как косвенный показатель того, что ME действительно не функционирует (так как при отключении UMA памяти
мы в произвольный момент времени «выдираем» у ME процессора данные и код, объем ядра и базовой обвязки у МЕ больше чем SRAM, функционировать без UMA в «полную силу» ОС МЕ контроллера не может.

5. В какой то степени мы доверяем, что ME выключает сам себя (можно взять модуль, найти обработчик указаной команды и удостовериться в
этом). Но исследователи представили метод для косвенного доказательства отключения МЕ.

Что касается KVM, то это было сделано всего лишь для наглядности, мы не опираемся на это как на главный довод.

>Неужели на ME-контроллер не подаётся питание? Или подлинно известно,
что он перестаёт исполнять код (например, халтится)?

Подается, он висит в бесконечном цикле.
Они выпустили патчи для данных уязвимостей. Но это конечно не значит, что они стали неуязвимыми.

Просто в продолжение статьи мы брали наиболее яркие примеры 2016 года, а не все найденные в этом году уязвимости антивирусов (их конечно больше).
По поводу проверки на необнаружение – постоянно сталкиваемся с анекдотическими случаями, когда дотошные разработчики зловредов обкатывают свои поделия на VirusTotal – до их полного необнаружения… и к полной радости антивирусных вендоров, которым прямо в руки отдают зловреда ещё до распространения :)

> нужны драйвера перехвата всего подозрительного.
>Совершенно непонятно откуда они возьмутся в этом проекте

Эта технология уже работает, и даже не на уровне драйверов, а на уровне «до загрузки операционной системы». На PHDays будет отдельный доклад на эту тему – приходите :)

Да, такой динамический анализ (запуск реального зловреда на виртуальной машине) – это одна из технологий, которую мы используем.

Хотя производительность анализа на виртуальной машине существенно ниже быстрой сигнатурной проверки антивирусом, поскольку анализируется реальное поведение зловреда или последствия клика на ссылку «click me!» или открытие документа «вам оставил по наследству $1млн. нигерийский магнат.pdf».
>идеи заюзать несколько антивирусов сразу и их реализации были еще…
>ну лет 5 назад точно. Так что ничего нового и толку мало. Хотя, желаю удачи.

Колесо тоже изобрели давно, однако же автомобильные компании как-то умудряются делать востребованный продукт.

Проблема в том, что польза от проверки несколькими антивирусами есть (многие компании этот подход используют, а в банковской отрасли вообще есть принятая практика использования в своих системах защиты решения не менее 3-х вендоров), но вендоры между собой договариваться вряд ли будут и вероятность появления такой «многоядерной» системы от какого-то вендора невелика. Так что идея конечно не новая, но ее реализации не торопятся появляться.

>Здесь кратно повышается только вероятность ложноположительного срабатывания.

Да, конечно, проблема ложных срабатываний никуда не девается. Мы и не пытались ее решить — хотя в системе с несколькими ядрами чисто математически вероятность ложных срабатываний уменьшается (вспомним про умножение вероятностей независимых событий из школьного курса).

>Антивирусные вендоры перманентно обмениваются сэмплами.
>Конечно, это не означает, что детект появляется одновременно у всех,
>но всё равно, бОльшая часть начинает детектится относительно быстро (сутки).

Это как раз не так. Средняя по индустрии задержка появления сигнатуры в базе антивируса относительно времени появления угрозы составляет недели две. А некоторые вирусы могут ГОДАМИ жить необнаруживаемыми. Если есть доступ к VirusTotal, там это очень ясно видно бывает. Сами вендоры прекрасно осведомлены об этой проблеме и выстраивают целые облачные технологии для улучшения оперативности реагирования на угрозы.

>Риск, что анализ сэмпла антивирусом приведет к заражению?!
>Такое можно практически исключить, не бывало такого.

Если внимательно почитать статью, там как раз рассматривался такой сценарий с Comodo, когда эмуляция некоторого зловреда была реализована так, что часть инструкций выполнялась прямыми вызовами API-функций операционки (да еще и с привилегиями системы).

>А вот создать хорошую виртуальную среду, эмулировать пользовательскую ОС, вот это задача та еще.
>Поддержка таких песочниц — весьма трудоемкое занятие.

Да, именно такие песочницы у нас есть. Динамический анализ – это одна из технологий, которая используется в PT Multiscanner (не сочтите за рекламу).

>>… желательно, чтобы защитная система давала возможность ретроспективного анализа.
>Это вообще не понял.

Это как раз просто. Если есть задержка между появлением угрозы и ее детектированием антивирусным движком, и движок не хранит файлы, которые через него проходят, то возможен сценарий, когда на периметре установлено антивирусное средство, но в нем ещё нет записи о зловреде, и зловред проникает за периметр.

Чтобы обнаружить заражение нужно, чтобы (а) антивирусное средство обновилось и (б) зловред еще раз попытался проникнуть через периметр — или был отловлен уже на рабочей станции. Если (б) не происходит, то зловред может жить внутри годами, несмотря на то, что его уже все детектят (очень частый сценарий для APT-атак).

Ретроспективный анализ работает так: все проверяемые файлы сохраняются, и при изменении баз антивирусных движков в фоне перепроверяются. Если вердикт меняется – админу приходит оповещение и можно начинать разбираться с последствиями. Да, заражение уже может произойти, но время реакции на него сокращается существенно.

>Вы знали например, что на айфонах могут скапливаться болезнетворные микробы?

Во-первых, не только болезнетворные, но и полезные. Во-вторых, что более интересно — микробное сообщество на ваших пальцах / клавишах идентифицирует вашу личность не хуже, чем отпечаток пальца. А может даже и лучше: отпечатки можно подделать куском мармелада, а вот персональный набор кожных микробов подделать практически невозможно.

Но Онищенко об этом пока не знает. Да и мы не будем пока палить тему. Об этом все начнут писать в 2019-м году, ну тогда и мы напишем. А пока тссссс.
Тому, кто верит бумагам с печатью — наверное, не нужна.

Хотя до сих пор непонятно, почему из этой бумаги следует такое уверенное «участие спецслужб». Отключить абоненту SMS можно по разным причинам. Например, чтобы остановить уже идущую атаку. Представьте, что система безопасности оператора фиксирует массовую утечку, а затем — массовую рассылку SMS с запросами на авторизацию. Вы бы что сделали в этом случае? Подождали бы до завтра, пока у всех ваших абонентов уведут аккаунты?
Корреляция двух событий не означает, что первое событие стало причиной второго. Это даже в средней школе объясняют.
>Почему же это произошло только

А почему вы решили, что «только»? Атаки, о которых сразу же становится известно и жертве, и прессе — это лишь небольшая часть успешных атак. Согласно исследованию FireEye (M-Trends 2015) сейчас среднее время нахождения хакера во взломанной сети до обнаружения составляет более 200 дней. Так что советуем подождать — может быть, всплывёт и более интересная переписка.
Да, Telegram присылает код на девайс с открытой сессией, но при попытке авторизации на другом устройстве можно нажать «не получил код», и тогда он придет в виде SMS. Кроме того, после перерегистрации абонент теряет доступ к GPRS/3G/LTE, и если у него нет подключения к WiFi в текущий момент, то и активной сессии тоже нет. Мы не закрывали сессию специально, доступа к аппарату жертвы не нужно.
Извините, мы не отвечаем за отдел безопасности МТС. Цель статьи — показать возможность атаки без лишней «теории заговора».

Но кстати, если уж вы любите конспирологию, то должны понимать, что при недостатке информации можно всегда сочинить контр-теорию.

Например: отдел безопасности телекома мог отключить SMS именно для того, чтобы *предотвратить* развитие атаки. Мы ведь не знаем, когда и на каком уровне их ломанули, и сколько абонентов были атакованы. Возможно, что они обнаружили подозрительные транзакции и на всякий случай заблокировали ряд сервисов (но было уже поздно).

И это далеко не единственный возможный вариант. Но ещё раз: здесь статья об одном реальном варианте атаки. А не о всех гипотетических вариантах.

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность