Как работает Android, часть 1
В этой серии статей я расскажу о внутреннем устройстве Android — о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.
Тайна прошивок
Как с помощью самых общих предположений, основанных на знании современных процессорных архитектур, можно восстановить структуру программы из бинарного образа неизвестной архитектуры, и дальше восстановить алгоритмы и многое другое?
В этой статье мы расскажем об одной интересной задаче, которая была поставлена перед нами несколько лет назад. Заказчик попросил разобраться с бинарной прошивкой устройства, которое выполняло управление неким физическим процессом. Ему требовался алгоритм управления в виде компилируемой С-программы, а также формулы с объяснением, как они устроены и почему именно так. По словам Заказчика, это было необходимо для обеспечения совместимости со «старым» оборудованием в новой системе. То, как мы в итоге разбирались с физикой, в рамках данного цикла статей мы опустим, а вот процесс восстановления алгоритма рассмотрим подробно.
Практически повсеместное использование в массовых устройствах программируемых микроконтроллеров (концепции интернета вещей IOT или умного дома SmartHome) требует обратить внимание на бинарный анализ встраиваемого кода, или, другими словами, бинарный анализ прошивок устройств.
Бинарный анализ прошивок устройств может иметь следующие цели:
- Анализ кода на наличие уязвимостей, позволяющих получить несанкционированный доступ к устройству или к данным передаваемым или обрабатываемым этим устройством.
- Анализ кода на наличие недокументированных возможностей, приводящих, например, к утечке информации.
- Анализ кода для восстановления протоколов и интерфейсов взаимодействия с устройствами для обеспечения совместимости данного устройства с другими.
Поставленная выше задача анализа бинарного кода может рассматриваться как частный случай задачи анализа бинарника для обеспечения совместимости устройств.
Вам не нужен блокчейн: 8 популярных юзкейсов и почему они не работают
Порой диву даёшься, чего только люди не сделают «на блокчейне». С середины 2017 я занимаюсь аудитами безопасности смарт-контрактов и повидал всякого. В отдельную категорию я бы выделил «применения блокчейна», которые выглядят логичными и полезными, но в основе содержат проблему. И кочуют из стартапа в стартап вместе с ней. Здесь я рассмотрю ряд таких примеров, опишу проблемы и неработающие способы решения. После прочтения этого текста вы будете знать, с каких вопросов стоит начать, если вам как разработчику/клиенту/инвестору предложат такое «применение блокчейна».
Дисклеймеры
- Я описываю юзкейсы и проблемы, которые возникают на первом шаге. Я не утверждаю, что эти проблемы нельзя решить. Но при рассмотрении подобной системы стоит понимать, как создатели предлагают решать соответствующую проблему.
- Словосочетание «применение блокчейна» режет глаз. Тем не менее, здесь и далее я буду писать его без кавычек, хотя до сих пор до конца не уверен, что возможны другие применения блокчейна помимо денег, то есть кроме Bitcoin.
1. Supply Chain Management
Пусть мы заказали доставку товара и перевозчик обязуется по дороге соблюдать условия хранения, например, поддерживать низкую температуру. Предлагается следующее решение: устанавливаем в грузовик датчик, который регулярно публикует температуру в холодильнике в блокчейн. Таким образом, можно проследить историю температуры и убедиться, что условия хранения были соблюдены на всём пути.
Конференцию PHP Central Europe отменили из-за того, что среди выступающих не оказалось женщин
Как мы искали связь между Mēris и Glupteba, а получили контроль над 45 тысячами устройств MikroTik
что инструментом проведения атаки был ботнет Mēris, состоящий из сетевых устройств компании Mikrotik. При этом они отметили, что изучить образец бота у них не было возможности, но утверждение, что Mēris – это «вернувшийcя Mirai», не совсем точно из-за различия в сетевых уровнях атаки (L7 и L3).
Мы уверены, что данные обстоятельства привлекли внимание многих специалистов
по информационной безопасности в попытках изучения внутреннего устройства ботнета Mēris
и природы его возникновения. Мы в Solar JSOC CERT не стали исключением и пришли к выводу, что, возможно, Mēris начал зарождаться еще в 2018 году с помощью вредоносного семейства Glupteba, которое до сих пор является «поставщиком» устройств для Mēris. Так же нам удалось получить контроль над 45 тысячами устройств MikroTik.
Записки пентестера: случаи на охоте
— Ребята, вы круты! Так нас еще никто не опускал!
— Мы старались.
Да, жизнь охотников за уязвимостями полна специфических комплиментов от заказчиков и не менее специфических ситуаций. За прошедший год мы выполнили более пятидесяти тестов на проникновение в разные компании и, надо сказать, повидали всякое. Один пароль ко всем учеткам и системам, открытое хранение паролей в базе данных, остатки отладочного функционала в боевой среде… Поэтому, когда наши коллеги из JSOC CERT поведали несколько историй по расследованию киберинцидентов, мы в отделе пентеста решили не отставать и показать другую сторону «баррикад»: инфраструктуру заказчика глазами хакера. Сегодня расскажем о наиболее интересных за последнее время внешних пентестах, когда мы должны были проникнуть во внутренний периметр заказчика, имея только список его внешних IP-адресов и доменных имен.
Ваш звонок очень важен: как мошенники пытались навязать мне кредит
Последнее время кажется, что мошенники стали звонить даже чаще, чем друзья и знакомые. К якобы службе безопасности якобы «Сбербанка», которая интересуется, делал ли я перевод Ивану И. из Новосибирска, я как-то даже привык. Но тут позвонили с новым для меня заходом: на этот раз про кредит. Возможно, кто-то из вас даже сталкивался с подобной схемой, но я лично – первый раз. И об этом мой пятничный пост.
ИБ-факапы 2019 – типичные и не очень
«Зато не скучно!» — так звучит неформальный девиз сотрудников нашего центра мониторинга киберугроз Solar JSOC (и надо сказать, 2019 год полностью ему соответствовал). В начале нового года многие любят подводить итоги и ставить новые цели, но мы решили вместо этого рассказать несколько «ужасов нашего городка» – кейсов 2019 года, которые впечатлили даже видавших виды аналитиков. Вывод же из этих историй только один: технологии развиваются и эволюционируют, а человеческая лень, халатность и безалаберность вечны.
В ОС Windows обнаружена критическая RCE-уязвимость уровня EternalBlue
Cогласно информации, предоставленной компанией Microsoft, для успешной эксплуатации необходимо лишь иметь сетевой доступ к хосту или серверу с уязвимой версией операционной системы Windows. Таким образом, в случае если системная служба опубликована на периметре, уязвимость можно проэксплуатировать непосредственно из сети интернет, без дополнительного способа доставки. Рекомендации по мерам защиты под катом.
Что почитать на новогодних праздниках
BlueKeep-2 — теперь уязвимы все новые версии Windows
Подробности и рекомендации по защите под катом.
«Не влезай, убьет!» или вся правда о безопасности АСУ ТП
Мы решили собрать наш опыт защиты АСУ ТП и рассказать о самых частых проблемах и популярных мифах о безопасности в данной области.
Обратная сторона zero knowledge: бэкдор в zk-SNARK, который невозможно обнаружить
Solidity 0.5.0 — что нового он нам несет
Update: 13.11.2018 вышел релиз, вот подробное описание изменений. В статье рассказывается про состояние этой версии в мае (за пять месяцев до релиза).
Хочу рассказать об изменениях языка Solidity, которые ожидаются в версии 0.5.0. Сразу отмечу, что я ограничусь только языком — его грамматикой и семантикой.
Какого-то вменяемого текста на эту тему нет даже на английском языке, но недавно в репозитории Solidity появился проект.
По нему можно отслеживать прогресс подготовки версии 0.5.0.
Disclaimer: в статье описано текущее состояние проекта, к релизу многое может поменяться. Точную информацию можно получить из официального changelog'a.
Как вредоносы обходят песочницы с помощью Visual Basic
Пишем настоящий Pointer Analysis для LLVM. Часть 1: Введение или первое свидание с миром анализа программ
Эта статья станет вступительной в моем небольшом цикле заметок, посвященном такой технике анализа программ, как pointer analysis. Алгоритмы pointer analysis позволяют с заданной точностью определить на какие участки памяти переменная или некоторое выражение может указывать. Без знания информации об указателях анализ программ, активно использующих указатели (то есть программ на любом современном языке программирования — C, C++, C#, Java, Python и других), практически невозможен. Поэтому в любом мало-мальски оптимизируещем компиляторе или серьезном статическом анализаторе кода применяются техники pointer analysis для достижения точных результатов.
В данном цикле статей мы сосредоточимся на написании эффективного межпроцедурного алгоритма pointer analysis, рассмотрим основные современные подходы к задаче, ну и, конечно же, напишем свой очень серьезный алгоритм pointer analysis для замечательного языка внутреннего представления программ LLVM. Всех интересующихся прошу под кат, будем анализировать программы и многое другое!