Joomla 3.4.4 SQL Injection Exploitation via SQLMap

October 19, 2015 Exploits & PoC's, Hacking Tutorials, Uncategorized No comments yet


Bypassing Unvalidated Open Redirect Filters

July 19, 2015 Hacking Tutorials, Uncategorized No comments yet

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

July 19, 2015 Hacking Tutorials, Uncategorized No comments yet

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.

Products
Recent Posts
Recent Comments
    Archives
    Categories
    Meta