 My name is Pelle Suley. I'm a principal security consultant at Symantec. I joined Symantec after the at-stake acquisitions. So prior to Symantec, I worked for at-stake. I still do the same job that I did for at-stake just in a different organization. So I primarily focus on doing penetration testing of different environments. I don't have a handle because usually if I find my name is confusing enough to stop most people. Okay, so when I'm going to go over, first I'm going to go over why KIA security seems to be serving out there talk. People haven't talked about it in a while. There's a whole lot of information out there on it. Then I slowly walk up the OSI model in terms of the different level of protections. What I'm going to do is I'm going to go kind of fast through the first couple of levels because the first couple of levels are probably fairly intuitive to most of you, put the computer in a locked case, et cetera. And then we're going to get into some of the application security aspects. And here where I'm going to focus is how KIAs interact with web apps and how developers need to think about their applications in the context of a web application, which not all of them are currently doing. So if you go to Merriam Webster, it divides the KIAs as a small standalone device providing information and services on the computer screen, not the best definition I've seen out there. According to this, your PDA could be a KIAs. What I'm going to do is I'm going to expand it a little bit farther and say that a KIAs is a public accessible terminal that provides a single application for use by end users. This talk is primarily going to focus on Windows KIAs that run the AirNet Explorer browser or a similar browser. There are many different KIAs platforms out there. Some are on Linux, some are on Windows, some are on proprietary operating systems. For the sake of this discussion, I'm going to focus on the Windows based operating systems because that's the ones you see out there more often. You probably have seen them in multiple places. You probably use them if you look around any of the casinos. You see them everywhere. You probably use one to get your plane ticket to come in here. Also, I chose to do KIA security because the methodologies I'm going to be talking about apply to other arenas besides just KIAs, for instance, Citrix applications. Citrix applications operate similar to a KIAs. The only difference is you use your web browser and plug in the web browser to access a single application instead of actually standing directly at the device. When we talk about KIAs, we have to sort of understand where they sit within the environment. I found this one online. I sanitized it a little bit, so I didn't pick on the particular vendor. But you can see they tend to live in fairly complex environments. This particular one had a 80 gig hard drive on it for storing information that is processing. It also had internal connections to public servers where it was able to pull off media. It also had connections out to third-party websites. So in terms of a public computer, KIAs are interesting to hackers because it's almost like saying in the terminal within the environment. If you go sit at the admin's desk, you have a nice computer in front of you, you have access to internal resources, you have access to the internet. With a KIAs, you end up with a similar environment. So getting sort of into why KIAs, KIAs have been growing a lot recently. You can't go into any retail store without seeing them now. CEOs, CTOs, they all love them because it makes all the customers who believe that if you want something done right, do it yourself. It makes all of them happy because now you have the ability to go and do things yourself without having to actually interface with the store staff. The store staff are happy because they don't have to interface with you. And it drives revenue. Most of the places, they find that people who are using the KIAs to stay in the store longer, they get their answers to their questions faster, etc. From a CTO perspective, in terms of risk, one of the things that you have to consider is PCI compliance, which is the payment card industry data security standard, which defines how environments are supposed to behave and how they're supposed to be protected if they store, transmit, or process credit card data. Some of the KIAs that I'm going to show in a few seconds actually do that, so they fall under PCI compliance. The PCI standards are fairly strict and fairly well-defined. So deploying a public terminal that correctly protects credit card data can be a challenge. For the IT administrator, it's basically the ultimate lockdown challenge. The Windows operating system was designed to be all things to all people. They're supposed to give you accessibility to everything, you're supposed to be able to get everywhere, and the operating system within only a few clicks. And when you're deploying a KIAs, what you're doing is you're trying to take that operating system and limit it down to do just one thing. That can be somewhat daunting to go through and turn all of those things off. There's network segmentation issues for the network admins in terms of keeping the KIAs away from protected devices. They can be difficult to manage. These are all out at retail stores. So there's usually not an IT person on site or near the environment. This may be in Oklahoma, it might be in South Dakota. You probably don't have IT admins at every single one of those places. The best thing you have is calling the store manager and hoping that he's a computer guy. And then also what I'm gonna get into later is that these redefine the risk of web applications. I'm gonna be taking a look at how vulnerabilities and web applications can actually be a threat to the KIAs environment, and therefore a threat to your internal network. If you saw some of the Black Hat Talks, a lot of the Black Hat Talks focused around cross-site scripting. There was cross-site scripting in AJAX, there was cross-site scripting in MySpace. Spy Dynamics did a talk about cross-site scripting in Armageddon. So for those of you who have attended Black Hat, some of this is gonna cover cross-site scripting again to a certain extent. And then from the hacker's perspective, why is the hacker interested in the KIAs? Well, this doesn't really require an advanced skill set, at least not until you actually get onto the device and into the terminal, and then how far you get into the network is dependent upon your skills from attacking from an internal resource. Since many retailers and many large corporations all have sort of the Skittle security model, crunchy on the outside, soft and chewy on the inside. Once you're on an internal network, it's not too hard to progress in. So a lot of the attacks, they just actually use existing Windows functionality that somebody forgot to turn off. Similar to a server, you have potential access to multiple users. It's a single server that's used by multiple users. Therefore, they pay off a little bit better. And also, many scenarios, it's an anonymous attack. You don't have to authenticate to these devices when you do an attack. You just have to walk up there and start using the terminal. Nobody asks who you are or why you're there, or in most cases, what you're doing. So jumping into the first level attack that most people look at, first level attack is your physical security risks. So can you reboot the machine and get it to start up in a different mode? Can you control C out of the login? Can you put sniffers in place? Can you, maybe you just want to steal the hardware because it's got an 80 gig hard drive and you need one. So physical security risks are fairly straightforward. Some of the more advanced devices also need to protect against things such as shoulder surfing because people are processing their credit cards. And there are multiple ways of protecting these. I'm actually going to show a couple of kiosks here in a second. In addition to the cases you put them in, you can also do things such as using thin terminal clients. You don't necessarily use a PC that has a bunch of USB jacks to it. You instead go with something that's a little closer to the Mac cube where there's not a whole lot of interface into it. Also, depending on how secure you need it to be, there's also alarms, cameras, and privacy screens that can be put into place. And actually one of the cool things on the more advanced kiosks is they have a floor mat. One of the things that people are concerned about when dealing with web applications or kiosk applications is what if the person walks away in the middle of doing something, right? You're in target, you're using their kiosk, you look over and your kids run away so you run away from the terminal, go chase the kid, all of your information's still there on the screen. One of the ways that they protect against that is they put floor mats in front of the kiosks which determine when people step onto them and step off of them. That way when you step off the mat, it triggers an application reboot and therefore clears all the information out of there and you don't have to worry about the application storing the data when you walk away. Just take a look at some of the different ones out there. These are two that I saw just at Office Macs and Best Buy. These are your fairly simple deployments. All they're doing is locking up the CPU in the cabinet but you still have that direct access to a normal keyboard, a normal monitor, and in these cases a printer environment. To go one step farther, this is one from Vons. They also have custom cabinets. So here you don't have to worry about people plugging stuff directly into the environment as much because it's in a protected case and the keyboard is actually integrated into the structure. And then you're gonna have to forgive my photography here. My digital camera doesn't take really good pictures of black environments. In addition to using customized keyboard, you can also control what keys are available to the user by not providing them. So here if you look at the keyboard, it's only got one big red mouse button as opposed to two mouse buttons that limits the person's ability to be able to do right click attacks and get to added functionality through right clicking. Also if you count the keys you squint really hard. You'll notice that keys such as alt and control have been removed from the environment as well as the F keys. That is a really easy way for people to prevent attacks from using specialized keys and keystroke combinations, control C, alt at four, et cetera. And I also took a picture of the target one because you can't really read it on the projector screen but one of the things that the target key ask allows you to do is that first button says target visa account management and the other is target card account management. So if you want to actually manage your target credit card you can do that from a publicly accessible kiosk. I didn't take a look at the exact details because I didn't have a target visa card and I didn't particularly feel safe and if I did have one putting it through the system. But some of these kiosks that are available they do process credit card information that's why they are PCI compliance issues come into place. On the far right hand side you can see the card swipe for you to swipe your card. If you're swiping your card that means there's track data which is being processed by the machine which is also a very sensitive topic for those who are under PCI compliance. Target isn't the only one that does this. I've seen card readers on things such as Home Depot kiosks, et cetera. But I'm gonna be referring back to this deployment because this is one of the more sensitive deployments with the kiosks. I also noticed these while searching on the internet. I don't know if there's any physical vulnerabilities to these. I haven't actually physically seen these in person. I just couldn't imagine that a computer geek who was a hacker would walk past these and not try and screw with them. So. Moving on to the network layer, there's two attack scenarios and everyone thinks of the first attack scenario, right? Someone comes in, tries to break into the kiosk and goes from the kiosk outward. But there's also another attack scenario that kiosks people don't always take into account and that's a hacker in the internal network who wants to go in and actually take control of the kiosks. The kiosk and the VONS scenario that takes your employment record so if you want to apply for a job and you want to put your name, your address, all of the schools you went to, all that sort of personally identifiable information into it, you can, that might be of interest. Also for somebody who wants to go after credit card data, they might not go after, they may not want to take the risk of going after the internal database. The internal database has firewalls, it has IDS systems, it has admin who are actively monitoring the devices or at least that's what everyone hopes. But the kiosks tend to be just another PC that's out in the environment and aren't always monitored as heavily. So rather than going to where the data gets stored in the database, the attacker may choose to go to where the data is being input, which is the kiosk. And this also gets back to the fact that a lot of retailers have very flat, very open networks. So chances are the attacker could probably be able to ping the kiosk if they wanted to. And then once they have access to the network, there's a whole series of attacks you would be able to do. You can download your tools from the internet to do your malicious attacks. If the kiosk is using a wireless connection because the kiosk is in a retail store that wasn't originally wired for networks, one of the ways you could generate wireless traffic to do your web cracking would be to use the kiosk. You would have an idea of what was being sent and when because you're controlling the device. As far as DMZ setup for kiosks, network-wise it can be very complicated, especially if it's under PCI compliance, because you have to segment the network so specifically. You can see someone from Visa smiling in the corner there. But basically you have to have filters on everything. You have to have filters on where it can go out on the internet. Traditionally, with these web applications, you only want them to go to your store. You don't want them to go to evilhacker.com and start downloading to the tools. So you have to have network filters about where they can go out on port 80. You also have to have filters in terms of where they can get to internally. Chances are there's only a handful of places you want the kiosk to be able to touch internally. And if you don't have filters in place, the person's going to be able to roam the network pretty freely and I actually have an example of that a little bit later. And then also to protect from the internal attacker, you want to make sure that access to the kiosk is limited to only the administrator zone. Logging, logging can be done a couple of ways. You can do the traditional assist log type setups. Some applications also log over the internet. So if you go out and get a commercial off the self system, what some of these will do is they will post to a website all of their log data. The problem is that a lot of these kiosks are designed by people who are concerned about ease of use and functionality, so they may not be logging everything that you need to be able to log. It's just going to log uptime and CPU usage and things like that. And the other two are fairly straightforward in terms of protecting the environment. As far as host and application OS security risks, this is something that I've also used when attacking citrus devices. And basically what it is, is escaping the system in the way the administrator wasn't thinking about and using that for malicious intent. For instance, with SysTrade functionality, your antivirus software may allow a user to create a log of the quarantine report. I use that once to create a file with a weird extension. I then double clicked on the file and that brought up the open with dialogue and that gave me a list of the applications that were already installed that I could use for the environment. Also, attackers are going to be going after local file access. So you want to make sure you have your NTFS in place of using search functionality. I remember internet explorer is an integrated part of your operating system. So in addition to being able to search the net, you can also search your local hard drive and mounted drives. Other things people can do, you can use a customized shell. So what some kiosks do is it will have it launch internet explorer by changing that reg key. So rather than launching explorer.dxc, it'll launch iExplorer.dxc. The rest are some fairly good tools in terms of being able to lock down the environment. Microsoft published the Microsoft shared computer toolkit. This will have most of the OS stuff that you need to be able to do. It's a toolkit that was designed to allow people to secure public access terminals. So it walks through many of the controls that you would need to have in place in order to lock down a public access terminal. So that's pretty good. This URL has some nifty XP registry tricks. So some of the things that I'm talking about, such as disabling print to file, et cetera, those aren't as well documented. This URL actually has tons of little XP registry tricks. I won't profess that all of them are exactly accurate, but usually you can find out the reg key name and go to MSDN from there. And the last way you can secure the environment if you wanna go with Windows is to use a Windows CE and kiosk mode. Microsoft publishes a Windows CE that's available for kiosks, although when I was doing my research for the device, one of the things I found was a blog by an MSDN developer who said that, even after two service packs, the Windows CE kiosk does not work for all installations. There are just too many different variations of how kiosks work and how kiosks are deployed for it to work for every installation. They took their best shot based on the most common practices. Some of these are fairly obvious. You would probably know them if you've ever launched a public access terminal before, so I'm not gonna go through each of them in depth. I am gonna talk a little bit about software restriction policy in IE in a few seconds. These are also fairly common attacks. These also help protect against some of the physical security attacks that you may see. Just to give an example of sort of hidden functionality that people tend not to think about. If you go into IE and you do file and you go to print, one of the checkboxes is print to file. It sometimes overlooks small checkbox, people don't think about it. But if you select print to file, it'll allow you to go here. If you have NTFS permissions in place, the worst they can do is write to temporary directories. Unless, of course, they click on network, which then allows you to get to map network drive. And if you don't see the drive you like, you can go out on the internet, start looking for one that you do like. So just from going from something as simple as print to file, you then are able to get to things such as map network drive, connect using a different username. Another functionality you probably didn't think was associated with that. With software restriction policy, I've seen a lot of people deploy software restriction policy without really understanding that none of the solutions are perfect. For instance, one of the ways that software restriction policy works is it allows you to take a digital signature of the application, and then you can create an allow or deny role based on that application. So for instance, let's say you don't wanna allow command.exe to run. You import it into the software restriction policy, it creates a digital signature of command.exe, and then no matter where I copy command.exe on the operating system, it won't run because the signature matches. Downside to that is you're basing your rules based off of the signature. So if you use a different application, then you can bypass the software restriction policy. For one engagement, all I did is I went off to FreshMeet and I found some persons customized command shell, which had different font colors and allowed you to do utility CDs and stuff like that. I downloaded that. I got command line access using a different command shell than the one Microsoft provides. Restrict run, if you're deploying Windows 2000, one of the ways you can restrict applications from running is using the restrict run process. However, this is name based and it's only applications launched through the Explorer process. If the application is launched through the system process, the application will still be allowed to run. So you need to be aware of the limitations of some of the tools that you're using. Whitelist is always the best solution but it is difficult to implement. Although, in a kiosk situation, it's actually sometimes a little easier to implement because they are such specialized devices. And then there are the shortcuts, right? Control Shift S to try to get the tax manager. A lot of the people I've talked to who were willing to admit that they had broken into a kiosk at one time, most of their attacks went through just doing simple key combinations. One thing I also noticed is the flying Windows key for those Best Buy and Office Max solutions. You notice that they gave a Windows natural keyboard. Sometimes what happens is the developers are using their laptop, their laptop's created by IBM, it doesn't have the flying Windows key, they don't actually think about it. Then it gets deployed to a kiosk that does have the flying Windows key and the flying Windows key actually does a few cool things even though it's mostly marketing. If you need the list of everything that can be shortcutted, I include the URL from Microsoft in terms of all the command line shortcuts. All right. That gets us to what I really wanted to get into which was the web application security risks. This is where we've worked our way up or now at layer seven. A lot of times when you're doing a pen test of a web application, most people consider cross-site scripting to be less important. If you're not a target of phishing, if you're not WAMU or eBay, cross-site scripting may not have that large of an impact in your environment unless you're deploying a kiosk and I'll get to that in a second. Also, administrators don't always think about authentication timeouts, what's left in cache, et cetera. Typically, they take the point of view well, if you're using a public access terminal, you should have known better. We're working on our target alliances of people using home computers or trusted systems. However, if your company's actually deploying the kiosk, then there's an additional risk and you have an obligation to make sure that it works within your kiosk environment. So if some of you attended Black Hat, White Hat Security did a presentation on how to use cross-site scripting to be able to do Nmap attacks, to be able to establish URLs of sites visited, how to capture keystrokes, et cetera. None of these use traditional browser exploits. This was all using existing functionality within the browser. JavaScript is a programming language which has security imposed upon it by the browser. So there's a lot you can do with just existing JavaScript functionality. Some of the people I talked to, they thought, well, yeah, but if somebody closes the browser or shuts down the machine, it all goes away and you'd have to sit there for a while in order for some of this stuff to work to go through all the Nmap ports. And so it seems fairly esoteric. However, in a kiosk environment, it's not as esoteric. You are the person who is controlling the browser is you. Therefore, you will sit there as long as you need to in order to collect the information that you want. And you won't close the browser and you will allow their tools to be able to go through and connect to all the different ports and start to do an attack. And the best thing for you is if the machine actually does wipe the cache after you walk away, they've just wiped away all of the evidence. Most of the attack was happening in process memory. So there's a very small footprint involved. You don't need to install a machine on the code. All you need to be able to do is use a cross-site scripting attack to redirect to a website which has their tool in place. So document location works just as well as having the location bar physically present within the environment. Another scenario that people don't look into is unplanned functionality. They don't necessarily integrate the kiosk into their QA of their website. Gives the developers aren't necessarily aware of it or they just haven't thought to actually include it within the environment. So this is a story I got off of security focus where somebody broke into the application by accident. This web application, what it allowed you to do is configure a URL to go to after you click logout. So you click logout and if you wanted to go to news.google.com it would send you to news.google.com. The problem here was they didn't think about how that would affect a kiosk environment. So here what the person did was they had that configured, they went in, they used the kiosk. The application tried to redirect them, they got it prompt, it came up and said you're not allowed to do that. He went okay, but it still sent them there anyway. Most of the Windows environments I've tested all tell me I can't do something and then allow me to do it anyway. So he was able to go out to the external location. And he got a little more curious about where it could go and he also discovered that he could find the internal website fairly easily just by going through 10, 10 addresses. So this is an example of developers not thinking about how their application works in a kiosk environment. One other example of not thinking about how your environment works with kiosks. This is the Amazon sign off policy for how you log out. I recently went to Amazon, bought something off of Amazon and I was looking for the logout button. I couldn't find the logout button. So I went clicking through their fax and I found this in terms of how to log out. Now you have to go through three steps and you have to enter in blank information. And the third step says close the browser. In kiosks environment, you're usually not allowed to close the browser. So that creates a scenario right there. Amazon went through, I guess they burned out all of their engineering coming up with a one-click purchase and are still working on the one-click logout. So there's all sorts of Internet Explorer risks. It's tied into everything. Sometimes you can abuse multimedia plugins to get to places within the environment. Sometimes you can use control keys. If there are non-terminated sessions, then somebody could walk up and take over somebody's session once they walk away from the application. They could potentially get file system access, et cetera. One of the things that Internet Explorer allows you to do is you can actually run Internet Explorer in kiosk mode. This is standard install for Windows XP. So, wrong Internet Explorer. If you're running kiosk mode, it just looks like this. It's essentially full screen mode without any of the buttons. There are some downsides to this, one of which is you can still open up locations and none of the control keys are limited off of there. And all you need to do to launch it is type iexplore.exe-k and that'll launch in the kiosk mode. So, early when I mentioned, you can change the command shell you log into. What a lot of people who use that registry key do is they substitute this command line in for this shell. And then when the application logs in, it immediately launches Internet Explorer in full screen mode. So, while it does prevent people from being able to get to certain spots, there are limits. Control keys still work, frames with JavaScript navigation would still work, et cetera. So, you still have to go through the process of locking down in i.e. And if you're going to do that, one of the ways you can do that is the Internet Explorer administration kit. This is fairly flexible. It gives you most of the controls you need. It's published by Microsoft. You can download it. They have documentation. It explains all the different group policy settings. The third set way of going about it, and this is what a lot of commercial off the shelf applications do, is they put a wrapper around Internet Explorer. So, they'll use the container object model. And what they'll do is embed Internet Explorer into the application. That prevents you from having direct access to Internet Explorer. Their application captures all the keystrokes first and then feeds it into Internet Explorer as needed. This is a fairly successful way for most people to lock down their applications. But you still need to go through and go through a penetration test to make sure that the controls within Internet Explorer are still secure, because a cross-site scripting attack would still work potentially in this scenario as well. If you're going to lock down on i.e. the manual way, this is just a small list of some of the things that you wouldn't want to lock down. I'm not going to go through each of them. Some of the more important ones are things such as File, which disabling a file protocol so you can't get local drive access. If you're using Mozilla instead, there are things that you want to be able to lock down there as well, such as About Config, in terms of being able to protect the environment. You need to make sure that you have all of your security settings in place, et cetera. You have to keep in mind that there are multiple, multiple ways to get to the Internet Explorer security settings. For instance, you can get there from going to the Privacy Report. So if you go into i.e. and you select Privacy Report from the pull-down menu, from there you can get into the settings. You can get to those settings through using Windows Media Player. So if the site has Windows Media Player and you're right-clicking around in there, you can get to those settings. So you need to make, assume that somebody's going to be able to get there. In most cases, if you're a host operating system, admin, you need to assume that the person's going to break out of the application. You need to start from that assumption and then secure your box from there. Other control Internet Explorer navigation keys, again, you're probably familiar with most of these. One thing that administrators tend to overlook is Control-L also trades an open dialogue box as well as Control-O. Just a few more shortcut keys. There are a lot of keys you have to lock down. This is part of the reason why people use the customized keyboards. It's just too much of a pain to go back and remap a lot of these keys. As far as application security controls, there's a lot of different things that you can do. One of the things that you can do is you can reboot the application after a period of inactivity. So if nothing's happened within the application within 10 minutes, 15 minutes, go ahead and reboot the application. That way it forces the cache to be cleared and causes personal information to be able to be logged. If you don't want to reboot the application, you can also use Wiper software. Just be careful you don't actually wipe the logs. You might need those later. Another thing that some people do, which is actually worthwhile, especially if you're fairly kiosk heavy, is come up with a custom website. If your normal website links off to third parties, you may go through all the trouble of getting cross-site scripting eliminated from your environment, but you have no control over what the third party site does. And you're probably not keeping up with what the third party's utilizing in their environment. So what some people do is they set up a custom website. That way there are no links to third parties. And they can limit the functionality that the person can interact with to make sure they don't do more with the account than they really should. As far as utilizing a custom application, there are several commercial solutions. If you go on the source forage or fresh meat, you can find some entry-level ones which range from $80 to $250. These will mostly go through and set your group policy settings for you. Some of these other ones are just some of the bigger names in the field. Necky is fairly popular in terms of setting up environments and doing custom environments for you and doing custom applications. But again, you have to keep in mind they're not considering your website a lot of times when they're designing these solutions. As far as open-source solutions go, there are several open-source solutions available. One is OpenKD Kiosk. This is, of course, Linux-based, but what it allows you to do is lock down the KD environment using name-value pairs. So that can get a little bit tedious. They also have a Kiosk administration tool so you can go in and do checkboxes for it. I haven't taken a complete look at it, but if you're more of a Linux person and you prefer Linux, that's one solution. There is a custom Chrome for Mozilla available. I took a look at it and it does the job it needs to do, however, the code is a little bit cludgy. So in terms of customizing it for your particular environment, it's not necessarily the strongest code base to work off of. And then there are also bootable CDs. Another approach that many people take is they will say, okay, I'm not gonna do the hard drive, I'm not gonna do the install, not gonna take the risk of them running to disk what I'm gonna use is customize CD. So there's Instant Kiosk, Kiosk CD, Boothbox. Boothbox is fairly popular. It runs off of a customized Linux kernel called damsmalllinux, so limited Linux kernel. And it's an okay solution, but one of the things you also have to keep in mind when you do these CD solutions is that patch management for a CD-only solution is difficult. If you want to upgrade because there's a Mozilla browser exploit out there, you have to go and re-burn a whole bunch of CDs and mail them all to your retail locations and then have somebody go in and switch out the CD that's being used. It's not necessarily practical for a lot of businesses, which is why sometimes they go with a full operating system install. The URL I provided at the bottom, this is a charity which takes old machines and creates public web stations. So for instance, if people affected by Katrina, you could send them your old hardware, they throw in Boothbox CD and they set up public web stations for people who are affected in the Gulf Coast region. One of the last things I wanted to go through in terms of security is also operation security. Most of the time when I've gone into environments, no one ever asked me what I'm doing. No one asked me why I was taking photos of the kiosks for this slideshow. For clients that have actually had me go in and tried to affect an environment without warning the employees first just to see what we could do and how long we could stand there. In most cases, we could stand there for a really long time and then affect the environment. So employee education can also be important in terms of warning people that someone may try to alter these environments. If it's a target kiosk or a similar setup, they may try to put one of the card readers over the top of the existing card reader. So people need to be able to be on the lookout for that. If you're thinking about actually walking out of here and starting to test some of the kiosks, one of the things that you should probably think of is that casinos tend to have better video monitoring than your average retail store. Also, if you break out of the kiosk and you think, well, I'll break out, see where I can get to and then put it back, you can't always get it back the way you found it or so I've heard. So then you gotta go find somebody and say, stupid computer, broke. If you're designing web applications, you need to make sure that the kiosk is integrating your software development life cycle, that your web developers are aware of the kiosk scenario and they're designing their cookies to be temporary only or they're designing a specialized website or they're considering how the functionality is gonna affect the kiosk. So if it's gonna redirect you like the example I found, something that needs to be considered with these kiosks. Also need to be integrating the incident response programs which I will get to shortly and of course you can always have somebody review the deployment of the kiosk. As far as kiosk security and headlines, this was actually a public access terminal but it was interesting enough that I thought I would mention it. Basically what somebody did is they went to kiosk and they implanted a sniffing program called invisible keylogger stealth. It was kind of popular a while back. At 13 kiosk stores sprinkled around Manhattan. This occurred over a period of two years. The guy just kept going back in there installing it and it's not positive whether it was like this at this time but one of kiosk or Kinko solutions was to completely reimage their kiosk on a weekly basis. That way if you installed a keystroke logger, it would be wiped away. This guy was apparently worth this guy's time to keep coming back anyway and keep stealing public information. And I've got the URL if you wanna see the full story. This also created a problem too when the FBI was going after a terrorist a while back. Terrorists was using Kinkos to go out and communicate with other terrorists. The fact that Kinkos completely re-imaged their kiosk actually put a gum in the works because along with completely re-imaging the OS they also re-imaged all the logs. So the FBI was somewhat stuck there in terms of being able to figure out what this guy could do. In general, if you're thinking about deploying kiosks they are fairly popular. Most of the people I've talked to have either deployed a kiosk themselves or in the process of deploying them or I've broken into them for fun. But they're a major security risk. They're very hard to lock down. Usually it doesn't take a really qualified hacker to break into these things. They're very simple. I didn't really say any O-days or tools with this because you don't need them. In most cases you're using existing functionality or you're using a simple attack such as cross-site scripting in order to get into the environment. Also it requires security at every level. The environments that we've looked at in the past they tend to have the skilled security model. So once you break into the kiosk you are able to get everywhere else you think you might need to go. And you also need to think about your web applications. If you're gonna point your browser at these web applications what does that mean to your environment? What do cross-site scripting vulnerabilities mean to your environment? What do permanent cookies mean to your environment? SSL versus HTTP. How does that work in an environment? How does that work within a kiosk? How well do you have the browser itself locked down against several common attacks? So I finished a little bit earlier than I expected. Are there any questions? Yeah. The point with that is the implementation within the environment. If you have a skilled security environment. The question was what was the point of disabling SSL V2 in the environment? One of the threats would be the internal attacker who's sniffing the environment. Most people are using the kiosk it's not their personal computer. They will probably just go ahead and click okay past any security warning messages. Also in terms of monitoring and knowing when somebody's going to do something and when somebody's gonna go to a site it's much more likely in a kiosk scenario that they would know when that's gonna happen because you can physically see the person doing it within the environment. Yes. How do you like the use of Windows XP embedded for this application? And whether you have any specific suggestions how to secure Windows XP embedded systems? I only heard part of that. Specific recommendations of Windows XP in what? I'm talking about the Windows XP embedded edition. Okay. Which is a lot more suitable for actual kiosk design since you can disable most of the stuff right at the West level. And why are people not using it? Why are people not using it? Different reasons. Some people believe they can go all it alone and just design their own kiosk. There are environments which do use the Windows XP embedded environment. Like I mentioned earlier there was a Windows I found the Windows CE blog where the guy said, they've tried to deploy Windows CE in multiple environments and there's just too diverse in this situation for it. So embedded systems sometimes will work in terms of limiting the number of attacks. Also proprietary operating systems will work in terms of limiting the type of attacks. What I found, the interesting thing I found about Windows XP embedded, because I was kind of curious about one kiosk project. It's basically a full copy of Windows XP professional, except that you get to be able to customize every aspect of the OS and still be able to apply a standard source pack against it. That's about as close as you get to custom Windows. In fact, I'm considering deploying Windows XP embedded as a desktop OS rather than a general purpose desktop OS at this point. Yeah, patching can be critical for these environments and difficult to do given the network segmentation. Also in terms of predicting downtime and things like that. Next. What about touch screen terminals with no keyboard? What sort of exploits there might be to circumvent that? Some touch screen terminals still have environments or things that you can do within the environment. Depends on what type of buttons they have in place. I know one person I was talking to said that they were able to get down to the shell because they knew that with a touch screen environment, like if you touch the two corners in the bottom and then you touch the two corners in the top, it would kill the application and get you to the desktop. They are much, they can be safer. It depends also on the software you're deploying. For instance, I believe Necki, they provide touch screen environments, but they still use JavaScript and VB script and they still process the original homepage. So it depends on the vendor in terms of how you're doing the touch screen environment, but that would be the next step up from just providing a keyboard with limited keys. But the only sort of exploit type of things would be that touching the screens and getting out of the application type of stuff. There isn't some other way around that. Well, once you get to the desktop, sometimes the touch screens will also allow you to move the mouse. Yeah, you had that, sure. So from there, it depends on where you could get to in terms of clicking within the environment, but it is much more limited in those scenarios. Thanks. Next question. I had a question, do they make, I saw earlier you showed a list of like kiosk applications. Did they make like an application that can go in and say like intercept the keyboard and the mouse functions and pipe it through it before allowing it through? Essentially, putting the operating system sort of asleep in the background and then everything, you know, as far as input and output goes, is filtered entirely through the application that's been written dedicated to the TLS application? Yes, that is actually one of the solutions that they do in terms of our customized browsers, is that they will write a wrapper application so that you're not directly interfacing with the software. So you would launch that application as the shell environment, and then all the keystrokes and all the events would go to that application, that application can choose whether or not to honor those. Okay, then. So there are applications that do that. I believe Necky does that to a certain extent, although they're a little bit more browser-based, and I believe KISS and KeoWare do that, but my memory's a little bit vague in terms of the differences between some of these. I was gonna say to the guy that previously asked the question he was talking about the touchscreen thing, I was gonna say, I do remember a hack at a college where you could actually take a key and rub it in the corner of the screen and actually cause a taskbar to kick up. Yeah, there are different shortcuts for different vendors. It's a security through obscurity thing. For instance, the person I was talking to who knew the combination in terms of the two keys, the corners and the tops, that was because they also deployed the same kiosk so they knew how to get out of it. Most of the kiosk vendors don't necessarily publicly give a lot of information in terms of how their kiosks work because I tried to go in and try and see what some of them do. So there is a little bit of security through obscurity, but still that's probably just a phone call waits for the tech support if you need to ask a question. Just say you lost the manual and ask them what you need to need. Okay, thanks. Any other questions? Okay, thank you everyone for coming. If you have any questions, there's my email address and I'll be happy to talk to you about this afterwards.