Adding CVE-2019-1166

[MrAle98]

Currently, ntlmrelayx.py will try to bypass MIC only exploiting CVE-2019-1040. In this article https://www.preempt.com/blog/active-directory-ntlm-attacks/ by preempt, it's detailed CVE-2019-1166 a.k.a "drop the mic 2". Here the code I added, will try to exploit CVE-2019-1166, by modifying the TargetInfo structure inside the NTLM_CHALLENGE message, by adding the ‘msvAvFlag’ field (variable avFlagsPair), and then will update the length of the structure. To be honest during the tests with wireshark i noticed that the field was correctly injected but the client didn't echo it back into the NTLM_AUTHENTICATE message, probably due to a patched windows version i was using. So i don't have a proof of the successful exploitation even if the packets exchanged seems to be compliant with the article. Anyway the modifications doesn't affect the correct exploitation of CVE-2019-1040. I'm just student, so i could have misunderstood some things, in that case, if you can, let me know what mistakes i've done, just to learn.

[asolino]

Thanks for the PR @MrAle98. We're in the process of tagging a new release but will definitely take a look at this and test it afrterwards.

[MrAle98]

Thanks for your reply. I found a tool that checks for CVE-2019-1166 at this link https://github.com/preempt/ntlm-scanner (i think created by who discovered mic related vulnerabilities). Here you can find a pull request issued by me (the only one). You can give it a look, maybe could be useful. In addition i gave a look at the documentation and this is what I found about how a client should behaves about inserting the MIC: In fact, seems that if you inject an MsvAvFlags with value 0x0 in the NTLM_CHALLENGE message, it's later set by the victim client with value 0x2. If you try to inject more then 1 MsvAvFlags with value 0x0, the client will set the first one with value 0x2 and will then echo back all of them in the NTLM_AUTHENTICATE message. Since the server, according to the article mentioned in the previous comment, will take into account only the first MsvAvFlags attribute, the one with value set to 0x2 by the client, the server will check the MIC and so the bypass fail. To summarize, the main problem is how to inject the FIRST MsvAvFlags attribute with the value 0x0 in the NTLM_CHALLENGE message, without this being changed by the client. Anyway, better if you tests everything i wrote, since anyway i can have made mistakes or misunderstood something. Sorry for the long comment. Good job!

[MrAle98]

Hey i think I finally found the way to exploit CVE-2019-1166 and successfully bypass MIC. It seems that by injecting an MsvAvFlags attribute with value 0x0 but with length 0x8, the server doesn't calculate the MIC. First attempt injecting MsvAvFlags field with length 0x4 and value 0x0:

Second attempt injecting MsvAvFlags field with length 0x8 and value 0x0:

Notice that in the second attempt the authentication is performed successfully. My modifications in fact inject the malicious attribute inside the NTLM_CHALLENGE message sent to the client.

[martingalloar]

Hey @MrAle98! Just wanted to let you know that we didn't forget about this, but I'm having some troubles trying to make this changes to work in my environment. I'm observing also some inconsistencies with https://github.com/preempt/ntlm-scanner (I think you also reported) and what seem to be vulnerable/non-vulnerable targets. In some cases the extra 4 bytes seem to make a target from a working scenario into dropping NTLM_CHALLENGE messages.

[MrAle98]

Hi @martingalloar! To be honest I find some issues when I try relaying from SMB to SMB. In addition both the victim client and victim server have to be vulnerable to CVE-2019-1166. A host patched to CVE-2019-1166 will probably drop NTLM messages that have the MsvAvFlags field with length 0x8, if the host is either the client or the server.

I tried right now with an older impacket version and this is what I got. I tried to simulate an attack leveraging resource-based constraint delegation and the spoolservice bug (printerbug.py)

Starting ntlmrelayx.py (in pycharm):

Forcing client to start NTLM authentication procedure on attacker host through printerbug:

NTLM messages relayed successfully to ldaps service and created new computer account with delegation rights on victim client:

Getting TGS to impersonate Administrator on victim client and getting access as SYSTEM:

Unfortunately from smb to smb seems not working. If you think that every domain controller vulnerable to CVE-2019-1166, will be also vulnerable to CVE-2020-1472 a.k.a zerologon, I don't know how much could be useful trying to implement this feature for the scenario I described. Let me know what you think. Sorry for this comment that looks like a blog post, I hope will be helpful :)