Chapter 6 security defense practices for iOS apps: files that cannot be destroyed

Chapter 6 security defense practices for iOS apps: files that cannot be destroyed

Think of a common file system as a big notebook. When a file is deleted, many people think that this page is completely hacked with the trigger, just like the confidential document about Area 51. But in fact, what happened behind this operation is more like drawing a huge X on this page with a very small red pen. The file is marked as deleted, but the content still exists in the notebook. Anyone who wants to know what it looks like can easily read its content, regardless of whether a red X marks it as deleted. This is how the trial lawyers, whether in the American drama Boston Legal or in real life, can restore a large number of deleted files from the suspect's computer. Apple also knows this, so it began to use some specially designed file system encryption methods in iOS 4 to prevent deleted files from being restored. However, this technique is not perfect, and sometimes files may still be stolen.

As we can see earlier, iOS 4 and iOS 5 use an encrypted file system. All files in this file system use a unique key for encryption. In the file system, this key is stored in the attribute cprotect, and it is actually encrypted by the so-called AES-Wrap method, encrypt its key, or store it in the Dkey that can be erased by the NAND, or one of the protection level keys. When a file is deleted, the cprotect attribute of the file will be lost. Without the encryption key in this attribute, the file cannot be disclosed, so restoring it makes no sense.

Imagine that wherever you go, there is a secretary that we call Iris. Now imagine that Iris will help you remember everything you have done in the past one or two months. Remember to record all the things you have said. Of course, you agree to do so. Well, this is really helpful, because sometimes you are easy to forget, especially when you drink too much coffee and often get down. You can tell Iris what to say to a specific customer on which day, so that she will repeat it at that time.

However, Iris (except when you are always embarrassed in the morning bath) has a disadvantage, because she will remember everything you said, if you don't pay attention to it, you will record the password that you will hand over to the customer to access some files on your website. You have adopted a very strict security mechanism to ensure that your password will not be leaked. But Iris is always with you. If someone can win her, they can get all the files of your customers.

Apple's HFS log is the electronic version of iOS Iris. HSF logs record write, change, and delete operations on all file systems, so that the file system will not lose data after the device is destroyed or the power supply is invalid. HFS logs are encrypted using the EMF key. We have learned before that the key is stored in the erasable storage area of NAND. The EMF key is not encrypted using the required password. Therefore, anyone who knows how to do this can easily decrypt HFS logs without the user password. In Chapter 5th, The Sogeti brute force cracking tool not only extracts all other encryption keys from the device, but also provides this function. When the encryption key of a file is written to the cprotect attribute of the disk, the HFS log automatically records a copy of the file to the disk.

If a file has been deleted, the encryption key written to the disk will be erased, but the copy written to the HFS log will not. This may be because the HFS log feature appeared earlier than the HFS + encrypted volume, so it runs independently of the encryption feature and other additional features of the file system. Unless Apple locates and clears an encrypted key for a deleted file from the log, it can steal a copy of the key and restore the original file.

0x00 scrape HFS logs

Chapter 5th describes Sogeti's free data protection tool suite, which contains a set of tools for decrypting iOS files and key chain data. Another tool named emf_undelete in this suite is used to scrape out the cprotect attribute that contains the file encryption key in HFS logs. This tool will try to use these keys to decrypt the files left on the disk. Like Iris, HFS logs only store limited information for a period of time until the information becomes older data is rotated out. The length of this period depends on the activity of the device, which may be as short as one day or as long as several weeks. The more frequently the device is used, the faster the HFS log rotates the old data.

To obtain the log Content, go to the python_scripts directory of the Sogeti tool set, execute the emf_undelete.py script, and enter the original disk image obtained by RawTheft. In addition, you also need to use the KeyTheft load in Chapter 4th to obtain a device's encryption key.

$ python emf_undelete.py rdisk0s1s2.dmgKeybag: SIGN check OKKeybag unlocked with passcode keycprotect version : 2Found deleted file record 109296 lto2.datFound deleted file record 111607 NetworkInterfaces.plistFound deleted file record 111939 com.apple.AutoWake.plistFound deleted file record 111571 com.apple.PowerManagement.plistFound deleted file record 109294 com.apple.network.identification.plistFound deleted file record 111874 com.apple.wifi.plistFound deleted file record 111871 preferences.plist...

When the script runs, It scans the deleted files and encryption keys in the log, and then performs the second scan to extract the data to two directories named junk and undelete. The undelete directory contains the files that can be successfully decrypted by scripts. The junk directory contains the files that cannot be verified, but may still be valid.

Some basic file headers (referred to as magic values) are written in the EMF script to determine whether the file is valid. Check the isDecryptedCorrectly function of the hfs/journal. py file and you will see them.

magics=["SQLite", "bplist", "<?xml", "xFFxD8xFF", "xCExFAxEDxFE"]"""HAX: should do something better like compute entropy or something"""def isDecryptedCorrectly(data):for m in magics:if data.startswith(m):return Truereturn False

In fact, we should make some improvements to it to achieve better results. The above implementation method limits the file types that can be verified by the reverse deletion script. To improve this function and reduce the number of valid files moved to the junk folder, replace the function with the following code:

def isDecryptedCorrectly(data, filekey):filename = "/tmp/%s.bin" % (filekey.encode("hex")[:8])write_file(filename,data)filetype = commands.getoutput("/usr/bin/file -b %s" % filename)os.unlink(filename)print "file type for %s: %s" %(filename, filetype)if filetype == "data":return Falsereturn True

The above code calls an external program named file. This program is a UNIX tool included in Mac OS X, used to determine the file type. It can identify a lot of valid files, determine whether a successfully decrypted file is valid and readable, and give more accurate results. When the file tool cannot determine the type of the file being viewed, a common data type is simply returned.

Although the file tool is more accurate, it cannot identify proprietary files. If your application software uses a custom format in some specific files, you may have to search in the junk folder because the anti-deletion tool cannot identify them.

0x01 restore idle Space

Scan unallocated space thoroughly, which is the last method to restore deleted data. This function is disabled by default in the anti-delete tool, because it takes a long time to scrape unallocated memory, and the effect is usually not very good.

You can activate this feature by editing the hfs/journal. py script. There is a call to carveEMFemptySpace near the bottom of the file, but it is disabled by an if False statement:

if False:fks = set(reduce(lambda x,y: x+y, filekeys.values()))print "%d file keys left, try carving empty space (slow) ? CTRL-C toexit" % len(fks)raw_input()carveEMFemptySpace(volume, fks, carveokdir)

Change this statement to if True and save the modification. In this way, after the original log operation is complete, you will see a prompt to start restoring.

0x02 frequently restored data

By scraping HFS logs, you can restore many different files. In fact, anything that once exists on the file system may be restored, especially small files such as attribute lists and images. Due to the limited size of HFS logs, small files are more likely to be restored.

Application Screen

When an application is suspended to the background, a screen is captured and written to the disk. This is to achieve the effect of Window Scaling back to the screen when the user returns to the application software next time, just as the application software is immediately loaded from the background. In fact, it takes some time for the application to load it back and become active again, and the animation effect gives the software some time.

Each time an application is suspended, the screenshots of the application are repeated. Later, the screenshots are deleted or overwritten. When a call comes in, or other events that may cause application software suspension, screenshots may also occur. You can often find these deleted application screenshots in HFS logs to leak your applications.

Even the most secure data encryption content in the software (see Figure 6-1 ).

Figure 6-1. Restored user email screenshots. The email software is a very useful tool in forensics.

In addition to Application Software screenshot leakage, secure websites also face this problem. Whether it's Google (see Figure 6-2) or the confidential email you see inside the enterprise VPN, screenshots may cause insecure protection of the best data.

Figure 6-2. screenshots restored from a Safari browser session

List of deleted Properties

The old attribute list and other configuration files are often restored from logs. If these files store confidential data, encryption keys, or other sensitive data of the website and are deleted, the data may still be recovered. Some applications first write a plaintext attribute list and then use the encryption function to encrypt the data. Even if the plaintext copy has been deleted, it can still be restored, so that the original plaintext content is leaked.

In such a case, a secure mail client stores copies of the emails it is currently processing to a temporary SQLite database. This database file is used to copy data between different components of the application. After the operation is completed, the data is deleted. Although the application securely stores emails in its primary database, any emails that have been selected and processed in this temporary database are temporarily stored. Therefore, attackers can easily exploit this vulnerability.

Deleted audio emails and recordings

The voice mail is directly pushed to the iPhone connected to the visual voice mailbox, so that you can randomly access and listen to it offline, or even before the user listens to the information, these files have been pushed down, so you can even find unread voice emails on the device. Voice mail files use the AMR encoding format, which is an audio encoding method specially designed for audio recording. The same audio format is used for recording files. Deleted recordings may also be found on the device.

Deleted keyboard Cache

As described in Chapter 4th, the keyboard cache contains the cache of data input through the keyboard anywhere in the application software, unless this text box of the software is specifically disabled for automatic error correction or set as a secure password box. You can find a copy of the deleted keyboard cache file from the HFS log, which even contains a copy of the cached data entered through the keyboard very early.

Photos and other personal information

Similarly, deleted photos and other personal information stored in deleted files can be restored from HFS logs. For example, an online banking application stores a check photo taken by a camera on the device. When this check photo is cleared, it is actually deleted rather than completely erased, in this way, attackers may obtain residual data.

0x03 Summary

Any file that has just been deleted may exist in the log. Do not rely on the assumption that devices will safely erase files after they are deleted. It is best to think that the file system has no encryption protection capability at the underlying layer. If the data contains sensitive information that you do not want attackers to restore, do not write the plaintext copy of the data into the disk. In Chapter 2, you will learn a series of anti-Forensics techniques. Using these techniques, you can safely clear data when deleting a file, and prevent your application from saving the screen when it is suspended.