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

Разбираем феномен целенаправленных атак

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

В новостях то и дело мелькает: «В результате таргетированной атаки преступникам удалось украсть два миллиарда долларов из 40 банков и финансовых организаций по всему миру…», «…Жертвами атаки, направленной на промышленные компании, стали более 500 энергетических, металлургических и строительных компаний более чем в 50 странах…», «…Эффективные и грамотно размещенные вредоносные программы, предназначенные для реализации атак на систему SWIFT, позволили киберпреступникам украсть миллионы…» и так далее, и так далее.

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

К сожалению, термины «таргетированная атака» и «целенаправленная атака» некорректны. Почему? Вспомним классическое определение компьютерной атаки: «Компьютерная атака — целенаправленное несанкционированное воздействие на…». Стоп, стоп, уже достаточно! Получается, что цель-то есть у любой атаки, а не только у «таргетированной».
Отличительная особенность целенаправленных атак заключается в том, что атакующий активно и интеллектуально подходит к выбору точки входа в конкретную инфраструктуру, достаточно долго анализирует циркулирующую в ее компонентах информацию и использует собранные данные для получения доступа к ценной информации.

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

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

Жизненный цикл атаки и возможности противодействия на каждом ее этапе я рассмотрел в своей колонке.

👆Когда кто-то напомнил, что сегодня выходной.

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

* Fuzzing ClamAV with real malware samples

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

* Earn $200K by fuzzing for a weekend: Part 1

За круглой суммой в заголовке находится еще одно подтверждение, что «memory-safe != отсутствие уязвимостей». На примере виртуальной машины, написанной на Rust, автор продемонстрировал эффективность поиска багов Rust-приложений, применив известные техники фаззинга к известному таргету. В материале уделено внимание подготовке тестовых оракулов (test oracles) - механизмов определения ожидаемого и аномального поведений таргета в процессе тестирования.

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

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

Если определить (как это сделали авторы статьи «Unknown Threat Detection With Honeypot Ensemble Analsyis Using Big Datasecurity Architecture») неизвестные атаки как набор действий на сенсорах предварительно развернутого в инфраструктуре ханипота, то впоследствии данные этих сенсоров можно использовать для вычисления признаков выявленной атаки в реальной инфраструктуре с использованием вероятностной оценки.

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

На примере это схемы в материале «Неизвестные атаки: поймать и просчитать» разбираем формальное определение термина «атаки нулевого дня» и приводим пример ее детекта с использованием опен-сорсной IDS.

“Как хакеры могут уничтожить город” - материал, подготовленный специально для издания The Village по мотивам нашего исследования и предназначенный исключительно для воскресного прочтения.

За громким заголовком в духе какого-то блокбастера прячется вполне здравая мысль:

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

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

«Подключенная» медицина и ее диагноз

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

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

Подробности анализа защищенности медицинских устройств находятся во второй части отчета.

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

“S” в аббревиатуре “IoT” означает “Security”.

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

Всем бодрого понедельника!

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

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

Про наступательную безопасность

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

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

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

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

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

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

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

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

Юридические аспекты этой идеи, а также архитектура “offensive honeypot” рассмотрены в авторской колонке для издания «Хакер».

Переоптимизация глубокой нейронной сети с внедрением "downhill" навыков. На этот раз без метода "Dropout" (специалисты по анализу данных поймут метафору).

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

Оценка защищенности к DDoS-атакам

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

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

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

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

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

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

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

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

Время: 18-00, четверг, 28 июля
Место: онлайн
Повод: встречаемся с друзьями из компании Awillix, чтобы обсудить тему безопасной разработки и, в частности, ранние стадии SDLC. Тема открывает цикл эфиров про безопасность ИТ-продуктов и приложений, поэтому если ты не понаслышке знаком с разработкой - добавляй событие в календарь и присоединяйся к дискуссии.

Исследование безопасности умных городов, упакованное в формат доклада и представленное на китайской конференции GeekPWN, которая прошла в Шанхае и включила нас в свой "Hall of Fame" за "sums up the pain points of Smart City".

«Сэр, пройдемте со мной», - говорит один из офицеров и указывает пальцем на коридор с множеством маленьких комнат для допроса. «Цель визита? – Выступление на конференции Hacker Halted 2015. Конечный пункт назначения? – Атланта, Штат Джорджия…» Через полчаса содержательной беседы нам возвращают багаж, и мы выходим из аэропорта, где нас встречает раскаленный воздух и джетлаг. Добро пожаловать в США.

Отчет о моей первой поездке в Атланту на конференцию Hacker Halted. Там же состоялась презентация нашего исследования о деанонимизации пользователей Tor.

Как в компьютерной игре: навык “Enduro” разблокирован.

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

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

Знай актуальную поверхность атаки.

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

Материал, в котором собраны методы проведения разведки на основе открытых источников (Open Source Intelligence, OSINT), основательно описывает процесс и инструменты сбора информации о корпоративном периметре и доступных ресурсах. Техники предназначены в первую очередь для участников bug bounty, но могут быть применены в процессах внешнего анализа защищенности.

К наиболее распространенным ошибкам, которые разработчики совершают в незрелом процессе SDLC, относятся ошибки управление секретами. В кодовую базу попадают пароли, хардкодятся API-ключи к CI/CD и 3rd-party системам, заносятся учетные данные пользователей.

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

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

Продолжаем тему скраппинга Github. В статье "Скребём Github: поиск секретов разработки" разобрал сценарии ручного поиска секретов в репозиториях и рассказал об интересных кейсах утечек учетных данных для коммерческих платформ статического анализа.

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

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

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

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