Apple Tells Congress 'Nothing Was Ever Found' to Suggest Alleged Supply Chain-Based Hack

[techwhiz]

Evidence:
https://www.bloomberg.com/news/arti...cked-supermicro-hardware-found-in-u-s-telecom

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.

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.

Once again, the chip doesn't know if they are running burn in or a real application.
So how do you propose it distinguish at boot time, what the machine is doing.
Again, does not make sense.

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, but fundamentally it is a BIOS (Basic Input Output System).
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.

 

[jtara]

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.

No, it doesn't. Somebody found a different hack. An easier one. That somebody planted an easy one does not preclude that somebody else planted a harder one. Faulty logic.
[doublepost=1539120523][/doublepost]

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?

I do not assume it is patching the OS. It could be patching firmware in any one of a number of chips, for example.
[doublepost=1539120619][/doublepost]

To have that much smarts and processing power you are not using induction to power a chip.

The article actually implied it does NOT have a lot of smarts. It just needs enough to do the job, whatever that is. It's clear the goal here is NOT to use the chip itself for mass exfiltration. It's not even clear that the goal is exfiltration.
[doublepost=1539120667][/doublepost]

If it's go no pins how do you get inject the data into the kernel space in memory at the right time?

Again, I do not make the assumption that the goal is to patch the OS kernel. At least not directly.
[doublepost=1539120729][/doublepost]

you need to know the address and the programmable register space for each device you want to communicate with.

And how is that a problem? Given that whoever did this almost certainly had board schematics and the BOM?
[doublepost=1539121615][/doublepost]

Once again, the chip doesn't know if they are running burn in or a real application.

The chip can certainly know the current time and date, how long the system has been powered, etc. Probably much more, such as average power usage. Burn-in should be easy to detect. There's a reason it's called BURN-in.

Could be as simple as "wait 6 months". That will work most of the time to insure you are past burn-in. At that point, the system will almost certainly face less scrutiny.

 

[DanBig]

Bloomberg is just throwing the pasta at the wall to see what sticks now!
Just like the Grain of Rice spy chip they now are claiming the Ethernet RJ45 port has been modified to be a spy! This too is just not technically viable and the data rate would exceed what any spy chip could forward or decode.

Folks this is all BS until they can prove it physically from a trusted authority.

 

[Abazigal]

Seems like people are placing more trust in Apple than Bloomberg. Interesting times we live in right now.

 

[marzer]

screams this was a republican hoax

LOL! You do realize this is Bloomberg...of the Michael Bloomberg empire. He only ran as a Republican in NY to ride Giuliani’s coat tails, esp. Rudy’s high post-9/11 approval ratings. Personally, he’s a long time Democrat/democrat supporter with a liberal leaning progressive agenda.