Closed colindean closed 12 months ago
Some more resources:
https://adamtheautomator.com/azure-sas-token/
https://improvado.io/docs/how-to-generate-an-azure-sas-token
I think the challenge here is that it's effectively a set of URL query parameters and they could be in any order.
It looks like from the screenshots I'm seeing of tokens and tables that there are
sv ss srt sp se sr st spr sig
query parameters, and these are required:
sv sig
and some others that may be required:
se sp sr
It seems like it might be OK to look for core.windows.net
on the same line but that then binds tightly to the public Azure storage…
I think this one is tricky since the researchers intended to share the link, they just messed up the privileges on the link that they shared. There are tools that can try to detect this, but they're what I'd call "active scanners", meaning they actually reach out and try to make requests to the URLs and try to determine if they're over-provisioned. However ripsecrets is intentionally not an active scanner since that opens up a huge surface area of potentially vulnerabilities that just haven't yet been exploited in other secret scanning tools :-)
On the heels of this wild news about Microsoft leaking 38 TB of data because of a committed SAS token, maybe ripsecrets could audit for that, too.
https://learn.microsoft.com/en-us/azure/ai-services/translator/document-translation/how-to-guides/create-sas-tokens?tabs=Containers
Here are some examples from that doc:
Looks like the presence of
sv
with an ISO date andsig
query params, and sig is base64 encoded.Adding these URLs to the end of
test/one_per_line/azure
reflects that ripsecrets doesn't already catch them.