3

Imagine a user has an ip of 1.2.3.4

The server the user intends to connect to has an ip of 2.3.4.5

An attacker has a machine with a promiscuous network card on the user's local network.

The attacker also has a server on a seperate network with ip 3.4.5.6

The user sends a request to 2.3.4.5, which the attacker had DDOS'd. As such, 2.3.4.5 will not respond.

The attacker's machine on the user's local network sniffs the request and sends it to the 3.4.5.6; 3.4.5.6 is set up to take this information to form a request to 1.2.3.4 where it spoofs the IP of 2.3.4.5 and has all the required TCP Sequencing information to form a request that looks real.

When the user sends another request, it is once again sniffed by the attacker's local machine and sent to 3.4.5.6 which can then send another false request. The cycle continues.

Since 3.4.5.6 appears to be 2.3.4.5 and since 3.4.5.6 is NOT located on the user's local network, the user's firewall is unable to detect any foul play.

I'm assuming that this type of attack is not actually possible and that somewhere there is a misconception on my part about how networking works. Why would an attack like this not be possible?

majneeds2chill
  • 31
  • 3

3 Answers3

3

You have some assumptions in the scenario and some simply don't work. Mostly because you are using IPs in your scenario.

What you are missing, but actually hint at, is the TCP handshake. The attacker machine needs to become a true Man-in-the-Middle and re-route the traffic to the server. The server doesn't spoof anything; the attacking machine does. The attacking machine becomes seen as the gateway to the remote server.

Possible improvements to the scenario to make it more realistic:

  • Why send the user's traffic somewhere else? If the attacker is in the user's network, the attacker machine should respond.
  • As mt2935 points out, the attacker gains a lot of benefit due to the fact that DNS is often performed first. Manipulate DNS, and the IP spoofing problem goes away.
  • No need to DDoS the server on the Internet if you can reroute the user's traffic on the local network.

What prevents the problem:

  • TLS. The certificates in TLS mean that the server cannot be spoofed. That's why TLS is now standard on almost every site.
  • DNSSEC. This prevents DNS manipulation. Not widely used, but growing.
schroeder
  • 123,438
  • 55
  • 284
  • 319
  • That works if the service here is protected by TLS, and the client actually checks the certificate(s). That's a reasonable assumption for anything web related, but OP was more generic. – Ricky Oct 28 '21 at 01:20
  • @Ricky ... yes, TLS has to be in use or added. Just like DNSSEC. These are 2 things that can prevent the problem. I'm not sure what your comment is trying to say. – schroeder Oct 28 '21 at 07:24
  • I'm saying the unspecified service would have to (properly) support TLS. [if it works via IP, then it likely isn't checking the cert.] I would expect the security SE to not speak in such absolutes... TLS does *not* mean the domain *cannot* be spoofed; it makes it some measure of difficult. If you're a household name like Paypal, or eBay, getting a trusted cert will be difficult. If you're not, we'll it's not so difficult to get Let's Encrypt to give you a cert. (Other CA's have been tricked as well.) – Ricky Oct 28 '21 at 08:02
1

An attack like the one you describe is very possible. In fact, it's even simpler to pull off an attack like this if you control the network's gateway router (e.g. if you provide wifi service in a public space). In that case, you can redirect any outgoing request to a server that you control.

This is why it is important to always connect using a secure protocol. And, this is why we have PKI, certificates and certificate authorities.

Users don't typically make requests using IP addresses like 23.201.25.188, they make requests using FQDNs, like www.paypal.com. If a user points his web browser to https://www.paypal.com/, and an attacker redirects this request to a server that he controls, the browser would display a warning that the connection is insecure, because the malicious server would not have a valid CA-signed SSL/TLS certificate (and matching private key) for www.paypal.com. See Could a stolen certificate show as trusted? for more info.

mti2935
  • 19,868
  • 2
  • 45
  • 64
1

Such an attack is possible, but requires more than you've laid out.

The attacker having a machine in the same local network (IP subnet? Layer-2 broadcast domain?) is not enough. Networks have been built using switches for many decades now, so it's not immediately possible to see any other host's traffic. As the traffic to be intercepted would be going "off net", it will be headed to the gateway for that network. Without controlling the switch(es), the gateway, or ARP poisoning the sender, the attacker will never see it.

IF the attacker can manage to get that traffic directed to them, then as a man-in-the-middle, they can do whatever they need.

IF the attacker can see a copy of the traffic (ala a hub -- switch monitor, MAC table flood, ...), then they can pretend to be the target. However, the traffic is still destined for the router/firewall. An astute firewall admin would notice the impossible active half-connection reaching the firewall. (the firewall itself most likely wouldn't think anything of it.)

Ricky
  • 119
  • 2
  • So, by ARP poisoning, your "IF" conditions are met. You have phrased it as though your IFs are separate or not dependencies. So, if the attacker ... decides not to do what is necessary at the network level to attack ... then an attack cannot perform the IP-level attack. Yes, that's true. but your phrasing would lead someone to a different conclusion. – schroeder Oct 28 '21 at 07:30
  • A or B, not both. If you can do A, there's no need for B. If you can do B, why expend the effort to get to A. (the key issue is seeing the traffic in the first place.) – Ricky Oct 28 '21 at 07:53