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.