WhatsApp is using your IMEI number as password | Hacker News Reader

WhatsApp is using your IMEI number as password

samgranger.com

156 pointsdutchbrit77 comments

An "Ask HN" that's somewhat related:

Is Facebook doing something similar on Android? I have left an application update pending for weeks because Facebook requires access to Phone Calls, which allows the application to "determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like."

This does not sit well with me.

I also don't allow any app requiring those details (unless they are needed obviously, like VoIP), but I think what most companies want is the unique serial number, so they can keep a track of how many unique devices are used by them. But since Android does not gives permission at more granular level, I simply don't install any such app, or don't upgrade one which ask for it.

As for Facebook, I am using Tinfoil for Facebook app (It is a website wrapper, essentially). It was faster than whatever app Facebook managed to write.

> Tinfoil for Facebook

And Tinfoil is better integrated with the Android system than the official Facebook app. Click a Facebook link in an app or browser - you'll get Tinfoil as an option to view the link but not the official app.

What a brilliant name! We need a tinfoil chrome extension.

Check if PDroid is available for the ROM you use, it allows you to choose which permissions to allow for each app. I've blocked Facebook access to the GPS and Contacts using PDroid.

There is no public API on the iPhone to access the IMEI, so at least it is pretty conclusively not using that there.

Thanks for the heads up - I didn't know

Good post - although for posterity retrieving a phone number doesn't work as described in all cases. Calling `getLine1Number()` on a GSM phone will return the MSISDN, but not all carriers store the MSISDN on the SIM (for security reasons), so it will in some cases return null. This is a somewhat moot point, because there are other ways to find mobile numbers!

As you point out, this is almost certainly an Android specific implementation, because there's no way to get either the MSISDN or the IMEI through iOS using the public API (if it was to transpire that WhatsApp were using private calls to obtain them then that would be another story entirely).

MSISDN file on the SIM card (EFmsisdn) is optional and has default access rights allowing you to modify it with just a PIN(CHV1) code (see 3GPP TS 51.011). Therefore, information stored in this file is not very reliable, since everyone knowing the PIN code of the card can change it's content. I do not think it has anything to do with the security reasons...

I do not see anything wrong with using IMEI as a seed for a password generation, the problem is that this number should be encrypted using proper encryption method and not just transformed using MD5 hash function.

xxx

WhatsApp in fact is using NSClassFromString to get access to the private class UITextEffectsWindow ;P. However, I don't think it doing anything to get access to CoreTelephony and pull the IMEI.

Another piece of evidence for this is an article published on a website I found while searching for the API endpoints that WhatsApp is connecting to; this person pulled apart the Android client.

http://www.mathyvanhoef.com/2012/05/whatsapp-considered-inse...

In this article there are a few API calls that are discussed, including v1/exist.php and v1/code.php: the former takes an argument sim=MSISDN and the latter takes both sim=MSISDN and imsi=IMSI.

However, on my device (iOS), all of the other fields are being sent (including the MCC and MNC, which you can apparently get using the public CTCallCenter API) except those sim and imsi fields.

(Note: the actual service seems to run over XMPP, and I did not bother figuring out how I'd man-in-the-middle that to figure out my password, so maybe they do something really sneaky at a later step.)

Small nitpick - MD5 is not technically "encryption"

From the article: " likely to be an inverse of your phones IMEI number with an MD5 encryption thrown on top"

MD5 is a digest...not encryption

He fixed it.

This is well-known. I'm curious to know how they get the IMEI on iOS cause there isn't a public API but only an undocumented method on the CoreTelephony.framework. Using a private method is one of the easiest ways to be banned from the App Store. BTW on January 13, 2012, Whatsapp was pulled from the iOS App Store for 4 days. I think they were pardoned by Apple because of the popularity of the application.

Deleted post from Google cache: http://webcache.googleusercontent.com/search?q=cache:samgran...

From your post, it seems like you didn't contact WhatsApp before publishing this post. What was your reasoning for going public with this vulnerability before at least trying to contact them and giving them a chance to resolve the issue?

I sent them a message a few days ago, but didn't receive a reply (yet).

This is a well-known design decision on their side. This is not as much a discovery as bringing it up.

Is there a particular reason (that you're aware of) for this decision? I'm certainly no expert on the matter, but it seems risky to store everything like that, especially unsalted. LinkedIn, anyone?

The problem isn't storing -- remember that we don't know how they store it, we only know how the password is generated. IMEI is intended to be unique and private -- e.g. knowing your IMEI might be enough to report the phone as stolen. If someone knows your IMEI they most likely have enough control over the phone to either completely spoof it or put malicious software on it. This makes it a reasonable tradeoff against implementing "proper" passwords, with their own ton of problems.

> IMEI is intended to be unique and private

It's intended to be unique but not secret and not hard to guess. It's a bit like your SSN or a computer's MAC address.

> If someone knows your IMEI they most likely have enough control over the phone to either completely spoof it or put malicious software on it

Err, no? Your phone can be asked to broadcast it via radio, your phones previous owner / sales clerk knows it, etc, your wife/gf knows it, etc. Now it's trivial for any of those to gain access to your WhatsApp without any active and sophisticated attack requiring physical access.

Sure, with sufficient effort it might be possible for someone sniffing radio or having at some point handled your phone to subvert it in other ways, but this is zero effort.

Can anyone explain in general what is the point in WhatsApp which isn't compatible with anything except itself, vs normative XMPP/Jingle client through which one can communicate with any user from federated XMPP servers? I have hard time understanding why new closed (walled garden) IM networks appear in these day and age.

It got traction because it worked simply with no config and was very cost effective in certain use cases.

I know it was used as a precursor to iMessage type eaperince to send 'texts' and images using only data, so was perfect for communicating across countries with no carrier charges.

So the only point was in avoiding one time step like adding an account to the client (like users do with e-mail too) / or registering on some XMPP server? Still it hardly justifies creating more walled networks (unless they allow federation and regular XMPP communication with their servers).

Do you think consumers care about walled networks? No.

To a degree they do, since users of one walled network can't communicate with users of other walled ones, and if they want they need to create an account in each of them. While federated XMPP is like e-mail, i.e you can use one ID to communicate with users from many servers. So there is an obvious comfort even for the end user.

It's quite popular in countries where buying SMS credits is not always an afforded cost, but public wifi is everywhere. Basic Android phones are fairly popular and inexpensive given that they double as a web browser and communication device for many.

That's understandable, but my question was about creating WhatsApp vs making a regular conformant XMPP/Jingle client which also simply works through TCP and UDP. The later gives free choice of what XMPP server to use and allows communicating with users of other federated servers. WhatsApp allows communicating only with WhatsApp if I understand correctly.

I would imagine this is a plus for them, sadly. It's probably easier to extract revenue from a walled garden than an equally user-friendly XMPP client.

Here in Vietnam you can get unlimited 3g access for $2/month and once you've paid for that using something like WhatsApp is much cheaper than paying the SMS fee for every message.

I use it to talk to my friends back home because:

- it's free (or inexpensive compared to international SMS)

- it doesn't require any technical expertise whatsoever

- it's cross platform

- it already has traction

I can't think of any alternative which has this combination of properties..

I hate to be the devil's advocate but I swear by Facebook's messenger app. It does exactly the same things: international, FREE-as-in-beer, really cross platform (can whatsapp do web?), push notifications on iPhone thereby effectively replacing SMS, etc. As long as the other person is on facebook of course!

It has come to the point that my wife and I barely use SMS anymore and are actually saving some play money on SMS thanks to that thing.

And that is bad news for carriers worldwide yes, but not that anyone really feels pity for them anyway.

You see, so what stops them all from implementing their clients and servers using conformant XMPP with enabled federation? Can your Facebook messenger connect you to users of WhatsApp and vice versa? No. With Federated XMPP it'd just work. Is it just their greed, or lack of thinking? Actually Facebook does use XMPP, and I think even WhatsApp in some way internally does, but Facebook server lacks federation, and WhatsApp isn't even conformant to standard XMPP. In the end - you have no way to connect the two.

This situation resembles the early period of the Internet, when users of Compuserve couldn't send e-mails to users of AOL (and other way around). It sounds completely weird today, but how is this situation with IM networks different?

Understandably there are historic isolated networks (AOL, MSN etc.) which predate any serious federation efforts, and even they are slowly enabling XMPP in some ways. But creating new closed ones in the present time is just weird and only serves to make the situation worse.

Using Facebook's messenger app requires you to know someone in way which just having their phone number doesn't.

For example, if I'm going to go on a date with someone and we've swapped numbers that's enough for us to talk by SMS/iMessage/WhatsApp, whilst we probably[1] don't know each other well enough yet to expose our digital lives to each other on Facebook.

[1] - This entirely depends on things like age, social norms, how much personal information is on your Facebook page etc. Also, depending on are you going on a date with someone you already know vs. someone new. Mostly the point being that anything that just needs a phone number has a low barrier to communication while also not leaking any personal information (other than your phone number).

Ubiquity; works on every mobile platform. (Including Nokia/Symbian, Windows Phone) So you can talk to any of your friends if they install the app.

Phone numbers are logins. Everybody with a phone already has one, so they don't have to do the whole 'create/verify an ID/password' dance.

If you have friends in other countries, this avoids roaming SMS charges. And if you are from Ireland, or Greece, lots of your friends are in other countries.

> you can talk to any of your friends if they install the app

Yes, that's exactly the catch. Why should you require them to install anoter app if they might already use some other IM network? Approach of WhatsApp may be simplifies the initial registration step, but it adds to the global mess of the non interoperable IM networks. Negative impact way outweighs any potential comfort benefits, and authors who promote such things are to be blamed for it.

> Everybody with a phone already has one, so they don't have to do the whole 'create/verify an ID/password' dance

Actually you might want to do it, since numbers change, while IDs don't. Plus you want to authenticate the other party if for example you need a secure conversation (such as with OTR).

For most people it's far easier to just install an app instead of going through a whole setup and registration process and remembering a login handle and a password. I have a lot non-geek friends who are happy with how WhatsApp works. They mostly ignore all privacy issues with this.

I'm not really directing this critique to WhatsApp users, rather to WhatsApp authors, who exploit users' comfort of no configuration vs one time configuration / registration, while causing with that a proliferation of walled networks. They are not doing a good service to users at large.

One time configuration / registration is not really a burden. All users are familial with that process. And they don't do it each time they read their e-mail for example. As I said, the negative impact of non interoperability proliferation is way more significant.

If you installed WhatsApp on an Android device for example, your password is likely to be an inverse of your phones IMEI number with an MD5 encryption thrown on top of it (without salt).

How does OP know this? Was there a leak of "passwords" or did he find this through trial & error?

Edit: Just found out that's what it says even on the Wikipedia entry about WhatsApp[1].

[1]: http://en.wikipedia.org/wiki/WhatsApp

it's called reverse engineering though. it's much easier to use reverse ios code than that weirdass dex format though imho

You can convert .dex files back to .class files, and then use a java decompiler. Not all functions will be properly decompiled but overall it's still quite good. Knowing this, reversing Android apps is actually a lot easier.

Really? I've done it once or twice, not hard at all with smali: http://code.google.com/p/smali/

While it may not be the case in this scenario (since Sam says in a response on here that he sent them a message a few days ago), everyone should always be responsible in how they disclose flaws or discoveries in software:

http://en.wikipedia.org/wiki/Responsible_disclosure

> So just as giving a vendor no time to fix a vulnerability is irresponsible, so is it even more irresponsible to give that vendor a blank rain check.

http://kevtownsend.wordpress.com/2012/09/01/java-vulnerabili...

I don't think responsible disclosure applies to deliberate, already-public protocol decisions.

No offense but what is the big deal about this...This seems to be extremely low risk if you can even call it a risk, and hardly a vulnerability..

Every method on your website to “exploit” this is retrieving IMEI number through alternative ways which would mean the phone would be compromised anyway...If someone can compromise the phone who cares about this?

Maybe whatsapp can be accessed more easily but isn't that moot if you already have phone access..If you have phone access already why would an attacker care about whatsapp?

Whatsapp is not necessarily insecure based on this..You are giving whatsapp bad publicity for no reason

I don't even think it's a design flaw that they used that as the password because if someone has phone access, and/or access to their number already then they are probably screwed anyway

please correct me if I'm missing the actual vuln here..

Your IMEI isn't secret: not random/hard to guess, and not private. It's like a MAC address. Except you can't change it.

This still seems minor. If someone is able to get the number doesn't that spell larger issues than whatsapp? I get the point being made and I understand the potential issue, but I don't see how its a major security problem with whatsapp as I figure things are probably compromised anyway if the user is able to get the IMEI to begin with

> If someone is able to get the number doesn't that spell larger issues than whatsapp?

No, since it's not a secret. Why would outing your IMEI spell large issues?

even if you have the users phone nurmber and imei nuumber one would assume u already have access to other info then anyway so who cares about whatsapp Can you easedrop on whatsapp sessions from another phone using this info?

Asking users to participate in "two-factor authentication" seems like a great way to match people's personal information to particular devices.

So maybe we have a double-edged sword here. If you want to be able to authenticate you have to give some company the ability to track you and monitor all your activity (which they will try to "monetize"). It sounds sort of tinfoil hat but this is what we are facing.

The reason: We insist on using the web and other "client-server" approaches for almost everything we do using the internet, instead of considering end-to-end, peer-to-peer approaches. Things are so insecure when everyting goes (mostly) unencrypted over the open web via middleman (Facebook servers, Gmail servers, etc.) that we need to try things like "two-factor authentication".

This actually seems to me like a perfect solution (from WhatsApp's side). This way as long the user has the same phone number, he/she doesn't have to remember any credentials, which is probably the main reason (or one of the top 3) for people using WhatsApp in the first place.

And as for the "security problem", if someone has access to your phone they can just maliciously use the app itself. I'm not saying that this should just be ignored, but in this specific case the author had probably created the bigger part of the security threat by publishing the article.

An unsalted(!) md5(!) is never a perfect solution unless your goal is insecurity. The idea of using the IMEI as unique device dependant string for hash generation is good but you must make it impossible for anyone to find out how the hash is created or it is a glaring security hole (as demonstrated).

Many many apps have permissions to read the IMEI. Just as many have access to the internet. Add whatever permission is needed to find out the device's phone number and you have all you need.

Exactomundo!

I'm assuming that they (WhatsApp) were trying to make the experience as close as possible to SMS without help from the carriers, so by using the phone number (which they verify, by the way) and the phone itself as the credentials -- only one of which most people replace, and that's mostly once every 2-3 years -- is a great idea for getting users to their platform with a minimal security tradeoff, hence in my opinion a perfect solution.

And again, if an app had fooled a user for permissions to get their phone number they could probably just ask for permissions to send and receive SMS's -- which is what some banks (at least here, in Israel) use to verify online accounts.

Perhaps a better solution would be to tie it to the Google account on the phone? This could be done without requiring the user to remember any details as most people already have an account tied in.

IMEI isn't related to the phone number (IMSI is). And it's a horrible idea since IMEI isn't secret.

I should have said the phone number on the same device. And like I said in my original comment, you need some kind of access to the user for getting the IMEI (unless you work for one of the carriers, but the point still applies) so in lots of cases it would be easier to just physically do something worse on the phone itself.

Un-official What's App API for PHP and Python: https://github.com/venomous0x/WhatsAPI

A reference to https://github.com/venomous0x/WhatsAPI/ wouldn't hurt you, author.

Though the post is deleted now I suppose this is true. I have a dual-mode GSM/CDMA phone and WhatsApp fails when it switches between modes. The app stays the same so it's clearly polling the ESN (CDMA side) and IMEI (GSM side) to validate. When I switch between active sides of the device, WhatsApp consistently requires a re-validation.

The more scary part of this is that WhatsApp probably has a database with phonenumber/imei number pairs on their servers.

The fact that their API uses the IMEI is not great but relatively low risk.

Wait until their servers get hacked and that list of how-many-million pairs of phone/imei numbers gets released.

Setups like this are time bombs.

Nothing Found Sorry, the post you are looking for is not available. Maybe you want to perform a search?

Fixed, sorry!!

Whatsapp for iPhone uses a MD5 hash of mac address taken twice. For details look at http://www.ezioamodio.it/?p=29

Does the deleted post mean that it contained false info?

No, I made 2 noobish mistakes.

1) I edited the default wordpress post, dated from May 2) I set the time for the future without noticing (wrong timezone!!)

mPhoneNumber = tMgr.getLine1Number(); This doesn't work. The phone number is not stored in the device but is assigned by the operator and stored in (god only knows where) location, at least here in India.

skype and viber also need your imei to function. the skype example is particularly interesting since it's complementary to the username + password we already have.

"Dial *#06# for IMEI"

Does anyone know any other neat tricks like this?

They're GSM feature codes - implemented features vary from carrier to carrier, but there are lists of commands here:

http://www.stereo.org.ua/2007/gsm-codes/ http://www.arcx.com/sites/GsmFeatures.htm

There are additionally model specific codes for hardware diagnostics (rather than interacting with the network) on a model-by-model basis.

Yes - on my network, Vodafone UK, these are the ones I can remember off the top of my head:

  *#1345# - gives you your credit balance if you're on a prepaid account
  *#100# - your phone number
  *#101# - the current network date and time
  *#[102-105]# - various network engineering information that I can't understand.

You can also, as long as you're on original GSM and not 3G, use the 'cell broadcast' feature to make it show you the current area code you're in (or more accurately, that your current tower is in). This is a throwback to an ancient price plan which gave cheaper calls to your local area. It's very much deprecated, so some newer cells don't broadcast the area code info, and no 3G cells do so.

Sure.

On iPhones, try 3001#12345# .

On Android it often depends on the specific model you have. Here are some for the Samsung S3:

#06# Show IMEI number

#0# LCD Test Menu

##4636##* user statistics and Phone Info

#0011# Displays status information for the GSM

#1234# View SW Version PDA, CSC, MODEM

#12580369# SW & HW Info

#197328640# Service Mode

#32489# (Ciphering Info)

#232337# Bluetooth Address

#232331# Bluetooth Test Mode

#232338# WLAN MAC Address

#232339# WLAN Test Mode

#0842# Vibra Motor Test Mode

#0782# Real Time Clock Test

#0673# Audio Test Mode

#0# General Test Mode

#2263# RF Band Selection

#872564# USB Logging Control

#4238378# GCF Configuration

#0283# Audio Loopback Control

#1575# GPS Control Menu

#3214789650# LBS Test Mode

#44336# Sofware Version Info

#7780# Factory Reset

27673855# Full Factory Reset

#0289# Melody Test Mode

#2663# TSP / TSK firmware update

#03# NAND Flash S/N

#0589# Light Sensor Test Mode

#0588# Proximity Sensor Test

#3282727336# Data Usage Status

#7594# Remap Shutdown to End Call TSK

#34971539# Camera Firmware

#528# WLAN Engineering Mode

#7412365# Camera Firmware Menu

#07# Test History

#3214789# GCF Mode Status

#272886# Auto Answer Selection

#8736364# OTA Update Menu

#301279# HSDPA/HSUPA Control Menu

#7353# Quick Test Menu

27674387264636# Sellout SMS / PCODE view

#7465625# View Phone Lock Status

7465625638# Configure Network Lock MCC/MNC

#7465625638# Insert Network Lock Keycode

##7780##* Factory data reset - Clears Google-account data, system and program settings and installed programs. system will not be deleted, and OEM programs, as well as My Documents (pictures, music, videos)

##7780##* Factory reset

This seems a bit dangerous. Does it require any kind of password?

I just tried it on an HTC Incredible 2 on Verizon. Nothing happened. No error message, just back to the dialer.

EDIT: I see now it was stated these are SIII specific. Guess that explains why nothing happened for me.

On AT&T dial *639# to get a text message with your upgrade status.

Any news about the renewed authentification system?

Reply on news.ycombinator.com