Category Archives: Uncategorized
How to respond to spam…
This is a bit different from our usual blog content. When I need a break, I take a moment and do a bit of creative writing. This writing typically surfaces as a creative response to some targeted spam. This is one of those responses:
Please keep in mind I wrote this tongue in cheek and I don’t really feel this way about developers.
Hi Jeremy,
I’ve came across your company’s profile on LinkedIn and thought that you might be interested in hiring mobile software developers.
We have an Android developer available which is supposed to work remotely under your managerial control from our office in Ukraine.
Our company finds, employs and supports client’s own software development teams, which work under the client’s 100 % managerial control from our office. Companies from the Netherlands, Norway, Germany, Belgium, Denmark and the USA already have their teams in our office (references on demand).
Is this something that might interest you?
P.S. PHP, C++, Microsoft .Net developers are available for hire (CVs are available).
————————————
Dear Jane,
My organization is involved with mobile security in very special way. We are, what you would call, ‘White hat hackers’. What this means is that we work with organizations that develop mobile applications. Mobile applications are new, but they are not terribly hard to develop. So I will now tell you a story.
This is a story about Joe. And he is a different kind of hacker from the typical Intrepidus Group hacker. He is a hacker in the more traditional sense of “one who hacks” or someone that writes code. Joe is an overworked developer at a large insurance company.
Joe was sitting at his desk waiting for his latest bug fixed to be reviewed by the QA team. Joe checked the clock in his computer task menu. Only 3:45, and already, he was falling asleep. He knew it was going to be tough to finish the day. There were a couple more blocking issues on his application that he knew had to be fixed before it could be released. He performed a quick mental calculus on the level of effort to fix those remaining bugs. He knew his manager would not be happy, he estimated over two days to fix the remaining bugs.He got a little hot under the collar just thinking about the deadline, which was passed a week ago. His manager was under pressure to release the new mobile application. The executive management team was keen on “engaging” their customers in a mobile fashion. Joe had once worked with Objective-C and when the discussion of the insurance company’s mobile application came up; Joe figured he would get a chance to do some cool work. He dumbly volunteered to be an iOS developer. His life was never quite the same since that moment. He has been straining to learn the framework and finish the application on time. He had to constantly fight feature creep and outlandish expectations about what a mobile application could do. The executive management team seemed to be under the impression that the heavens would shine down upon their mobile applications and that the damn thing would just fart rainbows and solve the company’s problems.
Joe ruminated on this a bit longer. 4:00PM. He pecked away at his keyboard slowly to appear productive. His mind was racing. He couldn’t wait to get home and see the latest episode of Jersey Shore. He reviewed his bug list one last time. He realized there were several security issues in the list. He changed their priority to low and justified this with the explanation that mobile applications were inherently insecure and unimportant so it would be silly to spend time working on security bugs.
Joe took a break and headed to the restroom. He knew he could kill ten minutes this way. He finished his business up and checked his complexion in the mirror. Damn, Joe thought, the male pattern balding was getting worse. His wife’s constant nagging was finally getting to him. He would have to go visit a hair loss center. He did not want to admit it, but a lot of his identity was tied up in vain things, such as his looks. He was legitimately afraid his wife might not love him as much if he didn’t lose a bit of weight and fix this hair condition. Maybe getting a Camaro SS, one of those new ones with 500 horse power, would make his wife think twice. Joe sighed and headed back to his desk. This was going to be a long 50 minutes. Eventually the time passed and he meekly filed out with everyone else. He hopped into his aging Toyota Corolla and battled it out for an hour with all the other poor citizens in the strangling traffic Utopia.
Developers like Joe are what keep us employed. They don’t care about security more than they have to.
Thanks,
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.
