Hacker News Reader

Comment by mkhalil | Hacker News Reader

In related news, Trustico's site is down apparently due to users being able to run commands as root on their webserver.

I wonder if this was used to extract some private keys?

https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself.

They are running the good old php shell of "<%= system(%_REQUEST['cmd']) %>". As root. As a security company.

This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

> mailed 23000 private keys

I had a similar thought. My thought was: "HOLY SHIT!"

"As a security company."

Well, their CEO's linked-in profile doesn't really sound like a security company.

> Email Marketing Digital Marketing Google Analytics Google Webmaster Tools Market Analysis Marketing PPC SEM SEO Sales Security Social Media Marketing Web Analytics Affiliate Marketing Google Adwords Management E-commerce Lead Generation Online Marketing Online Advertising SaaS Marketing Strategy Strategic Partnerships Cloud Computing New Business Development Business Strategy Start-ups Web Development CRM Social Media Product Marketing Solution Selling Strategy Channel Partners Channel Sales Business Alliances Business Development Leadership Social Networking Network Security Hardware Product Management B2B Professional Services GTM Partner Program Development Internet Security Google B2B Marketing Sales Operations

If you sell certs, you're a company in a security-related context. I don't care who you are, I care if you do your job.

Saying that, that quote sounds way too long to not be BS.

The quote sounds like SEO.

CEO SEO?

SpaceX to launch SEO CEO's REO into LEO.

(I expect this post will get 0E0 upvotes)

On the plus side, a notebook doesn't have connection to the internet...

In some languages (German for one) the common word for laptop is translated to notebook in English.

The term notebook computer is used in English as well, however its usage has declined significantly over time compared to the term laptop:

https://trends.google.com/trends/explore?date=all&q=laptop%2...

It is declining, but I highly suspect the MacBook will remain the MacBook, and not the MacTop.

I choose to believe that this is performance art. The world is a better place that way.

What they actually had was probably more like:

    system('openssl req -config /prod/prod-config.cnf -subj "/CN={$DOMAIN}" ....'

And whoever wrote that function assumed someone else had sanitized DOMAIN.

It looks like a lot more understandable of a mistake when framed like that.

Does it really? Even if the code author hadn't learned to escape/sanitize close to use so it's visible (or to avoid cases where you need to escape/sanitize entirely, like using something that bypasses the shell and takes array arguments), let's look at the manpages.

PHP's system() manpage: http://php.net/manual/en/function.system.php

  [red box]
  Warning
  When allowing user-supplied data to be passed to this function, use escapeshellarg() or escapeshellcmd() to ensure that users cannot trick the system into executing arbitrary commands.

system(3): http://man7.org/linux/man-pages/man3/system.3.html

  Any user input that is employed as part of command should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed.  Such risks are especially grave when using system() from a privileged program.

This is a canonical mistake that's used as a mistake example in textbooks.

at this point i think the problem with system() should be blamed on the language and not the people using the language. how many legitimate uses of system() functiona call are there. a primitive that does fork() execv() on an array is a much better alternative. yeah, it doesn't 100% fix problems you might have issues with - style flags but you are in a much better situation. like if your users want to do system() maybe force them to do the extra work.

system() style functionality -> should be the hard thing to do execv() style functionality() -> should be the easy thing to do

Whilst I do wish I could cleanse a web application of actually supporting system(), we have system() in Perl, Ruby, Python, and modules for Node. I've seen people bagging PHP and that really isn't fair.

Shower thought: Allow me to globally disable system() in for language x. Aside from the obvious case of just banning these insane system calls, you're protected against surprise vectors in parsers.

Edit: You would presumably mitigate pipe open vulnerabilities too

I suspect that these languages just end up deferring to the system() library function in libc. LD_PRELOAD or other linker trick would then let you override it with a do-nothing or complain-loudly replacement.

You can do so with SELinux btw. You can remove the right for a program to run the exec syscall.

It's just sad that there is no really good tutorial how to write your own SELinux modules for your own applications. It's easier than it seems and allows some really powerful security measures.

Maybe you could write one? I bet that it would be really appreciated.

All of those languages have an option to pass in arguments as an array and bypass the shell completely. PHP does not. It's much safer with no shell (though not perfect).

I propose a new term: "Clown Car" security.

For situations like this where a fiasco just keeps getting worse, each step its own facepalm.

* Asking users to generate private keys on the issuer's server

* Storing those private keys

* Emailing those private keys

* Sending that email completely in the clear

* Running unsanitized user input on their server

* as root

Should count as probable cause for revoking the remaining 27k certificates then, no? It's not unreasonable to think someone has been exploiting this for years, siphoning any private key passing through?

The remaining 27k certificates are probably the ones which were generated on and which never left the customer's premises. The only thing which could be siphoned in these cases is the CSR, which is harmless (it contains essentially the same info as the certificate, which is public).

If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be none the wiser (except for perhaps looking at CT logs)?

No. The CSR is tied to the key and the resulting certificate as well. Verifying that the CSR belongs to the key would be he CAs job, not the servers. If the server was rooted, an attacker could probably just use it to create an arbitrary new certificate - but revoking the legitimate cert won’t fix that.

1. User validates domain and submits csr 2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA 3. CA signs a cert because the domain was validated 4. Rootkit receives valid cert for its own private key 5. Rootkit presents a bogus error to enduser 6. Enduser tries again and rootkit lets it through

End-result: there are now two certs and private keys for the domain, one of which is compromised?

Just a though experiment. I'm not familiar with the domain validation flow this reseller site was using.

Like I said: If you compromise the Trustico servers which are a reseller, you could trick the CA into believing that a CSR is valid for a domain. This would get you a certificate with a key under your control. But revoking the certificate with the key under the owners control won’t fix this. The illegitimate certificate would still be under the attackers control and remain valid.

Unless you revoke all the certs issued through that channel/reseller - the legitimates would be collateral damage but you'd also get rid of any illegitimate ones?

If you compromised the reseller, would you have the reseller keep a list of illegitimate certificates that you issued via that channel?

Surely the actual CA has a database of certificates it has issued and by which reseller?

Certificate transparency logs would out that pretty quickly.

1. Rootkit issues cert and sends to hacker

I find this plan to be much much easier.

Presumably, even if you had root on the reseller website, you would need to wait for the domain owner to actually perform a domain validation before the actual CA's system would deliver any certificates?

Considering the security on that website, probably not.

Even if you did, I would argue that if you have root access to the validation form, getting a certificate signed is not going to be exponentially harder either.

Waiting for a potential target to sign a cert using that specific reseller is just borderline useless.

An attacker of a CA will be interested in either their CA private key (or intermediary) or the ability to get arbitrary certs signed.

Random targets on the internet are useless since it's unlikely they can MitM them.

Wouldn't that attack mean that the cert the domain owner got wouldn't work on their webserver, since they didn't have the correct private key for it?

Yes, but you could fool the user with an error message so the user tries again and let it through unmodified? (Hide the fact that a cert was actually issued already)

Someone might have rm -rf / --no-preserve-root'd them! :)

Hmmm, you sound guilty!

;-)

Not me guv'ner! Honest like!

Probably good, in case anyone was looking to dump stuff on that server.

Reply on news.ycombinator.com