Attackers exploit a vulnerability in the Ksoft Uploader software! for installing Gh0st RAT
Our analysts receive for analysis thousands of new malware samples every day and among this general flow, it is possible to find curious instances. In this case, it is not even about the executable file, but about the data file, which is the configuration file of a legitimate application. Such a file and fell into our hands.
Further analysis of the suspicious file showed that it is malicious and leads to a vulnerability in the product Uploader! Ksoft company. Below are the details of the exploit and a brief description of its payload.
The exploit itself, that is, the specially configured configuration file of the specified software that we found, uses a buffer overflow ( BufferOv ) vulnerability for its work. Program Uploader! Designed for user experience with FTP protocol. Its settings such as the address of the remote FTP host and the user name are stored in the configuration file referred to as uploadpref.dat.
')
The PoC code for this exploit was published back in March 2014.
Uploader tool configuration file! consists of a set of lines, which includes a line with the name of the user and the name of the target host server to upload (upload) files. For processing the file data and its subsequent parsing, the application uses a standard C ++ incoming stream called std :: ifstream . When reading lines from a file, the application correctly checks the size using the C ++ functions in_stream.get (buffer, sizeof (buffer), '\ n') . However, the application code processing the last field in the file with an encrypted password uses the in_stream >> buffer code, with the buffer array located on the stack. In the event that the application does not call the in_stream.width (...) function, the in_stream >> buffer call will fill the buffer buffer on the stack until the end of the file or the white space character is reached.
Fig. The vulnerability is present in the in_stream >> encrypted_password call, which allows the exploit to overflow the buffer on the stack and execute the necessary code.
ESET specialists promptly contacted the developers of this software and informed them about the found vulnerability. Within 24 hours, Ksoft experts fixed the vulnerability and released a new version of the Uploader! v 3.6.
The malicious file uploadpref.dat analyzed by us causes the program to copy the required amount of data onto the stack and overflow the buffer whose size is fixed and is 80 bytes. As a result of overwriting the data placed in front of the buffer variable, the exploit damages the frame structure (Structured Exception Handler) SEH and places the shellcode there, as well as a pointer to it in the frame. Copying data to an overflowed buffer is stopped by an exception (exception), which signals that the top of the stack has been reached and that it has been addressed at an unacceptable address in the memory (access violation). As a result of the exception that occurred, Windows calls the pointer function from the SEH frame, which has already been overwritten by the exploit. This new address points to the gadget with the code from the address space of the Uploader! .. The gadget is a set of instructions pop ecx; pop ecx; ret . After these instructions are executed, the execution flow is transferred to the first shell code of the exploit, which is already located on the stack.
Fig. View from the debugger of the situation of triggering an exception in case of violation of memory access on the stack. In the command window you can see the instructions of the gadget, from which control is transferred to the shell code.
The method of rewriting SEH handlers is already quite ancient and was described in detail by the Corelan Team team on their website . Windows Vista SP1 + operating systems contain a special function called Structured Exception Handling Overwrite Protection (SEHOP), which protects applications from illegitimate rewriting of SEH handlers at the OS level. This feature is disabled by default on client editions of Windows and enabled by default on server editions. Enabling such a function on client editions of Windows can be performed using the EMET tool or this instruction . In addition, support for the SEHOP mechanism should be provided by the application itself, which must be linked using the / SAFESEH option (not present in the Uploader!).
The exploit is based on the PoC volume, the link to which we cited above, it contains similar sequences of pop commands ; pop; ret at the beginning of the file. In the case of the original PoC, there are significantly more of them and there are a total of 178 teams. Other parts of the exploit, such as the shellcode and its execution levels, were added by the authors themselves.
Fig. Header uploadpref.dat from poc.
Fig. Header uploadpref.dat from the exploit.
Before launching the payload, the exploit needs to perform several steps of its code.
At stage zero (Stage 0), the shellcode takes control from the SEH handler code, which points to a gadget with a sequence of instructions pop ecx; pop ecx; ret . The first shellcode instructions unpack the code of the next level ( shell_code_1 ). It calculates a single-byte value from a two-byte word and writes it to the same memory location.
Fig. The unpacking code for the subsequent shellcode part.
At the end of the first level (Stage 1) the contents of the entire uploadpref.dat file will be copied into memory. For this purpose, the shellcode uses the Windows API functions, obtaining their addresses by analyzing the export tables of the corresponding Windows system libraries directly. The function is searched based on the calculated hash of its name. The hash is calculated by summing each individual hexadecimal representation of the character from the name of the function in lower case and multiplying the intermediate iteration sum by two. Below is the Python code that implements this algorithm.
It is interesting to note that this algorithm for calculating the hash is identical to that specified as an example in the book by Chris Anley and John Heasman entitled "The Shellcoder's Handbook: Discovering and Exploiting Security Holes". Its implementation in C can be found on page 145 of the second edition of the book.
After receiving the corresponding function addresses, the shell_code_1 code allocates two buffers in size in memory with the size of the size of the file uploadpref.dat. The contents of the entire file are copied to one of the buffers, and the second remains intact. After this, the shellcode transfers control to the code from this file located at offset 0x10 from the beginning of the file. Below this code is listed in C.
At the second level (Stage 2), the function unpacks data at offset 0x650 from their beginning into the memblock2 buffer. For data decompression, a rather inefficient algorithm is used, after which their size is 3.632 bytes. After this operation, control is transferred to the beginning of the blocklock2 block, which contains the third level shell code (Stage 3).
At Stage 3, the exploit code reopens the uploadpref.dat file and extracts the PE file from it, which is located at offset 0x1600. The file is placed in a dedicated memory buffer. The decompression algorithm is identical to the one used at the previous level. After this, the exploit creates a new process in suspend mode, injects the executable file there and launches it. The PE file extracted from uploadpref.dat is 56.832 bytes in size and specializes in the loading and execution of a Gh0st RAT dropper.
The table below shows the structure of the uploadpref.dat file.
The downloader copies the original exploit file (uploadpref.dat) and its extracted file called msfeedssync.exe to the current user's Application Data directory. After that, it creates a shortcut to the executable file and places it in the Start menu autostart directory. Thus, after the reboot, the exploit will work again and all steps will be executed again.
Fig. A shortcut in the startup folder indicating the execution of the malware file.
After performing the above operations, the bootloader is considered to be successfully installed in the system and after a reboot it can successfully perform its main function, which is to download the Gh0st RAT dropper. Dropper will be downloaded using the HTTP protocol. To do this, the malware runs at intervals of 30 minutes. two streams. Based on the HTTP user-agent string, which each of them uses to work with a remote server, we called the first thread Alan_function , and the second BFunction . Each of them tries to download the Gh0st RAT dropper from different URLs that use the same domain name. After downloading the file, it is unpacked, each of the threads tries to call different parts of the dropper code.
We were able to detect the first propagation method of the malware dropper, which was used in March 2015. The executable file downloaded by the daunloader was associated with the daunloader itself, since one of its obfuscation functions included the unpacking code of the dropper DLL file calling the exported function TestFunction . This library can be delivered to the BFunction thread to achieve the same results.
The Gh0st RAT executable file downloaded this way is the dropper of this malicious program. Gh0st RAT has been previously documented by various researchers of AV companies. The backdoor network protocol includes a string of five characters to identify a malicious campaign. In our case, the identifier was the string "A1CEA". We were able to find the following links providing backdoor information with the same campaign ID.
In the Gh0st RAT sample we analyzed, the C & C server with the address www.phw2015.com and the TCP port 2015 was used. At the time of our analysis, the domain corresponded to the IP address 112.67.10.110.
This modification of the Gh0st was slightly different from the original backdoor and contained the following functions.
In the sample analyzed by us, all Gh0st functions were active, including the keylogger.
Conclusion
The analyzed exploit is not special or even essential, since the Ksoft Uploader! Software for which it is intended is not a widespread application. We know practically nothing about the purpose for which it was used and by what intruders, like what the vector of its propagation was. A social engineering method could be used for propagation, but in this case the attack should have been directed, since the attackers should have information on the victim’s computer’s presence on the computer. Anyway, the attackers had to lure a potential victim to download this file, and then also point the user to its use and placement in the directory with the program itself.
Gh0st RAT was described in the following studies.
Michael G. Spohn (McAfee), Know Your Digital Enemy: Anatomy of a Gh0st RAT, 2012
www.mcafee.com/ca/resources/white-papers/foundstone/wp-know-your-digital-enemy.pdf
Snorre Fagerland (Norman), The many faces of Gh0st Rat, 2012
download01.norman.no/documents/ThemanyfacesofGh0stRat.pdf
Compromise Identifiers (IoC)
The backdoor uses a mutex with the following name:
www.phw2015.com www.phw2015.com www.phw2015.com
Further analysis of the suspicious file showed that it is malicious and leads to a vulnerability in the product Uploader! Ksoft company. Below are the details of the exploit and a brief description of its payload.
The exploit itself, that is, the specially configured configuration file of the specified software that we found, uses a buffer overflow ( BufferOv ) vulnerability for its work. Program Uploader! Designed for user experience with FTP protocol. Its settings such as the address of the remote FTP host and the user name are stored in the configuration file referred to as uploadpref.dat.
')
The PoC code for this exploit was published back in March 2014.
Uploader tool configuration file! consists of a set of lines, which includes a line with the name of the user and the name of the target host server to upload (upload) files. For processing the file data and its subsequent parsing, the application uses a standard C ++ incoming stream called std :: ifstream . When reading lines from a file, the application correctly checks the size using the C ++ functions in_stream.get (buffer, sizeof (buffer), '\ n') . However, the application code processing the last field in the file with an encrypted password uses the in_stream >> buffer code, with the buffer array located on the stack. In the event that the application does not call the in_stream.width (...) function, the in_stream >> buffer call will fill the buffer buffer on the stack until the end of the file or the white space character is reached.
Fig. The vulnerability is present in the in_stream >> encrypted_password call, which allows the exploit to overflow the buffer on the stack and execute the necessary code.
ESET specialists promptly contacted the developers of this software and informed them about the found vulnerability. Within 24 hours, Ksoft experts fixed the vulnerability and released a new version of the Uploader! v 3.6.
The malicious file uploadpref.dat analyzed by us causes the program to copy the required amount of data onto the stack and overflow the buffer whose size is fixed and is 80 bytes. As a result of overwriting the data placed in front of the buffer variable, the exploit damages the frame structure (Structured Exception Handler) SEH and places the shellcode there, as well as a pointer to it in the frame. Copying data to an overflowed buffer is stopped by an exception (exception), which signals that the top of the stack has been reached and that it has been addressed at an unacceptable address in the memory (access violation). As a result of the exception that occurred, Windows calls the pointer function from the SEH frame, which has already been overwritten by the exploit. This new address points to the gadget with the code from the address space of the Uploader! .. The gadget is a set of instructions pop ecx; pop ecx; ret . After these instructions are executed, the execution flow is transferred to the first shell code of the exploit, which is already located on the stack.
Fig. View from the debugger of the situation of triggering an exception in case of violation of memory access on the stack. In the command window you can see the instructions of the gadget, from which control is transferred to the shell code.
The method of rewriting SEH handlers is already quite ancient and was described in detail by the Corelan Team team on their website . Windows Vista SP1 + operating systems contain a special function called Structured Exception Handling Overwrite Protection (SEHOP), which protects applications from illegitimate rewriting of SEH handlers at the OS level. This feature is disabled by default on client editions of Windows and enabled by default on server editions. Enabling such a function on client editions of Windows can be performed using the EMET tool or this instruction . In addition, support for the SEHOP mechanism should be provided by the application itself, which must be linked using the / SAFESEH option (not present in the Uploader!).
The exploit is based on the PoC volume, the link to which we cited above, it contains similar sequences of pop commands ; pop; ret at the beginning of the file. In the case of the original PoC, there are significantly more of them and there are a total of 178 teams. Other parts of the exploit, such as the shellcode and its execution levels, were added by the authors themselves.
Fig. Header uploadpref.dat from poc.
Fig. Header uploadpref.dat from the exploit.
Before launching the payload, the exploit needs to perform several steps of its code.
At stage zero (Stage 0), the shellcode takes control from the SEH handler code, which points to a gadget with a sequence of instructions pop ecx; pop ecx; ret . The first shellcode instructions unpack the code of the next level ( shell_code_1 ). It calculates a single-byte value from a two-byte word and writes it to the same memory location.
Fig. The unpacking code for the subsequent shellcode part.
At the end of the first level (Stage 1) the contents of the entire uploadpref.dat file will be copied into memory. For this purpose, the shellcode uses the Windows API functions, obtaining their addresses by analyzing the export tables of the corresponding Windows system libraries directly. The function is searched based on the calculated hash of its name. The hash is calculated by summing each individual hexadecimal representation of the character from the name of the function in lower case and multiplying the intermediate iteration sum by two. Below is the Python code that implements this algorithm.
def hash_name (name):
result = 0
for c in name:
result = 2 * (result + (ord © | 0x60))
return result
It is interesting to note that this algorithm for calculating the hash is identical to that specified as an example in the book by Chris Anley and John Heasman entitled "The Shellcoder's Handbook: Discovering and Exploiting Security Holes". Its implementation in C can be found on page 145 of the second edition of the book.
After receiving the corresponding function addresses, the shell_code_1 code allocates two buffers in size in memory with the size of the size of the file uploadpref.dat. The contents of the entire file are copied to one of the buffers, and the second remains intact. After this, the shellcode transfers control to the code from this file located at offset 0x10 from the beginning of the file. Below this code is listed in C.
HANDLE f = CreateFileA (“uploadpref.dat”, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0);
DWORD uploadpref_size = GetFileSize (f, 0);
char * memblock1 = VirtualAlloc (NULL, uploadpref_size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
char * memblock2 = VirtualAlloc (NULL, uploadpref_size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
ReadFile (f, memblock1, uploadpref_size);
stage_2 = & memblock1 [0x10];
stage_2 (& memblock1 [0x650], memblock2);
// the address of the buffer memblock2 is passed to the exploit code as an argument, the exploit will later pass control
At the second level (Stage 2), the function unpacks data at offset 0x650 from their beginning into the memblock2 buffer. For data decompression, a rather inefficient algorithm is used, after which their size is 3.632 bytes. After this operation, control is transferred to the beginning of the blocklock2 block, which contains the third level shell code (Stage 3).
At Stage 3, the exploit code reopens the uploadpref.dat file and extracts the PE file from it, which is located at offset 0x1600. The file is placed in a dedicated memory buffer. The decompression algorithm is identical to the one used at the previous level. After this, the exploit creates a new process in suspend mode, injects the executable file there and launches it. The PE file extracted from uploadpref.dat is 56.832 bytes in size and specializes in the loading and execution of a Gh0st RAT dropper.
The table below shows the structure of the uploadpref.dat file.
The downloader copies the original exploit file (uploadpref.dat) and its extracted file called msfeedssync.exe to the current user's Application Data directory. After that, it creates a shortcut to the executable file and places it in the Start menu autostart directory. Thus, after the reboot, the exploit will work again and all steps will be executed again.
Fig. A shortcut in the startup folder indicating the execution of the malware file.
After performing the above operations, the bootloader is considered to be successfully installed in the system and after a reboot it can successfully perform its main function, which is to download the Gh0st RAT dropper. Dropper will be downloaded using the HTTP protocol. To do this, the malware runs at intervals of 30 minutes. two streams. Based on the HTTP user-agent string, which each of them uses to work with a remote server, we called the first thread Alan_function , and the second BFunction . Each of them tries to download the Gh0st RAT dropper from different URLs that use the same domain name. After downloading the file, it is unpacked, each of the threads tries to call different parts of the dropper code.
- The Alan_function thread expects the uploaded file to be an executable PE file and simply executes it for execution, passing control to the entry point.
- The BFunction thread expects the uploaded file to be a DLL. In this case, it will call from it an exported function called TestFunction .
We were able to detect the first propagation method of the malware dropper, which was used in March 2015. The executable file downloaded by the daunloader was associated with the daunloader itself, since one of its obfuscation functions included the unpacking code of the dropper DLL file calling the exported function TestFunction . This library can be delivered to the BFunction thread to achieve the same results.
The Gh0st RAT executable file downloaded this way is the dropper of this malicious program. Gh0st RAT has been previously documented by various researchers of AV companies. The backdoor network protocol includes a string of five characters to identify a malicious campaign. In our case, the identifier was the string "A1CEA". We were able to find the following links providing backdoor information with the same campaign ID.
- A sample that was discovered in December 2013 and was loaded into the Malwr database.
- The Snort Rule that was added on March 3, 2015
- Analysis of a sample of malware on the Korean portal Wins .
In the Gh0st RAT sample we analyzed, the C & C server with the address www.phw2015.com and the TCP port 2015 was used. At the time of our analysis, the domain corresponded to the IP address 112.67.10.110.
This modification of the Gh0st was slightly different from the original backdoor and contained the following functions.
- The function of collecting data on the characteristics of the computer.
- A special function called “TestFunction” that loads other malicious components of the backdoor.
In the sample analyzed by us, all Gh0st functions were active, including the keylogger.
Conclusion
The analyzed exploit is not special or even essential, since the Ksoft Uploader! Software for which it is intended is not a widespread application. We know practically nothing about the purpose for which it was used and by what intruders, like what the vector of its propagation was. A social engineering method could be used for propagation, but in this case the attack should have been directed, since the attackers should have information on the victim’s computer’s presence on the computer. Anyway, the attackers had to lure a potential victim to download this file, and then also point the user to its use and placement in the directory with the program itself.
Gh0st RAT was described in the following studies.
Michael G. Spohn (McAfee), Know Your Digital Enemy: Anatomy of a Gh0st RAT, 2012
www.mcafee.com/ca/resources/white-papers/foundstone/wp-know-your-digital-enemy.pdf
Snorre Fagerland (Norman), The many faces of Gh0st Rat, 2012
download01.norman.no/documents/ThemanyfacesofGh0stRat.pdf
Compromise Identifiers (IoC)
The backdoor uses a mutex with the following name:
www.phw2015.com www.phw2015.com www.phw2015.com
Source: https://habr.com/ru/post/269751/
All Articles