[NT] Authentication Flaw in Microsoft SMB Protocol Still Present After 3 Years
From: support@securiteam.com
Date: 04/20/03
- Previous message: support@securiteam.com: "[TOOL] VNCPwdump, VNC Password Decoder"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: 20 Apr 2003 16:59:34 +0200
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
In the US?
Contact Beyond Security at our new California office
housewarming rates on automated network vulnerability
scanning. We also welcome ISPs and other resellers!
Please contact us at: 323-882-8286 or ussales@beyondsecurity.com
- - - - - - - - -
Authentication Flaw in Microsoft SMB Protocol Still Present After 3 Years
------------------------------------------------------------------------
SUMMARY
Microsoft uses SMB Protocol for "File and Printer sharing service" in all
versions of Windows. Upon accessing a network resource, NTLM
Authentication is used to authenticate the client on the server. When a
logged-in user requests for a network share on the server, Windows
automatically sends the encrypted hashed password of the logged-in
username to the target SMB server before prompting for password. Although
the hashed password is not sent in plaintext format, and it is encrypted
by the server challenge, a malicious SMB Server could use this information
to authenticate on the client machine and in many cases, gain full control
over the shared objects of the client such as C$, etc.
This vulnerability was first reported by dildog at Defcon about 3 years
ago.
DETAILS
SMB, which stands for Server Message Block, is a protocol for sharing
files, printers, serial ports, and communications abstractions such as
named pipes and mail slots between computers. Microsoft uses this Protocol
along with NTLM Authentication protocol to provide a so-called "User-level
file and printer sharing" service in various versions of Windows.
When a logged-in user tries to connect to a remote machine network shares,
for example \\server\myshare, windows automatically sends the login
information of the logged-in user to the SMB server before asking any
username or password from the user. At this step, if the authentication
fails, Windows pops up a window and asks for a username and password.
The "login information", which is sent to the SMB server, contains neither
the plaintext format of the password, nor the hashed password, which is
stored on the SAM. In fact, the client encrypts the hashed password of the
user by the challenge it receives from the server and then sends this data
to the server. This data is called the NT/LM-Response. Server uses the
locally stored hashed password and uses same way to encrypt the hashed
password. If the result is equal to the Response sent by the client, then
the authentication is successful. This is the way NTLM authentication
works.
It is obvious that sniffing the Network and extracting the Challenge and
the NT-Response could not help us to find the plaintext passwords. Some
tools such as L0phtCrack use a brute-force attack to find the plaintext
password. Nevertheless, this way is only suitable for short and not
complicated passwords. In addition, it is a time-consuming procedure even
for short passwords.
As mentioned earlier, windows by default sends the NT/LM-Response of the
logged-in username to the SMB server before asking for any
username/password. At the first glance, it does not arise any security
risk, but by using a slightly tricky method, a malicious SMB server could
use this information to authenticate on the client machine.
The following procedure illustrates the way an Attacking Server uses to
gain access to a Victim Client. Although in this procedure the attack
starts by the client request for a network share, it is possible to force
the client to initiate this connection. As an example, by sending an HTML
email that contains an object with the SRC attribute pointed to a resource
on the server, the victim machine will automatically initiates the
procedure. This procedure contains 10 steps:
1. The client tries to connect to the Server. It sends a request to the
attacking SMB server.
2. Attacking SMB server receives this request, but it does not send its
own generated challenge to the client, instead it sends a request for the
attacking client.
3. The attacking SMB client sends a request to the victim SMB server.
4. The victim SMB server sends a challenge to the attacking SMB client.
5. Attacking SMB client sends this challenge to the Attacking SMB server,
and it sends it back to the victim client.
6. The victim client receives the challenge. It encrypts the password,
using the received challenge and sends it back to the Attacking Server.
7. The Attacking server sends this response to the Attacking client.
8. The attacking client sends the received response back to the victim
server.
9. The victim server receives the response.
10. A successful authentication occurs on the victim. At this moment, the
Attacking client has control over the victim machine.
The subtle idea behind this procedure is to request a challenge from the
victim server and send it back to victim client whenever the victim
requests a connection. By this way, the attacking machine could gain the
NT/LM response of a specified user, and it sends it back to the victim to
authenticate on victim machine.
Although this procedure is a bit complicated and exploitation requires
full knowledge about the NTLM and SMB protocols, Open-Source
implementations of SMB protocol make exploitation much easier. (Thanks to
Samba).
Points
1. The attacking machine gains a level of access as equal as the logged-in
user privileges on the victim machine.
2. The exploitation will fail, if the victim SMB ports (139/445) are
closed, or the victim is behind a firewall.
3. This vulnerability is not limited to 'File sharing service' and is most
probably exploitable in various RPC services, which use NT/LM
authentication.
Solution:
The best way to fix this vulnerability is that the SMB client refuses the
challenges (nonce) which are equal to challenges recently sent by SMB
server.
ADDITIONAL INFORMATION
The information has been provided by <mailto:salman@linux.ce.aut.ac.ir>
Salman Niksefat and <mailto:haamed@linux.ce.aut.ac.ir> Haamed Gheibi.
========================================
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: "[TOOL] VNCPwdump, VNC Password Decoder"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
