If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside, it could be carrying a virus. Research by one group focused on hiding a trojan inside an AVR Arduino bootloader, proving even our little hobbyist microcontrollers aren’t safe.
The specific aim of the research was to hide a trojan inside the bootloader of an AVR chip itself. This would allow the trojan to remain present on something like a 3D printer even if the main firmware itself was reinstalled. The trojan would still be able to have an effect on the printer’s performance from its dastardly hiding place, but would be more difficult to notice and remove.
The target of the work was the ATmega328P, commonly used in 3D printers, in particular those using the Marlin firmware. For the full technical details, you can dive in and read the research paper for yourself. In basic terms, though, the modified bootloader was able to use the chip’s IVSEL register to allow bootloader execution after boot via interrupt. When an interrupt is called, execution passes to the trojan-infected bootloader’s special code, before then returning to the program’s own interrupt to avoid raising suspicion. The trojan can also execute after the program’s interrupt code too, increasing the flexibility of the attack.
Simply reflashing a program to an affected chip won’t flush out the trojan. The chip instead must have its bootloader specifically rewritten a clean version to remove the offending code.
It’s not a super dangerous hack, overall. Typically, flashing a malicious bootloader would require physical access to the chip. Furthermore, there’s not heaps to be gained by sneaking code onto the average 3D printer out there. However, it’s nonetheless a good example of what bootloaders can really do, and a reminder of what we should all be careful of when operating in security-conscious domains. Stay safe out there!
” Furthermore, there’s not heaps to be gained by sneaking code onto the average 3D printer out there. ”
Networked, or plugged into USB, let the fun begin.
Yeah, especially USB. Trivial to install malware by emulating a keyboard. Yet another method for long term persistence.
Not trivial for an Arduino or similar, their USB interface is over a UART adapter chip, so you aren’t accessing the raw USB pins.
Also, the 328p doesn’t have a native USB interface. There are libraries to allow emulating a USB device, but IIRC they require clocks different from the “standard” Arduino 8MHz and 16MHz, which would lead to significantly (audibly and visually noticeable) different performance from the 3D printer. But again, that’s if the 328p had its pins wired directly to the USB pins, which it doesn’t on the vast majority of 328p products.
A number of the 32bit 3d printer boards don’t interface to USB natively. Instead, they rely on a USB to serial bridge chip (like a CH340) to do the conversion. No room there for USB attacks if all there is at the end of the USB connection is a serial converter.
OTOH some control boards do handle USB natively – those would be more exposed.
ccp
“… if it’s got a silicon chip inside, it could be carrying a virus”.
Wow! I know those 555 lovers are a clever and resourceful bunch – but a virus? Really? Cool! ;-}
Okay next HaD challenge: get a virus into windoze using only a network of 555s. I have faith(if only because of the target, but I believe in you too).
You can build an usb killer with one 555.
I don’t think that many printers use 328p’s.
many open source 3d printers use a basic Arduino.
I believe, the BlackBox CNC Controller uses 328
Modern marlin doesn’t really fit on a 328p. Most avr boards running 3d printers use a 1284p, which is a chip from the same family that has a bit more memory, and a few more pins.
They had some commentary about 328p, but the actual malware was on a 2560.
The principle could possibly be expanded to cover other microcontroller bootloaders? The blue sky is open wide
Low end printers aren’t going to be compromised but high-end ones /could/ be using the same pull-down resistor chip method that became suspect in the Supermicro debacle. That is some NSA-level shit, so it’s unlikely for anyone not intending to print ICBM rocket engines.
Or by a government wanting to detect people printing guns and injecting a potentially fatal defect in the print to keep somebody (else) safe.
I have my doubts with that use case. How should a 3d printer with something with the performance of a 328p or similar recognize ghost gun parts? Those things are essentially motor controllers with g code interpreters and some nice extra features.
It doesn’t work that way though. The gcode file that tells the printer how to print just tells it very basic instructions like “move the x axis this far while moving the extruder this amount”. Open an unknown gcode file in Notepad and see if you can figure out what the final print will be.
Hobbyist microcontrollers are insecure by design so as to not impede the hobbyists, so I don’t see what all the hubbub is about. The point of using open or off-the-shelf hardware is to make the hardware accessible to amateurs.
What’s the real world benefit of taking control of some random hobbyist 3d printers? Unwanted lewd prints in at odd hours of the morning? Who in the world would exploit this, and for what gain?
Too much of security articles these days focus on rare and niche cases for exploit to scare the general public. I personally don’t care if the surface of attack requires that I make stupid decisions to expose non public information about myself. Every day I find more reasons that I should shut off my internet access and return to reading books, and reading material like this article does nothing to abate that sensation.
The snag comes when these things get implemented into products because they’re available, the dev teams have experience and fondness for them, and they’re cheap due to scale.
Infected boot loaders sent out by dodgy suppliers, emulate a keyboard to install malware.
The Microchip ATMega328p is definitively NOT a hobbyist microcontroller, as well as the rest of the ATMega-, Tiny- and the late SAM Series. Those MCU families have existed long before arduino started. I think one of the main reasons why it got popular in many open source hardware projects is the availability of a free / lowcost Toolchain and IDE solution.
Just because specific hardware does not require you to buy compiler licences and SDKs for several thousand dollars does not automatically classify it as “amateur hardware”.
I think the main reason for this article is to sensitize people for the possibility, that your new stock hardware could get delivered to you with unwanted firmware extensions – which is a universal problem when using preinstalled / precompiled software. It’s not fair to blame the a standard hardware design for that. But people also do not expect their electric toothbrush to be operated by a signed, encrypted firmware on a PSA Level 3 certified chip, right?
Kind Regards
I would expect my electric toothbrush to use a masked ROM but only because it’s so simple. Get a Bluetooth toothbrush and any semblance of security goes out the window.
Why on earth would a toothbrush need Bluetooth in the first place?
I guess for “game-ifying” teeth brushing for kids? But even that wouldn’t require Bluetooth.
Statistics? 🤷♂️ Some medical/fitness applications may be able to log how long you brush your teeth? Or maybe it has a built-in speaker for music playback, dunno ? 😀 I mean, XXX toys with Bluetooth do exist, too, don’t they? To upload new “moves”? 🤣
“What’s the real world benefit of taking control of some random hobbyist 3d printers?”
That’s entirely not the problem here. The target is the computer connected to the printer.
Now that you mention printers.. Network printers and print servers used to a traditional target for malware, too.
“The target is the computer ” – yes, that would be the more interesting case. But that isn’t what this paper was about. It was very much “how to attack the prints made by the printer.”
No, I think the main problem is the USB stack, both in silicon and in the OS. It originally was designed to interface trustworthy peripherals and has no concept to defend itself from the dark side of the force, hi.
Personally, I think that Thunderbolt is much worse. It’s an external version of PCIe 1x, without any safety mechanisms. It allows DMA (USB3+ does too), for example, which technically grants total access to the address space of the PC’s main memory.
https://en.wikipedia.org/wiki/DMA_attack
Personally, I think that old FireWire (aka i.LINK aka 1394) could have done better, maybe, all in all. It was simply more mature and had a relationship to ethernet.
With a quick skim, it seems like this is more of a “back door” than a “Trojan” – they haven’t figured out a way of replacing the bootloader with a compromised bootloader; they’ve just figured out a way for a compromised bootloader to affect 3d printing. Since most people don’t replace their bootloader, and since the bootloader can’t be replaced without some significant effort, it seems like a bit of a stretch.
Using IVSEL to intercept application interrupts is clever, but I think also easily undone by the application.
Yeah, mitigation is very easy. It’s sort of a clever idea, but not really a “risk”, as for replacing the bootloader, you could upload a special firmware that replaces the bootloader and then upload the normal firmware after that. No need for really special effort in other hardware tools or anything.
This!
This is a fun POC hack, so if you’re into that sort of thing, it’s really cool!
This is _not_ an “oh my god, I need to worry about this” hack.
You are spooked by Putin? Come on. North Korea? Pfft. CCP like the next guy said is a far more likely option.
Look up Crypto AG. The call originates inside the house. But in this case it’s a friendly white hat cybersec researcher (hopefully) only interested in the paper. If he weren’t, you most likely wouldn’t be reading about it right now. Only a very scrupulous person discloses a zero-day.
The point is: They proofed it because they could. Why not? It is to show, where trojans and viruses can be potentially installed and affect our devices.
In this particular case I can think of a supply chain attack: The manufacturer of arduino clones could flash the bootloaders with a malicious version.
This would affect thousands of users.
Yes, the attack is somehow harmless. But still, we should improve the security of every device and we should especially pay attention to devices that are manufactured by non-genuine manufacturers.
Cybersec researchers are like that. Be glad they come out with zero days and publish it instead of the alternative. They find a lot of “so what” but they also occasionally find a doozy, and it’s good they’re always looking.
alies for sure
You could use it to interfere with the operation of one axis of the machine just enough to encode a serial number into all prints made with the 3D printer, just enough to show up on forensic inspection but otherwise not noticable. A bit like the yellow dot codes on color printers.
It’s possible to overwrite the ATMEGA328 AVR bootloader using an application, even though the datasheet said that can’t be done. So, one can overwrite the trojan bootloader with a clean one (or vice-versa!!!).
https://hackaday.com/2014/07/05/overwriting-a-protected-avr-bootloader/
This is the same principe as what we (at my former employer) did use on a 8051 based remote io. We got tired of changing eproms after a software change at our customers (worldwide). So the eprom had only the “boot” code and the the “appl” code was downloaded from the “operating application” at its initializing stage, which did run on a DOS pc. The 8051 uses different memory maps for code and ram (both 64k) with the same address. By mappng the upper 32k of CodeMem and DataMem to the same SRAM you chould (needed) to download the “appl” code.
For communication we are using (our) “multi master” implementaion of RS485 (375 kBps 9,N,1) the transfere speed was about 15 kbyte per second.
This did happen in 1991/1992 and was in production for over 20 years, there are stil a few hundred machines running at the moment.
A) neat.
B) this is the way.
In other words, before you use that new shiny Arduino from AliExpress, get out your old trusty USBasp you soldered yourself in $favoriteHackerspace aeons ago and flash a new boot-loader onto it.
All the more reason to use Optiboot, and for a program to check the loader version and- if possible- fuses when it starts up.
And what do we learn from this (aka moral of the story)?
Exactly! Do safer information exchange! Use traditional serial ports like EIA-232 (PC) or RS-422 (Mac) for a serial connection!
Give USB no chance! 😎
Macs haven’t had native RS-422 for…
(flips through calendar)
… 24 years and 1 month when the iMac replaced all I/O except Ethernet with USB.
And while some PCs still have RS-232 like ports, they’re not common to be brought out to an external connector and rarely fully compliant to the spec.
What makes those protocols safer than UART?
Did you read the article? The Trojan isn’t on the FTDI or CHM UART-USB IC, just the AVR. As far as the AVR is aware, it IS on an RS-232 port. The AVR is unaware of USB.
Reading is a great way to become less ignorant.
This particular attack had nothing to do with USB.
“If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside,”
Nope! Not this time! Can’t do that with a 555!
Wasn’t there that student that hid a PIC in a TTL to fool his teacher? 😏
“If there’s one thing we’ve learned over the years, it’s that if it’s got a silicon chip inside, it could be carrying a virus.”
Nope! Not this time! Can’t do that with a 555!
maybe not so useful to do on an atmega. but think about all the wifi connected iot devices. you could flash a bootloader onto a bunch of WiFi chips before they are sent to a manufacturer to be baked into products. the main application works as expected so nobody is suspicious, and then the user connects it to their wifi themselves. boom, big botnet achieved
I guess it’s way too much to hope for that people would actually READ the paper in question, or at least the full HaD article, before jumping to conclusions about what they think it must have said? Sheesh!
och no!
my arduino ;(