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.
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.
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.
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.
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.)
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?
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.
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.
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).
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).
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.
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.
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.
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.
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.
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].
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.
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:
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?
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.
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.
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.
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.
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.
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.
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)
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.