A Case of Broken Trustico
On March 1, the Croydon, UK based SSL/TLS cert reseller Trustico made headlines in what could quite possibly be one of the most convoluted and worst-case scenarios for website security.
The firm had devised a plan to rid its customers of all of Symantec and its subsidiaries certificates, which also includes GeoTrust, Thawte, and RapidSSL certs. This particular set of SSL certificates had recently all been handled by DigiCert, and Trustico planned on replacing these with Comodo issued certificates (which may or may not be as secure due to recent events). This plan aligns exactly with the future plans where Google chrome and Mozilla teams will perma-ban all Symantec certificates due to some shady issues in the past.
DigiCert pushed back and told the head of Trustico that certificate revocation could only happen in specific cases. When asked to explain further, the Chief Product Officer of DigiCert communicated that this kind of revocation typically happens only when certificates have been compromised. Playing off of the compromised card, Trustico pounced on the opportunity. So naturally and nonchalantly Trustico produces evidence of a “compromise” – by sending DigiCert a copy of all 23,000 customer private keys.
In a flurry of ‘he said she said’ chaos, both companies took their arguments to Mozilla’s security policy news group which then ultimately spilled over onto Twitter, and the rest is potential Pwnie award fuel.
DigiCert responded by issuing alerts to its customers detailing the compromise of their certificates, which Trustico verified that these private keys (which checked out according to customers who were privy to the email contents) were all obtained via ‘cold storage’. Naturally (and appropriately) customers freaked out.
The very fact that Trustico had copies of these private keys, and that these private keys were able to be identified and paired to a customer raises several red flags in the “what not to do as an SSL reseller” category.
To make matters worse, as if they weren’t already a burning trash fire of epic proportions – an individual publicly dropped an unpatched vulnerability that existed on Trustico’s website that allowed remote attackers to have root access on their webserver…. the very same webservers that issued the customers their SSL certs and their public/private key generator as well. This effectively made these certificates quite possibly compromised legitimately.
Trustico responded by immediately shutting down their website in order to evaluate and patch the vulnerability. They remained down till late in the evening and resumed sales on March 2.
Customers of Trustico and all SSL resellers are advised to be very aware of your key status and to handle their private keys with utmost care. If you are concerned about your reseller’s security and if they don’t explicitly declare their measures, ask them. As a customer and as a facilitator of security for your customers and users – by ensuring proper security steps occur throughout the entire chain, you can help ensure sensitive Internet traffic cannot be snooped, intercepted, or hijacked by shady individuals.
Equifax Breach Isn’t Even in its Final Form
Apparently Trustico isn’t the only company digging through its cold storage. In yet another fun chapter in the 2017 Epic Equifax Breach, the credit-reporting company dusted off yet another 2.4 million people that were affected by the breach – bringing up their ultra-combo tally to 146.4 million people affected.
In a statement released this week, Equifax stated the newly discovered victims were only “partially” affected since their data contained “only” home addresses, driver’s license states, dates of insurance or expiration dates. The discovery came after investigators began looking over additional details of the breach and shifted their focus from Social Security number information to additional personally identifiable information (PII) data that was also stolen.
Luckily these individuals will be contacted by Equifax and offered identity theft protection and credit file monitoring services. If you are a proud member of the 146.4 million club, make sure to take all the appropriate measures to ensure your data is secure and make sure to establish additional protection outside the window offered by Equifax or any other company to ensure fraudsters aren’t just waiting for those to expire before they take advantage of the stolen data.
Smurfing In 2018
A newfound Distributed Denial of Service attack was unleashed earlier this week and victims were getting hosed by hundreds of gigabytes per second. Unlike most script-kiddie DDoS attacks, which usually are cheap knockoffs of the classic Low Orbiting Ion Cannon (LOIC) this attack was completely new and is actually an amplification attack – thus making it immensely more powerful.
LOIC and its cheap knockoffs usually require bots and attackers to identify a resource on the target site that takes up large bandwidth (such as a movie file, or large images) and request them repeatedly. This will then establish a valid connection to the victim’s webserver from the bot machine that for all intents and purposes, is a valid web request. This will then trigger the webserver to grab the file and send it to the attacker, thus consuming bandwidth. The attacker will then cancel the request and the victim will end up dumping its cache of the large file and moving on to the next request – thus also consuming CPU and memory – thus compounding its DDoS capabilities.
With the right technology and analysis in place, victims can protect themselves against these typical LOIC type attacks and similar attacks which come from bot machines. However, this new attack which was detailed by Akamai’s principal architect Baryy Reveendran Green is a whole other kind of beast.
The novel attack has all the hallmarks of Smurf attacks from the late 90s and early 2000s in which an individual spoofed packets from a victim’s machine to a ICMP broadcasting node on the Internet. These nodes would amplify a single packet and return hundreds or even thousands of packets back to the spoofed address – thus allowing a single individual the ability to crash entire websites by sending a few packets to only a hundred nodes or so.
The new DDoS attack utilized memcached instances which have a ‘feature’ for requesting statistics over UDP. An attacker, by spoofing a simple 15-byte UDP request from a victim’s machine, gets a response between 1,500 and 65,000 KB in length – per request. This amplification has allowed the DDoS attackers to reach nearly 500 Gbps in recorded instances. To make matters worse, the attacks will appear to originate from a service provider’s router, thus some machines with automatic DDoS or firewall protection may actively block valid or mission critical IP addresses which could further complicate matters.
Memcached is not meant to be installed on public facing Internet machines (so of course it is), and by design, does not come with any access control features (why would it?). So, if you are a victim of this attack or are looking for protection of against this 2018 Smurf variant, block all incoming traffic from port 11211 and contact your ISP to see if they can provide additional guidance.
If you are a system administrator, check all of your machines and make sure memcached server is not public facing (like its config file stated) and disable UDP listening. The rest of us really appreciate it.
