In a recent penetration testing project we encountered a situation where in order to prove exploitability and possible damage we had to exfiltrate data from an isolated server using an OS command injection time based attack.
The scope of the project was an API. During the testing process we identified an interesting GET request that received 2 parameters: the first a string and the other one ID number.
By fuzzing the string parameter, at first, it looked like we had a potential SQL injection, based on the way it handled single quotes. Trying this attack vector didn’t seem successful, but when we sent the ` sleep 10` command and the HTTP response returned 10 seconds later, we knew we had something. Our first thought was that this was game over for the application, we managed to get a Remote Code Execution on the API server.
If you missed the first part of this series, where you can read about what is a shellcode and how it works, you can find it here: Part I. In this part, I will cover required information in order to be able to properly write a shellcode for Windows platform: the Process Environment Block, the format of Portable Executable files and a short introduction to x86 Assembly. This article will not cover all the aspects of these concepts, but it should be enough in order to properly understand shellcodes.
Process Environment Block
Within Windows operating system, PEB is a structure available for every process at a fixed address in memory. This structure contains useful information about the process such as: the address where the executable is loaded into memory, the list of modules (DLL), a flag specifying if the process is being debugged and many others.
It is important to understand that the structure is intended to be used by the operating system. It is not consistent across different Windows system versions, so it may change with each new Windows release, but some common information has been kept.
This article contains an overview of shellcode development techniques and their specific aspects. Understanding these concepts allows you to write your own shellcode. Furthermore, you could modify existing exploits that contain already made shellcode to perform custom functionality that you need.
Let’s say you have a working exploit in Internet Explorer or Flash Player that opens calc.exe. This isn’t really useful, is it? What you really want is to execute some remote commands or to do other useful functionality.
In this situation you may want to use standard existing shellcode as the ones from Shell Storm database or generated by from Metasploit’s msfvenom tool. However, you must first understand the basic principles of shellcoding so you can use them effectively in your exploits.
For those who are not familiar with this term, as Wikipedia says:
“In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called “shellcode” because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode… Shellcode is commonly written in machine code.”