Crypto challenges - WOWHacker CTF

Last week team CLGT took part in the WOWHacker CTF. I was in charged of crypto challenges, so I decide to write something about challenge 1 and challenge 10.

1. Challenge 1

Challenge 1 is...crazy hahaha. Only one or two teams could solve it until the author (hello hinehong :-D) gave out a list of 7 hints. I have designed some web-related crypto challenges (which you will see soon ^^) so I think the difficulty of challenge 1 relies on how fast people can guess the meaning of the cookie. It would be easier for the teams if the author sets the cookie as cookie = cipher + "|" + key. BTW, here's my solution.

When you access the link above, you'll see a bunch of javascripts. After decoding those javascripts (which I leave as exercise for readers), you'll see a form whose target is http://221.143.48.96:8080/you_are_the_man_but_try_again.jsp. This form accepts a parameter named "hong" which is either true or false. If you set hong=true, the server sends back a cookie like below:

id =pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e

This looks like a base64 encoded string, but it's not. In fact you need to modify it a little bit before you can base64 decode it. This is, as I said previously, why this challenge is hard.

One trick I learn from this challenge is to guess the boundary between key and cipher text, one should try to truncate one character a time and base64 decode the string until he gets an output whose length in bytes is a multiple of 8 or 16, which are common block cipher's block length.

The cookie can be either "cipher + key" or "key + cipher", so one should try the above process in both cases. If you can't find any such output, then you know your theory is wrong, i.e. the cookie is in some other form. Fortunately, my theory is right in this case.

It turns out that the first 32 bytes of the cookie is the cipher text, and the rest 8 bytes is the key. It's a 8-bytes key, so this cookie should be encrypted by DES which is a popular 8-bytes key block cipher. I wrote a small python script to decrypt the it:

>>>from Crypto.Cipher import DES
>>>cookie = 'pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e'
>>> key = cookie[32:]
>>> data = base64.b64decode(cookie[0:32])
>>> des = DES.new(key, DES.MODE_CBC)
>>> des.decrypt(data)
'wowhacke\xd6\xe0\xbc*e\xe7\n\xc7\x1a\xf92w6H\xfd\xe5'

Hmm. I remembered I tried to submit 'wowhacke' to the scoring server, but, of course, it's not the correct answer. Then I wasted the next hour to test various stupid theories to understand what the last 16 bytes of the output are.

It was not until I nearly gave up on this challenge, I realized the obvious: this is mode ECB stupid!!! Why on earth I always thought it's CBC? I changed the mode, and the result is:

>>> des = DES.new(key)
>>> des.decrypt(data)
'wowhacker@!hine@ipsec\x03\x03\x03'

Remember those '\x03\x03\x03'. You'll see them again in my crypto challenges ;-).

2. Challenge 10

Challenge 10 is cool. In summary, the author sets a RSA private key as a property of a Java object, then he gives out the serialization stream of that object, and asks teams to recover the private key to decrypt a ciphertext.

So the first thing we must do is to understand how Java does serialization. I was never a fan of Java, so this is something completely new to me. But that's why I really enjoy playing capture the flag games. It forces me to learn new thing fast in a very short time.

I spent nearly 1 hour reading the spec, mostly on the object serialization stream protocol. Then I spent one and a half hour starring at my hex editor screen and acting as a binary parser which was, I don't know why I feel that, really fun (later on Tora of SexyPwndas fame showed me a much less painful way to recover the object. Thanks Tora!)

I recovered the RSA private key eventually. How to use it to decrypt the ciphertext in key.txt? While de-serializing the object, you would see that there's a field named tripleDesKey containing a 24-bit string which you can get by base64-decoding the last 32 bytes of the serialized object.

At first I thought I should use the RSA key to decrypt this 24-bit string to get the real tripleDesKey, and uses that key in turn to decrypt key.txt. This hybrid approach is the standard way to do encryption using public key cryptosystem. But you shouldn't expect anything standard in CTF, rite?

It turns out all that tripleDes key and ciphertext are just there to distract me. I have to admit that I don't like challenges giving false trails. You can either give good trails or no trail at all. Giving false trail is a sin :-P.

Anyway, if you look at key.txt, you'll see that its content is a 128-bytes string. 128-bytes = 1024-bit = the size of the modulus in the recovered RSA private key. So this string should be the ciphertext encrypted directly using the RSA private key. Indeed it is!

>>> from M2Crypto.RSA import *
>>> rsa = load_key('my_rsa_key')
>>> data = open('key.bin').read()
>>> rsa.private_decrypt(data, 3)
'\x00\x02#padding#x00isec@#$wowhacker!!'

There's a small minor issue that I intentionally left out. Can you find out what it is and resolve it yourself?

I hope you enjoy reading this. Happy hacking!

Web Hacking Challenge - WOWHacker CTF

This post is about challenge 8 which made gamma95 and I feel so lost when it comes to web hacking.

Challenge 8 (not accessible atm) is the only web hacking challenge in WOWHacker's CTF. In hindsight it's not very difficult, but in fact it took us almost 1 day to solve it.

This is a classic PHP local file inclusion attack. If you set the parameter ty and the cookie 71860c77c6745379b0d44304d66b6a13 to the same file name, the vulnerable PHP script in challenge 8 would try to include that file. Here's what the code looks like:

$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
{
echo "Error!";
}
else
{
if (include($ty) != 'OK')
{
    echo "Can't find that page!";
}
}

Update: gamma95 has just noticed me this challenge may not be a PHP local file inclusion attack. Maybe it's just a vulnerable readfile call like this:

$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
{
echo "Error!";
}
else
{
if (file_exists($ty))
{
    readfile($ty);
}
else
{
    echo "Can't find that page!";
}
}

For vulnerable scripts like this, the trick is to include files in known location which may contain important information, i.e. Apache httpd's error_log or access_log. As we knew this is a Windows machine, we tried to test our theory by including C:\Windows\system32\drivers\etc\hosts which worked as expected. At this point, we thought we were just moments away from the solution of this challenge, but in fact we were totally stuck for the next several hours.

We went on to guess the location of Apache httpd's log files. We sent hundreds of requests, but none worked. I even downloaded and installed a copy of Apache httpd to understand its directory structure but still no luck. Why it didn't work???

Like challenge 1, it wasn't until we almost gave up on this challenge, we realized the simple fact: we always thought that the web server was Apache httpd while it was IIS actually! Years of abandoning Windows has brainwashed us! What a shame!

The next steps are simple. The default IIS installation would store log files in C:\WINDOWS\system32\LogFiles\W3SVC1\exYYMMDD.log. As the premilinary round started on 2009.08.14, we guess we should include C:\WINDOWS\system32\LogFiles\W3SVC1\ex090814.log which in turn reveals this secret script:

/tmxhffjsqkdlxmwhaWkddlsemt/answpsorltlagkrpglaemfdjttmqslek/rmfoehrufrnrdpsvntutspdy.php

This script asks for a username and password which gamma95 had bypassed it using a trivial SQL injection attack even before I figured out what I should do next. After bypassing the authentication, we obtained the flag which is: Do you know StolenByte???

No we don't know him, but thanks for a nice challenge!

ISR-evilgrade – Inject Updates to Exploit Software

ISR-evilgrade is a modular framework that allow us to take advantage of poor upgrade implementations by injecting fake updates and exploiting the system or software.

How does it work?

It works with modules, each module implements the structure needed to emulate a false update of specific applications/systems. Evilgrade needs the manipulation of the victims DNS traffic, it works in conjunction with man-in-the-middle techniques or MITM such as DNS, ARP, DHCP, etc.

Attack Vectors

Internal scenario:

• Internal DNS access
• ARP Spoofing
• DNS Cache Poisoning
• DHCP Spoofing

External scenario:

• Internal DNS Access
• DNS Cache Poisoning

What are the supported OS?

The framework is multiplatform, it only depends of having the right payload for the target platform to be exploited.

Implemented modules

• Java plugin
• Winzip
• Winamp
• MacOS
• OpenOffice
• iTunes
• Linkedin Toolbar
• DAP [Download Accelerator]
• Notepad++

You can download ISR-evilgrade here:

isr-evilgrade-1.0.0.tar.gz

Or read more here.

XTest – VoIP Infrastructure Security Testing Tool

What is XTest?

XTest is a simple, practical, and free, wired 802.1x supplicant security tool implementing the RFC 3847 EAP-MD5 Authentication method. It can be used to assess the password strength within wired ethernet environments that rely on 802.1x to protect IP Phones and the VoIP Infrastructure against rogue PC access. XTest is developed in C and freely available to anyone, under the GPLv3 license.
Why XTest?

XTest was developed with the specific aim of improving the security of environments that use 802.1x to protect IP Phone endpoints and their supporting VoIP Infrastructure. With the increasing prevalence of 802.1x Supplicant support in wired hard Phones, 802.1x will be increasingly used to ensure that remote IP Phones placed in areas with low physical security will have their directly connected ethernet switch ports secured against unauthorized access.

Furthermore, the tool can demonstrate the danger of relying solely on 802.1x, because the current wired 802.1x implementation only requires authentication when the port initially comes up/up. Subsequent packets are not authenticated, allowing an attacker to share a connection on a hub with the valid 802.1x supplicant, allowing unauthorized switchport access.

Features

• 802.1x Supplicant: XTest can test the username and password against an 802.1x Authenticator (Ethernet Switch), and supports re-authentication. This is a simple and easy method of comparing the password against a valid 802.1x Supplicant running on an IP Phone or a PC.
• Offline pcap dictionary attacK: If you capture a valid 802.1x authentication sequence into a pcap file, XTest will run a dictionary attack against the pcap using a supplied wordlist. XTest will elicit the password from the pcap if the dictionary file containst the valid password.
• Shared Hub unauthorized access: Using a shared hub, XTest can use the successful authentication of a valid 802.1x supplicant to gain unauthorized access to the network.

Tested Platforms

802.1x Supplicants:

• Cisco Unified IP Phone 7971G-GE
• Cisco Unified IP Phone 7961G-GE
• Cisco Unified IP Phone 7941G-GE
• Cisco Unified IP Phone 7942G
• Cisco Unified IP Phone 7945G
  

802.1x Authenticator:

• Cisco Catalyst 3560 (WS-C3560G-24PS)

Radius Server:

• CiscoSecure ACS 4.1

You can download XTest here:

xtest-1.0.tar

Or read more here.

onesixtyone 0.3.2 – An Efficient SNMP Scanner

The SNMP protocol is a stateless, datagram oriented protocol. An SNMP scanner is a program that sends SNMP requests to multiple IP addresses, trying different community strings and waiting for a reply. Unfortunately SNMP servers don’t respond to requests with invalid community strings and the underlying UDP protocol does not reliably report closed UDP ports. This means that ‘no response’ from the probed IP address can mean either of the following:

• machine unreachable
• SNMP server not running
• invalid community string
• the response datagram has not yet arrived

The approach taken by most SNMP scanners is to send the request, wait for n seconds and assume that the community string is invalid. If only 1 of every hundred scanned IP addresses responds to the SNMP request, the scanner will spend 99*n seconds waiting for replies that will never come.

This makes traditional SNMP scanners very inefficient.

onesixtyone takes a different approach to SNMP scanning. It takes advantage of the fact that SNMP is a connectionless protocol and sends all SNMP requests as fast as it can. Then the scanner waits for responses to come back and logs them, in a fashion similar to Nmap ping sweeps. By default onesixtyone waits for 10 milliseconds between sending packets, which is adequate for 100Mbs switched networks. The user can adjust this value via the -w command line option. If set to 0, the scanner will send packets as fast as the kernel would accept them, which may lead to packet drop.

Running onesixtyone on a class B network (switched 100Mbs with 1Gbs backbone) with -w 10 gives us a performance of 3 seconds per class C, with no dropped packets. All 65536 IP addresses were scanned in less than 13 minutes.

You can download onesixtyone here:

onesixtyone-0.3.2.tar.gz

Or read more here.

sslsniff v0.6 Released – SSL MITM Tool This tool was originally written to demonstrate

Ah can’t believe I haven’t posted about this one before, one of my favourite tools! It was a big breakthrough to have a passive OS-fingerprinting tool after relying on Nmap and Xprobe2 for the longest time.

OS fingerprinting is a very important part of a pen-test during the information gathering stage.

P0f v2 is a versatile passive OS fingerprinting tool. P0f can identify the operating system on:

• machines that connect to your box (SYN mode),
• machines you connect to (SYN+ACK mode),
• machine you cannot connect to (RST+ mode),
• machines whose communications you can observe.

P0f can also do many other tricks, and can detect or measure the following:

• firewall presence, NAT use (useful for policy enforcement),
• existence of a load balancer setup,
• the distance to the remote system and its uptime,
• other guy’s network hookup (DSL, OC3, avian carriers) and his ISP.

All this even when the device in question is behind an overzealous packet firewall, when our favourite active scanner can’t do much. P0f does not generate ANY additional network traffic, direct or indirect. No name lookups, no mysterious probes, no ARIN queries, nothing. How? It’s simple: magic. Find out more here.

P0f is quite useful for gathering all kinds of profiling information about your users, customers or attackers (IDS, honeypot, firewall), tech espionage (laugh…), active or passive policy enforcement (restricting access for certain systems or otherwise handling them differently; or detecting guys with illegal network hookups using masquerade detection), content optimization, pen-testing (especially with SYN+ACK and RST+ACK modes), thru-firewall fingerprinting… plus all the tasks active fingerprinting is suitable for. And, of course, it has a high coolness factor, even if you are not a sysadmin.

P0f v2 is lightweight, secure and fast enough to be run almost anywhere, hands-free for an extended period of time.

You can donwload p0f v2 here:

p0f.tgz
p0f for Windows

Or read more here.

Essential Wireless Hacking Tools

Anyone interested in gaining a deeper knowledge of wireless security and exploiting vulnerabilities will need a good set of base tools with which to work. Fortunately, there are an abundance of free tools available on the Internet. This list is not meant to be comprehensive in nature but rather to provide some general guidance on recommended tools to build your toolkit.

See Dan Hoffman Hack a Blackberry LIVE
at ChicagoCon 2007

Finding Wireless Networks

Locating a wireless network is the first step in trying to exploit it. There are two tools that are commonly used in this regard:

Network Stumbler a.k.a NetStumbler – This Windows based tool easily finds wireless signals being broadcast within range – A must have. It also has ability to determine Signal/Noise info that can be used for site surveys. I actually know of one highly known public wireless hotspot provider that uses this utility for their site surveys.

(NetStumbler Screenshot)

Kismet – One of the key functional elements missing from NetStumbler is the ability to display Wireless Networks that are not broadcasting their SSID. As a potential wireless security expert, you should realize that Access Points are routinely broadcasting this info; it just isn’t being read/deciphered. Kismet will detect and display SSIDs that are not being broadcast which is very critical in finding wireless networks.

(Kismet Screenshot)

Attaching to the Found Wireless Network

Once you’ve found a wireless network, the next step is to try to connect to it. If the network isn’t using any type of authentication or encryption security, you can simply connect to the SSID. If the SSID isn’t being broadcast, you can create a profile with the name of the SSID that is not being broadcast. Of course you found the non-broadcast SSID with Kismet, right? If the wireless network is using authentication and/or encryption, you may need one of the following tools.

Airsnort – This is a very easy to use tool that can be used to sniff and crack WEP keys. While many people bash the use of WEP, it is certainly better than using nothing at all. Something you’ll find in using this tool is that it takes a lot of sniffed packets to crack the WEP key. There are additional tools and strategies that can be used to force the generation of traffic on the wireless network to shorten the amount of time needed to crack the key, but this feature is not included in Airsnort.

(Screenshot of Airsnort in Action)

CowPatty – This tool is used as a brute force tool for cracking WPA-PSK, considered the “New WEP” for home Wireless Security. This program simply tries a bunch of different options from a dictionary file to see if one ends up matching what is defined as the Pre-Shared Key.

(Cowpatty Options Screenshot)

ASLeap – If a network is using LEAP, this tool can be used to gather the authentication data that is being passed across the network, and these sniffed credentials can be cracked. LEAP doesn’t protect the authentication like other “real” EAP types, which is the main reason why LEAP can be broken.

(Asleap Options Screenshot)

Sniffing Wireless Data

Whether you are directly connected to a wireless network or not, if there is wireless network in range, there is data flying through the air at any given moment. You will need a tool to be able to see this data.

Wireshark (formerly Ethereal) – While there has been much debate on the proper way to pronounce this utility, there is no question that it is an extremely valuable tool. Ethereal can scan wireless and Ethernet data and comes with some robust filtering capabilities. It can also be used to sniff-out 802.11 management beacons and probes and subsequently could be used as a tool to sniff-out non-broadcast SSIDs.

(Screenshot of Ethereal in Action)

(Yahoo IM Session being sniffed in Ethereal)

The aforementioned utilities, or similar ones, will be necessities in your own wireless security toolkit. The easiest way to become familiar with these tools is to simply use them in a controlled lab environment. And cost is no excuse as all of these tools are available freely on the Internet.

Protecting Against These Tools

Just as it’s important to know how to utilize the aforementioned tools, it is important to know best practices on how to secure your Wireless Network Against these tools.

NetStumbler – Do not broadcast your SSID. Ensure your WLAN is protected by using advanced Authentication and Encryption.

Kismet – There’s really nothing you can do to stop Kismet from finding your WLAN, so ensure your WLAN is protected by using advanced Authentication and Encryption

Airsnort – Use a 128-bit, not a 40-bit WEP encryption key. This would take longer to crack. If your equipment supports it, use WPA or WPA2 instead of WEP (may require firmware or software update).

Cowpatty – Use a long and complex WPA Pre-Shared Key. This type of key would have less of a chance of residing in a dictionary file that would be used to try and guess your key and/or would take longer. If in a corporate scenario, don’t use WPA with Pre-Shared Key, use a good EAP type to protect the authentication and limit the amount of incorrect guesses that would take place before the account is locked-out. If using certificate-like functionality, it could also validate the remote system trying to gain access to the WLAN and not allow a rogue system access.

ASLeap – Use long and complex credentials, or better yet, switch to EAP-FAST or a different EAP type.

Ethereal – Use encryption, so that anything sniffed would be difficult or nearly impossible to break. WPA2, which uses AES, is essentially unrealistic to break by a normal hacker. Even WEP will encrypt the data. When in a Public Wireless Hotspot (which generally do not offer encryption), use application layer encryption, like Simplite to encrypt your IM sessions, or use SSL. For corporate users, use IPSec VPN with split-tunneling disabled. This will force all traffic leaving the machine through an encrypted tunnel that would be encrypted with DES, 3DES or AES.

Questions or comments can be sent to Daniel V. Hoffman, CISSP, CWNA
danielvhoffman@yahoo.com