How can you exploit a website that resolves to localhost?

Question

Let's say you're on a pentest (or bug bounty hunting) and you meet a domain that resolves to 127.0.0.1, How can you exploit that? is that even considered a misconfiguration ? sometimes i see domains named like 127-0-0-1.domain.com and it resolves to localhost, why do the developers even need such a thing ?

Answer 1

A service that's running on localhost/127.0.0.1 would only be exploitable from within the host itself.

This type of configuration would indicate an internal-only service, that is intended to be used only from the host itself.

Depending on the service or architecture implemented, this type of configuration would be an appropriate deployment of a service that responds to internal-only requests.

From an external penetration testing standpoint, you would normally do an internal scan after gaining access to a particular internal host to identify these type of local-only services, then you would continue vulnerability scanning and further exploitation, perhaps to elevate privileges or gain access to other resources from that service.

Answer 2

Oooh, that's very dangerous. There are two main attack vectors against such systems.

1. Cross-user same-machine access. Loopback network sockets are notable for being the only mainstream form of IPC with absolutely no support for authentication or access control (you can try bolting something on at the application layer, like TLS, of course). As such, an attacker on the same machine - likely even one within a sandbox such as an app from an app store or a malicious page in a browser - can connect to the server as a client, or possibly even spoof the server (launching before the server does and squatting its port) and wait for the legit client to connect. This can allow local EoP to attack other users and/or break out of a sandbox.
2. Spoof DNS and impersonate the server. If you have local network access (e.g. on public WiFi at an airport or cafe) you can spoof DNS responses and make the DNS query return your own IP instead of the loopback address. You can then run a server yourself and impersonate the real server (optionally forwarding traffic back to the real server - after modification, if desired - assuming it listens on external interfaces). Obviously this won't work if the client expects the server to use a trusted TLS certificate, but this sort of system almost never does. This allows a remote attack on the system, and depending what the client does, you might be able to gain local code execution, steal credentials, or otherwise compromise the user.

---

sometimes i see domains named like 127-0-0-1.domain.com and it resolves to localhost, why do the developers even need such a thing ?

CORS and/or cookies, mostly. They want to be able to serve content (almost always web content) from a local process, but also want it to be treated as a "real" subdomain that shares a root domain with "the rest of" their servers. This means you can share cookies across the subdomains, use a simple CORS policy that forbids foreign domains, or even lower the page origin to the same root domain on both the local and remote servers' pages and actually be treated as same-origin for purposes such as iframes. Some browsers and platforms (mostly Apple's) also treat "real" domains better than IP addresses even when not required by the spec.

It can also be done for TLS - no real CA will issue a cert for "127.0.0.1" or even for "localhost", but "127-0-0-1.domain.com" works - but it would be very weird (and possibly dangerous) if that's happening here. A CA-issued cert for that domain would require that the private key be distributed with the application so that the server could use it, and then of course anybody with the app could steal the key and use it themselves, completely breaking the point of TLS (and also requiring, by policy, immediate revocation of the certificate). Alternatively, you can create a self-signed certificate and install it in the machine's/browser's trust store, but you can do that without bothering to use a "real" domain on DNS.