Hi folks! I want to share with you an issue about a configuration based vulnerability in probably many SOCKS installations. I did not find anything about this at www.socks.nec.com, Bugtraq archive or AltaVista engine, although the idea looks rather simple. In connections established via the SOCKS 4 protocol the client chooses the address of the target application server. Therefore NEC recommends to configure sockd to deny any connections to the internal network if used in conjunction with a firewall. But what if the client requests a connection to the loopback (127.0.0.1) address? It appears that the only protection of the socks server's loopback interface is on the CLIENT side! The socks client software connects 127.0.0.1 directly to the client's machine loopback interface. If someone changes the appropriate lines in the socks client code, then the client sends the request - strictly as directed by its /etc/socks.conf - to the socks server. sockd might permit this connection, if it has a rather liberal /etc/sockd.conf configuration. It will then connect to the requested TCP port on the socks server host's loopback interface. This allows for three typical exploit scenarios: 1) The client can circumvent IP filters that protect the firewall's services on the network interfaces. 2) The client can reach TCP services that are listening only on the loopback interface. 3) The client can circumvent IP address based authentication, because the accessed service only sees the loopback address with which sockd connected instead of the real client's address. In an experiment I tried to connect from a UNIX client on the internal network to port 6000 on a typically configured SOCKS 4 based UNIX firewall with IP filters and the X server running. The X server would not serve my connection request from my client machine due to strict host access based authentication settings and IP filter protection. But when I used X Windows over a manipulated socks client to connect to the socks server on the firewall and having it access port 6000 on 127.0.0.1, I succeed to take, e.g., a screendump from the firewall display. I think that this is not a bug in the socks software. It is just a weakness in typical configurations. Therefore I did not contact NEC before - everybody who gets to know about this problem can simply protect his socks server by adding a line to the beginning of /etc/sockd.conf: deny 0.0.0.0 0.0.0.0 127.0.0.0 255.0.0.0 I did not test SOCKS 5; I only suppose that this very problem still exists. Though I do not know if it is possible to do something bad via TCP on multicast addresses, it might be a good idea to block these to: deny 0.0.0.0 0.0.0.0 224.0.0.0 224.0.0.0 and maybe even the 0.0.0.0, 255.255.255.255, and external interface's broadcast addresses. Kind regards Gerhard Rieger
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:48 PDT