This evidence is a chip found in an ethernet connector.
As I stated, if it's phoning home, then you would be able to detect the if you cared about your network, just py using WireShark or anything else to monitor egress packets.
From the article:
"Three security experts who have analyzed foreign hardware implants for the U.S. Department of Defense confirmed that the way Sepio's software detected the implant is sound. One of the few ways to identify suspicious hardware is by looking at the lowest levels of network traffic. Those include not only normal network transmissions, but also analog signals -- such as power consumption -- that can indicate the presence of a covert piece of hardware."
Also note they indicate the further into the hardware you go the more complicated the hack needs to be. This precludes the idea of a chip tried on the motherboard injecting code into the OS.
[doublepost=1539118700][/doublepost]
The article doesn't state that.
Injection would be at boot time, no OS at that time. And anyway, the OS would almost certainly be some flavor of Linux, as if that mattered.
It matters quite a bit. You need to know where in resident memory to store the patch or you crash the machine.
So how do you determine where to patch the OS, if it isn't loaded yet?
Makes no sense.
I maintain you need ZERO pins. Two makes it easier. Three makes it easier. Four makes it really easy. Both power and signal can be done inductively. If zero pins, power would have to be "stolen" from signal transitions and stored somehow - capacitor or battery. But from the description, not that exotic.
To have that much smarts and processing power you are not using induction to power a chip.
If it's go no pins how do you get inject the data into the kernel space in memory at the right time?
Once again makes no sense.
One version, according to the article, was embedded between the layers of the circuit board.
Not rocket science. It will be a version of Linux or BSD. But probably Linux.
As I stated, if they can embed this between the layers of PCB its small and without direct connection to some portion of the memory or CPU bus, injecting code is going to be difficult.
Everything programmable is programmable over the I2C serial bus. TWO lines. (Sorry, yes, I said one...) You just need to get at the I2C bus. Which runs all over the place.
I know what I2C is, I've designed I2C controllers.
I know the protocol, and I also know that you need to know the address and the programmable register space for each device you want to communicate with. But putting something on the I2C us would be detectible very easily. Also not everything gets programmed over I2C.
Once again, the chip doesn't know if they are running burn in or a real application.It would be rather foolish for it to reveal itself during burn-in. Do you think they are that stupid?
It's a chip that WAS detected. That's a major premise of the article.
So how do you propose it distinguish at boot time, what the machine is doing.
Again, does not make sense.
EFI, but fundamentally it is a BIOS (Basic Input Output System).BTW, I doubt these boards have a BIOS. That's a blast from the past. But I will grant that by BIOS your probably mean EFI, right?
----
EFI and UEFI allow are an Extendible Firmware Interface, but the firmware we are talking about is BIOS.
I'll grant one bit of skepticism. If it was able to communicate with external systems over a separate management port, then Apple/Amazon/whoever was REALLY sloppy. It was mentioned, though, that the discovery occurred in a development environment, and some sloppiness is to be expected there, because "it's not production".
We don't know if they went to the trouble of putting management ports on a separate switch, or even on a separate VLAN. And we don't know if they also had Chinese switches.
There were simplifications made for the article, and the writer admits such. I think any exfiltration or command (and I'm not convinced that was necessarily the goal) would more likely have been done by the infected firmware, whether that might be BIOS/EFI, processor, or other. (Could even be a hard drive controller that would store or deliver modified data.)
That was my point, an easier attack is a peripheral or firmware.
You can more easily infect a USB controller because USB must be enumerated and touched by the processor at a very low level. The USB enumeration will be in a ROM, but instructions can be injected. This is how a virus in the hardware of a USB stick works.
Piggybacking on USB would be easy by essentially making the device act as a hub. Minimal modifications to the board and it acts as a passive participant before and after enumeration. You inject code at each boot, then you just do nothing.
The article had numerous errors and the writers do not understand how a computer works.