Just curious...wouldn't it make sense to apply the patch unless one's
DNS server is firewalled both internally and externally? We have seen
botnet owners launch high volume trojan campaigns at the drop of a hat,
and if it is in fact the botnet owners that are going to exploit this,
it would seem that they could attack from clients within one's network.
It's a much less likely scenario than the worm or direct Internet attack
approaches, but it certainly would still seem to be a vulnerability. I
suppose that it may depend on how ultimately important security is for
one's organization, after all, we don't all use retinal scanners to
unlock our doors :)
Keep in mind that this was detected in the wild 7 days before Microsoft
even released the advisory. The original posts say that the traffic
looks similar to Blaster worm traffic. Here's what happened back in
2003 with that one...note that it hit one month after the advisory and
that one was using ports <1024, though fixed ports that are easier to
target if open:
http://isc.sans.org/diary.html?date=2003-08-11
Matt
Colbeck, Andrew wrote:
The Administrators who should be applying the workaround are precisely
the same Administrators that have accidentally allowed inbound
connections on arbitrary ephemeral ports, i.e. if they clumsily opened
connections as per Darryl's suggestion of how/why this lack of
firewalling might happen.
If you /are not sure/, then apply the workaround.
If you /are sure/, but like a belt and suspenders approach and can
live without using the MMC snap-in to remotely manage your DNS server,
apply the workaround.
Normal DNS traffic, including zone transfers, are not affected.
I've provided the requisite registry entries as text file
attachments. Rename from .txt to .reg and apply the disable registry
file, then stop and start the DNS service. Then test your DNS with a
query or two, and test if the MMC snap-in can truly not manage from a
remote machine if you are so inclined.
It worked for me.
Andrew.
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
Behalf Of *Matt
*Sent:* Friday, April 13, 2007 11:53 AM
*To:* [EMAIL PROTECTED]
*Subject:* Re: [Declude.JunkMail] Vulnerability in RPC on Windows
DNS Server Could Allow Remote Code Execution
Sounds then like it should be more specific. It would seem to
make sense not to expose services such as DNS, which run as SYSTEM
and has full rights, to RPC traffic on variably assigned ports
higher than 1024. Maybe that makes more sense.
We're awfully lucky that stateful firewalls evolved and became
generally available before worms became prolific.
Based on what SANS says, they recommend option #1 of the
recommendations that says "Disable remote management over RPC for
the DNS server via a registry key setting." at
https://isc.sans.org/diary.html?storyid=2627 It would also seem
that if one is not running Windows DNS, then you are not at risk
from this particular threat. Note that this bug has the potential
of becoming another Code Red/Nimda/SQL Slammer if it is worm-ified
and pushed out before the eventual Windows Update is widely
implemented. Seems that spammers are more interested in owning
boxes rather than wreaking widespread havoc with worms these days
though.
Matt
Sanford Whiteman wrote:
It is also odd and possibly grossly incompetent of Microsoft to
choose to use ports 1024+ for such purposes, but I'm thinking that
they have some weakly justifiable reason to do this as a "feature".
RPC endpoints always choose dynamic ports in the customary ephemeral
range, not the reserved range. This is by definition and common sense.
RPC is not a Microsoft invention. It was pioneered by Xerox & Sun and
was implemented using the same basic model across many OSs.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/
Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail
Aliases!
http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
------------------------------------------------------------------------
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters]
"RpcProtocol"=-
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
------------------------------------------------------------------------
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters]
"RpcProtocol"=dword:00000004
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
