Risk
4/23/2010
02:45 PM
Connect Directly
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Blippy Leaks Four Credit Card Numbers

Social exhibitionism meets Google Search and learns that one can share too much information.

One day after The New York Times explored the rise in social Web sites that expose information about users' purchases and activities, declaring that people are becoming more relaxed about privacy, a minor data breach at one such site offers a reminder that people do indeed have something to hide.

Blippy.com, a social Web site that allows users to share information about things they've bought, was found to have leaked four credit card numbers. All of the numbers begin with 5424, the Citibank Mastercard prefix, suggesting that statements provided to Blippy by one particular payment processor contained too much information.

A Google search for the exact phrase "from card" in conjunction with the site: operator to restrict the search to the blippy.com domain turned up the four credit card numbers for purchases made at merchants such as Audible, Exxon Mobile, Pizza Hut, iHop, Kroger's, Starbucks, Wendy's, and numerous others.

The same search on Bing.com does not reveal credit card numbers and it appears that Bing has not even indexed them -- a search for a specific credit card number returns no results in Bing.

Ask.com and Yahoo.com searches also do not return credit cards from Blippy.

The reason for this is that Google's indexing procedure is not only extremely fast but also aware of new data on servers -- even data that has not been linked to other pages -- if the site owner has published what's called a site map. Site maps tell Google's crawler where to look for information.

In a phone interview, Blippy co-founder and CEO Ashvin Kumar said that Blippy has asked Google to remove the information.

Google responded as this article was being written. Subsequent efforts to access the search results pages were rejected with the following message: "We're sorry ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now."

In a blog post, the company offered an official statement: "Many months ago when we were first building Blippy, some raw (not cleaned up, but typically harmless) data could be viewed in the HTML source of a Blippy Web page. The average user would see nothing, but a determined person could see 'raw' line items. Still, this was mostly harmless -- stuff like store numbers and such. And it was all removed and fixed quickly."

But according to the company, Google indexed this information before it was cleaned up. While cached pages were subsequently updated to reflect the clean versions of the Web pages published by Blippy, its search snippets continued to include the data that had long since been removed from Blippy's files.

In a statement, Google confirmed that it was dealing with the issue.

"Around 9:00 a.m. Pacific we learned that Blippy.com had published credit card numbers on their website," a Google spokesperson said in an e-mailed statement. "As part of our usual crawling and indexing process, these numbers became discoverable in Google search snippets. Blippy contacted us and we took special measures to remove the numbers from search results. We fixed the problem around 11:20 a.m. Pacific and the numbers should no longer be discoverable in search."

Aware that news of the incident was spreading on Twitter, Google accelerated its takedown procedure for the information. But even so, the exposed credit card numbers have been copied to online forums like anonboard.com.

This means that the unfortunate individuals affected face an elevated risk of fraud or identity theft, even with the removal of their information from Google's search snippets.

Asked whether this incident might make some people reconsider sharing information, Kumar said, "Naturally people may feel that way, but they should know that security is a super-important issue for us. At the end of the day, we're all users of Blippy too and we don't want our information exposed."

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
DNS Threats: What Every Enterprise Should Know
Domain Name System exploits could put your data at risk. Here's some advice on how to avoid them.
Flash Poll
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio

The cybersecurity profession struggles to retain women (figures range from 10 to 20 percent). It's particularly worrisome for an industry with a rapidly growing number of vacant positions.

So why does the shortage of women continue to be worse in security than in other IT sectors? How can men in infosec be better allies for women; and how can women be better allies for one another? What is the industry doing to fix the problem -- what's working, and what isn't?

Is this really a problem at all? Are the low numbers simply an indication that women do not want to be in cybersecurity, and is it possible that more women will never want to be in cybersecurity? How many women would we need to see in the industry to declare success?

Join Dark Reading senior editor Sara Peters and guests Angela Knox of Cloudmark, Barrett Sellers of Arbor Networks, Regina Wallace-Jones of Facebook, Steve Christey Coley of MITRE, and Chris Roosenraad of M3AAWG on Wednesday, July 13 at 1 p.m. Eastern Time to discuss all this and more.