PRBear8
join:2003-01-02
Norwalk, CT
| reply to DLinkSupprt3
Re: Remotely Exploitable Vulnerability In All D-Link Gateways
Is the VDI-624 also affected? It's basically a DI-624 with custom firmware.
If it is affected, is D-Link working on a patched firmware for it?
Is Verizon aware of the issue and who's responsible if my PC's are attacked as a result of the vulnerability? D-Link or Verizon? |
|
klo
join:2006-07-08
0000
| reply to JTS33
Urm... I forgotten to read the wireless part of your post JTS33...
Yes, if it is UPnP, I would imagine it is also exploitable via wireless - after all, the problem lies in the UPnP feature.
Here's something I found in the forum you might find helpful:
»www.eeye.com/html/research/advis···714.html |
|
klo
join:2006-07-08
0000 | reply to JTS33
Yeah it seems that way - at least from what I've heard / read anyway... |
|
JTS33
join:2003-05-03
USA | reply to klo
Is the UPnP vulnerability exploitable only to someone who has physical access to the router? (in other words, being able to plug into one of the wired ports).
Or can it be used to compromise the router wirelessly? |
|
klo
join:2006-07-08
0000 | reply to Hofbrau
I know this might be a bit of a stupid question, but would disabling UPnP on the router mitigate this vulnerability?
(Btw. thanks rseiler, for the link!) |
|
rseiler
join:2001-11-01
| reply to Hofbrau
Re: Remotely Exploitable Vulnerability In All D-Link Gateways
Is this it?
»www.eeye.com/html/research/advis···714.html
Given this, it would seem that the problem is all but meaningless for wired routers: "This vulnerability exists on the Local Area Network (LAN) interface of affected D-Link devices. Due to the ease in which one can gain access to the LAN interface of wireless devices, this attack is remote in nature."
Systems Affected:
DI-524 Rev A
DI-524 Rev C
DI-524 Rev D
DI-604 Rev E
DI-624 Rev C
DI-624 Rev D
DI-784 Rev A
EBR-2310 Rev A
WBR-1310 Rev A
WBR-2310 Rev A |
|
Stonecoldtx
join:2003-05-14
Dallas, TX
1 edit | reply to Hofbrau
Would this perhaps be the Vulnerability?
»www.securityfocus.com/bid/16621
Or, perhaps THIS one, from last year?
»www.securityfocus.com/bid/13679 |
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC | reply to JTS33
This whole thread is horked.
There obviously are two different issues.
The DI-5xx/6xx software architectures are fundamentally different than the 2100AP and it is unlikely that they would share the same bugs or vulnerabilities. |
|
JTS33
join:2003-05-03
USA
3 edits | reply to funchords
said by funchords  :said by DLinkSupprt3 :The routers that could be affected by this are: DI-524 DI-604 DI-624 DI-784 EBR-2310 WBR-1310 WBR-2310 We have released firmware for the following models: DI-604 - 3.52 DI-784 - 2.40 EBR-2310 - 1.04 Firmware for the other models is currently being tested. We're not trying to make light of the subject, but the problem found has to do with UPnP, which is a LAN side protocol, so the routers will not be susceptible to WAN side attacks because of it. I'm sorry, but this is making no sense to me at all. First, D-Link does not list the 2100ap above. Second, the exploit mentioned seems to have nothing to do with UPnP. I'm perfectly willing to end up with egg on my face -- but is D-Link sure that we're talking about the same vulnerability? -- Robb the Very Confused The webpage link in the original post doesn't provide any details about the vulnerability except to say that it allows remote code execution. But given the mention of UPnP, it is probably referring to a different vulnerability than the webpage links provided by latinuser_uy concerning the 2100ap. |
|
sir_brizz
join:2005-12-29
Pleasant Grove, UT | reply to JimF
Re: New firmware available for DI-624!
WBR-2310 1.02 Beta, stable so far, and fixes exploits mentioned. |
|
JimF
join:2003-06-15
Allentown, PA
3 edits | reply to klo
The comparable software for the DI-524 fixes the UPNP reboot issue for me. It is completely stable after 24 hours even with UPNP disabled. But I use it only as an access point, and can not check the other reboot issues, such as P2P or gaming use that require opening ports and may cause reboots with heavy use. And I would avoid Turbo mode with the 624. |
|
klo
@co.uk
| reply to Hofbrau
Hey have anyone tried the new firmware for DI-624 on the UK D-Link site?
»www.dlink.co.uk/?go=jN7uAYLx/oIJ···bpTNuU6B
For those who have tried it, does it also fix the reboot problem?
I'd love to know as I'm on a slightly older (but very stable) FW at the moment and I'd like to keep my router as stable as possible.
Thanks. |
|
JimF
join:2003-06-15
Allentown, PA
1 edit | reply to JTS33
Re: Remotely Exploitable Vulnerability In All D-Link Gateways
Yes, I am using 3.20 now. But I have tried 3.02, its original firmware, and it still reboots with UPNP disabled, though not as frequently as with 3.20. In fact, I have gone through all the recent versions of the DI-624 firmware also using paul248's hex editing procedure, including 2.71b11 and 2.59, as well as the Eusso generic firmware and they behave the same way insofar as UPNP is concerned for me. There are other factors that cause reboots too, and you have to un-peel the onion layer by layer. But 3.20 is stable for me now.
|
|
JTS33
join:2003-05-03
USA
| reply to JimF
said by JimF :I use my DI-524 C1 as an access point only, with the WAN port disconnected and DHCP turned off, and still get the reboots when UPNP is disabled. You're running firmware v3.20, right?
With my DI-524 C1,
firmware 3.20 = reboots with UPnP disabled
firmware 3.02 = NO reboots with UPnP disabled
It looks like a firmware issue to me. |
|
JimF
join:2003-06-15
Allentown, PA
| reply to Hofbrau
said by Hofbrau :
"Ironically, disabling UPnP in the router control panel is what causes many DI-624 Rev. C3 to randomly reboot"
It might not be so ironic (or random) after all. It could very well be that disabling UPnP exposes the vulnerability in some manner, which allows incidental Denial of Service conditions to take place, an obvious symptom of which might be resetting of the gateway.
Probably not. I use my DI-524 C1 as an access point only, with the WAN port disconnected and DHCP turned off, and still get the reboots when UPNP is disabled. In fact, the reboots occur even if there is no traffic at all through the DI-524. It is a long-standing problem that predates the discovery of the vulnerability. Yes, I have seen cases where the wrong packet can cause a reboot even of my PC. But I expect this rebooting problem is just due to inadequate testing of the router under non-default conditions, since UPNP is enabled by default. It doesn't say much for their quality control, but I am personally not concerned about the security issue. In fact, it is pretty safe as it is rebooting. |
|
Hofbrau
@rr.com
| reply to neek
"This Firmware update: DI-604 - 3.52 is for the DI-604 Rev. E. I have the DI-604 Rev. B, is there a Firmware update planned for it as well?"
Great question.
If only D-Link had a security advisory/statement with a FAQ to answer such questions.
Nah, thats expecting too much from them.
Cogitate,
Hofbrau |
|
Hofbrau
@rr.com
| reply to 524DJunk
"Does this mean there is a possiblity that Dlink will update the DI524 Rev d firmware. It is utter garbage your own tech told me so."
Take note of the fact that even though they list the 604 as being "fixed", the firmware update made available only applies to the E revision of the 604. Earlier revisions have no firmware update made available.
You might want to keep that in mind when it comes to your own situation with your 524 Rev D.
Cogitate,
Hofbrau |
|
Hofbrau
@rr.com
| reply to JimF
"It looks like the eEye report, and the reply from DLinkSupprt3 refers to "routers". The post from latinuser_uy refers to the DWL-2100ap, which is of course an access point, though it seems to be loosely referred to as a router also in some of the security reports. So there may be two different vulnerabilities."
Two different vulnerabilities.
The D-Link "tech" essentially confirms it with his statement regarding the vulnerability being related to the UPnP functionality - which isnt in play with the DWL-2100AP report.
"At any rate, they don't list the DI-634M as being affected, and you can turn off UPnP on that without a problem."
Different UPnP IGD 1.0 code modules most likely. There are plenty of vendors of UPnP device code these days, not to mention all the in-house modifications that chipset makers and device vendors can and do make with whatever code they licensed (assuming its licensed, and not completely coded in-house).
"So I am hoping that the fix will allow UPnP to be turned off on the DI-524 as well. We can always hope."
It certainly would be nice if they included a stable mature robust sedure UPnP IGD 1.0 implementation.
Considering all the exposure that Microsoft endured over its own insecure UPnP support code in Windows back in late 2001, youd think a UnP device implementer would "go the extra mile" when it comes to verifying and testing their UPnP code/functionality.
Also, considering that such UPnP code is modular, and available for licensing/usage from several sources/vendors, and considering that eEye only listed D-Link gateways being affected (assuming they tested other vendors popular models), one can reasonably assume that D-link either coded its UPnP IGD module in house, or did in-house modifications to a licensed module from a third party.
Either way, it doesnt bode well for D-Link's in-house firmware engineering and development.
Cogitate,
Hofbrau |
|
Hofbrau
@rr.com
| reply to funchords
"I'm sorry, but this is making no sense to me at all."
I bet it doesnt.
Its what happens when one doesnt read (in this case the original post).
"First, D-Link does not list the 2100ap above."
Ayup. Its not gateway. Its a wireless access point. As such, it wouldnt need UPnP IGD (Internet Gateway Device) 1.0 support, since, its not a gateway. It could have UPnP WLAN Wireless Access Point 1.0 support, or even UPnP Basic Device 1.0 support, but, it doesnt.
Its not a gateway, and it doesnt have UPnP device support of any kind.
One might consider these additional "clues" that one apparently didnt bother reading the original post, or the content at the referenced link, or, didnt comprehend that the second post contains links to a different vulnerability.
"Second, the exploit mentioned seems to have nothing to do with UPnP."
Perhaps you should have read the original post, and not the second post, for details (as minimally provided) about the vulnerability.
Nothing in the provided "details" would exclude UPnP in any way, and would in fact include it, considering that the vulnerability is remotely exploitable, and UPnP IGD 1.0 is a "remotely accessible" service.
Reading - it works.
Cogitate,
Hofbrau |
|
