This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Privilege escalation (OTG-AUTHZ-003)"

From OWASP
Jump to: navigation, search
(New page: {{Template:OWASP Testing Guide v3}} '''This is a draft of a section of the new Testing Guide v3''' == Brief Summary == <br> This section describes the issue of escalating privileges from...)
 
 
(32 intermediate revisions by 12 users not shown)
Line 1: Line 1:
−
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
  
−
'''This is a draft of a section of the new Testing Guide v3'''
+
== 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 or her privileges or roles inside the application in ways that could allow privilege escalation attacks.
  
−
== Brief Summary ==
+
Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.
−
<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.
 
−
<br>
 
−
== Description of the Issue ==
 
−
<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.
 
  
−
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.
 
  
−
<br>
+
The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit. For example, a programming error that allows 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.
−
== Black Box testing and example ==
+
 
 +
 
 +
Usually, people 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 an online banking application, accessing information related to a different user).
 +
 
 +
 
 +
== How to test ==
 
'''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 portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), can 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 such functions as another user in order to verify if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).
  
 +
=== Manipulation of user group ===
 
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 allows the user that belongs to grp001 to access order #0001:
 +
<pre>
 +
POST /user/viewOrder.jsp HTTP/1.1
 +
Host: www.example.com
 +
...
  
−
  POST /path/viewMyOrder.jsp HTTP/1.1
+
  groupID=grp001&orderID=0001
−
Host: www.example.com
+
</pre>
−
[others HTTP Headers]
 
  
−
gruppoID=grp001&ordineID=0001
+
Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.
  
−
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.
+
=== Manipulation of user profile ===
  
 
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 a hidden field in the HTML returned to the user after a successful authentication.
  
 
  HTTP/1.1 200 OK
 
  HTTP/1.1 200 OK
Line 43: Line 46:
 
  Expires: Thu, 01 Jan 1970 00:00:00 GMT
 
  Expires: Thu, 01 Jan 1970 00:00:00 GMT
 
  Connection: close
 
  Connection: close
−
  <form  name=“autoriz" method="POST" action = “visual.jsp">  
+
−
  <input type="hidden" name="profilo" value="SistemiInf1">                                        
+
  <form  name="autoriz" method="POST" action = "visual.jsp">  
 +
  <input type="hidden" name="profile" value="SysAdmin">
 
  <body onload="document.forms.autoriz.submit()">
 
  <body onload="document.forms.autoriz.submit()">
 
  </td>
 
  </td>
 
  </tr>
 
  </tr>
  
−
What if the tester modifies the value of the variable "profilo" with “SistemiInf9”?  
+
 
−
It is possible to become administrator?
+
What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
 +
 
 +
=== Manipulation of condition value ===
  
 
For example:<br>
 
For example:<br>
−
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:
+
In an environment where the server sends an error message contained as a value in a specific parameter in a set of answer codes, as the following:
 +
 
 +
@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`   
 +
StateExecToolBar`0`0`0`FlagsToolBar`0
 +
 
  
−
@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.
  
−
The server gives an implicit trust to the user. It belives that the user will answer with the above message closing the session.
+
In this condition, verify that it is not possible to escalate privileges by modifying the parameter values. In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.
−
In this condition, verify that modifying the parameters value it is not possible to escalate privileges.
+
<br><br>
−
For example modifying the `PVValido` value from '-1' to '0' (no error conditions) it is possible to authenticate as administrator to the server.
 
  
 +
=== Manipulation of IP Address ===
 +
Some webistes uses IP address to limit the access or count the number of error login based on IP address.
  
−
...<br>
+
For example:
−
'''Result Expected:'''<br>
+
X-Forwarded-For: 8.1.1.1
−
The tester should verifies to execute a successfull privilege escalation<br><br>
+
 
 +
In this case, if the website uses the value of 'X-forwarded-For' as client IP address, tester may change the IP value of the 'X-forwarded-For' HTTP header to workaround the IP source identification.
 +
 
 +
=== URL Traversal ===
 +
Try to traverse the website and check if some of pages that may miss the authorization check.
 +
 
 +
For example:
 +
/../.././userInfo.html
 +
 
 +
=== WhiteBox ===
 +
If the URL authorization check is only done by partial URL match, then it's likely testers or hackers may workaround the authorization by URL encoding techniques.
 +
 
 +
For example:
 +
startswith(), endswith(), contains(), indexOf()
 +
 
 +
=== Weak SessionID ===
 +
Weak Session ID has algorithm may be vulnerable to brute Force attack.
 +
For example, one website is using MD5 (Password + UserID) as sessionID. 
 +
Then, testers may guess or generate the sessionID for other users.
  
−
== Gray Box testing and example ==
 
−
'''Testing for Topic X vulnerabilities:'''<br>
 
−
...<br>
 
−
'''Result Expected:'''<br>
 
−
...<br><br>
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
−
...<br>
+
* Wikipedia - Privilege Escalation: http://en.wikipedia.org/wiki/Privilege_escalation<br>
−
'''Tools'''<br>
+
 
−
* OWASP WebScarab
+
 
−
...<br>
+
==Tools==
 +
* OWASP WebScarab: [[OWASP WebScarab Project]]
 +
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy (ZAP)]

Latest revision as of 02:23, 8 February 2017

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

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 or her privileges or roles inside the application in ways that could allow privilege escalation attacks.

Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.


The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit. For example, a programming error that allows 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, people 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 an online banking application, accessing information related to a different user).


How to test

Testing for role/privilege manipulation
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), can 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 such functions as another user in order to verify if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

Manipulation of user group

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

 POST /user/viewOrder.jsp HTTP/1.1
 Host: www.example.com
 ...

 groupID=grp001&orderID=0001

Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.

Manipulation of user profile

For example:
The following server's answer shows a 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="profile" value="SysAdmin">
<body onload="document.forms.autoriz.submit()">
</td>
</tr>


What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?

Manipulation of condition value

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

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-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 it is not possible to escalate privileges by modifying the parameter values. In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.

Manipulation of IP Address

Some webistes uses IP address to limit the access or count the number of error login based on IP address.

For example: 

X-Forwarded-For: 8.1.1.1

In this case, if the website uses the value of 'X-forwarded-For' as client IP address, tester may change the IP value of the 'X-forwarded-For' HTTP header to workaround the IP source identification.

URL Traversal

Try to traverse the website and check if some of pages that may miss the authorization check.

For example: 

/../.././userInfo.html

WhiteBox

If the URL authorization check is only done by partial URL match, then it's likely testers or hackers may workaround the authorization by URL encoding techniques.

For example: 

startswith(), endswith(), contains(), indexOf()

Weak SessionID

Weak Session ID has algorithm may be vulnerable to brute Force attack. For example, one website is using MD5 (Password + UserID) as sessionID. Then, testers may guess or generate the sessionID for other users.

References

Whitepapers


Tools

Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_Privilege_escalation_(OTG-AUTHZ-003)&oldid=226098"