('binary' encoding is not supported, stored as-is) Here is a message that I sent to D-Link support regarding this vulnerability: -- Start email -- I currently own a DWL-1000AP Wireless Access point. My firmware version is 3.2.28 #483 (Aug 23 2001). I run my access point using 128-bit WEP, a non-default admin password, a non-default SSID name, and I disallow all MACs except for those explicitly allowed. Knowing that the DWL-1000AP used SNMP, I performed a MIB walk to obtain the available counters that I could monitor. In the process I found a weakness in the product which could potentially allow an attacker to hijack the access point. I first performed the MIB walk using the read-only SNMP community of public (which was simply a educated guess on my part, but nontheless the default read-only community for most devices). I was surprised to find the "admin password" (for this example my password was "snowball") to the access point listed in clear text in OID 1.3.6.1.4.1.937.2.1.2.2.0 as a string value. Next I setup my SNMP utility to use "snowball" as the write community, and I was able to reset the value stored in that OID to any arbitrary value. A quick check by accessing the HTTP configuration page of the access point showed that the password was indeed changed. This means that anyone armed with a simple SNMP utility which can perform read and write operations, the read community name (which defaults to "public" with no way to change it using D-Link's config software), and access to the network connected to the ethernet port of the access point could hijack the access point and either simply configure it to allow them access to the wireless network or completely change the configuration and cause a denial of service. The only protection currently offered by the access point against this attack is the lock access point procedure. While this is effective, I do not believe that it is practical. The access point may be mounted in a hard to access area, for example, in which case a simple configuration change would require physical access to the device, which may be impractical in all situations. A more practical solution would be to give the user the ability to set both the read-only (found in OID 1.3.6.1.4.1.937.2.1.2.1.0) and write community names. This can currently be done, as I have tested, by using an SNMP utility to write to the read-only community OID. By changing that community, an attacker would have to sniff SNMP packets accross the network or otherwise figure out the read-only community, a more difficult task than simply using the default read-only community for most SNMP devices. By giving the user the ability to control the read-only community value through the HTTP configuration, it would be a very simple task for that user to change the value during the initial setup and thus increase the security of the access point. I realize that the most secure method is the lock access point method. However, I believe that the simple ability to change the read-only community name has enough security value and is simple enough not to be overlooked and should be integrated into your configuration software. -- End email -- D-Link responded with this unsatisfactory message: -- Start email -- Dear Valued Customer, In regards to your e-mail, I agree however the dwl-1000 is intended for residential use. It doesn't put of enough wireless signal to cause much concern of hackers. The hacker would have to be sitting outside you house by the window. Thank you for your technical question and feedback. If you are continuing to have problems, please contact our live support at 800-758-5489 or resubmit the problem at http://www.dlink.com/tech/contact/. Thank You, D-Link US Technical Support 949-790-5290 -- End email -- I find D-Link's response to be unsatisfactory, considering how easy it would be to allow a user to change the read community name. Until D-Link decides to do anything, I'd encourage anyone who has a DWL-1000AP to use an SNMP utility to change the read community stored in OID (1.3.6.1.4.1.937.2.1.2.1.0). Jonathan Strine jstrineat_private
This archive was generated by hypermail 2b30 : Fri Dec 21 2001 - 11:58:49 PST