Comment by Sebb767 | Hacker News Reader

Comment by Sebb767 | Hacker News Reader

Zerodium[0], the magic string searched for in the fake user agent, is a zero-day acquisition platform, in case anyone else is wondering. The third parameter to `zend_eval_string` in the commit [1] is the "filename" [2] of the executed code, which is probably used for stack traces. Which is quite a strange choice, because seeing that in the logs would probably ring alarm bells immediately. Overall, this commit seems strange in its structure IMO - not in a "good" covert way, but in a "why does it not try to hide better" way.

EDIT: According to zerodiums charts, this would have been a payout of up to 250k$. However, I'm not quite sure what the attackers plan on cashing out on that would have been, given that the exploit would have quite obviously referenced zerodium and therefore would make the submitter the primary suspect of being the author. Maybe some APT used this "simple" format to disguise the actual power? But then again, it would be in their interest for the exploit to actually go through.

[0] https://www.zerodium.com/

[1] https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad...

[2] https://bugs.php.net/bug.php?id=78224 (only mention I found with a documented use of the parameter)

[3] https://zerodium.com/program.html

The commits say it was 'sold to zerodium, mid 2017', which would lead me to believe that someone has already been paid for this.

I'd say the reason it doesn't hide better is because it's specifically meant not to hide. It's burning the vulnerability that has apparently existed for almost 4 years.

The vulnerability most people here are talking about was introduced to the PHP codebase last weekend, as part of the block of code containing the "sold... mid 2017" message -- that vuln wasn't there previously, at least in that form. It's not clear what exactly is going on here, but if something was sold to Zerodium in 2017, it wasn't that vuln.

So, the message "sold to zerodium, mid 2017" is there, but may not be true -- it might very well be deliberate misdirection.

Perhaps the vulnerability in the git server that allowed this is what was sold, rather than the commit.

I don't see much point in discussing these latest commits. It's very unlikely they were actually malicious in intent (at least to PHP).

The vulnerability that is of interest is the one that allowed these commits to be injected. That is what I figure was sold years ago, and was burned recently.

Problem is, burning the exploit this way only works if someone does the work to find it.

Of course, it could appear in the server logs (or be detailed on a file dumped on the filesystem) - but it seems PHP have just decided to move to Github, and may not actually care about this, so it may not see the light of day.

Sorry, I'm not sure what you mean. The commit was almost certainly never meant to make it in to some server log, it was meant to be seen, and it was. In that way it 'burned' (ie destroyed) the backdoor in to the PHP code repo.

And PHP does seem to care about the real exploit, the one in their infrastructure, which is why they're moving to Github.

Mind expanding on your above comment to help me understand?

Meant to be seen with a commit named "fix typo" wtf are you talking about? It's only due to luck that it has been reverted quick enough before being available through binaries.

I mean exactly what you did - "The vulnerability that is of interest is the one that allowed these commits to be injected".

Yes, it will be evident that the commits appeared in the git history, but not necessarily how they got there. If the git repo on disk suddenly has that commit, and no other usual indicators of compromise, that doesn't really give you anywhere to start looking for, what we agree is, the interesting vulnerability. All you have is "we know this box/service was definitely rooted, so look at all our infrastructure end-to-end".

They care about the exploit enough to move - of course. But do they care enough to investigate and find the actual exploit? Or hand over the server image to someone who does? Unless they've wrapped it in some PHP, it's probably not their core competency. I don't follow the PHP project, so I don't know the answer to that.

Okay, I see what you mean. I guess I assumed they wouldn't just accept that their server was hacked and not do a through investigation (or have someone do so), but I suppose that's mostly because I couldn't imagine not if it was me.

> it was meant to be seen, and it was

Are you sure about that? If anyone wanted to demonstrate their access/power, they would probably leave some way to identify themself as the author - with a half-hearted concealment like this, anyone could claim to have been the hacker.

The only way this discovery would help the hacker, is if they intended to force a security audit of the karma system and/or the move to GitHub.

> The only way this discovery would help the hacker, is if they intended to force a security audit of the karma system and/or the move to GitHub.

I agree. Of course I can't be sure of anything here, but to me this commit seems suggestive that there's other injected code somewhere since mid 2017.

You also make a good point on attribution. I had considered that too and if not wanting to take credit could tell us anything about the author.

For example say you were an intelligence agency that knew about this access and knew it was being used by an enemy. Perhaps you couldn't let php know about the vulnerability without exposing that you had access to other data allowing you to know about it. Creating this commit could be a way to share knowledge without it being known where/how it was found.

Of course that's all wild speculation.

Zerodium say they have nothing to do with this: https://twitter.com/cBekrar/status/1376469666084757506

>Likely, the researcher(s) who found this bug/exploit tried to sell it to many entities but none wanted to buy this crap

but why so snarky?

twitter. the takes are hotter than the sun, the style is snarkier than zkSNARKs.

am I understanding it correctly that somebody had breached the PHP git server and tried selling it to 0-day and similar exploiting businesses?

That was my assumption given that they explicitly mentioned zerodium. But so far only the commit itself is public, so until we know more about the attack or the attacker, this is pure speculation. The tweet from zerodium is not clear on whether they received an offer for this vulnerability, unfortunately.

> Zerodium say they have nothing to do with this

Would they admit if they did?

"zerodium investigated zerodium and zerodium found out that zerodium had nothing to do with this"

Well the opposite may be true too - the comment may be lying about it having anything to do with zerodium or that date.

Could be just a meme or a bad attempt of misdirection in case it went undetected for a while.

That's unknown, but it would be strange for them to be involved - it would not make much sense for them to pay out a bounty to themselves.

I think it's far more likely that someone tried to plant this there in order to cash out via zerodium.

Maybe the person that reported the exploit to Zerodium already cashed out in mid 2017 and was angry that the exploit hasn't been fixed yet. Therefore, he decided to make it very obvious and force php to react.

I believe the exploit itself was introduced with the commit in question, it wasn't there before.

The other exploit, the one that allowed the commit to be injected.

As has been pointed out elsewhere, the exploit is the ability to inject code into the PHP Git repository. Not this RCE.

Reply on news.ycombinator.com