search

fortra / impacket

Impacket is a collection of Python classes for working with network protocols.
https://www.coresecurity.com
Other
13.54k stars 3.58k forks source link

Using HTTPS socks doesn't seem to work #642

Open Pxmme opened 5 years ago

Pxmme commented 5 years ago

Hi guys!

Normal behaviour

I'm successfully relaying authentications to a specific webapp that uses HTTP NTLM Auth.

I asked ntlmrelayx.py to put them into socks right after successful relaying, so I could simply connect to these socks one by one and browse the webapp as the user I impersonnated.

Thing is though : when I type "socks" in order to see the socks I have got, I see this kind of result :

ntlmrelayx> socks Protocol Target Username AdminStatus Port

HTTPS webapp.mydomain.com DOMAIN/USER1 N/A 443
HTTPS webapp.mydomain.com DOMAIN/USER2 N/A 443
HTTPS webapp.mydomain.com DOMAIN/USER3 N/A 443
HTTPS webapp.mydomain.com DOMAIN/USER4 N/A 443

I'm happy, right? It seems to be working.

I then go to Burp in order to tell him to forward all requests to a specific socks. Let's say, I wanna use USER1 socks.

Finally, let's configure Firefox to go through Burp :

And we are all set, right? Now, whenever I browse https://webapp.mydomain.com/ on Firefox, it will go like this :

Firefox -> Burp -> Socks

And I shall have a session running as USER1!

Problem

Now comes the problem I'm facing : whenever I try to connect to webapps.mydomain.com, a debug log pops up on ntlmrelayx shell :

ntlmrelayx> [-] SOCKS: Don't have a relay for 10.10.10.5(443)

It seems like ntlmrelay isn't able to "know" webapps.mydomain.com's IP address.

I tried a few things : editing /etc/hosts, going through Proxychains instead of Burp, doing DNS lookup through the socks proxy... Nothing worked.

I'm kinda tapped out so I thought I'd ask here.

thanks in advance for reading and maybe helping me guys! 👍

Pxmme commented 5 years ago

Tried using SOCKS with SMB just now, in order to see if I'd encounter the same issue : I do.

SOCKS : Don't have a relay for XX.XX.XX.XX(445) SOCKS : Don't have a relay for XX.XX.XX.XX(139)

And again, typing "targets" shows me I have SOCKS opened but for some weird reason, it tries to match the IP with the domain name (which is the target) and then throws this error :(

Pxmme commented 5 years ago

Used the debug option to confirm what I was suspecting 👍

Protocol - Target - Username - AdminStatus - Port HTTPS webapp.mydomain.com MYDOMAIN/USER1 N/A 443
ntlmrelayx> ntlmrelayx> ntlmrelayx> [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443 [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443 [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443 [+] SOCKS: New Connection from 127.0.0.1(33172) [+] SOCKS: Target is 10.10.10.5(443) [-] SOCKS: Don't have a relay for 10.10.10.5(443) [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443 [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443 [+] KeepAlive Timer reached. Updating connections [+] Calling keepAlive() for MYDOMAIN/USER1@webapp.mydomain.com:443

Problem is indeed that target doesn't match what's asked. Script must do a strict check or something. There should be an "hidden alias" with the IP of the domain name if provided.

I tried using SMB & direct IP address instead of domain name : it works.

Problem in my case is that this webapp redirects traffic by looking at the targetted URL, i.e. if it sees "example.org" it'll redirect to app1, if it sees "example2.org" it'll redirect to app2... and accessing it by direct IP doesn't work.

Pxmme commented 5 years ago

Alrighty, I've been able to make progress. By going through proxychains, I've been able to briefly usurp a session before it all went to hell.

I can't access any session anymore, it tells me certificate isn't right.

Here's the debug log :

[+] SOCKS: New Connection from 127.0.0.1(37132) [+] SOCKS: Target is mywebsite.mydomain.fr(443) [+] Handler for port 443 found <class 'impacket.examples.ntlmrelayx.servers.socksplugins.https.HTTPSSocksRelay'> [+] Wrapping client connection in TLS/SSL [+] SOCKS: [('SSL routines', 'ssl3_read_bytes', 'tlsv1 alert unknown ca')] [+] SOCKS: Shutting down connection

Any idea would be gratefully welcome at this point.

Pxmme commented 5 years ago

It really is weird.

When I catch a hash and NTLMRelay opens a new socks, if I connect to it almost immediately and start browsing the webapp, then... Everything is fine. Really. It works.

But if I let it sit for a while before trying it... Connection isn't secure. I'm out.

Weird thing is, I still see the keepalive() debug messages going on... It's like they're not really sent.

Pxmme commented 5 years ago

Alright, I think yesterday was a glitch.

Today, I started the whole process over, got a socks, connected to it through Proxychains, and...

Secure Connection Failed

An error occurred during a connection to XXXXXXXXXXX. You have received an invalid certificate. Please contact the server administrator or email correspondent and give them the following information: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. Error code: SEC_ERROR_REUSED_ISSUER_AND_SERIAL

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

I can't seem to find a solution. Tried importing the cert impacket creates in /tmp into Firefox without success. I can't understand why it was almost working yesterday and now it's not.

Please, if you have any idea, feel free to answer to me here. I'm available. I'm active. I check this issue at least twice a day.

I'll keep looking on my side of things. Thanks!

asolino commented 5 years ago

Hey @Pxmme

Thanks for your detailed report. Indeed all of the socks functionality was tested / designed only with IPs in mind. Adding support for FQDN shouldn't be that hard. I'll take a look at it and will let you know.

Pxmme commented 5 years ago

Hey @asolino thanks for your answer. I "fixed" it by hardcoding a domain name value inside the code :') temporary fix anyway ;)

gui11aum3P3tiT commented 5 years ago

Hello,

I have the same problem. @Pxmme which file have you modified and where ? Can you send an example ?

Thank's

Pxmme commented 5 years ago

Hey @gui11aum3P3tiT,

I sure can help you out.

Edit this file : impacket-master/impacket/examples/ntlmrelayx/servers/socksserver.py

Find this bit of code inside : image

See the "AAAAAAAAAAAAAAA"s ? Replace them with the name of your target. For example, if your target is called "dc", replace both "AAAAAAAAAAAAAAAAAA"s with 'dc' :)

Finally, go back into the "impacket-master" folder and do :

python setup.py install

then it should be working fine! ;)

gui11aum3P3tiT commented 5 years ago

Thank's :)

gui11aum3P3tiT commented 5 years ago

I don't unterstand why burp and ntlmrelayx.py have the same port (1080) ?

Two services using the same port (1080) on the same address (127.0.0.1) is not possible... ?

Pxmme commented 5 years ago

I don't unterstand why burp and ntlmrelayx.py have the same port (1080) ?

Two services using the same port (1080) on the same address (127.0.0.1) is not possible... ?

What do you mean? Burp is using port 8080 by default...

gui11aum3P3tiT commented 5 years ago

Yes you configure socks proxy with 1080 port and firefox port with 1080 ports. But with chrome I tried and it's possible to use directly socks of ntlmrelayx without burp...

But I have a second problem, the certificate.... I have this error in chrome ERR_SSL_PROTOCOL_ERROR

But in the console of ntlmrelay I have this message : [*] HTTP: Proxying client session for DOMAIN/USER@web.apps.local(443)

The certificate of socks use by ntlmrelayx.py is export to /tmp/impacket.crt I tried to upload it in Chrome and Chrome say me file not valid...

So I think all it's good for socks server, but for chrome I don't know..

Do you have any idea for my problem ?

Thank's

gui11aum3P3tiT commented 5 years ago

Anyone have idea for fix problem about keepalive ?

Dfte commented 2 years ago

Hey! So I have been working with HTTPS socks and I stumbled upon this bug:

Exception occurred during processing of request from ('127.0.0.1', 53258) Traceback (most recent call last): File "/usr/lib/python3.9/socketserver.py", line 683, in process_request_thread self.finish_request(request, client_address) File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/examples/ntlmrelayx/servers/socksserver.py", line 286, in init socketserver.BaseRequestHandler.init(self, request, client_address, server) File "/usr/lib/python3.9/socketserver.py", line 747, in init self.handle() File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/examples/ntlmrelayx/servers/socksserver.py", line 310, in handle request = SOCKS5_REQUEST(data) File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/structure.py", line 87, in init self.fromString(data) File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/structure.py", line 152, in fromString self[field[0]] = self.unpack(field[1], data[:size], dataClassOrCode = dataClassOrCode, field = field[0]) File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/structure.py", line 326, in unpack return self.unpack(two[0],data) File "/usr/local/lib/python3.9/dist-packages/impacket-0.10.1.dev1-py3.9.egg/impacket/structure.py", line 385, in unpack return unpack(format, data)[0] struct.error: ('unpack requires a buffer of 1 bytes', "When unpacking field 'VER | B=5 | b''[:1]'")

It looks like the SOCKS server is having problems parsing the certificate files. Considering it is related to the HTTPS socks server I thought it would be better to merge both issues and try to fix them both ;)!

I'll take a look at this bug.

barrett092 commented 1 year ago

FYI - this bug still exists. Relaying fails if you have a text file of FQDN's versus IPs.