Dirty Magic @ Penetration Testing

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

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

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

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

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

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

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

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

За что мне дали баллов на ZeroNights HackQuest

Все, должно быть, уже в курсе, что на берегах Невы в эту пятницу, 25 ноября, состоится первая питерская конференция, посвященная практическим аспектам ИБ — ZeroNights. Организаторы — группа Defcon Russia.

Для нагнетания правильной обстановки и прочего 3,14-ара группой добровольцев, состоящей из Владимира Воронцова, Алексея Синцова и Дарта Вейдера Dirk’а van Veen’а, был разработан и запущен HackQuest.
Спешу рассказать о заданиях, которые я решил.

Забавный дуализм в оценке рисков ненаправленных атак на сайты

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

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

До недавних пор я считал, что в деле защиты от ненаправленных атак работает принцип двух товарищей и медведя. Принцип гласит, что для того, чтобы не быть съеденным медведем, не надо бежать быстрее медведя, а достаточно бежать быстрее своего товарища. В переложении на веб-безопасность это значит, что защищенность сайта должна быть немного выше, чем средняя защищенность других сайтов того же класса в той же гео-зоне. Идея понятна: злоумышленники, реализующие ненаправленные атаки, добиваются массовости. Следовательно, у них есть понимание того, когда анализ очередной цели стоит прекратить (ибо он становится не cost-effective, т.е. прибыль с данного сайта не покроет ресурсы, потраченные на его взлом) и перейти к следующей, вероятно более уязвимой цели.

Так вот на днях меня посетило озарение, что это не всегда так.

Веб-безопасность: прогноз на 2011 год

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

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

• Незрелость технологий (если мне не изменяет память, только j2EE снабжалась достаточным количеством документации по архитектуре веб-приложений, методикам разработки и пр.). Таким образом, всему сообществу пришлось вырабатывать свои best practices, наступая на одно и те же грабли.
• Отсутствие стандартных компонентов и фреймворков. В результате этого приходилось изобретать свои велосипеды. Мы и сейчас можем увидеть, что очередная студия веб-дизайна нет-нет, да и попытается впарить свою CMS заказчику. Практически у каждого веб-программиста были свои разработки. Что же в этом плохого?
  Рассмотрим две ИС: одна написана под заказ, другая — использует продукты open source сообществ. Владельцы второй ИС получают в качестве бонуса наработки всего сообщества, которое самоорганизовалось вокруг продукта. Т.е. при наличии процедур по обновлению ИС, можно ожидать, что ее качество (а в том числе и защищеность) будет постоянно повышаться. Обратной стороной медали является повышенное внимание со стороны злоумышленников к популярному продукту. Т.е. нельзя исключать риски применения 0-day уязвимостей в отношении данной ИС. Но, на мой взгляд, преимущества забарывают недостатки. Вернемся теперь к самописной ИС. Непрерывного процесса повышения качества нет, ибо нет сообщества. Следовательно, уязвимости в продукте будут обнаруживать в лучшем случае white hat’ы с последующим responsible disclosure, а в худшем (и более вероятном) случае — злоумышленники. Т.е. шанса на исправление ошибки до реализации атаки у владельцев такой ИС не будет.
• Ситуация еще больше подогрелась огромным спросом на специалистов в области веб-разработки и наличием технологий с низким порогом входа (например, PHP, ColdFusion). Т.е. низкоквалифицированные работники тоже были востребованы и писали server-side код.

Что мы наблюдаем сейчас?

Анализ защищенности vs оценка защищенности vs анализ безопасности

Этот пост я решил написать, прочитав описание курса «Анализ и оценка защищенности Web-приложений». Вопрос, которым я задался, звучит так: «чем отличается анализ защищенности от оценки защищенности? И чем это отличается от анализа/оценки безопасности?» Это разные услуги или одно и то же?

Безопасность — как фактор качества веб-приложений

Этот пост меня побудило написать недавнее выполнение оценки безопасности одного веб-проекта.
Случилась ситуация ровно, как было описано в примере (см. первое примечание): в исходном коде содержался SELECT, в который попадал параметр из HTTP-запроса без обработки. Однако, в результате анализа окружения, в котором работало веб-приложение, стало ясно, что в исходном коде найдена не уязвимость, а всего лишь недостаток. Тем не менее, я его поместил в итоговый отчет. Реакция разработчиков была, как в шутке :)

Какая технология разработки веб-приложений самая безопасная?

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

Давайте попробуем задаться правильным вопросом: «какая технология (и/или фреймворк) сделает разработку уязвимого приложения максимально затруднительным?» Речь тут, конечно, идет о трудностях привнесения технических уязвимостей, ведь никакой фреймворк не предотвратит внесение уязвимостей бизнес-логики.

Итак, какой же фреймворк будет мешать разработчикам привносить уязвимости?

РусКрипто’2010

Прошла неделя с нашего с Денисом выезда в пансионат «Солнечная Поляна». Выехали в 4 часа в четверг, потому до места назначения (перед глазами встают картинки из одноименного фильма :)) доехали быстрее, чем порой едешь на работу по Москве. Мысли об относительности мигом настраивали на научный лад.