pydbg is pretty sweet in general as a full featured python debugger.. i’ve kicked it around on windows for some sillyness and just tried the OSX port (http://code.google.com/p/paimei/source/browse/#svn/trunk/pydbg) which seems to work ok..

(it supports a dbg.search_memory(’foo’) call which should yield instant joy, except it doesnt.. i suspect u will have to end up doing your break on SSL_read(), then locating / dumping ur buff)

are u currently using ptrace to get as far as u are ?

Post ur success story when u are done.. :>

Thanks for the comment - and yes I’ve gone down this same track, however even with “more messing about” it’s not actually as easy as it sounds. Apache is quite good about not making system calls with the clear HTTP (except for the log file entry), leaving a tool like “strace” pretty much in the dark. Of course I can see the read and writes to the connected client socket, but this data is already encrypted.

Something like ltrace would be ideal, and I was hoping to hook the openssl calls here, but for whatever reason it manages to crash my apache process, rendering it pretty useless (on my environment at least).

Of course a debugger would be great - but I believe it would be unacceptable to halt the process (think malicious web server admin attempting to steal user credentials in a production environment). I haven’t looked at pydbg, if it’s possible to automate this process then that’s certainly an option. Thanks, I’ll check that out.

So (assuming pydbg doesn’t lead me anywhere) my option using strace is to actually break apart the SSL handshake (as I have the private key), steal the symmetric session key and use this to decrypt the conversation. This is cool because from an attack execution point of view it’s as simple as attaching strace to the running apache processes and logging all the data - the decrypt can occur after the fact, and no fancy tools are required (except strace, which is very common on machines I’ve encountered).

btw - I wanted to say hi and bravo on your itweb talk (i think the most entertaining one of the summit, dom’s a close second), but you sp guys are way too sneaky… :)

Ciao,
Tom

Once it hits the app, theres a basquillion places to hook the data (because the app doesnt notice at all..)

if for some reason u still want to:
i took a quick look this evening, and if u run httpd -X (for simplicity for now) and then attach a debugger, breaking on SSL_read() you should be able to find your way to the un-encrypted buff..

if you did this in pydbg you could automate this fairly easily..

if you are running solaris (or OSX) u could also try dtrace (just for the geek fun of it)

trace -n ’syscall:::entry /execname==”httpd”/{self->arg1=arg1;}’ -n ’syscall::write:return /self->arg1/ {printf(”%s(\”%S\”)\n”,probefunc,copyinstr(self->arg1)); }’

on my machine returns:
CPU ID FUNCTION:NAME
1 17719 write:return write(”::1 - - [03/Jun/2009:22:03:44 +0200] \”GET /?moo=blah/ HTTP/1.1\” 304 -\n”)

1 17719 write:return write(”[03/Jun/2009:22:03:44 +0200] ::1 TLSv1 DHE-RSA-AES256-SHA \”GET /?moo=blah/ HTTP/1.1\” -\n”)

(Both are still calls to the log write, but with more messing about you should get what you need?)