woFF

XSS? – javascript location object encoding in various browsers

woff — Tue, 08 Jun 2010 20:27:46 +0000

I thought it would be great to quickly share some interesting stuff I noticed about the way the different browsers handle the javascript location object, but first a few words about the object’s properties and what they contain:

hash – everything after the # (anchor) in the URL
host – the hostname and port
hostname – the hostname
href – the full URL
pathname – path to the requested file
port, protocol – i think these speaks for themselfs
search – the query string (~GET parameters)
target – the url link’s target name

What is so interesting about these parameters? Well it seems that the different browsers handle the values in them differently and if they are written back to the html with javascript (for example with document.write) they can easily lead to cross-site-scripting. Here is the summary about the parameters I found “interesting” (not encoded by the browser):

	IE 8	Firefox 3.6.3	Chrome 4.1.249.1064	Opera 10.53
location.hash	not encoded	not encoded	not encoded	not encoded
location.href	not encoded	encoded	not encoded (the hash in it is not encoded)	not encoded (the hash in it is not encoded)
location.search	not encoded	encoded	encoded	encoded

I used the following simple html site to check the parameters:

location object XSS test

I opened the URL “inner_html_xss_01.html?bold?#italic?” and was looking for bold and italic texts (of course they could have been some nasty javascript calls as well).

For example the result on Firefox was:

On Internet Explorer 8:

I don’t know if this is intended in the different browsers, but one thing is sure: if it is avoidable try not to use javascript to work with changeable parameters or at least encode everything by hand as well .

I haven’t really played yet with parameter pathname and target, but I think it is possible to get similar results. The browsers act differently if the url comes from a link or is entered directly to the browser… I will check these later and update the table…

I don’t think these are vulnerabilities in the browsers, but in some (very limited) scenarios they can be exploited, so I thought it worths a post. Don’t be afraid to comment

SSH2 “MITM” like attack with JMITM2

woff — Wed, 26 May 2010 23:40:23 +0000

First: the following attack is not a real (at least not a perfect) man-in-the-middle attack, since the target will get a warning about the altered SSH server footprint and the attacker needs to “hijack” the communication between the target and the SSH server (ARP cache poisoning for example…), but I think the tool deserves a note (all the credits for the software goes to David Gümbel).

I remember, the first time I downloaded JMITM2 from http://www.david-guembel.de/index.php?id=6 I was sitting in a web cafe near to the university with a friend trying to “attack” each others SSH2 connection. Tonight I am alone, so I started two Damn Small Linux (DSL) in Virtualbox. One will be the SSH server (192.168.56.101), other will be the attacked client (192.168.56.102) and the host will be the attacker (192.168.56.1).

After starting the SSH server on 192.168.56.101 with the commands “sshstart” and “/etc/init.d/ssh start” and connecting to the service from the client machine (192.168.56.102) to get the RSA fingerprint it is time to prepare the attacker machine.

I will start with JMITM2 since it needs some configuring and arpspoof is pretty simple to use…

First we need to edit JMITM2′s bin/conf/server.xml file and change the “ListenAddress” to our IP (192.168.56.1 in this case) and “Port” to the standard SSH port (22).

Now let’s edit the bin/runm.sh script and set the SSH server’s IP address (192.168.56.101) as the first parameter:

JMITM2 is set up, for arpspoof we just need a few iptables rules:

We need to spoof “two-ways” so two arpspoof will be running (the attacked machine must think we are the SSH server and normally the SSH server should think we are the attacked machine), so we should run “arpspoof -i vboxnet0 -t 192.168.56.101 192.168.56.102″ as well.

After these steps when the target tries to connect to the SSH server he will connect to us (hopefully provide us a password ) and we will build a new connection to the SSH server in his name (just like a proxy). Of course the situation is not that simple. When the attacked machine connects to us JMITM2 will start connecting to the SSH server and ask us if we accept the provided fingerprint (this is necessary only first time) – of course we accept it. JMITM2 sends a login prompt to the attacked machine, but the SSH client will warn the user, that the fingerprint sent by us is not the same as the “original” SSH server’s:

If the user “wants to continue connecting” (which he really should not!) we will get his/her credentials:

(by the way as you can see JMITM2 generates a lot of output, “grep” is recommended )

The session for the attacked user of course will work correctly, we will “proxy” every command and result.

Some things to notice:

the attack absolutely depends on the attacked user, if he doesn’t accept the changed RSA key fingerprint we are lost
maybe I was not careful enough, but JMITM2 builds the connection to the SSH server in our name (from our IP), so the attacker IP will be logged on the server… I will check soon if this is how it is meant to work.
ARP spoofing is bad

Maybe later I will play with the plugin features of JMITM2, I think there will be some more fun to discover.

// I welcome every comment or observation…

HSIYF Hacking Tournament #1

woff — Tue, 18 May 2010 22:24:29 +0000

Background

Not so long ago it turned out that Vadium (congratulations!) and me got a “shared” first place in “How Strong Is Your FU Hacking Tournament #1″, so I decided to archive my feelings, findings and the penetration test here.

A few weeks before when I saw the above banner on offensive security’s blog I got excited. Well I’m not a Jackie Chan fan, but I had a feeling that this must be something really good. Couple of minutes later I was registered and started to think about the things I had to do to prepare for the “hacking tournament”. I got a new version of Ubuntu on my computer and googled for security tools nearly every night for a week. I know… BackTrack is great, but I wanted to refresh my memories and look after some new tools.

As it turned out more than 1000 contestants got the mail with the required information to “start the fight”. The rules were simple:

no denial of service (DoS) attacks
no disruptive attacks
no attacks against “non-target machines”

There were three target machines, but to gain access to two of them the contestants had to hack their way through the “n00bfilter”. I really don’t want to repeat my “official” report here, if you are interested in every technical detail you can download the document from here, if you are interested in others reports you can grab them from here. Of course there were no ultimate solutions, but these worked for me.

n00bfilter

As I said to gain the required access to the “internal” network the machine “n00bfilter” had to fall. First step was to enumerate the machine, run a portscan, grab some service banners if necessary. SSH and HTTP were open.
After checking a default login page on the HTTP port I started trying some basic sql injection attacks to bypass the authentication. Some probes resulted in a warning page from the web application firewall (WAF) called “dotDefender” that it blocked my request. I tried some more advanced sql injections, but I always got the error message, so I moved my “cross-hairs” from the login page to the WAF. I checked some information about the software and it turned out, that the installed version is vulnerable to a post authentication remote command execution vulnerability.
The web interface of the software was in the default directory, I got a Basic HTTP auth popup asking for my username and password. Actually the popup provided a valid username (admin) and the password was “manually bruteforced”… well, it was the word “password” (not too hard to find out indeed).

So I got a valid “Authorization” header, used it in a forged packet sent out against the target with Paros.

In fact before I sent the working packets I wanted to take a look on the admin interface of the WAF. It was a mistake… logging in triggered the firewall and I got banned for 5 minutes every time (ideal for some coffe and small-talk with the girlfriend ). But Paros got the result quickly… one search for the proof file (n00bSecret.txt) and one to “cat” its contents. After entering the proof into the tournaments control panel I was very surprised (and of course extremely happy) to see my nick show up first on the scoreboard.

killthen00b

Despite the fact that the attack flow in the above image is very short and easy this machine had some interesting things to explore.

After running an nmap and analyzing the results I decided to go after the installed SurgeMail application. With google I found some exploits against it, but all of them needed a valid SMTP user and password. We were given with an FTP user and password, but a quick check confirmed that that user is not a valid SMTP user. Port 3389 was open, so i started rdesktop and tried to connect to the computer, in a sec a Windows 7 login screen showed up. Just to be sure I checked if the FTP user is able to log in here, the result was good, but not excellent… he is not in the “Remote Desktop Users” group (but this error message means that he is a valid local user and we know his password!).

I grabbed the installed FTP servers banner with netcat and found an excellent directory traversal attack against it on explo.it. Just to be sure I downloaded some config files, SurgeMails administrator (admin.dat) and user (nwauth.dat) database and found the cgi-bin of SurgeMail’s “WebMail”. Running john against the two SSHA hashes provided me one valid SMTP user (n00b with password pippo123). Since I found the cgi-bin directory and had a plan in my mind I didn’t launch SurgeMail related exploits against the server. Why not use metasploit to generate a reverse payload, upload it, run a meterpreter listener and execute the uploaded executable “through” a browser.

Yeah, it was that simple, the proof.txt was in the administrators desktop (and since we got NT AUTHORITY/SYSTEM it wasn’t problem to access it).

ghost

For me this one was the nightmare at the beginning. I just couldn’t find anything to attack. Port 80 was only open, a dummy login page was available and thats it. I tried to silently portscan it, ran nikto, httprint… everything I knew. It looked like an IIS/ASP, but it wasn’t. Some default ASP files were found by nikto for example, but they were 0 byte long. So after deciding this is a linux and the webserver is apache 2.x I was stuck… no exploit, no input field to play with. I left the tournament for 10 hours to be with my friends, to celebrate a birthday and got back to finally find something new, which I should have found 12 hours before. A javascript on the test.asp page (which I just didn’t try manually…). From here it was just a few hours left to gain a root shell. Following the traces of the javascript I found another directory and a vulnerable PHP login script. Started my own webserver, rewrote a PHP shell script (to work correctly) and used the remote file inclusion vulnerability to include it.

Using the PHP shell I uploaded and executed a reverse perl shell connecting to port 4567… just to have a more comfortable environment to hack.

I got www-data, but needed root… local privilege escalation would be ideal, but the kernel was pretty new, so after some check I gave up on the kernel and searched for another clue. I opened upsecurityfocus.com and started to look for vulnerabilities affecting Ubuntu (starting with the newest one). After some hours of searching I found an EXT4 vulnerability, the only problem was that I had to compile the exploit and do “su – root” (which requires TTY shell…). GCC was easily found on the target (/usr/bin/gcc-4.4) and to get around the “su: must be run from terminal” error message I used a simple python script.

Summary and thanks

It was fun, thanks for the challenges and congratulations to the contestants. Buherátoréknak meg külön grat a sebességért!

Hello World!

woff — Tue, 18 May 2010 22:24:04 +0000

After due deliberation (and getting a shared first place in the HSIYF Hacking Tournament #1 – see the next post) I decided to start this site to have a place where I can share my ideas, developments and achievements in the IT security field with the public. Anything shared in this site is released by me and there isn’t any connection or liability that belongs to my current or any previous eployer.