[HN Gopher] Stealthy Linux rootkit found in the wild after going...
___________________________________________________________________
Stealthy Linux rootkit found in the wild after going undetected for
2 years
Author : webmaven
Score : 215 points
Date : 2023-12-10 11:26 UTC (11 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| le-mark wrote:
| > Specifically, it hides files and directories beginning with the
| names "auwd" and "vmware_helper" from directory listings and
| hides ports 52695 and 52699, where communications to attacker-
| controlled servers occur.
|
| Do people out there really "allow any" ports on their firewalls?
| Or are those ports for control inside the firewall only?
| 3np wrote:
| Outgoing? You bet. Have you been out there?
| BLKNSLVR wrote:
| Outgoing, which I believe this would be, is generally far less
| restrictive than incoming.
|
| I'm playing around with IP address level detecting and blocking
| using incoming ports as indicators. I'm going to set aside some
| time to think more about restrictions on outgoing ports as a
| result of this and your comment.
|
| Do some logging of frequently used remote ports over a couple
| of weeks and create a baseline set of allowed ports, block
| everything else and see what breaks.
|
| I already use the limited Feodo Tracker[0] lists to flag in my
| firewall logs whether any device on the network has attempted
| to contact a known C&C IP address.
|
| Thanks for push.
|
| [0]:https://feodotracker.abuse.ch
| peblos wrote:
| Log4shell would have been a much smaller problem if so
| goodpoint wrote:
| Yes. This is some very basic malware, but real ones will use
| HTTPS on port 443.
| BLKNSLVR wrote:
| Only allow HTTPS out to FAANG (whatever it is now) +
| Cloudflare IP address ranges
| Kubuxu wrote:
| Nothing prevents C&C from being fronted by cloudflare.
| viraptor wrote:
| And CloudFlare will be extremely happy to let them hide
| there. They don't care about malware abusing their
| workers infra.
|
| But also "Only allow HTTPS out to FAANG" - ok, so now
| you're allowing encrypted connections to 2 largest cloud
| providers. At that point what's the benefit at all?
| jay-barronville wrote:
| > They [Cloudflare] don't care about malware abusing
| their workers infra.
|
| This is a serious allegation to make. Do you happen to
| have some supporting evidence?
| fullspectrumdev wrote:
| It's widely known and talked about in the infosec
| community - getting CF to do _anything_ about malicious
| content on their services is an absolute nightmare.
|
| I do understand they don't want to set any bad precedents
| internally, but their abuse reporting is abysmal.
| jay-barronville wrote:
| Do you have some supporting evidence?
| averageRoyalty wrote:
| Is it needed? Most hosting companies and CDNs are
| difficult to get to remove malicious content, this is
| pretty well known. I don't know why we'd require some
| form of irrefutable evidence to believe Cloudflare isn't
| the same.
| viraptor wrote:
| Just search for CloudFlare worker abuse. There's lots of
| stories like this
| https://news.ycombinator.com/item?id=37064311 , larger
| campaigns like https://www.bleepingcomputer.com/news/secu
| rity/blackwater-ma... , DDoS campaigns originating from
| workers https://news.ycombinator.com/item?id=38496499
|
| It's kinda hard to point to someone saying how big the
| problem is, because most posts are just "sigh, here's yet
| another example, anyway...". I wouldn't go as far as
| saying they're doing this as an intended strategy, but
| it's definitely a case of it being hard for CloudFlare to
| care about an issue when they're in business of selling
| protection from that issue.
| sambull wrote:
| One mans C&C server is anothers RMM.
| llamaInSouth wrote:
| Im pretty sure he was joking anyways... Either way, I
| thought it was funny.
| pyinstallwoes wrote:
| Better to limit per process
| mort96 wrote:
| Create a bunch of burner Google accounts and use Google
| Drive or Docs or Calendar as C&C?
| franga2000 wrote:
| I've used Google App Script for C&C in a demo before.
| It's HTTPS traffic going to a Google IP and the domain is
| script.google.com - what looks more legit than that?
| fullspectrumdev wrote:
| Hiding your C&C behind clownflare is basically the default
| mode for a lot of actors.
|
| CF are terribly slow to respond to abuse, their ranges are
| allowlisted everywhere, and it's not terribly hard to hide
| your backend infrastructure (origin) even from cloudflare
| itself.
|
| Sure you have to deal with the eventual takedown of your
| domain, by CF or more likely the domain registrar, but it's
| trivial to work around that (backup domains, frequently
| rotating them, etc).
|
| What's funny is how Namecheap are now absolutely god tier
| at doing takedowns on malicious domains - they used to have
| a very poor reputation and now will process a takedown
| (provided evidence) within the hour usually.
| zelphirkalt wrote:
| Wondering if typo, auto-correct, or intentional ...
| anyway, I like :D
| averageRoyalty wrote:
| Given the critical tone, I'd say probably intentional.
| goodpoint wrote:
| Yes, and with domain fronting and doing traffic patterns
| that look legitimate.
|
| A good solution is to block all outgoing traffic on
| production servers.
| vitus wrote:
| > Or are those ports for control inside the firewall only?
|
| It seems so. This traffic likely will not even traverse a
| firewall -- the article lists the IP addresses used with port
| 52699, which are all RFC1918 space (172.16.0.0/12).
| RCitronsBroker wrote:
| attacking telecom infrastructure smells like possibly state actor
| related to me
| BLKNSLVR wrote:
| Novel protocol usage gives off that kind of smell too.
| RCitronsBroker wrote:
| oh yes, it does. Good catch. False-Flagging your actions as
| commercially motivated doesn't strike me as a hard to
| construct alibi, either. Certainly not beyond the scope of
| sophisticated, state aligned actors, except maybe the north-
| Koreans, that guardians of peace Spiel was entertaining tho.
|
| This awakens memories of GCHQ attacks on Belgian(?) telecom
| providers; they really are inherent gold mines for dragnet
| surveillance, stealing database, offensive cyberattacks and
| probably lots more. There's a reason Huawei is subsidized for
| offering cheap 5g infrastructure to international clients,
| it's a real nice thing to have backdoors to. Not saying the
| west is much better in this regard, Cisco has been more than
| compliant in similar shenanigans just to name one.
| fullspectrumdev wrote:
| "Using weird protocols" for C&C is old hat for hackers tbh.
| Well over a decade ago after reading an RFC I switched all my
| backdoors to use SCTP - a protocol many of my peers had never
| fucking heard of - and found it evaded a shit tonne of
| IDS/firewall products.
| foobarian wrote:
| Or is it low hanging fruit? :-)
| RCitronsBroker wrote:
| touche lol, narrowing it further down to thai telecom is not
| really helping to raise the metaphorical fruit either.
| spacecadet wrote:
| 2 years and they don't know how it starts? Well, I bet we can
| assume at first it was People. It is probably still largely
| people, but 2 years of possible persistent C2... I would think by
| now it's possibly using many other areas of ingress without any
| people involved.
| Pixie_Dust wrote:
| How does this "stealthy Linux rootkit" get onto the system in the
| first place. Without opening a malicious email attachment or
| clicking on a malicious weblink.
| dspillett wrote:
| Those methods would work. Could also be included in pirate
| content in a torrent or similar (this was a significant vector
| for windows malware in the 2010s). Some instances could also
| have been manually placed. Or the creator could have bought the
| services if a bonnet, installing the seeds on machines already
| backdoored and open. There are a fair few ways to get new
| rootkits out there, a number of them difficult to trace back to
| the true source.
|
| EDIT: from the article: The researchers have
| so far been unable to determine precisely how Krasue
| gets installed. Possible infection vectors
| include through vulnerability exploitation,
| credential-stealing or -guessing attacks, or by
| unwittingly being installed as trojan stashed in an
| installation file or update masquerading as legitimate
| software
| 0xDEF wrote:
| Today most (by volume) Linux attacks are against IoT devices
| that run Linux and SSH with weak/no auth.
|
| Behind that are attacks on Linux web servers where exploits in
| the web application (e.g. WordPress) or the web framework (e.g.
| Rails) are the attack vector.
| fulafel wrote:
| The posing as a VMware helper process and timeframe hints this
| may be associated with the recent VMware compromise
| epidemic(s).
| ufmace wrote:
| Seems to me this is probably a later stage thing. Somebody got
| initial access to a company's systems via such a mechanism to
| some individual's system. A few more cycles of recon,
| exploitation, and pivoting later, they may be in a position to
| install something like this on some actually important server.
| Use it to maintain access to the things they really want, then
| delete evidence of the previous steps to cover their tracks.
|
| Now that it's at least 2 years after the initial intrusion, it
| could be pretty tough to determine how that happened and what
| path the attacker took.
| belltaco wrote:
| Would SecureBoot have prevented the rootkit parts of this?
| fullspectrumdev wrote:
| Probably not, depending on configuration. You can do very
| clever things with secure boot on Linux to have all kernel
| modules signed, etc, but if the attacker has ring0 code
| execution anyway that can be evaded without a huge amount of
| effort.
| rs_rs_rs_rs_rs wrote:
| Linux rootkits meta really did not change much since 1999.
| fullspectrumdev wrote:
| Yep. They come in basically the same flavours.
|
| Binary replacement (replacing top, ps, netstat, etc with
| patched versions) is the oldest trick.
|
| Syscall hooking kernel root kits largely only vary in how
| exactly they hook the syscalls - there's a few methods, but the
| underlying principle is the same.
|
| And then you have userland hooks which usually use LD_PRELOAD
| to intercept system calls/libc calls to get the job done.
|
| Honestly most of the time a full blown root kit is overkill,
| just name your binary something innocuous and have it not do
| anything too fucking obvious and nobody will notice.
| CableNinja wrote:
| Itd be obvious if you really look, but i once discovered in
| Perl you can make your command look however you want when you
| run `ps`. I was able to make a process appear to be a kernel
| process (one with `[]`). It was pretty hard to discover
| unless you were very familiar with what every kernel process
| did. Ive discovered other fun ways of hiding things too, such
| as creating `...` as a directory. The first time i
| encountered that, it took me a whole day to find that dir.
| matheusmoreira wrote:
| Not just Perl. Any Linux process can do it.
|
| https://www.man7.org/linux/man-pages/man2/prctl.2.html
|
| > PR_SET_NAME
|
| > Set the name of the calling thread
| milliams wrote:
| Krasue is a Linux Remote Access Trojan that has been active since
| 20 and predominantly targets organizations in Thailand.
|
| Off-topic, but this is the first time I've seen post-1999 year
| denoted with just two digits without the use of an abbreviating
| apostrophe.
| Luc wrote:
| It's written '2021' on Group-IB's page. Perhaps a typo they
| corrected. https://www.group-ib.com/blog/krasue-rat/
| juunpp wrote:
| Aka, we're getting old.
| consumer451 wrote:
| In a Darknet Diaries episode from a while back, I recall a three
| letter agency person saying something along the lines of "oh,
| haha they are running desktop Linux, those guys never run anti-
| virus software, this will be easy..."
|
| Can anyone give me any more depth on this? Is a typical desktop
| Linux distro install more likely to be susceptible to attack by a
| nation-state level actor?
| steve1977 wrote:
| I mean there's people installing stuff with curl | sudo bash
| and friends, so go figure...
| throwaway09223 wrote:
| Anti-virus software is utterly worthless in detecting
| previously-unknown rootkits. Not a factor.
|
| The typical attack vector for any system would be compromising
| the inbound software. This is really easy to do when people are
| downloading and installing random programs from websites. This
| used to be less common, but popular cutting edge tools have
| popularized it recently "distro packaging is too slow, etc,
| curl|bash to install"
|
| On linux, most base software comes from the distro
| repositories. The question there is how hard it would be to
| compromise these systems (including one of the mirrors). This
| includes ancillary packaging systems (pip, cpan, gems, conda,
| etc)
| consumer451 wrote:
| > Anti-virus software is utterly worthless in detecting
| previously-unknown rootkits.
|
| Maybe the "this will be easy" part was that without AV
| software, there was a greater chance that they could just
| spin up Metasploit, and wouldn't even have to use one their
| stockpiled zero-days?
| autoexec wrote:
| Why worry about stockpiled zero-days even for non-linux
| systems when they can just force MS or Apple to hand over
| data or inject whatever they want into an OS "update".
| consumer451 wrote:
| If I'm beginning to recall the story correctly, it's that
| your suggested route would involve more time, paperwork,
| and this particular op might not be important enough to
| get the bug guns authorized by the higher-ups. Hence,
| "oh, this will be (relatively) easy..."
| throwaway09223 wrote:
| AV doesn't detect the exploit mechanism -- that's not how
| it works. It's only pattern matching existing binaries.
|
| The difficulty level is "recompile with small changes and
| test that it doesn't match" not "develop a new attack
| vector"
|
| It really is stupid and pointless against an attacker with
| even a bare minimum of competence (able to run a software
| build vs downloading binaries)
| CAP_NET_ADMIN wrote:
| Most of the currently used AV software contains heuristic/ML
| components that are able to gather and analyze various
| indicators of compromise. Without something like that
| running, you're basically tied to manual review of systems
| running at the moment. Making malware for such scenarios is
| basically making a Base64-encoded script in the language of
| your choice and then exploiting something(either the user or
| some software) to get it to execute.
|
| I know, because I've been writing small malware toys and it
| got blasted by both Bitdefender and ESET.
| hulitu wrote:
| > Most of the currently used AV software contains
| heuristic/ML components that are able to gather and analyze
| various indicators of compromise
|
| Ransomware runs just fine on corporate computers with the
| latest and greatest "antivirus" software.
|
| I really lost hope some 10 years ago, when i saw that i
| have to manually remove malware from memory sticks, because
| macaffe was clueless. After more than a year they released
| an update that will detect and remove the malware (it was a
| virus speading through autorun.inf with exe names which did
| not have any sense like jhghjjj.exe)
| consumer451 wrote:
| I can't speak to that particular attack vector today, but
| it's interesting that McAfee isn't even on this Gartner
| chart, and that Microsoft is now a leader. Things have
| really changed in that space.
|
| https://www.cybereason.com/blog/cybereason-named-a-
| leader-in...
| heavyset_go wrote:
| > _On linux, most base software comes from the distro
| repositories. The question there is how hard it would be to
| compromise these systems (including one of the mirrors). This
| includes ancillary packaging systems (pip, cpan, gems, conda,
| etc)_
|
| IMO if you're worried about the NSA, I assume they have
| access to root certificates and your package manager that
| uses TLS would be vulnerable. Wouldn't have to compromise any
| system or mirror to do so.
| throwaway09223 wrote:
| I mean yeah, I would say that's one way to compromise those
| systems.
| sp1rit wrote:
| > your package manager that uses TLS would be vulnerable
| most distro package managers (dpkg, rpm, etc.) tend to use
| gpg which shouldn't suffer from those issues (but they
| could obviously still have some sort of other backdoor for
| gpg).
|
| Still, I feel like distro packages are _really_ secured
| compared to stuff you install via pip /npm/... as I don't
| believe they do anything beyond protecting downloads with
| TLS.
| lmm wrote:
| > IMO if you're worried about the NSA, I assume they have
| access to root certificates and your package manager that
| uses TLS would be vulnerable. Wouldn't have to compromise
| any system or mirror to do so.
|
| Debian-derived systems use GPG signing so that wouldn't be
| enough, there's no central authority in the first place.
| There are hundreds of Debian developers, and most likely
| they could find one with poor opsec (or straight-up send a
| National Security Letter), but they would pretty much be
| burning that specific individual.
|
| (Do distro package managers use Certificate Transparency?
| That would be the hope on the TLS-based side)
| dharmab wrote:
| The default settings of many Linux distros don't enable major
| security features. For example, on Arch Linux, microcode
| updates must be configured separately and most users likely
| skipped that step.
|
| Also, X11 has really poor separation between processes. Any
| desktop application running in Xorg can keylog all user inputs.
|
| It is possible to build a secure Linux installation but it
| requires a lot of careful OS knowledge and the discipline to
| only use a small set of software with established provenance.
| And probably disabling Javascript.
| seeknotfind wrote:
| One big example is home folder access. Linux has a variety of
| file access control systems (the most prominent are Linux file
| permissions and SELinux). However, typically any application
| you run will be run under your own user and have access to your
| home folder.
|
| In macOS/Windows, there are runtime permissions these days
| which allow you to control which folders can be given to which
| application.
|
| Linux needs to mainstream a solution like this. One of the most
| popular way Linux users can handle this today is by associating
| a user with a application and granting various permissions to
| that user. However this is a far cry from safe by default, and
| it requires deep system knowledge.
| foobiekr wrote:
| Once you own the home folder you can drop aliases for
| anything you want in the bashrc with almost no one noticing.
| At that moment point you are essentially done in almost all
| cases even in the absence of a local root exploit which Linux
| continues to be rife with. You will eventually catch a sudo
| password (using a trivial sudo wrapper alias) and all the ssh
| keys and jump host or password manager config.
| medstrom wrote:
| Moreover, even if the user manages to deny you root access
| through excellent hygiene, that just means you can't
| include this machine in your botnet. You still have full
| view of the home folder! Upload to a data broker, get $.
| marcosdumay wrote:
| Yeah, that's bullshit. None of the mainstream OSes will help
| you protect you from a nation-state actor.
| consumer451 wrote:
| As I wrote in another comment:
|
| > Maybe the "this will be easy" part was that without AV
| software, there was a greater chance that they could just
| spin up Metasploit, and wouldn't even have to use one their
| stockpiled zero-days?
| tsujamin wrote:
| There's a lot more footguns for attackers on modern windows
| than other operating systems. Most can be bypassed (EDR, AV,
| AMSI, ETW, UAC, controlled folders, App Control, block at
| first site etc), but it definitely raises the bar if your end
| goal is very low likelihoods of detection.
|
| Put differently: the gauntlet you have to run on Windows (and
| to a lesser extent macOS I imagine) is much longer
| akira2501 wrote:
| In order for AV to work, it has to have the highest level of
| permissions on the system, high enough to analyze all actions
| and potentially deny or alert on them.
|
| I don't trust that an AV vendor can _add_ security to a system
| with a _new_ and obscure binary looking over the kernels
| shoulder. I don't think the properties of the universe allow
| for this to ever be true.
| akyuu wrote:
| The Linux desktop technology stack lags behind Windows and
| macOS when it comes to security. The causes are both technical
| (see this comment [1] for an overview) and non-technical, often
| stemming from a fragmented development model where there are no
| clearly defined security boundaries. For example:
|
| - There is no real concept of base system because distros are
| usually a patchwork of software from diverse sources. This
| means stuff like proper secure boot is not really feasible on
| any distro (although AFAIK the systemd/Fedora people are
| working on it with signed UKIs and immutable OS images).
|
| - Some features that could live in userland for improved
| security are instead implemented in the kernel, while both
| Windows and macOS generally keep moving exploitable features
| like font rendering to userland.
|
| - Distros often disable or disregard security features such as
| SELinux or mitigations like CFI.
|
| Here [2] is a more detailed article examining the lack of
| security of Linux desktops in case you're interested.
|
| [1] https://news.ycombinator.com/item?id=37502088
|
| [2] https://madaidans-insecurities.github.io/linux.html
| enasterosophes wrote:
| Malware requires propagation vectors. Computers don't work by
| magic, instead when thinking about security you should think
| about your threat model. What are you protecting and from whom,
| and what is the attack surface you are exposing which would
| allow them to get prize?
|
| On Linux, the attack surface may not be non-existent, but by
| default it is smaller than some other operating systems. Any
| halfway competent Linux sysadmin can configure iptables or some
| other firewall to block all network traffic except what is
| specifically permitted. Even when something is exposed, it
| usually only allows access to specific user accounts (including
| system service accounts.) Once access is granted to an account,
| you are then constrained by discretionary access controls (DAC)
| (i.e. POSIX users + groups + file permission modes), and, for
| the paranoid, by mandatory access control (MAC) (eg AppArmor or
| SELinux) as well.
|
| As others have said, such access could theoretically allow
| bootstrapping to greater privilege escalation, especially if
| you only have DAC and no MAC, but in practice it's harder than
| it sounds.
|
| I have seen plenty of publicly-exposed Linux VMs compromized
| over the years. They were always compromized via one of two
| methods: the admin user explicitly enabled password
| authentication to ssh instead of adhering to keypairs (which we
| enforce by default); or, they opened up a vulnerable service
| such as a database to the public internet. It was _never_ via
| some virus.
|
| You hear people saying dumb stuff like, oh no one uses Linux
| and that's why there are no viruses. To that, I say our Linux
| server farms have a vast amount of highly valuable compute
| power and research data. If it were possible to infect these
| machines with a virus, any halfway competent nation state,
| ransomware group or bitcoin mining conglomerate would very much
| consider it a worthwhile investment to develop such a virus.
| ninkendo wrote:
| Question to HN, is chkrootkit still useful to use at all? I
| remember using that tool decades ago thinking it gave me some
| semblance of peace of mind, but I've also kind of assumed that
| sophisticated malware would likely be able to evade it.
___________________________________________________________________
(page generated 2023-12-10 23:01 UTC)