How We Exploited Email-Based Invoice Features to Access GitHub and Slack

Invoice Import Vulnerability

• Weakness found in email-based invoice import feature.
• Exploit enabled access to internal resources (GitHub, Slack).
• Risk: attacker pivot from invoice processing → core systems compromise.
• Root cause: insufficient input validation & trust boundaries.
• Defense: enforce strict validation, sandboxing, and access controls.

Functionality Overview:

The platform (redacted.com), offers a diverse range of accounting services. A particular feature that stood out was the ability to add expenses through email. To utilize this function, users are required to forward their email receipts to [email protected]. However, before doing so, one needs to set a source email address with redacted.com to ensure that the emails are recognized and accepted.

For illustration, if I receive an invoice at [email protected] and need to upload it to the accounting website, I first need to set [email protected] on redacted.com as the source email to store the received mails from. Subsequently, I forward the invoice from [email protected] to [email protected]. The platform then processes this email, converting its HTML content into a PDF, which gets stored in the user's portal.

The Exploit:

To leverage this vulnerability and infiltrate the company's workspace, our approach was to register on GitHub as example using the [email protected] email. Here's a step-by-step breakdown of our exploitation process:

• GitHub Registration: Signing up on GitHub mandates the verification of the provided email address. They send a confirmation code to this address to complete the registration.

• Capturing the Confirmation Email: Our objective was to intercept the confirmation email sent to [email protected]. It's essential to note that GitHub dispatches these confirmation emails from the address [email protected].

• Setting Up Email Source: To seize emails from [email protected], we modified the source email setting in our portal to [email protected]. This meant any correspondence from [email protected] directed to [email protected] would be rerouted and stored in our account on the portal.

• Intercepting the Confirmation Code: Having set everything in motion, we proceeded to sign up on GitHub using [email protected]. As anticipated, GitHub's confirmation email (originating from [email protected]) was dispatched to [email protected].

• Accessing the Confirmation Code: Leveraging the platform's feature, the intercepted email was automatically converted into a PDF document. The platform then scanned its user base to determine the rightful owner of the email based on the source email setting. Since we had designated [email protected] as our source, the PDF containing the confirmation code was deposited into our portal account.

• Finalizing GitHub Registration: Armed with the confirmation code from the PDF, we were able to finalize our GitHub registration. This gave us unfettered access to the company's GitHub workspace, exploiting the vulnerability to its fullest.

Limitations and Bypasses

Dynamic Email Addresses

While exploiting GitHub was relatively straightforward given their consistent use of the static [email protected] address, other platforms presented challenges. For instance, Slack employs dynamic emails in the form of no-reply-{{Random-Token}}@slack.com, making it nearly impossible to predict the exact source email for our portal.

However, where there's a will, there's a way. We found an ingenious workaround by leveraging the trust relationships between third-party authentication providers and platforms:

• Setting up Apple as a Bridge: Given that many platforms support OAuth-based registration (signing up via Apple,Google, Facebook, etc.), we chose Apple as our bridge.

• Configuring the Accounting Portal: In the accounting portal, we designated [email protected] as our source email.

• Apple Account Creation with Target Email: Next, we initiated the process to create an Apple account using [email protected].

• Intercepting Apple's Confirmation Email: As per their procedure, Apple sends a confirmation email to verify ownership. Given our configuration, this email was captured in our portal, allowing us to retrieve the confirmation code.

• Finalizing the Apple Account: With the code in hand, we completed the Apple account setup. Now, [email protected] was not only an active email on the target domain but also linked to a new Apple account.

• Utilizing OAuth for Slack Registration: Heading over to Slack, we opted to register using the "Sign up with Apple" option, which employs OAuth authentication. By doing so, Slack queries Apple to validate the email address without requiring a direct email confirmation.

• Exploiting Trust Relationships: Since our Apple account (associated with [email protected]) was authenticated, Slack trusted this authentication and allowed us to proceed, giving us access to the company’s workspace without the traditional confirmation step.

In essence, we managed to circumvent the dynamic email hurdle by harnessing the implicit trust platforms place in third-party authentication providers, exemplifying the potential risks inherent in such trust relationships.

Limited Source Email:

Certain accounting platforms require the use of a single source email, specifically the one utilized during sign up. For instance, if you register with [email protected], only the emails forwarded from [email protected] to [email protected] will appear in your account. This implies you'd need to register with [email protected] (in the context of GitHub) to successfully exploit the system. The trick lies in the fact that some applications mandate email confirmation, while others do not. We successfully circumvented the email confirmation in certain targets because some platforms underestimate the security implications of such a requirement.

Remediation

The most effective method to rectify this problem is to offer users a completely distinct email domain. For instance, if your employees are using redacted.com, establish a new domain for user emails like redacted.co, or create a new subdomain, such as mail.redacted.com. Consequently, the receipts email would change to [email protected] or [email protected]. This strategy effectively compartmentalizes different email functions, significantly reducing the risk of such vulnerabilities.

Identifying Potential Targets:

We initiated our search by looking for recurring patterns in email addresses and keywords that might indicate similar functionalities, such as "receipts@" and "expenses@" To aid in our search, we employed search dorks to comb through networks for comparable features, using search terms like "“receipt@" and "Forward" We then applied these discovered patterns to identify new potential targets. One notable example was within lifestyle and time management applications, where users are often required to forward specific emails to addresses like [email protected] We frequently found mentions of these functionalities in community forums, support sections, or official documentation, either as user queries or as described features.

Statistical Overview:

Throughout our exhaustive research, we scrutinized over 75 platforms that employed similar email-based functionalities. The security landscape of these platforms is as follows:

• 25 platforms were found to be vulnerable, exhibiting susceptibility to the security flaws we've identified.

• 22 platforms had enacted basic security measures like Two-Factor Authentication (2FA), but nonetheless retained minor vulnerabilities that could be exploited through more advanced techniques.

• 33 platforms showcased robust security mechanisms, effectively mitigating the vulnerabilities we investigated. Some of these platforms used AI algorithms to extract transactional or invoice data from emails without actually storing the email itself, effectively preventing us from gaining access to any confirmation codes or links. Others used entirely different email addresses for their functionalities, such as [email protected] or [email protected], further compartmentalizing their email roles and reducing risk.