search

the-useless-one / pywerview

A (partial) Python rewriting of PowerSploit's PowerView
GNU General Public License v3.0
890 stars 113 forks source link

List index out of range in invoke-userhunter function #18

Closed ThePirateWhoSmellsOfSunflowers closed 7 years ago

ThePirateWhoSmellsOfSunflowers commented 7 years ago

Wesh !

Sorry in advance for this issue, but you know, short assignement so few debug traces and I haven't try with powerview... Anyway, I have an error with the invoke-userhunter function, whatever the "hunted user" I try, pywerview crash :( The others functions are working fine, so I don't know.

$ ./pywerview.py invoke-userhunter -w domain.local -u myuser -p password --dc-ip 192.168.1.1 --username otheruser
Process UserHunterWorker-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/home/xxx/tools/pywerview/pywerview/worker/hunting.py", line 46, in run
    result = self._enumerate_sessions(target_computer)
  File "/home/xxx/tools/pywerview/pywerview/worker/hunting.py", line 60, in _enumerate_sessions
    self._lmhash, self._nthash) as net_requester:
  File "/home/xxx/tools/pywerview/pywerview/requester.py", line 228, in __enter__
    LDAPRequester.__enter__(self)
  File "/home/xxx/tools/pywerview/pywerview/requester.py", line 131, in __enter__
    self._create_ldap_connection()
  File "/home/xxx/tools/pywerview/pywerview/requester.py", line 85, in _create_ldap_connection
    self._lmhash, self._nthash)
  File "/usr/local/lib/python2.7/dist-packages/impacket/ldap/ldap.py", line 303, in login
    resp = self.sendReceive('bindRequest', bindRequest)[0]['protocolOp']
IndexError: list index out of range

:v: PEACE AND BANANA :banana:

the-useless-one commented 7 years ago

Hmm, that's weird... Did you try with the dev version of pywerview? The branch is available on GitHub. Are you running this on an assignment or is this a test on a local lab? [Edit] just pinging @asolino, to see if he knows what's up.

ThePirateWhoSmellsOfSunflowers commented 7 years ago

Nope, master branch only and I can't have access to the environment anymore. Tested against a Server 2012, with a tiny domain (<50 users and ~10 computers).

the-useless-one commented 7 years ago

Oh, I think I see what the problem is. The user hunting worker creates a NetRequester object to list sessions on the target computer.

By default, a NetRequester tries to connect to its target computer with LDAP and RPC (cause NetRequester's functionalities use both LDAP and RPC).

However, sometimes, a NetRequester object is just used to make RPC requests against "normal" servers (and not DC), like for listing sessions. In that case, connecting via LDAP to the server should fail, because the LDAP port is not open. This is what this try/except block is for.

But in your case, the LDAP port was open, so there was no socket.error raised, and the NetRequester tried to authenticate, which caused the exception. It seems that you had an LDAP server which was not a DC on your range.

Do you have an nmap scan of your range? I'm curious as to why there is a non-DC LDAP server on the network.

As for a fix, it should be pretty easy, I'll just have to except on IndexError, as well as socket.error. It's a shame that you don't have access to the environment anymore to test the fix :disappointed:

[Edit] It's also possible that the LDAP port was open, but that the service behind it was not an LDAP server, which would explain the error in the impacket call.

ThePirateWhoSmellsOfSunflowers commented 7 years ago

Ok, I think I get it. Within the small domain, there was a DC for another domain (mycompany.local), so the credentials (domain.local\myuser:password) are not valid for the LDAP connection on this DC. Mystery solved, Scooby Doo ending ! :dog2: