Another Malware with Persistence

Here’s a piece of Chinese malware that infects SonicWall security appliances and survives firmware updates.

On Thursday, security firm Mandiant published a report that said threat actors with a suspected nexus to China were engaged in a campaign to maintain long-term persistence by running malware on unpatched SonicWall SMA appliances. The campaign was notable for the ability of the malware to remain on the devices even after its firmware received new firmware.

“The attackers put significant effort into the stability and persistence of their tooling,” Mandiant researchers Daniel Lee, Stephen Eckels, and Ben Read wrote. “This allows their access to the network to persist through firmware updates and maintain a foothold on the network through the SonicWall Device.”

To achieve this persistence, the malware checks for available firmware upgrades every 10 seconds. When an update becomes available, the malware copies the archived file for backup, unzips it, mounts it, and then copies the entire package of malicious files to it. The malware also adds a backdoor root user to the mounted file. Then, the malware rezips the file so it’s ready for installation.

“The technique is not especially sophisticated, but it does show considerable effort on the part of the attacker to understand the appliance update cycle, then develop and test a method for persistence,” the researchers wrote.

Tags: advanced persistent threats, backdoors, China, firmware, malware

Posted on March 9, 2023 at 8:33 PM • 5 Comments

Comments

Clive Robinson • March 10, 2023 7:52 AM

@ ALL,

I wrote a little on this APT this morning,

But a lot more on why I’ve seen the security hole it used to be “persistant”. Because I’ve seen the mistake that was made be made over and over again with “code signing” used for updating.

It’s especially true of “embedded devices” where ubtill recently resources were limited.

Any way you can read more,

https://www.schneier.com/blog/archives/2023/03/friday-squid-blogging-were-almost-at-flying-squid-drones.html/#comment-419207

If there is one big takeaway,

“Understand the difference between authenticating a communications channel and authenticating any transactions that come through the channel.”

In security more generally way to many make the mistake of authenticating channels, not the transactions.

SpaceLifeForm • March 10, 2023 3:32 PM

Obviously not signed. Right?

Clive Robinson • March 10, 2023 5:51 PM

@ SpaceLifeForm,

Re : Code Signing Chain.

“Obviously not signed. Right?”

We can find out but it’s almost certainly immaterial.

The devices had already been infected with the APT.

The APT had a test running every ten seconds looking for an update/download in progress.

The APT would wait for the “zip file” to appear, which would have happened after any archive code signing.

The APT halted the update process.

Then opened the zip added the APT malware to it and then re-zipped it

Then alowed the update process to continue.

So the APT attack was going to work regardless of if the usuall form of code signing was used or not…

It’s a problem I identified a long time ago, and why we should stop hashing archives and signing the hash, and move codesigning into the actuall the the final update proces so the checking and updating are not two seperate sequential process but one atomic process.

Because as long as the processes are seperate and sequential, then a major security hole exists between the two of them that can always be exploited.

It’s a fundemental security issue with rather more than just code signing. As I’ve observed in the past, you need to “authenticate the transaction” as “authenticatting the channel” is always inadiquate as MITM attacks become easily possible if you don’t.

In this case signing the hash of the archive is “authenticating the channel” updating is the transaction, so it’s that which MUST be authenticated over the entire code.

This can be done by encryption and a suitable “chaining mode” checked inside the update process as it happens. That way an attacker can not get “in between” for the equivalent of a MITM attack.

However if the attacker can replace the update process or patch out the chaining authentication then…

Which now I’ve said it will probably be the next type of APT persistant method.

And before you ask “Yes I do have a solution” for that eventuality but it needs hardware modifications (and not the “memory tagging” variety as they can be bypassed).

iAPX • March 11, 2023 7:53 AM

These “boxes” are very interesting because they are revealing the real state of (un)security we are all exposed to, while pretending to be a security device.

No clean and relatively secure update process (yes atomic)
No signed executables, while not expected to run user-created executables
No processes containment
No files containment
Essentially no in-depth security inside the “security” box

This is what should have been expected from an intern setting up a Pi VPN for the first time, not from a “security” company.
And until there’s a security audit, or doing it ourselves after buying the box on our own time and our own hard-earned money, there’s no way to know what is the real security-level of these boxes.

There’s a lot that should have been done, from a security design standpoint to mitigate (yes we mitigate!) the risks.
This have to change!

Who? • March 13, 2023 12:26 PM

Another firewall manufacturer that sells overpriced low-end network appliances with incredibly expensive maintenance contracts and unsigned firmware updates.

They are more interested in making difficult for non customers to get access to firmware updates than making these updates secure.

In short, go the open source way if you are serious about security.

Another Malware with Persistence

Comments

Leave a comment Cancel reply