Explanation Of Browser Exploitation

It was requested that I give a plain English explanation of how an attacker compromises a browser. I’m going to try to give a lot of detail in some areas but I will leave specific things out in order to not confuse. Hopefully by understanding how programs are exploited readers will be better equipped to choose security programs.

The first step in an attack is getting the victim to hit some kind of content that an attacker controls. This is generally achieved by either hacking a legitimate site and waiting for the user to get there, or sending the victim a link and tricking them into clicking it. Those are not the only ways, nor are they mutually exclusive.

Attacks against a browser can potentially be in the JavaScript renderer, a piece of the browser that looks at the JavaScript code on a webpage. The attacker can slip in some malformed and malicious code that may do many things. One of those things may be to overflow a buffer set up by the renderer.

By doing this an attacker can write to data outside of the buffer, and overwrite some piece of code or data that will essentially give them control over the renderer process. This initial code that runs the necessary instructions to compromise the process is the stage one shellcode. All of these instructions are essentially manipulated instructions that already exist in the process, and an attacker calls them from the legitimate program (in order to bypass DEP) using ‘return oriented programming’ (ROP). ASLR randomizes the location of these usable instructions, which forces an attacker to search for them in some manner (information leak is the most reliable, or heap spray). Once an attacker knows the location of the instructions they can chain them (ROP chain) together to call various functions. There are tools to automate ROP chain generation, which means attackers have to do a lot less work.

Attackers will now typically (they could do it all from stage one through ROP) download their second stage shellcode into the victim browsers address space, and this shellcode will carry out some instruction, such as creating a connection to a remote server.

At this point an attacker has full control over the renderer process (in Firefox this is the same as the browser process, in Chrome it is separated into another process) and can execute code in the context of this process. They can make calls that download and execute payloads, or they can create new threads in separate process, or read a file, or write a file, etc. It is important to know that the attacker’s code is the renderer process – they are the same process, no new process has spawned, it’s all happening within the renderer.

If the attacker wants to they can now drop and execute their third payload (as is common), and this is where programs such as antiexecutables come in – very late in the game. Keep in mind that although an antiexecutable can potentially prevent this payload from executing, attackers have already compromised the process – they can enumerate processes in the system, hop control to another process, keylog, read/write to the file system and registry, they can even run local privilege escalation attacks long before they ever execute this final payload or touch the disk.

So as an attack continues the attacker gains more and more control over a process. Defenses that prevent attacks in stage 1 are ideal, and attacks that don’t kick in until stage 3 have to be very powerful to be effective.

One of the restrictions an attacker will come across is the space that they have to fit their shellcode, which is why, oftentimes, they simply drop the initial shellcode in and have it immediately pull down and execute the file payload. But the advantage to staged shellcode that waits before downloading that final payload is obvious – an attacker can gain significant information on the system, they can avoid forensic analysis, AV, AE, etc. But as most users make virtually no effort to secure their systems users of such products have gotten away with it by being a just-difficult-enough target relative to the rest of the world.

It’s important to note that attacks do nothave to follow this patter. Java attacks are typically ‘sandbox escapes’, they run Java code on the system and then trick the Java Virtual Machine into running the code as a standard user, so there’s no shellcode, there’s just a malicious class file launching and running the malware directly. I didn’t go into information leaking, I really just talked about a very specific attack using a buffer overflow, and the focus was more to explain how staged shellcode works.

If something needs clarifying just let me know in a comment.