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!

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.

Wordlist for Common Pet Names

If you are testing web applications for security, be sure to examine the Forgot Password functionality and attempt to subvert it.  It's another way that users can authenticate to the app and is often less secure than the primary method.  First you'll need to enumerate usernames (try the username wordlists I made available a while ago).  Once you have some valid usernames, the Forgot Password functionality will often present you with a challenge to answer one of the user's personal security questions.

One of the most common security questions you see is "What was the name of your first pet?".  If the application doesn't limit the number of attempts, you have a very good chance at answering this question by iterating through different names with a tool like Burp Intruder.  The last time I did this successfully, "Rocky" was the name of the user's pet.

You need big list of common pet names to do this.  That's exactly what I'm providing here for your download pleasure.  My wordlist currently has over 1,400 pet names.

  Click here to get the pet name wordlist

Enjoy!  Obviously my list can't cover every conceivable pet name, but please let me know if you think I'm missing a common one.

Where To Practice Your Web Hacking Skills

I was invited to contribute to the blog of application security company Checkmarx.  Last week my first post was published and covers some ways you can safely practice your web hacking skills.

Wordlists for Common Usernames

I made some wordlists a while ago containing common usernames.  They have proven very useful to me when doing application penetration testing, specifically they are great to use as the payload for Burp Intruder.

I created the lists by taking the 10,000 most common last names in the United States and prepending a single letter (for example "dferguson" appears in the usernames-d.txt wordlist).  There are wordlists for all letters except "i", "q", "x", and "z" (frankly, there aren't many first names that begin with those letters so it's a waste of time to try them).

 Click here to get the username wordlists (zip)

One scenario where you might leverage these wordlists is a web application where the login page returns a different error message depending if a valid username is received versus and invalid username.  Run Intruder on the login request and you can probably reap a nice set of valid accounts.

You'll also find a special wordlist called usernames-top100-each-letter.txt.  This is perfect when you have limited time and want to maximize your potential to find a valid account.  And there's another list called usernames-generic.txt, which could help you discover some test accounts.  Of course you can combine these wordlists any way you want (even concatenate them together and try the whole darn thing).

Things get a little more complex if the web app requires an email address for login.  You could certainly append "@gmail.com", "@yahoo.com", "@aol.com", etc. to the usernames.  Separate wordlists could be created for each email domain, or you could just leverage the power of Burp Intruder to append the domain on the fly.

Risky to Report Website Vulns

The main reason I stopped reporting vulnerabilities to website owners is the risk of being prosecuted.  The Internet is more dangerous when well-meaning security researchers are treated this way.  I was new to Application Security in 2006, so I didn't realize that I was actually taking a pretty big risk when I told Netflix about their CSRF vulnerabilities.  In my mind I was doing them a favor.  They got a free mini pen test.  In fact as a Netflix subscriber, I was giving them money!  It turns out they were nice and simply said "thank you", then went about fixing the issue.

Today I ran across Patrick Webster's story from Australia and he wasn't so lucky.  He noticed that his bank's web application allowed for any customer to view another customer's account information, including very sensitive data that could allow for identity theft.  This type of insecure direct object reference vulnerability is very simple to exploit.  Mr. Webster just changed a numerical parameter in the URL to discover the problem.  He reported it to his bank, who decided to report him to the police.  It's not like this guy was a determined attacker with premeditation who spent weeks doing reconnaissance on the site.  That said, he clearly went too far by running a script that "cycled through each ID number and pulled down the relevant report to his computer".  That wasn't necessary to report the vulnerability.

Another example is Andrew Auernheimer who is potentially facing 5 years in prison due to his AT&T "account slurper" script.  Again, he went too far with the script, but clearly he might've been prosecuted anyway.  One of the comments on this story was humorous:

You seem to be implying that every exploit can be anticipated. The article points out that AT&T changed their code after discovery of the hack. There is no indication that they knew it was a problem before hand.

Web app vulns can and should be anticipated.

Don't Need No Stinkin' Coupon Print Activator

This is a real-life example of exploiting a web application security flaw. I received an email from Discover Card offering some Lowe's coupons.
I was needing to buy some stuff there anyway, so I decided to grab them.
I was soon shocked and amazed. Turns out they expect you to download an executable (something called a"Coupon Print Activator") and run it just to print the coupons.
I am not in the habit of running strange .exe's.
But, I really wanted those coupons (and perhaps sensed my hacking skillz were being challenged). I looked at the requests being made to the server, and noticed that dsppreprint.cfm had some JavaScript pointing to interesting URLs, one to "print.cfm" and one to "print_noplugin_redirect.cfm". The query strings were radically different between the two, so I decided to append the query string from print.cfm onto the other .cfm file.
This hybrid URL ended up in a round-about way returning some HTML with an "embed" tag with a bunch of attributes. One of the attributes was very interesting to me.
A request to this URL returned some raw data that appeared to be meant for consumption by the Coupon Print Activator. It also led me to discover yet another URL.
A request to this URL returned the following jpeg image (numbers masked to protect something or other):
So I got a bar code. Wonder if I could print this bar code and use it at the self-checkout at Lowe's? This would not be unethical as I was entitled to the coupon anyway. I just didn't want ro run that Activator thingy! As a simple test, I jumped over to Lowes.com and added a ceiling fan to my shopping cart. There was an input field for "Promotional Code".
Proceeding to enter the number that appeared below my bar code, I was pleased to see my $10.00 discount applied.
To sum up, coupon obtained, Activator thingy bypassed. Sorry I do not have time get into how this site could have been written more securely. Suffice it to say that exposing data, URLs, and client side logic is not good.

Keeping Your RapidRez Number Safe... Not!

I went through a web application for enrolling in Budget's Fastbreak service not too long ago. Upon completing the process, they gave me a special number, called my "RapidRez" number. The final page displayed my RapidRez number and gave a warm and fuzzy message stating that "for security reasons" they won't send me an email confirmation with my number. The page looks like this:

Let's ignore the fact that the HTML is screwed up, which causes the "NTRA end" comment to be visible in Firefox. Inspection of the HTML source revealed something much more interesting and somewhat disturbing.

As you can see, my RapidRez number, which is so sensitive that Budget does not want to send it to me via email, was sent to a server called adfarm.mediaplex.com. I have no idea what if anything Mediaplex does with all the RapidRez numbers they are collecting. My personal opinion is that Budget should not tout the sensitive nature of these numbers and then proceed to send them to a third party. At least don't make it so obvious! If sensitive data needs to be sent to business partners, I would suggest doing it a different way, such as a nightly batch process over a secure channel.