Posted: Wed Dec 18, 2019 18:04 Post subject: CVE-2019-14899: Suggested VPN Vulnerability Mitigation
Just an FYI
CVE-2019-14899 is a vulnerability that can be exploited by an attacker to determine if a user is connected to a VPN and modify unencrypted traffic in a VPN tunnel.
An attacker who shares the same network segment as the targeted user can determine if they are using a VPN, obtain the virtual IP address, determine if the target is currently visiting a specified website, and even inject data into an unencrypted TCP stream.
Setting rp_filter to STRICT or using the following firewall command should act as a fix for this:
and this
iptables -t raw \! -i <vpn interface> -d <local IP / netmask of interface> -j DROP
should look like
iptables -t raw \! -i TUN1 -d 192.168.1.1/255.255.255.0 -j DROP
please confirm is this the correct syntax...??
Yes, I can confirm that you are indeed correct.
I personally placed
Code:
echo 1 > /proc/sys/net/ipv4/conf/tun1/rp_filter
AND
Code:
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
in DD-WRT’s Startup Command multi-line textbox. Modifying the ‘all’ key ensures that there is not a higher value in any configuration key effecting the interface.
Of course, you can always test effectiveness of the mitigation on the interface in question by issuing
Code:
nmap -T4 -A -v -Pn <target ip>
from a client device on the same network. Thank you for expanding on that.
Joined: 16 Nov 2015 Posts: 6437 Location: UK, London, just across the river..
Posted: Thu Dec 19, 2019 10:11 Post subject:
can confirm first line works along with my set up....
can confirm the second line
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
in a bit of an IDLE time it breaks my VPN/DNS and so on...
or i may be wrong...will try it later again to be sure... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
can confirm first line works along with my set up....
can confirm the second line
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
in a bit of an IDLE time it breaks my VPN/DNS and so on...
or i may be wrong...will try it later again to be sure...
That is quite interesting that it breaks the VPN after a while. If you’re certain that the rp_filter variable is not defaulted to a higher value anywhere else in DD-WRT, you can leave out modifying the all key.
If you exclude modifying the all key, you can just run a quick cat command after you reboot your router to ensure that tun1 rp_filter variable is set to STRICT/1 per your settings:
Code:
cat /proc/sys/net/ipv4/conf/tun1/rp_filter
A value of STRICT/1 for tun1 for will confirm that the all key modification is not needed. Thank you!
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Thu Dec 19, 2019 19:10 Post subject:
Hmm... rc.firewall is not the command input box. Just like rc.custom and rc.startup are not the command input box. If that causes issue in the shell scripts, there is a larger problem. Only time you need escape characters are for running commands from the input box, I thought... but I could be wrong.
Joined: 16 Nov 2015 Posts: 6437 Location: UK, London, just across the river..
Posted: Thu Dec 19, 2019 20:12 Post subject:
cat /proc/sys/net/ipv4/conf/tun1/rp_filter
returns 0
cat > /proc/sys/net/ipv4/conf/all/rp_filter
returns 1
im running tun1 in start up script
and all via CLI been there for a few hours nothing bad yet will see...tomm _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
im running tun1 in start up script
and all via CLI been there for a few hours nothing bad yet will see...tomm
I believe tun1rp_filter key should be 1 on boot if you added.
Code:
echo 1 > /proc/sts/net/ipv4/conf/tun1/rp_filter
to your startup command. Having only all rp_filter as 1 will not protect the openvpn connection so you may want to try changing tun1rpfilter variable to 1 again.
Also consider that if you disconnect and reconnect your openvpn connection during normal operation, the rp_filter will reset to build defaults.
It looks like BrainSlayer has made some changes for this using iptables on SVN btw so we may get to test it soon:
Of course, you can always test effectiveness of the mitigation on the interface in question by issuing
Code:
nmap -T4 -A -v -Pn <target ip>
from a client device on the same network. Thank you for expanding on that.
So your <target ip> is a local device on the same vpn network as the pc/laptop running the command? After executing the command what am I looking for to tell me it's doing it's job?
TIA!! _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
Of course, you can always test effectiveness of the mitigation on the interface in question by issuing
Code:
nmap -T4 -A -v -Pn <target ip>
from a client device on the same network. Thank you for expanding on that.
So your <target ip> is a local device on the same vpn network as the pc/laptop running the command? After executing the command what am I looking for to tell me it's doing it's job?
TIA!!
<target ip> would be the openvpn local IP in this application.
If you were to apply rp_filter protection to another interface such as a vlan or vap, then you’d also be able to test the integrity of the fix if you're uncomfortable with testing your tun1 on an active deployment.
A successful implementation test would result in nmap complaining about dropped scans and slowing to a crawl.
Joined: 16 Nov 2015 Posts: 6437 Location: UK, London, just across the river..
Posted: Fri Dec 20, 2019 5:51 Post subject:
well it seem BS will implement
iptables -t raw \! -i TUN1 line instead of
echo . /proc/sys/net/ipv4/conf/tun1/rp_filter
here is nmap output running those 2 in statrt up script
echo 1 > /proc/sys/net/ipv4/conf/tun1/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
root@R7000:~# nmap -T4 -A -v -Pn 10.10.10.9
Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-20 08:57 EET
Initiating Parallel DNS resolution of 1 host. at 08:57
Completed Parallel DNS resolution of 1 host. at 08:57, 0.00s elapsed
Initiating SYN Stealth Scan at 08:57
Scanning 10.10.10.9 [1000 ports]
Discovered open port 443/tcp on 10.10.10.9
Discovered open port 53/tcp on 10.10.10.9
Completed SYN Stealth Scan at 08:57, 1.76s elapsed (1000 total ports)
Initiating Service scan at 08:57
Scanning 2 services on 10.10.10.9
Completed Service scan at 08:57, 5.00s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against 10.10.10.9
Retrying OS detection (try #2) against 10.10.10.9
Retrying OS detection (try #3) against 10.10.10.9
Retrying OS detection (try #4) against 10.10.10.9
Retrying OS detection (try #5) against 10.10.10.9
Nmap scan report for 10.10.10.9
Host is up (0.00018s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
53/tcp open tcpwrapped
443/tcp open ssl
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=6.70%E=3%D=12/23%OT=443%CT=1%CU=30310%PV=I%DS=0%DC=L%G=Y%TM=7DAC2
OS:0E5%P=arm-openwrt-linux-gnu)SEQ(SP=FF%GCD=1%ISR=115%TI=Z%II=I%TS=6)SEQ(S
OS:P=FF%GCD=2%ISR=115%TI=Z%TS=7)ECN(R=Y%DF=Y%T=40%W=ABAA%O=MFFC7FNSSW1%CV=Y
OS:%Q=)T2(R=Y%DF=Y%B=4$%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=N)T
OS:6(R=N)T7(R=N)U1(R=Y%DF=N%T=41%IPL=184%UN=0%RIPL=G%RID=G%RIPCK=F%RUCK=G%R
OS:UD=G)IE(R=Y%DFI=N%T=44%CD=S)
Uptime guess: 0.853 days (since Thu Dec 19 12:29:39 2019)
Network Distance: 0 hops
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: All zeros
Read data files from: /opt/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 27.21 seconds
Raw packets sent: 1315 (68.274KB) | Rcvd: 2483 (119.516KB) _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Last edited by Alozaros on Tue Dec 24, 2019 11:46; edited 1 time in total
well it seem BS will implement
iptables -t raw \! -i TUN1 line instead of
cat /proc/sys/net/ipv4/conf/tun1/rp_filter
Yes. This is because, when you simulate step 1 of the vulnerability attack, the rp_filter command basically halts the nefarious packets. This has the unfortunate effect of halting all other legitimate packets behind it as it takes its Time dropping the nefarious packets.
On ARM systems, this is computationally expensive and doesn’t speed up until the attack stops.
It is better to go with second one so users under attack don’t panic when their router slows down.