Posted: Sun Aug 14, 2016 19:06 Post subject: Re: Security issues with DDWRT
qGUBcZWwBHb1 wrote:
I've mentioned this several times in the past but I'm now posting a scan using Nexpose to show the vulnerabilities identified.
Until these are addressed, do not assume that DDWRT is secure.
It's really too bad since these are mostly easily implemented configuration changes. Let the devs know if this matters to you.
The scan is complete nonsense, no detail given and since this image shows no description to the end user it is not useful, or better misleading.
Unless you provide proper details and an exact description how dd-wrt can be exploited or puts the user at risk, I consider this to be a april fools joke.
Example why the scan result is complete nonsense.
SSL Server support no strong ciphers. DD-WRT offers aes ciphers which are widely considered strong ciphers, weak ciphers e.g. are disabled by default in latest builds.
This tool is just unsound and the way you use it is to discredit dd-wrt is really poor. I'm sure this tool would display dozens of "vulnerabilities" for a default, linux,windows ... install. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
1. TLSv1.0 and TLSv1.1 are offered. This isn't ideal. TLSv1.2 is the only one considered secure. See last paragraph https://www.imperialviolet.org/2014/12/08/poodleagain.html
2. 3DES ciphers offered. Not recommended
3. Self-signed cert still uses deprecated SHA1
4. Secure Client-Initiated Renegotiation - Vulnerable
5. CRIME, TLS (CVE-2012-4929) - Vulnerable
6. Missing HTTP security headers. See securityheaders.io
7. Things like HSTS, X-Content-Type-Options, Content-Security-Policy, X-Frame-Options, X-XSS-Protection at a minimum
8. BEAST (CVE-2011-3389) - Vulnerable. Bad ciphers: DES-CBC3-SHA AES128-SHA AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
9. Only forward secret ciphers should be used
10. The DNS amplification attacks are real but have limited mitigation due to how dnsmasq is used. At a minimum, the following flags should be included: --local-service -z
Do not blindly assume that simply enabling AES means you are secure. That is completely untrue.
Ball is in your court. I'm happy to help if you are willing to listen.
1. TLSv1.0 and TLSv1.1 are offered. This isn't ideal. TLSv1.2 is the only one considered secure. See last paragraph https://www.imperialviolet.org/2014/12/08/poodleagain.html
2. 3DES ciphers offered. Not recommended
3. Self-signed cert still uses deprecated SHA1
4. Secure Client-Initiated Renegotiation - Vulnerable
5. CRIME, TLS (CVE-2012-4929) - Vulnerable
6. Missing HTTP security headers. See securityheaders.io
7. Things like HSTS, X-Content-Type-Options, Content-Security-Policy, X-Frame-Options, X-XSS-Protection at a minimum
8. BEAST (CVE-2011-3389) - Vulnerable. Bad ciphers: DES-CBC3-SHA AES128-SHA AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
9. Only forward secret ciphers should be used
10. The DNS amplification attacks are real but have limited mitigation due to how dnsmasq is used. At a minimum, the following flags should be included: --local-service -z
Do not blindly assume that simply enabling AES means you are secure. That is completely untrue.
Ball is in your court. I'm happy to help if you are willing to listen.
So, disable TLS 1.0 and 1.1 on your browser and you'll eliminate half of that, and you can make your connection as secure as you want. You can also go obtain a SHA2 cert, signed by a trusted CA and then install it yourself. Do you not trust your own router?
I understand where you're coming from, qGUBcZWwBHb1, but at the same time, nothing you've pointed out is alarming to me and I work in infosec for a living. I would just advised you to be careful with the tone of your message and intent. Be civil, and remember you get what you paid for. If you don't like it, go back to stock FW.
By the way, have you tested the stock FW? Which hardware do you have? I know that doesn't matter for the DD-WRT side as the binaries across different hardware are pretty much the same for ciphers and encryption suites, but it would be interesting to know which vendor you're on and what the results are on their FW. _________________ R7000 Nighthawk - DD-WRT v3.0-r50308
R7000 Nighthawk - DD-WRT v3.0-r50308
~~~~~~~~~~Dismantled for learning opportunities~~~~~~~~~~
WRT54Gv2
WRT54Gv8.2
~~~~~~~~~~Other Settings~~~~~~~~~
https://nextdns.io/?from=2d3sq39x https://pi-hole.net/ https://github.com/DNSCrypt/dnscrypt-proxy
You aren't the only one that does infosec =) If I were to take your comments at face value, not dealing with EXTRABACON etc. because they are "corner cases" would be the norm (don't you trust your ASA?). Yeah, no.
I, for one want to improve the tools that I use and not accept the status quo. Trust but verify and all that good stuff.
Read my comment again, I'm offering to help get these fixed whereas your comment about just going back to stock firmware is frankly not very useful.
PS. there's a reason why server side cipher selection is preferred.
PPS. R7000.
Glad you took my facetious comments, and band-aid solutions/suggestions well. Have you tested stock FW at all? _________________ R7000 Nighthawk - DD-WRT v3.0-r50308
R7000 Nighthawk - DD-WRT v3.0-r50308
~~~~~~~~~~Dismantled for learning opportunities~~~~~~~~~~
WRT54Gv2
WRT54Gv8.2
~~~~~~~~~~Other Settings~~~~~~~~~
https://nextdns.io/?from=2d3sq39x https://pi-hole.net/ https://github.com/DNSCrypt/dnscrypt-proxy
Posted: Sat Aug 20, 2016 6:00 Post subject: Gentleman:Smart people help other who are less handicapped..
..I am one of them , I posted a comment yesterday http://www.dd-wrt.com/phpBB2/viewtopic.php?t=303763 about the [DoS attack: ACK Scan] and [DoS attack: FIN Scan] etc on my new Netgear R6900, so I went and posted it and replaced it with R7000, guess what we have the same problem, I have the similar attack on R7000, now I know DD-WRT I was able to run some scripts and protect my firewall. The firmware does not allow that, I am not aware of any way this is can be done, after google search , I found out that Netgear has this problem and people have complained about the Factory default firmware. I am not sure it is specific to Netgear R7000 or many other brand names.
R7000 logs
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.216.36], Friday, Aug 19,2016 12:54:42
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.217.196], Friday, Aug 19,2016 08:40:28
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.219.46], Thursday, Aug 18,2016 20:19:18
I am sure you two gentleman and Kong and BS could shed some light to the million sof DD-WRT users who adore the work they do for the community, I understand they may not be "Perfect", why cannot all three of you join forces to the help the less fortunate and handicapped (Intellectually)
You aren't the only one that does infosec =) If I were to take your comments at face value, not dealing with EXTRABACON etc. because they are "corner cases" would be the norm (don't you trust your ASA?). Yeah, no.
I, for one want to improve the tools that I use and not accept the status quo. Trust but verify and all that good stuff.
Exactly we are talking about extra hardening, not known security issues.
Quote:
Read my comment again, I'm offering to help get these fixed whereas your comment about just going back to stock firmware is frankly not very useful.
Help does not mean demanding extra features for free in a given time frame. It is also preferred to report security issues upstream, e.g. openssl if there are any known weaknesses in an app.
If we know of any real issues we fix them, if we find time for extra hardening, we will do it.
If you think your issue is not solved fast enough you have a few options:
-fix it yourself and send a patch
-pay BrainSlayer to implement it
-report it upstream, e.g. tell openssl/dnsmasq devs, that they should fix their soft.
P.S. Unlike OEM fw or other projects we usually use up to date opensource software. Others still use unsupported software at their base e.g. 2.6 kernels.
Updates come make it into builds within days, e.g. openssl fixes etc. Thus don't really get your point, why don't you demand the same from your router manufacturer, you are paying him after all? _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Posted: Sat Aug 20, 2016 7:25 Post subject: Thank you Kong !
Kong, Thanks for the reply, this is exactly what I mentioned when I said the issue could be stemming from the "Older versions" of kernel, and additional features. upstream developers.
I wish I could send my little contribution to BS , as I think your contributions to community is very critical for "less intellectually capable" like me. Please let me know how I send my modest contribution, I feel I owe you for the software BS developed for E3000 for past 6 years and I started using your version about 2 months back.
Einstein said it best Ego=1/Knowledge i.e "More the Knowledge Lesser the Ego,Lesser the Knowledge More the Ego"
I think DD-WRT community has well intended people who want to help, i think there many newbie (including me) who need to reduce the left side of the equation.
Kong, as mentioned, most of the issues are config related issues and not source related so there's really nothing for upstream to fix other than shipping better factory defaults.
IIRC, I did open issues in the bug tracker a while ago. I'll see if I can find them again and post them here.
BTW, I did rerun with Nexpose again and found the following. Interestingly, curl returns a "(52) Empty reply from server"
MOD EDIT: Image too big for this forum. It makes posts impossible to read on many monitors. I felt the unreadable comments were more important than this image. Please repost accordance with the forum rules, or cut and paste the results in a post.
Hi, post jacking a bit as I had a similar question I was just looking into. Can we set the TLS version/ciphers we want for the HTTPS management portal in a persistent config file somewhere or is that baked into the build?
Based on Kongs comment above it almost sounds like its baked into the build but want to double check.
Joined: 16 Nov 2015 Posts: 6437 Location: UK, London, just across the river..
Posted: Fri Sep 23, 2016 19:30 Post subject: Re: Gentleman:Smart people help other who are less handicapp
Avichi wrote:
..I am one of them , I posted a comment yesterday about the [DoS attack: ACK Scan] and [DoS attack: FIN Scan] etc on my new Netgear R6900, so I went and posted it and replaced it with R7000, guess what we have the same problem, I have the similar attack on R7000, now I know DD-WRT I was able to run some scripts and protect my firewall. The firmware does not allow that, I am not aware of any way this is can be done, after google search , I found out that Netgear has this problem and people have complained about the Factory default firmware. I am not sure it is specific to Netgear R7000 or many other brand names.
R7000 logs
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.216.36], Friday, Aug 19,2016 12:54:42
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.217.196], Friday, Aug 19,2016 08:40:28
[DoS attack: ACK Scan] attack packets in last 20 sec from ip [216.58.219.46], Thursday, Aug 18,2016 20:19:18
Could you please let us know and share the knowledge how to protect ourselves too, the rest of the DD-WRT community,
with poor knowledge...there must be a lot of regular users that are not fully aware what to do to protect themselves.
Could you share the script ......with the community and improve the security of many others...
I also run some firewall commands for DDoS attacks but as you stated that you know something valuable,
you go first, and i will share my knowledge too tell us about those scripts _________________ 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
Using a security tool is one thing. Knowing how to use it is another. You have to tailor the tests for the specific target. For example in this case, the tool reports that the router is able to do recursive DNS lookups. Well this is perfectly normal, since the router IS intended to provide resolution services to the LAN. This is a test that should only be run against a public facing, typically authoritative nameserver (which serves specific zones).
From time to time I also have to deal with people sending me a long list of "OMG security holes!" reports spit out by some tool that they ran against my firmware. A first scan at the list typically dismisses 1/3 of the reported "issues" as being "perfectly normal", or "not a problem within a LAN context".
Testing a router requires different tests from testing a public-facing server. And the tests also change based on whether you test from the WAN side, or from the LAN side. Having open SMB ports is perfectly normal on the LAN side. On the WAN side - not so much.
And I concur that the same tests should be run against the stock firmware first, to establish a baseline. Because if DD-WRT comes up with fewer security issues, then it means it's still a better solution than sticking with the OEM firmware. Quite a few of OEM firmwares contain stuff that should keep you awake at night, between the voluntary backdoors and the 10 years old OpenSSL versions they contain.
Hi, post jacking a bit as I had a similar question I was just looking into. Can we set the TLS version/ciphers we want for the HTTPS management portal in a persistent config file somewhere or is that baked into the build?
Based on Kongs comment above it almost sounds like its baked into the build but want to double check.
Thanks,
You have to bake it into the build so you'll have to compile it yourself or convince one of the devs to incorporate it.
I'm for TLSv1.2 and above but unfortunately there are people here that think "more secure than stock firmware" is good enough. Security is a sliding scale but I'd prefer mine not to be compromised through questionable configuration choices.
......with the community and improve the security of many others...
