Monthly Archives: October 2013

Chromebook, Linux

Chromebook 14: First Impressions

Leave a comment

Background

I have been looking to get  a laptop like machine to use as a hackery system. Something I could take with me on travel, and something I could mess up on a regular basis without disrupting my work / personal system. I started with the classic list of laptop criteria: fast, light, thin, cheap with good battery life. Since it was a hackery system, there were a few other requirements. It did not need a CD/DVD and a quick recovery system would be a good thing, and expandability for futureproofing would be good. Yeah right. Since most of us can’t have everything we want, I had to shortlist this to critical items. Most importantly, I needed something I could easily slip in my pack with my primary laptop, had a decent sized screen, and was cheap.

I considered a number of options, and ended up picking a 14 inch HP Chromebook. I really don’t  understand why the exclusive retailer is Walmart, but the package is interesting. It includes:

  • The Chromebook / 4GB RAM / 9 hours of battery life / Haswell processor
  • 100 GB of Google Drive storage for 2 years ~ $5 x 24 (retail)
  • 200 MB of T-Mobile 3g monthly access for 2 years ~ $5 x 24 (guesstimate)
  • 12 Gogo Flight Internet passes ~ $14 x 12 (retail)

At retail, these individual items total up to about $408 + Chromebook (with a retail package cost of $350), and if we assume between bulk discounts and subsidies the add-ons are probably worth about half that, this puts the effective cost of the Chromebook alone at about $150. For that price, it is the best cheap / thin / big screen laptop to fit my needs.

First Impressions

ChromeOS is more than a browser. The user interface is Chrome Browser on top of a Chrome-like window manager on top of a Linux base OS. The factory default mode has no privileged access (root disabled), but full functionality can  be enabled with ‘developer mode’. As far as running a more traditional Linux install, there is a very interesting chroot solution called ‘crouton‘. More on that in a later post. One of the cool features I discovered is that by switching from developer > factory > developer modes I reset the entire OS to default configuration in about 20 minutes from an internal image – which makes for a very fast / low overhead feature for useful hackery.

Overall – I am still not ready to give up my primary / full function laptop, but this is probably the best value in a laptop I have ever bought.

Internet Security, Security

Google Two Factor Authentication

Leave a comment

Background

Anytime we get real data on Internet user passwords, we once again discover people are bad with passwords. Additionally as the tools to compromise and crack passwords get better, even high quality passwords are becoming less secure. Two factor authentication is something that should be used – when available and if you have an authenticated website / webapp, there is a cheap and easy method to implement.

In an earlier post, I showed that some online services were more critical than others from a security perspective – specifically the email account used for account recovery for other services. In many cases, this is Google Gmail and in this post I will be using it as an example.

One Time Passwords and Google Authenticator

Google Authenticator is a relatively simple app written by Google that generates time windowed One Time Passwords (OTP) every 30 seconds. This app is available for Blackberry, iOS and Android devices, and can be used for Google account access as a Two Factor Authenticator (2FA). More importantly, it can be used by any non-Google website or application developer. Let me back up a minute, and explain why this is a good thing.

An Authenticator is something you use to authenticate – or prove who you are to a system. A password is an authenticator, but not a very good one by itself (anymore). Authenticators can be based on:

  •  Something you know : Password, PIN code
  • Something you possess : Smart Card/Fob, SecurID, device with Google Authenticator
  • Something you are (biometrics) : Fingerprints, Retina scan, etc.

The idea behind Two Factor Authentication is that even if one the factors is weak, the combination of two factors is much stronger than either one of the authenticators individually. Most importantly – it is very easy to share passwords, but very hard to share both parts of a Two Factor Authentication.  In the very recent past, 2FA was not very accessible since passwords are cheap to use / implement, and none of the other authenticator options were.

Here is where Google Authenticator comes in. Google Authenticator provides a well known (RFC6238) method to generate six digit authenticator tokens based on the current time and a shared secret key. The app can also support multiple concurrent authentication generators. The app does not depend on Google services – and up until a certain point, it was open sourced. Open source equivalents to Authenticator are available. Details on the alternatives and how Authenticator functions is in the associated Wikipedia article.

Enabling on Google Account – How it Works

To setup 2FA on your Google account, do the following:

  1. Install Google Authenticator on your Smart Device (phone / tablet / etc)
  2. Login to your Google Account
  3. Go to Account Settings / Security / 2-Step Verification and select ‘edit’
  4. Enter the information including the phone number and printing out the 10 emergency codes. Safety nets are what prevent Self Inflicted Denial of Service Attacks (SIDoSA).
  5. Follow the instructions to load the shared secret into the app AND verify it.
  6. That’s it – you are setup.

After that, you will be asked to enter username / password followed by a request for the six digit authenticator from your smart device. Since I don’t store cookies, I need to do this each time I login – but after a few days it becomes an easy habit. I also have the knowledge that my account is fairly secure – even if my password looks like “Fluffy-Bunnies” instead of something like ‘H@Af5%Zwqhkh*6iJ8’.

Potential Risks with using Google Authenticator

There are no risk free solutions to real problems, and Google Authenticator also has its risks. We can look at a couple of scenarios to see what some of those may be:

  • When used on Google Account:
    • Q: If my Google Authenticator device is lost or stolen and it happens to be the phone listed as my recovery, could somebody use that to access my Google account?
    • A: Only if: your phone is not locked (it should be), and they also have your password – since they need both factors to get in. Low Risk (and yes you should put a lock on your phone).
    • Steps: If this actually did happen the first actions you should take is to use one of your 10 recovery codes to login to your google account, disable 2FA, disable that device password (if you use device passwords) and change your primary password – taking your lost / stolen authenticator out of the loop and disabling access of any form from that device.
  • When used on some Non-Google website /application:
    • Q: Since the secret key for this non-Google website / application is entered into Google Authenticator, does Google now have access to my account on this non-Google website / application.
    • A: Not very likely. It is possible that they are backdooring all of these secret keys, but since:
      • There is no direct association between a secret key and a given website / application, there is no direct way for Google to know where this key should be used; and
      • It is only one half of a two factor authentication, since they are missing the password authenticator (and the username).

Bottom Line

Passwords alone are about a decade past being effective and rapidly approaching useless. Google Authenticator provides an effective authenticator generator for Google accounts that can also be used on just about anything (there is a PAM plugin available). and when paired with a password provides a much better degree of security.

Recommendations

Use it for Google accounts and any other website that offers it as an option. Use it for your enterprise login.

For the Maker community – Use it for your PIN pad on your house/garage door. Use it for access to your home automation webserver.  A rolling Google Authenticator can be duplicated on multiple devices easily to allow family wide access, but cannot be shared with others (something to be said for that). 

Use it everywhere you can imagine – and if you can use it with a password, you have 2FA and all of the goodness that comes with that.

Internet Security, Security

Security as a System: iMessage

Leave a comment

Background

Say it with me folks, “Security is a system”. In case it is not obvious what that means, I will articulate. Security is made up of a collection of parts, and the system security of this collection is not based on the average security of those parts, or the sum security of these parts – it is based on the weakest security of those parts and how they are integrated. And – sometimes that weakness is not even a part, but a gap in the integration of those parts.

I know, in the abstract we have all heard it before. However we have a new example that highlights this principle.

Before we get into the example I want to share a few of Tom’s Rules of Security:

  1. Know your Threat – Security can only be understood / judged in the context of a given threat type. Good security against one class of threat may be worthless against another class of threat.
  2. Follow the Keys – Key management is about how and where the encryption / access control keys are kept. Whoever holds the keys controls the access. If it isn’t you, you don’t control access.

Note – These are not really my rules, just my personal versions of well known principles.

In the Spotlight: Apple iMessage

Recently there was a presentation in Kuala Lumpar (by pod2g) addressing the security of Apple iMessage. More specifically the presentation highlighted a few weaknesses that illustrate the two rules identified above, and went into great detail as to how it could be compromised. For our purposes, we need to first look at how iMessage works and then we will look at how it can fail – or at least be insecure.

From any given iMessage client a secure message can be sent to any other iMessage client. This message is based on public-private key encryption keys. With public-private encryption keys, every user has two keys – a private key (which is the secret key) and the public key (which can be shared with anybody). These are special keys in that any message encrypted with the public key can only be decrypted with the cooresponding private key, and conversely any message encrypted with a private key can only be decrypted with the corresponding public key. In the first case, it allows somebody to send a secure message to a given person without needing to exchange secret keys. In the second case – also known as digital signing, it identifies the source of the message since only the holder of that given private key could create that message. When these methods both used, a message can be sent from Ted to Alice (using their respective public keys) and:

  • Ted knows Alice and only Alice can decrypt the message if it was encrypted with her public key.
  • Alice knows that Ted and only Ted could have sent the message if it was signed with his private key.

To a certain degree, that is what Apple iMessage does. However, messages are not sent directly between Alice and Ted, they are sent through Apple services and retained under both of the AppleID accounts of the message participants. This alone is not a security exposure by itself, but as a user I would like the option to purge my historical data. It may be securely encrypted today, but who is to say how secure that may be in the future?

In any case, the next part of the story is that all the public keys used by iMessage are stored on Apple ESS servers and are delivered to iMessage clients automatically. Which puts Apple in a perfect position to compromise any encrypted iMessage with a Man in the Middle attack (MiTM). Specifically pages 75&77 (of the presentation) show that Apple has full control of the public key directory, public keys are retrieved by clients “as needed” (with a 30 minute cache window), and users have no visibility into the public keys being used. At any point Apple has the technical capability to insert themselves as the endpoint to a message and then recreate / encrypt the message and send to the intended recipient. Since the keys are exchanged in the background – the users will not be aware than it was not an end to end encryption.

Most of the other 88 pages in this presentation illustrates how iMessage works under the covers, and the challenges of a third party compromise. I will give you a clue – it would be very difficult for anybody who is not Apple to compromise iMessage, but technically very easy for Apple to do.

Bottom line

Apple controls the Keys :There is nothing to imply that Apple is spying on iMessages. However there are no technical limitations that would prevent them from doing so if they were so inclined or directed to, since indirectly they control the keys.

Know your threat: If the threat you concerned about is Joe Internet Hacker, iMessage is very secure, with a very low risk of interception/decryption. However if the threat you are concerned about has a National Security Letter in their pocket, iMessage probably does not provide much security.

Update [2013 Nov 5] : A very well written analysis of Lavabit at thoughtcrime.org shows that Lavabit had a similar approach to key management – and same weakness of co-mingling the keys with the “secured” accounts on the server.

Internet Security, Security

Internet Security As a System

Leave a comment

Background

Most of us do not see our activities on the Internet as a system, and if it is a system we are not sure what that has to do with securing ourselves on the Internet. First lets look at a typical Joe Internet User in terms of the definition of system – “a set of connected things or parts forming a complex whole”. The parts are the individual services we use – GMail, Facebook, Amazon, iTunes, PayPal, Verizon and/or AT&T, etc. For each one of these we have a username and password – which may or may not be very unique. The connectivity part is the user, Joe Internet user – who is the real target of a attacker.

How you defend this type of a system is not entirely obvious, however if we flip the perspective around it may give us some insight. Specifically, how would an attacker plan to go after your accounts to their benefit?

If we assume the threat model is a high volume, Internet cyber extortionist looking for a quick return, we can characterize an attack pattern.

Phases of an Attack

A simple attack has three phases:

Compromise – This phase is where an attacker has already identified you as a target, and is probing for a weakness / vulnerability to “get inside” – compromising the system.

Mapping / Discovery – This phase is where the attacker has compromised some part of your system of services and is mapping out your other accounts / services. Since this process is essentially information gathering / compromise – it is fairly hard to detect. This information is used to plan and execute the next phase as quickly as possible.

Exploitation – This phase is where the attacker implements a plan to use the information collected to their benefit – and usually to your detriment.

An Example of a Common Attack

In this example, Joe Internet User is a typical first world Internet power user with all of the accounts listed above –  GMail, FaceBook, Amazon, iTunes, PayPal, Verizon and/or AT&T, etc..

In our first example, the attacker has been perusing Facebook and found a public profile for promising target. The status updates indicate either an iPhone/iPad/Android Tablet / Smartphone etc – indicating either a iTunes or Google Play account, or both. Other references may indicate online shopping habits – enabling the attacker to identify target accounts. Most importantly, the attacker discovers the target’s primary email address – either GMail, HotMail or Yahoo (for example). Connections to other social networks (eg Twitter, Google+, Instagram, etc) provide additional sources of personal information. At this point the attacker knows where you live, your age, family / marital status, friends, pets / kids names / ages, where you work, what you do for a living, where you went to school, and what you do for fun. All from public sources.

The next part of discovery is compromising an account. The most promising is usually the primary email account. This is due to this magical feature of every Internet service – the password recovery email address. People forget passwords and people forget usernames, but every service has an email address for password recovery. This is usually setup when the account is initially created, and forgotten shortly afterwards.

To get back to our process, the attacker makes a number of educated guesses for the password for the users primary email account – and sadly most people are still using simple passwords. Is your email password based on a birthday, names (parents, spouse, kids, pets), sports team / player, personal interests? With a one or two number appended? In any case, lets just guess that an attacker will compromise a quarter of all accounts in less than 25 guesses – and our Joe Internet User GMail account has been compromised. Where does that lead us?

The attacker is patient, and access to a primary email account is a much better way to collect more useful / personal information. One of the first things an attacker is going to do is download the user contacts and email – in case the user suspects compromise and changes the password. Most webmail services provide this feature, and it ensures that the attacker has a backup of your information. At this point we have to ask a few questions about Joe Users webmail account. Does he have a folder with his online account email? Bills, credit cards, online shopping accounts? Do the contacts have birthdays, anniversaries, even Social Security numbers? We know they have addresses, email and phone numbers. Each of these helps build data for credit card fraud. At this point this is still a discovery process, and the attacker is very careful to not touch, change or leave any clues of activity.

Exploitation is the next step and the attacker will develop a plan of attack and usually the first step is based on the accounts and stored credit cards / store credit cards. For example – is there an Amazon, Tiffanys, Macys, Sears, etc online account with an credit card saved in the online store? Is the email account tied in with a Google Play Store and a credit card? The attacker can buy phones, tablets and computers using that account. Is it tied to a Verizon, AT&T, or T-Mobile with a credit card stored in the account? Once again, the attacker can buy phones and tablets from these accounts. The first think to consider for online shopping is embedded credit card numbers. Some of these are credit cards that can be removed – but most store credit cards are automatically available on the account and cannot be removed without cancelling the credit card.

The next step of exploitation is to look for signs of illegal or incriminating information that can be used to extort something from the user. Most people know this as blackmail, and although it does not occur often – it does occur. Think about the depth and breadth of highly personal information that is in your email accounts.

Going one step beyond blackmail, attackers will sometimes “hijack” all of the accounts by changing the passwords and redirecting the recovery email address to some email account held by the attacker. Then a message is sent to the user, asking for ransom to get their accounts back. Once again – this is rare, but it does occur.

Generally the last part of exploitation is where all of this personal information gathered on Joe User, his friends, family, acquaintances etc, is used to build a persona database used to apply for credit and loans – credit fraud and what is commonly known as identity theft.

A Few Simple Steps

This example shows how attackers see the collective accounts and services of Joe Internet User as a system – with Joe User as the key connective element, and how attacking a few weaknesses provides significant opportunity to the attacker.

  1. Learn how to create Good Passwords (and use them when possible) – I get frustrated when an account service requires an 8-12 character password, with upper case, lower case, numbers and symbol. This does create a high entropy password – but is also very difficult to remember. Take a look at this xkcd panel and think about it when you create passwords.
  2. Primary Email Account – Since your primary email account is your account recovery account, this account is more critical than any other account. Choose / use a quality password and if possible use two factor authentication.
  3. Two Factor Authentication (2FA) – If the service offers two factor authentication, referred to as “2-step verification” by Google – use it. Two factor authentication does not make an account impossible to compromise, but it makes it sufficiently hard that this type of attacker will move on as soon as they discover you are using it. Google (GMail, Google Play) and WordPress both offer free 2FA for user accounts. In both cases it is based on a mobile device app – Google Authenticator
  4. Stored Credit Card Numbers / Bank Account Numbers – Carefully tradeoff the convenience of storing a credit card online in an account versus the cost if it is compromised. I recommend removing any general credit card numbers.
  5. Store Credit Accounts – Store credit accounts are usually tied right to that stores online store and cannot be removed without closing that line of credit. Attackers know this and use this to their advantage. Consider closing those lines of credit.
  6. Sanitize Contacts / Email – Audit your contacts and all of your email to see what could be deleted and clean it up. How necessary is a 5 year archive of all sent mail? If you are worried about holding onto everything – back it up before cleaning. The less information available in a compromise, the lower the risk.
  7. Sanitize Social networks / Make your profile Private – Most of the social networks now enable you to make your profile private – so only your circles / friends can see what is on your pages. In addition, content should be cleaned up to reduce your online presence. Once again, is it really necessary to have a 5 year archive of Facebook posts?
  8. Unique Passwords – DO NOT use the same password for all your accounts. DO not use a couple of passwords for all your accounts. Use unique passwords for each account. If one of you accounts is compromised, make them work for each account – don’t just give it too them.

These steps will not make your accounts bulletproof, but most attackers are opportunists and these steps will harden your accounts enough for them to move on to somebody else.

Internet Security

How to Secure Dropbox (and others) – Part 1

Leave a comment

Personal security and privacy on the Internet are often seen as lost dreams – something we sacrificed in back in the 90s without a clue. In this blog, I cannot give this back to you, but my hope is to help you take back at least some parts of your personal online security / privacy piece by piece.

Background

One of the most interesting transformations in how people use the Internet is personal data convergence. In this model, a user may have a phone, a laptop, a tablet and a desktop system. Or another particular type of user would “roost” at different computers that were convenient. Personal data convergence is where that user has some mechanism or function to access and update a personal datastore from each one of these devices – fairly transparently. This is a big deal because (when done correctly) this process renders the platform or device transparent – enabling people to more effectively do what they do.

For example – at one time everybody had a home telephone, and each one had the same basic capabilities, and the primary value of having a telephone had very little to do with the actual telephone, and everything about the function and service – how it enabled the user. This personal data convergence means that each user can have their cloud of resources follow anywhere they go, and this has resulted in a proliferation of services that offer something like this. Examples include:

  • Dropbox – a basic client / server / cloud service that provides some gigabytes of data that can be synchronized between Windows, iOS, Android, Linux, OSX and others. Premium service offers more space. Free format allows any file type. Storage is at 2GB to 5GB, depending on their promotions.
  • Box – Similar to Dropbox with fewer client types supported, but more space (with the free service), which is at 10GB at this time.
  • GDrive – The Google spin on a user-centric filestore. This was originally an extension of their online office suite, and only supports specific file types.
  • Chrome – This is not a general filestore, but a specialized synchronization where all of the personal features of Chrome are stored in the Google Cloud. This includes favorites, cached usernames / passwords, cookies, history and configuration.
  • iCloud – The Apple spin of online backup / synchronization. It synchronizes and backs up the entire Apple universe of devices, but like most things Apple, there is more left unsaid than should be. We can guess that it is better than average, but no better than it has to be. But it will work well with Apple devices and it will look good the whole time.

The Issue

Each one of these has their value add / differentiator to appeal to some specific use case, but each one of these also has a significant structural security issue. In each of these services, data is essentially unsecured within the service provider. Seriously – although several (if not all) of these service providers will make strong statements about the level of encryption they use on their SSL/TLS connections and how data is encrypted on servers with some form of disk encryption, however if the keys are held by the same service provider – it means nearly nothing. In any case, this class of service is not going away – and will only increase in size and capability – but from a basic privacy and security perspective, it is one (big) step up from public storage on the Internet.

For example, right now, today – passwords for nearly every WiFi router (that is paired with a Android device – worldwide) is stored in Google servers. As part of the account backup process, Google has been backing up WiFi settings for the last several Android versions – which means hundreds of millions of WiFi passwords worldwide. Recall that Google Streetview got into some trouble over harvesting WiFi passwords, but now they build it into the Android ecosystem – and they get the passwords with no muss or fuss.

From a personal viewpoint – I see this consolidation of my online footprint, particularly private elements like usernames, passwords, and network access as something to be very uncomfortable with.

Security Theater in the Cloud

The following articles provide an entertaining juxtaposition between real security and security theater. Both are technically correct, but have very different messages.

With that perspective, now take a look at this post from Google regarding G-Drive encryption.

Yeah. As a security guy, i have to ask the question – Google and Apple have smart guys working there, lots of them. So if this is supposed to be real security, clue me in who the threat is? Based on the fact that in both cases they control the encryption and they control the keys, so it is not protected from these vendors, insider threats, anybody who could compromise their keystores, or National Security Letters. My cynical nature whispers to me and says it is security theater.

Is there a “fix” ?

For these service providers, there is no “fix” since the unsecured nature of their services is a key part of their business model. With this level of access to your personal data and files, they can build an incredibly detailed demographic profile of you as a consumer, you as a citizen, you as a security threat, and you as a future employee for any firm willing to get / buy the data. I don’t think it comes as any surprise that even if you pay for a service, a very subtle and implicit part of the cost is giving up any claim to privacy and security for the data stored in the service. This is very much a case of broken by design (and intent).  So any talk of a privacy / security “fix” is purely subjective and and not likely to be supported by the service providers. Depending on the service provider, they may consider it a violation of their terms of service. Caveat Emptor.

We have Options

If retaining your privacy and securing your personal data matter, we basically have three options.

1) Air Gap : Don’t put private / personal data in these services. It may sound excessive – but air-gapping your personal data from the Internet is the most robust privacy control you can use.

2) File Level Encryption: Use encrypted containers on the cloud sync service. Examples include Trucrypt and Keepass.

3) Private Cloud synchronization: Drop these services for something where you – the user, controls the encryption keys. Examples include BitTorrent Sync and SharePlan.

In any case, this is only part 1, and in part 2 I will expand on the options to better secure these synchronization services.

Android, Android Security

Android 4.3 Permissions Manager

Leave a comment

For the most part, security features of iOS and Android are fairly well matched, being driven by the same threat environment and competitor feature sets.

Over the last year, one exception to that has been the User Permissions control in iOS, where the user can dynamically select to disable certain permissions to apps at the OS level. In some circles is is referred to as Middleware MAC, and the gist of it is that the user needs to have the ability to lockdown individual permissions on each application sandbox – rather than the current Android “accept all requested permissions, or don’t install”.

In practical terms, having User Permissions Management means that (for example), you as a user can block a flashlight app from having access to your contacts – even if it was installed with that permission. This is huge deal since it give the user control rather than the app developer (who you should really not trust too much).

A few of the alternative AOSP ROMs have had some implementation of this for a while – CyanogenMod for example. However, the implementation it was very involved since the AOSP launcher and process spawner (zygote) did not even look at permissions, and had no capability to deny execution or block privileges  – so some fairly deep OS hooks needed to be written to provide this capability. This level of complexity prevented easy implementation on factory OSes.

But now, good news everyone!  In Android 4.3 there are signs that the framework for such a capability (and parts of the userspace tools)are built in in the AOSP codebase. Much like the multi-user framework which started showing up two versions before it was supported, I suspect that 4.4 (kitkat) will have some limited but supported version of user level permissions management, and something beyond 4.4 will have a fully developed capability.

As it sits today, there is a user level tool available, but it is not officially supported and reports are that it has no safeties built in – so you can render an app non-functional quite easily. See the linked article below for details on how to check it out.

Android, Android Security, Linux

WhitePapers

Leave a comment

In the past I have written some whitepapers of some topical interest, and they are in MS Word / PDF format. The attached documents include:

Mobile Security-AndroidMalware-2013-Mar: General De-FUDing (FUD=fear, uncertainty and doubt) of Android Security by explaining what the real risks were and what were not real risks.

Android Hacking for Nexus7_2012-11-19-part1: Part 1 of an OReilly style manuscript that shows the user how to build and develop a custom Android image for the Nexus 7 from source (AOSP).

Android Hacking for Nexus7_2013-01-31-part2: Part 2 of an OReilly style manuscript that shows the user how to build and develop a custom Android image for the Nexus 7 from source (AOSP).

At some point in the future i will be doing an HTML render of these, and doing a refresh at the same time. Until then – this is what you get.

Pentesting

Installing / Using W3af

Leave a comment

Background

W3af is a vulnerability scanner for web applications. Arbitrarily scanning random webpages / sites without permission from the site owners could get you a visit from law enforcement of the cyber type (FBI in the US). I recently had the opportunity to scan some customer sites with this tool.

Increasing complexity is the nature of life on the Internet, and increasing complexity leads to increased flaws and security vulnerabilities. In order to “harden” their systems Internet companies often have their systems penetration tested (ie pentested). Pentesting is a multistep process that loosely follows these steps:

  1. Networking mapping: from the entry point, map (to the greatest degree possible) map out everything beyond the entry point that may be accessible to the outside attacker.
  2. Discovery / Auditing : Based on this mapping, push and probe each system for known vulnerabilities and weaknesses.
  3. Exploitation: Based on the identified weaknesses / vulnerabilities, structure an attack to exploit to validate / confirm the exposure.

W3af is a tool that automates steps 1 and 2 of this process, enabling a much more thorough scan in a short period of time. Of course like any automation, the results from the tool need to be reviewed and analyzed, since many of the results will be false positives (not real vulnerabilities).

Installation

My first attempt to install W3AF was from the Ubuntu software center, and did not have much luck with it. The current version in the repository for 12.04LTS would crash on scan every time for me. Based on reports from around the web, this is very common and can vary – but was fixable with some effort. Not wanting to create some configuration Frankenstein, I decided a better and faster way to resolution may be to go to the source. So at the W3AF homepage, the following directions were provided.

    git clone https://github.com/andresriancho/w3af.git
    cd w3af
    ./w3af_gui

Which was fairly painless worked well. however it was not complete. There were a number of dependencies identified with the first run of the gui, and a pointer to a script to install them. After setting the execute flag on the script, this worked really well, and I was able to launch the w3af gui. I ran the app from a terminal window, and was able to monitor the scrolling messages and on my first scan, a message appeared indicating that there was a failed dependancy – Python-Webkit.

Usage Notes

After installation of this, i discovered that the app would generate a nice graphical map of the website beneath the URL being scanned. Nice. In any case, like many open source projects, it can be very functional – but it has more than a few non-obvious gotchas. Of note:

  • If you setup for a number of consecutive scans, the clear data function does not appear to be 100% effective. I noticed that after two or three, the scrolling log display would sometimes stop displaying. Or the scrolling time graph on the log page would simply not be drawn, leaving a large blank space in the lower right corner. For the most part, exiting the W3AF gui app and restarting after each run seem to clear out whatever cruft was laying around.
  • In my attempt to be productive, i was configuring multiple scan configs for different targets – while it was running a long scan on a current configuration. It basically trashed the current run and no useful results were produced. So once again, exiting and restarting the app resolved whatever state it thought it was in.
  • Check your reporting / output plugin. Essentially nothing is enabled. I created a ~/w3af/reports directory to contain the results, enabled the xml, csv and html reports to point to that directory. Note – even with verbose turned off, there is a lot of data.
  • Although the app can produce a nice pictoral graph of the network (look under results / URLs tab), it does not save or provide a method to save. Use ‘screenshot’ to capture / save a region.
  • After a run is complete, save your reports off to a directory that matches the scan config – consecutive runs will overwrite the files.
  • In order to filter results in the HTML report, open it and search for “Severity: low” , “Severity: medium” or “Severity: high” to count / find issues.

Summary – W3af is fairly solid as a webapp mapper / scanner, and installs easily per the directions on w3af homepage in less than 30 minutes. It is not well suited for targeting multiple targets concurrently.

Links W3AF homepage

Linux

Ubuntu Wubi (not dead yet – but close)

Leave a comment

Ubuntu Wubi is a Windows based installer that dual boots your Windows system with the least amount of effort. It really is (was?) my favorite way to keep a backup Ubuntu image handy. The idea was that the Wubi installer would run under windows, download and install a fairly generic configuration to your system with only about three configuration decisions. It took about 30 minutes in the background and after that a reboot, and automagically it was a boot option.

However recently issues have been creeping into the mix. These currently include:

  • Ubuntu does not support Wubi past 12.04 LTS
  • Wubi does not support Windows 8
  • Trying to upgrade past 12.04 inside the image may not work (it did not for me), requiring a scrub and re-build of my install

Remember – Wubi enabled me to install a dual boot Ubuntu image in the background in about 30 minutes – so I could be doing something useful the entire time. What alternative gives me that?

Much like Google Reader, it is really disappointing to see something really useful fade away.

Wubi Installer Link

Pentesting

Pentesting: Day 1

Leave a comment

Occasionally I get the opportunity to do something interesting, and today was one of those days. As part of a customer engagement, we are scanning parts of their public interfaces for vulnerabilities. We are stopping short of actual pen-testing, but are going through the discovery and audit phases to identify vulnerabilities. Last week I had identified two tools I wanted to look at; W3AF and OpenVAS. A critical point – the services we are scanning are web apps / web services. Today was a big day because the customer provided me with an email indicating that i was authorized to scan a certain set of their addresses from a specific address of mine. Not quite a Get Out of Jail Card, but close. This means I can go in with my scanner and be as noisy as I want to be without being too concerned about the FBI showing up at my door.

In any case, I installed and configured both of them today from respective sources (ie http://w3af.org/ and http://www.openvas.org/). Initial impressions are that OpenVAS looks and acts like it could support a continuous monitoring program on a network in a fairly automated manner (post setup), and could scale well. It provided a broad range of network port scanning capabilities against a large number of configured targets – all individually configurable. The W3AF application on the other hand is focused on web-apps vulnerabilities, and works best against a single URL / IP address or target.

Regarding the results, the OpenVAS was very fast (i.e. less than 5 minutes) to scan the target but produced no significant vulnerabilities. This can be contrasted with W3AF which took about an hour to run the OWASP Top 10 Scan and produced a 100+ low / moderate priority findings.

Bottom line – If you considering internal continuous monitoring for your network OpenVAS has a low pain threshold to implement. If on the other hand you are looking to protect your Internet based webapp – regular scans with W3AF is a better tool.