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."
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.
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.
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.
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.
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?
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.
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.
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:
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.
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.
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 don't know each other well enough yet to expose our digital lives to each other on Facebook.
 - 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).
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
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..
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
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?
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)
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.
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".