One of the authors of the post here. We prefer sticking to the facts rather than speculating the account was compromised without having a solid proof. Someone on /r/netsec also had an interesting theory that this might be an intentional backdoor[1].
For what it's worth, the project referred to in the post is free, open-source, and unrelated to the commercial offering.
You seem to have updated the wording to "has been backdoored by a malicious actor". Isn't that more speculation, with the tentativeness removed? What facts incline you to believe it was a malicious actor, and not the maintainer?
Yes, that's true. And I agree that there is some malicious actor; a bag of Base64-encoded code doesn't get inserted as an innocent accident. But the way you've expressed yourself, more than once, suggests you have reason to believe the malicious actor is other than the maintainer.
Do you have any evidence, one way or the other?
Let's not chop logic. I don't think you've been completely frank about this. The commit was signed by the maintainer, right, using a private key? That means the maintainer "done it", absent evidence to the contrary. And apparently the maintainer is silent.
Apologies; I am not a git user. I thought every git commit was signed, excuse my ignorance. I'm surprised something in PyPi can be shipped without any signatures, but I'm not shocked; I'm not a fan of language-specific repositories. NPM is an example of what I'm not a fan of.
> It is possible the original developer of the package had their account compromised and used by a malicious actor.
> whose maintainer's account was likely compromised by a malicious actor
Seems to still be speculating about the cause without diving deeper into the topic, or is there some cache invalidation of the article that is missing perhaps?
Yes, that would be caching. We kept the first sentence, as it's still possible his account was compromised (we have no strong evidence to prove it, but no strong evidence to refute it either).
Thanks for the heads-up, the goal was mostly avoiding that typing the author's name in Google brings up this post. I'll have it blurred for the sake of consistency, though.
Hello there! I'm one of the authors of the post. Sorry you feel we "hyped it up", that was definitely not the intent. The malicious package is targeting FastAPI applications. The point is that there are a lot of applications the attacker could attempt to target (through social engineering, malicious pull requests etc.)
Will adapt the wording to make it clearer. Thanks for the feedback!
> The point is that there are a lot of applications the attacker could attempt to target(through social engineering, malicious pull request, etc.)
If you want to discuss the potential damage an attacker can do with a GitHub account, why not hype it up even more unrealistically and talk about how they could have attacked any public repo on GitHub that accepts PRs. The article should either be limited to what actually happened or you should follow the thought through to its logical conclusion. Why do you stop when you've sufficiently scared people enough to start talking about datadog tooling?
Author here - sorry you feel like this is content marketing. I identify myself as a cloud security engineer, so that's a clear antigoal. The intent is to show what's the systematic adoption of cloud security controls _that matter_, based on real-world data breaches. We also published a follow-up post[1] with actionable advice for practitioners on how to turn on some of these mechanisms (such as S3 Public Access Block).
Would love to hear your thoughts on how we can make it "deeper" and "more accurate" in the future!
One of the authors here - confirming that "40 percent of organizations have at least one IAM user that has AWS Console access and does not have multi-factor authentication" is about IAM users and does not include the root user.
We did release some (hopefully) actionable guidance alongside the study[1].
Trusted Advisor is a fair point, but note that most of its security checks only come with the Business or above AWS support plan. IAM Access Analyzer is a great service but it currently supports only 6 resource types[2].
We'll look into adding both, appreciate the feedback!
I made wrong assumptions when writing this tweet. I clarified this on Twitter. Apologies for the confusion. Not sure if it makes sense to delete the tweet / thread.
This is surprising, considering what is outlined in a previous comment[1]. I hope GitHub provides more transparency on the takedown actions for "malicious content / exploits" like they do for DCMA notices[2].
Apologies for making wrong assumptions. I removed the original Tweet (see screenshot[3] for the original).
For what it's worth, the project referred to in the post is free, open-source, and unrelated to the commercial offering.
[1]: https://www.reddit.com/r/netsec/comments/z30465/comment/ixlj...