PayPal has two major flaws in its attempt to be secure. I’ve been able to exploit both on my own account.

1a. Scenario: User types in password, and even if they log out, does not close the browser. Or their PayPal password is captured by spyware, key-stroke copying software, or simple air-cracking. There are several others.

1b. Assumption: user has the “2nd tier” security RSA token fob that generates a new 6 digit number every 60 seconds, and expects that to provide additional security.

1c. Flaw: even if you log out of PayPal in Firefox or IE, but leave the browser opened, I can simply go to the browser window/tab, go back to the page after the login, where the user is prompted for the 6 digit randomized code.

1d. Problem: browsers that let you go back to a page and “Resend Data” in doing so, will bypass the typed password prompt, and go to the “Enter Security Code” page, where any six digit random number can be entered.

1e. Analysis: Years of use show that a breakdown of what digits the “security code” is comprised of. The code almost never starts nor ends with a “0”. The distribution of digits that comprise the code is not equal across all six digits, allowing a random brute-force attack to be more effective by re-trying the more common combination of six digit codes.

1f. Attacks: assume user did not clear cache and close window of Firefox and IE browsers, and that the “Enter Security Code” page can be returned to whether or not the user has logged out. Another approach: capture password via spyware, or any key-stroke monitoring method.Enter typed password to get to the “Enter Security Code” page. 

1g.Modes of Attack:

Method 1: WinRunner, etc. can be used to automate the process of returning to the “Enter Security Code” page.

Method 2: I was able to write a Perl script using ‘wget’ to automate this process.

1h. Execution: Using a known typed password, log in to the second security stage. Then given any of the methods above or multiple others, generate a random 6 digit code every time, or using probability-based analysis, generate a single code to “retry” every 60 seconds when the previous code has changed.

1i. Results: Compromised account. Change password, take over account, etc. Various ways to pull funds to untraceable accounts, “send money” to a temporary, false account (easily created using an open proxy), etc.

The list of possible methods is much larger, and the execution of each attacks can be done in multiple ways, allowing brute force access to credit card usage, existing money in the account, and so on. The variations are too long to list.

Short version: “resend” to “Enter Security Code” page. Try 6 digit code. Repeat. I’ll work out the math on how long it would take, assuming one attempt every 60 seconds, although it can be more frequent.