Makrushin
3.69K subscribers
242 photos
33 videos
363 links
Денис Макрушин. Здесь, чтобы спасти мир.

Про кибербезопасность, технологии и людей.

По вопросам сотрудничества: @makrushin_bot

Канал в Max: https://max.ru/join/ujHOeKoo_3u03g8bHBzJdGx39G2ETpQkTZk98MOg8fA

makrushin.com
Download Telegram
Доклад, представленный на международной конференции Security Analyst Summit, открывает серию исследований, посвященных «умной медицине». 6 минут этого выступления в 2017 году, по мнению некоторых комментаторов и присутствовавших, стали сейчас еще более актульными: маска на лице в начале доклада использовалась еще до того, как это стало необходимостью 😷
“S” в аббревиатуре “IoT” означает “Security”.

👆Тот момент, когда никто не понял шутку.

Всем бодрого понедельника!
🔥5
Угрозы для систем трекинга показателей здоровья

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

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

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

«Мое сердце остановилось…»

26 июля 2013 года не стало известного специалиста по информационной безопасности Джека Барнаби, который выявил уязвимости в определенной модели кардиостимуляторов. Обладая необходимыми спецификациями, злоумышленник имел возможность воспользоваться специальным «бэкдором», который был оставлен производителем устройств для удаленной связи с девайсами, и вызвать смертельный электрический разряд напряжением 830 В на расстоянии около девяти метров от потенциальной жертвы. У злодея также была возможность перепрограммировать устройство, что, в свою очередь, означает возможность установки специальной малвари, которая, например, могла быть подобием программного таймера. Три, два, один, разряд...

Другой эксперт по информационной безопасности — Билли Райос (Billy Rios) провел анализ защищенности программного обеспечения инфузионной помпы PCA 3 Lifecare производства Hospira и обнаружил уязвимости, часть из которых позволяли злоумышленнику увеличить скорость введения лекарств (а через такие насосы обычно вводятся сильнодействующие средства. — Прим. ред.) и тем самым спровоцировать передозировку у потенциальной жертвы.

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

Модель угроз для персональных устройств сбора показателей здоровья и ответы на вопросы редакции "Хакер" собраны в авторской колонке.
1.337 секунды до того, как накрыла волна…

Волна исследований, вышедших на выходных и требующих нашего внимания.

* Symbiote – новый образец вредоносного ПО, использующий eBPF и LD_PRELOAD для сокрытия

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

* Угнать за 130 секунд

Баг позволяет добавить новый NFC-ключ для автомобиля Tesla

* SFUZZ: High Performance Coverage-guided Greybox Fuzzer with Custom JIT Engine

Новый greybox coverage-based fuzzer, основанный на эмуляции, который использует кастомный JIT-компилятор для достижения высокой производительности.
👍2🤔1
Про наступательную безопасность

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

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

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

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

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

Почему бизнесу неинтересны решения подобного класса? Потому что «false positive» может отправить клиента в ханипот, а бизнес уложить на лопатки. Так что незачем испытывать судьбу. И тем не менее в ходе расследования ИБ-инцидента этот бизнес вынужден инвестировать средства в оперативно-разыскные мероприятия, чтобы найти «ответчика».

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

* Легально ли с юридической точки зрения атаковать хакера в ответ?
* Как мне убедиться в том, что ханипот не атакует клиента?

Юридические аспекты этой идеи, а также архитектура “offensive honeypot” рассмотрены в авторской колонке для издания «Хакер».
1
Переоптимизация глубокой нейронной сети с внедрением "downhill" навыков. На этот раз без метода "Dropout" (специалисты по анализу данных поймут метафору).

Я считаю, что лучший путь обучения наша нейронная сеть проходит через неудачи и стресс. Превратите свои проваленные экзамены и бизнес-питчи, продуктовые pivot'ы и нерабочий код, неудачные трюки и падения с байков в прочную нейронную связь. И наслаждайтесь процессом.
Оценка защищенности к DDoS-атакам

Сре­ди огромно­го количес­тва сце­нари­ев DDoS-атак уже типичным в стал метод уси­ления ата­ки пос­редс­твом некор­рек­тно нас­тро­енных ресур­сов Сети. Нап­ример, зло­умыш­ленник может отпра­вить 100 байт (условно) спе­циаль­ным обра­зом сфор­мирован­ного зап­роса к DNS-резол­веру, и тот, в свою оче­редь, отпра­вит 1 Кб отве­та на ресурс жер­твы. Мож­но толь­ко пред­ста­вить, что будет, если зло­умыш­ленник отпра­вит подоб­ные зап­росы от сво­его неболь­шого бот­нета к огромно­му спис­ку DNS-резол­веров. Кста­ти, дан­ный бот­нет не обя­затель­но может сос­тоять из заражен­ных стан­ций — в него так­же могут вхо­дить инстан­сы какого‑нибудь пуб­лично­го обла­ка. Добавим сюда пуб­личные веб‑сер­висы наг­рузоч­ного тес­тирова­ния, с помощью которых мож­но реали­зовать ата­ку типа SaaS Amplification, и получим доволь­но уве­сис­тую «кувал­ду» для веб‑при­ложе­ния.

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

Ус­ловно про­цеду­ры опре­деле­ния реак­ции информа­цион­ной сис­темы на ту или иную наг­рузку мож­но раз­делить на три вари­анта:

* наг­рузоч­ное тес­тирова­ние (load-testing) — опре­деле­ние реак­ции сис­темы и ее работос­пособ­ности при некото­рой заранее задан­ной (пла­ниру­емой, рабочей) наг­рузке;
* тес­тирова­ние отка­зоус­той­чивос­ти (stress-testing) — ана­лиз поведе­ния информа­цион­ной сис­темы при ано­маль­ной наг­рузке (нап­ример, при DDoS-ата­ках);
* тес­тирова­ние про­изво­дитель­нос­ти (performance testing) — ком­плексный под­ход, сочета­ющий в себе два пре­дыду­щих метода тес­тирова­ния.

В авторской колонке описана сис­тема стрес­сового тес­тирова­ния, которая успешно показала себя в практических задачах, которые выполнялись в ходе услуг нагрузочного тестирования веб-приложений.
👍1
👆2013 год. Я витаю где-то в облаках. И рассказываю на ZeroNights о том, как использовать облачные ресурсы для усиления DDoS-атак.

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

Время: 18-00, четверг, 28 июля
Место: онлайн
Повод: встречаемся с друзьями из компании Awillix, чтобы обсудить тему безопасной разработки и, в частности, ранние стадии SDLC. Тема открывает цикл эфиров про безопасность ИТ-продуктов и приложений, поэтому если ты не понаслышке знаком с разработкой - добавляй событие в календарь и присоединяйся к дискуссии.
1
Исследование безопасности умных городов, упакованное в формат доклада и представленное на китайской конференции GeekPWN, которая прошла в Шанхае и включила нас в свой "Hall of Fame" за "sums up the pain points of Smart City".
2
«Сэр, пройдемте со мной», - говорит один из офицеров и указывает пальцем на коридор с множеством маленьких комнат для допроса. «Цель визита? – Выступление на конференции Hacker Halted 2015. Конечный пункт назначения? – Атланта, Штат Джорджия…» Через полчаса содержательной беседы нам возвращают багаж, и мы выходим из аэропорта, где нас встречает раскаленный воздух и джетлаг. Добро пожаловать в США.

Отчет о моей первой поездке в Атланту на конференцию Hacker Halted. Там же состоялась презентация нашего исследования о деанонимизации пользователей Tor.
👍3
Как в компьютерной игре: навык “Enduro” разблокирован.

А вот, чтобы ты мог погрузиться в тему безопасности приложений и разблокировать навыки поиска уязвимостей, следующую неделю объявляю “неделей App Sec”.

Каждый день буду разбирать материалы, которые прокачивают скилл, необходимый Security Champion’у в процессе безопасной разработки.
👍7🐳1
Знай актуальную поверхность атаки.

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

Материал, в котором собраны методы проведения разведки на основе открытых источников (Open Source Intelligence, OSINT), основательно описывает процесс и инструменты сбора информации о корпоративном периметре и доступных ресурсах. Техники предназначены в первую очередь для участников bug bounty, но могут быть применены в процессах внешнего анализа защищенности.
👍1💩1
К наиболее распространенным ошибкам, которые разработчики совершают в незрелом процессе SDLC, относятся ошибки управление секретами. В кодовую базу попадают пароли, хардкодятся API-ключи к CI/CD и 3rd-party системам, заносятся учетные данные пользователей.

Чаще всего секреты встречаются в следующих репозиториях:
* код авто-тестов, которые QA-инженеры бэкапят в свои персональные публичные репозитории;
* репозитории организаций-подрядчиков, отвечающих за интеграцию клиентов с продуктом;
* персональные репозитории разработчиков, которые бэкапят свои внутренние тулзы;
* скрипты установки продукта и skeleton-файлы микросервисов, используемые подрядчиками, отвечающими за установку и поддержку продукта (operations).

Если есть забытые секреты, то есть и возожность их найти. Вот подборка утилит для автоматизации поиска ценных данных в коде:
* gitGrabber – позволяет в реальном-времени мониторить Github и прочие сервисы на предмет появления секретов. Подходит для задачи мониторинга появления секретов по заданные поисковые запросы.
* gitLeaks – тулза для мониторинга конкретно заданных репозиториев на утечку секретов. Отлично подходит для выполнения задач мониторинга официального репозитория компании.
* shhgit – утилита, которую можно использовать в качестве системы мониторинга утекших секретов в публичных репозиториях.
* trufflehog - инструмент, который доступен в Github Action, и который поможет пробежаться за секретами по коммитам.
👍4
Продолжаем тему скраппинга Github. В статье "Скребём Github: поиск секретов разработки" разобрал сценарии ручного поиска секретов в репозиториях и рассказал об интересных кейсах утечек учетных данных для коммерческих платформ статического анализа.

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

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

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

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

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

Зачастую такие спецоперации могут длиться годами, и жертва может даже не догадываться о присутствии постороннего в ее собственной ИТ-инфраструктуре. Однако самое печальное, что о существовании, целях и средствах злоумышленников могут уже знать эксперты, которые пристально следят за активностью киберпреступных групп и развитием их инструментов и, кроме того, участвуют в расследовании аналогичных инцидентов, где использовались подобные средства. Более того, уже могут быть опубликованы материалы исследований инструментов, обнаруженных при проведении той или иной APT-атаки, и в этих материалах, кроме текста о том, как исследователь копался в исходном коде малвари, зачастую может содержаться куда более ценная информация, которая окажется полезной для «харденинга» IT-инфраструктуры.

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

Типичный отчет содержит приблизительно следующую информацию об APT-кампании:

* детали о цели и жертвах;
* время активности;
* перечень узлов (IP-адреса) жертв;
* текущая активность;
* показатели компрометации (IOC, YARA rules);
* инструменты, которые использовали злоумышленники;
* описания инфраструктуры командных центров (C&C);
* MD5-хеши вредоносных компонентов.

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

В материалах "Заставь малварь играть по правилам" и "Показатели компрометации как средство снижения рисков" рассказываю об индикаторах компрометации и вариантах их использования для выявления угроз.
Уязвимости системы ведения медицинской документации OpenEMR

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

Одним из таких приложений является OpenEMR – открытая платформа для ведения медицинской практики. Данное программное обеспечение является бесплатным (любая организация может совершенно бесплатно использовать этот продукт для своего бизнеса) и открытым (исходный код данного продукта доступен любому разработчику). Кроме того, это программное обеспечение имеет сертификат ONC Complete Ambulatory EHR, который выдает авторитетная организация в сфере здравоохранения. Именно все эти особенности обеспечили ее популярность данной платформы среди различных медицинских учреждений по всему миру. Достаточно взглянуть на карту, чтобы оценить распространенность этого «лакомого кусочка» для преступников, охотящихся за медицинской информацией.

Так вот к чему это все? В результате беглого анализа безопасности OpenEMR, выяснилось, что вполне реален следующий сценарий:

Шаг 1: злоумышленник внедряет вредоносный код на этапе регистрации на данном портале в качестве пациента.
Шаг 2: данный код попадает на главную страницу портала, и пользователь, который просматривает эту страницу, расстается со своими учетными данными (и как следствие, медицинскими данными).
Шаг 3: таким образом злоумышленник собирает медицинскую информацию всех пользователей данного портала, среди которых есть и врачи.
Шаг 4: учетные данные врачей и администраторов, позволяют злодею добраться до всех пациентов.

В результате: мы смотрим очередную новость про «громкую утечку медицинских данных, в результате которой пострадали 100500 пользователей».
Всех, кто сегодня начинает учебу и тех, кто начинает обучать, поздравляю с Днем Знаний!

В этом году я тоже продолжаю движение «Application Security» вместе со студентами – будущими звездами индустрии информационной безопасности. Уже второй год подряд двигаюсь в открытом формате. Анонс открытых лекций, состоявшийся в прошлом году, остается актуальным и в этом:

“Разработав курс «Основы безопасности приложений» для изучающих информационную безопасность в НИЯУ МИФИ, мы решили сделать наши лекции открытыми для всех студентов любых российских ВУЗов.”

Студент, запрыгивай в чат этого канала, чтобы не пропустить лекции.
👍121
Использование символьного выполнения для выявления вредоносного кода

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

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

Этот метод используется для поиска ошибок в программах, но авторы исследования решили применить его для определения экземпляров ransomware. Выбрав три ключевых признака семплов рансомвары (энумерация файлов, операция над файлами, шифрование), исследователи применили технику символьного выполнения для детекта. Результаты: детект 95,60% рансомвары, 0% ложных срабатываний.
👍7