----------------------------------------------------------------------
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 (sozni@xato.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"
