GWAPT done, Tenets of Web Application Security

It's been a while! I've come to accept that I will probably never have enough time to put into this blog as I would like. I admit my posts will be sporadic, but hopefully the content that I do end up posting is helpful to those of you that read it.

GWAPT Certification!

Recently I achieved getting my GIAC Web Application Penetration Tester (GWAPT) certification. I passed with a 96% and I highly recommend anyone considering going into web application pentesting to take. I took a SANS course with Kevin Johnson and had a great experience.

Ok, so let's get to today's post.

Basic Security Tenets for protecting web applications

I'm going to attempt to consolidate the many attacks we see against web applications and some steps you can take to prevent them in your web applications. Again, these are some basic things coming off the top of my head and is by no means a comprehensive list.

Client Side Code:
With AJAXified (is that actually a word now?!?) websites, more and more logic is being passed down to the client. This presents a problem (or an opportunity if you're someone like me) as anything being passed down to the client can be modified and used.

Seriously avoid putting things like input validation and authentication logic on the client side as it makes the bad guy's job much much easier. Remember that anything on the client can (and will) be turned against you.

Session Handling:

One of the ways attackers go after web applications is attacking the session management system itself. If an attack is able to get a legitimate session, they've essentially unlocked a door and allowing them to continue through your application. Here are some things you can do to help eliminate session vulnerabilities.

1. Don't build your own session management piece, use a framework
   Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
2. Prevent Session Fixation, most notably in Microsoft ASP.net
   Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
   
   Session Fixation occurs when an attacker is able to get a session ID before authenticating that does not change after authenticating. This is pretty easy to check as all you need to do is look at your session ID before authenticating and after. If it changed then congratulations you don't have a problem with session fixation.
   
   Microsoft's ASP.net still has a problem with session fixation; so if you use ASP.net make sure your site is not vulnerable. If you find that you do need to patch this up, OWASP has a page explaining one tactic to do so here

XSS Prevention:

Cross Site Scripting is a very common attack method and nearly every input on a page can be a potential attack vector. Successful XSS attacks can allow attackers to deface websites, hijack sessions by stealing cookies, or even redirect users to malicious websites.

1. Input Validation
   Articles talking about XSS are abundant on the web so I won't go into tons of detail here (if you want more detail please ask, there's enough material there to be its own post). Suffice it to say that whenever you're accepting input, make sure that you're only allowing the kinds of information in that field that it needs. Phone numbers only need numbers and either dashes or sometimes periods. I can't think of a good reason to allow alpha characters and <> inside of a phone number field. Basically just think of what the user would actually need and restrict the characters they can input to only what they require. If at all possible, utilize white listing instead of black listing. Black listing is only effective if you've covered every possible BAD entry, and since attacks are always evolving, this can be a risky gambit.
   
   Another measure to implement on input validation is to use canonicalization which can prevent double and triple encoded attacks. Canonicalization reduces input to their most basic form before being accepted as input.
   
   This might seem like a lot of work (and it really can be), but this is the best way for web applications to prevent XSS attacks.
2. Output Encoding
   Even if we're filtering our input, what if we missed something? Most developers use black lists instead of white lists because it's harder to list all of the valid inputs you can put in vs a list of obvious attacks. Encoding outputs can prevent attacks removing the malicious entries and thus defanging the attack. This is especially important if dangerous characters have to be used as inputs.
3. Forums should use non-HTML tags for formatting
   This obviously only applies to Forums, but changing the formatting tags to non-html entities prevents attacks where these tags can be used for stored XSS attacks. A browser is never going to misinterpret [:bold:] as <b> for example. This gives the developer the freedom to disallow html tags inside their forum posts (or at least escape everything as data) to prevent the attack.

Back to it: Blind SQL Injection Basics

Hello everyone!

First off let me apologize for the lapse in posts...life has been pretty crazy for the past few months and I simply haven't had any time to devote to blogging. Things seem to be getting to a more manageable state now, so let's get on with it!

I figured I'd get back into the blogging groove by going through the basics of blind SQL injection. So for this post I'm going to assume you know how SQL Injection works (If you don't, kaoticcreations has some good material on the subject http://kaoticcreations.blogspot.com/p/basic-sql-injection-101.html).

Now, what's the difference between a standard SQL injection and a blind SQL injection you ask? With a blind attack, you don't actually see the results of your injection, but rather the page will display differently if you got back valid data vs. an error (which can be as subtle as having the page taking longer to load!).

So let's take a look at an example of this. Below you can see that we've successfully deduced that this input field is vulnerable to attack.

Notice that we didn't get anything back from the injection (SQL responses, etc.),but we can definitely see we got the "Registered" response. Now, if we get a "Registered" response when feeding it something true (because 1 does indeed equal 1), what happens if we try something blatantly false such as 1=2? What will happen then?

Well look at that, we got a different response. Using this method we can work to deduce the names of the tables and the attributes therein, but in my future examples I'm going to assume that in this same table we're going to look for someone's PIN and that the attribute is called PIN.

 Well, the PIN could be any number really...so what I've done here is guessed an arbitrary number to give us a starting point. Let's say we want to see if the pin number is less than 10,000.

 Sure enough it is. Ok, so we know the pin is less than 10,000. What if we choose something smaller, say 3,000?

Nope, so we know that the PIN is somewhere between 3,000 and 10,000. If we go up by 100's we end up getting to 3,200. NOTE: if you are searching for a particular number like this, a better method is probably a binary search algorithm (search by halves each time) than doing it arbitrarily like i'm doing in this example.

So we know the number is between 3,100 and 3,200 (because 3,100 showed as Unregistered as well, I just didn't post a picture of it). So let's try half way between these two.

So, the PIN is between 3,150 and 3,200. Following the same procedure we can finally get to the actual PIN

So, now we know that the PIN on this record is "3156".

Now, this was a manual example demonstrating blind SQL injection. There are several tools that can do this automatically such as sqlmap, sqlbrute and others.

As always I hope this has been helpful to understand the basics of how blind SQL injection works. If you have any questions or comments please leave them below.

I know where you live: using public record to find addresses

So the other day I was introduced to  weknowyourhouse.com. A great project taking advantage of those that use the geolocation feature in twitter to broadcast the coordinates of their house. That got me thinking about other ways that this can be done.

Thanks to my wonderful wife, I learned a while back that counties keep records that are often searchable online (property records, marriage records, etc.). Hmm, I wonder if we might be able to use this information to track someone down...Let's find out!

For this exercise I decided to grab a random stranger from one of my Facebook friends. For simpleness, let's call him Bruce. Everybody say hi to Bruce.

It says here that bruce lives in a certain city in Colorado...great! A quick google search says that Bruce lives is in Larimer County. Now let's see if Larimer County has an online accessible database for property records...

Yup, looks like they do! If the county didn't, you'd still be able to get this information, you'd just have to call and possibly pay a fee depending on what you requested.

Ok, so back to Bruce...Searching for property records using Bruce's name let's see what pops up.

Well, there we go. We were able to track down Bruce's address!

Now, this won't work in every instance. If someone rents then the original owner will show up in the property records. Also, sometimes the house will be in the spouse/parent's name (depending on the target obviously).

Just a simple way to take your stalking...err "tracking skills" to the next level. If you want a more "hacker" type approach, try using NAT pinning to find the external MAC address of their router and use geo-location to find them instead (3 part series, very good stuff).

Messin' with bash history

     Alrighty, it's been a while since my last post. I'm a little hesitant to write about anti forensic techniques because I personally feel that they don't aid red team very much and hurt blue team quite a bit. The focus of this post today will be for cases where you legitimately need to manipulate the bash history, or execute commands that you don't necessarily want written to bash.

     The main ways to manipulate the bash history fall into a few categories. 1) Preventing the session's history to be written, 2) Removing entries already written into .bash_history, and 3) Executing commands in a way that won't be written to bash.

1) Preventing the session's history to be written

     Ok, so let's assume you've gone and acidentally typed your password into the command prompt and hit enter...it happens. Well, if we don't want that password to be in history and we don't care about any of the other activities we've done in our session we can kill bash and prevent it from closing out gracefully. You see, it's not until bash has closed gracefully that it writes everything to the .bash_history file. There are many ways to do this, but my personal preference is to just type "kill -9 $$". This command will force the bash process to close itself. You'll lose your session (locally your terminal will close, remotely you'll be disconnected), but when you reconnect your history won't be written. This can also be accomplished by setting the HISTFILE variable to /dev/null.

     In some distributions of linux you can actually run commands without the fear of it being written simply by putting a space in front of the command you want to run. If your distribution doesn't do it by default setting the HISTCONTROL variable to ignorespace will allow you to do this as well.

2) Removing entries already written into .bash_history

     So let's say you didn't know about method #1 and you already closed out the session gracefully...no worries. Since bash writes its history to .bash_history we can go ahead and just edit the .bash_history file and remove what we want. Combining #1 and #2 you can edit what you want out and not have anything in .bash_history showing that you edited it.

     Another fun way to manipulate the bash history would be to grep out (using grep -v) the commands you wanted to have disappear to another file and then you can pipe the contents of that file to overwrite the .bash_history file. You'll leave a file behind with the grep'd contents, but you avoid writing anything in .viminfo.

3) Executing commands in a way that won't be written to bash

     When executing commands on a remote machine, you can actually put your commands in as part of the ssh connection by adding your commands between some quotes. For example, if you wanted to simply echo hello on a remote machine you would type ssh username@machine "echo hello". This command won't be written to the bash history at all.

Of course blowing the bash history away is always an option, but I won't be covering that in this post.

I didn't include pictures in this post. If I get enough requests for them I can add some for clarification.

You just can't trust wireless: covertly hijacking wifi and stealing passwords using sslstrip

NOTE: The following post (and all post on hakinthebox) are for educational purposes only. Do not perform any of these activities unless you have permission to do so.

Today we're going to talk about utilizing sslstrip together to steal passwords. For this i'm going to be using my WiFi Pineapple Mark IV, which is a very handy little box and I highly recommend having one for your wireless pentesting.

First we need to install sslstrip on the pineapple. For this we will use a USB thumb drive to give it the additional space needed for the installation. Fortunately for us, with the most recent firmware installing sslstrip is quite simple and can be done simply through the web interface.

Click on the Pineapple Bar and select "list available infusions  (aka modules)".

Go through all the modules until you find the sslstrip module and click on the "Install" link. This will prompt you to select whether to install it on internal storage or on the USB storage.

Once sslstrip is installed it will put a new line in the pineapple bar labled "sslstrip", go ahead and navigate to it and start up sslstrip by clicking the start button.

Now that we have sslstrip running we just need to grab some passwords. I used my laptop and connected to  my pineapple's wireless network. Let's use Facebook for our example.

By default Facebook defaults to HTTPS connections, but because we have sslstrip doing its magic it sends the connection from the pineapple to the victim's computer as HTTP.

Once the victim logs in they still get access and can go on with their day, but moving back to sslstrip we notice that we've grabbed the e-mail address and password.

Combining sslstrip and karma gets even more alluring as karma can advertise itself as any access point that a computer sends a request for. Taking it a step farther and adding a de-auth script in that disconnects everyone that's not connected to you and you've got a recipe for harvesting passwords from every wireless user around you. No cracking necessary.

Easy to remember passwords that are hard to break

I had a conversation with a colleague of mine where we were discussing the difficulties associated with breaking multi-word passphrases and how we might be able to simplify the process. We determined that given some knowledge of the person and being able to use online resources to create a wordlist could be an effective means to get some results. He was able to use Twitter's API to create password lists that include multi-word passphrases. If you haven't seen it already check out his article at http://7habitsofhighlyeffectivehackers.blogspot.com/2012/05/using-twitter-to-build-password.html

This post is more oriented to those that want to know what makes a good password and what pitfalls to avoid in our own passwords.

Today I'm going to cover 3 areas that make passwords difficult to crack. 1) It's not a popularly used password (I'm looking at you password123) 2) It's hard to bruteforce and 3) Mangling rules don't remove the complexity of the password.

1) Not a Popularly Used Password

There are many password lists out there that are very good at catching the most popular passwords that are used. In my previous post I used a 37GB wordlist that was sorted by popularity. Most passwords in use today mainly consist of a word with some kind of random characters put at the beginning or the end, consist of a "keyboard walk" (I.E. qwerty), or simply numbers. If your password is 12345, password123, 123goaway, etc. consider changing your password.

2) Hard to Bruteforce

This is simply a question of math. Every character of a password gives you X^Nth possible combinations where N is the number of characters in the password and X is the total number of possible characters that could be in the password.

For example, a password of 12flux would give you an X of 36 and an an N of 6 (26 for a-z lowercase and 10 for numbers) which gives you 2176782336  possibilities. When using hashcat I was getting a little less than 1/2 a billion tries per second so this password wouldn't even take a full second to crack. Now if we do a longer password utilizing numbers, lowercase and uppercase letters, and special characters which we'll assume to be all the ascii printable characters comes to 95^N. Let's assume the password is Elv1s lives@. Theoretically this would give you 12^95 or 3.328268652×10¹⁰² possible combinations. Assuming we're cracking at 500M passwords a second that will take 2.110774132×10⁸⁶ years...that's a pretty long time. But this isn't always perfect which brings us to number 3.

3) Mangling Rules don't remove complexity

Since it is usually a better tradeoff to compute the possible changes to a core word (I.E. add numbers before the word, after the word, etc.) instead of having to store every possible combination; password cracking programs like John and Hashcat have the ability to specify mangling rules to modify the words in the wordlist. Mangling rules can get quite complex and make it possible to guess words that wouldn't be found in a simple wordlist. For example, many would think that  P4s$W0rD is better than password because you have more complexity. While this would be harder to bruteforce, with a mangling rule removing l33tspeak would catch this password rather quickly. Here is just a small list of the mangling rules that are used. Keep in mind that several of these can be used at the same time.

• "L33tspeak" mangling
• Adding numbers to the beginning of the word
• Adding numbers to the end of a word
• Reverse the word
• Change to upper/lower case
• repeating the word

We've also been seeing a lot of success creating phrases by indexing books and turning them into a giant wordlist. Don't just use a phrase from a book! Another attack vector that can be used is a combinator attack. It utilizes two dictionaries and tries all possible combinations between them with mangling rules inbetween.

Recommendations

When picking a password, think of phrase that will be easy enough to remember, but hard enough to avoid these kinds of attacks. Shocking nonsense can also be helpful. How hard is it to crack My1gr82day was great! ? Bruteforcing isn't going to be very effective against this password and a combinator style attack would still have a hard time guessing this. In all, this would be considered a safe password (except now that it's posted on the internet...it's not...go figure).

GPU password cracking while you game

The other day I was on oclhashcat's website and I noticed one of their advertised features is" Low resource utilization, you can still play games while cracking " which intrigued me, so I figured I'd setup hashcat on my gaming machine and see how it was able to perform. I found a copy of the hashes obtained from the militarysingles.com breach and did a simple dictionary attack against it just to see how fast it would perform. The results were pretty promising. Keep in mind that I am using my personal gaming machine that was built on a budget. I think I spent less than $600 for it all. I won't post the full specs, but the video card I am using is a GeForce GTX 460. Let's see how far we were able to push hashcat.

So 4 1/2 million computations per second...not bad! The GPU utilization shows it hovering between 80% and 90%. Granted this is without doing any mangling rules, but is still an impressive number. In case you were wondering I left it running while I played some Diablo 3 and didn't notice any significant impact on the game, although hashcat did slow down a bit while playing. It looks like you can indeed crack passwords and game at the same time.

After getting to know hashcat a bit, I decided to see how well it could crack passwords. Up until this point the only tools I had used for password cracking were John the ripper and Cain.

I took the hashes from the militarysingles.com breach and passed a sorted and prioritized dictionary (sorted so the most common passwords are used first, etc.) and did a test to see how many passwords it would get in a second. Here's what I got:

In 1 minute out of 118k we were able to get 21k passwords. Hmm...that's pretty good, let's let it sit for a little longer and see what we can get. I checked back in at the 5 minute mark:

72,937 passwords recovered in 5 minutes. In 5 minutes we were able to recover more than 60% of all the passwords. This is also with a single word list and no mangling rules. Well, if we let it run for the full half hour and go through the word list without any rules, what do we end up getting?

Not too much better sadly. The final number is 75,837 or 64% of the passwords. Not too bad for a 1/2 hour's worth of work.

Let's start utilizing the power of mangling rules now. Just using the stock mangling rules that come with hashcat (in this example i'm using the best64 and the passwordspro rules) let's feed the passwords back into hashcat

After the first pass we jump up to 83k, after the 2nd pass we jump up to 86k. At this point we've spent about 40 minutes attacking these hashes.

Well, that's the time I have to cover hash cat. If you have any questions feel free to leave comments and ask questions.