142 lines
8.5 KiB
Markdown
142 lines
8.5 KiB
Markdown
---
|
|
date: 2022-06-07T07:15:51Z
|
|
draft: true
|
|
aliases: []
|
|
categories: ['apprentice']
|
|
series: ['hacking', 'security']
|
|
tags: ['apprentice', 'tech', 'bug']
|
|
chroma: true
|
|
toc: true
|
|
title: Security issues
|
|
description: Various security issues I found, disclosed and got fixed as an apprentice!
|
|
---
|
|
|
|
Here is a collection of security issues I found, disclosed and got fixed as an apprentice!
|
|
At SkyLabs I fixed the issues myself, but at Sircon they delegated all the boring support to me and the previous apprentice.
|
|
So there I just disclosed the issue to the responsible person and both of them fixed their respective issues within an hour.
|
|
|
|
## SkyLabs
|
|
SkyLabs has surprisingly good stability compared to expectations based on the codebase.
|
|
I'm guessing it's a byproduct of Python that let's us fail pretty safely on almost all endpoints.
|
|
The in-house development is mainly four services, two JS frontends and two Python Flask backends, all web.
|
|
|
|
These services are a captive portal, it's API and an admin interface web app and it's API.
|
|
|
|
We support lots of interesting [authentication](https://wiki.skylabs.no/partner:authentication) methods!~
|
|
|
|
### Sky ID Admin
|
|
And so far the only real security related issue I've found in the in-house codebase is that the Access Control was missing a check.
|
|
The problem is that API keys that are associated with a deleted account is valid.
|
|
Allowed methods are by x-api-key Authorization header, api-key as an url parameter or by Json Web Token.
|
|
The JWT is passed in an Authorization Bearer header, which is wrong, [Bearer](https://datatracker.ietf.org/doc/html/rfc6750) Auth header prefix should be reserved for [OAuth 2](https://datatracker.ietf.org/doc/html/rfc6749).
|
|
|
|
Anyway when using API keys, not JWT, the server just fetches the API key record from the database.
|
|
The function calls for this goes from the Access Control controller class through an API key controller.
|
|
Problem is the API key controller class only checks if the associated user exists, not if it's been marked as deleted.
|
|
So if you have an API key, you may have your accounts full access after it's supposedly been deleted.
|
|
|
|
And the fix for it was super easy!~
|
|
|
|
We use a custom endpoint decorator, like flasks own @app.route, but we control what happens.
|
|
It's here the authentication is implemented, on all requests that go to routes defined with this decorator will run the Access Control controller.
|
|
Access Control goes through the auth options in its dunder init function and sets self.current_user to some admin user from the database.
|
|
To fix the problem I could've made this check specific to the API keys by putting it in the API key controller that also has a user getter function.
|
|
But I chose to add an if statement to the Access Control user getter, this is called by our endpoint decorator.
|
|
So I literally just changed this.
|
|
|
|
{{< highlight py >}}{{% asset "apprentice/security/accesscontrol.py" %}}{{< /highlight >}}
|
|
|
|
To that!
|
|
|
|
{{< highlight py >}}{{% asset "apprentice/security/accesscontrol-fix.py" %}}{{< /highlight >}}
|
|
|
|
To fix this issue.
|
|
|
|
If you wonder why we "raise Forbidden".
|
|
It has to do with the endpoint decorator which will catch all errors.
|
|
And will report them to us by e-mail and a slack bot.
|
|
The HTTP response will be error 500 if it's a Python error.
|
|
But if it's one of our own error classes that's been raised.
|
|
Then an error code, description and status code will be taken from that exception class and sent as the response.
|
|
|
|
There is also the case of the JWT secret key that's wayyy too small.
|
|
And not changed since it was introduced in the admin API.
|
|
Old keys is a theme on SkyLabs servers.
|
|
|
|
I'm surprised no one, as far as we know anyway, has broken into the servers yet.
|
|
|
|
#### Funny
|
|
Something I find kinda funny is the fact that those exception descriptions are in English, but the admin frontend is entirely in Norwegian only.
|
|
It's even got a big ass JavaScript file that maps all the error codes to messages.
|
|
And the best part about that whole situation is the fact that my boss/the sales guy at the company wants to sell our services outside Norway...
|
|
The only part that supports multiple languages is the actual captive portal, but even that has a bug which makes it so that only two languages can be active at one time.
|
|
|
|
#### Minor
|
|
One minor issue I found in our production system is the password for the "system" account.
|
|
The password for that account is a real shitty one that I've seen used several palaces at the company.
|
|
It's even been used as a Wi-Fi password.
|
|
To fix this one very easily I just enabled 2FA on the account.
|
|
But the whole account should probably just be deleted as nobody ever uses it.
|
|
|
|
### Servers
|
|
{{< img src="apprentice/skyid/old-intrauser-key.png" caption="The old intrauser ssh key" >}}
|
|
|
|
On the other side, the cloud servers had some bigger problems.
|
|
Here I did find a *BIG* security issue. Ancient ssh keys.
|
|
We use Ansible to manage the servers and deploy code updates.
|
|
There is an Ansible var file that has a list of user accounts with options for shell and ssh pubkey.
|
|
That file also has a list of old accounts that should be deleted.
|
|
These are per employee users.
|
|
But the intrauser and Ansible users have existed since 2016...
|
|
using the same keys that they were created with.
|
|
The reason this is such a big threat is the fact that the Ansible and all employee accounts has sudo access without password.
|
|
|
|
The intrauser does actually have a password set, but it may use sudo without password when running rsync.
|
|
And the thing is, [gtfobins](https://gtfobins.github.io/) has a privilege escalation exploit for rsync that our servers are vulnerable to.
|
|
|
|
So check it; these screenshots are from SkyLabs' Ansible git log!~
|
|
|
|
{{< img src="apprentice/skyid/intrauser-key.png" caption="Me finally updating the key" >}}
|
|
|
|
And it's even worse... as it turns out the OpenVPN setup also has keys from guess when!
|
|
That's right! 2016...
|
|
So even if you only got access to the intrauser, it's super easy getting local privilege escalation on the servers.
|
|
|
|
To be honest I'm quite surprised the servers hasn't been pwnd big time!
|
|
|
|
As I've in fact proven that any ex-employee that has a copy of our Ansible repo could easily forge OpenVPN client keys and certificates.
|
|
And also got full root access over ssh anyway.
|
|
Just add a little [Tor](https://torproject.org/) magic on top of that, and you got full access to all the servers without us being able to trace it back...
|
|
|
|
## Sircon
|
|
These guys has a few beefy ass physical servers in their own rack in a supposedly EMP and fire safe room in the basement of their offices.
|
|
Those physical machines run virtual machines that run WHM/cPanel and whatever PHP app the customer would like.
|
|
But >90% of their customers are non-technical and just only interact with the default WordPress setup and maybe the e-mail service that comes with their cPanel.
|
|
Most of the people calling in to their support line has problems using their e-mail, and it's usually the end user who fucked up.
|
|
|
|
### Servers
|
|
Have you ever used Apache httpd? Have you ever used its .htaccess config?
|
|
Well it's pretty cool, but may pose a threat on shared "web hotels" like WHM servers running a whole lot of cPanel accounts.
|
|
If using .htaccess is allowed users may set their own configuration options for httpd.
|
|
|
|
And the issue I identified here was the fact that cgi configuration options where allowed in .htaccess.
|
|
So I had some fun making wired cgi scripts in python, perl and bash.
|
|
|
|
The last thing I did before disclosing it to Sircons server guy was to make a proof of concept script that gave me a shell on the server.
|
|
As they don't allow ssh access and PHP is configured to not allow anything dangerous, like the system() function, that would allow you to create shells.
|
|
|
|
Example .htaccess to run cgi scripts.
|
|
|
|
{{< highlight apache >}}{{% asset "apprentice/security/htaccess" %}}{{< /highlight >}}
|
|
|
|
The fix for this is the [AllowOverride](https://httpd.apache.org/docs/current/mod/core.html#allowoverride) directive.
|
|
Just make sure it does not include "FileInfo".
|
|
|
|
### WordPress
|
|
I found a bug on their homepage [sircon.no](https://sircon.no) where they have a simple WordPress shop with a couple of cool features, like [this](https://sircon.no/sjekk-om-din-nettbutikk-nettsted-driftes-miljovennlig/) where you supposedly can check how green a web page is. As in green energy.
|
|
|
|
The bug I found was missing server side validation and a shopping cart that's stored in the browsers local storage with price specified.
|
|
This is a pretty minor issue however, as they don't do automatic provisioning, and it only gets added to some internal webpage they use to keep track of everything.
|
|
But whatever you posted as the price would show up in that tool.
|
|
You could even post negative prices!
|