[EN] 2 CVEs Inside — Unexpected Journey: From Zero to Company’s Internal Servers
Hello everyone, it’s been a while since I didn’t post any blog posts.
In this blog post, I would like to give a walkthrough on the two vulnerabilities that I recently discovered during a penetration test: “CVE-2023–3374” & “CVE-2023–3375”.
Some time ago, me and my buddy Emre Odaman got handed over a Digital Signage / Media Device Management Platform – named “Bookreen” to perform a penetration test for a client.
What this platform does?
This “Digital Signage / Media Device Management Platform” basically manages all the information screens (just some basic Smart TVs — nothing fancy) in a corporate to make announcements, publishing ads, etc. It is also being used in managing meeting rooms such as setting a meeting location, scheduling a meeting time, organizing attendees and so on. — this is where everything gets interesting.
As a vendor with good awareness of cybersecurity, you never thought your company’s internal servers could be compromised by a simple IoT device, right?
We are trying to make everything “smarter” but “security” is NOT one of our concerns.
Of course, using Android tablets for scheduling our meetings is a brilliant idea and it is even better when those tablets can communicate with your internal network — for integrating LDAP and everything.
In fact, using this kind of a technology — when it is secured properly — can make so many things easier. However, in this case, it is putting things in a great danger.
Everything started with a simple reconnaissance we did w/Emre on one of those “Android Tablets”:
Normally, what we expect to see here is that this tablet should be running in “Kiosk” mode and the application that is currently running on this tablet should not be bypassed/closed by any means.
However, after couple of simple tryouts, we bypassed the application and we were able to use the tablet just as it was our own — thanks to Emre.
Quick note here: Developers DID take some precautions after our little trick in here but that was not sufficient. Developers tried to activate “Kiosk” mode but — I will not go into more detail— it was misconfigured either.
After bypassing the application, the first thing we’ve looked for was “Settings”, not surprisingly. We did this to check whether there was any “Hotspot” functionality allowed on the tablet so that we would be allowed to join to the VLAN that the tablet is currently connected to.
“Luckily”, the tablet had an ethernet connection and there was a “Hotspot” functionality allowed on the tablet.
Basically, what this accomplished was tethering the Ethernet connection of the tablet, as an AP.
On following, we have connected to this “Hotspot” and transferred a malicious “.apk” file to get a reverse shell connection from the tablet.
After installing this malicious “.apk” file, all we need to do is trigger it to get a reverse shell connection into our local.
As we can see, we’ve obtained a reverse shell successfully. Next is enumeration, checking for current privileges & privilege escalation — if necessary.
Another red flag: the device is “rooted”. That means the device is running with the highest privileges as possible and we do not have to suffer on trying to escalate our privileges; from here, we can do anything we want.
Quick note here: On a cross-check, we saw that the Android Debugging Bridge (ADB) port was also enabled on all of those Android tablets and that means we can access to these devices by simply connecting their ethernet cables to our computers — without striving with all the tracks that we left while trying to upload a malicious file.
Let’s continue to beginning of the interesting part. After doing some enumeration, we’ve found a juicy file: the “base.apk” file.
Side track: Pivoting through the network
After initial scan, we discovered that we are able to access all of the IoT devices on the network with a root shell through ADB, all the bells and whistles. Building an .apk with msfvenom is easy; installing it, running it over the network and obtaining a Meterpreter shell on all the devices, not so much. The ADB allows us to install applications over the network & run our msfvenom apk (at least in this case). But, we cannot obtain a reverse shell connections because of the NAT connection on the tablet.
Basically, the Android Hotspot acts as a router, and NATs all connections from client devices to the wider-area network. This is useful for scanning the network and accesing other devices, but obtaining reverse shells are mostly impossible.
Even after obtaining a meterpreter shell through our main Hotspot, and configuring it to port forward inbound connections to us, we had no success. Since we never came across such a scenario, troubleshooting took a good while. We had to improvise.
Idea: Static Binaries
We check our Hotspot device’s CPU architecture, and compile a static socat binary for the target. Voila, it works! Configured socat to forward all inbound connections into our Meterpreter handler, and with some quick and dirty scripting, we obtained full root Meterpreter shells from all the devices — around a hundred of Android tablets installed across the whole campus, cameras and microphones. Scary, huh?
It is a simple misconfigured Android tablet up to now. What is so fancy?
Here comes the exciting part.
When we decompiled the “.apk” file that we recently had in our hands, we came across some hard-coded information inside the application:
As we can see from these screenshots, the developer was generous enough to share an external source that is related with one of the company’s demo servers.
Well, what do you expect?
After a successful login, our first attempt was to gain persistence so that we would not lose our access to this page by any “accident”.
Seems like we have a couple of “Admin” titled users but after poking out the application more, we see that it is not the “Official Admin” role.
After hitting “Add User” button, we’ve tried to create a new user named “sysadmin”. We filled out the required fields and sent it to the server.
CVE-2023–3374
Before sending this request to the back-end, why not intercept it first and see what is being sent:
Seems like the roles that we try to define for our user are being sent under the parameter named “roles” and it has the value “11”. Why not change this value to “0” and see what happens?
BOOM! Seems like there is a lack of control on validating user inputs while creating a new user on the system. Let’s login to the high-privileged user account that we’ve just created:
Note that “Low-Privileged” user had more restricted functionalities on their User Menu (on the left) and “High-Privileged” user has more functionalities defined on their User Menu:
This “bug” got assigned a CVE (Common Vulnerabilities and Exposures) ID as: “CVE-2023–3374: Privilege Escalation Vulnerability on Bookreen Digital Signage/Media Device Management Platform” — or more formally: “CWE-184: Incomplete List of Disallowed Inputs”.
OK. Now what?
CVE-2023–3375
After escalating our privileges, we continued to look for more bugs. On “Companies” page, (this bug also exists on 3 more pages) we’ve found a file upload module that looks interesting:
On this file upload module, I have used a trick called “Bypassing File Upload Restriction Using Magic Bytes”. By using this trick, we can exploit a file upload module that uses a poor filtering.
To be more clear about this, we are simply tricking the system by telling some file is in different file format than it seems. What I mean is that we can represent a file with “.php” extension as if it is an image file by changing the bytes in it’s magic header:
After modifying the file, we can try to upload it:
Seems like we have uploaded the file successfully. Now the last thing we need to do is trying to trigger it:
This “tiny bug” that allows us to exploit Remote Code Execution vulnerability got assigned a CVE (Common Vulnerabilities and Exposures) ID as: “CVE-2023–3375: Unrestricted File Upload leading to Remote Code Execution Vulnerability on Bookreen Digital Signage/Media Device Management Platform” — or more formally: “CWE-434: Unrestricted Upload of File with Dangerous Type”.
Thanks [TR]
Bildirmiş olduğum zafiyetlerin tanımlanması ve kapatılması sürecinde oldukça hızlı bir şekilde aksiyon alan ülkemizin en önemli merkezlerinden biri olan Ulusal Siber Olaylara Müdahale Merkezi (USOM)’a teşekkürlerimi sunarım.
Thanks [EN]
During these CVE assignment processes, TRCERT (USOM — BTK/ICT) has helped the progress a lot to make it as fast as possible. I would like to give my honest appreciations for their awesome work.
Thank you for reading, see you on the next one.
