Difference between revisions of "Testing for Privilege escalation (OWASP-AZ-003)"

From OWASP
Jump to: navigation, search
m (Added definition of vertical, horizontal escalation. Corrected syntax where it was possible without major restructuring (however, further work is required).)
Line 5: Line 5:
 
== Brief Summary ==
 
== Brief Summary ==
 
<br>
 
<br>
This section describes the issue of escalating privileges from one stage to another. During this phase the tester should verify that is not possible for a user to modify his privileges/roles inside the application that could allow a privilege escalation.
+
This section describes the issue of escalating privileges from one stage to another. During this phase the tester should verify that it is not possible for a user to modify his privileges/roles inside the application that could allow a privilege escalation.
 
<br>
 
<br>
 
== Description of the Issue ==  
 
== Description of the Issue ==  
 
<br>
 
<br>
Privilege escalation occurs when a user gets to access more resources than is normally allowed when it should have been protected from the application. This is usually conducted from a flaw in the application. The result is that the application performs actions with more privileges than intended by the application developer or system administrator.
+
Privilege escalation occurs when a user gets access to more resources than he is normally allowed when it should have been protected from the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than intended by the application developer or system administrator.
  
 
The degree of the escalation depends on which privileges the attacker is authorized to possess and which privileges can be obtained in a successful attack. For example, a programming error that permits a user to gain extra privilege after successful authentication limits the degree of escalation because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.
 
The degree of the escalation depends on which privileges the attacker is authorized to possess and which privileges can be obtained in a successful attack. For example, a programming error that permits a user to gain extra privilege after successful authentication limits the degree of escalation because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.
 +
 +
Usually we refer to ''vertical escalation'' when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to ''horizontal escalation'' when it is possible to access resources granted to a similarly configured account (e.g., in a online banking application, accessing information related to a different user).
  
 
<br>
 
<br>
 
== Black Box testing and example ==
 
== Black Box testing and example ==
 
'''Testing for role/privilege manipulation''' <br>
 
'''Testing for role/privilege manipulation''' <br>
In every point of the application where a user can create information in the DB ( a payment, add a contact, send a message), to receive information (statement of account, order details, etc.) o delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access as another user to verify for example if it is possible to access a functionality that should not permicted by the user's role.
+
In every point of the application where a user can create information in the DB ( a payment, add a contact, send a message), to receive information (statement of account, order details, etc.) or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access as another user to verify for example if it is possible to access a functionality that should not be permitted by the user's role.
  
 
For example:<br>
 
For example:<br>
The following HTTP POST permits to the user that belongs to grp001 to access to order #0001:
+
The following HTTP POST permits to the user that belongs to grp001 to access order #0001:
  
 
  POST /path/viewMyOrder.jsp HTTP/1.1
 
  POST /path/viewMyOrder.jsp HTTP/1.1
Line 27: Line 29:
 
  gruppoID=grp001&ordineID=0001
 
  gruppoID=grp001&ordineID=0001
  
Verify if a user that not belongs to grp001 can modify the value of the parameters ‘gruppoID’ and ‘ordineID’ to gain the access to that reserrved data.
+
Verify if a user that does not belong to grp001 can modify the value of the parameters ‘gruppoID’ and ‘ordineID’ to gain access to that reserved data.
  
 
For example:<br>
 
For example:<br>
The following server's answer shows an Hidden field in the HTML released to the user after a successful authentication.
+
The following server's answer shows an Hidden field in the HTML returned to the user after a successful authentication.
  
 
  HTTP/1.1 200 OK
 
  HTTP/1.1 200 OK
Line 58: Line 60:
 
  StateExecToolBar`0`0`0`FlagsToolBar`0
 
  StateExecToolBar`0`0`0`FlagsToolBar`0
  
The server gives an implicit trust to the user. It belives that the user will answer with the above message closing the session.
+
The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.
 
In this condition, verify that modifying the parameters value it is not possible to escalate privileges.
 
In this condition, verify that modifying the parameters value it is not possible to escalate privileges.
 
For example modifying the `PVValido` value from '-1' to '0' (no error conditions) it is possible to authenticate as administrator to the server.
 
For example modifying the `PVValido` value from '-1' to '0' (no error conditions) it is possible to authenticate as administrator to the server.
Line 64: Line 66:
 
<br>
 
<br>
 
'''Result Expected:'''<br>
 
'''Result Expected:'''<br>
The tester should verifies to execute a successfull privilege escalation<br><br>
+
The tester should verify to execute a successful privilege escalation<br><br>
  
 
== Gray Box testing and example ==  
 
== Gray Box testing and example ==  

Revision as of 05:00, 7 July 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Contents


This is a draft of a section of the new Testing Guide v3

Brief Summary


This section describes the issue of escalating privileges from one stage to another. During this phase the tester should verify that it is not possible for a user to modify his privileges/roles inside the application that could allow a privilege escalation.

Description of the Issue


Privilege escalation occurs when a user gets access to more resources than he is normally allowed when it should have been protected from the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than intended by the application developer or system administrator.

The degree of the escalation depends on which privileges the attacker is authorized to possess and which privileges can be obtained in a successful attack. For example, a programming error that permits a user to gain extra privilege after successful authentication limits the degree of escalation because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation.

Usually we refer to vertical escalation when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to horizontal escalation when it is possible to access resources granted to a similarly configured account (e.g., in a online banking application, accessing information related to a different user).


Black Box testing and example

Testing for role/privilege manipulation
In every point of the application where a user can create information in the DB ( a payment, add a contact, send a message), to receive information (statement of account, order details, etc.) or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access as another user to verify for example if it is possible to access a functionality that should not be permitted by the user's role.

For example:
The following HTTP POST permits to the user that belongs to grp001 to access order #0001:

POST /path/viewMyOrder.jsp HTTP/1.1
Host: www.example.com
[others HTTP Headers]
gruppoID=grp001&ordineID=0001

Verify if a user that does not belong to grp001 can modify the value of the parameters ‘gruppoID’ and ‘ordineID’ to gain access to that reserved data.

For example:
The following server's answer shows an Hidden field in the HTML returned to the user after a successful authentication.

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com 
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache 
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close
<form  name=“autoriz" method="POST" action = “visual.jsp"> 
<input type="hidden" name="profilo" value="SistemiInf1">                                         
<body onload="document.forms.autoriz.submit()">
</td>
</tr>

What if the tester modifies the value of the variable "profilo" with “SistemiInf9”? It is possible to become administrator?

For example:
In an environment in which the server sends an error message contained as value in a specific parameter in a set of answer's codes, as the following:

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValido`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`    
StateExecToolBar`0`0`0`FlagsToolBar`0

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session. In this condition, verify that modifying the parameters value it is not possible to escalate privileges. For example modifying the `PVValido` value from '-1' to '0' (no error conditions) it is possible to authenticate as administrator to the server.


Result Expected:
The tester should verify to execute a successful privilege escalation

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools

  • OWASP WebScarab

...