SOCKS5 proxy is broken in 7.1.1

RouterOS General
1

Does anyone have socks 5 working in 7.1.1?
I tried to move from SOCKS4 (that works for me) to SOCKS5 and it looks like it is BROKEN. Here is what I got from wireshark communication:

/ip/socks/set auth-method=password

C->S 05 02 00 02       // Client proposes auth methods: 0-none 2-user/pass
S->C 05 02             // Server chooses 2-user/pass auth method
C->S 05 02 64 6d 01 31 // Client provide credentials: user:dm pass:1
S->C 01 01             // What is it??? At least VER==05 is expected as first byte, 2nd is status 01=general SOCKS server failure

/ip/socks/set auth-method=none

C->S 05 01 00                                                        // Client proposes auth methods: 0-none
S->C 05 00                                                           // Server chooses 0-none auth method
C->S 05 01 00 03 1864656269616e2e696e662e74752d6472657364656e2e6465  // Client issues CONNECT(01) with DOMAINNAME(03) of 0x18 bytes
S->C 05 00 00 01 c0 a8 64 fa b2 6c                                   // Server reports success(00) with IPv4 192.168.100.250 port 0xb26c
C->S <270 bytes of GET request>
S->C ACK and 3ms later RST                                           // WHY???

The GET request is following:

GET /debian-cd/11.2.0/i386/iso-cd/debian-edu-11.2.0-i386-netinst.iso HTTP/1.0
User-Agent: Download Master
Accept: */*
Referer: http://debian.inf.tu-dresden.de/debian-cd/11.2.0/i386/iso-cd/
Pragma: no-cache
Cache-Control: no-cache
Host: debian.inf.tu-dresden.de

Through SOCKS4 I can download this file (of course after reconfiguration of Mikrotik and Download Master to use SOCKS4).

To decoding I used SOCKS5 specification SOCKS Protocol Version 5 and Username/Password Authentication for SOCKS V5

I have not tried more advanced SOCKS5 features like BIND, UDPASSOC and IPV6, this will be next step of investigation after CONNECT will start to work.

2

Given that the purpose of SOCKS 5 over 4 is to add more security features and that those features are implemented in a fundamentally insecure way, I believe it’s best to leave it in the dustbin of history along with FTP and Telnet.

The one secure use I can see is SOCKS over SSH (e.g. ssh -D in OpenSSH) where the SSH tunnel provides encryption and authentication. At that point, SOCKS 4 suffices.

If that doesn’t appeal, then dot1x is a better solution for determining if a given client is allowed to use network resources. That, or a VPN, such that only those clients that have connected to it get routed out to the protected resources.

3

It’s broken in 7.1.1, it was only fixed in 7.2rc.

And sure, it’s not secure, but that’s not the point. It’s just one piece of puzzle to be used together with something else, if you want security.

4

It is when we’re talking about SOCKS 4 versus SOCKS 5 and the need for username/password authentication. What’s the point asking for user credentials when they’re so easy to sniff or MITM away? There’s a reason the networking community has deprecated all cleartext protocols that carry passwords.

To be clear, I do still see value in SOCKS 4. I’ve used it over SSH myself. I just wouldn’t use it for anything where the proxy server is meant to provide security or other blocking functions. It’s as secure as one of those paper Japanese houses: it keeps out only those choosing to be civilized.

5

Given that the purpose of SOCKS 5 over 4 is to add more security features

Security is a very wide term and your interpretation of it is not fully cover it.

Also take a look here https://www.iana.org/assignments/socks-methods/socks-methods.xhtml



ARP is also insecure. Will you suggest Mikrotik authors to remove it?

Or may be you want to secure DHCP or just will through it away?

And also I hope you know that crls are often distributed using http, not https to avoid deadlock. Will you also suggest to ban it?

I am not interested in fixing the world or starting holy war.

I believe it’s best to leave it in the dustbin of history along with FTP and Telnet.

Thank you for your believes.

I just interested whether it is implemented according to spec and whether it works for someone?

6

It’s broken in 7.1.1, it was only fixed in 7.2rc

Thank you for confirmation. Will take a look whether I can check it.

7

@tangent: Again, it depends on how you use it. If you’d have SOCKS server accessible directly from internet, even with username/password, it’s bad idea. But in some controlled environment, where other users don’t have any chance to sniff between client and SOCKS server (which may be used to access some other networks), why not, there’s no problem there.

As for difference between 4 and 5, big one is support for hostnames instead of just numeric addresses (and yes, it was in 4a already), but mainly that 5 is current standard (if we don’t count that it’s quarter of century old), so anyone adding support for SOCKS will likely add only 5 and not long time dead 4.

8

I’ll bite: what definition for “security” includes sending usernames and passwords over a cleartext channel?


Also take a look here > https://www.iana.org/assignments/socks-methods/socks-methods.xhtml

Okay, I’m looking, but what am I looking at?

It can’t be the reference to GSSAPI, part of Kerberos, since you wouldn’t be speaking of usernames and passwords over SOCKS if you were.

Is it the non-RFC’d reference to SSL? That smacks of the STARTTLS hack, which keeps getting exploited.

Is it the mere fact that a well-respected standards body is involved? They were involved in FTP, Telnet, SMTP, POP, IMAP… All of which have been broken and now are best only run over a secure channel.



ARP is also insecure.

It’s funny that you mention it, since a) that’s one of the most effective ways to establish a MITM channel, with which you can break protocols like SOCKS5, and b) fixing ARP’s problems is one of the things you get from dot1x and a VPN, the solutions I recommended you look to instead.


Will you suggest Mikrotik authors to remove it?

It is entirely possible to operate a network without using SOCKS5. It is not possible to operate anything involving Ethernet+IP without ARP. So, no.


Or may be you want to secure DHCP or just will through it away?

That’s why RouterOS has “trusted” links: to prevent DHCP poisoning. Where that doesn’t suffice, you can use RouterOS’s firewalling features to block UDP port 68.


crls are often distributed using http, not https to avoid deadlock. Will you also suggest to ban it?

CRLs slow things down, so numerous alternative workarounds are in current use in preference to direct use of CRLs. Chrome ignores CRLs, for instance.


I am not interested in fixing the world or starting holy war.

Okay, but what are you interested in? You say you want username/password authentication, but then you defend the use of a technology that leaks those credentials to anyone with the wit to sniff or MITM them. What exactly are you protecting against? Do you believe the locks on little girls’ diaries constitute “security”?


I just interested whether it is implemented according to spec and whether it works for someone.

What I’m interested in is what threat model plaintext passwords on a SOCKS proxy effectively addresses.

9

@tangent

It is not possible to operate anything involving Ethernet+IP without ARP.
Really? And I had such experience. Have you heard about static ARP records? If no, please read. And go ahead “securing” your network by adding static ARPs and static IPs on all your hosts: now it’s possible and you are insecure!

It’s funny how you answer on your own questions making them trivia:

I’ll bite: what definition for “security” includes sending usernames and passwords over a cleartext channel?

They were involved in FTP, Telnet, SMTP, POP, IMAP… All of which have been broken and now are best only run over a secure channel.

So it’s possible to send passwords in cleartext in secure way? Will you bite your … self now?

BTW GMail POP/SMTP/IMAP also REQUIRES passwords to be in cleartext :slight_smile:, yes because they are secured by SSL.

Are you sure I do not use IPSec to connect to SOCKS?

As I got reply and I am not interesting feeding trolls, please don’t write more answers: I’ve got your point you are an expert in security and SOCKS is pure evil.

10

Sure, a measure about as secure as other forms of MAC address filtering. Which is to say, not secure.


it’s possible to send passwords in cleartext in secure way?

The point of the comment was to say that if you need to send a password, you shouldn’t send it in cleartext at all. Thus my suggestion for SOCKS over SSH in this case.

However, if you need to authenticate a user over plaintext, then yes, there are numerous ways to do that without sending a password. One was mentioned in the IANA document you mentioned, CHAP.

A more modern protocol with the same basic intent is SRP.


GMail POP/SMTP/IMAP also REQUIRES passwords to be in cleartext

Not in cleartext: over TLS, which is the default, for GSuite at least.

Even then, there’s an alternative to sending your actual password.

To use these features in support of your argument is to beg the question: why is SOCKS-over-TLS not a standard protocol? That I’d support.


they are secured by SSL

TLS, not SSL. SSL is broken and obsolete; Google doesn’t support it any more.


Are you sure I do not use IPSec to connect to SOCKS?

That’s not “in cleartext”. Also, if you’re running SOCKS over IPsec, I see no point to setting up user names and passwords. If you have the keys to connect via IPsec, you are ipso facto allowed to make SOCKS connections, so you might as well not send the user names and passwords at all. Authentication mode zero.


I am not interesting feeding trolls

If being concerned about security is “trolling”, I’ve got to wonder about your definitions on a lot of words.

11

@tangent

The question was: whether SOCKS5 is working in Mikrotik RouterOS 7.1.1.

And yes as a proper testing requires I tested both methods proposed by Mikrotik: auth-method=none and auth-method=password.

If Mikrotik proposes CHAP (that you fortunately noticed on 2nd reading) I would also test it.

The rest is trolling (“a troll is a person who posts … extraneous, or off-topic messages”, I hope this definition is clear enough for you), thus if you cannot add value to answer (WHETHER SOCKS5 WORKS, NOT HOW SECURE IT IS), please be kind and keep your opinion with you.

Thank you.

12

Well, it could make sense if SOCKS server had ACL based on usernames (so not the one in current RouterOS). Then IPSec would secure access to server and usernames would control what destinations the server can be used to access.

13

It’s broken in 7.1.1, it was only fixed in 7.2rc.
I tested 7.2rc3:

  • auth=none WORK
  • auth=password FAIL (with same stupid reply 01 01)
14

Works here with:

curl --head --socks5 tester:heslo@192.168.80.184:1080 https://forum.mikrotik.com

This is wrong:

C->S 05 02 64 6d 01 31 // Client provide credentials: user:dm pass:1

First byte should be 01:

15

First byte should be 01
You are right: checked other programs they work.
Thank you.

16

Broken again?
Using latest 7.15.2 CHR.
Socks5 works only several seconds after enabling it.
Firefox with socks5 configured opens sites fast at first. But after several seconds everything stops working and connections end by timeout.
I have several CHRs in two different locations and they have same behavior.

17

Tried to downgrade to 6.49 on one of CHRs and Socks5 works fine on v6.
But I need v7 for some other reasons, so I can’t use v6 for a long time.