Сломать всё
Автор
Илья Медведовский
Пентест нужен, если заказчику требуется понять, насколько уязвима его система и насколько легко ее взломать.
Удивительно, но то, чем мы занимались последние 15 лет, вдруг оказалось весьма популярно. Так уж случилось. И теперь пентест практически сродни футболу, в котором не смыслит почти никто, но разбираются поголовно все. Поскольку мы часто видим или глубоко технические статьи в этой области, или нечто неопределенное вокруг нее, я решил популярным языком изложить, что же такое пентест и какие нюансы с ним связаны.
Что такое пентест. Виды пентестов
Максимально обобщенное определение теста на проникновение (на сленге «пентест», сокращение от англ. — penetration testing) будет звучать так: это поиск уязвимостей за ограниченное время и практическая проверка возможностей их реализации с выдачей рекомендаций по устранению обнаруженного.
Поскольку «пентест» слишком общий термин, прежде всего означающий именно практический хакинг, то в ряде случаев вполне допустимо называть его аудитом защищенности/безопасности, или просто аудитом, используя данное слово в контексте как синоним. А потому в дальнейшем мы будем говорить не столько о каноническом пентесте, сколько об аудите безопасности/пентесте, с учетом нашего опыта и широкой международной практики.
С нашей точки зрения в подобном аудите безопасности/пентесте можно «широкими мазками» выделить три основных типа работ (конечно, бывают вариации/комбинации, и я перечислю не все, а только основное):
- аудит инфрастуктуры;
- аудит приложения (веб, бизнес);
- исследования.
Аудит ИТ-инфраструктуры
Объект аудита — внутренняя сеть или внешний периметр. Задача аудита — за ограниченный срок в определенной модели нарушителя(ей) найти все возможные известные уязвимости ПО, недостатки парольной политики, недостатки и тонкости настроек конфигурации, особенности архитектуры и т. д., используя которые пентестеры стремятся реализовать на практике различные векторы атак (обычно с помощью цепочек уязвимостей — то что, кстати, в принципе не может сделать сканер). Задача творческая, сложная и интересная, но не требующая поиска 0day и глубокого изучения отдельных ИТ-компонентов. Хотя это не возбраняется и частенько наблюдается в качестве побочного результата у квалифицированного аудитора — лишними 0day никогда не бывают (0day — это уязвимость нулевого дня, то есть неизвестная на данный момент).
Аудит приложения (веб или бизнес)
Объект аудита — приложение и его окружение. Задача аудита — за ограниченный срок в определенной модели нарушителя(ей) провести глубокий анализ приложения, в частности, найти неизвестные уязвимости, добившись при этом максимального покрытия (полноты изучения). Подчеркиваю: при анализе именно приложения. Речь идет об уязвимостях, в том числе архитектурных, некорректных настройках и т. п. Добиться нормальной полноты анализа (конечно, не 100%-й, это по определению нереально) можно в том случае, если мы не имеем в виду огромные приложения с десятками миллионов строк кода. Также при анализе приложения обязательно проверяется и его окружение (ОС, базы данных, веб-сервер), но только на наличие известных уязвимостей, логики, парольной политики, тонких настроек и т. п. Никто неизвестные уязвимости во всем окружении не ищет — это невозможно за период аудита и не является его целью.
Исследования
Объект исследования, как правило, базовые компоненты ИТ. Задача исследования — поиск неизвестных уязвимостей. Это самое интересное, самое сложное и самое редко встречающееся — словом, то, что обычно нужно не коммерческим заказчикам, а государству, спецслужбам или крупным вендорам. Я говорю о поиске новых уязвимостей (0day) в общеизвестных базовых ИТ-компонентах (ОС, базы данных, роутеры, ERP-системы, датчики АСУ ТП и т. п.) и в ряде случаев — о написании эксплойтов к ним. Подобное исследование действительно огромное и очень сложное; причем постоянное и многолетнее. Только так с течением времени (зачастую оно занимает годы для больших систем) можно добиться приемлемой полноты анализа.
Соответственно, если в процессе общего аудита или аудита приложения аудитор/пентестер не нашел в окружении, например, уязвимость HeartBleed, это произошло лишь потому, что... он его и не искал — подобная задача не входит и не могла входить в ТЗ, что очевидно. Вот если бы в процессе отдельного исследования конкретной библиотеки он не нашел бы уязвимость — вот тогда это его прямой промах. Но и такое случается, к сожалению. Как и баги вендоров, которые, кстати, первичны. Увы, 100%-ной полноты поиска в нашем деле добиться невозможно. Но надо к ней стремиться.
Добавлю ряд небольших, но важных замечаний. Во-первых, на заре появления пентестов, речь о середине 90-х, в некоторых случаях считалось, что достаточно проникнуть в систему любым образом или сломать ее через любую уязвимость (или цепочку уязвимостей) и пентест останавливался — результат в виде успешного проникновения достигнут. В дальнейшем с развитием пентестов заказчики стали понимать, что его главная цель вовсе не «вау-эффект», а полнота поиска. Поэтому сегодня такие цели при пентесте ставятся только при необходимости осуществить «боевую» операцию, и в подавляющем большинстве случаев основная задача пентеста все-таки обнаружить максимально возможное число уязвимостей и векторов атак за ограниченный промежуток времени и предоставить рекомендации по их закрытию.
Во-вторых, социальная инженерия, то есть атака на систему с использованием человеческих слабостей, сегодня вообще не относится к пентесту, поскольку ее реализация всегда возможна и практически никак не зависит от технического уровня защищенности системы.
В-третьих, с некоторой натяжкой можно считать (только условно), что пентест — полное моделирование и повторение действий реального злоумышленника. Это не совсем так. Аудитор, особенно в случае пентеста ИТ-инфраструктуры, связан многими контрактными ограничениями, которых не существует у реального злоумышленника. Плюс ограничение по времени.
Зачем нужен аудит безопасности/пентест
На самом деле мне очень хотелось перенести этот раздел в самое начало, но рассудив здраво, я решил, что будет довольно странно говорить, зачем нужно то, суть чего не до конца ясна.
В данном случае все просто, но как обычно есть некоторые нюансы. Очевидно, пентест нужен, если заказчику требуется понять, насколько уязвима его система и насколько легко ее взломать. Для чего это надо заказчику — было написано во множестве статей (в том числе «Санитары леса»), и я не думаю, что следует повторяться. Если кратко, то мир ИТ стал настолько сложен и многообразен, что без «санитаров леса», коими и выступают пентестеры, клиенты, с одной стороны, останутся один на один с хакерами, а с другой — будут полностью зависеть от вендоров, интеграторов и собственной ИТ-службы, никак не контролируя процесс с точки зрения уязвимостей. При этом мы все прекрасно знаем, какую ответственность несут вендоры и интеграторы в случае инцидента, произошедшего у заказчика, из-за уязвимости в ПО или неправильной конфигурации. Никакую. Вот почему аудит — стандартный элемент контроля практической безопасности, который рекомендуется как международными, так и российскими стандартами по ИБ.
Кстати, существует масса забавных иллюзий, связанных с поиском ответа на вопрос, зачем и кому понадобился пентест. Например, весьма наивно полагать, будто пентест нужен интегратору для обоснования необходимости проекта защиты, то есть пентест в данном случае является первым и обязательным шагом. Скорее наоборот. Пентест часто крайне опасен и даже вреден для бизнеса интеграторов за исключением случая «вау-эффекта» с показательным взломом (вот это всегда полезно, если мы говорим о безопасности). Дело в том, что после работы пентестера (речь идет об аудите инфраструктуры — а именно он теоретически обычно интересен интеграторам или так им кажется) обычно выясняется, что 95% основных проблем устраняются совершенно бесплатно патч-менеджментом и тонкими настройками. А вот для решения совершенно других проблем и закрытия оставшихся 5% и требуются те самые дорогостоящие продукты и интеграторы с их проектами, для реализации которых необходим совершенно иной предпроектный анализ. И пентест не имеет к нему никакого отношения. Поэтому подавляющее большинство наших интеграторов обычно никогда и не стремилось развивать у себя столь специфичную и сложную хакерскую экспертизу, справедливо считая ее непрофильным и даже вредным бизнесом, однако в течение многих лет выдавая буквально все что угодно за пентест, кроме самого пентеста.
Ответственность компании аудитора
Говоря об ответственности пентестера, давайте вначале вспомним об ответственности вендора за оставленные уязвимости. Это именно он, вендор, делает софт с уязвимостями и иногда закладками (читай: теми же самыми уязвимостями, но оставленными специально). Вендор, продавая софт, не более чем любезно разрешает им пользоваться согласно лицензии, но никак не отвечает за любой ущерб, причиненный по вине созданного им софта. То есть в случае атаки через оставленную вендором уязвимость последствия для него равны нулю — добро пожаловать в мир ИТ!
Таким образом, ответственность аудитора в данном случае — вопрос не самый простой, но если задуматься, ответ на него вполне очевиден. Пентестер не может и не должен гарантировать, что нашел все уязвимости и придумал все вероятные векторы атак — так не бывает. Как для вендора нереально создать абсолютно безопасный софт, так и для аудитора нереально найти все уязвимости. Это аксиома. И в данном случае единственный выход для заказчика гарантированно получить качественный результат — выбирать доверенного и квалифицированного пентестера, о чем и пойдет разговор в следующем разделе.
Что же может гарантировать аудитор? Все, что указано в договоре, правда, на качество выполнения работы никакой договор и самое хорошее ТЗ не влияют, хотя и являются необходимым, но не достаточным условием. Гарантировать аудитор может неразглашение конфиденциальной информации, включая большие штрафы за ее разглашение (данный пункт при желании страхуется). При проведении пентеста инфраструктуры аудитор не может обеспечить ее отказоустойчивость, но должен к этому стремиться. Для опытного пентестера вероятность возникновения таких проблем, когда его действия способны привести к отказу в обслуживании, обычно минимальна (крайне редко, но системы падают даже от простого сканирования). Поэтому, скажем, инфраструктурный аудит АСУ ТП нужно выполнять буквально в «белых перчатках». Словом, как вы покупаете софт на условиях «как есть» плюс некоторые оговорки, так и пентест проводится «как есть» плюс некоторые оговорки — и третьего здесь не дано. Соответственно, важнейшими параметрами, по которым следует выбирать пентестера и которые определяют качество предоставляемых услуг, становятся доверие и квалификация.
Квалификация и доверие к компании-аудитору
Как выбрать пентестера? Здесь есть два основных критерия: доверие к аудитору и его квалификация.
Доверие
Как заказчик может понять, следует ли доверять данной компании-аудитору? Ответ традиционен: перечень крупных клиентов и их референсы (открытые или гораздо чаще закрытые), давно ли компания на рынке, насколько она известна и т. д. Вопрос доверия становится краеугольным камнем, поэтому совершенно не важна квалификация, если нет доверия.
Рассмотрим подробнее следующую типовую проблему, напрямую связанную с доверием, — страх перед пентестерами. Что, в общем-то, правильно: пентестеров, как и любых других внешних консультантов, надо бояться. Конечно, прежде всего, нужно бояться... интеграторов и вендоров, оказывающих техническую поддержку, — они гораздо опаснее. Они, в отличие от пентестеров, которые не знают ничего, кроме дыр, прекрасно разбираются во всей системе: что и где в ней находится и что с этим можно сделать, к тому же имеют все необходимые права. Кроме того, к интеграторам все давно привыкли, и контроль над их деятельностью сильно ослабляется с течением времени, что делает их еще опаснее...
Но есть одно важное и специфичное «но», связанное именно с пентестерами. В отличие от интеграторов в пентестерских компаниях работает много увлеченной и талантливой молодежи, у которой иногда стирается грань между виртуальностью и реальностью. Дело тут не в криминале, а именно в излишней увлеченности и мальчишестве — я поднимал этот вопрос в статье «Как приручить хакера?». И таким «хакерским» коллективом достаточно сложно управлять — требуется немалый опыт, знание особенностей, различные выстроенные и отлаженные, но одновременно специфичные процессы. Таким особым опытом и отличаются зрелые пентестерские компании по всему миру, и им доверяют топовые клиенты. Поэтому совет № 1 — пользуйтесь только услугами доверенных, опытных и известных на рынке специализированных компаний-пентестеров.
Однако, несмотря на довольно серьезные риски, которые справедливо вынуждают компании пользоваться только услугами доверенных аудиторов, есть ряд смягчающих обстоятельств. Итак, чего больше всего боятся заказчики?
Аудитор слишком много узнает
Контролируемый пентестер не сделает ничего того, что не может сделать неконтролируемый злоумышленник. Уж пусть лучше об уязвимостях узнает аудитор и сообщит вам, чем это сделает кто-то другой без контракта. Кроме того, после ухода аудитора уязвимости обычно быстро исправляются и все его знания через короткое время становятся никому не нужными, если конечно, он ничего для себя не припас на будущее — а во избежание этого смотри совет № 1 по выбору пентестера.
Аудитор получит доступ к критичным данным
Да, он может получить доступ к критичным данным, например, через административные права в системе — это его прямая задача. Но иметь возможность получить доступ к данным и реализовать ее — две большие разницы. Это вовсе не означает, будто пентестер обязательно будет читать данные, к которым у него может появиться доступ. Если еще точнее, то имея административные права к системе, он обязан на этом остановиться, не получая одновременно доступ к заведомо критичным данным, а заказчик должен контролировать действия пентестера. Кроме того, не надо забывать, что в случае критичных систем аудиторы часто работают на тестовых стендах. Однако риск безусловно есть, и в очередной раз следует воспользоваться советом № 1.
Квалификация
Вторым важнейшим условием после доверия является квалификация компании-пентестера.
Дело в том, что о качестве работы аудиторов не всегда свидетельствуют положительные референсы заказчиков, так как далеко не все из них способны объективно оценить результат проведенного у себя пентеста. Чрезвычайно важно понимать, что это за заказчик и какой у него уровень зрелости в столь специфичной области, как проведение пентестов. Способен ли клиент адекватно оценить качество выполненного у него пентеста? Не путает ли он пентест со сканированием?..
Уровень зрелости заказчика, а значит, и доверия к его референсам можно оценить по двум главным признакам:
- Наличие у него собственной команды пентестеров (Offensive Team).
- Длительный опыт работы с ведущими известными в мире компаниями-пентестерами с признанной репутацией.
В этом случае понятно, что даже сто референсов от российских промышленных компаний из второй тысячи даже в подметки не годятся одному референсу о проведенном внутреннем аудите, например, от компании Apple. Поэтому с точки зрения именно квалификации важны отзывы только зрелых заказчиков.
Каковы же основные объективные критерии квалификации аудитора?
- Референсы от заказчиков с высоким уровнем зрелости по отношению к пентестам.
- Референсы за найденные уязвимости от ведущих мировых вендоров (MS, Oracle, SAP, VMWare, Cisco) и веб-сервисов (Google, Yandex). (Самый объективный параметр, который однозначно говорит о том, что компания-аудитор умеет искать неизвестные уязвимости в продуктах серьезных вендоров. Осталось только посмотреть на их качество и количество.)
- Опубликованные (желательно на Западе) исследования на тему поиска уязвимостей (в данном случае речь о технических исследованиях, которые не следует путать с маркетинговыми исследованиями, коими буквально кишит рынок).
- Выступления на ведущих мировых технических хакерских конференциях.
- Глубокая специализация на определенных особо сложных или нестандартных системах (ERP, АСУ ТП и т. п.) с референсами вендоров и зрелых заказчиков (уточняющий критерий для некоторых случаев).
***
Самое главное при работе с аудитором — выстроить всю вышеизложенную цепочку. Какой именно вам нужен пентест, что именно будут ломать и что будет получено на выходе? Какие при этом существуют риски? Каковы критерии выбора? Понимание всей этой относительно несложной специфики пентеста позволит как избежать возможных проблем и недоразумений при его проведении, так и максимально повысить его эффективность.
Опубликовано 25.09.2014