PayPal redirect exploited in Apple ID phishing attack

Fraudsters have exploited a redirection vulnerability in a PayPal website in an attempt to steal Apple IDs. Phishing emails sent by the fraudster were disguised as receipts from the iTunes Store for expensive items, enticing victims to try to cancel the fake orders.

The emails stated, "If you did not order the above products and suspect your account has been hijacked kindly visit the link below". The link was displayed with a legitimate-looking location (www.order.itunes.com/verify/cancel) but actually took victims to a URL on the PayPal communications website. The phishing email also noted, "You will be asked some specific questions about you and your financial data to prove you actually owned the account."

The page on PayPal's website at https://www.paypal-communication.com/r/4V2JION/PPPU5A/GDY6I8I/20PEVD/7ZS7MP/7M/h?a=http://192.185.##.###/~broo23yo/ immediately redirected victims to the Apple phishing site specified in its GET parameter, http://192.185.##.###/~broo23yo/. Parts of these addresses have been obfuscated, although the target of the redirect has since been suspended by its hosting company, HostGator, and the PayPal URL used in the phishing emails no longer redirects to the URL specified in the a parameter.

Fraudsters use redirection scripts on well-known and well-trusted websites in order to increase the success of their phishing campaigns. Some email clients block access to links that use IP addresses directly and, as such, would scupper the fraudster's efforts. Using a fully-qualified domain name eliminates this particular problem, and some operators of third-party blocking software might also assume that all PayPal domains can be trusted without exception, which may not always be true. Cautious users who hover over links before clicking on them will see that the disguised links in the phishing email actually go to a trusted PayPal website, which would not seem untoward.

PayPal's site at www.paypal-communication.com uses an extended validation (EV) SSL certificate, which demonstrates that an enhanced set of guidelines has been followed in order to verify the identity of the website's owner. Some browsers emphasise this additional level of verification by adding green cues to the address bar, so a visitor can be sure with reasonable certainty that this site does indeed belong to PayPal, Inc. In this case, however, the redirect was near-instantaneous, so potential victims would not have seen the additional EV browser cues.

Notably, the secondary purpose of extended validation certificates is to address problems relating to phishing, but this is not effective when a phishing attack exploits flaws on a legitimate website using an EV certificate. A somewhat-similar scenario has previously affected PayPal: a third-party website which used an EV certificate was compromised and used to host a PayPal phishing site in 2011.

Incidentally, encrypted traffic destined for www.paypal-communication.com could also be vulnerable to eavesdropping. This Apache-powered website offered the TLS heartbeat extension prior to the disclosure of the Heartbleed bug, so the private key for its SSL certificate could have been compromised. PayPal promptly reacted to this by switching to a new SSL certificate (issued on 14 April 2014), but crucially, the potentially-compromised certificate has not been revoked. PayPal's main site, www.paypal.com, is affected by the same problem: its pre-Heartbleed certificate has also not been revoked.

Failing to revoke the previous certificate means that if it has been compromised, correctly-positioned attackers could use it to impersonate the secure PayPal communication website until the certificate expires in April 2015. As the site used an EV certificate, revocation is all the more important and is often more effective than the checks made for standard certificates. Most major browsers will make OCSP requests for EV certificates and will not display the EV browser cues if the certificate has been revoked or if there is no positive verification of its current status, e.g. if the OCSP request was blocked by a man-in-the-middle attacker. Revoked EV certificates are also more likely to appear in Chrome's CRLSets, which are arguably the most effective form of revocation checking currently available.