Re: [Security-announce]Incident Report: Malicious takeover of ctx project on PyPI
Takeover of the ctx project was reported on multiple channels overnight and was mitigated as of 6:07 AM Eastern.
Ee, Thanks for the quick action by the Python infrastructure and security teams. I don't normally dig into such things, but was curious. I found the incident report clear, and since the exploit was very simple and written in Python, I actually understood it. (Many hacks these days seem obscure, especially stuff involving buffer overruns or use-after-free.) But I digress. Reading the report raised a couple questions for me. 1. Would requiring 2FA for all PyPI accounts be reasonable? 2. This might seem odd, but would it also be reasonable to require accounts to be associated with a large, well-known email service provider? That second one would seem to be pretty debatable, but the odds of, say, gmail.com or outlook.com, expiring and being reregistered would seem pretty slim. It's much more likely that an individual's account would simply be hacked. Hmmm... Maybe I should just retract that idea. I think #1 might help, however. Again, thanks... Skip Montanaro
On Fri, May 27, 2022 at 9:40 AM Skip Montanaro <skip.montanaro@gmail.com> wrote:
Takeover of the ctx project was reported on multiple channels overnight and was mitigated as of 6:07 AM Eastern.
Ee,
Thanks for the quick action by the Python infrastructure and security teams. I don't normally dig into such things, but was curious. I found the incident report clear, and since the exploit was very simple and written in Python, I actually understood it. (Many hacks these days seem obscure, especially stuff involving buffer overruns or use-after-free.)
But I digress. Reading the report raised a couple questions for me.
1. Would requiring 2FA for all PyPI accounts be reasonable?
Because both GitHub ( https://github.blog/2022-05-04-software-security-starts-with-the-developer-s...) and npm ( https://github.blog/2022-05-04-software-security-starts-with-the-developer-s...) will be requiring 2FA in the future, so we are not trailblazing here. The attackers are unfortunately too relentless and vast to leave PyPI alone. Add in the fact that Python packaging does not lock Python versions and require hash verification (at least for now; I'm still trying to get this rectified), this problem will persist.
2. This might seem odd, but would it also be reasonable to require accounts to be associated with a large, well-known email service provider?
Speaking as someone sending from a personal email address, the answer is no. 😉 That might protect folks from re-registering a dead domain, but it doesn't protect against people phishing a password.
That second one would seem to be pretty debatable, but the odds of, say, gmail.com or outlook.com, expiring and being re-registered would seem pretty slim. It's much more likely that an individual's account would simply be hacked. Hmmm... Maybe I should just retract that idea.
Slim, but it's happened: https://whoapi.com/blog/5-all-time-domain-expirations-in-internets-history/ . -Brett
I think #1 might help, however.
Again, thanks...
Skip Montanaro _______________________________________________ Security-SIG mailing list -- security-sig@python.org To unsubscribe send an email to security-sig-leave@python.org https://mail.python.org/mailman3/lists/security-sig.python.org/ Member address: brett@python.org
On 5/30/22 6:56 PM, Brett Cannon wrote:
On Fri, May 27, 2022 at 9:40 AM Skip Montanaro <skip.montanaro@gmail.com <mailto:skip.montanaro@gmail.com>> wrote: 1. Would requiring 2FA for all PyPI accounts be reasonable?
Because both GitHub (https://github.blog/2022-05-04-software-security-starts-with-the-developer-s... <https://github.blog/2022-05-04-software-security-starts-with-the-developer-s...>) and npm (https://github.blog/2022-05-04-software-security-starts-with-the-developer-s... <https://github.blog/2022-05-04-software-security-starts-with-the-developer-s...>) will be requiring 2FA in the future, so we are not trailblazing here. The attackers are unfortunately too relentless and vast to leave PyPI alone. Add in the fact that Python packaging does not lock Python versions and require hash verification (at least for now; I'm still trying to get this rectified), this problem will persist.
Skip, you might also be interested in this Discourse discussion about the current state of requiring multifactor auth on PyPI: https://discuss.python.org/t/require-mfa-on-pypi/12077/28 -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
participants (3)
-
Brett Cannon -
Skip Montanaro -
Sumana Harihareswara