Proposed Pseudo-Code for Hacking Process

It is quite common in Information Systems to use pseudo code to describe a process. I have often thought that the same principle can be applied to the process of hacking an organisation, which may help people understand the process and how to protect themselves. Below is my proposal for this pseduo-code for the hacking process. This is very much a work in progress. I would welcome feedback on it and I will update it as suggestions are made or as I feel it needs revising.

organisation = proposed target
organisation.footprint(value, effort, risk)
profit = value - (effort * risk)
if profit > 0 then
  organisation.enumerate()
  select attack_type
    case DoS
      engage_botnet(myBotnet)
      myBotnet.launchDDoS(organisation)
    case Access
      organisation.gainAccess(myAccount)
      myAccount.Elevate()
      organisation.installBackdoor(myAccount)
      organisation.cleanUP()
  end select
else
  exit
end if

This highlights the fact that we only need enough security to make it not worthwhile attacking, i.e. it will cost the attacker more to compromise our system than they will gain. Who would spend £1m to get £10 worth of information? We don't need (indeed cannot have) absolute security, just enough to protect our system. It also highlights another interesting point. Perhaps we should make our countermeasures public - not the actual implementational details or versions, but the fact that they are in place, e.g. that we have an IDS. Consider blatant versus hidden CCTV cameras. Cameras in plain sight deter most criminals, whereas hidden cameras spy on criminals while they perpetrate their crime.

We want to make the risk of being caught/prosecuted value high, so that hackers require a higher value:effort ratio, which we won't give them. Given two identically protected organisations with the same value, would you attack the one that doesn't monitor activity or the one that does?

Obviously, the above is very vague and doesn't provide methods to complete these tasks, but that is not the point of this post. Backdoors and Trojans are usually relatively easy to install if you have the right level of access to the system, so much of your security is going to hang on stopping a hacker from gaining access. Gaining access to an organisation is usually performed in one of four main ways:

• Malware
• Sniffing
• Direct Attack
• Social Engineering

There are ways to protect yourself, up to a point. Some of the most critical are:

• Installing Antivirus/Antispyware
• Latest OS and Application Patches
• Enterprise-level firewall, with IDS/IPS, AV, etc.
• Personal firewalls on all mobile devices
• Secure, hardened configurations
• Browser lock-down
• Encrypted communication (e.g. SSL/TLS, VPN, etc.)
• User Education!

The last point is often overlooked as a critical security practice. Please feel free to comment.

Telephone and Fax Services Security

In this day of doing everything online, we still rely heavily on services delivered over POTS (Plain Old Telephone Service). Banks and credit card companies still require the telephone to make certain changes, queries and security checks, even though most functions can be performed online. Medical records, bank details, security key order requests, etc., are routinely transferred by facsimile. However, are these secure? Are they more or less secure than doing the same thing online?

I'm not going to talk about the underlying security of POTS, but concentrate on a couple of easy attack vectors on the end device of the user that I have recently observed. A couple of weeks ago, I needed to amend something on one of my credit card accounts (I would tell you which bank, only it's my personal credit card and I don't want phisers knowing which banks I have accounts with). This bank has an automated telephone answering system to make things more efficient and reduce staff required - pretty standard. So I made sure that I was in a room on my own, to prevent eavesdropping my conversation, and dialled the number. The automated system asked me to type in my full credit card number on the keypad.

The problem with doing this is that the telephone will remember these digits as part of the last number dialled. Therefore, all someone would have to do is to recall the last number dialled and read off the credit card number. If they actually dial it they would be put through as the legitimate card holder. Now, admittedly they will probably ask some security questions on the other end before making any changes, but these may consist of simply asking for a date of birth, which is fairly easy to find out. Even if you don't know this information, other information may be given away in the mean time (e.g. who the card holder is as they normally use your name in any greeting). The problem is compounded if you make a call from work, where you will probably be using an exchange. Exchanges will store all the numbers dialled, including any options or credit card numbers entered on the phone's keypad. This log can simply be printed out and your details read off. Of course the number dialled will show which bank you are using as well, although this can also be gleaned from the first 6 digits of your credit card number.

Things can potentially get worse if you use facsimile or fax machines. There are different types of fax machines that work in different ways. Most will keep a log of calls and faxes sent and received. This may or may not be a problem, depending on the level of detail of the log and whether you're typing in credit card details during a phone call made on the machine. However, some fax machines use rolls of pigment on acetate (or similar) to print the fax out when received. The problem here is that these rolls are wound through during printing and that part is never reused (otherwise you will get gaps in your printing). However, what this means is that when you come to throw the roll away once used, it will have a perfect facsimile of everything printed on the machine since the roll was put in, only in negative. To get round this, you must shred, or otherwise destroy, the used roll, not just throw it in the bin.


As to whether this is more or less secure than an online transaction is a difficult question to answer. On the one hand, you often need physical access to the phone or fax machine to get to the logs, although telephone exchanges are often online. Also, sifting through a bin outside a premises isn't that hard and can often be very rewarding. On the other hand, transactions online are encrypted and people are more aware of the security implications in general. However, malware and man-in-the-middle attacks can still thwart this type of transaction, but it does require more skills than sifting through a bin.

Not all data leakage comes from computers, pen drives, etc. Sometimes a seemingly innocuous device can betray your information and breach your security. Unfortunately, you have to think of all possible attack vectors and mitigate the risks. This is why a full information policy that covers all forms of data is required.

Log Attack Attempts

While I was answering emails and writing another blog post, I was reminded that lots of people ask me about the seriousness of the threat of attack as they are sceptical. So, I decided to turn on additional logging on my router to view all incoming traffic to see what it is blocking silently. I can tell you that in 2 hours on my home connection here I have had 22 different IP addresses making 47 different attempts to connect to me. One tried to launch a Denial-of-Service (DoS) attack on my web server three times (unsuccessfully), and another attached to my web server to view the options available and didn't bother retrieving any pages - this is a classic sign of footprinting before an attack. The first was host 123-204-6-150.dynamic.seed.net.tw and the second was host164-120-static.29-87-b.business.telecomitalia.it.

What were the other 20 connection attempts? Well I don't actually have anything else open on my network, but by logging all connection attempts I can view what people are trying. One tried to connect to port 3389 (Microsoft's RDP port) and then 3306 (mySQL), which is maybe a slightly strange combination - Microsoft's Terminal Services machine running open source mySQL? There were 4 attempts to connect to port 135 (Microsoft's DCOM Service Control Manager), 3 attempts to connect to port 445 (Microsoft's Directory Services), 4 attempts to connect to port 3128 (Active API Server), 2 attempts at port 2967 (SSC-Agent), 3 attempts at port 8000 (iRDMI, but sometimes used as secondary web port), and so on.

There are well-known attacks for these ports that are supported under tools such as the Metasploit Framework. So, this is an unlisted private broadband connection that had 22 attack attempts in 2 hours. What people have to realise is that computers are very good at doing repetitive, mind numbing tasks. You can scan a range of IP addresses very easily from tools that you can download for free. If they get a reply to these sweeps then they can investigate. If your firewall isn't blocking all these ports then you will get attacks. That's not the end of the story though. If your firewall responds to these connection attempts then you are telling the attacker that there is a machine there to be attacked. How do you stop this?

When one machine tries to connect to another over the network several things can happen, but the two main ones are: the port is open and a service is running on it accepting connections, in which case the connection will be successful; secondly, the port is not open and the service that would use that port isn't running, in which case your machine will respond telling the originating host that it isn't listening on that port. Now it is worth running a full port scan to find out what it is listening to (and yes, before you ask, you can defeat the port scanning alerts on firewalls fairly easily in most cases). This is what you must stop by stealthing unused ports, i.e. if a connection attempt comes in on a port you aren't using, discard the packet and do not reply. Most firewalls will do this for you if you configure it, but make sure that it is set up correctly.

One final note, always log attack attempts and never set your firewall to reply to pings on the WAN port!

P.S. I've had 7 more since starting to write this post.