Slashdot Mirror

Ironically, that same update describes Comcast's nationwide problems that started last night (US Time) and says it was caused by an equipment upgrade and not related to the DNS Cache poisoning. BUT, the problem was not network connectivity, but the DHCP's DNS Servers became unavailable. Read more at DSLReports and (from first hand experience), the work-around was fairly easy which was to manually specify the DNS server, rather than use the DHCP'd one. Comcast says it was resolved about two hours ago - scroll down to the bottom of the page.

You probably would have been better off sending your findings to handlers@sans.org

I did. They responded by posting that Win2k SP3+ was supposedly immune but that people with that configuration were reporting the poisoning.

Today's ISC update from SANS indicates they're closing in on the root cause. Apparently, MS DNS servers implicitly trust servers to which they forward. BIND 4 and BIND 8 don't scrub poisoning information when they respond to a forwarding server. DJBDNS and BIND 9 do scrub the data.

See the SANS "Survival Time" data - It's currently at 21 minutes, but it has been 15 minutes in the past.

I have been discussing this topic with a couple collegues, and the last time we recalled the SANS security level raised to Yellow was right before each major worm release... i.e.: Blaster, Sasser Worm, etc...

http://isc.sans.org/infocon.php

Just food for thought.

I took the SANS security boot camp when they first started. I found it valuable and very well done. A solid week of good, well presented, stuff that you won't find anywhere else.

However, even though I passed all the exams needed for GIAC certification, the follow on requirement to submit papers simply did not fit my work schedule. As the only system administrator for a small startup, I simply did not have time to write papers. So, the requirement they appear to be dropping was the requirement that blocked my certification.

Writing a good paper takes time and focus. Something that working system administrators often find short in supply.

By poisoning DNS they can take over the domain of a "good" web site. Just a very recent example. Or how about the Google 302 redirect?

Since the majority of viruses, spyware, and other crap are due to user inaction, this isn't really a fair metric about the overall security. However, it is good to compare against the Windows survival time which is measured in minutes. This does show that Apple has its default security setup as "paranoid with multiple tin foil hats) compared to Windows XP's default setup. A more interesting test would compare how hard it is to get spyware onto a user's computer via the default webbrowser since that seems to be the primary vector these days. However, this is problematic since it's heavily dependent on user stupidity.

--
Want a free iPod?
Or try a free Nintendo DS, GC, PS2, Xbox. (you only need 4 referrals)
Wired article as proof

What the hell difference is it in a lab environment if my system is more secure than yours if there's no measure of real world elements? Dropping a couple hundred boxes on the net and plotting out the time it takes for their security to be subverted would be a good measure of the OS security.

Multiple bandwidth tests (56k-1.5mbdsl) trying to update the OS. Utilizing vendor (Dell/HP/Gateway) XP installs/Linux installs (not fully patched, but patched a *little*) In combination with hardened installations in similar configurations. You could more than likely run a hardened setup with autoupdates on Windows/Linux side by side without a successful attack the length of the survey.

Oh I don't know, something like: this

http://isc.sans.org/diary.php?date=2004-10-11

a few hints to identify whats going on in a particular system.

Maybe I have been lucky but I see less then 5 attempts to my port 22 a day. I only allow accounts with existing keys (no password auth) and only from a few source ip addresses access but I can still see all of the attempts that fail. You can always see the trends by port and attack by browsing the internet storm center. See how you compare to the averages or you can look up specific port related issues from the other links on that page.

http://www.e-fense.com/helix/Helix is a forensics LiveCD, comes with a bunch of great apps, and as their web-site says, http://www.sans.org/ SANS uses their liveCD for their forensics training. Pretty cool if you ask me.

As you point out, this attack exploits weak passwords in MySQL - a social engineering attack, irrelevant to the source code. But the patch question I raised,

"And what happens when different people release incompatible patches? Is a worm a good way to force a fork in an OSS project, making it less competitive?"

is still valid in general. Sometimes it takes a while for the "official" distributor of the software to issue a patch. In the meantime, many of us with the source of a vulnerable OSS program will patch the hole ourselves. And distribute the patch, at first to our friends, but then into general circulation. If we distribute the SW we patched, and it's under GPL, we're obligated to distribute the patch. So multiple patches, from different sources, can be available, and even necessary when the official vendor doesn't release one faster, leaving our systems vulnerable. Especially if we examine the "alternate" patches ourselves before installing, using them can be teh safest alternative. But now the source has forked. So this is a "social engineering" DoS opportunity to attack the official app project: exploit enough bugs too quickly for the official project to issue patches quickly enough to meet demand, and people will write their own, forking the project. If that happens enough, and a full patchset remains unavailable from the official project, the source might remain forked.

This scenario seems unlikely, though possible, and is hypothetical until it is actually encountered. But it is a vulnerability that OSS projects have that proprietary ones don't, relying on the usually advantageous property of open "patchability". I won't be surprised to see it actually happen someday. Especially when some valuable, resourceful proprietary apps get lethally threatened by competing OSS apps. So, just like any other security scenario, it's worth considering in advance. So when it does happen, at least the attackers won't have the element of surprise totally on their side.

I imagine an SSL man-in-the-middle attack could also be quite effective (assuming their browser hasn't already seen the 'bank.com' certificate to know its changed.

The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.

Following the Bouncing Malware: Part I
http://isc.sans.org/diary.php?date=2004-07-23

Following the Bouncing Malware: Part II
http://isc.sans.org/diary.php?date=2004-08-23

Following the Bouncing Malware: Part III
http://isc.sans.org/diary.php?date=2004-11-04

Following the Bouncing Malware: Part IV
http://isc.sans.org/diary.php?date=2004-11-24

The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.

Following the Bouncing Malware: Part I
http://isc.sans.org/diary.php?date=2004-07-23

Following the Bouncing Malware: Part II
http://isc.sans.org/diary.php?date=2004-08-23

Following the Bouncing Malware: Part III
http://isc.sans.org/diary.php?date=2004-11-04

Following the Bouncing Malware: Part IV
http://isc.sans.org/diary.php?date=2004-11-24

The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.

Following the Bouncing Malware: Part I
http://isc.sans.org/diary.php?date=2004-07-23

Following the Bouncing Malware: Part II
http://isc.sans.org/diary.php?date=2004-08-23

Following the Bouncing Malware: Part III
http://isc.sans.org/diary.php?date=2004-11-04

Following the Bouncing Malware: Part IV
http://isc.sans.org/diary.php?date=2004-11-24

The Internet Storm Centre's "Follow the Bouncing Malware" diary entries (written by Tom Liston) covers passthison.com (which belongs to Spamford). Quite a good read.

Following the Bouncing Malware: Part I
http://isc.sans.org/diary.php?date=2004-07-23

Following the Bouncing Malware: Part II
http://isc.sans.org/diary.php?date=2004-08-23

Following the Bouncing Malware: Part III
http://isc.sans.org/diary.php?date=2004-11-04

Following the Bouncing Malware: Part IV
http://isc.sans.org/diary.php?date=2004-11-24

Note: we earlier reported that it takes advantage of a php vulnerability. This does not seem to be the case.

The ISC posted a couple of snort sigs and other details.

"An attack would require a user to visit the attacker's Web site first, and any type of Web browser could make a user vulnerable."

It seems like most non-email Internet attacks require you to visit an attacker's website before the payload can be delivered (there are some good articles about this at ISC). I would tend to think that unpatched browsers (<cough>IE<cough>) would still cause more problems that this.

Don't misunderstand me, though; I am not trying to excuse Google from the flaw, but the good news is that it's already fixed, and I'm sure the scum of the Internet are going to focus on these other (exciting, money-making) opportunities.

PS. I know Seth Fogarty, does that give me some sort of karma bonus ;-)

It's not just anecdotal evidence. SANS has hard numbers of average the "survival time" before you're attacked. Currently it's 18 minutes.

Put an unpatched windows machine unprotected on the Internet and you are toast.

The fact remains that getting rid of spyware is very, very hard.

Agreed. However, installing spyware in the first place shouldn't be as ridiculously easy as it is!

The design tradeoffs between security/usability have in IE have created a wonderful inTRAnet explorer. It's great for filling in the company timesheet using some custom ActiveX applet, but it should _NEVER_ be allowed on the inTERnet.

To follow your analogy, a dune-buggy is fantastic at messing around on dunes, but you wouldn't want to be driving one on the highway.

[ shameless plug ]
See "Examination of PC security: How we got where we are and how to fix it"
[ /shameless plug ]

*rolls eyes*

It's not the Java game ITSELF that hands out the malware, its their presence on a page that also contains malware.

When a person says they have to get their Java game fix on, they're not talking about Java doing the damage - they're pointing out that these games have to RESIDE ON A PAGE SOMEWHERE. Since our open source buddys like to give stuff away, unscrupulous individuals take advantage of that, and find a way to make a profit - off the backs of a generous donation to the world community, I might add.

A "popular" example is yahoogamez (used by "Follow the Bouncing Malware" series of articles at SANS)

Here's a link to begin reading about the site, and the consequences.

Here's Part 4

The Helix distribution is meant to serve a very specific purpose: Incident response and gathering evidence. The tools included in the distribution are excellent for both Windows and Linux incident response (i.e. penetration, compromise, etc). When inserted into a Windows machine, it provides excellent tools for gathering evidence from hardware storage and memory storage. You can also use it in two fashions for Linux incident response: 1) Immediate response (just insert the CD have access to non-compromised programs), and 2) bootable in case the target system has been shutdown (a common reaction when an admin finds a server has been compromised). Because it is based on Knoppix, it does a great job at recognizing hardware, including useful tools, etc. With the Helix distribution, and good sized USB/Firewire external harddrive, you have everything you need to gather critical evidence when a system has been compromised. I have also read the Windows Incident Recovery book. While I found it not very complete (very little discussion of the actual gathering of evidence, and discussion of evidence preservation) it did have some good Windows information. However, the best environment for analysis is Linux because of the open source nature, and the capabilities of its included toolsets. If you are interested in this area, I highly recommend the training provided by SANS (http://www.sans.org/) in their Track 8: Systems Forensics. Its expensive, but the information and tools are well worth it.

Part 4 is already here.

Tom Listons Following the Bouncing Malware from ISC SANS has some amazing info. He did a complete analysis of www.yahoogamez.com. That site gave him some great infections.

FTBM - Part I -
http://isc.sans.org/diary.php?date=2004-07-23/
FTBM - Part II -
http://isc.sans.org/diary.php?date=2004-08-23/
FTBM - Part III -
http://isc.sans.org/diary.php?date=2004-11-04/
FTBM - PART IV -
http://isc.sans.org/diary.php?date=2004-11-24/

Tom Listons Following the Bouncing Malware from ISC SANS has some amazing info. He did a complete analysis of www.yahoogamez.com. That site gave him some great infections.

FTBM - Part I -
http://isc.sans.org/diary.php?date=2004-07-23/
FTBM - Part II -
http://isc.sans.org/diary.php?date=2004-08-23/
FTBM - Part III -
http://isc.sans.org/diary.php?date=2004-11-04/
FTBM - PART IV -
http://isc.sans.org/diary.php?date=2004-11-24/

Tom Listons Following the Bouncing Malware from ISC SANS has some amazing info. He did a complete analysis of www.yahoogamez.com. That site gave him some great infections.

FTBM - Part I -
http://isc.sans.org/diary.php?date=2004-07-23/
FTBM - Part II -
http://isc.sans.org/diary.php?date=2004-08-23/
FTBM - Part III -
http://isc.sans.org/diary.php?date=2004-11-04/
FTBM - PART IV -
http://isc.sans.org/diary.php?date=2004-11-24/

Tom Listons Following the Bouncing Malware from ISC SANS has some amazing info. He did a complete analysis of www.yahoogamez.com. That site gave him some great infections.

FTBM - Part I -
http://isc.sans.org/diary.php?date=2004-07-23/
FTBM - Part II -
http://isc.sans.org/diary.php?date=2004-08-23/
FTBM - Part III -
http://isc.sans.org/diary.php?date=2004-11-04/
FTBM - PART IV -
http://isc.sans.org/diary.php?date=2004-11-24/

There are at least two other IE exploits out there that MS has not patched, and SP2 won't protect you. see: http://isc.sans.org/diary.php?date=2004-11-20 Quote: Two More IE Vulnerabilities Exploit code has been released for two more Internet Explorer vulnerabilities that were released on Wednesday (Nov. 17). This code would enable an attacker to trick users into executing malware. These vulnerabilities affect Microsoft Internet Explorer 6.0 SP2 and are not prevented by Windows XP SP2. The original advisory is here: http://secunia.com/advisories/13203/ The proof of concept exploit: http://www.k-otik.com/exploits/2041119.IESP2disclo sure.php While on the topic, it is interesting to note some statistics that Secunia has been compiling about Internet Explorer vulnerabilities: IE 5.01 - 42 advisories (7 unpatched) http://secunia.com/product/9/ IE 5.5 - 55 advisories (8 unpatched) http://secunia.com/product/10/ IE 6.0 - 69 advisories (18 unpatched) http://secunia.com/product/11/ If you still think SP2 has mystical properties: http://www.safecenter.net/UMBRELLAWEBV4/ie_unpatch ed/

• Part 1
• Part 2
• Part 3

• Part 1
• Part 2
• Part 3

• Part 1
• Part 2
• Part 3

• Part 1
• Part 2
• Part 3

• Part 1
• Part 2
• Part 3

The ISC has more details here and here.

The ISC has more details here and here.

Why should a spammer harvester mail addresses by himself? There are so many viruses, trojans etc out there: The Army Of Lamers can do it for him.

Have a look at this.

Or maybe even the number of minutes that your unprotected Windows box can survive on the net?

• The Coroner's Toolkit (getting a bit dated)
  
• The Sleuth Kit
  
• Helix
  

Based merely on the contents of the free chapter I am appalled... to think that a BA from Rutgers, a Masters from Rutgers, and an MBA anticipated in May of 2005 from Columbia University... produces such drivel. I don't mean to insult Mr. Branigan, but the whole tone of his writing style smacks of back-woods self-aggrandizement more than that of a professional. It further solidifies my belief that a college degree, while looking great hanging on the wall in the den, is only useful when trolling for a job. (Required to pay for said degrees, etc.)

Either that, or he (and Addison Wesley) have assumed this book is written solely for the entertainment of a 6th grade reader. If you're looking for a book you can really sink your teeth into on a subject such as this, skip the anecdotes and go for the "Cybersecurity Operations Handbook" by John W. Rittinghouse and William M. Hancock. You can find it here. Or better yet, hop out to The SANS Institute and get yourself some tolp-quality training.

On a ten-scale, I'd have to give this one a 5 folks.

Man!! The last 5 years, the thing has been having a hell of a crisis

I think this shows how important it is for the community to keep non-govt supported efforts going. See for example the Internet Storm Center. Just compare the amount of useful information they put out compared with what you get for your tax dollars from places like US-CERT.

I wouldn't take SANS's list of browser security holes too seriously. It lists the most publicized holes in Mozilla rather than the most serious holes. (To get a list of the most serious holes, look the "critical severity, high risk" holes (marked in red) on mozilla.org's list.) SANS's list includes Mozilla XPInstall Dialog Box Security Issue, which was fixed a few months ago, but fails to mention that a fully-updated version of IE in SP2 is still vulnerable. Under the list, SANS claims that Firefox does not have automatic updates, which is false.

The entire 56 page report is available in pdf. Lets be sure to slashdot both their servers:
http://files.sans.org/top20.pdf (351KB)

It appears that a particularly crafted request may confuse ASP.Net and allow access to otherwise protected directories.

If a web server receives a request for a particular URL (e.g._http://server/somedirectory/filename), the 'somedirectory/filename' part has to be mapped to a particular file located on the server. This translation has been the source of many "directory traversal" bugs. The IIS unicode exploit is probably the most famous one.

After our original posting of this diary, a few users pointed to the following articles which provide more details then provided by Microsoft's advisory:
(Thanks to Chaouki & Daniel)

www.heise.de/security/news/meldung/51730 (german)
http://www.derkeiler.com/Mailing-Lists/NT-Bugtraq/ 2004-09/0068.html
blogs.devleap.com/rob/archive/2004/10/02/1803.aspx (italian)
www.k-otik.com/news/10052004.ASPNETFlaw.php (french)

It appears that by switching a '/' character in the URL with '\' or '%5C', the canonicalization routine will be confused. So if the URL: http://www.example.com/secure/file.apx is password protected, using the either of the following URLs will bypass the restriction: http://www.example.com/secure\file.apx http://www.example.com/secure%5Cfile.apx

In addition to the slash/back-slash confusion, one reader reports that inserting a space will bypass the URL restriction as well: http://www.example.com/%20/secure/file.apx (had no chance to validate this method so far)

URL Obfuscation

Handler and star SANS instructor Ed Skoudis compiled a comprehensive list of various URL obfuscation methods used in phishing schemes and spam. Some of these methods do not work with all browsers (e.g. the %01 issue in older Internet Explorer versions). In order to preserve the tricky details of some of these methods, we setup a page which includes just the URL methods without our usual header and footer:isc.sans.org/presentations/urlobfuscation.p hp (to view as source: isc.sans.org/presentations/urlobfuscation.txt ).

Jan Reilink wrote to point us to this page with more details about URL obfuscation and decoding:www.pc-help.org/obscure.htm .

It appears that a particularly crafted request may confuse ASP.Net and allow access to otherwise protected directories.

If a web server receives a request for a particular URL (e.g._http://server/somedirectory/filename), the 'somedirectory/filename' part has to be mapped to a particular file located on the server. This translation has been the source of many "directory traversal" bugs. The IIS unicode exploit is probably the most famous one.

After our original posting of this diary, a few users pointed to the following articles which provide more details then provided by Microsoft's advisory:
(Thanks to Chaouki & Daniel)

www.heise.de/security/news/meldung/51730 (german)
http://www.derkeiler.com/Mailing-Lists/NT-Bugtraq/ 2004-09/0068.html
blogs.devleap.com/rob/archive/2004/10/02/1803.aspx (italian)
www.k-otik.com/news/10052004.ASPNETFlaw.php (french)

It appears that by switching a '/' character in the URL with '\' or '%5C', the canonicalization routine will be confused. So if the URL: http://www.example.com/secure/file.apx is password protected, using the either of the following URLs will bypass the restriction: http://www.example.com/secure\file.apx http://www.example.com/secure%5Cfile.apx

In addition to the slash/back-slash confusion, one reader reports that inserting a space will bypass the URL restriction as well: http://www.example.com/%20/secure/file.apx (had no chance to validate this method so far)

URL Obfuscation

Handler and star SANS instructor Ed Skoudis compiled a comprehensive list of various URL obfuscation methods used in phishing schemes and spam. Some of these methods do not work with all browsers (e.g. the %01 issue in older Internet Explorer versions). In order to preserve the tricky details of some of these methods, we setup a page which includes just the URL methods without our usual header and footer:isc.sans.org/presentations/urlobfuscation.p hp (to view as source: isc.sans.org/presentations/urlobfuscation.txt ).

Jan Reilink wrote to point us to this page with more details about URL obfuscation and decoding:www.pc-help.org/obscure.htm .

Such disasters are often blamed on bad software, but the cause is rarely bad programming. As systems grow more complicated, failures instead have far less technical explanations: bad management, communication or training.

Really? So the buffer overflows, et al occur because people are not properly trained? I believe the buffer overflow is one of the more prevalent causes of vulnerabilities. The SANS Top 20 list text contains 24 instances of the word 'overflow'. Hmmm.

"In 90 percent of the cases, it's because the implementer did a bad job, training was bad, the whole project was poorly done," said Joshua Greenbaum, principal analyst at Enterprise Applications Consulting in Berkeley. "At which point, you have a real garbage in, garbage out problem."

Perhaps we need an additional step in here: garbage processing.