[HN Gopher] Perfctl: Stealthy malware targeting Linux servers
___________________________________________________________________
Perfctl: Stealthy malware targeting Linux servers
Author : johnfernow
Score : 143 points
Date : 2024-10-04 00:14 UTC (22 hours ago)
(HTM) web link (www.aquasec.com)
(TXT) w3m dump (www.aquasec.com)
| johnfernow wrote:
| From the article:
|
| > "Aqua Nautilus researchers aim to shed light on a Linux malware
| that, over the past 3-4 years, has actively sought more than
| 20,000 types of misconfigurations in order to target and exploit
| Linux servers. If you have a Linux server connected to the
| internet, you could be at risk. In fact, given the scale, we
| strongly believe the attackers targeted millions worldwide with a
| potential number of victims of thousands, it appears that with
| this malware any Linux server could be at risk.
|
| ...
|
| - It utilizes rootkits to hide its presence.
|
| - When a new user logs into the server, it immediately stops all
| "noisy" activities, lying dormant until the server is idle again.
|
| - It utilizes Unix socket for internal communication and TOR for
| external communication.
|
| - After execution, it deletes its binary and continues to run
| quietly in the background as a service.
|
| - It copies itself from memory to various locations on the disk,
| using deceptive names.
|
| - It opens a backdoor on the server and listens for TOR
| communications.
|
| - It attempts to exploit the Polkit vulnerability (CVE-2021-4043)
| to escalate privileges.
|
| In all the attacks observed, the malware was used to run a
| cryptominer, and in some cases, we also detected the execution of
| proxy-jacking software. During one of our sandbox tests, the
| threat actor utilized one of the malware's backdoors to access
| the honeypot and started deploying some new utilities to better
| understand the nature of our server, trying to understand what
| exactly we are doing to its malware."
|
| The article goes into more depth of the attack flow, what the
| malware does, and how they detected it.
| CGamesPlay wrote:
| The CVE has a typo; the actual is CVE-2021-4034.
| https://nvd.nist.gov/vuln/detail/CVE-2021-4034
| ykonstant wrote:
| From the link:
|
| >The current version of pkexec doesn't handle the calling
| parameters count correctly and ends trying to execute
| environment variables as commands.
|
| Oh, for fucks sake.
| stuff4ben wrote:
| Thank you for that. I was wondering why a medium vuln was
| causing so much headache in a binary that wasn't even
| described by the article.
| guenthert wrote:
| > - It opens a backdoor on the server and listens for TOR
| communications.
|
| So a `lsof -iTCP` should list it, right? Is it using TCP port
| 9050 or a custom port?
|
| EDIT: Ha, they are (not surprisingly) way ahead of me. From the
| article: "The malware continues to copy itself from memory to
| half a dozen other locations, with names that appear as
| conventional system files. It also drops a rootkit and a few
| popular Linux utilities that were modified to serve as user
| land rootkits (i.e. ldd, lsof)."
| crackez wrote:
| There's always - cat /proc/net/tcp*
|
| And remember: echo * can be your "ls" in a pinch.
| Pesthuf wrote:
| But let's be honest, there's no reason to use these unless
| you already know your server is compromised. In which case
| the server would be taken down rather than ssh'd into.
|
| And even then the attacker could patch cat, bash, provide
| sneaky aliases or just compromise Libc altogether.
| loeg wrote:
| I don't think we need a copy/paste of the very first page of
| the article in the comments.
| pm2222 wrote:
| Does uefi secureboot help or not at all?
| johnfernow wrote:
| I'm not sure, outside of my expertise, but I think it might not
| help.
|
| The attack takes place after boot, so maybe at best UEFI
| secureboot could prevent persistence of the malware, but I
| don't think it'd even achieve that, as the malware adds popular
| Linux utilities that were modified to serve as user land
| rootkits, and runs them by modifying the ~/.profile script.
| That script is ran when the user logs in (it starts the malware
| first, and then everything that's supposed to run on the server
| after), and I don't believe UEFI secureboot has any protections
| against ~/.profile script modifications or rootkits ran after
| boot.
| vaylian wrote:
| See the mitigation section in the article:
| https://www.aquasec.com/blog/perfctl-a-stealthy-malware-targ...
|
| UEFI won't help here. But keeping your system up to date and
| limiting the system to the necessary functionality will help
| you.
| opengears wrote:
| In the mitigation section there is written 'Deploy Runtime
| Protection: Use advanced anti-malware and behavioral
| detection tools that can detect rootkits, cryptominers, and
| fileless malware like perfctl.' -- which tools can we
| currently use to detect perfctl?
| ykonstant wrote:
| I hear Crowdstrike is king ([?] [?] [?])
| doubled112 wrote:
| To be fair, a system that rebooted and won't come back up
| IS pretty secure.
| AStonesThrow wrote:
| No, because it's a denial of service.
|
| C-I-A triad: Confidentiality, Integrity, Availability.
|
| A dead system is confidential, and if that's your
| criterion, then fine, but legitimate users may require
| access to intact data and services.
| doubled112 wrote:
| Sure, and availability in this sense is often forgotten,
| but I was only joking about Cloudstrike's ability to
| block malware.
|
| A dead machine is difficult to infect with malware. You'd
| have to go out of your way to do so.
| blueflow wrote:
| Not at all.
| pushupentry1219 wrote:
| I'm curious to understand why you would think that it would
| protect this at all?
| jeroenhd wrote:
| The article describes a hooking library as a rootkit but I
| can't see any indication of this rootkit inserting itself into
| the boot process. Instead, it seems to LD_PRELOAD itself into
| processes at a later stage.
|
| Secure boot won't help here. In theory one could configure a
| system to only trust executables and DLLs signed by a trusted,
| external signatory (like a locally hosted package repository)
| but I don't know of any Linux distros that make it easy to set
| up something like that. You'd also need to invent something to
| sign scripts, because signing binaries is only a part of the
| problem (in theory you could set this up Powershell, I think?
| But I doubt many Linux systems will boot with PS in the place
| of /bin/sh). Once the kernel launches the init process, the
| rest secure boot verification chain essentially ends.
|
| It seems to me that prevention isn't hard by simply updating
| old software and perhaps running antivirus software on your
| servers.
| PhilipRoman wrote:
| A lot of focus on the malware itself, but not so much on the
| misconfigurations and vulnerabilities which enable it. Would love
| to see that list. Other than that, the evasion techniques look
| pretty traditional.
|
| And of course the privilege escalation is done by a polkit
| vulnerability...
| allkindsof wrote:
| Also more interested in what the misconfigs are.
| fredsted wrote:
| It seems to be a RocketMQ vuln; it's described further down the
| page.
| opengears wrote:
| are there any scripts or steps to 100% detect perfectl yet?
| Gys wrote:
| > In all the attacks observed, the malware was used to run a
| cryptominer
|
| I assume it starts by detecting a continuous 100% utilization
| of the cpu's.
| jellykid wrote:
| Supposedly it tones down it's activity while a user is logged
| in and waits for the machine to go idle. Another reason to
| have centralized performance monitoring.
| Gys wrote:
| Yes, but tools like htop show the average load over the
| last 15 min. So I assume that will show a high utilization.
| aflukasz wrote:
| Article mentions couple of const paths that are used, like
| /root/.config/cron/perfcc.
|
| Also, it mentions that ~/.profile is modified (EDIT: and many
| others, actually), so IDS like AIDE, if operated correctly,
| should alert you on that. I don't see any mentions about
| attempts to circumvent locally run IDS. I wonder if/why malware
| author did not attempt any evasive actions here, given how much
| they try otherwise. Maybe cost/benefit ratio is too low?
| theamk wrote:
| From the text, tons! This rootkit does not seem very stealthy
| at all.
|
| IMHO, a simplest one is to check $PATH. If there are suspicious
| entries, like /bin/.local/bin, it's a sign of infection.
|
| You can also check for presence of the specific files as
| mentioned close to the end of article.
| sea-gold wrote:
| Here is Ars Technica's write up:
| https://arstechnica.com/security/2024/10/persistent-stealthy...
| kvemkon wrote:
| And the discussion
| https://news.ycombinator.com/item?id=41736572.
| theamk wrote:
| Heh, my work has a firewall policy: any activity towards TOR
| servers flags an alert and makes security contact you. If you
| don't confirm it was by design, they'll start full scale
| "computer compromised" procedure. (And if you do confirm it it
| was by design, then they'll ask you to change that design if
| possible :) )
|
| I thought it was overly paranoid, but it seems that would have
| really helped in this case.
| waihtis wrote:
| Unless youre doing security research, there close to zero
| legitimate uses of Tor for the average citizen.
| indrora wrote:
| There are plenty of reasons to use Tor. Not only to obfuscate
| location but to defend against mass surveillance, including
| that of the state [1]. Remember that Tor was developed
| originally and funded by the US State Department. Tor makes
| communications of LBTQ/Anti-authoritarian/journalist
| individuals safer in a world where the State Department has
| to put out advisories [2] about traveling while queer, a
| pride flag sticker is illegal and punishable by death or
| imprisonment in over 24 countries and journalists are
| imprisoned for talking to those who speak out.
|
| Tor is an essential tool for all citizens -- Especially those
| in the US who would be targeted by those who seek infinite,
| unrestrained power.
|
| [1] https://i.kym-
| cdn.com/photos/images/original/002/128/768/403...
|
| [2] https://travel.state.gov/content/travel/en/traveladvisori
| es/...
| mppm wrote:
| In theory, yes. In practice, the safety that Tor provides
| is in numbers, and the numbers just don't look good any
| more. By using Tor, you are entering a fairly small pool
| that you share with legit criminals and will be blocked and
| targeted accordingly. A good VPN like Mullvad is the saner
| option for most people.
| whilenot-dev wrote:
| In practice, even corporate greed steps in your way
| here... I can't even access reddit with Mullvad if I
| don't onionize it.
| snakeyjake wrote:
| Detecting TOR traffic is trivial for state actors who
| control their local infrastructure. In the PRC, TOR usage
| is banned and the ban is enforced via packet inspection.
|
| In any nation likely to target residents in the manners you
| have proposed, using TOR for any appreciable length of time
| puts a more prominent target on their backs than walking
| around with a pride flag sewn onto your jacket.
|
| And fingerprinting TOR usage via deep packet inspection is
| the fancy-pants way of doing it. Many nations like
| Ethiopia, Kazakstan, China, and Iran also just prevent
| routing to known TOR exit nodes-- and they're all known.
|
| Meanwhile TOR is like "just use a proxy brah", seemingly
| completely unaware that proxy usage is also detectable and
| that giving advice like that to vulnerable persons in
| unsafe countries is dangerous to those persons.
|
| So then you get to the "Swiss cheese model" of disaster
| prevention where in order to safely use TOR you have to use
| it through a VPN that you connect to through a proxy (all
| of which is STILL detectable) and any mistake along the way
| due to not being absolutely and completely perfect in the
| configuration or usage of TOR will put you at risk of
| automated detection.
|
| edit: you also, as a vulnerable user in an unsafe country
| who may not have consistent access to the internet or even
| speak English, must be stringently up-to-date on the
| software versions (e.g. the Ricochet vulnerability) of
| every product used in the TOR chain, which seems...
| unreasonable.
| pphysch wrote:
| > Tor is an essential tool for all citizens -- Especially
| those in the US who would be targeted by those who seek
| infinite, unrestrained power.
|
| This is quite euphemistic. Tor exists to provide
| telecommunications support to US govt-backed political
| operations in foreign countries.
|
| The individual welfare of people does not factor in. Take
| for instance the recent murder of an American citizen by
| $GOODGUYS vs. when another American citizen died under
| $BADGUYS captivity. Totally different treatment and
| rhetoric. People don't matter, politics does.
|
| We should not falsely romanticize State Department programs
| at the expense of human rights.
| tptacek wrote:
| You could make the same point without kicking up all the
| drama by saying there are close to zero legitimate reasons
| for a work computer on a work network to be reaching out to
| Tor.
| setopt wrote:
| I'd 100% understand if they want to block it... but for a
| while I ran my home server as a Tor hidden service just to
| get free dynamic DNS and NAT traversal, and could SSH into
| it from my office by accessing Tor from there. That's
| arguably a legitimate use case.
| tptacek wrote:
| Literally one of the specific, enumerated use cases
| corporate networks have for blocking this stuff.
| TZubiri wrote:
| "CVE-2023-33246 is a vulnerability found in RocketMQ, which is a
| software that manages messages"
|
| A more appropriate but less clickbaity title would be "Stealthy
| malware targetting servers running RocketMQ"
| nine_k wrote:
| The description of the payloads and of the hiding methods was
| educational though. Other malwares likely use similar
| techniques after the initial penetration.
___________________________________________________________________
(page generated 2024-10-04 23:01 UTC)