SQLi Web уязвимости Взлом Обучение

Атака на web приложение для самых маленьких. Методичка и стандартные сценарии

Атака на web приложение для самых маленьких. Методичка и стандартные сценарии

Мы уже написали немало про атаки на web приложения. Но до тех пор пока в сети существуют уязвимые приложения – найдётся и работенка для редтимера. Поэтому мы будем повторяться и писать до тех пор, пока ты не “отшлифуешь” свои навыки.

В этой статье мы вернемся к “азам” и рассмотрим основны атак на веб приложения. Пройдёмся по таким темам как:

Из чего состоит типичное WEB-приложение

Цели атакующего

Изначально атакующий хочет получить web-shell.

Что такое web-shell?

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

Также хакера может интересовать БД (база данных) веб-приложения, например, если это интернет-магазин, то в ней могут храниться данные банковских карт. Также в базе данных могут находиться логины и пароли (бывает и в открытом виде) пользователей, в том числе и для администратора сайта. Ну и само собой в БД могут находиться очень важные файлы, содержащие в себе какую-либо конфиденциальную информацию или тайну. Соответственно, целью хакера становится копирование (слив, дамп) базы данных к себе.

Следующий пункт, к которому стремится хакер — это получение шелла на сервере. Что даёт шелл? Шелл даёт возможность управлять непосредственно самим сервером, на котором находится веб-приложение, создавать директории, менять какие-либо правила, оставлять свои зловредные программы, например, для майнинга криптовалюты, сниффинга различных данных, добавление взломанной машины в ботнет. Или он может использовать эту машину для атаки на внутреннею сеть (если таковая имеется).

Финальная цель – это получение root-доступа к машине. Это означает, что хакер имеет полный контроль на сервере и может делать с ним абсолютно всё, вплоть до полного захвата машины.

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

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

Основной набор уязвимостей и атак описывается в ежегодном отчёте компании OWASP, который называется OWASP TOP 10. Данный топ, представляет собой список самых часто встречающихся в этом году уязвимостей.

В данном топе описываются самые часто встречающиеся за этот год уязвимости и атаки, найденные или проведённые в веб-приложениях. Почти всегда на 1 месте стоят – SQLi (SQL injection) – внедрения SQL кода.

Как выглядит на практике внедрение SQL кода?

Допустим, мы имеем определённый запрос к базе данных, в котором в качестве одного из параметров участвуют данные, которые были введены пользователем на веб-сайте. Если эти данные участвуют в составлении запроса к базе данных, то мы можем непосредственно влиять на этот запрос, например, сначала мы запросим товар с идентификационным номером 1, далее с номером 2, если такие номера есть, то мы получим по ним данные, какое-нибудь описание, цену и прочее. Так упрощённо работают запросы к базе данных. Что произойдёт, если мы захотим нарушить логику запроса и запросим не номер товара, а передадим в этих данных какие-либо ключевые слова языка запроса?

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

SELECT * FROM goods WHERE id = userinput,

где userinput – это то, что ввёл пользователь. Представим, что никакой обработки не происходит и то, что ввёл пользователь, никак не проверяется и вставляется в запрос как есть. Что тогда произойдёт? Если на месте пользователя окажется злоумышленник или специалист по уязвимостям веб-приложений, то он сможет с помощью ключевых слов языка SQL управлять запросом и доставать из различных таблиц необходимые данные, например, логин и хэш пароля администратора, номера банковских карточек, электронные почты пользователей и прочее, что чаще всего хранится в базе данных. Вот так приблизительно и работает уязвимость, связанная с инъекцией SQL-кода. Почти все уязвимости связаны с неправильной обработкой входных данных, получаемых от пользователя.

Теперь рассмотрим стандартный план действий при атаке на веб-приложение

Итак, на первом этапе анализа веб-приложения происходит сбор информации о данном веб-приложении (сайте).

Он бывает двух видов: пассивный и активный. Суть их в том, что при активном режиме вы уже фактически вмешиваетесь в работу веб-приложения, и если у вас нет на это разрешения, то это является нарушением законодательства, по крайне мере в РФ.

Активный сбор информация – это, например, сканирование активных портов, которое вы проводите. Иногда активные порты можно посмотреть через различные сервисы наподобие Shodan или онлайн сканеров.

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

После сбора информации обычно идёт поиск уязвимостей. Фактически самая важная часть исследования и одна из самых сложных. Здесь нет как такового верного подхода, у каждого исследователя свой подход к поиску уязвимостей: кто-то использует сканеры, фаззеры и прочие утилиты, кто-то ищет вручную, используя только базовые инструменты по типу Burp Suite или только браузер, но это совсем редко встречается. Поиск уязвимостей особенно в BlackBox’e чаще всего представляет из себя создание разнообразных предположений и гипотез и последующую проверку их. Есть также так называемые “известные” уязвимости – это уязвимости, которые уже известны сообществу и могут быть обнаружены, если веб-приложение не обновляло ту часть, где находится эта уязвимость, как раз для такого рода уязвимостей и существуют сканеры.

После обнаружения уязвимости или ряда уязвимостей, разрабатывается вектор атаки на приложение. Что это значит?

Это значит, что, исходя из найденных уязвимостей и их типа, необходимо разработать план нападения на приложение, который должен учитывать, что и как будет проводиться и какие финальные цели, обычно это очень подробно описывается в отчётах исследователей. У злоумышленников вектор атаки зависит от целей, исследователям же приходится расписывать все возможные варианты атаки злоумышленника и последствия, которые будут после удачной или неудачной атаки. Также есть обще описательные вектора уязвимостей, которые содержат в себе тип уязвимости, доступ необходимый для её эксплуатации и критичность.

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

Под пост-эксплуатацией подразумевается заметание следов и оставление себе удобного доступа к машине, либо к полученным функциям.

Разобрались?

Теперь уделим ещё немного внимания SQL инъекциям.

SQLi

Внедрение SQL-кода (SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

Как это работает?

объясненние сделано максимально простым и опущены некоторые нюансы

Для представления механизма работы SQLi, нужно представлять, что такое база данных и скрипты, в которых производятся запросы к базе данных, а также знать хотя бы на примитивном уровне SQL и иметь навык написания базовых запросов.

Грубо говоря, обычная, в нашем понимании, БД состоит из множества таблиц. У каждой таблицы, естественно, есть столбцы и есть строки. Собственно, это ключевой момент. Возьмем к примеру таблицу пользователей какого-либо интернет-магазина. Для каждого пользователя должно быть описано несколько параметров (логин, адрес электронной почты, дата регистрации, сохранённая карточка и т.д.).

В итоге каждый столбец определяет какой-либо параметр пользователя, а каждая строка – конкретного пользователя. А в пересечении нужного нам столбца и строки будет информация о параметре нужного пользователя.

Пример

Представим, что вы (скрипт) идёте в магазин (базу данных), и просите в магазине (создаёте SQL запрос и отправляете его в базу данных) продавца: “Мне нужна одна бутылка воды за 25 рублей”.

Теперь переделаем это в SQL запрос к базе данных, получим следующее:

SELECT * FROM магазин WHERE (тип=’вода’ AND цена=25) LIMIT 1

Собственно, в ответ на вашу просьбу (SQL запрос) вы (скрипт) получаете бутылку (информацию), и продавца (Базу данных) уже не волнует, что вы будете с ней делать, так как свою работу он выполнил. Вы можете ее выпить, вылить, подарить (обработать, вывести, рассчитать) и тд.

Что надо бы знать?

­­Для полного понимания запроса в базу данных необходимо знать на базовом уровне язык SQL, однако даже без особых знаний можно заметить, что запрос выглядит понятным, так как используются довольно известные слова и они трактуются в данном случае однозначно. Вопросы может вызвать разве что окончание запроса: “LIMIT 1” – данная конструкция объявляет, что необходимо выдать только первый найденный результат, если вдруг их больше одного (бутылок по такой цене может быть очень много, но нам нужна только одна).

Все остальные мнемоники (команды) запроса предельно понятны:

        SELECT – выбери (возьми)

        FROM – из (указывает от куда нужно взять, чаще всего после данной команды следует название одной из таблиц в текущей базе данных)

        WHERE – где (указывает какие значения различных параметров должны быть у той строки которую мы хотим получить, по сути указывает критерии для того товара который мы хотим получить)

Для успешной реализации атаки типа SQLi необходимо хорошо знать язык SQL.

Обобщенно атака типа SQL инъекция (SQL injection) возникает в случае если злоумышленник может каким-то образом модифицировать запрос к БД.

Ещё один пример

Рассмотрим всё тот-же пример с магазином.

Допустим вы решили пойти в магазин за кефиром, и специально написали на бумажке список продуктов, которые хотите купить, чтобы ничего не забыть. Предположим, что у вас дома оказался друг, который очень любит шоколад, однако ему нельзя есть его много и на его просьбу, вы ответили отказом и не стали записывать в листочек его пожелание. Итого вы получаете листочек, в котором на каждой новой строке записаны продукты, которые вам необходимы в магазине. Допустим, что каждый из продуктов будет представлять собой некий запрос к базе данных (магазину) как и в прошлом примере. Вы просто отдаёте продавцу свой листочек (скрипт передаёт запросы в базу данных) и он, читая очередную строку кладёт в ваш пакет тот или иной продукт (сохраняет результаты, того что удалось получить из базы данных). Теперь представим, что в данный листок ваш друг всё-таки умудрился вписать шоколад (провел атаку SQL injection) и продавец, читая очередную строчку может увидеть следующее: “Масло за 100 рублей или шоколад за 150 рублей”. В магазине может не оказаться масла, или продавцу долго за ним идти, и он положит вам в пакет шоколад. Продавец в данном случае не имеет представления о том, что вашему другу нельзя шоколад и вам он тоже особо не нужен, он просто выполняет свою работу, предоставляет продукты согласно переданному ему списку (база данных будет осуществлять работу по возврату данных на основание входящих запросов, если они были составлены правильно). Переведя это в SQL запрос получим следующее:

SELECT * FROM магазин WHERE (тип=’масло’ AND цена=’100’) OR (тип=‘шоколад’ AND цена=‘150’) LIMIT 1

Атака удалась потому что вы не проверили листочек перед тем как отдать его продавцу (скрипт не проверил входные данные перед формированием запроса и его отправки в базу данных).

Где можно найти SQLi?

SQLi может возникать в местах, где есть ввод параметров, например формы поиска товаров в интернет магазине или форма авторизации, которые есть на большей части всех веб-приложений. Любой не фильтруемый пользовательский ввод – почти всегда приводит к плачевным последствиям.

Особенности

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

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

        Большинство SQLi обнаруживаются путём нарушения общего мнения о том, что должно быть введено в данное поле конечным пользователем, чаще всего срабатывает символ одинарной кавычки, так как многие из параметров – строковые. Подставив в какой-либо параметр кавычку и получив ошибку, содержащую слова “SQL syntax error” или что-то подобное, можно сразу сказать, что скорей всего здесь есть SQLi.

SQLi. Практика

Перед началом разбора механизма работы уязвимости SQLi необходимо оговориться о некоторых моментах, связанных с базами данных. Ниже представлен список тезисных заключений про реляционные базы данных, которые чаще всего используются в веб-приложениях.

А теперь перейдём к практике. Для повторения всех действий понадобится Kali Linux и базовые знания языка SQL (достаточно будет тех, которые были представлены в предыдущем посту)

Работа с базой данных.

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

Открываем консоль на Kali Linux (можно использовать и другой Linux-дистрибутив, но тогда Вам самостоятельно придётся установить набор, называемый LAMP – Linux/Apache/MySQL/PHP, который представялет собой веб-сервер, БД, и скриптовый язык.

Пишим в консоль следующую команду: mysql

Видим ошибку. Данная ошибка означает, что не получается подключиться к серверу (так как mysql – это сетевой сервис). Нужно запустить его, с помощью следующей команды: service mysql start (это стандартный шаблон запуска сервиса в Linux).

Далее подключаемся уже знакомой нам командой:

Если подключение прошло корректно, то мы окажемся в консоли управления базами данных. По сути MySQL представляет собой СУБД (Система управления базами данных), то есть с помощью неё можно удобно управлять различными базами данных. Для начала посмотрим какие базы данных у нас есть на текущий момент с помощью команды: show databases;

Это стандартные 3 базы данных, которые необходимы для корректного функционирования mysql. Сейчас подробно разбирать их не будем.

Давайте создадим новую базу данных и назовём её “shop”, т.к. мы будем хранить в ней учётные данные покупателей вымышленного магазина. Команды для создания: create database shop;

Мы создали базу данных, но пока она пустая. Теперь необходимо “зайти” в данную БД и создать в ней таблицы. Смена исользуемой базы данных происходит с помощью команды: use <databasename>

Теперь необходимо создать таблицу. Создадим таблицу под именем “user” в которой будем хранить логин, хэш-пароля, номер карточки (придуманный из головы). Для этого нам необходимо при создании таблицы указать каждому полю (месту где будет располагаться то или инное значение для одной записи) тип данных. Так-как все хранимые нами данные в БД можно представить в виде текста, то и тип у ячеек будет текстовый.

Команда для создания таблицы:

create table users (name VARCHAR (32), password VARCHAR (32), cardnumber VARCHAR (32));

VARCHAER (32) означает тип данных – символьный длинной 32 символа.

Проверяем наличие таблиц в базе данных командной:

show tables;

Сейчас наша таблица пуста, это можно проверить следующей командой (запросом на языке SQL).

команда для получение всего содержимого таблицы:

SELECT * FROM users;

Добавим новую запись. Например добавим пользователя – admin, который будет являться администратором данного магазина.

команда добавления новой записи:

INSERT INTO users VALUES (“admin”, “21232f297a57a5a743894a0e4a801fc3”, “no”);

Пароль представляет собой md5-хеш от строки “admin”, его можно получить с помощью простой команды в консоли:

команда:

python -c ‘import hashlib;print hashlib.md5(“admin”).hexdigest()’

Добавим ещё одну запись, но теперь обычного пользователя (сделать самостоятельно).

Результат запроса, отображающего все содержимое таблицы должен быть следующий.

Отлично! Теперь у нас есть тестовая БД.

Работаем с веб-сервером и пишем скрипт!

Теперь необходимо запустить веб-сервер (в случае с Kali Linux – это веб-сервер apache2).

Проверить корректность его запуска можно с помощью бразуера, зайдя на localhost (ip 127.0.0.1).

Теперь необходимо создать небольшой скрипт, который обращается к базе данных и работает с созданой нами таблицей.

Все файлы для веб-сервера apache2 хранятся в папке: /var/www/html

Сейчас там находится лишь один файл, который мы видим в браузере.

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

Теперь создадим там PHP-скрипт (не бойтесь, каких либо навыков программирования на PHP нам пока не нужно).

Сделаем скрипт, который выводит информации об PHP-движке, установленным на данной машине.

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

nano phpinfo.php

Набераем следующее.

<?php phpinfo(); ?>

Суть скрипта заключается в том, что он просто вызывает функцию phpinfo().

Сохраняем скрипт (Ctrl+O) и выходим из редактора (Crtl+X).

Проверяем, что скрипт работает:

Теперь напишем скрипт, отвечающий за авторизацию в магазине, и допустим там возможность внедрения SQL кода.

Создаём файл “login.php” и помещаем в него следующий код (ссылка).

Обратите внимание, что в скрипте в самом начале присутсвует такой параметр, как пароль пользователя, для подключения к базе данных. Как поставить пароль на подлкючение к базе данных можете посмотрет сами в Интернете или повторить действия со следующих скриншотов.

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

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

Разбираем уязвимость!

Теперь самое основное.

Видим форму авторизации. Представим, что мы не знаем какой пароль у пользователя “user1” и в целом мы просто посетитель и увидил форму авторизации.

Попробуем ввести в поле username значение “user1”, а в password “test123” (мы знаем, что это неверно).

Видим “Login error!”

Теперь предположим, что запрос к БД составляет немного не верно, точнее наши входные данные не совсем корректно обрабатываются, пред тем как быть подставленными в запрос. Поставим символ кавычки в поле username (таким образом мы нарушаем синтаксис языка, т.к. кавычки должны быть открыты и закрыты).

Мы получаем ошибку синтаксиса, и можем предположить что здесь есть SQLi.

Попробуем отбросить проверку пароля. Для этого закоментируем всё что идёт после имени.

Коментарий это два тире (минуса) “–“, всё, что идёт после комментария, не обрабытавается (как и в других ЯП).

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

Таким образом мы можем внедрить свой SQL код и выполнять произвольные запросы к базе данных, доставая из неё всё необходимое.

Для лучшего понимания, попробуйте сделать такие запросы напрямую в СУБД mysql, например, вот так.

Ресурсы для тренировки

Это тренировочный сайт одной российской CTF команды. Там есть ряд заданий на SQLi, от простых к сложным.

http://training.hackerdom.ru/board/

Категория: Injections

Если Вы не хотите регестрироваться, то вот ссылка на первое задание (второе откроется после решения первого)

http://sql.training.hackerdom.ru/

Если тебя интересует продолжение, читай эту статью.

Сегодня мы ознакомились с основами атаки на web приложения. И если даже ты знал что-то из этого, уверен, что повторить не помешает. И помни, как гойорят йоги: самое главное – практика. Кто ищет – тот всегда найдёт.

Очень злой админ
Очень злой админ Автор статьи

Админ сайта. Публикует интересные статьи с других ресурсов, либо их переводы. Если есть настроение, бывает, что пишет и что-то своё.

Комментарии

  1. “Коментарий это два тире (минуса) “–“, всё, что идёт после комментария, не обрабытавается (как и в других ЯП).”

    Зачем тогда на скриншоте выше по сторонам двух тере стоят одинарные кавычки?

Leave a Reply

Your email address will not be published. Required fields are marked *