Юлия Омельяненко


 
Опубликовано: 12 августа 17:16
 700
 

Осторожно, злой WAF.

 
 

Сколько систем и корпоративных сетей проходили через наши руки, сплошь и рядом встречалась ситуация: защита ставилась на периметр, а во внутренней сети заказчика, что называется, “кто в лес, кто по дрова”. Довольно стереотипное мышление: хакеры нас атакуют из интернета, от них нас спасет периметр. Стоит VPN-шлюз, а значит доступа в нашу сеть никто просто так не получит. Есть еще сайт с нашим приложением, но его защитит и спасет великий и могучий WAF. Да, спасет, если хакер начинающий.

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

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

Итак, приступим. Первой и очевидной целью на пути являлся веб-интерфейс магазина, за которым прячется WAF. Веб-сервер расположен в ДМЗ, что позволило бы в случае его успешной компрометации попасть в сеть, минуя VPN-шлюз. Первое, что возможно сделать, это просмотреть исходный код страницы, попробовать “поиграть” с параметрами. Но не забываем, что сервер охраняется WAF. Но мог бы он стать серьезным препятствием и как злоумышленник смог его обойти? WAF устроен таким образом, что не дает произвести атаку и блокирует действия злоумышленника (весь трафик с IP-адреса), если может их предотвратить, то есть, когда запрос уже отправлен. Поэтому просто так сканером уязвимостей воспользоваться не получилось бы, так как для сканирования характерно большое количество отправляемых запросов. При уменьшении их числа процесс идет довольно медленно, но без блокировок. В конкретном случае стараться обходить WAF даже и не пришлось: на сервере была уязвимость протокола OpenSSL Heartbleed, которая позволила перехватить данные для VPN-подключения, получить легитимный доступ во внутреннюю сеть, оставшись не замеченными, и уже внутри ее “сеять хаос”. Но что, если бы владелец ресурса был более предусмотрителен и закрыл бы данную уязвимость вовремя?

WAF, как и большинство средств превентивной защиты информации, работает по прецедентному принципу: реагирует на известные ему способы атак. Какие типовые атаки злоумышленник может совершить, и есть ли альтернативы, подходящие для обхода WAF?

Атака Обход правил безопасности
Сканирование на уязвимости Слишком большой поток запросов может спровоцировать блокировку. Можно уменьшить количество запросов до предельно допустимого уровня. Обнаружить, откуда проводилась атака, поможет ручной анализ логов.

Простые SQL-инъекции в полях ввода данных, в т.ч. “слепые”

WAF не может запретить абсолютно все запросы, а потому на нем настраивается “черный список” сигнатур. Атаку можно успешно провести, изменив тип параметров в запросе на разрешенные. Например:

Блокирует: =OR+1=1

Но пропускает: =1+OR+0x10=0x10

При этом знак равенства также может быть заменен на любой другой (!=, <,>). И это весьма часто срабатывает.

Успех атаки зависит от настроек WAF и использования параметризованных запросов в коде приложения.

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

SQL-инъекции в URL  Подмена значений параметров в адресной строке WAF легко распознает и блокирует. Но использование HPP (HTTP Parameter Polution) может WAF и одурачить. Успех атаки зависит от среды приложения, но проверку на уязвимость к HPP выполнить нужно, чтобы исключить или наоборот обратить внимание на данный вектор..
XSS (cross-site scripting)

Так как суть данной атаки - внедрение кода поверх исходной страницы, то она почти во всех случаях успешно отработает, не дойдя до WAF.

 Успех атаки тоже зависит от среды приложения, но проверку на уязвимость к XSS выполнить нужно, чтобы исключить или наоборот обратить внимание на данный вектор.


Это далеко не все известные способы. Но вывода можно сделать сразу два:

  •  WAF не спасет от уязвимостей в коде приложения. Часть способов могла бы быть обречена на провал и без WAF при анализе самого приложения на уязвимости (то же касается и примера с Heartbleed).
  • WAF всегда будет содержать ограниченное количество сигнатур. А значит, можно подменять словари.

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

Как лучше защититься? Топ-3 обязательных мер:

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

2) Исходите из того, что приложение постоянно кто-то ломает, пусть даже неуспешно. Новости об обнаруженных уязвимостях идут “на руку” как злоумышленникам, так и вам самим. Регулярно тестируйте и обновляйте приложение и его окружение, обновляйте словари и сигнатуры WAF, периодически проверяйте логи вручную.

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

Юлия Омельяненко - Ведущий эксперт «Лаборатории Цифровой Форензики»