Риски, риски, риски...

Риски, риски, риски...
Недавно, в ходе работ по анализу защищенности наткнулись на уязвимость Web-интерфейса управления одним UTM-устройством . Достаточно типичное сочетание CSRF и XSS примечательно тем, что через Web-интерфейс позволяет получить доступ к коммандной строке устройства и интерактивно "рулить" системой в браузере администратора. Но не суть, уязвимость типичная . Интересное началось, как обычно на этапе взаимодействия с вендором. Мы не сошлись в степени риска, связанной с этой уязвимостью, что привело к ожесточенной переписке. В связи с этим, хотелось бы поделится своими наработками в данном направлении. Как правило, степень риска присваивается уязвимости производителем системы, в которой изъян был обнаружен, либо компанией, выпускающей средства защиты (сканеры уязвимостей, системы обнаружения атак и т. д.). В этом случае используется привычная по правилам дорожного движения схема: низкая степень риска (зеленый), средняя степень риска (желтый), высокая степень риска (красный). Иногда выделяется дополнительный, четвертый уровень риска критические уязвимости. Такого подхода придерживаются многие производители, например, Microsoft в своих уведомлениях об обновлениях программного обеспечения использует четыре уровня критичности уязвимостей. Однако, "светофорная модель" весьма непрозрачна и очень зависит от мировозрения и самочувствия эксперта и других факторов. В связи с этим мы широко используем в своей работе методику CVSSv2. http://www.securitylab.ru/analytics/355336.php http://www.securitylab.ru/analytics/356476.php Достаточно простые метрики, заложенные в CVSSv2 позволяют более или менее однозначно оценить риск. Более того, метрики позволяют оценивать и различные дополнительные факторы, такие как вероятность эксплуатации и среду. Что очень важно. Цитирую : Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:зависимость от контекста;зависимость от конфигурации системы;зависимость от метода определения. В различных приложениях уязвимости одного типа могут иметь различную степень риска. Так, уязвимость [Подделка HTTP-запросаk может не представлять угрозы для типичного репрезентативного сайта или поисковой машины, и наоборот классифицироваться как проблема высокой степени риска в Web-интерфейсе электронной почты или платежной системы. В результате утечки информации злоумышленник может получить доступ к журналам работы приложения (низкая или средняя степень риска), а может загрузить резервную копию исходных текстов сайта (высокая степень риска). Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость [Внедрение операторов SQLk обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной. В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример [Внедрения операторов SQLk, использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом [белого ящикаk. Т.е. крайне некорректно относить две различные уязвимости одного типа (например 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". Вот такая она разная, оценка рисков.
metrix assesment research positive technologies
Alt text

Тени в интернете всегда следят за вами

Станьте невидимкой – подключайтесь к нашему каналу.