Two pieces of the story that don’t add up for me.
Two pieces of the story that don’t add up for me.
This is telling you that your experience is limited, not that the story is wrong. Trying to do egress filtering at scale is extremely hard for all but the most basic threats. If they open a socket to data-collector.pla.cn, yes, probably a majority of large shops would notice that within a few months but what if it's just a connection to S3/EC2, buried in the noise of all of the legitimate use of those services?
Think about how hard it is if the attacker is smart enough to bundle that into other traffic: compromise your mail server and have it respond slightly differently to some spambots, have a webserver respond to the Baidu crawler with actual data encoded in the cookies it sets knowing that the Great Firewall can pick the data up (Baidu doesn't even have to be involved – just something which gets packets somewhere they can see them), etc. If it's on a network with people, that's especially easy – is that user-agent hitting sites in China a bot or just the staffer who keeps tabs on market news for that region? (But, you may say, our user and server networks are tightly segregated! Does that apply perfectly to your terminal servers? How would you know if your web proxy started making a few extra requests?)
The mention of seeing a problem first in a Siri data center was interesting to me because those data centers probably have very consistent network activity and it'd seem like the kind of place where the defense team would have the best chance.
There is no way that any large tech company security operation misses this traffic phoning home from a management vlan.
1. The implant can use the host network interface before the host OS starts 2. The implementation depends on VLAN tagging and the implant simply uses configures its network interface to use the same tag as the host interface 3. The implant can compromise the host OS when it loads and use its networking stack after it loads
IIRC the original story mentioned en passant that at least one company detected some odd behaviour on the network, which eventually resulted in hw examination and the uncovering of these moles. TBH, that part is immaterial: it might well be some parallel construction to avoid giving away NSA intel capabilities.
> Where did all the boards in question go?
Warehouse 51 [1] of course.
https://media1.fdncms.com/chicago/imager/best-approximation-...
Also, just because you don’t know where the boards are does not mean that they don’t exist.
Outbound traffic is allowed unrestricted in 95% of the deployments, it is just a life fact, people trust their own systems.
My current deployments allow outbound SMTP only. All software packages (rpm or whatever) get pushed in via rsync from the outside, or are built in an adjacent lab behind the firewalls and pushed across.
Oh yeah - docker. I thought this one was pretty funny:
https://threatpost.com/malicious-docker-containers-earn-cryp...
If you deploy several thousand of those backdoor chips, you wouldn't set them up to ping your C&C infrastructure all on its own. Rather, you'd use a magic string as a trigger to activate the backdoor in some few targets to reduce the chance of the outbound traffic being detected.
The attacker could use this to escape AWS/shared computing sandboxes/containers in order to attack their peers. Exfiltrating the data stolen could be easily hidden in something that looks like legitimate customer traffic.
> has to travel over wire as TCP/IP,
BTW, this is not the case. If exfil via conventional system networking is too hard to avoid detection, they'll find another channel. RF via LOS, ultrasonic, or some of a million other ideas.
Or if they can insert themselves into the maintenance team, they can retrieve their chips at a later date.
Or you can just use the default credentials Cisco is addicted to leaving in their code.
can you imagine how it would go down if a major corporation like apple experienced a hardware hacking based infrastructure breach, contracted a cybersecurity company, and the tech heading their case asked them like "well were you making sure to check which ports were open?"
The chip passes the stolen data between the VM instances by DMA. The stolen data hitches a ride inside an otherwise innocuous TCP packet storing log entries in that S3 bucket.
Logs are routine backed up off site.
There would be absolute nothing at the network level to distinguish the infiltrated packets.
Lower latency scenarios could be devised which would be similarly invisible but allow better command & control.
Original article supposes that the implanted chip was used to modify the boot process of the BMC in such a way that the BMC loaded its software over the network. The question is why this network activity wasn't easily detectable and firewalled off by default.
It seems that you suppose that the chip can be directly used for some sort of userspace-inside-a-VM to ring0(?) escalation. In particular, you suppose that the chip has access to main memory. Can you elaborate on what functionality do you think the implant could've had?
I would assume the reason why no one noticed outbound traffic is because it’s dormant.
> Why haven’t the leakers just provided the actual chip? It should have been as easy as ordering one.
Sure, let me just order up a state intelligence compromise. It's right here on Alibaba right under Official_PLA_61398.