29 января 2018
Почему SQL Injection - это самый опасный вид уязвимостей?
Самый распространенный способ взлома сайтов и программ, работающих с базами данных, - SQL Injection. Чем же так опасна данная уязвимость?
SQL инъекция на данный момент является не только широко распространенной уязвимостью, а еще и одной из самых опасных по версии OWASP Top 10 Application Security Risks 2017. Попробуем разобраться почему.
Суть уязвимости — выполнение произвольного запроса к базе данных. Запрос может быть любым: на чтение, запись, модификацию и удаление каких-либо записей. Звучит катастрофично, не правда ли? А ведь этими угрозами все не ограничивается, так как при определённых обстоятельствах можно добраться и до чтения/записи локальных файлов или даже до выполнения кода! Все зависит от целей, которые преследует злоумышленник, от используемой системы и того, как она сконфигурирована.
Существует несколько типов SQL инъекций:
- Классическая SQL Injection — простая и легкая в эксплуатации. Позволяет злоумышленнику атаковать БД и сразу видеть результат атаки. В последнее время встречается нечасто.
- Error-based SQL Injection — чуть более сложный и затратный по времени тип атаки, позволяющий, на основе выводимых ошибок СУБД, получить информацию о всей БД и хранящиеся в ней данные. Эксплуатируется, если кто-то в спешке забыл отключить вывод ошибок.
- Boolean-based SQL Injection — одна из «слепых» инъекций. Суть атаки сводится к добавлению специального подзапроса в уязвимый параметр, на который БД будет отвечать либо True, либо, неожиданно, False. Атака не позволяет сразу вывести все данные БД «на экран» злоумышленнику, но позволяет, перебирая параметры раз за разом, получить содержимое БД, хотя для этого потребуется временной отрезок соизмеримый с содержимым БД .
- Time-based SQL Injection — следующая из «слепых» инъекций. В данном случае злоумышленник добавляет подзапрос, приводящий к замедлению или паузе работы БД при некоторых условиях. Таким образом, атакующий, сравнивая время ответа на «True» и на «False» запросы, символ за символом может получить все содержимое БД, но времени уйдет на это больше, чем в случае эксплуатации Boolean-based атаки.
- Out-of-band SQL Injection — редкий тип. Атака может быть успешна только при определенных обстоятельствах, например, если сервер БД может генерировать DNS- или HTTP-запросы, что встречается нечасто. Также, как и Blind SQL, позволяет посимвольно собирать информацию о хранящихся там данных.
Чем это грозит?
Все это описание понятно большинству технарей, но далеко не всегда понятно бизнесу: «Ну запишут они в БД «Здесь был Василий», а дальше что?» Разбираем по пунктам.
«Слив» БД
Наиболее популярное явление, к которому приводит успешная атака — утечка всей информации, содержащейся в БД. Хорошо, если там не было ничего ценного (кроме фотографий ваших любимых котиков ^_^), но, в зависимости от обстоятельств, чаще в БД хранится множество весьма критичных данных: учетные записи пользователей (включая пароли), номера телефонов, адреса электронной почты, а нередко номера карт, их сроки действия и прочие сопутствующие сведения.
Чем грозит? В первую очередь, репутационными потерями, ведь мало кто захочет пользоваться сервисом, из которого могут вытащить какую-либо информацию о нём. Ещё хуже, если пароли хэшировались слабыми алгоритмами, что потенциально приведет к их восстановлению. Как вы понимаете, это крайне негативно отразится на всем бизнесе. Нечто подобное случилось у компании Taringa (новость на thehackernews.com), где пароли хранились хэшированными алгоритмом MD5, который еще в 2011 году был признан устаревшим (RFC 6151). В результате около 94% были восстановлены в течение нескольких суток.
Deface
Про последствия deface’а, наверняка, слышал каждый. Некоторые, даже встречали разного рода «акции», выраженные в размещении рекламы на главных страницах зачастую немаленьких и известных организаций, настройку редиректов на «вирусные сайты», замену всей главной страницы каким-нибудь мемом, а иногда даже и угрозами. Такие манипуляции зачастую организованы как раз при помощи SQL Injection-атак.
Помимо столь грубых способов указать на проблемы безопасности, существуют более утонченные и элегантные. Например, долгое время предлагалась «услуга» по размещению номера телефона заказчика на сайте жертвы. То есть пользователь, заходя на сайт компании А, знакомился с описанием товаров и услуг, но звонил по подмененному номеру уже в компанию Б. И, что тоже немаловажно, такие «модификации» сайта замечаются далеко не сразу.
Помимо столь грубых способов указать на проблемы безопасности, существуют более утонченные и элегантные. Например, долгое время предлагалась «услуга» по размещению номера телефона заказчика на сайте жертвы. То есть пользователь, заходя на сайт компании А, знакомился с описанием товаров и услуг, но звонил по подмененному номеру уже в компанию Б. И, что тоже немаловажно, такие «модификации» сайта замечаются далеко не сразу.
Отдельно стоит упомянуть популярные в последнее время ICO. Почему? А потому что, если кто-нибудь заменит опубликованный в официальном источнике адрес кошелька, на который собираются средства, эти средства станут собираться уже на счете злоумышленника. Такие атаки были с успехом проведены несколько раз в прошлом году.
DoS
Отказ в обслуживании, пожалуй, одно из самых нелюбимых бизнесом событий. Причина этого проста: возникают простои в обслуживании клиентов, которые ведут как к потере репутации, так и к упущенной выгоде. DoS вызывается просто: либо база заполняется «мусорными» записями, либо, что гораздо опаснее, она просто удаляется. Второй случай особенно интересен, если по каким-либо причинам не делались (или не проверялись!) бэкапы.
Чтение системных файлов
Атака встречается весьма редко и работает только при некорректной настройке системы. Суть заключается в чтении системных файлов, в которых также указаны различные настройки, учётные записи и прочие чувствительные данные. Обычно подобные атаки применяются для углубления понимания атакуемой системы и намётывания дальнейших действий с целью получения доступа к ней.
Повышение привилегий
Некоторых нехороших пользователей по каким-то причинам может не устраивать тот факт, что они не являются администраторами в системах. С помощью SQL инъекции у таких пользователей появляется шанс исправить данную ситуацию. Так, например, в популярной CMS Joomla существовала возможность через инъекцию вытащить Cookie учётной записи администратора. Одним запросом, кстати говоря. А небезызвестная и распространённая MS SQL может предоставить даже несколько способов повысить привилегии (в зависимости от того, как сконфигурирована СУБД).
К чему это может привести? К большим проблемам, если кратко. Последующий сценарий подобной атаки может быть любым: это и все ранее перечисленные угрозы, и дополнительно, все действия, доступные администратору (может отличаться от системы к системе).
Повышение привилегий — одно из самых неприятных развитий событий, так как злоумышленник с правами администратора может доставить немало хлопот.
Повышение привилегий — одно из самых неприятных развитий событий, так как злоумышленник с правами администратора может доставить немало хлопот.
Remote Code Execution (RCE)
Является, пожалуй, самым опасным вектором атаки, к счастью, нечасто встречающимся. Обычно выполняется с целью получения shell’а и, следовательно, контроля над сервером целиком.
Часто RCE осуществляется уже после атаки Privilege Escalation и из-за слабых настроек прав доступа в системе, но это происходит не всегда так. Для реализации атаки злоумышленник загружает файл-зловред и либо запускает его удалённо, либо сам одним из доступных образом «цепляется» к нему.
Какие последствия могут быть? Любые, включая все ранее перечисленные. Все опять же зависит от целей злоумышленника. Кто-то начинает использовать сервер для майнинга криптовалюты, кто-то может настроить репликацию БД на «свой» сервер, а кто-то просто пойдет дальше и постарается получить управление остальными серверами в локальной сети. Последствия могут быть самыми печальными.
Часто RCE осуществляется уже после атаки Privilege Escalation и из-за слабых настроек прав доступа в системе, но это происходит не всегда так. Для реализации атаки злоумышленник загружает файл-зловред и либо запускает его удалённо, либо сам одним из доступных образом «цепляется» к нему.
Какие последствия могут быть? Любые, включая все ранее перечисленные. Все опять же зависит от целей злоумышленника. Кто-то начинает использовать сервер для майнинга криптовалюты, кто-то может настроить репликацию БД на «свой» сервер, а кто-то просто пойдет дальше и постарается получить управление остальными серверами в локальной сети. Последствия могут быть самыми печальными.
Как защититься?
Несмотря на всю серьёзность уязвимости, защита от атаки весьма проста: при разработке приложения необходимо уделить особое внимание фильтрации ввода и настройке прав. Обязательно отключайте вывод ошибок на «рабочей» системе, ни к чему пользователю такая чувствительная информация. И после каких-либо изменений в приложении проводить ASV-сканирования для гарантии. А в идеале, ввести данные действия в Software Development Life Cycle. Он же у вас уже есть, верно?
Используете готовое приложение? Всегда своевременно обновляйтесь. Часто это простое правило может уберечь от плачевных последствий.
Дополнительной мерой является установка Web Application Firewall (WAF) систем. Именно подобный класс решений заточен на борьбу с выше описанными атаками и, надо сказать, весьма хорош.
Хотите убедиться, что ваши системы надежно защищены? Или интересуетесь пилотом WAF? Обращайтесь, мы с радостью проведем аудит или поможем с тестом решения по защите от подобных атак.
Филипп Заболотный
Ведущий инженер, Акрибия
Ведущий инженер, Акрибия
Другие публикации по теме