 Okay, so what am I going to talk about today? I'm going to talk about hacking internet kiosks. It's pretty much my favorite subject these days. I want to cover over what is an internet kiosk and a kiosk software security model. Pretty much how these things tick, how they work. I don't want to talk about some vulnerabilities in kiosk software and vulnerabilities in the core kiosk security model. Vulnerabilities in how these things are designed, why kiosks are fundamentally insecure, and pretty much I'm going to show you how you can hack any Windows internet kiosk in less than 120 seconds. Guaranteed! That shit pops shells! Thank you! Then we have a Defcon exclusive. I'm going to be releasing a couple of tools, some things that are quite cutting edge, quite new and funky. Then we have some more live demos up here. Hopefully if we have time, I'm going to hack two commercial internet kiosks that are virtualized on my laptop up here. Then after this talk you're welcome to go rape and pillage throughout Vegas. So one of the downsides of living in New Zealand is I spent a hell of a lot of time in airports, stopovers, and last year I spent eight hours in Hong Kong and I was sitting there after this flight and I was scratching my head and I didn't really know what to do sitting in this airport and I saw this internet kiosk sitting in the corner and I actually saw a queue of these Asian businessmen waiting to use the kiosk. I thought to myself, man, that kiosk is real popular. I thought, I wonder if I could hack it. I wonder if I could go see the kiosk or loan party it. I thought, oh man, that would be pretty cool. That's a good way to kill time but to stop over, right? Then something kind of dawned on me and I realized that these kiosks are really popular. I see these everywhere and people used them but I rarely hear about them. I don't often see publications and security focus on how to hack kiosks. A bug track, I don't really see postings on latest kiosk vulnerabilities. I don't know of me that we have a very popular service which has very poor security visibility and this of course equals a very, very good attack target. That's what I said. Right here, right now, I want to find every possible method of hacking an internet kiosk and I want to become the fucking king of internet kiosk hacking. I don't think there's anyone else out there who is the king of internet kiosk hacking. All right, so when I got back to New Zealand I started keeping my eye out for kiosks. I basically found them everywhere. I found them in airports, train stations, libraries, DVD rental stores, corporate building lobbies, convenience stores, post office cafes, hospitals, motels, hotels and universities. Now while I've been in Vegas I've been walking up and down the strip and every casino here has at least five or ten kiosks. There are kiosks out in the lobby out there. But if you've used those kiosks I wouldn't. I've used them too. Okay, now I think this is primarily because you don't really need a quad-core Xeon to run a kiosk. You can have really cheap, shitty technology sitting in the corner of your office and set up a kiosk. So we have kiosks now everywhere because you can build on for 100 to 100 bucks. Okay, so my initial observations of kiosks, well from a hardware perspective kiosks are usually built in these really tough, rugged, hard shell cases. They're usually fiberglass or wooden shell. They have a lack of physical access to the computer case so you can't access the floppy drive, DVD, USB or fly wire. The kiosk is usually also bolted to the ground or it's padlocked or it has a big secure lock on it attaching it to something. Generally the idea is that the general public, you and me, we're evil hackers and the kiosk vendor does not trust us. So every attempt is made to make sure the kiosk cannot be stolen or just generally messed with. Now from a software point of view the majority of kiosks have noticed actually run commercial kiosk software on Windows. Now I have noticed that Linux and BSD kiosks exist but Windows is far more popular. It just outweighs it. Basically there are 44 commercial Windows kiosk products on the market. The Windows kiosk market is actually a multi-billion dollar industry. It's absolutely huge. And especially marketed as being able to turn that old shitty computer in the back of your office into instant revenue. You go out and you buy my $59 shareware app, you install it on your crappy computer and instantly you can make some money. Now these kiosks are essentially Windows skinned. Alright? So a kiosk browser will implement standard Internet Explorer libraries. I'm talking winhgp.dll and msinet.ocx and Windows is sort of drastically skinned to feel like a kiosk or to look like a kiosk. You can usually still tell that these things are Windows but it doesn't really look like Windows. It looks bastardized. It looks kind of gimped or changed. So I realized that a kiosk software is really the best attack target. I was thinking maybe I can try some hardware hacks on these things. But then I thought while sitting in the Hong Kong airport in my eight hour stopover with a pair of bot cutters, probably isn't going to work so well when I want to hack with the kiosk. So I determined that I need to be able to walk up to any Internet kiosk and I need to pop shell quickly. I need explore.exe to pop up or cmd or command.com and time limited. I don't want to be there for an hour and a half hacking. I have to do this in less than five minutes. I have to do this really, really fast. That and these kiosks cost money. And I don't want to spend money on this shit. Okay, so I spent the last 16 months researching methods of penetrating kiosk software. What I did was I virtualized the top ten most popular Windows kiosk products in Myanmar. I detailed and compared the security model of each of the kiosks. Best you see what each kiosk defends against and how it works. Then compared it against all the other kiosks. Then I researched new methods of compromising these Internet kiosks. And I developed a kiosk attack methodology. Basically a whole set of tests you can do on a kiosk that is pretty much guaranteed to pop shell. And my startling result, of course, 10 out of 10 on my kiosks, 100% success rate, you know, they all die. Okay, so the kiosk security model. Now kiosk software implements security by two distinct approaches. Firstly, they try and reduce available host functionality. So this is a disallowing native OS functionality that can be used maliciously. So an example of this would be Disabling Command Prompt. You do this by setting a registry key for Disable CMD. And if you try and run CMD.exe it'll pop up and say Command Prompt has been disabled so you can't run it. There are many other examples of this, Disabling Task Manager, Disabling RedJet it, things like that. And the second approach is jailing the user into a secure kiosk browser application. So you're essentially stuck inside this kiosk browser, right? The kiosk browser is ran in full screen. You don't have any ability to minimize, close or get rid of the browser. The start bar, the trade menu is usually removed or hidden. And the only thing you can do is browse the web. This doesn't mean that the operating system isn't there anymore. There's still windows under this. You just can't access it. You can't physically click on something to give you windows. Here's an example. There's a screenshot for you. This is Site Kiosk. It actually looks very similar to Windows. If you notice the trade bar on the start button, it looks a bit different, looks quite custom. And you see that the start menu has Site Kiosk on there. And you only have one option and that's to open up a new browser window. So you're pretty much trapped inside this sort of user interface. There's another example. This is NetStop Kiosk. This is actually the kiosk that is used right over there. This has a custom taskbar. This actually doesn't have any buttons or pop-ups or anything at all. The kiosk application is ran as a full screen desktop application. You don't have any ability to close it. And you can only browse the internet using this. It doesn't give you the ability to launch other applications or click on things or really do anything interesting. So these kiosk browsers actually proactively monitor your usage. They're trying to defend against malicious hackers like us. So a kiosk contains numerous blacklists of prohibited activity. So if you try and do something sneaky the kiosk will stop you. For example inside kiosk if you try and pop up the internet browser and you browse the c colon slash it'll pop up this little message box saying accessing this URL is prohibited and won't let you. Kiosk also monitor all the infocus modal dialogues that pop up. So if you try and pop up a save file dialogue it'll detect that window has popped up and instantly close it for you. It'll send a WM close message to the dialogue ID of the window that pops up and it closes it goes away. So this really limits what you can do with the kiosk using the browser. Again this is another method of reducing functionality. A kiosk also implement API hooking. So they hook native OS API calls which can be used maliciously. Things like kill process, get command line W, console. I mean how are you ever going to be able to run cmd.exe if you can't call alec console. The kiosk browser is usually ran in a high security zone. So file downloads are all disabled. Browser scripting, pop ups, active x are all disabled. And typically there's usually a watchdog timer that'll run and maybe every four or five minutes the kiosk will enumerate all of the active windows and processes and see if you're trying to do anything malicious. See if there's a copy of cmd running or anything that you shouldn't be doing and it'll kill that process instantly. Now the kiosk also implement a custom keyboard driver. So they disable all the windows shortcut key combinations. So if you try and do things like control shift escape to try and pop up the task manager or alt f4, you'll find that the modifier keys are actually unmapped. So control, tap, alt, start. The function keys. They don't exist. They don't work. You'll find you have a custom mouse. So you don't actually have a right mouse button. You only have a left mouse button. Again, more methods of reducing how you can actually interact with the kiosk. It's limiting you so you can only click on shit with the left mouse button in Google. A good example of this is that picture of the keyboard just up there. That's a very common kiosk keyboard and you see that it's missing a whole lot of keys. It's missing all the good keys. Alright, so hacking kiosk software. Now the kiosk security model is based on reducing functionality. It's limiting functionality that can be used to escape the kiosk browser. So exploiting a kiosk requires invoking functionality. We need to cause applications or functionality to spawn or pop up on screen. And we need to use that invoked functionality to then escape the kiosk jail. We want to spawn a command prompt and then essentially get back to windows. We want to get out of the kiosk, kill the kiosk, get rid of it. Now, kiosks implement blacklists as I said. Blacklists by nature are never actually 100%. You can never have a blacklist that'll cover every possible permutation to downfall the blacklist. We only need one method of escaping the kiosk software jail. We just need one command shell. That's all we need. And this basically means that kiosks are very hackable. Okay, so what are the available kiosk input vectors? The first thing I did when I was looking at hacking these kiosks was some threat modeling. And I basically worked out every which way I can communicate or interact with the kiosk. These are my input vectors. And then the question is how can I use these input vectors to then invoke functionality? So we have two main streams of input. Firstly, we have physical input. So this is interacting with the kiosk GUI. This is using the keyboard or the mouse. Clicking on buttons, graphics, menus. Typing values into text input fields. And secondly, we have remote input. So this is browsing to perform the kiosk terminal. Can I use remote content to interact with my kiosk at all? Okay, so what do we need to do? Well, firstly, we need to escape the kiosk graphical jail. We need to minimize or close the kiosk browser application. And we want to pop a command shell. Then we want to need to kill the kiosk browser process. So like task kill, for slash I am, kioskbrowser.exe. Then we need to re-enable or get back a convergent windows XP sitting there where the kiosk used to be. I reckon from there I can pretty much do anything I want. You know, you can do anything with windows. And then secondly, I need to start downloading additional binaries to the kiosk. So I might want to download a port scanner, a metasploit, a root kit, Trojan or a keylogger. You know, I want to then infect the kiosk and start continuing my ownage. Okay, so let's say you find a kiosk and you'll load more. And there's a big sign up saying one dollar for one hour of internet usage. You have to use the dollar. You have to insert a dollar. I haven't found any tricks to bypass the whole money requiringness of a kiosk. So you shove in your dollar and you find you're trapped inside this kiosk browser. You know, the right mouse button has been disabled. You have a custom keyboard and certain keys have been removed. You know, this feels like a windows OS. You can see like some of the icons, some of the graphics are very similar. But it has a very custom design layout. The start bar is labeled the super kiosk start bar. Some shit like that. And you only have one visible button to start browsing. So the first thing you do is you start browsing. Okay, so the first thing you're going to try and do is browse the local file system using the kiosk browser. This is the most obvious attack, the most obvious exploit. So a local windows user, i.e. a person sitting on a keyboard, is capable of accessing the file system because you're a local user. So kiosk software must explicitly block local browser attempts. Now, you can see in that screenshot there that if I type c colon backslash windows backslash, it pops up a little message box saying, sorry, this drive is not available. Now, the good thing about windows is that it's basically designed for fat-fingered idiots, right? It's catering for people who mistype shit when they're drunk. So maybe c colon backslash windows backslash is blocked, but what about c colon four slash windows backslash? What about file colon four slash four slash c colon four slash windows? So I got a little table there of all the possible permutations that I could come up with. And you can see now how blacklists start failing really fast because the blacklist probably only blocks one, maybe two of those examples, maybe three, maybe four. What about environment variables, typing things like percent window percent? You know, that doesn't have any backslashes or C or anything like that in it, you know? So these tricks, that bypass is actually quite a few kiosks. We can use common dialogues to hack kiosks. This is a relatively no trick. So windows contains common dialogue libraries. These are things like saving a file, opening a file, selecting a font, choosing a color. These come from comdlg32.dll, the common windows dialogue library. Now comdlg32.dll implements common windows controls. These controls come from comctl32.dll. Now the file open and file save dialogue contain what's called the file view control. This is the same control that actually Windows Explorer uses. The file view control provides full explorer functionality. So essentially a file open dialogue equals explorer because it's the same control being used. And we can use that to launch processes. Now you see this. So let's say you get to your kiosk and you see this pretty UI. My first thing I do is I go around and I click every single button, every single icon, every single graphic, everything I can. I just mash everything systematically. I basically see if I can invoke a file open dialogue. Maybe there's an ability to send an email to a friend and attach a file. When you attach a file, you pop up the file open dialogue, which has the file view control. Then you browse to c colon slash, right click cmd.exe and run it. If you find on some kiosk where you don't have a right click button, you can drag another file onto cmd.exe and cmd will spawn. Let's do one again. Now the Internet Explorer image toolbar. This is actually a toolbar that hovers in the top left whenever you click a really large image. And each icon of this toolbar can invoke a common dialogue. This will allow you to invoke a file save, file print, file mail to, and open my pictures in Explorial, directly spawn explorer. Now, if the kiosk is written using Internet Explorer libraries, this toolbar is present because it's part of the Internet Explorer libraries. So it's a pretty easy test to do. You click a really large image somewhere on the kiosk, and you see if this toolbar pops up. If it does, you win. In the case of the file print example, you can use file print to then say print to a file and spawn a file open dialogue. Same trick. Do you have another common dialogue? You win. Okay, so using the keyboard. Keyboard shortcuts can be used to access the host OS. So another good check is to see if a custom keyboard driver is present. Although a lot of keyboards, although a lot of kiosks do implement custom keyboard drivers, a lot of the more budget ones don't. So this is a pretty good trick, and it's very, very simple. And you can see the modifier keys are enabled. So I have a list of keyboard shortcuts here which will produce common dialogues. It's got control B, control I, control H, control L, O, P, S. And of course you also have kiosk specific administrative shortcuts. So almost every kiosk product has a secret back door that allows an admin to log into it. It allows an admin to shut down the kiosk or make changes or basically unlock it. So all you do is you go to the keyboard and you mash your fingers over the whole thing. You try weird key combinations. Possibly something pops up in the menu. If it does, you win. Or you get a little further. Okay, browser security zone. So browser security model incorporates multiple security zones. I'm sure you're all well aware of this. So we have the restricted site zone, the internet zone, the intranet zone, and trusted sites. And each security zone adheres to a unique security policy. So the internet zone actually has less ability to interact with the kiosk and maybe lock down by the kiosk browser. But the trusted sites and the intranet zone actually have more access. So as a local user on a keyboard, you're actually available, you're allowed to access all security zones. But the URLs must be typed into the entry bar. So a pretty cool trick you can do with this is by using the about Plugable Protocol Handler, which belongs to the trusted site security zone. Now, this Plugable Protocol Handler actually suffers from a cross-site scripting vulnerability. What this means is that you can render arbitrary content in the trusted site security zone remotely or as a user on a kiosk. So one of the things we can do is, by typing about colon, less than input %20 typical file, greater than, you can pop up a file-browse dialogue. That's a file-browse dialogue from within the trusted sites. The kiosk probably isn't going to detect that or be aware of that. This isn't a very well-known trick. And this gets around any kiosk that is only protecting or defending the internet zone, which most kiosks do. Just another note on that. Another thing you can do is linking to the file system. So the internet zone can't actually link back into the own file system of the browser, but while the trusted sites zone can. So perhaps the kiosk might block or detect the common dialogue popping up, but if you can follow a link to the file system, then you win again. That trick works against, actually quite a few kiosks, including site kiosk, the first kiosk I showed you. Okay, now the shell protocol handler. The shell handler provides access to Windows web folders. These URLs, things like shell colon profile, shell colon program files, things like that. Each URL you type in will spawn explore.exe and browse the particular web folder. So a good thing to check is the shell handler blocked by the kiosk. Can we access that? If you can, you know, you win. What about this? If you type shell colon colon colon, squiggly bracket, long-guid squiggly bracket, you can actually invoke a web folder by the class ID. So this particular thing is invoking the control panel inside Internet Explorer. So you can bypass any ACLs that may exist on control.exe if the kiosk is trying to block you from accessing the control panel by just popping the control directly inside Internet Explorer. I love IE. All right, so... the downside to physical input vectors. So I realized pretty quickly that kiosk software is designed to not trust the guy on the keyboard. When people write these apps and they sell them, they're sold as being a secure solution. And a kiosk user is actually the most obvious security threat. When I'm sitting in the airport, the guy who wrote the kiosk software is trying to defend against me. He's trying to defend against the guy who's bored who wants to hack the kiosk. So my research concluded that physical inputs are actually not that successful. I was getting a 40-50% chance of popping shell on a kiosk. It's like 40-50%? Ah, that's not good enough. I'm not the king of kiosk hacking yet. So I also realized that a lot of the techniques that I've just told you are actually not that original. Most of these things have been published. If you Google kiosk hacking, you'll see all the things I've told you. And that's just not good enough. If you're going to come to DEF CON, if you're going to come and release something, you've got to have ODE. You've got to have some cool tricks that no one else has ever seen before. Right? I made a really subtle discovery during my research that remote websites are actually not factored into the kiosk security model. It's like, ooh, that's fun. Websites are actually trusted more than the dude on the kiosk. I was like, whoa, that's getting better and better. This is because the kiosks rely on the default browser security model. None of the kiosk vendors have actually taken into account a potential malicious website. So what available remote input vectors do we have? This is content visited from a kiosk terminal, hosted on a remote website. So we have browser scripting languages. We have VB script. We've got JavaScript. We've got Java applets. We've got ActiveX. Which is part of .NET. We have protocol handlers. We have file type handlers. We've got Flash. We've got Director. We've got Acrobat. We've got RealMedia. We've got QuickTime. We've got Windows Media Player. We've got a hell of a lot more attack vectors than we did being a physical user on a kiosk. So I said to myself, I need a kiosk hacking website. That's pretty much going to be the money. I need an online tool that you can visit from an internet kiosk. And it provides content for you to escape a kiosk jail. So I wrote this thing I called iCAD, the interactive kiosk attack tool. It's the first of its kind. Nothing else exists like this as far as I know. It's a new method of hacking internet kiosks. And this is very fast. I can't compop shell in less than 120 seconds. And I found that I also have a 95 to 100% success rate using my remote methods. The rest of this talk will detail all the methods in iCAD. And I'll go through it all. But this is officially being launched now at Defcon, Defcon 16. This is available live on the internet at icad.ha.cked.net, icad.hack.net. And you can use this. Anyway, this is free. This is freely available. This is all good stuff. Okay, so what can iCAD do? Firstly, first thing I thought to myself, while I'm sitting at a kiosk, I'd really like to know what kiosk I'm sitting at. I'd really like to know what's on the kiosk and what I can do with the kiosk. So I wrote this little JavaScript app which detects all of the installed applications on a kiosk. I use the resource protocol handler to pull out bitmap resources out of an executable, and I verify the height of the extracted bitmap. So if I can prove the bitmap exists from the executable, then I know the executable exists. If the executable exists, then I know the app is installed. So iCAD is capable of detecting about 15 or 20 commercial kiosk products and about 40 or 50 installed applications. So you can see on the screenshot on the far right, it's detected the kiosk platform is NetStockPro kiosk. It's detected that I have Windows MediaPlay 11 installed, NetMeeting, .NET Framework 1, 2, MSN Messenger and MovieMaker. This is really important for me because this tells me what attack vectors I now have available, what input vectors are installed on this kiosk and how I can now further define or focus my attacks. iCAD can also display local browser variables. So just using JavaScript, I can pull out all the navigator.appVersion and appName variables and basically determine what software the kiosk is written on. So MSinet and WinHDP.dll actually display Internet Explorer app versions. So I can visit this page on iCAD and it'll tell me if the kiosk is based on IE, or if it's based on a custom browser control. This gives me more information about the attack target, about what I'm trying to do. This can also detect the presence of the .NET CLR. You'll see in the navigator app version that if .NET is installed, it appends itself into the app version. So you can see that this particular kiosk has .NET CLR 2 installed. I can also display remote server variables. So I can discover the remote IP address of the kiosk terminal. Pretty handy things to know, right? Okay, iCAD also contains all common browser dialogues in one place. So you can just click down a list, things pop up and you can see if they're blocked or not. So I have a file open, file print, file save as, and a print preview dialogue that'll pop up. And this is pretty handy. This saves the guesswork and really decreases the time involved in hacking a kiosk. We can also use flash to invert common dialogues. So Adobe Flash is the most widely used plugin in the world. According to the Adobe website, there's something like 720 million browsers with flash currently installed. And ActionScript 3 is capable in invoking three unique file open dialogues. These are select files for upload, select files for upload, and select location for download by site name. Now the dialogue title in these cases are actually very important because when a kiosk is monitoring the windows that pops up, it's verifying the dialogue names against the blacklist. So if I can pop up a common dialogue which has a unique dialogue title, then it might evade the blacklist. So the flash dialogues are not the standard, i.e. choose file dialogues. So that bypasses quite a few blacklists. But they still contain the same file view control. So you still get the same functionality, you just defeat the blacklist. Okay, we can also try and spawn applications on the kiosk. So can we cause an application or process to launch on the kiosk? Perhaps the spawn application contains a common dialogue. Perhaps we can use that application to then provide additional access to the kiosk, or further compromise the host. So iCat tries to invoke the default Windows URI handlers. It'll try and invoke call to, go for HTTP, tell net, TN-3270, R-LOG, and LDAP news and mail to. Now essentially, if you click the ahref link that I have on screen there, to the mail link, the default Windows mail to URI handler will spawn. In most cases, this is Outlook Express. So we can get Outlook Express to pop up. We can also try and spawn third-party URI handlers. MMS, Skype, SIP, Play, Steam, QuickTime, you know, the list goes on. Whatever is installed on the kiosk, we can make that pop up. I'll potentially use that app to then escape the kiosk jail. It's all about invoking functionality, getting shit to pop up, getting something other than browsing the Internet. Okay, here's an example. We're using the HTTP, the help and support center in Windows. So if you click the link, the ahref-hcp-4-slash-4-slash-dummy link, you can get help and support center to pop up. Now basically, you can use the help and support center to then invoke a command prompt. And how you use it is you basically search for using the app you want to launch. So if you search for using command prompt, it'll pop up this page on how to use the command prompt, which is really handy. And then you'll see in there on the far right, the little link that says open the command prompt. You notice that you can click that with the left mouse button only. So this is quite cool because most kiosks don't have a right mouse button. So this provides a good method of doing that. And the same for notepad or pretty much any Windows app. You can just search for using an app name that you want to launch. Bang, you got it. Okay, so iCAP provides links to over 100 different URI handlers. So you can just click, click, click down the list and see what pops up. You can determine which handlers are covered by the kiosk blacklist and use the invoke handler to escape the kiosk itself. I've also implemented automatic execution of URI handlers. So by using DHTML and JavaScript, I can sequentially invoke all of these handlers. So you don't even have to click down the list. You just click once and the shit just pops up. It just spawns fucking everywhere. And you win! Okay, iCAP also contains all of the physical input vectors that I was talking about before, the URLs to type, all the different permutations of typing in C colon windows, all the shell handlers, and also the GUID shell handler, as I told you about, because obviously you're not going to be able to remember the GUID of the control panel when you're sitting at the kiosk. I can barely remember my name in the morning. I'm not going to remember a GUID. Okay, so we can also invoke applications using file type handlers. Now, if you click on a file, such as test.myfile, windows will spawn the myfile file handler. Now, Internet Explorer actually supports promptless handler execution. An example of this is Windows MediaPlay. I think for seamless integration with a browser or some crap like that, if you click test.wmv, a Windows MediaPlay will just pop up. It won't actually ask you, hey, are you sure you want to launch Windows MediaPlay? It will just spawn. Now, this is really, really good for us, because remember, kiosks are monitoring all the stuff that pops up. So if nothing pops up, it can't block it. So Windows MediaPlay becomes a pretty good trick. Now, that's determined by this edit flag setting, which is a binary bit. If the third bit is one, then you don't get any prompt that pops up. And I found a bunch of different apps that basically don't prompt or don't ask you anything before they launch. They just spawn. And of course, kiosks fail to detect these things when they launch. So I can't, again, use this DHTML and JavaScript to invoke 108 unique file handlers. So I have a list of every possible file extension I could think of. And it'll try and invoke all of them. So again, you can possibly get 108 different things just popping up. It's just good, you win again. Okay, I can't, and Windows MediaPlay files. So I thought to myself, man, this is really cool. Windows MediaPlay spawns without asking me anything. I've got to expand this. I've got to get some cool tricks out of this. So Windows MediaPlay will silently launch for the .asx file format. These are the playlist files, right? Who here knew that you can have a playlist which is web-enabled? Oh yeah, couple people, couple people, cool, cool, cool. All right, so it's a pretty... I didn't really know you could do this, but you can see the screenshot of the top on the right. I have a playlist that basically says, hey, I have web content that's available here. So the .asx file that I have available on iCat will actually cause Windows MediaPlay to pop up and then launch a browser inside itself and re-browse iCat, which is my tool. Now, this is a really good trick because when you can get Windows MediaPlay to act as a browser, it essentially gives you a browser with a lower security control than the kiosk. So you decrease the level of paranoia that's implemented in these kiosks, and you can then use Windows MediaPlayer to hack the kiosk again through its browser. Go through the same process. You click everything in iCat, different shit pops up. You win again. You can use Windows MediaPlayer for your advantage. The only disadvantage on this is the dialogue that pops up that says this enhanced content you're about to play uses the following web page. You should only open web pages from sources that you trust. Of course, you trust iCat, right. And no kiosk blocks that dialogue. Well, that's pretty handy. Okay, so iCat and Office Documents. So I realized, hey, Office Documents are pretty cool. It's an amazing platform that can do all sorts of crazy stuff. What can I do with Office? So I realized that if you have an Office file viewer installed on a kiosk, you pretty much win. And you win because in an Office document, you can embed an object. So I thought, well, if I can embed an object, why don't I embed an executable? Why don't I embed cmd? So I have doc files, docx, xlx, xlsb, xlsm, and xlsx, which all contain embedded cmd files. So if you use the iCat file handler invocation trick and you find that Office pops up, you may get a document which says something like this. cmd.exe embedded within a doc file. And then you double-click it, and the open package contents box pops up and it says, warning you, very specifically, this package you're about to open will run a program, contain this package. That program could do anything. It may harm your computer. I don't really care about the kiosk. Okay? I've got a whole lot more file handler tricks like this, but I don't really want to detail all of them. I have 108 files in iCat. So basically I'm just going to say that iCat will try and spawn the most useful file possible to make your hacking attempt easier, smoother, and faster. Okay, iCat and Java Rapplets. Okay, so side Java Rapplets can execute local processes. Did anyone know this? Yeah. No one? All right, all right. So who knew that you can actually get a Java signing cert for free? That's pretty good. I'm a bit of a cheap ass. So you can detect if a JRE is installed by using the iCat reconnaissance trick, the first thing I showed you. And that'll basically tell you if Java is installed. Now if Java is installed, you can use iCat to then spawn different Java applets. And those Java applets will try to do different things again. So of course you can spawn cmd, you can spawn notepad, you can spawn regedit, you can spawn command.com. And this little dialog box pops up. It says warning dash security. You're guessing around yadda yadda. No kiosk, block that dialog. So again, you win. One of the things I included in here was Jython by PDP from Genius Citizen. I don't know if PDP's in the house. PDP in the house? Nope. All right, so Jython is inside an applet, which is pretty powerful. No, sorry, Jython is Python inside an applet. So you can invoke Jython from iCat and get a full Python terminal inside Java inside the kiosk. You can then use Python to just start executing whatever Python code you want to start running and further own the kiosk from within Java. Which is pretty handy. Okay, what about ActiveX? Now safer scripting ActiveX can be used to compromise a kiosk. So we can have an unsafe method within an ActiveX control. So object.execute cmd.exe. So the question is, can we install a malicious ActiveX on a kiosk? What I did was I wrote an ActiveX. It has one method exported called execute and it will execute any executable you give it. I wouldn't suggest installing this on your desktop computer. This is a very insecure ActiveX, right? But it fulfills the purpose of what we're trying to do with the processes on a kiosk. Now installing an ActiveX requires administrative authority. So if you have admin rights and you can install an ActiveX, then you're pretty fucking lucky. And props, you got it. But the chances are this isn't going to work. This isn't a very highly reliable method. Now, I have noticed that ActiveX and the way ActiveX is written deployed is essentially changing with Internet Explorer 8. So as of Internet Explorer 8 we're trying to install ActiveX because, technically, an ActiveX will no longer be installed, which can potentially mean that in a few years' time when kiosks start being based on Internet Explorer 8 libraries, this trick will come in very, very handy and will be very powerful and get you lots of shells and punish. Okay. Click once. So, click once is .NET 2.0 plus technology. Who here actually knew about this? Well, okay, like four or five fans. That's good. I don't even know about this. I don't even know that you could do this with .NET. So this is called online application deployment. It uses the .application file handler. Essentially it means you click a .application file and .NET just downloads stuff and starts running it. Well, that's really cool because you don't need admin rights. You can do this with an unsigned application and you can execute with full trust. And our CAS isn't implemented. The code access security policy. So essentially you can do pretty much whatever the fuck you want. And that includes running binaries doing, well, pretty much anything. Now users are warned. You get this dialog box that pops up that says application run dash security warning. Again, no kiosks were able to detect this dialog box. So if .NET is installed, you win. Now this is particularly important because many kiosks are now written in .NET. Which means the CLR is present. And .NET 2 is installed. So this is basically one click. You got shell. I found this to be the most powerful, the easiest the fucking bomb. It really works. This is Uber. So I said to myself, .NET is this powerful attack vector. What can I do with this? How can I really expand application deployment to fully compromise kiosks and do it faster, do it better? So I wrote a whole bunch of apps. First thing I wrote. Also I wrote the iCat embedded web browser. So the idea behind this is that you click a link and it will spawn up a new web browser. It will spawn a web browser that doesn't have the same paranoid security restrictions that the kiosk has. The similar trick to using winners media players web browser. You can then use that web browser to then further compromise the kiosk. Works pretty good. Or you can just use it to browser websites that may be prohibited or banned from the kiosk or it just gives you a basically a version or a refresh of IE. Then I wrote the iCat application executor. The idea behind this is the ability to spawn any executable you want. So you can say, I want to pop up CMD. I want to pop up notepad, command.com. It also supports macros. You can say, I want to spawn every useful application on this system. And it will spawn 62 applications. Everything from the onscreen keyboard to task manager, regmon, help control panel, command.com, cmd.exe, everything. It just does absolutely everything. Then I thought to myself, wow, geez, since I'm getting that pretty good at writing.net maybe I should write a token hijacker. So I wrote the iCat token pincher. Now recently token hijacking has become a very hip subject. It's kind of like the new cool thing to do. The idea is that you can have a user on a Windows system which has what's called the SE impersonate privilege. Now this is typically a network service users or users that have slightly more rights than a user, but not full admin rights. Such as maybe a power user. Now the SE impersonate privilege allows you to impersonate any available system tokens that may be on the system. Maybe on the kiosk or the terminal. So the iCat access token pincher will enumerate all of the system tokens that are available, and then pop you a system shell. Which is pretty good if you have the SE impersonate privilege. And it'll spawn cmd.exe into the context of the privilege token. This is loosely based on a script that came from Insomnia security, Brett Moore. He wrote something called Insomnia shell, which was a .spx token impersonation shell popper. And I sort of adapted it and modified it and rewrote it a bit into the iCat access token pincher. So props to Brett. Okay, so who here has ever crashed a web browser? Put your hand up. Yeah! I wanted that response. Web browsers are pretty crap on there. So what about crashing a kiosk? I call this emo kiosking. Or kiosk self mutilation. Alright, so if we can create an unhandled exception in a kiosk browser, we win. Why do we win? Well, the kiosk browser crashes. Pops up that little dialogue and says, oh no, I've had an exception of crash. Don't know. Other than there's the desktop. Woo! That's pretty easy, right? I mean, you win. This is, I think, one of the only situations where an application crash is actually a really highly critical vulnerability, because it completely escapes the kiosk jail. So what it did in iCat was I found a whole bunch of really common exploits that affect win.hdp.dll and msinut.ocx that cause crash situations. You know, you can't get EIP, you can't pop a shell, but everything just crashes. And I added all of them into iCat. So essentially you can just click down a list and see if the kiosk crashes. This is good if you just want to be a real asshole and crash a kiosk. This is the fastest, easiest method for escaping a kiosk. And it's fairly reliable. I found about 40% of kiosks crashed somewhere or another. I mean, that's not 100%, but it's something, right? It's something. But then I thought, what about browser plugins? Ooh! Bet I can crash those. So I thought to myself, well, what's the most common browser plugin in the world? Well, 720 million desktops have the flash plugin installed. Oh, well, I should focus on flash. So I performed a file format fuzzing on the SWF file format. Essentially trying to find an SWF file that would reliably crash a browser. Any browser. And it turns out, I found a few. You can actually crash your browser very, very reliably with flash. The exploits I found are immediately unexploitable. These are not shell-popping O-Day, but they crash. It crashes a browser. So I created what I call the iCat AutoMagic Flash Crasher. So if the flash plugin is installed on the kiosk, iCat can crash it, guaranteed because it's O-Day. Hey! It works! So the trick then is, really, does the kiosk detect the unhandled exception and respawn, or does it just present the desktop? So some kiosks detect the unhandled exception. They hook the SE unhandled exception filter, and they say, well, you know, shit, something bad happened. I better respawn the kiosk and continue. But a lot of the cheaper products just don't, and they just crash, and you get the desktop, and you win. Okay, so let's assume something works. Out of that list, I can guarantee something works. And let's say you have access to the kiosk file system. Maybe a command shell spawned. Maybe a common dialogue popped up. Maybe five minutes. Alright, I'm going to have to move. Alright, so maybe a command shell popped up. Common dialogue, Java, et cetera. So now you need to download additional tools and binaries to the kiosk. So how do you download files in a tool-less environment? So the kiosk isn't going to have Wget installed, right? File downloads are likely to be disabled. How do you download stuff on a kiosk that won't really let you download stuff? Okay, so old school. Downloading files and windows. You can download files using a common dialogue. If you could pop up a file-open dialogue, you can type in hdp- website cmd.exe and it'll download it. It'll save it to the temporary internet files folder, as you can see in the screenshot from below. This downloads any file, type, or size. You can use flash to download files. So most kiosks disable file downloads within the browser security policy. So going into IE Tools, Internet Options, Custom Level, File, Download, Disable, it's in the screenshot. You can use the flash file reference object to download files. And it bypasses the browser security policy. Flash doesn't actually validate the browser security policy, and it'll download files for you. This completely bypasses browser security. This is, again, another O-day trick. This is unpublished and works very, very effectively. You can use Notepad to download files. You can go file-open in Notepad and just download a text file. It has to be 7-bit safe. It can't download 8-bit data, but you can download files using Notepad. So if you find an interesting log file on a kiosk, you can upload that using Notepad to a remote website. Another cool trick. Okay, so the number one problem, kiosk hacking, is a toolless environment. So I thought to myself, I-Cat needs to provide tools for kiosk hacking. So I have a whole bunch of tools there. I'm going to try and run really fast as present now so we can actually do a demo at the end. So I'm not going to explain these tools to you, but as you can see on the list, I've got things to enable start-laws, things, pretty much everything. They're available as .exe.zip and used in a flash download method so you can just bypass the browser security policy crap. And they're also available using VB script and 7-bit safe so you can download them using Notepad, which is pretty handy. I'm just going to skip this. I really want to reach the demo. I want to show you guys some shell. Okay, so using I-Cat, I-Cat is a tool designed to aid penetration testing in kiosk hacking. One thing I want to say is don't be a dick and attack the server. Don't try and crash anything. Help me make this the best kiosk hacking tool in the world. So make me feedback. Also, I-Cat is going to be open sourced real soon. So I'm going to release I-Cat portable so you can download it onto a USB disk, plug it into a kiosk. If you're a security consultant working on site, you don't have internet access. Okay, so the demo is... Okay, so I know I said I can hack an internet kiosk in less than 120 seconds. That's but proof of the punning. I may not do a lot of talking. Just watch. Okay, so... Here, I have a kiosk. Can you just full screen this? Can you guys hear me? All right. All right, so I'm going to Google real fast for I-Cat. Paul Craig. Here's I-Cat. I-Cat. Whoa, here's I-Cat. Check out that picture. Oh, yeah. All right, so firstly, it's thought applications. This kiosk is running here where kiosk, basic kiosk. I can see I have all this shit installed. I have .NET 1. I have .NET 2. I have Windows Media Player, things like that. So let's go down. Let's see if I can pop up a common dialogue. Okay, so can I pop up file, open dialogue? No, nothing happens. It's blocking the dialogue from popping out. Oh, shit. Oh, no. But I know .NET is installed because it told me .NET is installed. So I can click on this and it wants tools. I'm going to run the I-Cat application executor. So I have a help system here as well using DHTML pop-ups that will basically tell you what all of the tools do. Watching application. And that's okay. Don't worry about that. Okay, now I have a bit of a rule here. Whenever I pop shell, you clap like wild warresses. Okay? All right? Execute. Hey, shell. Command shell detours. I'll go through 17 different command invocation methods. This will bypass anyone that's trying to block cmd.exe or command.com. I use win.com, lofix.exe. I use start. I use every possible method on Windows to invoke a cmd.exe. And shell, shell, shell, shell. What's the time to have now? Okay, I'm going to try and do one more kiosk. This is Internet kiosk pro. I on purpose didn't want to do that. This works. Try it. It works. Nine seconds it took me. Nine seconds. So, again, I'm going to Google. iCat, Paul Craig. Hey, iCat. Hey, iCat. Um, so, firstly, installed applications. Once installed, hey, Internet kiosk pro. I got Winner's MewPlay 11. I got all that good stuff. I'm just going to go right down and check out some of these tools I have. I got these really kick-ass tools. Can I download a copy of cmd.exe? Oh, your current security settings did not allow this file to be downloaded. Uh, what about... What about this? Oh, damn, that doesn't work. What about using Flash? Wait for it. Wait for it. That's the end of my talk. Thank you very much. Have fun owning kiosks.