Bypassing Unvalidated Open Redirect Filters

Overview

A quick PoC/tutorial on bypassing open redirect filters in Infosec Institutes Level 13 CTF challenge. Full details on the challenge can be found here: http://ctf.infosecinstitute.com/ctf2/. All credits go to 1N3 @CrowdShield and full disclosure details can be found here: https://xerosecurity.com/dashboard.php?bug_id=691

Request #1

The request below indicates that the affected page is redirecting all requests sent to the redirect= parameter which may be vulnerable to open redirect attacks.

Response #1

The addition of the Location: header indicates that the value specified in the redirect= GET parameter is being injected into the Location: header field.

Burpsuite Open Redirect Fuzz List

Using Burpsuite Intruder or any other web proxy, we can use the following list to check for open redirect vulnerabilities and possible bypasses. This can be downloaded using Gist here: https://gist.github.com/1N3/de48ab54edd831cb12fb

http://google.com
//google.com
\/google.com
\/\/google.com
/\google.com
/\/\google.com
|/google.com
/%09/google.com
/google.com
javascript:document.location=http://google.com

Bypass Request #2

After fuzzing the redirect= parameter, we can see from the responses that javascript is being executed (levelCompleted(13);) only when the bypass is successful. The application attempts to prevent redirection attacks by blocking absolute redirection targets starting with http:// or https://. However, an attacker can defeat this defense by omitting the protocol prefix from their absolute URL. If a redirection target starting with // is specified, then the browser will use the same protocol as the page which issued the redirection. The application also appears to be blocking the standard protocol-relative sequence (//). However, an attacker can defeat this defense by using backslashes instead. Some browsers (notably Chrome and Safari) accept these non-standard protocol-relative sequences.

Bypass Response #2

Bypassing HTML5/Javascript XSS Restrictions

OVERVIEW:

A quick PoC/tutorial on bypassing client-side HTML5/Javascript XSS filters in Infosec Institutes Level 1 CTF challenge. Full details on the challenge can be found here: http://ctf.infosecinstitute.com/ctf2/. All credits go to [email protected]

STEP 1: Inspect the Site Name element

Since the application performs character encoding for the “<” and “>” characters, we will need to check the code to see if the sanitization is occurring at the server level, or client side. If it’s client-side (ie. HTML5/Javascript), this can be altered and bypassed by the user. To do this, use any web browser and right-click on the “Site Name” form element and click the “Inspect Element” option. This will open developer tools which will allow us to edit the properties.

STEP 2: Remove client side restrictions

Replace the existing input field to increase the maxsize field and remove the characters allowed property as follows:

<input type="text" placeholder="Name of site" maxsize="100" class="form-control" required="" name="name">

STEP 3: Edit the ex1.js file to remove character encoding

Since the web application also appears to be sanitizing the “<” and “>” characters via ex1.js (Javascript), we will need to edit the client side javascript first to bypass this. This can be done in web developer tools by clicking the Sources” tab and editing the ex1.js to remove the HTML character encoding:

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

STEP 4: Enter the XSS payload

After the client side validation and sanitizing is removed, enter the following payload into the “Site Name” field and click “Submit”.

<script>alert('Ex1')</script>

RESULT:

The result is that our Javascript alert window was successfully injected into the page after all client-side code was altered and bypassed. To prevent these types of attacks, validation should be done from a server side component that the user cannot control or edit.

Exploiting PHP Eval() Functions

OVERVIEW:

A quick PoC/tutorial on executing arbitrary PHP code via PHP’s eval() function in Infosec Institutes Level 2 CTF challenge. Full details on the challenge can be found here: http://ctf.infosecinstitute.com/ctf2/. All credits go to [email protected]

STEP 1: Understanding the use of eval()

Based on the applications function, we can guess that the application is using similar backend code to calculate the result:

<?php eval(\"$num1\" \"$operand\" \"$num2\"); ?>

STEP 2: Editing the operand field

Since there appears to be server side validation preventing non-integer values for $num1 and $num2, we can try to edit the operand field to get our injected PHP code to run. This can be done using a web browser and right-clicking the element and selecting “Inspect Element”.

STEP 3: Edit the operand field to inject our PHP code

To inject our PHP code, we will edit the operand field as shown below to control the execution of the original function without producing an error:

<option value=" + 1; phpinfo(); 1 + "> + 1; phpinfo(); 1 + </option>

RESULT:

After clicking Submit, you will notice that our injected PHP function is executed and displayed. To prevent these types of attacks, all use of eval() should be avoided at all costs and all user input should be sanitized and validated before being executed.