Poisoned Lolip0p PyPI Packages
I thought they only poisoned candy on Halloween. On the Python Package Index, three new fake packages, colorslib, httpslib, and libhttps, have appeared with malware.
Wasn’t it only a few days ago that some vile twit placed a malware-poisoned file on the Python Package Index, masquerading as a real program? Why, yes, yes, it was! Here we go again!
Not Real Programs
This time FortiGuard team discovered a similar zero-day attack in three PyPI packages (Python Package Index) called “colorslib,” “httpslib,” and “libhttps.” These sound familiar, But, none of these are real Python programs.
So, why would anyone bother with them? Because, unlike similar PyPI attacks, the attacker, who posted them, wrote up descriptions and meta-text to make them look like legitimate programs.
Usually, the attacker doesn’t even bother. As the PyTorch Team explained about the earlier instance, “Since the PyPI index takes precedence, this malicious package was being installed instead of the version from our official repository. This design enables somebody to register a package by the same name as one that exists in a third-party index, and pip will install their version by default.”
Whoever thought that was a good idea? I’d like to talk to them.
That said, once in place, they try to run a PowerShell command with a suspicious URL. This sends the program along to another site. There, it downloads an untrustworthy executable called “Oxyz.exe.” Then, it drops another executable, “update.exe,” that runs in the folder:
In this directory, while running update.exe, it drops numerous files to the folder
And, among them, you’d find SearchProtocolHost.exe, which is the actual malware. There’s also a process that collects Discord tokens, so there’s a little information stealing going along as well.
More to Be Done
Although there were, in total, only a few hundred downloads of the treacherous trio, that’s still too many.
You may ask — I know I did — why does this keep happening to PyPI? The Python Software Foundation is trying to fix PyPI’s security. Clearly, more, much more, needs to be done.
For now, all you can do is carefully — and I mean carefully — check any new Python code before letting it anywhere near your production systems. Personally, I don’t think I add any Python code that hasn’t been around for at least a month on my systems. Let someone else find out if there’s something wrong the hard way. I don’t have the time.