February 2006

Recursive DNS servers as a growing DDoS problem

hi guys.

we discussed recursive dns servers before (servers which allow to query anything – including what they are not authoritative for, through them).

the attack currently in the wild is a lot bigger and more complicated than this, but to begin, here is an explanation (by metaphor) of that part:

spoofed icmp attacks have been around for a while. how many of us still get quite a bit of icmp echo replies stopped at our borders? these replies come to us due to spoofed attacks using our addresses.

now, imagine it – only bigger:
smurf.

introduce an amplification effect.

as bigger udp packets will be fragmented by the servers, and udp obviously does not do any handshake and can easily be spoofed…
the server receives a large packet, breaks it down to several fragments and moves the query on.
that’s where the amplification effect starts.

both the attacked server and the unwilling participant in the attack, the recursive servers, experience a serious dns denial of service that keeps getting amplified considerably.

one of the problems is obviously the spoofing. let us, metaphorically and wrongly treat it for a minute as the remote exploit.

the second part of this problem is the recursive server, which for the moment we will wrongly treat as the local exploit.

obviously both need to be fixed. which is easier i am not so sure.

in the past, most network operators refused to implement best practices such as bcp38 (go fergie!) because they saw no reason for the hassle. returning back to: “if it isn’t being exploited right now, why should i worry about it?”

well, it is being exploited now, and will be further exploited in the future. combating spoofing on the internet is indeed important and now becoming critical.

removing the spoofing part for a second, the attack vector for this can easily be replaced, as one example, with a botnet.

a million trojaned hosts sending in even one packet a minute would cause quite a buzz – and do. now amplify the effect by the recursive servers and…

so, putting the spoofing aside, what do we do about our recursive servers?

there are some good url’s for that, here are some:
http://www.us-cert.gov/reading_room/dns-recursion121605.pdf
http://cc.uoregon.edu/cnews/winter2006/recursive.htm
http://dns.measurement-factory.com/surveys/sum1.html

the recursive behaviour is necessary for some authoritative servers, but not for all. as a best practice for organizations, as an example, the server facing the world should not also be the one facing your organization (your users/clients). limiting this ability to your network space is also a good idea.

if you would like to check for yourselves, here is a message from duane wessels [1] to the dns-operations [2] mailing list where this is currently being discussed:

if anyone has the need to test particular addresses for the presence of open resolvers, please feel free to use this tool:

http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl

it will send a single “recursion desired” query to a target address.
if that query is forwarded to our authoritative server, the host has an open resolver running at that address.

dan (da man) kaminsky and mike schiffman have done some impressive work on this subject, outlined in dan’s latest shmoocon talk.
they found ~580k open resolvers:
http://deluvian.doxpara.com/, http://www.doxpara.com/

i suggest those of us who need more information or help go to the dns-operations mailing list from oarc (see below) and ask the experts there, now that this is finally public.

update:

full technical details on how the attack works at:
http://www.isotf.org/news/dns-amplification-attacks.pdf

gadi evron,
ge@beyondsecurity.com.

[1] duane wessels – dns genius and among other accomplishments the author of dns top.
[2] dns-operations – http://lists.oarci.net/mailman/listinfo/dns-operations

[changed title from: recursive dns servers ddos as a growing ddos problem]

Microsoft and week-lasting Security Advisory fix process [UPDATED]

The fixing process of Microsoft Security Advisories page is not the fastest I have seen.

On 16th February I noticed several mysterious non-working links at advisory Vulnerability in Windows Service ACLs. Service Pack download links and the CVE-2006-0023 reference pointed to the following target directory:

www.microsoft.com/Local Settings/Temporary Internet Files/Local Settings/Temporary Internet Files/OLK4D

and its subdirectories. All folders located at OLK4D were named as ‘H’, J’ etc. Like we now, Windows uses names of these type when generating subdirectories to Temporary Internet Files folder. You can’t see these in Windows Explorer, you have to use Command Prompt, DIR/A is worth of trying 😉

I have informed MSRC immediately after noticing of these errors. No need to say that clicking these links generated a typical “We’re sorry, the page you requested could not be found” 404 page. Microsoft fixed these links on Friday, Feb 24th, after _eight_ days.

There was a similar case related to Sober advisory #912920 earlier too. AV vendor links pointed to the Desktop folder. For example, McAfee’s W32/Sober link pointed to

www.microsoft.com/Desktop\'.

When visiting these links they were being redirected to Desktop Deployment page www.microsoft.com/technet/desktopdeployment/default.mspx. Odd.
I checked the HTML source code too and this was the result:

Real Symantec’s URL

www.symantec.com/avcenter/venc/data/w32.sober.x@mm.html

pointed to

"/Desktop/~".

The next question is if these directories were from the internal publishing system or directories in workstations used in publishing process.

Update: Added information about previous issue in Sober.X Security Advisory 912920 etc.

Enron – the pain keeps coming

Note: I posted this to slashdot along with proof of the Private data. It has not yet been approved.

A year (or more) ago, a large batch of Enron emails were released to the public. This data set has been very useful from a ‘Research’ perspective. Just this weekend, I was using it to test the speed of PCRE vs Python vs Perl…until I happened upon a little nugget of information which led me to look at the dataset from a Security/Privacy perspective.

It appears as if data is included within these emails which violates individual Privacy. The data includes, but is not limited to, Account information to non-Enron applications (FTP login credentials, web credentials, etc.), Parent-teacher school data, private residence addresses, private residence phone numbers, Names and Social Security Numbers, and more.

Where did the Enron emails come from? The United States Federal Energy Regulatory Commission. That’s sad.

Some examples (I stripped out the SSN or Credit Card number with X’s, and changed the name/address):

A Social Security Number

To: Patti Thompson/HOU/ECT@ECT
cc: Sally Beck/HOU/ECT@ECT, Shelly Jones/HOU/ECT@ECT
Subject: Summer Intern Information

Patti:

The following intern will be in Sally’s department this summer:

Name Start Date SS#

Jane Doe May 22, 2000 XXX-XX-XXXX

Please let me know the CO# and Cost Center#.

If you have any questions, I can be reached at x35850.

Thank you.

-sap

Another Social Security Number

From: christina.valdez@enron.com
Subject: Tom Hopwood
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Badge #15518 – SS # XXX-XX-XXXX

A Credit Card purchase

Date: Thu, 10 May 2001 08:07:00 -0700 (PDT)
From: john.arnold@enron.com
To: ticketwarehouse@aol.com
Subject: Re: eBay End of Auction – Item # 1236142249
Mime-Version: 1.0^
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

199.99+ $18 o/n shipping = 217.99

Visa 4128 XXXX XXXX XXXX exp X/XX

shipping and billing address :
John Arnold
XXXX XXXX XX
Houston, TX 77002
XXX-XXX-XXXX