iStupid: Beaconing SSIDs to aid cleanup of network list.
Sometimes, the names of past Wi-Fi networks your iOS device has used get broadcast to the world as the device tries to find someone to talk to, and this can (possibly) leak information about your favorite home or work networks. So it’s a good idea to delete these networks whenever you’re done using them. Unfortunately, here’s no way to remove Wi-Fi networks from the “Preferred Network List” (PNL) on iOS, unless you happen to be in range of that network at the time. Then, and only then, do you get the option to “Forget this Network.”
So now there’s iStupid, the “indescreet SSID tool (for the) unknown PNL (on) iOS devices.” It beacons out whatever SSID you want it to, so that your phone will think it’s nearby and let you delete the network from the phone’s database.
A nice little trick…be even cooler if it could detect the aforementioned SSID pings and automatically beacon them back, to essentially “auto-discover” the networks your device knows about.
Creative usernames and Spotify account hijacking.
A nice writeup on how canonical forms can cause problems when using extended UNICODE alphabets.
Not so good since the function apparently was not idempotent, but at least it provided insight into why the attack worked. When you registered an account ‘ᴮᴵᴳᴮᴵᴿᴰ’, canonical_username got applied once, and an account with canonical username ‘BIGBIRD’ got registered which was allowed since it did not collide with the existing account with canonical username ‘bigbird’. When resetting the password for ‘ᴮᴵᴳᴮᴵᴿᴰ’ canonical_username was applied once, so the email to send the password reset to got sent to the address associated with the newly created account with canonical username ‘BIGBIRD’. However, when the link was used, canonical_username was once again applied, yielding ‘bigbird’ so that the new password was instead set for the ‘bigbird’ account. We were relying on nodeprep.prepare being idempotent, and it wasn’t.
Also intriguing was the fast that ultimately the problem was traced to a python library update.
Apple's security strategy: make it invisible.
Interesting piece from Rich Mogull about Apple and how the user interacts with security.
Apple is famously focused on design and human experience as their top guiding principles. When it comes to security, that focus created a conundrum. Security is all about placing obstacles in the way of attackers, but (despite the claims of security vendors) those same obstacles can get in the way of users, too.
While Apple hasn’t said so explicitly, it’s clear that one key principle guides them when it comes to security: The more you impede a user’s ability to do something, the more likely that user is to circumvent security measures.
This is awesome. A project to encrypt your data, and then reformat it to “look like” other data, like HTTP. Then deep packet inspection can’t recognize that it’s something else…like covert communication sneaking past the eyes of an oppressive regime…or, well, data being exfiltrated from a compromised corporate network.
More generally, we’re optimistic FTE has long-term
potential as a tool to enable users to control how their traffic is classified by passive DPI systems. As one example, over the last month, we’ve successfully tunneled Tor through the Great Firewall of China, using FTE to make our traffic “look like” HTTP.
Kind of proves my long-standing belief that you simply can’t catch well-executed exfiltration. If you’re okay going low and slow, you can make it look like *anything*.
iOS 7 and Mavericks: New feature roundup from a security perspective.
A quick link to a piece I posted on the Intrepidus Group blog. Lots of cool features coming in iOS 7, and many of them will probably have “interesting” security implications.
Android Security Overview | Android Open Source.
I haven’t seen this before (being primarily focused on iOS), but this looks like a pretty good parallel to the Apple iOS Security whitepaper published last year.
cortesi – Skout: a devastating privacy vulnerability.
Another scary privacy find from Aldo Cortesi:
The Skout mobile application talks to Skout’s servers through a simple API.
What’s returned is a blob of XML containing the user’s complete profile data. In fact, the profile data is too complete, including some bits of data information that is never actually used by the app. For example, we can see the user’s exact date of birth… but only the user’s age in years is actually displayed. Most serious, however, is the high-precision location information that is returned in the homeLocation and location tags.
The three decimal places of precision in the co-ordinates is enough to locate a user to within about 110 meters north-south, and substantially less than that east-west depending on the distance from the equator.
Fortunately, the vendor patched the API within a few hours of notification.
I really should get into the habit of checking all my apps from time to time for this kind of leakage.
Getting started with login verification | Twitter Blog.
This is a form of two-factor authentication — when you sign in to twitter.com, there’s a second check to make sure it’s really you. After you enroll in login verification, you’ll be asked to enter a six-digit code that we send to your phone via SMS each time you sign in to twitter.com.
This is great, and has been an increasingly frequent request over the past couple of years. However, there’s one drawback: You can only use your phone number with one account.
So if you have a public Twitter account, and another one you use for work, or for close friends, or for headlines from your blog…you can only enable two-factor authentication for one of those accounts.
The growing use of phone numbers or email addresses as a substitute for an account name is something that’s been driving me crazy for a long while, this is just another example of how it can unnecessarily hamper users.
John McCain Tim Cook Questioning – Business Insider.
Sen. McCain asked why we have to “keep updating apps” all the time:
McCain does have a point. It’s really annoying to pop open the App Store every time there’s a new update. We wish iPhones worked more like Android phones in that respect, letting you update apps automatically.
But is that really a good idea? I know there have been several times in the past year where an upgrade to an app broke things, and needed a subsequent “emergency” fix from the developer.
Maybe a hybrid approach — auto-update after they’re [1, 2, whatever-setting-you-prefer] week(s) old?