2019 Day 2

### Overview In this presentation, Justin explores the security risks residing within "software development software"—the tools developers use daily to write, compile, and deliver applications. Emphasizing his background in application security and bug hunting rather than red teaming or DevSecOps, the speaker explains why developer workstations are high-value targets. He demonstrates how seemingly innocent actions like navigating directories or opening source code in an IDE can lead to workstation compromise via vulnerabilities in developer toolchains.

### Key Topics - **Targeting Developers**: Software developers frequently possess broad access across an organization's code repositories, production infrastructure, AWS credentials, SSH keys, and shell history. Compromising a developer machine facilitates intellectual property theft and supply chain poisoning. - **Unconventional Attack Surfaces**: Beyond the obvious danger of running untrusted binaries, developer workflows present risks at each stage: cloning repositories (git client bugs), changing directories into untrusted codebases (shell hooking tools), reading code (IDE configuration and document parsers), and building projects (malicious makefiles/build manifests). - **Real-World Parallels**: The speaker references broader supply chain and vertical-specific attacks, such as Forcepoint's research on malicious AutoCAD files, the ShadowHammer campaign compromising ASUS updates, and reports of backdoored compilers used against gaming companies.

### Technical Details - **Ruby Version Manager (RVM) Vulnerabilities**: - RVM hooks into the shell profile and wraps the `cd` command to dynamically adjust environment paths when entering Ruby project folders. - The speaker discovered that RVM parsed `.versions.conf` files to export environment variables. - First primitive: Arbitrary environment variable control allowed setting `PS1` (the shell prompt) to execute arbitrary commands (e.g., via `$(id)`) on prompt expansion. - Second primitive: A flawed sanitization routine attempted to escape backticks and `$()` characters with backslashes before calling `eval`, but failed to escape preexisting backslashes. By prepending a backslash, the two backslashes escaped each other, leaving the subshell command unescaped and achieving arbitrary command execution. - **Visual Studio Code Workspace Settings Flaw**: - VS Code supported workspace configuration via `.vscode/settings.json`, including the ability to specify the `git.path` setting. - Using `strace`, the speaker determined that VS Code invoked the specified git binary directly via an `exec`-style sink rather than passing arguments through a shell. - VS Code ran commands in sequence: first `<git.path> --version` from the user's current working directory, and then `<git.path> rev-parse` from the workspace directory. - Setting `git.path` to `bash` allowed `bash --version` to return exit status `0`, causing VS Code to proceed to execute `bash rev-parse` inside the project folder. Placing an executable script named `rev-parse` in the root of the repository resulted in arbitrary code execution when the project directory was opened in VS Code. - **Chained Attack Demonstration**: Using Docker containers, the speaker simulated a victim cloning a malicious repository, entering the directory, and opening it in VS Code, sequentially triggering three separate reverse shells (via a recursive git clone flaw, RVM's `cd` hook, and the VS Code `git.path` override).

### Takeaways - **Toolchain Awareness and Patching**: Developers must understand the automated helper tools in their environment, recognize that tools like RVM often lack automatic update mechanisms, and keep their entire development toolchain patched. - **Containerization and Sandboxing**: Running IDEs like VS Code inside ephemeral Docker containers isolates work contexts and mitigates host persistence, though graphical forwarding over X11 sockets still presents breakout risks. - **Enterprise Defenses**: Organizations should implement multi-factor authentication for sensitive infrastructure access, monitor developer endpoints, understand the blast radius if a developer's access is abused, and consider red team exercises initiated directly from developer workstation environments.