Хроники пентестера #4: безопасность внешних веб-приложений

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

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


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

В одном из пентестов на сайте заказчика было найдено несколько критических уязвимостей, которые в перспективе могли позволить выполнять команды на сервере. Однако воспользоваться ими продолжительное время не получалось. Секунды превращались в минуты, минуты складывались в часы, цель была так близка, но все старания были безуспешны. Оглядевшись вокруг было замечено, что перед нами лишь один из сайтов большого хостинга. Учитывая, что на страницах исследуемого сайта и его соседей был замечен один и тот же зловред, вполне логично предположить, что злоумышленник до нас вряд ли стал бы заморачиваться с уязвимостями именно нашего анализируемого сайта. Наверняка он шел по пути наименьшего сопротивления и залился через соседей. Но ограничения при пентесте не позволяют повторить подобные подвиги. Между тем, старания все-таки не были напрасны и используя каскад уязвимостей сайт заказчика сдал свою оборону. Далее, вместо классического сбора информации, предстояло выяснить, каким образом зловред попал на страницы этого ресурса.

Следующая история раскрывает тему использования уязвимостей нулевого дня при пентестах. Перед нами очередной оф. сайт другого заказчика на вполне себе безопасной системе управления сайтом Joomla. При поверхностном серфинге на глаза попадает уязвимый модуль, информация об уязвимости в котором еще не успела просочиться в паблик. Также известна информация, что на днях через указанный модуль проходила массовая заливка. И как это не странно, сплоитс у нас уже был на руках:)) Далее, как в голливудских фильмах. Вводим target, запускаем, заливаемся, радуемся)) После этого предстояло ответить на вопрос, "кто здесь"? И ответ не заставил себя долго ждать. Как бы шеллы с eval и base64 очень палевны.

Последняя история, о которой я хочу сегодня рассказать, не менее показательна, чем остальные. Шутка ли, когда на одном из внешних сайтов всеми известного и любимого российского банка установлен бэкдор на языке наших поднебесных друзей. Более того, даты показали, что бэкдор был залит более года назад и на протяжении всего этого времени оставался незамеченным! Остроты всей истории придает также тот факт, что операционная система, на котором расположен веб-сервер, входит в состав корпоративного домена Active Directory банка. Как было выяснено позже службой управления ИБ самого банка, за все время был зафиксирован лишь один запрос, который собственно и установил бэкдор, т.е. в этот раз просто повезло. Кстати, бэкдор (аля веб-шелл) под Tomcat действительно оказался довольно наворочен (добавили себе в копилку), а установлен он был к слову через дефолты в интерфейсе администрирования Tomcat.

Так как же защитится от подобных угроз?

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

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

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

Так, что же требуется, чтобы защитить сайт от атаки нулевого дня при этом не прибегая к анализу его безопасности методом фаззинга или исходного кода? По моему видению должно быть реализовано как минимум следующее:
- стойкие пароли к используемым идентификаторам во всех интерфейсах (ftp, раздел администрирования и т.п.).
- все интерфейсы администрирования должны быть доступны только для доверенных IP-адресов; опционально, использование двухфакторной аутентификации везде, где это возможно.
- минимизация привилегий во всех компонентах.
- правильно настроенные таблицы разграничения доступа (начиная с файловой системы и заканчивая разграничением доступа средствами системы управления сайтом, если она предоставляет подобный функционал).
- безопасные конфигурации веб-сервера и его среды (например, безопасные конфигурации PHP).
- использование превентивных механизмов контроля (Web Application Firewall).
- ограничение сетевого доступа со стороны веб-приложения к любым другим компонентам сети; размещение веб-сервера в изолированной сетевой среде (aka персональная ДМЗ).

Придерживаясь перечисленных подходов вы существенно повысите безопасность своего веб-приложения. Желаю успехов в постоянной битве добра с добром по другую сторону :)