Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.
Impact version: 2.2.5
Test with PHP 7.2
The vulnerable code is located in the index function of the app/admin/c/PluginsController.php file, which fails to validate the webapi parameter, leading to a taint introduced from the $webapi variable into the tainted function curl_setopt, and after the curl_exec function is executed, it sends a request to the URL specified by the webapi parameter, eventually leading to an SSRF vulnerability. However, this vulnerability is triggered in two stages, first by passing the set parameter to reset the webapi section of the plugins_config field in sysconfig. The SSRF vulnerability is then triggered when the function is triggered again and without any parameter values.
Because the webapi parameters are not limited, it is also possible to use the server side to send requests, such as probing intranet web services. The corresponding PoC is as follows
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.
Impact version: 2.2.5
Test with PHP 7.2
The vulnerable code is located in the
indexfunction of theapp/admin/c/PluginsController.phpfile, which fails to validate the webapi parameter, leading to a taint introduced from the$webapivariable into the tainted functioncurl_setopt, and after thecurl_execfunction is executed, it sends a request to the URL specified by the webapi parameter, eventually leading to an SSRF vulnerability. However, this vulnerability is triggered in two stages, first by passing thesetparameter to reset thewebapisection of theplugins_configfield insysconfig. The SSRF vulnerability is then triggered when the function is triggered again and without any parameter values.Because the webapi parameters are not limited, it is also possible to use the server side to send requests, such as probing intranet web services. The corresponding PoC is as follows
PoC stage 1: the value of the webapi to set
You can also use the following curl command to verify the vulnerability as PoC Stage 1
PoC stage 2:
Eventually we can see the corresponding request in the apache server logs, which proves that the SSRF vulnerability can be triggered
The text was updated successfully, but these errors were encountered: