Откажись от SQL, приди к ORM. Введение в sqlmap, sql-inj. Атака и защита от SQL.

[D2]

Спойлер: soundcloud
https://soundcloud.com/akimrizk%2Fannenmaykantereit-kiz-hurra-die-welt-geht-unter

Написано - chiefchain
Для - XSS.is

1. Введение
1.1 О чём статья?
Здрасте, всем. Если заголовок для вас показался страшным сном, то не волнуйтесь - опыт использования sqlmap или знания о sql-inj, не особо вам пригодится для понимания статьи. Мы начнем с самых азов и шаг за шагом разберем, как работают инъекции, проэксплуатируем на каком-нибудь таргете, и почему они вообще являются такой серьезной угрозой. Так же не забудем и про WAF(Web Application Firewall) - всяческие системы, которые защищают от различного рода атак. Посмотрим как с ним бороться и обходить эту дрянь. И кроме того, хочу ответить на важный вопрос: почему я призываю отказаться от использования чистого SQL и перейти на ORM? Это уже конечно будет не в рамках атаки, а в рамках защиты. Всё обсуждение будем вести в связке с языком Python, именно там легко показать влияние ORM, а так же sqlmap написан на нём. Приятного прочтения, не забудьте оставить вашу "рецензию" по итогу прочтения, чего не хватало, чего было слишком много, обратная связь как никак важна, чтоб понимать в будущем куда лучше углубиться =)
1.2 Кто такой этот ваш SQL и как он связан с ломом баз данных?
Добро пожаловать в мир баз данных, дорогие друзья! Представим, что база данных - это огромный архив, где лежат вся информация, требующаяся для нормальной работы сайта, приложения, да чего угодно. А SQL, он же Structured Query Language - просто язык, который позволяет нам удобно обращаться с базой данных. Ему уже за полтинник, но он всё так же стабильно используется, даже если вы будете в попытках убежать от чистого SQL, перейдя на какой-нибудь SQLAlchemy, то не волнуйтесь, сбежать не получится, это просто так скажем конвертор из одного вида, в другой. Теперь всё же как он связан с нашим ломом баз данных. Всё достаточно просто и нативно, одна из распространенных уязвимостей это - SQL-инъекция. Способов её реализации куча, начиная от проблем в форме ввода данных, заканчивая дилеммой где-то в отправке запроса, работая с ними надо ещё иметь достаточно неплохую фантазию. В 2017 году по данным OWASP эта уязвимость была на первом месте, сейчас же скатилась до третьего места.

Окей, а давайте посмотрим самый простой и банальный пример на форме входа. Для начала определимся с тем, что происходит на стороне бэкэнда сайта, возьмём простую сверку наличия в базе пользователя с таким-то юзернеймом, с таким-то паролем. Выглядеть вся эта картина будет примерно так.
Код: Скопировать в буфер обмена
SELECT * FROM users WHERE username = 'user' AND password = 'pass';
У нас задача выполнить инъекцию своего кода в этот кусок, чтоб он всегда выполнялся верно, для этого мы можем использовать утверждение '1'='1', если у нас получится добавить это условие в код запроса, то мы всегда авторизуемся. В итоге, эксплуатируем ручками таким образом, что в поле формы ввода логина пишем:
Код: Скопировать в буфер обмена
user' OR '1'='1'
Таким образом у нас всё поплывет, и получится запрос такой итоговый запрос.
Код: Скопировать в буфер обмена
SELECT * FROM users WHERE username = 'user' OR '1'='1' AND password = 'pass';
Это банальный пример, чтоб было минимальное представление о скулях, в нынешнее время уже наврятле вы сможете найти такие дырки, только лишь в каких-то полудырявых, старых, до ужаса проектов..
1.3 WAF? Урод, мешающий нам. Сокрытие инъекций от него.
WAF (Web Application Firewall) — это межсетевой экран, который работает на прикладном уровне и предназначен для защиты веб-приложений от различных видов атак, включая SQL-инъекции, RCE (Remote Code Execution), XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery). WAF анализирует весь трафик, фильтрует его и блокирует запросы, которые ему не понравятся, прежде чем они достигнут веб-приложения. WAF на практике использует простой набор правил для анализа трафика. Они могут быть основаны как и на известных шаблонах атак, например из OWASP, как рассказывал ранее, а так же можно создавать и свои правила, под свои конкретные цели своего приложения. Банальнейший пример на скули, это проверка на подозрительные строки, такие как: UNION SELECT, OR '1'='1'. Защита от инъекций заканчивается чаще всего на проверке паттернов. Окей, а как мы можем бороться с ним? Как скрыть от него нашу инъекцию? Тут на самом деле тяжело сказать, что есть один какой-то золотой вариант, ведь админ всегда может добавить свои правила. Окей, давайте начнём с определения "Тампер". Под этим словом мы подразумеваем обфускацию нашей полезной нагрузки с целью сокрытия от WAF. Здесь можно использовать как готовые варианты, так и написать свои варианты. Я расскажу лишь про парочку, существующих и уже готовых вариантов. Chardoubleencode - кодирует дважды все символы в нашей полезной нагрузке, полезен он будет для попытки обхода фильтра, если он разбирает URL-кодированные запросы, а так как мы дважды кодируем, то прибегнет он к другому, где де-факто наша полезная нагрузка будет лежать, но её не будет, а когда запрос дойдёт до бэка, то там он уже трансформируется в то, что нам нужно. Можно так же пробовать играться с регистром запроса, но это помогает достаточно редко. И третий метод, который мне тоже нравится, называется nonrecursivereplacement, он дублирует наши слова в запросе таким образом, чтоб при их удалении WAF-ом, они всё равно остались. Примитивный пример, можно привести такой, у нас было - "1 UNION SELECT 2--", а превращаем его в такое "1 UNIOUNIONN SELESELECTCT 2--". Ведь по итогу удаления, мы получаем, то что у нас было в исходном варианте.

Я так же не могу сказать ничего про обфускацию запросов в hex формат, или base64, конечно мы можем пройти WAF таким образом, но поймет ли нас бэкэнд, до которого мы по итогу будем отправлять такой запрос?
1.4 SQLMap. Пробивайся быстрей и проще.
SQLMap — позволяет нам томатизировать эксплуатации SQL-инъекций. Изначально не подразумевались чёрные цели, был выпущен под лицензией "Code of conduct", которая гласит, что надо использовать лишь в законных и этических целях, но когда это вообще кого-то останавливало?) Практические каждое ПО, можно развернуть в обратные цели. Он поддерживает кучу СУБД, хоть PostgreSQL, хоть старый Microsoft SQL server, что делает его практически лучшим в своих целях. Он сам умеет определять наличие скулей в параметрах запросов, которых порой может быть прям до кучи. Сам же умеет делать дампы баз, ну и куда без встроенных механик защит от WAF. При работе с ним перед тем как начать пробивать скулю через него рекомендую узнать какая БД стоит на сайте, достаточно пробить зарезолвить его в днс чекере, чтоб узнать айпишник, а там уже посмотреть открытые порты и узнать. Соответствие БД к порту чуть пониже.
Код: Скопировать в буфер обмена

MySQL - 3306
PostgreSQL - 5432
Microsoft SQL Server - 1433 (так же возможен 1434)
Oracle - 1521 (возможен 1526)
SQLite - отсутствует, тк не поднимается в сеть, работает локально.
MariaDB - 3306 (форк MySQL)
DB2 - 50000
Sybase - 5000 (возможен 4100)

1.5 ORM - это? Почему пора отказываться от чистого SQL и переходить на ORM?
ORM (Object-Relational Mapping) на самом деле простая технология, которая преобразовывает все ваши взаимодействия с базой данных в объектно-ориентированный стиль, грубо говоря ООП среди баз данных. Если говорить совсем простым языком, то вместо того чтоб писать SQL-запросы вручную, мы работаем с объектами, которые заранее задали, которые в последствии автоматически преобразуются в SQL, это очень сильно упрощает работу, но при этом конечно время выполнения через ORM будет чуть побольше, но не так уж прям критично я считаю. Выглядят наши объекты примерно так в случае работы с SQLAlchemy.

Как по мне главной причиной перехода на ORM является именно защита от SQL-инъекций, ведь когда вы пишете на чистом SQL, то только вы сами отвечаете за обработку ввода пользователя и дальнейшюю её экранизацию. Но мы ведь люди? Значит есть и человеческий фактор, который всегда играют какую да никакую роль. ORM же делает всё, да, наоборот. Она сама обрабатывает параметры запросов, экранирует их, и тем самым предотвращает инъекции. Да, можно сказать, что над созданием ORM-ок тоже работают люди, и им тоже свойственно ошибаться. Но, одно огромное "НО", над фреймворками работает куча людей, тем самым и снижается вероятность человеческого фактора. Нативный пример как это работает, к примеру мы имеем вот такой SQL-запрос:
Код: Скопировать в буфер обмена
SELECT * FROM admins WHERE password = 'somepassword' AND login = 'somelogin';
В то время как с ORM это выглядит следующим образом
Код: Скопировать в буфер обмена
Admins.objects.filter(password=md5_password, login=request.POST['login'])
Переход от чистого SQL к использованию ORM - это не только вопрос удобства, но и безопасности, а так же перехода к новым технологиям, порой я удивляюсь от поддержки проектов с миллионным траффиком на php, и планировать никто не куда не хочет, ведь зачем ломать, то что работает?..- Хотя такая позиция тоже имеет право на существование.
2. Практика
2.1 Первоначальная работа с таргетом.
Представим, что у нас уже есть сайт, с которого мы хотим уже дернуть БД, для начала стоит найти есть ли вообще на нём такие пути, чтоб там можно было указать параметр, в данном случае нам нужо прогнаться по всевозможным директориям, которые есть на сайте, ходить руками и гонять их проверять, это тоже бред. По этому прибегаем к такому софту как v3n0m-scanner, он поможет нам найти существующие страницы, листы с дорками у него уже заранее есть, их 12 тысяч, но можно дополнять своими. Функционал у него заключается не только в этом, но и другие, я их не проверял, не пользовался, но Cloudflare Resolver звучит интересно, хоть и не смотрел как оно работает.

Список путей, который заранее подгружен выглядит примерно так

Теперь уже пора приступать к поиску наших путей, в первом мы указываем домен, на котором будем искать, так же можно и пробовать и поиск по поддоменам, для этого надо указать звездочку перед главным доменом (а можно и по всему интернету, можно к примеру только по *.com, и так далее). Дальше указываем по скольким доркам прогонять, при 0 это может затянуться конечно надолго, но так результатов точно стоит ожидать больше, дальше уже указываем кол-во потоков, что отвечает за нашу скорость, и последнее так это по скольким страницам в поисковиках будет идти анализ, от него зависит так же скорость.

После чего получаем юрлы сайта, где этот путь существует. Теперь надо проверить, присутствует ли там вообще уязвимость. Для этого достаточно попробовать поставить одиночную ковычку. И если мы получаем ошибку, то бинго, скуля тут есть.

Скуля есть, в данном случае мы сразу видим название используемой СУБД, но для полноты картины расскажу ещё как можно узнать её. Этот метод бессмысленен для работы с сайтами за CF. Для начала берем наш домен и находим его айпишник через всяческие сервисы, я пользуюсь - https://dnschecker.org/ . Ищем обязательно по записи типа - А.

Как получили айпишник, бежим на shodan/fofa всё что угодно, любые сканнеры и смотрим либо на открытые порты, где ищем соответствия с базой, мини-списочек с ними лежит чуть выше в статье.

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

Окончательно убеждаемся в том, что это все же MySQL, если же вы не нашли информации ни на одном из краулеров, то проверьте открытые порты через nmap.
Первоначальная подготовка прошла, теперь можно скакать к sqlmap
2.2 Запускаем в бой sqlmap.
Собрали уже всю информацию, которая нам нужна, можно переходить теперь и к нему, Скачать