ENGINEERING BLOG

Binary Ninja support, HTML coverage reports, consistent styling

Lighthouse is an open source code coverage explorer designed for security professionals. This post documents the landmark release of Lighthouse v0.8, most notably introducing support for Binary Ninja, a more consistent cross-platform user experience, and countless other features, tweaks, and bugfixes.

To give some perspective, over 35 files (of ~40) that make up the core plugin were modified. The journey from Lighthouse v0.7 to v0.8.1 consists of a long and twisted ~96 commits, making up a third of the entire project’s commit history. Under the hood, multiple components of the project underwent substantial changes.

A gource visualization of the code contributions behind Lighthouse v0.8

The shortage of proficient cyber operators in a world now dependent on connectivity and information has left nations scrambling to build capabilities in a volatile and high stakes race for digital arms. Despite the availability of near infinite capital, the industry finds itself bottlenecked by a scarcity of experts. This deficit has been further aggravated by the increasing complexity of the field, and lack of upstream educational investments.

As strong advocates of security education, we’ve dedicated time towards developing a number of unique technologies to help address this widening deficit. We demonstrate how these tools can be used to educate larger, less specialized demographics, improve student-autonomy, and scale the security workforce to meet market demands.

Four Heap Sprays, Two Dangling Pointers, One Bitflip

As the sixth and final post of our Pwn2Own 2018 series, we document the long and twisted road of weaponizing CVE-2018-4193 to exploit the macOS WindowServer. Serving as a memory-corruption based privilege escalation to root, this was used as a zero-day to escape the Safari sandbox on macOS 10.13.3.

First, we will describe the constraints of our discovered vulnerability. We then cover the tools and techniques used to discover interesting corruption targets compatible with our vulnerability, followed by a detailed walkthrough of the exploit as developed for Pwn2Own 2018. Finally, we publish the source to our complete exploit at the end of the post, offering a challenge and reward for the community to build a better exploit.

Fuzzing the macOS WindowServer for Exploitable Vulnerabilities

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.

Illustrating the Progression of Advanced Exploit Primitives In Practice

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

Root Cause Analysis of a Non-Deterministic JavaScriptCore Bug

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

Evaluating Complex Software Targets for Exploitable Vulnerabilities

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.

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.

Practical Decompilation of Ethereum Smart Contracts

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.

Frida, C++ demangling, context menu, function prefixing, bugfixes

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

A Sampling of Anti-Decompilation Techniques

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.

Function Arguments, Basic Block Mode, and more

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.

Supplementing Flare-On 2017 with some sanity

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.

Intel pintool, cyclomatic complexity, batch load, bugfixes

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

Compiling Executables for the Classic POSIX Subsystem on Windows

/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.