Kiosk Hacking: When there is nothing else left

April 7, 2008 – 7:29 AM

In the tiger team operations we have been involved with, I often end up hacking through the least interesting systems. If you ask AP, a password-cracking ninja and master of hacking through simplicity, the less interesting the system is, the higher the chances to be insecure. A successful exploitation of these systems often leads to successful exploitation of the network and other adjacent systems. This post will concentrate on some theory and practicalities around what to do when penetration testing Kiosks when nothing else is left.

Why Kiosk? Kiosk are perfect for all kinds of scenarios. Everybody who has played enough with them knows that they are insecure no matter how much hardening you apply on them. They are also very much subjective to attack because the attacker has physical access as well. This means that tampering with the keyboard or any other input/output port is very much possible. Kiosk are uninteresting because they seem to provide very basic features and therefore they are being largely ignored. At the same time, they are highly interesting because people use them for all kinds of mission critical stuff without thinking twice about the confidentiality and security aspects of the operations they perform. Let’s not forget that Kiosk are to an extend backdoors to the network where they reside and the domains where they are controlled from.

The traditional ways of hacking Kiosks are well documented, yet unknown to the masses. The basic idea is to obtain some kind of access on the system which gives you enough flexibility to do whatever that needs to be done. The traditional ways are all based around the idea of escaping the standard GUI lockout. Usually Kiosks are locked so that the user can only use the features which are provided by the vendor but nothing else. Sometimes, Kiosk are not correctly locked which of course allows attackers to quickly gain access to Windows’ shell by using something like File -> Open dialog or any other mechanism which allows them to open Explorer shell/frame. This includes the Help system, the Open/Save/Save As features and pretty much everything else that deals with files, explorer and iexplorer. On some Kiosks, browsing through the file system is not possible but yet you can spawn executables by using Outlook, if it is Windows based, because Outlook is usually not blocked and you can add executable attachments to emails which when doubclicked are executed, etc. But that’s not all. There are other ways someone can gain access to a Kiosk or at least gain access to the data it holds or it may hold in the future.

Files, Read, Write, Etc

Although it is much more convenient to have a command shell spawned for your own needs, sometimes this is very hard and you might not have enough time to mess around with the details which are involved in the process. Simple backdoor techniques could work very well in this case. I am not referring to installing software on the Kiosk which is tested, but rather modifying files which can provide further access to the attacker. I’ve seen Kiosks which are relatively locked and significantly hardened but yet they run under privileged accounts. Notepad or other type of software which allows writing to files is not blocked at all which gives us the opportunity to overwrite files. The host file is a very good target in that case. Modifying this file could potentially give the attacker access later when the system is not hardened. For example, if we substitute the IP address for the google.com domain on a hardened box which we cannot exploit, at some point in time when the box is significantly weaker we can take advantage of the fact the the google.com domain will result into a host controlled by us and therefore take over the Kiosk. Not to mention the fact that that way attackers will be able to sniff all sorts of goodies from the hijacked domains.

In some cases you don’t have write access but you can read. In one of the tiger team operations we were involved, we broke though the Kiosk into a protected FTP server due to the fact that the Kiosk software had autoupdate VBScripts which use FTP to pull the software. Unfortunately, the poor developers have left the FTP credentials in clear text which gave us write access to the FTP server and some other critical sections of their network. Reading files is a huge dangers and unfortunately it is not very easy to block especially when the Kiosk is based on a rich operating system such as Windows or some Linux variant or even MacOS.

Java, Applets, Flash and Browser Access

Not that long time ago I’ve published quite awesome little browser-based tool called Jython Shell. The Jython shell, although a completely legitimate programing tool, can give you some helpful features when Java is enabled on the Kiosk. The applet spawns a simple console screen which is hooked to to the Jython/Python interpreter. All necessary libraries and bindings are downloaded at runtime into a temporary folder from where they are loaded. Therefore, on a Kiosk which allows Java applets to run, we can gain access by using Python primitives and the privileges of the current user. We can spawn files/executables but also spawn sockets and do all kinds of things. It comes quite useful indeed. Other technologies such as Flash, ActiveX and SilverLight are very useful for the purposes outlined above as well.

Active Exploitation of Vulns

Although you see fairly locked and patched Kiosks once in a while, most of them are not patched. On a number of cases we’ve found Kiosks which are running VNC with auth credentials set to password. Some of them were even vulnerable to the VNC auth-bypass bug. They were accessible from the Internet which was a big problem. On other cases we were able to exploit the browser by visiting a server which holds specific exploits which we thought might work. Kudos to the Metasploit team for putting the framework together.

Source: GNUCITIZEN