Slipstream attack and OpenWrt?

Are slipstream attacks possible through an OpenWRT router with the default configuration?

It seems the NAT slipstream attack was announced the day before yesterday. In short, it is described as an attack on web browsers behind Application-level Gateway (ALG) capable routers. I do not fully understand whether that applies to OpenWRT or not.

What I did learn and understand is that according to Wikipedia, ALG is in netfilter on Linux. Unfortunately I could not detuct the answer to my question from reading OpenWRT's netfilter documentation. Skimming through upstream's netfilter docs gave me the impression protocol specific parts of conntracking should likely end up as separate kernel modules when enabled. Thus my belief is that an attack it is unlikely to succeed unless such modules are loaded.

Would it be safe to assume no slipstream mitigation needs to be taken on OpenWRT when find /lib/modules -name "*nf_conntrack_*" only returns ipv4, ipv6 and rtcache; i.e. nothing like e.g. ftp, h323 or sip?

there are available packages for netfilter ftp and sip
example
https://downloads.openwrt.org/releases/19.07.4/targets/ath79/generic/kmods/4.14.195-1-b84a5a29b1d5ae1dc33ccf9ba292ca1d/kmod-nf-ipvs-ftp_4.14.195-1_mips_24kc.ipk
https://downloads.openwrt.org/releases/19.07.4/targets/ath79/generic/kmods/4.14.195-1-b84a5a29b1d5ae1dc33ccf9ba292ca1d/kmod-nf-ipvs-sip_4.14.195-1_mips_24kc.ipk

So anyone activating these protocols is vulnerable

With the package kmod-nf-nathelper-extra which I use for proto_gre (and also unfortunately loads sip helper modules) the router is vulnerable as tested on this site: http://samy.pl/slipstream/server

So at the moment, the best course of action is to NOT use any NAT helper modules.

2 Likes

To be clear, to test:

  • Browse to the website on a LAN client
  • Open any client firewall
  • Disable any browser extension that may hinder WebRTC
  • And run echo something here | (nc -vl localhost 3306 || nc -vvlp localhost 3306) on the LAN client?

correct?

I'm also wondering how it's "detecting local subnets". Those listed don't exist in my network and the results are not consistent on each visit. I did a quick read of his site, I think it just uses a list of common router IPs perhaps?

1 Like

Correct

Yes.

If WebRTC doesn't work, it should fallback to a timing based attack. WebRTC makes it easier, but is not required.

Correct. Then once it did it's initial scan, you have to click the button to try to exploit the router.

Yes, that's the timing attack. It tries random often used router IPs. Based on the timing of the replies it can gather information whether or not there was actually a device on that IP.

2 Likes

:+1:

The last step...I just assumed all would see that and didn't think to type it (bad when writing steps :laughing:) . OK, cool and thanks for noting it for everyone.

Thank you all for both replying to my question and elaborating on the topic.

1 Like

So how do I interpret the result of the test???
If I run the test and it first say I am a "odd fellow" and everyting gives unusable candidate and then I push the test button and it tries its magic over and over many times and then stops without never get a singel internal IP adress other than my routers Internet IP adress.
I guess that is a good ting, or what?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.