search

pombreda / impacket

Automatically exported from code.google.com/p/impacket
Other
0 stars 0 forks source link

smbrelayx.py prob #35

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. from client do "dir \\ip_attack\c$"
2. on attack machine "smbrelayx.py -h ip_DC -e payload.exe"
3.

What is the expected output? What do you see instead?
should execute payload and return to the listener a shell from the DC but 
instead;
[*] HTTPD: Received connection from 192.168.246.205, attacking target 
192.168.246.207
[*] SMBD: Received connection from 192.168.246.205, attacking target 
192.168.246.207
[*] Authenticating against 192.168.246.207 as HACK\Administrator SUCCEED
[*] Requesting shares on 192.168.246.207.....
[!] Error requesting shares on 192.168.246.207, aborting.....
[!] Error performing the installation, cleaning up: SMB SessionError: class: 
ERRNT, code: STATUS_ACCESS_DENIED(Access is denied.)
[*] Service Installed.. CONNECT!
[*] Opening SVCManager on 192.168.246.207.....
[!] Error performing the uninstallation, cleaning up

What version of the product are you using? On what operating system?
AD domain 2008r2(with a share) with win7x64sp1 client all full updated
attack machine kalix64

Please provide any additional information below.
i can use psexec.py with or without hashes and get a shell with the same domain 
account Administrator.

Original issue reported on code.google.com by clip0c...@gmail.com on 10 Dec 2013 at 4:57

GoogleCodeExporter commented 9 years ago 
Hey.. 

a few questions/requests:

1) Can you send me a wireshark dump of that attack? Try to constrain just the 
hosts involved for better understanding
2) What payload.exe is?

From the output you sent me, looks like the authentication succeeded (the most 
important part) but there was a problem trying to request the shares on the 
other side.. which is kind of weird.. It says tho, that the service ended up 
installed .. but I'm assuming nothing happened on your side. The wireshark dump 
will help me a lot.

thanks for reporting this!
beto

Original comment by bet...@gmail.com on 10 Dec 2013 at 6:59

GoogleCodeExporter commented 9 years ago 
Hi

in attach the dump from wireshark, showing the browsing to \\ip_attack\admin$.

please keep in mind that the share is on the DC(246.207)the machines have no 
antivirus and that i did not change any GPO.

the payload.exe its a meterpreter_reverse that i have also tested on the DC and 
client by copy it manually to them and it works fine.

Thks for the help.
F.

Original comment by clip0c...@gmail.com on 11 Dec 2013 at 12:33

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey Mate:

Thanks for the dump. Just to clarify whether I'm right:

1) 192.168.246.205 is the victim machine, where you're browsing 
\\ip_attack\\admin$ from
2) 192.168.246.211 is the attacking machine, where you will forward 
192.168.246.205 credentials to the target host
1) 192.168.246.207 is the target host you want to relay the credentials to 

If i'm right with that.. take a look at packet 96.

The target machine is accepting the authentication BUT, it is signing SMB 
Packets. Then afterwards attacking machine wants to connect to 
\\192.168.246.207\ipc$ and it gets access denied ('cause the was no signature 
in the original packet).

Now.. it could be two things:
1) The server is enforcing signing (can you check the local security policies 
of the target machine?, LOCAL POLICIES->SECURITY OPTIONS->Microsoft network 
server: Digitally sign communications* and tell me the values you have?)
2) The SMB Relay module is not clearing the bit for signing, hence shooting 
himself in the foot. I gotta take a look at the code.. then I'll let you know.

thanks for the report!
beto

Original comment by bet...@gmail.com on 11 Dec 2013 at 4:47

GoogleCodeExporter commented 9 years ago 
Also check, at the victim machine, the policies for LOCAL POLICIES->SECURITY 
OPTIONS->Microsoft network client: Digitally sign communications*

Original comment by bet...@gmail.com on 11 Dec 2013 at 5:04

GoogleCodeExporter commented 9 years ago 
Take a look at packet 87, 192.168.246.207 is saying signatures are required :(

You can find that data, inside the packet, Negotiate Protocol Response -> 
Security Mode.

Most probably the domain is enforcing signing of smb packets. If so, this 
attack cannot be performed.

Please let me know if this is right.. otherwise we'll keep researching.

cheers
beto

Original comment by bet...@gmail.com on 11 Dec 2013 at 5:10

GoogleCodeExporter commented 9 years ago 
Hi beto,

you are 100% correct in all.

DC and Domain GPO forcing digital signing of smb packets. But client only siggn 
if server enforce!

So no work arrow this?

Thks.
F.

Original comment by clip0c...@gmail.com on 11 Dec 2013 at 6:19

GoogleCodeExporter commented 9 years ago 
Yep.. so the server will reject packets if they are not signed.. 

Read the smbrelayx.py comments at the beginning:
# The only way to stop this attack is to enforce on the server SPN checks and 
or signing.

So.. nope.. with those options on you cannot relay connections. 

Just in case, could you disable the server's configuration Microsoft network 
server: Digitally sign communications(always) and perform the attack against to 
see if it works?

thanks mate.
beto

Original comment by bet...@gmail.com on 11 Dec 2013 at 7:04

GoogleCodeExporter commented 9 years ago 
Yeap.. disabeling on the domain controler GPO the Microsoft network server: 
Digitally sign communications(always) allows the attack to work in perfection.

thks beto.

Original comment by clip0c...@gmail.com on 12 Dec 2013 at 12:50

GoogleCodeExporter commented 9 years ago 
Thanks for checking it out mate. 

I'm gonna add a warning message whenever the target server has signing required 
so the user knows before hand.

cheers
beto

PS: Stay tuned, I have some ideas that might workaround this limitation.. but I 
still gotta do some research ;)

Original comment by bet...@gmail.com on 12 Dec 2013 at 1:24