Google Leaks 282,867 Hidden WHOIS Records

Google is taking some flack after a defect in Google Apps accidentally leaked a large number of customers’ domain registration WHOIS information. Over 282,000 domains registered using Google Apps for Work since mid 2013 have been exposed, opening up the potential that victims could become targets of spear phishing attacks, or even identity theft. The leak was first discovered by Cisco’s Talos Security Intelligence and Research Group on February 19, who quickly notified Google of their findings.

The attack exposes these customers’ names, phone numbers, email addresses, and even physical addresses. The alarming part of this leak is that the effected customers payed extra for a service that specifically keeps domain registration WHOIS information hidden from public view. Google was partnered with a company called eNom to mange domains registered by Google Apps for Work customers, and was tasked with maintaining the hidden WHOIS data. Domain registrants fell victim to this leak when their domains were automatically renewed the following year. eNom’s domain renewal system did not recognize that the domain registrant had previously payed for the unlisted WHOIS service, and went ahead and publicly renewed the domains with the hidden registrant information, allowing the WHOIS information to be archived in the public directory.

After being notified by Cisco Talos of the defect in Google Apps, Google patched it five days later. Strangely, Google waited until March 12th, almost three weeks later, to inform the effected customers that their WHOIS information had been leaked. Cisco Talos, in their public statement regarding the finding, encouraged effected customers to take the necessary actions to protect themselves from danger as a result of their domain registration being leaked. Actions recommended for victims include monitoring their email accounts for suspicious mail that might be highly sophisticated and targeted phishing attempts, as well as to monitor things that might indicate identity theft, such as credit scores or bank statements.


Sources:
https://threatpost.com/google-apps-defect-leaks-private-whois-data-of-280000/111624
http://arstechnica.com/security/2015/03/epic-google-snafu-leaks-hidden-whois-data-for-280000-domains/

Jarrod Manwaring

Apple Pay Creating a New Attack Vector for Credit Card Fraud

When Apple announce Apple Pay last October the security of it was made a huge point for its use. After the huge iButt breach last year that was wildly publicized and eaten up by the media, Apples reputation for security has been shaken up. The whole idea behind Apple Pay is that credit card information does not pass between the retailer and consumer but that Apple Pay acts as a middle man trusted by both parties. The intention is to avoid breaches like the ones we have seen at Target and Home Depot where the weakness was in the POS systems at the retailer. In short, if the retailer never sees the sensitive information then the retailer can never leak the information.

The new vector lies in how new cards are set up. Apple Pay is now being used later on in the fraud process. Attackers are using stolen identifying information to add new credit cards to Apple Pay and then using Apple Pay to commit the fraudulent transactions. This has three main advantages to the attacker. One, the retailer can not verify the credit card information on their end because Apple has taken this burden. Two, they do not need to only stick to online transactions because they can use Apple Pay to directly purchase from retailers. Lastly, It is much harder to trace back to a person. Once a card is added to Apple Pay it can be used at any retailer that accepts it to spend as much money as possible before the card is flagged or deactivated. Interestingly enough it is estimated that 75% of the fraudulent transaction happen at Apple store themselves because to the valuable items sold and the integration with their own system.

The actual flaw in the system is low tech. There are 3 different paths that adding a new card can take, the Green Path (accepted), the Red Path (rejected) or the Yellow Path (requiring additional cooperation with the bank). Most of the fraudulent cards have been activated through the Yellow Path with banks that do not have good security practices.

Overall it is hard to pin the blame on someone with this issue. Is it the banks, Apple, or the people who got their identities stolen to begin with? What can be said for sure is that this story hurts Apples reputation for security. As with the iButt breach Apple has been more vulnerable to low tech hackers than actual holes in their code.

Ryan Frank

Sources:

http://www.latimes.com/business/hiltzik/la-fi-mh-apple-pay-would-be-secure-20150307-column.html

http://www.droplabs.co/?p=1231

http://searchfinancialsecurity.techtarget.com/news/2240241612/Amid-Apple-Pay-fraud-banks-scramble-to-fix-Yellow-Path-process

Phishing Leads to Man-In-The-Middle Attacks

Krebs on Security reported that a security company called Proofpoint had detected a 4 week-long targeted phishing campaign against customers of one of Brazil’s largest ISPs who use two routers (UTStarcom and TP-Link) that are commonly used on that ISP. The emails pretended to be an account/billing message from the ISP with a link to a fake site that looked like the ISP’s site. The fake site used a cross-site request forgery exploit to start a brute force attack against the victim’s router administrator login page using default usernames and passwords for the two brands of routers. Once the script had successfully logged in it would change the router’s primary DNS (Dynamic Name Server) address to the criminal’s own malicious DNS. This allows the crooks to monitor all web traffic, hi-jack search results and redirect the victim from legitimate sites to look-alike spoofs that steal authentication credentials and sensitive data like usernames, passwords and credit card info. This could also lead to the installation of other malware.

dnshijack-600x162
I
mage of malicious iframe scripts used to hi-jack the router and DNS

This type of  attack is especially dangerous because it can bypass antivirus and security tool detection and can even lead to the router and hosts becoming part of a bot-net.

The important take away from this attack is that users need to change the default usernames and passwords on their routers and take precautions against falling victim to phishing attacks.

Sources:
http://krebsonsecurity.com/2015/02/spam-uses-default-passwords-to-hack-routers/
https://www.proofpoint.com/us/threat-insight/post/Phish-Pharm

Author: Charles Leavitt

Uber Car Service Hack

It was revealed February 27th of this year that the one of the databases that the car service Uber owns was hacked on May 13th 2014. The vulnerability was not discovered until September 17th of that year. The information that Uber released appears to show that the vulnerability was only exploited once, and it appears that there were 50000 employees affected by the breach. The database contained the drivers full names and their licence numbers.

Upon discovery of the breach the company changed the access protocols. It does not currently seem like there was any customer information lost, and there only seems to be one instance of unauthorized access. Uber has given its employees a year of free credit  monitoring through the company Experian.

At this point there still does not appear to be any fraudulent activity among any of the 50000 people who were affected. Uber has created a lawsuit which allows them to investigate the intrusion and try to determine the name of the person who did the attack.

http://blog.uber.com/2-27-15

Samuel Mosher

Ramnit Shut down by Europol

Last week, European law enforcement shut down a botnet of 3.2 million computers with help of Microsoft, Symantec, and Anubis Networks.  Ramnit and its dangers have been known for five years.  Although it started as a simple worm, it evolved into a complex virus that used several methods to get information from its victims and spread.

There were six modules to Ramnit:

Spy module- Ramnit would watch what pages were viewed by its victim and manipulate web forms on certain pages to get extra information.  For example, it could add a “credit card number” field to an account creation page, and send that value back to the hackers.

Cookie grabber- It sent cookies from its victims to the hackers, so they can steal authentication to banking sites.

Drive scanner- Scanned the victim’s hard drive and sent files back to the hackers, specifically from folders likely to hold sensitive information.

FTP server- Created an FTP server on the user’s computer, so hackers could upload and download files from it with ease.

VNC- Allowed hackers to VNC into the victim’s computer at any time.

FTP grabber- Would grab credentials for FTP servers that the victim had access to.

Ramnit was spread via infected files hidden in downloads on compromised websites, including several public FTP servers, compromised due to the FTP grabber.  It evades most anti-virus programs, because it also copies itself to memory, so if it is wiped from the victim’s hard drive, it will re-install itself.

It was taken down when police forces in Germany, Italy, the Netherlands, and the U.K. seized the servers the hackers were operating on.

John Deeney

http://www.symantec.com/connect/blogs/ramnit-cybercrime-group-hit-major-law-enforcement-operation

http://arstechnica.com/tech-policy/2015/02/europol-cracks-down-on-botnet-infecting-3-2-million-computers/