×

Just When You Thought it was Bad Enough: The SolarWinds Attack

This year has been … a wild ride to say the least. 2020 has packed more in its yearly trip around the sun than some decades. First, there were the fires in Australia, Brazil, and California. Then came March, and the collective realization that things were never going to be what they were, even after the pandemic. Oh, and there was a presidential election that left everyone on edge, ongoing racial, economic, and political turmoil, and even a Brexit deal (of sorts). In short, we’ve all seen some things.

But this crazy year still had a bit more crazy to give us, and so on December 13, FireEye disclosed one of the largest, most sophisticated global intrusion & espionage campaigns in modern history, the SolarWinds supply chain attack. The compromise, which has been initially attributed to APT 29 (Cozy Bear), Russia’s foreign intelligence service, has affected at least 200 organizations directly (and potentially affected thousands more) around the world. Details are still being uncovered by the day.

A Quick Overview of the Attack

On December 13, FireEye disclosed that it had been the victim of a supply chain attack via the SolarWinds Orion platform, used to monitor and manage IT health. Attackers used digitally-signed certificates issued from the SolarWinds website to install an infected update package masquerading as a legitimate Orion software update. Once the payload was installed, communication with third-party servers was established allowing for remote access by the attackers. Then the payload removed itself and restored legitimate update files. With remote access, the attackers were able to gain additional credentials and move laterally throughout the network against specific targets. Current timelines project that the attack has been ongoing since at least March 2020, with the initial exploit going back to OctoberNovember 2019.

SolarWinds Malware Infection Chain — Microsoft Defender Research Team

The initial disclosure noted that one of the payloads, SUNBURST, had been used to conduct espionage against victim sites, and leveraged multiple sophisticated techniques to evade detection, obscure activity, and maintain persistence. One of the more clever aspects was the use of local IPs and dynamically-generated hostnames that match the victim’s environment, making the attack even more difficult to detect. There’s also potentially a second attack vector, known as SUPERNOVA that is still being investigated, but may be piggybacking on the SUNBURST vulnerability.

The attack’s complexity and many-pronged approach is complicated, highly technical, and worth a deeper dive. We’ve compiled a list of great resources to read over to better understand how the attack works (and what mitigations can be taken).

Why Supply Chain Attacks Are Spreading

We’ve talked before about the risk of supply chain attacks. Senior Consultant Carey Lening has given a talk about the growth of supply chain attacks across numerous industries, including finance, the maritime sector and industries.

What makes these attacks so challenging, is that organizations have limited control over the security posture of downstream providers. Even a Zero Trust security model is unlikely to have stopped the SolarWinds attack, as the tool itself had privileged access to enterprise servers. And despite what opportunistic vendors may be claiming, no single tool or service can prevent this.

Unfortunately, the best solutions to mitigate against future SolarWinds-style attacks tend to require buy-in from the top, both in terms of cost and resources, but also a willingness to fundamentally change how security is practiced internally. In short, a defense-in-depth, mature security model that emphasizes:

  • Thorough network and device hardening, as well as adherence to baseline best practices for security;
  • Comprehensive visibility of system and network activities;
  • Regularly sharing and updating threat data across industries, domains and tools;
  • Timely review and actioning of relevant threat indicators, including temporal analysis of compromised devices to understand lateral movements;
  • Isolation and prompt investigation of machines where known-bad file signatures have been detected;
  • Identification of compromised (or likely compromised) accounts.

Additionally, standards bodies, government regulators, and big industry players (looking at you, Microsoft, Amazon, Google, Apple, etc.), also need to step up and begin to enforce industry-wide changes. As the Atlantic Council notes in their detailed report on supply chain attacks, ‘Breaking trust: Shades of crisis across an insecure software supply chain’, support for robust, widely-compatible secure standards and code practice is paramount. Improving open source libraries is also another critical component that will take a village.

Finally, there should also be an emphasis on holding vendors and third party providers to account for their own security practices (or lack thereof). While there’s no such thing as perfect security, in the case of SolarWinds, security was … not exactly a priority. By rewarding firms with dollars for lackluster security practice, it sends a message that security isn’t a critical concern, and increases the attack surface.

In short, we’re all in this together, and we need to start acting accordingly.

My Brand! The Rise of the Elevated Spoof.

At Credio, we’ve written before about how COVID-19 is having an outsized impact on everything in daily life, including cybersecurity and privacy threats.

As users have been forced to leave the confines of hardened on-prem networks and turn to cloud and other hosted services, organizations have faced greater challenges, often with fewer resources at hand.

The Rise of the Elevated Spoof

For this week’s issue, we wanted to delve into one growing area of concern for organizations -the rise of domain spoofing and improved phishing techniques.

According to a recent report by F5 Labs, “55% of phishing sites made use of target brand names and identities in their URLs.”

Gone are the days of the poorly-written, dodgy sites that boasted exaggerated urgency and laughable spelling mistakes. Now criminals are going for sites that genuinely look and act like their targets — right down to the domain names.

More TLDs = More Opportunities to Wreak Havoc

So how are fraudsters doing it? It turns out, there are a number of techniques available.

Domain Name Spoofing: Fraudsters are learning that, thanks to the wonders of hundreds of top level domain names, it’s still easy to register a deceptively-similar looking domain name, clone a target’s login page, and blast out a link to the user.

For example, let’s say you’re interested in mimicking the domain name for apple.com. Obviously, Apple has already registered all the apple.* domains that most of us can think of. But as more top-level domains and ccTLDs (country-code TLDs) come online, it becomes a game of whack-a-mole to keep up.

Compounding this is the rise of free and low-cost domain registrars such as Freenom and DotTK, which provide inexpensive (and sometimes free) domain registrations, even of popular domains.

Unicode and IDNs: Add to that, the problems that come from our multilingual world — and the Unicode standard. While Unicode is a great equalizing force by opening up opportunities for non-Western speakers to be heard — providing text for most of the world’s writing systems has a cost — it gives criminals a bigger sandbox to play in.

IDNs, or Internationalized Domain Names — use the power of the Unicode standard to allow organizations to connect online in local languages. IDN registrars are still few and far between, but some will allow fairly convincing-looking registrations — for example applе (the Cyrillic capital letter Ie, in lowercase).

Punycode: But say you’re a scammer, and committed to keeping the domain in the .com TLD. Now, GoDaddy won’t accept non-ASCII unicode character sets, so your plans for applе.com likely won’t fly. Enter punycode.

Punycode is a way of converting letters that cannot be written in ASCII into Unicode ASCII encoding. Using punycode, you can include non-ASCII characters within a domain name by generating a “bootstring” encoding of unicode. Here’s the punycode for applе.com – xn--appl-y4d.com (which can be registered for around $11).

On certain vulnerable browsers (and especially mobile devices, where eyeballs are contending with smaller screens, shrunken urls, and the inability to hover a mouse), it renders the page as applе.com, which looks surprisingly legitimate, especially if you’re clicking on a link and might be distracted, or haven’t had your first cup of coffee. Throw in a free Letsencrypt TLS certificate, and it’s a very convincing-looking fraud opportunity.

Site Cloning: Even the practice of cloning a website can often be trivially easy. One need only visit the target’s website, save the page, and extract the HTML, CSS, images and other elements, and upload that content to a hosting site. With a few alterations, a fraudster can make a rather convincing-looking site at https://applе.comthat might confuse even the most skeptical among us.

While phishing attacks will only continue to improve so long as there are victims to be had, it’s important that awareness, security controls, and the tools we use, also continue to evolve with the threat. Our eyes can’t do it alone.

Resilience: Planning for When the Clouds Go Away

Resilience: Planning for When the Clouds Go Away On November 25, AWS suffered a major service disruption in its Northern Virginia (US-East-1) region. It left the region out of commission for over 17 hours, and took thousands of sites and services, including Adobe, Twilio, Autodesk, the New York City Metropolitan Transit Authority, The Washington Post offline. When Planned Upgrades Go Wrong In a post-mortem, Amazon described how a planned capacity increase to their front-end fleet of Kinesis servers led to the servers exceeding the maximum number of threads allowed by the current configuration. As the servers reached their thread limits, fleet information, including membership and shard-map ownership, became corrupted. The front-end servers in turn were generating useless information, which they were propagating to neighboring Kinesis servers, causing a cascade of failures. Additionally, restarting the fleet appears to be a slow and rather painful process, in part because AWS relies on this neighboring servers model to propagate bootstrap information (rather than using an authoritative metadata store). Among other things, this meant that servers had to be brought up in small groups over a period of hours. Kinesis was only fully operational at 10:23pm, some 17 hours after Amazon received the initial alerts. Finally, the failures with Kinesis also took out a number of periphery services, including CloudWatch, Cognito, and the Service Health and Personal Health Dashboards, used to communicate outages to clients. For reasons that aren’t totally clear, these dashboards are dependent on Cognito, and may not be sharded across regions. Essentially, the post-mortem seems to imply that if Cognito goes down for a region, affected customers in that region will have no way of knowing. Resiliency, or How to Survive the Next Outage While Amazon posted a number of lessons learned in their post-mortem, which are all worth reading, today we wanted to discuss what customers can do to limit their own risks in the Cloud:

  • Build Outages into your BCP and IRP: While providing continuous service and support is the main goal, we should all be mindful of worst-case-scenarios. That means identifying critical workloads and applications, considering and having a plan to execute fail-over options, and ensuring that customers can be alerted when a failure can’t be avoided. Build response and recovery plans around these considerations.
  • Housing Critical Workloads in Multiple Availability Zones (AZ): Since the AWS outage appears to have been isolated to a single region, organizations that relied on hosting their critical systems across AZs were less impacted when US-East-1 went down. Consider services like AWS’ Multi-Region Application Architecture to fall over to a backup region. These features are not available by default, however, and must be built into an organizations’ overall architecture plan.
  • Use Amazon Route 53 Region Routing: Another best practice for ensuring geographic distribution is to use Route 53 to route users to infrastructure outside of AWS, whether it’s another cloud provider, or a more minimalist on-prem backup service.
  • Test for Your Worst Case: Adopt Netflix’s ‘Chaos Engineering’ model to test what happens when networks, applications, or infrastructures go down, and develop a road-tested plan for how to work around those failures.