Interesting idea by Samy (yes, that Samy):
Here is a proof of concept in what I'm calling NAT Pinning ("hacking gibsons" was already taken). The idea is an attacker lures a victim to a web page. The web page forces the user's router or firewall, unbeknownst to them, to port forward any port number back to the user's machine. If the user had FTP/ssh/etc open but it was blocked from the router, it can now be forwarded for anyone to access (read: attack) from the outside world. No XSS or CSRF required.
In short, he exploits a smart mechanism in modern network equipment, which graciously and "magically" NATs on the fly arbitrary ports when certain handshake patterns are detected in outbound traffic, allowing (usually older) protocols which require a "call back" connection (like FTP, IRC or SIP) to work properly.
Good news is that ABE can prevent exploitation without hampering the useful functionality. If you're concerned about this issue, you just need to open NoScript Options|Advanced|ABE and edit the "USER" ruleset, adding the following rule:
# NAT Pinning blockage (blocks outbound HTTP traffic to unlikely ports) Site ^https?://[^/]+:[0-35-7] Deny
Bad news is that Java, Flash, Silverlight and maybe other plugins can open raw sockets bypassing any browser control, including ABE. Just another reason to keep them at bay.
Thanks to Thoughtcrime for bringing this to my attention, and to Samy for the chat we had this afternoon.
January 8th, 2010 at 1:58 am
[...] hackademix.net » NAT Pinning and ABE hackademix.net/2010/01/08/nat-pinning-and-abe – view page – cached Here is a proof of concept in what I’m calling NAT Pinning (”hacking gibsons” was already taken). The idea is an attacker lures a victim to a web page. The web page forces the user’s router or firewall, unbeknownst to them, to port forward any port number back to the user’s machine. If the user had FTP/ssh/etc open but it was blocked from the router, it can now be forwarded for anyone... Read moreHere is a proof of concept in what I’m calling NAT Pinning (”hacking gibsons” was already taken). The idea is an attacker lures a victim to a web page. The web page forces the user’s router or firewall, unbeknownst to them, to port forward any port number back to the user’s machine. If the user had FTP/ssh/etc open but it was blocked from the router, it can now be forwarded for anyone to access (read: attack) from the outside world. No XSS or CSRF required. View page [...]
January 8th, 2010 at 3:16 am
Nice, fast response :D
After some digging this seems to be an old threat from the 2.4 days of Linux netfilter:
See PROGENY-SA-2001-15 for ftp and CAN-2002-0060 for the irc conntrack hack using dcc
I haven't confirmed this but most Linux based routers should be patched by now.
January 8th, 2010 at 3:57 pm
@ac:
No, this one has never been fixed because it's not a bug.
This issue is related to the fixed bug you found (it affects the same functionality), but in this case the functionality is working as expected, allowing the remote IP to connect with the originating IP at the requested port.
So Linux-based routers are still affected, and they are unlikely to be patched any time soon against a non-bug...
January 8th, 2010 at 4:19 pm
Wow!
Brisk work.
So now most of all, thoughty, Samy *and* Giorgio are my heroes.
January 8th, 2010 at 4:39 pm
I tried the vulnerable yesterday, and it seems like ABE blocked it successfully. When I clicked on the link, then ABE came with a "Warning" and my router hasn't forwarded any ports :)
But i'm still writting "Site ^https?://[^/]+:[0-35-7] (newline) Deny" in my USER.abe file
January 8th, 2010 at 8:32 pm
@#3 Giorgio
Many thanks for clearing up my misconception!
I suppose the only patch (besides using NoScipt of course) is to disable ip_conntrack_ftp.o and ip_conntrack_irc.o on 2.4.* or nf_nat_ftp.ko and nf_nat_irc.ko on 2.6.*
Will have to look how much functionality this breaks.
Another thing: I'm curious if this can be used to open a port to another system on network than the one that's used to send the command eg by guessing the internal IP?
January 8th, 2010 at 10:18 pm
@ac:
Apparently yes. And before the two bugs you named were fixed, you didn't even need to guess the IP...
January 12th, 2010 at 12:10 pm
[...] NAT Pinning and ABE – hackademix.net Some feedback on NAT pinning and prevention of attacks using this. [...]
January 14th, 2010 at 6:09 pm
Shouldn't the regular expression be
^https?://[^/]+:([1-35-79]|8(?!0)|8(?=0\d)|4(?!43)|4(?=\d{3}))
in order to prevent connections to ports different from 80 and 443? The expression used in the post still allows port 45, 81, 9, etc.
Warning: I assume no one will start the port number with 0, seems rather unlikely a link using that will be up to something good.
January 15th, 2010 at 12:26 am
@Christophe:
Technically yes, but
January 23rd, 2010 at 11:45 pm
I have a question again, Giorgio, even though it may have been asked already.
What's the benefits of employing 255.255.255.0 as your redirect address/local domain within your hosts file, instead of using 0.0.0.0?
Wouldn't those two addresses offer the same benefits overall? Or will using the subnet mask 255.255.255.0 do something else I'm not aware of?
Just curious what you have to say about it.
P.S. I referenced your knowledge on the Wikipedia article for Hosts file.
January 24th, 2010 at 3:58 pm
@Sorrow:
Both are invalid endpoints, so they're both OK as long as the OS immediately rejectS them for connection building, improving responsiveness.