christophetd

The malicious commit (2cd2223dcd90fa9d9c72851427602aa0e179e061) was not signed. Sorry you feel like the writing isn't frank.

If the maintainer themselves added the backdoor, can't they be considered a malicious actor?

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.

We just updated the wording. Thanks for the feedback.

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.

[1]: https://www.reddit.com/r/netsec/comments/z30465/comment/ixlj...

Hello! One of the authors of the post here. Just added a sentence in the introduction to make it crystal clear:

> While FastAPI itself is not impacted, this is an interesting occurrence of an attacker attempting to deploy a FastAPI-specific backdoor.

Appreciate your feedback!

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!

Author here - have a look at the methodology section at the bottom of the page. Feel free to ask if anything is unclear.

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!

[1]: https://securitylabs.datadoghq.com/articles/state-of-aws-clo...

Sure. My point is that Trusted Advisor is also a commercial product, as opposed to IAM Access Analyzer which is free.

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.

Hello! One of the authors here.

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!

[1]: https://securitylabs.datadoghq.com/articles/state-of-aws-clo...

[2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...

It's been taken down, but still available through https://web.archive.org/web/20211230160444/https://vpnovervi...

The tweet has been removed. Now that this has been clarified, I don't want to be a vector for spreading inaccurate information.

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.

UPDATE: GitHub CISO pointed out that GitHub did NOT take down the JNDI Exploit repository.

https://twitter.com/_mph4/status/1470343429599211528

https://twitter.com/christophetd/status/1470346676053422081

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).

[1] https://news.ycombinator.com/item?id=29538151

[2] https://github.com/github/dmca

[3] https://i.imgur.com/sJe3OTI.png