At this year's 44Con conference (held in London) Daniel and I introduced a project we had been working on for the past few months. Snoopy, a distributed tracking and profiling framework, allowed us to perform some pretty interesting tracking and profiling of mobile users through the use of WiFi. The talk was well received (going on what people said afterwards) by those attending the conference and it was great to see so many others as excited about this as we have been.

In addition to the research, we both took a different approach to the presentation itself. A 'no bullet points' approach was decided upon, so the slides themselves won't be that revealing. Using Steve Jobs as our inspiration, we wanted to bring back the fun to technical conferences, and our presentation hopefully represented that. As I type this, I have been reliably informed that the DVD, and subsequent videos of the talk, is being mastered and will be ready shortly. Once we have it, we will update this blog post. In the meantime, below is a description of the project.

Background

There have been recent initiatives from numerous governments to legalise the monitoring of citizens' Internet based communications (web sites visited, emails, social media) under the guise of anti-terrorism. Several private organisations have developed technologies claiming to facilitate the analysis of collected data with the goal of identifying undesirable activities. Whether such technologies are used to identify such activities, or rather to profile all citizens, is open to debate. Budgets, technical resources, and PhD level staff are plentiful in this sphere.

Snoopy

The above inspired the goal of the Snoopy project: with the limited time and resources of a few technical minds could we create our own distributed tracking and data interception framework with functionality for simple analysis of collected data? Rather than terrorist-hunting, we would perform simple tracking and real-time + historical profiling of devices and the people who own them. It is perhaps worth mentioning at this point that Snoopy is compromised of various existing technologies combined into one distributed framework.

"Snoopy is a distributed tracking and profiling framework."

Below is a diagram of the Snoopy architecture, which I'll elaborate on:

1. Distributed?

Snoopy runs client side code on any Linux device that has support for wireless monitor mode / packet injection. We call these "drones" due to their optimal nature of being small, inconspicuous, and disposable. Examples of drones we used include the Nokia N900, Alfa R36 router, Sheeva plug, and the RaspberryPi. Numerous drones can be deployed over an area (say 50 all over London) and each device will upload its data to a central server.

2. WiFi?

A large number of people leave their WiFi on. Even security savvy folk; for example at BlackHat I observed >5,000 devices with their WiFi on. As per the RFC documentation (i.e. not down to individual vendors) client devices send out 'probe requests' looking for networks that the devices have previously connected to (and the user chose to save). The reason for this appears to be two fold; (i) to find hidden APs (not broadcasting beacons) and (ii) to aid quick transition when moving between APs with the same name (e.g. if you have 50 APs in your organisation with the same name). Fire up a terminal and bang out this command to see these probe requests:

tshark -n -i mon0 subtype probereq

(where mon0 is your wireless device, in monitor mode)

2. Tracking?

Each Snoopy drone collects every observed probe-request, and uploads it to a central server (timestamp, client MAC, SSID, GPS coordinates, and signal strength). On the server side client observations are grouped into 'proximity sessions' - i.e device 00:11:22:33:44:55 was sending probes from 11:15 until 11:45, and therefore we can infer was within proximity to that particular drone during that time.

We now know that this device (and therefore its human) were at a certain location at a certain time. Given enough monitoring stations running over enough time, we can track devices/humans based on this information.

3. Passive Profiling?

We can profile device owners via the network SSIDs in the captured probe requests. This can be done in two ways; simple analysis, and geo-locating.

Simple analysis could be along the lines of "Hmm, you've previously connected to hooters, mcdonalds_wifi, and elCheapoAirlines_wifi - you must be an average Joe" vs "Hmm, you've previously connected to "BA_firstclass, ExpensiveResataurant_wifi, etc - you must be a high roller".

Of more interest, we can potentially geo-locate network SSIDs to GPS coordinates via services like Wigle (whose database is populated via wardriving), and then from GPS coordinates to street address and street view photographs via Google. What's interesting here is that as security folk we've been telling users for years that picking unique SSIDs when using WPA[2] is a "good thing" because the SSID is used as a salt. A side-effect of this is that geo-locating your unique networks becomes much easier. Also, we can typically instantly tell where you work and where you live based on the network name (e.g BTBusinessHub-AB12 vs BTHomeHub-FG12).

The result - you walk past a drone, and I get a street view photograph of where you live, work and play.

4. Rogue Access Points, Data Interception, MITM attacks?

Snoopy drones have the ability to bring up rogue access points. That is to say, if your device is probing for "Starbucks", we'll pretend to be Starbucks, and your device will connect. This is not new, and dates back to Karma in 2005. The attack may have been ahead of its time, due to the far fewer number of wireless devices. Given that every man and his dog now has a WiFi enabled smartphone the attack is much more relevant.

Snoopy differentiates itself with its rogue access points in the way data is routed. Your typical Pineapple, Silica, or various other products store all intercepted data locally, and mangles data locally too. Snoopy drones route all traffic via an OpenVPN connection to a central server. This has several implications:

(i) We can observe traffic from *all* drones in the field at one point on the server. (ii) Any traffic manipulation needs only be done on the server, and not once per drone. (iii) Since each Drone hands out its own DHCP range, when observing network traffic on the server we see the source IP address of the connected clients (resulting in a unique mapping of MAC <-> IP <-> network traffic). (iv) Due to the nature of the connection, the server can directly access the client devices. We could therefore run nmap, Metasploit, etc directly from the server, targeting the client devices. This is a much more desirable approach as compared to running such 'heavy' software on the Drone (like the Pineapple, pr Pwnphone/plug would). (v) Due to the Drone not storing data or malicious tools locally, there is little harm if the device is stolen, or captured by an adversary.

On the Snoopy server, the following is deployed with respect to web traffic:

(i) Transparent Squid server - logs IP, websites, domains, and cookies to a database (ii) sslstrip - transparently hijacks HTTP traffic and prevent HTTPS upgrade by watching for HTTPS links and redirecting. It then maps those links into either look-alike HTTP links or homograph-similar HTTPS links. All credentials are logged to the database (thanks Ian & Junaid). (iii) mitmproxy.py - allows for arbitary code injection, as well as the use of self-signed SSL certificates. By default we inject some JavaScipt which profiles the browser to discern the browser version, what plugins are installed, etc (thanks Willem).

Additionally, a traffic analysis component extracts and reassembles files. e.g. PDFs, VOiP calls, etc. (thanks Ian).

5. Higher Level Profiling? Given that we can intercept network traffic (and have clients' cookies/credentials/browsing habbits/etc) we can extract useful information via social media APIs. For example, we could retrieve all Facebook friends, or Twitter followers.

6. Data Visualization and Exploration? Snoopy has two interfaces on the server; a web interface (thanks Walter), and Maltego transforms.

-The Web Interface The web interface allows basic data exploration, as well as mapping. The mapping part is the most interesting - it displays the position of Snoopy Drones (and client devices within proximity) over time. This is depicted below:

-Maltego Maltego Radium has recently been released; and it is one awesome piece of kit for data exploration and visualisation.What's great about the Radium release is that you can combine multiple transforms together into 'machines'. A few example transformations were created, to demonstrate:

1. Devices Observed at both 44Con and BlackHat Vegas Here we depict devices that were observed at both 44Con and BlackHat Las Vegas, as well as the SSIDs they probed for.

2. Devices at 44Con, pruned Here we look at all devices and the SSIDs they probed for at 44Con. The pruning consisted of removing all SSIDs that only one client was looking for, or those for which more than 20 were probing for. This could reveal 'relationship' SSIDs. For example, if several people from the same company were attending- they could all be looking for their work SSID. In this case, we noticed the '44Con crew' network being quite popular. To further illustrate Snoopy we 'targeted' these poor chaps- figuring out where they live, as well as their Facebook friends (pulled from intercepted network traffic*).

Snoopy Field Experiment

We collected broadcast probe requests to create two main datasets. I collected data at BlackHat Vegas, and four of us sat in various London underground stations with Snoopy drones running for 2 hours. Furthermore, I sat at King's Cross station for 13 hours (!?) collecting data. Of course it may have made more sense to just deploy an unattended Sheeva plug, or hide a device with a large battery pack - but that could've resulted in trouble with the law (if spotted on CCTV). I present several graphs depicting the outcome from these trials:

The pi chart below depicts the proportion of observed devices per vendor, from the total sample of 77,498 devices. It is interesting to see Apple's dominance. pi_chart

The barchart below depicts the average number of broadcast SSIDs from a random sample of 100 devices per vendor (standard deviation bards need to be added - it was quite a spread).

The barchart below depicts my day sitting at King's Cross station. The horizontal axis depicts chunks of time per hour, and the vertical access number of unique device observations. We clearly see the rush hours.

Potential Use

What could be done with Snoopy? There are likely legal, borderline, and illegal activities. Such is the case with any technology.

Legal -Collecting anonymized statistics on thoroughfare. For example, Transport for London could deploy these devices at every London underground to get statistics on peak human traffic. This would allow them to deploy more staff, or open more pathways, etc. Such data over the period of months and years would likely be of use for future planning. -Penetration testers targeting clients to demonstrate the WiFi threat.

Borderline -This type of technology could likely appeal to advertisers. For example, a reseller of a certain brand of jeans may note that persons who prefer certain technologies (e.g. Apple) frequent certain locations. -Companies could deploy Drones in one of each of their establishments (supermarkets, nightclubs, etc) to monitor user preference. E.g. a observing a migration of customers from one establishment to another after the deployment of certain incentives (e.g. promotions, new layout). -Imagine the Government deploying hundreds of Drones all over a city, and then having field agents with mobile Drones in their pockets. This could be a novel way to track down or follow criminals. The other side of the coin of course being that they track all of us...

Illegal -Let's pretend we want to target David Beckham. We could attend several public events at which David is attending (Drone in pocket), ensuring we are within reasonable proximity to him. We would then look for overlap of commonly observed devices over time at all of these functions. Once we get down to one device observed via this intersection, we could assume the device belongs to David. Perhaps at this point we could bring up a rogue access point that only targets his device, and proceed maliciously from there. Or just satisfy ourselves by geolocating places he frequents. -Botnet infections, malware distribution. That doesn't sound very nice. Snoopy drones could be used to infect users' devices, either by injection malicious web traffic, or firing exploits from the Snoopy server at devices. -Unsolicited advertising. Imagine browsing the web, and an unscrupulous 3rd party injects viagra adverts at the top of every visited page?

---

Similar tools

Immunity's Stalker and Silica Hubert's iSniff GPS

Snoopy in the Press

Risky Biz Podcast Naked Scientist Podcast(transcript) The Register Fierce Broadband Wireless

***FAQ***

Q. But I use WPA2 at home, you can't hack me! A. True - if I pretend to be a WPA[2] network association it will fail. However, I bet your device is probing for at least one open network, and when I pretend to be that one I'll get you.

Q. I use Apple/Android/Foobar - I'm safe! A. This attack is not dependent on device/manufacture. It's a function of the WiFi specification. The vast majority of observed devices were in fact Apple (>75%).

Q. How can I protect myself? A. Turn off your WiFi when you l leave home/work. Be cautions about using it in public places too - especially on open networks (like Starbucks). A. On Android and on your desktop/laptop you can selectively remove SSIDs from your saved list. As for iPhones there doesn't seem to be option - please correct me if I'm wrong? A. It'd be great to write an application for iPhone/Android that turns off probe-requests, and will only send them if a beacon from a known network name is received.

Q. Your research is dated and has been done before! A. Some of the individual components, perhaps. Having them strung together in our distributed configuration is new (AFAIK). Also, some original ideas where unfortunately published first; as often happens with these things.

Q. But I turn off WiFi, you'll never get me! A. It was interesting to note how many people actually leave WiFi on. e.g. 30,000 people at a single London station during one day. WiFi is only one avenue of attack, look out for the next release using Bluetooth, GSM, NFC, etc :P

Q. You're doing illegal things and you're going to jail! A. As mentioned earlier, the broadcast nature of probe-requests means no laws (in the UK) are being broken. Furthermore, I spoke to a BT Engineer at 44Con, and he told me that there's no copyright on SSID names - i.e. there's nothing illegal about pretending to be "BTOpenzone" or "SkyHome-AFA1". However, I suspect at the point where you start monitoring/modifying network traffic you may get in trouble. Interesting to note that in the USA a judge ruled that data interception on an open network is not illegal.

Q. But I run iOS 5/6 and they say this is fixed!! A. Mark Wuergler of Immunity, Inc did find a flaw whereby iOS devices leaked info about the last 3 networks they had connected to. The BSSID was included in ARP requests, which meant anyone sniffing the traffic originating from that device would be privy to the addresses. Snoopy only looks at broadcast SSIDs at this stage - and so this fix is unrelated. We haven't done any tests with the latest iOS, but will update the blog when we have done so.

Q. I want Snoopy! A. I'm working on it. Currently tidying up code, writing documentation, etc. Soon :-)

Brilliant, the client has decided to implement their own CMS and you've found a variable that's vulnerable to SQL injection. Starting up your favourite SQL exploitation tool, you upload a suitable web shell and fire up the browser. In an instant, you control that server, but do you really own the box?

Looking back at the major hacks of the last 18 months, attackers used a variety of techniques to obtain sensitive information. For the RSA hack, social engineering was used, allegedly consisting of a malicious Excel spreadsheet sent from a web master at a recruitment website. Once loaded, Poison Ivy was dropped on the host and the games began. Attackers started recon exercises, pivoting between hosts and finally exfiltrated the data (the rest is well-known and publicised). In the case of HBGary, attackers compromised their systems using a similar approach as the RSA attackers did: target an individual using social engineering using an earlier toehold to expand to a foothold. These types of attackers might have a fancy new name (Advanced Persistent Threats) but at the end of the day, they are using techniques that have been around for a while.

Owning a single host isn't the end of the journey, it's just the start.

At this year's 44Con, students will have the chance to learn how to take their offensive skills to the next level. Think of it as APT-style assessments.

Hacking By Numbers - BlackOps Edition will teach the next stage of the attack: lateral movement within a network, pivoting, and going after business relevant systems and data. Often, the juicier targets are buried deep inside the network, requiring complex tunnelling, evasion so as to not trigger alerts and finally, when you've accessed a target, ways to exfiltrate the data (spreadsheets via Facebook direct message, scp over a DNS tunnel, this can be fun).

The course looks at key areas of post-exploitation, and covers:

• Working with big data on assessments
• The difference between exploiting and owning a system
• OSINT
• Effective ways to tunnel, pivot and exfiltrate data without being noticed
• Owning systems using client-side attacks and social engineering
• Privilege escalation

At the end of the course, students will participate in a final exercise set in a semi-real world environment, where they will need to used what they've learned compromise a target organisation, escalate privileges and tunnel sensitive data out from the network.

This course is aimed at making you think differently. It's offensive security at its best. To join this course, visit our booking page.

Security policies are necessary, but their focus is to the detriment of more important security tasks. If auditors had looked for trivial SQL injection on a companies front-page as hard as they have checked for security polices, then maybe our industry would be in a better place. I want to make this go away, I want to help you tick the box so you can focus on the real work. If you just want the "tool" skip to the end.

A year and a half ago, SensePost started offering "build it" rather than "break it" consulting services, we wanted to focus on technical, high-quality advisory work. However, by far the most frequently "consulting" request we've seen has been asking for security policies. Either a company approaches us looking for them explicitly or they want them bolted on to other work. The gut feel I've picked up over the years is that if someone is asking you to develop security policies for them, then either they're starting on security at the behest of some external or compliance requirement or they're hoping that this is the first step in an information security program. (Obviously, I can't put everything into the same bucket, but I'm talking generally) Both are rational reasons to want to get your information security policies sorted, but getting outside consultants to spend even a week's worth of time developing them for you, is time that could be better spent in my opinion. My reasons for this are two-fold:

• If you're starting a security program, then you have a lot to learn and possibly a lot of convincing of senior management to do. Something like an internal penetration test (not that I'm advocating this specifically instead of policy) will give you far more insight into the security of your environment and a lot more "red ink" that can be used to highlight the risk to the "higher ups".
• Security policies don't "do" anything. They are a representation of management's intention and agreements around security controls, which in the best case, provide a "cover my ass" defense if an employee takes you to task for intercepting their e-mails or something similar. The policies need to be used to derive actual controls, and are not controls in themselves.

Instead, we too often end up in a world where security policies, rather than good security, is the end goal while new technologies keep us amused developing new ones (mobile policies, social media policies, data leakage policies etc.)

Saying all of this is fine, but it doesn't make the auditors stop asking, and it doesn't put a green box or tick in the ISO/PCI/CoBIT/HIPAA/SOX policies checkbox. Previously, I've pointed people at existing policy repositories, where sample policies can be downloaded and modified to suit their need. Sites such as CSOOnline or PacketSource have links to some policies, but by far the most comprehensive source of free security policy templates is SANS. The problem is people seem to look at these, think it looks like work, and move on to a consultancy that's happy to charge for a month's worth of time. Even when you don't, the policies are buried in sub-pages that don't always make sense (for example, why is the Acceptable Use Policy put under "computer security"), even then several of them are only available in PDF form (hence not editable), even though they are explicitly written as modifiable templates. What I did was to go through all of these pages, download the documents, convert them into relevant formats and categorise them into a single view in a spreadsheet with hyperlinks to the documents. I've also included their guidance documents on how to write good sec policies, and ISO 27001-linked policy roadmaps. I haven't modified any of the actual content of the documents, and those retain their original copyright. I'm not trying to claim any credit for others' hard work, merely make the stuff a little more accessible.

You can download the index and documents HERE.

In future, I hope to add more "good" policies (a few of the SANS policies aren't wonderful), and also look into expanding into security standards (ala CIS Security) in the future. If necessary, take this to a consultancy, and ask them to spend some time making these specific to your organisation and way of doing things, but please, if you aren't getting the basics right, don't focus on these. In the meantime, if you're looking for information security policies to go away, so you can get on with the bigger problems organisations, and our industry in general are facing, then this should be a useful tool.

The text that follows is a short statement I prepared for the press ahead of my presentation at the 'The International Conference on Cyber Conflict' (http://www.ccdcoe.org/ICCC/) in Tallinn, Estonia. It felt like I had very mixed response, so I'd be interested to hear what others think…

My background and context

Any opinion can only be understood if you also understand its context. Therefore, in order to understand the thinking that follows, you also have to understand my perspective. Three aspects of my context effect my thinking here:

1. My business is Attack and Penetration testing. I have little insight or experience beyond that narrow field and therefore my view will be skewed by my professional experiences.
2. Our business is primarily based in South Africa. Hence much of my perspective is formed by making my living in a developing country.
3. I am no expert on international policy. Hence my hope is that my views can help to inform policy. I'm not attempting to dictate policy in any way.

It should be noted that these are the perspectives I was asked to bring to the event.

In the piece that follows I will make 5 basic hypothesis, namely:

1. Information warfare is real
2. Information warfare is asymmetrical
3. Countries like South Africa can't defend themselves
4. Neither can other countries
5. This reality must surely impact cyber policies world-wide

Information warfare is real

My first point is that 'information warfare' or 'cyber warfare' (by some definition) is real and is happening already today. Certainly, even if we are not seeing actual 'battles' being fought, the so-called 'military digital complex' described by Dr Dan Geer exists and is busy accumulating skills, technology and cyber territory as we speak. If the general public was not aware of this already, then this fact became blatantly clear from the email correspondence of information security firms 'HBGary', 'Palantir' and 'Endgame Solutions', which recently got publicly released after HBGary's systems were allegedly breached by the hacker collective known as 'Anonymous'.

Information warfare is asymmetrical

My next point is that information warfare is asymmetrical, with the cards stacked massively in favor of the attacker. Those of us doing so-called 'red team' work have always argued that the defender has to be successful all of the time, while the attacker only has to be successful once, which suggests that a successful compromise of any given target is always just a matter of time and money.

This fact is graphically illustrated by the apparent success of the Stuxnet attack against the the Iranian nuclear enrichment program at Natanz. By all accounts Stuxnet was a devastatingly successful attack launched by one nation or group of nations against key national infrastructure of another nation. It bypassed all reasonable security controls and could easily have been more destructive, potentially even causing loss of life. All that at the measly price of between $ 500,000 and $ 2 million - apparently less than what the US airforce currently spends in a day.

When it comes to securing an entire country against a well-funded and well-equipped adversary this is even more true, because governments have a dependency on systems and infrastructure for banking, administration, utilities, industry and communications that they do not control. Security in many of these industries is still very poor and, even if governments did apply themselves to improving security as a matter of national policy, I would argue that it may already be too late and that many systems are already compromised by malicious software, some of which will be too sophisticated to detect and remove on the scale required.

A simple analogy for what I'm saying here can be seen in the recent Wikileaks saga. We tend to think of the Wikileaks saga in terms of Julian Assange and the 'leak', but really what we should be considering is the fact that over 500 thousand people apparently had access to the so-called 'secret' documents that Assange ultimately released to the world. Its a problem of scope: How can a government hope to protect something that is being accessed by half a million people, and how can we begin to believe that, with that level of exposure, the security of SIPRNET hadn't already been breached multiple times before?

Now you can see why information warfare is asymmetrical and why it is almost impossible for an entire country to defend itself. This is the core element of my hypothesis this week.

Countries like South Africa can't hope to defend themselves

If its true that information warfare is real, and that its asymmetrical as I've argued, then where does that leave countries like my home, South Africa? South Africa is a typical developing country: Situated at the very tip of Africa, the country is a greedy adopter of new technologies like mobile telephony, nuclear power, e-government and online banking that support growth and upliftment of our people, but plagued by HIV/AIDS, crime, high unemployment and poor systems of education, we don't have the skills or financial resources to invest in the kind of security we would need to even begin to defend ourselves. South Africa is "connected", but not "protected".

If my government were to approach me and ask: "How can we defend ourselves in this new realm of cyber warfare?" I would have to answer: "We can't". So what option is left to South Africa? Either we can ignore the problem and hope it goes away, or possibly we can develop our own offensive capability to act as a deterrent to would-be attackers. I'm not sure whether this strategy would work, but I do believe that it would at least be feasible to implement, which a defensive strategy is ultimately not. If you accept our previous assertion that a capability like Stuxnet could be developed for just a few million dollars, then even South Africa could afford to get in on the cyber warfare game and potentially strike a few retaliatory blows against its enemies or would-be enemies and thereby maintain a kind of uncomfortable peace. Rather than developing such a capability, we could acquire one commercially, or possibly join a treaty to obtain one, but it strikes me as basically the same thing.

But neither can other countries

But here's the twist: What's true for small, developing countries like South Africa is actually also true for all countries. The size of your country does not fundamentally alter the asymmetry of the equation: The attacker still has the advantage. One could even argue that the bigger your country, and the more connected your systems are, the more vulnerable you are to attack. If this argument is true, that means almost all countries will be presented with the same lack of strategic options for cyber warfare that South Africa has.

So where does it all go from here?

Thus far I have argued that we are (finally) seeing the dawn of a new cyber battle space and that in this new battle the odds massively favor the attacker. I've argued that information and information systems are simply too large, too complex and too inter-connected to defend, and that incidents like Stuxnet and Wikileaks will therefore, inevitably, become more commonplace. I've also suggested that this is probably just the tip of the iceberg.

I've argued that this new reality poses a real national-security challenge to small and emerging countries like South Africa who are 'connected' but can never really be sufficiently 'protected' to defend themselves against a well funded adversary. I surmised that this is true (to a greater or lesser extent) for all countries, no matter how large or powerful.

If this analysis is accurate then it is my opinion that countries have two options going forward. Now, I am no military or political scientist so my domain of expertise is being severely stretched here, but the two options I see are:

• Cyber neutrality and information freedom

or

• A cyber arms race and Mutually Assured Destruction

In the 1st option governments can accept that information and information systems cannot be defended against all threats and endeavor to shape local and international affairs in such a way that conflict is avoided, there are no secrets, and there is shared benefit in keeping their information systems alive and connected to the rest of the world.

I love this view of the future as it resonates deeply with the original hacker ethos in which I was 'raised', but I have to confess that I struggle to imagine it being real.

In the second model countries will endeavor to defend themselves by building deterrents - tools of mass cyber destruction aimed at their enemies with the threat of destructive digital force. As history has shown us during the Cold War it seems to me that this approach will ultimately reach a kind of digital stand-off where no single country can afford to unleash its weapons for fear of also destroying itself and the conflict will be reduced to an endless series of spy-vs-spy intrigues and counter-intrigues that will play off in the computers of every government, business, school and even home in the world.

There may be a third option, but if there is I fail to see it. One thing is clear: Unless governments, NGOs, thinkers like Tom Wingfield and other leaders act quickly to highlight and address these challenges then history will take its inevitable course and my colleagues and me will soon all be wearing uniforms and working for the military.

Thank you.

In my previous role working as a security manager for a large retailer, I developed some password tools for various purposes, primarily to help non-security people with some of the basics. I licensed them under the GPL, and I think it's about time they saw the light of day.

There are a couple of tools, which I will explain below. They're all written in JavaScript, primarily because it is cross-platform, but can be centrally hosted. They all work in Firefox and Internet Explorer, although the automatic copy to clipboard functionality of the service desk tool is IE only.

The intention is for the tools to be placed into your organisation's intranet somewhere. I found they came in much use, allowing me to reference a specific tool and setting rather than esoteric password theory in documents. For example, security standards documents would say "Service account passwords should either be generated by the password generator set to the service account setting, or be rated as "very strong" by the password strength checker", which is far more practical than quoting a list of password rules.

Being centrally hosted also allows updates to be made immediately in the case of a policy change, new common password addition, or bug. This also allowed web logs to provide an audit trail of who was using the tools. Particularly useful in the case of monitoring service desk activity e.g. If the service desk records 100 password resets, and the tool only saw 10 hits, you know something's up.

If you're a tactile learner, you can grab them here.

Password Strength Checker

This tool was written in response to the poor attempts at password strength checkers seen on many sites. They do basic checks for upper, lower-case characters and numbers. This allows passwords like "Password1" to be marked as "strong." Primarily based on Tyler Atkins' entropy and common word checker, I put together a more advanced utility. This will check the chosen password for:

• Length (over 8 characters)
• Character sets (lowercase, uppercase, numbers, special characters)
• Frequency (checks for common sets of characters e.g. "u" following "q", biased to English)
• Common Words (checks that common words aren't used e.g. Password1)

I've added a progress bar from Gerd Riesselmann, and a key for guidance. I've also eased the password strength requirements to better fit reasonable corporate password policies. These can be easily modified in the code though.

There are two versions provided, one which displays the results of the entropy calculations, and one which does not (user's rarely care).

Password Generators

There are three password generators, each with a different audience in mind.

Full Password Generator

The full password generator is the most complex and has a number of features:

• Generate random passwords of varying complexity based on a "usage" selector such as "user", "administrator" or "service account". These match up to the complexity key in the strength checker.
• Generate lists of passwords to be used as distributed One-Time-Password lists. This is useful if passwords are regularly required between two parties to avoid using a static password. The list can be delivered via an alternative medium than the data being transmitted, and an agreed rotation period set up, such as a new password to be used "every day" or "every week".
• Create a NATO alphabet version of the password for speaking over the phone with the "will be spoken" option

The actual password generation code was courtesy of the no-longer-available CryptoMX tools, and the NATO alphabet conversion code was courtesy of L. Bower.

Service Desk Password Generators

The service desk password generators were created to help the service desk stop resetting everyone's password to the same thing. It's one of the most pervasive security problems in any organisation, the service desk are told to reset passwords to some common password like "abc123", "Password<x>" or "<username>". Most user's know it, and if you do ever investigate service desk password resets, will find some serious abuses going on. This tool is a quick and dirty way to provide more reasonable alternatives for the service desk to use.

It's basic features are:

• A very simple interface and instructions
• A basic and somewhat unique password is generated
• A "pronounceable" version of the password is created in the NATO alphabet for speaking over the phone
• The password is copied to the clipboard (IE only) for pasting into whatever reset tool is in use

There are two versions, the first generates a strong random password, and the second uses one of a list of weak base words, with random numbers put on the end. The second was created after push back from the service desk agents saying that user's were complaining about the random passwords. I don't like the second version, because it is still fairly predictable, and someone internally could pull out the passwords and create a simple password list to feed to any number of tools. If you are going to use the second version, please use your own list of words, ideally several thousand to increase the entropy. The current list was created by taking the top 500 6-digit words from the Unix English (en) dictionary, and removing complex ones.

These tools where originally written when I was an employee of Deloitte South Africa, and while necessarily under the GPL due to included code, are still published here with permission of them. They have however, been updated since then on SensePost's coin.