Likes Likes:  0
Resultaten 1 tot 4 van de 4
Geen
  1. #1
    Authentication flaw in microsoft SMB protocol
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Authentication flaw in microsoft SMB protocol



    Detailed information:
    http://seclab.ce.aut.ac.ir/vreport.htm

    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.

    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)

    Detail
    ======
    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. 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
    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.

    Authors
    =======
    This vulnerability has been found and exploited by Salman Niksefat
    (salman@linux.ce.aut.ac.ir) and Haamed Gheibi (haamed@linux.ce.aut.ac.ir),
    B.S students of computer engineering at the university of Amirkabir,
    computer department, network security lab.

    Exploit
    =======
    We will publish the exploit code after a patch be created by software
    vendor.

  2. #2
    Dave Aitel
    Authentication flaw in microsoft SMB protocol
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Authentication flaw in microsoft SMB protocol

    Also found and demonstrated by dildog at defcon 3 years ago. So don't
    hold your breath waiting for that patch.

    Dave Aitel
    Immunity, Inc.
    http://www.immunitysec.com/

    On 19 Apr 2003 13:24:33 -0000
    <seclab@ce.aut.ac.ir> wrote:

    >
    >
    > Detailed information:
    > http://seclab.ce.aut.ac.ir/vreport.htm
    >
    > 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.
    >

    ....
    > Exploit
    > =======
    > We will publish the exploit code after a patch be created by software
    > vendor.


  3. #3
    Jesper Johansson
    Authentication flaw in microsoft SMB protocol
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Authentication flaw in microsoft SMB protocol

    > -----Original Message-----
    > From: Dave Aitel [mailto:dave@immunitysec.com]=20


    > Also found and demonstrated by dildog at defcon 3 years ago. So don't
    > hold your breath waiting for that patch.


    You don't need to wait. This is prevented with NTLM v.2, which shipped
    with Windows NT 4.0 SP4 in October 1998. This type of attack is also
    foiled with Kerberos, which is negotiated by default in a Windows 2000
    or higher domain.

    To learn more about using NTLM v.2 and Kerberos, refer to the Windows
    2000 Security Hardening Guide:
    http://www.microsoft.com/technet/sec...ws/Win2kHG.asp
    downloadable at:
    http://www.microsoft.com/downloads/d...5E83186-A2C8-=
    4
    C8F-A9D0-A0201F639A56&DisplayLang=3Den


    > > When
    > > a logged-in user requests for a network share on the=20

    > server, Windows=20
    > > automatically sends the encrypted hashed password of the logged-in=20
    > > username to the target SMB server before prompting for password.


    This is not correct. Window sends a response to a server challenge. The
    response is computed from the users hash and the challenge sent by the
    server. Passwords, hashed, encrypted or otherwise, are never sent on the
    wire during a connection.

    Jesper M. Johansson
    Security Program Manager
    Microsoft Corporation


  4. #4
    Chris Wysopal
    Authentication flaw in microsoft SMB protocol
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Authentication flaw in microsoft SMB protocol

    In-Reply-To: <909EB55D24CCFD4D9ABABD1B9BD610C609F5DBD8@red-msg-06.redmond.corp.microsoft.com>


    On Mon, 21 Apr 2003, Jesper Johansson wrote:

    >You don't need to wait. This is prevented with NTLM v.2, which shipped
    >with Windows NT 4.0 SP4 in October 1998. This type of attack is also
    >foiled with Kerberos, which is negotiated by default in a Windows 2000
    >or higher domain.


    While this is true, in this attack it is a malicious server which makes
    the client configuration important. Unless LMCompatabilitylevel has been
    changed from its default of 0 or "Send LM & NTLM responses" this attack
    should still work. This is the default on Windows 2000 and XP.

    >To learn more about using NTLM v.2 and Kerberos, refer to the Windows
    >2000 Security Hardening Guide:
    >http://www.microsoft.com/technet/sec...ws/Win2kHG.asp


    The hardening guide recommends setting this level as high as possible and
    there really isn't any reason these days not to run an NTLMv2 client
    environment by setting this LMCompatability level to 3 or higher. This
    can be done through a domain security policy. It is also a good idea to
    filter TCP ports 139 and 445 outbound on your perimeter if possible.

    -Chris

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics