Background
On an engagement last year, we were asked to perform a security review of several “HR kiosks” at various locations. These particular kiosks were located within manufacturing facilities and allowed employees without company assets to access HR applications. We went in with little knowledge of what the kiosks were running, and only had about 2 full days to test them. By then end of the engagement we could fully break out and kill the kiosk application. We also had a nice 0-day to report to the vendor.
The kiosks were running recent versions of SiteKiosk (http://www.provisio.com/web/us/products/windows-kiosk-software-sitekiosk). By default, the SiteKiosk application provides access to a full screened browser.
Attack Path
We started with our familiar “break out” playbook that we use when trying to break out of other sandboxed / kiosk-style environments such as Point of Sale (POS), Citrix, or Remote Apps. We went through our initial hit list of likely breakouts such as Ctrl-O, Ctrl-S, browsing to a file:// uri, downloading a file, etc. All of these either had no effect or were met with a SiteKiosk error message we were going to became very familiar with.
We started doing some research about other ways to open an application from a browser. Eventually we found the JavaScript msSaveOrOpenBlob() method that opens a “blob” of data in the default application of its file type. We created an html page that would open a .txt file and hosted it on the internet.
<script>
bb = new MSBlobBuilder();
bb.append("test data 2");
window.navigator.msSaveOrOpenBlob(bb.getBlob(),"testing2.txt");
</script>
Browsing to this immediately popped open a notepad window. From here we could go to File > Save As to open a Windows Explorer window.
Access to the filesystem initially appeared to be restricted to just the kiosk account’s home directory. The go to trick of browsing to the local C$ share did not work here, so a little more research was required. We recalled that Windows uses “shell:” style shortcuts to browse to dozens of different operating system folders directly. By browsing to “shell:system” we landed in the System32 folder.
First up? cmd.exe of course. We don’t have right click, so we can’t select the easy ‘run’ option from the menu. If we drag some random text file on it however, cmd.exe will attempt to open it. Sadly, we get a system error here.
There is little chance of getting past GPO settings while we’re still in kiosk mode. What about PowerShell? That brought us back to our friendly SiteKiosk error message. So now we need to get SiteKiosk to back off. Somewhere in the process of writing JavaScript we managed to run some bad code with an infinite loop that froze the SiteKiosk browser (it automatically restarted 30 seconds later). What if we could get Notepad up, then freeze the SiteKiosk browser? A quick JavaScript modification:
<script>
bb = new MSBlobBuilder();
>bb.append("test data 2");
window.navigator.msSaveOrOpenBlob(bb.getBlob(),"testing2.txt");
setTimeout(function(){
while (true) { }
}, 2000);
</script>
Perfection! Now we just drag a text file onto powershell_ise.exe to open it, and we’ve got ourselves a PowerShell terminal.
We have about 30 seconds before SiteKiosk realizes its frozen and restarts, so we need some quick and dirty code to keep it out of action. We use our first PowerShell instance to open another where we’ll run a loop.
start powershell
It took a few tries of 30 second chances to identify the SiteKiosk processes, but then we can kill them.
While (1) {Get-Process sitekiosk,watchdog | kill}
With a bit of red text flying in the background, we now have SiteKiosk down for good and all the time in the world to play with PowerShell.
Lessons
There are a few takeaways from this.
- Hiding the C: drive in Windows Explorer doesn’t stop all the filesystem shortcuts from working. Try the “shell:” style shortcuts when doing any similar kiosk or sandbox testing.
- msSaveOrOpenBlob() is a great way to open a file. It does require an IE based browser like the default one SiteKiosk uses.
- Don’t control process execution from the same process that the user has access to (or from a process the user has privileges to kill).
Response
We first disclosed our findings to Provisio (the company that makes SiteKiosk) in November of 2016. They provided us with a patch for the current version on February 2, 2017, and released a patched version on March 1st (SiteKiosk 9.4.3958). Their solution was to prevent powershell.exe and powershell_ise.exe from being launched via Group Policy, just like how cmd.exe was restricted. While this prevents the last step in our attack path, we are still able to hang the SiteKiosk process and browse the filesystem.
After testing this release (SiteKisok 9.4.3958), we discovered that by using wscript.exe and cscript.exe, we could reperform the same actions. Provisio released an update to the software (SiteKiosk 9.4.3975), which restricts access to these executables.
Recommendations
If you are using SiteKiosk, make sure you update to the latest version. We also suggest selecting the Chrome based browser in the SiteKiosk configuration if you aren’t relying on any IE specific features. In Chrome, we were unable to use the msSaveOrOpenBlob() method or hang the process with an infinite JavaScript loop.
Happy hacking!
If you’d like to see if your company uses this product, feel free to look through the Provisio extensive client listing: http://www.provisio.com/web/us/references
Dan Astor
Dan specializes in network penetration testing, adversary simulation, and red team operations. Dan is a member and lead of SRA’s R&I team, which researches and develops tools, techniques, and public content.
Dan has worked for clients in several industries including banking, entertainment & media, insurance, healthcare, pharmaceutical, manufacturing, and utilities.
Dan regularly contributes to open source tooling and blog posts. He has also obtained his Offensive Security Certified Professional (OSCP) certification.
You must be logged in to post a comment.