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?

schroeder
  • 125,553
  • 55
  • 289
  • 326
personal_cloud
  • 389
  • 1
  • 8

4 Answers4

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...

personal_cloud
  • 389
  • 1
  • 8
Serge Ballesta
  • 25,952
  • 4
  • 42
  • 84
  • On the flip side, https:// on a local machine will never be using a certificate issued by a generally-recognized certificate authority. – supercat Dec 03 '22 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 03 '22 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 03 '22 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 03 '22 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 04 '22 at 03:34
  • @Kevin: Also, the A or AAAA record can be edited after the certificate is issued. Not only is it not within the CA's power to prevent, it's desirable to be able to scale out without breaking existing certificates. – Ben Voigt Dec 04 '22 at 04:47
  • @Kevin and even a HTTP challenge might work - if the "official" DNS resolves example.com to a public IP and only your private DNS (or even /etc/hosts or equivalent) resolves it to the loopback address. – Hagen von Eitzen Dec 04 '22 at 09:09
  • @mentallurg has now [looked in the source code](https://security.stackexchange.com/a/267283/286296) and confirmed "it always throws warnings when it sees the raw HTTP protocol" and much more: it always throws the warning when there is no HTTPS certificate. – personal_cloud Dec 25 '22 at 19:59
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.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 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 03 '22 at 06: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 03 '22 at 07: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 03 '22 at 15:50
  • @Austin You have to draw the line between insider and outsider. If an 'attacker' includes people with full privileges on an endpoint, then what is the use of saying "your information could be stolen by attackers"? Sure, it's a problem, but it's not a technical problem: you've simply trusted the wrong people. – personal_cloud Dec 03 '22 at 17:29
  • @Steffen Exactly, the question is how to draw the line reasonably. There are lots of reasonable things you can do in system development that have security implications. But is that a good enough excuse for Google to be making potentially slanderous statements about other people's software? – personal_cloud Dec 03 '22 at 17:36
  • @personal_cloud: *"But is that a good enough excuse for Google to be making potentially slanderous statements about other people's software?"* - You draw the line where you see it currently and complain that Google is making statements you consider *"potentially slanderous"*. Google draws the lines somewhere else and warns you because it wants to protect you. Who is right? What does Google know how secure your system is? – Steffen Ullrich Dec 03 '22 at 18:14
  • 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 03 '22 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 03 '22 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.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • 4
    It doesn't look like a self-signed certificate to me; that looks like HTTP traffic. – wizzwizz4 Dec 03 '22 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 03 '22 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.

personal_cloud
  • 389
  • 1
  • 8
  • 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 '22 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 '22 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 '22 at 16:14