2016 ShmooCon Proceedings
Search…
Hiding from the Investigator: Understanding OS X and iOS Code Signing to Hide Data
Hiding from the Investigator:
Understanding OS X and iOS Code Signing to Hide Data
Abstract
To hide data from a the forensic practitioner you need to exploit either a gap in their knowledge, their processes, and/or their tools. This is a talk about all three in regards to Apple OS X and iOS code signing. Much research has been conducted around code signing with respect to preventing malicious code execution at binary load time. This strictly about forensics, binary tampering, and data smuggling.
Content
Imagine you are an incident responder for a large organization that is predominantly OS X users that have Admin rights and you allow all connections to the internet with no filtering. When something deemed as an incident happens, you use OSXCollector from Yelp to collect data from the workstation in question and you just reformat the drive depending on the suspected activity. You look at OSXCollector data and you give any program a pass that comes back as signed by Apple or a reputable developer. After all, OS X signing is solid. Right?
Well, it depends on how you do your analysis, but OS X signing may not work the way you think it does.
Mach-O Binaries
On Windows with the PE file format, if you issue the following command to a signed windows binary, it will no longer be signed:
1
echo 'No longer signed' >> Some_signed_binary.exe
Copied!
On OS X and iOS, if you do the same it will still be signed:
1
echo "Still signed... sorta" >> some_signed_macho
Copied!
Try for yourself, on OS X versions prior to El Capitan, do the following:
1
# This will not work on El Capitan if SIP is enabled
2
sudo echo "Still signed... Sorta" >> /bin/ls
3
​
4
# This will work on El Capitan - if you have Firefox
5
sudo echo "Still signed... Sorta" >> /Applications/Firefox.app/Contents/MacOS/firefox
6
​
7
#You could do this
8
sudo echo 4GB.mov >> /Applications/some.app/Contents/MacOS/firefox
Copied!
Go ahead and execute the binaries. You will notice that they both execute. But why? If I issue the following command, codesign will note that they are no longer signed:
1
codesign --verify -vv /bin/ls
2
codesign --verify -vv /Applications/Firefox.app
3
​
4
Firefox output:
5
codesign --verify -vv /Applications/Firefox.app
6
[snip]
7
/Applications/Firefox.app: main executable failed strict validation
Copied!
By default, Mach-O binaries that are part of an application bundle (like Firefox.app) need to either have a valid signature or not be signed at all to execute. Stand alone binaries like /bin/ls do not need to have a valid signature, they will execute either way, by default. So why did the Firefox.app still execute while not having a valid signature? Because the operating system does not use strict signature checking for binary execution. The codesign equivalent is made using the the --no-strict flag.
1
codesign --verify -vv --no-strict /bin/ls
2
codesign --verify -vv --no-strict /Applications/Firefox.app
3
​
4
Firefox output:
5
codesign --verify -vv --no-strict /Applications/Firefox.app
6
[snip]
7
/Applications/Firefox.app: valid on disk
8
/Applications/Firefox.app: satisfies its Designated Requirement
Copied!
What's the difference between strict and no-strict checks?
Mach-O Format
Strict checking involves the entire Mach-O on disk and other resources in the application bundle, if an application. No strict checking involves from the Mach header to the end of the last section that is mapped into memory via the Load Commands, usually that is the Code Signature section and as of 10.10.4, there could be no sections outside of the Code Signature section. Since appended data is not mapped into memory via a load command, it goes unchecked. Meaning you can hide data and the OS will not complain by default.
This also works on iOS. Yes, iOS applications are installed with only no-strict checking.
1
POC:
2
1. Transfer purchases from your iPhone to your mac.
3
2. Find the ipa of some application.
4
3. Unzip the ipa.
5
4. Append data: echo secret_photos_stash >> Payload/AppName.app/AppName
6
5. Navigate back up to application root
7
6. Zip the application to an ipa - include everything that unzipped originally
8
7. Delete app from iPhone
9
8. Sync purchases or use Xcode to side load the application.
10
9. Now that iOS application is smuggling data!
Copied!
I reported this issue and a resource issue to Apple in April 2015 and was assigned CVE-2015-3714 https://support.apple.com/en-us/HT204942.
1
Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, OS X Yosemite v10.10 to v10.10.3
2
​
3
Impact: Tampered applications may not be prevented from launching
4
​
5
Description: Apps using custom resource rules may have been susceptible to tampering that would not have invalidated the signature. This issue was addressed with improved resource validation.
Copied!
The most significant change from 10.10.2 to 10.10.4 (the security update patch for Mach-O loading) was the following section of code:
1
/* If we have a code signature attached for this slice
2
* require that the segments are within the signed part
3
* of the file.
4
*/
5
if (result->cs_end_offset &&
6
result->cs_end_offset < (off_t)scp->fileoff &&
7
result->cs_end_offset - scp->fileoff < scp->filesize)
8
{
9
if (cs_debug)
10
printf("section outside code signature\n");
11
return LOAD_BADMACHO;
12
}
Copied!
This check, from within the load_segment() function in bsd/kern/mach_loader.c, verifies if a section is outside of the code signature section. It is a great check as one could have modified code outside of the signature on a fully signed application. As it stands now, apple verifies code that is loaded into memory, so appending code to the end of the binary will not result in direct code execution. And that is a great thing! Now onto data hiding.
Universal Binaries
Universal binaries (Fat binaries) are Apple's way of deploying a single binary everywhere so it can execute anywhere on multiple chip architectures.
Fat File
Notice the padding between Mach-O binaries. Here is the code from bsd/kern/mach_loader.c, that parses the fat file for Mach-O binaries.
1
if (is_fat) {
2
/* Look up our architecture in the fat file. */
3
error = fatfile_getarch_with_bits(vp, archbits,
4
(vm_offset_t)(&header->fat_header), &fat_arch);
5
if (error != LOAD_SUCCESS)
6
goto bad2;
7
​
8
/* Read the Mach-O header out of it */
9
error = vn_rdwr(UIO_READ, vp, (caddr_t)&header->mach_header,
10
sizeof (header->mach_header), fat_arch.offset,
11
UIO_SYSSPACE, IO_NODELOCKED, kerncred, &resid, p);
12
if (error) {
13
error = LOAD_IOERROR;
14
goto bad2;
15
}
16
​
17
/* Is this really a Mach-O? */
18
if (header->mach_header.magic != MH_MAGIC &&
19
header->mach_header.magic != MH_MAGIC_64) {
20
error = LOAD_BADMACHO;
21
goto bad2;
22
}
23
​
24
*file_offset = fat_arch.offset;
25
*macho_size = fat_arch.size;
Copied!
This code means the data between Mach-O binaries are not checked. Mach-O binaries are mapped in memory and checked independently, for the architecture that is being executed. Again there is no direct code execution from patching data into these sections. And the sections can vary in size, but average about 0x1000 bytes. What happens if we insert data in the unprotected sections? From an execution standpoint, nothing. After adding a single byte in one unprotected section and using codesign we get an interesting error:
1
codesign --verify --no-strict -vv ./dmesg
2
./dmesg: An internal error has occurred.
Copied!
Apple was not expecting this. Using OSXCollector, no error is returned on this.
Not Checked
Code Execution
The data hiding aspects are now obvious. How can this be abused to get code execution to perhaps add extra functionality to your application? For iOS, you would need to find a way to create RWX memory to execute foreign code in your application. That and bypass the App Store checks, like Charlie Miller.
On OS X, creating RWX memory is still possible. There are two scenarios and both involve post exploitation / installation. The first via post exploitation, an in memory infection scans Mach-O binaries for a magic number in an egg hunter way - once it finds its egg, executes the following payload. The second, is an App Store application that checks itself on disk for an egg and executes the payload afterwards. A user or an attacker could extend the functionality of the application in this manner. Both POCS are available here.
Solutions
After talk with Apple Security Engineers in November 2015 about the appending data issue. They feel that users should use only strict checks to determine if binaries are actually signed and have not been tampered with. As such, I do not see strict checking by default being pushed info the kernel (beyond gatekeeper) to enforce strict checking at mach-o load time - anytime soon.
Introducing Kyphosis
Kyphosis is the medical term for hunchback, because the original thought was you could have a 64KB Mach-O binary with 4GB+ file appended on it. The goal of kyphosis is to find data that is appended to a Mach-O file or hidden between Mach-O files in a Universal binary - whether the binary is signed or not. It's a python class and it can be used standalone to pull data from a binary. It uses Macholib and a Universal binary parser from my side project BDF.
1
Usage: ./kyphosis macho/universal_binary
2
#If nothing comes back, you are ok.
3
​
4
$ ./kyphosis.py dmesg
5
Found extra data in the Fat file slack space for dmesg
6
Writing to dmesg.extra_data_section0
7
​
8
$ cat dmesg.extra_data_section0 | hexdump -C
9
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
10
*
11
00000b30 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |A...............|
12
00000b40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
13
*
14
00000fd0
15
​
16
$ ./kyphosis.py ./ls
17
Found extra data at the end of file ./ls
18
Writing to ls.extra_data_end
19
​
20
$ cat ls.extra_data_end
21
Still signed.... sorta
Copied!
To help the OS X forensic/incident response personnel, I've submitted a pull request (link) to OSXcollector, that will collect this extra data, put it into a dict, base64 encode it, and add it to the dict that OSXcollector uses for data storage. I've tested this on my own OS X instances, but I don't run a lot of applications. However, I did find one application that kept code outside of Mach-O Load Commands. It's from IDA PRO:
1
$ ./kyphosis.py /Applications/IDA\ Pro\ 6.8/uninstall.app/Contents/MacOS/osx-intel
2
Found extra data at the end of file /Applications/IDA Pro 6.8/uninstall.app/Contents/MacOS/osx-intel
3
Writing to osx-intel.extra_data_end
Copied!
And it's a Tcl script:
1
00000000 4A 4C 1A 00 00 2D DC AB 80 21 14 AA 1C D9 CE 0A 00 00 6B 00 JL...-...!........k.
2
00000014 81 02 28 B2 21 31 CB 53 19 00 00 F8 09 D4 1F 28 05 0D 1C EB ..(.!1.S.......(....
3
00000028 01 AD 23 C8 06 54 03 BB 10 40 05 81 01 6C F1 23 72 9D 1E 0C ..#[email protected]#r...
4
0000003C C6 09 1D 0C 2E 17 AC 0A 23 20 70 0A
5
[snip]
Copied!
This application is not signed (all of IDA PRO) and I did not dive into what this script does in particular. Maybe I will at a later date.
In addition, patches were submitted and accepted to Knockknock and OSQuery to do strict checking by default.
Happy Hunting!
Metadata
Tags: forensics, anti-forensics, Apple, OS X, iOS, codesigning
- Primary Author Name: Josh Pitts
- Primary Author Affiliation: N/A
- Primary Author Email: [email protected]
Last modified 3yr ago