When exploiting real world software or devices, achieving arbitrary code execution on a system may only be the first step towards total compromise. For high value or security conscious targets, remote code execution is often succeeded by a sandbox escape (or a privilege escalation) and persistence. Each of these stages usually require their own entirely unique exploits, making some weaponized zero-days a ‘chain’ of exploits.

Considered high risk consumer software, modern web browsers use software sandboxes to contain damage in the event of remote compromise. Having exploited Apple Safari in the previous post, we turn our focus towards escaping the Safari sandbox on macOS in an effort to achieve total system compromise.

Using Frida to fuzz the macOS WindowServer from the lockscreen

Software bugs come in many shapes and sizes. Sometimes, these code defects (or ‘asymmetries’) can be used to compromise the runtime integrity of software. This distinction is what helps researchers separate simple reliability issues from security vulnerabilities. At the extreme, certain vulnerabilities can be weaponized by meticulously exacerbating such asymmetries to reach a state of catastrophic software failure: arbitrary code execution.

In this post, we shed some light on the process of weaponizing a vulnerability (CVE-2018-4192) in the Safari Web Browser to achieve arbitrary code execution from a single click of an unsuspecting victim. This is the most frequently discussed topic of the exploit development lifecycle, and the fourth post in our Pwn2Own 2018 series.

A weaponized version of CVE-2018-4192, executing arbitrary code against JavaScriptCore in early 2018

In software security, root cause analysis (RCA) is the process used to “remove the mystery” from irregular software execution and measure the security impact of such asymmetries. This process will often involve some form of user controlled input (a Proof-of-Concept) that causes a target application to crash or misbehave otherwise.

This post documents the process of performing root cause analysis against a non-deterministic bug we discovered while fuzzing JavaScriptCore for Pwn2Own 2018. Utilizing advanced record-replay debugging technology from Mozilla, we will identify the underlying bug and use our understanding of the issue to speculate on its exploitability.

Using Mozilla's rr, one can place a memory breakpoint, and run an execution trace backwards

Vulnerability discovery is the first stage of the exploit development lifecycle. The duration of this phase is open-ended because the search space, code quality, and evaluation process for a given target can vary wildly. Deciding between manual and automated vulnerability discovery is often a question of priorities and can be difficult to balance effectively.

As part two of our Pwn2Own 2018 blogpost series, we will discuss our methodology of researching a complex software target (the Safari Web Browser), narrowing our scope of evaluation, selecting a vulnerability discovery strategy, and developing a browser fuzzer unique to this engagement.

A snippet of a JavaScript testcase generated by our grammar based JS fuzzer

For a top-level discussion of this blog series and our entire Pwn2Own 2018 exploit-chain, check out part one.

Pwn2Own is an industry-level security competition organized annually by Trend Micro’s Zero Day Initiative. Pwn2Own invites top security researchers to showcase zero-day exploits against high-value software targets such as premiere web browsers, operating systems, and virtualization solutions.

We were interested in participating for the first time this year, choosing to target Apple Safari on macOS because the software & platform was one that we had not worked with before.

For the purpose of this competition, we discovered and exploited two previously unknown vulnerabilities in Apple software to achieve remote code execution as root through a single click in the Safari Web Browser.

Joshua Smith from ZDI evaluating our submitted zero-day at Pwn2Own 2018

At Ret2, we take pride in the breadth and depth of the security research that we perform. Our passion and pursuit of niche subjects has taken us through all walks of the industry. In each new space we touch on, we hope to leave it having made some measurable innovation. But as interest fades, we oftentimes archive this work and move on.

This past weekend, we encountered a candid opportunity to publicly exercise some of our previously unpublished research and technology. Specifically, this blogpost will detail the practical application of an interactive decompiler we wrote for the Ethereum bytecode.

We demonstrate how this technology trivialized the reverse engineering of a closed source smart contract for the qualification round of DEFCON CTF 2018, continuing our narrative on the importance of interactive security tooling.

Decompiling the EVM bytecode from within Binary Ninja

It has been about two months since I pushed out the previous update to Lighthouse, a code coverage plugin for IDA Pro. Overdue for an update, I spent the past several days adding new features to the plugin, addressing feedback, and fixing up bugs that have accumulated since the v0.6 release.

This post marks the release of Lighthouse v0.7 - Big ticket changes include Frida support, a right click context menu, improved usability for large IDB’s, C++ name demangling and a multitude of other tweaks + bugfixes.

Lighthouse v0.7 comes with a right click context menu and function prefixing capabilities

Traditional (assembly level) reverse engineering of software is a tedious process that has been made far more accessible by modern day decompilers. Operating only on compiled machine code, a decompiler attempts to recover an approximate source level representation.

'... and I resisted the temptation, for years. But, I knew that, if I just pressed that button ...' --Dr. Mann (Interstellar, 2014)

There’s no denying it: the science and convenience behind a decompiler-backed disassembler is awesome. At the press of a button, a complete novice can translate obscure ‘machine code’ into human readable source and engage in the reverse engineering process.

The reality is that researchers are growing dependent on these technologies too, leaving us quite exposed to their imperfections. In this post we’ll explore a few anti-decompilation techniques to disrupt or purposefully mislead decompiler-dependent reverse engineers.

ripr is a plugin for Binary Ninja that automatically extracts and packages snippets of machine code into a functionally identical python class backed by Unicorn-Engine. This allows one to quickly and easily reuse logic embedded in binaries, from python.

In the past two weeks, I’ve found time to revisit the project, add several new features, and fix a number of bugs. This blogpost will touch on some of the major updates to ripr.

Generating a python class with ripr

New features include: Automatic Function Argument Mapping, a “Basic Block” mode, and an uninitialized variable detection analysis. Additionally, ripr’s dependency on PyQt5 has been removed.

October 13th marked the conclusion of FireEye’s fourth annual Flare-On Challenge. Every year the Flare-On challenge attracts thousands of hackers, security researchers, and enthusiasts alike in a race to solve a diverse suite of increasingly difficult reverse engineering challenges.

The eleventh challenge (second to last) presented itself as a single PE32 with a subleq based virtualized obfuscator, an architecture consisting of only a single instruction.

Dumping the subleq assembly for the challenge

Some of you will find this eerily reminiscent of movfuscator, a toy compiler by domas which implements a subset of the x86 instruction set using only the mov instruction.

In this post I’ll detail a practical approach towards untangling this challenge. We will implement a custom architecture plugin for Binary Ninja, and then proceed to augment it with some basic reasoning to de-obfuscate the challenge.

Lighthouse is a code coverage plugin for IDA Pro. Last week I promoted the github development branch to master and tagged the release as Lighthouse v0.6. This post details some of its noteworthy changes.

Highlights for this release include a Lighthouse compatible Intel pintool, cyclomatic complexity metrics, batch loading, and a number of important bugfixes.

Lighthouse is a plugin to explore and visualize externally collected code coverage in IDA Pro

/SUBSYSTEM:POSIX

You’ve seen it before, haven’t you? It’s strange. It’s like a face you passed on the street but can’t quite place. Was it déjà vu? A doppelganger? Maybe the first time you saw it it was in a sea of linker flags on MSDN, or perhaps when fumbling around with the project settings in Visual Studio some years ago.

You lingered for an extra second thinking “What on earth…?” while your eyes glazed over in reverie.

POSIX Subsystem Linker Flag in Visual Studio 2015

An artifact of evolution and monument to supporting legacy software. It was built by the ancients, forgotten, and left for new generations to rediscover.

No, this isn’t the new Windows Subsystem for Linux. Beneath this flag lay the classic POSIX Subsystem on Windows.