Не секрет, что реализация механизмов безопасности IoT-устройств далека от совершенства. Известные категории уязвимостей умных устройств хорошо описаны в Top IoT Vulnerabilities от 2018 года. Предыдущая версия документа от 2014 года претерпела немало изменений: некоторые пункты исчезли совсем, другие были обновлены, появились и новые.

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

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

За подробностями следуйте под кат.

I1 Слабые, предсказуемые и жестко закодированные пароли

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

Тип устройства	Название	CWE	Недостаток безопасности
	Routers Netgear	CWE-601: URL Redirection to Untrusted Site ('Open Redirect')	Кто угодно из сети может воспользоваться путаницей в конфигурации, чтобы получить контроль над устройством, изменять настройки DNS и перенаправлять браузер на зараженные сайты.
	Loxone Smart Home	CWE-261: Weak Encoding for Password	Злоумышленник может получить доступ к паролям пользователей, а следовательно, и к их аккаунтам.
	AGFEO smart home ES 5xx/6xx	CWE-261: Weak Encoding for Password	Злоумышленник может получить доступ к паролям пользователей, а следовательно, и к их аккаунтам.
	Industrial wireless access point Moxa AP	CWE-260: Password in Configuration File	Злоумышленник может войти с парой логин-пароль от учетной записи администратора, указанной в инструкции, и получить доступ к управлению всей системой.
	Heatmiser Thermostat	CWE-260: Password in Configuration File	Злоумышленник может войти с парой логин-пароль от учетной записи администратора, указанной в инструкции, и получить доступ к управлению всей системой.
	Digital video recorder Mvpower	CWE-521: Weak Password Requirements	Учетная запись администратора не требует пароль при входе, поэтому доступ к ней может получить кто угодно.
	DBPOWER U818A WIFI quadcopter drone	CWE-276: Incorrect Default Permissions	Злоумышленник может получить доступ к файловой системе, используя возможность анонимного доступа без пароля.
	Nuuo NVR (network video recorder) and Netgear	CWE-259: Use of Hard-coded Password	Злоумышленник может получить привилегии администратора, а значит, и полный контроль над системой из-за жестко закодированного пароля.
	Vacuum Cleaner LG	CWE-287: Improper Authentication	Злоумышленник может обойти аутентификацию и получить доступ к видеозаписям с устройства.
	Eminent EM6220 Camera	CWE-312: Cleartext Storage of Sensitive Information	В инструкции указан пароль 123456, который большинство пользователей установят не задумываясь и сделают свое устройство уязвимым.
	LIXIL Satis Toilet	CWE-259: Use of Hard-coded Password	Пароль для подключения устройства по Bluetooth хранится в открытом виде в коде, что дает злоумышленнику возможность управлять работой умного унитаза по собственному желанию и против воли владельца.
	FUEL Drill	CWE-259: Use of Hard-coded Password	Злоумышленник может найти жестко закодированный пароль и получить права администратора и управлять устройством.
	Billion Router 7700NR4	CWE-798: Use of Hard-coded Credentials	Жестко закодированные учетные данные дают злоумышленнику возможность получить полный контроль над устройством.
	Canon Printers	CWE-269: Improper Privilege Management & CWE-295: Improper Certificate Validation	Злоумышленник может получить доступ к незащищенному устройству и обновить прошивку, потому что логин и пароль не требуются для доступа к устройству.
	Parrot AR.Drone 2.0	CWE-285: Improper Authorization	Пустая пара логин-пароль дает возможность злоумышленнику подключиться к дрону и управлять им.
	Camera Amazon Ring	CWE-285: Improper Authorization	Злоумышленник может использовать для авторизации учетные данные по умолчанию.

I2 Небезопасные сетевые подключения

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

Тип устройства	Название	CWE	Недостаток безопасности
	Smart Massager	CWE-284: Improper Access Control	Злоумышленник может изменить параметры массажера и причинить пользователю боль, вызвать ожог кожи и нанести вред здоровью.
	Implantable Cardiac Device	CWE-284: Improper Access Control	Злоумышленник может изменить настройки имплантируемого устройства, что может увеличить расход батареи и/или нанести вред здоровью.
	Hikvision Wi-Fi IP Camera	CWE-284: Improper Access Control	Злоумышленник может удаленно управлять камерой и даже отключить ее.
	Foscam C1 Indoor HD Cameras	CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')	Удаленное исполнение кода на камерах может привести к утечке чувствительной пользовательской информации.
	Toy Furby	CWE-284: Improper Access Control	Злоумышленник может внести изменения в прошивку и использовать Ферби для слежки за детьми.
	Toy My Friend Cayla	CWE-284: Improper Access Control	Злоумышленник может следить за пользователями и собирать информацию о них.
	iSmartAlarm	CWE-20: Improper Input Validation	Злоумышленник может "заморозить" будильник, и он перестанет будить.
	iSPY Camera Tank	CWE-284: Improper Access Control	Злоумышленник может залогиниться на устройстве как анонимный пользователь и заполучить контроль над файловой системой устройства.
	DblTek GoIP	CWE-598: Information Exposure Through Query Strings in GET Request	Злоумышленник может отправить команды для изменения конфигурации или выключить устройство.
	Nuuo NVR (network video recorder) and Netgear	CWE-259: Use of Hard-coded Password	Злоумышленник может получить привилегии администратора, изменять настройки устройства и даже следить за пользователями.
	Sony IPELA Engine IP Cameras	CWE-287: Improper Authentication	Злоумышленник может использовать камеру для отправки фото и видео, добавить камеру в ботнет Mirai или следить за пользователями.
	iSmartAlarm	CWE-295: Improper Certificate Validation	Злоумышленник может получить пароль или другие пользовательские данные с помощью поддельного SSL-сертификата.
	Routers Dlink 850L	CWE-798: Use of Hard-coded Credentials	Из-за небезопасного сетевого подключения злоумышленник может получить полный контроль над устройством.
	Amazons Ring Video Doorbell	CWE-419: Unprotected Primary Channel	Учетные данные для подключения к устройству передаются по незащищенному каналу связи.
	Cacagoo IP camera	CWE-287: Improper Authentication	Злоумышленник может воспользоваться возможностью неавторизованного доступа к устройству, а затем управлять им.
	Trifo Ironpie M6 Vacuum cleaner	CWE-284: Improper Access Control	Злоумышленник может удаленно подключиться к устройству и управлять им.

I3 Небезопасные интерфейсы экосистем

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

Тип устройства	Название	CWE	Недостаток безопасности
	Industrial wireless access point Moxa AP	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	Злоумышленник может получить доступ к сессии, которая никогда не истечет.
	AXIS cameras	CWE-20: Improper Input Validation	Злоумышленник может изменить любой файл в системе, получив права администратора.
	Belkins smart home products	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') & CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')	Злоумышленник может получить достук к телефону и чувствительной информации.
	Routers D-Link DIR-300	CWE-352: Cross-Site Request Forgery (CSRF)	Злоумышленник может изменить пароль от учетной записи администратора и получить его привилегии.
	AVTECH IP Camera, NVR, DVR	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	Злоумышленник может изменять настройки устройства через атаку CSRF (например, пароли пользователей).
	AGFEO smart home ES 5xx/6xx	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	Злоумышленник может получить доступ ко всем файлам, хранящимся в системе. Он может изменить конфигурацию устройства и установить нелегитимное обновление.
	Loxone Smart Home	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	Все функции устройства могут контролироваться злоумышленником через команды веб-интерфейса.
	Switch TP-Link TL-SG108E	CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	Злоумышленник может реализовать XSS-атаку на устройство и "заставить" администратора выполнить Javascript-код в браузере.
	Hanbanggaoke IP Camera	CWE-650: Trusting HTTP Permission Methods on the Server Side	Злоумышленник может изменить пароль администратора и получить его привилегии.
	iSmartAlarm	CWE-287: Improper Authentication	Злоумышленник может отправлять команды на устройство, включать и выключать его.
	Western Digital My Cloud	CWE-287: Improper Authentication	Злоумышленник может получить полный контроль над устройством.
	In-Flight Entertainment Systems	CWE-287: Improper Authentication	Злоумышленник может контролировать средства информирования пассажиров. Например, может подделать данные о полете (высота, скорость и пр.).
	Smart key KeyWe	CWE-327: Use of a Broken or Risky Cryptographic Algorithm	Злоумышленник может узнать закрытый ключ, чтобы открыть дверь.

I4 Отсутствие безопасного механизма обновлений

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

Тип устройства	Название	CWE	Недостаток безопасности
	Devices by GeoVision	CWE-295: Improper Certificate Validation	Злоумышленник может обновить прошивку устройства без авторизации.
	Canon Printers	CWE-295: Improper Certificate Validation	Механизм аутентификации отсутствует: кто угодно может получить доступ к устройству и обновить/изменить прошивку.
	Smart Nest Thermostat	CWE-940: Improper Verification of Source of a Communication Channel	Прошивка доставляется на устройство по незащищенному протоколу передачи данных, и нет возможности проверить ее легитимность.

I5 Использование небезопасных или устаревших компонентов

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

Тип устройства	Название	CWE	Недостаток безопасности
	Amazon Echo	CWE-1233: Improper Hardware Lock Protection for Security Sensitive Control	Злоумышленник при помощи паяльника может изменить конфигурацию колонки, и превратить ее в устройство для прослушки.
	Light bulb	CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls	Злоумышленник может перепаять элементы лампы.

I6 Недостаточная защита приватности

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

Тип устройства	Название	CWE	Недостаток безопасности
	Gator 2 smartwatch	CWE-359: Exposure of Private Information ('Privacy Violation')	Злоумышленник может получить доступ к информации о версии прошивки, IMEI, времени, методе определения локации (GPS/Wi-Fi), координатах и уровне заряда батареи.
	Routers D-Link DIR-600 and DIR-300	CWE-200: Information Exposure	Злоумышленник может получить доступ к чувствительной информации об устройстве или сделать его частью ботнета.
	Samsung Smart TV	CWE-200: Information Exposure	Злоумышленник может получить доступ к бинарным файлам или аудиозаписям, хранящимся в системе телевизора.
	Home security camera	CWE-359: Exposure of Private Information ('Privacy Violation')	Фотографии пользователя могут быть украдены злоумышленником и опубликованы в сети.
	Smart sex toys We-Vibe	CWE-359: Exposure of Private Information ('Privacy Violation')	Злоумышленник может получить информацию о температуре устройства и интенсивности его вибрации.
	iBaby M6 baby monitor	CWE-359: Exposure of Private Information ('Privacy Violation')	Злоумышленник может просмотреть информацию, включая детали видеозаписи.

I7 Небезопасная передача и хранение данных

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

Тип устройства	Название	CWE	Недостаток безопасности
	Owlet Wi-Fi baby heart monitor	CWE-201: Information Exposure Through Sent Data	Злоумышленник может следить за детьми и родителями через камеру.
	Samsung fridge	CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')	Злоумышленник может заполучить учетные данные от Google-аккаунтов жертв.
	Volkswagen car	CWE CATEGORY: Cryptographic Issues	Злоумышленник может получить удаленный доступ к управлению машиной.
	HS-110 Smart Plug	CWE-201: Information Exposure Through Sent Data	Злоумышленник может контролировать работу вилки, например, выключить подсветку.
	Loxone Smart Home	CWE-201: Information Exposure Through Sent Data	Злоумышленник может контролировать каждое устройство, работающее в системе умного дома, и получить права доступа пользователя.
	Samsung Smart TV	CWE-200: Information Exposure	Злоумышленник может прослушивать беспроводную сеть и инициировать атаку брутфорсом, чтобы восстановить ключ и дешифровать трафик.
	Routers Dlink 850L	CWE-319: Cleartext Transmission of Sensitive Information	Злоумышленник может удаленно контролировать устройство.
	Skaterboards Boosted, Revo, E-Go	CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')	Злоумышленник может отправлять различные команды, чтобы управлять скейтом.
	LIFX smart LED light bulbs	CWE-327: Use of a Broken or Risky Cryptographic Algorithm	Злоумышленник может перехватывать и дешифровать трафик, включая данные о конфигурации сети.
	Stuffed toys	CWE-521: Weak Password Requirements	Аудиозаписи пользователей хранятся так, что доступ к ним может получить злоумышленник.
	IoT Smart Deadbolt	CWE-922: Insecure Storage of Sensitive Information	Злоумышленник может получить доступ к чувствительной информации, хранящейся на устройстве.
	Router ASUS	CWE-200: Exposure of Sensitive Information to an Unauthorized Actor	Злоумышленник может получить доступ к чувствительной пользовательской информации.

I8 Отсутствие возможности настройки устройства

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

Тип устройства	Название	CWE	Недостаток безопасности
	TP-LINK IP Surveillance Camera	CWE-? (не удалось подобрать CWE)	Злоумышленник может беспрепятственно эксплуатировать уязвимость в устройстве, так как оно устарело и не обновляется.

I9 Небезопасные настройки по умолчанию

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

Тип устройства	Название	CWE	Недостаток безопасности
	ikettle Smarter Coffee machines	CWE-15: External Control of System or Configuration Setting	Злоумышленник может получить полный контроль над устройством из-за того, что большинство пользователей не настраивают кофемашины под себя, а оставляют их с заводскими небезопасными настройками.
	Parrot AR.Drone 2.0	CWE-284: Improper Access Control	Настройки дрона предполагают возможность неавторизованного подключения к нему и управления им.
	HP Fax machine	CWE-276: Incorrect Default Permissions	Злоумышленник может воспользоваться неправильными настройками факса и полным отсутствием механизмов безопасности.
	Smart speakers	CWE-1068: Inconsistency Between Implementation and Documented Design	Колонки активируются словами, не указанными в инструкции, и прослушивают происходящие.

I10 Отсутствие физической защиты

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

Тип устройства	Название	CWE	Недостаток безопасности
	Baby monitors Mi-Cam	CWE-284: Improper Access Control	Злоумышленник может следить за пользователями.
	TOTOLINK router	CWE-20: Improper Input Validation	Злоумышленник может внедрить бэкдор.
	Router TP-Link	CWE-284: Improper Access Control	Злоумышленник может получить привилегии администратора и сделать устройство частью ботнета через незащищенный UART.
	Smart Nest Thermostat	CWE-284: Improper Access Control	Злоумышленник может загрузить процессор через периферийное устройство по USB или UART.
	Blink XT2 Sync Module	CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls	Незащищенный разъем позволяет злоумышленнику подключиться к устройству.
	Amazon Echo	CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls	Злоумышленник при помощи паяльника может изменить конфигурацию колонки, превратив ее в устройство для прослушки.

К сожалению, этот список можно продолжать бесконечно. На рынке появляется все больше IoT-устройств, а значит у злоумышленников появляются все новые возможности для достижения своих целей. Наша подборка уязвимых IoT-устройств не единственная, и мы предлагаем вам узнать о них больше: Safegadget, Exploitee и Awesome IoT Hacks

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

Национальный институт стандартов и технологий США выпустил Межведомственный отчет о состоянии международной стандартизации кибербезопасности для Интернета вещей (IoT). В этом документе приведены стандарты безопасности программного обеспечения и рекомендации по повышению его защищенности. Кроме того, производителям IoT-устройств рекомендуется использовать программное обеспечение, способное предотвращать, обнаруживать и смягчать вредоносное воздействие на производимые устройства.

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

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

Первоисточник

• Какие бизнес-задачи решает Secure SDLC
• Как строится Secure SDLC: схема проверки, инструментарий, согласование графика релизов
• Вот такие баги ловит команда Secure SDLC: кейсы из практики Digital Security
• Жизнь после SDLC: дальнейшее развитие APP Sec в компании

• Руководители компаний-разработчиков ПО
• Руководители отделов разработки
• Руководители и сотрудники подразделений ИБ компаний-разработчиков

10 июня компания Digital Security провела онлайн-встречу по информационной безопасности Digital Security ON AIR. Записи докладов можно посмотреть на Youtube-канале.

По материалам докладов мы выпустим цикл статей, и первая из них об уязвимостях PHP-фреймворков уже ждет под катом.

Что такое MVC

Большинство PHP фреймворков использует MVC Model-View-Controller концепцию разделения проекта на три отдельных компонента:

• модели, отвечающие за данные;
• представления, отвечающие за интерфейс;
• контроллеры, отвечающие за логику.

Компоненты независимы друг от друга, то есть внесение изменений в один из них не затронет другие.

Полезные уязвимости в PHP

Итак, что же искать в типичном проекте, созданном на PHP-фреймворке? Искать нужно все! Как ни удивительно, встретить можно любую уязвимость, так как ответственность за безопасность лежит в большей степени на разработчике проекта. Прежде всего нужно проверить, не включен ли режим отладки (исследователю это будет на руку; но если вы забыли выключить его на своем сайте, то поспешите это сделать). Режим отладки сильно поможет как в дальнейшем поиске уязвимостей, так и в их эксплуатации. Кроме режима отладки в любом проекте на PHP обязательно используются операторы сравнения для описания логики приложения. И тут скрывается еще одна уязвимость, типичная для PHP.

Речь идет о type juggling. Она возникает, когда в коде используется оператор сравнения == вместо ===. Оператор сравнения == сравнивает объекты в PHP по-особому, предварительно преобразовывая типы данных, из-за чего логика при сравнении пользовательских данных может быть нарушена. Например, можно войти под учетной записью администратора, используя пароль null. Оператор сравнения === сравнивает объекты без преобразования типов, рекомендуется использовать его в качестве основного оператора сравнения. Примеры сравнения приведены в табличке ниже из доклада о type juggling от OWASP.

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

Не менее распространенная уязвимость, из-за которой возможны большинство RCE, это десериализация потенциально опасных данных. Дело в том, что в PHP можно сериализовать любой объект преобразовать объект в строку, из которой его можно восстановить. Для восстановления строчку нужно десериализовать с помощью функции unserialize(). Уязвимость возникает, когда на вход этой функции подаются данные, контролируемые пользователем. Так он может собрать цепочку из классов, которые приведут к выполнению кода или чтению файлов на сервере. Тут стоит упомянуть phpggc сборник уже готовых гаджетов (gadgetchains, цепочек из классов) для популярных PHP-фреймворков. Узнать больше об эксплуатации десериализации можно из доклада Павла Топоркова.

Каждый фреймворк состоит из набора пакетов, которые нужно как-то компоновать. На помощь приходит Composer, управляющий всеми зависимостями, который используется во всех фреймворках и сильно упрощает жизнь: все зависимости прописаны в одном файле composer.json. Все зависимые пакеты можно проверить на уязвимости с помощью сайта snyk.io просто передав ему composer.json. Также можно проверить только PHP-уязвимости с помощью специального инструмента Security Checker.

Laravel

Перейдем к главному к анализу PHP-фреймворков. Самым популярным PHP-фреймворком считается Laravel: он очень простой и достаточно безопасный сам по себе. Вся его логика описана в контроллерах. Middleware находится рядом с контроллерами и нужна для проверки шаблонных условий: например, является ли пользователь администратором или является ли введенный e-mail валидным. Также middleware может лежать в kernel.php. Все маршруты лежат в одной папке. Web маршруты лежат в web.php, а api маршруты в api.php. Представления лежат в отдельной папке и обычно являются blade-шаблонами. Конфигурационный файл сайта находится в корне, в файле .env. В нем хранятся учетные данные от базы данных и APP_KEY, включается режим отладки и прописываются другие настройки сервера.

Всего было найдено четыре довольно критичных уязвимости в Laravel:

• CVE-2017-9303 специфичная утечка учетных данных;
• CVE-2017-16894 утечка файла .env через прямое обращение к нему (http://example.com/.env);
• CVE-2018-6330 error-based SQLI в GET-параметре dhx_user (пример вызова версии базы данных представлен на рисунке ниже);
  
• CVE-2018-15133 полноценная RCE через десериализацию хедера.

Рассмотрим возможность получения RCE.

В качестве примера был создан блог, уязвимый к этой CVE. Эксплуатация данной уязвимости возможна при соблюдении двух условий: нужно знать APP_KEY из .env, и сервер должен принимать POST-запросы. Если версия Laravel очень старая, то можно воспользоваться имеющейся уязвимостью CVE-2017-16894 и достать .env (http://example.com/.env). Второй способ вызвать ошибку, чтобы перейти в режим отладки, и из него получить необходимый APP_KEY. Далее генерируем заголовок со встроенной полезной нагрузкой. Если отправить POST запрос на сервер с таким заголовком, то полезная нагрузка десериализуется на сервере, что спровоцирует выполнение кода. В данном случае выполнится команда, которую мы первым аргументом передали в скрипт. Скрипт состоит из двух частей: скрипта подписи заголовка, доступного по ссылке, и phpggc-модуля, с помощью которого генерируется полезная нагрузка. Остается отправить POST-запрос с этим заголовком и получить результат выполнения команды на сервере.

Symfony

В PHP-фреймворке Symfony маршруты располагаются в директории config. Контроллеры находятся в директории src, представления в директории templates.

У Symfony на cvedetails можно найти наибольшее количество CVE по сравнению с другими фреймворками. Среди них есть и пара очень старых RCE. Одна возможна из-за того, что при эксплуатации XSS в тэге script в параметре language можно указать язык PHP, и тогда PHP-код, указанный внутри тэга, выполнится на сервере. Вторая RCE, еще более старая, позволяет поместить PHP-код в специально сконфигурированный yaml-файл. При парсинге yaml-файла PHP-код выполнится на сервере.

Интересна история с обходом аутентификации. Сразу оговоримся, что CVE 2016 и 2018 года относятся к одному и тому же модулю аутентификации через LDAP. В 2016 году обнаружили, что процесс аутентификации можно обойти, используя пустой пароль (CVE-2016-2403). Уязвимость исправили, но допустили ошибку.

В 2017 году в другом модуле аутентификации нашли ту же проблему (CVE-2017-11365). В этот раз действительно исправили: введенный пользователем пароль сверяется не только с пустой строкой, но и с null. Это необходимо, потому что в языке PHP null не считается за пустую строку.

В 2018 году все-таки нашли ошибку в исправлении 2016 года (да-да, и такое бывает), которая позволяла обойти аутентификацию с помощью null, и закрыли ее (CVE-2018-11407).

Вот так можно было 2 года обходить LDAP с помощью null.

За последний год нашли еще несколько разнообразных уязвимостей на любой вкус. Некоторые из них легко эксплуатировать, например, уязвимости, заключающиеся в возможности header injection. Другие например RCE эксплуатировать довольно-таки сложно. Они новые, и модулей для них в phpggc нет, а работать с классами во фреймворках надо уметь. Так что если встретились с Symfony, уязвимым к этим багам, желаю удачи :)

Yii

Перейдем к фреймворку Yii. У него все не так, как у других, поэтому рассмотрим его более внимательно.

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

Фильтр та же middleware, которая используется для шаблонных действий. Например, чтобы проверить, является ли пользователь администратором или является ли введенный e-mail валидным. Виджеты служат для создания сложных настраиваемых элементов пользовательского интерфейса. Например, с помощью виджета можно сгенерировать интерфейс выбора дат. Кроме того, в Yii нет конкретного файла с маршрутами. Все дело в том, что он сам строит маршрутизацию внутри сайта, используя контроллеры и действия. Соответственно, нам нужно либо вручную искать все контроллеры и все действия, либо писать чудо-скрипт, который сгенерирует файлик с маршрутами.

Из уязвимостей следует отметить три CVE:

• CVE-2014-4672 RCE, позволяющая выполнять любые PHP-методы;
• CVE-2018-6010 утечка информации через ошибки;
• CVE-2018-7269 SQLi.

Остановимся на первых двух поподробнее.

Утечка информации возникает, когда режим отладки выключен и исключения ловятся стандартной функцией. Так вышло, что при переходе на страницу About срабатывает исключение, режим отладки выключен, и мы не можем получить никакой дополнительной информации из этой ошибки. Но если на эту же страницу обратиться при помощи ajax-запроса, то внезапно мы получаем содержимое конфигурационного файла. Как же так? Все дело в том, что при ajax-запросе выдается сообщение, прописанное в исключении. Для наглядности мы поместили туда конфигурационный файл сайта. Однако, через такую уязвимость могут просочиться достаточно чувствительные данные (пароли или ключи), которые помогут при исследовании сайта.

Если вам повезло встретить проект, использующий Yii версии 1.1.14 и виджет CDetailView, в который передаются пользовательские данные, то вы сможете выполнять любой метод на сервере. На Github'е пишут, что таким образом можно выполнить любой PHP-файл в системе, но когда я попробовал это сделать, он не проходил условие, прописанное в функции run класса CDetailView, если не был явно подключен в коде.

$value=is_callable($attribute['value']) ? call_user_func($attribute['value'],$this->data) : $attribute['value'];

Так мы передаем название класса и метода в запросе и видим содержимое конфигурационного файла сайта при помощи заранее добавленной секретной функции. Это все происходит потому, что параметр value проверяется функцией is_callable(), и если результат сравнения положительный, то он вызывается функцией call_user_func().

CakePHP

Фреймворк CakePHP структурно мало чем отличается от Laravel. Понятно, где искать модели, представления и контроллеры.

В нем так бы и были только лишь древние уязвимости (CVE-2010-4335, CVE-2012-4399), если бы не недавняя CVE-2019-11458 на десериализацию, при помощи которой можно перезаписывать файлы на сервере. Гаджетов пока что нет, поэтому будем ждать обновления phpggc.

Codeigniter

И, наконец, Codeigniter. Структура приложения понятная, все компоненты находятся на своих местах.

Из интересных уязвимостей можно выделить две старых (CVE-2014-8684, CVE-2016-10131) и одну относительно новую (CVE-2017-1000247). Первая из них настолько старая, что для нее есть модуль для Metasploit. Вторая встречается не только в этом фреймворке, но и во многих других PHP-фреймворках и PHP-приложениях. Более свежая CVE 2017 года обычная header injection в функции set_status_header(). Рассмотрим поподробнее две старые уязвимости.

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

В этом примере рассмотрим вторую уязвимость в функции mail(). Она передает параметры в программу Sendmail, пятый аргумент которой опционален. Этим пятым аргументом в нее можно передать адрес отправителя, чтобы почтовый сервер получил сообщение об ошибке, если сообщение не будет доставлено. Но передает он его в Sendmail с помощью флага -f, благодаря чему можно вставить через пробел свои аргументы и получить RCE. Существует много техник эксплуатации, но обычно используется два основных метода. В первом случае при помощи флага -С (использовать другой конфигурационный файл) читаем содержимое любого файла на сервере; его можно сохранить в какой-нибудь файл при помощи флага -Х (записывать весь траффик). Это нужно для того, чтобы открыть файл напрямую через сайт, записав содержимое файла в корень веб-сервера. Во втором случае с помощью флага -OQueueDirectory перемещаем письмо в очередь в указанную папку и сохраняем его полностью с PHP-кодом внутри тела письма. Далее выполняем его, например, добавив в корень веб-сервера.

Заключение

Подводя итог, стоит сказать, что PHP-фреймворки просты и лаконичны. Наиболее критичные уязвимости существуют в старых версиях фреймворков, так что необходимо регулярно обновлять их, иначе пентест продукта может сразу выявить парочку RCE. Я разобрал и перечислил далеко не все уязвимости, и далеко не во всех фреймворках. Кто знает, сколько еще удивительных уязвимостей они хранят в себе. Увлекательных пентестов!

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

Один из протоколов, используемых для увеличения безопасности онлайн-платежей 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.

Почему протокол 3D Secure называется именно так?

Полное название этого протокола Three Domain Secure.
Первый домен домен эмитента это банк, выпустивший используемую карту.
Второй домен домен эквайера это банк и продавец, которому выплачиваются деньги.
Третий домен домен совместимости (interoperability domain) инфраструктура, используемая при оплате картой (кредитной, дебетовой, предоплаченной или другими типами платежных карт) для поддержки протокола 3D Secure. Он включает в себя Интернет, подключаемый модуль продавца (merchant plug-in), сервер контроля доступа (access control server) и других поставщиков программного обеспечения.

Зачем это нужно?

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

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

Версии протокола 3D Secure

v1.0 - 2001 г -v2.0 - 2014 г - Устарелоv2.1 - 2017 гv2.2 - 2018 г

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

На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.

Как это устроено?

Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.

На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.

Как это работает?

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

1 Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку "Оплатить". В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.

После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.

После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.

VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.

Клиенты не могут видеть эти два типа сообщений.

2 MPI создает PaReq (Payment Request) запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.

Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.

3 Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.

А поподробнее?

CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.

<?xml version="1.0" encoding="UTF-8"?><ThreeDSecure>  <Message id="999">    <VEReq>      <version>1.0.2</version>      <pan>4444333322221111</pan>      <Merchant>        <acqBIN>411111</acqBIN>        <merID>99000001</merID>        <password>99000001</password>      </Merchant>      <Browser>        <deviceCategory>0</deviceCategory>        <accept>*/*</accept>        <userAgent>curl/7.27.0</userAgent>      </Browser>    </VEReq>  </Message></ThreeDSecure>

В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.

<?xml version="1.0" encoding="UTF-8"?><ThreeDSecure>  <Message id="999">    <VERes>      <version>1.0.2</version>      <CH>        <enrolled>Y</enrolled>        <acctID>A0fTY+pKUTu/6hcZWZJiAA==</acctID>      </CH>      <url>https://dropit.3dsecure.net:9443/PIT/ACS</url>      <protocol>ThreeDSecure</protocol>    </VERes>  </Message></ThreeDSecure>

VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.

Pareq

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

URL: https://site.ru/acs/pareqMD=5ebde4d3-3796-7a4d-5ebd-e4d300003dd0&PaReq=eJxVUstywjAM%2FBUm98QPDDiMcIc2dMoh0AedKb2ljiDpNAFMUgJfXzuFPnzSrjQraWW4aoqPzieafb4pRx4LqNfBUm%2FSvFyPvOfFrS%2B9KwWLzCBGT6hrgwpi3O%2BTNXbydOS96VDocEX9FePaF1IIPwlF6qeoV7Inqeyh9hTcjx9xp%2BDcSNk%2BAQdygVbR6CwpKwWJ3l1PZ0rwQZ9SIGcIBZpppAaSuse7POwC%2BeagTApUy%2FEsmrwE8Xw2WQJpKdCbuqzMUfWFLb4AqM2HyqpqOyTkcDgExabEY3BMyhSbwNRAXB7I70D3tYv2Vq%2FJUzU7Teg8ejjE7xMWn9Z8Hk35fKEtNx4BcRWQJhUqTplklIoOC4c9NuwOgLQ8JIUbRDHK2vW%2BEWxdk%2FG%2F1F8KrO%2FGnuWyywUBNls7v62wZv7EQH5nvrlzlurKGsUGNOwy0ZfhXf5udlkmV7ey98rfmnjpjG6LnGJubeKUslbSASBOhpxvSM7nt9G%2Fb%2FEFnkK9RA%3D%3D&TermUrl=https%3A%2F%shop.ru%2Fgates%2F3ds

Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq параметр этого платежного запрос. Он содержит всю важную информацию о платеже;
3) TermUrl URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.

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

Важный момент 1: ACS сервера обрабатывают все входящие PaReq!

Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.

Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).

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

Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос это попробовать выполнить XXE. И это правильный путь!

Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:

<ThreeDSecure><Message id="poEpShmja0A36YWe0JOyr4Zt"><Error><version>1.0.2</version><errorCode>99</errorCode><errorMessage>Permanent system failure.</errorMessage><errorDetail>Failed to build error message.</errorDetail></Error></Message></ThreeDSecure><errorCode>5</errorCode><errorMessage>Format of one or more elements is invalid according to the specification.</errorMessage><errorCode>98</errorCode><errorMessage>Transient system failure</errorMessage><errorCode>4</errorCode><errorMessage>Critical element not recognized</errorMessage>

Ошибка может помочь получить дополнительную информацию о версии ACS. Некоторые из них могут также оказаться полезными для получения данных из XXE.

Раскрутим XXE

Рассмотрим следующий пример:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ThreeDSecure [<!ENTITY ac SYSTEM "file:///proc/sys/kernel/hostname">]><ThreeDSecure><Message id=123-123-123-123-123-123"><PAReq><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>&ac;</merID><name>MerchantName</name><country>643</country><url>http://asdas.as</url></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><amount>202000</amount><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent><desc>AcquirerName</desc></Purchase><CH><acctID>DYasdVQAOX6as3dfcxccwzPCR6Q74eS5</acctID><expiry>2209</expiry></CH></PAReq></Message></ThreeDSecure>

acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.

Еще один интересный параметр (и наиболее полезный для атаки) это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.

Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:

<ThreeDSecure><Message id=" 123-123-123-123-123-123 "><PARes id=" 123-123-123-123-123-123 "><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>ACS server name</merID></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent></Purchase><pan>000000000000000</pan><TX><time>20181004 21:34:21</time><status>U</status></TX><IReq><iReqCode>55</iReqCode><iReqDetail>PAReq.CH.acctID</iReqDetail></IReq></PARes></Message></ThreeDSecure>

Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор это выполнить DOS через XXE-атаку "billion laughs" (проверялось на тестовом сервере).

Где это можно найти?

В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:

/acs/pareq/___uid___/acspage/cap?RID=14&VAA=B/way4acs/pa?id=____id____/PaReqVISA.jsp/PaReqMC.jsp/mdpayacs/pareq/acs/auth/start.do

И распространенные имена поддоменов:

acs3ds3dssecurecappaymentsecm3dsauthtestacscard

Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.

3D Secure v 2. *

Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.

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

Для этого в 3DS 2.0 предусмотрели 3DS SDK.

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

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

Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!

Этот психологический момент послужил причиной изменения спецификации второй версии протокола для сокрытия момента перенаправления.

Как работает 3D Secure v2?

Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.

Первый и самый важный момент это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.

Особенности работы v2

Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).

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

А поподробнее?

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

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

Что контролирует пользователь?

CReq (base64url json) challenge request сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.

{"ThreeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e","AcsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340","MessageType": "CReq","MessageVersion": "2.1.0","SdkTransID": "b2385523-a66c-4907-ac3c-91848e8c0067","SdkCounterStoA": "001"}

Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).

В CReq вы можете увидеть следующие поля:

К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.

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

Проблемы (найденные и возможные)

На что смотреть в v1

• XXE в параметре Pareq:
  
  • DOS
  • чтение файла
  • ssrf
• XSS в параметрах TermUrl
• Blind XSS все параметры и заголовки попадают в систему мониторинга
• Pareq не подписан, но в нем есть цена! Отсюда может последовать атака уже на магазин, т.к. если на стороне магазина не будет проверки суммы подтвержденной операции, то вы сможете совершить покупку вещи стоимостью в 100р за 1р.

На что смотреть в v2

• Blind XSS все параметры и заголовки попадают в систему мониторинга
• Challenge flow, главное его поймать

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

Полезные ссылки

https://github.com/w3c/webpayments/wiki
https://www.EMV.com/emv-technologies/3d-secure/
https://3dsserver.netcetera.com/3dsserver-saas/doc/current/schema/3ds-api.html
https://github.com/webr0ck/3D-Secure-audit-cheatsheet

P.S. Возможно, вам пришел в голову вопрос: "Я пользовался AliExpress, Amazon, другое, и мне не приходил OTP код. Здесь использовался 3DS?" Нет, не использовался. Это как раз примеры тех случаев, когда магазин берет на себя ответственность за мошеннические операции.

Узнав результаты голосования, проведённого в одной из наших прошлых статей, мы решили более подробно обсудить вопрос организации фаззинга. Кроме того, в рамках онлайн-встречи по информационной безопасности "Digital Security ON AIR" мы представили доклад, основанный на нашем опыте в DevSecOps, где также рассказали об этой интересной теме.

Записи всех докладов можно посмотреть на нашем Youtube-канале. Если же вы предпочитаете текстовый формат, добро пожаловать под кат!

1. Фаззинг
   
   • Введение
   • Эффективно ли тестирование?
   • Что такое фаззинг?
   • Фаззинг всё ещё популярен?
   • Статический анализ
   • Непрерывный фаззинг в непрерывной разработке
2. Этапы интеграции фаззинга в проект
   
   • Выбор инструментов для организации фаззинга
   • Определение Attack surface
   • Анализ целей для фаззинга
   • Подбор входных данных
   • Написание фаззера
   • Сборка и её особенности на разных платформах
3. Фаззинг в облаке
   
   • Фаззинг-ферма от Google
   • Почему решение от Google подходит не всем?
   • Что получаем в итоге?
4. Заключение

Фаззинг

Введение

Относительно недавно вышла замечательная книга Building Secure and Reliable Systems от инженеров компании Google. Её главным лейтмотивом является мысль о том, что безопасность и надёжность систем и ПО тесно взаимосвязаны. Публикация подобного материала одним из крупнейших лидеров IT-рынка отлично демонстрирует, что безопасность становится неотъемлемой частью как процесса разработки, так и всего жизненного цикла системы или ПО.

Эффективно ли тестирование?

Чтобы сделать безопасную и стабильную систему, её нужно тестировать. К сожалению, писать идеальный код, не требующий доработки, не может никто. Поэтому в написанном коде априори есть ошибки и уязвимости. Как и в других сферах жизни, понимание этого приходит лишь с опытом. Аналогично в IT в целом и в разработке в частности: каждая компания или команда может находиться на своем уровне профессиональной зрелости. Какие-то подходы на определённом этапе будут просто недоступны для них. Так, если не внедрена непрерывная интеграция, то и о нормальном тестировании речи быть не может, не говоря уже о тестировании безопасности во время разработки. Так что, если вы не внедрили непрерывную интеграцию (CI), мы надеемся, что после прочтения нашей статьи вы начнёте делать шаги в нужном направлении. Далее мы предполагаем, что у вас есть настроенный и функционирующий CI, на базе которого и будут предлагаться улучшения.

CI/CD нужны не только для автоматизированных тестов, но и в глобальном плане для того, чтобы соответствовать требованиям времени. Каскадная модель разработки, согласно которой этапы проектирования, разработки и тестирования происходят строго последовательно, постепенно уходит в прошлое или остается лишь в определенных нишах. Сейчас очень важна скорость разработки. Важно, чтобы каждая часть ПО могла развиваться независимо от других частей. Таким требованиям соответствует метод непрерывной разработки. А непрерывной разработке нужно непрерывное тестирование.

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

https://resources.securitycompass.com/blog/how-to-sell-training-costs-internally-2

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

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

Что такое фаззинг?

Для начала небольшой исторический экскурс. Сам термин "фаззинг" ("fuzzing") появился впервые около 30 лет назад в работе An Empirical Study of the Reliability of UNIX Utilities. С его появлением связана одна интересная легенда. В 1988 удар молнии исказил передаваемые по линии данные, что привело к падению утилиты автора исследования. После этого уже профессор Брет Миллер вместе со своими студентами сделал полноценное исследование в данном направлении и на одном из семинаров представил программу fuzzer. Данная программа предназначалась как раз для тестирования ПО. Сам Брет Миллер так описывал свой подход: Наш подход не является заменой формальной верификации или тестирования. Скорее, это легковесный механизм для поиска ошибок в системе и повышения её надёжности. Официальное же определение фаззинга звучит так:

Фаззинг это техника автоматизированного тестирования, при которой на вход программе подаются специально подготовленные данные, которые могут привести её к аварийному состоянию или неопределённому поведению.

Сегодня мы сконцетрируемся на использовании фаззинга для кода на таких языках программирования, как С и С++, потому что:

• в ПО на таких ЯП чаще находят бинарные уязвимости;
• эффективные средства поиска уязвимостей, такие как libFuzzer и AFL, ориентированы, в первую очередь, на языки C и C++;
• огромное количество программ и библиотек написано на C и C++.

Тем не менее все указанные наработки как минимум можно использовать без особых проблем для ПО на Rust или Go.

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

The Art, Science, and Engineering of Fuzzing:A Survey

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

• по знанию о входных данных:
  
  • Black-box мы ничего не знаем про формат данных. Нужно реверсить
  • Gray-box что-то о формате мы выяснили, но полная информация о нём нам всё ещё неизвестна
  • White-box у нас есть спецификация. Мы располагаем всеми сведениями о формате данных
• по цели, которая будет подвергнута фаззингу:
  
  • source-based у нас есть исходники проекта
  • binary-based у нас нет исходников проекта
• по наличию обратной реакции от тестируемого приложения:
  
  • feedback driven есть обратная реакция
  • not feedback driven нет обратной реакции
• по операциям, которые будут совершаться над входными данными:
  
  • генерационные
  • мутационные
  • комбинированные

Стоит отметить, что часто binary-based фаззеры называют black-box, а source-based gray- или white-box. В данной статье нас в первую очередь интересует source-based фаззинг с обратной связью, поскольку мы строим DevSecOps для разработки собственного продукта или анализа opensource-проектов, а это значит, что исходный код для него у нас есть.

Фаззинг всё ещё популярен?

Кто-то может задаться вопросом: "Если фаззингу уже более 30 лет (согласно некоторым источникам и с учетом прообраза этого метода тестирования, и все 70), то почему только в последнее время он стал так популярен?".

В начале тысячелетия Microsoft в рамках описания создания Secure Development Lifecycle
выпустили несколько статей, посвящённых тематике фаззинга, но тогда речь в основном шла о black-box-фаззинге. Однако в 2013 году фаззинг получил вторую жизнь, благодаря созданию feedback-driven fuzzing, который позволил достичь новых высот в этой сфере. Важную роль также сыграло появление простых и понятных инструментов, о которых мы расскажем далее.

Feedback-driven fuzzing это вид фаззинга, при котором фаззер изменяет входные данные так, чтобы их обработка затрагивала как можно больше участков кода программы. Работа таких фаззеров возможна, благодаря их способности реагировать на отклик (feedback) программы. Обычно таким откликом является покрытие кода. Метрики покрытия кода отслеживают суммарное количество выполненных строк кода, базовых блоков, количество сделанных условных переходов. Задача фаззера генерировать данные, которые приводят к увеличению покрытия кода.

Одним из наиболее популярных feedback-driven фаззеров является American Fuzzy Lop от Michael Zalewski. AFL был создан в 2013 году и стал главным двигателем прогресса в современном фаззинге.

Про AFL было уже несколько статей на Хабре, но повторимся, как он работает:

• в исполняемый файл добавляется инструментация для сбора информации о покрытии кода. Информация будет сохраняться в shared bitmap;
• AFL запускает программу и доходит до функции, которую нужно профаззить. Здесь он сохраняет своё состояние через системный вызов fork;
• далее происходит цикл "мутация данных запуск откат". При этом данные мутируются с учётом покрытия кода, получаемого от программы.

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

AFL оказался чрезвычайно эффективным при фаззинге различных программ. Это и сделало его знаменитым. Он был добавлен в Google Summer of Code (GSoC), а вокруг него сформировалось большое сообщество. Многочисленные энтузиасты предлагают собственные модификации AFL, которые по разным причинам не были приняты в основную ветку (например, существуют вариации для других ЯП). Об этом можно узнать подробнее в ещё одной нашей статье, посвященной различным вариациям AFL фаззера. Ещё хотелось бы заметить, что создатель AFL отошёл от дел и до недавнего времени проект почти не обновлялся, из-за чего многие стали использовать его активно поддерживаемый форк AFL++.

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

В итоге так и случилось. В 2015 году появился libFuzzer один из подпроектов LLVM. LibFuzzer позволяет реализовать feedback-driven in-memory фаззинг и имеет все преимущества, характерные для средств фаззинга исходного кода:

• позволяет создавать отдельные фаззеры для каждой функции из рабочего проекта;
• использует санитайзеры;
• может быть интегрирован в проект через toolchain.

Статический анализ

Прежде чем обратиться непосредственно к Continuous Fuzzing, скажем пару слов об анализаторах кода и фаззерах. Для тех, кто думает, нужно ли это всё, если те или иные анализаторы кода уже используются в процессе разработки.

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

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

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

На эту тему есть отличная статья How to Prevent the next Heartbleed, в которой автор сравнил эти подходы для улучшения качества openssl на примере нашумевшей уязвимости heartbleed. И именно подход, объединяющий анализ кода и фаззинг, помог выявить проблему с heartbleed. А обычное покрытие кода тестами, пусть и 100% по всем веткам разработки, оказалось не столь эффективным.

Непрерывный фаззинг в непрерывной разработке

Что же такое Continuous Fuzzing? Continuous fuzzing это подход к организации процесса. Иными словами, его эффективность будет зависеть от правильности организации процесса разработки в вашей компании. Все инструменты для организации такого процесса уже давно созданы осталось лишь правильно встроить их в свою систему.

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

Крупные компании уже не первый год настраивают у себя процесс фаззинга и развивают используемые инструменты. Этот подход уже множество раз доказал свою эффективность. Одна только статистика от Google ошеломляет числом найденных за время ее работы уязвимостей. По данным на 2019-й год, за все время существования ClusterFuzz было обнаружено около 16000 ошибок в Chrome и 11000 ошибок в более чем 160 популярных проектах с открытым исходным кодом.

Для организации фаззинга большие компании используют разный инструментарий. Выбор инструментов зависит от того, какие цели преследуются фаззингом, а также насколько безболезненно возможно внедрить этот инструментарий в уже существующий процесс разработки. В основе ClusterFuzz от Google лежат LibFuzzer, AFL и HonggFuzz (создан на базе LibFuzzera). Компания Microsoft недавно сделала публичным свой проект Springfield, превратив его в полноценный SaaS. Mozilla, помимо уже упомянутых фаззеров, разработала свой фреймворк для быстрого построения фаззеров (Grizzly) и дашборд для агрегации результатов фаззинга. Github не отстает. Так, он интегрировал ossfuzz в свою систему.

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

Поэтому, чтобы начать строить процесс Continuous Fuzzing у себя, необязательно быть крупной компанией, как тот же Google. Для этого не нужно крупных кластеров или мейнфреймов стартовые требования для внедрения Continuous Fuzzing минимальны. Речь о них пойдёт ниже, так как мы в своих проектах чаще используем значительно меньшие мощности и при этом успешно находим уязвимости.

Этапы интеграции фаззинга в проект

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

Выбор инструментов для организации фаззинга

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

• Составление поверхности атаки (Attack Surface)
  
  • ПО, в котором удобнее проводить аудит кода (Пример: Sourcetrail)
  • ПО для построения MindMap-схем (Пример: Xmind)
• Фаззинг
  
  • AFL (форк AFL++)
  • LibFuzzer (HonggFuzz)
  • KLEE*
• Санитайзеры (Sanitizers)

Для составления поверхности атаки необходимо ПО для аудита кода. Например, это может быть sourcetrail, understand, или подойдёт какая-нибудь популярная IDE. Лучше, чтобы ПО для инспекции кода имело возможность автоматического "рисования" блок-схем. Если у разработчиков уже есть готовые блок-схемы для программ из их проекта, то это значительно облегчит процесс. Если же нет, то искренне соболезнуем. Далее из составленной блок-схемы необходимо извлечь те куски, где тем или иным способом могут попасть на вход данные из недоверенных источников. Так и определяется поверхность атаки. На практике весьма удобно оформлять поверхность атаки в виде майндмап. Поверхность атаки служит не только для составления метрик "безопасности" (code coverage), а также, можно сказать, выступает чеклистом для написания фаззеров.

Об AFL и libFuzzer мы уже рассказали ранее, а практическое применение рассмотрим дальше, поэтому не будем на них останавливаться подробно. Можно считать их стандартом индустрии на данный момент. KLEE не совсем фаззер, хотя в некотором роде его можно использовать и так. Для описания процесса работы KLEE потребуется отдельная статья (на Хабре можно найти несколько, но KLEE за это время сильно обновился). Если же кто-то хочет углубиться в тему SMT, то в одной из прошлых статей мы опубликовали список материалов, который может помочь в этом. Если вкратце, то KLEE представляет собой символьную виртуальную машину, где параллельно выполняются символьные процессы и где каждый процесс представляет собой один из путей в исследуемой программе. Для каждого уникального пройденного пути KLEE сохраняет набор входных данных, необходимых для прохождения по этому пути. Это помогает улучшить эффективность фаззинга с помощью увеличения покрытия, а следовательно он прекрасно работает в паре с самими фаззерами.

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

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

Мы не зря начали наш список инструментов с тех, что помогают составить Attack Surface. В презентации для FuzzCon, посвящённой 25-летию фаззинга, была представлена следующая схема:

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

Определение Attack Surface

Что же стоит за словосочетанием "attack surface" ("поверхность атаки")? Возможно, вы уже знаете официальное значение, так как оно так прочно обосновалось в глоссарии, что даже удостоилось отдельной страницы в словаре хакерских терминов журнала Wired. Однако повторимся: если говорить по простому, это "возможность получения некорректных данных из недоверенных источников".

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

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

• файлы различные парсеры (XML, JSON), мультимедиакодеки (аудио, видео, графика);
• сеть сетевые протоколы (HTTP, SMTP), криптография (SSL/TLS), браузеры (Firefox, Chrome) и архиваторы файлов (ZIP, TAR).

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

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

В зависимости от структуры проекта количество нод может быть даже меньше, но в данном случае мы имеем следующее разделение:

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

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

Анализ целей для фаззинга

Цель для фаззинга (fuzz target) это функция, которая принимает на вход данные и обрабатывает их с использованием тестируемого API. Иными словами, это то, что нам необходимо фаззить.

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

1. Аргументы функции, через которые передаются данные для обработки. Нужен сам буфер для данных и его длина, если её возможно определить.
2. Тип передаваемых данных. Например, документ html, картинка png, zip-архив. От этого зависит то, как будут генерироваться и мутироваться поступающие на вход данные.
3. Список ресурсов (память, объекты, глобальные переменные), которые должны быть инициализированы перед вызовом целевой функции.
4. Если мы фаззим внутренние функции компонентов, а не API, то понадобится составить список ограничений, которые накладываются на данные кодом, выполненным ранее. Бывает так, что проверка данных происходит в несколько этапов это нам тоже следует учитывать.

Анализ opensource-проекта с использованием sourcetrail

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

Подбор входных данных

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

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

При создании набора seeds нужно учитывать, что:

• Его элементы должны влиять на покрытие кода программы. Чем выше покрытие, тем меньше неисследованных мест остаётся в программе.
• Размер его элементов не должен быть большим, иначе это повлияет на скорость фаззинга. Ведь чем больше длина входных данных, тем дольше функция будет их обрабатывать и меньше запусков программы сможет сделать фаззер за единицу времени.
• Кейсы в сидах должны быть функционально различными. Сильно похожие данные будут тормозить процесс фаззинга, поскольку фаззер часто будет попадать в места, которые уже были им исследованы. Перед запуском фаззера лучше провести минимизацию данных и убрать всё лишнее.

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

Сиды очень сильно влияют на эффективность фаззинга. Этап подбора входных данных также нельзя игнорировать. Однако современные фаззеры порой бывают настолько хороши, что могут буквально из ничего сгенерировать хороший корпус. Пример такого корпуса, сгенерированного фаззером AFL, показан на рисунке выше. Более подробно этот процесс автор AFL Michal Zalewski описал в своём блоге. Советуем почитать.

Написание фаззеров

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

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

#include "MyAPI.h"extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {  MyAPI_ProcessInput(Data, Size);  return 0;}

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

<!--INFO: Seed: 2240819152INFO: Loaded 1 modules   (6 inline 8-bit counters): 6 [0x565e90, 0x565e96), INFO: Loaded 1 PC tables (6 PCs): 6 [0x541908,0x541968), INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytesINFO: A corpus is not provided, starting from an empty corpus#2  INITED cov: 3 ft: 4 corp: 1/1b lim: 4 exec/s: 0 rss: 35Mb===================================================================29562==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff2fba1ba0 at pc 0x0000004dda61 bp 0x7fff2fba1b30 sp 0x7fff2fba12d0WRITE of size 65 at 0x7fff2fba1ba0 thread T0    #0 0x4dda60 in strcpy (/home/user/Documents/tmp/main+0x4dda60)    #1 0x52540f in MyAPI_ProcessInput(char const*) (/home/user/Documents/tmp/main+0x52540f)    #2 0x52561e in LLVMFuzzerTestOneInput (/home/user/Documents/tmp/main+0x52561e)    #3 0x42fe0a in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/user/Documents/tmp/main+0x42fe0a)    #4 0x42f3a5 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/user/Documents/tmp/main+0x42f3a5)    #5 0x4310ee in fuzzer::Fuzzer::MutateAndTestOne() (/home/user/Documents/tmp/main+0x4310ee)    #6 0x431dc5 in fuzzer::Fuzzer::Loop(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, fuzzer::fuzzer_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/home/user/Documents/tmp/main+0x431dc5)    #7 0x427df0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/user/Documents/tmp/main+0x427df0)    #8 0x44b402 in main (/home/user/Documents/tmp/main+0x44b402)    #9 0x7f7ee294409a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)    #10 0x421909 in _start (/home/user/Documents/tmp/main+0x421909)Address 0x7fff2fba1ba0 is located in stack of thread T0 at offset 96 in frame    #0 0x5252ef in MyAPI_ProcessInput(char const*) (/home/user/Documents/tmp/main+0x5252ef)  This frame has 1 object(s):    [32, 96) 'buf' <== Memory access at offset 96 overflows this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork      (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/user/Documents/tmp/main+0x4dda60) in strcpyShadow bytes around the buggy address:  0x100065f6c320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c360: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00=>0x100065f6c370: 00 00 00 00[f3]f3 f3 f3 00 00 00 00 00 00 00 00  0x100065f6c380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c390: f1 f1 f1 f1 00 00 00 00 f2 f2 f2 f2 f8 f3 f3 f3  0x100065f6c3a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c3b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x100065f6c3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes):  Addressable:           00  Partially addressable: 01 02 03 04 05 06 07   Heap left redzone:       fa  Freed heap region:       fd  Stack left redzone:      f1  Stack mid redzone:       f2  Stack right redzone:     f3  Stack after return:      f5  Stack use after scope:   f8  Global redzone:          f9  Global init order:       f6  Poisoned by user:        f7  Container overflow:      fc  Array cookie:            ac  Intra object redzone:    bb  ASan internal:           fe  Left alloca redzone:     ca  Right alloca redzone:    cb  Shadow gap:              cc==29562==ABORTINGMS: 1 InsertRepeatedBytes-; base unit: adc83b19e793491b1c6ea0fd8b46cd9f32e592fc0xa,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,\x0a\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xffartifact_prefix='./'; Test unit written to ./crash-76387a0aaeb6a1d2b6b6f095ab49c927c00243e5-->

Сборка и её особенности на разных платформах

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

Платформа

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

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

Компилятор

Думая о том, каким компилятором собирать фаззеры, мы всегда вспоминаем, что libfuzzer это подпроект LLVM, а в AFL предусмотрен llvm_mode, про который в его readme написано:

Настоящая инструментация на этапе компиляции, а не просто грубые изменения на уровне ассемблера.

Возможность добавления инструментации во время компиляции и поддержка LLVM самыми популярными фаззерами делает выбор компилятора очевидным для сборки лучше всего использовать clang. Конечно, нам попадались проекты, которые не были ориентированы на сборку этим компилятором, но нас это никогда не останавливало.

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

Касательно системы сборки, отметим, что это, скорее, вопрос вкуса и, возможно, привычки использования того или иного инструмента. Конкретно наш опыт показывает, что использование cmake позволяет в разы ускорить внедрение фаззинга в проект:

# Step 1add_custom_target(${FUZZ_TARGET_NAME})# Step 2function(add_fuzzer name path)    add_executable(${name} ${SRC} ${path})    target_compile_options(...)    set_target_properties(...)    add_dependencies(${FUZZ_TARGET_NAME} ${name})# Step 3set(fuzzers my_ideal_fuzzer1 my_ideal_fuzzer2 ...)foreach(fuzzer ${fuzzers})    add_fuzzer(${fuzzer} ${FUZZERS_DIR})endforeach()

Кратко интеграцию фаззеров в сборку проекта на cmake можно описать в трех шагах на примере нашего недавнего проекта:

• Создаём цель ${FUZZ_TARGET_NAME}, к которой в зависимости будем добавлять фаззеры.
• Пишем простую функцию, которая принимает на вход название фаззера и путь к его исходному коду. Реализация этой функции сводится к нескольким вызовам других cmake-функций. Сначала необходимо указать список исходников для сборки компонента который мы будем фаззить. Он хранится в переменной ${SRC}. Потом идут два вызова для установки опций компилятора и компоновщика. Последним вызовом добавляем новый исполняемый файл в качестве зависимости к цели, созданной ранее.
• Остаётся дописать простой цикл который поочередно добавит все фаззеры к созданной ранее цели.

Другой пример система сборки autotools. Она является достаточно старой и не такой удобной, как cmake. Однако это не помешает внедрению фаззинга в проект. Например, здесь показан пример интеграции фаззинга в WebRTC сервер janus-gateway. Сам скрипт занимает где-то 100 строчек на bash. Конечно, это не так много, однако, как только проект начнёт меняться, эти скрипты тоже необходимо будет поддерживать в актуальном состоянии. На это может потребоваться дополнительное время.

Фаззинг в облаке

Наконец, мы добрались до финальной главы непосредственно про организацию continuous fuzzing. Сначала мы посмотрим, как с этой задачей справились в Google, а затем что получилось у нас.

Фаззинг-ферма от Google

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

Схема сontinious fuzzing от google

Пробежимся по элементам схемы:

• Developer команда разработчиков проекта
• Upstream project репозиторий с проектом
• Oss-fuzz вспомогательный репозиторий для интеграции continuous fuzzing. Хранит build-конфиги фаззеров
• Builder Сборщик фаззеров. Его задача скачивать исходники фаззеров из репозитория с проектом, подхватывать build-конфиги из oss-fuzz и производить сборку фаззеров. После сборки builder закачивает в хранилку (GCS bucket) файлы, необходимые для запуска фаззера
• Clusterfuzz масштабируемая система для управления процессом фаззинга. Отвечает за планирование запусков фаззеров, обработку полученных от них данных, сбор статистики и многое другое. Пополняет свою коллекцию фаззеров из хранилки.
• Issue tracker система отслеживания задач: youtrack, jira и подобные им программы. Сюда приходят отчёты о найденных уязвимостях

А теперь рассмотрим сам процесс интеграции. Начнём с того, что у команды разработчиков должен иметься репозиторий с кодом проекта. Здесь же должны храниться исходные коды фаззеров. Для интеграции необходимо подготовить build-конфиги для сборки и запуска фаззеров в инфраструктуре Google. Готовые build-конфиги нужно добавить в репозиторий oss-fuzz через пулл-реквест. После принятия пулл-реквеста можно радоваться: фаззеры будут автоматически собраны и запущены в Clusterfuzz. С каждым новым коммитом в oss-fuzz будут подхватываться фаззеры из репозитория с проектом. Если вдруг нашлась уязвимость, то уведомление придёт к разработчикам в issue tracker. Разработчики своевременно исправляют баги и все остаются довольными.

Почему решение от Google подходит не всем?

Отметим, что ферма для фаззинга от Google это круто. Впрочем, и в этой бочке мёда есть ложка дёгтя. Несмотря на то, что Clusterfuzz имеет открытый код, он жёстко привязан к облачным сервисам Google.

Это означает, что:

• Для закрытых проектов такая система не подходит.
• Изменить что-то под себя вряд ли получится.

Поэтому мы сделали свою фаззинг-ферму. Собственное решение для continuous fuzzing позволяет нам:

• Снять ограничения на используемую инфраструктуру. Ферму можно запускать как в публичном облаке, так и у себя локально.
• Полностью контролировать работу фермы: мониторинг, конфигурирование, добавление собственных фич и т.д.
• Осуществлять фаззинг проприетарного программного обеспечения.

Схема нашей фермы похожа на схему от Google, однако она проще. Основная логика сосредоточена в компоненте FuzzFarm. Он выполняет те же задачи, что и Clusterfuzz. Ферма использует только наши внутренние ресурсы и может работать без доступа к интернету.

Схема работы нашей фаззинг-фермы

Интерфейс пользователя мы сделали простым и минималистичным. При этом он покрывает все необходимые задачи в continuous fuzzing.

Интерфейс пользователя нашей фаззинг-фермы

Что получаем в итоге?

В итоге мы имеем следующие преимущества использования continuous fuzzing:

• Для разработчика это более быстрое обнаружение ошибок и готовые данные для юнит-тестов. В баг-трекер приходит уведомление, разработчик устраняет ошибку и быстро делает тест с использованием полученного от фермы кейса.
• Ещё один шаг к оптимизации заключается в автоматическом создании юнит-тестов из полученных результатов фаззинга. Тестировщик будет рад :)
• Наконец, можно добавить автоматический анализ крэшей. Для безопасника будет намного лучше, если система за него будет оценивать критичность найденных уязвимостей и предоставлять ему красивый отчёт. Более того, запуск фаззеров и обработка их результатов производятся автоматически. У безопасника появится время попить кофе.

Заключение

Тема фаззинга на сегодняшний день уже вышла далеко за пределы просто одного из видов тестирования. Это целое направление, объединившее единомышленников в коммьюнити. Уже проходят целые конференции и митапы, посвященные только фаззингу. Это большое и разноплановое направление со множеством перспектив развития, к примеру, Structure-Aware фаззинг, о котором мы постараемся рассказать позже. Поскольку, как вы могли заметить, развитие как отдельных инструментов, так и в целом направления не стоит на месте, существует возможность улучшать показатели по всем параметрам: скорости, качества, трудозатратам и т.п.

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

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

• Дмитрий Евдокимов d1g1
• Никита Кныжов presler

Соавтор статьи: Павел Князев poulix

Материалы

• 25 Years of Fuzzing
• Фаззинг важный этап безопасной разработки
• Зоопарк AFL фазеров
• Фаззинг глазами программиста
• The Art, Science, and Engineering of Fuzzing: A Survey
• Pulling JPEG out of thin airl
• AFL dictionaries
• Building Secure and Reliable Systems
• Fuzzing for Software Security Testing and Quality Assurance
• Recent Papers Related To Fuzzing

• отдел анализа защищённости 2019
• отдел исследований 2019
• результаты Summ3r of h4ck 2018

Введение

• Разработка для Ghidra
• Advanced Server Side
• Про Libfuzzer
• Куда жать после RCE?
• Pentest Android
• Про taint анализ
• Kubernetes: From zero to hero и т.д.

1. Почему решили стажироваться именно в Digital Security? Чем привлекла вас компания?
2. Понравилась ли стажировка? Что особенно запомнилось? Насколько реальность совпала с вашими ожиданиями?
3. Расскажите о своей задаче/задачах.
4. Показались ли интересными задачи, над которыми вы работали в процессе стажировки? Было ли что-то, чем вы хотели заняться, но не удалось?
5. Готовы ли вернуться в компанию на стажировку или на работу?

Даниил Гавшин, тема Разработка плагина для Ghidra

Никита Челноков, тема Автоматизация поиска code reuse гаджетов для обхода CFI

Новосельцева Алёна, тема Символьное исполнение в Ghidra

Олег Мошков, тема Binary Lifting Fuzzing

Георгий Геннадьев, тема Apple BLE protocols

Заключение

С удовольствием и даже гордостью публикуем эту статью. Во-первых, потому что автор участница нашей программы Summ3r of h4ck, Nalen98. А во-вторых, потому что это исследовательская работа с продолжением, что вдвойне интереснее. Ссылка на первую часть.

Добрый день!

Прошлогодняя стажировка в Digital Security не оставила меня равнодушной к компании и новым исследованиям, так что в этом году я взялась поработать над проектом так же охотно. Темой летней стажировки Summer of Hack 2020 для меня стала Символьное исполнение в Ghidra. Нужно было изучить существующие движки символьного исполнения, выбрать один из них и реализовать его в интерфейсе Ghidra. Казалось бы, зачем, ведь в основном движки представляют собой самостоятельные решения? Этот вопрос будет возникать до тех пор, пока не попробовать то, что автоматизирует действия и сделает их наглядными. Это и стало целью разработки.

Статья в какой-то степени является еще и продолжением статьи моего наставника, Андрея Акимова, о решении Kaos Toy Project с Triton. Только сейчас нам не придется писать ни строчки кода решить крякми можно будет практически двумя кликами.

Итак, начнем по порядку.

Пара слов о символьном исполнении

Символьное исполнение представляет собой технику анализа программного обеспечения, которая позволяет найти все наборы входных данных, способствующие выполнению каждого из его возможных путей. Если говорить обобщенно, то во время символьного исполнения производится замена переменных/регистров их символьными значениями. Зависимость между переменной и ее символьным значением называется формулой. Единичные формулы объединяются в более сложные и подаются на вход SMT-решателю. Он, в свою очередь, ищет решение к логической формуле и выдает результат утверждение удовлетворяется (satisfied) или утверждение не удовлетворяется (unsatisfied). Во время символьного исполнения ветки будут расходиться, и произойдет создание форков и новых ограничений на символьные значения. Экспоненциальный рост числа форков является одной из главных проблем в этой области, поскольку для вычислений растущего числа веток требуются большие мощности.

Если говорить об общей классификации движков символьного исполнения, то среди них выделяют статические символьные движки (SSE, emulated) и динамические символьные движки (DSE, concolic). Достоинством статических движков является поддержка эмуляции как всей программы, так и конкретной ее части. И поскольку не происходит непосредственного запуска на CPU, а лишь эмулируются инструкции, открываются возможности для анализа разнообразных архитектур. Однако, страдает масштабируемость, и могут возникнуть определенные трудности со входами в сторонние библиотеки.

DSE, в отличие от SSE, исполняет каждую ветку отдельно, и по своей сути он быстрее, поскольку символизирует не все подряд, а только входные данные пользователя (источник книга "Practical Binary Analysis" by Dennis Andriesse".

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

Выбор символьного движка

Первым наставники посоветовали изучить Triton. С ним хорошо получилось изучить теорию символьного исполнения. Движок может работать как в режиме SSE, так и в режиме DSE. Однако у него ограниченное количество поддерживаемых архитектур (x86, x86-64, ARM32, Arch64), и мне сложно было представить, каким образом можно реализовать его API в контексте интерфейса Ghidr-ы. Так что Triton пришлось отложить и ресерчить дальше.

Следующим подопытным стал KLEE. Он, несомненно, является самым мощным движком символьного исполнения, с его помощью можно работать с по-настоящему серьезными проектами и исследованиями. В контексте реализации архитектуры плагина здесь основной проблемой выступила генерация llvm-биткода. А все потому, что для полноценной работы KLEE необходимо подавать скомпилированные clang-ом в llvm-биткод (.bc) файлы исходников. Были идеи по передачи бинаря llvm-лифтеру (их ассортимент можно увидеть тут), однако ни один из этих вариантов не сработал, и KLEE выдавал ошибки. Говоря о наработках в области трансляции Pcode в llvm, есть лишь один Ghidra-to-LLVM. В рамках ресерча пришлось протестировать и его. Как оказалось, он не работает с 32-битными бинарями, и если и удавалось получить результат в виде .ll-файла, то после обработки llvm-ассемблером llvm-as и получения llvm-биткода KLEE все равно не хотел работать с подобным самопалом и выдавал ошибки. Так что KLEE также пришлось оставить, несмотря на его широкие возможности по символьному исполнению.

Наставники также посоветовали изучить движок S2E. Он расширяет возможности QEMU по трансляции бинарных инструкций в TCG и также транслирует сам TCG в LLVM. Это была заманчивая идея, однако для работы с ним требуется Python3. И, как известно, Ghidra использует старый Jython 2.x, что, казалось бы, полностью перекрывает поток возможностей по интеграции современных инструментов в Ghidr-у. Движок, который был выбран в итоге, тоже работает только с Python3, но в случае с ним возможно было придумать обходной вариант через системный интерпретатор. А поскольку S2E работает как отдельный инструмент, его использование из Ghidr-ы не представляется возможным.

На момент написания статьи вышел еще один движок символьного исполнения SymCC. Точнее, правильно его назвать оберткой компилятора для C-кода. Представьте: у вас на руках исходники, вы компилируете исполняемый файл, как в случае с KLEE и clang-ом, только здесь с SymCC. Компилятор интегрирует необходимый для символьного исполнения код и библиотеки в новоиспеченный исполняемый файл. После запуска получаем директорию с кейсами, сгенерированными во время выполнения. Все классно, но привязать такое к Ghidr-е невозможно, так как у нас на руках не исходники проекта, а результат дизассемблирования и декомпиляции.

Финальным выбором стал angr. Он популярен, у него доступный и подробно задокументированный API, и интегрировать данный движок было действительно реально. Конечно, как уже отмечалось, без Python3 никуда, в Ghidra его поддержка отсутствует, но в случае с angr-ом мне показалось возможным написать универсальный скрипт, который смог бы запускаться на системном интерпретаторе, решать заданный бинарь и передавать результат обратно в Ghidr-у. Вот такой был план.

Сердито. Костыльно. Канонично.

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

Если изучить принцип работы декомпилятора в Ghidra и его взаимодействие с GUI, то можно понять, что основе лежит схожий костыльный алгоритм. Дело в том, что Ghidra работает с декомпилятором через stdin и stdout потоки, используя классы DecompileProcess и DecompInterface. Так что архитектуру плагина можно считать вполне каноничной в контексте Ghidra.

На написание логики скрипта не ушло много времени. Он, по сути, собирает в себя базовые возможности angr-a по символьному исполнению для решения ctf-тасков. На графический интерфейс пришлось потратить львиную долю времени, и его разработку не могу назвать захватывающей. Как и Ghidra, графический интерфейс плагина написан на Java, в роли IDE по традиции выступил Eclipse.

Для GUI плагина было создано 4 файла:

• AngryGhidraPlugin.java в файле указывается основная информация о плагине и происходит его инициализация.
• AngryGhidraProvider.java самый объемный файл, который инициализирует компоненты графического интерфейса основного окна плагина; здесь прописана логика создания файла конфигурации для скрипта, происходят запуск скрипта и чтение результатов, их передача в интерфейс.
• AngryGhidraPopupMenu.java здесь прописаны дополнительные параметры контекстного меню окна дизассемблера Ghidr-ы. Благодаря этому файлу можно задавать необходимые адреса прямиком из окна дизассемблера, а также внедрять пропатченные байты памяти в контекст работы angr-а.
• HookCreation.java инициализирует окно создания хуков.

Итак, пара слов о функциональных возможностях плагина.

• Auto load libs определяет работу загрузчика необходимых библиотек для исполняемого файла. Пользователь определяет, нужна ему эта опция или нет.
• Find Address адрес, куда вы хотите попасть во время выполнения программы (например, на адрес вывода строки License key is validated!).
• Blank State адрес, с которого вы начинаете эмуляцию. Если не добавлять дополнительных параметров в дальнейшем, то по умолчанию все регистры и память обнулены. Удобно назначать на адресе точки входа или на адресе вызова функции проверки, если вы знаете ее расположение в коде и хотите ускорить процесс работы angr-a.
• Avoid addresses адрес/адреса, которые в ходе символьного исполнения нужно избежать. При их нахождении angr автоматически отметет соответствующие им ветки с меткой avoid и не пройдет дальше. Чем больше таких адресов указать, тем чаще angr будет отбрасывать ненужные ветки кода и найдет решение быстрее (если это решение существует).
• Arguments аргументы, поставляемые на вход программе (argv[1], argv[2] и т.д.). Иногда значение, которое необходимо сделать символьным, передается через аргумент(-ы) к программе.
• Hooks хуки позволяют перехватить указанные инструкции и внести определенные значения в регистры. Например, когда необходимо записать в регистры символьные вектора, это будет продемонстрировано в дальнейшем решении Kaos Toy Project.
• Store symbolic vector если необходимо создать символьный вектор в адресном пространстве определенной длины, а потом, например, поместить его в регистр. Если плагин найдет решение, он выведет содержимое созданного символьного вектора.
  
  • Write to memory иногда бывает необходимо, чтобы определенные участки памяти были заполнены конкретными значениями. Например, в случае Kaos Toy Project, это значение Installation ID, которое инициализируется по адресу 0x4093a8. Это поле окна плагина можно заполнить патчингом из Ghidr-ы, для этого необходимо пропатчить нужные вам байты, выделить их и открыть контекстное меню дизассемблера AngryGhidraPlugin -> Apply patched bytes.
• Registers те значения регистров, которые вы самостоятельно инициализируете при запуске эмуляции с заданного адреса. Здесь также можно создать и сохранить символьные вектора нужной длины.

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

Продолжаем хорошую традицию

Наконец, решим Kaos Toy Project плагином AngryGhidra.

Первое, что сделаем запустим toyproject.exe в любом отладчике и отследим, по какому адресу записываются байты Installation ID.

Взглянем на байты по адресу 0x4093a8, это и есть наш Installation ID.

Нужно учитывать тот факт, что отладчик в Ghidra отсутствует, а angr осуществляет эмуляцию бинаря (за это отвечают компоненты PyVEX и SimEngine). Это значит, что значение Installation ID инициализировано не будет, нам нужно сделать это самостоятельно. Наш ход патчинг байтов в Ghidra.

Найдем адрес 0x4093a8 и запатчим нулевые значения байтами Installation ID, выделим их и выберем в контекстном меню AngryGhidraPlugin -> ApplyPatchedBytes:

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

Строка Congratulations! Now write a keygen and tutorial! однозначно для нас искомая, так что адресом для поиска станет адрес помещения в стек этой строки для вызова окна с сообщением. Выберем адрес 0x40123b, для этого можно вписать его в поле Find Address или, открыв контекстное меню, выбрать AngryGhidraPlugin -> Set -> Find Address. Теперь адрес будет перекрашен в зеленый цвет.

Строка That is just wrong. Try harder! говорит о неверном введенном ключе, так что отметим адрес 0x401250 в качестве Avoid Address. Теперь он будет красным в окне дизассемблера.

Чтобы сократить время поиска решения будет удобно выбрать начальное состояние (Blank State) по адресу, где вызывается функция проверки введенного ключа. Это функция 0x4010ec. Выделим адрес вызова этой функции в качестве Blank State Address, и он перекрасится в голубой цвет.

С назначением адресов мы закончили:

Остался последний момент. Заглянем в функцию проверки ключа по адресу 0x4010ec и изучим, каким образом нам стоит передать две части ключа в плагин.

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

Можно заметить, что первоначально введенные две части ключа обрабатываются функцией по адресу 0x40109d:

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

Откроем окно AngryGhidraPlugin и создадим хук по адресу 0x4010ff, чтобы заполнить значения регистров EDX и EBX символьными векторами длиной по 4 байта.

Теперь все готово к запуску, жмем Run и получаем результат!

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

И проверяем:

Ключ подошел! И ни строчки кода! Плагин AngryGhidra сделал все за нас.

Большое спасибо компании Digital Security за интересную стажировку, которая прошла для меня в удаленном формате, наставникам Андрею (@e13fter) и Саше (@dura_lex), отдельная благодарность за поддержку Виктору Склярову и Борису Рютину!

Плагин на Github: AngryGhidra.

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

Если когда-то давно можно было обойтись простым разграничением доступа и шифрованием конфиденциальной информации, то сейчас так сразу и не разберешься, что именно использовать. К некоторым аббревиатурам (вроде IPS, DLP и WAF) уже многие привыкли. Однако копнешь чуть глубже откроется невиданный мир многофункциональных систем защиты и маркетинга. Разберемся, что же значат все эти модные аббревиатуры и что за ними скрывается.

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

Защита приложений

AST Application Security Testing

Инструменты анализа и тестирования приложений, которые позволяют не упустить из виду уязвимости, действующие на уровне ПО. Gartner выделяет четыре основных вида AST:

• Static AST (SAST) тестирование методом белого ящика. Позволяет находить уязвимости исходного кода на ранних этапах разработки.
• Dynamic AST (DAST) тестирование методом черного ящика. Помогает находить уязвимости и слабости безопасности в работающем приложении. Подобные инструменты моделируют заранее известный список внешних атак на приложение.
• Interactive AST (IAST) сочетает в себе некоторые из элементов двух предыдущих подходов. Тестирование происходит в режиме реального времени, пока приложение работает в среде контроля качества или тестовой среде. Проверяется в том числе и сам код, но уже после сборки.
• Mobile AST выявляет и анализирует уязвимости мобильных приложений во время разработки и после нее.

SCA Software Composition Analysis

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

WAF Web Application Firewall

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

RASP Runtime Application Self-Protection

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

• диагностика (только оповещение об угрозах);
• самозащита (запрет подозрительных инструкций).

Защита данных

DAP Database audit and protection

Системы данного класса обеспечивают безопасность систем управления реляционными базами данных (СУБД). DAP это развитие базовых возможностей мониторинга инструментов database activity monitoring (DAM), но при этом они имеют такие дополнительные функции, как:

• обнаружение и классификация данных;
• управление угрозами и уязвимостями;
• анализ на уровне приложений;
• предотвращение вторжений;
• блокировка активности;
• анализ управления идентификацией и доступом.

DLP Data Leak Prevention или Data Loss Prevention

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

DCAP Data-Centric Audit and Protection

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

CASB Cloud Access Security Broker

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

SDS Software-Defined Storage

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

Защита конечных точек

EPP Endpoint Protection Platform

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

EDR Endpoint Detection and Response

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

• STAP Specialized Threat Analysis and Protection
• EVC Endpoint Visibility & Control

Контроль доступа

IAM Identity and access management

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

IGA Identity Governance and Administration

Развитие технологий Identity Management (IdM) и IAM привело к возникновению нового класса решений для идентификации и управления доступом IGA. Основное отличие между ними заключается в том, что IGA предлагают более гибкие настройки и процессы согласования доступа к ресурсам, а также имеют системы разделения ответственности для критичных бизнес-операций и системы оценки рисков при настройке ролей.

PAM Privileged Access Management

Данный класс решений призван затруднить проникновение в сеть и получение доступа к привилегированным учетным записям, а также усилить защиту привилегированных групп пользователей. Помимо этого, PAM также расширяет возможности мониторинга, видимости и детализированного управления привилегированными учетными записями. Заметим, что для обозначения систем контроля привилегированных пользователей, встречаются и другие наименования данного класса решений, например: Privileged User Management (PUM), Privileged Identity Management (PIM), Privileged Password Management (PPM), Privileged Account Security (PAS).

SDP Software Defined Perimeter

Программно-определяемый периметр, также известный как Zero Trust Network Access (ZTNA). Это новый подход к защите удаленного доступа к сетевым службам, приложениям и системам как локально, так и в облаке. SDP распределяет доступ к внутренним приложениям на основе личности пользователя и с доверием, которое адаптируется под текущий контекст. Помимо прочего, SDP делает инфраструктуру приложений невидимой для интернета, что позволяет избежать сетевых атак.

Защита сети

SWG Secure Web Gateways

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

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

NGFW Next-Generation Firewalls

Объединяют многие возможности традиционных межсетевых экранов, включая:

• фильтрацию пакетов;
• преобразование сетевых адресов (NAT);
• преобразование адресов портов (PAT);
• блокировку URL-адресов;
• VPN с функциональностью quality of service (QoS);
  и другие функции, которых нет в традиционных брандмауэрах: предотвращение вторжений (IPS), проверка SSL и SSH, deep-packet inspection, обнаружение вредоносных программ на основе репутации и осведомленность о приложениях.

NTA Network Traffic Analysis

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

IDS Intrusion Detection Systems

IDS анализируют и отслеживают сетевой трафик на предмет признаков, указывающих на то, что злоумышленники используют известную киберугрозу для проникновения или кражи данных из вашей сети. Системы IDS сравнивают текущую сетевую активность с базой данных известных угроз, чтобы обнаружить такие типы поведения, как: нарушения политики безопасности, вредоносное ПО и сканеры портов.
Разновидности IDS: Network-, Protocol-, Application Protocol- и Host-based.

IPS Intrusion Prevention System

IPS активно запрещает сетевой трафик на основе профиля безопасности, если этот пакет представляет известную угрозу безопасности (логическое продолжение IDS, часто реализуется система IDS/IPS).
Разновидности IPS: Network-, Wireless- и Host-based.

IDPS Intrusion Detection and Prevention Systems

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

• сигнатур;
• обнаружения аномалий протокола;
• поведенческого мониторинга;
• эвристики;
• интеграции advanced threat defense (ATD);
• threat intelligence (TI).

UTM Unified threat management

Модификация файрвола, объединяющая в себе множество функций, связанных с обеспечением безопасности, например, IDS/IPS, VPN, антивирус.

Анализ внутри сети

NBAD Network behavior anomaly detection

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

BDS Breach Detection System

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

UEBA User and Entity Behavior Analytics

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

С привлечением людей

SIEM Security Information and Event Management

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

SOC Security Operations Center

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

SOAR Security Operations, Analytics and Reporting / Security Orchestration, Automation and Response

По сути это более развитая SIEM, т.е. система сбора, анализа и реагирования на инциденты безопасности. Решения SOAR, позволяющие более автоматизировано определять приоритеты и обрабатывать события и инциденты безопасности, развивались для того, чтобы помочь аналитикам SOC повысить их собственную эффективность.

IRS Incident Response Platforms

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

TIP Threat Intelligence Platform

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

MDR Managed Detection and Response

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

Ловушки (имитация системы)

DDP Distributed Deception Platforms

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

Имитация нападения

BAS Breach and Attack Simulation

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

Расследование

NFT network forensic tools

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

Вместо заключения

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

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

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

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

Начнем конечно с определения того, какие данные считать конфиденциальными. OWASP причисляет к ним пароли, номера кредитных карт, медицинские записи, личную информацию и бизнес-секреты. Помимо этого, за списком чувствительных данных следует обращаться к законам и отраслевым постановлениям тех регионов, откуда к вам могут прийти пользователи. Если речь о России, нужно заглянуть в Федеральный закон РФ 152-ФЗ О персональных данных, а в случае европейских пользователей, например, в Общий регламент ЕС по защите данных (GDPR) или в закон Великобритании о защите данных (DPA), которые регулируют использование персональных данных.

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

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

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

Время удивительных историй

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

Ищем старые версии

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

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

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

Смотрим шире на процессы

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

Лишнего не болтаем

Аналогичная проблема несогласованности процессов была найдена в функциональности сброса забытого пароля. После ввода логина (в данном случае адреса электронной почты) сайт уточнял, куда отправить пароль: на почту или на привязанный номер телефона. Если был выбран второй вариант, то на странице появлялось оповещение с наполовину скрытым номером телефона. А вот в HTTP-ответе от сервера номер отображался целиком. Так можно было собрать целый список из пар почта-номер телефона. Раскрытие-с.

Кстати, к разговору о функционале сброса пароля. Если при реализации функционала регистрации только единицы забывают использовать общее предложение неправильный логин или пароль, то при восстановлении пароля информацию о наличии того или иного логина в системе раскрывают гораздо чаще. Конкретные ответы от сервера, подтверждающие наличие записи в системе, позволяют составить список пользователей и порой успешно использовать его в дальнейших атаках (фишинг, password spraying и т.д.). Но не только явные сообщения раскрывают информацию, вывод можно сделать по таймингу (например, таким страдали старые версии OWA веб-клиента для доступа к Microsoft Exchange) или телу ответа.

Не храним лишнее

Существует хорошая практика хранить только то, что действительно необходимо. Так, на неком сайте каждый раз, когда система отправляла email пользователю (например, при регистрации, анонсе мероприятий и т.п.), все сообщения записывались в лог. Этот лог на сайте был доступен, внутри хранились непосредственно текст сообщений, фамилия и имя пользователей, а также их почта. Интересно, что многие утилиты для поиска директорий данный файл не находили. Так как его размер был огромен (несколько ГБ), утилиты просто не могли дождаться, пока он скачается, и пропускали его. Но, перепробовав несколько вариантов утилит, аудиторы в конце концов добились своего.

В данной истории, помимо того, что в лог записывались избыточные данные, так еще и доступ к ним никак не был ограничен. Это, как ни парадоксально, далеко не редкий случай. Здесь стоит снова вспомнить ряд громких случаев (например, раз, два, три), когда утекали довольно серьезные объемы данных с Elasticsearch серверов.

Ну, не будем о грустном. Просто не забывайте правильно использовать авторизацию там, где она необходима.

Дружим с логикой

И все же самой распространенной болячкой, позволяющей утекать пользовательским данным, являются небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR). В подтверждение расскажем две неклассические истории.

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

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

В другом случае IDOR был найден при просмотре транзакций. В HTTP-запросе передавались три параметра:

POST /api/get_transactions HTTP/1.1Host: example.comGT|2315486|2315488|40117812222030001111

, где 2315486 идентификатор пользователя,
2315488 идентификатор карты,
40117812222030001111 номер счета.

На первый взгляд, перебрать 3 значения (34 цифры) не представляется возможным за обозримое время. Но, как выяснилось впоследствии, номер счета (40117812222030001111) в запросе можно было опустить: запрос все равно оставался валидным, как и ответ. Соответственно, оставалось только два числа для подбора идентификатор пользователя и идентификатор карты.

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

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

Еще раз всё проверим

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

Заключение

Мы уверены, что подобных, а порой и куда более зубодробительных историй в практике специалистов ИБ предостаточно, но не всегда получается ими поделиться с сообществом. Обычно такое можно услышать в приватной беседе за кружечкой чая. И все же, делиться подобными случаями (обезличенно, конечно) крайне полезная практика как для сообщества, так и для разработчиков. Поиск уязвимостей это своего рода искусство мыслить иначе. Давайте вдохновлять друг друга.

В этой статье мы расскажем о полезных плагинах для Burp Suite Professional инструмента для анализа веб-приложений. Плагинов много, и, чтобы помочь аудиторам сделать правильный выбор, мы составили список тех, которые сами чаще всего используем в работе.

Кратко о Burp Suite

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

Удобство Burp Suite заключается в том, что все утилиты и плагины, которые дополняют его, могут взаимодействовать друг с другом. В настройках браузера вы можете установить в качестве прокси Burp Suite (для сайтов, работающих по HTTPS, также будет нужно установить сгенерированный TLS-сертификат Burp). В этом случае все ваши действия в браузере, а именно отправленные запросы и полученные ответы, будут сохраняться в Burp Proxy. Кроме браузера, на десктопе можно попробовать перенаправить в Burp HTTP-трафик из мобильных приложений, да и вообще любой HTTP-трафик, будь то десктопное приложение или какое-нибудь IoT устройство. HTTP-запросы из истории Proxy можно пересылать в другие инструменты и работать с ними.

Например, вам нужно проверить можно ли устроить bruteforce-атаку на подбор OTP-кода. Для этого вам нужно перехватить запрос на проверку OTP...

и отправить этот запрос в инструмент Intruder.
После этого нам достаточно будет выделить место в HTTP-запросе, которое нужно атаковать, и настроить значения, которые будут применяться, в данном случае у нас перебор чисел от 0000 до 9999.

Либо можно воспользоваться инструментом Repeater для того, чтобы вручную выполнять какие-либо проверки, тесты или атаковать веб-приложение. Например, можно легко проэксплуатировать SQL-инъекцию в случае, если какие-нибудь иные инструменты вроде sqlmap не могут с ней справиться.

Этим инструментарий Burp Suite однако не ограничивается. Приведем список стандартных инструментов Burp Suite из коробки:

• Proxy прокси-сервер, позволяющий перехватывать весь HTTP- и WebSocket-трафик между браузером и веб-приложением, а также просматривать историю прошедших через него запросов. Кроме того, Proxy имеет ряд настроек, позволяющих перенаправлять трафик или модифицировать его на лету.
• Scanner инструмент для сканирования веб-приложения на уязвимости. С версии Burp 2.0 также включает crawler для сбора доступных страниц и endpoint в веб-приложении.
• Intruder инструмент для проведения автоматизированных атак и фаззинга веб-приложений.
• Repeater инструмент для ручного изменения и повторной отправки конкретных HTTP-запросов, а также для анализа ответов приложения.
• Sequencer инструмент для автоматизированного анализа энтропии в ответах от сервера. Это могут быть сессионные идентификаторы или токены. Представьте: у вас есть тысяча псевдослучайных токенов, и нужно узнать, есть ли закономерность в их генерации. В этом случае и пригодится Sequencer. Однако на практике этот инструмент бывает полезен очень редко.
• Infiltrator инструмент, который помогает проводить аудит приложений, добавляя в них хуки для потенциально уязвимых мест. Для его использования необходимо, чтобы разработчик установил генерируемый инструментом файл на машину, где запущено приложение. В работе инструмент применяется крайне редко.
• Clickbandit инструмент для генерации clickjacking атак. На практике пригождается редко.
• Decoder инструмент для кодирования и декодирования данных.
• Comparer работает почти как diff, поможет найти различия между двумя большими запросами.
• Collaborator внешний сервер, который позволяет проверить различные blind-вектора, когда нужен отстук на какой-то публично доступный IP-адрес в интернете.
• Extender волшебная палочка для добавления расширений.

Также стоит отметить, что Burp поддерживает работу с WebSocket, позволяя так же, как и при работе с протоколом HTTP, перехватывать и модифицировать запросы, передаваемые через WebSocket. А в новых версиях добавили функциональность, аналогичную Repeater, только для WebSocket.

Подробно останавливаться на каждом элементе Burp Suite мы не будем, а перейдем скорее к самому интересному полезным дополнениям и расширениям.

Param-miner

Про param-miner мы упоминали, когда обсуждали Arjun. Этот инструмент аналогичен Arjun, но работает в Burp и, кроме параметров, может находить еще скрытые заголовки и Cookie. Изначально разрабатывался как средство для поиска скрытых параметров, которые могут быть полезны при поиске уязвимостей типа Web Cache Poisoning.

+

• Плагин помогает находить скрытые GET/POST-параметры, параметры JSON-запроса, HTTP-заголовки, Cookie.
• Позволяет запускать как анализ нескольких запросов, так и всего трафика.

-

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

Stepper

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

Самый простой способ использования следующий. Допустим, для каждого нового запроса вам нужно получить новый CSRF-токен. Делать это вручную крайне неудобно. Вместо этого вы можете сделать последовательность в Stepper, которая будет сначала получать CSRF-токен, после чего выполнять нужный вам запрос. Для этого вам нужно будет в первом запросе указать, что является параметром, и добавить его как переменную (csrf_token в примере).

А затем в следующем запросе указать, куда этот параметр подставить, используя название переменной ($VAR:csrf_token$). В итоге Stepper сможет выполнить корректную последовательность запросов. Результаты подстановки можно будет увидеть во вкладке Stepper Replacements.

Кроме того, этот параметр можно использовать в другом инструменте, например в Repeater, указав в запросе переменную как $VAR:Test:csrf_token$:

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

+

• Существует возможность создавать произвольные последовательности HTTP-запросов.
• Для извлечения интересующих параметров из запросов и ответов используются регулярные выражения, что дает определенную гибкость в конфигурировании последовательности
• Есть глобальные переменные, которые можно использовать в Repeater.

-

• Отсутствует режим для фаззинга последовательности запросов, аналогичный Intruder.

Turbo intruder

Turbo Intruder более быстрый аналог Intruder, оснащенный скриптовым движком для отправки большого количества HTTP-запросов и анализа результатов. Полезен, если ВАМ НУЖНА СКОРОСТЬ! Очень эффективен при поиске уязвимостей, связанных с "состоянием гонки" (Race Condition), поскольку имеет внутри небольшой скриптовый движок на Python, в котором есть специальные функции для тестирования Race Condition (например, одномоментная отправка запросов). Возможности расширения позволяют заскриптовать различную логику, например многоступенчатую аутентификацию.
Пример простой bruteforce-атаки с использованием Turbo Intruder:

Для сравнения устроим с помощью Intruder и Turbo Intruder bruteforce-атаку для подбора OTP, состоящего из 4-х цифр от 0000 до 9999. Будем использовать 50 потоков. В нашем эксперименте Turbo Intruder справился всего за 18 секунд, в то время как Intruder за 18 секунд совершил лишь примерно 1000 запросов!

+

• Быстрый. По словам разработчиков, опережает даже скрипты на Go.
• Может быть запущен автономно через командную строку.
• Скриптовый движок на Python позволяет обеспечить гибкость, а значит может работать с многоступенчатыми последовательностями атак и отправлять запросы любого вида (может быть полезно при попытке эксплуатации атак HTTP Request Smuggling).
• Собственный стек HTTP позволяет отправлять запросы, которые нарушают корректную работу некоторых библиотек, а также позволяет добиться хорошей скорости отправки запросов.
• Удобная система фильтров анализа отправленных запросов и полученных ответов.
• Существуют различные шаблоны скриптов.

-

• Сложнее использовать, чем стандартный Intruder
• Написание скриптов в окне без подсветки синтаксиса и мощи современных IDE довольно неудобно, кроме того эти скрипты сложно отлаживать.
• Интерфейс в отдельном от Burp окне.
• По словам разработчиков, сетевой стек не так надежен, как ядро Burp.
• Может стать причиной DoS, поэтому рекомендуется отслеживать производительность приложений во время атак.

Freddy

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

Примеры уязвимостей, которые может обнаруживать Freddy:

+

• Пассивный режим сканирования может обнаруживать использование потенциально опасных библиотек сериализации и API-интерфейсов, анализируя сигнатуры в HTTP-запросах и HTTP-ответы для поиска исключений, выдаваемые целевыми библиотеками.
• Активный режим сканирования добавляет проверки в стандартный Burp Scanner, для обнаружения уязвимостей используются различные методы.
• Добавляет в Intruder словарь с различными проверками для поиска баг десериализации.

Backslash Powered Scanner

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

Пример репорта Backslash Scanner:

+

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

-

• Может давать false-positive и потому требует некоторой настройки для конкретных веб-приложений.

Active Scan ++

Active Scan ++ также дополняет стандартный сканер Burp Suite некоторыми проверками, которые не входят в стандартный комплект поставки Burp.

+

• Не требует никаких дополнительных настроек.
• Периодически обновляется, добавляются новые техники, основанные на новых исследованиях

J2EEScan

J2EEScan плагин, заточенный для атак на J2EE (Java 2 Enterprise Edition) приложения. "Под капотом" имеет большое количество проверок, связанных с Java-приложениям, в том числе проверки на известные уязвимости вроде Apache Struts. Проверки также добавляются в стандартный Burp Scanner. На практике этот сканер далеко не часто что-либо находит, но иметь его под рукой точно стоит.

+

• Не требует никаких дополнительных настроек.

-

• Плагин давно не обновлялся.

Upload Scanner

Upload Scanner еще один плагин для дополнения проверок Active Scanner. Поможет проверить точки загрузки файлов на такие известные уязвимости, как ImageTragic, инъекции PHP в метадату изображения, загрузку файла htaccess и т.д.

+

• Имеет гибкие настройки, позволяющие указать форматы файлов, используемые модули, что позволяет уменьшить количество отправляемых плагинов запросов.
• Кроме проверки уязвимостей, связанных с обработкой изображений, плагин умеет искать Code Injection, XSS, обход CSP и т.д.

Error Message Checks

Error Message Checks плагин, который пассивно обнаруживает различные stacktrace и вывод ошибок в веб-приложении, которые могут появиться при сканировании или crawling'е. Это очень полезно, поскольку не все сканеры могут обнаружить сообщения об ошибках сервера и оповестить о них, потому это часто остается незамеченным для аудитора, который смотрит на приложение со стороны пользователя.

+

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

Decoder Improved

Decoder Improved по сути, улучшенный стандартный Decoder. Встроенный Decoder в Burp не так уж и хорош и имеет свои недостатки: в нём нет вкладок, неудобно использовать Hex-редактор, к тому же имеет довольно скудное количество возможных форматов данных. С этими проблемами и помогает справится Decoder Improved.

+

• Поддерживает всё, что есть в Decoder, а также позволяет использовать алгоритмы сжатия (Gzip, Zlib), хешировать данные, а также меняет систему счисления (от base 2 до base 32).
• Поддерживает функциональность вкладок.
• Имеет улучшенный Hex-редактор.
• Предлагает функциональность регулярных выражений, что позволяет в процессе кодирования/декодирования легко подменять данные.
• Поддерживает режим замены только спецсимволов HTML/URL, в то время как буквенно-цифровые символы остаются без изменений

Hackvertor

Hackvertor плагин, который также поможет преобразовать данные в запросах и ответах. Только для этого не придется переключаться между вкладками. При работе с ним в Repeater или Intruder появляется возможность оборачивать пейлоады в специальные теги, с помощью которых задаются правила кодирования или декодирования данных. А все преобразования происходят на лету во время отправки запроса. А еще у него есть форк, который работает с pareq, который пригодится при тестировании 3D Secure, от нашего коллеги web_rock.

+

• Позволяет кодировать и декодировать данные на лету.
• "Под капотом" содержится огромное количество различных правил преобразования, которые также можно сочетать друг с другом.
• Шаблоны XSS-пейлоадов из коробки.
• Возможность создания своих правил.
• Возможность использования прямо из Repeater или Intruder.

Logger++

Logger++ плагин, главная задача которого тщательно логировать все запросы, происходящие внутри Burp Suite. Как те, что просто летят из браузера, так и те, что генерируются плагинами и сканером. Плагин устраняет основной недостаток встроенного Proxy History логирование запросов только из браузера и отсутствие прочих запросов из недр Burp, например запросов конкретного плагина, запросов из других инструментов (например, Repeater) или сканера в текущий момент. Плагин поддерживает фильтрацию логов. Так, вы можете найти все POST-запросы без CSRF-токена. Для этого нужно, побродив по ресурсу, отфильтровать историю запросов по методу запроса и интересующему параметру.

+

• Логирование всех запросов из инструментов и плагинов.
• Наличие фильтрации для быстрого поиска по логу запросов.
• Конфигурация плагина позволяет выбирать необходимые для логирования инструменты.
• Существует возможность импортировать запросы из OWASP ZAP, Proxy History и WStalker.
• Существует возможность экспорта логов в формате JSON и CSV.

-

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

HTTP Mock

HTTP Mock плагин, который будет полезен, если вам надо подменять не просто кусочек ответа (тогда вам поможет Match&Replace в настройках Proxy Intercept), а целиком весь ответ для определенных URL.

+

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

Request highlighter

Request highlighter плагин для подсветки HTTP-запросов на основе содержимого заголовков. Удобно для выделения уникальных Cookies, хостов, токенов аутентификации, пользовательских заголовков. С помощью плагина во вкладке Proxy History можно помечать запросы, относящиеся к различным сессиям, хостам, браузерам или устройствам. Данная функциональность может быть очень полезна, если нужно протестировать сайт с нескольких браузеров с разными пользовательскими сессиями плагин будет подсвечивать запросы соответствующими цветами.

+

• Удобная подсветка.

-

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

Autorize

Autorize плагин для проверки уязвимостей, связанных с разграничением прав доступа в веб-приложении. Удобен и прост в работе. По большей части всё, что нужно, это просто указать, где в запросе места, по которым определяется сессия пользователя, и подставить нужные значения. Далее плагин будет повторять все запросы, которые вы делаете в браузер, но уже с другими сессионными идентификаторами, что позволяет очень быстро проверить IDORы в приложении.

+

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

HTTP Request Smuggler

HTTP Request Smuggler плагин для проверки недавно заново открытых атак типа HTTP Request Smuggling. Несмотря на то, что стандартный сканер Burp Suite также выполняет проверки на данную уязвимость. Этот плагин обновляется чаще, и его можно запускать отдельно от остального сканирования, что бывает удобно, если нужно проверить только эту уязвимость.

PHP Object Injection Check / PHP Object Injection Slinger

PHP Object Injection Check и PHP Object Injection Slinger плагины, которые позволяют проверить уязвимости в десериализации PHP-объектов. Первый просто добавляет несколько проверок в стандартный Burp Scanner, а второй представляет собой отдельный сканер, в который отдельно нужно добавлять запросы. PHP Object Injection Slinger содержит в себе множество различных проверок из PHPGGC инструмента для создания payloadов для десериализации в PHP.

CSP Auditor

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

+

• Удобный вид для чтения CSP.

-

• Редко обновляется.

Заключение

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

Немного (в)водной

Kubernetes (или K8s) это расширяемая платформа, которая становится стандартом среди систем оркестрации при построении Cloud Native приложений. Сейчас все больше компаний переходят на Kubernetes. Поскольку он является одной из самых критичных составляющих DevOps-процесса, возникает вопрос: С чего начинать формирование безопасности Kubernetes?

Как и у любой системы, сложности с Kubernetes возникают уже на этапе настройки безопасной конфигурации и обслуживания: интерфейсы CRI, CNI, CSI, точки встраивания и изменения, CRD, кастомные операторы и контроллеры, различные версии API и т.д. При этом далеко не все команды разработки в полной мере знают, как все работает внутри инфраструктуры.

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

Незащищен по умолчанию

В Kubernetes существует множество механизмов безопасности: RBAC, NetworkPolicy, PodSecurityPolicy (seccomp, AppArmor, SeLinux) и т.д. Но они по умолчанию отключены. Сделано это для того, чтобы первый опыт использования платформы был удачным, а запуск или перенос приложений не был ничем усложнен. При миграции в новое окружение дополнительные ограничения создают проблемы в работе приложений, которые могут сказаться на процессах всей компании.

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

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

Если ИБ-специалист отвечает за безопасность всей инфраструктуры, то атакующему стоит найти всего один изъян и уделить внимание одной конкретной области, чтобы скомпрометировать всю систему.

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

Черная кошка в темном Kubernetes

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

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

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

Подходы к безопасности облачных технологий

Первое решение для обеспечения безопасности K8s необходимо выбрать исходя из простоты использования и легкости интеграции с другими решениями.

Выделим подходы, которые стоит рассмотреть при работе с инфраструктурой Kubernetes:

• Подход Zero Trust (нулевое доверие) модель безопасности, при которой нет доверия ни к кому и ни к чему, т.е. все пользователи и устройства должны подтверждать свои данные каждый раз, когда они запрашивают доступ к какому-либо ресурсу внутри или за пределами сети;
• Графовая модель модель безопасности и представления данных, основанная на графе, который показывает все возможные последовательности действий или отношения между процессами. Согласно специалистам ИБ из Microsoft, сейчас безопасность думает списками, а нападающий графами, и пришло время использовать против злоумышленников их же оружие;
• Безопасность Runtime технология безопасности, которая обнаруживает и блокирует аномалии в приложениях в реальном времени с помощью добавления функций защиты в среду исполнения;
• Поиск аномалий, которые связаны не только с атаками, но также с проблемами некачественно написанного кода или неправильной конфигурацией.

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

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

Выводы и напутствия

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

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

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

• За первые три месяца 2020 года, согласно отчету Terranova security, удаленные сотрудники получили 30 000 подозрительных сообщений, а весь целевой фишинг, связанный с COVID, увеличился на 667%.
• В течение 3 квартала 2020 года 37% компьютеров и серверов в мире, использующихся для хранения и обработки биометрических данных (отпечатки пальцев, шаблоны лица, голоса и радужной оболочки глаза), как минимум один раз подвергались риску заражения вредоносным ПО.
• Согласно результатам Microsoft Digital Civility Index, в России в 2020 году из всех онлайн-угроз чаще всего люди сталкивались с рисками нежелательной коммуникации: об этом заявили 71% опрошенных, из них с мошенничеством и обманом встретились 54%.

Напомним основные этапы атаки социальной инженерии:

1. Сбор информации о целевом объекте;
2. Подготовка сценария действий и необходимых средств атаки (фишинговые ресурсы, вредоносные вложения и др.);
3. Установление связей и завоевание доверия жертвы;
4. Достижение цели атаки (получение необходимой информации).

• Они выглядят естественно, поскольку мошенники эксплуатируют доверие пользователей;
• Информация, на которой они базируются, может утекать за пределами рабочего места сотрудника, что бывает довольно сложно отследить;
• Часто злоумышленникам не требуется тратить время на эксплуатацию уязвимости в ПО компании или поиск 0-day в продуктах, чтобы после обратить ситуацию в свою пользу. Всё сделает пользователь, достаточно лишь подтолкнуть. Это дёшево и сравнительно быстро, особенно если рассматривать phishing as a service.

Сценарий в работе

• Макросные сценарии сценарии, где пользователь должен разрешить выполнение макросов. В качестве примера недавней атаки можно привести запуск шифровальщика через макросы.
• Парольные сценарии сценарии, где пользователь должен ввести в систему свои логин и пароль. Здесь можно вспомнить необычную атаку с использованием азбуки Морзе.
• Сценарии с исполняемыми файлами сценарии, где пользователь должен скачать и установить исполняемый файл. Телефонный скам якобы от компании Microsoft, а также атаки на пользователей LinkedIn с использованием бесфайлового бэкдора more_eggs.

Макросные сценарии:

Парольные сценарии:

Сценарии с исполняемыми файлами:

Цифры и факты

Случай 1.

Случай 2.

Рекомендации:

Вывод:

• сфера деятельности компании;
• особенности физической защиты периметра офисного здания (заборы, камеры, посты охраны и т.п.);
• особенности здания, где располагается офис (целый ли БЦ занимает компания или только часть, местоположение постов охраны, расположение основных и запасных входов и выходов);
• особенности окружающего ландшафта (наличие вокруг здания кустов, скамеек, мусорных контейнеров, куда злоумышленник может спрятать свои устройства);
• распорядок дня сотрудников и их привычки;
• возможность проникновения 3-х лиц на территорию;
• фотографии пропусков, планы этажей, расписания мероприятий и иную информацию, которую можно найти в открытом доступе.

Вне (?) подозрения

1. Технический персонал

2. Обслуживающий персонал

3. Доставка еды

Что делать в таком случае?

4. Курьерские службы

Что делать в таком случае?

Как могут проникнуть в здание?

1. Я на собеседование

Что делать в таком случае?

2. Игра в переодевание

Что делать в таком случае?

3. Опоздание на встречи

Что делать в таком случае?

4. Вход через курилку

Что делать в таком случае?

5. Копирование пропусков

Что делать в таком случае?

6. Физические носители

Что делать в таком случае?

Рекомендации

Для компаний:

• Проводить обучение охраны. Все заходящие на территорию люди должны либо пользоваться пропусками, либо вручную заноситься в журналы. В той или иной форме следует фиксировать сведения о перемещениях по территории.
• Иметь гостевые пропуски для посетителей с ограниченным радиусом действия. Если возможно, реализовать систему man's trap.
• Внедрить СКУД, которая не подвержена атаке клонирования, например на основе HID iclass se или mifare desfire.
• Проводить тренинги для сотрудников. Сотрудники должны понимать, в какой момент можно стать мишенью и какие есть способы затруднить работу злоумышленника.
• Сохранять баланс между корпоративной культурой и задачей защитить компанию.

Для сотрудников:

• Не нужно стесняться разговаривать с людьми. В большинстве случаев вы поможете человеку решить его проблему, однако не стоит в это время забывать о базовых мерах предосторожности.
• Сомневаетесь, но не хотите показаться невежливым, пропуская подозрительную личность за собой паровозиком? Замешкайтесь, сделайте вид, что читаете сообщение в телефоне, и посмотрите, куда пойдет этот человек и что он будет делать.
• Не бойтесь показаться параноиком, обращая внимание других на подозрительную активность.
• Следуйте указаниям службы безопасности/IT-отдела. Помните, что тренинги по безопасности проводятся не просто так, а политика ИБ это не очередной документ, который можно прочитать и забыть.
• Нужно понимать, что никто вас не просит ловить подозрительного человека за рукав и лично тащить к начальству. Это (если обратного не утверждает трудовой договор) не ваша обязанность. Ответственность за поимку возможного преступника лежит на охране объекта, ваше дело обратить внимание на подозрительную активность и предупредить об этом.
• Отключайте Wi-Fi на телефонах, если он вам не нужен. Особенно это касается владельцев Android-устройств, поскольку они более уязвимы к атакам типа evil-twin ввиду особенностей работы этой ОС.

Вывод