Greg Freeman has posted the second part of his "hacked PHP application" series (part one is here). In this new post he looks at the aftermath - what to do and check to do cleanup and fixes so it doesn't happen again.

This is a follow up post from my previous post "How to Tell if Your PHP Site has been Hacked or Compromised". This post will discuss some the first steps you should take when you have identified that your site has been compromised. The first sections discuss a few points that are not relevant to everyone, the later sections will discuss how to fix the exploits.

He includes a list of things to think about including:

• What kind of hosting you use (and if that contributed)
• The option to redirect all requests for your site to one page
• Get a list of all PHP files to locate something malicious
• Locating "non-PHP PHP files"
• Finding files with possible malicious content

He also includes a few suggestions to help prevent issues in the future - update to the latest versions, patch your code, rethinking your permissions and monitoring for potential repeat attacks.

According to this new post on DevShed, there have been several targeted attacks against U.S. bank websites (DDoS), some of which involved the compromise of PHP-based applications.

Once the hackers got into the PHP-based websites, they inserted toolkits to turn them into launch pads for their distributed denial-of-service attacks. Hackers then launched the attacks on banks by connecting directly to the compromised PHP-based websites and sending them commands, or took advantage of intermediate servers, proxies or scripts to make the websites do their bidding. InformationWeek lists three attack tools used by the hackers: KamiKaze, AMOS, and the "itsokaynoproblembro" toolkit, also known as Brobot.

Several major banks have been targeted including Bank of America, JP Morgan/Chase, HSBC and Well Fargo. The main problem was out-of-date software running on the site containing known security issues the attackers could exploit to install their own software.

If a hacker can break into a PHP-based website to use it as a staging area for an attack on a different website, they can also use that website to store stolen information. InformationWeek cited the example of the Eurograbber attack campaign, revealed earlier this month. The gang involved in that campaign stole $47 million from more than 30,000 corporate and private banking customers - and used PHP-based websites into which they hacked to store stolen information.

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

On PHP.net there's a quick security advisory for those that didn't see the news - the wiki.php.net machine was compromised but has been wiped and all accounts reset and requiring a password reset.

The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.

The issue was caused by a combination of a problem with the wiki software and a Linux root exploit. The Register has additional comments about the issue and outage.

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

Some of you might have heard about the hacking of the phpBB.com website earlier this week. Well, Stefan Esser has posted a bit more about the vulnerability in the PHPList software that lead to the problem.

A few days ago phpbb.com was hacked through a super-globals-overwrite vulnerability in PHPList that was used by an attacker for a local file inclusion exploit. Details about the whole attack, written down by someone who claims to be the attacker, can be read here.

Stefan talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.

From the GNUCitizen blog, there's a new post about a recent meeting (of the OWASP London Chapter) where several presentations were given on methods for exploiting PHP applications. The three talks given were:

• Rodrigo Marcos - hacking PHP sockets for fun and profit
• David Kierznowski - exploitation techniques using real world examples
• Colin Watson - talk about security badges

There's links to the slides for one the formal presentations, the exploitation techniques - two sets: the remote exploit examples and local exploit examples.

Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.

I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.

He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.

You can download the code here.

Gareth Heyes has an example of yet another way he's seen developers incorrectly handle incoming connections and the information inside. This time, he focuses on the remote IP coming from the client.

Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server.

He points out the difference between HTTP_X_FORWARDED_FOR and REMOTE_ADDR and how, despite them being the same almost all of the time, shouldn't be trusted since they could be spoofed. He even includes an example script showing how it could be done (and how a bit of Javascript can even be inserted).

The Ubuntu linux group has released an update for their PHP packages to help protect their users from issues like security bypass and remote exploits.

This fixes a weakness and some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users to bypass certain security restrictions and by malicious users to bypass certain security restrictions.

Packages can either be downloaded manually or via the linux distro's package manager. This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu.