1. Introduction
USB media, and in particular pen drives, are responsible for much of the virus and malware infections on workstations and even servers used by unsuspecting users. A simple “stick” of a USB flash drive can bypass all security measures implemented in the network environment. With that in mind, I decided to look for a way to passively immunize a USB media, so that the protection is on the media and not on the machine. There is no mitigation, but it is possible to greatly reduce the risk of infection with the technique I will present.
2. How Infection Occurs
When a USB media is inserted into a Windows machine, the auto-play feature starts. If at the root of the media there is an autorun.inf file, it is read by the system and its instructions are processed automatically. The most efficient technique for infecting USB media is then to copy the malware itself (usually a PE binary) to the media and also create an autorun.inf at the root of the media that runs the malware every time the media is inserted into a Windows machine. This process is explained in the text “How to remove flash drive viruses” [1], which I wrote in January 2010.
3. The Idea of protection
There are several attempts to prevent these infections, from simple programs that try to remove virus traces on USB media to more complex software, dubbed USB “firewalls” that allow you to control all traffic. The problem is that the machine is protected, but not the USB media. If you use the flash drive, for example, on another machine, it can become infected and serve as a means of spreading because the software that protects the USB is on your machine and not on the flash drive.
Since all malware I've analyzed creates an autorun.inf to self-reproduce, the idea is to create a healthy autorun.inf on the root of USB media that is “unalterable”, “undeletable”. This way, malware will not be able to overwrite the healthy autorun.inf for its malicious and malware executable can even be copied to the media, but will not boot when the media is inserted into any Windows, ie it will simply be stored on the media. , but harmless (unless some user manually finds the executable and runs it). But is it possible? Let's go to the tests. Checking the possibility
After some searching on “indelible” file creation, I found Panda USB Vaccine [2], which promises to do exactly the proposal. It actually works and creates an “undeletable” autorun.inf on the root of USB media. The drawback to me is that it is closed source software and there is no documentation on how it does it, and it only runs on Windows. I was developing USBForce [3], free software for pest protection on USB media when I found Vaccine. Naturally, I would like to implement this functionality of creating an “undeletable” autorun.inf in my software. Besides, I couldn't sleep without knowing how (technically) this file is created and if it was undetectable.
4. Reversing the Vaccine Technique:
I used some tools to know how Vaccine works, starting with the RDG Packer Detector [4], which, besides other features, can know which compiler is used to generate the binary, very useful information before debugging: RDG informs that there is no packer and that the software was written in Borland C ++. You can't take everything for granted, but it's a good starting point. In addition, RDG detects a call to the IsDebuggerPresent function [5]. Some software closes when they realize that they are being debugged and this function is one way to have this perception. Usually the compiler puts some interesting information in the .data section of the generated executable. It doesn't hurt to look quickly at what's in there. For this I used pev [6] with the “-s” option to display information about the executable sections:
> pev -s USBVaccine.exe | more
Sections:
Name: .text
Virtual size: 0xd9000
Virtual Address: 0x1000
Data size: 0xd8600
Date offset: 0x600
Characteristics: 0x60000020 (01100000000000000000000000100000)
contains executable code
is executable
is readable
Name: .data
Virtual size: 0x1d000
Virtual Address: 0xda000
Data size: 0x12c00
Data offset: 0xd8c00
Characteristics: 0xc0000040 (11000000000000000000000001000000)
contains initialized data
is readable
is writable
Knowing the offset (position) where the .data section starts, I used hdump [7] to peek at the bytes:
> hdump USBVaccine.exe | findstr “d8c [0-9] 0 ″
000d8c00 43 6f 64 65 47 65 61 72 20 43 2b 2b 20 2d 20 43 | CodeGear C ++ –C |
000d8c10 6f 70 79 72 69 67 68 74 20 32 30 30 38 20 45 6d |
000d8c20 62 61 72 63 61 64 65 72 6f 20 54 65 63 68 6e 6f | barcaderoTechno |
000d8c30 6c 6f 67 69 65 73 00 00 00 10 40 00 b2 12 40 00 | logies…. @… @ |
000d8c40 b2 12 40 00 22 15 40 00 01 00 00 00 00 00 00 00 | .. @. ”. @ ……… |
000d8c50 fc 64 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .d @ …………. |
000d8c60 30 99 4e 00 4c ad 4e 00 50 ad 4e 00 68 d0 4b 00 | 0.NLNPNhK |
000d8c70 c0 d1 4b 00 50 d2 4b 00 e4 d3 4b 00 b0 93 4e 00 | ..KPK… K… N. |
000d8c80 00 00 f8 ac 4e 00 74 ad 4e 00 ec aa 4e 00 00 00 |… .NtN… N… |
000d8c90 00 00 00 00 00 00 00 00 00 00 00 90 90 00 00 00 00 | ……………. |
In fact, it looks like the binary was written in Borland C ++, but with a more current version (Embarcadero bought Borland's CodeGear division).
Let's go to the software execution:
What we are looking for is the event code “click” of the “Vaccinate USB” button, right? There are specific tools for working with binaries generated on specific versions of compilers. In the case of BC ++, there is a particularly interesting tool called E2A (Event To Address), which can tell the address of each software event, which makes life much easier:
The function address that the button's click event calls is 0x404C58. Now it's debugging. I used OllyDbg [8] for this. The idea is to place a breakpoint at this address, run Vaccine on the debugger, click the button to vaccinate the media and follow step by step what the software does from the breakpoint.
5. Understanding Protection:
As shown in the video, Vaccine creates a normal AUTORUN.INF file at the root of the media, but then looks for the entry of this file in the FAT to locate the byte that controls the attributes. According to the documentation [9], it is the byte after the file extension. For ease of understanding, I used Hex Workshop [10], which has the ability to edit disks and logical volumes. In addition, it allows the creation of custom structures to interpret the displayed bytes. I created a simple structure ( fat32-directory-table.hsl ) to reproduce the FAT-32 Directory Table.
The byte in question is a bitfield, where each bit corresponds to an attribute:
BitMask Attribute
0 0x01 Read Only
1 0x02 Hidden
2 0x04 System
3 0x08 Volume Name
4 0x10 Subdirectory
5 0x20 File
6 0x40 Unused 1
7 0x80 Unused 2
Remembering that in the video I showed that Vaccine writes this byte as 0x20 (File) and then searches it on disk and changes it to 0x42 (Unused 1 + Hidden). That's where the magic lives. I don't know why, but when the 0x40 attribute is set, it is not possible to read, execute, modify or delete the file. I did tests with the other attributes but the expected behavior only happens with this same set 6 bit. Implementation Attempts I naively tried to implement the feature in USBForce, which was written in VBScript, but the "Attributes" property is an enum of predefined values and doesn't accept any value, so I didn't accept 0x42:
Set objFSO = CreateObject (“Scripting.FileSystemObject”)
Set objFile = objFSO.GetFile (“F: AUTORUN.INF”)
objFile.Attributes = & H20 'File
WScript.Echo “0x” + Hex (objFile.Attributes)
objFile.Attributes = & H40 'Not used 1
WScript.Echo “0x” + Hex (objFile.Attributes)
The code above assumes that there is already an autorun.inf file on volume F. It prints 0x20 and then 0x0, meaning an attempt to enable the unused attribute fails.
References
USB media, and in particular pen drives, are responsible for much of the virus and malware infections on workstations and even servers used by unsuspecting users. A simple “stick” of a USB flash drive can bypass all security measures implemented in the network environment. With that in mind, I decided to look for a way to passively immunize a USB media, so that the protection is on the media and not on the machine. There is no mitigation, but it is possible to greatly reduce the risk of infection with the technique I will present.
2. How Infection Occurs
When a USB media is inserted into a Windows machine, the auto-play feature starts. If at the root of the media there is an autorun.inf file, it is read by the system and its instructions are processed automatically. The most efficient technique for infecting USB media is then to copy the malware itself (usually a PE binary) to the media and also create an autorun.inf at the root of the media that runs the malware every time the media is inserted into a Windows machine. This process is explained in the text “How to remove flash drive viruses” [1], which I wrote in January 2010.
3. The Idea of protection
There are several attempts to prevent these infections, from simple programs that try to remove virus traces on USB media to more complex software, dubbed USB “firewalls” that allow you to control all traffic. The problem is that the machine is protected, but not the USB media. If you use the flash drive, for example, on another machine, it can become infected and serve as a means of spreading because the software that protects the USB is on your machine and not on the flash drive.
Since all malware I've analyzed creates an autorun.inf to self-reproduce, the idea is to create a healthy autorun.inf on the root of USB media that is “unalterable”, “undeletable”. This way, malware will not be able to overwrite the healthy autorun.inf for its malicious and malware executable can even be copied to the media, but will not boot when the media is inserted into any Windows, ie it will simply be stored on the media. , but harmless (unless some user manually finds the executable and runs it). But is it possible? Let's go to the tests. Checking the possibility
After some searching on “indelible” file creation, I found Panda USB Vaccine [2], which promises to do exactly the proposal. It actually works and creates an “undeletable” autorun.inf on the root of USB media. The drawback to me is that it is closed source software and there is no documentation on how it does it, and it only runs on Windows. I was developing USBForce [3], free software for pest protection on USB media when I found Vaccine. Naturally, I would like to implement this functionality of creating an “undeletable” autorun.inf in my software. Besides, I couldn't sleep without knowing how (technically) this file is created and if it was undetectable.
4. Reversing the Vaccine Technique:
I used some tools to know how Vaccine works, starting with the RDG Packer Detector [4], which, besides other features, can know which compiler is used to generate the binary, very useful information before debugging: RDG informs that there is no packer and that the software was written in Borland C ++. You can't take everything for granted, but it's a good starting point. In addition, RDG detects a call to the IsDebuggerPresent function [5]. Some software closes when they realize that they are being debugged and this function is one way to have this perception. Usually the compiler puts some interesting information in the .data section of the generated executable. It doesn't hurt to look quickly at what's in there. For this I used pev [6] with the “-s” option to display information about the executable sections:
> pev -s USBVaccine.exe | more
Sections:
Name: .text
Virtual size: 0xd9000
Virtual Address: 0x1000
Data size: 0xd8600
Date offset: 0x600
Characteristics: 0x60000020 (01100000000000000000000000100000)
contains executable code
is executable
is readable
Name: .data
Virtual size: 0x1d000
Virtual Address: 0xda000
Data size: 0x12c00
Data offset: 0xd8c00
Characteristics: 0xc0000040 (11000000000000000000000001000000)
contains initialized data
is readable
is writable
Knowing the offset (position) where the .data section starts, I used hdump [7] to peek at the bytes:
> hdump USBVaccine.exe | findstr “d8c [0-9] 0 ″
000d8c00 43 6f 64 65 47 65 61 72 20 43 2b 2b 20 2d 20 43 | CodeGear C ++ –C |
000d8c10 6f 70 79 72 69 67 68 74 20 32 30 30 38 20 45 6d |
000d8c20 62 61 72 63 61 64 65 72 6f 20 54 65 63 68 6e 6f | barcaderoTechno |
000d8c30 6c 6f 67 69 65 73 00 00 00 10 40 00 b2 12 40 00 | logies…. @… @ |
000d8c40 b2 12 40 00 22 15 40 00 01 00 00 00 00 00 00 00 | .. @. ”. @ ……… |
000d8c50 fc 64 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .d @ …………. |
000d8c60 30 99 4e 00 4c ad 4e 00 50 ad 4e 00 68 d0 4b 00 | 0.NLNPNhK |
000d8c70 c0 d1 4b 00 50 d2 4b 00 e4 d3 4b 00 b0 93 4e 00 | ..KPK… K… N. |
000d8c80 00 00 f8 ac 4e 00 74 ad 4e 00 ec aa 4e 00 00 00 |… .NtN… N… |
000d8c90 00 00 00 00 00 00 00 00 00 00 00 90 90 00 00 00 00 | ……………. |
In fact, it looks like the binary was written in Borland C ++, but with a more current version (Embarcadero bought Borland's CodeGear division).
Let's go to the software execution:
What we are looking for is the event code “click” of the “Vaccinate USB” button, right? There are specific tools for working with binaries generated on specific versions of compilers. In the case of BC ++, there is a particularly interesting tool called E2A (Event To Address), which can tell the address of each software event, which makes life much easier:
The function address that the button's click event calls is 0x404C58. Now it's debugging. I used OllyDbg [8] for this. The idea is to place a breakpoint at this address, run Vaccine on the debugger, click the button to vaccinate the media and follow step by step what the software does from the breakpoint.
5. Understanding Protection:
As shown in the video, Vaccine creates a normal AUTORUN.INF file at the root of the media, but then looks for the entry of this file in the FAT to locate the byte that controls the attributes. According to the documentation [9], it is the byte after the file extension. For ease of understanding, I used Hex Workshop [10], which has the ability to edit disks and logical volumes. In addition, it allows the creation of custom structures to interpret the displayed bytes. I created a simple structure ( fat32-directory-table.hsl ) to reproduce the FAT-32 Directory Table.
The byte in question is a bitfield, where each bit corresponds to an attribute:
BitMask Attribute
0 0x01 Read Only
1 0x02 Hidden
2 0x04 System
3 0x08 Volume Name
4 0x10 Subdirectory
5 0x20 File
6 0x40 Unused 1
7 0x80 Unused 2
Remembering that in the video I showed that Vaccine writes this byte as 0x20 (File) and then searches it on disk and changes it to 0x42 (Unused 1 + Hidden). That's where the magic lives. I don't know why, but when the 0x40 attribute is set, it is not possible to read, execute, modify or delete the file. I did tests with the other attributes but the expected behavior only happens with this same set 6 bit. Implementation Attempts I naively tried to implement the feature in USBForce, which was written in VBScript, but the "Attributes" property is an enum of predefined values and doesn't accept any value, so I didn't accept 0x42:
Set objFSO = CreateObject (“Scripting.FileSystemObject”)
Set objFile = objFSO.GetFile (“F: AUTORUN.INF”)
objFile.Attributes = & H20 'File
WScript.Echo “0x” + Hex (objFile.Attributes)
objFile.Attributes = & H40 'Not used 1
WScript.Echo “0x” + Hex (objFile.Attributes)
The code above assumes that there is already an autorun.inf file on volume F. It prints 0x20 and then 0x0, meaning an attempt to enable the unused attribute fails.
References
- https://www.mentebinaria.com.br/articles/security/how-to-remove-pen-drive-r5-virus/
- http://www.pandasecurity.com/homeusers/downloads/ usbvaccine
- https://github.com/merces/usbforce
- http://www.rdgsoft.net
- http://msdn.microsoft.com/en-us/library/ms680345(VS. 85) .aspx
- https://github.com/merces/pev
- https://github.com/merces/hdump
- http://www.ollydbg.de
- http: / /www.nationmaster.com/encyclopedia/VFAT#Directory_Table
- http://www.hexworkshop.com
How To Protect USB Media
Reviewed by Vaishno Chaitanya
on
October 29, 2019
Rating:
Reviewed by Vaishno Chaitanya
on
October 29, 2019
Rating:
Posts
No comments: