The Internet Systems Consortium [http://www.isc.org] has released an update for all supported BIND 9.x versions today (2009-Jan-07) containing a security patch to address a potential DNS poisoning vector.  *NOTE*  This patch release does not appear to be an emergency situation requiring immediate updates for all.  The bug appears to affect only specific BIND configurations where DNSSEC has been enabled.  Updates will be made if this is not the case.

If you or your organization is responsible for the operational management of any supported version of BIND 9.x and have explicitly enabled and utilize DNSSEC features, it may be time to consider planning your upgrade.  Patch deployment would appear most critical among recursive name resolvers.  The flaw affects all actively developed and supported versions prior to and resolved with today's release of BIND 9.3.6-P1, 9.4.3-P1, 9.5.0-P2(-W2), 9.5.1-P1 and 9.6.0-P1.  No detail is available to support the identification of affected versions within vendor specific package management systems that use back ported versioning.  In this latter case, check with your vendor.

From the BIND "RELEASE NOTES" relative to each specific supported version:

BIND 9.6.0-P1 is a SECURITY patch for BIND 9.6.0.  It addresses a bug in which return values from some OpenSSL functions were left unchecked, making it theoretically possible to spoof answers from some signed zones.

If you are not entirely certain whether your organization is running DNSSEC enabled configurations, especially among recursive resolver deployments which is where I understand would be the most logical target for most DNS cache poisoning attacks. <ashamed> I myself was not certain if my org was running DNSSEC. </ashamed>.   I leaned heavily on my buddy Mark, whom I consult on just about every DNS related issue.  It was he who helped me identify how others could remotely query for DNSSEC enablement among their BIND (recursive) server infrastructure.

How can I check my BIND deployments remotely?

The following validation steps make the assumption that you will use a recent version of the dig client for dnssec query support. 

• Command line followed by query results for a recursive DNSSEC enabled resolver configuration:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m ANY_OLD_DOMAIN.c0m +dnssec | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
; EDNS: version: 0, flags: do; udp: 4096   

       The presence of the 'do' flag above implies that DNSSEC is enabled in the recursive name server.

• Command line followed by query results for a recursive resolver without DNSSEC support:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m ANY_OLD_DOMAIN.c0m +dnssec | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
; EDNS: version: 0, flags:; udp: 4096

       An empty flag set, or a missing 'do' flag implies that DNSSEC is not supported by the resolver.
  
  No claims are made as to the actual security posture or to the presence of a potential poisoning vulnerability based on either result set.  Do your homework.

• Command line to query for BIND version:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m chaos txt version.bind.
.
;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.x.x"
.
     It is considered very "impolite" to version query name servers you do not manage.
  
  Please note that the version which is sent back from a resolver may not be valid as this is a commonly modified field.  Often found among version query results are smarmy remarks, insults and occasionally the preferred contact method for establishing communications with the appropriate operational management team.  If you receive a version string value and suspect that this value is indeed accurate, consider implementing some best practices in minimizing your attack surface while contemplating whether you really want to advertise versioning elements of your critical infrastructure.
  
  If you are feeling especially cheeky and do not mind enticing future attacks against your infrastructure, one might consider configuring in a version string of, hmmm.. say "8.2.3"?.  Ok, the latter is NOT a recommendation for anyone!

Refer to the ISC BIND Server software Index

https://www.isc.org/downloadables/11

William Salusky
Handler on Duty (heh-heh)

Recently we have been witnessing a rise of politically motivated hacking attacks by supporters both sides involved in military actions in Gaza. This was more or less expected, whenever two sides collide there will be people supporting them, even through various attacks on the Internet.

Over the weekend another site popped up, www.help-israel-win.com which is down at the moment. According to what was posted on the site, it was built by "a group of students who are tired of sitting around doing nothing".

The site asked visitors supporting Israel to download and install a file from the site (called PatriotInstaller.exe) that will help disrupt their enemy's efforts.

Obviously, the file looks suspicious so I went to analyze it. The installer is an NSIS packed .NET executable that has been subsequently obfuscated with Dotfuscator. Dotfuscator is a commercial .NET obfuscation tool that stops you from easily analyzing .NET executables since they can be normally (relatively) easy decompiled as they are stored as CIL (Common Language Infrastructure), something similar to Java bytecode.

So, no text strings are visible in the code and it can be (again, relatively) difficult to analyze, but not impossible, of course:



After playing with it a bit (and executing it in a safe environment), the program just connects to an IRC C&C server running on port 80. It has a hardcoded list of C&C servers containing IP addresses and DNS names, probably if some of those hardcoded IP addresses go down. Here's the list extracted and deobfuscated from the binary:

74.200.82.243:80
74.204.170.92:80
213.175.205.254:80
94.76.212.76:80
94.76.212.77:80
74.204.188.161:80
74.204.188.180:80
pati.dyndns.info
defend.is-a-geek.net
pati.servebeer.com
rocker.redirectme.net
pati.chickenkiller.com
takemeout.jumpingcrab.com

The embedded IRC client uses a well known (and legitimate) IRC client library SmartIrc4net. The binary has some commands embedded as well, which can help distinguish what it can do:

.connect
.close
.stop
.hide
.show
.update
.version
.refresh
.platform
.memory
.cpu
.login

Finally, it can retrieve a remote file and save it on the local machine as TmpUpdateFile.exe – certainly sounds fishy.
While at the moment it does not appear to do anything bad (it just connects to the IRC server and sites there – there also appeared to be around 1000 machines running this when I tested this) the owner can probably do whatever he wants with machines running this.

The uninstall process seems to be correct, as the author(s) say on the web page, but it is questionable if the binary will download something else.

In any case, and as always – be careful what you download and run on your machine, especially if it's coming from unknown sources that you can't trust.

--
Bojan