Hacker News Reader

Comment by ashishbijlani | Hacker News Reader

I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down; a few are listed here https://packj.dev/malware

1. https://github.com/ossillate-inc/packj

View on HN

Does it work on obfuscated calls? For example, a base 64 encrypted string that gets decrypted and then passed to a shell.

Altough, I guess in that case, the shell call itself is suspicious.

What if the shell call itself is obfuscated?

> a base 64 encrypted string that gets decrypted and then passed to a shell.

This is a very common malicious behavior. Packj detects obfuscation [1] as well as spawning of shell commands (exec system call) [2]. I've updated threats.csv to flag code obfuscation.

1. https://github.com/ossillate-inc/packj/blob/main/main.py#L48... 2. https://github.com/ossillate-inc/packj/blob/main/main.py#L48...

Does this work at the system call level, where it would detect e.g. any attempt to open ~/.aws/credentials, or does it rely on heuristic analysis of the code itself, which will always be able to be "coded around" by the malware authors?

The correct approach would seem to be to not run untrusted code in an environment where it can read your AWS credentials.

https://github.com/ossillate-inc/packj#how-it-works

I imagine you'd want some kind of fuzzer with security-oriented tracing on top. I've never heard of such a tool, but I'd bet it exists somewhere.

As I understand, they use static analysis. So the malicious code can be hidden by obfuscation.

For example, instead of writing

    open('/etc/password')

One can write

    method = calculateMethodName()
    name = calculateEtcPassword()
    geattr(__builtins__, method)(name)

I guess you'd have to run it in a malware sandbox like Cuckoo.

Turns out, stuff like Java's SecurityManager:https://docs.oracle.com/javase/7/docs/api/java/lang/Security... were there for a reason.

Note, it's been around since JDK 1.0, so 1996, 28 years ago (!), though it's not widely used.

But it allows sandboxing of libraries you use. I was using it to make a faulty library that was calling System.exit(0) - yes, a library that was shutting down the entire process, closing the main app... - not do that and instead wrap the exit in a regular exception.

Python and especially Javascript are reinventing a lot of "enterprise" ideas that Java invented 20+ years ago. Maven groupIds are another example from the Java ecosystem (they're used to avoid top level package name squatting).

You are of course correct that those features are extremely useful and that the JDK authors foresaw these situations long before they were a big deal. But also you do note that it's not widely used which is also correct and that's the important bit. I think it would be more accurate to say that python and javascript are discovering (perhaps not fully intentionally) ways to implement these ideas that are suitable for mass community adoption.

IMHO it's like the difference between basic research (mostly not very useful on its own but extremely important) and public health in medicine (the thing that actually makes a massive impact on the world that leverages the former but at a slower and more controlled pace). To stretch the analogy even more any doctor worth their salt will tell you that a treatment plan is only as good as the likelihood that the patient will stick to it. Other things like let's encrypt (https everywhere) and signal/whatsapp/telegram (strong privacy enabled by default) come to mind as implementing ideas on things that experts had been handwringing for decades that people "should" be doing that are now done so well that it feels almost silly not to do them the good way.

The Java Security Manager was not very effective in practice. It was already deprecated in Java 17 and will be removed in the future: https://openjdk.org/jeps/411

I understand their reasoning but it's still kind of sad that there's no replacement planned.

It would be cool if there was a universal access control platform, but I guess the best we're getting is Docker, because such a platform would commoditize OSes, which OS creators for sure don't want :-(

From an organizational standpoint its better because it lets a sysadmin/security person sandbox anything and everything instead of having to become proficient with the tooling for every different language (which may not even exist).

Python had some sandboxing attempts long time ago, like 20 years if not more, but without much success. Zope - one of the first web frameworks - needed one, but if I remember correctly it broke around Python 2.5, so you had to use Zope with an old version of Python.

https://wiki.python.org/moin/SandboxedPython has some details

Yes, we are incorporating strace-based dynamic analysis (containerized) to collect system calls. However, Packj can currently flag use of getattr() API as it is equivalent to "runtime code generation" [1]; a developer can go and take a deeper look then.

1. https://github.com/ossillate-inc/packj/blob/main/main.py#L47...

Packj currently uses static code analysis to derive permissions (e.g., file/network accesses). Therefore, it can detect open() calls if used by the malware directly (e.g., not obfuscated in a base64 encoded string). But, Packj can also point out such base64 decode calls. Fortunately, malware has to use these APIs (read, open, decode, eval, etc.) for their functionality -- there's no getting around. Having said that, a sophisticated malware can hide itself better, so dynamic analysis as you suggested must be performed for completeness. We are incorporating strace-based dynamic analysis (containerized) to collect system calls.

Hey, I tried to check whether your project can detect obfuscation, but it doesn't appear to be installable. In requirements.txt:

- esprima==4.0.0 requires Python 3.6 (EOL) or lower because the package is really old and uses the async keyword (promoted in py37) as an attribute name, which is a SyntaxError on py37+.

- GitPython==3.1.27 requires Python 3.7 or later (requires-python:>=3.7).

Thanks for trying it out and sharing your feedback! I will fix this issue and also create a Dockerfile for easy testing.

Looks interesting, thanks. I'd like to see something like this but with a transparent proxy interface that you can point your package managers to so that you always in inspected and approved packages.

That's exactly what I am working on right now! I made an open source project called ambience (currently in public alpha https://ambience.sourcecode.ai ).

The point of that project is that you can create or use an existing repository proxies and attach to it what I called "audit policies" those are basically a list of packages/versions you want to block or allow. The default ones include for example malicious, vulnerable, yanked packages etc... (the blacklist repository) to which you point pip, poetry etc... and it will block installation of the packages listed in the audit policies attached to the repository. You can also create ad-hoc repositories or repository per project to keep it separate and operate in whitelist mode where you allow only whitelisted&audited packages.

On top of that there is also "monitor" mode where you can allow installation of any package or subsset of packages and it will capture all depedencies for purpose of tracking the software supply chain accross the company or project and those packages would be automatically scanned and audit using integration with another project of mine called Aura that is a static analysis scanner designed for the python supply chain.

As mentioned this is currently in open alpha mode so access is limited and user registration is not open (I am currently working on users&permissions for making their own repositories and audit policies) but if someone is interested in testing or this project in general or an early access to features behind the curtain feel free to shoot me an email at admin @ sourcecode.ai . The license is open source so it can be also self-hosted.

That's a cool project - I really like that it's open source and self hostable. A key thing for me would be npm package support - the nodejs ecosystem is such a dumpster fire.

Is it easy to find a list of packages that have been pulled from python/npm in the past? Would be interesting to train some models against it

What would the input to such a model be? The malicious code snippets? Or do you want to classify packages according to other meta data?

Yeah. I was wondering how easy it would be to classify using a language model/models. ALthough I don't know how it'd work with binary blobs, multiple languages, etc.

I think certain things would be picked up pretty easily e.g. obfuscated code would be a pretty loud feature, but subtle stuff might be undetected and generally I can't see the model being super accurate.

Sure. Please email me (in profile) for the list. You can also look at the following resources for malware samples:

1. https://github.com/IQTLabs/software-supply-chain-compromises 2. https://github.com/rsc-dev/pypi_malware 3. https://github.com/osssanitizer/maloss/blob/master/malware/R...

Thanks, will take a look at this - would be lovely to add something of this nature to a CI pipeline.

We've created a Github action [1]. It pulls data from our backend service https://packj.dev that continuously scans packages. You will have to create a free account.

1. https://github.com/marketplace/actions/packj-dev-audit

How do you make sure the dependencies the tool itself uses are sane to use?

By pinning versions, running Packj on deps and manual analysis :)

Reply on news.ycombinator.com