Ubersicht is Exploitable
mister-infinity opened this issue · comments
On https://github.com/BoofSec/Ubersicht-rce-0day there is a tool available which says Uberischt is Vulnerable.
thanks for reporting, I will look into it!
do you know this group btw - trying to figure out if they would respond positively to questions.
I don't know this group. Tested the code and it looks like they are sending a post request to http://127.0.0.1:41416/run with a header added: (name) origin (value) http://127.0.0.1:41416. This authenticates the original request. After a succesful post you can add a command to the POST request which results in a RCE.
indeed, but the server only listens on loopback, so this should not be exploitable unless you already have access to the machine
indeed, but the server only listens on loopback, so this should not be exploitable unless you already have access to the machine
Sounds good, didn't test it yet. I'm blocking 41416 for external requests in the firewall ( just to be sure ).
If I send you a link to a malicious site which uses JS fetch('http://127.0.0.1:41416/run'), is that not then RCE?
The request should not succeed: the server checks the origin header, which can't be spoofed from within the browser
if you have evidence to the contrary please let me know so I can patch it 😅
Is this still a thing? If I click on the link it opens up the widgets in my browser. I'm not deep enough into web development to be able to say that shouldn't happen if you check the origin header on the "server side"/application side.
@Rincewind34 if you open http://127.0.0.1:41416 you will see your widgets, indeed and they will be working. The site is only visible to you and the content is controlled by the widgets you install.
However, if you visit http://some.malicous.site.com (as an example) it should not be able to make post request to http://127.0.0.1:41416/run
Thanks for the explanation!
Thank you for your work on this great software!
I had independently discovered the locally running server being open, and, while researching it, came across this issue in the repository. I think I have identified a legitimate threat: privilege escalation from localhost in such scenarios as multiple users on the same system, users logged in via ssh, etc. I have taken the liberty to implement some additional layers of protection within Übersicht to help mitigate these threats.
The first measure is port randomization. Since the server runs currently on a known port, it is trivial to target. By randomizing the port, the naïve attack can be prevented. This comes with the caveat that the CORS proxy will also be unpredictable. One idea, which requires some changes to widgets, would be to provide the CORS proxy port somehow in JavaScript land (for example, the uebersicht object might be a good place).
The second idea is to authorize requests using a shared token randomly generated at startup. This is completely transparent to all widgets. However, this requires the use of some APIs that are only available from macOS 10.13+.
The pull requests are currently in draft right now, since they are not in their final form. Let me know what you think so far at your convenience.
@execjosh thanks for looking into this! For my understanding, how would a privilege escalation look like - I think I can picture it, but just to double check my understanding.
I have implemented a token authorization in the past and TBH I would feel better if the command endpoint would be more locked down. What kept me from releasing it was knowing that it would break many people's workflow of loading the widget 'page' on their browser to debug. I also got the feedback that it is likely overkill, but this could change that assumption.
Thanks for checking this out!
For my understanding, how would a privilege escalation look like - I think I can picture it, but just to double check my understanding.
I have confirmed the following scenario in a multi-user environment:
- two users on system: admin and xxx (who only has Very Limited Permissions™)
- admin uses the GUI
- xxx is allowed to ssh into the machine
- while admin is logged in and working, xxx logs in remotely using ssh
- xxx can hit the command endpoint with e.g.
curlto execute any command as admin (demonstrated withwhoamiwhich shows admin) - therefore, xxx is able to escalate to the same privileges as admin
Does that match with your understanding?
I have implemented a token authorization in the past and TBH I would feel better if the command endpoint would be more locked down.
Awesome! 🎉
What kept me from releasing it was knowing that it would break many people's workflow of loading the widget 'page' on their browser to debug. I also got the feedback that it is likely overkill, but this could change that assumption.
I think that the settings should be secure by default because the vast majority of users probably just want to run widgets. At the same time, I think the settings should be customizable in order to accommodate special workflows (e.g., widget developers loading the page directly in a browser).
What do you think about adding a new setting to toggle the token check?
Alright thank you, the vulnerability is clear! I will continue the discussion on the PR