add client-outbound SOCKS support

[aus]

In some situations, it may be useful to utilize the chisel tunnel to access the internal network of the connected client. With the recent addition of reverse port forward remotes, we can simply start a SOCKS5 server on the client and remote port forward to it.

Example: (see comment below for latest syntax)

server

chisel server --reverse
2019/02/09 12:54:50 server: Reverse tunnelling enabled
2019/02/09 12:54:50 server: Fingerprint a7:39:0e:a3:78:87:9e:ba:12:12:b0:42:62:75:99:e3
2019/02/09 12:54:50 server: Listening on 0.0.0.0:8080...
2019/02/09 12:54:52 server: proxy#1:R:127.0.0.1:5000=>127.0.0.1:1081: Listening

client

chisel client --socks5 http://chisel-server:8080 R:127.0.0.1:5000:127.0.0.1:1081
2019/02/09 12:54:52 client: client-side SOCKS5 server enabled
2019/02/09 12:54:52 client: Connecting to ws://localhost:8080
2019/02/09 12:54:52 client: Fingerprint a7:39:0e:a3:78:87:9e:ba:12:12:b0:42:62:75:99:e3
2019/02/09 12:54:52 client: Connected (Latency 404.322µs)

[jpillora]

Thanks for the PR! I think a better user experience would be for it to work like the server's socks endpoint (e.g. socks, converts to localhost:1080:localhost:socks). So maybe R:socks should try to listen on the server's 1080 and forward through the clients internal socks handler (does not need to be listening, use ServeConn instead, see chisel server usage).

[aus]

Thanks for the feedback! I did originally consider something like you've suggested, but this was a quick solution to a problem. I'll consider implementing as you've suggested, but it may take some more time for me to understand the code (and more of golang).

I do prefer the R:socks design better. And if multiple clients connect, then the subsequent client can simply specify a free port to listen on (e.g. R:1081:socks).

[jpillora]

Awesome, no rush!

…

On Tue, 12 Feb 2019 at 2:00 pm aus ***@***.***> wrote: Thanks for the feedback! I did originally consider something like you've suggested, but this was a quick solution to a problem. I'll consider implementing as you've suggested, but it may take some more time for me to understand the code (and more of golang). I do prefer the R:socks design better. And if multiple clients connect, then the subsequent client can simply specify a free port to listen on (e.g. R:1081:socks). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#78 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmr87kj-ITyEPfXrmC-9AZxRLv2RdObks5vMi5RgaJpZM4ayr3B> .

[aus]

Reworked the code to support the R:socks remote syntax. Let me know what you think. Thanks!

[jpillora]

Sorry! You right in not needing the socks option. I should have clarified, an attacker can send any "ExtraData" and could crash the client with a nil pointer exception when the *socksServer is under. So the check would be for if socksServer == nil, then reject

…

On Mon, 25 Feb 2019 at 2:53 am aus ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In client/client.go <#78 (comment)>: > @@ -272,13 +286,19 @@ func (c *Client) Close() error { func (c *Client) connectStreams(chans <-chan ssh.NewChannel) { for ch := range chans { remote := string(ch.ExtraData()) + socks := remote == "socks" Thanks for the feedback! I guess I'm a bit confused. My understanding of the linked code block is that it essentially checks whether the --socks5 server option was enabled. Are you saying that the --socks5 server option should be checked and enabled in order for client socks remotes R:socks to work? Or are you saying there should be a client option of --socks5? Or neither? 😄 In my original commit, I had added the client option --socks5 to enable the client socks server. However after your suggestions, I've concluded that the client --socks5 option is redundant if the client is also specifying socks in the reverse remote R:socks. I understand the security reasoning for having the server --socks5 option. Since the client specifies the remote, the server should not allow clients with free network access unless explicitly enabled. But for client socks, I don't really see any risk where neither the server nor client would need to enable the --socks5 option. And the --reverse server option already permits or denies the server-side risk. Hopefully you can clarify things for me. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#78 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmr89lQpmh3r3yYG8tAfsvq8Z04-TAOks5vQrVlgaJpZM4ayr3B> .

[aus]

Thanks for the clarification. And good catch. I've add the nil check as suggested.

(if you got an email notification on my previous comment, please ignore. I realized I did not have the --socks5 server option on when testing.)

[aus]

For those following along at home, the current syntax works like this:

root@server:~$ chisel server --reverse
2019/02/28 20:13:06 server: Reverse tunnelling enabled
2019/02/28 20:13:06 server: Fingerprint 60:12:73:13:4a:ad:29:f5:51:f9:4c:05:62:e8:13:2c
2019/02/28 20:13:06 server: Listening on 0.0.0.0:8080...
2019/02/28 20:13:22 server: proxy#1:R:127.0.0.1:1080=>socks: Listening

root@client:~$ chisel client http://example.com:8080 R:socks
2019/02/28 20:13:22 client: Connecting to ws://example.com:8080
2019/02/28 20:13:22 client: Fingerprint 60:12:73:13:4a:ad:29:f5:51:f9:4c:05:62:e8:13:2c
2019/02/28 20:13:22 client: Connected (Latency 999.8µs)

From the chisel server (example.com), you can access a SOCKS server on 127.0.0.1:1080 that will originate from the client chisel (12.34.56.78).

root@server:~$ curl -x socks5h://localhost:1080 http://icanhazip.com
12.34.56.78

Then we see this in the server log:

2019/03/01 02:23:46 server: proxy#1:R:127.0.0.1:1080=>socks: conn#1: Open
2019/03/01 02:23:46 server: proxy#1:R:127.0.0.1:1080=>socks: conn#1: Close (sent 101B received 425B)

[CCob]

Very cool PR, works very well. Is there a way we can request the listen IP when setting up the reverse socks proxy. Seems to default to 127.0.0.1. I can see that the port can be changed, R:socks:5000 for example, but could we have something like R:socks:0.0.0.0:5000

[aus]

Yup. This is already supported. Another example:

From the server:

user@server:~$ chisel server --reverse
2019/12/20 09:22:12 server: Reverse tunnelling enabled
2019/12/20 09:22:12 server: Fingerprint cf:03:16:24:f2:a3:77:73:75:2e:dc:fd:9a:f8:36:05
2019/12/20 09:22:12 server: Listening on 0.0.0.0:8080...

From the client:

user@client:~$ chisel client http://example.com:8080 R:0.0.0.0:5000:socks
2019/12/20 09:23:10 client: Connecting to ws://example.com:8080
2019/12/20 09:23:10 client: Fingerprint 52:21:e8:07:f4:6a:81:7d:f3:57:c0:a8:6c:b8:c1:46
2019/12/20 09:23:10 client: Connected (Latency 539.3µs)

And now we can see our server log that we are listening on 0.0.0.0:5000:

2019/12/20 09:23:10 server: proxy#1:R:0.0.0.0:5000=>socks: Listening

You cannot change the listening port on the client side, because the client does not listen with a reverse socks.

[karimodm]

Why wasn't this merged yet? It is awesome!

[malcomvetter]

Why wasn't this merged yet? It is awesome!

^^^ This! ^^^

[aus]

I have a fork here with some other useful PRs merged. Check the red branch.

https://github.com/aus/chisel/tree/red

[jpillora]

Looks good! Will test tonight and get this merged :) Sorry guys

[jpillora]

Merged, can you guys please test

Thanks again @aus, I ended up merging your red branch since it was newer (And made a few minor edits here and there, see 68050d0)

[aus]

Awesome! Thanks for the merge @jpillora. And thanks for creating chisel! It's been really useful for me. I will test the release.

Also, there were a few additional minor changes in my branch that may not be reflected in the changelog:

• real IP logging
• exposing DialContext on chisel client

The DialContext is useful if you are creating a chisel client and need to modify the connect behavior. I created aus/proxyplease for this purpose. A DialContext from aus/proxyplease enables my chisel client to transparently authenticate against a Kerberos HTTP proxy via SSPI. proxyplease might be worth integrating into chisel as a dependency, but my code probably needs a bit more testing and cleanup.

[jpillora]

Oh yea I saw those in there, forgot to mention

Cool looks good - I'm doing some Go+kerberos stuff at work at the moment actually, will take a look

[malcomvetter]

Merged, can you guys please test

Thanks again @aus, I ended up merging your red branch since it was newer (And made a few minor edits here and there, see 68050d0)

Thanks!

[n4kre]

Hi @jpillora,

Oh yea I saw those in there, forgot to mention

Cool looks good - I'm doing some Go+kerberos stuff at work at the moment actually, will take a look

For chisel clients in Windows environments, the following two extra options would be awesome:

• automatic HTTP CONNECT proxy selection selection based on on system settings;
• authenticate against this proxy using SSPI (Negotiate / Kerberos / NTLM).

In addition to the work from @aus, maybe the Px (Python) implementation can help.

Essentially, it would be pretty cool to be able to enjoy the Px features within chisel directly. :)
A typical use case would be a red teaming operation where user credentials are unknown and one must go through a corporate proxy (unknown a priori: based on the Windows proxy settings / PAC) enforcing Kerberos or NTLM authentication.