Something ‘trivial’ will eventually be chained and used against you

Matt
INSINIA
Published in
4 min readDec 9, 2018

One thing I hear a lot, ‘xss is not an issue’, maybe it’s not as issue to you but to me, someone who has been proficient in programming native JavaScript for almost a decade, totally different story.

Why? Well essentially now I am the programmer of your app, I can now write my own code in the context of your application, there are some exceptions but generally the options are limitless. One can simply chain a few lesser conditions together to achieve something greater.

For example, things like adding an admin user (even with robust app defences), port-scanning the users local network or sending payloads to exploit local-only devices to steal Bitcoin (see below) — plus much, much more.

https://twitter.com/h43z/status/950080318601560066

XSS to local exploit is not much of a chain…but chains are everywhere, so let’s up the ante and dive down into the depths of memory land to touch on ROP chains

What is ROP?

ROP stands for Return Oriented Programming, it a leap on from ret2libc, which is basically a really old technique used when an exploit needs to return to libc to invoke a C library function to bypass protections like a non-executable stack.

How do ROP exploits work?

  1. A gadget is a sequence of CPU instructions ending in the RETurn- to- caller instruction. Applicable to all CPUs.
  2. A chain of gadgets can be constructed so that it is malicious code.
  3. Gadgets are harvested from the user written code of the process, and the libraries.
  4. Theorem: Given a large enough process code segments, any arbitrary computation can be performed by a chain of gadgets.
  5. We do not need to inject shell code; instead, build a chain to invoke a shell.
  6. None of the ASLR, NX, DEP mitigation techniques can prevent this exploit.

Source: http://cecs.wright.edu/~pmateti/Courses/4440/Lectures/Exploits/Injection/ROP.html

Say what? Put simply, we re-use the programmers own code, chaining it together to eventually return to code we want to execute.

The most basic example of a ROP exploit, this one is from a baby challenge so functions have been created that need to be called to succeed, in the real world the options could be very limited or limitless depending on application footprint. If you want learn more and try out some exercises head over to https://ropemporium.com/

But ROP is not the only chaining one can do at a low level, don’t forget COP (Call Oriented Programming), JOP (Jump Oriented Programming) & others! None of these would be possible without chaining seemingly harmless instructions together. Even with recent developments in secure compilers they still leave about 2% of code which could potentially be used for advanced ROP chains.

Now we have a little pattern emerging, let’s create a simple equation to help us remember…

trivial + trivial * trivial = lethal

At mobile pwn2own MWR created the longest chain in pwn2own history…

MWR Labs was back to show they shop for bugs in bulk. They used 11 different bugs — plus some “features” — to get code execution and leak sensitive data on the Samsung Galaxy S8. Their exploit chain started in the Samsung Internet Browser, then leveraged a bug in Google Chrome and several other Samsung applications to install an APK, which allowed them to achieve persistence through a reboot.

And an excerpt from an old FireEye report shows the power of chaining to evade modern defenses…

The ability of Angler EK to evade EMET mitigations and successfully exploit Flash and Silverlight is fairly sophisticated in our opinion. These exploits do not utilize the usual return oriented programming to evade DEP. Data Execution Prevention (DEP) is a mitigation developed to prevent the execution of code in certain parts of memory. The Angler EK uses exploits that do not utilize common return oriented programming (ROP) techniques to evade DEP. Instead, they use Flash.ocx and Coreclr.dll’s inbuilt routines to call VirtualProtect and VirtualAlloc, respectively, with PAGE_EXECUTE_READWRITE, thus evading DEP and evading return address validation-based heuristics.

Every hack is some form of chain at a macro level… portscan -> enumeration -> exploitation, I believe it even has a fancy name…Cyber Kill…? ah, chain, that’s right, but even at a micro level advanced threats chain seemingly benign, unrelated elements together… bug -> feature -> condition -> info leak -> bug -> pwn etc.

I try to always remember, just because I can’t see how much of a risk a trivial element is, or I don’t know how to exploit it, doesn’t mean someone else can’t, they usually can!

Finally, never forget that just because something seems ‘trivial’, it does not mean it will not eventually be chained and used against you. Next time you think a trivial issue is not worth your attention, remember this old proverb, For Want of a Nail…

“For want of a nail the shoe was lost.
For want of a shoe the horse was lost.
For want of a horse the rider was lost.
For want of a rider the message was lost.
For want of a message the battle was lost.
For want of a battle the kingdom was lost.
And all for the want of a horseshoe nail.”

--

--