Authentication flaw in microsoft SMB protocol Apr 19 2003 01:24PM
seclab ce aut ac ir (1 replies)

Detailed information:




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.

Vulnerable Systems


All versions of Windows including:

Windows XP (confirmed in the lab)

Windows 2000 server/professional (confirmed in the lab)

Windows .NET server (vulnerable but not confirmed)

Windows 9x/Me (vulnerable but not confirmed)



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


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. But, this way is only suitable for short and not complicated

passwords. Also, it?s 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 which 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


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


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



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




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




This vulnerability has been found and exploited by Salman Niksefat

(salman (at) linux.ce.aut.ac (dot) ir [email concealed]) and Haamed Gheibi (haamed (at) linux.ce.aut.ac (dot) ir [email concealed]),

B.S students of computer engineering at the university of Amirkabir,

computer department, network security lab.



We will publish the exploit code after a patch be created by software


[ reply ]
Re: Authentication flaw in microsoft SMB protocol Apr 19 2003 04:11PM
Dave Aitel (dave immunitysec com)


Privacy Statement
Copyright 2010, SecurityFocus