Любое объективное и полноценное тестирование на проникновение должно
выполняться с учетом рекомендаций и правил. Хотя бы для того, чтобы быть
грамотным спецом и ничего не упустить. Поэтому, если ты хочешь связать свою
профессиональную деятельность с пентестом – обязательно ознакомься со
стандартами. А в первую очередь – с моей статьей.
Правила и рамки информационного пентестинга представлены в методологиях
OSSTMM и OWASP. Впоследствии полученные данные можно легко
адаптировать для проведения оценки соответствия с какими-либо промышленными
стандартами и "лучшими мировыми практиками", такими как, Cobit,
стандартами серии ISO/IEC 2700x, рекомендациями CIS/SANS/NIST/etc
и – в нашем случае – стандартом PCI DSS.
Безусловно, накопленных данных, полученных в процессе тестирования на
проникновение, для проведения полноценной оценки по промышленным стандартам
будет недостаточно. Но на то он и пентест, а не аудит. Кроме того, для
осуществления такой оценки в полном объеме одних лишь технологических данных по
любому будет мало. Для полноценной оценки требуется интервьюирование сотрудников
различных подразделений оцениваемой компании, анализ распорядительной
документации, различных процессов ИТ/ИБ и много еще чего.
Что касается тестирования на проникновение в соответствии с требованиями
стандарта по защите информации в индустрии платежных карт, – он не намного
отличается от обычного тестирования, проводимого с использованием методик
OSSTMM и OWASP. Более того, стандартом PCI DSS рекомендуется
придерживаться правил OWASP при проведении как пентеста (AsV), так и
аудита (QSA).
Основные отличия тестирования по PCI DSS от тестирования на
проникновение в широком смысле этого слова заключаются в следующем:
- Стандартом не регламентируется (а значит и не требуется) проведение атак с
использованием социальной инженерии.
- Все проводимые проверки должны максимально минимизировать угрозу "Отказа в
обслуживании" (DoS). Следовательно, проводимое тестирование должно
осуществляться методом "серого ящика" с обязательным предупреждением
администраторов соответствующих систем.
- Основная цель такого тестирования – это попытка осуществления
несанкционированного доступа к данным платежных карт (PAN, Cardholder Name и
т.п.).
Под методом "серого ящика" (gray box) подразумевается выполнение различного
рода проверок с предварительным получением дополнительной информации об
исследуемой системе на разных этапах тестирования. Это позволяет снизить риск
отказа в обслуживании при проведении подобных работ в отношении информационных
ресурсов, функционирующих в режиме 24/7.
В общем случае тестирование на проникновение по требованиям PCI должно
удовлетворять следующим критериям:
- п.11.1(b) – Анализ защищенности беспроводных сетей
- п.11.2 – Сканирование информационной сети на наличие уязвимостей (AsV)
- п.11.3.1 – Проведение проверок на сетевом уровне (Network-layer
penetration tests)
- п.11.3.2 – Проведение проверок на уровне приложений (Application-layer
penetration tests)
На этом теория заканчивается, и мы переходим к практике.
Определение границ проводимого исследования
В первую очередь необходимо понять границы тестирования на проникновение,
определиться и согласовать последовательность выполняемых действий. В лучшем
случае со стороны подразделения ИБ может быть получена карта сети, на которой
схематично показано, каким образом процессинговый центр взаимодействует с общей
инфраструктурой. В худшем – придется общаться с системным администратором,
который в курсе собственных косяков и получение исчерпывающих данных об
информационной системе будет затруднено его нежеланием делиться своими
уникальными (или не очень, – прим. Forb) знаниями. Так или иначе, для проведения
пентеста по PCI DSS, как минимум, требуется получить следующую информацию:
- сегментация сети (пользовательская, технологическая, ДМЗ, процессинг и
т.д.);
- межсетевое экранирование на границах подсетей (ACL/МСЭ);
- используемые Web-приложения и СУБД (как тестовые, так и продуктивные);
- используемые беспроводные сети;
- какие-либо детали обеспечения безопасности, которые необходимо учесть в
ходе проведения обследования (например, блокировка учетных записей при N
попытках неправильной аутентификации), особенности инфраструктуры и общие
пожелания при проведении тестирования.
Обладая всей необходимой информацией, перечисленной выше, можно
организовывать свое временное пристанище в наиболее оптимальном сегменте сети и
приступать к обследованию информационной системы.
Network-layer penetration tests
Для начала стоит провести анализ пробегающего мимо сетевого трафика с помощью
любого сетевого анализатора в "неразборчивом" режиме работы сетевой карты
(promiscuous mode). В качестве сетевого анализатора для подобных целей
замечательно подходит
Wireshark или CommView. Чтобы выполнить этот этап, хватит 1-2 часов работы
снифера. По прошествии этого времени накопится достаточно данных для проведения
анализа перехваченного трафика. И в первую очередь при его анализе следует
обратить внимание на следующие протоколы:
- протоколы коммутации (STP, DTP и т.п.);
- протоколы маршрутизации (RIP, EIGRP и т.д.);
- протоколы динамической конфигурации узла (DHCP, BOOTP);
- открытые протоколы (telnet, rlogin и т.п.).
Что касается открытых протоколов, – вероятность того, что они попадутся во
время снифания проходящего мимо трафика в коммутируемой сети, достаточно мала.
Однако, если такого трафика много, то в обследуемой сети явно наблюдаются
проблемы в настройках сетевого оборудования.
Во всех остальных случаях присутствует возможность проведения красивых атак:
- классической атаки MITM (Man in the middle) в случае, когда используется
DHCP, RIP
- получение роли корневого узла STP (Root Bridge), что позволяет
перехватывать трафик соседних сегментов
- перевод порта в магистральный режим с помощью DTP (enable trunking);
позволяет перехватывать весь трафик своего сегмента
- и др.
Для реализации атак на протоколы коммутации доступен замечательный инструмент
Yersinia. Предположим, что в процессе анализа трафика были выявлены пролетающие
мимо DTP-пакеты (смотри скриншот). Тогда отправка пакета DTP ACCESS/DESIRABLE
может позволить перевести порт коммутатора в магистральный режим. Дальнейшее
развитие этой атаки позволяет прослушивать свой сегмент.
После тестирования канального уровня стоит переключить внимание на третий
уровень OSI. Дошла очередь и до проведения атаки ARP-poisoning. Тут все просто.
Выбираем инструмент, например,
Cain&Abel или Ettercap
и обговариваем с сотрудниками ИБ детали проведения этой атаки (в том числе,
необходимость в проведении атаки, направленной на перехват одностороннего SSL).
Все дело в том, что в случае успешной реализации атаки ARP-poisoning в отношении
всего своего сегмента может наступить ситуация, когда компьютер атакующего не
справится с потоком поступающих данных и, в конечном счете, это может стать
причиной отказа в обслуживании целого сегмента сети. Поэтому наиболее правильным
будет выбрать единичные цели, например, рабочие места администраторов и/или
разработчиков, какие-либо определенные сервера (возможно контроллер домена,
СУБД, терминальный сервер, etc).
Успешно проведенная атака ARP-poisoning позволяет получить в открытом виде
пароли к различным информационным ресурсам – СУБД, каталогу домена (при
понижении проверки подлинности NTLM), SNMP-community string и пр. В менее
удачном случае могут быть получены хеш-значения от паролей к различным системам,
которые нужно будет за время проведения пентеста постараться восстановить по
радужным таблицам (rainbow tables), по словарю или атакой "в лоб". Перехваченные
пароли могут использоваться где-то еще, и впоследствии это также необходимо
подтвердить или опровергнуть.
Кроме того, стоит проанализировать весь перехваченный трафик на присутствие
CAV2/CVC2/CVV2/CID/PIN, передаваемых в открытом виде. Для этого можно пропустить
сохраненный cap-файл через NetResident и/или
0x4553-Intercepter.
Второй, кстати, замечательно подходит для анализа накопленного трафика в целом.
Application-layer penetration tests
Переходим на четвертый уровень OSI. Тут, в первую очередь, все сводится к
инструментальному сканированию обследуемой сети. Чем его проводить? Выбор не так
уж и велик. Первоначальное сканирование можно выполнить с использованием Nmap в
режиме "Fast scan" (ключи -F -T Aggressive|Insane), а на следующих этапах
тестирования проводить сканирование по определенным портам (ключ -p), например,
в случаях обнаружения наиболее вероятных векторов проникновения, связанных с
уязвимостями в определенных сетевых сервисах. Параллельно стоит запустить сканер
безопасности – Nessus или XSpider (у последнего результаты помясистей будут) в
режиме выполнения только безопасных проверок. При проведении сканирования на
уязвимости необходимо также обращать внимание на присутствие устаревших систем
(например, Windows NT 4.0), потому как стандартом PCI запрещается их
использование при обработке данных держателей карт.
Не стоит, при обнаружении критической уязвимости в каком-либо сервисе, сразу
же бросаться на ее эксплуатацию. Правильный подход при тестировании по PCI –
это, во-первых, получить более полную картину состояния защищенности обследуемой
системы (является ли эта уязвимость случайной или она встречается повсеместно),
а во-вторых, согласовать свои действия по эксплуатации выявленных уязвимостей в
определенных системах.
Итогами инструментального обследования должны стать общая картина
реализованных процессов ИБ и поверхностное понимание состояния защищенности
инфраструктуры. Во время отработки сканов можно попросить ознакомиться с
используемой политикой ИБ в Компании. Для общего саморазвития :).
Следующий этап – выбор целей для проникновения. На этом этапе следует
провести анализ всей собранной информации, полученной в ходе прослушивания
трафика и сканирования на уязвимости. Вероятно, к этому моменту уже будут
прослеживаться уязвимые или потенциально уязвимые системы. Следовательно, пришло
время воспользоваться этими недостатками.
Как показывает практика, работа проходит по следующим трем направлениям.
1. Эксплуатация уязвимостей в сетевых сервисах
В далеком прошлом осталось время, когда эксплоитинг был уделом избранных,
способных хотя бы собрать чужой код и (о Боже!) подготовить свой шелл-код.
Сейчас эксплуатация уязвимостей в сетевых сервисах, таких как переполнение
буфера и иже с ними, доступна каждому. Причем, процесс все больше напоминает
игру в жанре "квест". Взять хотя бы Core Impact, в котором весь пентест сводится
к клацанью мышкой по различным выпадающим менюшкам в красивой GUI-обертке.
Подобный инструментарий здорово экономит время, которого при внутреннем пентесте
не так уж и много. Потому шутки шутками, а фичисет, реализованный в Core Impact,
позволяет, особо не утруждаясь, последовательно выполнить эксплуатацию, поднятие
привилегий, сбор информации и удаление следов своего пребывания в системе. В
связи с чем Core Impact пользуется особой популярностью у западных аудиторов и
пентестеров.
Из общедоступных инструментов подобного рода можно упомянуть следующие
сборки: Core Impact, CANVAS, SAINTexploit и всеми любимый Metasploit Framework.
Что касается первой тройки, – это все коммерческие продукты. Правда, некоторые
старые версии коммерческих сборок утекали в свое время в интернет. При желании
можно отыскать их в глобальной сети (естественно, исключительно с целью
самообразования). Ну а весь бесплатный свежачок сплоитов доступен и в Metasploit
Framework. Конечно, существуют zero-day сборки, но это уже совсем другие деньги.
Кроме того, бытует спорное мнение, что при проведении пентеста их использование
является не совсем честным.
На основе данных сетевого сканирования можно немного поиграть в хакеров :).
Предварительно согласовав список мишеней, провести эксплуатацию обнаруженных
уязвимостей, а после выполнить поверхностный локальный аудит захваченных систем.
Собранная на уязвимых системах информация может позволить повысить свои
привилегии и на других ресурсах сети. То есть, если в процессе проведения атаки
ты порутал винду, то не лишним будет снять с нее базу SAM (fgdump) для
последующего восстановления паролей, а также секреты LSA (Cain&Abel), в которых
зачастую может храниться в открытом виде много полезной информации. К слову,
после проведения всех работ собранная информация о паролях может расцениваться в
контексте соответствия или несоответствия требованиям стандарта PCI DSS (п. 2.1,
п.2.1.1, п.6.3.5, п.6.3.6, п.8.4, п.8.5.x).
2. Анализ разграничения доступа
Анализ разграничения доступа необходимо выполнять на всех информационных
ресурсах, на которые удалось реализовать НСД. И на общих файловых ресурсах
Windows (SMB), на которых открыт анонимный доступ – тоже. Зачастую это позволяет
получить дополнительную информацию о ресурсах, которые не были обнаружены во
время сетевого сканирования, или наткнуться на другую информацию, различной
степени конфиденциальности, хранимую в открытом виде. Как я уже говорил, при
проведении тестирования по PCI, в первую очередь, поиск направлен на обнаружение
данных держателя карт. Поэтому важно понимать, как могут выглядеть эти данные и
искать их во всех информационных ресурсах, к которым имеется соответствующий
доступ.
3. Атака типа брутфорс
Необходимо, как минимум, проверить дефолты и простые комбинации логин-пароль.
Подобные проверки требуется провести, прежде всего, в отношении сетевого
оборудования (в том числе, для SNMP) и интерфейсов удаленного администрирования.
При проведении AsV-сканирования по PCI DSS не разрешается осуществлять "тяжелый"
брутфорс, который может привести к состоянию DoS. Но в нашем случае речь идет
про внутренний пентест по PCI, а потому в разумном виде и без фанатизма стоит
осуществить атаку по подбору простых комбинаций паролей к различным
информационным ресурсам (СУБД, WEB, ОС и т.п.).
Очередной этап – это анализ защищенности Web-приложений. При пентесте по PCI
про глубокий анализ Web речи не идет. Оставим это QSA-аудиторам. Здесь
достаточно осуществить blackbox-сканирование с выборочной верификацией
эксплуатабельных server/client-side уязвимостей. В дополнение к уже упомянутым
сканерам безопасности можно воспользоваться сканерами, заточенными под анализ
Web. Идеальное решение – это, безусловно, HP WebInspect или
Acunetix Web Vulnerability
Scanner (который, кстати, на "отлично" детектит баги в AJAX). Но все это –
дорогая и непозволительная роскошь, а раз так, то нам подойдет и w3af, который в
последнее время набирает обороты в плане детектирования различного рода
уязвимостей в Web-приложениях.
По поводу ручной верификации уязвимостей в Web! Необходимо, как минимум,
проверить механизмы аутентификации и авторизации, использование простых
комбинаций логин-пароль, дефолтов, а также всеми любимые SQL–инъекции,
инклудинг-файлов и выполнение команд на сервере. Что касается client-side
уязвимостей, то, кроме верифицирования возможности эксплуатации уязвимости, тут
более ничего не требуется. А вот с server-side необходимо немного повозиться,
ибо все-таки пентест, хоть и по PCI DSS. Как я отмечал ранее, мы ищем PAN,
Cardholder Name и CVC2/CVV2 опционально. Вероятнее всего, подобные данные
содержатся в СУБД, а потому в случае нахождения SQL-инъекции стоит оценить имена
таблиц, колонок; желательно сделать несколько тестовых выборок, чтобы
подтвердить или опровергнуть присутствие подобных данных в базе в
незашифрованном виде. Если столкнулся с Blind SQL-иъекцией, то лучше натравить
на Web-сервер sqlmap (с
ключом --dump-all), который на текущий момент работает с MySQL, Oracle,
PostgreSQL и Microsoft SQL Server. Этих данных будет достаточно для демонстрации
использования уязвимости.
Дальнейший этап – это анализ защищенности СУБД. Опять же, есть отличный
инструмент – AppDetective от "Application Security Inc.", но это дорогое
удовольствие. К сожалению, аналогичного сканера безопасности, который бы выдавал
такой объем информации, как это умеет AppDetective, и поддерживал столько же
СУБД, в настоящее время не существует. И потому приходится брать на вооружение
множество отдельных, несвязанных между собой продуктов, которые заточены под
работу с определенными вендорами. Так, для ораклятины минимальный набор
пентестера будет следующим:
- Oracle Database Client – окружение для работы с СУБД
- Toad for Oracle – клиент для работы с PL/SQL
- Oracle Assessment Kit – брут пользователей и SID’ов баз
- различные сценарии на языке PL/SQL (например, аудит конфигурации или
возможность спуститься на уровень выполнения команд ОС)
Заключительный этап тестирования на проникновения по PCI – это анализ
защищенности беспроводных сетей, вернее, даже не анализ, а поиск точек доступа,
использующих уязвимые конфигурации, таких как Open AP, WEP и WPA/PSK. С другой
стороны, стандарт PCI не запрещает проводить более глубокий анализ, в том числе
с восстановлением ключей для подключения к беспроводной сети. Потому имеет смысл
осуществить подобного рода работы. Основным же инструментом на этом этапе,
конечно, будет aircrack-ng. Дополнительно можно провести атаку, направленную на
беспроводных клиентов, известную как "Caffe Latte", с использованием все того же
инструмента. При проведении обследования беспроводных сетей можно смело
руководствоваться данными с сайта
Wirelessdefence.org.
Вместо заключения
По результатам тестирования проводится анализ всей собранной информации в
контексте соответствия техническим требованиям стандарта PCI DSS. И как я уже
отмечал в самом начале, таким же образом данные, полученные при пентесте, можно
интерпретировать в контексте любого другого высокоуровневого документа,
содержащего технические критерии и рекомендации к системе управления
информационной безопасности. Относительно используемого шаблона для отчетных
документов по PCI, – можно использовать требования MasterCard к отчету по
AsV-сканированию. В них предусматривается разделение отчета на два документа –
документ верхнего уровня для руководителя, в котором содержатся красивые графики
и указан процент соответствия текущего состояния системы с требованиями PCI DSS,
и технический документ, содержащий протокол проведенного тестирования на
проникновение, выявленные и эксплуатируемые уязвимости, а также рекомендации по
приведению информационной системы в соответствие с требованиями MasterCard.
Засим могу попрощаться и пожелать удачи в исследованиях!
WWW
pcisecuritystandards.org - PCI Security Standards Council.
pcisecurity.ru – портал,
посвященный PCI DSS от Информзащиты.
pcidss.ru – портал, посвященный
PCI DSS от Digital Security.
isecom.org/osstmm - Open
Source Security Testing Methodology Manual.
owasp.org - Open Web Application
Security Project.
|
