4 ms·
Cloud instances are generally firewalled off from each other, usually cross-account, vpc, etc. Two machines can't reach each other just because they're AWS inst
by dpedu 8y ago
Cloud instances are generally firewalled off from each other, usually cross-account, vpc, etc. Two machines can't reach each other just because they're AWS instances. That would be silly.
- zaroth 8y agoThe attacker and target have VMs on the same hardware. The attacker has a fake presence serving cat pics which is constantly sending “valid” logging traffic to an S3 bucket. 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.
- robryk 8y agoIt seems that you're arguing for a different functionality of the implanted chip than the original article. 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?
- PeterisP 8y agoNot the parent poster, but the chip can indirectly used for such an escalation - the chip would have the capacity to modify BMC software as it's loaded from a nearby memory chip; and BMC has direct access to main memory that enables all kinds of interesting escalation scenarios.