Describe the bug
It seems that sometimes cme parses the OS information of a host queried via SMB as a bytes object instead of an utf-8 string. This results in a crash with a traceback (something along the lines of "'bytes' object does not have attribute 'find'", it has been a while since I encountered this one).
Maybe it would be cleaner/saner to patch impacket in order to make sure that self.conn.getServerOS() always returns a utf-8 string?
I don't know what the cleanest handling of this would be and therefore can't propose a pull request. In general this should be an easy fix.
To Reproduce
I have encountered this across multiple pentest assignments and I think it mostly happens if UNIX systems with open SMB shares are present on the network. However, I am not exactly sure what triggers the interpretation as bytes objects.
Expected behavior
Don't crash on real-world networks with legitimate SMB servers.
Crackmapexec info
OS: Kali
Version of CME: 5.2.3 (yes, that has been an older version, but the code parts listed above have not changed)
Describe the bug It seems that sometimes cme parses the OS information of a host queried via SMB as a bytes object instead of an utf-8 string. This results in a crash with a traceback (something along the lines of "'bytes' object does not have attribute 'find'", it has been a while since I encountered this one).
In one particular assignment I applied a temp fix by prepending https://github.com/Porchetta-Industries/CrackMapExec/blob/3172c5243d5d173382fb6bb56e4ced614cd946db/cme/protocols/smb.py#L609 with
This was a quick fix that worked and I implemented it in this place because it was right next to the line that popped up in the stack trace. However, this is defenitely not a clean place to check for this. Maybe the check should take place in https://github.com/Porchetta-Industries/CrackMapExec/blob/3172c5243d5d173382fb6bb56e4ced614cd946db/cme/protocols/smb.py#L268?
Maybe it would be cleaner/saner to patch impacket in order to make sure that
self.conn.getServerOS()
always returns a utf-8 string?I don't know what the cleanest handling of this would be and therefore can't propose a pull request. In general this should be an easy fix.
To Reproduce I have encountered this across multiple pentest assignments and I think it mostly happens if UNIX systems with open SMB shares are present on the network. However, I am not exactly sure what triggers the interpretation as bytes objects.
Expected behavior Don't crash on real-world networks with legitimate SMB servers.
Crackmapexec info