Security issues with DDWRT

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page 1, 2  Next
Author Message
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Sun Aug 14, 2016 16:47    Post subject: Security issues with DDWRT Reply with quote
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.

Sponsor
<Kong>
DD-WRT Guru


Joined: 15 Dec 2010
Posts: 4354
Location: Germany

PostPosted: Sun Aug 14, 2016 19:06    Post subject: Re: Security issues with DDWRT Reply with quote
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/
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Thu Aug 18, 2016 4:57    Post subject: Reply with quote
Challenge accepted.

The following is tested against your r30430M build. Just installed tonight.

The tool used is https://testssl.sh . You can use this to verify the output yourself.

Output can be seen here. http://pastebin.com/Lmk3BGTY

Let's go through what is wrong:

    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.
HalfBit
DD-WRT Guru


Joined: 04 Sep 2009
Posts: 736
Location: AR, USA

PostPosted: Sat Aug 20, 2016 3:23    Post subject: Reply with quote
qGUBcZWwBHb1 wrote:
Challenge accepted.

The following is tested against your r30430M build. Just installed tonight.

The tool used is https://testssl.sh . You can use this to verify the output yourself.

Output can be seen here. http://pastebin.com/Lmk3BGTY

Let's go through what is wrong:

    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? Smile

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-r40270M kongac (07/11/19)
~~~~~~~~~~~~~~Currently Unused~~~~~~~~~~~~~~
WRT54Gv2 - V24 STD Build 22118 configured as AP
WRT54Gv8.2 - V24 Micro Build 22118 configured as AP
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Sat Aug 20, 2016 3:40    Post subject: Reply with quote
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.
HalfBit
DD-WRT Guru


Joined: 04 Sep 2009
Posts: 736
Location: AR, USA

PostPosted: Sat Aug 20, 2016 3:52    Post subject: Reply with quote
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-r40270M kongac (07/11/19)
~~~~~~~~~~~~~~Currently Unused~~~~~~~~~~~~~~
WRT54Gv2 - V24 STD Build 22118 configured as AP
WRT54Gv8.2 - V24 Micro Build 22118 configured as AP
Avichi
DD-WRT User


Joined: 03 Nov 2013
Posts: 52

PostPosted: Sat Aug 20, 2016 6:00    Post subject: Gentleman:Smart people help other who are less handicapped.. Reply with quote
..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)

Thank in advance,

Avi
<Kong>
DD-WRT Guru


Joined: 15 Dec 2010
Posts: 4354
Location: Germany

PostPosted: Sat Aug 20, 2016 6:25    Post subject: Reply with quote
qGUBcZWwBHb1 wrote:
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/
Avichi
DD-WRT User


Joined: 03 Nov 2013
Posts: 52

PostPosted: Sat Aug 20, 2016 7:25    Post subject: Thank you Kong ! Reply with quote
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.
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Tue Aug 23, 2016 23:22    Post subject: Reply with quote
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.
ju2wheels
DD-WRT Novice


Joined: 12 Jul 2015
Posts: 10

PostPosted: Fri Sep 23, 2016 18:12    Post subject: Reply with quote
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,
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 2912
Location: UK, London, just across the river..

PostPosted: Fri Sep 23, 2016 19:30    Post subject: Re: Gentleman:Smart people help other who are less handicapp Reply with quote
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 Rolling Eyes ......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 Embarassed Embarassed

_________________
Atheros
TP-Link WR740Nv1 ------DD-WRT 33772 BS WAP/Switch (wired)
TP-Link WR1043NDv2 ----DD-WRT 41369 BS (AP,PPPoE,NAT,AD Blocking,AP Isolation,Firewall,Local DNS,Forced DNS,DoT)
TP-Link WR1043NDv2 ----DD-WRT 41321 BS (AP,NAT,AD Blocking,Firewall,Wi-Fi OFF,Local DNS,Forced DNS,DoT)
TP-Link WR1043NDv2 ----Gargoyle OS 1.11.0 (AP,NAT,QoS,Quotas)
Qualcomm/IPQ8065
2x Netgear R7800 -------DD-WRT 40270M 4.9 Kong (AP,NAT,AD-Blocking,AP&Net Isolation,VLAN's,Firewall,Local DNS,DNSCrypt-proxy v2 x2)
Broadcom
Netgear R7000 -------DD-WRT 40270M Kong (AP,NAT,VLAN,AD-Blocking,Firewall,Local DNS,Forced DNS,DoT)
------------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 via Entware by mac913
RMerlin
DD-WRT User


Joined: 05 Mar 2012
Posts: 273

PostPosted: Mon Sep 26, 2016 18:39    Post subject: Reply with quote
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.
barryware
DD-WRT Guru


Joined: 26 Jan 2008
Posts: 13049
Location: Behind The Reset Button

PostPosted: Tue Sep 27, 2016 21:21    Post subject: Reply with quote
Wash it down with gasoline (petrol), and dry it with a match.. Problem solved..

Smile

_________________
[Moderator Deleted] Shocked
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Tue Sep 27, 2016 22:51    Post subject: Reply with quote
ju2wheels wrote:
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.
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum