До тех пор пока в сети существуют уязвимые приложения — найдётся и работенка для редтимера да и блэчер будет богат. Поэтому мы будем повторяться и писать до тех пор, пока ты не «отшлифуешь» свои навыки.
В этой статье мы вернемся к «азам» и рассмотрим основны атак на веб приложения. Пройдёмся по таким темам как:
Изначально атакующий хочет получить 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-кода. Почти все уязвимости связаны с неправильной обработкой входных данных, получаемых от пользователя.
Теперь рассмотрим стандартный план действий при атаке на веб-приложение
Итак, на первом этапе анализа веб-приложения происходит сбор информации о данном веб-приложении (сайте).
Он бывает двух видов: пассивный и активный. Суть их в том, что при активном режиме вы уже фактически вмешиваетесь в работу веб-приложения, и если у вас нет на это разрешения, то это является нарушением законодательства, по крайне мере в РФ.
После обнаружения уязвимости или ряда уязвимостей, разрабатывается вектор атаки на приложение. Что это значит?
Это значит, что, исходя из найденных уязвимостей и их типа, необходимо разработать план нападения на приложение, который должен учитывать, что и как будет проводиться и какие финальные цели, обычно это очень подробно описывается в отчётах исследователей. У злоумышленников вектор атаки зависит от целей, исследователям же приходится расписывать все возможные варианты атаки злоумышленника и последствия, которые будут после удачной или неудачной атаки. Также есть обще описательные вектора уязвимостей, которые содержат в себе тип уязвимости, доступ необходимый для её эксплуатации и критичность.
Далее идёт эксплуатация, это считается самой сложной частью, так как правильно поэксплуатированная одна небольшая, некритичная уязвимость может привести к катастрофическим последствиям.
Под пост-эксплуатацией подразумевается заметание следов и оставление себе удобного доступа к машине, либо к полученным функциям.
Разобрались?
Теперь уделим ещё немного внимания SQL инъекциям.
SQLi
Внедрение SQL-кода (SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного 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
- Стандартный план действий при атаке
- В первую очередь это статические данные, файлы, CSS (Cascading Style Sheets) или таблица стилей, JS (JavaScript), картинки, HTML файлы
- Но статические данные нам не особо интересны (кроме важных файлов, хранящихся на веб-сервере), так как уязвимостей, связанных с ними, обычно не бывает. Для начала нас интересует на каком языке написано веб-приложение. Язык, на котором написано веб-приложение, может быть абсолютно любой, начиная от дефолтных PHP, Ruby, Python и заканчивая ASM, но, конечно, чаще всего используется какой-то скриптовый язык.
- Помимо языка нам нужно понимать, на каком веб сервере работает приложение. Чаще всего это Apache2 или nginx, но бывают и другие варианты, например, для встраиваемых систем часто используют маленькие, легковесные веб-сервера написанные на С/С++.
- Далее идут базы данных. БД почти всегда используются более-менее серьёзным веб-приложением, в БД хранятся данные пользователей, настройки сервера, файлы, картинки и прочая очень интересная для взломщика информация. Для больших БД нужны удобные системы управления или СУБД, часто используемые варианты: MySQL, Oracle, SQLite.
- И финальный элемент структуры – ОС, на которой всё это находится. Понятно, что она может быть любой, но чаще всего используется какой-нибудь Linux-дистрибутив (серверный).
Изначально атакующий хочет получить 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-кода. Почти все уязвимости связаны с неправильной обработкой входных данных, получаемых от пользователя.
Теперь рассмотрим стандартный план действий при атаке на веб-приложение
Итак, на первом этапе анализа веб-приложения происходит сбор информации о данном веб-приложении (сайте).
Он бывает двух видов: пассивный и активный. Суть их в том, что при активном режиме вы уже фактически вмешиваетесь в работу веб-приложения, и если у вас нет на это разрешения, то это является нарушением законодательства, по крайне мере в РФ.
После сбора информации обычно идёт поиск уязвимостей. Фактически самая важная часть исследования и одна из самых сложных. Здесь нет как такового верного подхода, у каждого исследователя свой подход к поиску уязвимостей: кто-то использует сканеры, фаззеры и прочие утилиты, кто-то ищет вручную, используя только базовые инструменты по типу Burp Suite или только браузер, но это совсем редко встречается. Поиск уязвимостей особенно в BlackBox’e чаще всего представляет из себя создание разнообразных предположений и гипотез и последующую проверку их. Есть также так называемые “известные” уязвимости – это уязвимости, которые уже известны сообществу и могут быть обнаружены, если веб-приложение не обновляло ту часть, где находится эта уязвимость, как раз для такого рода уязвимостей и существуют сканеры.
После обнаружения уязвимости или ряда уязвимостей, разрабатывается вектор атаки на приложение. Что это значит?
Это значит, что, исходя из найденных уязвимостей и их типа, необходимо разработать план нападения на приложение, который должен учитывать, что и как будет проводиться и какие финальные цели, обычно это очень подробно описывается в отчётах исследователей. У злоумышленников вектор атаки зависит от целей, исследователям же приходится расписывать все возможные варианты атаки злоумышленника и последствия, которые будут после удачной или неудачной атаки. Также есть обще описательные вектора уязвимостей, которые содержат в себе тип уязвимости, доступ необходимый для её эксплуатации и критичность.
Далее идёт эксплуатация, это считается самой сложной частью, так как правильно поэксплуатированная одна небольшая, некритичная уязвимость может привести к катастрофическим последствиям.
Под пост-эксплуатацией подразумевается заметание следов и оставление себе удобного доступа к машине, либо к полученным функциям.
Разобрались?
Теперь уделим ещё немного внимания SQL инъекциям.
SQLi
Внедрение SQL-кода (SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного 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. Практика
- Реляционная база данных — база данных, построенная на основе реляционной модели.
- В реляционной базе каждый объект задается записью (строкой) в таблице. Реляционная база создается и затем управляется с помощью реляционной системы управления базами данных.
- Фактически реляционная база данных — это тело связанной информации, сохраняемой в двухмерных таблицах.
- Связь между таблицами может находить свое отражение в структуре данных, а может только подразумеваться, то есть присутствовать на неформализованном уровне.
- Каждая таблица БД представляется как совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы — атрибутам (признакам, характеристикам, параметрам) объекта, события, явления.
