Results

To examine the McAfee DLP solution specific tests were performed to determine whether the solution can fulfill the requirements listed in Table 2. To evaluate the capabilities of the system, a simple policy was created: Every file that contains the string SECRET should be blocked from being written to any removable media.

Figure 2: Structure of the test environment

Discover Are regular expressions matched and is data blocked? Are all file types handled properly?

Are all file extensions handled properly? Monitor Are all devices monitored?

Are all file systems monitored properly? React Is sensitive data blocked?

Are all incidents reported properly? System Security Is all sensitive traffic encrypted?

Exist any obvious vulnerabilities? Table 2: Testcases for McAfee DLP

Figure 3: Text pattern for matching the string secret

Figure 4: The complete reaction rule using the text pattern

Additionally, a notification message should show up. The blocked data then should be stored for further analysis. This policy could be applied using the text pattern shown in Figure 3 and the reaction rule shown in Figure 4. The examination of this basic system again is divided in three sections which derive from the single stages identify, monitor and react.

Identify

The first simple test was the copying of a text file containing the text SECRET to an USB stick. As was not to be expected otherwise, the text file was blocked (Figure 5 and 6) and stored at the repository of the ePO server (Figure 7). After this check of the correct functionality of the system, further tests regarding the file type recognition were performed. Every DLP solution supports lots of file

Figure 5: Copying the secret file to a USB stick

types that can be understood and parsed. So the following combinations of more sophisticated file types were generated:

• PDF document containing the string SECRET • Zip archive containing this PDF document

• Word document containing an embedded excel tabular containing the string SECRET

• Zip archive containing this Word document

Since all of this file types are officially supported all 4 files were detected to be valuable content and thus blocked.

To check whether a real deep content analysis is performed, the test was re- peated using the same PDF file but the first line, which contains usually hints on the file type, has been removed. The following listing shows that the first line %PDF-1.4 is missing in the second file secret-nomime.pdf :

$ diff -a -u secret.pdf secret-nomime.pdf

--- secret.pdf 2009-01-24 13:00:51.000000000 +0100

+++ secret-nomime.pdf 2009-01-27 10:14:38.000000000 +0100 @@ -1,4 +1,3 @@

-%PDF-1.4

This slightly modified file was not detected by the scan engine as Figure 8 shows. In general, this means that unknown mime types are not monitored. Similarly, a PNG image which contained the EXIF comment (where EXIF is an standard for embedded meta data for images) SECRET was copied to an USB stick. This test should examine whether recognized document formats are parsed completely and correctly. As the file can be copied to an USB stick, this is another failing of the solution.

Monitor

The next step is to examine whether all possible channels are monitored properly to ensure that all data can be discovered and analyzed. In a first step, it was tested whether the monitoring engine is restricted to certain file systems. A file containing a NTFS alternate data stream was prepared and copied to the USB stick. This special extension of the NTFS file system was monitored correctly (Figure 9).

Completely different file systems like the Linux ext3 file system which was included by installing a special driver was also monitored. A file containing the secret string was detected and blocked.

Figure 8: PDF files with removed leading line are not recognized

Figure 10: Unmonitored partition

Figure 11: Monitored partition

In contrast, it is a severe restriction that devices containing more than one partition are not properly monitored. Using an USB hard drive containing three partitions, only the last mounted partition was monitored during several attempts. The first two ones were not monitored. Thus it was possible to write arbitrary data containing the secret string to the first two partitions (Figure 10 and 11). Another kind of a side channel is the possibility of copying a file which is named SECRET.txt to an USB stick. Even though the file name contains the valuable information SECRET, the file is not blocked (Figure 12).

To ensure the stability of the endpoint agent, it is important to analyze the behavior of the system when a big file must be examined. Since the McAfee Host Data Leakage Prevention does not analyze files which are bigger than 500 MB, it was not possible to run a test using a 5GB file containing random data.

Figure 12: Information contained in file names is not monitored

React

Since the last two paragraphs figured out which data is recognized and monitored, the reaction methods need to be examined in detail.

As Figure 6 showed, data gets deleted if valuable information is discovered. To check whether valuable data is really deleted, a completely empty USB stick was prepared. Every sector of the flash memory was overwritten with zero (more technical description for all further steps reside in Appendix C, special documen- tation for this paragraph in C.1). When this USB stick was inserted into the client system, it must be formatted and then could be mounted. A file containing SECRET several times was written to the stick and expectedly got blocked and deleted. After this process, the stick was examined on a very low level without using any filesystem structures (the used standard forensic methods are described in Appendix C.1). The resulting data still contained the secret string SECRET. Thus it is possible to bypass the DLP solution via recovering the deleted files. To eliminate the side effects of wear leveling techniques [Cha07], the test was verified using a floppy disc – ending up with the same result.

In a last step of reaction, the blocked data is stored on a central repository. This central repository is available via SMB and a provided network share. Monitoring this transmission it showed up that the file is just delivered via SMB without further encryption. Since SMB is a plain text protocol it was no problem to intercept the traffic and extract the sensible information (Figure 13).

Figure 13: Files containing sensitive data are transmitted via SMB in plain text

System Security

It is obvious that the DLP architecture is a worthwhile aim for attackers. A lot of valuable data is stored on the incident repository, descriptions of all secret patterns are available and no further searching would be necessary. Thus the overall security of the DLP system has to be appropriate to protect the mass of confidential data. The first phase of reconnaissance revealed several provided network services which could be discovered using port scanning techniques (results are listed in Appendix C.2). The most interesting port was TCP port 8443 of the ePO server since it is used for logging in to the management console. The use of the encrypted HTTPS protocol for all traffic is definitely necessary, but the server supported insecure encryption algorithms with insufficient key lengths (Appendix C.3) which would allow the decryption of intercepted traffic. Usually most clients support strong cipher algorithms, but if any kind of mobile or embedded device is used to access the webservice, it is possible that only a weak cipher is negotiated.

Another web interface on the central server can be reached using TCP port 80. It provides remote access to functions like DeleteAllEvents which purges all events from the reporting system. Since the unencrypted HTTP protocol is used the NTLM handshake used for authentication can be sniffed. If weak passwords [Ril06] are used the password can be brute forced and an attacker could log in to delete all events. To mitigate these threats, strong SSL ciphers with appropriate authentication should be used to ensure that no communication can be sniffed.

To find programming flaws in the endpoint agent, all interfaces must be enu- merated. In a first step, a port scan (Appendix C.2) revealed a listening network

service on TCP port 8081 on the client side. Since this interface allows an attacker to send arbitrary data to the service, it is important that no vulnerabilities exist in this exposed network interface. Otherwise it could be possible to compromise the complete system exploiting the management port of the DLP solution.

The second step is the enumeration of local functions which are intercepted by the DLP solution. All software solutions which monitor activities on the system – like anti virus or personal firewalls – must intercept certain system interfaces to see whether they are accessed. It is for example possible to hook the operating system function that creates new files. Based on this interception, a DLP solution can read files that should be created and block these calls if they would harm any policies.

Local attackers or malicious users could also inject code into these functions. This could for example disable the DLP solution or help the attacker gaining the higher privileges of the DLP solution. These so called API hooks were enumerated using memory analysis techniques (Appendix C.4).

Using this knowledge on hooked functions and network ports, it was possible to analyze the behavior of these interfaces using so called fuzzing techniques [SGA07]. This black box analysis method reveals major programming flaws which can also lead to security vulnerabilities. In general, it gives an overview whether the appli- cation was properly tested and developed following secure coding best practices. The performed tests did interact with both the network socket and the hooked API functions and are described in detail in Appendix C.4. This basic evaluation did not reveal any crashes neither of the DLP client nor of the operating system.