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.
Mobile Rooting Jailbreaking: Feature vs Privilege Escalation
I had the opportunity to take a very interesting Android Forensics course last week offered by ViaForensics. They’ve compiled great research and have developed some excellent tools for Android devices which can be a huge time saver for forensics analysis. However, I had not realized the degree to which the tools and analysis in that space right now are dependent on being able to obtain root access on the device. This reminded me of a side discussion that went on at DefCon 18.
Many of the ways to obtain root on a Android device require physical access and one can argue, pose a more limited threat for the end user. Some devices like the Nexus One even seem designed to be “developer” phones and allow users to flash the device with the firmware of their choosing. However, one of the first EVO 4G ways of obtaining root level access was from an APK download from unrEVOked’s website. Just by installing the APK, the application was able to root the devices. Clearly, most users would want the vulnerability this exploits to be patched before malicious APKs started to bundle this into their downloads (and it was patched). But at the same time, a number of users also want root access to their devices in order to customize them, investigate applications for privacy concerns, or test for other security issues. In the case of forensics analysis, root level access is needed to do the job.
The security industry has normally been fairly open about working with vendors to fix major security issues. What seems to be happening here is that there’s a growing trend in the community of even legitimate researchers, to hold on and not reveal their root level exploits. To some degree, maybe this is nothing new. However, I feel that if these attacks were found on standard desktop or server operating systems, the community would almost all largely support alerting the developer and getting a patch out to end users. These vulnerabilities would be seen as privilege escalation attacks and would need to be locked down. I don’t think its the same when it comes to closed or restricted devices. This could be an interesting discussion as more locked down devices are released.
And now with the FCC weighing in on jailbreaking, could the price-to-earnings ratio of a smartphone jailbreak skyrocket? Example: http://www.jailbreakme.com/faq.html If we are in the era of no more free bugs — what will be more lucrative for exploit developers and the budding entrepreneur? Giving away a free tool? Charging for a jailbreak app that they hope no one else reverses and puts out a cheaper tool? Or will the best dollar offer come from private exploit packs or organizations that intend to weaponize the vulnerability? Will we see the day when an smartphone exploit can buy you gold grill faster than an IIS/IE8 exploit?
cheers!
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)
Max’s 2010 Las Vegas BH/DC Summary
Hey, this is Max Sobell and I’ve been interning with Intrepidus Group this past summer. I just got back from my first Blackhat/Defcon with IG a few days ago. Corey summed up quite a few of the really good talks but there was one more that was particularly interesting. The WiMAX Hacking (https://groups.google.com/group/wimax-hacking) talk, from Pierce, Goldy, and aSmig feat. sanitybit was great.
For those of you who aren’t familiar with WiMAX, it’s a wireless broadband technology being deployed (and spreading rapidly) by Clearwire (and others, though Clearwire has the largest network). The team’s research was done on the Clear network, which Time Warner, Comcast, and Sprint all re-brand, though it is the same physical network. One thing I really liked in the talk was the emphasis on the hardware hacks and jailbreaks. They combined some hardware hacking with some VPN tricks to own a couple WiMAX devices and the captive portal page. The team was able to send fragmented packets though OpenVPN on UDP/53 without actually logging into the portal to get free WiMAX. Unfortunately, the downside is that the Location Based Services (LBS) from Clearwire (currently not very accurate and can’t be turned off) allow anyone bumming off the network to be tracked down by fellow users via a development key. One thing that confused the audience was the speakers didn’t qualify what they meant by LBS. In the context of their talk, they were talking about traditional signal strength analysis and antenna orientation. What was not mentioned is that these 4g WiMAX cellular radios also have a real GPS radios which is a requirement of E911. I would assume that the carrier has the ability to locate a device within meters based on the GPS radio.
Friday morning Corey, Mike, and I played in the Hack Cup soccer games on the Goal++ team along with DC Campbell, DC’s friend Judd, and Adam Pridgen. We sustained some early injuries, which left Mike scooting around the Riviera for the rest of the week in a motorized cart, but made it to the semi-finals with no subs. Unfortunately after that we had to stop playing because we lost DC to the airport and Judd had to go back to work. But watch out next year, Goal++ will be back! A big thanks to Nico Waisman for organizing the tournament and to Immunity for sponsoring it.
That’s it from me!
-Max
higB’s 2010 Las Vegas BlackHat DefCon summary
higB here.. I’ll keep my post mostly about the culture
Amanda did a great job making sure we were in the Palace tower (not the stinky Forum tower). It was awesome having help this year to organize the Intrepidus Group visit to BlackHat/DefCon. Every year we get bigger and every year the cat herding task is more challenging. Thanks Amanda! (and thank you Mac for organizing the shoot, more on this later…)
Some of our traditions are borrowed, but we have some of our own, too.
Tradition: The FNG list
If you haven’t brought an intern to Vegas with you I HIGHLY recommend it. In keeping with Intrepidus traditions, the FNG is required to fetch Vegas supplies.
Rules:
- The FNG can get you any reasonable supply.
- The FNG should avoid drug dealers named Doug.
- The FNG must have your list prior to Tuesday the 27th.
Max, thank you! You were awesome!
(LtoR: Corey, Max, Zusman, Pridgen)
Tradition: Custom Con Tee Shirt
One fond memory I have of my early days at FS was rocking a freshly designed con shirt. Prosise and crew put in effort to get a cool design for us to wear every year. We carry on a similar tradition here. (The shirt is usually packed with inside jokes, so apologies in advance.)
Click to see the design
Tradition: Death via Maggiano’s
If you didn’t see any of us Friday night, it’s because we got close to nearly killing ourselves at Maggiano’s. Seriously, we have to stop going there. Every year it’s the same thing, followed by a direct trip to the hotel room to moan and groan. I was down for the count and didn’t leave the hotel room.
*New* Tradition: DefCon Unofficial Shoot [Link]
My first DefCon was in 98. My first participation in the DefCon shoot was 2010. Thanks to our guy Mac for organizing and, of course, Deviant and crew. The event was well organized, but I think they were a little worried when they saw the target we brought…
Of course we knew Mac and Jim would be great marksmen, but we were all a little creeped out by how awesome Doug was. (If that is your REAL name, Doug…mister “i’ve never done this before…”)
This is getting a little long so I’ll go rapid fire:
Hot:
- Ridley’s Photos: check em out
- Jeremy Allen and Raj Umadas BH talk on Mallory
- Zach’s BSides talk
- #maggianos
- taqueria canonita venetian
- SecurityTwits party
- DefCon Shoot
- Craig Heffner’s “Millions of Routers” talk (seriously)
- WiMax talk: Pierce, Goldy and aSmig
- Blake Self and Bitemytaco’s Docsis talk
- Blue EFF teeshirt
- This year’s badge
Not Hot:
- The Riviera (gross bathrooms .. yay Rio?)
- Goon track change on Saturday screwed over people in line.
- Last year’s badge (it was bad enough that it deserved another mention)
- FastlapLV broken and slow go-karts
I hope to see everybody next year!
-higB
(LtoR: Dean, Aaron, and Rohyt @ Caesars.)
Corey’s 2010 Las Vegas BlackHat DefCon summary
Hey, Corey here, I’ll get the Intrepidus Group con wrap up started, followed by some more posts from the crew.
The IG gang spent last week out in Vegas for the annual BlackHat and DefCon trips. While I missed a handful of high profile talks (like Barnaby Jack making it rain twenties) and even one or two of the talks from the NYC security crew (sorry Marcin, didn’t realize it was a joke when you told us to leave), there were still a number of them that were interesting and I’d recommend checking out when you get the chance.
I’m amazed there’s not more buzz about Craig Heffner’s awesome “How to Hack Millions of Routers” talk. He demonstrated a DNS rebinding trick that appears to be very pervasive across a number of devices. It can allow you to remotely access services on the internal interface of the device. There’s a few conditions required to allow this to happen, but it brings up a point we recently dealt with for one of our servers. Instead of relying on just firewall rules to block a port you don’t want exposed, lock down the service to only listen on the interface you want. So for that webserver you should only hit over an SSH tunnel instead of seeing this in netstat
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
and then having a firewall rule to block access, lock it down to just the loopback interface:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN
There were quite a few mobile security talks this year. While the demos failed, I think Grugq’s slides on GSM base station attacks give a great GSM overview for anyone who is unfamiliar with some of the key terms and architecture. Of course Chris Paget’s talks are always entertaining. If you’ve been keeping up with his posts or previous GSM work, the talk was pretty much what you expected. I think one of his best posts recently was just after the iPad hack and really making clear the relationship between ICCIDs and IMSIs here in the US.
Hats off to the Trustwave crew for the Android rootkit and releasing their proof of concept. They did a great job, but I’m a little surprised how much response this has gotten. It seems like this was just waiting for someone to do since day one of Android. Maybe it’s just people don’t realize Android runs Linux under the hood. To me, it just always seemed like a forgone threat that if you’ve got root on a Linux box, you’ll probably be able to have some sort of root kit installed. Guess you need a working demo to drive home the point sometimes.
The Lookout team also had a good overview of Android permissions and some ways around a few of them. They’ve come up with a system for two way internet communication without asking for the INTERNET permission in their manifest.xml file. We’ve been testing their other claim about rebooting the device by creating over 2000 toast messages. While it works in our emulators, it seems the Nexus 1 and Droid Incredible allow the user to force close the application when it starts acting up.
One of the key take always though was to make sure your Android apps in production don’t dump too much into the logs. We’ve been surprised by the wealth of information we’ve seen Android applications spew, which is great for us during a review, but is not fit for a release version. The talks brought up a good point that other apps can access the log file and mine for data. They can install and just ask for the READ_LOGS permission and the consequence of that for most users would not be obvious.
And no BlackHat 2010 wrap up would be complete without a mention of Mallory. I know others will post more on that, but in case it wasn’t stressed enough, Mallory is a huge time saver if you’re testing mobile applications. The guys did a lot of extra to make sure even SSL wrapped protocols aren’t a problem to get between and man-in-the-middle. It’s really a great tool and cuts down on so much setup time after you’ve got Mallory set up once. (If you’ve ever experienced the pain of realtime editing a packet stream via netsed or ettercap, you will understand why Mallory is the way to go…)
Oh, and in case you missed our t-shirts this year, hit up HigB soon. You want a shirt? He can get you a shirt, believe me. There are ways, dude… but there’s only a few left.
Till next year,,,
(Left to Right: Corey, Clark, and Heitzman)
Identifying Malware via User-Agent Headers
Can you tell if a host is remotely infected just by a single HTTP request? For some malware the answer is yes.
By now, I think our readers are pretty familiar with PhishMe. As you can imagine, we see a lot of hits to PhishMe from a variety of browsers. And even better, we see a lot of hits to PhishMe from a variety of browsers where the user is likely to click on things. Each time a user makes a requests a website, the user’s browser sends a “user-agent” string to the web server as part of the request. A simple user-agent string looks like:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Here’s a quick break down of what this string tells us. The Mozilla/4.0 portion indicates a Mozilla-based browser. This user is running Internet Explorer 7.0 and Windows NT 5.1 (Vista). You can check your user-agent here.
Now for Internet Explorer, it’s pretty easy to append information to this user-agent string by editing the registry. You will typically see a number of .NET related items coming from a normal user-agent header on a Windows system.
Where it gets interesting is when we see user-agents like these next ones. It seems that some viruses and malware (or “potentially unwanted software”) insert their name or a token into the user-agent string. Here’s some examples we found:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AntivirXP08; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; PeoplePal 7.0; .NET CLR 2.0.50727)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727)This last user-agent string shows the user’s browser is infected with FunWebProducts which are not nearly as much fun as they sound.
If the malware instead appends a token to the user-agent string, this token could be used to track the user from site to site or to trigger certain behavior on malicious websites. We identified several pieces of potentially unwanted software and tallied the number of infected users using PhishMe. The graph below shows the most common pieces of malware found in user-agent strings:
We looked at IE 6, 7, and 8. Using this total number of “infected” users, we broke down the infections into browser version and divided by the total number of users running each browser version to get the percentage of each version’s population which is infected. As it turns out, the portion of infections is pretty similar across all IE versions. Isn’t IE 8 suppose to protect users much more than IE 6? This is a bit of a surprise, but suggests something we’ve known about the current state of attacks. You can have strong software controls, but security still depends as much on the user operating the software safely. Even given a browser that is relatively hardened against threats, users must know how to identify sites with malware and phishing schemes in order to stay safe. Patching and updates are important, but so is user awareness.
PhishMe clients can contact our support team for an analysis of your user base.
Front Range OWASP Conference
I’m just finishing up my third trip to Denver to speak at the Front Range OWASP Conference (FROC). This time I was corrected, as I was told that FROC is a local conference, and not a regional one. It had me fooled. The amount of attendees definitely threw me off! At any rate, David Campbell, Kathleen Thaxton, and others definitely put on a good event, and this one is going to remain on my schedule for years to come.
This year Intrepidus had two speaking slots at FROC. In the application security track, Raj Umadas and Aaron Rhodes covered some advanced man-in-the-middle techniques used for software testing. They flexed some muscle with a few Intrepidus in-house developed tools, showing how easily some non-plaint text protocols (like SSH) can be intercepted and tampered with. Stay tuned for more on this topic, as Raj and fellow Intrepid-dude Jeremy Allen will be presenting additional content on this subject at BlackHat in July.
In the emerging technologies track, Zach Lanier and I discussed our current opinions/observations on the mobile application security space, as well as the variety of testing techniques we employ when testing apps written for various mobile platforms. For example, while it might be easy to extract and decompile a RIM application to perform some static byte code analysis, the same technique would not apply to C/C++ binary client written for Windows Mobile. In this case, it can be faster (easier) to understand and break the application by analyzing/tampering with its network traffic. We followed this up with a number of case studies based on mobile app assessments we’ve performed. We’ll be continuing our research and presenting further, additional content at the New York State Cyber Security Conference later this month, and also in October at SecTor in Toronto.
Lock down your Android APK permissions
We’re not planning on becoming a “how to” blog anytime soon, but thought this could be interesting to a number of you with Android phones and a love of the 3rd party apps (Hi Pandora… you look mighty fine today). Android users are probably used to seeing a list of permissions an application desires just before you hit that big install button in the Android Market. Unfortunately there’s not much of a way to figure out why an application wants particular permissions, nor can you choose to grant an application some permissions and not other ones. (Like you can do on a RIM device.) It’s just “here’s what the app wants”: install or don’t install. If you want a little more control on the permissions an application is granted, an awesome little tool called “apktool” can help you out.
Let us take the Bubble Burst Lite game as an example of a free app that I may want to try out, but don’t want to give too much access to my phone. In particular, I don’t want it reading my contacts or sending SMS messages to my friends about how badly I’ll crush them with my bubble popping skills. To lock this down, you will want to grab the com.androgames.BubbleBurst.apk file and install apktool (I’ll assume you already have adb installed by now). Next, run the following command to extract the APK and “decode” the application.
apktool decode com.androgames.BubbleBurst.apk BubbleBurstLite
You will notice in the new directory that was just created there is an AndroidManifest.xml file which you can read in any text editor (while there are other tools that can extract this info from an apk, I’m a big fan of this tool and the format it uses). Next, you will see the “uses-permission” tags typically at the end of the file. In our case, the app is requesting four permissions: INTERNET, ACCESS_NETWORK_STATE, RECEIVE_SMS, and READ_CONTACTS.
Next, remove the tags for the permissions you don’t want the application to have. In my case, I’m going to remove the permissions for RECEIVE_SMS and READ_CONTACTS. You can also pull out things like the “SMSReceiver” tag a little higher up in the file. Save your changes, then head back to the command line to have apktool rebuild the application.
apktool build BubbleBurstLite
This step will create an “out.apk” file in the dist subfolder. But before you can install it on your phone, you must first sign the apk. In this example, I’ll just use my own self-signed key that I’ve previously created.
jarsigner -verbose -keystore my-release-key.keystore out.apk igkey
(Raj, a fellow Intrepidus Group colleague, made a good point to me at this step. If you sign all your apps with the same key, and developers knew that and coded for it, they could have permission to communicate with each other and share data… and possibly, one day rise up against you. Help do your part to keep Cyberdyne Systems at bay and sign each app with a unique key.)
Now back to our changes, plug in your device and finish things off with the “adp install out.apk” command. You will now notice when you view the application’s permission in the Settings->Applications->Manage Applications menu, the unwanted permissions are gone. Play away, secure in the knowledge that any bubble blasting smack is going to come from you and not from the application covertly sending SMS messages in the background.
Your embedded web server is so 2003
Meet my new favorite web server, the GoAhead WebServer. We’ve been playing around with a handful of embedded devices recently and most developers now give you some sort of web interface to configure them over. Turns out we’ve been seeing a lot of them with GoAhead’s web server, which hasn’t had an official update from the vendor since 2003. This tiny guy is written in C and the source code is downloadable (although you do need a license).
While some vendors have highly customized the server, others are running it fairly as-is with just including their own customized Active Server Pages (ASP). What is interesting from a security stand point is that a number of recent devices we’ve seen are still using old versions of the web server. Old versions that include vulnerabilities like “%5C” directory transversal attacks and changing the file extensions of a request from “.asp” to “.as%70″ to view the server side source. DoS attacks are likely to work (although I think that can be a difficult issue for any embedded web server) and you are also likely to find CSRF attacks against the applications running on this web server since developers will need to roll their own mitigation control for this. Here’s a link to the release notes with security fixes from the latest version of the GoAhead WebServer, updated December 2, 2003.
http://data.goahead.com/Software/Webserver/2.1.8/release.htm
We are all aware how important patching systems can be. My home NAS device got a firmware update a few months ago that I applied. However, even though it’s up-to-date with my vendor, it’s still vulnerable to some issues which are over six years old because they haven’t patched the code from their vendor. So take a look at your embedded device and don’t be afraid to lob some 2003 sauce at them. You might find that it still works.
