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.