Hacked Badoo Apk

[Antionette Eastin]

LeakedSource provided three chunks of data to Motherboard, each containing 10,000 records. Out of 100 accounts tested across the three samples, 54 were linked to an active account on Badoo, while 23 indicated that an account had been created, but that the user had not completed registration by clicking the confirmation link emailed to them.

Messages sent to many of the email addresses linked to accounts on Badoo did not successfully deliver. Motherboard is yet to hear back from any of the apparent victims, and we will update this article if we receive a response.

In all, the data dump apparently contains 127,343,437 records. Motherboard was unable to confirm whether the dump was indeed this large, but another source who also obtained the data reported a similar figure.

Passwords in the samples provided to Motherboard were hashed with MD5, a hashing algorithm that has long been trivial for hackers to crack. According to Leaked Source, nearly 50,000 of the passwords in the datadump were "badoo". No one Motherboard spoke to who was in possession of the dump knew exactly when the data was hacked.

"Badoo takes privacy and security extremely seriously. Badoo has not been hacked and our user records/accounts are secure. We monitor our security constantly, and take extreme measures to protect our user base. We were made aware of an alleged data breach, which upon a thorough investigation into our system, we can confirm did not take place," Badoo spokesperson Joelle Hadfield told Motherboard in an email.

That statement is near identical to another issued recently. In May, hackers claimed to have obtained over 50 million records from another dating site called Zoosk. As Motherboard and tech news site ZDNet found, that data was, however, likely not sourced from Zoosk. ZDNet approached Badoo when many of the supposed 'Zoosk' email addresses had the domain "@mobile.badoo.com."

Curiously, 28,685,533 unique email addresses in the 'Zoosk' data also appeared in the Badoo data dump, according to Leaked Source. The exact connection between the two datasets is not clear at this stage, nor if they overlap in any other ways.

The lesson: As we've seen over the past week, sometimes data breaches take years to come to light. Users can't rely on waiting for a hack to go public, or for a company to acknowledge it. With that in mind, users should be thinking proactively, and taking steps to protect all their online accounts, even if one site they use does happen to be breached. One way of doing that is with a password manager, which generates strong, unique passwords and stores them either locally or online. That way, when one site is attacked, any details leaked won't necessarily allow hackers to access any other accounts.

Data breaches can be shady business. There's obviously the issue of sites being hacked in the first place which is not just shady, but downright illegal. Then there's the way this information is redistributed, the anonymous identities that deal with it and the various motives people have for bringing this data into the public eye.

One of the constant challenges with the spread of data breaches is establishing what is indeed data hacked out of an organisation versus data from another source. We've seen many recent cases where representations of a data breach have been made and the claim subsequently well and truly disproved. For example, the recent case where it was claimed that 272 million accounts had been stolen from Hotmail, Yahoo, Gmail and Mail.ru. The mail providers subsequently confirmed that no, this was not the case. Same again for recent claims that there were 32 million Twitter accounts on the loose. Twitter quickly debunked this and speculation that they were obtained via malware has never been substantiated.

The first thing I try and do when I see a new data breach is establish if it's legitimate and I've written before about how I do this. Under no circumstances do I want to end up in a situation where I'm making a claim about an organisation being hacked which is then proven to be false, not only because of the potential reputation damage to the company, but because of the unnecessary angst it causes for those involved in the incident. Plus, any claims of this nature are being made by me as an identifiable individual; I'm not hiding behind the veil of anonymity and shirking any responsibility associated with getting my facts wrong. Integrity is essential, particularly in an area of security so frequently lacking it.

But here's the problem and the catalyst for writing this post: sometimes there are breaches where I just can't be certain of the authenticity, yet there are many indicators which point to an actual breach. The incident sits in that grey area between "very unlikely to be legitimate" and "almost certainly legitimate". For example, the Badoo breach. They've denied the data came from them so that in itself is an important factor to consider. That doesn't necessarily mean they're right, but it's a factor involved in my confidence level, particularly when the likes of LinkedIn and MySpace openly acknowledged the legitimacy of their recent breaches. The Badoo data itself is... eclectic. Here's the first row of the breach file:

This implies the presence of many interesting fields, yet every subsequent row is inconsistent with this insert statement and contains significantly less information. For example, here's a sample Mailinator account (these are often disposable addresses used by individuals who are not creating genuine accounts they actually intend to use):

Here we have an ID, email (the alias also contains the word "badoo"), username, password, first and last name (clearly fabricate above, but seemingly legitimate on many other records), what's possibly a username or alias, birth date, gender and what are likely foreign keys to other tables. The Badoo website confirms the existence of the email address via the password reset feature and that MD5 password hash has a plain text value of... "badoo".

However, they'll happily allow one of Mailinator's hundreds of alternative domain names (such as spamhereplease.com). Now this doesn't mean that the account above didn't come from Badoo, it may simply mean that at some time after it was originally created they changed their policy on addresses and disallowed that host name. I thought I might see similar behaviour when creating a password but no, Badoo will still happily allow a password of "badoo". There are 49,941 "badoo" passwords in the dump...

This exercise gives me some degree of confidence in the legitimacy of the breach, but the same process with other records was much less conclusive. Particularly for an incident of this size, I didn't want lingering doubts so I needed to reach out further.

Over recent weeks, I've been in contact with dozens of Have I been pwned (HIBP) subscribers who are in the alleged breach. I've been using them to help sanity check the data and the results have been... mixed. With only a limited set of data available to actually verify whether it actually came from Badoo, I provided snippets to the alleged owner and asked them not just if the data itself was correct, but if they'd ever created an account on Badoo. Often I'd get a simple confirmation - "Yes, I had an account there and yes, the data is correct". Other times they were adamant they'd never created an account but their personal attributes were accurate. Then in some cases, none of the data was accurate.

Now negative responses don't necessarily mean that someone didn't have an account; they could have forgotten, they could have created one with another service that Badoo since acquired or someone could have simply signed them up without their knowledge. All of these are possible. Problem is, in some cases, people would respond like this:

This was after I suggested that one of my HIBP subscribers issue a password reset for what was allegedly their account. It's possible their email was genuinely in the system and it was simply "soft deleted" (the record was still there but merely flagged as inactive), but it's also entirely possible that Badoo has never seen this individual before. Similar story here:

So you see the challenge in terms of verification when there are both positive and negative indicators of legitimacy. It would be irresponsible to make an outright claim that "Badoo was hacked", yet by the same token there is a very high likelihood that at least some of the data has come from them. Ultimately, the only conclusion I can emphatically reach is that the data is "unverified", which brings me to the concept of unverified data breaches in HIBP.

This is actually not a new thing, in fact I created a UserVoice idea for it back in 2014. Actually, I did more than that, I integrated the concept of an unverified breach into the underlying data model of the system and whilst I didn't publish anything in the API documentation, there's been an "IsVerified" flag returned with the breach model for some time now. Until today, it's always returned "true", but Badoo marks the first unverified breach I've loaded.

Because it's unverified, it's important I indicate that whenever the breach is described in the system. The first place you'll see that is on the homepage as it's within the top 10 breaches loaded into the system in terms of size:

The next is that if you search for an email address and it appears in an unverified breach, there'll be an indicator in the description. Now this isn't possible with Badoo because being a dating site it's also flagged as "sensitive" which means you can't search for it publicly. However, those who've subscribed to HIBP's free notification service can still view everything they've been pwned in by following the link in the email they receive when signing up (you can come back and do this even if you're already subscribed):

Because it's there in the description of the incident, anyone who appears in the data breach and receives an email notification will see a clear explanation of the unverified nature of the data with a link through to this blog post. The point is that I want to ensure at every possible opportunity, the unverified status of the data is made perfectly clear.

3a8082e126