Security Blog
Archive for October, 2010
Change MAC Address on Mac OS X
12 years
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
12 years
by Dustin Schultz
in Security
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
12 years
by Dustin Schultz
in 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
12 years
by Dustin Schultz
in Security
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
- 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.
Simple HTTP Server Detector
12 years
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?
12 years
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
13 years
by Dustin Schultz
in Security News
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!
Learning about malware analysis
13 years
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!
* http://taosecurity.blogspot.com/2008/12/best-book-bejtlich-read-in-2008.html
* 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!
Stuxnet
Zues Bot
One Time Password Protocol Using Your Email
13 years
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
- On computer @ site to login, click the “Forgot Password” link – enter the email you registered with the site
- Generate a random 12+ (100+ if you wanted!) alphanumeric/special char password using a random password generator (they’re all over online)
- Highlight and copy the password (CTRL-C/CMD-C)
- Log in to the email address, click the “Reset Your Password” link in the email you received from the site.
- Paste and submit the new password @ the reset screen
- Return to site login, enter username, paste password
- Copy something random back into the clipboard — like a space
- Forget