2006-03-10 20:26:24 by: h4x0r
Windows 2000 and Windows XP Terminal Services IP Spoofing
PS:IT's COOL,来自:雨夜&罐头代码
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.
Credit:
The information has been provided by sozni.
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 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) 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/.
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), TCPView (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.
Comments Feed: http://www.4evil.org/feed.asp?q=comment&id=638
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.
Credit:
The information has been provided by sozni.
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 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) 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/.
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), TCPView (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.
Comments Feed: http://www.4evil.org/feed.asp?q=comment&id=638
There is no comment on this article.
