SSRF DoS Relaying

In 2012, SSRF attacks turned from something exotic into a very real threat. The works of Alexander Polyakov, Vladimir Vorontsov and other researchers in this field have made almost a complete picture of the various mechanisms of such attacks and possible consequences. Nevertheless, since the development of this topic began relatively recently, there is still room for research.

This article will examine a small feature of the FTP protocol, thanks to which a vulnerability allowing an SSRF attack to be carried out can be used not only to obtain information or develop an attack vector, but also to relay DoS attacks to both external and internal systems (in including a system with a vulnerability that allows DoS-attack).

A bit of theory from the last century (you can skip)

')
One of the oldest DoS attacks is a SYN-flood. The attacker falls asleep to the attacked service with SYN packets, ignoring SYN / ACK responses. Thus, a host of half-open connections appear on the victim's host, and in the end the victim simply becomes unable to respond even to a completely normal and legitimate request to connect to the service. This method of attack is as old as the Internet itself, and the first official classification, authored by researchers at CERT, appeared as early as 1996. At the moment there are many ways to deal with SYN-flood, such as SYN-cookies, SYN-caching, filtering and adaptive processing on gateways. Using a half-open and not fully open connection in a SYN-flood is beneficial not only because the attacked side does not process the responses, but also because any IP address can be substituted into the sent SYN requests, thus hiding the attacker. Despite the fact that an attack with open connections may be more effective in terms of countering defenses, its correct implementation is much more difficult (if, of course, this is not a DDoS attack). With SSRF, you can emulate a DoS attack with open connections, and the attacker's IP address will be hidden from the victim in the same way.

The essence of the vulnerability

Suppose we have a host with a vulnerability that allows an SSRF attack to be performed. This could be a XXE injection, incorrect server redirect, CRLF splitting of the request, or the simplest file_get_contents () with a user parameter in PHP. By transferring a URI to the host, we can force it to execute the request using the appropriate protocol. The first thing that comes to mind regarding DoS relaying is to pass an HTTP-URI of the type dos:/ dos:/ . But, since the HTTP protocol implies that the client sends the request first, the connection between the relay host and the victim host will end quickly. The choice of other types of URIs is small: except for HTTP, only FTP is supported by almost all common technologies in which SSRF is possible. At first glance, passing a URI of type dos:/ dos:/ looks promising, as the FTP client waits for the server greeting (“220 FTP server ready”) before sending commands. But, unfortunately, most FTP clients have a short connection timeout and, without receiving a response from the server within 5–10 seconds, simply disconnect. Most server technologies with “support” for SSRF will break the connection with a potential victim if the connection within which an SSRF attack occurs is broken. Another obstacle - the client will instantly disconnect from the server if it receives a message that is different from the standard greeting. But all is not lost - FTP via SSRF can still be used as a DoS relay. To do this, just remember about some properties of the protocol.

When working with an FTP server, the client uses two connections - control and data transfer. The first is used to exchange commands and the results of their execution between the client and the server, the second - to directly transfer data (directory listings, text and binary files, etc.). FTP can operate in two modes - active or passive, the mode of setting up a data connection depends on the mode.

In active mode, the FTP client creates a control connection to the server and sends it its IP address and a new port number (different from the client port number of the control connection), and then waits until the server starts a connection to this address and port number.

In modern networks, passive mode is most often used, since the client may be behind NAT or a firewall. The client sends a passive mode command to the server and, having received its IP address and port number from the server, opens a data connection from an arbitrary client port to the received address and port. The most interesting feature of the passive mode is that, having connected to the data transfer channel of the server, the client will wait until the server starts transmitting the data. At the same time, the timeouts for this connection in most FTP clients are comparable to the timeouts for TCP connections. In the past, active mode on an FTP server was widely used to conduct “FTP BOUNCE” type scans and open connection DoS attacks. SSRF allows you to use an FTP client in passive mode for conducting open connection DoS attacks.

Since, in the data transfer connection mode, the client always waits for data from the server, the following attack pattern can be implemented (see Figure 1). The attacker raises somewhere the fake FTP server (0) , which will transmit the victim's address as the address of the data connection. In turn, in the SSRF attack as a URI, you can pass ftp/file.txt ftp/file.txt (1). Then the host subject to SSRF (host relay) connects to the fake FTP server and when trying to download a file (2), it will receive the address and port of the victim (3) as the address and port of the passive connection. The established connection (4) between the relay host and the victim will be active for at least 60 seconds (if the service on the victim host waits for some data from the client, for example, HTTP and LDAP behave this way). A nice addition: after establishing a data connection, the control connection between the fake FTP server and the host relay can be broken. The data connection will not be affected until the end of the data transfer or timeout. Thus, when an SSRF attack is repeatedly carried out by transferring the fake FTP server address to the host victim, a stream of connections will collapse, depending entirely on the power and settings of the host relay web server. At the same time, the load on the fake server is not that big. If our fake server can process 100 requests per second, by the end of the first minute of the attack, 6000 connections will be established with the victim host. In addition, the victim host will never know the attacker's IP address.

It remains to solve the last problem - how can we transfer the victim's address to the client (relay host)?


Attack pattern

In the current implementation of FTP, two commands PASV and EPSV are responsible for establishing the passive mode. Their main difference is in the answer.

PASV response syntax:
227 Entering Passive Mode (a1, a2, a3, a4, p1, p2)
(where a1-a4 are the IP address octets in decimal notation, and the port is represented as 256 * p1 + p2)
The syntax of the EPSV command is slightly different:
229 Entering Extended Passive Mode (||| p |)
(where p is the port)

Thus, the newer EPSV command (described in RFC 2428) prohibits specifying a different IP address to establish a data connection, and the default FTP client considers this address to be equal to the server address in the control connection. It would seem that the slim idea of ​​attack collapses. But in reality, if the server responds to the EPSV command “500 Command not implemented”, then the vast majority of implementations of FTP clients will offer the server a PASV command. And already in it you can send the address and port of the service of the victim. In most cases, immediately after receiving the RETR (receiving file) command from the FTP client, you can break the connection with the client.

Example: Suppose we have a JSP servlet that is vulnerable to XXE and is running Java 1.6.x. By sending it as an external ENTITY, for example, "<! ENTITY J SYSTEM" fakeftp.adress/file"> fakeftp.adress/file"> ", you can initiate its connection to fake FTP. That, in turn, for the implementation of the attack should produce the following series of responses to commands:

220 i58 FTP server ready.
USER anonymous
331 Guest login ok send your email address as password.

PASS Java1.6.0_01 @
230 Guest login ok, access restrictions apply.

TYPE I
200 Type set to I.

EPSV ALL (2)
500 Command not implemented, superfluous at this site. (2)

PASV (2)
227 Entering Passive Mode (vic, tim, server, ip, 0.80). (3)

RETR file
150 Opening BINARY mode data connection for 'file' (5,000,000 bytes).

[here the fake FTP server can easily break the connection]



How it looks in WireShark (192.168.200.138 - fake FTP, 192.168.200.128 - relay, 46.4.xx - victim)

A certain subtlety lies in the fact that fake FTP needs to respond with an error to any active mode commands (eg EPRT) and passive mode new formation commands (EPSV, EPSV ALL) so that the FTP client has no choice but to use the old PASV command. In addition, a sufficient file size must be specified in the response to the RETR command in order for the FTP client to continue to maintain the connection, even if the attacked service sends it some data.

Different web technologies exposed to SSRF attacks have different implementations of FTP clients. These implementations have their own properties, which impose a restriction on the use of DoS-relaying by means of the ftp:// URI scheme. Summary characteristics of customers are presented in the table:

Php	+ *
cURL	+
Java 1.6	+ *
Java 1.7	Data connections only with 127.0.0.1 and the address of the FTP server *
Lwp	+ *
ASP.Net	- **
Python	+

* In some cases, there is no need for a fake FTP server, since the controlling FTP connection in this technology has a timeout of 60 seconds, and if the attacked service does not return (incorrect) data, then you can send the URI to the SSRF attack directly /file.txt /file.txt . If you are lucky, the FTP connection will not be terminated, even if the connection within which the SSRF attack occurred is closed.

** In ASP.Net with XXE injection, a controlling FTP connection to a remote host is established with a timer of 60 seconds. In addition, when the connection is broken, within which the SSRF attack occurred, the connection with the victim remains. So, despite the lack of support for PASV, a direct attack with a relay is possible.

It's funny, but in Java 1.7 it is forbidden to establish a data connection with an address other than the address of the control connection, even if the PASV command is used. But, making this edit, the developers forgot about the local loop, that is, you can use this technique for DoS'a internal host services, even closed by a firewall. As a real example, one of the old versions of SAP Portal, in which an SSRF attack through XXE was possible, can be cited. The portal went down with = <50 requests with SSRF and relaying the attack on the local SAP web server using URIs with the FTP protocol.

Protection

How can you protect against this kind of attack? It is clear that if there are no vulnerabilities leading to SSRF, then this technique will not work. If we omit the reasoning on the fact that in the modern world there are no FTP servers left without RFC 2428 support and that all developers of FTP client libraries should mandately prohibit the use of the PASV command, then ... You can do it the way Oracle developers did in the latest version of Java - prohibit the establishment of data transfer connections with hosts other than the local loop and the FTP server itself. But, as you can see, this “edit” does not provide complete protection against DoS relaying. Some kind of guarantee against such attacks is provided only by strict filtering of outgoing connections, and in this case it can be done by the server administrator or the information security engineer, but this is a situation where the medication may be more dangerous than the disease. But it still doesn't save from relaying DoS through a local loop.

Nothing absolutely new or previously unrevealed has been described above, but it is doubly amusing to see how the discovery of new types of attacks on systems allows reviving long-forgotten techniques.

The author of the article is Digital Security analyst Alexander Bolshev, unfortunately, not yet having an account on Habré.
UPD: thanks Genome_X account appeared - meet the user dark_k3y !