CVE-2019-16701

kiokoman

the first thing I saw was the code at packetstormsecurity.com
the first thing i noticed was
"--rhost", help = "Target Uri https://127.0.0.1"
"--password", help = "pfsense Password"
and i say to myself .. wtf

JeGr

@kiokoman said in CVE-2019-16701:

and i say to myself .. wtf

Indeed. But that could have been credentials from a non-priv user. Then it would be some sort of priv-escalation, but even then: calling it remote code execution was ambitious at best :) No one says the whole project is bug-free. But if you find some serious shit like a RCE - you call the vendor before writing some half-assed CVE. Or you post that at darknet forums to become famous and get that zero$day$$$ money. But posting it publicly without alerting the vendor? That's just bad style.

guardian

@dennis_s Can someone please explain this?

I had a look at:
link text

and I'm not sure what is going on here.

Remote host: https://127.0.0.1 - Is this code supposed to be running on the pfSense box?

I'm not a dev, but unsanitized eval() is far from best practice! Is this actually what is going on?

What are the RPC calls? Is this someone fuzzing the webGUI with a known username and password?

Is this a warning about some settings in pfSense that might inadvertently be set incorrectly?

If this is total BS, what is being done to get this out of the CVE database? It is giving pfSense (I assume unfairly) a bad name.

kiokoman

it's total BS i'm still trying to understand how it could be identified as a remote exploit
no one have the webgui exposed to the wan so you can't exploit from there
you can use that script from the LAN (the 127.0.0.1 is only an example, you can change it with the LAN ip of pfsense) but you must know username and password... also most of us have the webgui accessible only from a specific interface/vlan used for management
you can try to bruteforce the password (also total BS) and the possibility of not being discovered in the meantime is very low.
maybe you can use it on a new, unconfigured pfsense and from the LAN interface

jimp

@guardian said in CVE-2019-16701:

@dennis_s Can someone please explain this?

We already have, a few times. Here, on Reddit, Twitter, etc. It's bunk.

I had a look at:
link text

and I'm not sure what is going on here.

Someone completely misunderstood the purpose of the page and how privileges work.

Remote host: https://127.0.0.1 - Is this code supposed to be running on the pfSense box?

That's just their example, it could be anywhere that is capable of reaching the GUI process.

I'm not a dev, but unsanitized eval() is far from best practice! Is this actually what is going on?

It's necessary for XMLRPC sync between HA nodes so certain code can be run by the primary on the secondary node, for example. It requires either admin user access or a user that has been specifically granted access to the page.

What are the RPC calls? Is this someone fuzzing the webGUI with a known username and password?

It's code for HA sync and related actions. And as mentioned previously, it doesn't matter what the user is unless it's admin or a special user granted specific access to this function. Users do not get access to it by default.

Is this a warning about some settings in pfSense that might inadvertently be set incorrectly?

There are already warnings about privileges that effectively grant admin-level access, visible on the privilege assignment screens. Though this particular privilege doesn't have that warning in release versions yet.

If this is total BS, what is being done to get this out of the CVE database? It is giving pfSense (I assume unfairly) a bad name.

I'm not sure what, if anything, can be done. There have been BS reports before, and I'm sure there will be in the future. It was removed from exploitdb not long after it was posted, at least.

guardian

@jimp said in CVE-2019-16701:

We already have, a few times. Here, on Reddit, Twitter, etc. It's bunk.

Thanks for taking the time @jimp .... IIUC then:

Unless you have the WebGUI accessable from the WAN, then no one can access the RPC from the WAN -- Therefore it is not a REMOTE exploit.
Unless you have the admin password or the password for a specially configured user, then this can not be used -- If an attacker has the admin password, it's game over anyway!
Other than the default admin user, it would take deliberate action to configure a user that could execute the RPC, and there are warnings on the page so that a noob didn't do it without some awareness that it was happening.

As you said, not really any more dangerous than the WebGUI....

Only thing might be a good thing to rate limit bad password attempts to prevent brute force attacks.... but again, if it's only on the LAN, the risk is limited to an already compromised network.

KOM

@guardian said in CVE-2019-16701:

Only thing might be a good thing to rate limit bad password attempts to prevent brute force attacks....

System - Advanced - Admin Access - Login Protection

KOM

For some reason, in this specific forum we can post but we can't edit or delete our own posts.

guardian

@KOM said in CVE-2019-16701:

@guardian said in CVE-2019-16701:

Only thing might be a good thing to rate limit bad password attempts to prevent brute force attacks....

System - Advanced - Admin Access - Login Protection

Thanks... I didn't realize that was there, and it appears to be set by default to 3 bad attempts/30 minutes...

Does this apply to the RPC calls? If so, then brute force attacks are a total non-issue unless you have a very stupid/weak password.

kiokoman

@KOM
indeed, we must be careful about what we write or it could be the end

jimp

@guardian said in CVE-2019-16701:

Unless you have the WebGUI accessable from the WAN, then no one can access the RPC from the WAN -- Therefore it is not a REMOTE exploit.

Technically if it's possible from any system other than the firewall itself, it can be considered "remote" since it's not a "local" exploit, and it can happen across the network. Though you are correct in that there is no danger unless you have (foolishly) opened your GUI to the world.

Unless you have the admin password or the password for a specially configured user, then this can not be used -- If an attacker has the admin password, it's game over anyway!

Exactly. If you grant a user permission to run remote commands, don't be surprised when they can run remote commands.

Other than the default admin user, it would take deliberate action to configure a user that could execute the RPC, and there are warnings on the page so that a noob didn't do it without some awareness that it was happening.

There are more warnings now about the permission in general, but yes. And there are a number of permissions that could also give someone access to perform admin-level operations (such as granting permission to access diag_command.php). That said, some people do select-all on the permissions list not knowing what they are doing. There is no more danger from this specific page than others they would also grant access for when making that mistake, however.

Only thing might be a good thing to rate limit bad password attempts to prevent brute force attacks.... but again, if it's only on the LAN, the risk is limited to an already compromised network.

That is already done via sshguard, though there are improvements there on the current development code to ensure the XMLRPC auth failures get caught along with other bad auth attempts.

Oliver12

if you find some serious shit like a RCE - you call the vendor before writing some half-assed CVE. Or you post that at darknet forums to become famous and get that zero$day$$$ money. But posting it publicly without alerting the vendor? That's just bad style.