DeLux Edition: Getting root privileges on the eLux Thin Client OS

While on an engagement I came across a thin client running the eLux Linux distribution.

Designed as a secure, streamlined environment for users to access applications such as a browser, Citrix and terminal services, the vendor describes eLux as:

“… a hardware-independent operating system for cloud computing environments. It is based on a write protected file system and therefore secure against computer viruses and other malware without using special Antivirus Software. eLux® has been continuously developed and enhanced for more than 15 years.”[1]

The desktop, after a fresh installation, will look as below:

Figure 1 – The eLux desktop

The operating system can be locked down and managed either remotely from a Windows computer (using the ‘Scout’ management console), or locally with access to the local admin. Applications such as Citrix, Firefox and an RDP client can be deployed and will appear on the user’s desktop, configured for their requirements.

I will be working on the assumption that all features in the Control panel have been locked down:

Figure 2 – All fields locked in the local security settings

Breakout from Firefox in kiosk mode

Access to a low privilege shell or method to execute commands was the first step – sometimes, the xterm application will be made available but often you will need a way to break out.

I was able to execute xterm from Firefox configured in kiosk mode:

“The Kiosk mode starts the browser in fullscreen mode and with limited user rights. The user cannot open any tabs and cannot exit the browser. Kiosk mode is suitable if the user should only see one website and is not supposed to use further applications on the Thin Client.”[2]

The method I used was to browse to an RSS feed, then select xterm as the application to handle the subscription. Clicking a ‘mailto:’ link also worked in a similar fashion.

Figure 3 – Selecting xterm to handle RSS subscriptions

Enumeration

With access to the command line running as the user ‘elux’, I can start enumerating the environment and discover possible vulnerabilities. 

The first thing I did was search for setuid files. These are files that execute with permission of the owner:

Figure 4 – Searching for setuid files

I noticed screensavercc – a configuration utility for the screensaver. I modified the configuration of the sonar screensaver with an easily identifiable string then searched all files for this string:

Figure 5 – Using the test string ‘TEST-NCC’

The string was found in the main config file /setup/terminal.ini, meaning I was now able to alter the configuration of the device by injecting in to this file. 

Figure 6 – Screensaver configuration in /setup/terminal.ini

Privilege Escalation

The application did not sanitise user input and it was possible to insert additional content that would be written to the terminal.ini configuration file and parsed by the system on boot. 

After playing with different possible configuration options, I found that inserting the following into the ‘Sonar’ Host List configuration field added a new printer configuration which was vulnerable to command injection:

[PrinterList]
1=bob,1

[!PRINTER!1]
Type=net
TextFilter=false
PclFilter=false
Default=false
Address=$(mv /setup/terminal.ini /setup/terminal.ini.bak);
Tp=false

[Printd]
port_lp=0
port_lpsave=9100
port_usb=9101
port_com1=9102
port_com2=9103
Figure 7 – Inserting the printer configuration into the Host List field

After rebooting the device, the /setup/terminal.ini file was renamed to /setup/terminal.ini.bak and the device booted into its default configuration.

Getting a root shell

With the device now booted into the default configuration, I was able to access the control panel and make changes to the configuration. But what I really wanted was a root shell!

This ended up being a little easier than expected; most the fields in the control panel were vulnerable to command injection. Entering ;xterm; into the Time server field and clicking synchronize executed a root shell.

Figure 8 – Root shell

Conclusion

This ended up being a fun challenge and showed what can happen when you don’t properly sanitise user input. The issue was reported to Unicon Software, which worked closely with NCC Group to understand the vulnerabilities. I would like to thank the Unicon Software team for their quick response and cooperation.

The following CVE was assigned to this:

CVE-2017-7977

Vendor link:

http://www.myelux.com/cvesingle.htm?cve_id=CVE-2017-7977


References

[1] http://www.unicon-software.com/en/products/elux/

[2] http://www.unicon-software.com/udocs/en/#admin_guides/scout_enterprise/app_definition/browser/browser_kiosk.htm

Published date:  24 August 2017

Written by:  Craig Blackie