Author Archives: quine
“Voight-Kampff’ing The BlackBerry PlayBook” at INFILTRATE 2012
Last week, we gave a talk at Immunity’s awesome INFILTRATE conference in Miami Beach, FL. Our presentation, “Voight-Kampff’ing The BlackBerry PlayBook”, discussed some of the black-box style, independent research we performed on the BlackBerry PlayBook. Although some content was similar to our PlayBook talk at SecTor 2011, there were some very notable additions. In particular, we discussed reverse engineering of PlayBook firmware images; flaws in authorization of AppWorld downloads; and exposure of an authorization token used for BlackBerry Bridge (the PlayBook’s PIM and email sync component).
The lattermost point has stirred up a bit of press post-INFILTRATE, so we’d like to clarify a few things:
1. The exposure of the authorization token is facilitated by a bug in the Persistent Publish/Subscribe (PPS) facility of the QNX operating system. This bug causes the contents of otherwise-inaccessible files to be readable from a special file in the same directory. RIM was made aware of this PPS bug as a result of our SecTor talk, as well as notification from others, and again by us prior to INFILTRATE (with special emphasis on disclosure of the Bridge token) — they have fixed this PPS bug in Tablet OS 2.0 (beta).
2. This token exposure effectively renders the BlackBerry handset password moot. The exposed authorization token is accessible after the user has “unlocked” BlackBerry Bridge (where “unlocking” would entail entering the paired BlackBerry device’s password if one is set). Unlocking Bridge is an expected behavior/process for Bridge users. After all, if you’re using Bridge on your device, you’re going to do this. In the case where a BB handset password has not been set, a malicious actor could just request this token from the Bridge service directly.
3. This isn’t “sniffing”. Some highly misinformed comments on news articles have suggested things like “a bad guy would have to be within 10 meters to exploit this.” This issue is not, I repeat not related to Bluetooth (which is used by BlackBerry Bridge). As an aside, despite the title of the article, threatpost has one of the best (press) write-ups so far.
4. The pervasiveness of malicious mobile applications exacerbates this flaw. Unless you’ve been living under a rock, you know that even “savvy” users are frequently duped by seemingly legitimate applications which later turn out to be doing Bad Things. The downplaying of this as an attack vector is nonsense, and the “if dumb users install malicious apps, they deserve whatever’s coming to them” argument is silly. Note that client-side browser or document reader vulnerability could even render this vector moot in the end.
In upcoming posts, we’ll dive a bit deeper into the meat of our research, so stay tuned. For those interested, we have posted the slides at SlideShare, and uploaded some initial code to the Intrepidus Group GitHub page.
Intrepidus hosting a Convergence notary
Suffice to say, the Certificate Authority trust model seems to be fundamentally broken, and with increasing attention paid to it from numerous angles, it’s likely to need a massive overhaul before getting any better. However, there are efforts underway to change the way we think about trust in this capacity. Moxie Marlinspike, known for his contributions to (breaking) SSL and the CA system (among other things), recently developed an alternative to the traditional CA trust model. The project, called Convergence, pairs a Firefox add-on with a set of server-side components to help validate the authenticity and trustworthiness of a particular SSL-enabled site.
Although Moxie’s blog post (that led up to Convergence) and the video of his talk at BlackHat USA 2011 explain the rationale a bit more, the concept is simple: you visit a (SSL-enabled) site, let’s say SomeTrustedSite.com, and the Convergence add-on sees a certificate with a fingerprint FOO. The add-on asks a set of Convergence “Notary servers” what they see. If they see FOO, you can reason that SomeTrustedSite.com‘s cert is legit. If one or more of the notaries sees something that isn’t cert fingerprint FOO, something’s probably rotten (such as man-in-the-middling of your connection, or a notary’s connection, or some other network nastiness). Most importantly, you decide which notaries you want to trust, rather than relying on a browser-vendor defined list of Certificate Authorities. Convergence also attempts to anonymize inquiries to notaries so as to minimize the likelihood of a notary getting a bit too privy to your browsing habits.
Per the Convergence site, the installation process for the add-on is fairly straightforward: run Firefox, visit Convergence.io, click “Download”. After that, add any notaries you wish to trust — two Thoughtcrime notaries are enabled by default, and there’s an ever-growing list of additional notaries on the project’s Github wiki. As this project caught our eye, Intrepidus Group decided to spin up a notary server of our own, which can be added by loading our notary file (if you have Convergence installed, you can simply browse to “.notary” files/links to add the associated notary info).
And Intrepidus isn’t the only company to get on the Convergence notary server train. Late last month, Qualys announced their support of the project, as well as spinning up two notaries. We certainly hope to see more of this type of backing in the near future, and encourage others to run their own notaries as well.
OWASP Mobile – Top 10 Risks at AppSec USA
As one of the project leaders for the OWASP Mobile Security Project, it behooved me to help present, nay unveil the Release Candidate of the OWASP Top 10 Mobile Risks at OWASP AppSec USA 2011. Along with two of the other project leaders — Jack Mannino, of nVisium Security, and Mike Zusman, of Carve Systems — we discussed the general goals of the OWASP Mobile Security Project, its history, and finally the Top 10 Risks themselves. For each entry, we tried to provide an example of bad design or insecure coding practice that would give rise to such a risk, and/or a real world news story resultant of the associated risk item. We received great feedback from attendees, and it seemed some were very charged and passionate about the “top 10″ presented there. As mentioned in the slide deck, there is a 60-day window (from the unveiling) in which the RC Top 10 can be refuted or changed before we push it up to “Final” (that window ends on November 22).
The slide deck is available over at SlideShare.
We encourage anyone who’s interested to get involved in the OWASP Mobile Security Project (visit the OWASP wiki for information on mailing lists and other ways to help). With the Top 10 Risks and Top 10 Controls finally seeing the light of day, we’ve made some headway, but we’ve still got a long way to go.
Hey, Skype: the mid-90′s called…
…and they want their flaws back. A recent post by Justin Case over at Android Police discusses some file permission issues (as in “world readable” file permission issues) in the Skype client for Android. Skype’s CISO even posted a terse, slightly boilerplate response to Justin’s finding. As a user of said software, and a natural-born-skeptic, I decided to validate this finding — faith [in security], after all, is the antithesis of proof. First, let’s see what the package name is for my Skype installation (it differs from the package name of the beta build cited in the Android Police post):
Knowing that the default data store for most apps is /data/data/[package name], we’ll just follow along with the Android Police article:
Sure enough, the directory, and files therein, are world-readable. The Android Police article details just what these files contain, so I’ll skip detailing that here. There is one point of contention that’s a little FUD-y and perhaps slightly misguided (emphasis added):
Skype mistakenly left these files with improper permissions, allowing anyone or any app to read them. Not only are they accessible, but completely unencrypted.
Of course, this information could be encrypted, but is it really necessary or correct from a security/control perspective? A priori, there are two other points to consider, I think: first, that these data (logs, contacts, and other information) are even stored on the device to begin with and that the user has no way to disable their storage; secondly, the insecure permissions. Would anyone have cared about encryption, or lack thereof, if these files had been adequately protected? Those issues aside, the overhead of crypto for every little operation on client-side chat log entries, contact lists, and other data used by Skype would likely have a significant impact on performance and battery life — and then there’s the issue of the key, which would undoubtedly result in some blog post lambasting Skype for storing key material incorrectly (or something similar).
(Sidebar: yes, there certainly are privacy implications with chat logs and contact data being accessible by other applications, not to mention the compound issue of easily retrieving the user’s login name and subsequently the path to their files, and I’m not rushing to Skype’s defense — insecure file permissions and lack of crypto are perennial issues — but the crypto argument might not have much firepower here when weighed against the data being stored and the idea of re-evaluating some design elements.)
Anyway, such a file permission weakness is not novel or, honestly, even earth-shattering — a rough search for “world readable” or “world writable” related security advisories yields numerous results, easily spanning the bulk of two decades. As evidenced by Justin Case’s finding, this is no less applicable to the mobile application space. We at Intrepidus have discussed file permission issues identified during the course of our assessments, ranging from information leakage to modification of application components. Moreover, renowned security researcher, Tavis Ormandy, even discovered an interesting permissions-related issue in Lookout Mobile Security for Android, for which the sharp folks at Lookout issued a straight-to-the-point technical advisory. In this case, the file permission issue manifested in a different way — a notably insufficient umask(2) setting inherited by the software, something that could have been easily overlooked in design.
Web applications still struggle with 10+ year old security problems, and remote code execution is still possible (albeit a bit waning) on network-facing services. So, then, is it really a surprise that “mobile”, as a nascent space, is susceptible to many of the same security-pertinent design, development, and implementation blunders that have pervaded other areas for 10, 20 years and beyond?
I’m in ur 4sq, snarfin ur password — Redux
Earlier this year, I put up a couple of posts about an issue in the official Foursquare clients, for Android and Blackberry (and, by extension, iPhone), surrounding transmission of user credentials. The gist was that user credentials were sent “in the clear” and thus subject to interception by attackers (chiefly over WiFi). Most of the analysis focused on foursquared (the official Foursquare application for Android), but the problem spanned all three of the aforementioned mobile platforms.
In the latter half of this year, Foursquare has started to wise up to authentication and authorization — and are more or less forcing developers’ hands — as they are planning to switch to OAuth2 over HTTPS in the “coming weeks” as noted on the Foursquare blog. As suggested in previous posts, I’m a proponent of OAuth and I support this move, but I’m still skeptical about Foursquare’s plans. First, Foursquare noted that they’ve been using HTTP Basic Auth for their API, but didn’t mention that OAuth was available (and even preferred over Basic Auth). Second, the blog post says, “…using OAuth2/HTTPS as the standard for the new API…”, leading me to believe that alternative, and possibly less secure, means of accessing the API may still be available. Finally, there’s no public timeline/roadmap for implementation of OAuth2 (to my knowledge).
Although I’m still raising my virtual eyebrow all skeptic-like, I’m still happy to see Foursquare making this move.
Side note: Foursquare’s post seems to have been prompted by a recent post on Martin Kou’s blog wherein Martin cited the same authentication issues we found in February.
Zach’s 2010 BlackHat/DEFCON/B-Sides Las Vegas summary
I was aiming not to be the last contributor to this series, given that I’ve already received my proper lashings for slagging on posts as is. But, here’s my attempt at summarizing my experience in Las Vegas for BlackHat USA 2010, DEFCON 18, and the second Security B-Sides Las Vegas. I’ll scribble here what I can actually remember amidst the scorching blaze that is Vegas during the day, and the tiring, mind-scrambling, party-filled nights.
BlackHat
I actually caught the “System DNS Vulnerabilties and Risk Management” panel during the first day of BlackHat. Admittedly, I was expecting something beyond trumpeting about DNSSEC, though that’s…effectively…what the description of the panel was. *sigh* Anyway, the panelists explained the progress made with DNSSEC, explained some of the timelines for signing additional TLDs, what [we] should be on the lookout for, and even took a few good questions. One of the more intriguing inquiries from the audience was centered around emulating root nameservers in a completely isolated test lab. I wish I could recall what the exact response was, but that was right at the tail end of the panel and people were shuffling out. All-in-all, ‘okay’ session. (Really, though <fanboi> I just wanted to hear more from Whitfield Diffie </fanboi>.)
I also attended “These Aren’t the Permission You’re Looking For”, presented by my pal Anthony Lineberry, and his cohorts at Lookout, David Luke Richardson and Tim Wyatt. As someone who spends quite a bit of time on the Android platform, this session piqued my interest. I expected the usual rigmarole, introduce Android, the security model, how permissions work, message passing, etc., and I was on target. That part of the talk was very familiar to me, so I nodded along in step. Eventually, the talk shifted gears, discussing how applications can sidestep requesting certain permissions (such as fine-grained / GPS location data) simply by scraping those data from the logs, which requires only asking for the READ_LOGS permission (as my colleague, Corey, said in a previous blog post). Additionally, they discussed a means of exfiltrating certain data with zero permissions — by simply invoking the web browser (via an Intent), pointing to an attacker controlled web server, and sending device information and, in a few special cases, location data (IIRC, this was due to an issue in a third-party app).
The third, and final, talk I attended at Black Hat was “Harder, Better, Faster, Stronger: Semi-Auto Vulnerability Research” by Lurene Grenier (a.k.a. “pusscat”) and Richard Johnson. While certainly a bit dry to most of the audience (and even to me in a few spots), I was pretty excited about the concepts presented. The presenters basically laid out a workflow for finding, logging, archiving, and triaging bugs, and re-evaluating previously discovered bugs — constantly (in fact, one of the ideas presented was “constantly fuzzing”). Much emphasis was given to post-processing of bugs discovered during, say, the fuzzing process. Richard Johnson also presented a set of tools, including one called ”MoFlow” (IIRC, and that actually may have been the collective name), to help assist this process. Pusscat also showed off, briefly, a snapshot of a web interface that controlled and monitored distributed fuzzing/test processes. Cool stuff.
Security B-Sides Las Vegas
I didn’t actually attend the second day of BlackHat, but instead headed over to 2810 East Quail Ave., where lies a beautiful estate (with a gajillion [yes, a gajillion] pools). It also happened to be the venue for Security B-Sides Las Vegas. Surrounded by a ton of familiar faces, food, beer, and other refreshments, I chilled out for a bit before giving my own presentation, “It Melts In Your Hand: An Overview of Security (Failures) In Mobile Applications”. Through the nebulous haze of sleep deprivation, I managed to pull it off well enough (I think), and even answered some questions in a mildly coherent manner. After that, it was back to Caesars Palace to prepare for the Security Twits party.
DEFCON
Admittedly, my colleagues have done a better job of summarizing DEFCON than I can at this point. I spent most of my time in the “hallway track”, chatting up friends, old and new, about a myriad of things, ranging from hacking to Club Mate (blah). Also, I spent an inordinate amount of time getting my butt kicked in the Ninja Networks badge “game”. Notice I’m still a Level 1.
On the final day of DEFCON, I did manage to attend a panel about…wait for it…PCI. Yes. A PCI panel at DEFCON. And wouldn’t ya know it, it was packed. The panelists focused mainly on the pain points of PCI, the numerous misinterpretations and sheer laziness by merchants and service providers, and how we can all hope to effect change. Incidentally, the Q&A session following the panel, while in a smaller room (still packed, of course) was even more emotionally charged and powerful than the panel itself.
Here’s to more hax, more partying, and maybe even a bit of recovery.
Zach at the Adobe Haters Ball (photo by Stephen Ridley)
I’m in ur 4sq, snarfin ur password — Part II
In Part 1 of this discussion on Foursquare’s mobile applications, I demonstrated how the Foursquare Android app utilizes HTTP basic authentication over plaintext HTTP. Another intriguing aspect of all of this comes in the form of a snippet from the Foursquare API documentation:
For most methods, we require either Basic Authentication or OAuth Authentication. OAuth is the method we prefer you use so that clients do not have to hang on to usernames and passwords but can initiate requests on a user’s behalf via a special token.
As mentioned in the above snippet, OAuth is basically a protocol for authenticating and authorizing an entity (such as, say the Foursquare Android app) to perform an action on behalf of a user — without having to know the user’s credentials. OAuth can also provide additional protections such as signatures, timestamps, and nonces (to prevent replay attacks). Why, the very concept of the OAuth signature was designed for non-HTTPS communications. As seen in Part 1, the Android application uses Foursquare’s non-preferred method of authentication.
Looking at the source code of the Foursquare Android app shows that OAuth support exists, but is incomplete (and clearly not used):
This behavior doesn’t end with the Android application, though. Shortly before I drafted Part I, Foursquare announced a new version of their BlackBerry app. I promptly downloaded the app, installed it in a BlackBerry simulator, fired up Wireshark, and observed the same activity all over again:
(Anecdotal evidence suggests that the Foursquare app on iPhone does this, too. I haven’t investigated the new Windows Mobile application.)
This behavior is symptomatic of larger problems that pervade mobile applications: 1. the reliance on simple authentication mechanisms (e.g. usernames and passwords), and 2. the failure to adequately protect those mechanisms (see CWE-522 if you’re so inclined). As noted before, OAuth is the preferred method for API authorization on Foursquare, yet the developer(s) of these mobile applications elected to use the suboptimal Basic Auth method. It may seem that I’m picking on Foursquare, but this is really par for the course. As development shops race to shove their applications out the door, while sifting through the nuances of each mobile platform (RIM, Android, iPhone, BREW, Symbian, etc.), simple AuthN and AuthZ schemes will continue to pervade. Here’s to hoping that changes soon.
(Quick note: I’d originally planned a much more grandiose post, but due to time constraints decided to just call this done rather than complete. If I’m so inclined, time permitting, I’ll consider following up with a Part III)
I’m in ur 4sq, snarfin ur password — Part I
Hi, my name is Zach, and I’m a Foursquare user. If you’re not familiar with Foursquare, it’s a location-based social network and game (of sorts). Users “check in” to venues and, based on their activity, unlock “badges” and/or become “mayor” of that particular venue. Opinions of the service aside, I’m here today to highlight some issues pertinent to security (and possibly privacy) discovered in the official Foursquare mobile applications, including those running on the Android, iPhone, and BlackBerry platforms. These findings are, to some degree, part of the larger picture of mobile application security, especially with the <marketspeak> rapid convergence of mobile and web technologies. </marketspeak>
One day, during the course of continuing my Foursquare mayorship of the local bagel shop, I decided I’d go ahead and casually glimpse at what Foursquare was doing on my Android handset. I nohup’ed tcpdump in a terminal session, “checked in” to said bagel shop, and enjoyed my breakfast. Upon returning home, I copied the packet trace from my handset and analyzed it in Wireshark. Amidst the XML flying back and forth between the client and server, I noticed this:
GET /v1/checkins?geohacc=10000.0 HTTP/1.1
User-Agent: com.joelapenna.foursquared 2010011401
Host: api.foursquare.com
Connection: Keep-Alive
Authorization: Basic emFjaEBzb21lLnRsZDpteXBhc3N3b3JkWhat’s troubling here is the “Authorization” header, and the first parameter, “Basic”. In the case of “Basic” authentication, the client typically provides its credentials in the form of a username and password, which are concatenated together, separated by a colon, then encoded using Base64. For example, a username of “jrhacker” and a password of “secret” becomes “jrhacker:secret”. This is then Base64 encoded, resulting in “anJoYWNrZXI6bXlwYXNzd29yZA==”. Of course, Base64 encoding is only that — encoding. Using the Base64 encoded string from snippet above, it’s quick and easy to get credentials:
quine@durandal% echo "emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk" \\
| openssl enc -base64 -d
zach@some.tld:mypasswordSo, effectively, the official Foursquare application for Android utilizes HTTP Basic Authentication over a plaintext transport (HTTP). Attacks against the cellular network notwithstanding, the credentials are still fairly safe so long as they’re not going over WiFi. However, most WiFi enabled handsets will give priority to WiFi connections when they’re enabled, meaning the user’s credentials would be exposed to trivial sniffing attacks. I’ll recreate this simple Foursquare scenario and dive just a bit deeper after the bump.
