F5 Networks Endpoint Inspector – Browser-to-RCE?

If a bug falls in the forest, and the vendor denies that it’s a bug, is it still a bug? ?

TL;DR?

The F5 Endpoint Inspector is an application which can be called from a web browser to scan a client for compliance.

We found it can be abused to run arbitrary code, triggered by visiting a malicious website.

There’s a few pre-requisites to get it working, and it’s a bit tougher to get it working “cleanly” (without the user having to click much).

We reported this issue to F5, who say it is “not considered a vulnerability”. So they won’t be fixing it any time soon, apparently.

Eh? Let me see?

Ok, let’s have a look at this not-a-bug:

Here’s what’s happening:

• We browse to http://naughty.website/. That website contains a “specially-crafted” f5-epi:// URI. This causes the F5 Endpoint Inspector to run.
• A UAC box pops up, obviously trying to run a process signed by the legitimate F5 Networks certificate.
• Then we get powershell.exe popping up, running as a subprocess of f5instd.exe, at high integrity (that’s with admin privileges).

To be fair, this is the “clean” version of the exploit. I’ll talk about the “dirty” version later.

F5 says it’s NOT a bug, so what’s the problem?

They say there’s too many pre-requisites for them to consider it a bug.

Here are the basic pre-requisites to not-exploit this not-a-bug:

• The affected user has to have admin privileges, so they can click through the UAC popup.
• The attacker has to have a trusted code-signing certificate to sign a malicious CAB file.

That’s all.

If you want to not-exploit the not-a-bug cleanly (with only a clean, UAC popup for an F5-signed binary), the CAB file has to be signed by “F5 Networks Inc”, “F5 Networks” or “uRoam Inc”. The f5instd.exe binary checks for those strings in the “Signer Name” field of the signature:

It’s up to you to decide how realistic it would be to get a trusted code-signing certificate with any of those names. I will say, that “uRoam Inc” may not actually exist, since F5 bought it in 2003. That’s a little tip if you fancy trying one of the more elaborate workarounds to execute arbitrary code.

However, regardless, even if the “Signer Name” in the CAB signature isn’t one of those three strings, arbitrary code will still run. The user just has to click through another warning.

This is (what I guess I’m calling) the “dirty” version:

Note: a URL whitelist pop up box usually shows up on a new site, but it’s really inconsistent

Another prompt asks the user if they really want to extract the malicious CAB file, despite the fact it’s signed by “Your Employer!” rather than F5 or uRoam.

Anyway, that’s the reason F5 say it’s NOT a bug. So I guess it’s not a bug! Don’t worry about it.

What did F5 actually say?

F5 said this to us:

Respective teams have reviewed the report you have shared and it was determined that the findings is not considered a vulnerability.

The installation popup clearly shows the signer and the name and also displays a warning message. This behavior is no different from user downloading a file from internet and clicking on it to run it in the browser.

There is no automatic privilege escalation here either. If the installation required admin rights and user does not have those, he won’t be able to install the package.

What do we say?

I think… that I…. disagree. Here’s a few questions:

• Why allow CABs signed by 3^rd party certificates at all? Blocking all 3^rd party certificate would definitely make this less easy to exploit?
• Why not check more than just the “Signer Name” field in the certificate before extracting and processing the CAB? It’s, y’know, a certificate. There’s other bits of it you can check.
• Why are you updating your software by extracting CAB files in 2019? There are better ways to do this.
• “Also, uhh, this is less of a question and more of a statement”: yes, this is different from a user downloading a file from the internet and clicking on it to run it.

On top of this, F5 are a CVE Numbering Authority (CNA). So they decide what gets given CVEs. They decide what is considered insecure in their own products.

Is there an inherent conflict of interest in having companies decide what’s a vulnerability and what’s not?

“Pls show me how to do the pwn”

I’m going to hold off on details for the minute. Maybe F5 will change their minds. Let’s see.

Timeline

23/05/2019 – Reported to F5
27/05/2019 – Confirmation of receipt from F5, key exchange
29/05/2019 – Issue given a tracking number by F5.
01/06/2019 – We check with F5 for updates.
03/06/2019 – F5 request a CVSS score estimate from us.
03/06/2019 – We share a CVSS score with them. No response.
19/06/2019 – We check for an update.
19/06/2019 – F5 reply saying it’s not an issue.