42

It happens that I participate in a bug hunting program and analyzing the app I realized that there is a particular parameter that is very important for access control and that only changes with the IP address.

Anyway, the question here is if I can set a specific public IP address. I don't need to receive a response, just issue a request to parse the request.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Carlos Bello
  • 575
  • 4
  • 11
  • Great question! I would love to see a canonical answer to how the TCP/IP stack determines the IP address of the client, and whether that is spoofable. – Mike Ounsworth Feb 23 '21 at 15:05
  • 40
    @MikeOunsworth You can spoof whatever you like at the host level. Convincing the rest of the network to go along with it is the hard part. – gowenfawr Feb 23 '21 at 15:29
  • Related: https://security.stackexchange.com/questions/1062/why-dont-isps-filter-on-source-address-to-prevent-spoofing – mti2935 Feb 23 '21 at 15:38
  • 1
    Are you in control of the server that hosts the app? If yes, then you can setup a VPN between the client and the server, and use any IP address you want inside the VPN. – user000001 Feb 24 '21 at 07:16
  • "a bug hunting program".. if this was some sort of competition, you might try testing whether the machine that has this special IP is running some sort of proxy that you need to find out how to use. if this is just software analysis for a job, this fact should be mentioned in the final report, as hardcoding IPs for special access in an app is generally considered a bad move. – WooShell Feb 24 '21 at 14:48
  • Can you deploy the app locally or at least under a private network you have **full** control of? – usr-local-ΕΨΗΕΛΩΝ Feb 24 '21 at 15:34
  • Do you have control over the network this is done on? Or do you have to access the machine over the public Internet? – David Schwartz Feb 24 '21 at 22:51

6 Answers6

73

You can send out a packet with whatever IP address you like.

Then, one of the routers along the way might decide the packet makes no sense (it is a "martian packet") and discard it. Consider this:

                                                       | 192.1.1.1
                                 +------------------- GW4
                                 | 192.168.1.1
             +----------------- GW2------+
             | 192.168.16.1              | 192.168.33.1
      +---- GW1 -----+             ---- GW3 ----
      |              |
192.168.16.15   192.168.16.243
     YOU           ALICE

You send out a packet with a source address of 10.0.0.36 and directed to, say, 172.16.16.172. GW1, serving your network which is 192.168.16.0/24, only expected to receive packets matching 192.168.16.0/24, and your packet doesn't match, so it is dropped. You could spoof a connection coming from your "neighbour" Alice, but no more.

Even if GW1 did not complain, it would forward the packet to the next hop, which serves the whole 192.168.0.0/16 branch and also would ignore your packet.

And so on and so forth (the IP I used are actually not all that routable, but it's an example).

Granted, many routers won't do "ingress filtering" because they'll be obsolete or will believe it unnecessary and not cost-effective. But it only takes one hop to wreck the transmission.

Even without this hurdle, the difficulties are not over, because let's say you succeed in delivering to your target a packet coming from 10.0.0.36. The target will reply -- and will reply to 10.0.0.36, so the reply packet will never get back to you. Indeed, should the reply packet arrive to 10.0.0.36, the latter would simply reset the connection as unsolicited.

This is a problem, because most protocols where you "only need to issue a request" are in fact sent over TCP, which requires a handshake between the communicating parties before any data can be sent. The major exception is HTTP/2,

And without that first reply packet you have precious little chance (not the same as zero chances, but still) of establishing a full TCP connection, without which you probably won't be able to send your request.

You might be able to do this using UDP, or other protocols which have no handshake, if the target application uses UDP (it probably doesn't).

Community
  • 1
LSerni
  • 22,521
  • 4
  • 51
  • 60
  • 3
    Ingress filtering, not egress. – jcaron Feb 24 '21 at 00:42
  • 3
    @jcaron this answer describes packets being filtered on the way *out* of network, so egress is correct – coagmano Feb 24 '21 at 02:56
  • 1
    @jcaron It looks like he's talking about egress filtering, not ingress – slebetman Feb 24 '21 at 05:06
  • 4
    Ingress v egress is based on the interface where the filter is applied, i.e. on the interface where it enters the router (coming from the customer) or on the one where it exits the router (towards the Internet, so already mixed with traffic from other customers). I believe the filtering is usually done on the interface which receives the traffic (on the customer side), and that is were you can have the most accurate filtering, otherwise you can allow people to spoof IPs of other customers of the same ISP. Of course you can do either, or both, but ingress is more efficient (and often simpler). – jcaron Feb 24 '21 at 09:08
  • 11
    While the answer describes packets exiting the network, the check is done when they *arrive*. So @jcaron *has* the right of it - it's ingress filtering, not egress. – LSerni Feb 24 '21 at 09:45
  • From a practical point of view: When I want to sent my packet to a computer in a "random" fairly modern network in 2021, is it common that at least one of the gateways which my packet must pass uses an ingress-filter? – anion Feb 24 '21 at 15:25
  • @anion depends on several factors. Mainly who the "fairly modern network" is and who maintains it. My current ISP - *now*, this twenty-fourth of the month of February in the year of Our Lord two thousand fscking twenty-one - happily routes the 192.168.0.0/16 network, and there is a different, equally illegal network where some hosts *are answering my pings*. And yes, I am *paying* for this :-( – LSerni Feb 24 '21 at 17:19
  • @LSerni Could you clarify what the "precious little chance" of establishing a TCP connection without being able to receive the reply packet would look like? Curious how that would work. – Joel Feb 24 '21 at 17:39
  • 1
    @Joel https://www.greycampus.com/opencampus/ethical-hacking/network-or-tcp-session-hijacking – Rick Feb 24 '21 at 19:23
  • If you use a VM, the packet might not even get out of your virtual machine. For example, the KVM hypervisor control library libvirt implements both ingress and egress filtering on its virtual networks. – Michael Hampton Feb 24 '21 at 20:20
  • 3
    HTTP/2 is also going over TCP (and usually TLS). The point of HTTP/2 is to have multiple request-response pairs in the same TCP connection (and even in parallel), but it's still TCP. You might be thinking of HTTP/3, which is using QUIC over UDP (and doesn't have an RFC yet). – Paŭlo Ebermann Feb 24 '21 at 21:58
  • To be clear, egress filtering is a thing, but afaik it's not generally used at router level. Ingress filters should ideally be set to have the accepted routing packets match up with the published routing, but doing that thoughtlessly will break asymmetric routing. Ideally you put the ingress filter at the first layer 3 hop or NAC, buuuut that's effort and money and people are lazy. The reason routers don't do much egress filter is because the packet has to ingress to that router first and that's a better point to map an IP to allowed origin. – Kaithar Feb 25 '21 at 10:53
14

Probably not, depending upon whether or not your ISP is implementing Ingress Filtering:

a technique used to ensure that incoming packets are actually from the networks from which they claim to originate.

If your ISP is implementing Ingress Filtering, then your forged packets will be dropped as they traverse your ISP's network, and will never reach your target.

The odds are that your ISP does implement it:

As of 2012, one report suggests that, contrary to general opinion about the lack of BCP 38 deployment, some 80% of the Internet (by various measures) were already applying anti-spoofing packet filtering in their networks.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 1
    Note that the 20% if the networks that weren't checking in 2012 were counting on the other 80% for anti-spoofing measures. Most networks without this ability would only be spoofed with comms through their network only. But this is 2021 and this issue doesn't exist or it could easily be used now to divert traffic and could take down providers. – blankip Feb 24 '21 at 20:35
13

Even in the absence of ingress filtering as described in the other answers, IP spoofing will hit another hurdle: the TCP 3-way handshake, and possibly higher-level handshakes.

TCP is the basis for many of the most common protocols, including HTTP, FTP, SMTP, POP3, IMAP and their TLS-secured counterparts, as well as SSH, and many many more.

When you attempt a TCP connection, you send a first packet (SYN). Server replies with SYN-ACK. Client sends ACK. During the SYN and SYN-ACK exchange, random sequence numbers are chosen and transmitted.

If you use a spoofed IP address, the server will send the SYN-ACK to the device which actually has that IP, not you. So you won't receive the server's sequence number, and no communication will be possible.

There used to be issues a few eons ago when the sequence numbers were predictable. That allowed you to send packets blindly on the TCP connection (you would not receive any answer, but you could still send requests). This should now be fixed everywhere (see RFC1948).

If somehow you still manage to do so, most protocols now use TLS on top of TCP, which adds yet another handshake which will very definitively prevent you from sending anything if you don't receive the return traffic.

The story is different for UDP and raw IP protocols, but those have more limited use.

Community
  • 1
jcaron
  • 3,365
  • 2
  • 15
  • 22
2

If access control is done in the application layer and it's a HTTP-based application, you might be able to bypass the check by forging the relevant HTTP headers (e.g. X-Forwarded-For, True-Client-IP, or X-Real-IP).

Vegard
  • 3,032
  • 1
  • 10
  • 8
1

Your public IP address, if issued dynamically, cannot be switched until your ISP decides to. Static IP addresses assigned by your ISP can be switched, but your internet connection won't work unless the specific IP address has been assigned to you and in your IP range/scope.

Note

  • dynamic IP addresses typically are issued using consumer products.
  • static IP addresses are usually assigned to commercial/business products.

So, can you change your public IP address to a specific one?
Yes, and a working internet connection will reside only if you own that IP address and it is in your IP scope/range.

Thanks for covering the TCP-IP basics with us this morning.

Limit
  • 3,191
  • 1
  • 16
  • 35
Stereomac
  • 21
  • 1
0

I think we might be overcomplicating things. If it does not have to be a specific hard-coded value, just use another endpoint.

Of course, if you are a well-funded developer you can build a testbed independently of the internet (your own internet) and re-use public addresses. If you only need different values, you can have multiple IP addresses on the same host, but likely similar.

Consider VPN, VLAN, and VM's, even cloud. Also out of band such as GSM.

Are you filtering with IPTables/Apache2 directives or similar that rely upon any kind of reverse DNS? This will be extra work but bread and butter type work. It may be as simple as configuration management of dev and prod files.

schroeder
  • 123,438
  • 55
  • 284
  • 319
mckenzm
  • 469
  • 2
  • 6
  • "bug bounty" implies that the OP is a 3rd party to the system under evaluation. Which would appear to defeat all of your suggestions. – schroeder Feb 26 '21 at 18:14
  • But they get to analyze the app. which external bug bounty hunters cannot do. Supposedly they could compromise the genuine end points (physically a la Mission Impossible), or the white list as an insider. Of course many genuine insiders don't get to see the back doors either. – mckenzm Feb 26 '21 at 19:35