Hello and welcome to the Monday, October 17th, 2020 edition of the Sandsenet Storm Center's

Stormcast. My name is Johannes Ulrich, and today I'm back in Jacksonville, Florida.

First of all, an apology that on Thursday due to time zone issues, I recorded a Friday podcast

actually quite early. Turns out,

well, it was too early as we had an important update to the 40 OS 40 proxy vulnerability just after I

recorded. As announced earlier in the week, Horizon 3 AI released then later on Thursday,

a technical deep dive and proof-of-concept exploit.

Well, soon after that, we did actually see exploit attempts hitting our honeypots

that matched what Horizon 3 published.

As usual, at this point, you should consider vulnerable devices that are exposed already exploited, do not just patch, but investigate devices if there is any evidence of compromise.

The root cause of the vulnerability is, yet again, we had this with F5,

we had this with VMware, where web servers and web applications just trust headers that

proxies are supposed to set. And yet again, these headers are controlled by the attacker,

and with that authentication and access control is bypassed.

So it's part of normal operation. A proxy receives the request, then pass it on to the application,

but the application implicitly trusts any request with a client IP of 1-27-001 and a user agent of report runner, which is easily set by

the attacker.

And that user agent report run is exactly what we're seeing in some of the exploit requests

against our honeypots, the blog points out again the similarity to what we saw with F5 and VMB.

The end result is that this vulnerability is an authentication bypass for the rest API, so the attacker can do whatever the rest API allows them to do.

One of the features that's exposed here is the ability to add an ZH key to the authorized keys file on the system.

And that's exactly what the proof of concept exploit that Horizon 3 published does.

...