WhatsApp ‘backdoor’ turns out to be known design feature

On Friday, The Guardian newspaper accused Facebook’s WhatsApp messaging app of having a “backdoor” security vulnerability on the basis of a security issue revealed to it by researcher, Tobias Boelter of the University of California at Berkeley.

The newspaper has since backed away from the emotive word but the fire had been lit. Was this a fair accusation to throw at WhatsApp?

The report described how the app generates a new key pair for “offline” users, for example when a user loses or changes a phone or phone number and then (after a period of time) reinstalls the app afresh

In the respected Signal app, whose underlying encryption protocol was adopted by WhatsApp in 2016, messages sent to anyone in this situation are deleted and the sender is informed that something has changed. The message can then be re-encrypted and resent after verification that the recipient is still the same person.

In WhatsApp, by apparent contrast, the sending app is simply asked to re-encrypt and re-send the message, something the sender will only be told about if alerting is turned on, after the fact.

The issue is that WhatsApp’s servers could, hypothetically, force the resend of a message using a new key under its control without the sender being able to stop that – a man-in-the-middle (MitM) compromise of sorts.

The first objection with this is that hiding a malicious key reset indefinitely would be difficult on WhatsApp given the software’s “verify security code” feature that ensures both sides are using the same key and no MiTM is taking place.

This also looks more like a design trade-off than a backdoor. As a mass-market product, WhatsApp was designed to make itself as transparent as possible and not to bother users with possibly confusing alerts about key pair changes.

The developer who co-authored the Signal protocol used by WhatsApp, Open Whisper Systems’ Moxie Marlinspike, said the backdoor claim was a misnomer:  “Under no circumstances is it reasonable to call this a ‘backdoor,’ as key changes are immediately detected by the sender and can be verified.”

“It is great that the Guardian thinks privacy is something their readers should be concerned about. However, running a story like this without taking the time to carefully evaluate claims of a ‘backdoor’ will ultimately only hurt their readers.”

For something to be a true “backdoor”, it must simultaneously satisfy two criteria beyond simply compromising security or privacy. First, it must have been put there deliberately, for either benign or villainous reasons. Second, it must be undocumented, which is to say only the people who put it there know about it.

The minute a backdoor  becomes public knowledge, it stops being one and becomes just another security flaw that needs to be fixed if that product wants to hang on to its users.

On that basis, it is inaccurate to describe the WhatsApp issue as a “backdoor” when it is really a known design compromise, and also one that people should be aware of.

How to opt out of WhatsApp sharing your phone number with Facebook

Nearly two and a half years after Facebook acquired WhatsApp, and despite Whatsapp CEO Jan Koum saying at the time of the acquisition that user privacy wouldn’t suffer, the services are about to get a little bit friendlier with their data sharing.

WhatsApp’s new privacy policy gives it permission to share data, including your phone number, with Facebook “to coordinate more and improve experiences across our services and those of Facebook and the Facebook family”. In an FAQ, WhatsApp says it is doing this to:

1. More accurately count unique users

2. Better fight spam and abuse

3. Show better friend suggestions and more relevant ads to you on Facebook.

The messaging app explained the reasons for the changes in a blog post. It begins by highlighting its plans to test ways for people to communicate with businesses:

"Whether it’s hearing from your bank about a potentially fraudulent transaction, or getting notified by an airline about a delayed flight, many of us get this information elsewhere, including in text messages and phone calls. We want to test these features in the next several months".

It also makes some stark promises in the blog post that it won’t…

…"post or share your WhatsApp number with others, including on Facebook, and we still won’t sell, share, or give your phone number to advertisers".

Note the ‘on Facebook’ and not ‘Facebook’ itself.

Facebook won’t, however, be able to see any of your messages, photos or account information.

How to opt out

You can choose not to share your account information with Facebook for targeting purposes. There are two ways to do this:

1. On WhatsApp, don’t click Agree when it asks you to confirm you are happy with the change of terms. Instead, click to read more. You should then see a check box or control button at the bottom of the screen which says “Share my WhatsApp account information with Facebook to improve my Facebook ads and product experiences…”. Uncheck this.

2. If you have already agreed to the updated terms, you can go to to Settings > Account > Share my account info in the app. Then uncheck the box or toggle the control. But quick, WhatsApp says you only have 30 days to make this choice after agreeing to the new terms.

Sadly, 

Even if you opt out of the ad targeting part, WhatsApp says that Facebook will still be sent your data “for other purposes such as improving infrastructure and delivery systems, understanding how our services or theirs are used, securing systems, and fighting spam, abuse, or infringement activities.”

So it seems you can’t entirely opt out. Unless you stop using WhatsApp of course.

Unlock iPhone without passcode using Siri – video is bogus

The 35-second clip is called “iPhone Unlock WITHOUT Passcode Glitch *New 2016*” and had been viewed over 440,000 times as of Monday morning, after being uploaded last Thursday, 3 March.

It seems to show a man unlocking an iPhone without knowing the user’s passcode, gaining access by using Siri to ask the iPhone what time it is.

When the phone displays the time, the guy clicks on the Timer option at the bottom of the screen and uses the “When Timer Ends” option to buy more tones from the App Store.

The video says that by tapping the home screen from the App Store, you’ll get taken back to the home screen.

Presto! Unlocked phone.

But many commenters did indeed report success unlocking an iPhone with the timer-buy more tones voodoo routine.

Hmm… but only sometimes… and not when they tried it on a friend’s phone… and not when they used another finger, besides their thumb, to access the “buy more tones” button…???

In fact, the viral video fails to make one key aspect clear: by hitting the home screen to activate Siri in the first place, users engage Apple’s Touch ID fingerprint scanner.

Reversing Type 7 Cisco Passwords

I came across a few Cisco routers sitting on an internal network. The fact that they were using default cisco/cisco credentials made me cry a little inside, but wait, it gets worse… So I’m in the router, reviewing the running config, and I notice something interesting.

Note that both of these accounts have the same privilege level, but that the passwords are stored differently. This is because the first user was created with a command like this:

Whereas, the second user was created with this command:

The difference between these two storage methods (password or secret) are the hashing algorithms. Type 7 passwords use a very weak algorithm that can be easily reversed, but the “secret” command utilizes a MD5 hash which is much more secure. Due to this, it is never a good idea to use Type 7 passwords. This policy applies to both user accounts and passwords applied to the VTY or Console lines.

So now that I’ve found these Type 7 passwords, I need a way to reverse them. There are several different tools and websites that have this capability, but there’s an easier way! I don’t even have to leave the router! Thanks to a nifty little feature called the “key chain”, I can reverse these passwords right here, right now!

1. First, we will enter config mode:

configure terminal

2. Next, we will create our key chain and give it the name of NEW:

key chain NEW

3. We will enter the first key:

key 1

4. Then we enter the key-string, which will include the number 7 for encryption type and the text of the “encrypted” password:

key-string 7 07212E587D062A0014000E18

* At this point, you may add more keys by repeating steps 3 and 4 if you have multiple passwords to reverse. Make sure to increase the key count though (key 2, key 3, etc.).

5. Finally, we do a show command, and voila! Passwords!

do show key chain

Now that you’ve seen how incredibly easy it is to reverse these types of passwords, please go forth and check your routers! Ensure that all user accounts and enable passwords listed in the running config are proceeded by the word “secret”.

iPhones, iPads at risk of new lock screen passcode bypass flaw

A security researcher has published details of a newly-discovered flaw that can allow an attacker to quickly bypass iPhone and iPad lock screens.

Disclosed on Thursday, the "high"-rated vulnerability is said to affect iPhones 5 and 6, and iPad 2 tablets running iOS 8.2 and later. It's not clear if other devices are affected.

Apple's most recent figures show that the vast majority of iPhone and iPad users are running an affected version of the software, accounting to many tens of millions of users.

The flaw allows an attacker to bypass the passcode on the lock screen through a carefully performed time-based attack. An attacker must have access to the device to exploit the flaw.

Benjamin Kunz Mejri, who found the vulnerability, posted a proof-of-concept video of the attack taking place.

Mejri said in the advisory (edited for clarity) that a "local attacker can trick the iOS device into a mode where a runtime issue with unlimited loop occurs. This finally results in a temporarily deactivation of the passcode lock screen."

ZDNet was not able to independently verify the flaw at the time of writing.

The researcher said he notified Apple's security team on October 22 last year. It's not clear why the flaw was publicly disclosed. Thursday's advisory was posted more than three months after Apple was notified, falling in line with responsible disclosure principles.