Sockets are one of the most widely used inter-process communication primitives for clientserver applications due to a combination of the following factors. Sockets: Allow for bi-directional communication Allow processes to communicate across the network Are supported by most operating systems
What application developers need to be aware of is that attackers can target these same client-server applications by “hijacking” the server socket. Insecurely bound server sockets allow an attacker to bind his / her own socket on the same port, gaining control of the client connections and ultimately allowing the attacker to successfully steal sensitive application user information as well as launch denial of service attacks against the application server.
Sockets are identified by an IP address and port number. Port number can be in the range of 0 to 65535 whereas the IP address can be any of the underlying IP addresses associated with the system including the loopback address. The socket library also supports a wildcard IP address (INADDRY_ANY) that binds the socket to the specified port on all underlying IP addresses associated with the system.
This feature is extremely attractive (and hence widely used) from an application development point of view for the following reasons: The application developer does not need to write code to programmatically enumerate the underlying IP addresses (associated with the system) and then use one or more of them to bind the listening server socket.
In scenarios where the server has multiple network routable IP addresses, there is no additional overhead needed for exchanging the server’s listening IP address with the client. The client could use any one of the server’s network routable address and connect successfully to the server.
Figure 1:
 |
| Client-Server scenario |
However, it is possible to bind more than one socket to the same port. For instance, there could be an application server with a listening socket bound to INADDR_ANY:9000 and another malicious application server with its listening socket bound to 172.23.20.1101:9000. Note that both the applications are running on the same system, the only difference (as far as their listener sockets are concerned) is the binding of the listener socket. The legitimate application server has bound its listening socket to the wildcard IP address (INADDR_ANY) whereas the malicious application server has bound its listening socket to a specific IP address (172.23.20.110). When the client initiates a connection to the server, the client needs to use the routable address (172.23.20.110) and the port (9000) to connect to the server.
When the connection request reaches the server, it is the responsibility of the network stack on the server to forward the connection to the listener. Now there are two sockets listening on the same port (9000), and the network stack can forward the connection to only one of the listening sockets. Thus, the network stack needs to resolve this conflict and choose one of the two sockets to forward the connection to.
For this, the network stack inspects the incoming client request which is targeted for 172.23.20.110:9000. Based on this information, the network stack resolves in favor of the malicious application since it had bound its listening socket specifically on 172.23.20.110. Thus the malicious application gets the client connection and can communicate further with the client. This is referred to as “Socket Hijacking” i.e. the malicious application has successfully hijacked the legitimate application’s listener socket.
 |
| Socket Hijacking Scenario |
Impact of the vulnerability
Now that we understand and have discussed “socket hijacking” in detail, let’s turn our focus towards the impact of the socket hijacking vulnerability; or in other words what damage an attacker can perform by exploiting the socket hijacking vulnerability.
Hijacking the listener socket of the legitimate server essentially allows the attacker to setup a “spoof server” and hijack client connections without having to poison the client application in any way i.e. the client application still connects to the same IP address and the port as before however the attacker gets hold of the client connection. Having received the client connection, the attacker will then be in a position to potentially carry out much more damaging things such as:
- Information Disclosure – Depending on the transport security primitives and the actions the client and the server carry out based on the messages on the socket, the attacker could gain knowledge of sensitive data such as user credentials and even launch man-in-the-middle attacks.
- Denial of Service – The real server has no notification of the client connection and as such the attacker would be successful in causing denial of service to legitimate client(s).
Exploiting the vulnerability
So the next question is: “What does the attacker need in order to successfully exploit this vulnerability?” Following are the key considerations and the mitigating factors with respect to successful exploitation of this vulnerability.
- The attacker needs to have sufficient access to the system with the vulnerable application. The attacker does not need to have privileged access but needs to be able to execute his malicious application on the system.
- On Windows Server 2003 and later a default ACL is applied to all sockets and as such a limited rights user cannot hijack a socket opened by a different user unless the application explicitly used an insecure ACL while creating the socket.
- Ports 0-1023 are privileged ports on Windows XP SP2 & later. On these operating systems, the attacker would need administrator/super-user privileges to hijack sockets which are bound to ports in the range 0-1023.
Identifying the vulnerability
The vulnerability is introduced due to binding the socket insecurely. Let us look at the signature of insecure invocation of the “bind” API which is used to bind the socket to the underlying IP address and port. Since the socket is bound to wildcard IP Address (INADDR_ANY), this code snippet is susceptible to “socket hijacking” on Windows
SOCKET sListener = ::socket(AF_INET, SOCK_STREAM, 0);
//Check for error return code
sockaddr_in service; service.sin_family = AF_INET;
service.sin_addr.S_un.S_addr = ::htonl(INADDR_ANY);
service.sin_port = htons(9000);
int iRet = ::bind(sListener, (sockaddr*) &service, sizeof(service));
//Check for error return code
Remediating the vulnerability
Listener sockets must be bound securely by turning on the exclusive address use option (SO_EXCLUSIVEADDRUSE) on the socket so that an attacker cannot hijack the server socket. The following code snippet shows the secure binding of a listener socket:
SOCKET sListener = ::socket(AF_INET, SOCK_STREAM, 0);
//Check for error return code
sockaddr_in service;
service.sin_family = AF_INET;
service.sin_addr.S_un.S_addr = ::htonl(INADDR_ANY);
service.sin_port = htons(9000);
int iValLen = sizeof(BOOL);
BOOL bExclusiveUseAddr = TRUE;
int iFail = ::setsockopt(sTCPServer, SOL_SOCKET, SO_EXCLUSIVEADDRUSE, (char *)&bExclusiveUseAddr, iValLen);
//Check for error return code
int iRet = ::bind(sListener, (sockaddr*) &service, sizeof(service));
//Check for error return code
