Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SilentException]

2. You need the exact name OF the file and path in order to get to it, there is no directory listing. If the person that was doing this already knew all of your directories and files by name, I don't think they would need to backdoor the box by using a URL.

thats not correct, i succesfully got the directory listing ('find />/tmp/list') or executed any command as root using 3rd exploit..

As it is right now, I have a 1.06 beta firmware that this security hole is fixed, all attempts to access files from url on the box direct you to the login page.

besides, why are you just talking about the 2nd problem i noted? others should be fixed too

[D-Link Multimedia]

thats not correct, i succesfully got the directory listing ('find />/tmp/list') or executed any command as root using 3rd exploit..

besides, why are you just talking about the 2nd problem i noted? others should be fixed too

#1 and #2 are linked to the same issue. #3 has to be verified before we can respond to it.

[puterboy]

thats not correct, i succesfully got the directory listing ('find />/tmp/list') or executed any command as root using 3rd exploit..

Were you able to get this exploit to work from unprotected pages? or did the exploit require admin login?
Obviously case #1 would be much more severe because then basically anybody on the LAN would have carte-blanche read/write/execute permission without any password/authentication requirements...

[SilentException]

Were you able to get this exploit to work from unprotected pages? or did the exploit require admin login?
Obviously case #1 would be much more severe because then basically anybody on the LAN would have carte-blanche read/write/execute permission without any password/authentication requirements...

for my test it did require admin login but tbh i didn't look close enough (didn't have time), maybe even unprotected request can be found to do this attack. nevertheless, since the login timeout is default 10minutes and these attacks are local (unless you open port 80 on your dns-323 to the world - this you'd have to be crazy to do) one could execute this attack with no problems using for example arp manipulations.

#1 and #2 are linked to the same issue. #3 has to be verified before we can respond to it.

with #1 i ment that you can access some web interface pages/requests with no authorization

for #3 take the LAN options page for example, remove all javascript checks, in the ip field enter something like ";ls -la />/web/list;", and make request. you could also manipulate http fields directly using programs to do so..

[m3rs4]

well  SilentException. u r the man.
I am so glad that I heard dlink is closing holes for #1 & #2 in the next fw1.6. This is very nice for dlink ppl to listen and work on the problem.

#3 is very bad. and should be fixed 1st by dlink. I dont know what mechanism being used to fix holes for #1 & #2 but I believe if u can get root to execute anything for you then u r god.

[hilaireg]

I fear this thread is in danger of falling into a debate of opinions ... and I may be guilty of fueling some of it

puterboy:

I appreciate your concerns, they are quite valid and should be eventually addressed in a f/w release by D-Link engineering - and QA tested prior to distribution.  That said, I don't feel that they are critical enough to warrant D-Link engineering to rush out a f/w release for the sake of addressing these issues immediately as the tone of your posts seem to suggest.

Most folks that purchase the DNS series device, for the most part, do not even bother to update the f/w to the latest version posted on the D-Link support site.  Most folks take the unit home, plug it in, and start using it until a problem occurs that necessitates a support call to D-Link.  Every unit i've purchased to date ships with the original f/w.

I also had a look on the box regarding the sales/marketing quote you noted ... have a look at the (*) text that's on the end of the box


SilentException:

You made mention of the 'fun_plug' in one of your posts.  I assume that you have validated the vulnerabilities on a non-"fun_plugged" DNS device to ensure that the issues were indeed reproduceable.  I also assume you documented how to reproduce the issues and forwarded the information to D-Link engineering so as to have these exposures addressed.

If not, I would encourage you to send those off to D-Link as soon as you can so that they can review the exposures, address the coding deficiencies, and provide the steps-to-reproduce to their validation group for QA purposes.


fordem/D-Link Multimedia:

I completely agree with your view point; this is a consumer device and not an enterprise device.  Yes, the vulnerabilities need to be addressed but not at the cost of quality assurance.  The last thing D-Link would need is to release a f/w that effectively *bricks* a device or worst yet, makes the filesystem unreadable resulting in complete loss of data - I would not want to be the support desk person if that happened.

Additionally, as you have both pointed out - and rightly so - security is both physical & virtual.  The physical security in most homes is poor at best and anyone that enters the perimeter of the home has pretty much unrestricted access. 

As for virtual security, which is really what we are posting about here, it's less obvious.  Again as you both indicated, most users would not place their DNS device on the Internet ... it' just not best practice for those who can and definitely not something the remaining users would do - they simply wouldn't know how.


In summary, yes; the issues posted here should eventually addressed - it makes good sense to do so.  However, those who think that will resolve everything should:

1) Read up on TCP/IP and encryption of wire traffic - ex: wiretapping, wiresharking, airsniffing
2) Take time to fully understand how to secure confidential data - ex: passwords for backups


Cheers,

[fordem]

hilaireg

I believe the "vulnerabilities" have been verified on a "non fun_plugged" DNS-323, certainly I did some verification of my own when they were first brought to light and again several months later when I discovered that a previously reported "vulnerability" (shutting the device down from a webpage without first authenticating) was not actually a vulnerability.

[hilaireg]

Hi fordem,

Appreciate the follow-up ... just wanted to make certain that the noted vulnerabilities were tested on an untouched/unmodified device.

I was not able to reproduce some of the vulnerabilities listed - not that I tried very hard - and I'm certainly not questionning their validity.

Cheers,