NTLMv2 not supported

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Target a Windows Agent or Windows Network Share scan at a host that has 
configured the setting "Network Security: LAN Manager authentication level" to 
"Send NTLMv2 response only. Refuse LM & NTLM"

What is the expected output? What do you see instead?
I expect the scans to deploy properly, but they do not deploy at all.

What version of the product are you using? On what operating system?
0.5.1 - VM - with the default winexe utility

Please provide any additional information below.

I was doing some testing against my Windows 7 host and couldn't get my OpenDLP 
scans to deploy.  Once I changed the 'Send NTLMv2 response only. Refuse LM & 
NTLM' setting back to 'Send NTLM response only' both the Windows Network Share 
and the Windows Agent scans deployed just fine.

I have a feeling it might have something to do with the version of winexe that 
is distributed with OpenDLP.  It may not support NTLMv2.

I think the winexe version from Foofus or the version from 
https://code.google.com/p/passing-the-hash/ might support it.

When I get a chance, I will do some testing and update this issue (if nobody 
else beats me to it.)

Original issue reported on code.google.com by burnfrom...@gmail.com on 4 Apr 2013 at 1:46

[GoogleCodeExporter]

I've done some investigating and I have good news and bad news regarding NTLMv2 
support for OpenDLP.

Good News:

The winexe version from https://code.google.com/p/passing-the-hash/ will 
support NTLMv2.  (The version included with the 0.5.1 VM will not.)  

Using this version of winexe may require a code change within OpenDLP.  On some 
targets that I tested this version of winexe against, I have had to run winexe 
with the --uninstall switch first before being able to execute a command  ( 
winexe --user=user --password=pass --uninstall //10.1.1.10 ipconfig ) - so you 
need to run winexe once with the --uninstall switch and once to execute your 
command.  We may need to place extra winexe call this in the OpenDLP code 
anywhere winexe is called.  YMMV.

Overall, not too big of a deal, but that brings us to the bad news.

Bad News:

OpenDLP currently cannot connect to the targets over NTLMv2 with the 
Filesys::SmbClient library that it is currently using.  From a cursory review 
of the source code, it looks like this SmbClient library is used for Windows 
Network Share scans to read files and directories from the targets as well as 
used for the Windows Agent scans to upload the OpenDLP agent files to the 
targets.

I tried my best, but I was unable to determine if Filesys::SmbClient even 
supports NTLMv2.  If it does support NTLMv2, I am unsure of how to configure it 
to allow the use of NTLMv2.

I've attached a Perl script I used to try to determine NTLMv2 support for 
Filesys::SmbClient in case anyone wants it.  I modeled all of the commands 
after OpenDLP's use of the SmbClient library.

***
In order to support NTLMv2 for OpenDLP I think we have two things that need to 
be done:

1. Get support for NTLMv2 with Filesys::SmbClient or find a different library 
to use.  Then change all relevant code in OpenDLP.

2. Use the new winexe version within OpenDLP and add a few code changes to run 
winexe with the --uninstall switch before running other commands.

Original comment by burnfrom...@gmail.com on 4 Apr 2013 at 5:34

Attachments:

• testauth.pl

[GoogleCodeExporter]

To check if your targets require NLTMv2, do the following:*
1. Go to Local Security Policy
2. Select "Local Policies"
3. Select "Security Options"
4. View the setting for "Network security: LAN Manager authentication level"

During my testing, when that setting is set to "Send NTLMv2 response only.  
Refuse LM & NTLM" the OpenDLP scans will not work.

If possible, consider temporarily changing that to a lower setting while you 
perform the OpenDLP scans and then changing it back.

*Hosts on an AD domain may have this policy enforce via Group Policy, so you 
would need to check there instead.

Original comment by burnfrom...@gmail.com on 4 Apr 2013 at 6:16

[GoogleCodeExporter]

Here is a resolution that will allow OpenDLP to work with hosts that require 
NTLMv2 (and in my testing, is backwards compatible with hosts that don't 
require NTLMv2, all the way back to XP SP2):

1*. Create a file at /tmp/.smb/smb.conf that contains the line: client ntlmv2 
auth = yes
   To make this persistent, I added the following two lines to my /etc/rc.local file:
   mkdir /tmp/.smb
   echo "client ntlmv2 auth = yes" >> /tmp/.smb/smb.conf
2**. wget http://passing-the-hash.googlecode.com/files/winexePTH1.1.0-1.deb
3. sudo dpkg -i winexePTH1.1.0-1.deb
4. sudo mv /usr/bin/winexe /usr/bin/winexe.old
5. sudo cp /opt/pth/bin/winexe /usr/bin/
6***. Change /var/www/OpenDLP/web/bin/start-verify.html line 1159 to include 
the --reinstall switch.  It should read:
   my $command = "winexe --user=\'$domain\'\\$escape_user --password=$escape_pass --reinstall //$system \'\"$path\\OpenDLPz.exe\" x -y -o\"$path\"\'";
7. Start scanning hosts that require NTLMv2 :)

Alternatively, skip step 6 and just replace start-verify.html with the attached 
file.  Don't forget to chmod +x the new file.

* The Filesys::SmbClient library requires the smb.conf file to be located here. 
 The issue is detailed in a comment in the source code, line 252: 
http://cpansearch.perl.org/src/ALIAN/Filesys-SmbClient-3.2/SmbClient.pm
** the winexe version included with OpenDLP doesn't support NTLMv2
*** This winexe binary requires the --reinstall switch on some of the systems I 
tested, otherwise it won't execute. (I wish I could explain why, but I don't 
understand it.)  I did some testing and it doesn't appear to break anything 
with the legacy winexe binary and couldn't find any other negative side 
effects.  It appears the --reinstall switch only needs to be used when running 
the winexe command for the first time on each system, so I only included it in 
one place and not all calls to winexe.

Original comment by burnfrom...@gmail.com on 25 Nov 2013 at 5:18

Attachments:

• start-verify.html

[GoogleCodeExporter]

@burnfrom...  1000 thank you's for posting those six steps.  I had written off 
OpenDLP a year ago due to this exact issue.  Now, the SMB mount is working just 
fine.  

Also note:  The AD Account password can not be > 31 characters, of the Perl 
Filesys::smbclient (I think) will trigger a buffer overflow and die.

Original comment by slashdot...@gmail.com on 9 Jan 2014 at 9:23