Thursday, November 21. 2013
I keep telling people in my PHP security seminars that they should not allow weak passwords for user accounts. There are numerous ways to check for weak passwords, from preg_match to ext/cracklib.
I usually take passwords like “password” or “123456” as an example, because anecdotally, these are notorious examples for bad passwords. However, I always felt in the back of my head that empirical evidence for these examples was a little bit lacking.
Wednesday, November 28. 2012
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:
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”:
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.
Wednesday, October 31. 2012
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
82% of CAPTCHAs solved on the first try, with plain (untrained) gocr and a one-line shell script.
Wednesday, October 24. 2012
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:
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.
Tuesday, May 8. 2012
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:
« previous page (Page 1 of 3, totaling 15 entries) next page »