When you surf the web, your web browser requests and receives data from some remote server. If you are logging into a website, you would want to have your login info secure, meaning when you send that information to the remote server for verification, you don’t want the data to be in plaintext such that it can eavesdropped by someone on the network. This is where SSL (Secure Sockets Layer) or TLS (Transport Layer Security) protocols come in. These protocols are used when then website you visit has HTTPS instead of HTTP, with the ‘S’ standing for “secure”.
These protocols are based on a public key and a private key. These keys separately can be thought of as half of a whole key, and the whole key can be used to determine whether the information sent or received is from a source you expect, allowing you to know the data has not been compromised by another party. This is because data encrypted using somebody’s public key can only be decrypted using the same person’t private key. Suppose you are sending data to A from B. Then B uses A’s public key to encrypt the data, and when A receives the data, A can uses its private key to decrypt the data. Therefore, it is important to keep the private key locked up and secret.
This is where companies who issue SSL certificates come in. There are various ways to encrypt the data to make it secure, and various companies claim there algorithm is more secure or meets whatever criteria required for the server’s use, including warranties, browser support, subdomains, speed, and other additional exclusive features in a package.
On March 1, a user with the Twitter handle @svblxyz has noticed that he was not able to validate his certificate issued by Trustico, a certificate re-seller, and the site was instead sending curl requests (an application used in scripts for downloading various data) as displayed in the application logs. Another user with the Twitter handle @Manawyrm revealed that it’s possible to trick the script on the server doing the curl request to use some other command, also known as code injection. The most shocking thing about that was that the application logs showed that the command was run as root (highest privilege, no restrictions), meaning that script was running as admin. Another user by the Twitter handle @ebuildy also helped reveal that the company doesn’t use proxies, meaning that it is possible to inject code that would display all of the IP address of their LAN devices.
Having a code injection vulnerability on a server is bad enough since you let anyone to essentially mess around with. Having a code injection vulnerability that allows you run things as root is even worse since you then have complete access to the server. Having all that on a server which validates SSL certificates, and you have a complete nightmare. Following the tweets, it did not take the internet long to put Trustico’s server offline. One bad thing that have happened is someone wiping all data on the server, possibly without hopes for recovery or someone installing a bunch of backdoors on their server (allowing the person to get back in even after Trustico fixed the problem).
However, the worst thing that could have happened is private keys for SSL certificates being compromised. The user by the Twitter handle @ebuildy was able to figure out that Trustico doesn’t use proxies because when using code injection to display their localhost info, the results returned their own certificate under the company’s name. This means their private key could have been compromised and anyone could use code injection to run a command see the data unencrypted if they wanted to. Anyone who sends their SSL certificates for validation would have their certificates compromised. As of now the exploit is fixed and their old certificate was revoked and replaced with a new one.
A few days before the security flaw was found, Trustico was meaning to revoke security certificates by Symantec/DigiCert. Mozilla and Chrome browsers were rejecting DigiCert certificates after misissuing of over 30,000 of them. As a result Trustico decided it was better to switch from DigiCert to Comodo. According to a statement by Trustico, “We believe the orders placed via our Symantec® account were at risk and were poorly managed. In good conscience we decided it wasn’t ideal to have any active SSL Certificates on the Symantec® systems, nor any that didn’t meet our stringent security requirements”.
After they requested DigiCert to revoke the certificates to replace them with Comodo ones, DigiCert declined to do such unless they were compromised. Trustico then proceeded to email them the private keys of the certificates, and thus compromising them, providing insight that their certificate validation tools logged private keys of certificates. According to Jeremy Rowley from DigiCert, “Trustico not has provided any details how the private key leaked or how did they acquire the keys”, now leading to skepticism on whether any stored private keys were accessed by unauthorized during the time the code inject vulnerability was present.
— Alex Baraker