[BUG] Potential proxy exploit - deny rules to 127.0.0.1 are ignored

Bug (NIS Version: 20.3.1.22):


You cannot deny in / outbound traffic on 127.0.0.1, allowing local proxies such as Tor to become an attack vector

Details:

To illustrate the above point, set up Firefox to use a proxy (Tor) and then create a firewall rule:

First we'll create a generic "block everything" rule:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: Any
  • Protocol: All

Now run firefox and you will see connections made on 127.0.0.1 (some of them listening). Let's change the rule to be specific:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: 127.0.0.1
  • Protocol: All

Run Firefox again and you see the same connections and you can also freely access the web.

 

Now it might seem strange to set up a browser to use Tor and then create deny rules but this is merely for illustration. Any application, virus or worm could circumvent your deny rules if you have a proxy running, which is dangerous.

 

This also works with applications that have no rules. When NIS alerts you that a program is trying to access the internet and you choose "block once" or "block always", the connection is still allowed if the address is 127.0.0.1

 

Summary:


When the Firewall ignores specific "block" rules to 127.0.0.1 it opens the host computer to, at a minimum, two potential exploits:

  1. A proxy running on the host could be used as an inbound attack vector because the Firewall ignores specific
    block rules to 127.0.0.1
  2. A proxy running on the host could be used as an outbound exploit to send private information via a virus / worm
    because the Firewall ignores specific block rules to 127.0.0.1

SendOfJive wrote:

Hi MrSmite,

 

127.0.0.1 is an internal loopback address for communications that never leave your computer.  Loopback traffic on your PC never gets to an outside network, so it could not be used to launch an attack or send information out.  And the 127.0.0.1 address is not routable, so it could not be used as an attack vector from the outside.  A firewall is meant to block traffic from entering or leaving your computer, but traffic on the loopback never enters or leaves.  The Firefox traffic to 127.0.0.1 is entirely confined to your computer and has no connection with the internet at all - it is just FIrefox talking to itself.

 

https://support.mozilla.org/en-US/kb/how-stop-firefox-automatically-making-connections#w_loopback-connection

 

http://en.wikipedia.org/wiki/Localhost


I understand that 127.0.0.1 is a loopback address but I believe you misunderstood my OP. The traffic is NOT Firefox talking to itself. I will try to be as clear as possible but what I described is a security hole.

 

If I create a rule saying "Deny Firefox outbound traffic on 127.0.0.1" and then set Firefox to use the Tor proxy on 127.0.0.1:9050, I can start firefox and go to "www.google.com" and the page will load. This is not Firefox communicating with itself, it is Firefox communicating with the local proxy and is a security risk.

 

Another example in case you still don't understand:

 

I get an alert that "imstealingyourpassword.exe" is attempting to access the internet on 127.0.0.1. I choose "deny always". I then look using any number of IP monitoring tools and see "imstealingyourpassword.exe" happily exchanging data on 127.0.0.1:9050 (tor). It is a major security hole to allow a program to circumvent ANY specificly created rule.

 

Now before you repeat the "its not routable" argument, it doesn't matter. Proxies allow inbound connections and pass them on to the program connected to them on the 127.0.0.1 side. If a piece of malware is listening on 127.0.0.1 and sends notification home through a proxy, it is then open for connection from the outside.

 

Here's another illustration:

 

malware.exe -> "httpconnect" to "somemalwaresite.com" via 127.0.0.1:9050 -> tor -> your router -> your ISP -> "somemalwaresite.com" -> your ISP -> your router -> tor -> malware.exe

 

Using the reasoning "it's a loopback address" is a complete fallacy in the above example. Even with an explicit "deny" rule, malware.exe would be allowed to communicate with the proxy and ultimately out onto the web for any hacker or miscreant to take advantage of.


MrSmite wrote:

I understand that 127.0.0.1 is a loopback address but I believe you misunderstood my OP. The traffic is NOT Firefox talking to itself. I will try to be as clear as possible but what I described is a security hole.

 

If I create a rule saying "Deny Firefox outbound traffic on 127.0.0.1" and then set Firefox to use the Tor proxy on 127.0.0.1:9050, I can start firefox and go to "www.google.com" and the page will load. This is not Firefox communicating with itself, it is Firefox communicating with the local proxy and is a security risk.

 

It is FIrefox takling to itself.  You cannot reach www.google.com at 127.0.0.1 - that is not the IP address for Google, it is the IP address for your loopback network.  Firefox's traffic on 127.0.0.1 and to Google are completely unrelated to each other.  Also there is no such thing as "outbound traffic on 127.0.0.1". - 127.0.0.1 loops back to itself.  If you use a program like TPCView, you will see that 127.0.0.1 is a single endpoint - it is both the local address and the remote address.  You can't use it to connect to a second endpoint (like Google.com).

 

Another example in case you still don't understand:

I get an alert that "imstealingyourpassword.exe" is attempting to access the internet on 127.0.0.1. I choose "deny always". I then look using any number of IP monitoring tools and see "imstealingyourpassword.exe" happily exchanging data on 127.0.0.1:9050 (tor). It is a major security hole to allow a program to circumvent ANY specificly created rule.

Now before you repeat the "its not routable" argument, it doesn't matter. Proxies allow inbound connections and pass them on to the program connected to them on the 127.0.0.1 side. If a piece of malware is listening on 127.0.0.1 and sends notification home through a proxy, it is then open for connection from the outside.

 

"'imstealingyourpassword.exe' is attempting to access the internet on 127.0.0.1" cannot succeed for a couple of reasons.  FIrst, the connection would loopback rather than get to the internet, and second, even if it could get to the internet, internet routers will drop the packets by design - they will never reach a destination.

 

 


 

@SendOfJive

 

Once again it looks like you completely missed the fact that I'm talking about using a proxy.


If you run Tor (a proxy) which listens for connections on 127.0.0.1:9050, any application or malware that sends communication requests via the proxy will completely bypass Norton because NIS won't allow you to block 127.0.0.1

 

You should be able to block communication on 127.0.0.1 specifically to prevent malware from taking advantage from any proxy that is listening on 127.0.0.1

 

malware.exe -> sends a httpconnect request on 127.0.0.1:9050 through Tor, the request will be forwarded because NIS won't allow you to block 127.0.0.1. This completely negates all security provided by the firewall.

 

Please, take a minute and actually read what I'm posting. I'm not talking about some random application trying to connect to the web via loopback. I'm talking about malware communicating with a proxy that is listening on 127.0.0.1 because NIS does not allow you to block such applications.


SendOfJive wrote:

"'imstealingyourpassword.exe' is attempting to access the internet on 127.0.0.1" cannot succeed for a couple of reasons.  FIrst, the connection would loopback rather than get to the internet, and second, even if it could get to the internet, internet routers will drop the packets by design - they will never reach a destination.



Again, consider Tor (or other proxies). "imstealingyourpassword.exe" is attempting to access the internet on 127.0.0.1" can succeed if you have a proxy such as Tor listening for connections and passing them off to your router / the internet.

 

If you still have doubts:

 

1. download Tor and run it.

2. Create a rule to block Firefox on 127.0.0.1.

3. Run Firefox, set it to use a proxy 127.0.0.1:9050 (tools - options - network - connection)

4. Type in www.google.com.

5. Notice that Tor happily forwarded your request even though you blocked Firefox on 127.0.0.1

6. Now imagine that was "imstealingyourpassword.exe" instead of Firefox.

 

Please explain: If you can't block programs from using 127.0.0.1, how to you prevent malware from taking advantage of an open proxy that is listening on 127.0.0.1? This is a serious security hole for people running proxies.

OK, I am understanding your point a little better.  It may be a limitation of the Norton Firewall that the loopback cannot be blocked, because in general, this would not be a security issue (and inexperienced users attempting it would cause more harm than good).  In the case of Tor you may be correct that this would allow traffic to bypass firewall scrutiny.  This seems to be a situation common to many, though not all, firewalls.  I have tried to look into this a bt, but there doesn't seem to be a lot of discussion on the internet about this.  So I concede your point.

Bug (NIS Version: 20.3.1.22):


You cannot deny in / outbound traffic on 127.0.0.1, allowing local proxies such as Tor to become an attack vector

Details:

To illustrate the above point, set up Firefox to use a proxy (Tor) and then create a firewall rule:

First we'll create a generic "block everything" rule:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: Any
  • Protocol: All

Now run firefox and you will see connections made on 127.0.0.1 (some of them listening). Let's change the rule to be specific:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: 127.0.0.1
  • Protocol: All

Run Firefox again and you see the same connections and you can also freely access the web.

 

Now it might seem strange to set up a browser to use Tor and then create deny rules but this is merely for illustration. Any application, virus or worm could circumvent your deny rules if you have a proxy running, which is dangerous.

 

This also works with applications that have no rules. When NIS alerts you that a program is trying to access the internet and you choose "block once" or "block always", the connection is still allowed if the address is 127.0.0.1

 

Summary:


When the Firewall ignores specific "block" rules to 127.0.0.1 it opens the host computer to, at a minimum, two potential exploits:

  1. A proxy running on the host could be used as an inbound attack vector because the Firewall ignores specific
    block rules to 127.0.0.1
  2. A proxy running on the host could be used as an outbound exploit to send private information via a virus / worm
    because the Firewall ignores specific block rules to 127.0.0.1

I think Norton may justy be mis-identifying the loopback address as the source of the connection.

You can't really connect to or from the internet with the loopback address can you?

 

With your example with firefox and tor, those 2 programs are connecting through the loopback but tor is actually accessing the internet though another port is it not?

Firefox > To Tor on loopback

Tor > to internet on another port

(it's actually "another port" you want blocked)

 

For your scenario about malware "listening" on the loopback port, "something else" would be needed to accept the internet connection and transfer or forward it to the loopback connection would it not?

Malware Listening < Connection from loopback < Something needed here to connect internet with loopback  < Internet

 

Are you able to actually forward 127.0.0.1 to the internet directly to send or recieve something in either direction without a proxy or program in between the loopback and internet?

 

I know that some firewalls have a feature they call "application firewall" that can stop communication between 2 programs but thats really a misnomer because "Firewall" is generally the wall you build between your computer and others (or internet).

 

Sorry If I also misunderstood.

Dave

 


MrSmite wrote:

First we'll create a generic "block everything" rule:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: Any
  • Protocol: All

Now run firefox and you will see connections made on 127.0.0.1 (some of them listening). Let's change the rule to be specific:

 


 

 

I highlighed that part to show that your setting it to block "to and from other computers" and I think what your wanting it to do is "block to and from 2 programs on the same computer".

For all we know it might really be ready to block such communication but no communication actually is happening because Tor is using another port to access the internet.

 

If you want to completely internally block the loopback address all you would need to do is remove it's entry from the hosts file because that is what defines it in the first place.  (Although I have no idea how that will effect the normal operation of windows).

 

If you want to block only a specific program from using the loopback, I'm not sure how you would do that.

Maybe through the "program control" of the smart firewall.  (I don't have time now to try it).

 

Blocking "unknown malware" would be even harder because you can't make a specific program rule without knowing the name and location of the malware.

But in your second example about "malware listening on the loopback address", since Norton is an antivirus in a perfect would you shouldn't have any malware to be listening.

 

 

 

Sorry for the late reply, I recently moved and it took a while for them to get my internet up and running...


SendOfJive wrote:

OK, I am understanding your point a little better.  It may be a limitation of the Norton Firewall that the loopback cannot be blocked, because in general, this would not be a security issue (and inexperienced users attempting it would cause more harm than good).  In the case of Tor you may be correct that this would allow traffic to bypass firewall scrutiny.  This seems to be a situation common to many, though not all, firewalls.  I have tried to look into this a bt, but there doesn't seem to be a lot of discussion on the internet about this.  So I concede your point.


Thank you for this, I was afraid you might give up thinking I was yelling at you. I'm glad I was finally able to explain myself better. Just for a bit of information, I believe NIS 2010 was able to block communication on 127.0.0.1 and if I remember correctly, Commodo Free does as well.

 

I'm still looking for more information myself. Hopefully Symantec will patch in the ability to block 127.0.0.1 and just warn inexperienced users when they try to.


DaveH wrote:

MrSmite wrote:

First we'll create a generic "block everything" rule:

 

  • Rule: Block
  • Direction: To and From other computers
  • Computer: Any
  • Protocol: All

Now run firefox and you will see connections made on 127.0.0.1 (some of them listening). Let's change the rule to be specific:

 


 

 

I highlighed that part to show that your setting it to block "to and from other computers" and I think what your wanting it to do is "block to and from 2 programs on the same computer".

For all we know it might really be ready to block such communication but no communication actually is happening because Tor is using another port to access the internet.

 

If you want to completely internally block the loopback address all you would need to do is remove it's entry from the hosts file because that is what defines it in the first place.  (Although I have no idea how that will effect the normal operation of windows).


In regards to what you hilighted, that's just what NIS uses on the rule creation wizard so I had no other choice to put that. Using the Hosts file would break legitimate communications so that's not an option.

 


DaveH wrote:

If you want to block only a specific program from using the loopback, I'm not sure how you would do that.

Maybe through the "program control" of the smart firewall.  (I don't have time now to try it).


 That's what I did which started this whole conversation.

 


DaveH wrote:

Blocking "unknown malware" would be even harder because you can't make a specific program rule without knowing the name and location of the malware.

But in your second example about "malware listening on the loopback address", since Norton is an antivirus in a perfect would you shouldn't have any malware to be listening.


Obtaining the name / location of malware is easy since I run NIS with automatic rule creation off so it alerts me any time a program tries to access the internet. As for "shouldn't have any malware listening", this is unfortunately not always the case. No A / V product is 100%.

 

 

The point I was trying to make with this conversation is that there is a major security flaw by not allowing a user to block communication on the loopback address in the event that the system has a proxy such as Tor running.

 

If "malware.exe" attempts to contact "downloadviruspayload.com" via Tor (or other proxy) on 127.0.0.1:9050, there is no mechanism in NIS to prevent this from happening because NIS incorrectly thinks all communication on 127.0.0.1 is safe.