Category Archives: Uncategorized
Rochester Security Summit
If you live in Rochester, October marks the time of year when you once again prepare for Winter and and attend the Rochester Security Summit. Since 2006, RSS has been organized by the local chapters of OWASP and ISSA, and other interest groups like RIT, University of Rochester, and local businesses. The conference has three tracks depending on your background an interest: Business, Infrastructure, and Application. Jason Ross and myself will be presenting, both on Android.
So, let me get my plug out of the way. My presentation is on Android’s security design, auditing tools and techniques, and some real world examples. The take away from my talk will hopefully be a better understanding of Android security from the perspective of an enterprise, and tools necessary to be able to audit your own devices and apps. Presentation details here.
Jason’s talk on Android malware will include the tools and techniques he uses to perform research. He’ll also give a break down of some of the recent variants that we’ve seen in the wild. Presentation details here.
Some of the other interesting ones to check out are Gerry Brunelle’s two talks on rootkits, and Rel1k David Kennedy’s “Making Sense of (in)Security.”
This year, we’ll be at the Hyatt, which is a nice big hotel in the empty shell that is downtown Rochester. When you’re done with RSS for the day, and tired of the business environment, you should join us for a couple of drinks where we sit on a large wall and protect the city from White Walkers Canadians.
Skype 5.5 and New Hidden Emoticons
WARNING: This post is humorous (and not very technical) in nature. Please don’t take anything that follows seriously.
With that warning out of the way, we all know that Emoticons are a very serious topic. When Skype updates their emoticon set the Internet takes notice. When Skype announced new emoticons, they included a bit about two new “hidden” emoticons. With something this important hidden, there can be no rest until they have been discovered.
Skype encrypts and obfuscates their binary to prevent reverse engineering (and perhaps to compress it, etc.). Using the very powerful hacker tool, “Process Explorer” I was able to dump the process image. Using another advanced hacker tool, “strings” I was able to find the emoticon list. With a bit of spam to my co-workers I found a couple of hidden emoticons (zilmer) and (hollest). Zilmer and Hollest appear to people that were, or are, associated with the organization behind Skype.
Full Skype 5.5 emoticon listing:
(mooning) (u) (skype) (skype) (punch) (call) (talk) (mp) (mp) (mp) (~) (~) (o) (o) (e) (zilmer) (hollest) (wfh) (toivo) (bug) (wtf) (smoking) (smoking) (smoking) (rock) (poolparty) (poolparty) (finger) (fubar) (drunk) (swear) (headbang) (headbang) (*) (ninja) \o/ (d) (beer) (beer) (^) (flex) (flex) (cash) (cash) (pi) (pi) (coffee) (tmi) (bandit) (music) (tumbleweed) (sun) (rain) (rain) (F) (heidy) (heidy) (lalala) (lalala) (lalala) (lalala) (h) (highfive) (highfive) (highfive) (handshake) (n) (y) (y) (emo) (waiting) (waiting) (waiting) (shake) (nod) (smirk) (happy) (whew) (rofl) (bow) (think) (clap) (chuckle) (chuckle) (makeup) (makeup) (hug) (hug) (wait) (envy) (angel) (devil) (facepalm) (facepalm) (wave) (wave) (wave) (nerd) (mm) (mm) (mm) (worry) (party) (wasntme) (angry) (doh) (puke) (yawn) (yn) (yn) (yn) (yn) ]:) (inlove) (inlove) |-( |-) :^) :$ 
:* 
(:| ;( 
:O 
:D 
A few classic emoticons get rendered by WP here. So, please do enjoy that.
If you use Skype a lot check out Tattler.
@bitexploder
Intrepidus crew: Blackhat-Defcon Vegas next week
The entire crew will be there Tuesday-Sunday! Most of us are staying the entire time at The Rio but we have a few things going on at Caesars.
- Tuesday – Arrive, the FNGs to fetch supplies.
- Wed-Thurs – @caesars in sessions/ or at the cabanas/or booth.
- Thursday-Sunday – Find us at The Rio (or In-N-Out)
- Thursday, Early morning: – We are doing our own trapshoot. The Defcon shoot was just too massive last year. This is a competitive group that likes to keep score!
- Friday – Hack Cup, hopefully no injuries this year! - https://sites.google.com/site/securitytournament/
If you don’t find us in sessions or hallway-con, we are probably recovering in one of the two cabanas we rented out. If you are not staying at Caesars but still want to come hang out, stop by our booth to get a cabana pass.
Cheers,
-higB
BeaCon
Last weekend Corey, Zach, and I went to BeaCon, organized by MassHackers. This was one of the most fun and interesting conferences I’ve been to this year, and I know other people there felt the same way. It was cool to talk in front of such an approachable and lively group of people and overall a great experience.
All the talks were good, but there were a couple that definitely stood out. Dan Rosenberg and Jon Bieberheide‘s talk on bypassing grsecurity/PaX was clever, super 1337, and full of new techniques, like Rosengroping. Schuyler Towne’s talk on the history of locks was informative and showed some clever ways lock manufacturers could still protect their customers who had to register their keys with the Stasi. One of the cooler designs included a set of 4 dials around the main lock cylinder which had to be set properly for the lock to be unlocked. Once the Stasi found out about this, people had to register the combination, as well as the key. To counter this, the locks were built such that the combinations could be easily reset. While this didn’t stop the Stasi from invading citizens’ privacy, it certainly delayed them in entering citizens’ homes.
Corey and I gave an introductory talk on NFC covering some of the hardware basics behind the readers and tags, the ISO 14443 A standard, prior research that others have done, and some cool haxx. Corey demo’d a malicous “Google Places” poster.
A big Thank You to Zach Lanier, Jack Daniel, and the Mass Hackers for putting on a great conference! Hope to see you guys up there next year.
Cheers,
Max
Mallory Webinar Followup
First, we would like to thank everyone that attended our Mallory webinar. Mallory is Intrepidus Group’s in-house developed Man in The Middle Tool (MiTM) that we use to test mobile devices and applications. Several excellent questions were asked during this webinar. In response we have written up a guide to using the Mallory Minimal virtual machine and are distributing the Torrent for this virtual machine here.
First, download the [download id="269" format="2"]
Once you have the VM check out the Mallory Minimal VM Guide.
The guide walks through common setup scenarios with the virtual machine. You may also be interested in the SETUP document for Mallory if you want to build a virtual machine from scratch.
Cheap printer cartridges! Really.
We have a Lexmark Interact S605 printer in the office and when it shows the “Black Ink Cartridge Low” warning, I can’t help thinking… “cha ching, $25 to Lexmark”. The S605 takes the 100XL line of printer cartridges ($23.49 on Amazon). While reading reviews for the 100XL, I came across one from M. Walters pointing to the 105XL (physically identical to the 100XL but about 1/5th the price at $4.84 on Amazon). He or she claimed there is an RFID tag under the label which identifies the chip. We decided to try it out and, sure enough, M. Walters was right:
The 105XL cartridge fits just fine.
Whoops… we get the “unsupported cartridge” error when loading in the unmodified 105XL
Here are the RFID tags under the labels — we’re swapping the 100XL’s RFID tag with the 105XL’s tag.
Bingo! The cartridge now successfully authenticates to the printer, but it looks like the printer keeps track of each cartridge and its ink level. Still, we were able to print just fine with the new cartridge.
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.
Top 5 iPhone Application Development Security Issues
Since Apple released the iPhone in 2007, it has become one of the most dominant mobile phones in the market. In fact, Canalys forecasts Apple capturing 21.3% of the mobile market in 2010. The iPhone has seen quite a few significant platform security issues along the way. There has been a continual effort on jail breaking (gaining complete control over) the iPhone, and unlocking it (allowing it to be used on any GSM provider). Much of the security news related to the iPhone focuses on the platform itself, while less attention has been paid to individual applications in the app store (and how they are developed). What are the most common security risks affecting iPhone applications? Based on our experience testing iPhone applications we have compiled a top 5 list of security issues for developers:
1.) Sensitive data unprotected at rest – Mobile applications cut right to the heart of software functionality to provide what users absolutely need when they are on the move. For many applications, this can involve displaying, or even storing, sensitive data. Many iPhone applications read and display sensitive data, such as medical lab test results, or personal and business oriented financial data. For example, the Care 360 Mobile iPhone application allows doctors and medical professionals to retrieve and view lab results from Quest Diagnostics. Many large banks also provide mobile applications to provide better user experience than the Safari web browser for online banking. These applications handle some of the most sensitive data (medical and financial) most users will ever possess. Additionally, many applications also provide a variety of “remember me” functionality. Keeping this data secure and out of the hands of a malicious adversary is therefore of paramount importance for both the user and the application provider.
The solution to this problem is careful architecture design with a risk-based approach to help decide the security posture the application has towards data storage. Once the risk has been determined, it is essential to protect sensitive data that must reside on the device using a combination of strong cryptography and the Apple Keychain services, or equivalent cryptographic constructs, to protect this sensitive data while at rest.
2.) Buffer overflows and other C programming issues – The iPhone development platform is primarily Objective-C based. Objective-C provides a much cleaner environment for the programmer when compared to C. It inherently prevents many common C programming errors, which can result in exploitable bugs and flaws in an application. If a developer writes an application purely from within the confines of Objective-C using the Foundation, UIKit and other pure Objective-C frameworks, the application is relatively safe from most of the security issues that afflict C programs. For example, the NSString class prevents buffer overflow bugs effectively in most cases (assuming there are no flaws in the underlying NSString implementation). Another key point to the pure Objective-C environment of the iPhone is the fact that all object allocations go on the heap, which helps prevent stack overflows since directly programmer controlled memory does not live on the stack. The developer is responsible for allocating and deallocating objects, but the complexity is largely hidden from the developer compared to a C implementation.
However, some parts of the iPhone SDK require the developer to revert to standard C. This is an all bets are off proposition that eliminates the safety provided by the Objective-C platform. It is common to build and include C libraries in an iPhone application to avoid re-implementing code (and it is often the right choice from a time to market standpoint). This means going from relatively safe Objective-C libraries and moving to less safe C style strings for libraries like SQLite, a core part of many iPhone applications, and . Buffer overflows are one of the various issues that plague C programs. Vulnerabilities can stem from heap overflows, format string attacks, integer overflows, and other more subtle issues that are relevant when developing in C for iPhone.
Generally avoiding C libraries when at all possible is ideal. However, when C and C libraries are required developers must follow best practices derived over the lifetime of the C programming language. When observing best practices mistakes may still occur. Development teams must use safe string libraries and individual developers must understand the risks and vulnerabilities that can occur when writing code in C.
3.) Secure communications to servers – Almost every useful application that handles sensitive user data will connect back to some server component. Developers are, thus, faced with the challenge of having to protect sensitive data in transit as it traverses the Internet and sometimes even insecure wireless media. This is done using encryption; that must be implemented correctly.
Effective encryption entails avoiding reinventing the wheel and using trusted libraries that have been thoroughly reviewed. The iPhone SDK is, largely, like any other SDK regarding its SSL libraries. Developers must take care when using the URL loading library as the way the applications use the libraries in a development build or configuration will typically differ from proper usage in production. The default state of operation for the URL loading library is to fail on an invalid server certificate. However, during development it is often required to use an invalid certificate. Failure to use the libraries properly can result in weak client to server communications that allow a malicious adversary to compromise client to server communications.
4.) Patching your application – The App Store could be your worst enemy, a proper risk assessment of an organization’s tolerance for risk should be conducted to determine if the app store policy will match up with, and be acceptable, for any given application. Apple maintains tight control over the App Store and it will not be possible to issue a release in a very short (24-48) hour period in most cases. The Apple approval process generally takes at least a week. If the application has any issues that would cause it to fail, the approval process of the new build could take weeks to reach customers.
Unfortunately, there is very little that an organization can do regarding the risk associated with this issue. The best bet is to ensure that developers have a clear understanding of app store policy and that the testing process is thorough and proactively identifies issues that would cause the application to fail the approval process.
5.) The platform itself – User awareness is also a critical component of application security. Users often perceive and treat their mobile, Internet connected, devices with a different level of care compared to a laptop or desktop. Password policies, anti-virus software, and at least some awareness that their computer may contain sensitive data and that it requires protection is the norm for most users. Mobile devices are often lost, not password protected and get treated with a lower level of security awareness. This means that a user could easily lose their phone to a malicious individual and have their sensitive data compromised.
Thus, it is important to attempt to raise the mobile user’s awareness of the risks they are exposed to through well constructed documentation and application design. A mobile user that is more security conscious may take efforts to secure their environment more, such as by using a PIN or pass phrase to secure their device, and subscribing to Apple services that can help locate and disable lost or stolen devices. From a developers perspective the key thing is to alert the user when they are making security sensitive actions via visual cues and or dialogs/text. Users will generally do whatever is quickest and easiest for them. Developers must design these features to be as unobtrusive as possible.
Security Dialogs and Graphics
Something I take for granted working in the “IT industry” are the many different security dialogs and graphics I encounter. I am generally wise enough to interpret the security graphics and input choices put before me and make a well reasoned decision about the consequences of taking a particular action. I know enough about SSL and how the major web browser’s implement it that I can tell when something is wrong with the SSL on a site. However, I am not a typical computer user. I sat down and thought about the sheer quantity, type and variety of security dialogs out there. Many times a user is one security dialog or missed visual cue away from a security disaster. So, I started collecting images of various ways software indicates to me some significant security setting is set or a security event just occurred. What I saw, when comparing the various images, was quite interesting.
Whenever I want to know if something is to technical or tricky for the common user I think to myself, “would my mom understand this?”. With that thought in mind I am going to present some address bar images from three popular web browsers. Look at these images carefully and ponder them for a moment before continuing.
There are some very interesting things happening here. In my opinion the complete lack of consistency is the first, huge problem. Every browser looks different in some significant way. For EV certificates, Firefox has a green bubble. Internet explorer makes the entire address bar green. Google Chrome makes the text for the company name green. Chrome and Firefox show the company name. Internet explorer does not show the company name. Why even bother with an EV certificate when the average user will have no clue? What value is this really adding. What are the odds a user will click through and explore the details of the certificate?
Next up we have standard SSL. Two browsers incorporate a lock icon (Internet Explorer and Chrome). Firefox uses a blue bubble? Why blue? Should I trust the blue bubbles? What does that “s” in http mean? What happens if a user forgets to type it? Is this all documented somewhere in easy reach for a user or is the average user left to their own devices?
For final comparison we also have a few HTTP addresses. Notice that we use the lock as a favicon. Will the average user really be able to distinguish that these are not secure sites? Some of my family members don’t even use the URI bar (in fact, it’s turned off). In their mind the way you get to yahoo, is by first googleing for yahoo.com, then click the first link. Forgive me if some of these questions are hopelessly naive sounding, in my estimation, they are completely fair from the perspective of most browser user’s.
Next up we have some some dialogs and graphics from the iPhone:
The thing that is striking to me is that this dialog is all that separates a user from being man in the middled. There is no wording or verbiage to even indicate this is a security dialog. This dialog presumes the user knows what a “website certificate” is and the implications of said certificate being invalid. I am guessing most users will click right on through. And for comparison the small lock in the upper left corner is the only indication (other than the s, in https) that the user is “secured”
Superb. A tiny grey-ish lock. yet another different way the user is notified the site is “secure” or not. One tiny graphic. Finally, the browser on the blackberry gives absolutely no visual cues regarding the SSL status of the site. See the following screenshots for an example:
HTTP Site:
HTTPS Site:
Where is the lock? How will I know the site is secure if I don’t have a lock, a golden address bar, a green address bar, the company’s name in green, a blue or green bubble, a s in the address, or some other indicator that everything is OK? What is a user to do?
Away from the topic of browsers and their differing presentation of SSL security dialogs there are application permission dialogs. The following screenshots are from the BlackBerry OS (5.x).
Here the user is being asked to grant an application “Trusted Application” status. What is “Trusted Application” status? To BlackBerry’s credit it is one of the few dialogs that offers “Help” which further explains just what you will be granting this application. This is actually quite critical as most dialogs or security visuals don’t give the user any way to easily learn more.
Next we see another permission dialog from BlackBerry. This time it is trying to access “phone information”. You are not told what information until you click “Deny” as shown below. How can we expect users to make rational choices if they are not given the opportunity to discover what exactly they are allowing or denying?
Next is the standard windows UAC dialog:
Uh oh, an “unknown publisher”. Will the average user know that if the publisher is unknown that means that the executable has not been digitally signed using a code signing key? Will they know they are missing out on the opportunity to validate the binary has been signed with a certificate that has been verified by a trusted third party that lets them know everything is alright? One final image, and one of pieces of research on a previous blog post:
My conclusion and the point I am hoping to drive home is that application developers all have a responsibility to make sure a user can understand the implications of what they are clicking through. My goal is not to make any particular piece of software look bad. It is great that these dialogs and opportunities for security interaction exist at all. What is not so great is that users are often not informed enough about what these decisions represent so they are ignored or clicked through to make everything keep working. Strong messages and a way for the user to learn more about what is at stake are key. Command line SSH clients often have a very blunt approach:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)!
At the end of the day there is not an easy solution. Users are inclined to do whatever lets them accomplish their task at hand with a minimum of disruption. This means that helping them make the right security choice must also be minimally disruptive, and that can be a very hard task. It is something of a truism that usability often suffers for security features. It is “relatively” easy to design a secure system that is about as usable as a brick. It is much harder to design one that is easy to use and secure. Here is to hoping the software industry and information security communities can continue to advance the start of the art.
Jeremy
Reference: From the Sour Grapes Department at Microsoft: Summary: “Yeah, we know people REALLY hated Vista UAC, so instead of fixing it, we’ll just have some research guys write a paper about it” Start with RSnake’s coverage: http://ha.ckers.org/blog/20100317/effectiveness-of-user-training-and-security-products-in-general/
UPDATE: Reader Clerkendweller pointed me over to his excellent blog article on the rainbow of colors in IE8 with tab grouping.
