D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-323 => Topic started by: SilentException on June 03, 2008, 02:26:40 AM
-
hi
after little time spent testing the dns-323 web interface security i was surprised how many problems there are. i will not write a tutorial on how to exploit them but just explain what could be done with almost no problems.
1. unprotected pages
there are quite a few pages in the web interface that could be accessed without any form of authorization.
2. directory traversal problem - by entering "special" url, one could read ANY file on the device (like server.pem (private key!!!), shadow or ez-ipupdate.conf (pain text password)). it gets worse by the fact that webs runs as root so there are no permissions you can set to prevent it
3. unvalidated input fields
in many of the input fields data entered is used in system() calls. unfortunately, there is only java-script(!) validation so by bypassing it (easily done) and entering "special" data in the form, one could execute any command on the device as root
i hope d-link will recognize these security overlooks and try to fix them as soon as possible as nothing has been done in any of the firmware revisions..
one easy and quick fix i have thought of would be to ditch "classic" login form, include htdigest authentication in goahead and use it instead to protect root (/).
and that's exactly what i was trying to do last few days but the goahead sources from d-link gpl pack cannot be compiled ::)
-
There 's one more: after the 1.05 upgrade a new file was created on each of my drives, same place as the BT folder, file called '.wget.' something.
The file has hidden attributes but that seems to be the only thing that was done to 'protect' it.
Inside the file you can read in plain text the name/password for the only user with RW access to a drive.
The only thing I did was to set the DNS323 to make an incremental backup from the 1st drive on the 2nd one which is password protected and where only one user has access.
That wget file was created after I upgraded to v1.05
-
This looks to me like this is a very serious laps in security (FW v1.05).
I'm surprised there is no comment from D-Link on this!
The webs process will show *ANY* file on the DNS-323 to
anybody with access to port 80 of the DNS-323 with a web
browser.
http://<dns-ip>/etc/passwd - returns the password file
http://<dsn-ip>/etc/shadow - returns the shadow file
YIKES!!! :o
-
This issue is being looked into by product management.
-
Thanks for the info.... glad my roomie isn't a computer nerd like me.... lol.
-
Has this been sorted out, this is totally unacceptable
what is the point of a Backup storage device when your backup is Totally susceptible to any idiot who clicks on Network Neighborhood, not to mention all the Web security Flaws!!
I cannot believe that D-Link would create such a disaster? what the Hell is the point?
-
This is resolved in the next upcoming firmware.
Thank you.
-
This is resolved in the next upcoming firmware.
Thank you.
OK. I just found this thread and realized that it seems to be reporting the same security issue that I just (belatedly) posted on.
I really appreciate that D-Link is planning on fixing the problem but given the TOTAL SEVERITY of the problem -- i.e. all files (including RSA private keys, plaintext passwords, and all yourprivate data) are trivially readable by anyone with a browser on your local network -- I cannot understand why 4 months later no fixes have been offered.
This is not some obscure theoretical bug but a hole as large as the Pacific ocean that requires no special skills, knowledge, equipment, secrets, computational power or anything to fully exploit.
-
It requires local network access.
This device is meant for consumer use, not commercial or enterprise, nor military secrets - it's meant for use in an average home where, for the most part, users don't even bother with passwords and security comes from locking the doors when you go out.
-
You must have been living alone in a cave for the last 10 years or so.
Even the lowliest version of Windows has had individual password-protected user accounts since at least Win2000.
Even my throwaway cell phone has password protection as does just about any PDA.
Anybody with children or unrelated roommates or frequent guests will likely find themselves in the situation where they want to share network access over their LAN but still maintain some privacy over their personal data.
By definition, the dns-323 is a NAS (network attached storage) device which is defined as "file-level computer data storage connected to a computer network providing data access to heterogeneous network clients." Unless you are a geek living alone with your own network then you are likely to be sharing access with others in which case you would probably like to have a certain minimum level of privacy.
No one is asking for NSA level security. No one is expecting hardened physical-level security.
We are just expecting the device to have a commensurate level of access security to the lowest level Windows computer (which is a very low bar) and to provide the user/group access restrictions as advertised.
The main product page (http://www.dlink.com/products/?pid=509) says:
"With the built-in FTP server3, you can access your files remotely over the Internet from anywhere in the world and keep data safe by only giving rights to specific users or groups."
Well this is worthless at best and misleading or even deceptive advertising at worst if you can use simple http access to read any file you want.
Again, I love this device and I think it is attractively priced. That does not justify the situation which I will summarize again since you seem to be having a lot of trouble understanding it:
- The security hole is severe, pervasive, and easily exploitable without any special tools, knowledge, or access
- D-link continues to actively promote the device as providing secure user/group access to files
- There are many potential fixes which are easy, well-know, and would entail minimal cost in coding and testing (a rudimentary fix would require only a few lines of code)
- No one is asking for anything more than basic SOHO level of password restricted access (not spook-level just the entry level Windows of user accounts, not even ACLs)
- Despite this problem having been known for almost 6 months, D-link has done nothing to solve the problem in the field other than to note that they are working on it
-
OK. I just found this thread and realized that it seems to be reporting the same security issue that I just (belatedly) posted on.
I really appreciate that D-Link is planning on fixing the problem but given the TOTAL SEVERITY of the problem -- i.e. all files (including RSA private keys, plaintext passwords, and all yourprivate data) are trivially readable by anyone with a browser on your local network -- I cannot understand why 4 months later no fixes have been offered.
This is not some obscure theoretical bug but a hole as large as the Pacific ocean that requires no special skills, knowledge, equipment, secrets, computational power or anything to fully exploit.
1. This is a Local network issue. Although it is severe in the fact that you can access files via a URL to the device without authentication, the bigger issue would be the people you are letting connect to your network looking for those files.
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.
3. Fixes take time and this is not the only issue with the last firmware release. There are also feature enhancements being worked on for the next firmware which also take time and testing.
-
I certainly appreciate your response and the fact that D-Link is working on it.
And as I say in all my posts, I think it is a GREAT device - combining attractive features, solid construction, and good pricing.
My only reason for prodding here is that I would have hoped that D-link would have had an intermediate fix sooner for severe security holes like this (along with several of the other major bugs such as BT filling up the desk that don't affect me personally).
I guess my philosophy is that rather than waiting 6 months or longer for a major new release combining major bug fixes, minor bug fixes, and new enhancements, that there should be more frequent intermediate releases as needed to correct the major things.
As others have noted most of the major bugs can be fixed with only minimal changes requiring only minimal investment in development and Q/A. My guess is that the real hold-up is with new functionality that needs to be coded and tested from scratch.
And finally, while the security hole that we are talking about does require you to know the path name, that type of "security by (minimal) obscurity" doesn't exactly reassure me when I realize that various confidential files are only a simple url away...
-
We do appreciate our customers feedback and requests :). Sometimes it takes longer than we want it to due to complications but it does allow us more time to step back and re-evaluate aspects of our products and where there might be future potential.
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.
-
You must have been living alone in a cave for the last 10 years or so.
Even the lowliest version of Windows has had individual password-protected user accounts since at least Win2000.
Even my throwaway cell phone has password protection as does just about any PDA.
Anybody with children or unrelated roommates or frequent guests will likely find themselves in the situation where they want to share network access over their LAN but still maintain some privacy over their personal data.
I'm not referring to what security is available, but rather what is actually used.
I also do not live alone but rather with a very computer literate family - six members, with four desktops, six laptops, a Windows server, miscellaneous PDAs and handhelds with network access, a mixed wired (100/1000) mbps and wireless (802.11n) network, supporting multiple network printers - including laser and color all-in-ones (and yes the all-in-one is fully functional over the network).
To get back to security - did you chain your DNS-323 down or can your room mate walk in and just pick it up?
Oh - I forgot - I do network implementations (among other things) for a living, and that includes firewalls and wireless with 802.1x and PEAP, you know the one where every wireless device gets it's own strong encryption key, with the keys being randomly generated and automatically changed every fifteen minutes.
I point out the above only so you recognize that I have a healthy understanding of network security and how and when it actually gets used - sure you can lock your network down, and change your passwords every thirty days, but then you end up with the users taping them to the underside of the keyboard - I've seen one SecureID installation (password changes every 60 seconds), where the used kept the SecureID fob in an unlocked desk drawer with the user name taped to it.
A couple of points - the "security hole" requires you to have specialized knowledge - at a minimum the URL required to access it, and the user level security offered by the device is in my opinion is adequate for most homes where Windows is the dominant OS, your average Windows user is not going to fiddling with http to get access.
On the ftp issue - the device is as secure as any other ftp device - you post in the other forum, you've seen the warnings about how rapidly your ftp server will be compromised - try this - I've been running an ftp server on my DNS-323 and allowing anonymous access for several weeks now, access is logged at the firewall, and the only thing showing in those logs is when I access it - you go onto mention this being deceptive because you can access it using http - if you have provided port 80 access to the device, yes, that access would be possible, but I would question the reason for providing port 80 access.
If the DNS-323 is used as intended, in the environment in which it was intended, the security, whilst not top notch, will be adequate for most users - even with the present "security hole".
-
Listen, I'm sorry if I got to ad-hominem and I certainly don't want to get in a flame war.
I understand your point but while I may be exaggerating the actual threat on a typical SOHO network, I think that you are taking the opposite extreme.
While physical security and even more so "social engineering" and "human error" are often much bigger real-world security risks than data security, that doesn't mean that we get to be sloppy on the software side.
My only suggestion is to hold D-Link to the same level of base authentication security that one finds in low end home Windows OS and consumer electronics. And trust me, that is not a very high bar.
And it's not just security from crackers that is the problem. Writing code where all processes have root level access (as in the webs application) or where all files are world readable/writeable (as in the chmod a+w or chmod 777 snippets) is just sloppy coding and likely to get you into trouble. On my home Linux system, I use selinux, tcpwrappers, and sudo rather than su -- not because I worry about intruders but because it prevents me from doing stupid things and from writing sloppy code that may some day come back to bite me.
When I look at the scripts in /sys/crfs I see a lot of sloppy code. Sometimes it works and gets the job done. But other times it comes back to bite you as in the case mentioned here. This is not rocket science and my feedback to d-link is meant to be constructive to encourage a tighter level of programming. Heck, I'm just an amateur recreational programmer and I write far tighter code than I see in these scripts.
[and just as a side point -- I keep ftp (and also telnet, upnp etc.) disabled since I know how vulnerable it is -- I allow only local samba file sharing and remote access can only be done via ssh and even that only indirectly through a local machine and requiring a private key. Given the holes in http access, I'm probably going to shut down the webs process in my fun_plug.local script which runs off a usb stick so I can remove it if I need to get back to the basic setup. Which means that my biggest remaining vulnerability will be physical security which I am comfortable with]
-
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
-
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.
-
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...
-
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..
-
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.
-
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,
-
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.
-
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,