Netsparker’s Weekly Security Roundup 2018 – Week 01

Table of Content

1. The Impact of Meltdown and Spectre On the Web
2. HTTP Verb Tampering and a phpMyAdmin Cross-Site Request Forgery

The Impact of Meltdown and Spectre On the Web

In January 2018, the discovery of two high-profile vulnerabilities in modern processors was disclosed by spectreattack.com. They were given the names Spectre and Meltdown. The researchers who discovered them worked at Google’s Project Zero, various universities and even a private IT security company.

Both vulnerabilities are caused by problems that arise due to the use of speculative execution, a technique modern processors employ for performance improvements. The impact of both is devastating. They enable the theft of sensitive data, passwords and encryption keys from the memory of affected systems.

One major problem with these security flaws is that attackers can use them to read sensitive system memory, even if the code is executed inside a virtual machine (VM) or a sandboxed environment. This is why many companies are concerned about the sensitive applications they host in the cloud. If attackers manage to run code on the same server, which is often the case in shared environments, they can steal encryption keys and passwords from otherwise secure applications.

However, it turns out that attackers don’t actually have to execute a binary on an affected system to abuse the vulnerabilities. They can also be triggered by malicious javascript code in a user’s browser. This means that any malicious website can read the private data.

But it gets worse if you think about the implications. You don’t actually have to visit a shady website in order to get hacked. The code may be placed on a web application you regularly visit, if it is vulnerable to stored cross-site scripting (XSS). While the usual goal of XSS is to bypass the same origin policy (SOP), in this case, an attacker wants to reach a variety of users with little effort. That makes stored XSS such an appealing attack vector.

While an attacker can also use reflected XSS, it’s less useful in this case. If an attacker can make a user click a suspicious link, he may as well host the payload on his own server. If you own a website, you should take the same precautions as with a classic XSS attack. Use a strong content security policy (CSP) as well as context-dependent encoding in order to make sure that your site’s visitors are secure.

HTTP Verb Tampering and a phpMyAdmin Cross-Site Request Forgery

A vulnerability was discovered in phpMyAdmin, a popular database management tool written in PHP that has been developed for about 18 years now. This particular security flaw, found by Ashutosh Barot, affects versions v.4.7.x prior to 4.7.6.1/4.7.7. It is a Cross-Site Request Forgery (CSRF) vulnerability that allows an attacker to execute actions on behalf of legitimate users, merely by making them open a malicious link.

In order to understand the vulnerability, it is important to look at the message at the top of the commit that introduced the flaw.

This commit is based on the assumption that GET requests are (correctly) used to execute actions that don’t result in a state change. In other words, the GET requests only retrieve data, but do not modify or delete it. It turns out, however, that this wasn’t exactly true.

While there was code that checked for matching CSRF tokens sent via POST requests, it didn’t take GET requests into account. It just didn’t seem necessary for the above-mentioned reasons.

This was a problem though, since HTTP verb tampering was possible for these methods. What is HTTP verb tampering? Whenever your browser sends a request to a web server it sends an HTTP verb.

GET	/	HTTP/1.1
verb	path	protocol version

Applications often decide which action to take based on the HTTP verb. As mentioned already, GET is only designed to retrieve data. For a short period, this was the only available verb. Later, others were added, such as POST, which can be used to change or create data on the server. Other common verbs with different meanings include: PUT, DELETE and OPTIONS.

Sometimes, developers don’t check which HTTP verb is used. PHP even has a predefined variable, that consists either of GET or POST variables, depending on the verb. It’s called $_REQUEST and is often used when both GET and POST requests would lead to the same action on the server side. This makes it significantly harder to use the correct verb, and can easily lead to HTTP verb tampering.

Imagine that there is a CSRF token check that only works when the request method is POST. This example illustrates what such a check might look like:

<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
        // Check if request is valid
        if($_POST["token"] != $_SESSION["csrf_token"]) {
                exit("Invalid token!");
        }
}
$username = $_REQUEST["username"];
$password =  $_REQUEST["password"];
write_user_to_db($username, $password);
?>

The problem is that $_REQUEST doesn’t only accept POST requests; it can also be used with GET. This means that the CSRF token check will never run, but the rest of the code will. In this example, HTTP verb tampering bypassed the check.

Applications are vulnerable when these conditions are met:

• There is a security check for a specific HTTP verb only
• Requests are not discarded if other verbs, are used and the parameters will still be used by the application
• Additionally, it may accept arbitrary verbs

There is a similar problem with the phpMyAdmin vulnerability. Whenever a legitimate user clicks Drop Database, the following URL will be called:

http://example.com/pma/sql.php?ajax_request=true&token=b6a6527a5805591d544fb66c84f30faf&server=1&get_default_fk_check_value=true&_nocache=1515335432843146723

As you can see, there is a CSRF token. This request will create a popup, as illustrated, that prompts you to confirm your action.

However, once you click OK, another request is issued. This time it is a POST request, and it will delete the selected table.

The screenshot clearly shows that the application uses a POST request with a CSRF token. What we can do now is simply issue a GET request with the same parameters. If the application is vulnerable to HTTP verb tampering, it will execute the action without reference to the correct CSRF token, since the check doesn’t run for POST requests.

It works. An attacker can carry out this attack with an image tag like this:

<img src="http://example.com/pma/sql.php?db=one&goto=db_structure.php&table=test&reload=1&purge=1&sql_query=DROP+TABLE+%60test%60&message_to_show=something" >

This serious vulnerability was fortunately fixed in the latest version of phpMyAdmin. If you use a version prior to the ones mentioned above, it’s time to update your installation.