I have a question regarding the security of the loopback interface. It's particularly vague and deliberately conceptual as I'm not looking for answer along the lines of (considering the example below)- "well Tor's really secure so you don't have to worry about it" please! I'm happy to clarify where parts are unclear, and will gratefully accept all consignments of tin foil and hat making instructions
So far as I can tell, anyone who gets hold (read compromises) a user account on a machine can write and read to and from the loopback interface.Is this bad news?
Say you have a service, like many of us do, which speaks to another service on localhost. localhost is an alias to 127.0.0.1, which is the loopback device. Say the service makes a connection to localhost:555 (really, any port). This traffic travels unencrypted, in plain IP (with varying protocols: T_SQL, HTTP, SMB, etc), over the loopback to the service it must contact and the response does the same.
It is possible to sniff the loopback, e.g: wiki.wireshark.org/CaptureSetup/Loopback
Consider the case where someone has, unknown to you, compromised a user account your machine, (possibly the system account of another unprivileged service, through a vulnerability within the software code of that service). Your attacker can now open a connection to localhost and sniff the loopback device. That connection can be used to read the data traveling over the loopback, which may contain passwords or other sensitive data. From there, the attacker has all she needs- either the data she was looking for or the passwords that may let her get what she seeks.
Is this even a possibility? Or am I just being too paranoid- I do know that it is still possible to obtain user level/shell access through software vulnerabilities (although someone did mention 3.x kernels make it (their highlight) impossible Is this true- the comment is in a post I made for the curious, and I've only made, like 4? for (at least) system users to gain root access).
If it is possible, I don't understand how I'd be able to protect against this kind of attack- in the case where the compromised system account is different to the two who are in communication, an encrypted connection over the loopback would (I guess) suffice. But what about if the compromised system account was one of the two involved in the communication? Then the attacker would have access to the encryption method and properties, rendering the whole exercise useless (the key or other encryption property's integrity cannot be verified).
This is particularly important if you consider a simple common setup:
SERVER : OTHERPORT [e.g. Backend service]
SERVER : PORT <----> GATEWAY/FW : PORT <----> INTERNET <----> Loser
[e.g. Web Service]
The gateway can't have any prior knowledge of malicious traffic, and it would be unwise to trust it to make decisions which affect the security of the server (this is common sense- everything at the server, regardless of theoretical or reported origin, should be untrusted). But the service could easily become compromised. Even if the port is protected through something as complex as access control, the underlying control could become compromised, feeding in packets which should be untrusted through a connection on which only trusted packets are expected. Therefore the port cannot be trusted to remain secure, and neither can anything that can be read by the service bound to the port
If an attacker could come to gain access to a system account they could sit all day and explore otherwise closed ports, attempt to communicate with those ports without anything being logged or counteracted. They could attempt to brute force passwords of services running on common ports, a possibility that is more alarming if you don't detect the initial break in, etc, etc.
But here's the catch- if you do encrypt the loopback traffic between the two services, the web service will need a private key. That private key will need to be readable by, er, the web service (or at least, it will be in the memory of the system at an address the user running the service can request to read), so if the webservice is ever compromised, that particular channel is now open to be read by the attacker. It defeats any and all PK type secured communication to any services which trust the web service port (there might be more than the one communication need present on any given machine than shown in the basic example above).
Worse, what if a service was 'protected' behind a reverse proxy but relied on a backend which demanded communication over the loopback in plain protocol? What if this service was an OCSP responder- then anyone could arbitrarily alter the status of certificates for which the responder was responsible, just by getting hold of the loopback. What if that service was a database with service generated weak passwords- then anyone watching could either have a go at cracking it where they sat or retrieve the value to a remote system to do the same.
I've seen IPTABLES can be used to "tag" incoming packets (for example, helping with rate limiting). Could the same mechanism be used to restrict traffic on the loopback to packets which have a corresponding request from the internet? Are there any tricks out there which can help me avoid the loopback? Would using UNIX sockets instead of the loopback suffer from the same transport security 'risks'?
Obviously, care with user accounts is a fundamental must. Thanks for listening, any response whatsoever is appreciated!