In Part 1 of this article, we have seen how to reprogram the Phison USB controller in order to change the personality of a USB Pen-drive.
In this second part, we will explain how we used this "feature" in our customer engagement.
Our payload
When we discovered that we could create a single CD-ROM partition (and completely hide the expected read-write USB partition) we decided it was actually a better scenario than the old U3 drives. We wouldn't want our users to actually search for the file between two drive letters! The USB is seen as a single CD-ROM drive and "AutoPlay" should encourage the user to click on the executable.
The content of our ISO image looks like this (click on images to enlarge):
The "autorun.ini" and the "Files" subfolder should be hidden. We couldn't find a free Windows program that was able to carry the "hidden" flag from NTFS to CDFS so we simply created the image with "mkisofs" under Linux, with the following command line:
The "-J" flag creates a Joliet file system which supports Windows-specific extensions on CD-ROMs, including the "hidden" flag.
The "Navixia.pdf.exe" is our payload. It's an executable that we have compiled and that uses the Adobe PDF icon. On a computer that hides both the extensions and hidden files (default configuration), the content of the CD-ROM looks like this:
When executed, our payload would simply ex-filtrate basic information via both HTTPS (using proxy settings and transparent authentication if configured on the victim's workstation) and DNS queries.
The executable would also open a real PDF file (located under FilesSample.pdf) because, at the end of the day, this is what the user is expecting!
The last bit is the "autorun.inf" file. Its syntax is well described here [Ref1] and we ended up with this content:
- Open: specifies the executable behind the first "AutoPlay" action
- Action: specifies the name of that action
- Icon: specifies the icon that will appear on the drive letter. Not strictly required.
- Label: specifies the name of the drive in the file explorer
When this USB key is inserted under Windows 8.1, "AutoPlay" will show this at the top-right of the screen for a few seconds:
If the user clicks on it, it then show the "AutoPlay" menu:
Clearly, the top entry is our malicious execution and you will agree that this user interface is far from perfect. Chances are good that the user will actually launch our executable. Signing our executable would even increase the chances. If the user doesn't catch the "AutoPlay" action, then he should normally navigate to "My Computer", finding this:
Again, double-clicking on the CD-ROM drive would actually launch our executable if "AutoPlay" is enabled (turned on by default).
Finally, our user might be extra-careful (or "AutoPlay" has been disabled) and he would right-click -> Open the drive. In this case, he would see our single file (the rest being hidden). Double-clicking on it would execute it as well.We will not go any deeper into the specifics of the project but all we can say is that it worked beautifully,Game over!
ADS and SmartScreen
One nice side effect of sending files on USB/CD-ROM drives compared to E-Mail attachments or Web downloads is that CDFS and FAT32 do not support "Alternate Data Streams" (ADS).
This NTFS feature is used to flag files downloaded from the Internet and is at the heart of Windows security. On Windows 8 and later, this NTFS Data Stream will also trigger "SmartScreen". Windows will evaluate if a file has been seen before (by obviously sending hashes to Microsoft). If the file is completely new (never seen before), or suspicious, or if the Microsoft cloud service is not available, then the user will get this prompt:
In our case, the executable is considered a local file and fully trusted by the operating system.
Microsoft should probably evaluate the consequences of treating files coming from external drives and CD-ROMs in the same way they do for files downloaded from the Internet, without the requirement for NTFS-specific features.
Counter measures
In a corporate environment, we consider that the top-of-the-list action is user training and awareness. Users need to be able to detect such scenarios but they also need to understand that today they have become direct targets. "Sensitive" categories of personnel, such as human resources, finance and top executives, will need to be trained extra well!
On the technical level, disabling "AutoPlay" and showing file extensions is easy through Group-Policies and should be part of the standard desktop configurations.
Showing hidden files might be confusing for regular users but still a good idea for the more tech-savvy.
Future work
While creating those USB keys, our team had many interesting related discussions, especially regarding automatic code execution.
For instance, we wondered if USB could exploit DMA the same way FireWire did in the past. According to the USB specifications, the protocol doesn't allow direct memory access from a USB device and only the host controller (on the computer side) can perform DMA. That looks like a dead-end for attackers.
However, the fact that Apple's new MacBooks and Google's Chromebooks now use the USB type-C interface for everything (including charging) generates much talk on the Internet and many people argue that this new USB interface might be a potential attack vector.
Another idea would be to combine our work with a Teensy device [Ref2] and create a dual-personality drive that would be both a CD-ROM and a keyboard. The keyboard part of the drive could help in actually executing the CD-ROM hosted executable. From the work of the BadUSB guys [Ref3], it even seems possible to reflash the Phison controller and have it act as a keyboard, without any hardware changes.
Firmware hacking is yet another field. This paper from 2014 [Ref4] explains how to modify a hard-drive's firmware in order to potentially insert malware into it. It is now obvious that the NSA has been using such techniques and they even tell us in this Snowden leak [Ref5] that these are published Interns' projects:
Reversing the USB controller's firmware, it might be possible to hook into read/write functions and potentially modify data on-the-fly. This would obviously happen at a very low-level, below any OS or file system structures. Still, there might be ways to interact with data streams in a malicious way.
Conclusion
This article describes an interesting journey into the world of USB Pen-drives.
- We demonstrated in Part 1 that a standard Pen-drive can be reflashed and made to behave in different ways.
- In this second part, we described how we created a malicious payload to pen-test one of our customers.
At this point, we feel that we just scratched the surface of such an USB attack vector and that a lot still has to be discovered.