Buzzkill: How Using Hacker Tools Can Get You Owned

Buzzkill: How Using Hacker Tools Can Get You Owned

Speakers: Justin Steven, Head of Research, Tanto Security

Conference: Kawaiicon

YouTube: https://www.youtube.com/watch?v=yvm8tohCpZ8

Overview

In "Buzzkill: How Using Hacker Tools Can Get You Owned" at Kawaiicon, Justin Steven, Head of Research at Tanto Security, delivered a compelling and technically rich presentation on a critical, often overlooked aspect of cybersecurity: the inherent vulnerabilities within the very tools used by offensive security professionals. The talk dissects the risks associated with employing hacker tools, demonstrating how seemingly innocuous features can be weaponized by adversaries to compromise the security researcher or pentester themselves. Steven's presentation serves as a stark reminder that the pursuit of security often involves interacting with untrusted environments, making the tools and processes used in these interactions potential vectors for attack.

This presentation is highly significant for several reasons. Firstly, it challenges the common assumption that security tools are inherently secure, highlighting that even well-intentioned software can harbor critical vulnerabilities. Secondly, it underscores the profound implications of such compromises, ranging from the loss of sensitive client data—such as credentials and pentest reports, which are essentially "how-to-hack" guides for an organization—to the broader compromise of a pentester's infrastructure. Lastly, Steven's work provides actionable insights for both tool developers and users, advocating for more robust security practices in tool development and a greater emphasis on operational security for practitioners. By revealing real-world exploits in Bbot, a popular open-source attack surface mapping tool, Steven not only showcases the problem but also illustrates sophisticated attack techniques that leverage archive handling, Git internals, and API key management.

Background

▶ Watch: Introduction: Hacker tools can have bugs too (0:00)

The concept that "pentesters can get pwned too" is not new, but it is a recurring theme that often gets overshadowed by the focus on target system vulnerabilities. Justin Steven frames his investigation into hacker tool vulnerabilities by drawing on a history of incidents and observations that highlight this critical blind spot. He recounts the performance art of Dr. Wes Mcgru in 2015, who demonstrated the insecurity of the popular Wi-Fi Pineapple pentesting device. Mcgru's "softicking" and defacing of these devices, often straight out of the box, vividly illustrated that pentester tools can have bugs and that the processes pentesters follow carry inherent risks. This was further compounded by the fact that pentest laptops often travel to sensitive locations and contain highly valuable client data, including credentials and detailed pentest reports—effectively blueprints for breaching their clients.

Steven further contextualizes the problem by recalling the 2016 exploitation of Cobalt Strike team servers, a widely used red team and (unfortunately) cybercrime tool, through a known vulnerability. More recently, in the summer of 2021, North Korean threat actors were observed targeting security researchers with malicious Visual Studio projects delivered via direct messages, showcasing a persistent and evolving threat landscape targeting the security community itself. Steven also shares his personal experience finding vulnerabilities in Metasploit, humorously noting the irony of "Metasploit" modules now existing to exploit Metasploit itself.

The core problem, as Steven identifies, lies in the nature of these tools: they are designed to interact with untrusted external environments. Bbot, the focus of his talk, is an open-source attack surface mapping tool popular among pentesters and bug bounty hunters. Its modular, event-driven architecture means that its 91 modules are constantly reaching out over the internet, touching untrustworthy hosts, pulling back data, parsing it, and attempting to make sense of it. This constant interaction with potentially malicious input, combined with a codebase often touched by a diverse set of authors, creates fertile ground for vulnerabilities. Steven's decision to audit Bbot's modules stemmed from this understanding, recognizing that these modules represent the "cold face" of interaction with the internet, making them prime candidates for bugs.

Key Findings

▶ Watch: Zip Slip: Arbitrary file write via archives (4:40)

Justin Steven's comprehensive audit of all 91 modules within Bbot unearthed a trio of critical vulnerability classes, each demonstrating how an attacker could compromise a Bbot user's machine or leak sensitive data. These findings highlight the sophisticated ways in which seemingly benign functionalities, such as archive extraction, Git repository handling, and API key management, can be subverted when interacting with malicious or crafted input.

1. Archive Extraction Vulnerabilities (Zip Slip / Arbitrary File Write): Steven discovered two distinct methods to achieve arbitrary file write, and ultimately Remote Code Execution (RCE), by exploiting Bbot's recursive archive extraction mechanism. The first involved classic zip slip via symbolic link (symlink) traversal, allowing an attacker to write malicious executables into Bbot's tools directory. The second, more nuanced, leveraged a "double extraction primitive" caused by a case-insensitive file download module combined with specific tar archive structures, again leading to arbitrary file write via symlinks. The RCE was achieved by overwriting legitimate binaries (e.g., the tar utility itself) with attacker-controlled payloads, which Bbot would then execute.

1. Git Repo Pillaging (RCE via Malicious .git Directories): This category revealed two powerful RCE vectors targeting Bbot's git dumper module, which is responsible for downloading and checking out exposed Git repositories.

• Git Index Manipulation: Attackers could craft a malicious .git/index file containing directory traversal sequences (../). When Bbot's git dumper performed a git checkout based on this corrupted index, it would write arbitrary files to arbitrary locations on the user's filesystem. This was then leveraged to overwrite binaries like truffle hog in Bbot's tools directory, leading to RCE.
• Git Config Manipulation: An attacker could embed a malicious command within the .git/config file, specifically using the core.fsmonitor directive. Steven demonstrated a bypass for Bbot's sanitization efforts by relocating the fsmonitor command within the [core] section of the config, causing Git to execute the attacker's payload during common operations like git status or git checkout.

1. API Key Leakage: Steven identified vulnerabilities that could lead to the leakage of user-configured API keys for services like GitLab and GitHub.

• GitLab Key Leakage: Bbot's GitLab module was found to send the user's configured GitLab API key to any server that responded with a X-GitLab-Instance header, regardless of its actual domain. An attacker could simply masquerade as a GitLab server to exfiltrate the key.
• GitHub Key Leakage: The Git clone module would opportunistically inject the user's GitHub API key into clone URLs that contained "github.com," even if the actual host was an attacker-controlled server. This meant an attacker could present a repository URL like github.com.attacker.example and receive the user's GitHub key when Bbot attempted to clone it.

All identified vulnerabilities have since been responsibly disclosed and patched by the Bbot maintainers, Blackland Security.

Technical Deep Dive

▶ Watch: Git Index File: RCE via malicious checkout (15:00)

Justin Steven's talk provides a deep dive into the technical intricacies of these vulnerabilities, demonstrating a sophisticated understanding of file system operations, archive formats, and Git internals.

Bbot's Architecture and Vulnerability Surface:

Bbot is built on a modular, event-driven architecture. Modules listen for specific events (e.g., new DNS hostnames, IP addresses, URLs, passwords, vulnerabilities) published to a message bus. Upon receiving an event, a module can perform its own analysis, interact with external services, and publish new events. With 91 modules and 32 event types, Bbot's extensive interaction surface with untrusted data makes it a prime candidate for input-related vulnerabilities. Steven specifically targeted modules that perform file operations or interact with remote Git repositories.

Archive Extraction (Zip Slip) – The Recursive Trap:

Bbot's unarchive module recursively extracts archives. This process involves extracting an archive to a sibling directory named after the archive, then iterating through its contents. If an extracted item is itself an archive, the process repeats.

• Exploit 1: Symlink-based RCE via Malicious tar Binary:

1. An attacker hosts a malicious tar file on a web server. This archive contains two entries:

• A symbolic link named, for example, evil-tar, pointing to a relative path like ../../.bbot/tools. The .bbot directory is Bbot's user home, and tools is where it stores third-party binaries.
• An embedded archive (e.g., payload.tar) containing a malicious executable renamed to tar.

1. When Bbot downloads and extracts the outer tar file:

• It first extracts evil-tar, creating the symlink in its temporary extraction directory.
• It then extracts payload.tar. Crucially, because the extraction is done relative to the symlink's target, the malicious tar executable from payload.tar is written into ~/.bbot/tools/tar, overwriting the legitimate tar binary.

1. The next time Bbot needs to extract any tar file, it will execute the attacker-controlled tar binary, granting the attacker a shell on the Bbot user's machine. This works because Bbot adds ~/.bbot/tools to its system PATH, ensuring its own binaries are found first.

• Exploit 2: Double Extraction Primitive (Case-Insensitive Overwrite):

1. The file download module in Bbot was found to be case-insensitive when naming downloaded files, and it included a timestamp (to the second) in the filename. If an attacker hosted two files with names differing only by case (e.g., archive.tar and Archive.tar) and Bbot downloaded them within the same second, the second download would overwrite the first.
2. This "double extraction" meant the unarchive module would process the same tar file twice. Steven crafted a tar file containing a symlink (e.g., my_symlink pointing to /tmp) and a file my_symlink/payload.
3. The challenge was in gnutar's behavior: it's "nervous" about extracting symlinks and typically creates a placeholder, then processes other files, creating symlinks last. If a symlink points to a file that's also in the archive, gnutar might get confused or delete the symlink.
4. The successful exploit involved placing the symlink within a read-only directory inside the tar file. This prevents gnutar from deleting the symlink during the second extraction attempt, allowing the subsequent file entry (my_symlink/payload) to be written through the now-active symlink. This arbitrary file write could then be chained to RCE. A curious nuance was that this specific exploit failed if Bbot ran as root (e.g., in Docker), as root ignores file permissions.

Git Repo Pillaging – Subverting Version Control:

Bbot's git dumper module recursively downloads exposed .git directories and performs a git checkout to reconstruct the working directory. Git, while designed to be distributed, has a complex threat model for untrusted repositories.

• Git Index Manipulation for Arbitrary File Write/RCE:

1. Git uses an index file (a cache) to speed up operations. While Git builds this index locally and tries to sanitize paths (e.g., rejecting ../ sequences), the git checkout command, designed for speed, trusts the index implicitly.
2. An attacker can host an exposed .git directory containing a specially crafted index file. This index file would list seemingly normal files, but their internal paths would be manipulated to include ../ sequences (e.g., temp/houdini.ext modified to ../../temp/houdini.ext).
3. When Bbot's git dumper clones this repository and performs a git checkout, the git checkout operation, trusting the malicious index, writes files to arbitrary locations on the Bbot user's filesystem.
4. This arbitrary file write is then used to overwrite an executable like truffle hog (a tool Bbot uses) in ~/.bbot/tools, achieving RCE when Bbot subsequently attempts to run truffle hog.

• Git Config Manipulation for RCE:

1. Git's configuration (.git/config) can include powerful directives. One such directive is core.fsmonitor, which allows specifying an external command to integrate with an FS monitor daemon for faster index updates. If this directive is set to an attacker's payload, Git will execute it.
2. Bbot's git dumper included sanitization logic (a regex) to prevent fsmonitor from being exploited. However, Steven found a bypass: moving the fsmonitor directive from its expected [fsmonitor] section to the [core] section. Git still parsed and honored it, but the sanitization regex failed to detect it.
3. Upon operations like git status, git add, git commit, or git checkout within the cloned repository, the malicious command specified in core.fsmonitor would be executed, granting the attacker RCE. Steven noted this was a known issue from his prior research into Git dumper projects, highlighting a "source code supply chain" problem where vulnerabilities can proliferate through code reuse or borrowing ideas.

API Key Leakage – Trusting the Untrustworthy:

• GitLab Key Leakage:

1. Bbot allows users to configure a GitLab API key for enhanced attack surface mapping.
2. The GitLab module, when interrogating repositories or user information, would send this key to gitlab.com. However, if the user had also configured on-premise GitLab instances, the module would send the key to any server that responded with an X-GitLab-Instance HTTP header, regardless of its domain.
3. An attacker could simply host a web server, respond with this header, and when Bbot scanned it, the user's GitLab API key would be leaked directly to the attacker.

• GitHub Key Leakage:

1. Similarly, Bbot could be configured with a GitHub API key.
2. The git clone module, when encountering a clone URL containing "github.com," would opportunistically inject the user's GitHub API key directly into the URL (e.g., https://[email protected]/repo.git).
3. An attacker could host a repository at a domain like github.com.attacker.example. When Bbot attempted to clone this repository, seeing "github.com" in the URL, it would inject the API key, leaking it to the attacker's server.

These detailed technical breakdowns underscore the criticality of input validation, secure handling of external resources, and careful management of sensitive credentials in security tools.

Demo / Proof of Concept

▶ Watch: API Key Leakage: Impersonating GitLab/GitHub (22:00)

While the talk did not feature a live, real-time demonstration, Justin Steven thoroughly described the proof-of-concept (PoC) steps and outcomes for each vulnerability class, effectively walking the audience through how an attacker could exploit these flaws. His explanations were precise, detailing the crafted inputs (e.g., malicious tar files, manipulated .git/index and .git/config files) and the observed effects (e.g., overwriting binaries, execution of arbitrary commands, exfiltration of API keys).

For instance, in the archive extraction section, Steven elaborated on how a specially constructed tar file containing a symlink and an embedded malicious binary would lead to the overwriting of Bbot's tar utility in its tools directory, concluding with "It's kind of like a free toy in your serial, but in this case it's free shells on the machine of the person who's using Bbot to scan you." Similarly, for the Git index manipulation, he stated, "So if someone runs git checkout against your evil.git directory with an evil index, you have an arbitrary file write primitive into bbot." He then explained how this could be chained to "overwrite the truffle hog binary which gets run after the git checkout happens. And so if someone scans us with bbot we can get a shell through the git index file."

The API key leakage was also articulated with clear attack scenarios: "when we get scanned by Bbot, it will send the user's GitLab key to us" by simply cosplaying as a GitLab server. For GitHub, "when bbot stumbles across this gitlab it'll try and clone the git repository and then the github key will be leaked to us." These detailed descriptions, complete with the specific files, paths, and module interactions, served as clear demonstrations of the exploitability of the discovered vulnerabilities. The talk effectively functions as a comprehensive technical walkthrough of how these PoCs were developed and executed.

Defensive Implications

▶ Watch: Disclosure process and security best practices (25:00)

The findings from "Buzzkill" carry profound defensive implications, not just for users of Bbot, but for anyone involved in offensive security or using security tools. Justin Steven emphasizes that the responsibility for security extends to the tools and practices of the security community itself.

1. Immediate Patching: The most direct implication is to patch Bbot immediately. All vulnerabilities discussed in the talk have been responsibly disclosed and fixed. Users should ensure their Bbot installations are updated to the latest version to mitigate these specific risks.
2. Segmentation and Isolation: This is a paramount takeaway. Pentesters and security researchers should never run untrusted or even partially trusted tools directly on their primary host machines. Instead, critical security operations should be performed within isolated environments such as:

• Virtual Machines (VMs): Dedicated VMs for different projects or levels of trust can contain potential compromises.
• Containers (e.g., Docker): Containers offer lightweight isolation, although Steven notes the nuance that running tools as root within a Docker container can sometimes bypass certain exploit mitigations (as seen with the tar symlink trick).
• This practice extends to reviewing and testing exploit code from sources like GitHub or Exploit-DB; always run it in a sandboxed environment first.

1. Code Review and Scrutiny: Do not blindly trust security tools, even open-source ones. Steven advocates for reviewing the code of tools before running them, especially those that interact with external, untrusted input or perform sensitive file operations. Understanding how a tool processes data can reveal potential vulnerabilities.
2. Protecting Sensitive Client Data: Pentest reports, client credentials, and other sensitive data are high-value targets. Steven urges professionals to never let the confidentiality of client data depend solely on the correctness of the code in their security tools. Implement robust data handling policies, encryption, and access controls that assume a tool could be compromised.
3. Understanding Threat Models: The talk highlights the complexity of threat models for tools like Git. Users should educate themselves on the security assumptions and limitations of the tools they use. What Git considers a feature (e.g., configurable fsmonitor) might be exploitable in the context of a tool that implicitly trusts remote .git directories.
4. Responsible Vulnerability Disclosure: Steven praises Blackland Security's mature and graceful response to his vulnerability reports. This serves as a model for how security companies should handle disclosures related to their own tools. If security professionals find bugs in hacker tools, they should engage in high-quality, responsible vulnerability reporting to enhance collective security.
5. Awareness of "Source Code Supply Chain" Risks: The re-emergence of a Git config RCE bypass due to borrowed, inadequately patched code demonstrates that vulnerabilities can propagate through the reuse of code or even just "borrowing vibes and ideas" from other projects. This extends the concept of supply chain security beyond traditional libraries and dependencies to the conceptual and practical reuse of code snippets and logic.
6. Careful API Key Management: Users should be acutely aware of how their tools handle API keys. Configure keys only for the necessary modules and understand the specific conditions under which they are used and transmitted. The GitLab and GitHub key leakage examples show that even "opportunistic" key usage can be dangerous if the tool doesn't rigorously validate the remote host.

By integrating these defensive strategies, security practitioners can significantly reduce their attack surface and protect themselves and their clients from being "owned" by the very tools designed to secure them.

Key Takeaways

• Hacker tools are not immune to vulnerabilities: The security tools used by pentesters and bug bounty hunters, including popular open-source projects like Bbot, can contain critical flaws that can be exploited by adversaries.
• Interaction with untrusted input is a major risk factor: Tools designed to map attack surfaces or interact with external systems (like web servers hosting archives or Git repositories) are particularly susceptible to vulnerabilities related to input parsing, file handling, and network communication.
• Archive extraction and Git internals are complex and dangerous: Features like recursive archive extraction (leading to zip slip via symlink traversal) and the handling of Git repository internals (especially the .git/index and .git/config files) are prone to arbitrary file write and Remote Code Execution (RCE) vulnerabilities.
• API key management requires extreme caution: Tools that "opportunistically" use or transmit API keys, even to seemingly legitimate domains, can inadvertently leak sensitive credentials to attacker-controlled infrastructure if not implemented with rigorous host validation.
• Operational security for pentesters is paramount: Professionals must adopt strict isolation and segmentation practices (e.g., running tools in VMs or containers, reviewing code) to protect their own systems and, crucially, their clients' sensitive data from compromise.
• Responsible disclosure strengthens the ecosystem: Finding and reporting vulnerabilities in security tools, coupled with a mature and collaborative disclosure process, is vital for improving the overall security posture of the cybersecurity community.

About the Speaker(s)

Justin Steven is the Director of Research and the self-appointed social media mogul at Tanto Security, a research-driven offensive security services firm based in Australia. With a strong background in software security, he is passionate about finding bugs, bones (vulnerabilities), and exploitation. Steven is particularly known for his work in "making computers weird" and finding vulnerabilities in hacker tools, having previously discovered and reported bugs in widely used platforms like Metasploit. His research focuses on understanding and exploiting the security of the tools and processes employed by security professionals themselves, an area he has explored in depth through his extensive work on Git internals and tool-specific vulnerabilities.