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

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
DFsuerChe
50%
50%
DFsuerChe,
User Rank: Apprentice
8/8/2014 | 11:02:34 AM
Additional Measures.
A larger list exists on the following website.

 

http://www.kioware.com/docs.aspx?u=bestpractices.html&p=1&v=6.8.0&t=4

 

I particularily like the disable all USB ports and epoxy devices into useb ports part.

 

I was also happy to see that a Kiosk software company actually showed this information on their website and wanted to make sure people are taking security precautions.
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
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-1032
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in the Euroling SiteSeeker module 3.x before 3.4.5 for EPiServer allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party inf...

CVE-2012-1417
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in Local Phone book and Blacklist form in Yealink VOIP Phones allow remote authenticated users to inject arbitrary web script or HTML via the user field to cgi-bin/ConfigManApp.com.

CVE-2012-1506
Published: 2014-09-17
SQL injection vulnerability in the updateStatus function in lib/models/benefits/Hsp.php in OrangeHRM before 2.7 allows remote authenticated users to execute arbitrary SQL commands via the hspSummaryId parameter to plugins/ajaxCalls/haltResumeHsp.php. NOTE: some of these details are obtained from th...

CVE-2012-1507
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in OrangeHRM before 2.7 allow remote attackers to inject arbitrary web script or HTML via the (1) newHspStatus parameter to plugins/ajaxCalls/haltResumeHsp.php, (2) sortOrder1 parameter to templates/hrfunct/emppop.php, or (3) uri parameter to index...

CVE-2012-2583
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in Mini Mail Dashboard Widget plugin 1.42 for WordPress allows remote attackers to inject arbitrary web script or HTML via the body of an email.

Best of the Web
Dark Reading Radio