Airport Kiosk Admin Access

Don't underestimate the threat of shoulder surfing, especially when you're an airline employee accessing the administrative panel on kiosks at the airport.

This thought ran through my mind recently when I witnessed an employee - in a very busy ticketing area - casually double-tapping a certain spot on a kiosk's touchscreen.  A keyboard opened asking for input of a password.  Curiosity led to me continue watching as he proceeded to enter the password and access the local administrative menu.  I quickly jotted a note of what I saw for possible future testing.

One night a few weeks later, I was at the airport and found nobody in the ticketing area.  A good time for my test...

***** ACCESS GRANTED *****

Years ago I developed kiosk applications for colleges & universities as well as for Sprint retail stores. It's common practice to code in a "hot spot" somewhere on the screen to bring up a keyboard allowing for input of a password to access the admin menu (more examples here and here).  It might require a double-tap or triple-tap in a single spot, or a combination of taps in different spots.  The admin password itself is often something simple, such as the name of the business, the street number of the building, or the store number (if a retail store).

Moral of the story for kiosk admins: Be aware of shoulder surfing!

CWE: Disrespectful to Session ID in URL

Mitre's Common Weakness Enumeration (CWE) is the most comprehensive and granular taxonomy for web application security vulnerabilities and weaknesses.  So why, may I ask, is there no CWE ID for Session ID Exposed in URL?

Am I missing something?

Sure, we have CWE-384 (Session Fixation), but that's not the issue.  Session fixation in my experience is much more rare (and dangerous) compared to a session ID exposed in a URL.

Some might suggest CWE-287 (Improper Authentication) is the best fit.  That's a tough sell.  I don't buy it.

The closest one in my opinion must be CWE-598 (Information Exposure Through Query Strings in GET Request).  It's not a perfect fit, but the consequences section does refer to "impersonating a legitimate user".  That's a true risk for sure.

At this stage of the game, we probably won't see a CWE ID specific to Session ID Exposed in URL.  It seems like a no-brainer, but oh well. 

What the Tech behind this Website? Wappalyzer Knows

Trying to figure out what technologies/frameworks a web app is built upon is an important part of application security, especially pen testing.  It's something that should be done in the reconnaissance phase of an assessment.  Knowing what an application is using under the covers is a definite advantage in your quest to pwn it.

Trouble is, it's not so easy anymore.  There is a vast array of technologies that make up today's web application development landscape.  Not only are there are different types of web servers, application servers, and  programming languages, you also have to consider different development platforms (Java vs. .NET vs. something else), client-side JavaScript frameworks (Angular vs. React vs. something else), authentication protocols (OAuth vs. Kerberos vs. one-off vs. API token vs. something else), CMSs, CDNs, advertising networks, analytics engines, and so on.  Is your head spinning yet?

For quick feedback on what technologies a web application is using, I recommend the Wappalyzer browser extension.  It is available for both Chrome and Firefox.  Once installed, you will see the following icon in your browser's toolbar: 

Click this icon and you'll see a categorized listing of different types of technologies used by the website currently loaded in your browser.  Here is an example:

I have personally found this extension to be very useful... for pen testing or even when you see an interesting-looking site.  Find out what it's built on!  This extension thankfully works with Firefox 55 and later, which is something that can't be said of many popular Firefox extensions nowadays (this is thanks to Mozilla's shift to use the cross-browser WebExtensions API.

One last important note about Wappalyzer - you probably want to uncheck the option (shown below) where you send them "anonymous" reports for research.

Quick (but telling) IE vs. Chrome Comparison

The following "perfect timing" slideshow on MSN is entertaining, so my first thought was that IE would be the best browser with which to view it.  It's *MS*N after all.  Firefox is my main browser, but I like to fire up alternatives from time to time to understand the experience (well, except for Edge which still sucks).

http://www.msn.com/en-us/lifestyle/smart-living/photos-taken-at-the-perfect-time/ss-BBEzdUL?li=BBnbcA0&ocid=UE01DHP&fullscreen=true#image=1

Boy was I wrong about IE here.  It was slow, flaky, and then starting giving me "long-running script" errors and offering to stop the script for me. Even after saying yes to stop the script, the whole browser eventually locked up on me. FAIL.

Contrast that to Chrome, which was fast and worked flawlessly displaying the slideshow

I didn't try Firefox, because I have NoScript installed and just didn't want to deal with getting the slideshow to work.

Let's say "TLS" instead of "SSL"

A trend I noticed within information security circles is to use the term "SSL" even when we mean "TLS".  TLS is the newer and more secure replacement for SSL.  All versions of SSL, even the latest SSLv3 flavor, are considered to be insecure at this point. 

It's habit to say "SSL".  Our infosec minds auto-translate it to "TLS", but there are interesting, concrete reasons that the IETF chose the name TLS back in 1999.  In addition, words have meaning and many people who don't eat, drink, and sleep security aren't up to speed on the nuances of this stuff.  This includes millions of IT personnel who are responsible for configuring servers in a secure manner.  It also includes newbies who are entering the infosec field every day.

Information security professionals can be arrogant.  If someone isn't as knowledgeable as them, then that person is called stupid. For example, application security experts tend to denigrate developers for writing insecure code.  That bothers me a lot.

Here's another example:

So people who don't know about SSL vs. TLS are not clever.  Nice.

Years ago I didn't know much about security.  I was a developer and appreciated the opportunity to learn from others.  So let us be technically accurate and use "TLS", even if it turns out to be a losing battle in the end.

Webinar - Intro to Security Testing

I haven't done much blogging for a while.  I will be doing more posts this year.  At least that's one of my new year's resolutions!  Some of my posts will be original content residing here, but others will be links to articles or posts I've done elsewhere.

I'd like to start 2017 by sharing a link to the webinar I did in 2015 that is aimed at anyone who wants to dip their toes into the world of web application penetration testing.  The webinar was for the benefit of the uTest Community, and you therefore need an account to view the webinar.  It's easy and free to sign up though.

I'm proud to say the uTest community has given my webinar a stellar rating of 4.86 stars out of 5!  If you are new to the field of manual appsec testing, I'm sure you'll find it helpful.  Pro tip: install and learn Burp Suite!

The webinar is here: 
https://www.utest.com/courses/recorded-webinar-introduction-security-testing-dave-ferguson

Enjoy.