5 ms·

The article tries to play up the AI angle, but this was a pretty standard misconfiguration of a storage token. This kind of thing happens shockingly often, and

The article tries to play up the AI angle, but this was a pretty standard misconfiguration of a storage token. This kind of thing happens shockingly often, and it’s why frequent pentests are important.

cj 3y ago
> it’s why frequent pentests are important. Unfortunately a lot of pen testing services have devolved into "We know you need a report for SOC 2, but don't worry, we can do some light security testing and generate a report for you in a few days and you'll be able to check the box for compliance" Which is guess is better than nothing. If anyone works at a company that does pen tests for compliance purposes, I'd recommend advocating internally for doing a "quick, easy, and cheap" pen test to "check the box" for compliance, _alongside_ a more comprehensive pen test (maybe call it something other than a "pen test" to convince internal stakeholders who might be afraid that a 2nd in depth pen test might weaken their compliance posture since the report is typically shared with sales prospects) Ideally grey box or white box testing (provide access to codebase / infrastructure to make finding bugs easier). Most pen tests done for compliance purposes are black-box and limit their findings as a result.
- dylan604 3y ago
  I recently ran into something along the lines of your devolved pentest concept. I have a public facing webapp, and the report came back with a list of "critical" issues that are solved by yum update. Nothing about vulnerability to session jacking or anything along the lines of requiring actual work. I was a few steps removed from the actual testing, so who knows what was lost in translation and it being the first time I've ever had something I worked on pen tested. However, I feel this was more of a script kiddie port scan level of effort vs actually trying to provide useful security advice. The whole process was very disappointing.
  - im3w1l 3y ago
    How behind on yum updates were you anyway?
    - dylan604 3y ago
      not very. i guess i was too cavalier in hand waving it as a yum update. some of it was switching to a new repo with the most recent version available. but that was still just using yum. not like it required changes to the code base and workflow. maybe it was an amazon-linux-extras command for the actual package change, but still.
  - alaxapta7 3y ago
    I've seen worse. Couple years back, there was an audit that included an internal system I've been working on. It was running on Debian oldstable because of a vital proprietary library I wasn't able to get working on stable at the time, but it had unattended upgrades set up and all that. The company made some basic port scan and established that we're running outdated and vulnerable version of Apache. I found the act of explaining the concept of backports to a "pentester" to be physically painful. They didn't get paid and another company was entrusted with the audit.
    - pixl97 3y ago
      This is why I always attempt to turn off as much version information output as possible from any service. Make the pentester do their homework and not just look at "Apache 2.XX" Hopefully you also have an internal control that looks at actual package versions installed on the server.
      - dylan604 3y ago
        This is actually a take away that I did implement. it's one of those that's not actively a vuln, but might provide info on what other attacks to try.
      - alaxapta7 3y ago
        Normally I do that too, but this was fairly new and internal application that was still in development, so that's why it was there. And if it wasn't for this incident, they might actually trick our management into thinking they're somehow qualified to carry out such an audit.
- oooyay 3y ago
  Narrowly scoped tests designed for specific compliance requirements are fine. They lower the barrier to entry to some degree for even getting testing and still, or often enough, return viable results. There's also SAAS companies that have emerged that effectively run a scripted analysis of cloud resources. The two together are more economical and still accomplish the goals that having compliance in the first place sets out. When I was consulting architecture and code review were separate services with a very different rate from pentesting. Similar goals but far more expensive.
mymac 3y ago
Pentests where people actually get out of bed to do stuff (read code, read API docs etc) and then try to really hack your system are rare. Pentests where people go through the motions, send you report with a few unimportant bits highlit while patting you on the back for your exemplary security so you can check the box on whatever audit you're going through are common.
- iamflimflam1 3y ago
  Yep, most pentests go through the OWASP list and call it done.
  - ganoushoreilly 3y ago
    The problem is that is what most companies want. They don't want to spend the money nor get the feedback beyond "Best case standards". It's a calculated risk.
  - Faelian2 3y ago
    Honestly, the OWASP top ten is generic enough that most vulnerability fit in it : "injection", "security misconfiguration", "insecure design". The problem is 1. knowing the gazillion of web vulnerabilities, and technologies 2. being good enough to tests them 3. kick yourself and go through the laborious process of understand and test every key feature of the target.
  - fomine3 3y ago
    It's great if it's done exhaustively
- j245 3y ago
  From my understanding as a non security expert: Pentest comes across more as checking all the common attack vectors don’t exist. Getting out of bed to do the so-called “real stuff” is typically called a bug bounty program or security researching. Both exist and I don’t see why most companies couldn’t start a bug bounty program if they really cared a lot about the “real stuff”
trebligdivad 3y ago
How would a pentest find that? Ok in this case it's splattered onto github; but the main point here is that you might have some unknown number of SAS tokens issued to unknown storage that you probably haven't any easy way to revoke.
- sillysaurusx 3y ago
  A number of ways, including: - finding the token directly in the repo - reviewing all tokens issued
  - phatskat 3y ago
    Did you read TFA? It does mention AI, and also mentions that this is less about AI and more about the fact that the AI researchers had a TON of data to share, and their method for doing so was poorly configured SAS tokens… Which also, in the article, is mentioned can not be tracked - issued tokens happen on the client side (if I understood this correctly), which means that to audit tokens you’d have to ask everyone who had one issued to politely provide said token. Will everyone remember the tokens they have? Probably not. And if an attacker has already gotten what they needed, or managed to issue their own, no one would know.
acdha 3y ago
It didn’t seem to be focused on AI except for the very reasonable concerns that AI research involves lots of data and often also people without much security experience. Seeing things like personal computer backups in the dump immediately suggests that this was a quasi-academic division with a lot less attention to traditional IT standards: I’d be shocked if a Windows engineer could commit a ton of personal data, passwords, API keys, etc. and first hear about it from an outside researcher.
doctorpangloss 3y ago
Cloud buckets have all sorts of toxic underdevelopment of features. They play make believe that they're file systems for adoption. Like for starters, why is it so hard to determine effective access in their permissions models? Why is the "type" of files so poorly modeled? Do I ever allow people to give effective public access to a file "type" that the bucket can't understand? For example, what is the "type" of code? It doesn't have to be this big complex thing. The security scanners GitHub uses knows that there's a difference between code with and without "high entropy strings" aka passwords and keys. Or if it looks like data:content/type;base64, then at least I know it's probably an image. What if it's weird binary files like .safetensors? Someone here saying you might "accidentally" release the GPT4 weights. I guess just don't let someone put those on a public-resolvable bucket, ever, without an explicit, uninherited manifest / metadata permitting that specific file. Microsoft owns the operating system! I bet in two weeks, the Azure and Windows teams can figure out how to make a unified policy manifest / metadata for NTFS & ReFS files that Azure's buckets can understand. Then again, they don't give deduplication to Windows 11 users, their problem isn't engineering, it's the financialization of essential security features. Well jokes on you guys, if you make it a pain for everybody, you make it a pain for yourself, and you're the #1 user of Azure.
sneak 3y ago
It was so common that S3 added several features to make it really, really hard to accidentally leave a whole bucket public. Looks like Azure hasn't done similarly.
- mcast 3y ago
  Is there any valid use case for when it's a good idea to publicly expose a S3 bucket?
  - sneak 3y ago
    Sharing of datasets, disk images, ISOs, ML models, etc, as well as public websites.
xbar 3y ago
AI data is highly centralized and not stored in a serially-accessed database, which makes it unusual inasmuch as 40TB of interesting data does not often get put into a single storage bucket.

cj 3y ago

> it’s why frequent pentests are important. Unfortunately a lot of pen testing services have devolved into "We know you need a report for SOC 2, but don't worry, we can do some light security testing and generate a report for you in a few days and you'll be able to check the box for compliance" Which is guess is better than nothing. If anyone works at a company that does pen tests for compliance purposes, I'd recommend advocating internally for doing a "quick, easy, and cheap" pen test to "check the box" for compliance, _alongside_ a more comprehensive pen test (maybe call it something other than a "pen test" to convince internal stakeholders who might be afraid that a 2nd in depth pen test might weaken their compliance posture since the report is typically shared with sales prospects) Ideally grey box or white box testing (provide access to codebase / infrastructure to make finding bugs easier). Most pen tests done for compliance purposes are black-box and limit their findings as a result.

dylan604 3y ago
I recently ran into something along the lines of your devolved pentest concept. I have a public facing webapp, and the report came back with a list of "critical" issues that are solved by yum update. Nothing about vulnerability to session jacking or anything along the lines of requiring actual work. I was a few steps removed from the actual testing, so who knows what was lost in translation and it being the first time I've ever had something I worked on pen tested. However, I feel this was more of a script kiddie port scan level of effort vs actually trying to provide useful security advice. The whole process was very disappointing.
- im3w1l 3y ago
  How behind on yum updates were you anyway?
  - dylan604 3y ago
    not very. i guess i was too cavalier in hand waving it as a yum update. some of it was switching to a new repo with the most recent version available. but that was still just using yum. not like it required changes to the code base and workflow. maybe it was an amazon-linux-extras command for the actual package change, but still.
- alaxapta7 3y ago
  I've seen worse. Couple years back, there was an audit that included an internal system I've been working on. It was running on Debian oldstable because of a vital proprietary library I wasn't able to get working on stable at the time, but it had unattended upgrades set up and all that. The company made some basic port scan and established that we're running outdated and vulnerable version of Apache. I found the act of explaining the concept of backports to a "pentester" to be physically painful. They didn't get paid and another company was entrusted with the audit.
  - pixl97 3y ago
    This is why I always attempt to turn off as much version information output as possible from any service. Make the pentester do their homework and not just look at "Apache 2.XX" Hopefully you also have an internal control that looks at actual package versions installed on the server.
    - dylan604 3y ago
      This is actually a take away that I did implement. it's one of those that's not actively a vuln, but might provide info on what other attacks to try.
    - alaxapta7 3y ago
      Normally I do that too, but this was fairly new and internal application that was still in development, so that's why it was there. And if it wasn't for this incident, they might actually trick our management into thinking they're somehow qualified to carry out such an audit.
oooyay 3y ago
Narrowly scoped tests designed for specific compliance requirements are fine. They lower the barrier to entry to some degree for even getting testing and still, or often enough, return viable results. There's also SAAS companies that have emerged that effectively run a scripted analysis of cloud resources. The two together are more economical and still accomplish the goals that having compliance in the first place sets out. When I was consulting architecture and code review were separate services with a very different rate from pentesting. Similar goals but far more expensive.

mymac 3y ago

Pentests where people actually get out of bed to do stuff (read code, read API docs etc) and then try to really hack your system are rare. Pentests where people go through the motions, send you report with a few unimportant bits highlit while patting you on the back for your exemplary security so you can check the box on whatever audit you're going through are common.

iamflimflam1 3y ago
Yep, most pentests go through the OWASP list and call it done.
- ganoushoreilly 3y ago
  The problem is that is what most companies want. They don't want to spend the money nor get the feedback beyond "Best case standards". It's a calculated risk.
- Faelian2 3y ago
  Honestly, the OWASP top ten is generic enough that most vulnerability fit in it : "injection", "security misconfiguration", "insecure design". The problem is 1. knowing the gazillion of web vulnerabilities, and technologies 2. being good enough to tests them 3. kick yourself and go through the laborious process of understand and test every key feature of the target.
- fomine3 3y ago
  It's great if it's done exhaustively
j245 3y ago
From my understanding as a non security expert: Pentest comes across more as checking all the common attack vectors don’t exist. Getting out of bed to do the so-called “real stuff” is typically called a bug bounty program or security researching. Both exist and I don’t see why most companies couldn’t start a bug bounty program if they really cared a lot about the “real stuff”

trebligdivad 3y ago

How would a pentest find that? Ok in this case it's splattered onto github; but the main point here is that you might have some unknown number of SAS tokens issued to unknown storage that you probably haven't any easy way to revoke.

sillysaurusx 3y ago
A number of ways, including: - finding the token directly in the repo - reviewing all tokens issued
- phatskat 3y ago
  Did you read TFA? It does mention AI, and also mentions that this is less about AI and more about the fact that the AI researchers had a TON of data to share, and their method for doing so was poorly configured SAS tokens… Which also, in the article, is mentioned can not be tracked - issued tokens happen on the client side (if I understood this correctly), which means that to audit tokens you’d have to ask everyone who had one issued to politely provide said token. Will everyone remember the tokens they have? Probably not. And if an attacker has already gotten what they needed, or managed to issue their own, no one would know.

acdha 3y ago

It didn’t seem to be focused on AI except for the very reasonable concerns that AI research involves lots of data and often also people without much security experience. Seeing things like personal computer backups in the dump immediately suggests that this was a quasi-academic division with a lot less attention to traditional IT standards: I’d be shocked if a Windows engineer could commit a ton of personal data, passwords, API keys, etc. and first hear about it from an outside researcher.

doctorpangloss 3y ago

Cloud buckets have all sorts of toxic underdevelopment of features. They play make believe that they're file systems for adoption. Like for starters, why is it so hard to determine effective access in their permissions models? Why is the "type" of files so poorly modeled? Do I ever allow people to give effective public access to a file "type" that the bucket can't understand? For example, what is the "type" of code? It doesn't have to be this big complex thing. The security scanners GitHub uses knows that there's a difference between code with and without "high entropy strings" aka passwords and keys. Or if it looks like data:content/type;base64, then at least I know it's probably an image. What if it's weird binary files like .safetensors? Someone here saying you might "accidentally" release the GPT4 weights. I guess just don't let someone put those on a public-resolvable bucket, ever, without an explicit, uninherited manifest / metadata permitting that specific file. Microsoft owns the operating system! I bet in two weeks, the Azure and Windows teams can figure out how to make a unified policy manifest / metadata for NTFS & ReFS files that Azure's buckets can understand. Then again, they don't give deduplication to Windows 11 users, their problem isn't engineering, it's the financialization of essential security features. Well jokes on you guys, if you make it a pain for everybody, you make it a pain for yourself, and you're the #1 user of Azure.

sneak 3y ago

It was so common that S3 added several features to make it really, really hard to accidentally leave a whole bucket public. Looks like Azure hasn't done similarly.

mcast 3y ago
Is there any valid use case for when it's a good idea to publicly expose a S3 bucket?
- sneak 3y ago
  Sharing of datasets, disk images, ISOs, ML models, etc, as well as public websites.

xbar 3y ago

AI data is highly centralized and not stored in a serially-accessed database, which makes it unusual inasmuch as 40TB of interesting data does not often get put into a single storage bucket.