Poisoning Pidgins in the Park

Poisoning Pidgins in the Park

Speakers: Johnny Xmas

Conference: DefCamp

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

Overview

In his DefCamp talk, "Poisoning Pidgins in the Park," security researcher Johnny Xmas unravels a compelling real-world case study of a sophisticated social engineering and software supply chain attack. The presentation details an attacker's elaborate attempts to inject malicious code into the widely used open-source chat client, Pidgin. Johnny Xmas, despite self-professed lack of expertise in reverse engineering, meticulously recounts how he leveraged a "don't know, so I'll try" mentality to uncover a covert operation designed to compromise Pidgin users through a seemingly innocuous screen-sharing plugin.

This talk serves as a critical warning about the vulnerabilities inherent in open-source projects, particularly those maintained by small teams or individuals. It highlights the insidious nature of social engineering, where trust is weaponized to bypass technical safeguards. Beyond the technical specifics of the malware, the presentation emphasizes the importance of community vigilance, the necessity of robust code review processes for third-party contributions, and the power of an inquisitive, persistent mindset in cybersecurity investigations.

The narrative not only exposes a cunning attacker's tactics but also champions the spirit of collaborative problem-solving within the security community. It's a testament to how fundamental security principles and a willingness to explore unfamiliar territory can effectively counter even well-orchestrated threats, preventing widespread compromise for millions of users.

Background

▶ Watch: Embracing the 'I don't know, so let me try' mindset (2:00)

The talk centers on Pidgin, an enduring open-source, multi-protocol instant messenger client. Originally known as Gaim G, Pidgin has been a staple in the open-source community for decades, often shipping with various Linux distributions. It supports a vast array of chat networks, running on multiple operating systems, and is notable for its extensible architecture via third-party plugins. A crucial detail for this story is that Pidgin is primarily maintained by a single dedicated individual, referred to as Grim (or Gary), a common scenario in many vital open-source projects. Pidgin's core privacy and security features, particularly its resistance to man-in-the-middle attacks, rely heavily on a component called libotr (Off-the-Record Messaging library).

Johnny Xmas frames the incident within two critical cybersecurity concepts: a software supply chain attack and social engineering. A software supply chain attack, as defined in the talk, involves an attacker compromising the dependencies of a piece of software, either within the software itself or its compiler. This type of attack fundamentally abuses the trust placed in those dependencies and the final product. Social engineering, on the other hand, is described as the surreptitious control of a social situation, where affected parties are unaware of the manipulation. It abuses trust, often requiring the attacker to build rapport with strangers, with the ultimate goal of manipulating individuals with power to achieve a desired outcome.

The speaker introduces himself not as an expert in every field, but as someone who embraces the "I don't know, so I'll try" philosophy. This personal context is crucial, as it explains how he, a self-described non-reverse engineer, became instrumental in dissecting the malicious code. This approach stands in contrast to a growing mentality in the industry of "I don't know, therefore I can't," which Johnny argues is detrimental, especially in an industry desperate for problem-solvers. This talk, therefore, also serves as an inspiration for those grappling with imposter syndrome or new to the field, demonstrating that curiosity and persistence can yield significant security victories.

Key Findings

▶ Watch: Defining software supply chain attacks and social engineering (8:00)

The central discovery of this talk was a sophisticated, multi-pronged attack orchestrated by an individual going by the Discord handle "win for the win" (with a parent handle "take the profit"). This attacker attempted to compromise Pidgin users through a seemingly legitimate "screen-sharing" plugin. The core malicious findings were:

1. Malware Disguise: The attacker submitted a plugin named "Pigeon OTR Screen Share" to the official Pidgin plugin list. While the plugin outwardly performed screen sharing, it secretly harbored deeper malicious functionalities.
2. Hidden Malicious Capabilities: The plugin contained a keylogger to capture user keystrokes, functionality to upload screenshots from the victim's machine to specific external IP addresses, and a remote desktop backdoor. This backdoor was particularly insidious, leveraging an undocumented feature in Windows 10 (and earlier versions) that allowed access to hidden multiple desktops, enabling graphical remote interaction without the user's knowledge.
3. Compromised Dependency: A critical aspect of the attack was the attacker's provision of a modified libotr library. libotr is fundamental to Pidgin's privacy and security, ensuring encrypted, man-in-the-middle-resistant communications. The attacker claimed these modifications were necessary to fix "compatibility issues" between Pidgin's libotr and his plugin when both were enabled, a highly suspicious claim given libotr's core function.
4. Social Engineering Masterclass: The attacker systematically abused trust through various tactics:

• Ego Inflation: Lavishing praise on Pidgin and its maintainer, Grim, calling it an "amazing messenger" and "beautiful chat application."
• Feigned Altruism: Presenting the plugin as a valuable community contribution, claiming "my friends and I have a strong use for the plugin" and that "the whole community will find it very useful."
• Persistent Donation Offers: Repeatedly offering substantial cryptocurrency donations (up to $2,000 USD per month), even offering to set up accounting software like Zen Ledger for Grim, despite clear refusals, to foster a sense of obligation or gratitude.
• Legitimization Attempts: Creating a fake domain, jabberplugins.net, populated with other legitimate Pidgin plugins to appear credible, and aggressively pushing for his plugin to be listed as "security and privacy" on the official site, and ideally marked as "trusted."

1. Evidence Tampering: Upon being confronted with evidence of malicious activity, the attacker immediately took his server offline, causing jabberplugins.net to disappear, and emptied his GitHub repository, strongly indicating guilt and an attempt to erase his tracks.
2. "Catching Bad Guys" Narrative: When directly confronted, the attacker pivoted to claiming he was an "ethical hacker" using the malware to "catch bad guys" involved in cryptocurrency theft, even providing easily verifiable public arrest videos as "proof." This was a transparent attempt to justify his actions and deflect blame.

These findings collectively revealed a well-planned operation targeting both the technical infrastructure and the human element of the Pidgin project.

Technical Deep Dive

▶ Watch: Attacker's persistent crypto donation offers and flattery (16:15)

The core of the technical attack revolved around the "Pigeon OTR Screen Share" plugin, which, despite its benign appearance, was engineered to deploy a sophisticated set of malicious functionalities. The attacker demonstrated a clear understanding of system internals and social engineering to achieve their goals.

The plugin itself was provided as a binary, with the attacker later reluctantly providing source code consisting of an anomalous 5600 lines of C code within a single file – a significant red flag for any experienced developer, indicating poor coding practices at best, or obfuscation at worst.

Upon analysis of the source code (after it was eventually provided), Johnny Xmas employed basic yet effective reverse engineering techniques, starting with a simple grep (or "strings" equivalent for source code) to search for suspicious patterns. His focus was on indicators of network communication and data exfiltration, specifically:

• IP addresses and domain names: The code contained direct calls out to jabberplugins.net, a domain registered and controlled by the attacker. This served as a Command and Control (C2) server for the malware.
• Socket connections: Evidence of establishing network sockets indicated the plugin's capability to communicate with external hosts.

The malicious functionalities embedded within the plugin included:

1. Keylogging: The code was designed to capture user keystrokes, providing the attacker with sensitive information such as passwords, personal communications, and other data entered on the compromised machine.
2. Screenshot Uploading: The plugin could periodically take screenshots of the victim's desktop and upload them to specific, attacker-controlled IP addresses. This allowed visual surveillance of the user's activities.
3. Remote Desktop Backdoor (Windows Specific): This was perhaps the most ingenious technical aspect. The malware leveraged a feature in Windows 10 (and earlier versions) that allowed for multiple hidden desktops. While these desktops were not exposed to end-users for direct interaction, the attacker's code found a way to "tap" into this functionality. This meant the attacker could remotely connect to a separate, invisible desktop session on the victim's Windows machine, gaining full graphical control (keyboard and mouse) without the user being aware of any remote activity on their visible desktop. This offered a persistent, stealthy channel for deep system compromise.

A critical technical detail was the attacker's provision of a modified libotr. libotr is the Off-the-Record Messaging library, a cornerstone of Pidgin's security model. It provides strong encryption and deniable authentication, preventing man-in-the-middle attacks and ensuring message privacy. The attacker's claim of "compatibility issues" requiring a modified libotr was highly suspect. Tampering with such a fundamental security library would allow the attacker to potentially bypass Pidgin's core encryption, intercept communications, or introduce further vulnerabilities, far beyond the capabilities of a simple screen-sharing plugin. This modification was a significant attempt to compromise the integrity of Pidgin's security architecture itself.

The attacker's infrastructure included jabberplugins.net, designed to mimic a legitimate plugin repository. This site hosted not only the malicious screen-sharing plugin but also several other genuine Pidgin plugins sourced from GitHub, presumably to enhance its credibility and mislead users and maintainers into believing it was a trusted source.

The swift disappearance of jabberplugins.net and the emptying of the attacker's GitHub repository immediately after the keylogging functionality was mentioned served as irrefutable technical evidence of the attacker's guilt and an attempt to destroy the C2 infrastructure and source code.

Demo / Proof of Concept

▶ Watch: Johnny Xmas joins investigation, starts with basic analysis (24:15)

While Johnny Xmas did not perform a live demonstration of the malware itself during his talk, he provided the audience with the means to access the evidence directly. Two QR codes were presented: one linking to the extensive Discord chat logs detailing the social engineering attempts, and the second leading directly to the malware itself. This allowed attendees to independently verify the findings and conduct their own analysis of the malicious code.

Johnny's "demo" was primarily a detailed walkthrough of his investigative process, effectively serving as a proof of concept for how such an attack could be uncovered without advanced tools or expertise. He explained how he, a non-reverse engineer, approached the problem:

• Source Code Review: Upon receiving the attacker's source code, he treated it like a Capture The Flag (CTF) challenge.
• String Analysis: His first step was to look for plain text strings within the code, similar to running strings on a binary. He used regular expressions (grep) to specifically search for:
• IP addresses: To identify potential C2 servers or data exfiltration points.
• Socket connections: To detect any code attempting to establish network communication.
• Identification of Malicious Components: This methodical search quickly revealed the jabberplugins.net domain within the code, confirming the attacker's infrastructure. More importantly, it led to the discovery of the code implementing the keylogger, the screenshot uploading mechanism, and the unique method for exploiting hidden multiple desktops in Windows 10 for remote access.

By making the malware and chat logs publicly available, Johnny Xmas transformed his talk into an interactive learning experience, empowering attendees to dive into the specifics of the case and understand the technical details firsthand. This approach underscored his message that even without specialized tools, fundamental investigative techniques can yield significant results.

Defensive Implications

▶ Watch: Q&A: Advice for developers on collaboration and trust (37:30)

This case provides crucial lessons for both open-source project maintainers and general users regarding software supply chain security and social engineering.

For Open-Source Project Maintainers (like Grim):

1. Extreme Skepticism for Third-Party Code: Maintainers must adopt a highly skeptical stance towards all third-party contributions, especially those offering binaries or modifications to core, security-critical dependencies like libotr. The attacker's claim of "compatibility issues" for modifying libotr should have been an immediate red flag.
2. Mandatory Source Code Review: Never accept binary-only plugins. Always demand and rigorously review the source code. Even for "hobby" projects, a cursory review is insufficient; look for suspicious patterns like excessively large single files or unusual network calls.
3. Robust Plugin Policies: Implement clear, stringent policies for plugin submission. These should include:

• Requirement for publicly available source code.
• Independent security review by multiple qualified individuals.
• A clear distinction between "community-provided" and "trusted" plugins, with a much higher bar for the latter. The policy should not rely on personal trust alone, as Grim initially did.

1. Guard Against Social Engineering Tactics: Be acutely aware of common social engineering ploys:

• Flattery and Ego Inflation: Excessive praise for the project or maintainer can be a tactic to lower defenses.
• Unsolicited Donations: Persistent offers of large sums of money, especially in hard-to-trace cryptocurrencies, should raise suspicion, as they can create a sense of obligation or compromise.
• Pressure and Urgency: The attacker's constant pushing for listing and "security and privacy" categorization was a tactic to rush the process.
• Feigned Innocence/Victimhood: When caught, attackers often deny culpability or claim to be victims themselves (e.g., "my server was hacked").

1. Cultivate a Trusted Network: As Johnny Xmas emphasized, "it's dangerous to go alone." Maintainers should build a network of trusted security professionals and developers they can consult for code review, threat analysis, or general advice when something "feels strange." This external validation is critical, especially for single maintainers who may lack specific security expertise.
2. Avoid Public Confrontation: Johnny wished Grim hadn't revealed the specific discovery of the keylogger to the attacker. This allowed the attacker to immediately delete evidence. In such situations, it's often better to gather all evidence silently before confronting the perpetrator, if confrontation is even necessary.

For Users of Open-Source Software:

1. Exercise Caution with Plugins: Be extremely wary of installing third-party plugins, even if they appear on official project websites. Understand that "community-provided" often means "use at your own risk."
2. Verify Source and Reputation: Before installing any software or plugin, verify its source and reputation. Check for open-source code, active development, and community reviews.
3. Monitor Network Activity: Basic network monitoring tools can help identify unusual outbound connections from applications, which could indicate malware activity (e.g., screenshots being uploaded to unknown IPs).
4. Report Suspicious Behavior: If something seems off—an application behaving strangely, unexpected network connections, or even a developer's unusual social interactions—report it to the project maintainers or the broader security community. The timely report of a suspicious user was crucial in this case.

This incident underscores that security is a continuous process requiring vigilance, technical scrutiny, and a healthy dose of skepticism, especially in the collaborative, trust-based environment of open-source development.

Key Takeaways

• Social engineering is a primary vector for supply chain attacks: The attacker's elaborate psychological manipulation, including flattery, persistent donation offers, and feigned innocence, was crucial in attempting to bypass technical safeguards and gain the maintainer's trust.
• Open-source projects, especially those with single maintainers, are highly vulnerable: The reliance on one person (Grim) for both development and security vetting created a single point of failure that the attacker actively exploited.
• Malware can be ingeniously disguised and leverage obscure system features: The "screen-sharing" plugin concealed a keylogger, screenshot uploader, and a remote desktop backdoor exploiting hidden Windows desktop functionality, demonstrating sophisticated design.
• The "I don't know, so I'll try" mindset is critical for threat discovery: Johnny Xmas's willingness to investigate despite not being a reverse engineering expert, using basic tools like string searches, proved effective in uncovering the sophisticated malware.
• Robust code review and a trusted support network are essential for maintainers: Grim's decision to consult Johnny and the subsequent policy changes highlight the necessity of external security expertise and a community of trusted peers for vetting third-party contributions.
• User vigilance and clear reporting channels are vital: The attack was ultimately stopped because a suspicious user reported the plugin's malicious activity, underscoring the importance of community involvement in security.

About the Speaker(s)

Johnny Xmas is a seasoned professional in the information security industry, known for his unconventional career path and his practical, "I don't know, so I'll try" approach to problem-solving. His journey into cybersecurity began unexpectedly; he initially pursued a path in pharmacy technology and later attended university on a music scholarship for playing the flute, which eventually led him to work in a computer lab and sparked his interest in technology.

Throughout his career, Johnny has held diverse roles, including a unique position as a "sneakerbot blade runner," combating internet automation long before the widespread discussion of AI. He is a prominent figure in the hacking community, notably running BBSE, one of North America's most well-attended hacking meetup organizations, which has expanded internationally to places like Galway, Ireland. Beyond his professional life, Johnny is an avid motorcyclist and a passionate photographer of urban blight, focusing on abandoned buildings and infrastructure. His talk at DefCamp exemplifies his philosophy of tackling challenges head-on, even when lacking specific expertise, and sharing those experiences to inspire others in the security field.