OpenSSL version on Veeam Proxy Appliance

[michaelryancook]

Hi all. This is related to Case # 02358134. Our security team recently scanned our environment and the veeam proxy appliance used in SureBackup jobs was flagged as using an older OpenSSL version that has numerous vulnerabilities. We are running Veeam B&R 9.0.0.1715. I logged into the console of the proxy and verified that version 1.0.0 is installed and that the proxy is listening on port 443. We are trying to determine if there are any updates available that would address this vulnerability? Is the same version used in 9.5?

TIA, Michael

[foggy]

Hi Michael, the version that comes with the appliance in Veeam B&R v9 and v9.5 should be OpenSSL-1.0.1i and it didn't change in the recent release.

[michaelryancook]

Hi Foggy. Ours is definitely OpenSSL-1.0.0 not 1.0.1. We have been told that we need to run OpenSSL-1.0.1u or higher so even v9.5 will not address our issue. I may have to discuss with security to see what the exploit entails to see if we can leave as is.

[foggy]

We will be updating the appliance in one of the future releases.

[michaelryancook]

Thanks Foggy

[louis8963]

Hi all,

On 02 Nov 2017, OpenSSL release a Security Advisory talking about the secutiry issue
Ref: https://www.openssl.org/news/secadv/20171102.txt

I like to know is it related to VEEAM product like VEEAM 9.5 backup & replication.

After create case on the VEEAM support.

VEEAM engineer referral and advise me open a topic here.

So, any one can help?

Thanks.

[traderma]

Hi Veeam community,

we use SureBackup to verify our Backups. Our security team regularly performs scans on our network, and noticed that the Veeam proxy appliance that is the proxy to the Veeam VirtualLab environment uses outdated apache and OpenSSL versions (we use the most recent version of Veeam B&R, 9.5.0.1922). The Veeam proxy has the following vulnerabilities:

http://www.tenable.com/plugins/index.ph ... e&id=90888
http://www.tenable.com/plugins/index.ph ... e&id=93814
http://www.tenable.com/plugins/index.ph ... e&id=78555
http://www.tenable.com/plugins/index.ph ... &id=100995
http://www.tenable.com/plugins/index.ph ... e&id=96451
http://www.tenable.com/plugins/index.ph ... &id=101788
http://www.tenable.com/plugins/index.ph ... e&id=89081

Is Veeam going to patch this in future versions? Did anybody notice this before?

Cheers from Austria
Till

[traderma]

We will be updating the appliance in one of the future releases.

When will this happen? Apparently security vulnerabilities in the Veeam proxy are known for about a year now. I'd like at least an estimate when this will be fixed, that I can relay to our security team.

[foggy]

The update had actually already happened at least once since that reply. And it will happen again with the upcoming release of Veeam B&R 9.5 U4 - proxy appliance will contain OpenSSL 1.0.2l there (this version addresses all the mentioned vulnerabilities). I'm currently checking re: Apache version.

[foggy]

The rest of the mentioned vulnerabilities will also be addressed in U4 (without updating Apache version though - it is not required).

[mcz]

Hello everybody,

we are currently testing a security tool, which scans networks and checks every found endpoint for known security vulnerabilities (based on the CVE-database).
I was a little bit surprised when this tool found several vulnerabilities on the proxy appliance which will be deployed when setting up a virtual lab (using surebackup or surereplica). Of course you could argue that this appliance shouldn't be in the production network etc. but what if you need this appliance for a test/development environment which has been setup based on the latest backup?

Another fact that surprised me a little bit was that many vulnerabilities are older/known for longer than 2 years. I thought that veeam would patch these appliances and that every update (of B&R) would ship this patched appliances - I re-deployed one appliance and found out that nothing has changed, so it looks like that the patching process isn't working as I had expected.

Finally I would like to mention that our appliances currently have 82 vulnerabilities - a quite high number while we all know that one could be enough to mess things up.

Here are some examples of found vulnerabilities:
https://ibb.co/qLSGTDf

Is veeam aware of this? Will anything change in the near future? Any advice? Thanks!

[Andreas Neufert]

Thanks, reported to our security officer.

[foggy]

Hi Michael, not sure about all of them, but at least some will be addressed in the upcoming U4, please see above. Thanks!

[Gostev]

I checked with our security lead and he's aware about these, however apparently they are not as critical as vulnerability scanners report.

For example, all of the detected Apache and TLS vulnerabilities are not applicable to Linux file level recovery, because we don't start HTTP server, and thus they cannot be used to access backed up data.

On the other hand, when SureBackup jobs are running, the vulnerabilities CAN be exploited - but in the worst case scenario, they will allow the attacker can get into the isolated virtual lab network, which cannot be consider as a critical vulnerability either, as those VMs are impossible to damage with all writes discarded when they are powered off. Besides, just updating the appliance components won't fix this issue though — the main problem is hardcoded TLS certificate in the appliance configuration, which is something we plan to remove down the road.

All in all, as it was already mentioned, Update 4 does bring updated appliance components, so vulnerability scanners will report less findings after you upgrade.

[mcz]

Anton, thank you for the clarifications.

On the other hand, when SureBackup jobs are running, the vulnerabilities CAN be exploited - but in the worst case scenario, they will allow the attacker can get into the isolated virtual lab network, which cannot be consider as a critical vulnerability either, as those VMs are impossible to damage with all writes discarded when they are powered off.

Of course you are right, the attacker won't be able to cause a lot of damage - but it is still enough for a data breach. So for me it's not really about damage but much more about stealing data...

[Gostev]

Of course you are right, the attacker won't be able to cause a lot of damage - but it is still enough for a data breach. So for me it's not really about damage but much more about stealing data...

Not sure I follow you here. You would still need valid credentials to connect to those VMs running in the virtual lab, before any data breach can actually occur... and if you have those credentials, then why bother penetrating into the virtual lab environment when you can just connect directly to the production VM instead?

[mcz]

Yeah that's true. Got a little bit confused and didn't correctly remember that the appliance just does the routing and that the vm's data is being transferred betwen NFS and hypervisor. Thanks Anton.

[IR44]

Our Surebackup lab continues to show in Tenable as vulnerable. As per CVE-2022-1292 OpenSSL vuln is fixed in version 1.0.2ze.

Any update as to when this version will be released in a VBR update?

Thanks in advance

[HannesK]

Hello,
and welcome to the forums.

As far as I see, the risk score is moderate and the SureBackup appliance is not really critical in general. So the next regular update seems to be the release vehicle (I will check that and update the post then)

Best regards,
Hannes

[HannesK]

Update: according to our security team, the vulnerability in question is not in OpenSSL itself but rather in the helper script c_rehash that is sometimes included along with OpenSSL binaries. We don't use this functionality at all and as such the vulnerable module is not included on our helper appliances — so VBR is not affected by this CVE.

[macbobs]

I raised a ticket (06132793 OpenSSL) recently for my Microsoft Windows Server 2022 VBR host as it was showing up in our Security world as having a High level set of Vulns due to out of date OpenSSL software.

I was kindly advised to update to the latest 12 patch release (P20230412) which said it used the OpenSSL ((1.0.2zg)) https://www.veeam.com/kb4420?ad=in-text-link
The 1.0.2zg version is a paid for premier contract variant. I think, and admit I find the versioning numbers and letters used by OpenSSL confusing but the latest version in that branch is now OpenSSL 1.0.2zh. It is noted that OpenSSL 1.0.2 is out of support since 1st January 2020 and is no longer receiving updates unless you are a premium support customer. Tenable also note that the zh is a bit sour as well https://www.tenable.com/plugins/nessus/173268 Scores medium rating
https://www.tenable.com/plugins/nessus/171080 and High on the zg versions mentioned used in this patch?

My issue reported on from my endpoint Microsoft Defender Security client reports it sees the server as running OpenSSL version Version 3.0.5.0 AND Version 3.0.7.0 (which confuses me) - both of which are accordingly all behind the latest variant 3.0.9 as well! My EDR client is causing my boss to grind his axe on my neck.

Anyway, is there any plans to use a different variant for the OpenSSL version in the future so Nessus stops glowing Red at me, thanks!

[HannesK]

Hello,
yes, we have premier support and can provide security updates to our customers if something comes up (we do that regularly). The "high" issue is fixed with the 1.0.2zg version (that's why we upgraded). From a technical perspective, there is no advantage of using version 3.x, but yes, there are plans to migrate to 3.x.

Best regards,
Hannes