Privilege escalation

Privilege escalation vulnerabilities are often found in applications, which contain more than one an account type/privilege. In this case, it is a vertical privilege escalation in comparison to the cross-user access vulnerability (horizontal privilege escalation).

The detection of this type of vulnerability varies from application to application. Some knowledge about the application usually is necessary to execute a successful attack. For example the access to the different application privilege levels can give an attacker, enough information to break the privilege mechanism.

In the good old days, when register_globals was enabled by default, escalation of privilege attacks were quite easy to execute. However, access to the source of the application was required. Considering that there are so many PHP open-source projects, it was not so difficult. Here an attacker was looking for an uninitialised flag/admin variable (the variable, when set to true for example, was giving administrative access to the page/application). When he found one, for example $admin, and the excepted value was ‘1’. The next thing he needed to do was enter the following link to gain administrative privileges:

http://vulnerablesite.com/admin_page.php?admin=1

However, these times are over now, register_globals is disabled in the default configuration for several years and it is not possible to register a PHP global variable using a GET/POST/COOKIE parameters. Therefore, old attack vectors are not valid anymore.

Generally, this vulnerability can have many forms. Some of them are easy to detect and exploit (for example keeping an admin variable at the client side, i.e. Cookie value, parameter in GET/POST request), but some of them can not be found without access to the source code.

I am going to present two privilege escalation vulnerabilities here. The first one is a direct vulnerability, which stems from improper management of privileges. The second one uses different vulnerability class to make the attack successful.

6.5.1.

improper privilege management

At first sight everything seems to be alright with the privilege management. When a standard user tries to access the administrative page, he receives the following screen:

Securing PHP applications

In the background, the HTTP application answer at first glance seems to be correct too. The HTTP request for orders_admin.php looks as below:

GET http://insecure.butterfly.prv/orders_admin.php HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, application/x-silverlight, */*

Accept-Language: en-gb UA-CPU: x86

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Paros/3.2.13

Host: insecure.butterfly.prv Proxy-Connection: Keep-Alive

Cookie: sid=fcf40b5c873f8dd4419e27b95f8f03f4b6fed158

The application answer’s header:

HTTP/1.1 302 Found

Date: Mon, 14 Jan 2008 14:29:55 GMT Server: Apache

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache

Set-Cookie: sid=fcf40b5c873f8dd4419e27b95f8f03f4b6fed158; path=/; domain=insecure.butterfly.prv Location: http://insecure.butterfly.prv/login.php?req=/orders_admin.php

Content-Type: text/html

You can see that the application checks the user privileges and because the user is not the administrator, he is redirected to the login page, where he can re-authenticate to get access to the admin page.

However, there is a very interesting detail I am missing here. The content after the application answer’s header! Let’s take a look at it in the PAROS web proxy:

The selected text in one of the PAROS windows is the HTML code of the orders_admin.php page! What a surprise! Because of some programming error an attacker can get access to the admin page without much problem using this technique.

But accessing the page content in this way is not the most comfortable way we can image. I try to suggest a better way below.

For this purpose you will need a web proxy tool, for example Paros or Webscarab. Next you will have to intercept all responses of the traffic passing through the Proxy. When you log in to the application as a standard user, next try to access orders_admin.php using this URL:

http://insecure.butterfly.prv/orders_admin.php

The intercepted response from the server has to be changed a bit. The following part: HTTP/1.1 302 Found

needs to be changed to: HTTP/1.1 200 OK

After you change the response, click to continue passing through the HTTP traffic. This time you will be able to see the following application interface:

Securing PHP applications

Much better, don’t you think? As you have probably noticed that it is not exactly the same interface as the administrator has. The upper part of the screen comes from the standard user interface, however the accept interface is the real functionality, which was accessed successfully in this attack.

What is important here too, that an attacker is able to not only to read this page. He can use the administrative right to accept the orders without much problem too. Try to accept any of the orders, next you need to only change the response header to ‘200 OK’ and you will see that you action was successful.

6.5.2.

indirect privilege escalation

Sometimes, it is not possible to break the privilege management mechanism. In this case the only thing, which is left to an attacker, is to try to gain administrative privileges indirectly using an other vulnerability.

Many different vulnerabilities can be used for this purpose. I’ve described one in this document. It is based on the permanent Cross-Site Scripting vulnerability and was explained in details in the chapter 6.2.1.2. Similar exploitation can be reached using the file preview vulnerability described in the chapter 6.3.4.

In quick summary, the attacker has to trick the admin user to enter the page in the ButterFly application, where the inserted permanently Cross-Site Scripting code steals transparently the session cookie of the administrator. After it the attacker gains the full access to the application as the administrator has.