XAMEHA
14.02.2013, 15:12
Всем привет. При исследовании различных WEB-приложений без наличия исходных кодов поиск уязвимостей осуществляется только с белого входа - страниц сайта которые обрабатывают различные запросы от пользователя с параметрами GET, POST, Cookie, Headers, это может быть как и главная страница, так и Ajax запрос, запрос от Flash-приложения где кстати может использоваться не только HTTP и т.п.
В большинстве случаев все параметры тщательно проверяются и уязвимостей просто нет, однако довольно часто и особенно в крупных приложениях существует черный вход - страницы, к которым обращается сервер и парсит из них нужную ему информацию. Конечно не секрет, что многие скрипты поступают таким образом, но если у нас нет никакой информации о том, что делает сервер достаточно проблематично найти какую-либо уязвимость.
В этой теме возможно собрать различные методы исследования из вне таких приложений, типах уязвимостей о которых в данном случае разработчики не осведомлены, далее можно попробовать рассмотреть какое-либо приложение, использующие эту технологию. Основные сложности здесь в том, что обычно мы не можем получить какой-либо информации о использовании данных, ошибок и т.п. особенно если действия выполняются в фоне.
Некоторые вариации уязвимостей в других источниках были названы SSRF (Server-Side Request Forgery) но это не совсем корректно - подделки запросов здесь нет, нам будет удобнее просто рассматривать действия с содержимым страницы на стороне .
Начнем.
A. DoS - Самая простая атака в нашем случае, цель - отказ в обслуживании. Стандартная ситуация, приложение VK загружаемое в ифрейме, к которому передается некоторые параметры:
PHP:
app.php?api_url=http://api.vk.com/api.php&api_id...
Как видим приложению передается api_url на тот случай если адрес скрипта(old_api.php) или домен изменится(vkontakte.ru vs vk.com), далее сценарий приложения подсоединяется к этому серверу и предположим сохраняет информацию о пользователе себе в файл. Если мы передадим ссылку на сервер с большим файлом, да несколько раз обновим страницу, канал сервера будет полностью забит да и места на диске рано или поздно не останется.
Это самое простое, что можно придумать но я не советую так поступать. Другие методы основаны на разборе данных сервером, что мы сейчас и и рассмотрим, цель - передать скомпрометированные ответы с некоторой информацией, которая может использоваться ...
B.Уязвимости можно разделить на 3-категории - уязвимости в парсере, уязвимости в обработчике запросов и туннельные уязвимости где благодаря наличию нескольких уязвимостей предыдущих типов мы можем построить через них туннель до требуемой нам операции.
1.Уязвимости в парсере весьма стандартны - данные не проходят соответствующею фильтрацию и используются далее - в SQL-запросах, запросах к файлам, небезопасным вычислениям, нужно лишь узнать, что используется и каким образом методом проб и ошибок.
Здесь имеет место определить зависимость использования соединения во время парсинга, к примеру в фоновом процессе мы можем иметь инъекцию типа:
PHP:
SELECT*from`news`WHERE id= [SQL_CODE]
и если фоновый процесс разрывает соединение после выполнения запроса мы можем определить время парсинга которое включает выполнения данного запроса.
Если данные используются для вывода, нужно проверить возможность XSS и XXE, последняя из которых возникает при разборе многофункциональными парсерами XML документа, как некоторые советуют использовать на форумах:
PHP:
]>
&data;
';
$doc= newDOMDocument();
$doc->loadXML($data);
echo$doc->getElementsByTagName('antichat')->item(0)->textContent;
Не будем на них останавливаеться - к информации о них лучше обращаться по мере надобности, тем более она доступна в свободном доступе.
2. Уязвимости в обработчике запросов.
I.fsockopen:
fsockopen - Самая простая обертка, за исключением tcp и udp доступны tls, ssl, sslv2 и sslv3 а так-же udg, unix с помощью которых вохможно использовать локальные сокеты, такие как /dev/log но использовать простые файлы невозможно.
После изучения исходников практически не нашел за что можно зацепится, единственное - 4-ый параметр функции отдающий ошибку, которая в будущем может быть занесена в php-файл, БД и т.д. Есть несколько методов возможности передачи текста с нашим содержимым в него, но лишь некоторые позволяют передать спецсимволы:
PHP:
...
//Приоритет имеет первый па раметр, к примеру если ну но использовать порт 0 дл я unix-сокетов это пригодится
@fsockopen("tcp://abc.ru:80",803,$errorNo,$errorSTR);
//PORT abcd",0,$errorNo,$errorSTR);
//int(0) string(43) "Failed to parse address "abcd"
//Однако передачей порта в первом параметре это не о существить, но так-же нужно заметить что воз можно передавать цифровые значения в других систем ах счисления.
...
@fsockopen("tcp://abc.com",9223372036854775808,$errorNo,$errorSTR);//В 64-bit системах такой вариант тоже вызовет ошибку с вы одом параметра
...
var_dump($errorNo,$errorSTR, (int)992337203685477 5089,intval(9923372036854775089), (99233720368547 75089>1));
//Отрицательное число в PHP ожет быть больше одного, возможно при обходе фильт ров это поможет
...
@fsockopen("tcp://[abc.com",80,$errorNo,$errorSTR);
//Вывод в ошибку при разбор е IPv6 адресов
/*
Возникновение так их ошибок имеется и в дру гих сетевых функциях php.
*/
...
II.Разбор после использования cURL. cURL - очень злая штука, во многом благодаря тому, что самолично принимает решения. При её использовании программист обычно забывает про её опасность и клепает ПО из различных примеров.
К примеру задание 33 было основано на этом: /thread363372.html
PHP:
functionopen($url,$data) {//
$this->ch=curl_init();
curl_setopt($this->ch,CURLOPT_URL,'http://'.$url.'/data.php');
curl_setopt($this->ch,CURLOPT_RETURNTRANSFER,true);
curl_setopt($this->ch,CURLOPT_POST,1);
curl_setopt($this->ch,CURLOPT_POSTFIELDS, array('post'=>'true','testdata'=>$data));
returncurl_exec($this->ch);
//CURLOPT_URL, CURLOPT_POST - Это обычные цифорвые кон станты, различающиеся от ерсии к версии.
}
В функции допущена большая ошибка - при наличи в переменной $data строки @/etc/passwd на сервер $url отправилось бы содержимое этого файла.
CURLOPT_POSTFIELDS
- Все данные, передаваемые в HTTP POST-запросе. Для передачи файла, укажите перед именем файла @, а также используйте полный путь к файлу. Тип файла также может быть указан с помощью формата ';type=mimetype', следующим за именем файла. Этот параметр может быть передан как в качестве url-закодированной строки, наподобие 'para1=val1¶2=val2&...', так и в виде массива, ключами которого будут имена полей, а значениями - их содержимое. Если value является массивом, заголовок Content-Type будет установлен в значение multipart/form-data. Начиная с версии PHP 5.2.0, при передаче файлов с префиксом @, value должен быть массивом.
Читать мы можем только доступные файлы:
PHP:
if ((type=php_memnstr(postval,";type=",sizeof(";type=") -1,postval+Z_STRLEN_PP(current)))) {
*type='\0';
}
//А вот этого в документаци и нет, используется при у азании имени файла:
f((filename=php_memnstr(postval,";filename=",sizeof(";filename=") -1,postval+Z_STRLEN_PP(current)))) {
*filename='\0';
}
/* safe_mode / open_basedir check */
if (php_check_open_basedir(postval TSRMLS_CC) | | (PG(safe_mode) && !php_checkuid(postval,"rb+",CHECKUID_CHECK_MODE_PARAM))) {
RETVAL_FALSE;
return1;
}
Пожалуй мы добралиь до атак, которые можно назвать SSRF. Смысл этого заключается в том, что cURL при недостаточной обработке адреса сайта или включенной опции CURLOPT_FOLLOWLOCATION может применить свою интеллектуальность и весьма-корректно обрабатывать запросы на получение локальной или внутри-сетевой информации:
PHP:
file:///etc/passwd (file:// + /etc/passwd)
Здесь есть некоторые исследования: http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html
При анализе проекта нужно посмотреть на ответ сервера при различных видах переадрестации, неправильного ответа сервера, выдаче данных неопределенной длины, больший файлов, MIME-типов.
III.Экзотические функции - анализ DNS записей, WHOIS - Не могу сейчас сказать, что возможно, но это интересная тема для анализа.
Это - краткий обзор, тут не следует делать кучу примеров, интересные темы можно будет рассмотреть далее, прямо здесь, возможно попробовать что-то использовать на практике, ведь каждое ПО - уникальное. Возможно я что-то забыл упомянуть. Предлагайте свои функции, возможно данные возможности используются в некоторых CMS или существуют некоторые сервисы использующие внешние запросы, однако не желательно устраивать здесь взломы.
В большинстве случаев все параметры тщательно проверяются и уязвимостей просто нет, однако довольно часто и особенно в крупных приложениях существует черный вход - страницы, к которым обращается сервер и парсит из них нужную ему информацию. Конечно не секрет, что многие скрипты поступают таким образом, но если у нас нет никакой информации о том, что делает сервер достаточно проблематично найти какую-либо уязвимость.
В этой теме возможно собрать различные методы исследования из вне таких приложений, типах уязвимостей о которых в данном случае разработчики не осведомлены, далее можно попробовать рассмотреть какое-либо приложение, использующие эту технологию. Основные сложности здесь в том, что обычно мы не можем получить какой-либо информации о использовании данных, ошибок и т.п. особенно если действия выполняются в фоне.
Некоторые вариации уязвимостей в других источниках были названы SSRF (Server-Side Request Forgery) но это не совсем корректно - подделки запросов здесь нет, нам будет удобнее просто рассматривать действия с содержимым страницы на стороне .
Начнем.
A. DoS - Самая простая атака в нашем случае, цель - отказ в обслуживании. Стандартная ситуация, приложение VK загружаемое в ифрейме, к которому передается некоторые параметры:
PHP:
app.php?api_url=http://api.vk.com/api.php&api_id...
Как видим приложению передается api_url на тот случай если адрес скрипта(old_api.php) или домен изменится(vkontakte.ru vs vk.com), далее сценарий приложения подсоединяется к этому серверу и предположим сохраняет информацию о пользователе себе в файл. Если мы передадим ссылку на сервер с большим файлом, да несколько раз обновим страницу, канал сервера будет полностью забит да и места на диске рано или поздно не останется.
Это самое простое, что можно придумать но я не советую так поступать. Другие методы основаны на разборе данных сервером, что мы сейчас и и рассмотрим, цель - передать скомпрометированные ответы с некоторой информацией, которая может использоваться ...
B.Уязвимости можно разделить на 3-категории - уязвимости в парсере, уязвимости в обработчике запросов и туннельные уязвимости где благодаря наличию нескольких уязвимостей предыдущих типов мы можем построить через них туннель до требуемой нам операции.
1.Уязвимости в парсере весьма стандартны - данные не проходят соответствующею фильтрацию и используются далее - в SQL-запросах, запросах к файлам, небезопасным вычислениям, нужно лишь узнать, что используется и каким образом методом проб и ошибок.
Здесь имеет место определить зависимость использования соединения во время парсинга, к примеру в фоновом процессе мы можем иметь инъекцию типа:
PHP:
SELECT*from`news`WHERE id= [SQL_CODE]
и если фоновый процесс разрывает соединение после выполнения запроса мы можем определить время парсинга которое включает выполнения данного запроса.
Если данные используются для вывода, нужно проверить возможность XSS и XXE, последняя из которых возникает при разборе многофункциональными парсерами XML документа, как некоторые советуют использовать на форумах:
PHP:
]>
&data;
';
$doc= newDOMDocument();
$doc->loadXML($data);
echo$doc->getElementsByTagName('antichat')->item(0)->textContent;
Не будем на них останавливаеться - к информации о них лучше обращаться по мере надобности, тем более она доступна в свободном доступе.
2. Уязвимости в обработчике запросов.
I.fsockopen:
fsockopen - Самая простая обертка, за исключением tcp и udp доступны tls, ssl, sslv2 и sslv3 а так-же udg, unix с помощью которых вохможно использовать локальные сокеты, такие как /dev/log но использовать простые файлы невозможно.
После изучения исходников практически не нашел за что можно зацепится, единственное - 4-ый параметр функции отдающий ошибку, которая в будущем может быть занесена в php-файл, БД и т.д. Есть несколько методов возможности передачи текста с нашим содержимым в него, но лишь некоторые позволяют передать спецсимволы:
PHP:
...
//Приоритет имеет первый па раметр, к примеру если ну но использовать порт 0 дл я unix-сокетов это пригодится
@fsockopen("tcp://abc.ru:80",803,$errorNo,$errorSTR);
//PORT abcd",0,$errorNo,$errorSTR);
//int(0) string(43) "Failed to parse address "abcd"
//Однако передачей порта в первом параметре это не о существить, но так-же нужно заметить что воз можно передавать цифровые значения в других систем ах счисления.
...
@fsockopen("tcp://abc.com",9223372036854775808,$errorNo,$errorSTR);//В 64-bit системах такой вариант тоже вызовет ошибку с вы одом параметра
...
var_dump($errorNo,$errorSTR, (int)992337203685477 5089,intval(9923372036854775089), (99233720368547 75089>1));
//Отрицательное число в PHP ожет быть больше одного, возможно при обходе фильт ров это поможет
...
@fsockopen("tcp://[abc.com",80,$errorNo,$errorSTR);
//Вывод в ошибку при разбор е IPv6 адресов
/*
Возникновение так их ошибок имеется и в дру гих сетевых функциях php.
*/
...
II.Разбор после использования cURL. cURL - очень злая штука, во многом благодаря тому, что самолично принимает решения. При её использовании программист обычно забывает про её опасность и клепает ПО из различных примеров.
К примеру задание 33 было основано на этом: /thread363372.html
PHP:
functionopen($url,$data) {//
$this->ch=curl_init();
curl_setopt($this->ch,CURLOPT_URL,'http://'.$url.'/data.php');
curl_setopt($this->ch,CURLOPT_RETURNTRANSFER,true);
curl_setopt($this->ch,CURLOPT_POST,1);
curl_setopt($this->ch,CURLOPT_POSTFIELDS, array('post'=>'true','testdata'=>$data));
returncurl_exec($this->ch);
//CURLOPT_URL, CURLOPT_POST - Это обычные цифорвые кон станты, различающиеся от ерсии к версии.
}
В функции допущена большая ошибка - при наличи в переменной $data строки @/etc/passwd на сервер $url отправилось бы содержимое этого файла.
CURLOPT_POSTFIELDS
- Все данные, передаваемые в HTTP POST-запросе. Для передачи файла, укажите перед именем файла @, а также используйте полный путь к файлу. Тип файла также может быть указан с помощью формата ';type=mimetype', следующим за именем файла. Этот параметр может быть передан как в качестве url-закодированной строки, наподобие 'para1=val1¶2=val2&...', так и в виде массива, ключами которого будут имена полей, а значениями - их содержимое. Если value является массивом, заголовок Content-Type будет установлен в значение multipart/form-data. Начиная с версии PHP 5.2.0, при передаче файлов с префиксом @, value должен быть массивом.
Читать мы можем только доступные файлы:
PHP:
if ((type=php_memnstr(postval,";type=",sizeof(";type=") -1,postval+Z_STRLEN_PP(current)))) {
*type='\0';
}
//А вот этого в документаци и нет, используется при у азании имени файла:
f((filename=php_memnstr(postval,";filename=",sizeof(";filename=") -1,postval+Z_STRLEN_PP(current)))) {
*filename='\0';
}
/* safe_mode / open_basedir check */
if (php_check_open_basedir(postval TSRMLS_CC) | | (PG(safe_mode) && !php_checkuid(postval,"rb+",CHECKUID_CHECK_MODE_PARAM))) {
RETVAL_FALSE;
return1;
}
Пожалуй мы добралиь до атак, которые можно назвать SSRF. Смысл этого заключается в том, что cURL при недостаточной обработке адреса сайта или включенной опции CURLOPT_FOLLOWLOCATION может применить свою интеллектуальность и весьма-корректно обрабатывать запросы на получение локальной или внутри-сетевой информации:
PHP:
file:///etc/passwd (file:// + /etc/passwd)
Здесь есть некоторые исследования: http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html
При анализе проекта нужно посмотреть на ответ сервера при различных видах переадрестации, неправильного ответа сервера, выдаче данных неопределенной длины, больший файлов, MIME-типов.
III.Экзотические функции - анализ DNS записей, WHOIS - Не могу сейчас сказать, что возможно, но это интересная тема для анализа.
Это - краткий обзор, тут не следует делать кучу примеров, интересные темы можно будет рассмотреть далее, прямо здесь, возможно попробовать что-то использовать на практике, ведь каждое ПО - уникальное. Возможно я что-то забыл упомянуть. Предлагайте свои функции, возможно данные возможности используются в некоторых CMS или существуют некоторые сервисы использующие внешние запросы, однако не желательно устраивать здесь взломы.