Close to two years ago, a serious vulnerability in PHP was accidentally disclosed after it was discovered months prior during a hacking contest. A patch was released in relatively short order, and one would assume that given PHP’s prevalence as a web development framework, the fix would have been applied just as quickly.
But given the discovery last October of a new set of exploits for CVE-2012-1823, that assumption may not be correct.
Researchers at Imperva have been watching since Oct. 29 attacks exploiting the PHP bug. Attackers were using the new exploit to deliver arbitrary code to websites running PHP 5.4.x, 5.3.x before 5.4.2 or 5.3.12; those vulnerable versions account for about 16 percent of the sites on the web according to director of security research Barry Shteiman.
The new exploits were dangerous in that they allowed hackers to abuse an old vulnerability to not only run arbitrary code, but also adapt techniques found in botnets and crimeware kits to inject malware, steal credentials or system data from the server, or move laterally within the data center.
“Not only are we seeing a vulnerability used after it was released so long ago, but what we’re seeing is attackers and professional hackers understanding what vendors understand—people just don’t patch,” Shteiman said. “They can’t or won’t or are not minded to fix these problems.”
PHP is found on nearly 82 percent of websites today; these attacks target sites where PHP is running with CGI as an option, creating a condition that allows for code execution from the outside. Shteiman said the vulnerability affects a built-in mechanism in PHP that protects itself from exposing files and commands. A configuration flaw allows hackers to first disable the security mechanism, which in turn allows a hacker to run remote code or arbitrarily inject code.
“With the new exploit, it’s the same relative technique, but what we’ve seen is a lot of automation,” Shteiman said. “The tool that attacked these systems is running an interesting subset of dictionaries that requires an attacker know where PHP is installed on the server. We’ve seen attackers trying different paths to see which backend contains the [PHP] executable.”
The big-picture problem is the number of PHP websites still running vulnerable code despite the availability of a patch for close to two years now.
“PHP is installed as an interpreter,” Shteiman said. “Replacing the existing instance of PHP with a new one means downtime. Sometimes you may have to change applications because some things that are now deprecated may require application changes. For that reason, sometimes organizations don’t patch or go a different route. They might use a new framework instead.”
Original reports on the vulnerability triggered advisories from a number of organizations, including US-CERT. The bug is a relatively simple one; researchers found that when they passed a specific query string that contained the -s command to PHP in a CGI setup, PHP would interpret the -s as the command line argument and result in the disclosure of the source code for the application. They extended their testing and found they could pass whatever command-line arguments they wanted to the PHP binary.
“You’d think these bugs would be long forgotten, but it isn’t so; they’re like the undead. Vulnerabilities never die,” Shteiman said. “They don’t die and we realize if we see this executed by botnets trying to onboard servers and by crimeware kits being sold, that means attackers understand they can rely on old problems because people won’t fix them and attackers don’t have to work too hard.”
But given the discovery last October of a new set of exploits for CVE-2012-1823, that assumption may not be correct.
Researchers at Imperva have been watching since Oct. 29 attacks exploiting the PHP bug. Attackers were using the new exploit to deliver arbitrary code to websites running PHP 5.4.x, 5.3.x before 5.4.2 or 5.3.12; those vulnerable versions account for about 16 percent of the sites on the web according to director of security research Barry Shteiman.
The new exploits were dangerous in that they allowed hackers to abuse an old vulnerability to not only run arbitrary code, but also adapt techniques found in botnets and crimeware kits to inject malware, steal credentials or system data from the server, or move laterally within the data center.
“Not only are we seeing a vulnerability used after it was released so long ago, but what we’re seeing is attackers and professional hackers understanding what vendors understand—people just don’t patch,” Shteiman said. “They can’t or won’t or are not minded to fix these problems.”
PHP is found on nearly 82 percent of websites today; these attacks target sites where PHP is running with CGI as an option, creating a condition that allows for code execution from the outside. Shteiman said the vulnerability affects a built-in mechanism in PHP that protects itself from exposing files and commands. A configuration flaw allows hackers to first disable the security mechanism, which in turn allows a hacker to run remote code or arbitrarily inject code.
“With the new exploit, it’s the same relative technique, but what we’ve seen is a lot of automation,” Shteiman said. “The tool that attacked these systems is running an interesting subset of dictionaries that requires an attacker know where PHP is installed on the server. We’ve seen attackers trying different paths to see which backend contains the [PHP] executable.”
The big-picture problem is the number of PHP websites still running vulnerable code despite the availability of a patch for close to two years now.
“PHP is installed as an interpreter,” Shteiman said. “Replacing the existing instance of PHP with a new one means downtime. Sometimes you may have to change applications because some things that are now deprecated may require application changes. For that reason, sometimes organizations don’t patch or go a different route. They might use a new framework instead.”
Original reports on the vulnerability triggered advisories from a number of organizations, including US-CERT. The bug is a relatively simple one; researchers found that when they passed a specific query string that contained the -s command to PHP in a CGI setup, PHP would interpret the -s as the command line argument and result in the disclosure of the source code for the application. They extended their testing and found they could pass whatever command-line arguments they wanted to the PHP binary.
“You’d think these bugs would be long forgotten, but it isn’t so; they’re like the undead. Vulnerabilities never die,” Shteiman said. “They don’t die and we realize if we see this executed by botnets trying to onboard servers and by crimeware kits being sold, that means attackers understand they can rely on old problems because people won’t fix them and attackers don’t have to work too hard.”
Post a Comment Blogger Facebook