6

Please walk through how an attacker can intercept Chrome's connection to 127.0.0.1:999, as suggested by the warning below.

enter image description here

This warning is consitently displayed across many versions of Chrome in many OSes.

When I click the "learn more" link in the message, it says that SSL would be more secure, implying that an attacker can intercept Chrome's connection to 127.0.0.1:999. It is established that any user can open a port on 127.0.0.1. However, according to w3.org, only root can open port numbers below 1024. In light of this, how does the attacker pull off the interception in this case?

Improve this question

4 Answers 4

Reset to default
7

There are a number of different points here:

  • only root can open port numbers below 1024: that is true on most Unix-like OSes such as Linux. But any user can open any port on a Microsoft system, or macOS since version 10.14
  • an attacker can intercept Chrome's connection to 127.0.0.1:999: well 127.0.0.x is the loopback address. That means that for the attacker to intercept the connection it has to be already active on the local machine. Said differently, the interception could be a way to gather information to prepare a privilege elevation, but in any case for the attack to start, the local machine has to be already compromised

Google Chrome was written from the beginning as a browser and assumes that the client and the server could be on different systems. For that reason, it always throws warnings when it sees the raw HTTP protocol (in fact, any time there is no HTTPS certificate). But only you can say whether you actually trust your local network or your local machine.

What I mean here is that IMHO using https on a local machine adds little to no security: if the machine is compromised you should not trust anything because both the client and server side are compromised, and if it is not, no interception is possible...

Improve this answer
8
  • On the flip side, https:// on a local machine will never be using a certificate issued by a generally-recognized certificate authority.
    – supercat
    Dec 3, 2022 at 15:54
  • @supercat: I have long worked in an organization that used a private PKI. The IT support team installed the private root certificate into the browsers at part of any initial machine installation. Not being a generally-recognized CA was not a problem in that context...
    – Serge Ballesta
    Dec 3, 2022 at 16:40
  • It does appear that chrome just always throws the warning when it sees the raw HTTP protocol. Which in the case of privileged local ports, becomes a warning that your local machine could be compromised no matter what you do. Thank you for that advice, Google.
    – personal_cloud
    Dec 3, 2022 at 17:52
  • 2
    @SergeBallesta: The point is not what CA issued a certificate. The point is that no CA will issue a certificate to localhost, because there is no single host with such name. Issuing a certificate to localhost will not prevent from MITM, because an attacker could have in such case an own valid certificate for localhost.
    – mentallurg
    Dec 3, 2022 at 22:03
  • 2
    @mentallurg: It is possible for a real domain (i.e. not "localhost", but something like example.com) to resolve to addresses in 127.0.0.0/8 (or the IPv6 equivalent), and it is even possible to get a CA to issue a certificate for such a domain (using a DNS challenge, because the HTTP challenge would not work). The only thing a CA cares about is whether the entity providing the CSR is the same entity that controls the DNS entry. They do not check whether the A and AAAA records "make sense."
    – Kevin
    Dec 4, 2022 at 3:34
4

While for listening a port<=1024 usually root privileges are needed, sniffing the traffic on this port might still be possible. But sniffing traffic is all what is needed in order to extract sensitive information like passwords from unprotected (plain HTTP) traffic.

It is not uncommon that non-root users are given the permissions to run tcpdump or similar sniffers for example using sudo, because this is needed as part of their work.

Improve this answer
8
  • 2
    Sure, selective sudo is reasonable. But does that count as "non root"? I feel like Google is bending the meaning of "attackers" if it includes people that have upgraded sudo permissions.
    – personal_cloud
    Dec 3, 2022 at 6:45
  • @personal_cloud: Selective sudo is not root, but it is only providing limited access. It does not provide the ability to run a program which listens on port<=1024, so it is very different from the attack vector you had in mind. "I feel like Google is bending the meaning of "attackers" if it includes people that have upgraded sudo permissions." - Note that running selective code as root for less privileged users is pretty normal, for example by using suid programs like passwd. So where do you draw the line?
    – Steffen Ullrich
    Dec 3, 2022 at 7:17
  • 1
    @personal_cloud You’re not thinking ‘attackers’ in a proper security sense. The term does not define privileges, it defines intent. If someone is trying to effect an attack on the system, they are an attacker, regardless of whether they have root access, normal user access, or can only poke at things remotely from the network with no special privileges.
    – Austin Hemmelgarn
    Dec 3, 2022 at 15:50
  • 2
    @personal_cloud: "If an 'attacker' includes people with full privileges on an endpoint" - a user which has the privileges to run tcpdump on a multi-user system does not in any way have full privileges on the system. They still can sniff plain HTTP communication with localhost done by other users on the system, even with this reduced privileges.
    – Steffen Ullrich
    Dec 3, 2022 at 18:18
  • 1
    @personal_cloud Just because someone else has access to a system you are using does not automatically mean you trust them. You may not be in a position where you have an alternative to using that system. You may not have any way to know who all has access to the system. This isn’t a warning for developers on single-user systems that they have full control over, it’s a warning for people using shared systems that they have little to no control over (think students using school computers for example).
    – Austin Hemmelgarn
    Dec 3, 2022 at 20:39
3

There are tools for device Brother MFC L8900 CDW installed on your PC. They are listening to the port 999. Either you or somebody else with root privileges has installed them.

I suppose that these tools generated a self signed certificate. When you access web application that uses self signed certificate, browsers display a warning, which is normal. In case you access this computer from some other computer via network that you don't control, then really there can be a man-in-the-middle that intercepts your traffic, and if you don't check displayed fingerprints, you may accidentally accepts a certificate from the man-in-the-middle.

As long as you access this tool from the the same computer only, i.e. via localhost, I don't see any security risks.

Improve this answer
2
  • 4
    It doesn't look like a self-signed certificate to me; that looks like HTTP traffic.
    – wizzwizz4
    Dec 3, 2022 at 17:33
  • @wizzwizz4 Correct, the image I posted shows plain HTTP. Nonetheless, mentallurg's points still stand, and the software actually supports both HTTP and HTTPS. Chrome's warning is much louder if I connect using HTTPS.
    – personal_cloud
    Dec 3, 2022 at 17:40
-2

Chrome reports that an attacker can intercept privileged loopback ports. Given the vagueness of "attacker", the complexity of browser software, and the fact that Chrome is raising the issue, we should review Chrome's attack surfaces. For instance, you've logged out of your bank account, but debugging information remains in the browser console for subsequent users to see.

However, a clean system does not allow outside attacks on privileged loopback.

Improve this answer
3
  • So, all you're trying to say is that there isn't a risk, and that the automated message from the browser is being overzealous. But you just repeat the accepted answer. and with way more extraneous words ... (and a bit of a rant). Is this unique to Chome (and hence, Google)?
    – schroeder ♦
    Dec 20, 2022 at 15:58
  • 1
    The existence of a non-derogatory interpretation may get you off the hook for slander, legally. It doesn't get you off the hook for posting a misleading answer and the StackExchange consequences that come with that.
    – Ben Voigt
    Dec 20, 2022 at 15:59
  • @Ben I don't think anyone on this site is being misled. The answer is about what to put in product literature for people who might be misled by Google's warning. How do we set them back in the right general direction if they happen to believe the warning and we only have 3 sentences to explain?
    – personal_cloud
    Dec 20, 2022 at 16:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .