Neohapsis Labs

By Patrick Toomey

Direct link to keychaindumper (for those that want to skip the article and get straight to the code)

Last year I pushed a copy of Keychain Dumper to Github to help audit what sensitive information an application stores on an iOS device using Apple’s Keychain service.  I’ve received a few issue submissions on github regarding various issues people have had getting Keychain Dumper to work on iOS 5. I meant to look into it earlier, but I was not able to dedicate any time until this week. Besides a small update to the Makefile to make it compatible with the latest SDK, the core issue seemed to have something to do with code signing.

Using the directions I published last year the high level steps to dump keychain passwords were:

1. Compile
2. Push keychain_dumper to iOS device
3. Use keychain_dumper to export all the required entitlements
4. Use ldid to sign these entitlements into keychain_dumper
5. Rerun keychain_dumper to dump all accessible keychain items

./keychain_dumper -e > /var/tmp/entitlements.xml
ldid -S/var/tmp/entitlements.xml keychain_dumper

However, on iOS 5 you get the following error when running ldid:

codesign_allocate: object: keychain_dumper1 malformed object
(unknown load command 8)
util/ldid.cpp(582): _assert(78:WEXITSTATUS(status) == 0)

Looking around for the code to ldid, I found that ldid actually doesn’t do much of the heavy lifting with regard to code signing, as ldid simply execs out to another command, codesign_allocate (the allocate variable below):

execlp(allocate, allocate, "-i", path, "-a", arch, ssize, "-o", temp, NULL);

The Cydia code for codesign_allocate looks to be based off of the odcctools project that was once open-source from Apple.  I am unclear, but it appears as though this codebase was eventually made closed-source by Apple, as the  code does not appear to have been updated anytime recently.  Digging into the code for codesign_allocate, the error above:

unknown load command 8

makes much more sense, as codesign_allocate parses each of the Mach-O headers, including each of the load commands that are part of Mach-O file structure.  It appears that load command 8 must have been added sometime between when I first released Keychain Dumper and now, as the version of codesign_allocate that comes with Cydia does not support parsing this header.  This header is responsible for determining the minimum required version of iOS for the application.  If someone knows a compile time flag to prevent this (and possibly other) unsupported header(s) from being used let me know and I’ll update the Makefile.  The other options to get the tool working again were to either update odcctools to work with the new Mach-O structure and/or figure out an alternative way of signing applications.

Historically there have been three ways to create pseudo-signatures for Cydia based applications (you can see them here).  The third uses sysctl, and is no longer valid, as Apple made some changes that make the relevant configuration entries read-only  The second option uses ldid, and was the approach I used originally.  The first uses the tools that come with OS X to create a self-signed certificate and use the command line development tools to sign your jailbroken iOS application with the self-signed certificate.  It appears as though the tools provided by Apple are basically the updated versions to the odcctools project referenced earlier.  The same codesign_allocate tool exists, and looks to be more up to date, with support for parsing all the relevant headers.  I decided to leverage the integrated tools, as it seems the best way to ensure compatibility going forward.  Using Apple’s tools I was able to sign the necessary entitlements into keychain_dumper and dump all the relevant Keychain items as before.  The steps for getting this to work are as follows:

1. Open up the Keychain Access app located in /Applications/Utilties/Keychain Access
2. From the application menu open Keychain Access -> Certificate Assistant -> Create a Certificate
3. Enter a name for the certificate, and make note of this name, as you will need it later when you sign Keychain Dumper.  Make sure the Identity Type is “Self Signed Root” and the Certificate Type is “Code Signing”.  You don’t need to check the “Let me override defaults” unless you want to change other properties on the certificate (name, email, etc).
4. Compile Keychain Dumper as instructed in the original blog post(condensed below):

ln -s /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/ sdk
ln -s /Developer/Platforms/iPhoneOS.platform/Developer toolchain
make

5. scp the resulting keychain_dumper to your phone (any file system reference made here will be in /tmp)
6. Dump the entitlements from the phone

./keychain_dumper -e > /var/tmp/entitlements.xml

7. Copy the entitlements.xml file back to your development machine (or just cat the contents and copy/paste)
8. Sign the application with the entitlements and certificate generated earlier (you must select “Allow” when prompted to allow the code signing tool to access the private key of the certificate we generated)

codesign -fs "Test Cert 1" --entitlements entitlements.xml keychain_dumper

9. scp the resulting keychain_dumper to your phone (you can remove the original copy we uploaded in step 5)
10. you should now be able to dump Keychain items as before

./keychain_dumper

11. If all of the above worked you will see numerous entries that look similar to the following:

Service: Vendor1_Here
Account: remote
Entitlement Group: R96HGCUQ8V.*
Label: Generic
Field: data
Keychain Data: SenSiTive_PassWorD_Here

Now, the above directions work fine, but after dumping the passwords something caught my eye.  Notice the asterisk in the above entitlement group.  The Keychain system restricts access to individual entries according to the “Entitlement Group”, which is why we first dumped all of the entitlement groups used by applications on the phone and then signed those entitlements into the keychain_dumper binary.  I thought that maybe the asterisk in the above entitlement group had some sort of wildcarding properties.  So, as a proof of concept, I created a new entitlements.xml file that contains a single entitlement

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
     <key>keychain-access-groups</key>
     <array>
         <string>*</string>
     </array>
 </dict>
</plist>

The above file lists a single entitlement defined by “*”, which if the assumption holds, might wildcard all Entitlement Groups.  Using the above file, I recompiled Keychain Dumper and proceeded to resign the application using the wildcard entitlements.xml file.  Surprise….it works, and simplifies the workflow.  I have added this entitlements.xml file to the Git repository.  Instead of first needing to upload keychain_dumper to the phone, dump entitlements, and then sign the app, you can simply sign the application using this entitlements.xml file.  Moreover, the binary that is checked in to Git is already signed using the wildcard entitlement and should work with any jailbroken iOS device (running iOS 5), as there is no need to customize the binary for each user’s device/entitlements.

The consolidated directions can be found on the Github repository page, found here.   A direct link to the binary, that should hopeful work on any jailbroken iOS 5 device can be found here.

Mainstream Information Security news lines [http://bit.ly/pDaXpN]  were reporting another physical security attack against one of the most popular access card services, Mifare, which is still remembered by some for the 2008 attack on the Mifare Classic.  The Mifare DESFire card technologies are used across the world by businesses, governments, and residential consumers for protecting everything from garage door openers to critical infrastructure.

The attack requires a malicious person to acquire the physical card for around 7 hours to obtain the card’s secret key.  Once obtained, an attacker can assume the digital identity of individuals who use the card to authenticate/authorize their access. The atack highlights the reality that any physical devices can be cracked given enough time and cleverness.

When granting access to sensitive assets it is best to rely on multi-factor controls (something you have: the card; plus something you know: PIN or passphrase).

After Ben Hagen and I gave our talk at B-Sides Chicago, I wanted to circle back and recap some of the trends in webshells, new ideas, and reflections on this class of malware.  We presented a tool called NeoPI and demoed it’s effectiveness in detecting web shells.

NeoPI is a Python script that uses a variety of statistical methods to detect obfuscated and encrypted content within text and script files. The intended purpose of NeoPI is to aid in the identification of hidden web shell code. The development focus of NeoPI was creating a tool that could be used in conjunction with other established detection methods such as Linux Malware Detect or traditional signature/keyword based searches.  NeoPI is platform independent and can be run on any system with Python 2.6 installed.   NeoPI recursively scans through the file system from a base directory and will rank files based on the results of a number of tests. The ranking helps identify, with a higher probability, which files may be encrypted web shells. It also presents a “general” score derived from file rankings within the individual tests.  You can pull a copy of the code from https://github.com/Neohapsis/NeoPI.

There hasn’t been much of a change in the strange obfuscation techniques that some malware developers are using, but more security folks are aware of the problem.  One tool that has since been released that aids in the detection of these malicious files is called PHP Shell Detector.  This app’s primary focus is on the detection of PHP files, looking for suspicious calls such as eval/system/etc.  It then compares against a collection of fingerprints of common webshells.  This shares a lot of the same functionality as Linux Malware Detect, but has a pretty nice UI.  Unfortunately custom shells using other languages may be able to bypass the detection method.

Elena Kropochkina and Joffrey Czarny presented WebShells: A Framework for Penetration Testing at Hack in the Box Amsterdam earlier this year.  They presented a new platform that is language independent, resistant against third party unauthorized access and not be detected by AV/IPS/WAF.  I haven’t been able to download the slides for the talk (web server issue on the materials page for the conference) but I am interested to see how NeoPI will hold up against some of the new techniques they are claiming in their proof of concept.

HT shells  is an interesting project that contains webshells and other attacks against .htaccess files.  The shell first makes the .htaccess file accessible over web, and then another configuration setting makes the .htaccess file interpreted as PHP.  As NeoPI currently does not check for .htaccess files when using auto-regex, we will have to make a change to start looking at .htaccess files for potential malware.

Another interesting article I came across was from Rahul Sasi on the effectiveness of Antivirus in detecting web shells.  He went though the arduous effort of testing a variety of webshells and Antivirus effectiveness at detecting them.  No surprise that antivirus fails at detecting most webshells especially ones that have been customized.  This again, shows the importance of alternative mechanisms for detecting webshells.

I still strongly feel that a combination of tools and techniques is the most effective way to detect web shells, with a focus being on analyzing the specific malware for known oddities, and putting less of an emphasis on signatures.  This is mainly due to how easy it is to write a shell from scratch or modify an existing shell.  Even more important is actually assessing the applications that are being comprised with webshells, as webshell detection is a reactive control, and preventing the compromise all together is obviously preferable .

By Patrick Toomey

Last year Charlie Miller presented some fuzzing results on OS X, including fuzzing PDF files through OS X’s Preview application. Out of 2.8 million PDF files Preview crashed approximately 160,000 times. Obviously one can’t state anything categorical about the exploitability of these, but it does speak to a general code quality issue within Apple. Similarly, the security community has rightfully chastised Apple for their implementation of ASLR, DEP, etc. These stories, along with those of recent OS X specific malware, have gotten a fair bit of attention in the security community, with most everyone agreeing that Apple is going to have to do better. However, should we have really expected anything different?  As with any software company Apple has their priorities and apparently they didn’t think cleanly handling arbitrarily fuzzed PDF files and ASLR were going to sell more Macs. Microsoft took the same approach (prioritizing features/user experience over security) for many years before they were forced to swallow a big heaping spoonful of medicine. It could even be argued that taking the opposite approach (valuing security over user convenience/experience) isn’t the right answer either. That is not to say that the reason Linux never took off on the desktop is because they were too focused on security. But, Linux has often placed a high degree of value on the technical underpinnings of the platform rather than rallying behind user experience (this is obviously changing a bit with the likes of Canonical). The take away is that each of these platforms has a target audience and none of them are doing anything altruistic and/or evil, they are simply each catering to a different market.

So, with the upcoming release of Mac OS X Lion, I got to thinking about where Apple is going from a security perspective.  With many companies you can easily predict what they will do because you can just point to the five things that other people are doing better, and the obvious next step is for them to do those things better as well.  But, that isn’t generally Apple’s style.  Years ago Apple had their “Think Different” campaign. While obviously marketing speak, there is an air of truth to it. Apple has never been afraid of doing things differently, running the risk of upsetting users, breaking backward compatibility, or violating common wisdom. Sometimes this way of thinking works out well for them and other times it is pure hubris and doesn’t pan out. But, I do believe they don’t make decisions lightly. As such, as much as many security people think Apple is simply blasé about security, I actually think they have had a strategy for some time now and it is definitely different than the rest.

One of the main roadblocks I’ve seen in the software security space is that very often the advice that is given out is “do better”. While contemporary protections like ASLR, DEP, etc have upped the ante of successful exploitation, it isn’t as if they are a cure all. So, in the end, we still advise developers to do better. All of the above mentioned protections take the perspective of trying to prevent memory corruption from letting an attacker execute code in the context of the user. But, what if an attacker does get code executing in the context of the user? Windows, Linux, and even Apple have thought about this issue as well, and each has their own approach. Linux has SELinux, AppArmor, and other such Linux security modules that let a developer get extremely fine grained with regard to the permissions set available to a given process. Windows has a similar idea with their “low integrity” process model as well as misc things you can do with “access tokens”, “securable objects”, etc.  And then we have Apple, who developed a model very similar to AppArmor called Seatbelt (though it hasn’t historically been widely used or exposed to developers). So, what’s the issue, these all seem like pretty good ideas, so why isn’t everyone using them?  Well, it’s all about the marketing.

So, what do I mean by marketing? I am mostly definitely not talking about a Mac vs. PC style campaign where Mac touts the benefits of Seatbelt over Windows’ approach to using process integrity.  No, I am speaking more of the marketing around selling their solution to developers.  Historically the only people incentivized to use these extra protections were developers that really wanted to do better. As an example, Chrome obviously has in incentive to do better, as one of their core tenants is around security. They want to be known as the secure browser, and as a result, they have gone through non-trivial effort to create a security architecture for their browser that is second to none. But, what is the incentive for the average developer to go through this much effort/bother?  Similar arguments can be made on the Linux side of the house, as there is really very little incentive for the average developer to care about and subsequently bother with these mechanisms, as security is very likely not going to be the thing that makes or breaks a project’s success.  However, from Apple’s perspective, over time if developer’s simply fail to do better, then it is Apple’s brand that is watered down.  So, what is Apple doing?  They are doing it their own way.

Sure, Apple will probably improve their ASLR as well as improve a number of other current deficiencies so that they eventually measure up to the likes of Microsoft and Linux (hopefully this is all coming in Lion).  But, that is all table stakes at this point.  What is Apple going to do that is inherently different than either Microsoft or Linux?  For, that we only need to look at the App Store model.  Apple found a goldmine in marketshare/mindshare with the iOS App Store. When Apple first released their iOS App Store much of the tech community rejected the idea of such a closed platform. However, as time has shown, there is a huge percentage of the population that is 100% OK with such a platform and there are benefits to such a platform from a security perspective. All iOS applications are jailed ala Seatbelt, preventing one application from touching any other application’s data. Also, each application passes through Apple as the gatekeeper. So, if/when an application is found to be doing something suspicious Apple has the capability to pull the App from users’ phones. Sure, there are parts of this that sound way too Orwellian, but there is absolutely value in this model for a large subset of users.

If we look at the growth of the iOS App Store you will notice one very important thing. Apple never told developers  to secure their applications. No, instead they presented developers with a proposition. They basically offered developers the following: If you are willing to trade off a bit of flexibility in your application, we will mange much of the marketing and distribution for your application. Essentially, if you were willing to make a few concessions, you might walk away with a decent paycheck. So, what were those concessions? Well, you can’t write an application that requires root, you can’t read/write to arbitrary locations on the filesystem, you can’t use undocumented and/or private APIs, you must let apple review your application to ensure you haven’t violated any of these concessions, as well as a few others rules.  The net result is that apple marketed their way to a more secure platform (it was a win for developers wanting to make money and it was a win for users who wanted a great user experience to buy applications)

So, what does this have to do with the Mac? Well, Apple released the Mac App Store not long ago. Just as with the iOS App Store, there are some concessions developers must make if they want to make it in the store. These concessions are very similar to those in the iOS App Store. The next version of OS X touts “application sandboxing” as a new feature (probably based off of Seatbelt). I nearly guarantee that in order for an application to make it into the Mac App Store it is going to have to be built in such a way it could be sandboxed (i.e. no root, no low-level filesystem access, etc). So, again, Apple is creating an incentive for doing better without having to idly sit by the sidelines hoping that developers do better all by themselves.  While not a mind-blowing concept, it is different.  This is what Apple is all about; they pull together some reasonably good piece of technology, though it is likely not revolutionary, and then play to their core strength…selling the idea to their customer.  In this case they created a product that is enticing to both developers and users, with the result being a great user experience, and one that just happens to have the nice side effect of helping developers do better.