I came across with vulnerabilities in UTM device management web interface during security analysis recently. Rather typical combination of CSRF and XSS is interesting because it allows attackers to get access to device command line and manage the system interactively in administrator’s browser. But this is not the whole point, the vulnerability is typicaly.
The most interesting (as always) was communication with the vendor. We did not agree about the vulnerability risk level that led to desperate correspondence. Here I would like to share with you our ideas in this field.
As a rule, risk level is set by software vendor or by a company that produces protection tools (vulnerability scanners, intrusion detection systems, etc.). In this case typical scheme similar to road regulations is used: low risk level (green), medium risk level (yellow), high risk level (red). Sometimes an additional 4th level is used – level of critical vulnerabilities.
Many producers use this approach, for example, Microsoft uses 4 vulnerability risk levels in its security bulletins.
But ‘traffic lights’ model is not transparent and greatly depends on expert world view and general state and other factors. That’s why we use CVSSv2 methodology.
English
http://www.first.org/cvss/cvss-guide.html
Russian
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Rather simple metrics on which CVSSv2 is based allows assessing risks more or less definitely. In addition, the metrics allows assessing several additional factors as exploitation possibility and environment that is very important.
Quotation (Russian):
The most interesting (as always) was communication with the vendor. We did not agree about the vulnerability risk level that led to desperate correspondence. Here I would like to share with you our ideas in this field.
As a rule, risk level is set by software vendor or by a company that produces protection tools (vulnerability scanners, intrusion detection systems, etc.). In this case typical scheme similar to road regulations is used: low risk level (green), medium risk level (yellow), high risk level (red). Sometimes an additional 4th level is used – level of critical vulnerabilities.
Many producers use this approach, for example, Microsoft uses 4 vulnerability risk levels in its security bulletins.
But ‘traffic lights’ model is not transparent and greatly depends on expert world view and general state and other factors. That’s why we use CVSSv2 methodology.
English
http://www.first.org/cvss/cvss-guide.html
Russian
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php
Rather simple metrics on which CVSSv2 is based allows assessing risks more or less definitely. In addition, the metrics allows assessing several additional factors as exploitation possibility and environment that is very important.
Quotation (Russian):
Leaving aside advantages and disadvantages of the methods, the following characteristics could affect the assessment reliability:
- Context dependence;
- System configuration dependence;
- Assessment method dependence.
Vulnerabilities of the same type could be of different risk level in different applications. For example, CSRF vulnerability could not be a threat for typical representation server or search engine, but is a critical vulnerability for e-mail or payment system web interface. As a result of information leakage, an attacker could access application logs (low or medium risk level) or download the backup copy of the site (high risk level).
The system configuration could also affect the risk level. Thus, “SQL Injection” vulnerability is usually classified as a high risk level vulnerability. But if web application has restricted rights on DB server, it is a vulnerability of medium or low risk level. In another installation or implementation the same vulnerability could be used to access operating system with superuser rights that makes the vulnerability critical.
Assessment methods greatly affect vulnerability risk level. For the above example, a network scanner could just detect “SQL Injection” as a problem. To determine the available for potential attackers privileges one should try to use the vulnerability or get detailed information about communications between web application and DB server via white box method.
So it is absolutely incorrect to give to different vulnerabilities of the same type equal risk levels without detailed analysis (for example, SQL Injection).
Here is an example.
Let’s assume that SQL Injection allows to get access to DBMS with minimum web server privileges, for example, db_reader. And web application does not store confidential data (for example, passwords) in DBMS.
So CVSSv2 vector and risk level are:
In the other case, if user passwords are stored in DBMS (including administrator password), risk level is higher as the system is more vulnerable to attacks according to data confidentiality.
(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C)= 8.1
If web server has unreasonably extended privileges on DB server, for example, sa privileges, the same vulnerability is much more dangerous:
(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5
It we reduce it into “traffic lights” model or PCI DSS 5 levels (Urgent, Critical, High, Medium, Low), the result is:
1. Medium (2) and High (3)
2. Medium (2) and Critical (4)
3. High (3) and Urgent (>4).
It means that vulnerability risk level could vary greatly depending on the system and its settings.
CVSSv2 vector for XSS (see description above at the beginning of the note)
(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9
So in terms of PCI DSS (it is this model that is the most popular now) the risk level of the issue is High or even Critical, but not Low. But in any case the audit is failed :))
PS. I can understand vendor’s reasons, as if security is not taken into account when the software is designed then (quotation) "hardening the management interface would probably imply a complete redesign of it".
Here it is – the various risk assessment.
