metasploit fails conecting to impacket smbserver about impacket HOT 6 CLOSED

Hey Bryan:

Thanks for the report.. I'll take a look it at.. 

Any specific MSF module you're using for testing this? ( I assume all of them 
uses the same SMB client library, but just in case..)

cheers,
beto

Okey.. I think it's fixed.. please verify...

I tested it with smb_login and smb_enumshares.

Actually metasploit, as you say,DOES send extended security in the neg packet 
but not on the session_setup one.. Against a Windows 7 MSF does send it in both 
packets. There must be something the in my negproto answer that confuses msf 
(or something i'm returning not compliant with the protocol).  

I haven't applied your fix tho.. main problem is you can't cast the data to 
SMBSessionSetupAndX_Extended_Parameters if you're not sure whether or not the 
client sent that. SMBSessionSetupAndX_Extended_Parameters and 
SMBSessionSetupAndX_Parameters have different sizes. That would break clients 
trying to connect with standard security, under some circumstances.

What I did is what [MS-SMB] recommends, which is still reading the Flags2 at 
this stage to decide whether it's extended security or not.

One important note tho.. smbServer still does NOT support NTLMv2 authentication 
using under standard security (this is what MSF does), it does under extended 
security although right now we're granting access to everybody. So if you think 
about checking usernames it won't work yet.  

thanks again for the report Bryan..

cheers,
beto

Forgot to say...

fixed in http://code.google.com/p/impacket/source/detail?r=710

Confirmed it has been fixed, thanks for the quick turnaround!

Great :)

Check http://code.google.com/p/impacket/source/detail?r=711, I found out what 
was wrong there too.. Now it's more compliant with [MS-SMB] and [MS-CIFS].

Cheers,
beto