Недавно, в ходе работ по
анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним
UTM-устройством. Достаточно типичное сочетание
CSRF и
XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость
типичная.
Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении.
Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска — критические уязвимости.
Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей.
Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2.
http://www.securitylab.ru/analytics/355336.phphttp://www.securitylab.ru/analytics/356476.phpДостаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно.
Цитирую:
Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:
- зависимость от контекста;
- зависимость от конфигурации системы;
- зависимость от метода определения.
В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость «Подделка HTTP-запроса» может не представлять угрозы для типичного репрезентативного сайта или поисковой машины, и наоборот – классифицироваться как проблема высокой степени риска в Web-интерфейсе электронной почты или платежной системы. В результате утечки информации злоумышленник может получить доступ к журналам работы приложения (низкая или средняя степень риска), а может загрузить резервную копию исходных текстов сайта (высокая степень риска).
Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость «Внедрение операторов SQL» обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной.
В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример «Внедрения операторов SQL», использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом «белого ящика».
Т.е. крайне некорректно относить две различные уязвимости одного типа (например SQL Injection) к одной степени риска без детального анализа.
Привожу пример.
Предположим SQL Injection позволяет получить доступ к СУБД минимально необходимыми для Web-сервера привилегиями, например db_reader. Причем Web-приложение не хранит в СУБД конфиденциальной информации, например паролей.
Тогда вектор и степень риска CVSSv2 будет равены:
(AV:N/AC:L/Au:N/C:P/I:N/A:P/E:H/RL:W/RC:C) = 6.1
В другом случае, если в СУБД хранятся пароли пользователей, в том числе и администратора, то степень риска увеличится за счет большей подверженности с точки зрения конфиденциальности.
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C) = 8.1Если же Web-сервер работает с SQL-server с чрезмерными привилегиями, например sa, то эта же уязвимость будет гораздо более опасной:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5Если перевести эти оценки к "светофорной" модели или 5 уровням, принятых в PCI DSS (Urgent, Critical, High, Medium, Low), то получим:
1. Средний (2) и High (3)
2. Средний (2) и Critical (4)
3. Высокий (3) и Urgent (>4).
Т.е. степень риска одной и той же уязвимости может серьезно меняться в зависимости от конкретной системы и её настроек.
Что же касается XSS с которого начиналась заметка, то ее вектор будет
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9Т.е. с точки зрения PCI DSS (а именно эту модель сейчас "модно" использовать) степень риска данной проблемы можно обозначить как High или даже Critical, а не Low. В любом случае, аудит провален :)).
ЗЫ. Хотя я могу понять вендора, ведь если безопасность не заложена в приложение изначально, то, цитирую: "
hardening the management interface would probably imply a complete redesign of it".
Вот такая она разная, оценка рисков.
