51 Byte x86_64 OS X Null Free Shellcode

It doesn’t seem like there’s a lot of x86_64 bit shellcode out there for the Intel Mac platforms so I figured I’d write my own and share it. I’m using Mac OS X 10.6.5 at the time of this post.

Shellcode

Instead of starting with the source and ending with the shellcode, we’re going to throw this one in reverse and get right to the shellcode. So here you have it, a 51 byte Mac OS X 64 bit setuid/shell-spawning shellcode

  (more…)

Phrack 67 Today!

Phrack 67 comes out today! Phrack is THE online magazine for anyone interested in security. Phrack was the original magazine to debut the infamous “Smashing The Stack For Fun And Profit” article. Its been some time since they last released an issue (2009). “Is your blood boiling?” – heck ya! (more…)

Mac OS X 64 bit Assembly System Calls

After reading about shellcode in Chapter 5 of Hacking: The Art of Exploitation, I wanted to go back through some of the examples and try them out. The first example was a simple Hello World program in Intel assembly. I followed along in the book and had no problems reproducing results on a 32 bit Linux VM using nasm with elf file format and ld for linking.

Then I decided I wanted to try something similar but with a little bit of a challenge: write a Mac OS X 64 bit “hello world” program using the new fast ‘syscall’ instruction instead of the software interrupt based (int 0×80) system call, this is where things got interesting.
(more…)

Conficker’s P2P Update Process

There’s a great article on Conficker variant C’s peer-to-peer update process. It allows for distributed updating abilities by scanning for Conficker peers and implements a simple update protocol

  • What’s your version? Here’s my version. If your running version is higher than mine, send me yours, if not I’ll send you mine.

It’s a pretty in-depth read but very interesting. Check it out

How strong are my passwords?

I think the passwords I use are pretty strong. They’re long, random, alphanumeric, and special characters. I know it’s possible to crack passwords, given enough time, so I thought I’d give it a try. I’m curious how long it’s going to take to crack. (more…)

Ophcrack or Oph-crap?

I did some simple tests tonight using the “free” rainbow tables that come with Ophcrack. I was expecting at least one of my passwords to be cracked but neither were. I think there were a couple reasons for this

  1. The password on my XP machine is 15 characters – Ophcrack only goes up to 14 with the free tables for XP
  2. The password on my Windows 7 machine is not in the dictionary – Ophcrack only uses a “based on dictionary” hybrid table with the free tables for Vista+

The good thing here is that for the “trivial” user, they won’t be able to get my passwords since the non-free tables go for $99 a piece or they’ll need to obtain other tables online.

So is it Ophcrack crap? No, probably not, that would be a little harsh since I bet the free tables would crack a huge majority of the general public’s passwords.

Sniffing Traffic on Your Home Router or Hub

I’ve always knew it was possible to sniff traffic on your home network but every time I tried, I always ended up sniffing ‘management type packets’ (e.g. arp requests, syns, acks, etc). I’d never really seen any useful information come across the wire so I pretty much wrote off the idea of sniffing.

Recently I had done a little deeper dive related to some work I’m doing in class and discovered some of the things I’d done wrong in the past. So here’s a short post on sniffing traffic on your home network. Take a minute to understand the concepts and be responsible with your sniffing activities. (more…)

Online WPA Crackers

Almost everything, in some sense or another, is vulnerable to brute force. It’s just a matter of how long it takes for something to be brute forced that tends to it’s security. I found it pretty interesting that there are now online WPA crackers that will mount dictionary attacks against captured WPA authentication handshakes: (more…)

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

Enjoy!

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 http://www.macports.org/install.php. It’s all very simple double click and install DMG
packages.

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

#!/bin/sh
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.
    • (more…)

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 www.microsoft.com
Server: Microsoft-IIS/7.5

nobody@nobody:~/$ ./detect www.thexploit.com
Server: Apache

nobody@nobody:~/$ ./detect www.google.com
Server: gws

nobody@nobody:~/$ ./detect www.facebook.com
Server: unknown

nobody@nobody:~/$ ./detect www.reddit.com
Server: AkamaiGHost

nobody@nobody:~/$ ./detect www.twitter.com
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]);
		exit(1);
	}

	/* 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_host->h_length);
	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];
		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) {
	printf(error);
	exit(1);
}

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

DYNAMIC RELOCATION RECORDS
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.

Update:

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

Go to Top