Saturday, October 7, 2017

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!


Thursday, September 28, 2017

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. 


Wednesday, August 30, 2017

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.


Monday, July 17, 2017

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).

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.


Tuesday, February 7, 2017

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.


Friday, January 27, 2017

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:



Tuesday, June 16, 2015

OWASP #4 Continues to Laugh at Automated Scanners

I was thinking back to 2006 when I was new to the world of Application Security.  Someone on our consulting team arranged a call with a vendor called Secure Software, Inc.  They were a company with a code scanning product called CodeAssure, but they were probably best known for a freeware tool called Rough Auditing Tool for Security ("RATS").  The company was bought by Fortify in 2007 and their products essentially died off. 

On the call I wanted to better understand how this magical CodeAssure product worked.  For example, how could it recognize Insecure Direct Object Reference in a web application?  (Actually, that term wasn't even coined yet.  Back then it was called Broken Access Control. Come to think of it, I like that name better.)  Anyway, I described some of the vulnerabilities I was seeing during my application pen testing where I could edit numerical parameters in the URL or the HTTP request body and gain access to another user's data.

For a moment, there was dead silence on the call.  It was one of those times when nobody on their side knew how to answer and they were all hoping that one of their teammates would step up and offer an intelligent response.  In the end there was no intelligent response, only dancing around the question as sales people often do.  I was a little naive back then to ask the question in the first place.  I should have known their product could do absolutely nothing to identify this type of vulnerability. 

SAST scanning tools can't be relied upon to identify insecure direct object references.  But hey, the same is true for dynamic scanners.  DAST tools aren't human and aren't smart enough to know that if you change acct_id=100011 in a URL to acct_id=100012 and you get back a valid response with another person's data that it's a big freaking problem.  The exploitability rating of this flaw is off the chart.  Almost anyone can perform the attack and it is still happening today.  Even big companies that pay attention to security like Citibank can succumb

The bottom line in my opinion is that you can't use one security testing technique and have confidence that your apps are secure.  Multiple testing approaches are needed for the best assurance.  Obviously, cost is a factor here, but for your most business-critical applications, I would use SAST, DAST, and manual pen testing.  Techniques like IAST and RASP are making strides and have much promise as well.  Both of these are going to require development teams to be more involved (and accountable) for application security however.   


Friday, May 22, 2015

Bug in WebEx Productivity Tools Exposed Audio Conference Credentials

I recently found a security bug in Cisco's WebEx Productivity Tools.  The bug caused your audio conferencing credentials to be sent out in meeting invitations.  It was limited in scope to InterCall customers who integrate with WebEx.

InterCall is an audio conferencing solution and can be used as an alternative to WebEx's built-in audio.  My company is starting to roll out WebEx this way.  InterCall users have a dedicated  conference code and a leader PIN which are your account credentials.  The conference code is meant to be public, but the leader PIN is like a password and should be kept confidential.  Productivity Tools (PT) is an add-on product for WebEx customers.  One of the key features is an integration with Outlook that allows you to create WebEx meetings and send out the invitations from within Outlook.

The Discovery:
First I set up WebEx to use my InterCall account for audio and then downloaded and installed WebEx PT.  Next I created a test WebEx meeting from within Outlook and invited one person.  Upon clicking "Send", PT securely communicated to the WebEx server to auto-populate the conferencing information in the meetng invite.  When the information appeared, I saw my InterCall leader PIN just for a moment before the email was sent.  At first I thought it was a mistake, but inspection of my Sent Items folder showed that my PIN was indeed sent.  The person who received the invite confirmed he got my PIN as well.  Wow!  How could no one at Cisco or my company notice this?  I was unable to find a work-around except for avoiding PT altogether by logging into the WebEx site and creating a meeting from there.

The WebEx meeting host key was also exposed in the email, but that wasn't too worrisome because it changes with each meeting.

The Fix:
I reported this security threat to Cisco (and InterCall) on April 28th.  After pestering them for updates, Cisco Engineering finally confirmed to me on May 14 that it was a defect and that they were working on a fix.  I can now confirm that the bug has been fixed in WebEx Productivity Tools Version 2.36.13013.10003, which was released on May 19, 2015.  I would like to thank both InterCall support and Cisco PSIRT for their attention to this matter.  For reasons that are unclear, Cisco hasn't released a security advisory or security alert about this issue  This blog post will have to suffice.

I'd like to be able to say that technical acumen and advanced hacking were needed to find this vulnerability.  Alas that was not the case!  I was just curious about my new WebEx toy, wanted to understand how it worked, and stumbled upon it. Being curious and questioning things... it's what people in information security tend to do.

Update: On May 28th I received an email from WebEx notifying me about the patch for the vulnerability:


Sunday, December 7, 2014

I Cut My Payment Card in Half and What I Found Surprised Me

Recently I received an American Express card from Citibank to replace my expiring one.  Naturally, I cut the old card in half.  My customary procedure is then to discard one of the pieces in a trash receptacle at my house and the other piece in a different trash receptacle.  I figure this will keep me pretty safe from dumpster-diving fraudsters because the trash receptacles are typically emptied at different times and go into different plastic trash bags.

This time I decided to examine the pieces of my card.  What I found was that having only the right-side piece would allow someone to reconstitute the full 15-digit account number! Given where I cut the card, which was pretty much right down the middle, the front showed the last 7 digits and the back showed the first 8 digits.  See the photos below (numbers masked for the protection of me).

What's more, the 4-digit security code appeared on the front side and my full signature was visible on the back (also masked for my protection).  At least the security code was different on my new card, so once activated, using the old code should cause a payment authorization failure.  Still, many e-commerce sites do not require the security code when making a purchase.

So with just half of my old card, the expiration date is the only unknown to a dumpster diver.  That is not a big obstacle to overcome at all.  Logically, if someone throws away a payment card, the probable reason is that he/she received a new card to replace the expiring one.  What would be the expiration date of the new card?  It's very likely to be either two years or four years from now - either the current month or the subsequent month.

This reminds me of the story of the torn-up credit card application that I read about a few years ago.  A man named Rob Cockerham taped the pieces back together, filled out the application, and sent it in.  Amazingly, a shiny new card arrived in the mail for him a few weeks later.

The bottom line is: Be aware that if you cut up your debit cards or credit cards and throw the pieces away in different receptacles like me, you're not necessarily safe from dumpster diving.

I'm asking for a shredder for Christmas.


Thursday, November 20, 2014

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.


Thursday, October 30, 2014

Disabling SSLv3 in Firefox

With the recent discovery of the POODLE vulnerability in the SSLv3 protocol, I wanted to change my Firefox configuration to disallow SSLv3.  Mozilla released an extension for this called SSL Version Control, but I decided not to install it given its somewhat sketchy reviews.

No problem I thought.  Time to open the advanced configuration in Firefox by entering "about:config" in the address bar and make the change there.  Searching for "security", will show many configuration settings that start with "security.ssl3".  Some of them will be set to true and some to false.  You would think setting all the values to "false" here would be the solution.  Nope!  Don't do it.  Although the settings have "ssl3" in their name, they actually apply to both SSLv3 and all three TLS versions (1.0, 1.1, and 1.2).  If you change them all to false, both SSLv3 and TLS will be disabled and your browser will be incapable of communicating securely at all.

The correct solution, as described here, is easier.  Just set "security.tls.version.min" to 1, which means that TLS v1.0 is the minimum allowed version.  When set to 0, it means that SSLv3 is allowed.  I hope that helps.

This is a temporary work-around anyway as Mozilla says that SSLv3 will be disabled by default starting with Firefox 34.


Thursday, July 31, 2014

Building Secure Applications: How Mature Are You?

I was invited again to contribute to the blog of application security company Checkmarx.  My second post was published a couple of days ago and covers software security and the Building Security In Maturity Model (BSIMM).


  © Blogger templates The Professional Template by 2008

Back to TOP