Perimeter
11/15/2011
01:44 PM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Plugging The Kiosk-Sized Security Hole

Companies like to set up Internet kiosks for customers and job applicants, but their convenience can be their undoing

I spend a lot of time doing network and Web application penetration tests, security architecture reviews, and mobile security research, but there's one target I love to get my hands on whenever I get a chance: kiosks. Maybe that's because they're often assumed to be "secure" by the layperson since they run the XYZ software product that appears to lock down the system. But in reality, kiosks are sitting ducks, often placed on the same production network as other company workstations.

In fact, I've never encountered a kiosk whose security controls couldn't be bypassed in less than 10 minutes, though often in only about two minutes. What piqued my interest in kiosks this week is an article titled "How to Get Application Kiosks in Your Office Without Spending a Fortune." That sounds like a recipe for disaster if you were to ask me, and if you read the article, then you'll probably agree because there isn't a single mention of security.

But that's not a surprise since kiosks are all about convenience. The problem with that convenience is that it's a double-edged sword that works for both the target audience (e.g., job applicants, hotel patrons) and an attacker looking for a foothold in a target network.

The majority of the kiosks I've attacked have used specialized kiosk software that limits the interface users can see and what applications they are allowed to run. Each one has had similar holes within the print menu, open file dialog, properties windows, and Web browsing modules that allowed bypass and access to the underlying operating system and internal network. Had I not found the usual suspects, I would have resorted to Paul Craig's excellent iKAT kiosk-hacking tool.

I could probably go on and on about the fun things I've found on kiosks (e.g., vacation photos, bank information) or the incredibly open networks they were plugged into waiting to be pillaged, but I want to talk more about securing kiosks because that's what was missing in the aforementioned article. If you were to ask me the best way to secure kiosks in your network, then my response would be to ask if you really and truly needed kiosks.

If there were no way I could convince you that kiosks are about as necessary as cybercafes, then the No. 1 rule is they absolutely do not plug into your network. In most cases, businesses implement kiosks for job applicants and customers to access a Web-based portal for applying for a new job, signing up for a new account, or just general Web browsing (another no-no).

Kiosks should be on their own dedicated network with a separate Internet connection from your business network. Get them a cheap DSL connection, a USB cellular modem, or free WiFi from a neighboring business; just don't put them on your business network.

There might be some situations where the kiosk has to be on your network in order to access a particular network resource, like an internal Web application. This goes against my above rule, but if it's a requirement, then put the kiosk on its own VLAN, firewall everything but the one port needed to access the resource, and disable Internet access.

In addition to the network placement advice, there are several other configurations or activities that should go along with keeping the kiosk from becoming a liability to your network:

  1. Run antivirus, and keep it updated.
  2. Patch the OS and local applications regularly.
  3. Consider an application whitelisting product or Microsoft's AppLocker or Software Restriction Policies, and group policies to limit what can be run. (I'm not a fan of specialized kiosk software because I've yet to be stopped by one.)
  4. Restrict what IP addresses and/or URLs can be visited.
  5. Use a host intrusion detection system to monitor the local system for attacks.
  6. Disable the ability to boot from CD/DVD/USB devices.
  7. Set a BIOS password
  8. Disable any unused USB ports and epoxy the existing USB devices to the ports.
  9. Check for hardware key loggers on a regular basis.
  10. Put the kiosk in a public or easily monitored location to make detection of suspicious activity easier.
I'm sure there are other good ideas, so please share them. In the end, I would highly caution a company from deploying kiosks, but if it absolutely has to have them, then it needs to deploy them in a tightly controlled manner using the recommendations above, as opposed to the typical haphazard approach I come across.

John Sawyer is a Senior Security Analyst with InGuardians. The views and opinions expressed in this blog are his own and do not represent the views and opinions of his employer. He can be reached at johnhsawyer@gmail.com and found on Twitter @johnhsawyer.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
dfeenberg021
50%
50%
dfeenberg021,
User Rank: Apprentice
11/11/2012 | 11:26:28 PM
re: Plugging The Kiosk-Sized Security Hole
11. Connect the kiosk to the DMZ, not the internal network.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0914
Published: 2014-07-30
Cross-site scripting (XSS) vulnerability in IBM Maximo Asset Management 6.2 through 6.2.8 and 6.x and 7.x through 7.5.0.6, Maximo Asset Management 7.5 through 7.5.0.3 and 7.5.1 through 7.5.1.2 for SmartCloud Control Desk, and Maximo Asset Management 6.2 through 6.2.8 for Tivoli IT Asset Management f...

CVE-2014-0915
Published: 2014-07-30
Multiple cross-site scripting (XSS) vulnerabilities in IBM Maximo Asset Management 6.2 through 6.2.8, 6.x and 7.1 through 7.1.1.2, and 7.5 through 7.5.0.6; Maximo Asset Management 7.5 through 7.5.0.3 and 7.5.1 through 7.5.1.2 for SmartCloud Control Desk; and Maximo Asset Management 6.2 through 6.2.8...

CVE-2014-0947
Published: 2014-07-30
Unspecified vulnerability in the server in IBM Rational Software Architect Design Manager 4.0.6 allows remote authenticated users to execute arbitrary code via a crafted update site.

CVE-2014-0948
Published: 2014-07-30
Unspecified vulnerability in IBM Rational Software Architect Design Manager and Rational Rhapsody Design Manager 3.x and 4.x before 4.0.7 allows remote authenticated users to execute arbitrary code via a crafted ZIP archive.

CVE-2014-2356
Published: 2014-07-30
Innominate mGuard before 7.6.4 and 8.x before 8.0.3 does not require authentication for snapshot downloads, which allows remote attackers to obtain sensitive information via a crafted HTTPS request.

Best of the Web
Dark Reading Radio