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.”
The desktop, after a fresh installation, will look as below:
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:
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.”
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.
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:
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:
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.
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
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.
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:
Published date: 24 August 2017
Written by: Craig Blackie