[NT] Windows 2000 and Windows XP Terminal Services IP Spoofing
From: support@securiteam.comDate: 11/16/01
- Previous message: support@securiteam.com: "[UNIX] OpenSSH and S/Key Information Leakage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [NT] Windows 2000 and Windows XP Terminal Services IP Spoofing Message-Id: <20011116203339.2BEBD138BF@mail.der-keiler.de> Date: Fri, 16 Nov 2001 21:33:39 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Windows 2000 and Windows XP Terminal Services IP Spoofing
------------------------------------------------------------------------
SUMMARY
Terminal services suffer from 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 were 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>
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 that is based on the ITU T.120 protocol. The
problem is that rather than using he 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 between 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>
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 had 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/>
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 (
<http://www.snort.org> http://www.snort.org), TCPView (
<http://www.winternals.com> http://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
does not 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 could not 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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:sozni@xato.net> sozni.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] OpenSSH and S/Key Information Leakage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
