Support ticket logs available to download without authentication

[jochot]

Hey,
it came to my attention that, when you upload logs via the webinterface while creating a support ticket, those logs are uploaded to the Amazon cloud and you'll see a link to those logs in the tickets description.
It seems that veeam knows about the fact that those might include sensitive data, as described here:
https://my.veeam.com/#/kb2462
https://download2.veeam.com/pdf/process ... upport.pdf

if you will click on this link:
https://s3.eu-west-1.amazonaws.com/cptl ... 9cbdd573dd
you will be able to download the logs from my support case ID# 03785957 without any authentication.

This to me doesn't seem in line with today's security standards (and probably GDPR etc)

I am not blaming anyone here, I just want customers to know that, when you have sensitive data in those logs (which you probably have), you might want to go with the FTP variant of uploading logs instead of the Darg&Drop option until this is fixed.

[Gostev]

From looking at the full link pasted into Notepad, it would appear that the link does contain automatically generated access credentials that only work for the particular file, thus authentication is most definitely present. So unless the customer chooses to publish the link on a public forum, how would anyone else get to know it? I mean, this is no different from posting your domain credentials, right?

Or if I'm missing something and this is not your support case, then can you clarify how did you obtain this link in the first place?

[jochot]

Well "but noone knows the way to the open backdoor" is not a really good argument from the security point of view.
If someone want's to get this information, he can just create a script and brute-force those kind of links, downloading everything he get's.
I am not saying there is NO security here, but it is VERY VERY low security. It's like having a door with a keypad and you can guess as often as you want, at some point you'll get lucky and get in.
It isn't as easy to brute-force domain accounts, for one you have a user/password instead of just a user & you (should) have security checks that locks a user when it is being brute-forced, so I think that comparison doesn't really work for me

[Gostev]

Are you serious right now re: "very very low security" and brute forcing?

I mean, did you see the length of those secrets used in the link? Also, it's definitely not "just a user", look at the link more carefully.

How familiar are you with Amazon S3 security in general? Because pre-signed URLs is the gold standard for secure S3 objects access that is relied upon by millions of Amazon users...

[paul]

jochot, it's naive to think Amazon doesn't have protection against brute-forcing... hard to imagine they`ll tolerate continuous failed authentications from the same IP address.

[jochot]

I don't see the reason why this access cannot be restricted to the veeam domain?
I see that his is the normal way of sharing stuff, but to me that is the normal way to share externally, not internally.
When I share something in Azure, I restrict to either people in the company or specific external accounts.

I agree that it is not very very low, just don't see why it should be this way, or are you sharing those logs with external people not in your company?

[Maxi]

In fact, this link will have limited lifetime as well. I think we can make this lifetime 1-3 days and this will largely remove brute force case @Gostev

[mweissen13]

IMO there is no way you could ever brute-force a random credential this long. As long as not every support case from every customer is using the same credentials there is surely nothing to worry about.

[Gostev]

I agree that it is not very very low, just don't see why it should be this way, or are you sharing those logs with external people not in your company?

Of course not, however support engineers and developers can be out of office when on duty - in the home office, on the road, etc. So ease of debug log access for them is critical and directly affects time to answer. Of course we would not sacrifice security to achieve that, however as noted above pre-signed URLs are extremely secure.

[jochot]

it's limited to 45 days afaik.
Not saying that it should be inside the company network but shared to company accounts, still available in the internet, but before accessing you need to log in with your domain credentials.
So click on the link -> authenticate with your veeam domain account -> download the file.
Tbh I don't know if Amazon supports that feature, just working with azure where you can share only to authenticated AzureAD users(or only with the link also limited to 45 days, only to specific accounts etc.).

After looking at all of this, you might get lucky with having 45 days to figure out the secret, but you're right, it's a reasonable low risk to take

[tsightler]

As far as I know pre-signed URLs can, at most, be valid for 7 days. When the URL is generated, a signing key is use to create the signature and this key has a defined lifetime which I believe can be at most 7 days. Also, if you look at the URL, the X-Amz-Expires parameter is set to 518400 which is 6 days.

https://docs.aws.amazon.com/AmazonS3/la ... -auth.html

To brute force access, someone would have to brute force the specific signature for the URL, specifically this part:

X-Amz-Signature=c25ed058e4459b35590cef30303fa55939b61629efab0107e2ebd29cbdd573dd

I'm going to say that brute forcing this is going to be an impossible task given the timeframe, I'm sure that's why the signatures have a maximum lifetime exactly to be nowhere close to the time it takes to brute force the signature.

BTW, you mention FTP, but it's not uncommon for FTP URLs to include username and password in the URL as well, and FTP password is generally much shorter than the signature above so FTP is likely may be even easier to brute force. At a bare minimum I don't need to know the full URL before I start to brute force attack an FTP server. Admittedly, most FTP server will lock out an account/IP after a handful of failed attempts.