3 ms·
Netresec should be able to gradually increase the TTL of their packets going to Baidu to see which hop or link is doing the hijack. They mention someone did th
by cxseven 12y ago
Netresec should be able to gradually increase the TTL of their packets going to Baidu to see which hop or link is doing the hijack.
They mention someone did this earlier with the iCloud hijack by using mtr and tcptraceroute, but it looks like these tools won't work as-is this time because the Github man-on-the-side attack waits for the HTTP GET request. It's probably stateless and if so could be triggered by a lone ACK with a proper HTTP GET inside. As long as they're not behind a stateful firewall, replaying their ACK at various TTLs to find the smallest TTL that triggers the hijack would probably do the trick.
If the hijackers are clever they could make it look like the compromised hop is further away than it actually is, but not closer. Even so, this could be useful information and I'd love to see the result if anyone tries it.
Edit: changed trace method so that it'd actually work.
- jackdawjack 12y agoI think this might be a daft question, but why can't they inject packets with a (roughly) appropriate TTL for the current sequence that they're hijacking? From the two examples shown one might think they're picking ttl's more randomly
- cxseven 12y agoThey could make the packets stand out less, but there'd still be the overlapping reply from the legitimate Baidu host, unless the attackers went full MITM. In case anyone is confused: we're now talking about the TTL of the packets coming from hijackers, whereas I was originally talking about the TTL of the packets going towards Baidu and the hijackers. The TTL the hijackers send won't affect the tracing method I was suggesting.