Neohapsis Labs

This past Friday (February 3, 2012) Anonymous released a call recording regarding an assumed confidential conference call between two FBI field offices and a official UK investigation office regarding status on Anonymous, AntiSec, Lulzsec and other splinter cyber groups.  It was released on ThePirateBay, YouTube and Pastebin, and  from the Pastebin posts, the conference call appears to have been related to a meeting invite for a call on January 17, 2012 that was sent on January 13, 2012 to nearly 50 people from France, UK, Netherlands, Ireland, Germany, Sweden and hosted by US to coordinate internationally.  The posts were made by anonymous as part of their #FFF (F@$K FBI Friday) releases which has been going on almost regularly for over a year now.

It is unclear through YouTube audio if the call was from January 20, or a more recent conference call between the governments.  I think that this was probably only released because the hacking groups found no more use in that bridge number.  In listening to the call, one can gain insight into the global workings of the fight against cyber crime, as two current cases were lightly discussed. Insight was also sought regarding other persons of interest concerning breaches reported to government authorities.  I found the lack of care around people joining the call interesting as I could hear the extra beep that was missed by the call parties and I assume it was ‘Anonymous’ recording the call.

Few facts can be gathered around how anonymous gained the electronic invitation for the meeting.  After the Pastebin post with conference bridge call number and password, it does not seem that the conference system or software was hacked to gain access for the call.  One might assume that an email account or system on the distribution list could have been compromised to gain the conference details or some form of social engineering was used in the attack.  Either way, anonymous has again provided a reason for government and private industry to rethink their communication processes for distributing sensitive call meetings.  In future calls, I would think that every time the system beeps for a new attendee on the call there will be a stop to ask who had just joined the conference, especially when discussing active investigations or sensitive information.

While there is a need to share passwords for conference calls it is important to mitigate any risk in the process to overcome the shared password.  Typically this is done on conference calls by paying a very close attention to people joining the call and stopping conversation when the system makes a beep for a new participant joining the call.  If the conference call is of sensitive or classified information then the call should be halted or stopped if all parties are not able to be identified on the conference system.

Also, all parties need to read The New York Times article about board rooms being open up to hackers through weak implementation security as it has some relevance here.

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 .