9 ms·

This seemed to be more about how to compile/decompile and obfuscate Python code then anything about malware. The two examples were the ability to take screensho

This seemed to be more about how to compile/decompile and obfuscate Python code then anything about malware. The two examples were the ability to take screenshots and make web requests were the only two actual potential malware related topics, but even those are fairly basic concepts that have a huge range of applications outside malware. These things are also fairly trivial in most even slightly mature languages. The section on eval was a little more interesting but still nothing special. Personally, and this is just my probably uninformed opinion, the biggest thing about Python that makes it useful for malware is its huge, mostly uncurated repository of libraries and addons that are easy to install and use without ever looking at it. This aspect of Python seems likely the most appealing for would be malware writers. The ease of making malicious code widely available without a lot of scrutiny.

staticassertion 6y ago
I think you're talking about something very different, which is attacking Python's supply chain. This is talking about malware payloads themselves. I don't agree that those capabilities (taking screenshots, especially eval) are trivial in other languages. Eval in particular makes things trivial since you can basically do: eval(get_payload()), which is awesome from a staging perspective - the trend in malware is to modularize more and more for a number of reasons (less code to scan for sigantures, new monetization strategies, easier to update, etc). So having the ability to do runtime, reflective module loading to trivially get a capability like screenshotting is pretty huge.
easterncalculus 6y ago
I think your last point and the article's points reflect two different contexts though. One is attacking python software with malicious libraries, while the article's context is python being used to attack any system, even systems that don't have an interpreter installed. That being said, the security of PyPi and python packaging in general is certainly another interesting topic. I like to think that so far it hasn't been as bad as NPM, but there have been backdoored packages put out onto the internet. It's bound to happen with any public software repo, and with any project that trusts outside contributors without perfect review.
- zenhack 6y ago
  PyPI's architecture isn't meaningfully different than npm's. Npm has seen more high profile incidents because: 1. Packages tend to be smaller, and the transitive dependency trees of projects corresponding larger. This means there are more single points of failure. 2. More people are using it. Python, and for that matter most language package ecosystems, have the same problems as js, but many of them have gotten away with it for a bit longer due to (lack of) scale.

staticassertion 6y ago

I think you're talking about something very different, which is attacking Python's supply chain. This is talking about malware payloads themselves. I don't agree that those capabilities (taking screenshots, especially eval) are trivial in other languages. Eval in particular makes things trivial since you can basically do: eval(get_payload()), which is awesome from a staging perspective - the trend in malware is to modularize more and more for a number of reasons (less code to scan for sigantures, new monetization strategies, easier to update, etc). So having the ability to do runtime, reflective module loading to trivially get a capability like screenshotting is pretty huge.

easterncalculus 6y ago

I think your last point and the article's points reflect two different contexts though. One is attacking python software with malicious libraries, while the article's context is python being used to attack any system, even systems that don't have an interpreter installed. That being said, the security of PyPi and python packaging in general is certainly another interesting topic. I like to think that so far it hasn't been as bad as NPM, but there have been backdoored packages put out onto the internet. It's bound to happen with any public software repo, and with any project that trusts outside contributors without perfect review.

zenhack 6y ago
PyPI's architecture isn't meaningfully different than npm's. Npm has seen more high profile incidents because: 1. Packages tend to be smaller, and the transitive dependency trees of projects corresponding larger. This means there are more single points of failure. 2. More people are using it. Python, and for that matter most language package ecosystems, have the same problems as js, but many of them have gotten away with it for a bit longer due to (lack of) scale.