Security issues with DDWRT

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2
Author Message
<Kong>
DD-WRT Guru


Joined: 15 Dec 2010
Posts: 4339
Location: Germany

PostPosted: Wed Sep 28, 2016 5:32    Post subject: Reply with quote
qGUBcZWwBHb1 wrote:
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.


It would be possible to make a selection for it, but the webif is already a bit lame. Lots of help section in the webif are outdated etc. it lacks a beginner/advanced mode etc. and some sections should be reorganized.

_________________
KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Sponsor
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Tue Feb 07, 2017 3:51    Post subject: Reply with quote
One could make a case for good "factory" defaults.

The issues brought up here still apply: http://svn.dd-wrt.com/ticket/5373

I've even provided a patch so most of the legwork is done. Once again, I ask that you consider applying this.

For the HTTP headers, I recommend reading Scott Helme's excellent series of blog posts as to why.

Next, I've also looked at dropbear and wish to make some suggested changes. The ticket is here. http://svn.dd-wrt.com/ticket/5714 wherein the changes are in the associated diff.

These are relatively small simple config changes but make a world of difference.
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Thu Jul 20, 2017 8:18    Post subject: Reply with quote
this is all nonsense. remote administration is disabled by default and i never would advise someone to enable it and to expose the webgui to the internet and even then you cannot break it. because why? you still need a username and password. the ssl attacks are hased on decrypting traffic. but of someone reads the content of the webgui he still has no sensitive information to break in. the passwords are still extra encrypted. why do i keep alot of algorithms enabled? easy, some people are still like to use old browsers
_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Thu Jul 20, 2017 15:45    Post subject: Reply with quote
i also checked testssl.sh and these weak ciphers arent included since a long time, except you're using a old 4 mb flash device which uses matrixssl. but there is no fix for it, its simply not enough space for a strong ssl library
_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Sat Jul 22, 2017 3:14    Post subject: Reply with quote
BrainSlayer wrote:
this is all nonsense. remote administration is disabled by default and i never would advise someone to enable it and to expose the webgui to the internet and even then you cannot break it. because why? you still need a username and password. the ssl attacks are hased on decrypting traffic. but of someone reads the content of the webgui he still has no sensitive information to break in. the passwords are still extra encrypted. why do i keep alot of algorithms enabled? easy, some people are still like to use old browsers


pls actually look at the proposed patches, they do not require a new lib. if people still use old browsers, they need to upgrade. it's 2017 ferchristsake

given that the interface uses http basic auth and not proper http sessions, guess what? http basic auth has no mechanism to log out. plus it's plaintext over ssl, not

see http://www.skorks.com/2009/08/is-basic-authentication-really-insecure/
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Sun Jul 23, 2017 18:02    Post subject: Reply with quote
also, rather than poo-pooing the suggested changes as nonsense, tell me how what has been proposed makes things appreciably worse?

i've done all the legwork in cleaning up both httpd.c and dropbear configs. all you have to do is to apply the patches.
qGUBcZWwBHb1
DD-WRT Novice


Joined: 27 Jan 2015
Posts: 32

PostPosted: Tue Aug 20, 2019 20:52    Post subject: Reply with quote
Bumping this.

It looks like ddwrt how has TLSv1.3 (at least in the Kong version that I checked). So that's great!

But the overall list of ciphers offered is still less than ideal. Given that the browser vendors are *only* going to support TLSv1.2 and higher starting next year, it makes sense that anything older be disabled.

Using 'EECDH+AESGCM:AES+EECDH:!TLSv1:!AESCCM' as the cipher string will result in a good config
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Wed Aug 21, 2019 8:30    Post subject: Reply with quote
Semi-random comments. One of my ongoing tinkering projects is patching and updating oem stock firmware. The only problem is that, for instance in the case of oem Linksys firmware gpl code, both rc and httpd, among other things are pre-compiled binaries. There is no way to tweak or fix them save and except borrowing code from elsewhere, like any incarnation of Tomato. I probably haven't looked deep enough into the GPL source, perhaps, but it would be nice to have the un-compiled source for at least those two binaries. Mainly because some of the included packages for oem stock firmware cannot be changed easily or are not free to update to the latest security patched version, i.e. twonky media server, which is included in the oem stock firmware for Linksys routers. I haven't taken the time to figure out how to fool the pre-compiled rc and httpd to think minidlna is twonky. Anyhow, back towards the point, keeping up with security patches and updates is a never-ending process. Also, FWIW, in regards to the 2.6 Kernel, the most recent version is around 2 years old, 2.6.32.71 (MIPS), if you follow the MIPS community. I tried finding similar info for ARM, but came up short - but I probably wasn't looking as hard Wink. That is probably the other tricky thing, looking at the security vulnerabilities in the 2.6.32 kernel, looking at the upstream patches (for newer kernels) and figuring out backports that will work. Some of the vulnerabilities I have noticed, though, shouldn't be configured items for a router kernel. I mean, who uses CD-ROM drives in a router save and except for an x86 or x86_64/amd64 hardware-based device? Anyhow, just some random things that came to mind reading through this post thread. Security is definitely something that should always be addressed, vulnerabilities mitigated and/or patched, etc., no doubt about that.

EDIT: The easiest 2.6 kernel to patch is actually 2.6.39.4, although there are some upstream patches that just won't work. There could be ways to somehow mitigate things with some kind of hack, but. The painfully obvious thing is, that most managed networking equipment doesn't use modern kernels, and other than possibly using proprietary hardware drivers to mitigate things, there really is no sense of system security in the devices whatsoever.


Last edited by kernel-panic69 on Mon Aug 26, 2019 2:21; edited 1 time in total
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Mon Aug 26, 2019 2:15    Post subject: Reply with quote
BrainSlayer wrote:
i also checked testssl.sh and these weak ciphers arent included since a long time, except you're using a old 4 mb flash device which uses matrixssl. but there is no fix for it, its simply not enough space for a strong ssl library


Just for giggles, I looked up matrixssl. The version in the svn repository is a little dated.

https://github.com/matrixssl/matrixssl
Goto page Previous  1, 2 Display posts from previous:    Page 2 of 2
Post new topic   Reply to topic    DD-WRT 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