report for 192.168.93.132 PORT STATE SERVICE VERSION 111/tcp open rpcbind 2 (rpc #100000) 4000/tcp open remoteanything? 6000/tcp open X11 (access denied) 40001/tcp open unknown 48578/tcp open status 1 (rpc #100024) 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port40001-TCP:V=5.35DC1%I=7%D=6/23%Time=4E030EC3%P=i686-pc-linux-gnu%r( SF:SIPOptions,8A,"Length:22\x2022\r\nFrom:0\r\nCompress:no\r\nVersion:4\r\ SF:nTaskID:0\r\nTaskType:AuthenticationResult\r\nAddress:00:0C:29:3A:5C:9E SF:\r\n\r\n<ACK>InvalidTask</ACK>"); Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.13 - 2.6.31
probes send data designed to trigger responses to a listening service port • Responses are matched against regular expressions to identify previously profiled services • Probe / Response signatures are stored in the “nmap- service-probes” file in the nmap directory SF-Port40001-TCP:V=5.35DC1%I=7%D=6/23%Time=4E030EC3%P=i686-pc-linux-gnu%r( SF:SIPOptions,8A,"Length:22\x2022\r\nFrom:0\r\nCompress:no\r\nVersion:4\r\ SF:nTaskID:0\r\nTaskType:AuthenticationResult\r\nAddress:00:0C:29:3A:5C:9E SF:\r\n\r\n<ACK>InvalidTask</ACK>");
point we were running out of time on client site • Lot of other testing and reporting to be done • The issue was reported to the client as a Denial of Service vulnerability with potential for code execution ...Or Is It?
provide a pre-configured ThinPro virtual machine for testing purposes • HP ThinPro Test Drive • Download and unpack the virtual machine and we’re ready to continue testing
Option 1: Configure the Virtual Machine with GDB • Vulnerable package already installed • No GDB or symbols • Root file system mounted in read only • Option 2: Install the vulnerable package on another distribution • Must ‘acquire’ the vulnerable package • GDB and symbols already installed
a breakpoint in the crashing function in GDB • Run a non-overflowing test case • Backtrace the code execution back from libc++ • This gives us the address of the vulnerable function • Next step, load the binaries into IDA and dissassemble (gdb) backtrace #0 0xb667ee10 in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x080dda58 in ?? () #2 0x08083c2d in ?? () #3 0x08082f14 in ?? () #4 0x08063bf1 in ?? () #5 0xb66da96e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0xb6524a4e in clone () from /lib/tls/i686/cmov/libc.so.6
issue is actually rather easy • The cutdown Linux distribution includes no NX (DEP) or ASLR • Only two issues to overcome • The program does not crash while attempting to return to 0x41414141 (as hoped) • The crash appears in a call to the “std::string::assign” function in the “libstdc++” module • The stack needs fixing in order to execute our own code
to a string • std::string::assign(char const*, unsigned int) • Actually takes 3 arguments • A pointer to a string • The unsigned integer is the length of our input buffer • The char const* is pointer to our input buffer • The application takes care of arguments 2 and 3 • We can supply any pointer to writable memory for argument 1 • 0x0811b0a4 • 0x0811b104 • 0x0811b164
at the end of the function looks like above • The argument we passed to std::string::assign is in the way for executing shellcode directly with a JMP ESP • Two options • Return to a JMP [ESP+4] • Return to a POP, RET then a JMP ESP • These both have the same result to begin code execution after the std::string::assign argument 0xb59b51cc: 0x41414141 0x0811b098 0x41414141 0x41414141 0xb59b51dc: 0x41414141 0x41414141 0x41414141 0x41414141 0xb59b51ec: 0x41414141 0x41414141 0x41414141 0x41414141 0xb59b51fc: 0x41414141 0x41414141 0x41414141 0x41414141