Thursday, July 30, 2015

Advisory: [20150601] Joomla! Core - Open Redirect

Project: Joomla!
SubProject: CMS
Severity: Low
Versions: 3.0.0 through 3.4.1
Exploit type: Open Redirect
Reported Date: 2015-April-08
Fixed Date: 2015-June-30
CVE Number: CVE-2015-5608

Description: Inadequate checking of the return value allowed to redirect to an external page.

Affected Installs: Joomla! CMS versions 3.0.0 through 3.4.1

Solution: Upgrade to version 3.4.2

Contact: The JSST at the Joomla! Security Center.

Tuesday, July 21, 2015

[CTF Walkthrough] - Practical Website Hacking by

Here are my solutions for the levels I have solved so far for the CTF hosted by InfoSec Institute. Most of the levels are set for beginners in web application security and some of these scenarios are what we actually find during application penetration tests.

Browser: Firefox 39.x
Tools: Burp suite

UPDATE: I am on the winners list:

Level 1: A3 Cross-Site Scripting (XSS)

Target URL:

I saw that a request to the server was not sent when submitting the data. So there must be a client-side script that must be at work here.

There are many ways to actually debug JS, but I chose this quick and dirty way. Capture and observe all the responses when the page is requested. I found that there was a JavaScript validation being used to replace special characters such as "<" and ">" on both the form fields.

I modified the JavaScript logic so that I can use tags (<,>) and replaced with the character "~" instead.

var siteName = $(".ex1 input[type='text']").val().trim().replace(/~/g, "&lt;").replace(/~/g, "&gt;");
var siteURL = $(".ex1 input[type='url']").val().trim().replace(/~/g, "&lt;").replace(/~/g, "&gt;");

I entered the below payload into the "Site URL" field and submit.


There you go! The well known alert! :-)

Lesson learnt: Do not use client side validation and more importantly do not trust user input EVER!

Level 2: A1 Injection

The application code seems to be using eval() function in PHP which is vulnerable to dynamic code injection. I assumed that the code would be something like (not exactly).

$compute = $operand1.$operator.$operand2 

Both the operand fields seemed to accept only numeric values, otherwise would throw an error. After a lot of trial and error, I injected into the operator field the payload ;phpinfo();// and it worked like a charm!

There's the pop up!

More about how this exactly works is given here:'Eval_Injection')

Level 3: Data Validation; Parameter Delimiter

I am yet to solve this one!

Level 4: A4 Insecure Direct Object References

After a lot of trial and error, I tried double extension and I got a different error message (maybe this works?)

I tried to insert and it says I tried to add a remote URL (I can possibly load remote content?).

That's good news, I guess.

Let me actually try with and some random file name. Based on the hint, I tried changing the URL to uppercase except for the filename.

Et Voila!  :-O

Level 5: A7 Missing Function Level Access Control

Target URL:

I gotta admit, I used up all the hints and broke my head for several hours for this one. Tampering the HTTP verb doesn't do the trick, but also gotta modify the value of the referrer. In reality, I do not believe this scenario might come up or I have not seen this combination :-/

I found the login page link in the HTML source code.

The request to bypass the login is shown below. Th HTTP verb was modified to "CAT" and the Referrer URL is originating from "login.html"

That's it! A weird way to bypass a login page.

Level 6: A8 Cross-Site Request Forgery (CSRF)

This is the easiest one of all, as soon someone says CSRF via XSS we would immediately think of the IMG tag (atleast I do).

The payload used was: <img src="">

The above HTML tag would be executed on the logged in victim's browser and would send the above request with his cookies (CSRFed).

Challenge completed!

Level 7: A3 Cross-Site Scripting (XSS)

This level is about the vulnerable PHP $_SERVER variables such as PHP_SELF being used in the action of a form or part of an anchor's href attribute. 

A similar example can be found at:

Access the URL:'> <h1>haxorhead</h1>

The inserted tag now becomes part of the HTML and the name is displayed!

Level 8: File inclusion

The uploaded files can be viewed by providing the filename in the URL parameter "file" and this is possible using the PHP include to display the contents of the file.

The above URL would not work because the file chess1.png is a valid image file and does not have any PHP code that can be parsed.

I uploaded a file with "JPEG" extension and the below contents.

That's it, now access the uploaded file using the below URL:

It was strange that there was no pop up!

Level 9: A2 Broken Authentication and Session Management

Captured the request using Burp and noticed that the cookie parameter "user" has a base64 encoded value.

The base64 value was decoded and the result was: John+Doe. The application authenticates the user based on this cookie value.

Encode Mary+Jane to base64 value and replace the value of the cookie parameter "user" in the request as shown below.

That's it! I am now logged in as Mary Jane.

Level 10: Source Code Tampering

I pretty much managed to do whatever I want and I met the objective as well. But for some reason I do not get any pop up or message about completion. Not sure what I'm missing.

Level 11: Bypassing blacklists

Same as Level 9, change the value of the cookie parameter "welcome" to yes.


Level 12: Dictionary Attack 

I used intruder in Burp suite to perform the brute-force attack on the login page. The below dictionary list was used:

Here's the intruder configuration:

The password was: princess

Level 13: A10 Unvalidated Redirects and Forwards

The last one is a filter bypass by adding double slashes in the redirect parameter. Access the below URL: