Expression Language Injection

В списке уязвимостей, связанных с различного рода инъекциями (SQL, LDAP, XPath, etc) появилось новое наименование – Expression Language Injection. Новая разновидность инъекций описана в свежем исследовании Стефано ди Паолы (Stefano Di Paola) и Аршана Дабирсиаги (Arshan Dabirsiaghi). Уязвимость затрагивает JSP-приложения, написанные с использованием популярного в этой среде фреймворка Spring MVC. В результате успешной атаки EL Injection может привести к утечке данных как со стороны сервера (пути, значения глобальных переменных, etc), так и пользователя (обход httpOnly, получение идентификаторов сессий). Уязвимость возможна в том случае, когда внутри JSP-тэгов фреймворка Spring используется Expression Language – скриптовый язык, позволяющий получить доступ к Java-компонентам из JSP:

[html]<spring:message scope=”${param.foo}”/>[/html]

В чем заключается уязвимость?
Дело в том, что в Spring MVC выражения Expression Language внутри определенных атрибутов выполняются дважды, поэтому, приложение, получающее входящие данные посредством Expression Language как в примере выше, уязвимо к внедрению произвольных EL-выражений.

FuzzDB – умный фаззинг

Прежде чем начать рассмотрение проекта FuzzDB, нужно сказать пару слов о самом фаззинге. Итак, фаззинг (англ. fuzzing) – это способ тестирования приложений, в основе которого лежит передача некорректных, случайных или непредвиденных логикой программы данных. Чаще всего фаззинг применяется при blackbox-тестировании, т.е. в условиях отсутствия исходных кодов приложения. У фаззинга имеются как отрицательные, так и положительные стороны. К числу первых можно отнести низкую скрытность процесса тестирования, так как после проверки всех возможных параметров остаются следы, которые невозможно не заметить, если, конечно, проводится мониторинг журналов и нагрузки на систему. Среди положительных моментов выделяется полная автоматизация процесса, позволяющая значительно сэкономить время. Эффективность фаззинга в значительной степени зависит от программы-фаззера и базы, с которой она работает. Говорить, что фаззинг лучше метода ручного точечного тестирования или наоборот, некорректно, так как оба метода должны дополнять друг друга при blackbox-пентесте.

Универсальный XSS-вектор

Поиск XSS довольно трудоемкое занятие, так как необходимо учитывать множество контекстов, в которых может выполниться js-код, например внутри одинарных или двойных кавычек, внутри различных атрибутов и т.д. Для тех, кому надоело перебирать возможные варианты, пригодится следующий универсальный xss-вектор, который выполнится в любом контексте, т.е. его можно поместить в любой параметр и не беспокоится о том, в какой участок кода он в конечном счете попадет:

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;’/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

Размер немного великоват (428 байт), но это в любом случае более продуктивный вариант, чем "><script>alert()</script>.
Для удобного использования в Opera можно добавить данный вектор как заполнитель формы (Меню – Настройки – Общие настройки – Формы), для Firefox с плагином TamperData можно создать новый элемент контекстного меню для перехватываемых пакетов.

Credits: Gareth Heyes @ thespanner.co.uk

CMS Explorer

При проведении пентестов очень часто приходится иметь дело с такими известными CMS как Joomla, WordPress и Drupal. Эта тройка составляет значительную часть от общего количества используемых в сети систем управления контентом с открытым исходным кодом. Серьезные уязвимости, как правило, присутствуют только в древних версиях, поэтому на первый план выходят самостоятельно установленные плагины, безопасность которых может быть намного более далекой от идеала, чем в ядре системы.
Инструмент CMS Explorer служит для определения плагинов в перечисленных выше CMS. Он представляет собой небольшой perl-скрипт с набором списков плагинов для каждой из CMS. Наборы легко обновляются, указав ключ -update. Утилита также сканирует используемые темы оформления, но обычно это не несет никакой пользы. Чтобы отключить сканирование тем, в исходном коде нужно вручную указать значение соответствующего элемента массива ($OPTIONS{‘checkthemes’} = 0;), так как автор не предусмотрел такой опции при запуске.
Отличительной особенностью скрипта является автоматический поиск на предмет уязвимостей по базе данных OSVDB для найденных плагинов. Однако для использования поиска необходимо иметь ключ к API сервиса. Впрочем, получить его может любой желающий, пройдя регистрацию. К сожалению, присутствует одно ограничение – сервис позволяет сделать только 100 запросов в день. Получив ключ, нужно создать в папке с CMS Explorer файл osvdb.key и внести значение.

Новые способы обхода WAF и PHP эксплоиты

Стефан Эссер снова порадовал очередной порцией свежей информации о новых уязвимостях в своих выступлениях сразу на двух мероприятиях (RSS09 и Powerofcommunity). В частности, он поделился интересными способами обхода таких WAF как mod_security и F5 BIGIP ASM, информацией о возможных уязвимостях в продуктах, работающих на Zend Framework, а также о том, как можно использовать уязвимость, связанной с прерываниями внутренних функций в PHP, несмотря на выпущенные фиксы. Итак, обо всем по порядку.

Опубликован OWASP Top 10 2010 (RC1)

OWASP, открытый проект безопасности приложений, накануне представил для обсуждения новую версию списка десяти самых опасных угроз. В сравнении с OWASP Top 10 2007 изменениям подверглись четыре позиции. Меня удивило, что инклуд-баг Malicious File Execution был исключен из списка якобы в силу того, что PHP стал более безопасным по умолчанию. Видимо Jeremiah Grossman и компания не учли, что LFI (local file include) по степени риска теперь можно практически приравнять к RFI (remote file include). Возможно к 2010 бажных версий PHP будет намного меньше, но, несмотря на это, косячить в коде будут всегда. А может обнаружатся еще какие-нибудь новые уязвимости 🙂

Итак, сама десятка самых опасных угроз:

  1. A1 Injection (всякого рода инъекции, в т.ч. SQL, LDAP и т.д.)
  2. A2 Cross Site Scripting (не потерявший актуальности XSS)
  3. A3 Broken Authentication and Session Management (ошибки в архитектуре аутентификации и управления сессиями)
  4. A4 Insecure Direct Object References (незащищенные ресурсы и объекты, можно вспомнить случай с SVN)
  5. A5 Cross Site Request Forgery (CSRF)
  6. A6 Security Misconfiguration (небезопасная конфигурация окружения, различных фреймворков, платформы)
  7. A7 Failure to Restrict URL Access (несанкционированный доступ к функционалу, требующему особых привилегий – например обход проверки c помощью двойного слэша “//” в URL для получения доступа к управлению блогом в WordPress)
  8. A8 Unvalidated Redirects and Forwards (открытые редиректы, которые ведут к фишингу, HTTP Response Splitting и XSS)
  9. A9 Insecure Cryptographic Storage (небезопасное хранение важных данных)
  10. A10 Insufficient Transport Layer Protection (недостаточная защита данных при их передаче на транспортном уровне, например по HTTP вместо HTTPS).

Надеюсь, это неокончательная версия Top 10, ждем следующий релиз-кандидат.

PHP и зашифрованный код

Обфускация и шифрование кода в веб-приложениях обычно применяется с целью затруднения поиска уязвимостей, скрытия участков кода, осуществляющих проверку лицензионного ключа, невозможности редактирования, а также для защиты важных данных, например для подключения к базе данных. Методы шифрования могут быть самыми разными. В первую очередь проигрывают реализации обфускации на самом PHP – расшифровать такой код задача довольно тривиальная, так как в большинстве случаев ограничивается перехватом пары eval()’ов. Существуют даже универсальные инструменты для расшифровки, например вот этот скрипт на PHP. Что касается более продвинутых средств, таких как Zend Guard и ionCube, то дела здесь обстоят ничуть не лучше. Программа для расшифровки скриптов, закодированных Zend’ом, уже давно появилась в публичном доступе, а расшифровка ionCube также возможна, но пока только платно.

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

SVN позволяет получить доступ к исходному коду

SVNСегодня на habrahabr.ru был опубликован весьма интересный пост, рассказывающий о том, как были получены исходные коды нескольких тысяч русских веб-проектов, включая yandex.ru, rambler.ru, mail.ru, rbk.ru, а также самого habrahabr.ru. Последствия находки, на первый взгляд, действительно потрясающие. Все строится на вполне очевидном факте – повсеместном использовании систем для контроля версий aka SVN. Дело в том, что на сайтах, где используется SVN остаются метафайлы, в которых хранится вся структура проекта. В дополнение к этому, все файлы получают расширение .svn-base, что делает доступным их исходный код при прямом обращении. Разумеется, все самые популярные интернет-проекты на момент выхода поста уже исправили уязвимость, однако зарубежные сайты остаются подверженными раскрытию исходного кода. Стоит сказать, что, несмотря на огромную популярность SVN, по тем или иным причинам уязвимы далеко не все сайты. Согласно статистике, которую любезно предоставили авторы, только 0,14% просканированных сайтов были уязвимы. Тем не менее, недооценивать значение бага нельзя, посмотрим, к чему это приведет в масштабах всего интернета.
http://habrahabr.ru/blogs/infosecurity/70330/

Сканнер уязвимостей CMS Drupal

drupalscan

Не секрет, что идеальных сканнеров уязвимостей не существует, особенно если такой сканнер стремится быть универсальным. Как правило, чем выше поле действия сканнера, тем ниже скорость работы, а также процент его эффективности. Эту идею подтверждает проект OWASP Joomla Vulnerability Scanner, который нацелен на самую популярную CMS. Испытав сканнер, я остался очень доволен результатами и решил написать нечто подобное для другого не менее известного продукта – CMS Drupal.

Drupal заслуженно является одной из самых безопасных CMS. Поддержка безопасности CMS в отличие от, к примеру, WordPress находится на более высоком уровне благодаря активному тестированию CMS специальной группой Drupal Security Team и своевременному выпуску патчей и апдейтов, что подтверждается доверием пользователей. Тем не менее, как и у любого популярного веб-приложения, у Drupal есть свои уязвимости, что и послужило основнанием для создания простого сканнера.

Презентация способов обхода XSS фильтров на BlackHat

BlackHatЕжегодно проводимая конференция BlackHat является одним из самых значимых событий в сфере информационной безопасности. В этом году эксперты из множества стран собрались в Лас Вегасе, чтобы показать и обсудить результаты своих исследований. Разумеется, не обошли стороной веб-безопасность – наиболее интересное выступление дали Эдуардо Вела (Eduardo Vela) и Дэвид Линдсэй (David Lindsay) на тему реализации XSS-атак в условиях WAF. Были затронуты практически все самые известные программные продукты, связанные с защитой от XSS как на стороне сервера, так и клиента: PHP-IDS, Mod_Security, XSSFilter в IE8, NoScript. Наиболее слабым оказался Mod_Security, поэтому авторы доклада рекомендуют использовать PHP-IDS вместо него. XSSFilter, изначально неспособный защитить от всех типов XSS (по словам разработчиков из MS в силу производительности браузера), также был повержен несколькими новыми XSS-векторами. На уровне клиента докладчики посоветовали использовать Firefox+NoScript, хотя и для последнего были найдены способы обхода. Ознакомиться с материалами выступления можно на сайте одного из авторов. Презентация получилась немалой – более 100 страниц. Много внимания уделено новым XSS-векторам, некоторые из которых просто поражают воображение. Только взгляните:

(É=[Å=[],µ=!Å+Å][µ[È=-~-~++Å]+({}+Å) [Ç=!!Å+µ,ª=Ç[Å]+Ç[+!Å],Å]+ª])() [µ[Å]+µ[Å+Å]+Ç[È]+ª](Å)

($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''
+$)[_/_]+$_[+$])])()[__[_/_]+__[_+~$]+$_[_]+$$](_/_)

За этим, казалось бы, беспорядочным набором символов кроется всем известный javascript:alert(1);. Кроме того, показаны примеры XSS, которые могут возникнуть в будущем с внедрением HTML5, а также уязвимость в PHP-функции utf8_decode(), позволяющая эксплуатировать неправильную обработку UTF-8. В целом, доклад, если не инновационный с точки зрения способов обхода, то уж точно приносящий много пищи для размышления, как разработчикам, так и взломщикам.