Tag Archives: Usb

Wiping & Protecting Data from SSD/Flash Drives

USB Flash DriveI received a comment from a reader of this blog (hi Ziyad!) about an very old article posted in 2008 (!) about tools to wipe files from drives. I reviewed a list of tools available on Linux (or other UNIX flavors) to safely delete files. As you probably already know, deleting a file using the standard system call is not enough from a security point of view. The blocks used by the unwanted files are just tagged as “free” and are not overwritten. The goal of such “eraser” tools is to write random data in several passes. This is a valid technique for classic hard drives but, it’s not the case for new medias like Flash drives or SSD. Those new types of storage become more and more common in laptops, netbooks and even servers now. They have multiple advantages:

  • Fast startup (no need to “spin up”)
  • Silent!
  • Low power consumption
  • Fast random access
  • No moving parts (less risk of mechanical problems)

Try yourself the following demonstration. Connect an USB flash disk to your laptop:

   # tail -f /var/log/messages
   [...] usb 2-1: new high speed USB device using ehci_hcd and address 10
   [...] usb 2-1: configuration #1 chosen from 1 choice
   [...] scsi7 : SCSI emulation for USB Mass Storage devices
   [...] scsi 7:0:0:0: Direct-Access     USB2.0   Flash Disk       2.50 PQ: 0 ANSI: 2
   [...] sd 7:0:0:0: Attached scsi generic sg2 type 0
   [...] sd 7:0:0:0: [sdb] 1024000 512-byte logical blocks: (524 MB/500 MiB)
   [...] sd 7:0:0:0: [sdb] Write Protect is off
   [...]  sdb:
   [...] sd 7:0:0:0: [sdb] Attached SCSI removable disk
   # df | grep /media
   /dev/sdb                511504     14304    497200   3% /media/001B-9622

Create a temporary file with pseudo sensitive data like a credit card number:

   # mkdir /media/001B-9622/test
   # echo "Xavier|1234-5678-90|2010-12" >/media/001B-9622/test/data.tmp

The data are available via the raw devices:

   # strings /dev/sdb | grep -i "1234-5678"

Now, safely remove the file using the wipe command:

   # wipe /media/001B-9622/test/data.tmp
   Okay to WIPE 1 regular file ? (Yes/No) yes
   Operation finished.
   1 file wiped and 0 special files ignored in 0 directories, 0 symlinks removed but not followed, 0 errors occured.

Search again on the raw device:

   # strings /dev/sdb | grep -i "1234-5678"

The sensitive information is still present on the drive! Why?

A disadvantage of the SSD technology is the limited life-time (limited number of write cycles). To avoid this problem, the manufacturers use a technique called “wear-levelling” for prolonging the life of the SSD media. Basically this is a work-around which consists of distributing erasures and re-writes across the medium. This is great to extend the life-time but this brings up more security risks!

If you delete or overwrite data, new sectors will be used and the original data will remain on the original location for a while! Based on this security considerations:

  • Encryption of data already existing on the SSD is NOT safe!
  • Wiping of files does NOT work!

To safely store files on a SSD or Flash device, you can create a TrueCrypt container before copying files! To safely remove files, reformat the whole device. If you really need a 100% safe solution, a hammer could do the job 😉

But, an alternative solution exists: The support of TRIM by Operating Systems:

In computing, a TRIM command allows an operating system to inform a solid-state drive (or “SSD”) which data blocks, such as those belonging to a deleted file or affected by a format command, are no longer considered in use and can be wiped internally.” (source: Wikipedia)

Good news, Linux already supports TRIM via the hdparm command. More information is available here. Keep this in mind if you store confidential data in SSD or Flash devices!

Detecting USB Storage Usage with OSSEC

(Credits: Erik Araujo - sxc.hu)

Next step in my investigations with OSSEC. The possibilities of OSSEC are awesome and could clearly, in some case, replace a commercial log management solution! After collecting the Secunia vulnerabilities into OSSEC, I switched to the “dark side”: the Microsoft Windows agent. The USB sticks are very popular at users level and are a nightmare for system administrators. It’s so easy to get files away with critical data or  to inject malicious code into the network via suspicious USB sticks. Why not try to detect if an USB storage is used on a Windows workstation or server?

First of all, this solution is certainly not bullet-proof! My goal is to demonstrate how OSSEC can make the life of security professional (a little) more easier. OSSEC comes with an agent for the Microsoft operating systems. This is only a “agent”, it cannot be used in stand alone mode and cannot act as its own server. It is controlled from an OSSEC server running on UNIX. Like the other agents, it can perform the following checks:

  • Event log monitoring (Application, Security & System)
  • Integrity monitoring
  • Security Policy monitoring
  • Log files monitoring (IIS included)
  • Active response

The installation is pretty straight forward via a Windows installer. Once done, the OSSEC agent will be executed as a standard Windows service:

C:\Temp> net start | find "OSSEC"
   OSSEC Hids

The agent is managed via a nice GUI – the “Agent Manager”. Available actions are:

  • To start/stop the agent
  • To edit the configuration file
  • To display the log file

The OSSEC Agent Control Window

On the server side, there are three important files which define the security policy  of Windows hosts [Note: I’m assuming that your OSSEC server is already running. Consult your documentation if needed]. These are located in the directory “$OSSEC_DIR/etc/shared/“:

  • win_applications_rcl.txt
  • win_audit_rcl.txt
  • win_malware_rcl.txt

They come with predefined rules which should be sufficient to monitor a classical Windows environment. The rules are based on the following syntax:

#[Entry name] [any or all] [reference]
# type:<entry name>;
# Type can be:
#             - f (for file or directory)
#             - r (registry entry)
#             - p (process running)
# Additional values:
# For the registry , use "->" to look for a specific entry and another
# "->" to look for the value.
# For files, use "->" to look for a specific value in the file.
# Values can be preceeded by: =: (for equal) - default
#                             r: (for ossec regexes)
#                             >: (for strcmp greater)
#                             <: (for strcmp  lower)
# Multiple="Multiple" patterns can be specified by using " && " between them.
# (All of them must match for it to return true).

(For a complete overview and example, check out the OSSEC Wiki)

To detect the the presence of an USB stick (let’s focus of course on pure storage devices – we don’t care of mouse, keyboard or any other gadget), we will adapt the file “win_audit_rcl.txt“. Every time an USB storage device has been inserted into a port, the following registry key is incremented (+1 for each device inserted):


To detect the presence of a USB stick or disk, let’s define the following new rule in win_audit_rcl.txt:

[USB Storage Inserted] [any] []
r:HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR\Enum -> Count -> !0;

Save the file and push the changes to all your Windows agents. If everything runs fine, insert an USB stick in a monitored Windows machine and the following event will be received by the server:

** Alert 1268430696.36057: - ossec,rootcheck,
2010 Mar 12 22:51:36 (WinXP)>rootcheck
Rule: 512 (level 3) -> 'Windows Audit event.'
Src IP: (none)
User: (none)
Windows Audit: USB Storage Detected.

Cool! But not very powerful. The alert will be triggered only if the USB device is connected when the rootkit scan is performed! If a user connects and disconnects an USB device between two rootcheck scans, nothing will be detected. A possible solution could be to reduce the interval between two rootcheck executions but this will requires more resources and could affect the overall system performances. Another alternative is to go back to the Windows registry. and look for other solutions. It is a wonderful source of information, almost everything is written there! There is another interesting key in our case:


The first time an USB storage device will be connected, the key will be created and a sub-key with the device information. Example:


We can now create a second rule in win_audit_rcl.txt like:

[USB Storage Detected] [any] []

Restart again OSSEC and pushes the new audit files to your agents! Check your alert.log for messages like this one:

** Alert 1268681344.26683: - ossec,rootcheck,
2010 Mar 15 20:29:04 (WinXP)>rootcheck
Rule: 512 (level 3) -> 'Windows Audit event.'
Src IP: (none)
User: (none)
Windows Audit: USB Storage Inserted.

Note that this notification will remain while the registry key is present! It’s your job to clean up the Windows hosts which reported the alert! I’d like to increase the rootcheck rule accuracy by detecting if a new USB device has been inserted but at the moment, I didn’t find how to achieve this. If you have tips & trick, please share!

To conclude with this example, you can see how easy OSSEC can help you to keep an eye on threats inside your infrastructure. A next funny step could be to enable the remediation and configure the OSSEC agent to execute a script which will prevent from connecting USB storage devices!