• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Satisfice, Inc.

Software Testing for Serious People

Rapid Software Testing A Context-Driven Methodology
  • Home
  • About
    • Privacy Policy
  • Methodology
    • Exploratory Testing
    • Reasons to Repeat Tests
  • Consulting
  • Classes
    • James Bach’s Testing Challenge
    • Testimonials
    • RST Courses Offered
    • Testers and Automation: Avoiding the Traps
    • Rapid Software Testing Explored
    • Rapid Software Testing Applied
    • Rapid Software Testing Managed
    • Rapid Software Testing Coached
    • Rapid Software Testing Focused: Risk
    • Rapid Software Testing Focused: Strategy
  • Schedule
  • Blog
  • Contact
  • Resources
    • Downloads
    • Bibliography: Exploratory Process
    • Bibliography: Risk Analysis
    • Bibliography: Coaching
    • Bibliography: Usability
    • Bibliography: My Stuff From IEEE Computer and IEEE Software Magazines
    • Bibliography: The Sociology of Harry Collins

Amateur Penetration Testing

Published: November 7, 2004 by James Bach 1 Comment

It’s traveling season for me. London, Amsterdam, New Zealand, Australia, and so forth. That means I’m killing time in a lot of airports and hotel lobbies. And THAT means I’m testing software on kiosks and Internet access stations across this great planet of ours.

At first I was just trying to find interesting bugs, but more recently I’ve become interested in penetration testing. I’m an amateur at it, but I seem to be getting better with practice. Wherever possible, I send the details of any exploits to the companies that run those systems. Even though my behavior is probably illegal (when I actually do a take over), I like being on the sunny side of morality.

I want to share some of the details with you because I think companies should to take security a lot more seriously. Maybe they will if more people know how to circumvent bad security.

Recently, I was able to break into and take over a Internet access station at a hotel in London. Later, I failed to take control of one at Heathrow, but I did find some unsightly bugs in it. A different station at the Red Carpet Club (based on Windows 95, would you believe) fell pretty quickly.

These are the major techniques I use:

1. Look for and access generic, hidden Windows features.

A lot of these systems are based on Windows and use Internet Explorer. Attacking them is not very difficult, in most cases, because the Windows O/S is brimming with rich, creamy functionality. This functionality is difficult to disable, and much of it is hidden.

In my PDA, I keep a list of every keystroke shortcut in Windows (conveniently available from Microsoft). I try each one. Did you know that Shift-Alt-PrtSc activates high contrast mode in XP? Not only that, it gives you access to a bunch of accessibility settings.

In one kiosk I was able to invoke the XP “Help Center”. (Probably something to do with a very short vulnerability window or some other special state, because I couldn’t make it open, later on.) Once open, I tried to install a printer. This allowed me to browse for printer drivers, but through that interface I can see any file on the system. What’s more, I can delete any of those files. By strategically deleting files, a hacker could take over the system on reboot. (No, I didn’t do that.)

While I was playing with this, a notice came up informing me that Windows was ready to install Service Pack 2. By following that process half-way, I was able to invoke an IE session that let me browse and access the files on the hard drive. I discovered information that would have allowed me to attack the servers of the company that manufactured that kiosk. Yikes.

So, don’t turn on automatic updates, you public kiosk developers!

In addition to accessing hidden functions through hotkeys, I also go through each menu of each program I can access, especially Internet Explorer, looking for any function that starts a new application or gives me a file open/save dialog.

For example, in another kiosk, I was able to invoke the Microsoft newsreader application through Explorer. On the help menu there’s an option to view the readme. When invoked, Notepad comes up. Ah ha! With Notepad I created a batch file that opened a command prompt. I put that file in the startup folder. Then I rebooted and took control of the machine.

2. Look for special content on web pages.

A lot of kiosks give you controlled access to web pages. The access is easy to control if the web pages are simple HTML, but when third party plug-ins or special dynamic content is involved, there be dragons…

In yet another kiosk, which was better secured than the other two, I was allowed free access to the website for Heathrow Airport. No problem so far. Looking around that website, I found some PDF files. Acrobat Reader started up within IE, and gave me a new toolbar. One of the functions was Save a Copy, which allowed me to browse the files on the hard drive. I didn’t try it, but I bet I could have saved the PDF with the same file name as one of the files related to the application that drove the kiosk. This might be called a lobotomy attack. I don’t know what the pros call it.

3. Find the hidden technical support login interface, guess passwords, and otherwise beat on it.

Public kiosks almost always have a hidden interface that lets a technician log in and perform maintenance. That interface is often pretty easy to find and poorly tested.

In one case, the tech login was accessed by touching a particular word on a particular page. On another it was clicking three times on one button then three times on the button next to it (It took me all of five minutes to stumble onto it. So much more security through obscurity.) Another kiosk hardly bothered to hide it– you just click in the bottom left corner.

Tapping chaotically on the touchscreen of the United EasyCheckIn system caused a supervisor password prompt to come up. I have not yet been able to repro that, but now that I know it exists, I will keep trying until I learn how to do it on demand.

4. Create error conditions and see if that disables security or reveals functions.

The Del Discover Club kiosk at the Del Coronado hotel has a vulnerability that occurs within a 1/5 second window after causing a certain error message to occur.

5. Make a lot of things happen at once and see if they trip over each other.

Concurrency is so hard for programmers to get right. They make assumptions about states, and those assumptions are often faulty.

6. Make the system reboot, try to interrupt the process, and gather clues about system configuration.

I was unable to reboot the book search system at Barnes and Noble, but I was able to make a modal error dialog appear. By moving it off the screen, the terminal appears to be frozen (unless the user presses enter first). I didn’t try this, but it occurs to me that the store personnel would probably reboot the system for me if I reported that a terminal was frozen. If they walked away after that, I might be able to launch my attack.

Some of these kiosks have an unprotected power cord, believe it or not; and in the UK all outlets have switches on them, so I don’t have to pull the plug to cut the power.

Filed Under: Buggy Products, Exploratory Testing, Heuristics, Skills, Test Strategy

Reader Interactions

Comments

  1. Jack says

    29 July 2015 at 10:02 pm

    That’s pretty neat trick and nice way to learn and gives me ideas to try, who knows that ATM machines might have the same kind of vulnerabilities

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search

Categories

  • About Me (17)
  • Agile Methodology (14)
  • AI and Testing (4)
  • Automation (20)
  • Bug Investigation and Reporting (9)
  • Buggy Products (24)
  • Certification (10)
  • Context-Driven Testing (44)
  • Critique (46)
  • Ethics (22)
  • Exploratory Testing (34)
  • FAQ (5)
  • For Newbies (25)
  • Heuristics (28)
  • Important! (20)
  • Language (35)
  • Management (20)
  • Metrics (3)
  • Process Dynamics (27)
  • Quality (8)
  • Rapid Software Testing Methodology (23)
  • Risk Analysis (13)
  • RST (5)
  • Scientific Method (3)
  • Skills (30)
  • Test Coverage (8)
  • Test Documentation (8)
  • Test Oracles (5)
  • Test Reporting (11)
  • Test Strategy (26)
  • Testability (4)
  • Testing Culture (96)
  • Testing vs. Checking (18)
  • Uncategorized (12)
  • Working with Non-Testers (7)

Blog Archives

Footer

  • About James Bach
  • Satisfice Blog
  • Bibliography: Bach on IEEE
  • Contact James
  • Consulting
  • Privacy Policy
  • RST Courses
  • RST Explored
  • RST Applied
  • RST Managed
  • RST Coached
  • RST Focused: Risk
  • RST Focused: Strategy
  • RST Methodology
  • Exploratory Testing
  • Testing Training
  • Resources
  • Bibliography: Exploratory
  • Bibliography: Risk Analysis
  • Bibliography: Coaching
  • Bibliography: Usability
  • Bibliography: The Sociology of Harry Collins
  • Schedule
  • Upcoming Public Classes
  • Upcoming Online Classes
  • Public Events
  • Tester MeetUps

Copyright © 2025 · News Pro on Genesis Framework · WordPress · Log in