Как скомпрометировать веб-приложение? История атаки (часть 1)

24.02.2014 | Ровнов Павел
Want create site? Find Free WordPress Themes and plugins.

Не открою ничего нового, если скажу, что опубликованное в интернете веб-приложение всегда под угрозой. Считается, что реализовать данную угрозу сможет лишь злоумышленник с высокой квалификацией, а сама атака будет сложной и дорогостоящей, поэтому невозможной. Но это правда, лишь тогда, когда приняты верные шаги по защите веб-приложения, что, в общем, редкость. В реальной жизни на компрометацию одного из веб-приложений доменной зоны .by, входящего в первую десятку по посещаемости, злоумышленнику может потребоваться не более 5-и шагов. При этом атаку вряд ли можно назвать сложной – никаких «zero-day», достаточно лишь известных уязвимостей. Об этом читайте далее.
Как правило, злоумышленник преследует цель материальной выгоды. По моему мнению, сильная техническая цель злоумышленника – заполучить полномочия другого пользователя веб-приложения, а в пределе – полномочия администратора. В случае успеха, злоумышленник будет иметь не одну возможность оказаться в плюсе, как например, завладеть персональными данными пользователя или его денежными средствами (этот сценарий вполне вероятен, если веб-приложение – это интернет-банк). Поэтому предположим, что именно кража полномочий является целью злоумышленника. Для достижения технической цели могут использоваться как минимум следующие векторы: подбор параметров учетной записи пользователя, обход механизма аутентификации, атака cross site scripting.
Отправная точка атаки, как и всегда, – это разведка. Выполнив несколько пробных запросов, злоумышленник мог бы узнать следующую общую информацию о цели:

  • используемые технологии: PHP, JavaScript,  CSS;
  • протоколы взаимодействия с пользователем: HTTP, HTTPS;
  • структура: домен target.by и поддомены dom1.target.by, dom2.target.by, … .

Аутентификация пользователя веб-приложения выполняется по имени пользователя и паролю. Злоумышленник мог бы попытаться выполнить подбор параметров учетной записи, поскольку веб-приложение никак не ограничивает количество неудачных попыток аутентификации. Логично предположить, что злоумышленник не станет использовать эту возможность и предпочтет использовать менее заметный способ достижения своих целей,  поскольку администратор веб-приложения, как правило, имеет средства обнаружить подбор (хотя бы путем анализа журнала аудита).
При дальнейшем исследовании, злоумышленник мог бы обнаружить, что после аутентификации сессия пользователя поддерживается при помощи cookie (на рисунке – режим «Network monitor» браузера Mozilla Firefox, момент присвоения cookie).

Замечательно то, что cookie устанавливается без флага «HTTPOnly». Это означает, что скрипт, который работает на стороне клиента (в браузере пользователя) имеет доступ к значению cookie. При условии, что злоумышленнику удастся выполнить произвольный код на стороне клиента, он сможет прочитать cookie и тем самым заполучить сессию пользователя! То, что и требовалось злоумышленнику! Дело за малым – выполнить код на стороне клиента.
Известным инструментом для выполнения кода на стороне клиента является атака cross site scripting, или XSS (общая логика атаки – на рисунке).

Поиск XSS в общем случае выполняется с помощью сканера уязвимостей. При этом чтобы замаскировать сканирование под легитимный трафик число HTTP-запросов в единицу времени ограничивается. Однако если содержание всех запросов к веб-приложению анализируется, сканирование не пройдет «под радаром»: многочисленные запросы с нарушением формата входных данных быстро выдадут сканер. С целью не привлекать лишнее внимание администраторов, злоумышленник, вероятно, мог бы ограничиться проверкой потенциальных уязвимостей XSS вручную.
В случае, когда конкретный вектор атаки не дает результатов, ничего не остается, как вернутся на стадию разведки. Вновь изучая механизмы аутентификации и ведения сессии пользователя, злоумышленник, скорее всего, отметил бы, что сессия пользователя – единая для самого домена и всех поддоменов target.by (таково поведение cookie по умолчанию, если домен, или область действия, для cookie явно не указывается). Это означает, что можно не атаковать в лоб, а зайти с фланга. Другими словами атака, к примеру, XSS, использующая уязвимость веб-приложения в домене *.target.by позволит скомпрометировать и target.by. Wow!
Часто можно увидеть, что среди доменов *.target.by скрывается какой-либо open source «движок» для управления рекламой. Примечательно, что согласно перечню угроз безопасности веб-приложений OWASP Top 10 2013 на (почетном) 9-м месте – использование программного обеспечения и компонентов с известными уязвимостями («A9. Using Components with Known Vulnerabilities»). Об этом, не может не знать злоумышленник и он, скорее всего первым делом проверит перечень известных уязвимостей для найденного «движка».
Продолжение истории читайте в следующей части блога.

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий