Now that's interesting, I initially read this article using Firefox's reader mode. Turns out the article is a lot longer than presented in reader mode (8 of 21 paragraphs), hence my comment. The detail is after the part I was presented, had you not mentioned the technique used I wouldn't have known.
I understand how one would use YARA rules to identify that there's a file in VirusTotal containing secrets. What I don't get is whether there's a way for an actor to actually get the content of that file.
The scale of incompetence in our industry should be embarassing. You can also see it in the public statements made by some SV 'leaders' - what other industry has prominent people making fools of themselves like that? Is it a surprise that their products are poorly made or often scams? When people tell you who they are, believe them!
If you want to see something scary, look at the fake story Demirkapi managed to post, and note the domain name - actually nytimes.com! (IMPORTANT: The story is not real!)
Mostly because we are an immensely ignorant industry jealously guarding what little scraps of knowledge we gleam.
Theoretical computer science results get ignored for decades, until people like Carmack randomly sit down and read a book. (The rest of the world then gets to read about it years later in a biography, and it's still revolutionary since nobosy else sat down to read a book in the meantime.)
A lot of institutions know how to write efficient, safe software, but at best will talk about it in a blog post, their experience will never filter down into classes to teach the next generation.
And because that's not bad enough, we try to suffocate every possible problem with "more headcount", since that's easier than actually figuring out what your core problem is.
I think most computer science is inaccessible to the average programmer, who can't read and understand a mathematical proof either.
That's not to say the average programmer is a dunce. The opposite. It's simply that science and theorems are part of scientific discourse. They are usually not complete proofs and come with nuanced caveats and limitations.
It takes someone with scientific training and discipline to take that, and turn it into a feature for some IT product.
Not your average programmer. I don't think it's realistic at all to expect the IT industry at large to do these things.
That's what industry- and field- standards bodies used to do. They provided guidance and examples in that can be applied by the average programmer. These used to be sponsored by companies in their respective fields. But these days the focus is more on open source. Which has its own advantages and disadvantages.
I think the metric used to be every five years. If that's gone up to every two years that would be interesting. Do you have some sources for this? Five years is bad enough btw.
But in the end you get what you pay for in this industry. Programming jobs pay pretty well of course, which is because there is both scarcity and a lot of demand for them. Experience is even more scarce and not all companies are willing to pay for it. But mostly the issue is really companies trying to do things on unrealistic budgets with people that aren't necessarily very good at what they do.
I'm actually turning 50 in a few months. I recently got to work with people that are actually older than me, which is very unusual for me. Usually I'm the oldest in the room and at this point old enough to be some people's daddy even. I worked with a few interns 30 years younger than me recently, for example.
Mostly I actually prefer working with young people over older people in my teams. More mental agility and less set in their ways. I actually hate that in myself when I catch myself. Mostly older doesn't necessarily mean wiser.
I disagree with the calls for regulation here btw. The issue is not with engineers but with their employers not willing to pay for them to do better. There are plenty of certifications, security reviews, etc. that you can pay for. The issue is companies not doing that, skipping it, or treating it as a box ticking exercise and generally not taking it seriously. This stuff doesn't necessarily lead to good engineering decisions. Most banks are a good example of lots of ass coverage in that form combined with lots of technical debt. They buy plausible deniability, not better engineering.
> I disagree with the calls for regulation here btw. The issue is not with engineers but with their employers not willing to pay for them to do better.
Wouldn't regulations compel the employers to pay for better quality? I thought that was the most common need for and benefit of regulations.
Aerospace, I imagine. Boeing and ULA sent some astronauts up and can’t bring them back home. Meanwhile their execs are on Twitter telling us how SpaceX engines are incomplete while they’re actually firing.
He used retrohunt service which is part of virustotal https://virustotal.readme.io/docs/searching a service that allows developers to scan files for vulnerability. Apparently, virus total stores files and allows third parties to rescan these files later. Sounds like a vulnerability of this service and terrible practice. How can you expose your user files to any arbitrary access? Of course you should not put your secrets into file you upload to some virus scan, but how many users know that file they upload will be accessible publicly?
Your link just says they store the scam result which can be accessed without submitting the file.
>VirusTotal stores the analyses and report. This allows users to query for reports given an MD5, SHA1, SHA256 or URL and render them without having to resubmit the items (whether URLs or files) for scanning
> Demirkapi turned to Amazon Web Services, but the company refused to provide him with access to existing private reporting tools. “We believe firmly that customer credentials, including security keys, belong solely to customers. AWS does not grant external users access to manage or revoke security keys as that would violate security policies and erode customer trust,” says Aisha Johnson, an AWS spokesperson
AWS's response seems muddled. To make sure that "customer credentials [...] belong solely to customers" surely you would typically want an endpoint to revoke exposed secret keys?
Exposed secret keys is not a technological problem, not really. It doesn't belong to the category of problems you solve with automated decision making. I leave it to the reader to imagine how automated decision making would play out here.
But they should accept feedback about exposed secret keys through some way where a responsible person in company could act on it.
> I leave it to the reader to imagine how automated decision making would play out here
Could you elaborate? Many other services have automated revocation, either through scanning for exposed keys or offering an endpoint to submit keys to, and as far as I can tell the way it has played out is in successful warning of and prevention of many leaks. I don't see how lack of it can be justified as a "security" measure.
Keys should have sufficient bits of entropy to not be guessable. And if a malicious actor can guess a key, you should want it revoked as opposed to them doing more serious damage through other endpoints.
28 comments
[ 3.3 ms ] story [ 72.4 ms ] threadTL;DR a security researcher found lots of common security issues by using alternative data sources.
If you want to see something scary, look at the fake story Demirkapi managed to post, and note the domain name - actually nytimes.com! (IMPORTANT: The story is not real!)
https://web.archive.org/web/20230330043732/https://intl.prd....
Again, that's not real. But if the hacker tried, lots of people could react long before they realize it.
We are still a very inexperienced and unregulated industry.
Theoretical computer science results get ignored for decades, until people like Carmack randomly sit down and read a book. (The rest of the world then gets to read about it years later in a biography, and it's still revolutionary since nobosy else sat down to read a book in the meantime.)
A lot of institutions know how to write efficient, safe software, but at best will talk about it in a blog post, their experience will never filter down into classes to teach the next generation.
And because that's not bad enough, we try to suffocate every possible problem with "more headcount", since that's easier than actually figuring out what your core problem is.
That's not to say the average programmer is a dunce. The opposite. It's simply that science and theorems are part of scientific discourse. They are usually not complete proofs and come with nuanced caveats and limitations.
It takes someone with scientific training and discipline to take that, and turn it into a feature for some IT product.
Not your average programmer. I don't think it's realistic at all to expect the IT industry at large to do these things.
That's what industry- and field- standards bodies used to do. They provided guidance and examples in that can be applied by the average programmer. These used to be sponsored by companies in their respective fields. But these days the focus is more on open source. Which has its own advantages and disadvantages.
But in the end you get what you pay for in this industry. Programming jobs pay pretty well of course, which is because there is both scarcity and a lot of demand for them. Experience is even more scarce and not all companies are willing to pay for it. But mostly the issue is really companies trying to do things on unrealistic budgets with people that aren't necessarily very good at what they do.
I'm actually turning 50 in a few months. I recently got to work with people that are actually older than me, which is very unusual for me. Usually I'm the oldest in the room and at this point old enough to be some people's daddy even. I worked with a few interns 30 years younger than me recently, for example.
Mostly I actually prefer working with young people over older people in my teams. More mental agility and less set in their ways. I actually hate that in myself when I catch myself. Mostly older doesn't necessarily mean wiser.
I disagree with the calls for regulation here btw. The issue is not with engineers but with their employers not willing to pay for them to do better. There are plenty of certifications, security reviews, etc. that you can pay for. The issue is companies not doing that, skipping it, or treating it as a box ticking exercise and generally not taking it seriously. This stuff doesn't necessarily lead to good engineering decisions. Most banks are a good example of lots of ass coverage in that form combined with lots of technical debt. They buy plausible deniability, not better engineering.
Wouldn't regulations compel the employers to pay for better quality? I thought that was the most common need for and benefit of regulations.
>VirusTotal stores the analyses and report. This allows users to query for reports given an MD5, SHA1, SHA256 or URL and render them without having to resubmit the items (whether URLs or files) for scanning
AWS's response seems muddled. To make sure that "customer credentials [...] belong solely to customers" surely you would typically want an endpoint to revoke exposed secret keys?
But they should accept feedback about exposed secret keys through some way where a responsible person in company could act on it.
Could you elaborate? Many other services have automated revocation, either through scanning for exposed keys or offering an endpoint to submit keys to, and as far as I can tell the way it has played out is in successful warning of and prevention of many leaks. I don't see how lack of it can be justified as a "security" measure.