Главная > Uncategorized > Dirty Magic @ Penetration Testing

Dirty Magic @ Penetration Testing

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

Чтобы не было разносудов, сразу скажу, что под пентестом я понимаю получение некоторого уровня доступа к заданному ресурсу при заданных ограничениях. Например,
— получить доступ к документам с грифом ДСП;
— получить максимальные привилегии на одном из сетевых устройств в ядре;
— получить root в кластере процессинга и т.п.
Главное, что вопрос полноты, как при аудите, не стоит.

А теперь самое вкусное — это ограничения. Перечислю их по порядку от банальных до более тонких:
— время — например, под атаку отводится 24 часа, после чего Game Over @ Jigsaw Movie;
— методы воздействия — технические, физические, социальная инженерия;
— объекты воздействия — ломайте как хотите, а узел X не троньте;
— ресурсы и мотивация потенциальных злоумышленников.

И вот тут начинается самое интересное. Команда высококлассных пентестеров обладает заведомо большей квалификацией и набором инструментов (в том числе платных, за 100500$$), чем среднестатистический вероятный Интернет-проходимец.

Теперь представим себе такую ситуацию:

  1. Я заказываю пентест своей корпоративной сети и сервисов, оговаривая профиль предполагаемого нарушителя (в профиль входит мотивация, квалификация, доступные ресурсы).
  2. Пентест делает коммерческая фирма, которая хочет все работы выполнить с минимальными издержками. Так что пентестеры p0wn’ят мою сеть, например, через DNS Rebinding, переходят к режиму «белого ящика», находят уязвимость, которая подпадает под профиль нарушителя, обозначенный в договоре — вуаля!
  3. С одной стороны — да, получается, что тестируемая сеть не защищена от ожидаемых потенциальных нарушителей — есть конкретная уязвимость. С другой стороны мне абсолютно не понятно, будет ли уровень мотивации и квалификации потенциального злоумышленника, которого я ожидаю, достаточным для того, чтобы откопать и проэксплуатировать найденную уязвимость именно в режиме черного ящика. И моделирование именно такого процесса я ожидал, а не применение «ломика в рукаве»!

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

Всех с наступающим!

Реклама
  1. 30.01.2012 в 03:50

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

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

    В реальной жизни же непонятно, кто и как должен фильтровать технологии на «доступные» и «недоступные». Где гарантия, что технология за 100500$$, завтра не станет доступна первокласснику? Даже, если такие гарантии имеются, кто и на каком основании будет предоставлять их заказчику, который вообще не обязан вникать во все эти тонкости?

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

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

  2. 30.01.2012 в 11:36

    >>Не проще ли с точки зрения заказчика порадоваться, что деньги были потрачены не зря

    А как убедиться в том, что деньги потрачены не зря? Но это даже второй вопрос. Первый вопрос — это как определить достаточный бюджет и scope пентеста?

    >>При этом задача должна ставиться не как «получить доступ к документам с грифом ДСП», а как «вероятность обнаружения вектора атаки в течение времени X специалистом уровня Y».

    А чем второе отличается от первого с оговоренной моделью нарушителя?

  3. 01.02.2012 в 15:45

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

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

    • 01.02.2012 в 16:19

      Ну с точки зрения идеи пентеста, как она прописана во всяких умных источниках, все понятно. Как там получается, если плясать от печки:
      — Изначально надо обосновать затраты на ИБ и эффективность набора внедряемых мер. Для этого делаем анализ и оценку рисков.
      — После внедрения мер и процессов обеспечения ИБ хочется провести их тестирование — мол, соответствует ситуация задуманному или нет? При этом хочется сделать это не за огромные деньги, а за приемлемые. Тут-то и появляется весь такой в белом пентест.

      Другое дело, что весь процесс оценки рисков настолько плохо формализуем, что следствием этого является неформальная постановка задачи на пентест. Отсюда — semantic gap.

  4. 26.03.2012 в 00:30

    Если пен-тестер выше левелом, чем скрипт-кидис (а это условный факт), то по любому — все вектора модели типа «проходимец» войдут в подмножество все проблем, что будут выявлены при пен-тесте. Зачем искать «меньше»? Зачем НЕ искать 0дэи?( об этом как раз недавно тут говорил на конференции одной)

    Про поиск уязвимостей «белым ящиком» после того, как были повышены привилегии (у нас такая штука называется «про-активный аудит») — это фишка. Вообще, любой «атакующий» в здравом уме и доброй памяти, воспользуется любыми повышенными привилегиями, что бы получить БОЛЬШУЮ информацию о системе и других уязвимых местах (на будущие типа). Возможно это выглядит не честно. Но в хорошем отчете по пен-тесту все эти факторы отображаются. Типа как была найдена, вероятность эксплуатации и тд. Так что не вижу проблем 8) P.S. Модель нарушителя (как правило и не одна) всегда включается в ТЗ, в отчет и со всеми соотвествующими выводами и привязками о вероятности эксплуатации, векторах атак, возможными угрозами и т.д.

    • 26.03.2012 в 00:38

      Alexey Sintsov (@asintsov) :

      Зачем искать “меньше”? Зачем НЕ искать 0дэи?( об этом как раз недавно тут говорил на конференции одной)

      Ага, давай искать во всем стеке стандартных компонент: CMS (WP, например) -> Платформе (PHP с внешними либами) -> Веб-сервере -> ОС и стеке протоколов, а заодно и на маршрутизаторах, которые на пути попадуться! :)

      Я понимаю, что аналогии ложны, но это как городскую машину типа матиса проверить на краш-тест по требованиям формулы-1.

      Ты пишешь про отчет — все справедливо. А я пишу, о чем надо подумать при заказе

      • 26.03.2012 в 11:07

        Окей. При заказе — да. Стоило бы определиться, с этим я согласен 8)

  5. 26.03.2012 в 00:36

    Как убедиться….

    1) В отчете должен быть список проведенных мероприятий…
    2) В отчете должен быть список используемы методик (фаззинг, бин-анализ, анализ кода, эвристика — что где, сколько, какой глубиной…)
    3) В отчете должны быть описано, почему что-то было про эксплуатировано, а что-то нет.
    4) В отчете должны быть описаны все «места», где были проведены работы по поиску из пункта 1.

    и много что ещё…

    Тогда заказчик видит и полноту работ в скоупе, а не только кол-во уязвимостей, шеллов, и взломанных у чёток 8)

    • 26.03.2012 в 00:39

      Речь идет о предварительных работах:
      — как документацию на конкурс писать при объявлении конкурса на пентесты?
      — как отбирать исполнителей по их заявкам?
      — как ТЗ прописывать?

      • 26.03.2012 в 01:03

        А…это, ну тут дело в «заказчике». Как он ЭТО понимает и видит.

        — Заказчик определяет чего он боится, ну тупо — «атаки из интернет», «анонимуса», «инсайда!».
        — Заказчик определяет скоуп.
        — Заказчик смотрит — что у него уже есть. Процессы, служба ИБ, служба ИТ, кто за что там отвечает, что там ещё можно и нужно сделать — документация, политики и тд. Определяет что ДАСТ ему пен-тест и что он будет делать с отчетом потом 8) ТО есть должен быть процесс. Причем процесс, ну типа СУИБ, должен быть уже налажен!
        — Пишется доки для конкурса и ТЗ:
        — Цели
        — Скоуп
        — Модели нарушителя
        — Особые извращения (особые страхи и ожидаемые угрозы)
        — Доп требования. (сроки, особые узлы, требования к проведениям работ, например особо хотим проверить наш ActivеX плагин, что бы нашим клиентам риски снизить)
        — Желаемый результат (отчет с тем-то и тем-то, а ещё что бы так-то и так-то)
        — Требования к заказчику (опыт, люди, цвета логотипа ;) и тд.)
        — еще что-то забыл….

        Отбирать проще простого, особенно в России… исполнителей не так много, был бы «настоящий» рынок. Можно стенд с испытанием повесить в инет, назначать время для каждого кандидата, а потом логи смотреть — кто как и что делал 8)

  6. 26.03.2012 в 00:45

    Хотя проактивка не всегда честная штука. Это правда ;) Но это очень сильно зависит от уязвимости которая была найдена таким способом. Например, некоторые уязвимости без проактивки не возможно найти. А другие можно найти несколькими разными способами. Но больше важна тут вероятность эксплуатации (с позиции используемой модели нарушителя).

    P/S/ что-то я заспамил твой блог… Мысли вечером плывут медленно. Напишу одно, отправлю… а уже и добавить хочется ;)

    • 26.03.2012 в 00:50

      Ну ты же понимаешь, что вероятность и вероятность — могут быть двумя большими разницами, как повернешь.
      В принципе, у экспертного пентестера есть куча различных способов представить отчет заказчику так, что комар носа не подточит — все завсиит от его настроения и мотивации :)
      Потому и Dirty Magic (BTW, навеяно известной песней группы offspring).

  7. 26.03.2012 в 01:07

    Когда детали баги и проверочные данные есть в отчете НИКТО и НИЧТО не мешает заказчику проверить адекватность оценки.

    • 26.03.2012 в 01:10

      Погоди. Ты пишешь:
      > Но больше важна тут вероятность эксплуатации (с позиции используемой модели нарушителя).

      Давай формулу в студию! Я готов поспорить с адекватностью _любой_ формулы оценки вероятности :) Именно в этом мой point и есть (см. рассуждения про оценки рисков выше)

      • 26.03.2012 в 01:19

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

        + бинарная, по результатам пен-теста — была про эксплуатирована или нет. Тут можно спорить в случае, если проникновения не было 8)
        + экспертная — с экспертной оценкой спорить сложно, хе-хе…

        Итого, в среднем, три оценки, которые помогут понять заказчику, что по чем, + непосредственно само описание уязвимости и вектор использования. Что в финале вообще открывает глаза на истину и прозрение сути проблемы 8)

  8. 26.03.2012 в 09:26

    Вот ты сам себе противоречишь.
    Сначала пишешь:

    Alexey Sintsov (@asintsov) :

    Когда детали баги и проверочные данные есть в отчете НИКТО и НИЧТО не мешает заказчику проверить адекватность оценки.

    а потом признаешь, что шансов проверить у него вообще-то нет, да и метод оценки in the first place так себе:

    Alexey Sintsov (@asintsov) :

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

    Итого, в среднем, три оценки, которые помогут понять заказчику, …
    Что в финале вообще открывает глаза на истину и прозрение сути проблемы 8)

    Я хочу, чтобы оценка, сделанная в пентесте, была валидируемая. Ты (и пока никто ;)) мне не можешь привести конкретику, связанную с подсчетом вероятности в заданной модели нарушителя.
    В CVSS2 нет про вероятность и нет про модель нарушителя, экспертная оценка не валидируема, бинарная — вообще не оценка (или оценка чего-то другого) :)

    • 26.03.2012 в 11:40

      Как ты себе представляешь такую формулу? И вообще, будем честны, использование в модели нарушителя поле «квалификация» — очень условно. И часто не оправдано. Самое правильное принимать как есть «Пять хакеров, с такой квалификацией как у этих нердов из компании Х, которые будут ломать мою систему А в течении Н дней из сети Интернет с нулевым знанием о ней.». Тогда «квалификация» в модели будет прямо соответствовать реальной ситуации, а не абстрактному коню…

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

      CVSS2 есть, косвенные. Типа Access Complexity. Доп. условия прямо влияют на вероятность, снижая её. Соответственно снижается цифровое значение CVSS2. Но это к делу отношение не имеет. Это без привязки к модели. CVSS2 только для одной модели делалось — скрипт-киддис из Интернет.

  9. 26.03.2012 в 09:37

    Alexey Sintsov (@asintsov) :

    А…это, ну тут дело в “заказчике”. Как он ЭТО понимает и видит.

    — Заказчик определяет чего он боится, ну тупо – “атаки из интернет”, “анонимуса”, “инсайда!”.
    — Заказчик определяет скоуп.

    – Требования к заказчику (опыт, люди, цвета логотипа ;) и тд.)
    – еще что-то забыл….

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

    А на вопрос, надо искать 0day или нет — ответ простой, но бесполезный: все зависит от заказчика :)

    Когда я дискутирую на эту тему, всегда в качестве аргумента задаю следующий вопрос: «Для всех ли заказчиков будет полезен факт проникновения в сеть и повышения там привилегий через 0day (который знает только консалтер и больше никто) в платформе .NET?»
    На мой взгляд, многие заказчики должны приходить в ярость и вопрошать в ответ: «и что нам с такими выводами делать??»
    И, предполагая такую реакцию, подрядчики просто не сообщают о 0day, предпочитая находить другую уязвимость (уже методом white-box), которая позволяет достичь того-же, что и заготовленная.

    • 26.03.2012 в 11:49

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

      Штука типа — знает только консалтер и больше ни кто, вообще не имеет право на жизнь. Сегодня только ZDI и Microsoft знают о RDP PoC — а завтра весь Интернет 8)
      + Что нашел консалтер, может найти, то и другой… это вопрос тонкий и китайский. Но замалчивать, вот уж точно, что не верно… Особенно о RCE.
      C LPE так же. Смысл молчать? Если заказчик НЕ ЗНАЕТ, что делать — это говорит лишь об уровне зрелости заказчика, мы можем лишь помочь — что мы и делаем. Пишем вендору. сообщаем о 0дэй проблеме. Предлагаем workaround. Главное предоставить решение. Это почти всегда возможно. В конце концов — принятие риска — то же решение. Но решать за клиента нельзя. Пусть сам решает, ты будь честен и предложи все варианты 8)

      • 26.03.2012 в 14:13

        Alexey Sintsov (@asintsov) :

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

        И это поддерживаю! Но надо быть готовым к вопросам о том, как это ложится на scope исследования и страхи заказчика.

        Я-то (ты может это не понял) с самого начала очень скептически отношусь как к количественным, так и к качественным оценкам.

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

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

  10. 26.03.2012 в 14:04

    Alexey Sintsov (@asintsov) :

    Как ты себе представляешь такую формулу? И вообще, будем честны, использование в модели нарушителя поле “квалификация” – очень условно. И часто не оправдано. Самое правильное принимать как есть “Пять хакеров, с такой квалификацией как у этих нердов из компании Х, которые будут ломать мою систему А в течении Н дней из сети Интернет с нулевым знанием о ней.”. Тогда “квалификация” в модели будет прямо соответствовать реальной ситуации, а не абстрактному коню…

    Ну это же ты завел речь о вероятностях, а не я :)
    Я с самого начала согласен с тем, что вероятность ничего не скажет заказчику. Как и согласен с тем, что ты написал «Самое правильное принимать как есть» без дополнительных экстраполяций.

    • 26.03.2012 в 15:43

      Вероятность — условное выражение, для «доверительного» чтения отчета. Так проще воспринимать. Про точность такой оценки все понятно, но все же в некотором приближение она верна.

      Andrew Petukhov :
      Но это – высший пилотаж. Потому сек-фирмам проще скатиться в раздувание трудозатрат, выполнение ненужных работ и предложение решений со своей наценкой (см. Dirty Magic).

      Такой щит может быть, смотря с кем свяжешься. Особенно интеграторы рулят в этом плане ;)

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: