Mak5 WifiPineapple - the basics

I've been breaking out my Hak5 Wifi Pineapple of late, and figured since I'm messing around in it, I ought to share what I've learned.

First Steps - Setting Up

The first thing I did with my Pineapple was get an open wireless LAN going. Something kinda sticky, honeypot-like... First, I logged into my Pineapple (follow the included directions to get that far), by connecting to it with my Air over wifi. This is the homescreen:

Next, I went into the "Network" bar and moved to the "Access Point" tab and gave my WLAN a better name:

Think anyone will nibble?

Network Access

A Wifi Pineapple is more fun when it is connected to the webz and can proxy unsuspecti--er, generous volunteers. So next, I connected my Pineapple to my internal network:

OK this is awesome, because now I'm proxying my communications through my WLAN to the Internet. 

Shall We Play A Game?

NOTE: there are legal ramifications to interrupting folks' wireless connectivity. I do this only when 1) I'm at home, connected to my own WLAN, and testing or 2) when clients pay me to do a wireless assessment AND I HAVE A SIGNED DOCUMENT STATING I AM AUTHORIZED.

The Pineapple is, simply put, an awesome and powerful wireless network assessment tool. What you can do is almost unlimited. For this test, though, I'm going to use the "Karma" infusion to capture open networks. Karma is basically a tool which will mimic an open network--it's a very promiscuous access point. The background on Karma is that it's a simple tool to attack any wifi-capable device.

Karma takes advantage of the completely backwards concept that your computer continuously searches for networks its previously connected to. Instead of the Starbucks wireless AP calling out "Hey I'm Starbucks - anyone wanna connect?," your device (laptop, tablet, etc.) calls out "Is anyone here the Starbucks AP?" and connecting when someone answers yes. These are called "probe requests" and they're one of a couple really stupid implementation fails on wireless. Karma... Well, Karma responds "Yes" to every request. Every request...

Want to understand how "probe requests" work? Try these sources:

• https://scotthelme.co.uk/wifi-pineapple-karma-dnsspoof/
• https://www.youtube.com/watch?v=avJfT9JyiiM

So 30 seconds into running Karma, here's what I have:

Somewhere within reach of my Pineapple (running the long gain antenna), devices are looking for 5 different networks. Ten minutes later, this count jumped to 12 different networks. Eventually, I even captured an association (meaning a device which had formerly connected to an open network and which was happen to get another open connection to the same network - served up by me).

Things to Know

A few things to keep in mind:

1. Most of the tutorials say it's easier to tether over a network cable. None of my current laptops have network cables, but I'm able to tether just fine over WiFi. Don't be afraid to do it that way.
2. USB... To do any serious logging, you need to have a USB drive connected. I do not, yet, so that'll probably be the next blog.

Happy Pineapples!

Mounting a USB Device in a Linux VM

I recently did some work for a customer. Part of the project included a security analysis of a Linux-based VM client. The client is configured to VPN into the customer’s data center, so there’s really no way to network into or out of it (not easily). My challenge was pulling a few files off the client. Solution? Not all that difficult, actually:

1. Plug a USB device into the host machine
2. In VMWare, connect to the USB device
3. In linux, you need to create a mount point for the USB device, and then mount it
4. From there, it’s a simple copy command.
   

mkdir –p /mnt/myusb

mount –t vfat –o rw,users /dev/sdb1 /mnt/myusb

Oops another challenge:

• How do U know where the USB device ends up? I scratched my head for a while on that, until my buddy recommended I grep the logs.

Solution: I searched the logs for SCSI connections, by entering grep SCSI /var/log/messages and saw where the USB device had been attached.

Finally, it was a simple matter of copying the file, which was of course cp /root/myfile.txt /mnt/myusb and I was rocking!

Virtual Private Cloud

For a while now, I’ve been wanting to leverage a cloud service to host a scanning tool I’m working with. Given that the scan results are sensitive, I don’t really want to have the scanner publicly available. So it’s always struck me that a virtual private cloud with point-to-site VPN is the solution. Straightforward, right?

Well, no…

AWS doesn’t support it. I suppose I could configure something with an additional VPN server that straddles the Interwebz and the VPC but seriously? One more machine, more config, more support… blech.

 

Enter Azure – turns out, they support point-to-site VPN connections. It made my VPC hosting decision pretty easy.

Caveat: I didn’t look into Rackspace or the myriad of other “me-too’s!” out there. Just AWS and Azure.

You can read up on point-to-site VPNs here: http://msdn.microsoft.com/library/windowsazure/dn133792.aspx Keep in mind, this feature is currently (as of 2/2014) in CTP mode so it’s not exactly production ready. But since my site is small and won’t have a ton of traffic, I’m OK taking some chances on availability.

So finally the project kicks off today – ironically, creating the Azure VPC is quick but creating just the simple gateway? Not so much… Azure’s been churning away for 20 minutes already and still the gateway hasn’t completed. I guess I’ll capture the next step in another post.

Using SQLite to View Google Chrome History

I recently needed to view a user’s browser history from Google Chrome, without affecting that user’s actual history – in order words, without opening Google. In order to accomplish that, I:

1. Logged onto the desktop as an administrator
2. Installed SQLite3
3. Copied the Chrome history file from the user’s profile into the SQLite3 folder
4. Open the history file in SQLite
5. Executed a simple command to pipe a date/time stamp and the URL to a text file

It took some poking around the Internet to find how to do this – I’ll assemble the steps here, for “one-stop shopping” for people who need to do this.

Oh – this post assumes you’re logged on as an administrator.

Install SQLite3

This is pretty simple – go to the SQLite download page and get the version you need. http://sqlite.org/download.html I recommend the SQLite Shell precompiled binary for Windows.

I like to keep all my tools in one place, so I extracted SQLite3 into the \tools\SQLite\ folder. (BTW: I recommend keeping your tools folder somewhere where there are no spaces in the path—older apps can’t handle spaces).

Copy Chrome History

The user’s Chrome history file is NOT where the web says it is… Just sayin’. It’s here: C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\

The file is simply titled “history”. Copy that file and paste it into the SQLite folder you created when you downloaded that tool.

Open History in SQLite

Open a command prompt and navigate to the SQLite folder you created. Then type this and hit enter: sqlite3.exe history

Execute Query

Almost there – really, it’s that easy…

sqlite> .mode column
sqlite> .width 25 255
sqlite> .output urls.txt
sqlite> SELECT datetime(((visits.visit_time/1000000)-11644473600), "unixepoch"),
urls.url FROM urls, visits where urls.id = visits.url;
sqlite> .output stdout
sqlite> .quit

Yes, the period is needed before any command.

And that’s all there is to it – you’ll have a fixed-width file with the visit date in the first column and the URL in the second column.

Resources

http://sqlite.awardspace.info/syntax/localindex.htm

http://www.forensicswiki.org/wiki/Google_Chrome

Why Combine Static Code Analysis with Manual Pen Testing?

As company culture becomes more security focused, the company eventually decides to perform a penetration test against their application assets. As a consultant, I'm often asked to provide a broken down cost for "big rocks" in the process. Companies today are thinking quite narrowly--they want a penetration test when really the goal is to assess their application. My challenge has been to demonstrate the value of the full application assessment and help companies get beyond the pen test requirement.

What's an app assessment? Well, it's a mix of white- and black-box activities which result in fact-based risk decision making. There are generally five components to an application assessment:

1. Application review: what are the goals, business needs for an application, what kinds of data are stored in the app, what are the technologies behind the app?

2. OWASP ASVS: this tool captures key security decisions implemented in the application. It's an exhaustive form (level 3, which is usually applicable to healthcare and other sensitive applications, contains over 150 validation points).

3. Static code analysis: automated review of application source code. At Caliber, we are big fans of our partners at Checkmarx SCA. I'll blog on "2nd gen" SCA tools sometime. The key here is that SCA can generally find more vulnerabilities in certain categories faster than I can do it manually. For instance, XSS or SQLi vulnerabilities. These generally need to tested for one control at a time, with at times multiple permutations of inout text. Manually or even with dynamic application analysis, this can take days. Automated tools accomplish this in minutes or hours.

4. Manual penetration test: this is the traditional pen test activity everyone thinks about. With SCA involved earlier, I can spot check validity of results, and focus my efforts on topics like session management, authentication and business logic.

5. Analysis: data from each phase is assembled into a report, from which it can be assessed and prioritized.

Just pen testing alone *does* mimic what an attacker will do, with one significant difference: a paid pen test functions under time constraints. A determined attacker will take days or even weeks to profile and attack an application. This is one of the reasons why performing all 5 steps in an app assessment is beneficial: white-box assessments get to the same vulnerabilities, more quickly.

When it's time to do security on your web and mobile apps, don't just request a pen test. Go for the full assessment--sure it might cost a bit more, but you and I will both sleep better knowing you are more secure!