Results tagged “security”

UPDATE 2009-04-01:
The newest beta of the network exploration and auditing tool Nmap 4.85BETA5 is now available for download at nmap.org/download.
Among the changes, which you can read about in the CHANGELOG, is an especially handy tool which can detect machines compromised with the Conficker (aka Downadup aka Kido) worm.
The smb-check-vulns.nse script has been updated by its author Ron Bowes to include specially crafted RPC messages and detection of the giveaway response returned by a machine compromised with Conficker.

The script may be run like so:

nmap -PN -p139,445 -n -v --script smb-check-vulns --script-args safe=1 <targets>

which might result in:

Interesting ports on cleanhost1.com (192.168.0.1):
PORT    STATE SERVICE      REASON
139/tcp open  netbios-ssn  syn-ack
445/tcp open  microsoft-ds syn-ack

Host script results:
|  smb-check-vulns:
|  MS08-067: NOT RUN
|  Conficker: Likely CLEAN
|_ regsvc DoS: NOT RUN (add --script-args=unsafe=1 to run)

Interesting ports on compromised2.com (192.168.0.2):
PORT    STATE SERVICE      REASON
139/tcp open  netbios-ssn  syn-ack
445/tcp open  microsoft-ds syn-ack

Host script results:
|  smb-check-vulns:
|  MS08-067: NOT RUN
|  Conficker: Likely INFECTED
|_ regsvc DoS: NOT RUN (add --script-args=unsafe=1 to run)

The MS08-067 and regsvc DoS checks are not performed when "--script-args safe=1" is specified on the command line and is the reason you will see "NOT RUN" next to the host script result entry. The MS08-067 check can determine whether or not the KB958644 Microsoft patch for the vulnerability exploited by Conficker has been applied. There's a very good chance that this check will crash the server service of a vulnerable machine which is why it is suggested that the "safe" argument is specified to prevent the crash. If you want to perform the check, omit "--script-args safe=1" from the command.

If you have a large number of hosts in your organisation you may be interested in some great advice posted to the nmap-developers mailing list on tuning the nmap parameters to speed the process up, as well as a handy perl script for parsing nmap xml output files to extract the conficker results.

The background to this update to smb-check-vulns.nse may be interesting to anyone curious about or involved in defending against Conficker.

Researchers at Rheinische Friedrich-Wilhelms-Universitat Institute of Computer Science, Felix Leder and Tillmann Werner (members of the Honeynet Project) discovered that Conficker, which patches the MS08-067 vulnerability of its host, responds with a uncommon error codes when sent specific RPC messages.  These responses are entirely different than those that may be elicited from a normal patched or unpatched host thus making remote detection of compromised hosts a possibility.

Remote detection of Conficker is a real boon for system administrators who can now scan their entire organisation and determine whether there are compromised hosts on its networks without having to visit each machine or trawl through and decipher stacks of logs generated by network security monitoring tools.

Leder and Tillmann have posted details of their research into Conficker and methods/tools to detect and contain compromised hosts and there is a more detailed analysis available from them in a paper entitled "Containing Conficker - To Tame a Malware".

Several scanning tools are being or have already been updated to take advantage of this ability to remotely detect Conficker, as noted in a blog post by Dan Kaminsky, though it's worth noting that Nmap is free and will almost certainly get the job done quicker!

Experts Exchange is an IT community for knowledge sharing with a focus on solving technology problems.  Persons looking for answers ask questions and "experts" try and answer them.  Experts are awarded points for answering questions in knowledge "zones" and gain ranks in those zones when acquiring sufficient points:


When earning a rank an expert is given the opportunity to create an html badge which displays the rank, points and zone and which may be used as an email signature.  The badge is made up of various images hosted on the experts exchange website and because the urls for those images are predictable it is trivial for anyone to create a badge for a zone and rank to which they are not entitled:
 

	jah

Since nobody has yet attaied even half this amount of points, I'm the first person to be "awarded" the Legend rank.  Nice.

Now this isn't a major issue, but it could be used to mislead people as to a persons knowledge of a particular topic or in some cases a persons identity - it's possible for instance to create a badge for a ning.com social network for any user of that network and so impersonate them in communications.
It's not an easy task to prevent this sort of thing because these badges are just pieces of html which can be copied and placed anywhere and restricting the use of them to specific people isn't really feasible.

Never trust a badge then.

So let's say we want to poison the cache of nameserver.bigisp.com so that customers of a big ISP trying to find www.phatbank.com will be directed to a machine with an IP address of 69.118.105.108 instead of the real webserver at 83.97.102.101.

Let's assume we know the source IP address from which nameserver.bigisp.com will send recursive DNS queries and we know the IP address to which it will receive DNS queries from clients.

We start by sending DNS queries to nameserver.bigisp.com asking for A records for nonexist00000001.phatbank.com and then nonexist00000002.phatbank.com and then nonexist00000003.phatbank.com and so on.  These subdomains of phatbank.com don't exist and the responses that nameserver.bigisp.com receives from a legitimate nameserver will say so.

At the same time as we send the queries, we'll also send answers to nameserver.bigisp.com, but our answers won't say NXDOMAIN, they'll say 69.118.105.108.

Most of these answers will be ignored because the legitimate answer will arrive first, but if we send enough queries and corresponding answers, we hope that one of our answers will be accepted before the legitimate one.

When that happens, the cache is poisoned. nameserver.bigisp.com will cache a result that, for example, says nonexist00065535.phatbank.com is at 69.118.105.108. Cool. What's cooler is that each of our bogus answers contained what's known as an Additional Resource Record and each said:

 www.phatbank.com is at 69.118.105.108

This additional information is accepted and cached by nameserver.bigisp.com because it refers to the same domain as its query. Job Done.

This is my understanding of the exploit for the DNS flaw which Dan Kaminsky has helped to get fixed and which has possibly been independently rediscovered by Halvar Flake, then written about in a blog post by E. Copeland at Matasano which was quickly removed, but not before it had been noticed. On his website, Dan Kaminsky posted a quick response entitled 13 > 0 (which is, of course, true and we've had a good head-start because of it) in which he reiterated the, now more urgent, need for patches to be applied. The fact that the exploit now seems to be public may make people rethink their stance on this issue when talking about vulnerabilities in perspective. It's worth noting however, that nothing is yet confirmed with regard to this possible exploit and I think we'll not see Dan cave in to pressure to give-up the goods before Black Hat.

UPDATE: 2008-07-24T15:45 +0100 UTC

It seems the exploit could be even more devastating than this. A metasploit framework exploit module has been created for this flaw here:
http://metasploit.com/dev/trac/browser/framework3/trunk/modules/auxiliary/spoof/dns/bailiwicked_host.rb
"This exploit caches a single malicious host entry into the target nameserver by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached".

A further exploit module was later added:
http://metasploit.com/dev/trac/browser/framework3/trunk/modules/auxiliary/spoof/dns/bailiwicked_domain.rb
"This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS ['The hostname of the replacement DNS server'] option of this exploit".

As pointed out in some analysis by Nate McFeters and Billy Rios, this newer module allows a nameserver cache to be poisioned with a fake nameserver for an arbitrary domain meaning an attacker would control the cache entries for all subdomains of that domain.

Fast-flux Service Networks commonly are compromised hosts and part of a malicious botnet. They provide a layer of protection around a central "Mothership" to which they provide client access by blind proxy. The DNS records for the domain used to access the Mothership is a rapidly changing subset of the compromised hosts, or flux nodes, in the botnet which makes it more difficult to block client access to the Mothership which may be serving malicious content or Spamvertised services to clients. The weakest link is the Mothership - the central server providing the malicious content - which can be removed from the network thus removing the malicious content.

During April and May 2008, William Salusky, a security analyst and handler at the Internet Storm Center observed an interesting new behaviour of flux nodes communicating with the Mothership in a particular botnet. They were communicating with several machines which may have been Motherships or may have been a combination of motherships and other flux nodes. The flux nodes received, in response to an HTTP POST request, a file named COMMON.BIN which contained a list of all upstream machines to which client requests could be forwarded. This development, dubbed "Hydraflux" in a post to the ISC Handlers Diary, means that the malicious content can no longer be removed by "taking-out the Mothership" as there would be more than one. It seems reasonable to suppose that if one of the Motherships went offline, another might replace it (like the heads of Hydra) and that this might make it impossible to take-down such an operation as long as machines serving malicious content are added to the pool that constitutes the "Hydraship".

Interesting development indeed, but I think that this may work against, in the long run, those persons operating this type of network for criminal purposes. If it becomes harder to combat this type of network by informing Internet Service Providers's and other network administrative bodies about the Hydraships, the focus will switch to the new weakest link in the operation. I believe that the focus will turn to the domain registration process in order to find ways of reducing the numbers of domain names available to these operations which would make it easier to keep track and block access to those domains. We'll see. In the meantime, I'm looking forward to reading William's research on Hydraflux when it becomes available.
 

UPDATE: 2008-07-24T14:53 +0100 UTC

There is some more content on these observations available at:
http://handlers.dshield.org/wsalusky/ws/index.php/HydraFlux
 

On Tuesday, 8th July 2008, multiple vendors published patches for Domain Name System (DNS) software after a coordinated effort to mitigate a widespread vulnerability arising from deficiencies in the DNS protocol and common DNS implementations which would allow DNS cache poisoning attacks. Earlier this year Dan Kaminsky, a security researcher at IOActive, reported the flaw to authorities (including US CERT) after which engineers from multiple vendors around the world gathered, at the end of March 2008, to coordinate Tuesdays release of software fixes.

DNS, Background

The Domain Name System is critical for the normal operation of networked computers and the internet as a whole. DNS is a distributed system of Domain Name Servers which translate Domain Names (such as "google.com") to their respective numerical IP addresses (such as 72.14.207.99) and vice versa for DNS clients or resolvers. DNS allows the assignment of Domain Names to be independent of addressing by numerical IP address. At the top of the hierarchy are the Root Name Servers which provide authoritative answers to queries regarding Top Level Domains such as .com or .org. Each domain has one or more Authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to them. Resolving/Caching Name Servers will forward queries from clients (those requesting recursive queries) to other resolving and authoritative Name Servers, receive answers from these servers and pass the answer back to the clients from which it received queries. The vulnerability primarily affects Caching Name Servers which store, for a limited period of time, the answers received in response to their queries so that they can more readily provide those answers to clients and to avoid repeatedly requesting the same information. Cache poisoning involves providing bogus DNS information to a Caching Name Server so that queries to it from clients will be answered with the bogus DNS information. Cache poisoning allows a malicious party to control the destination of IP traffic from computers that request DNS information from a poisoned DNS cache.

The Flaws

In order to poison the DNS cache of a caching name server with bogus DNS information a malicious party must provide an acceptable answer to a query made by the name server before any other acceptable answer is received. To ensure that a bogus answer is acceptable requires that:

1. The question section (comprising QNAME, QCLASS and QTYPE) of the DNS answer is identical to that of a DNS query currently waiting for an answer.
2. The ID field of the DNS answer must be the same as that used in the DNS query.
3. The source IP address of the DNS answer must be the same address to which the DNS query was sent.
4. The answer must be directed to the same UDP port at the same IP address from which the DNS query was sent.

Cache poisoning is possible because the DNS protocol is used atop the User Datagram Protocol which is a connectionless transport protocol and because the above four requirements can be met by a malicious party.

1. To satisfy the first condition is trivial since if the malicious party wants to manipulate the IP address of any given domain, they need only issue a DNS query to the target caching name server for that domain. If the applicable information is not in the servers cache at that point, it will issue it's own query for that domain containing the same question section supplied by the malicious third party.
2. The DNS ID field is a 16 bit number which allows for 2^16 (65536) possible variations. Some DNS implementations increment this field sequentially and it may be possible for a malicious party to limit the number of likely ID numbers by predicting possible numbers or by issuing a query to the target name server for a domain to which the malicious party owns or has access to an authoritative name server and thus capturing the UDP traffic. Moreover, some DNS implementations do not use the entire 16 bits of the ID field. In any case, a malicious party would need to issue at most 65536 UDP packets containing the bogus DNS answer.
3. It is trivial to spoof the source address field in a UDP packet and a malicious party would need only to know the IP address of the name server to which the target name server sent a query.
4. Current DNS implementations often bind to a UDP port when the service starts and will continue to use that same port until shut down. It may be possible for a malicious party to determine, before a poisoning attack, the source UDP port and IP address used to send DNS queries by the target caching name server. This information could be obtained, for instance, at the same time as the value of the ID field in 2) above and is detailed in a paper by Gamma from August 1998.

A malicious party could also take advantage of the fact that it is possible to send multiple queries for the same information which increases the number of ID numbers for which there are outstanding queries thus making it more likely that one of the bogus replies would be accepted as an answer.

Not a new flaw

The inadequacy and predictability of the 16 bit ID field in the DNS header was noted in section 5.3 of a paper by Steven M. Bellovin (pdf) of AT&T Bell Laboratories in 1989, in a paper by Paul Vixie of Internet Software Consortium in 1995 and in a post by Daniel J. Bernstein to the mailing.unix.bind-users newsgroup in 2001. In his post, Daniel, a professor in the Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago, spelled out the increase in cost of a Normal Blind Attack against the Berkeley Internet Name Domain DNS implementation if the ID value and the source UDP port of a DNS query were selected using cryptographic randomisation.
The Fix

In order to mitigate the possibility of a successful exploit vendors have addressed three main flaws:

• Predictability of the ID field
• Multiple outstanding requests for the same information
• Fixed source port for generating queries

The US-CERT Vulnerability Note VU#800113 lists Systems known to be vulnerable, known to be invulnerable and those for which it is currently unknown as to whether vulnerable or not. There are links to more information about the products affected for each vendor. There is also information regarding what steps to take for users and administrators of affected products.

Dan Kaminsky's role

Earlier this year Dan Kaminsky evidently discovered (pdf) a reliable (and perhaps, much easier) method of exploiting the known flaws in popular DNS implementations and has been instrumental in bringing together the vendors who have reached consensus about how to mitigate the vulnerability and who have worked to implement the fixes before a coordinated public release. Dan's goal was to minimise the risk that malicious individuals could figure out the vulnerability before all vendors were able to offer updated versions of their DNS implementations. Dan intends to make public his exploit in a Black Hat USA 2008 Briefing on August 6th after which time the exploit will become public knowledge and it is highly likely that malicious individuals will have a field-day with any unpatched vulnerable systems very soon after (or possibly before, should the exploit is independently 'discovered').

On his website, Dan has made available a tool to allow visitors to check the susceptibility of the caching/resolving name server currently in use by the visitor. The tool displays the IP address of the resolver and the source port and ID field used in five queries to a seemingly random (and non-existent) subdomain of a domain registered for DoxPara Research. The tool reports whether the resolver used is vulnerable based, seemingly, on the source port and ID field. Yesterday, the resolver belonging to my Internet Service Provider made 5 queries from the same source port and with sequential ID's. Today, the resolver seems to have been patched:

Your name server, at X.X.X.113, appears to be safe.
Requests seen for 0c65d2323d50.toorrr.com:
X.X.X.113:3659 TXID=58111
X.X.X.113:18960 TXID=46569
X.X.X.113:47258 TXID=39068
X.X.X.113:64955 TXID=18071
X.X.X.113:17764 TXID=1625

What is really interesting about this story is the coordinated effort by security researchers and industry players to help make the internet a safer place for everyone. It only now requires users and administrators of name servers to follow the advice given and apply the patches. Early indications are that this is already happening. 

Manuel Caballero gave a presentation at the spring Microsoft BlueHat Security Briefings event on May 2nd entitled "A Resident in My Domain" and the abstract introduces the topic of a resident script that silently follows you while you surf, logs everything you type and even guesses your next move. Coupled with a global cross-domain weakness, this is apparently a nasty piece of work.

Giorgio Maone noted in his blog that news of the presentation is scarce and that Nate McFeters, who was at the briefings and saw the presentation, seems to have down-played the issue - he does, however, admit that "Resident scripts have put the fear of God into me" and continues "Whereas a normal cross-site scripting attack vector is[n't] great for the site that was cross-site scripted, it stopped there; it couldn't follow you off-domain. Manuel's can. Scary.". In response to Giorgio's request for more detail on the topic, Nate writes that "It's a horribly serious issue that affects all browsers and is currently not fixed on any of them I believe. So Manuel has been asked by the vendors to not release details at this time.".

Interestingly, Sirdarckcat throws some insight into the mix by working through some possibilities for the mechanisms involved based on the evidence available and some smart thinking and ends up with Proof of Concepts that are able to modify iframe locations in a different domain (and capture keystrokes - "guess your next move") in a window opened by open() and window.opener in IE6, 7 and 8.

I'm still trying to get my head around it, but it is definitely one to watch.
 
UPDATE: 2008-06-26T13:55 +0100 UTC

There's a short post on the McAfee Avert Labs Blog which mentions that they've seen an "article published in one of the Chinese Security E-zines, called pstzine, which talks about a new zero day Cross Domain Scripting flaw in IE6. This is still unpatched in IE6 as of now but IE7 and FireFox are not vulnerable to this."

pstzine can be found at http://webzine.ph4nt0m.org/ and the article is in Issue 0x02, Phile #0x04 of 0x0A (Google Translation to English).

If you're an IE 6 user try out a proof of concept adapted from the article. And then upgrade to the safer IE7 or better still get firefox.

It's worth noting that this particular flaw, whilst dangerous to IE6 users if used maliciously, is not the one that Manuel presented. That one affected "all browsers" - according to Nate McFeters who was at the presentation. I've still not read anything more about it and wait with baited breath...