Wednesday, 4 November 2009

Cryptography vs Moores Law

All cryptographic algorithms are breakable (with the exception of a one-time pad that is longer than the data to be encrypted)

The type of algorithm, key length, and validity of the implementation are all important factors as to how easy a cryptosystem is to break.

A key component of the way cryptography keeps data secure, is the vast computational effort required to break the algorithm or brute force the keys.

This computational effort is measured in millions, billions, or trillions of years (etc) I often see literature quoting strength in "how many billions of years it would take to break". However, when calculating the effectiveness of algorithms and key lengths it is VERY important to consider other factors, such as Moore’s Law.

Moore’s Law
Moore’s law basically states that the number of transistors you can place on a substrate doubles every two years. This can result in a doubling of processing power approximately every 18 months.

This is an exponential, and exponentials have an extremely powerful effect over the short term.

Some basic calculations
So, if an algorithm will take a billion years to break, on a single computer with today’s technology, and you start today, but upgrade your technology every 18 months, how long will it take?

Only about 45 years

Let me say that again, the cryptographers say a billion years, I say 45; based on improvements in computer technology we will all seen in the home. It's a big difference, but I may not be around in 45 years, so what else can make a difference?

If you are running a botnet of 100,000 machines and your users are swapping out their own technology (which on average doubles the processing power every 18 months)? = About 20 years

And your botnet doubles in size every 1.5 years = About 11 years

And if in addition to the above, flaws discovered in algorithms and implementations on average half the processing requirement every 1.5 years = About 9 years

So much for a billion years! What are the solutions?

Increase key lengths regularly, fix implementation flaws, deploy new cryptographic algorithms as they become available - and kill the botnets.

Friday, 30 October 2009

Botnets and distributed cracking

I've read and seen quite a few articles on botnets, and botnet culture.

Most describe the various business models; i.e. the criminal economics of running a botnet, such as making cash from spamming, DDoS, Ad-clicking, Scareware, key-logging and account stealing, hosting warez, and selling or renting botnets.

So, plenty of ways to make a few quid - if you have no morals.

However, there must be other more challenging things that can be achieved with a botnet, especially the larger ones with 100,000+ PCs.

I remember a good few years ago the SETI@home project where anybody with an internet-connected PC could participate by running a free program that downloads and analyzes radio telescope data to look for "intelligent" signals from space.

Basically this was an early trial of distributed computing using an opt-in botnet (not all botnets are bad)

Anyway, it has harnessed a massive amount of computing power over the years. Since its launch on May 17, 1999, five million people have contributed and the project has logged over two million years of computing time.

There are many other projects that have followed a similar model for other computations and you can now volunteer the idle time on your computer (Windows, Mac, or Linux) to; cure diseases, study global warming, discover pulsars, and many other types of scientific research.

So, back to the illegal botnets:

I can think of lots of calculations that could be done millions of times faster with the distributed power of a botnet; brute-force login attempts, hash cracking, forging SSL certs and cryptanalysis to name but a few. Its quite a scary notion for e-commerce.

Food for thought.

Wednesday, 28 October 2009

Using Nmap as a vulnerability scanner

All good hackers know nmap; the popular and highly functional port scanner. However, one thing you may have overlooked, is some of the newer functionality such as NSE.

It like to remind people, when discussing Hacking techniques, to remember that your actions are your Karma, and you will reap the results of your Karma. Please be an Ethical Hacker.

The Nmap Scripting Engine (NSE) was introduced with the release of nmap 4.2, and adds powerful functionality, such as brute force attacks, vulnerability scanning and much more.

Lets take a look at one example.

First check your version is up to it
(I'm using backtrack 4, so it's all good ;o)
nmap -V

Nmap version 5.21 ( )

Looks fine, so take a look in "/usr/share/nmap/scripts", and you will see a whole batch of scripts.

Picking one at random, lets look at robots.txt.nse

If you do a "more robots.txt.nse" you will find more information, but a simple usage could be something like:

nmap --script robots.txt.nse -p80

Starting Nmap 5.21 ( ) at 2010-06-03 17:01 BST
NSE: Script Scanning completed.
Nmap scan report for (
Host is up (0.037s latency).
80/tcp open  http
| robots.txt: has 15 disallowed entries
| /cgi /iaweb/ /cpc/vision/ /cpc/eps/
| /cpc/archive/ /cpc/dia/ /cpc/ecs/ /cpc/fcs/ /cpc/gif/
|_/cpc/OptContent/ /cpc/pix/ /cpc/sound/ /cpc/feature/

Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds

Which would be pretty handy if you were looking for areas on a webserver that the owner doesn't want Google to index, and of course you could easily scan a large range of hosts.

You can try some other examples for yourself of course.

Try this for example, which runs all of the relevant scripts, on a host, or range of hosts (based on open ports):

nmap --script all ipaddressrange

This is very useful for vulnerability scanning and could help identify holes in your server patching processes.

Saturday, 24 October 2009

IT Security qualifications

I signed up and am studying for the CISM exam on the 12th of December 09.

This is another string to add to my bow as I passed the CISSP back in September. CISM Is more focused on the management of IT Security, rather than technical details.

It would be nice to have both though.

Between now and then I have the 2nd half of PRINCE2 Project Management (PRINCE2 Practitioner) to do, in November, so that should keep me busy.

Also, in the new year I am looking forward to getting a bit more hands on with OSCP and CEH

Looks like OSCP is pretty tough, CEH should be relatively easy compared to OSCP.

Meanwhile I've been playing with this in my spare time, which is a good resource for learning about Metasploit.