Accellion Supply Chain Hack

A vulnerability in the Accellion file-transfer program is being used by criminal groups to hack networks worldwide.

There’s much in the article about when Accellion knew about the vulnerability, when it alerted its customers, and when it patched its software.

The governor of New Zealand’s central bank, Adrian Orr, says Accellion failed to warn it after first learning in mid-December that the nearly 20-year-old FTA application—using antiquated technology and set for retirement—had been breached.

Despite having a patch available on Dec. 20, Accellion did not notify the bank in time to prevent its appliance from being breached five days later, the bank said.

CISA alert.

EDITED TO ADD (4/14): It appears spy plane details were leaked after the vendor didn’t pay the ransom.

Tags: , , ,

Posted on March 23, 2021 at 6:32 AM • 10 Comments

Comments

Kurt Seifried • March 23, 2021 9:40 AM

The problem is on the one hand:

React quickly and patch fast

And on the other hand:

That may break things, and most of the time won’t become an immediate problem.

I personally experienced this with a combination of a PHP/WordPress vuln and local Linux Kernel exploit. I knew about it Friday evening, decided it could wait until Monday to fix. I got hacked over the weekend. All the other times I put maintenance off I didn’t get hacked (AFAIK).

We also have the problem of selection bias: older technology, not well maintained by the vendor (e.g. not a lot of proactive security, mostly reactionary to security researchers or attackers) and not operationally maintained by the end-user (budget cuts, resource constraints, etc.). By definition, people don’t typically stay on 10 or 20-year-old software because they’re willing to put a lot of resources into keeping that entire system fresh and up to date.

On the flip side, these systems are easier for attackers to research and compromise, they are much slower to change (e.g. Google Chrome keeps hardening the system and making changes, Apple iMessage, etc.). These systems are based on 10 or 20 year old technology, languages, and programming cultures that didn’t value security (we still don’t in a meaningful way but that’s another story).

These types of hacks are virtually guaranteed to happen at some point with these older IT systems.

JonKnowsNothing • March 23, 2021 9:47 AM

@All

There are at least 2 timings that need to be coordinated on patches/upgrades:

  • Timing of availability by the vendor
  • Timing of business operations

From the Bank FAQ

There was a period of five days from the patch on 20 December until 25 December when the breach occurred, during which the Bank would have applied the patch if it had been notified it was available.

There are some systems that can be patched “on the fly” but a good many cannot be patched during the middle of an operations period. Even if the folks in charge of the patch are sure that it’s not going to crash all the rest of their applications, and even if it’s a high-priority fix, the update/patches have to be scheduled before dumping code into the mix.

There are generally certain periods in the accounting cycle that are locked: Payroll Periods and End of Month/Quarter/Year reporting cycles. Once you calculate the duration of these activities, it is generally found there are 2 open periods on the monthly calendar that only impact day-to-day business. If you are a bank, that day-to-day business cycle has expanded to 24hours, continuous access.

For smaller enterprises, they may not have the massive duplication of systems needed to run parallel operations while one system is patched-tested and the unpatched one runs the recovery cut back in case of a failed patch.

So, the bank claims that they would have applied the patch during their End of Year Accounting cycle, and that they could do that patch within 5 days of notification, implying that if they knew on day 4 they would have patched it on day 5, is some tough mutton…

SwashbucklingCowboy • March 23, 2021 9:48 AM

Kurt, I think there’s a lot more 10, 20 and 30 year old software being used than you may realize – and that any of us would be comfortable with.

J • March 23, 2021 10:48 AM

I don’t understand why they call it a supply chain attack. As far as I can tell from the Mandiant document it’s not. The hackers used security flaws to install a web shell and then went fishing for valuable data.

Kurt Seifried • March 23, 2021 11:42 AM

@SwashbucklingCowboy

Oh, I’m aware, but a lot of these systems can (should) be behind firewalls/VPNs which greatly reduces the attack surface.

If you define the supply chain as stuff that you need to make your IT systems work then you’ll have the software you create/pull in, and these third-party apps you buy/license/use. You don’t need to invent the whole universe, but you should probably go to your hardware/VMs/providers of such and be aware of them.

name.withheld.for.obvious.reasons • March 23, 2021 10:41 PM

Another in the continuing saga of “As the Whack A Moles”, but let us return to this episode, “Days of Our Bytes, Merikan Style”. Fade in to scene 1, 6:30 AM EDT–Nantucket.

Today, as Francesca opens to the third page of the newspaper at the breakfast table and has her first sip of freshly squeezed orange juice, a subtle gnawing of wood can be heard from somewhere just outside the kitchen patio sliding door…contractors?

not.me • March 24, 2021 5:10 PM

I’m glad I dumped that program some years ago because its installation documentation, related to ssl and dmz configuration, were terrible.

Emily Watson • May 11, 2021 2:57 PM

I don’t comprehend why they consider it an inventory network assault. Supposedly from the Mandiant record it’s definitely not. The programmers utilized security blemishes to introduce a web shell and afterward went looking for important information.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.