Архив

Posts Tagged ‘disclosure’

Dirty Magic @ Penetration Testing

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

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

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

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

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

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

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

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

Реклама

Как наши читатели помогают находить уязвимости

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

Сама уязвимость стара как мир: Http referer leakage + отсутствие авторизации.

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

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

Смотрим веселые картинки под катом. Тег «Далее»

Поисковики отакуэ — анонимность опасносте!

Не успел утихнуть скандал с раскрытием СМСок Мегафона, не успели обманутые жены и мужья подать заявление на развод, как грядет новая серия неприятных минут для пользователей секс-шопов и прочих радостей жизни.
А все дело в том, что в Яндексе можно искать статусы доставки заказов некоторых Интернет-магазинов.

Получается примерно вот так:
Тынц
Выдача Яндекса со статусами заказов

Тынц
Кое-кто скоро получит много писем

Тынц
И этот тоже!

Пользовался онлайн секс-шопом? Жди на почту шутки, подколки и всякие увлекательные предложения уже завтра!

Метки: ,

CSRF в обход заголовка X-Requested-With

До недавнего времени хорошей защитой от CSRF-атак при активном использовании в приложении XHR-запросов считалось добавление в запрос заголовка

X-Requested-With: XMLHttpRequest.

Логика простая: коль скоро браузеры обеспечивают (окей, должны обеспечивать) same origin policy, то у атакующего не должно получаться построить кросс-доменный запрос с заданным заголовком. Многие сайты и фреймворки (в т.ч. Django, Ruby on Rails) использовали именно этот метод защиты от CSRF.
И все было хорошо до тех пор, пока товарищ Felix Gröbert из Google Security Team не нашел комбинацию условий, при которых злоумышленник сможет легитимно (т.е. не используя баги браузеров) осуществлять кросс-доменные запросы с заданным заголовком (в нашем случае — это X-Requested-With: XMLHttpRequest).
Детали атаки пока не разглашаются, но производители фреймворков вовсю выпускают патчи.

В общем, настоятельно рекомендуется:
— всем пользователям фреймворков Django и Ruby on Rails установить обновления безопасности;
— всем вычеркнуть из контрмер против CSRF использование заголовка X-Requested-With.

Update. Описание принципа атаки.

P.s. Offtopic. Также рекомендую посмотреть вот это творение от небезызсвестного Михаила Залевского (Michal Zalewski).

О трудностях обеспечения ограничений демо-лицензии у веб сканеров

Ни для кого не секрет, что у основных игроков на рынке коммерческих веб-сканеров цены огого: например, базовая лицензия для IBM AppScan SE — примерно 15 000$ за год. Как и для большинства дорогих продуктов, производители сканеров предусматривают возможность пробного использования. Соответственно, перед ними встает интересная задача: с одной стороны надо показать всю функциональность во всей красе, а с другой надо сделать так, чтобы этой функциональностью нельзя было воспользоваться для анализа произвольного веб-приложения без покупки лицензии.
Во всех известных мне сканерах эта задача решена одинаково: в пробной версии можно сканировать только специальные веб-приложения, расположенные на хостах, имена которых забиты в лицензию. Например, Acunetix дает сканировать только два веб-приложения: http://testasp.acunetix.com/ и http://testphp.acunetix.com/.
Любознательный пентестер тут же задастcя вопросом: как же в сканерах обеспечиваются эти ограничения? Тег «Далее»

Метки: