Vendors First, Customers Next

It was revealed in December that China hacked two vendors
and then attacked their clients.

This wouldn’t be the first time that a breach used
the actual target’s vendor as the attack vector.

Cloud Hopper

On December 20, CNBC reported that members of China’s elite Operation Cloud Hopper team breached the networks of Hewlett Packard Enterprise and IBM, then used their access to hack into their clients’ computers.

This isn’t the first time that a vendor was breached before attackers made it to their ultimate victim. In 2013, Target was hacked through a vendor and in 2011, several military contractors were attacked after hackers breached systems related to the RSA SecureID multi-factor authentication tokens.

Although details of that attack still have not been released, it is believed that information about the seed numbers used by the public RSA algorithm to generate one-time passcodes on the tokens was taken. I wrote about that story when it first broke.

You May Already be Hacked

The odds of your company being hacked are about the same as the odds of an earthquake in San Francisco. You may not know when it will come, but you can bet it will come. In fact, as I have written more than once, you may already be hacked and just don’t know it. According to Stephanie Balaouras of Forrester, hackers are in a network for an average of over 200 days before anyone has a clue.

Getting back to Operation Cloud Hopper, it is so named because the attack starts with breaching the cloud-based infrastructure of a managed service provider (MSP) which supports the actual target company. Once inside the MSP’s network, the attackers move to their desired target – or targets. Cloud Hopper has most recently impacted MSPs in the United Kingdom, United States, Japan, Canada, Brazil, France, Switzerland, Norway, Finland, Sweden, South Africa, India, Thailand, South Korea, and Australia. Again, the attackers don’t care about the MSPs; they want access to their customers.

You may have the best CISO in the world, and your network may be locked down so that there is no way that it can be breached from the outside. But let’s say that you contract with CloudCo for your email, as do perhaps a dozen to a hundred other companies.

Even though your network is locked down from the outside, an attacker may be able to breach CloudCo’s network and come in that way, or they may be able to breach another CloudCo customer, ride their network into CloudCo, and then into your network. Or an attacker could attempt a cross-VM attack using a zero-day exploit or unpatched system.

Back to the Future – Again

In the 1990’s, Tandem’s offshore development group supported a few software vendor sites in India, one of which had a NonStop server attached to a “phantom node” on the Cupertino network via lease line. In the day, a phantom node acted as a block, or firewall, between two parts of an Expand network. We can discuss that over a cold cider sometime.

When I visited India in 1994 to do a security audit on our partners, I put a LAN analyzer on our partner’s network to ensure there was no “leakage” beyond the phantom node. What I saw instead was traffic that did not belong to Tandem but belonged to an entirely different company. To save money, this software vendor only had one LAN in the building and attached systems from the multiple companies for which it was developing software. That meant that Tandem proprietary information was being mixed with competitor’s proprietary information on the same wires.

Putting proprietary information on connected networks is exactly what an MSP does. In theory, the networks are separated by firewalls, but if system operators at the MSP can access all of the systems that they are managing, then so can hackers.

What can organizations do to help mitigate this type of attack? Well, the use of Guardian on NonStop servers most certainly puts a brick wall in the path of any hacker. Trojans and Microsoft Office macros won’t run on Guardian. But if you must use OSS or have other systems within your infrastructure, here are some helpful tips and tricks:

• Encrypt your data. That doesn’t mean using encrypted hard drives which are only useful when they are powered down, that means real data-level encryption with hardware-protected keys. Products such as Voltage and Atalla would be a good start. You want a system that will return garbage unless the data is accessed via an authorized application or database manager.
• Ensure that your systems are patched. When new exploits are found, vendors try to fix them. If you don’t keep your systems patched, old exploits can still be used against them.
• Practice good cyber hygiene. Strong passwords, multi-factor authentication, and risk-based authentication are smart moves. Many security experts now recommend against changing passwords frequently.
• When an employee transfers or leaves, remove access immediately. This of course assumes that you have a system to track exactly what they had access to while they were employed.
• Attempt to filter phishing emails and train your employees how to spot them. Beware of social engineering to gain access to systems or passwords. Train your employees to double- and triple- check access requests. Even better, implement a risk-based access request system.
• Implement a risk-based monitoring system which can help flag real security events while minimizing false alarms.
• Very carefully evaluate the security implementation of any MSP and segment your own network so that the MSP has the absolute minimum access that they need to provide their services to you.

Finally, train, equip, and empower a cyber incident response team and link them at the hip with your business continuity team. Practice their response with tabletop and live-fire exercises. If you are infiltrated, you need to act fast to contain the damage. If you can afford it, use a Red Team to attack your systems before the black hats do. If the Red Team does find a hole, your cyber response team should be right on top of it.

This article is written in memory of Thomas Burg who passed away on April 16 of this year. Thomas was a good friend to both me and the NonStop security community. He surely will be missed.

Ron LaPedis, AFBCI, CBCV, MBCP, CISSP-ISSAP, ISSMP ▪ Managing Director ▪ Seacliff Partners International, LLC
San Francisco Bay Area