Security

36 Data Breaches We Found and Reported in 2016

In 2015 MacKeeper established a partnership with Chris Vickery — a skilled data breach hunter. Chris provided security auditing for MacKeeper, discovered potential threats, and advised the best solutions against future vulnerabilities. Besides that, Mr. Vickery reported on the newly emerged security and data breaches as well as provided useful personal recommendations on how companies and users can enhance their security.

 

2016 was marked by a growing number of data breaches. In this blog post, we’ve gathered the 35 most significant breaches.

 

This is the first post in a series of data breach reports.

 

 Click on a data leak name to read the report:

Essential reading and tools:

Microsoft Careers site: vulnerability attack

Punchkick Interactive is a mobile web development company. Microsoft relies on Punchkick to handle the database that powers m.careersatmicrosoft.com. The bad news is that, for at least the past few weeks, this backend database has been exposed to the open internet and required no authentication at all to access.

 

The good news is that as of February 5th, following my disclosure of the vulnerability to Punchkick and Microsoft, everything has been secured. For those curious, there is an overview screenshot of the database in its exposed form included with this post. You’ll notice some other company names in the image, but I focused on Microsoft due to the probability of that portion having the most impact.

 

All indications are that the database, a MongoDB instance, was not write-protected. You probably see where this is going — during the exposed timeframe, an attacker could have modified the database, and thus, the HTML code of job listing pages being served through m.careersatmicrosoft.com.

 

The ability to craft arbitrary HTML into an official Microsoft careers webpage is, to say the least, a powerful find for a would-be malicious hacker. This situation is the classic definition of a potential watering hole attack.

 

In that scenario, any number of browser exploits could be launched against unsuspecting job-seekers. It would also be a fantastic phishing opportunity, as people seeking jobs at Microsoft probably tend to have higher-value credentials.

 

Speaking of credentials, some of those were part of this exposed Punchkick database. As proof of the severity of the situation, one of my early emails to Microsoft regarding the vulnerability included a screenshot showing the name, email address, password hash, and issued tokens for Microsoft’s Global Employment Brand Marketing Manager, Karrie Shepro. A redacted version of the screenshot is posted along with this article.

 

My main point of contact at Punchkick Interactive was Charles Portwood. The most recent message I received from him contained, in part, the following:

 

The Mongo database is ours, but is used for a separate service that is ultimately consumed by the m.careersatmicrosoft.com website. This issue which caused the MongoDB to be exposed publicly has been fixed on our end.

 

Thanks for reporting to this us so that we could quickly correct it.

 

Charles R. Portwood II | Punchkick Interactive

 

He is right about Punchick “quickly” correcting it. I believe there was only one hour between my first email to hello@punchkick.com and the database being secured. Punchkick gets points in my book for the quick turnaround, strong password hashing, and generally being very nice. This was an example of excellent incident response.

 

The lesson to learn here is that if you’re a big-name player like Microsoft, it’s acceptable for third parties to handle mundane operations like job posting webpages. But be aware that a hole in the third-party’s security can quickly become a hole in your security.

uKnowKids.com database error exposed sensitive information on 1,700 kids

The uKnowKids child tracking platform claims to make “Parenting Easier, and Keeps Kids Safe Online.” However, earlier this month I discovered they were doing just the opposite. One of the uKnowKids databases was configured for public access, requiring no level of authentication or password and providing no protection at all for this data.

 

COPPA requires that a service such as uKnowKids.com “establish and maintain reasonable procedures to protect the confidentiality, security, and integrity of personal information collected from children.”

 

I don’t know about you, but I would consider it not a “reasonable procedure” to give the public open, unfettered access to a database containing detailed child information. I know that uKnowKids.com is bound by COPPA because their CEO, Steve Woda, told me so in a telephone conversation.

 

In fact, during that very same phone call, Steve Woda tried all manner of intimidation tactics against me. I can only assume that this is because he doesn’t want anyone reporting on the incident. Woda repeatedly insisted that I have acted inappropriately in my response to discovering and alerting his company to the gaping breach.

 

Furthermore, he tried to convince me that an outlet reporting on the breach could face liability under COPPA (a claim which is, of course, preposterous).

 

I was a bit surprised by Steve’s tone during that February 18th phone conversation. Just the previous day, he had sent me email messages such as the following:

 

Thank you again for alerting me to the data security breach that you discovered. I am super sensitive to ANY and EVERY security vulnerability (and in this case, breach), and so I am very, very thankful for your note […]

 

And:

 

[…] you could easily put us out of business if we are not provided the opportunity to comprehensively deal with this appropriately […]

 

I have no interest in putting uKnowKids “out of business”. However, I do not appreciate it when someone is nice and agreeable in emails and then issues veiled threats over the phone.

 

There’s no way for me to know for sure how long this data was exposed to the public internet, although the information collected by Shodan.io suggests that the database had been up for at least 48 days. There’s also no way for me to know for sure how many people may have accessed the database during the exposed timeframe.

 

The lesson to learn here is that, if you’re a parent, be wary of services that offer to monitor your child’s online behavior. These services collect unnerving amounts of data on your child and, when a breach occurs, all of that data can be exposed to untold numbers of people.

 

Also, if you ever decide to do-the-right-thing and notify a company that they are leaking data, try to keep all correspondence in written format. I’ve found that CEOs are much less willing to mind their manners in telephone conversations.

The Kinotopic app data leakage

About three years ago there was an iPhone app named Kinotopic. According to their website, which is still up, “Kinotopic allows you to create, share, and store short video moments and make them more expressive – in the form of animated pictures and cinemagraphs.”

 

Past users of Kinotopic may be interested to learn that there is currently a MongoDB database that appears to belong to Kinotopic sitting out on the open internet with no protection whatsoever. This derelict MongoDB instance contains, among other things, the email addresses, usernames, and hashed passwords for, what appear to be, over 198,000 previous Kinotopic users.

 

I have tried to get in touch with the Kinotopic developers in several ways. All were unsuccessful. For example, the email address given on their website for help and support is help@kinotopic.com. But good luck trying to send anything to that email address. It will bounce almost immediately.

 

Also, I had fun trying to contact Apple about the issue. I figured that Apple might have some way to contact the developers of a prior iPhone app. After all, doesn’t it make Apple look bad if an app, that had gained Apple’s official seal of approval, then later exposes its user database to the entire world?

 

When I contacted Apple, they had this to say via email:
 

“Chris, if you believe that this issue affects the security of an iOS device or the iTunes Store, you may report it to product-security@apple.com. […]

On the other hand, if this security issue only affects the application itself, I’m afraid you will need to continue getting in touch with the app developer for assistance.”


When that response came back from Apple they already knew that I had hit a dead-end trying to contact the Kinotopic developers. I was expecting a little more assistance in tracking down the makers of this software that was, until recently, officially supported and offered in the iPhone App Store.

 

Once I’m confident that they are the proper people to speak with, I can provide the exact IP address and port number of the exposed database. A semi-redacted overview screenshot of the database should be visible above this post. If that is your database, I want to talk with you.

 

And to anyone that may have used Kinotopic in the past — It’s probably time to cycle in some new passwords to your mix.

The Seoul subway hacked. Predictions and real cases

Fortunately for everyone and especially for the South Korean government, 213 computers of Seoul subway did not contain any sensitive information except the HR and internal planning-related documentation. However, the hackers stole 12 documents with the above-mentioned content.

 

Actually, this post is not dedicated to the hack of the subway in Seoul. We’ll try to explain how important is security for such a huge mechanism as the subway, what may happen in case of a hack, and what other known cases of hacks occurred before.

 

In one of our previous posts, we described and highlighted what is cyberwar and what could happen if it started. Actually, hacking the subway is a perfect weapon in the cyberwar. And security for such complicated systems is the main part in modern development. The subway typically includes several separate networks, which are not interconnected, such as the service network and administrative network. The first one is encrypted and extra secure. At the same time, it is not connected to the global Internet and is operated internally by management staff. Such structure helps to avoid the leakage of sensitive and strategic information. Moreover, it helps different sectors of the subway to work properly without affecting each other.

 

Unfortunately, the number of countries that care about subway security can be counted on the fingers. The main reason for this is the lack of modern equipment to develop security properly. As a result, disrupting traffic is as simple as hacking the local home network. In the worst-case scenario, the hack may cause the accident and even ransom.

 

A popular case has happened in Kyiv, Ukraine, when hackers hacked the digital screens in the subway cars by placing a photo of the famous “miss me” scene from BBC’s Sherlock. The subway management still has no idea what happened and who hacked them. Almost the same case happened in the Moscow subway when after connection to the Wi-Fi network the ISIS flag with title “Paris was yesterday, Moscow is today” appeared on the screen.

 

Likely, today the most popular target for cyberattacks is the turnstile system with the access cards. The daily ridership of the New York subway is more than 5,000,000 people, and the number of hackers is growing.

 

Still, we don’t know of any massive subway cyber-attack with victims. However, considering the rise of conflict between ISIS and the world’s leading countries, subway operators must consider the risk of being hacked. Radio subsystems are obviously more exposed, especially in ISM bands. In 2012, the Shenzhen CBTC system in China was reportedly jammed and the railway authorities interrupted 3G services for a day 11,16.

Verizon double-take data breach

Brian Krebs recently reported on a Verizon data breach.

 

I don’t know for sure if the bad guys in the most recent breach actually used an exploit to get the data, but I can tell you that the Verizon MongoDB that I found was completely unprotected by any password or authentication. All you needed in order to access it was a MongoDB client and the IP address.

 

The big difference is that the one I discovered was then responsibly disclosed to Verizon. However, it took them a month to plug the hole. It never made the news, but now I wish that I had made a bigger deal out of it. Maybe that would have spurred some changes which could have prevented the breach that Krebs wrote about.

 

Let’s start with my initial email to Verizon, which I sent to EmergencyCyberReport@verizon.com on December 22nd, 2015, and titled “Urgent data exposure notification”:

 

I've stumbled upon what appears to be one of your databases. It is currently configured for public access without any sort of password or authentication at all. In reviewing some of the data present, I have come across, for example, secret Verizon encryption and authentication keys (PSKs).

 

There are also some access tokens and password hashes for various services and accounts. This database also includes massive amounts of data and metadata for DVR, VOD, and Fios Hydra services.

 

If you believe this is indeed your database, I can provide the IP address and port number that you will want to check and secure. Please do respond promptly, as I'm sure Verizon does not wish for this data to remain in the public's view.

 

Sincerely,

Chris Vickery

And here is the response I received almost one month later (on January 19th, 2016):

 

Hi Chris,

 

It appears that you sent us a find and no one has responded.  Please confirm either way – if you have not been contacted then I would like to introduce myself – I’m the Director of Corporate Cyber Security for Verizon and will be your POC.

 

I look forward to hearing from you and working with you on your find.

 

Jim Matteo

Director

Verizon Corporate Security

 

I sent back a response letting Jim know that I had not heard from Verizon and wasn’t even sure if the database was still exposed (it was). I also asked Jim if I had included the IP address in my initial report and if there was anything else they needed from me.

 

That message prompted the following response from Jim:

 

I think I have everything. Give me a day or 2 to rattle some cages in our IT shop and get this looked at.

 

Thanks for your patience and again I apologize for our confusion over here

 

That evening it occurred to me that I had not actually sent Verizon the IP address of the exposed database in my initial report. I started to wonder if Jim really did have everything. So, I checked to see if the database was still leaking. To my surprise, it was. That’s when I fired off another email to Jim:

 

I just checked, and was surprised to see that the database is still exposed. While you're rattling those cages, you might want to point someone towards IP address [REDACTED] on port 27017 (the default MongoDB port). That's where the completely open database can be found. Attached is a screenshot that should also help.

 

Thanks for getting the ball rolling on this one.

 

-Chris

The same evening, Jim responded with the following one-liner:

Thanks for helping us out  — even if we're slow out of the gate. I'll be back with you shortly

 

That’s where the story went cold for a long time. I had not heard back from Jim until March 28th, 2016 when the Verizon PR staff heard that I was planning to post this article.

 

I want to be very careful here and make sure that nobody thinks I’m disparaging Jim. He has a very intense job and oversees a lot of people and systems, so I’m not trying to give the impression that he unfairly brushed me off. I’m sure things fall through the cracks all the time at every corporation the size of Verizon.

 

Jim and I actually had a very nice phone conversation last night. It turns out that the Verizon PR team is claiming that the MongoDB I found was only a test environment with fictitious customer data, non-sensitive reference material, unique encryption keys, and solely used passwords specific to that test environment (i.e. move along, nothing to see here).

 

So I asked Jim about that PR claim. Jim told me that he never personally had the opportunity to see the database that I found, but the PR people are indeed quoting the official report that had been passed up the chain regarding the incident.

 

That’s when I let Jim know that I still have over 50 gigs of data dumped from the MongoDB that I found, and that at least some of the database tables are actually marked as being production (i.e. not test data).

 

Jim understandably became very interested in the 50+ gigs of Verizon data that I still have. We agreed that it would be best for me to zip it down and securely upload it to him so that Verizon can review it and verify if this database really was just a “test environment” with no sensitive data. I did so last night.

 

Readers may be curious as to why I don’t necessarily believe Verizon’s claims at this point. I mean, if this database really was exposed to the public, then it would make sense that nothing important was in it, right?

 

Well, the thing is that companies, when caught with their pants down, almost always claim that the exposed data is fictitious, or just a test environment. It’s an easy excuse that, if believed, gets them out of a lot of potential embarrassment and liability. I’d say that 90% of the breaches I find are initially denied as just “test data”. But I’d also say that the vast majority of those do indeed turn out to be real breaches in the end.

 

The truth is usually a mix. Much of the time it really is a test environment, however, that test environment has usually been populated with real, production, data. So, in essence, it is a hybrid breach involving real data in an environment that no one was taking seriously. This is a potently dangerous practice that I’m finding more and more.

 

As you can see from the screenshots posted with this article, there was some ominous stuff here. My eyebrows raised when I realized there were password hashes exposed for accounts named “VzAppUserRW”, “VzAdmin”, and “VzSuperAdmin”.

 

To the victims of Verizon’s most recent data breach, I want to say that I’m sorry. I’m sorry that I didn’t make a bigger fuss back in December and January when I found the other exposed MongoDB. If I had sounded the alarm on that one, then maybe things would have been tightened down just a bit more and perhaps this latest breach, the one that Brian Krebs is reporting on, wouldn’t have happened.

 

***UPDATE***:  After one more conversation with Jim Matteo, from Verizon, I have additional details to report. For starters, I was right about the “hybrid breach” scenario in this case. It turns out that there was indeed production data here in somewhat of a test environment.

 

According to Jim, there had been some kind of service disruption in one of Verizon’s network services around November 6th, 2015. That’s when this test environment was put together and populated with, at least some level of, production data. It was used to troubleshoot and resolve the errors, but then wasn’t properly taken down after the problems were fixed. In fact, some Verizon employee, whether intentionally or unintentionally, ended up opening up the database to the entire world. That’s when I found it and reported it.

 

Jim assures me that even if this particular database had been fully leaked to the public, rather than just me discovering it, then no one really would have been harmed. I hope that’s the truth and I have no particular reason to disbelieve Jim. Although it still makes me curious if making a bigger deal out of the MongoDB I found would have resulted in tighter security measures surrounding the MongoDB that Krebs has more recently reported as stolen.

 

In the end, I have securely purged all 50 gigs of Verizon data from my storage and notified them as such. I’ll also be keeping Jim’s cell number handy just in case I find any more little treasure troves bearing the Verizon logo in the near future.

 

Follow the latest security news and stay up to date with information about security breaches with MacKeeper Security Research Center.

Massive breach of Mexican voter data

See the interview with Chris Vickery commenting on this breach.

 

Before going any further, let’s make one thing very clear. I’m not the one who transmitted the data out of Mexico. Someone else will have to answer for that. However, eight days ago (April 14th), I did discover a publicly accessible database, hosted on an Amazon cloud server, containing these records. There was no password or authentication of any sort required. It was configured purely for public access. Why? I have no clue.

 

After reporting the situation to the US State Department, DHS, the Mexican Embassy in Washington, the Mexican Instituto Nacional Electoral (INE), and Amazon, the database was finally taken offline April 22nd, 2016.

 

Under Mexican law, these files are “strictly confidential”, carrying a penalty of up to 12 years in prison for anyone extracting this data from the government for personal gain. We’re talking about names, home addresses, birthdates, a couple of national identification numbers, and a few other bits of info.

 

Earlier this week I gave a talk at Harvard University’s Center for Government and International Studies building, primarily on the topic of data breaches. As luck would have it, there was a student from Mexico present. After the talk, during which I had announced this latest breach discovery, he was able to confirm the accuracy of at least one record in the database.

 

His reaction was very serious. He immediately understood the potential harm that could be done if this database were to end up in the wrong hands. Kidnapping is a considerable problem in Mexico, and allowing cartels to download copies of this database could prove disastrous.

 

Following the September 11th terrorist attacks, the United States, for whatever reason, acquired a similar database through a data brokerage firm known as ChoicePoint. From what I’ve read, ChoicePoint managed to get ahold of the Mexican voter database in exchange for $250,000 back in the early 2000s.

 

When that story broke, citizens across Mexico were outraged that the US Government had the country’s private details. I can only imagine what fury will ensue now that anyone in the entire world could have potentially downloaded it. I mean, I’m just some guy in Texas… and I have it.

 

Related article: Another Mexican Database Found.

 

*Note:  Thanks go to the administrator of databreaches.net (who is also covering this story at https://www.databreaches.net/personal-info-of-93-4-million-mexicans-exposed-on-amazon/).
 

**Additional thanks to journalist Adam Tanner (Fellow at Harvard’s Institute for Quantitative Social Science) for putting me in contact with Mexico’s Instituto Nacional Electoral.

Medical records of 150,000+ patients became available online

Medical records contain all information relating to a patient's medical condition. In the old days medical records were a paper folder stored at the Doctor’s office. The records were relatively safe and secure because they were locked away in a storage room and only a small number of people would have access to them. Now anyone with an internet connection can potentially access the sensitive information of a massive number of Americans.

 

The MacKeeper Security Research Center experts have discovered the open and unsecured databases of the Electronic Medical Record by management companies Carebox and HealthELT. The databases contain the private medical data of more than 150,000 patients and were not encrypted or password protected. US Federal Law prohibits publicly sharing medical records under HIPAA that allows access to medical records and to keep that information private.

 

Health:Elt according to their website is a “Startup That Focuses On Medicaid Engagement, Logistics, And Technology Services”. To be fair, their database was secured and closed before we could contact them about the leak.

 

Clayton Gulick, CTO of HealthELT, replied to the notification email:

 

“We discovered this last week and closed it down, it was just a misconfigured dev database with test data, no sensitive data was leaked. Thanks again for notifying us!!”

 

***The screenshot clearly shows Social Security numbers and other sensitive medical data.

 

Carebox’s website says:

 

“We believe that Carebox will accelerate an inevitable transformation in how patient clinical data is collected, organized, and used… and we think the potential implications of that are incredible for consumers, life sciences, providers, payers, and employers!”

 

By the time of publication, Carebox did not respond to the notification email, but their database is now secured.

 

For cost and convenience medical professionals all agree that the future of Medical Records are Electronic Medical Records (EMRs). The benefit of EMRs are that they can be tracked and available at a moment’s notice to any medical provider. However, this also makes Electronic Medical Records vulnerable to data leaks or being exposed online if they are not properly secured and protected. This is yet another lesson of how important it is to secure and encrypt the private data of customers and users of any digital service provider.

 

Medical Record Storage is a vital concern for Practices, Clinics, and Hospitals of every size. As the requirements for Medical Records Management continue to change, practices need to stay updated on the latest data security practices and be in full compliance with the latest Records Retention Requirements. The MacKeeper Security Research Center did not download the entire user database, but only took screenshots as proof of the data leak and immediately notified Carebox and HealthELT to ensure the data was secured.

Over 10m marijuana site chat messages leaked online

The first has to do with TheTreesNetwork.com, a marijuana-enthusiast site where people are invited to casually gather and chat while watching videos that appeal to that target demographic. Personally, I have no feelings one way or the other regarding marijuana usage. But I do have a soft spot in my privacy-loving heart for people who may be saying incriminating things in an online chat without knowing that logs are being kept and their identities could be easily compromised by a breach.

 

On May 8th, I notified the site of their unprotected MongoDB database in an unusual, but certainly effective way. After joining the chat, I wrote “What would you do if I had proof that this site is leaking user details?”. The response from the crowd was basically, “Prove it.” So, I did by posting an Imgur.com link to an image showing an overview of the database (but not the specific IP address or any user details).

 

An admin was very quick to respond, as I expected. He (or possibly she) fixed the problem in mere minutes. It may have been the world’s fastest incident response.

 

As you can see in the first screenshot above this post, the unprotected Trees Network database contained over 10 million chat messages coming from over 44,000 users. I’m willing to bet that some of those chats would qualify as self-incriminating.

 

If anyone had admitted to criminal activity in one of those chat messages, then that person might be alarmed to learn that The Trees Network also keeps logs of its users’ IP addresses (see the second screenshot above). So, even if you are chatting under a pseudonym, all it would take is a subpoena to your internet service provider to find out who you are (assuming that a proxy or VPN is not being used).

 

The passwords found in the database were obscured using a strong hashing method (bcrypt). So, while it would be a good idea for users of the site to change their passwords, it wouldn’t be trivial for a malicious actor to break them.

 

The lesson to learn here is to always be careful about what you say online. You never know when it might come back to haunt you.

Breach #2

I believe the second data breach that I’m mentioning today involves the site Telly.com. However, I can’t be absolutely certain about that because they won’t answer my emails, they haven’t responded to Twitter messaging, and their DMCA phone line gives me a busy signal. It’s ridiculous.

 

I’ve been trying to alert them that they may be leaking account details of over 14 million users. Telly.com seems to be a primarily Arabic site, but plenty of it is in English, so I was hoping we could communicate. As you can see in the third screenshot above this post, it could be a fairly serious one. Follow the latest security news at MacKeeper Security Research Center with Chris Vickery.

Children’s educational site exposes thousands of user accounts and payment data

One of the biggest rules of data storage is to protect payment details of customers and taking every step possible to prevent unauthorized people to access stored cardholder data many companies use 3rd party merchant accounts to avoid processing payments.

ABCya.com data leak

ABCya claims to be the leader in free educational kids computer games and activities for elementary students to learn on the web and has an estimated monthly 4 million visitors per month. The site offers a wide range of games and tools to help children learn with educational games and tools. They claim “Millions of kids, parents, and teachers visit ABCya.com each month, playing over 1 billion games last year”. ABCya offers monthly subscriptions ranging from $6.99 to $29.99 and had the credit card data stored on a misconfigured database that was publically available.

  • credentials and info of 11k+ archived customers (incl. IPs, emails, names, temporary access code, hashed and salted passwords)
  • credentials and info on 21k+ active customers (incl. credit cards details such as hashed ID, fingerprints, expiration year and month, last 4 digits and card name in plain text).
  • more than 3k+ Stripe tokens and info
  • credentials of 4 “super admin” users for ABCya with encrypted/salted passwords and details.

The MacKeeper Security Research Team sent notifications on May 19th and received no response but noticed that databases are now secured and not publically available.

 

With each and every data breach, it becomes clear that companies who store customer data must take every precaution to protect that data. Companies who store and collect credit card data have additional responsibility and nearly every credit card provider discourages businesses from storing credit card data.

Another Mexican leaked database found

This is just a quick note to explain that I discovered another publicly exposed Mexican database on Wednesday, May 18th. I reported it to the Mexican electoral authority (INE) that same day.

 

Today, INE held a press conference and reported that the database has been taken offline. Their initial investigations indicate that the data pertains to the region of Sinaloa. I cannot confirm or deny that aspect at this time.

 

As far as I know, they did not mention the political party responsible for this leak. I can report that the database was titled “DBPRI” and all signs point to the PRI party as being responsible here. I have included a few screenshots further illustrating the database with this post.

 

I plan to post more about the situation as things develop.

 

And yes, I do have a copy of it.

Pacific Gas and Electric database exposed

UPDATE (Jun 1st): This post has been updated to include a statement from PG&E

 

Last week I discovered a data breach involving Pacific Gas and Electric, a very large electric utility company in California. The publicly exposed database appeared to be PG&E’s asset management system. Among other things, it contained details for over 47,000 PG&E computers, virtual machines, servers, and other devices. All of it completely unprotected. No username or password required for viewing.

 

We’re talking about IP addresses, operating systems, hostnames, locations, MAC addresses, and more. This would be a treasure trove for any hostile nation-state hacking group. That’s not to mention the 120 hashed employee passwords, or the plaintext NTLM, SOAP, and mail passwords.

 

Does anyone recall a recent example of hackers crippling an electric utility?
 

I do: https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid/

 

Before going any further I want to let you know that PG&E’s IT department is trying to claim that the database was “fake”. However, I want you to also know that nearly every data breach that I find is initially claimed to be fake. It’s a quick, easy excuse when your company is caught with its pants down and, if it works, you get off free and clear. But that excuse isn’t going to work this time.

 

Fictitious databases do not generally have areas specifically marked development, production, and enterprise. Fictitious databases do not generally have over 688,000 unique log record entries. This database did.

 

Sure, it’s theoretically possible to create software that could generate massive amounts of fake data, but companies don’t do that. Even if a database is for development purposes only, they tend to fill it with real production data. They do that because production data is easily available and free. Companies generally do not pay people to sit around and create great swaths of false data when plenty of data already exists to use. I’ve seen it over and over again.

 

To be clear, I absolutely do not believe PG&E’s claim that this is all fictitious data. They sure took it down quickly after I notified them on Thursday, May 26th.

 

PG&E didn’t bother to ask me if I downloaded a copy of this open, publicly exposed database. I’ll tell you now that I did. I still have it.

 

Ultimately, I would like to provide it to the US Department of Homeland Security so that they can 1) determine whether or not the data is genuine; and 2) take appropriate actions in the event that hostile actors also found the database.

 

PG&E Statement

  • With this incident, it is important to know that none of PG&E’s systems were directly breached in any way and no customer or employee data was involved.
  • A PG&E vendor was hosting an online demonstration using PG&E asset management data to show the capabilities of a platform that they were developing for us.  This data contained information on PG&E’s technology assets, such as computers and servers.
  • Our initial review indicated that the data was non-sensitive, mocked-up data. We based this feedback on an initial response from the vendor stating that the information in the database was a demo or “fake” data. Following further review, we learned that the data was not fake and removed access.
  • We continue working with all of our vendors to have appropriate procedures in place at all times to protect PG&E data in those instances when they have it.

Report: Boston-based educational consulting firm exposed the personal information of thousands of international students and hosting homes

The database (found via Shodan search and hosted on an Amazon cloud IP) appeared to be part of The Cambridge Institute of International Education (CIEE), a Boston-based educational consulting firm that increases international participation in American private high schools and strengthens the ability of those institutions to educate international students, according to their website cambridgenetwork.com.

 

Initially, when contacted by emails from their website on Jun 6th, CIEE did not respond to the database notification. However, after a phone call to their Boston office, the database was finally secured within an hour. MacKeeper Security and Research Center would like to thank Databreaches.net for assisting with the notification to CIEE.

 

One folder in the database seems to have a massive number of files that were publically accessible to anyone looking for them. The folder was titled "NewStudentsApplicationReportForFinanceV1" appears to have over 600K+ records for international students and includes personal information including names, emails, passwords, phones, account details, relatives info, passport details (all in plain text). Plus there were even correspondence records between the Cambridge Institute of International Education team members, and housing reports and working links to the pdf's and payment confirmations.

 

In addition, there was an additional collection of records that included the detailed information of 12,000+ hosting houses, containing the information on a household, family member details (such as medical conditions, if any, religious beliefs, even frequency of attending religious activities), occupation details, incl. emails and phones, birthdates, and other extremely sensitive data on the personal privacy of the host families. The database contained a treasure trove of sensitive data could have been used for a wide range of illicit activities and in addition to the possible illegal or criminal uses of this data, it is extremely embarrassing to see documentation of housing reports and detailed descriptions about students’ conflicts, medical conditions, personal problems, living conditions, and much more. 


Interestingly, the MacKeeper Security Researcher who discovered the data leak when browsing in Shodan took notice that the database was named after a planet from Star Wars. The database was named “Coruscant” —  a planet in the Star Wars universe (Imperial Center during the reign of the Galactic Empire).

 

The Cambridge Institute of International Education is yet another example of the importance of protecting sensitive data in the educational field. Since 2014 the number of students’ who have had their data compromised online has continued to grow and with over half of a million accounts left unprotected, it shows the full scale of just how big the number of students Cambridge left vulnerable vs other recent leaks.

 

*Notable data leaks or breaches to colleges and educational institutions 2014-16

  • The University of Maryland exposed SSNs and more for 300,000 students and employees
  • North Dakota University lost data on 300,000 students to hackers
  • Butler University lost 200,000 to hackers, and Indiana University exposed information on 146,000 students.
  • In 2015 vendors seeking to do business with the Chicago school district were given the personal data of 4,000 students
  • 2016 The University of Greenwich's accidentally published the personal data of students on their website

Real case: Topps’ mobile app's user accounts leaked online

Most adult men in the US will recognize the Topps brand name. They are the baseball card company that we all know and love. Unfortunately, I have reason to believe the Topps phone apps team may have some data security issues to address, and I can’t get a response out of Topps.

 

Bunt, Huddle, and Kick are three of Topps’ mobile apps that give fans the opportunity to engage each other on the go. Those same fans may be alarmed to learn that, back in early December of 2015, I stumbled upon three separate, publicly accessible databases containing what I believe to be many hundreds of thousands of user account details for these apps (a different database for each of the three), along with other data tables apparently necessary for the app servers to function.

 

The good news is that those three databases were secured a few days after I discovered them, which was faster than I could get around to sending notifications to Topps. Thinking that was the end of it, I decided to forget about the situation and move onto other things. Little did I know, about two weeks ago, a similarly exposed and publicly accessible database would appear (with all three apps’ data together on this one server).

 

There has been plenty of opportunities to notify Topps of the apparent leak this time around. In fact, I’ve sent emails to three different Topps support addresses:
 

Hello Topps,
 

I am a security researcher that occasionally comes across publicly exposed databases. Unfortunately it appears that I may have come across one belonging to you and containing a large amount of sensitive user account information. This looks like it involves data from Topps apps such as Huddle, Bunt, and Kick.
 

[SERVER DETAILS REDACTED]
 

[…] As I will most likely publicly disclose word of the incident (but not the data itself), it is only fair to let you know that any response, or lack of response, may be included in that reporting.
 

-Chris Vickery

The only response has been one automated message:
 

Your request (#172563) has been received and will be reviewed by the Topps BUNT Team […]


That’s all I’ve gotten back from Topps in over a week. At this point, I can’t definitively assign any fault to Topps regarding the apparent data leakage. After all, they have not confirmed or denied anything yet. Maybe it’s not their data after all, but that would really surprise me. Nevertheless, I can’t in good conscience watch this data continue to leak without at least trying to get a warning out.

An Interesting Announcement

As much as it pains me to say this — I’ve found another exposed US voter profile database. This one has 154 million entries.

Another US voter database leak

The database, a CouchDB instance, was located at IP address 104.154.48.169 on port 5984. It was configured for public access with no username, password, or other authentication required.

 

That address resolves to 169.48.154.104.bc.googleusercontent.com (which is the IP address in reverse followed by a google domain name). This indicates that the person or organization responsible for the leaky database was renting server space from Google’s Cloud services.

 

Each record contained an ID field following the scheme of “LAL”+[State Abbreviation]+[Record Number] (an example for Alaska would be LALAK176743). A little internet sleuthing showed that a data brokerage company named L2 (http://www.l2political.com) uses the same naming scheme for their records.

 

On Tuesday, June 21st, 2016, I sent an email to every L2 email address I could easily locate notifying them of the situation. In my email, I put forth the theory that a client of theirs was hosting data purchased from L2 in an insecure manner and asked for L2’s assistance in getting it taken down. I also attached a screenshot as proof of my findings. It turns out that my hypothesis was correct and L2 was more than willing to help me track down the client at fault.

 

Shortly after my email went out I received a response from L2’s CEO, Bruce Willsie, asking me to give him a call and providing his cell phone number. We had a pleasant conversation and I provided him with additional details that would hopefully assist in identifying exactly which client was responsible.

 

The database was taken offline within three hours of our telephone conversation. That’s a pretty good turnaround time if you ask me. After noticing that the database had disappeared, I sent another email to Bruce asking if L2 would like to make any statement prior to me reporting on the situation. His response was:

 

Hi Chris.

 

Thank you for finding this and thank you for giving us the opportunity to respond. We very quickly identified the national client, informed them immediately and they took down the site as quickly as they could. The client told us that they were hacked, the firewall was taken down and then the probing began.  

 

This was an old copy (from about a year ago) of the national file and it had only a very small number of our standard fields. Needless to say, the client is doing its own research now to determine the extent of the incursion. I’ve asked that they report back to us with their findings and their plan for hardening their system in the future. It’s unfortunate and, again, we greatly appreciate your discovery of the problem.

 

Best wishes.

 

Bruce Willsie

 

The “we were hacked” explanation comes out a lot in the kind of research that I do. One of the more noteworthy examples of this was when the Citizens’ Movement political party of Mexico made the same claim after I found an exposed copy of that country’s voter database. I have always believed that Citizens’ Movement was just lying to cover their own mistake.

 

That doesn’t necessarily mean that L2’s client is lying about being hacked, but I am taking it with a grain of salt.

 

The Serbian Connection:
 

While I was poking around this publicly exposed US voter profile database, I happened to query the server’s log file. The limited results are in the final screenshot above this post. Forgive me for not being savvier with the CouchDB suite at the time (I’ve since learned of better ways to enumerate the log file).

 

You can see that a Serbian IP, 89.216.31.2, was interacting with this same database back on April 11th of this year. Why was a Serbian IP messing around with a US voter database? Even if this was just a proxy server it is still very troubling that this apparent incursion took place back on April 11th.

 

If you have any special insight as to which organization may be responsible for this leak, please leave a comment below or send me an email. I’ve included a fair bit of information in this post, and maybe someone with better-sleuthing skills than myself can help crack the case. I don’t think L2 is going to tell us.

World-Check global terrorism database exposed online

A few years ago, Thomson Reuters purchased a company for $530 million. Part of this deal included a global database of "heightened-risk individuals" called World-Check that Thomson Reuters maintains to this day.

 

As stated by Vice.com, World-Check is used by over 300 government and intelligence agencies, 49 of the 50 biggest banks, and 9 of the top 10 global law firms. The current-day version of the database contains, among other categories, a blacklist of 93,000 individuals suspected of having ties to terrorism.

 

According to Chris, no hacking was involved in his acquisition of this data. “I would call it more of a leak than anything, although not directly from Thomson Reuters. The exact details behind that can be shared at a later time.”

 

This copy has over 2.2 million heightened-risk individuals and organizations in it. The terrorism category is only a small part of the database. Other categories consist of individuals suspected of being related to money laundering, organized crime, bribery, corruption, and other unsavory activities.

 

Thomson Reuters claims that the database has been exposed by a third-party and confirmed that data is now secured. Chris from MacKeeper has not released this database to the world.

 

***

 

Source: https://www.reddit.com/r/privacy/comments/4q840n/terrorism_blacklist_i_have_a_copy_should_it_be/ 

Security alert: Symantec and Norton vulnerabilities

According to Tavis, who discovered the vulnerabilities, the flows don’t even need any user interaction, they affect the default configuration, and the software runs at the highest privilege levels possible. “In certain cases on Windows, vulnerable code is even loaded into the kernel, resulting in remote kernel memory corruption.”

 

The list of vulnerable solutions in the Symantec enterprise line includes 17 items. These items had been posted as a security advisory on the Symantec website a bit earlier than Tavis’ post was published.

What is the danger?

Whoever could exploit one vulnerability in Symantec’s product by just emailing a file a link to a victim. Antivirus software cannot detect the malware until the executable is decompressed. Symantec decompressed files in the operating system’s kernel. It gave the malware hidden in an executable file an opportunity to gain complete access to the computer running the operating system. And, as Tavis said, the user didn't need to open or click the link. The wormable vulnerability lets an attacker easily compromise individual user data or the data of the entire enterprise.

 

If you are using one of Symantec's products, it’s time to update it right now. Symantec has already released updates of the products through the live updates, but not all of them. To close the vulnerabilities, some Symantec products should be updated manually. Learn Symantec’s advisory to update the product that you are using.

Real case: Oklahoma DPS and bank security exposure

On Saturday, July 9th, 2016, I called Automation Integrated’s service hotline to report that they may have a database security issue. The answering technician agreed there could be a problem as I described a CouchDB implementation, requiring no username or password to access, that appeared to contain an alarming amount of internal company files.

 

Among those files were photographs of security mechanisms (e.g. locks, RFID access panels, and controller boards) from within protected Oklahoma DPS buildings. Database entries contained, among other things, details on the make and model, location, warranty coverage, and even whether or not the unit was still functional.

 

My telephone conversation ended after I was provided an email address to which I could send details and evidence of the exposure. The technician also informed me that the email would be received by a group of company employees, so I might receive a panicked response.

 

Not entirely sure what to expect, I sent a brief message to the email address along with photograph attachments including images of the inside of an Oklahoma Highway Patrol building, a collection of surveillance camera stills, and one image taken from within a bank vault. A few of these images are viewable along with this post.

 

Some hours later my phone rang. It was a VP from Automation Integrated calling to thank me for alerting them to the issue. He took personal responsibility for the oversight and couldn’t have been nicer to me. He stated that the issue had been corrected and I verified, while still on the phone with him, that I could no longer access the database.

 

This is an example of an excellent incident response. The guy didn’t try to call me a hacker, he didn’t try to claim that it was a fake database filled with dummy data, and he didn’t try to deflect responsibility onto another company. What he did do was fix the issue promptly, verify with the original reporter that the issue was fixed, and he appreciated the fact that someone would go out of their way to make sure an issue like this was taken care of.

 

Sure, in a perfect world the problem would have never existed in the first place. But that’s not reality. Automation Integrated is far from alone. I have a constantly fluctuating list of 50 to 100 similar breaches that need to be reported. This one just happened to involve a security-related company and government buildings, so it got bumped to the top of my list.

 

Companies make these mistakes all the time. I wish more of them would react as well as Automation Integrated did.

Data breach on Sage servers

Specifically, what I found were over 20 unprotected MongoDBs, under the control of Sage customers, powering “on-premises” versions of Sage’s X3 server software suite. The Shodan.io search term used to unearth the list of unprotected installations was “port:27017 syracuse”. It appears that “syracuse” is an X3 server reference term.

 

X3 servers are intended for companies with over 200 employees, so finding more than 20 of them completely exposed to the public internet, with no username or password required for access, was a little unnerving. As you can imagine, some of these servers contained massive amounts of company records in the form of PDFs, DOCs, and XLS spreadsheets.

 

Initially, I had assumed that these servers were under the control of Sage itself and, accordingly, I sent an email notification earlier this week to the company regarding my findings. High-level Sage staff members sent a response back within hours (rather impressive when considering the UK time zone difference). We engaged in a telephone conversation shortly thereafter. The Sage representatives were very clear that while they claim Sage is not at fault for these breaches, Sage is extremely concerned with any situation involving their software being implemented insecurely by clients.

 

Sage immediately began a process of reviewing the IP addresses I supplied to them and notifying affected customer companies that have been insecurely utilizing Sage’s X3 server software. For a company that is claiming to not be at fault, it is noble that Sage would embark on such a quest to notify exposed companies spanning across the globe. Although, considering the potential public relations problems, it is probably in Sage’s best interest to do so. That process started two days ago.

 

So, what other kinds of interesting stuff did I find? Well, the first sign that these servers hadsomething to do with Sage was the presence of “[name]@sage.com” login credentials. Initially I considered the possibility that this situation could be the cause of Sage’s “insider credential” data breach. That has turned out to not be the case, but the possibility was interesting to say the least.

 

I can also tell you that certain identical password hashes were present across many of the installations. That strongly indicates identical default passwords being commonplace in X3 server implementations. Of course, there were also client-specific login credentials as well, and who wants to bet that many of those hashes could be cracked and used to access the also-exposed RDP services and SQL servers found at many of the same IPs?

 

Also worth noting—Sage confirmed that one of the exposed X3 servers I located was set up by Sage itself as a demonstration unit. That begs the question of why Sage would deploy a server, even if it was a demo, that contradicts its own best practices and instructions. A company as large and advanced as Sage should have IT staff that can run a VPN if something like access from a remote demo site is necessary.

 

I will likely catch some flak for now publishing details on how to locate this type of server. My decision to say something at this point is driven by a few key aspects. First of all, I’ve found logs indicating that I am not the first person to discover these exposed servers, so remaining silent would run the risk of less well-intentioned people plundering the data (if none have done so already). Secondly, there’s already been two days of Sage working around the clock to notify these exposed companies. If a client company’s IT staff is too inept to respond to this kind of urgent notification by now, then there’s little hope they will in the near future.

 

So, I’m left with what I’ll refer to as “the nuclear option.” That option being to ring some alarm bells and get a public message out. The message is simple: Sage’s on premise X3 software are not designed to be exposed to the public internet. If you are a large Sage client, make sure that your software installations are behind a firewall or, at the very least, you have some sort of access restrictions in place. Most companies do, but I know of at least 20 that did not… and the possible repercussions for those clients are frightening.

Luxury hotel leaks thousands of customers’ credit cards online

[This post has been updated to include statements on behalf of Silverland Hotels & Spas’ IT team - in italic]

 

The MacKeeper Security Research Center has discovered an open database belonging to the Silverland Hotel in Ho Chi Minh City, Viet Nam with thousands of unencrypted credit cards.

 

The cardholder accounts include the payment information of Australian, US, UK citizens and a range of international guests who have stayed at the hotel.

 

Imagine you have saved and planned for your perfect holiday trip to Vietnam’s capital, you booked your luxury hotel and of course, you wouldn't expect your card details and personal info available online. Along with the payment information, the database contained also login details, IP, and special requests of the guests. The total number of entries reached 6377 items (i.e. credit cards details).

 

This open database was publically available and required no password to access. The exposed database and the website were hosted on the same IP address.

 

The first notification was sent to the hotel email address immediately after we have identified the exposure during our weekly security scan on August 12th.

 

[The first email eventually discovered by Silverland, after being contacted by a customer late in the evening of August 29, in the hotel’s junk mail folder was dated August 17 and contained the August 12 email, which email did not include any address where it was purportedly sent].

 

[On August 30, 2016, MacKeeper engaged in a live chat with Silverland discussing the data leak.  That very same day, August 30, Silverlands’ IT team contacted Hostgator about the problem and port 27017 was immediately closed with password protection.  On September 6, 2016, Silverland completed the vulnerability assessment verifying that Silverland’s web server was secure.  Silverland’s customers that may have been affected were notified of the data leak by email on September 7, 2016]

 

The MacKeeper Security Research Center sent multiple emails, used the live chat feature on the website, and spoke with the assistant of the hotel owner using the private phone number found on the domain registry. Customers exposed as they continued to add additional credit card numbers to the database.  

 

It is unclear if the data was accessed by anyone else.

 

[UPDATE]

 

The Silverland Hotels & Spas’ IT team has secured the port in question with password protection, the webserver has been secured, the customers that may have been affected have been notified, and Silverland Hotels & Spas is working with the banking institutions to ensure that any potential problems are covered.  Additionally, Silverland Hotels & Spas has retained U.S. (Colorado) attorney Ira J. Bornstein to assist them in handling this matter.

Data breach at Kingo Energy

About two and a half months ago I came across a completely unprotected CouchDB installation sitting out on the open internet. As usual in my server scouring, no username or password was required for access. Several screenshots of this database are viewable along with this post.

 

Perhaps the most disturbing part of this breach is the inclusion of hi-resolution photographic images for both the front and back of Kingo customers’ Guatemalan national ID cards. Yes, it appears that, along with photos of the signed client contract, Kingo requires agents to take pictures of a new customer’s national identification card. Kingo then had the gall to store this highly sensitive data in an open, unprotected database that anyone in the entire world could access with a regular web browser.

 

Just to clarify a few things—It did not take the entire two and a half months to get this database secured. Personally, my Spanish is not great and language barriers can be daunting. Two years of high school Spanish has barely left me able to ask for directions. So, while I did understand that this breach would definitely need to be fixed, I put it on the back burner for a little bit while contemplating the best approach to take in contacting the right people.

 

Following an unrelated Columbian Government-related data breach, I met a high-level, native Spanish-speaking contact at Symantec. After considering him as a possible avenue to help reach the right people at Kingo, I took action on August 24th and, a few days later, the database became password-protected.

 

Kingo has not been greatly forthcoming on the exact details regarding which of my attempted breach notifications they received first, so I don’t know if it was my direct English-written email titled “Data Breach Notification,” or perhaps my Symantec contact, or one of the other avenues I attempted. However, Kingo has issued the following response:

 

[…] Our apologies for the late response but we were working on fixing the issue as a top priority.

 

Please allow us to tell you a bit about who we are and what we do:

 

Our mission at Kingo is "turning lives on", by providing a pre-paid solar system service for impoverished communities in Guatemala who lack of electricity. We are working to improve the life quality of many people by providing a solar energy system that provides illumination and positively impacts our customers in several areas such as financial savings, productivity, education, health and security.  

 

As an [sic] startup company we are constantly moving in order to have better and more reliable information systems. This is why we appreciate your inputs related to the recent data base issue reported.

 

We have taken immediate actions in order to secure the data. We are going to invest the needful resources in order to guarantee the privacy of our customer's personal information.

 

Thank you again for your inputs, sincerely

 

Kingo Team

 

This is certainly a very polite response from Kingo. They aren’t trying to call me a dirty hacker. They haven’t tried to blame the breach on a third-party contractor, and they aren’t trying to claim that it’s just a fictitious database. Those are the usual knee-jerk reaction statements I get from companies (which, by my own estimation, are lies about 90% of the time).

 

Let’s just hope I was one of only a few people to discover this database while it was unprotected and exposed. I know that there are many people actively scanning for exposed CouchDB instances, so, while I was probably not the sole person to find it, I’m crossing my fingers that no one with identity theft in mind grabbed a copy.

Data breach on the awards-screeners.com servers

As you might have guessed, awards-screeners.com (and the company responsible for running it, Vision Media Management) had a data breach problem to deal with recently. Almost two weeks ago I called Vision’s office to inform them that a MongoDB database, possibly related to their site awards-screeners.com, was completely exposed to the public internet with no username or password required for access.

 

The biggest immediately recognizable concern within this database was the existence of around 160 usernames and hashed passwords for people whose email addresses end with domains such as @paramount.com, @disney.com, @warnerbros.com, @fox.com, and @spe.sony.com. The user table had a total of about 1,200 entries, but there is reason to believe that some amount of load-balancing test data was also included. The 160 “actual logins” number is what Vision Media claims to be accurate.

 

The passwords that accompanied these accounts were strongly hashed (bcrypt algorithm) and salted. While this means that no one would likely be able to quickly crack any of them, given enough time an attacker could still possibly compromise a few of these accounts. Statistically speaking, at least a few of these hashes were likely the result of a user that picked an easy-to-guess base password. These accounts are high-value targets, so the motivation is definitely there for someone to spend the necessary hash cracking time.

 

Upon me explaining the situation, the employee who initially answered my phone call immediately transferred me to Vision’s lead internal counsel. That’s fairly impressive. Usually, I have to work my way through a few intermediate people before being passed to lead counsel of any company. It’s good to see that Vision takes the issue of data breaches very seriously and has apparently trained its staff to act accordingly.

 

Once I explained the nature of the exposed database to this attorney, he quickly pulled Vision’s CTO, Doug Woodard, into the room and had me repeat what I just told him. They were baffled as to how this could happen but both immediately understood the potential seriousness of the situation. Doug, who would become my main contact at Vision, stepped out of the conversation shortly thereafter so that he could make some very urgent calls to figure out what was going on with this MongoDB instance.

 

Then came the awkward part. I continued, over the phone, to inform Vision’s internal counsel that I had actually downloaded a copy of the publicly exposed database. I say this was awkward because, for the first time in all my research efforts, it felt like someone thought I was trying to proposition an extortion scheme. I very quickly clarified that my intentions are completely noble and I am not in any way trying to extort or blackmail anyone. I think we were both relieved when that was made clear.

 

Our phone call ended with us exchanging contact information for future updates as Vision investigates the situation. After hanging up, I did a quick check to see if the database was still exposed — it was not. Doug’s calls must have rattled some cages and quick action was taken to secure the data.

 

In the time since that initial phone call, I have spoken with and emailed Doug several times. Most recently these conversations have included an outside attorney, Tanya Forsheit, that Vision hired to represent them in the matter.

 

Tanya has very impressive credentials in the world of data breach law, which makes her initial email to me somewhat surprising. It stated, in part:

 

“As we are investigating, I trust you won't make any public statements until we know more, and that you won't use any of the information that you improperly downloaded.” [emphasis added]

 

Here’s the gist of my email response back to her:

 

I fully understand the duty you have to zealously represent the interests of your client. However, I would prefer that we be very careful regarding accusations of improper access. The bottom line is that, until my notification to Vision Media, this database was being published openly to the public internet through Amazon Web Services.

 

I know that Doug Woodard, CTO of Vision Media, has said there may have been a fault in Amazon's hosting platform. I find this scenario unlikely and I think you'll see that Amazon is fairly resistant to any suggestion of problems with their infrastructure.

 

The most likely explanation is that someone working for, or at, Vision Media made a mistake. It happens. But let's not shoot the messenger here. I like to think of myself as a fairly jovial, lighthearted person and I'm hoping that you and I can get along. That will be difficult if there are continued accusations of improper activity on my part.

 

I have cooperated with and contributed to data breach-related investigations conducted by the FTC, FBI, US Navy, HHS/OCR, US Secret Service, and other similar entities. Not a single regulatory or government agency I have interacted with has even suggested that what I do, downloading publicly published information, is improper.

 

After those initial tensions, all of my communications with Tanya and Doug have been very good, polite, and welcome. While I have not completely bought into Vision Media Management’s explanations of how this data breach occurred (or their claims that the database contains a majority of harmless test data), it has at least not been an unpleasant experience speaking with them.

 

If they had not been so kind to me, or if they had tried to label me some kind of evil hacker, I might not have been inclined to send them a second breach notification report this past weekend:

 

Hey again,

 

Sorry to be the bearer of (more) bad news, but it appears there are at least a few more, fairly important, holes for Vision to plug. I did a little digging into the "test data", just to verify what you have been saying, and it has led me to more completely exposed data that gives an even greater understanding into how Vision Media's system works.

 

Specifically, I ran across the publicly exposed S3 buckets located at "http://mpaa.visionmm.resources.s3.amazonaws.com" and "http://travis.visionmm.resources.s3.amazonaws.com".

 

These documents, that are currently exposed to anyone with an internet connection, shed light on the interplay between Vision/Deluxe Media, Kaltura, Netflix, and other players.

 

I'm fairly certain this reaches beyond the implications of harmless junk data. I'm also certain that people with actual malicious intent could cause harm if they came across all of this data and set about some time to reverse engineer the authentication measures. There are implications far beyond salted hashes here (Kaltura "ks IDs" might ring a bell for Doug).

 

[…]

 

At this time, I’m still waiting to hear back from Vision regarding the content of those S3 buckets (which included quite a bit of internal development documentation) as well as anything else that they may have found exposed while responding to this second notification.

 

I’ll most likely be writing an update to this post once more is known. For now, take a gander at the screenshots above this post, head over to TorrentFreak.com for additional coverage, and watch this blog for more info.

Trump website leak

The problem was that, if you asked real nicely, Trump’s asset repository was willing to hand out insider data. His team had bungled the settings on their Amazon S3 server, located at http://assets.donaldjtrump.com.s3.amazonaws.com.

 

After discovering this asset server’s existence, and my URL fuzzer being met with code 301 redirects instead of code 403 denials, I started digging. Because directory listing was disabled, there was no easy way to enumerate folder names within the asset bucket. I was running through a small dictionary of common folder names when I got a hit on a folder named “resumes”.

 

But this was still one step away from being a true leak. I needed more than just a folder name. I needed an actual downloadable file, and, due to the server being unwilling to provide a straightforward list of directory contents, I would need to correctly guess the name of a document before any successful download could take place.

 

Being the bright, young lad that I am, it occurred to me that there could be a few different naming schemes for files within a résumé directory. If an organized human was moving files into this directory, then perhaps the files would be named something like FirstnameLastname.pdf or Lastname,Firstname.docx. But guessing applicant names would be a complicated and rather tricky way to look for files.

 

I decided to cross my fingers and hope that whoever designed this system was using an automated script to move files into the résumé directory. So, what kind of name would an automated script assign? Well, probably something similar to “resume_1.pdf”.

 

With a head full of optimism, I quickly pointed my browser to http://assets.donaldjtrump.com.s3.amazonaws.com/resumes/resume_1.pdf.

 

Bingo! I was met with a download dialogue window. The file contained a glut of personal details, work/education history, and references for a young person hoping to become an intern with the Trump campaign.

 

I didn’t spend too much time looking for additional résumés. Some basic filename fuzzing readily turned up 24 of them with names ranging from “resume2.docx” to “resume_9.pdf” and even “resumeDT.pdf”. Several redacted samples are pictured above this post.

 

Having confirmed my suspicions, and definitively proving that a leak of personally identifiable information existed, the next step had to be notifying the appropriate people in order to secure the data and fix the leak. That was the only ethical thing to do, even if it meant that I wouldn’t have much time to fully explore the rabbit hole.

 

Knowing that Trump’s team is active on Twitter, I decided to ping them on that platform via my rarely-used Twitter account, @VickerySec. There was no response, so I decided to reach out to a trusted journalist friend that has helped me secure data breaches on several occasions. She is known by the moniker “Dissent” and is the administrator of Databreaches.net (a site I highly recommend).

 

Dissent (aka @PogoWasRight on Twitter) was able to contact the right people and get word of the leak to Trump’s staff. From there, it didn’t take long for the proper server permissions to be applied. Check out her investigation here: https://www.databreaches.net/trumps-campaign-mute-about-data-security-fail/

 

Ultimately this was an entirely avoidable mistake on the part of Trump’s tech staff. We’ll probably never know how bad the exposure really was or what other files I could have found. I have zero confidence that the campaign will be honest about that in whatever response they put out publicly (that’s if they do actually acknowledge the situation).

 

Let’s just hope that Donald’s team learned a good lesson here, and, if he is elected, that they are capable of guarding national assets better than their website’s assets.

EMR4All data breach: 30 breaches in one

A company known as EMR4All is responsible for placing these files in an open Amazon S3 repository (known as a bucket). This bucket was located at http://emr57.s3.amazonaws.com as recently as two weeks ago.

 

Tech-savvy readers will know that Amazon S3 buckets tend to include the “s3.amazonaws.com” part of that URL by default. That means, in order to find these files, all you had to do was guess the phrase “emr57”.

 

So, how did I find it? Well, after noticing a separate, properly-secured, company using the Electronic Medical Record acronym (EMR) in their S3 bucket title, I theorized that it might be worth checking to see if any unsecured emr-titled buckets existed.

 

Using a simple URL fuzzing program, I began looking for publicly exposed repositories beginning with “emr”. It took milliseconds to hit on the phrase “emr57”. Literally. Milliseconds.

 

In one of the images above this post, you’ll see a full listing of directories that were displayed to me without so much as a username or password being requested. You’ll also see an image containing a collage of medical practice logos found within the S3 bucket.

 

The folder that immediately grabbed my attention is the one titled EMR4allMaster. Past experience has shown that when you find a vast array of seemingly private data exposed, anything marked with the word “master” is worth investigating in order to identify the overall responsible party.

 

Googling the phrase “EMR4all” pointed me in the right direction, but unfortunately, the company’s homepage did not have any readily identifiable contact information. It was just a login portal for their clients with no contact phone number or email address to be seen.

 

If there’s one piece of advice I could impart to all holders of healthcare data, it’s this: Make sure you prominently display some method of contact on your homepage. When someone notices you are leaking data, you want that person to be able to contact you directly. Things get exponentially more complicated with each additional person that has to be contacted before the breach is secured.

 

Fortunately for me, I have a good working relationship with the administrator of databreaches.net (she goes by the name Dissent). After I could not quickly contact someone at EMR4All, she became instrumental in getting the breach secured. Dissent has high-level insurance industry contacts. One of them was able to get Amazon’s attention, who, in turn, notified EMR4All of the security issue. You can read Dissent’s side of the story here: https://www.databreaches.net/dozens-of-clinics-thousands-of-patients-impacted-by-third-party-data-leak/

 

You may now be wondering what EMR4All has to say about the whole situation. They were kind enough to contact me with the following statement:

 

EMR4all, a service provider of Rehab Billing Solutions, was notified by its vendor, Amazon Web Services, on Sunday, September 11th that its “S3” storage account containing practice information of the customers of our companies, including patient information, was vulnerable because it was accessible to persons outside of our organization. We were also informed that a data researcher discovered the vulnerability.

 

We took immediate steps to investigate and determine the source and extent of any access of practice information and the kind of information that might have been accessed. We can report that the vulnerability has been identified and closed, and updated access controls are now in place to secure the S3 account.

 

We have also notified all our customers and former customers of this unfortunate situation involving our Amazon Web Service S3 account and are working with them to provide information to their patients. Over the last few months, we have been in the process of moving our customers to new platforms as we were phasing out the company’s operations. We have always taken our customers’ information security very seriously, and we deeply regret any inconvenience this may have caused. We continue to monitor the situation closely, and work with our customers on transitioning practice data and following up with further notifications and appropriate steps. As required, we will inform proper authorities to ensure that this situation is resolved.

 

Follow-up questions from Dissent also revealed that, according to the company, no more than 30,000 total patients could have been affected by this breach (and it is likely a subset of that total). It’s difficult for me to verify this number due to the heterogeneous nature of the .txt and .edi transmittal files included in the data dump. I can’t even show you a screenshot of those files because they would have to be completely blacked out. They are simply massive chunks of private medical data strings. What a mess.

 

Ultimately I’m left with one overriding question here-- Why did nobody involved with EMR4All ask me if I downloaded the data? The answer is yes, as I nearly always do… (and it will soon be purged) But, seriously, why didn’t anyone bother to ask? That’s usually one of the first questions I get.

2.9 Million Louisiana voters’ data leaked online

Most people believe that voting is a fundamental right of any democracy. In the United States, an anonymous vote is considered your “right” and it is a cornerstone of the U.S. democratic process. This week researchers from the MacKeeper Security Research Center discovered an open and publically available database that contained detailed information on every voters in the state of Louisiana.

 

The voter database was named 'lavoter' was hosted on Google Cloud IP and contained 2,919,651 records for the entire state of Louisiana.

 

The information included the following categories (among other): Names, Full Address (incl. mail address), Sex, Race, Political Party Code, Voter Status, Registration Date, Registration Number, Personal Phone No., Last Voted data and Voting History data.

 

Exactly as specified at Louisiana’s Secretary of State website: http://www.sos.la.gov/electionsandvoting/publisheddocuments/recordformatsheet.pdf

 

Another database hosted on the same ip was named ‘ladps’ and contained 6,978,508 records. We can only guess that it attributes to ‘Department of Public Safety”, since the following categories were presented in database:  Full Name, Residence Address, Race, Sex, DOB, Height, Weight, Residence Parish code, Driving License Number, SSN code (but not the SSN itself), and issue number.

 

That database also contained information on deceased people. The total count of records in that one leads us to believe that it corresponds to the demographics of Louisiana.

 

When the MacKeeper Security Research Center was searching for the legal requirements for protecting voter data in the state of Louisiana we were shocked to discover that all voter data is for sale to basically anyone willing to pay for it. You do not even need to prove that you will use it for political purposes, research or any related election purpose. Louisiana’s system gives you the option of choosing past or present voters and you separate by various demographics (gender, race etc.), specify the party of your choice. The price for buying voter data comes out at $0.01 per name on the list.

 

http://www.sos.la.gov/ElectionsAndVoting/BecomeACandidate/PurchaseVoterLists/Pages/default.aspx

 

The current US election has shown us more than any other just how much technology has become a part of the process. The negative side of that is there is no common standard of security and data protection of election and voter data. The election rules and voter data varies from state to state and voter data may not even be considered private depending on where you live. The FBI has recently investigated the possibility of Russian hackers trying to influence the US election and in Dec 2015 MacKeeper’s Chris Vickery identified 191 million voter records that were exposed because of a misconfiguration in a CouchDB installation. In July 2016 WikiLeaks released 19,252 emails and 8,034 attachments from the top of the US Democratic National Committee and many experts expect more information will be released before the election. The real question is why are Americans so worried about Russian hackers and protecting voter’s personal data when some states will just sell it?

 

Voter data and election should be considered "critical infrastructure" and not sold off to the highest bidder or wholesale prices. Citizens should at a minimum have the right to “Opt Out” of having their data sold if they live in a state that sells voter information.

 

It is unclear if the database discovered by the MacKeeper Security Research Center belonged to the State of Louisiana, a political organization, or who? The files include driver’s license numbers so this would make us assume that only the state would have that sensitive information and those would be likely be removed from any sold lists. Regardless of who is responsible for the database it was publically available and exposing the data of 2.9 million voters.

 

The database has since been secured. It is unknown, how many people got access to it and who was the owner.

Dating site database leak for “Cheaters” with 1.5 million user accounts

Database appeared to be part of C&Z Tech Limited, a New Zealand registered company that operates a number of dating websites and a mobile application "Hook Up Dating". These dating sites target men and women "who are either attached/married seeking something fun on the side, or single seeking something casual".

 

The case of a “cheating” website brings back memories of the strange case of Ashley Madison. According to Forbes “Worldwide, the site has had 31 million total users over its lifetime, 6.8 million of whom logged in over the previous 90 days as of late November”. Unlike the Ashley Madison data that was actually hacked, this database was left open, unsecured and accessible to anyone. The fallout from the Ashley Madison hack destroyed marriages, families, and was even suspected in several suicides. Knowing the real danger of this data being leaked there is an added need for data protection and security.  

 

The exposed database contained more than 1.5 million users’ data, including usernames and passwords in plain text among the others (height, weight, DOB, gender, gay body type, race, IP, country etc) was left unattended for almost a day before it was secured.

 

Shortly after we sent notification to the company support we received the following message from "Edward" from HAF team.

 

“Thanks for letting us know, the MongoDB database was only live for a few hours as we were testing migrating data from SQL to MongoDB, so most of them were just dummy data with randomly generated emails and passwords, and not our live database, we shut down the database about an hour ago, and there're no data breach, only you guys had detected it.

 

Once again thanks for letting us know and we will make sure to secure it before making it live again.”

 

This type of answer is rather usual to claim that this is testing environment with so many files and accounts. We highly doubt this was “testing” data based on the type of files exposed and the massive number of accounts. Yes, our security research team still has a copy of the data for verification purposes.

 

The database is now secured but it raises a different question. How long should sensitive data be exposed and unsecured before it is called a data leak?

 

In line with what some US courts have said, a breach occurs the very moment that data is put in a publicly accessible place. So if it was available to the public for even one second, then it's a breach.

 

Leaked data is leaked data and it puts users at risk. If our security research team was able to discover and obtain this information, anyone else could have also. If a “bad actor” or criminal was to get this information they could try and blackmail individual users with threats to expose their infidelity and other forms of extortion.  

Real case: law firms unknowingly publishing online their internal file repositories

Please note:  if you represent either side in the case of Oppenheimer v. La Habra, you should probably not read past this point.

 

Can you imagine what would happen if a law firm inadvertently published its collection of electronic client files to the public internet? I can’t find any examples of this happening… until now.

 

My investigation into the remote synchronization protocol (“rsync”) has uncovered several law firms that were, perhaps unknowingly, publishing their internal file repositories to the world. Anyone with an internet connection could have downloaded these files, as they were being hosted on public IP addresses with no username or password protection. There is absolutely no form of hacking involved whatsoever here.

 

Client files are the crown jewels of a law firm and supposed to be kept under lock and key, which makes these internet-accessible discoveries even more surprising.

 

Publishing your own internal files through the public internet, via rsync protocol may be foolish, but it is not my job to ascertain the motives of law firms that, for whatever reason, wish to cause their own data breaches. Furthermore, according to the California Bar Association’s ethics hotline, there is nothing that a law firm can do to remove these documents from my possession.

 

I had every intention of simply writing a small post about the situation and deleting the whole 500+ gigabytes of gathered legal data. But then I saw something that I can’t unsee.

 

It involves a jail cell death video that is present in these files. On January 2nd, 2015, Daniel Oppenheimer hanged himself while in a holding cell at the La Habra city jail. Oppenheimer’s daughter is now suing for wrongful death. The District Attorney’s investigation concluded that there was no wrongdoing on the part of jail staff and that Mr. Oppenheimer’s own decision to take his life was the sole factor leading to his death.

 

I found evidence to the contrary. Within the client files for the Law Firm of Ferguson, Praet & Sherman, there is a text file titled “attorney notes WORK PRODUCT”. The content of that file is a timeline of events from Oppenheimer’s death video. Most of the noted events correspond with the timeline that is present in the District Attorney’s official report.

 

However, there are notable exceptions. Twice, while Daniel Oppenheimer strangles to death, La Habra jail staff members walk past his cell and do nothing to stop it. In the video you can clearly see their reflections in the plexiglass as they walk by. The first pass is nearly six minutes before anyone radios for help.

 

This “attorney notes WORK PRODUCT” file shows that an attorney with Ferguson, Praet & Sherman noticed these reflections in the video. It indicates that someone at Ferguson, Praet & Sherman knows that the District Attorney’s report is missing these key timeline entries.

 

It would certainly be awkward for the City’s defense attorneys to point out deficiencies in the DA’s report. But it’s the right thing to do. And for all I know, someone at Ferguson, Praet & Sherman may have indeed pointed this out to the appropriate channels, but I have seen no evidence of that.

 

I cannot sit idly by and do nothing in this situation. I cannot simply delete these files. My conscience will not allow it. If someone must face scrutiny in order for this truth to get out, then let it be me. It is a burden I will gladly bear in order to see that potential manslaughter does not get swept under the rug.

 

Daniel Oppenheimer may not have been a great person. He was an admitted meth user and had a long history of run-ins with the law. But when a staff member at the La Habra City jail had a duty to act, this video shows that they did not.

 

I am calling on the Orange County District Attorney to take another look at this death video and act appropriately against the individuals that walked past and did nothing while a man, in their care, strangled to death.

Multi-state voter lata Leak

This week the MacKeeper Security Research Center discovered a publically available database of voter records totaling more than 350K. The records are from multiple states and split among MT / NJ / CA / VA.

 

California voter_file = 60,744 records
 

MT voter_file = 50,000 records
 

NJ voter_file = 72,114 records
 

VA voter_file = 62,574 records (with party ID, WardCode, VANID)
 

VA voter_file = 61,995 records
 

VA voter_file = 46,625 records
 

354,052 records in total!

 

The personal information includes names, home address, phone number, gender, date of birth, state voter ID, race, marital status, unique voter ID, date of voter registration, phone number, political affiliation and whether or not they voted in primary elections and more.

 

Here is the redacted excerpt from one file:

 

"vf_g2000" : "",

 "vf_g2001" : "",

 "vf_g2002" : "",

 "vf_g2003" : "",

 "vf_g2004" : "",

 "vf_g2005" : "",

 "vf_g2006" : "",

 "tsmart_first_name" : "REDACTED",

 "vf_g2008" : "Y",

 "vf_g2009" : "",

 "vf_p2001" : "",

 "vf_p2000" : "",

 "vf_p2007" : "",

 "vf_p2009" : "",

 "vf_p2005" : "",

 "vf_p2004" : "",

 "vf_registration_date" : "REDACTED",

 "vf_p2007_party" : "",

 "tsmart_city" : "REDACTED",

 "tsmart_township" : "",

 "DistanceInCluster" : 1,

 "vf_g2007" : "",

 "tsmart_last_name" : "REDACTED",

 "vf_p2004_party" : "",

 "vf_p2003" : "",

 "vf_p2002" : "",

 "vf_m2001" : "",

 "tsmart_DMA_Name" : "Norfolk-Portsmouth-Newport News VA",

 "vf_g2012" : "",

 "vf_g2011" : "",

 "vf_g2010" : "Y",

 "tsmart_zip4" : "REDACTED",

 "voterbase_id_original" : "VA-REDACTED",

 "voterbase_phone" : "REDACTED",

 "voterbase_marital_status" : "Married",

 "vf_p2006" : "",

 "tsmart_zip" : "REDACTED",

 "vf_p2011_party" : "",

 "calculated_gender" : "f",

 "vf_p2009_party" : "",

 "combined_strata" : "Age 18-39EastAfrican-AmericanFemale",

 "tsmart_middle_name" : "REDACTED",

 "vf_pp2012" : "",

 "vf_p2010_party" : "",

 "voterbase_gender" : "Female",

 "voterbase_dob" : "REDACTED",

 "race_strata" : "African-American",

 "vf_pp2012_party" : "",

 "vf_pp2008" : "",

 "vf_p2002_party" : "",

 "vf_pp2000" : "",

 "vf_pp2004" : "",

 "tsmart_state" : "VA",

 "vf_pav" : "",

 "age_strata" : "Age 18-39",

 "vf_p2012_party" : "",

 "cluster_quota" : 15,

 "vf_p2003_party" : "",

 "tsmart_HD" : "78",

 "gender_strata" : "Female",

 "voterbase_race" : "African-American",

 "tsmart_ward" : "",

 "tsmart_county_code" : "REDACTED",

 "tsmart_SD" : "5",

 "vf_pp2004_party" : "",

 "vf_p2006_party" : "",

 "region" : "East",

 "voterbase_age" : "24",

 "tsmart_CD" : "4",

 "vf_m2002" : "",

 "vf_m2003" : "",

 "vf_m2000" : "",

 "voterbase_id" : "REDACTED",

 "vf_m2006" : "",

 "vf_m2007" : "",

 "vf_m2004" : "",

 "vf_m2005" : "",

 "phone_strata" : "Landline",

 "tsmart_municipal_district" : "",

 "vf_m2009" : "",

 "voterbase_phone_type" : "Landline",

"tsmart_place_name" : "REDACTED",

 "vf_p2000_party" : "",

 "cluster_number" : "1",

"Phone" : "REDACTED",

 "vf_voter_status" : "Active",

 "tsmart_precinct_name" : "REDACTED",

 "vf_m2011" : "",

 "vf_m2010" : "",

"voterbase_registration_status" : "Registered",

 "tsmart_county_council" : "",

 "tsmart_county_name" : "REDACTED",

 "vf_m2008" : "",

 "tsmart_name_suffix" : "",

 "tsmart_school_district" : "",

 "tsmart_full_address" : REDACTED",

 "vf_pp2000_party" : "",

 "vf_party" : "Unaffiliated",

 "vf_p2008" : "",

 "vf_voterfile_id" : "REDACTED”,

 "vf_m2012" : "",

 "ClusterId" : "1",

 "tsmart_judicial_district" : "",

 "vf_absentee_status" : "",

 "vf_p2010" : "",

 "vf_p2011" : "",

 "vf_p2012" : "",

 "calculated_birthyear" : "REDACTED",

 "tsmart_city_council" : "",

 "tsmart_precinct_id" : "REDACTED",

 "vf_p2001_party" : "",

 "vf_early_voter_status" : "",

 "vf_p2008_party" : "",

 "vf_p2005_party" : "",

 "vf_pp2008_party" : ""

 

Some states restrict how the data may be used and set restrictions for commercial or charity. Most states require that voter data be used only for political and election-related activities, but what if the records are leaked publically and are available to anyone online?

 

The challenge going forward will be how to secure voter records that are likely already compromised or in some cases for sale by the state election commissions. In September 2015 MacKeeper discovered 2.9 million voter records from the state of Louisiana and discovered a disturbing reality that the state was selling voter records. Louisiana’s system gives you the option of choosing past or present voters and you separate by various demographics (gender, race etc.), specify the party of your choice. The price for buying voter data comes out at $0.01 per name on the list. How or will states and private groups protect voter data or will voter data just become public record similar to court records?

 

NOTE TO MEDIA

 

We were not able to identify the owner of this database and seek help from the media or security community to help get the database closed.

Habitat for humanity breach

Habitat for Humanity is a large, international charity that builds and provides low-income housing. Ex-president Jimmy Carter is a vocal supporter of the organization. They do good things and help a lot of people. That is why is pains me to report on the poor data breach incident response of their Michigan branch.

 

The silence on Habitat’s side may be somewhat related to the fact that their Colorado branch recently announced an actual hack, rather than a simple exposure of data, that has been crippling operations. Having to announce a second, separate, breach within a month is probably not on the top of Habitat’s wish list. But it’s the right thing to do.

 

Here are the technical details — Habitat for Humanity of Michigan is a client of a web hosting provider named Providence, which in turn gets service from an ISP named ACD. All of these companies are based in Michigan. During the course of my research, I discovered a publicly exposed remote synchronization (rsync) service that was operating on an ACD IP address.

 

Most of the files available from this rsync service were encrypted with ShadowProtect backup software. However, there was a notable exception: The Habitat for Humanity of Michigan files. It appears that either someone simply forgot to encrypt them, or whoever does IT for Humanity chose not to take advantage of the encryption, or perhaps the files were scheduled for encryption but it had not yet taken place.

 

Whatever the case, I soon had over 400 gigabytes of virtual hard drive data stemming from Habitat for Humanity of Michigan.

 

Looking through 400 gigs in order to see if personal information had been exposed can be a little challenging. I soon found a directory with over 700 folders containing PDF background and credit check reports. You can imagine how sensitive these reports are. They contain everything a malicious actor would need for identity theft. I also quickly found a SQL database backup file with a bevy of information, including over 4,600 peoples’ social security numbers, names, addresses, phone numbers, etc.

 

It was after normal business hours on October 9th when I confirmed that sensitive information was indeed exposed by this hosting breach. Fortunately, ACD (the ISP involved) has a 24-hour hotline for technical issues. I called and spoke with a young man who said he would look into the situation. When I checked on it the following day, the rsync service was no longer accepting public connections.

 

A few days later I followed up with Habitat to make sure that ACD had notified them of the issue. Later investigation, conducted by Dell Cameron of The Daily Dot (https://www.dailydot.com/debug/habitat-for-humanity-applicants-michigan-data-breach/) revealed that ACD had in fact contacted Providence, who appear to be the main hosting provider for Habitat’s Michigan branch.

 

As far as I can tell, Providence did not inform Habitat. Although it would be nice if Habitat could confirm that for me.

 

Whatever the case, Providence provided Dell Cameron with a little background: “I will tell you that the way that it was presented to us made it sound like [Vickery] may have been a hacker and that it may have been a phishing scam.”

 

That is interesting because, even if I was some sort of malicious hacker, they still should have informed Habitat that there had been a data breach. I’m not sure how phishing could have fit into the mix. At this point I already had the data. There’s no point in phishing for credentials or other information if the data is already publicly exposed and has been handed out.

 

Overall, the incident seems to have been handled very badly by three separate parties. If the information I have gathered is correct, then ACD should not have represented to Providence that some sort of “hacking” occurred, Providence should have at least requested my information from ACD (which I had provided) in order to look into the issue, and Habitat for Humanity of Michigan should have at least responded to my data breach notifications.

 

This all goes to show that the current state of data breach response is not good. Very few companies will own up to making mistakes, very few will accurately communicate information surrounding the event, and even fewer will follow through with a well-planned incident response plan. Most will do everything possible to avoid notifying the affected clients or “victims”.

 

I will continue working to improve this sad state of affairs.

Car dealership provider DealerBuilt leaky CRM

However, in the digital age, there is one more thing you should consider and that is: did the dealership leak my personal data and credit information online? With the latest discovery of nearly a million records leaked online both automotive dealership employees and customers alike have had their private data left vulnerable to criminals. We must now face the reality that no matter what industry you work in or what products you buy there is a strong chance that your sensitive personal data could be leaked online if it is not secured properly.  

 

What DealerBuilt CRM database contains?

It appears that the database containing the information belongs to dealerbuilt.com, a dealer management and payroll system. On their website, they claim that “DealerBuilt’s Payroll Application offers a comprehensive solution to manage your payroll needs”. They also offer customizable reporting tools that help dealerships historically document and review payroll and other vital employee information. Despite managing the private and sensitive data of over a million customers and salespeople there is no mention of how DealerBuilt handles security or data protection of all of these records.

 

Here is the public report still visible at Shodan: https://www.shodan.io/host/199.102.214.20#873

 

This discovery immediately attracted our attention, since this particular instance featured 128 folders named after clients. All of them were password-protected, except one, the most vulnerable were - “DealerBuilt”, with “Clients’ backup”. It appeared that this folder contained all their clients’ CRM SQL database backups. When restored and mounted, these databases were an infinite source of private data.

 

Upon further analysis of the content we came to the conclusion that the data formatted across the tables are almost exactly the same because the company hosting them (DealerBuilt) is giving all of their car dealership customers the same CRM software.

DealerBuilt CRM database

Just to give you an example: there were several folders containing the private and personal information of over a thousands customers and employees. These files include names like “faemployee" and "lycustomer". In just one document called "lycustomer" there are 27,703 people. Some of the files have social security numbers and even spouse social security numbers. The “faemployee” table contained from 60 to 300 rows of information. Multiplied by 128, you can guess or estimate the total number of individuals who have had their personal data exposed.

DealerBuilt CRM database

When employment data is leaked that contains social security numbers it makes it a higher risk for criminals to engage in identity theft, filing false tax returns or other forms of fraud. This same risk likely applies to the many thousands of customers who have purchased vehicles or possibility even applied for financing with every dealership that uses the DealerBuilt platform.

 

This massive leak is just another painful lesson of what happens when private and sensitive data is stored without encryption or modern data security practices. The dealerbuilt.com database is now secured and it is unclear how many other people may have accessed the data or what steps DealerBuilt will take to notify the millions of affected customers and salespeople.

Pet Retailer FuturePets still leaks credit card data of 110K+ customers

Recently, we have found that Futurepets.com, a US online pet store, has leaked details of more than 110,000 credit cards, which were used to shop on the website.

 

Moreover, we discovered that the Rsync protocol was set to stream data without any password protection. It means that anyone with an Internet connection and an Rsync client could have downloaded the data belonging to more than 190,000 customers. This data included checkout information, shipping addresses, emails, names, phones, and credit card details such as 16-digit numbers, expiration date, cardholder names, etc. There was no CVV code listed "as is", but some fields contained it, apparently by mistake...

Pet Retailer FuturePets database

Futurepets.com claims to be the specialty pet retailer offering services and solutions for the lifetime needs of pets.

billing

Apparently, the problem is in the way and how the website collects and stores personal data of its customers. Our researcher made a test order and we realized that the website doesn’t use any login and password for user data backups. The amount of information that the website asked us to provide during the checkout, made us in the security community feel uneasy.

 

The total number of exposed credit and debit cards listed in the database is 110,429, and what is more disturbing, this list has been collecting the customer's card data since 2002. Some of the credit cards have already expired but those that were added between 2015 and 2016 are still active and in some cases, the CVV numbers of the credit cards are also listed.

FuturePets credit cards exposed

When our researchers came across the database we immediately notified the owners of Futurepets.com regarding the misconfigured database, but as of this publication, we have not received any response. Hopefully, someone related to Futurepets.com will reply and secure the database. If this data were to fall into the wrong hands and be used for fraud, the folks of Futurepets.com may face reputational damage and possible regulatory actions.

 

According to Payment Card Industry Data Security Standard (PCI DSS), retailers do face serious potential consequences for non-compliance with standard security protocols in their daily operations. In addition, sensitive authentication data such as CVC, CVV, and CVV2 must not be stored after authorization, even if encrypted. The PCI DSS standard was created to “increase controls around cardholder data to reduce credit card fraud via its exposure.”

pcidss requirements

How credit card data may be used? In 2014, when more than 600,000 individuals had their personal details stolen from the UK companies. The credit card details were sold for only £1 per card on the dark web, and to date, it is still unknown where exactly that data was taken from. That case remains the biggest leak of credit card details ever.

 

Our recent investigation shows that money may be taken from the credit card even without knowing a CVV code. Cardholders claim that retailers such as Amazon may charge money from their credit cards without asking for Card Verification Value (CVV). The same happens in hotels, which can charge or freeze the money on the credit card without knowing the CVV code.

 

As for the hotel, another database containing thousands of unencrypted credit card details was discovered a few months ago by the MacKeeper Security Research Center. Fortunately, the discovered DB belonging to the Silverland Hotel in Ho Chi Minh City, Vietnam, was secured within a few days, and the mistake did not result in significant damage.

Joan Jett’s BlackHeart Records data leak online

The data breach is a massive treasure trove for fans and cybercriminals alike. There are unreleased tracks, never-before-seen pictures, even rejection letters from 1980 when Joan Jett was trying to get a record deal. There are also social security numbers of label employees and band members, internal memos and scanned checks of royalty payments, and much more.

 

From the entertaining obsessed fan emails to lawsuits and arrest records of the label manager, this database is a look inside of how the record label is operated and the communication between rock and roll royalty.

 

Although there are no naked pictures or Hollywood style tabloid drama in the hundreds of gigabytes and countless thousands of files, there is a complete view of the many aspects of being a famous rockstar, operating a record label, and the meticulous documentation of every achievement, failure, or internal and external communications.

 

With the social security numbers, banking information, scans of passports, and IDs it is easy to see that cyber criminals could have exploited this data for identify theft, fraud, or extortion. The data is now secured and it is not known how long that IP was publically available.

 

One of the files that caught our attention was a folder named “Lawsuits”.

 

Buddy Miles the legendary drummer and a member of Jimi Hendrix's Band of Gypsys (1969–1970). In 2003 Miles sued Jimi Hendrix’s estate for invasion of privacy, breach of contract, unfair trade practice, and false advertising. The defendants also included Universal, EMI, Warner Bros., MCA. Miles claims he was a co-writer on many well known Hendrix hit songs, but the family denied this and claimed that Mr. Miles was a hired musician and was not entitled to any additional royalties or compensation. Buddy Miles died in 2008 and it is unclear what ever became of the lawsuit because the judge ordered a gag order and there is no public record of this case. The MacKeeper Security Research Team has seen the motions, court documents and assumes these are true and correct accounts of legal action.

 

The data was completely exposed to the public internet with no username, password, or other authentication method in place. Anyone in the entire world with an internet connection could download the data. Generally, when dealing with software, the word "vulnerable" is used to describe a system that can be, or is, exploited in some fashion. In this situation, no exploit or deception was utilized in any way.

Ameriprise data breach

Here’s what we know: The data was coming from a Network Attached Storage device insecurely configured with no username or password required for access. This specific leaky device was not on the internal Ameriprise network, as it was physically located inside an Ameriprise employee’s home. But then how did it receive and store unencrypted, internal Ameriprise data? That’s the mystery.

 

It turns out that an identical NAS device exists within this employee’s satellite Ameriprise office, and somehow the devices were synchronized with each other over the open internet. I found it through a random review of Shodan.io rsync results.

Ameriprise portfolio

Out of an abundance of caution, Ameriprise has pulled both devices and will be examining them within an internal IT lab.

 

Through journalist Zack Whittaker, of CNET/ZDNET/CBS, I’ve heard that Ameriprise is claiming the company does not supply these devices to their offices. This may be at odds with what I was told by the affected financial advisor in question. I was informed that the very reason he had one of the devices in his house was that it is the same exact model of device they use at his office.

 

Now, that doesn’t necessarily mean that Ameriprise specifically deployed or even authorized the use of that device within the advisor’s office. However, an Ameriprise employee did indicate to me that the pulling and examining of the devices was, in part, to make sure there wasn’t a bigger problem to worry about. To me, that says there is at least some concern that more of these devices may be out in Ameriprise offices. That’s not to say there’s any reason to think more may be misconfigured in the same way, but it’s at least worth looking into as a possibility.

 

When Zack Wittaker asked how Ameriprise secures NAS devices that its offices may be using, Ameriprise’s PR people replied, “We provide a secure online storage solution for this information.”

 

I find it odd, then, that within the leaked data there is a confidential Business Continuity Plan (BCP), dated Feb. 4th, 2015, in which Ameriprise asks its advisors “Do you keep your backup computer records (i.e. hard drive, memory stick, etc.) at a location other than your office?”, to which the possible answers are “Yes”, “No”, and “N/A – (select this option if you are using an online solution)”.

Ameriprise computer information

Why would that question even exist if Ameriprise only provides a secure online storage solution?

 

Additional security and compliance documentation within the leaked files make plenty of references to physically securing flash drives and external hard drives, so Ameriprise has to know that these kinds of devices do actually exist within their offices. That’s essentially what a Network Attached Storage device is – one or more external hard drives connected to a computer network, generally for the sole purpose of data storage and backups.

data storage and backups

The biggest question, that will probably never be answered, is whether or not I could have used any of the gathered credentials to gain access into Ameriprise’s internal network. Doing so would be a clear violation of the Computer Fraud and Abuse Act, which makes even attempting it off-limits to me and my research efforts.

 

One avenue that a real criminal hacker could have pursued would be cracking the password-manager backup files contained within the data trove. The financial advisor uses 1Password to manage his web credentials. This means that hashed versions of all his passwords were included. Only one “master password” would need to be cracked and then all of them would be made available in plain text. A password hint file was even included pertaining to this master password. Considering what’s in the hint file, I’m pretty sure the master password could be cracked.

 

If you’re an Ameriprise client and received a notification letter about this event, I’d love to see a copy. There are still many questions to be answered and I’m hoping the affected clients are provided a detailed and accurate account of what transpired. Ameriprise is a big name and they should set the bar high with a detailed report of how this happened.

Special ops healthcare worker breach

Potomac Healthcare Solutions provides healthcare workers to the US Government through Booz Allen Hamilton (you know, Snowden’s old employer). It is not presently known why an unprotected remote synchronization (rsync) service was active at an IP address tied to Potomac. I do know that when I called one of the company’s CEOs this past Thursday to report the exposure, he did not seem to take me seriously.

password list

At the end of our short conversation, he asked me to send an email. So, I did. After we hung up, I sent an email to Potomac’s two co-CEOs detailing the breach and included their Social Security Numbers, home addresses, dates of birth, and phone numbers. Here’s the intro:

 

Hello again Mr. Joseph,

 

You and I just spoke over the phone a couple of minutes ago. I described to you a recent publicly accessible collection of data I have discovered that appears to be internal Potomac Healthcare files. You requested that I send over an email. I have also put Mr. Burden as a recipient and attached a file that should demonstrate that this is not a hoax.

 

I am, primarily, concerned for national safety's sake as there are things like names, email addresses, phone numbers, and Social Security Numbers for people that appear to work both directly at your facilities and at US military installations.

Potomac Healthcare files

I figured that would do the trick. Much to my surprise, the unprotected file repository was still up and available an hour later. It shouldn’t take over an hour to contact your IT guy and kill an rsync daemon.

 

That last point is especially true when your publicly exposed files contain, in addition to healthcare workers, the names and locations of at least two Special Forces data analysts with Top Secret government clearance.

government clearance

I decided to, basically, call Potomac’s boss. I’ve made a few contacts at various government agencies, some more helpful than others, most not wanting their names or departments to be mentioned… ever. So, I went through my email archives and found the appropriate phone number.

 

Potomac’s files went offline about 30 minutes later. I may never know for sure if that second phone call had anything to do with the documents finally being secured, but I’d like to think it might have helped.

 

It’s not hard to imagine a Hollywood plotline in which a situation like this results in someone being kidnapped or blackmailed for information. Let’s hope that I was the only outsider to come across this gem. Let’s really hope that no hostile entities found it. Loose backups sink ships.

Explosive lata Leakage of Allied-Horizontal files

High-quality scans of explosives handling licenses were also found in the files, which raises the possibility of impersonating authorized explosives handling personnel. Most of the time data breaches are limited to fraud as far as potential damage goes. The knowledge and credentials contained in this one could have been used to cause some real damage.


The company ultimately responsible for the present leak, Allied-Horizontal, runs a wirelining outfit. Part of this business is known as “perforation” (the process of putting explosives in the ground and strategically blowing them up). Companies that handle such explosives are tightly regulated by the Bureau of Alcohol, Tobacco and Firearms (ATF).


This repository, which was exposed to the public internet without any authentication, is another recent example of Network-Attached-Storage devices gone awry via the remote synchronization service (rsync). One particular brand of NAS devices, which starts with a “B”, appears to be especially prone to this misconfiguration (more on that in a future post).


After downloading over 7 gigs of internal Allied-Horizontal files, which represents only a small fraction of the overall exposure, I became convinced the data was legitimate and the leak should be plugged quickly.

In my early days of breach reporting, I would start by notifying employees at the bottom and working my way up, but I’ve recently become brasher in my approach. Now I start the notification process with the most senior executive and work my way down. Things happen much faster that way.


One of the files I downloaded was a spreadsheet containing the names, titles, and personal cell phone numbers of, what appeared to be, all employees at the company.

So, I looked up the Allied-Horizontal CEO’s cell phone number and gave him a call this past Monday (Nov. 28th). After I explained a few things, he understood the potential seriousness of the situation. I asked if there was an IT department I could contact and he offered to immediately pass my phone number to them. A few minutes later the IT department gave me a ring. The leaky server was secured nearly as quickly as I could hand over the IP address. They wasted no time.


Their IT department also gets bonus points for not suggesting that I somehow “hacked” them. They were actually very grateful for the heads-up and couldn’t have been nicer to me. It’s refreshing when that happens.


The moral of this story is that companies should be regularly hitting their important IP addresses with tools like nmap and masscan (or even looking themselves up on Shodan.io or Zoomeye.org). Heck, throw Censys.io into the mix while you’re at it. Keeping an eye on all potential exposure points is a tough task. It’s unfortunate that most companies either can’t afford dedicated network security staffers, or the C-level executives don’t understand the immense impact of a data breach scenario.

Incident response at Sheet Metal Workers Union

For example, let’s look at the Sheet Metal Workers Union. In early October, I found a database backup belonging to their Northern California branch which contained over 24,900 members’ names, social security numbers, phone numbers, addresses, ethnicity, beneficiaries, etc., etc. Basically, if I was an identity thief, I would never need another list of victims, and they left it completely exposed to the public internet through a passwordless rsync server.


In addition to that database backup file, there were PDF union member files named in the following fashion: “Last Name, First Name, Social Security Number.pdf”. Can you believe someone thought that would be a good idea?


So, on October 10th I left a voicemail with the Northern California branch’s main office explaining the security blunder. The database and other files were secured sometime shortly thereafter (within a day or two). However, I haven’t heard anything in response from the Sheet Metal Workers Local 104. They have my name and phone number. They know that my message was accurate. Shouldn’t they have some questions for me? Perhaps so that when they (hopefully) let their members know of the security failure, the union can at least be fully informed of every relevant detail. That seems like the reasonable thing to do.

Now, let’s look at a slightly more complex example:  Did you know that State Farm recently had a fairly serious data breach incident? Around 3,000 extremely detailed client files were leaking out onto the open internet. It’s true, but technically the leak stemmed from one of State Farm’s Pennsylvania law firms, Goldberg Miller & Rubin, rather than directly from State Farm. There should be a redacted screenshot above this post illustrating the very personal nature of these files.

I spoke with Goldberg Miller & Rubin in mid-October, and the data was secured within a few hours, but I don’t know for sure if the law firm ever told State Farm about the situation. This, as I recently learned, could lead to some hefty consequences. State Farm is more than just an insurance company. They actually run a bank these days. That binds State Farm to the high standards of security that a financial institution must follow. These standards are heavily regulated and can be viciously enforced.


What I’m trying to say is this- “Hey State Farm, did Goldberg Miller & Rubin tell you about the leak? Feel free to get in touch with me if you’d like to know more about the situation.”


I feel like ending on a high note, so let’s move on to a much better example of incident response involving US Military related data:  A retired colonel, named John Warden, runs a consultancy business called Venturist Inc. This company provides “strategic planning and execution training for management and leadership teams.” Colonel Warden is the architect behind the US Air Superiority strategy which was utilized during the first Gulf War and, from seeing the files which were exposed, it is apparent that he still provides some level of advice to the US Military.

Venturist Inc, like the previous two organizations mentioned in this post, were running an unauthenticated, publicly exposed, rsync service which was connected to an internal company file system. Screenshots, that I have redacted, showing the kind of files which could be found are included with this post (probably the last two images above, as I’m never quite positive which order they will end up displayed on this page).


Col. Warden took quick action. He had an employee call me the day following my weekend breach notification email and voicemail message. During this call, the employee and I were able to figure out which storage device was causing the problem and, as an immediate quasi-fix, she unplugged the unit from its power outlet. I confirmed to her that as soon she unplugged it, the data became unreachable on my end.


I’ll leave you with the appreciative email I received later that day from Col. John Warden himself. Keep this in mind the next time you hear about a security researcher being attacked in response to a breach notification:

 

Dear Chris,


Thank you so much for bringing this to our attention and double thanks for going to the trouble of finding emails and phone numbers.  […] without you, we would have gone blithely about our business and been feeding data to all kinds of nasty people.  If there is anything I can do for you, please let me know. Among other things, I would be delighted to send you a copy of my book Winning in FastTime. Just give us a FedEx address when you can. Again, many thanks and continued good luck with your research and reporting!


Best,

John Warden

HP printer vulnerability: how it works?

The secret is that thousands of unprotected printer hard drives are laying exposed on the Internet. That’s right, your office’s big HP printer probably has many gigs of internal storage space, and, if you don’t protect port 9100, you’re basically handing an anonymous FTP server to the hacker community.

There are a few free, open source pieces of software that can be used to upload and interact with HP printer hard drives over port 9100. After uploading to a printer, the file can be accessed by visiting http:///hp/device/ with any web browser.


This opens up a world of possibilities. A hacker can host malicious web pages and scripts on your printer and link it to potential victims. Maybe he needs to host an executable somewhere so it can later be served through a wget request. These printers are wonderful repositories. It doesn’t take much creativity to realize that even highly illegal materials could be stored this way.


After all, this kind of printer is usually powered up and online twenty-four hours a day. Even in sleep mode it will still host files. And who checks the contents of their printer’s hard drive? What are the odds of this hacker’s secret stash ever being discovered? Pretty low if you ask me.


Then you also have to consider that any organization leaving their printers exposed to the internet probably doesn’t have the greatest, if any, logging system in place. The chances of being caught are extremely low for the malicious actor.


Naturally, you may be wondering why I am highlighting this problem. Won’t it just help amateur hackers elevate their game? Disclosing vulnerabilities will always be a double-edged blade. Sure, some people will take advantage of the information, but it’s my sincere belief that anyone seeking tips on how to protect themselves should also be made aware.


So, if you’re concerned about security, put your printers are behind a firewall and, if it’s a Hewlett-Packard, make sure port 9100 isn’t open.


Discover latest security breaches at MacKeeper Security Research Center and find out stats on cyber analytics project.
 

***


Portions of these articles may be used for publication if properly referenced and credit is given to MacKeeper Security Research Center.

 

Read more guides:

arrow

Run Application

step_1

Click Continue

step_2

Click Install

step_3