• treadful
    link
    fedilink
    English
    arrow-up
    8
    ·
    4 days ago

    Fuck this article.

    Using publicly available AWS IP ranges, attackers identified potential targets by scanning for application vulnerabilities or misconfigurations. […] The group scanned exposed endpoints for sensitive data, including database access credentials, API keys and other security secrets

    That’s the most detailed information about the exploit in the article. And there’s no relevant external links either. Literally nothing actionable in it.

    • edric@lemm.ee
      link
      fedilink
      English
      arrow-up
      6
      ·
      4 days ago

      Applying Occam’s Razor, I assume this is publicly exposed buckets and lack of (or misconfigured) resource-based policies on those buckets, which is probably like the most common reason for these breaches.

      • treadful
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        3 days ago

        But we’ll never know because people can’t do basic reporting.

        Also, you generally don’t magically get things like API keys and database credentials from buckets. Unless your team is completely braindead.

        • edric@lemm.ee
          link
          fedilink
          English
          arrow-up
          2
          ·
          3 days ago

          you generally don’t magically get things like API keys and database credentials from buckets

          Oh you underestimate how clueless some people can be. One of the highest priority checks of cloud SOCs is to just routinely scan for public buckets, because people expose (accidentally or intentionally) stuff on their test or sandbox accounts a lot, and it’s not surprising to find keys and secrets in there. Obviously a simple SCP policy of denying API calls to make a bucket public will easily solve this problem, but then again, even big companies screw that up too.