Hacking 101
Tools of Mass Destruction
Lecture 3
"ITOD - Internet Tool of Doom"
Alec Muffett

Are we sitting comfortably?

Then I shall begin.

A few months ago, I was watching some consumer-information type programme on T.V - Here And Now, Watchdog - something like that.

The main item on the program was an expose' on confidence trickery - specifically in the hundreds of cases of old-age pensioners (senior citizens, crumblies - call them what you will) who were being approached in their homes by thugs who would demand money from them for work that had never been solicited, or on behalf of the local council, or gas board or water board, and so on...

I was shocked. Appalled. Aghast, even.

How could the BBC be so utterly irresponsible, I wondered?

How could their programmes editor be so completely thoughtless as to air a program like this, which would certainly plant the idea of similar shenanigans in the minds of Britain's youth.

Thousands, perhaps millions of adolescents with a desire to make fast cash might have seen that program and then gone out and done the same for themselves, preying on the weaknesses of our most vulnerable members of society.

[START RANTING]

From this premise, it seems obvious to me that we need much tighter control on the media, to prevent further instances of this occuring - where today's youth will be corrupted by ideas fed to them through mainstream communications media and, thereby turn against society, with increasing crime rates and greater costs for law enforcement, causing higher taxes...

[DRAMATIC PAUSE]

Of course, this is all bullshit.

Yes, it's true that I saw such a program, and yes, I was shocked.

However what I was shocked by was that it was occuring - even that this sort of crime could occur at all. Through my own naievity, perhaps, I hadn't thought of this as a possible problem which could impact people I know and love.

The concept had never crossed my peaceful and generally law-abiding nice-guy-if-a-bit-daft, mind. Now that I felt informed about the situation at least to some extent, I could take at least some steps to try to ensure that the problem was unlikely to occur amongst my circle of relatives.

However... on the other hand, the sort of kneejerk reactions that I tried to outline, earlier, are all too common in the communications industries.

For those of you who've witnessed them, think back to arguments you've seen regarding topics like encryption, network auditing tools, host auditing tools, www software like java or netscape cookies (an interesting topic in itself) - double edged software which equally be put to good, bad, or stupid (naive) use - and usually all of the debates will include at least a few hype-driven threads along the lines of:

• "bad people will use this for nefarious purposes", or
• "our youngsters will be corrupted by this."

As you may have guessed from my take on the issue, I believe that in many such situations that there is generally a greater benefit in informing the populace in some constructive manner, than there is in promoting ignorance and locking it down via authoritarian controls.

Such is the way of debate over Internet security vulnerabilites; I have almost given up reading newspapers and trade-rags due to the high proportion of quite ludicrous fantasy that one encounters nowadays, especially when (from the vantage point of experience) it is easy to see when a story has been shoehorned into the press to fit someone's political or commercial agenda.

So, it is in an attempt to redress the media's swamping of the press with stories of elite hacqerz ("some as young as 12 years old!") with arcane skills which defy mortal imagination, I have prepared this little one-day programming course in "How to Build a Hacking Toolkit".

At the end of it, I hope you'll agree, that many of the basic skills of hacking are quite as easy as knocking on doors and browbeating little old ladies out of their pension money.

For those of you who may suffer wit-impairment of some form, please note that I do not condone either of the activities of extorting money from the elderly, nor of hacking into other people's machines - but I do feel strongly that there is a overall benefit in shining a light on hacking methods.

Before I begin, though, I suppose that I had better say a thing or two about plumbing.

I won't pretend that everyone in this room has been exposed to computer programming in general or to operating systems like Unix in particular, so instead of just whipping slides of programs on and off the OHP without any of the magic sinking in, I thought that I'd best explain what's going on.

Consider a plumbing system - a source of waste water which them passes though a variety of pipes and appliances on it's way to the sewage outlet.

[SEWAGE]

First the water passes into the sink, drains into the sewer, then reaches a filtration plant which processes it in a variety of ways:

• add chemicals
• filter it
• let it stand
• filter it again

The point to emphasise here is the modularity of the process; a well defined flow of "stuff" starts in one place and is piped through a variety of processes which do something useful, before the "stuff" is finally dumped.

Similarly perhaps to a network auditing (or, if you prefer, network breaking) program:

[FLOWCHART]

Where you start with a list of computers (or "hosts") which are attached to the network.

Again, the "stuff" is piped through a variety of processes - of removing unnecessary information, of checking that we are able to reach each host that is listed. Then, the list is passed through an "attack engine" which processes it in a variety of ways:

• get an address to work on...
• try to break into it this way...
• write the results to a file
• try to break into it that way...
• write the results to a file
• try to break into it the other way...
• write the results to a file
• get the next address.

Finally, the files that are created may be examined either automatically or by a human, looking for keys - indications of weakness - which have been detected by the attack engine, and which which may be collated to make a list of weak machines.

I hope that doesn't look too technical for people to follow. 8-)

What I've outlined is basically a strategy - a fairly commonsense strategy at that - for detecting machines that are attached to a network and which suffer weak security.

What surprises most people is how easily this strategy can be converted into a working tool that matches the expectations of this design.

To illustrate this, I have written ITOD - a network breaking tool written with five aims in mind. ITOD is meant to:

• be real/usable
  ...to illustrate the previous "flowchart" yet provide real functionality - some would say to provide a "real" threat.

• be portable
  ...at least amongst it's target environment (Unix)

• be extensible
  ...so that it can be enhanced easily

• be moderately comprehensible
  ...for an audience of even slightly computer-literate people.

• fit on the back of an envelope.
  ...and to be small. Very small.

[HOSTS]

# loopback
127.0.0.1       localhost

# servers
10.1.1.1        crypto loghost
10.1.1.2        foo
10.1.1.3        bar
10.1.1.4        baz
10.1.1.5        wibble
10.1.1.9        thud thud-slip

# cartoon cluster
10.1.2.9        bugs
10.1.2.11       daffy
10.1.2.12       taz
10.1.2.14       elmer
10.1.2.15       porky
10.1.2.16       droopy2
10.1.2.18       speedy

Here we have a plausible looking list of 14 machines that are attached to a network - such information must be generally available in order for computers to communicate with each other, and here we see a list of network addresses, each with one or more names - hostnames - attached.

Working from this, we can immediately cast an impression of what our overall tool should look like, and (by using a couple of utilities that are standard with the Unix operating system) - we can even start implementing some of it:

[ITOD]

...don't be put off at first glance; this the code for our hacking program in it's entirety. One page of text. The first half of the program can be safely ignored when gaining an rough understanding of the program: [COVER TOP SECTION] - being as it merely deals with setting up a few bits of data that we'll need later, but don't have to bother with now.

This leaves 8 lines of code.

The first section merely sets up a directory - a folder - a repository in which we shall store the information that we glean:

• check if an appropriately named directory exists
• if not, try to create one
• and if that fails, come to a complete stop.

[FLOWCHART]

• take the list of hosts
• strip out the network numbers (please take that on trust)
• fire the list through a process to check if the machine is alive or dead (switched off, unplugged, etc) - named "ping" like a sonar ping.
• fire the remaining addresses into a hacking engine, and finally...
• quit once you're finished.

Having thus implemented the general concept of the tool - how the data flows through it, and what tasks each of the modules of the tool should perform, we're now stuck with the matter of following though this outermost shell of design by implementing the modules themselves.

The first module - called itod-ping

[ITOD-PING]

- is trivial to analyse and it's contents will be familiar to anyone with a basic knowledge of Unix; if you're not familiar, the logic is simple and follows a commonsense approach to the module's specification:

• whilst you can read a host address from upstream...
• ping that address - where ping is a standard program that tests whether a machine is reachable...
• ...and if ping fails, go get another address...
• else echo the IP (network) address - ie: pass it downstream for further processing.

Now - before going on - I must agree that yes, to some people (perhaps journalists especially) all this looks mystical or incomprehensible, and that therefore we should venerate people capable of writing it - but I must assure you that it's not magical in any way.

The software that you see here would have run mostly unchanged on any unix computer of 10, perhaps 15 years ago, and the language that these programs are written in dates back to 1970.

This is all college-level stuff, and is no more magical than Pitman's shorthand.

Returning to our flowchart, the remaining addresses of "live" machines on the net are passed downstream to:

[ITOD-ENGINE]

The hacking engine - itod-engine - the sewage plant of our analogy, which is the last remaining bit of any complexity. Similar to the previous program, this module -

• reads one network address at a time, until the list is exhausted.
• creates a subdirectory (if one does not already exist) a folder in which to store information that we will gather about each individual host.
• then, foreach of a series of more modules (each of which implements an single attack), it...
• ...runs the attack against the host, and stores the result in a logfile.

So now we have the complete picture - stuff (a list of hostnames) is stripped of non-essential information and fed into one program (which filters out dead machines) and is further fed into another program, which launches an army of weenie little attacker programs against the host, gathering information, which is then stored in files indexed by the address of the machine.

We have not yet addressed the question of "What are these attacks?" - but I should like to defer that question for awhile, and to ask the audience to think like criminals for a moment.

Imagine that you too want to cheat OAPs out of their pension. If you were intent on this crime, how would you approach it?

• Start with a list of steet names and people's addresses?
• Identify viable targets of the appropriate age group?
• Approach each target house in turn, armed with enough background information to trick the resident into trusting you?
• Try a series of arguments on the occupier in order to swindle them?