The Fellowship of the Phish: PayPal's Perilous Request Feature

In cybersecurity, we often find ourselves fixated on the latest sophisticated malware or zero-day exploits. However, sometimes the most intriguing threats come from unexpected places. Recently, I found myself on the receiving end of a series of social engineering emails that highlighted an often-overlooked aspect of security: the abuse of legitimate features.

While many security experts would dive deep into the psychological manipulation tactics employed in such attacks – analyzing the language used, the urgency created, or the emotional triggers exploited – I want to discuss a different aspect: How attackers are weaponizing the very features designed to make our lives more convenient.

For the emails I'm about to describe, I won’t focus on the scam itself, but rather the mechanism it appears the attacker used.  Sometimes the most dangerous vulnerabilities aren't in our software, but in our assumptions about how it should be used.

The Anatomy of the Attack

Let's break down this attack into its constituent parts to truly appreciate its ingenuity:

Stage 1: The Money Request

The opening salvo in this two-pronged attack was deceptively simple: a PayPal money request for $299. This is seen in the screenshot below.

At first glance, this might seem like a rather blunt instrument. After all, who would simply pay such a request without question? 

However, this initial step serves multiple purposes:

• It establishes a sense of urgency and concern in the target since they aren’t sure why they would get this.
• It provides a seemingly legitimate reason for PayPal to be contacting the user.
• It sets the stage for the more sophisticated second phase of the attack.

From the attacker's perspective, if this first step is successful, they've scored a quick win – $299 in their pocket. But the true genius of this attack lies in its ability to proceed even if this initial gambit fails.

Stage 2: The Cancellation Twist

The second email demonstrates a level of sophistication that sets it apart from run-of-the-mill phishing attempts. This message appeared to be a cancellation of the previous request, with the subject line clearly stating "This money request has been canceled."  The email is shown below.

Now it gets interesting:

1. The body of the message claimed that a $650 Bitcoin purchase was successful.
2. It stated that the original request was not canceled, contradicting the subject line.
3. A phone number was provided, ostensibly for disputing the charge.

In a quick look, it does appear that this message was delivered via the Paypal system.  While I did not test the Paypal system to see, the headers and such all seemed to be valid for Paypal.  This clever use of PayPal's own messaging system accomplishes several things:

• It creates confusion by presenting contradictory information.
• It escalates the sense of urgency by increasing the monetary amount at stake.
• It provides a seemingly official channel (the phone number) for resolving the issue.
• Most importantly, it apparently abuses a legitimate PayPal feature to lend credibility to the scam.
  

Not a Bug, but a Feature

Here's where this attack differs from many we see in the cybersecurity space: it's not exploiting a vulnerability in PayPal's code. There's no buffer overflow, no SQL injection, no cross-site scripting at play. The system is functioning exactly as it was designed to.

The money request feature is working correctly:

• It allows users to request money from others.
• It sends notifications about these requests.

The cancellation feature is also operating as intended:

• It allows the requester to cancel a money request.
• It notifies the recipient of the cancellation.
• It permits the requester to include a message with the cancellation.

The attacker has simply found a way to use these features in an unexpected and malicious way. This presents a unique challenge from a security perspective. How do we defend against the misuse of properly functioning features?

Rethinking Design and Testing

Software developers, security professionals, and QA testers need to consider this type of abuse as they do their job. They need to think beyond the happy path when designing and testing features.

Expanding Our Security Horizons

Traditionally, security testing often focuses on:

• Ensuring proper authentication and authorization
• Protecting against known attack vectors
• Safeguarding sensitive data
• Maintaining the integrity of the system

While these are all crucial aspects of security, this social engineering attack demonstrates the need to also consider:

• How features could be combined in unexpected ways
• The potential for abuse in user-generated content areas without using XSS
• How the system's own messaging could be co-opted by attackers

The Human Element in Security Testing

This is where the human element in security testing proves invaluable. Penetration testers, with their adversarial mindset, are uniquely positioned to uncover these types of creative misuses.

Why human testers are crucial:

• Creativity: They can think outside the box in ways that automated tools cannot.
• Context Understanding: They grasp the broader implications of feature interactions.
• Adaptability: They can adjust their approach based on discovered information.
• Behavioral Analysis: They can mimic the thought processes of potential attackers.

While automated security scanning tools are excellent for identifying known vulnerabilities and coding errors, they fall short when it comes to detecting logical abuses of features. They can't easily determine if a feature that's working correctly could be used maliciously.

QA and UAT: The Front Lines of Defense

Quality Assurance (QA) and User Acceptance Testing (UAT) teams are often the unsung heroes in preventing these types of attacks. By adopting an "attacker's mindset," these teams can serve as a crucial line of defense.

How QA and UAT can help:

• Scenario Testing: Develop test cases that explore unconventional use of features.
• Combinatorial Testing: Test how different features interact with each other.
• Negative Testing: Don't just test that features work, test how they fail.
• User Journey Mapping: Consider the entire user experience, including potential misuse.

Integrating security considerations into QA and UAT processes can help catch these issues before they make it to production. This might involve:

• Including security professionals in the QA process
• Providing security training to QA and UAT testers
• Developing security-focused test cases and scenarios
• Encouraging a "think like an attacker" mindset across the team

The Dark Side of Design

The method used in this PayPal attack bears a striking resemblance to dark patterns in user interface design. Dark patterns are design choices that benefit the service provider at the expense of the user, often by manipulating or coercing users into taking actions they wouldn't otherwise take.

Examples of dark patterns include:

• Trick questions in forms
• Hidden costs revealed only at checkout
• Forced continuity in subscriptions
• Disguised ads that look like content

In the case of our PayPal scam, the attacker is essentially creating their own dark pattern. They're exploiting a feature designed for convenience and turning it into a tool for confusion and manipulation.

From Dark Patterns to Dark Uses

Just as we scrutinize UI/UX designs for dark patterns that might manipulate users, we must also examine our features for potential "dark uses" – ways in which attackers could twist their functionality for malicious purposes.

Considerations for identifying potential dark uses:

1. User-Generated Content: Are there any feature that allows users to input content that other users will see is a potential vector for abuse?
2. Notification Systems: How could system notifications be manipulated to mislead users?
3. Cancellation or Reversal Features: Could these be used to create confusion or a false sense of security?
4. Combining Features: How might different features interact in ways that could be exploited?

By considering these aspects during the design phase, we can potentially head off these issues before they become real-world problems.

Conclusion

The PayPal money request scam serves as a stark reminder that in the realm of cybersecurity, we must constantly challenge our assumptions. Security isn't just about building impenetrable walls or squashing bugs – it's about understanding the entire ecosystem of our applications and how they might be misused.  This is why we like to work with our clients during a penetration test: to help them see how we evaluate applications and APIs.