>На графике «какой-то показатель» уязвимостей среднего уровня
>равен 100% для всех языков!!!
Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.
А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.
>а у Other — практически в ноль должен уходить
Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.
Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.
>И никому (ок-ок — мне) в потоке «Разработка» не интересно
Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.
Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».
Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.
>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»
Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:
>или услышать про проблемы написания кода, который этого избежит
… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.
Ссылка в конце поста ведет на полные тексты наших исследований. Там просто больше графиков и подробностей для тех, кому это интересно.
Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.
Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?
Во всех успешных тестах в детализации вызовов отображались только вызываемые номера. В данной атаке конференц-связь устанавливается не в сети оператора, а на внешнем коммутаторе, поэтому факт конференции никак не может отразиться в детализации вызовов.
>> Затем подконтрольный коммутатор направляет вызов на оборудование товарища майора, который организовывает конференц-связь между прослушиваемыми абонентами и товарищем майором?
— Да.
>>В стандартной детализации вызовов этот сеанс связи отобразится с указанием номера товара майора?
— В стандартной детализации отображается набранный номер. Номер злоумышленника в детализации не фигурирует.
>> Если подконтрольный коммутатор находится в другой стране — как отразится на состоянии лицевого счета инициатора звонка?
— Для препейдного абонента вызов проходит в обход реальной биллинговой платформы. Если будет происходить сверка CDR с базой онлайн биллинга, то абоненту позже могут предъявить счёт. Но, как правило, такая сверка происходит при серьёзном расхождении начислений в базах CDR и биллинговой платформы.
>>Какова причина неудач в оставшейся половине аттак?
— Некоторые операторы не позволяют изменять профиль абонента из внешних сетей, поэтому перенаправление вызова в этих случаях было невозможно.
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-контроллер не подаётся питание? Или подлинно известно,
что он перестаёт исполнять код (например, халтится)?
По поводу проверки на необнаружение – постоянно сталкиваемся с анекдотическими случаями, когда дотошные разработчики зловредов обкатывают свои поделия на VirusTotal – до их полного необнаружения… и к полной радости антивирусных вендоров, которым прямо в руки отдают зловреда ещё до распространения :)
> нужны драйвера перехвата всего подозрительного.
>Совершенно непонятно откуда они возьмутся в этом проекте
Эта технология уже работает, и даже не на уровне драйверов, а на уровне «до загрузки операционной системы». На PHDays будет отдельный доклад на эту тему – приходите :)
Да, такой динамический анализ (запуск реального зловреда на виртуальной машине) – это одна из технологий, которую мы используем.
Хотя производительность анализа на виртуальной машине существенно ниже быстрой сигнатурной проверки антивирусом, поскольку анализируется реальное поведение зловреда или последствия клика на ссылку «click me!» или открытие документа «вам оставил по наследству $1млн. нигерийский магнат.pdf».
>равен 100% для всех языков!!!
Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.
А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.
>а у Other — практически в ноль должен уходить
Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.
Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.
Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.
Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».
Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.
>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»
Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:
https://habrahabr.ru/company/pt/blog/244159/
https://habrahabr.ru/company/pt/blog/246449/
>или услышать про проблемы написания кода, который этого избежит
… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.
https://habrahabr.ru/company/pt/blog/271287/
Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.
Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?
— Да.
— В стандартной детализации отображается набранный номер. Номер злоумышленника в детализации не фигурирует.
— Для препейдного абонента вызов проходит в обход реальной биллинговой платформы. Если будет происходить сверка CDR с базой онлайн биллинга, то абоненту позже могут предъявить счёт. Но, как правило, такая сверка происходит при серьёзном расхождении начислений в базах CDR и биллинговой платформы.
— Некоторые операторы не позволяют изменять профиль абонента из внешних сетей, поэтому перенаправление вызова в этих случаях было невозможно.
Главный вопрос при реализации тру рандома — алгоритм восстановления, для подобных систем потеря 90% пакетов не должна приводить к потере управления. Лучше использовать больше каналов, широкий диапазон, непредсказуемую схему переходов, кодирование с исправлением ошибок, передачу с максимально возможной частотой, ну и конечно же — шифрование.
В Syma используется чип BK2423 который содержит второй банк регистров, которые активируются командой 0x53, к оригинальному nRF это не имеет никакого отношения, именно их Вы наблюдали на шине SPI
DeviationTX – проект opensource пульта, который позволяет не ревёрсить протоколы конкретных дронов, мы надеялись на то, что кто-то из участников конкурса его найдет)
В презентации об этом сказано, сам Intel допускает определенную фривольность (видимо исторический фактор).
В «живой природе» выловить такое не удалось, видимо это вопрос времени,
но патент и настройки для этой функции в Flash Image Tool для PCH есть
уже сейчас.
Тут имелось ввиду, что UMA используется как swap бортовой SRAM. Кеш для
ME — это сам 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, то это было сделано всего лишь для наглядности, мы не опираемся на это как на главный довод.
Подается, он висит в бесконечном цикле.
Просто в продолжение статьи мы брали наиболее яркие примеры 2016 года, а не все найденные в этом году уязвимости антивирусов (их конечно больше).
> нужны драйвера перехвата всего подозрительного.
>Совершенно непонятно откуда они возьмутся в этом проекте
Эта технология уже работает, и даже не на уровне драйверов, а на уровне «до загрузки операционной системы». На PHDays будет отдельный доклад на эту тему – приходите :)
Хотя производительность анализа на виртуальной машине существенно ниже быстрой сигнатурной проверки антивирусом, поскольку анализируется реальное поведение зловреда или последствия клика на ссылку «click me!» или открытие документа «вам оставил по наследству $1млн. нигерийский магнат.pdf».