Archive for October, 2010

Change MAC Address on Mac OS X

Changing your MAC address can be useful in main situations. If you’re reading this page, you’re already likely aware of why it’s useful so let me get straight to the details.

Disassociate from an Access Point (AP) without turning off AirPort

nobody@nobody:~$ sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport
nobody@nobody:~$ sudo airport -z

Change the MAC address

nobody@nobody:~$ sudo ifconfig en1 ether 00:11:22:33:44:55


Sniff Open Wireless Traffic with Mac OS X

Sniffing open wireless traffic can be pretty interesting and entertaining. It’s amazing to see what gets transferred across a network. Just make sure you’re doing it legally.

Sniffing on Mac OS X is very similar to sniffing on any other operating system with a few small caveats.

1. Install MacPorts

This is the best package manager IMHO for OS X. You’ll need to install Apple XCode Developer tools prior to installing MacPorts. The install page details all that information here It’s all very simple double click and install DMG

2. Install Wireshark

Open a Terminal:

nobody@nobody:~$ sudo port install wireshark

If you just start Wireshark at this point, no interfaces will show up. Your user needs to own /dev/bpf in order to use the interfaces.

3. Create a Startup Script

Create this small script in /usr/bin/wireshark_start

osascript -e "do shell script "chown $USER /dev/bpf*" with administrator privileges";
wireshark &

Give it full execute permissions

nobody@nobody:/usr/bin$ sudo chmod +x wireshark_start
4. Configure Wireshark & Start Sniffing

Start Wireshark

nobody@nobody:~$ wireshark_start

Once Wireshark is open, choose Capture->Options, choose Interface ‘en1′, ensure ‘capture packets in monitor mode’ is enabled, click Start!

You should now be capturing packets. You’re pretty much ‘drinking from a fire hose’ so you need to make sure you utilize Wireshark’s Filter section. e.g. to filter http traffic, type in ‘http’ in the filter box and hit apply.

The Current State of Wireless Security

This post is a small survey of existing Wi-Fi security protocols pertaining to home and small offices as of Oct. 25th, 2010

WEP – Wired Equivalent Privacy – WEAK

Anyone with the slightest knowledge of wireless security protocols knows that WEP is very insecure. A very inexperienced individual can get the tools and watch a tutorial on how to crack a WEP key in a few hours. WEP seriously has so many problems from a cryptographic point of view.

  • The master key is used within the encryption instead of deriving a key from the master key.
  • Keys can be derived from datagrams.
  • The hashing algorithm it uses for integrity is weak (CRC32)

Do not secure your network with WEP. WEP will be completely out of production by 2014.

WPA – Wi-Fi Protected Access – MODERATE-STRONG

WPA was the interm solution to WEP’s serious weaknesses while WPA2 was developed. One of the important points of WPA is that it derives encryption keys from the master key instead of utilizing the master key in the encryption.

WPA has held it’s ground for some time but it still vulnerable to brute-forcing weak passwords by capturing an authentication handshake.Weaknesses in WPA implementations have been discovered as early as 2008 and are continuing to be discovered into early 2010.

The current vulnerabilities exist in the Temporal Key Integrity Protocol (TKIP) (the enhanced protocol to address WEP vulnerabilities). They allow an attacker to inject a small amount of valid encrypted packets of their choice. When the original vulnerability was discovered, Quality of Service (QoS) needed to be enabled on the access point in order to successfully take advantage of the vulnerabilities. Specifically, having QoS enabled,
allowed one to bypass WPAs replay protection. However, as of early 2010, the QoS requirement for the attack is not required. Because this vulnerability doesn’t expose the key, people are not as concerned about it and it hasn’t warranted much concern. Although the attacks aren’t much of a concerned, I’d suggest if you’re going to use WPA, use WPA-AES, NOT WPA-TKIP. TKIP was officially deprecated from the 802.11 spec as of early 2009. The take home message of WPA as quoted from the Wi-Fi alliance:

Q: Is WPA still secure?
Yes, WPA remains secure. WPA is the major upgrade to Wi-Fi security, applicable to
enterprise and home users. WPA was independently verified to address all of WEP’s
known weaknesses. WPA2 is not being released to address any flaws in WPA.

WPA2 – Wi-Fi Protected Access 2 – STRONG

WPA2 was the final spec that the Wi-Fi Alliance had been working on when WEP vulnerabilities were discovered. Instead of utilizing TKIP for encryption, WPA2 utilizes AES. WPA2 is very similar to WPA-AES with a few minor differences that are negligible to security protection.

Like WPA, WPA2 passwords can also be brute-forced, thus strong and random passwords should be used. Other weaknesses in WPA2 do exist but they can generally be avoid by implementing basic security practices. Due to the deprecation of TKIP and the inherently stronger AES encryption, WPA2 is the recommended wireless security protocol. 

Cracking WEP with the Intel 3945abg

Since I’ve been reading a lot about security in networking, I figured I’d give the well known WEP cracking a try.

Common Misconceptions With Wep Cracking
  1. You need a special card to crack WEP keys.
    • This is not true, with some caveats. Any card that can be switched to “monitor mode” can be used to crack WEP keys. The vast majority of cards can do this or someone has written a custom driver (e.g. Airport Extreme Cards on Macs) to enable it. HOWEVER, and this is a big however; if you want to crack WEP without waiting for days or even weeks, you need a card to supports “packet injection.” This list is much smaller but growing as the hardcore driver writers write custom drivers for them.
  2. Nobody is going to crack my WEP key
    • Not only is this entirely untrue, I personally promise you it will happen. There are now websites hooked into the Google Maps API which map out SSID’s and their encryption level, typically on major roads –
Intel 3945abg Wireless Card

This is the card that I have on my Dell Inspiron 640m and is a very popular card for laptops. Natively, this card does not support injection but around 2007 a package called ipwraw was developed by Tolas Feup and has since had 3 versions up to 2008 – I use Backtrack and as of version 4.0 this card is fully supported with no custom configuration, simply load up Backtrack and start capturing and injecting!


With Backtrack loaded (ensure you’re in an graphical environment, if not type ‘startx’), do the following:

Turn on monitoring mode on the Intel card. You should then have a mon0 interface.

airmon-ng start wlan0

Now, search for your WEP Access Point (AP) by scanning SSIDs. This uses a technique called channel hoping to rapidly switch through all wireless channels to capture broadcasting packets:

airodump-ng mon0

Once you located your WEP AP, type ‘-c’ to terminate airodump-ng and copy the BSSID of your WEP AP and make note of the channel. We’re now going to turn it back on but have it only capture this specific BSSID. Leave this terminal open when you’re done.

airodump-ng --bssid BSSID -c CHANNEL -w OUTPUT_FILE mon0

Now we need to associate with the AP. Open a new terminal and type

aireplay-ng -1 0 -a BSSID mon0

If you received authentication successful from the previous command, you can move on. We’re now going to do an ARP replay attack against the AP so that we can get it to generate enough Initial Vectors (IV) (I plan to discuss the details of WEP weaknesses in a later post) that it will reuse one and from there we can obtain the WEP key

aireplay-ng -3 -b BSSID -h 00:11:22:33:44:55 mon0

This command may take a minute or so. What it’s doing is capturing packets and looking for an ARP packet. Sometimes it can take a while to find an ARP packet if there is little activity on the AP. Once it finds an ARP packet, you’ll see it repeatedly send ARP packets — this really is the key to the speed of the attack. Without this, we’d have to wait for quite some time to get enough IVs to do the crack.

Now you’ll need to monitor the airodump-ng terminal. Once the ARP packets are being replayed you should see the count in the Data column grow at a fast rate. You need to wait until this number is very large (depending on the key size of the AP). Try with 50k and then 100k and so on. Once you’ve captured enough data you can stop the aireplay-ng sending ARP requests and run the following (replace with OUTPUT_FILE from above):

aircrack-ng OUTPUT_FILE-01.cap

If successful you’ll get a KEY FOUND! with the cracked WEP key. Enjoy, have fun, and don’t do anything illegal please!

Simple HTTP Server Detector

The preamble to this post is that you can do this in a few lines with CURL, telnet, wget etc. I’m also sure someone has already written one of these but coming from a Java background, it was useful for me (and may be to others) to write a simple application that uses sockets in C.

very Simple HTTP Server Detector 1.0

(I was laughing when I wrote that title)

nobody@nobody:~/$ ./detect
Usage: ./detect < domainname >

Output looks like this

nobody@nobody:~/$ ./detect
Server: Microsoft-IIS/7.5

nobody@nobody:~/$ ./detect
Server: Apache

nobody@nobody:~/$ ./detect
Server: gws

nobody@nobody:~/$ ./detect
Server: unknown

nobody@nobody:~/$ ./detect
Server: AkamaiGHost

nobody@nobody:~/$ ./detect
Server: hi <=== LOL!!

If you’re new to C, see if you can come up with an implementation on your own and then check out the reference below (heavily commented for understanding):

 * Simple HTTP Server Detector
 * Copyleft 2010.
 * All rights have been wronged.
 *  Created on: Oct 5, 2010
 *      Author: xploit
#include <stdio.h> /* Printf, perror, etc */
#include <stdlib.h> /* exit */
#include <sys/socket.h> /* sockets */
#include <netinet/in.h>
#include <netdb.h> /* Host lookup */
#include <string.h> /* bzero */

/* HTTP port */
#define WEB_PORT 80
/* Receive buffer size */
#define RECV_BUF 1024
/* Server buffer size */
#define SRVR_BUF 256

void fatal(char *error);

int main(int argc, char **argv) {

	int socket_fd, i;
	struct sockaddr_in remote_addr;
	struct hostent *remote_host;
	char recv_buf[RECV_BUF], srvr[SRVR_BUF];

	if (argc < 2) {
		printf("Usage: %s <domainname>n", argv[0]);

	/* Create a socket */
	if ((socket_fd = socket(PF_INET, SOCK_STREAM, 0)) == -1) {
		fatal("Failed to create socketn");

	/* Resolve the domain name */
	if ((remote_host = gethostbyname(argv[1])) == NULL) {
		fatal("Failed to resolve domain namen");

	/* Set address and port of remote host */
	memcpy(&(remote_addr.sin_addr), remote_host->h_addr_list[0],
	remote_addr.sin_family = AF_INET;
	remote_addr.sin_port = htons(WEB_PORT);

	/* Zero out the rest of the struct */
	memset(&(remote_addr.sin_zero), 0, 8);

	/* Connect to the domain */
	if ((connect(socket_fd, (struct sockaddr *) &remote_addr,
			sizeof(struct sockaddr))) == -1) {
		fatal("Unable to connect to domainn");

	/* Send a HTTP head req */
	if ((send(socket_fd, "HEAD / HTTP/1.0rnrn", 19, 0)) == -1) {
		fatal("Error sending HEAD requestn");

	/* Receive the response */
	if ((recv(socket_fd, &recv_buf, 1024, 0)) == -1) {
		fatal("Error reading HEAD responsen");

	/* Find the server substring */
	char *srvr_ptr = strstr(recv_buf, "Server:");

	/* Fail if it wasn't found */
	if (srvr_ptr == NULL) {
		fatal("Server: unknownn");

	/* Read server line*/
	i = 0;
	while (srvr_ptr[i] != 'n' && i < SRVR_BUF) {
		srvr[i] = srvr_ptr[i];
	/* Terminate String */
	srvr[i] = '\0';

	/* Clear string */
	srvr_ptr = NULL;

	/* Print the results */
	printf("%sn", srvr);

	/* Stop both reception and transmission */
	shutdown(socket_fd, 2);

	return 0;

// Prints an error and exits
void fatal(char *error) {

How is glibc loaded at runtime?

I’ve been looking into address-space randomization. ASLR relies on randomizing the based address of things like shared libraries, making return-to-libc attacks more difficult. I understood the basics of ASLR but I still had a lot of questions. How are shared libraries, like libc, loaded at runtime? What is the global offset table? What is the procedure linkage table? What is a position independent executable? In this post, we’re going to look at all of these.

Back in the Day

In “the olden days” libraries used to be hard coded to be loaded at a fixed address in memory space. Runtime linkers had to deal with relocating conflicting hard coded addresses. Windows, to some extent, still does this.

PIC – Position Independent Code

Then came along Position Independent Code which simply means that the code (usually shared libraries) can be loaded at any address in memory-space and relocations are no longer a problem. In order to do that, binaries added sections for the GOT and the PLT.

Global Offset Table

Every ELF executable has a section called the Global Offset Table or the GOT for short. This table is responsible for holding the absolute addressof functions in shared libraries linked dynamically at runtime.

nobody@nobody:~$ objdump -R ./hello_world

./hello_world:     file format elf32-i386

OFFSET   TYPE              VALUE
08049564 R_386_GLOB_DAT    __gmon_start__
08049574 R_386_JUMP_SLOT   __gmon_start__
08049578 R_386_JUMP_SLOT   __libc_start_main
0804957c R_386_JUMP_SLOT   printf
Procedure Linkage Table

Just like the GOT, every ELF executable also has a section called the Procedure Linkage Table or PLT for short (not to be confused with BLT (Bacon Lettuce Tomato) ). If you’ve read disassembled code, you’ll often see function calls like ‘printf@plt,” that’s a call to the printf in the procedure linking table. The PLT is sort of like the spring board that allows us to resolve the absolute addresses of shared libraries at runtime.

nobody@nobody:~$ objdump -d -j .plt ./hello_world

./hello_world:     file format elf32-i386

Disassembly of section .plt:

08048270 <__gmon_start__@plt-0x10>:
 8048270:       ff 35 6c 95 04 08       pushl  0x804956c
 8048276:       ff 25 70 95 04 08       jmp    *0x8049570
 804827c:       00 00                   add    %al,(%eax)

08048280 <__gmon_start__@plt>:
 8048280:       ff 25 74 95 04 08       jmp    *0x8049574
 8048286:       68 00 00 00 00          push   $0x0
 804828b:       e9 e0 ff ff ff          jmp    8048270 <_init+0x18>

08048290 <__libc_start_main@plt>:
 8048290:       ff 25 78 95 04 08       jmp    *0x8049578
 8048296:       68 08 00 00 00          push   $0x8
 804829b:       e9 d0 ff ff ff          jmp    8048270 <_init+0x18>

080482a0 <printf@plt>:
 80482a0:       ff 25 7c 95 04 08       jmp    *0x804957c
 80482a6:       68 10 00 00 00          push   $0x10
 80482ab:       e9 c0 ff ff ff          jmp    8048270 <_init+0x18>
The GOT, The PLT, and the Linker

How do these all work together to load a shared library at runtime? Well it’s actually pretty cool. Lets walk through the first call to printf. Printf@plt, which is not really printf but a location in the PLT, is called and the first jump is executed.

080482a0 <printf@plt>:
 80482a0:       ff 25 7c 95 04 08       jmp    *0x804957c
 80482a6:       68 10 00 00 00          push   $0x10
 80482ab:       e9 c0 ff ff ff          jmp    8048270 <_init+0x18>

Notice that this jump is a pointer to an address. We’re going to jump to the address pointed to by this address. The 0x804957c is an address in the GOT. The GOT will eventually hold the absolute address call to printf, however, on the very first call the address will point back to the instruction after the jump in the PLT – 0x80482a6. We can see this below by looking at the output of the GOT. Essentially we’ll execute all of the instructions of the printf@plt the very first call.

(gdb) x/8x 0x804957c-20
0x8049568 <_GLOBAL_OFFSET_TABLE_>:      0x0804949c      0xb80016e0      0xb7ff92f0      0x08048286
0x8049578 <_GLOBAL_OFFSET_TABLE_+16>:   0xb7eafde0      0x080482a6      0x00000000      0x00000000

In the PLT code, an offset is pushed onto the stack and another jmp is executed

080482a0 <printf@plt>:
 80482a0:       ff 25 7c 95 04 08       jmp    *0x804957c
 80482a6:       68 10 00 00 00          push   $0x10
 80482ab:       e9 c0 ff ff ff          jmp    8048270 <_init+0x18>

This jump is a jump into the eventual runtime linker code that will load the shared library which contains printf. The offset, $0×10, that was pushed onto the stack tells the linker code the offset of the symbol in the relocation table (see objdump -R ./hello_world output above), printf in this case. The linker will then write the address of printf into the GOT at 0x804957c. We can see this if we look at the GOT after the library has been loaded.

(gdb) x/8x 0x804957c-20
0x8049568 <_GLOBAL_OFFSET_TABLE_>:      0x0804949c      0xb80016e0      0xb7ff92f0      0x08048286
0x8049578 <_GLOBAL_OFFSET_TABLE_+16>:   0xb7eafde0      0xb7edf620      0x00000000      0x00000000

Notice that the previous address, 0x80482a6, has been replaced by the linker with 0xb7edf620. To confirm that this indeed is the address for printf, we can start a disassemble at this address

(gdb) disassemble 0xb7edf620
Dump of assembler code for function printf:

Since the library is now loaded and the GOT has been overwritten with the absolute address to printf, subsequent calls to the function printf@plt will jump directly to the address of printf!

All of this also has the added benefit that a shared library is not loaded until a function in it’s library is loaded — in other words, a nice form of “lazy-loading!”

Zues Botnet & Its Sophistication

The Zues trojan has been around for quite some time. Enough time that some people have even dedicated entire websites to tracking Zues Botnets (According to the Zues Tracker, even a host on my hosting company is, or was at one time, part of the Zues Botnet!!). It’s primary target is stealing bank account information and it has been utilized successfully to steal a lot of money!

It’s said to be one of the biggest, if not the biggest, Botnets on the Internet according to Wikipedia.

Zues is a very sophisticated piece of malware. Instead of the standard central IRC based “command & control” — it utilizes a P2P web based command center which completely eliminates centralized shutdown. It also comes equipped with sophisticated updating abilities and spreads through multiple vectors, including Facebook and LinkedIn.

Even more so interesting, the bot writers built in functionality to kill your operating system. Seems like a smart idea if you want to self destruct your botnet!

If you’re interested there’s tons of info on the Zues botnet online; just do a quick search.


Excellent post from McAfee Labs on Zeus Crimeware Toolkit showing that it even comes with a graphical interface for configuring and building the malware!

Learning about malware analysis

Like my previous post on wanting to learn more about rootkits, I’d love to learn more about malware analysis. How do antivirus companies reverse engineer malware that they find? How does the FBI get clues to the original of malware? I’m sure there is tons of stuff online to read but I’m also going to check out this book (so much to learn!)

Malware Forensics: Investigating and Analyzing Malicious Code covers the emerging and evolving field of “live forensics,” where investigators examine a computer system to collect and preserve critical live data that may be lost if the system is shut down. Unlike other forensic texts that discuss “live forensics” on a particular operating system, or in a generic context, this book emphasizes a live forensics and evidence collection methodology on both Windows and Linux operating systems in the context of identifying and capturing malicious code and evidence of its effect on the compromised system.
Malware Forensics: Investigating and Analyzing Malicious Code also devotes extensive coverage of the burgeoning forensic field of physical and process memory analysis on both Windows and Linux platforms. This book provides clear and concise guidance as to how to forensically capture and examine physical and process memory as a key investigative step in malicious code forensics.
Prior to this book, competing texts have described malicious code, accounted for its evolutionary history, and in some instances, dedicated a mere chapter or two to analyzing malicious code. Conversely, Malware Forensics: Investigating and Analyzing Malicious Code emphasizes the practical “how-to” aspect of malicious code investigation, giving deep coverage on the tools and techniques of conducting runtime behavioral malware analysis (such as file, registry, network and port monitoring) and static code analysis (such as file identification and profiling, strings discovery, armoring/packing detection, disassembling, debugging), and more.

* Winner of Best Book Bejtlich read in 2008!
* Authors have investigated and prosecuted federal malware cases, which allows them to provide unparalleled insight to the reader.
* First book to detail how to perform “live forensic” techniques on malicous code.
* In addition to the technical topics discussed, this book also offers critical legal considerations addressing the legal ramifications and requirements governing the subject matter

I’d love to get my hands on some of these binaries and dive in. If anyone happens to have any of these to analyze, please contact me!
Zues Bot


One Time Password Protocol Using Your Email

Do you ever have a login that needs to be secure but you don’t want to create and remember a new random and cryptic password? I do all the time, especially for things that I don’t log in to frequently but still need to be secure. Remembering tons of 12+ random password, even with key store is a pain.

So I created a one time password protocol that I use all the time with popular sites like Twitter

The Protocol
  1. On computer @ site to login, click the “Forgot Password” link – enter the email you registered with the site
  2. Generate a random 12+ (100+ if you wanted!) alphanumeric/special char password using a random password generator (they’re all over online)
  3. Highlight and copy the password (CTRL-C/CMD-C)
  4. Log in to the email address, click the “Reset Your Password” link in the email you received from the site.
  5. Paste and submit the new password @ the reset screen
  6. Return to site login, enter username, paste password
  7. Copy something random back into the clipboard — like a space
  8. Forget
Go to Top