Using a Throwing Star to Capture Packets

Mobile applications are a hot commodity these days.  It seems like everyone and their brother/sister is writing them.  Kevin Johnson even tells a story of a bait/mobile application shop here in Florida somewhere.  When I say bait, you guessed it, I really mean bait as in fishing bait.  Earthworms and such.  With everyone writing these apps, and no real way to know how secure they are it is really up to each of us to take the responsibility to test the apps we want to use.

There are multiple ways to test a mobile application.  One technique, that I won't be covering in this post, is to hook up a proxy server for your device and intercept the HTTP(s) traffic that is passed around.   Another way, which is the focus of this article, is to capture all of the traffic between the device and the server.  This method not only captures HTTP traffic, but also allows inspecting other protocols that the application may be using.  This is ideal when the application uses raw sockets vs generic HTTP requests.

When testing a mobile application, on a physical device, there are a things that make it easier.  The first step is to have a dedicated wireless router or access point specifically for the mobile device.  For example, I have a Linksys router that is used only for mobile device testing.  The second step is to intercept the traffic from the wireless device to the internet.  This can be done by placing a tap between the wireless router and the other routers and connecting your computer to the Tap. 

I choose to use the Throwing Star LAN Tap Pro from Great Scott Gadgets (http://greatscottgadgets.com/throwingstar/).  There is also a non-pro version, but dust off your soldering skills to put it together.  The setup is really easy.  The following steps are used to do the hardware setup:

   * Wire the Wireless Router/Access Point to the Throwing Star LAN Tap
   * Wire the Throwing Star LAN Tap to the existing infrastructure
   * Wire your computer to the Throwing Star LAN Tap on the interception port

The following image shows the LAN Tap wired up:

Now that we are set up to listen in on the traffic, it is time to fire up a packet capture program.  I use WireShark, but you could use a different program if you prefer.  You can get WireShark from http://www.wireshark.org/.  Setting up Wireshark is pretty quick and easy.

Once you open WireShark, Click on Capture…Interfaces to select an interface (seen below):

After Selecting an interface, click the start button to start capturing traffic.   The following image shows an example of WireShark capturing packets.  

Now that you have packets, you can start to analyze them.  The benefit of capturing this level of detail when testing a mobile application is that it allows you to see more than just the standard HTTP traffic.   It is not uncommon for developers to use direct connections rather than going through the HTTP Protocol.  This technique allows you to view any other connections that the application may be making that a tool such as Burp would not identify. 

I recommend everyone that is testing mobile applications to use this technique to ensure they are not missing any connections the application makes. 

Want to know more about mobile application penetration testing?   Kevin Johnson and James Jardine will be teaching "Assessing and Exploiting Mobile Applications with OWASP Mobisec" at Blackhat USA 2013.  There are two sessions running and this is going to be an excellent course filled with hands-on labs.  For more information: http://www.blackhat.com/us-13/training/assessing-and-exploiting-mobile-applications-with-owasp-mobisec.html

James Jardine is a Principal Security Consultant with Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Preparing for a Consultant

As security consultants, we regularly travel to clients’ sites and experience a wide range of environments and atmospheres. While some are better than others (and some much worse), it’s very common for the client to not be fully prepared when we arrive. This often results in delays, a less efficient use of the time we have, and even missing findings because we can only assess what we have access to.

In this blog post I’m going to outline some of the failures that we often see. I’ll also give you some specific things that you can do to prepare for having consultants come on-site.

Why Bring in a Consultant?

To begin, let’s look at a couple of the reasons that security consultants are hired.

• Not Enough People/Time: Many organizations know what they need to do, but they don’t have the resources to really do the job well.
• 3rd Party Review: An outsider can openly assess a system without the inherent blindness that always creeps into a culture.
• Lack of Internal Skills: Some organizations just don’t have the specific skill-sets required to complete specific tasks.
• Compliance Requirements: PCI, HIPAA, etc may require that certain tasks be performed by an outside team.
• Management Attention: Sometimes it just takes an outside consultant to ring the bell loudly enough to get light focused on certain issues. 

All of these reasons are valid uses of consultants. Unfortunately the reason for the hiring consultants is often misunderstood, miscommunicated, or just poorly planned. This can cause a “circling of the wagons” approach where your internal team binds together to repel the “attackers.”  So that leads us to the most important thing you can do…

Communication
The number one thing you can do in your organization before your consultants arrive is to COMMUICATE! Bring in your whole team and make sure they understand what’s going on. Bring in representatives from adjacent teams that may be affected. Bring in management who may be called on to approve policy exceptions. Get everyone involved from the very beginning. Don't wait for us to get onsite to tell everyone what's going to happen.

The goal should be to avoid an “us versus them” mentality that will destroy your project. Explain that this is a collaborative, team effort, with the ultimate purpose of benefiting the organization.  Nobody likes confrontations or being called out for mistakes. Let everyone know that a primary goal of the assessment is to find areas for improvement, not to place blame.

Get Approvals - Ask Early, Ask Often
Bringing in consultants almost always requires exceptions to standard policies. We may need access to information not commonly shared outside the organization. We may need network access that requires firewall or ACL changes. We may need to view system configurations or vulnerability scans. Start making a list as early as possible and get the appropriate sign-off from system owners and managers. When possible, specific written authorization can make the process go very smoothly later on.

Prepare Documentation
Begin making a file of all the documentation that the consultants may need. If you can provide it on the first day we get on site then it will greatly increase our effectiveness.  Of course this will vary greatly on the type of engagement, but here’s a list of some of the most common things we may ask for:

• Network map(s) & similar documentation
• IP ranges and domains to be tested or excluded
• User names to test as (At least 2 different users for each role type to be tested.)
• Policies, procedures, manuals, etc, that are to be reviewed
• Source code for any applications or sites in scope
• Firewall, IPS, router, configurations or rule-sets
• Department organizational chart
• Policy exception lists
• Contact list of involved employees (including email addresses and phone numbers)
• Anything you want us to know. If there are specific concerns, or known issues, spell that out ahead of time.

Schedule Facilities
While on-site, we usually base our activities out of a conference room. It must be lockable and should be big enough to comfortably seat 4-5 people and 4-5 laptops. We’ll also need a landline telephone and at least one Internet connection, though additional connections can be helpful.  Take the time to make sure that the room is reserved for the entire duration of the engagement. If we’ll be conducting interviews or meetings in other rooms, make sure those are reserved as well. Often for a kick-off or review meeting, there may be 5-10 people in the room.

Schedule Interviews
If the engagement includes interviewing members of your team, do some preliminary scheduling ahead of time. It’s always frustrating to get on-site for a 5-day assessment and find out that someone isn’t available until Thursday. Of course you should also be flexible and understand that things may change as the assessment proceeds.

Conclusion
Every organization is unique and presents different challenges, but by planning ahead you can ward off most delays. So get your whole team involved and set the stage for a great engagement.



Nathan Sweaney is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at nathan@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Autocomplete and actual risk: Why do we look at it?

Autocomplete is always a fun topic to discuss.... ok maybe my idea of fun is not the normal idea. :)  During our web penetration testing, we often find where the client's application allows the password or other sensitive information to be saved by the browser.  When we find it, we often have push back from the client stating that its the end user's decision to allow this. (Of course we disagree. <grin>)

Recently I was working with my daughter (Sarah), who is home schooled, on a spelling lesson.  She was trying out this online service that provides lessons such as spelling and math for students.  While working through a spelling lesson with her, I noticed an interesting problem.  Autocomplete was enabled for the input boxes.  (On Sarah's laptop, I have autocomplete enabled because she is 6 and doesn't use credit cards. <grin>)

This started me thinking about the use of autocomplete and the typical response from security testers.  I believe that most of you reading this would mention autocomplete being enabled for a credit card field or a password entry box on a web site. (Even if its just a low or informational finding.)  But do you evaluate the other fields and entry boxes?  Do you base your thought process around the actual business process and if the data could be considered sensitive?

To better understand this, let's walk through the business issue with this application.  First, the lesson was a spelling lesson.  On the previous series of pages, the application presented a lesson that defined a word and had a form field.  When Sarah clicked into the field, an onfocus event fired which played an audio file of the word being spoken.  She would then type each word as part of the lesson.  Finally, at the end of the lesson there is a test.  This test also used the onfocus event to play the word she needed to spell.  When Sarah clicked into the field, it would display the autocomplete history which was the word from when she did the practice portion of the lesson.

While this is not an earth shattering flaw, it does undermine the main purpose of the online lesson system.  Which would be a business issue since this is a subscription service and if I can't trust that the test results aren't based on if my kid pays attention to the autocomplete, then why would I pay for the service?

As penetration testers, this is exactly the type of business concern that we need to be paying attention to while testing.  And for the record, I did notify the lesson provider and have not yet heard back from their developers.

Kevin Johnson is the CEO of Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at kevin@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Professionally Evil: This is NOT the Wireless Access Point You are Looking For

I was recently conducting a wireless penetration test and was somewhat disappointed (but happy for our client) to find that they had a pretty well configured set of wireless networks.  They were using WPA2 Enterprise and no real weaknesses that I could find in their setup.  After conducting quite a bit of analysis on network captures and looking for any other source of weakness, I finally concluded that I wasn't going to get anywhere with the approaches I was taking.  Rather than giving up and leaving it at that, I decided to go after the clients using the network and see what I could get them to do.  I had a a laptop and a number of iOS, Android and Palm devices at my disposal, so how would they respond to a fake access point?

I decided to setup a fake access point (AP) using a matching SSID, which we will call "FOOBAR" for our purposes.  I downloaded the latest version of hostapd (2.0 as of this post) and set it up to be use WPA2 Enterprise and configured Freeradius-WPE as the fake authentication system.  The goal was to have a client connect to my evil AP and then give me their credentials.

Freeradius-WPE came pre-installed on my laptop running Backtrack, so no real work there.  About all I did was install a valid SSL certificate for use by the radius daemon.  Unfortunately, I could never get Freeradius-WPE to handle the CA certificate chain correctly and that had an impact on my attack later on.  If you don't care about a valid TLS certificate, then start Freeradius-WPE on Backtrack by running "radius -X".  The -X will cause the daemon to setup self signed TLS certificates automatically.

With that done, I moved on to installing hostapd.  At first I installed hostapd from the apt repositories already setup in Backtrack.  Unfortunately, there was an issue with that version and my setup, which caused it to fail at startup.  To get around this, I downloaded and installed the app from source and the problem went away.  Below is my hostapd.conf file.

This config is largely based off of some searches for default configurations of hostapd and then I researched the settings that I needed to have to get WPA2 Enterprise working.  The critical pieces to doing that were setting wpa=1 and then setting wpa_key_mgmt=WPA-EAP.  I also made sure that hostapd was pointed to my radius server and had the correct password to access it.  Last, I set my SSID to match our client's environment (or in in this example used "FooBar").  To get hostapd running, I ran "hostapd hostapd.conf" and I was up and running.  

I picked up my test iPhone and found FooBar in my list of available networks.  When I selected this network, I was prompted for my test account's username and password.  So far so good...  Then I hit a major snag in making this attack invisible.  The SSL certificate chain was not being presented properly, so my cert showed up as invalid.  

After a bit of troubleshooting and a dwindling testing window for this attack, I finally had to relegate fixing this to later research.  And honestly, if someone was presented with an invalid certificate the chances are pretty high I'd get someone to click on it in spite of this warning.  I accepted this warning and proceeded on with my test.  The credentials were sent to my fake AP and Freeradius-WPE captured my credentials.  

The password doesn't get sent across, but that's hardly an issue in this case.  I'm using a really dumb password for our example and John the Ripper with a good password list will have no issues with it.  All we need to do is take the username and hashes and put them into a text file in the format that john expects for NETNTLM hashes.  This involves removing all the colons in the hashes and getting them delimited properly for the expected format.  My two entries end up looking like this in my capture file.

Finally, I turn John loose on the hashes by running "john -w:/pentest/passwords/wordlists/rockyou.txt --format=NETNTLM hashes.txt".  As expected, the hashes broke within seconds.

At this point the attacker wins by using these credentials to log into the targeted network and proceeds with whatever the next step in their attack is.  There were a few steps to get to this point, but really it was pretty straight forward.  

Happy pen testing!

Jason Wood is a Senior Security Consultant with Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at jason@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

The Watering Hole: Is it Safe to Drink?

How many times have you been told you have a vulnerability that you just don’t understand  its relevancy?  Cross-Site scripting comes to mind for many people.   Sure, they get the fact that you can execute scripts in the user’s browser, but often times they really don’t fully understand the impact.  Of course, we determine that impact through risk analysis.  What is the true impact and how much risk does it pose to the affected parties?
Over the years, I have heard numerous companies and previous employers state that no one would attack them because they are too small or that they didn’t have anything that the attackers would want.  I have always disagreed with this statement or theory.  Maybe you are a company that doesn’t contain financial data, or health information.  Maybe you don’t deal with sensitive information at all.  So what is the risk? 
We have to start thinking about more than just the type of data that we hold.  We have to look at the bigger picture.  Who are our clients or users?  Who do we do business with that may have something of interest to an attacker.  One of the big concerns that has been directed toward these smaller companies is the idea of pivoting.   If I wanted to attack a major bank, would it make sense to attack the bank directly?  Very large banks usually have bigger budgets and theoretically would have stronger security controls in place.  That could be a lot of work to get through that entry point.   But what about that small company, that has a smaller budget, and probably (not always) fewer security controls that does business with that big bank?   Is there an opportunity to compromise the small company and pivot into the larger bank through a B2B channel they have set up?   This is certainly a possibility.
Something newer we are seeing is this idea of a Watering Hole attack.  This focuses more on the “WHO” visits your site.  The idea behind a watering hole attack is that it is a targeted drive by malware type of attack.  Rather than putting a malicious payload on a site that EVERYONE accesses, why not target a site that the victim you are tracking frequents.  Think of this as similar to the difference between phishing and spear phishing.  In a phishing attack we send out the attack email in mass, but in spear phishing, we are much more refined in who receives the message.   The same goes for this watering hole attack.
As always, we are witnessing the evolution of these attacks.   Migrating from a broad spreading mechanism to a more targeted one has a lot of benefits.  One is that your specific target is more likely to fall prey.  Two, there is less chance of the attack getting noticed if fewer users actually see it.  We have seen other situations where the attackers have actually built their delivery mechanism to not deliver to know security professionals or researchers based on their IP address to avoid getting noticed as quickly. 
The watering hole is just another example of why security does matter to every website, no matter what your content may be.  Even if the attack isn’t against our servers, but against our users, that can have a serious effect on our businesses.   The next time you hear someone say that they are too small or don’t have any data that attackers may want, think about the watering hole concept and see if you are still a nobody in this world.

James Jardine is a Principal Security Consultant with Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Professionally Evil: Your Stealth Startup is Showing

During our penetration tests we often get asked about the amount of information that is leaking out via social networks, web pages and the like.  In fact the first step in our methodology is Recon where we search the Internet and social networks for information about the company we are targeting.  It is sometimes surprising what we find when we look.

During the course of one engagement, the organization commented that their staff was not allowed to discuss the company on social networks.  They had gone so far as to forbid their staff from listing the company as an employer on LinkedIn.  When we heard this, we of course felt that a gauntlet had been thrown down.  So we decided, as an addition to the penetration test, to see exactly how effective this strategy would be in preventing us from determining who worked for them.

We began by working through LinkedIn's search and Google, limiting the site in the results to LinkedIn. (This last can be accomplished by adding the site:linkedin.com string to the query.)  By doing this and searching for things like the city the organization was located, we were able to find a single person who had posted a status message with the name of the company in it.  This was the break we were looking for.

We then started poking around in two sections of this LinkedIn profile.  The first was the connections list.  As shown in the below screenshot, (taken from my connection list NOT the clients!) we are able to see people connected to the person we are viewing.

Connections Listing

This gave us a listing of the one person's connections, which often include people who work at the same company.  We also looked at the People Also Viewed listing.  The one from my profile is shown below.

People Also Viewed These Profiles

This lists the various accounts viewed after the visitor left this profile while browsing LinkedIn.  By taking these two lists, from the one account, we were able to start picking out people who either did not list a current employer or had something interesting.

What was that something interesting you ask? Well it's simple.  When people realized that they were not allowed to list their current employer, they began to put in various strings that meant they worked for a Stealth Startup.  We also noticed that many people put the same string.

By recursively working through these two lists on each account, we were actually able to create a detailed list of employees we believed were part of the company.  We were then able to gather a good idea of the technology in use and even what the stealth application was related too.  This was due to the listed skills and the fields the employees came from before their stint at the startup.

So how do you fix this?  Ultimately, you can't!  People are going to list things and you are going to have to deal with the results.  So make sure you know what is out there.  This organization was not searching for data like this since they felt that they had it covered with their policy.  Make sure you don't fall into the same trap! If portions of your corporate security depend on employees following procedures, then you must regularly test for violations of those policies.


Kevin Johnson is the CEO of Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at kevin@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Brute Forcing the Change Password Feature

As a penetration tester, brute force attacks are something I test for on every application.  Obviously, I test the login forms for this type of security flaw.  There are also other areas of an application that brute force attacks can be effective.  The one I want to discuss in this post is related to functionality inside the authenticated section of the application.  More specifically, the change password screen.

Done right, the change password screen will require the current password.  This helps protect from a lot of different attacks.  For example, if an attacker hijacks a user’s valid session, he wouldn’t be able to just change the user’s password.  It also helps protect against cross-site request forgery for changing a user’s password.  I know, I know, it can be argued with cross-site scripting available, cross-site request forgery can still be performed, but that gets a little more advanced. 

What about brute forcing the change password screen?   I rarely see during an assessment where the developers, or business has thought about this attack vector.  In just about every case, I, the penetration tester, can attempt password changes with a bad password as much as I want, followed by a valid current password to change the password.  What if an attacker hijacks my session?  What if someone sits down at my desk while I have stepped away and I didn’t lock my computer (look around your office and see how many people lock their computer when they walk away)? 

It is open season for an attacker to attempt a brute force attack to change the user’s password.  You may wonder why we need to change the password if we have accessed the account.  The short answer is persistence.  I want to be able to access the account whenever I want.   Maybe I don’t want the user to be able to get back in and fully take over the account.

So how do we address this?  We don’t want to lock the account do we?  My opinion is no, we don’t want to lock the account.  Rather, lets just end the current session in this type of event.  If the application can detect that the user is not able to type the correct current password three or five times in a given time frame (sounds familiar to account lockout procedures) then just end the current session.  The valid user should know their password and not be mis-typing it a bunch of times.  An invalid user should rightfully so get booted out of the system.  If the valid user’s session ends, they just log back in, however the attacker shouldn’t be able to just log back in and may have to hijack the session again which may be difficult.

Just like other brute forcible features, there are other mitigations.  A Captcha could also be used to slow down automation.  The key differentiator here is that we are not locking the account, but possibly just ending the session.  This will have less impact on technical support as the valid user can just log back in.  Of course, don’t forget you should be logging these failed attempts and auditing them to detect this attack happening.

This type of security flaw is common, not because of lazy development, but because this is fairly unknown in the development world.  Rarely are we thinking about this type of issue within the application, but we need to start.  Just like implementing lockouts on the login screens, there is a need to protect that functionality on the inside.

James Jardine is a Principal Security Consultant with Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.