AppSec Notes

Tuesday, January 7, 2014

Alternatives to the Boring XSS Alert Box

Demonstrating that a web application is vulnerable to reflected cross-site scripting (XSS) is not very exciting. It's always kind of like, "oh hey, look here, an alert box popped up when you clicked on that link". Scary. Dramatic. Not! I was looking for more interesting ways to show how XSS could be used. I figure the code is more likely to get fixed if you can make a memorable impression. I came up with a few options.

I'll present these techniques using 3 websites that are Internet facing and purposefully built to be susceptible to reflected XSS.

demo.testfire.net (operated by IBM)
www.webscantest.com (NT Objectives)
testasp.vulnweb.com (Acunetix)

All of the URLs here were tested successfully with Firefox 26, IE 11 with the XSS Filter disabled, and Chrome 31 with the "--disable-xss-auditor" command line option. Note - if you have the NoScript extension, you'll have to either disable it temporarily -or- allow scripts on the above domains plus sc0rn.com and disable the XSS protection.

First, there is the boring alert box that I'm trying to get away from:

Alternative #1 is to fill the victim's screen with unicorns and rainbows.

Alternative #2 is to Rickroll the victim (i.e., redirect to Rick Astley's famous 80's music video).

Alternative #3 is to display some HTML... a funny news story in this case. (in Firefox w/NoScript you may have to click refresh for this to work)

Feel free to use these or create your own. I think you'll agree these are definitely better than popping an alert box.

Lastly, I have a hilarious, but mildly racy (NSFW?) alternative. (in Firefox w/NoScript you may have to click refresh for this to work)

Sunday, December 22, 2013

How I Keep Track of My Passwords

We all know that you shouldn't re-use the same password on different websites, but this is extremely difficult in practice considering the number of sites people use today. Password managers were developed to help solve the problem of remembering passwords. Some examples are KeePass, Password Safe, and LastPass. They work fine for many people. However, I personally don't like the idea of depending on a password manager. I want the ability to pull the correct password out of my brain in case I'm ever in a situation where I don't have access to the password manager. There's also a risk that your passwords could be compromised (this is true about any data that is stored, encrypted or not).

I have over 100 different passwords, but I don't have any problem remembering them. I don't write them down or use any sort of password manager. I came up with a system that enables me to remember my passwords. It works for me, so I'm sharing the technique in case anyone else thinks it might be helpful.

With my system, you only have to remember two things.

A core password.
Your scheme.

First, come up with a strong core password of about 8 or 9 characters. This core piece should be random gibberish and needs to have a lowercase letter, an uppercase letter, a number, and a special character. An example is kM92ax4!. Whatever you decide upon, memorize it.

Second, pick a scheme based on the website's domain name. The scheme is used to supplement your core password. As a simple example, your scheme could use the last 3 characters of the site's domain, add one letter to each (this is actually an encryption technique called "ROT1"), and append this to your core password.

So for the site "www.verizonwireless.com", we see the last 3 characters of the domain are "ess". Therefore the 3 additional characters would be "ftt" and your final password is kM92ax4!ftt.

For sprint.com, your final password is kM92ax4!jou.

For att.com, your final password is kM92ax4!buu.

Come up with a any scheme you want as long as it's based on the website domain. Here are some other possibilities:

Prepend the first character to your core password/append the last two
Capitalize one or two of the letters
Subtract two letters ("ROT24" encryption) instead of adding one
Look at the first two chars + last char of the domain, instead of the last three

You get the idea. The scheme remains constant, but your password changes. Whatever you decide, never tell anyone your core password or your scheme.

My system isn't perfect. It doesn't work on sites that have a short maximum password length (like 10) or onerous password requirements (like requiring you to change it every 90 days). But overall it has worked great for me.

Sunday, December 8, 2013

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.

Friday, October 4, 2013

Think of Base64 Data as Plain Text

I think there is still confusion in the minds of many developers about Base64 encoding. It's not encryption. It doesn't offer any protection of the data at all. It's trivial to decode with Burp Suite, a desktop utility, or a website such as this.

When testing a web application for security, be sure to decode any Base64-encoded strings you see (often they will have one or two "=" at the end). You may find the resulting data is gibberish, which probably means it's encrypted or hashed. Or you may find sensitive user data developers were hoping to hide. You also might find technical information about the deployment infrastructure or a clue that leads you to another area of the application that has a security hole.

What is Base64 encoding? Just a way to encode ANY data so it can be represented as plain ASCII text. This is convenient in many situations. Email attachments are sent as Base64 data for example. For every 3 bytes of data, encoding will get you 4 ASCII characters. It works by first concatenating ("smooshing") the data together in binary form, then chunking it up into 6 bit sequences. Padding with zeros is done if needed so the data is a multiple of 3 bytes. Each 6 bit sequence is converted to an ASCII character according to a standard Base64 encoding table.

Here is an example of Base64 encoding in action.

1) Start with some data. It could be Hex, Binary, ASCII, and so on. Let's use the word "Hi".

2) Convert each byte to binary. We need to add one zero for padding in this case.
H : ascii code 72 / binary 01001000
i : ascii code 105 / binary 01101001
0 : binary 00000000

3) Smoosh the binary data together:
010010000110100100000000

4) Chunk it up into 6 bit sequences:
010010 000110 100100 000000
The decimal equivalent is:
18 6 36 0

5) Convert to Base64 using the table below. Any artificial trailing zero is represented by a "=".

The Base64 string is: SGk=

Saturday, March 30, 2013

Bizarre CAPTCHAs

We all understand the security benefits of using a CAPTCHA as it relates to anti-automation in a web application. The most common implementation of CAPTCHA functionality is reCaptcha, a technology that Google purchased in 2009. Most of the time it works great, but recently I ran across a site that was producing some bizarre images. I saved a few of these, and I'm pleased to present them here now for your enjoyment!

Hmm, I don't have some of these letters on my keyboard:

Users are expected know calculus now?

If a word is upside down, would you enter it left to right or right to left?

Absolutely no clue:

Wednesday, November 28, 2012

The Audacity of Your Flashlight App

I've been taking a closer look at my mobile apps lately, specifically the permissions they request when downloading and installing them. It has been quite an eye opener. It turns out that mobile apps are invading our privacy. It's as simple as this: any app that can read your contacts and access the Internet can slurp your data and send it off to some random server to be stored and/or used in a nefarious way.

The finding that surprised me the most was the audacity of my little old flashlight app. I was using "Tiny Flashlight + LED", which is allowed to read your phone identity and have full Internet access. A flashlight app that needs Internet access is nonsensical to me. I switched to use OI Flashlight, which requires only the permissions of camera control and preventing the device from sleeping. I discovered during my research that most flashlight apps want Internet access. The top 4 flashlight apps that appear when searching for "flashlight" on Google Play are:

All four require Internet connectivity! However, the winner of the most inappropriate and egregious permissions contest is "Brightest Flashlight Free" by Goldenshores Technologies, LLC. This popular app (over 10 million downloads) requires the following permissions:

full Internet access
your location (both coarse and fine)
modify your SD card contents
read your phone identity

Can you think of a reason a flashlight app needs to know your current location or modify the data on your SD card? I can't either.

Tuesday, November 20, 2012

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.

Wednesday, October 10, 2012

"Sorry, that password is already in use"

Here is a good example of the kind of insecure practices application developers are doing out there.

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-October/008535.html

Thank you Jim Burton for being concerned and speaking out. I have to admit laughing out loud when first reading this. That may have been wrong of me.