Page 1 of 1
Brian Krebs is reporting on a clever PayPal phishing scam that uses legitimate PayPal messaging.
Basically, the scammers use the PayPal invoicing system to send the email. The email lists a phone number to dispute the charge, which is not PayPal and quickly turns into a request to download and install a remote-access tool.
One of the effects of GDPR—the new EU General Data Protection Regulation—is that we’re all going to be learning a lot more about who collects our data and what they do with it. Consider PayPal, that just released a list of over 600 companies they share customer data with. Here’s a good visualization of that data.
Is 600 companies unusual? Is it more than average? Less? We’ll soon know.
Troy Hunt has identified a new spam vector. PayPal allows someone to send someone else a $0 invoice. The spam is in the notes field. But it’s a legitimate e-mail from PayPal, so it evades many of the traditional spam filters.
Presumably it doesn’t cost anything to send a $0 invoice via PayPal. Hopefully, the company will close this loophole soon.
Brian Krebs has the story. Bottom line: PayPal has no excuse for this kind of stuff. I hope the public shaming incents them to offer better authentication for their customers.
This is a pretty impressive social engineering story: an attacker compromised someone’s GoDaddy domain registration in order to change his e-mail address and steal his Twitter handle. It’s a complicated attack.
My claim was refused because I am not the “current registrant.” GoDaddy asked the attacker if it was ok to change account information, while they didn’t bother asking me if it was ok when the attacker did it.
[…]
It’s hard to decide what’s more shocking, the fact that PayPal gave the attacker the last four digits of my credit card number over the phone, or that GoDaddy accepted it as verification.
The misuse of credit card numbers as authentication is also how Matt Honan got hacked.
It’s the Browser Exploit Against SSL/TLS Tool, or BEAST:
The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target’s browser into the encrypted request stream to determine the shared key. The code can be injected into the user’s browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.
Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.
The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.
While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley’s David Wagner pointed out in a 1999 analysis of SSL 3.0 that “SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative.” And TLS’s vulnerability to man-in-the middle attacks was made public in 2009. The IETF’s TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.
Another article.
EDITED TO ADD: Good analysis.
This hack was conducted as a research project. It’s unlikely it’s being done in the wild:
In one attack, Wang and colleagues used a plug-in for the Firefox web browser to examine data being sent and received by the online retailer Buy.com. When users make a purchase, Buy.com directs them to PayPal. Once they have paid, PayPal sends Buy.com a confirmation message tagged with a code that identifies the transaction.
PayPal handles its side of the process securely, says Wang, but Buy.com was relatively easy to fool. First the team purchased an item and noted the confirmation code used by PayPal. Then they selected a second item on Buy.com but did not pay up. Instead, they used the code from the first transaction to fake a confirmation message, which Buy.com accepted as proof of payment.
Paper here.
Here’s a clever attack, exploiting relative delays in eBay, PayPal, and UPS shipping:
The buyer reported the item as “destroyed” and demanded and got a refund from Paypal. When the buyer shipped it back to Chad and he opened it, he found there was nothing wrong with it—except that the scammer had removed the memory, processor and hard drive. Now Chad is out $500 and left with a shell of a computer, and since the item was “received” Paypal won’t do anything.
Very clever. The seller accepted the return from UPS after a visual inspection, so UPS considered the matter closed. PayPal and eBay both considered the matter closed. if the amount was large enough, the seller could sue, but how could he prove that the computer was functional when he sold it?
It seems to me that the only way to solve this is for PayPal to not process refunds until the seller confirms what he received back is the same as what he shipped. Yes, then the seller could commit similar fraud, but sellers (certainly professional ones) have a greater reputational risk.
Details from TheRegister.
Sidebar photo of Bruce Schneier by Joe MacInnis.