----------------------------------------------------------------------

                     Xato Network Security, Inc.
                             www.xato.net

                     Security Advisory XATO-112001-01
                           November 7, 2001

        WINDOWS 2000 AND XP TERMINAL SERVICES IP ADDRESS SPOOFING

----------------------------------------------------------------------

Systems Affected
================
Windows 2000 (All service pack levels)
Windows XP
Not Tested: Windows NT4 TS Edition

Overview
======== Terminal services has a bug that allows an attacker to cause
both the Terminal Services Manager and the Event Log to record a spoofed
IP address for Terminal Services connections. Although the operating
system itself is not fooled, if an administrator is not aware of the
issue he would not have reason to distrust the IP address reported by
Terminal Services. The vulnerability is exploited by sending traffic
through a router that uses Network Address Translation (NAT). Note that
although we have used the term "spoofing", this is not related to other
well-known TCP-IP spoofing techniques.

Details
=======
Although Terminal Services has no built-in logging facility, it is
possible to view the details of current connections by using the
Terminal Services Manager MMC utility. Among those details is the Client
Address, referring to the IP address of the connected client. IP
addresses are also recorded in the Windows Event Log although not all
logon/logoff events consistently record the IP address. An example of
what is recorded by the Terminal Services Manager can be seen here:
http://www.xato.net/reference/screen1.htm. Note that this information is
available as soon as a connection is established, even if the client has
not logged in.

The vulnerability lies in how Terminal Services gathers the client
connection information. When a Terminal Services connection is created,
the client provides certain information to the server to establish how
to configure the terminal. It also provides other information such as
the Client Name and the Client Address. This information is transferred
using the Remote Desktop Protocol which is based on the ITU T.120
protocol. The problem is that rather than using the TCP stack to
determine the client's IP address, Terminal Services just trusts
whatever address the client provides. However, sometimes a client behind
a router does not know its public IP address and only knows the internal
IP address that it has been assigned. When creating a Terminal Services
connection, the client provides the IP address it has been assigned
internally since it knows nothing about any public IP addresses.

For example, suppose a client is behind a router and is assigned the
internal IP address 192.168.0.10. Obviously, this is not a valid IP
address on the internet but the router provides Network Address
Translation to allow traffic from a public IP address to be translated
to an internal IP address. When that internal client connects to an
outside Terminal Server, it tells the server the only IP address it
knows: 192.168.0.10. Although there is a valid TCP-IP connection
betweeen the client and the server, Terminal Services records the
client's internal IP address.

So looking again at the example screen
(http://www.xato.net/reference/screen1.htm) we see that the server has a
connection from a client with the IP address 192.168.0.10. However, if
we use the command: netstat -n | find "3389" we will see the actual IP
address of the client.

With this knowledge, an attacker could change internal NAT'd IP
addresses (and perhaps adjust a few routes) to make it appear as if the
Terminal Services connection is coming from another IP address. The
impact is that one can use deception to conceal his IP address when used
in conjunction with other attacks. For example, suppose one was to use a
tool (coming soon) to brute-force passwords via Terminal Services. The
Terminal Services Manager would show active connections, but may not
show the correct IP address. Suppose also that one was able to discover
a valid password on that server. He could then connect to the server
using a spoofed IP address to conceal his true location. One could use
this vulnerability to hide their identity while using up available
client connections, locking out user accounts, flood the Event Log with
bad password attempts, or flood the server with Terminal Services
requests.

Another issue here is the fact that IP addresses logged by Terminal
Services and/or the Event Log are no longer credible and therefore
hardly useful as evidence in a court of law.

The bottom line: the IP address recorded by Terminal Services cannot be
trusted. One must rely on another logging mechanism to get the true
client IP address.

ALTERNATIVE LOGGING MECHANISMS

The most obvious method for logging Terminal Services connections is to
use your existing firewall or router. Another alternative is to log
connections right at the server by using a third-party tool. One such
tool we have found to be very effective is windump.exe available at
http://netgroup-serv.polito.it/windump/.

We recommend the following command:

C:\>windump "tcp dst port 3389 and tcp[13] & 3 !=0"

This filter logs all Terminal Services packets that have the SYN or FIN
flags set. With this, you can log every time a client connects to or
disconnects from Terminal Services (without logging the flood of packets
in-between):

windump: listening
on\Device\Packet_{940579A9-9084-4FBF-9022-7DA8A1199C49}

22:01:03.730687 ha.cker.org.3066 > ts.xato.net.3389: S
1887421511:1887421511(0)win 16384 <mss 1460,nop,nop,sackOK>

22:01:05.053519 ha.cker.org.3066 > ts.xato.net.3389: F
1887423387:1887423387(0)ack 2178985598 win 16730

22:01:06.112778 ha.cker.org.3067 > ts.xato.net.3389: S
1888029907:1888029907(0)win 16384 <mss 1460,nop,nop,sackOK>

22:01:06.755659 ha.cker.org.3067 > ts.xato.net.3389: F
1888031309:1888031309(0)ack 2179633419 win 16818

Other alternative logging methods are to use Snort (www.snort.org),
TCPView (www.winternals.com), or Microsoft's built-in Network Monitor.

CONCLUSION
==========

Microsoft was made aware of this issue in June of 2001. At that time
they decided that although it is an issue that needs fixing, it did not
warrant the immediate release of a hotfix. Microsoft was investigating
whether they should make this change in Windows 2000 Service Pack 3, but
it appears that it did not make it in the beta. They have not dismissed
the issue, it is just not seen as a serious threat requiring immediate
attention. Part of their reasoning is that if you are not logged in, it
doesn't matter what your IP address is, and if you are logged in, then
you have already been authenticated with your password.

Although we agree that this issue does not pose a direct threat to a
server's security and perhaps can wait to be fixed, we do feel that
administrators should certainly be aware that the IP address reported by
Terminal Services cannot be trusted. Because of the potential for
deception and the doubtful credibility of Terminal Services logging, we
recommend that a third-party logging mechanism be used to record
Terminal Services connections.

COMMENTARY
==========

In light of recent comments by Microsoft and others (see
http://www.microsoft.com/technet/columns/security/noarch.asp), we
thought it would be appropriate to end this paper by stating our own
opinion and policy on full disclosure, advisory exploitation, and
accountability.

We believe that the issue is not as simple as saying that full
disclosure is bad or that full disclosure is good. The attempt to take
sides is what sparks so much discussion whenever the topic is brought
up. We believe that although there are many benefits of full disclosure,
these benefits definitely come at a price.

The primary benefits of full disclosure are:

1. Administrators can Better Protect - Although many administrators
certainly do not care, a significant number do use public exploit
information, including actual exploit code, to better understand and
prevent attacks. Many use exploit details to build IDS signatures,
identify attacks in log files, and to prevent similar attacks in the
future.

2. Common Security Knowledge Increases - When details of an exploit are
made public, many (although not enough) software developers look at
their own code to see if they are making the same mistakes. By studying
the exploit as a community, we improve security across the board for
many current and future products.

3. Exploit Details Help Research - Many Microsoft hotfixes have been
updated and re-released more than once to address new variations of an
attack. Full exploit details allow other researchers to experiment with
variations of an attack and often turn up further vulnerabilities.
Furthermore, public exploit code can facilitate regression testing when
new patches are released. More than once a hotfix has been released that
reopened a previously patched hole. At Xato, we often run old exploit
code after installing new hotfixes or service packs just to make sure
these holes are still patched.

4. Public Exploits Level the Playing Field - The most common argument
for full disclosure is that by distributing exploit details and code,
admins are more knowleadgeable and therefore less likely to be a victim
of an obscure exploit.

5. Public Exploits Hold the Vendors Accountable - Many security
researchers have had the experience of reporting holes to software
developers only to watch them go to great lengths to avoid taking
responsibility for the vulnerability. Public disclosure always takes
care of that.

Nonetheless, these benefits of full disclosure come at a price:

1. Some irresponsible researches disclose vulnerabilities before a patch
is ready.

2. Some irresponsible researches disclose vulnerabilities on weekends,
increasing the exposure time before systems are patched.

3. Having detailed information requires little skill to exploit a
vulnerability; having actual exploit code requires even less skill. As a
result, more people are able to exploit the holes.

4. Because of the media hype surrounding any Microsoft vulnerabilities,
it is easy for a security researcher to exploit this hype for their own
gain. Even a lame Microsoft hole brings a lot of web hits.

Despite all these facts, the argument is often between those who release
exploit details and those who make software. However, most security
researchers are quite responsible when releasing exploit details and
Microsoft is usually good about acknowledging and fixing holes. Yet
despite all these best efforts, millions of systems were affected by the
rash of worms over the last few months. By now we should realize that it
really does not matter how much we disclose or how much Microsoft
patches if the system admins don't even bother with security. It took
something as extreme as a world-wide worm epidemic to get people to
install patches, often for the first time since Windows was installed on
their servers.

How is it that we have not yet held all these system admins accountable?
Why have they gotten away with being so irresponsible with security for
all this time? We are not just talking about overworked admins in small
IT shops, we are talking about some of the largest companies,
governments, and ISP's in the world. These are the people protecting our
personal and financial information. These are the people who boast of
their security because they have an SSL certificate installed. These
are the people who always ask for too much personal information on web
forms yet tell us they will keep it private. And their lack of security
affects us all.

Yet for some reason they have not been blamed. Instead the blame has
been bounced between security researchers and Microsoft. We worry that
all these public exploits are fostering script kiddies, but what are we
going to do about all the admin kiddies? Although we certainly do not
wish to condone worm propagation, we cannot deny the fact that the most
recent attacks made the internet world a bit more secure. If you haven't
already noticed, IIS servers are pretty secure nowadays.

Public exploit code, an outbreak of malicious worms based on that code,
script kiddies; they all hold system admins accountable for their
network security; something that so far they had failed to do on their
own.

It is therefore Xato's policy to continue to publish papers such as this
as the need arises. We feel that it addresses issues that the public
needs to be aware of. We believe that we are releasing this information
in a responsible manner. Although in this case Microsoft has not
provided a patch for this issue, we are providing workarounds and other
countermeasures to compensate. And yes, we do this because it brings
exposure for our business. But we don't seek that exposure at the
expense of Microsoft or others. We don't blame Microsoft for having
bugs in their software and we don't use advisories to add false hype to
an issue. Our goal is to increase Windows security in general and our
advisories help us achieve that goal.

ACKNOWLEDGEMENTS

Author: sozni (soznixato.net)

This document is located at:
http://www.xato.net/reference/xato-112001-01.txt

-------------------------------------------------------------------

THE INFORMATION PROVIDED IN THIS ADVISORY IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND. XATO, LLC. DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

COPYRIGHT (c) 2000 XATO, LLC. ALL RIGHTS RESERVED.

XATO SPECIALIZES IN SECURING IIS. THE IIS SECURITY INSIDER NEWSLETTER
IS NOW AVAILABLE AT WWW.IIS-INSIDER.COM

-------------------------------------------------------------------

Additional Keywords:
Terminal Services, Security, SP3, IP Spoofing, TS

"Ignore the man behind the curtain"

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]