About the presentation

This presentation is created by Frank van Vliet and is presented at the ISC2 Secure Amsterdam conference. For any questions, don’t hesitate to contact him at frank.vanvliet@certifiedsecure.nl.

Ethical hacking

Frank van Vliet (1982) is an ethical hacker, known for hacking sites like FreeBSD.org and slashdot.org. Since 2003, he started working for Pine Digital Security as Security Specialist; this meant performing attack and penetration tests, source code audits and lecturing many workshops on secure programming. Besides security tests, Pine Digital Security is also the major provider of lawful interception solutions.

In 2006, I co founded the spin-off company Certified Secure. By capturing the meaning of the word ‘security’ in checklists, Certified Secure is able to certify companies based on the status of their security.

Besides my work as security professional, I also attend the Kerckhoffs Institute master Computer Security which is provided by a joint effort of the University of Twente, Nijmegen and Eindhoven. I’m currently writing my master thesis on automated attacker profiling (intruder detection instead of intrusion detection).

No network is safe

Hackers can penetrate any network or system (given enough time). New security vulnerabilities are found every day, and no software is programmed 100% secure. Some types of attacks are closely guarded hacker-secrets and will not be publicly known for several years.

Also, hackers are not bound by any moral rules; they can attack any network. They could hack your home network to enlarge their bot network, they could hack your company network just for fun and personal education. They could also attack to steal company secrets and other valuable information.

In the end, each and every network will have to be secured, so who is going to do that?

How can we stop those hackers?

Most of us are working somehow in the security business. Some of you are either a security professional, working for a security company, or work/study in the world of academics.

We are often not directly end-responsible for the security of others’ networks, but they turn to us for advise, performing security tests, new security research or nice and shiny security products.

When something becomes available as a silver bullet in security, we like to jump onboard and believe we’ve finally succeeded in securing something.

IDSs, the silver bullet

Intrusion Detection Systems are perfect, they’ll automatically protect your network against any form of attack! I’ve been there, building an inline signature based intrusion detection system which could also drop the offending packets. It was the perfect black box to secure any network, if only…

Don’t add something to fix something else

There are security problems in any network, place any number of computers together and you’ll have a bunch of problems; most systems are only up-to-date when they are deployed, miss adequate firewalling, run insecure services, etcetera.

What you should do, is to fix those problems: update each system and install some mechanism for automatic updating (and testing of those updates obviously), Implement firewalling based on deny all, permit only the minimum required, perform source code audits and penetration tests on your services.

You cannot, however, add something to your network to solve those problems…

It is actually a bad idea to deploy an IDS

Adding an Intrusion Detection Systems will not solve your problems, it is not a silver bullet. There might be some legitimate reasons to implement an Intrusion Detection System, but none of them will allow you to ignore the real problems in your network. In most cases, it is actually a very bad idea to deploy an Intrusion Detection System.

Wishful thinking does not stop real hackers

Let’s start of by stating that an Intrusion Detection System will not stop real hackers attacking real networks. It is very wishful to think your magic box will stop motivated hackers who know what they are doing.

As you know, there are generally two types of Intrusion Detection Systems, the system working on signatures (Signature based IDSs) and the system working profiles of normal traffic (Anomaly based IDSs). For both types, we’ll discuss why they fail to stop real attackers on real networks.

There are no signatures for unknown attacks

First look at Signature based IDSs. They are basically glorified pattern matchers, having a list of known attacks (signatures) and they match passing traffic to the signatures. When the traffic matches a signature, it is seen as an attack and reported. The matching traffic might even be dropped or a TCP RST might be send. This last method obviously isn’t very helpful since the destination will first process the attack, and then close the connection after being exploited.

Somehow, this list of signatures must be generated and kept up to date. This means they connect to a central server to download the latest and greatest signatures, or one must manually update the list.

It’s easy to see that having a list of known attacks will never work, this list is per definition out of date; you cannot create a signature of an attack before it is known.

Each year, more vulnerabilities are disclosed

How often are new security problems found? MITRE published number about the new vulnerabilities found each year. In 2006, this number was around 7000. It is easily seen that each year, more vulnerabilities are disclosed. This must keep the maintainers of the lists of signatures quite busy.

An average of 18 new vulnerabilities a day

If we divide the number of vulnerabilities found each year by 365, we get the average number of vulnerabilities found each day for each year. As you can see, this is an average of 18 new vulnerabilities each day to be included in the list of signatures. Obviously some vulnerabilities full outside the scope of a Signature based IDS (for example the local vulnerabilities), but all vulnerabilities must still be researched.

Snort takes 7 days to create signatures

The normal cycle for a vendor that creates signatures is the following:

1.  The vulnerability is reported. This might be on public mailing lists like bugtraq or full disclosure, or by direct announcements by product vendors.

2.  The vulnerability is researched. It must be validated this vulnerability does actually exist, methods of attacking this vulnerability must be created and tested.

3.  A signature can be created matching all attacks for this problem. It is best to write signatures based on the vulnerability instead of writing it on specific methods of exploiting this problem.

4.  Finally, the signatures must be distributed to all Intrusion Detection Systems, deployed all over the world. This might be a push method (connecting to the systems) or a pull method (having them connect to a central signature repository).

This takes a lot of time; the latest snort rules (where you have to pay for) are updated only once a week.

It could take years for a 0-day to publish

Even if the published vulnerabilities could be transformed directly to signatures, there are a lot of security problems which are never published. Hackers like to share so called 0-days, and are very protective of these. It could literally take years before a 0-day for OpenSSH is published to the public.

How is a Signature based IDS supposed to know of these problems?

Anomaly based IDSs have potential

Next to Signature based IDSs, there are Anomaly based IDSs. These systems are the kind I like, they define what behavior is normal and detect deviations of this normal pattern. They have the potential to stop 0-day exploits, and don’t depend on a (commercial) vendor to provide a list of signatures.

However, such systems are not yet ready to be deployed on real networks.

Abnormal traffic is listed as an attack

To use an Anomaly based IDS, it is important to learn this system what is considered ‘normal behavior’. This means it will need attack-free network traffic that is representative for the network the IDS is going to protect. This training traffic allows the IDS to create a profile of `normal behavior’.

When the training is complete and the profile of `normal behavior’ is created, the IDS can receive new traffic and is able to distinguish between normal and abnormal traffic. Most Anomaly based IDSs make this decision based on the statistical distance between the new traffic and the stored profile. If the distance is greater then a given threshold, the traffic is considered abnormal and is listed as an attack.

Demonstration

A demonstration using fruit will clarify the actual working of an Anomaly based IDS named POSEIDON. For more information, I suggest reading the following paper:

POSEIDON: a 2-tier Anomaly-based Network Intrusion Detection System

by Damiano Bolzoni, Sandro Etalle, Pieter Hartel

http://eprints.eemcs.utwente.nl/1326/02/01610007.pdf

It is hard (manual) labor

The main problem of Anomaly based IDSs is to create the trainig set. Without representative, attack free network traffic of your network, the IDS cannot learn what normal behavior is and will not be able to tell the difference between normal and abnormal traffic.

The only way to create a training set for a real network, is to capture it’s network traffic for a period of time and then manually removing all attacks from this traffic. One could use Signature based IDSs to assist, but it is hard (manual) labor to create this training set.

Even worse, when the network changes, the training set is no longer representative. This means that every time a server is added to the network, or the website is changed, a new training set needs to be created.

It is infeasible to create training sets for real networks and keeping them up-to-date.

Per definition, IDSs make a best guess

Intrusion Detection Systems that are listening on the network have no way of knowing how a system receives and interpret their network packets. Per definition, network based IDSs have to make a best guess.

Attackers like to exploit the situation where an IDS has to guess. When faced with two choices, the IDS could also decide to test both cases for attacks. In theory this is a nice solution, but in practice this does not scale when faced with multiple options for each packet the IDS sees.

RFCs are implemented differently

For example, it could very well be that servers support different features to encode their packets. Those features might be types of encoding like encryption and compression.

Also, some servers understand Unicode characters, while others will only see a set of ASCII characters. The Unicode-enabled servers will literally see different data than servers without Unicode capabilities.

Furthermore, the implementation of the RFCs is known to be different from product to product. The IDS can chose to stick to the exact definition by the RFC, but the servers would interpret the packets differently based on the software they use.

The IDS will never know for sure

Next to different features and RFC implementations, even identical servers can interpret their packets differently. The most obvious reason for this is that packets can be reordered by a router and switch located after the IDS inspection point.

TCP allows packets to be ordered again based on their sequence numbers, but if two packets arrive with overlapping sequence numbers only the first packet is used (or the last based on the implementation of the RFC).

If the IDS is using a SPAN port on a router or switch, chances are that it is already dropping packets. The aggregated network traffic, both in and out, of all ports is most likely higher then the available bandwidth on the SPAN port.

What is the extra risk of using an IDS?

Until now, the main point of this presentation has been that real hackers will not be stopped or detected by IDSs. But the question arises, `can’t I use an IDS to defend against the lesser hackers?’. The answer to this question cannot be given as a simple ‘yes’ or ‘no’.

Like all security solutions, it is a question of risk. Do you think the risk of scriptkiddies penetrating your network must be addressed? Don’t you think that this risk should be addressed using proper version management and secure coding practices? And also important, what is the extra risk of using an IDS in your network?

The following half of this presentation will answer this last question.

No software is secure

We all know that security vulnerabilities can be found in all software. It is impossible to write 100% secure code that can withstand hackers in present and future times. So we should also agree that the software of your IDS contains security vulnerabilities.

But, having security vulnerabilities is just one input on the equation of risk. Risk is calculated based on the vulnerabilities in software, the requirements on hackers to exploit them and the impact of such an exploit.

Bypassing and compromising Snort

As an example, we take an open source Signature Based IDS named Snort. As suggested in the previous slide, this product contains a lot of security vulnerabilities. There are vulnerabilities know to bypass the IDS, but also many vulnerabilities like buffer overflows and integer over/under flows actually compromising the IDS.

Normally, you would limit attack surface

Normally, you would limit attack surface by using a firewall and disabling all services you don’t really need. However with an IDS it is the other way around. The IDS is implementing all possible services, and is listening on all parts of the network. This gives attackers a lot of attack surface and gives them easy access to the IDS.

A simple example network

In the case of a compromised IDS, it is good to reason about the impact of this scenario. In this example case there is a simple network with just three servers. More complicated networks would have multiple network segments with internal firewalling etc.

All network traffic is compromised

When the IDS is compromised, the attacker has access to all network traffic passing through this network. It doesn’t matter if the exploit targeting the IDS was addressed to Server A, when an exploit compromises the IDS all network traffic is compromised.

All servers are compromised

When the IDS is compromised, it is safe to say all systems in the network can be compromised.

Sensitive information can be gathered

The network traffic contains many protocols that don’t use cryptography. These protocols often contain usernames and passwords which can also be used to access the systems on the network. Also, sensitive information can be gathered by just reading the email and watching for web traffic on a network.

A special class of problems arise when an IDS is of the active type, capable of ‘preventing’ attacks by resetting connections. When an IDS is able to insert packets in the network, it is capable of performing man in the middle attacks compromising even encrypted channels of communication.

Some IDSs go one step further

Some IDSs go one step further, completely removing the security of encrypted channels. When such an IDS is compromised, the attacker has the private key of the SSL certificate. Now the attacker can compromise encrypted channels without performing man in the middle attacks.

You are faced with a decision

In the end, you are faced with a decision. Is the risk you introduce with an IDS worth the reduction of risk posed by scriptkiddies. Is this really your way of improving the security of a network?

It is your job to stop hackers

In summary, you are faced with protecting networks against hackers.

IDS will not stop hackers

Intrusion Detection Systems will not stop real hackers, and will increase the risk of a completely compromised network.

Fix the real problems

You don’t fix the problem with an IDS. If you want to improve the security of a network, it would be best to solve the actual security problems.

Thanks for your attention

If you have any questions, please don’t hesitate to contact me on frank.vanvliet@certifiedsecure.nl.