Penetration testing often takes place in situation where the management doesn't fully trust the IT department. It is sometimes ordered by the IT department itself to show its excellent work. However, this is not the case covered by this case study. Leran more about penetration test from Miroslav's article.

Penetration testing often takes place in situation where the management doesn't fully trust the IT department. It is sometimes ordered by the IT department itself to show its excellent work. However, this is not the case covered by this case study.

One day a phone rang in our office that surprised me a bit. The caller introduced himself as a security manager of one big oil company (The sphere of business, identification passwords etc. were purposely changed to make client identification impossible). He said his company is interested in our services and he'd like to have a meeting with us. He spoke mysteriously, he didn't want to tell any details and he wasn't equipped for secure communication.

Within a week the mysterious call turned out to be a request for internal "zero knowledge" penetration test – that is a test which should discover weak points that could be exploited from within the internal network by someone who has no information about the tested network and applications. Further, it was agreed that the subject to test will be only network exploitable weak points. During the contract preparation we were aware that it's not typical contract and that a maximal discretion and an exactness in statements are desirable. The reason is that customer often expects the contractor to take complete responsibility for the effects of testing. In this case it was not possible and we had to explain the impossibility of such responsibility to the customer.

Nobody doubts that every minute of system outage in a bank causes significant losses, it's not so obvious in an oil company. However, the level of loss could be similar because the entire processing line depends on the computer network. I must admit I told to myself "What losses could there be? In the worst-case the oil wouldn't be processed for a few hours"; I was quickly set right by them, however. I was told that it in the worst-case the oil products could leak onto the ground instead of the containers. Better not to think the consequences to the end.

Not only does the testing itself result from the estimate of losses and possible risks but also the contract between the contractor and the customer. It also arises from the nature of the penetration tests that we are dealing with activities which are against most of the instructions and rules for ordinary employees. It's especially necessary to tell who is responsible for what in the contract. Because of the risk of very high possible losses and because we were not able to find an insurance company which would cover the risk, we could not take the responsibility for the risks of testing without detail knowledge of the systems, devices and applications and their configuration. And we could not get these informations because then it wouldn't be "zero knowledge" testing.

Despite of the fact that both contracting parties wanted an exact definition of their responsibility in the contract, this demand showed to be unfeasible. The final contract of course defined the responsibility for situations that could possibly happen, but we unfortunately could not take the responsibility in some cases because we didn't know the configuration of the systems and we couldn't make sure that they are patched with proper security patches etc. The contractual liability for the possible nonavailability of some of the systems was established as follows:

The client is obliged to make a complete backup of all data and configurations and save it to the bank just before the start of testing.

The client will provide an appropriate emergency service which will immediately solve possible breakdowns of individual systems. This emergency service will be provided for all key systems and applications.

The contractor is aware he works in the real-time operation and he will conform the testing method to that fact. He will also act with maximal care.

In addition to other ordinary statutes the contract also stated an independent arbiter who, in case of a problem, will judge if the problem was caused by the contractor (e.g. using inadequate methods) or by the client (e.g. because of an error in configuration, absence of key security patches, etc.).

Both parties approached the testing with responsibility so the above-mentioned statute wasn't used.

Technical background of penetration testing

After more than a week the contract was finished and signed by both parties so we could begin with testing. When I came to the place a small room with two PCs was assigned to me. Each of them was connected to another Ethernet segment and they allowed me to get to a VLAN used by all users. Upon stating my network adapter's address I got an IP address from the range normal users use. These two PCs and the necessary know-how was all equipment I got for the testing. I was also equipped with an attendance system chip card which allowed me to access the room and WC.

I used a desktop PC with Debian unstable Linux distribution with a 2.6 kernel and a notebook with Windows XP and the same Linux distribution as on the desktop for the penetration testing.

The penetration testing itself

Of course I could begin with running a few security scanners (with all vulnerability tests turned on) and base the handwork upon its results. Unfortunately there are companies that just write their report on the basis of these results and then they are finished. I didn't even consider that because I've done this work for a long time. Especially in this environment it would be very dangerous. Some operating systems and applications don't have their network communication done well enough so such behavior could very easily lead to DoS.

There are even such operating systems and applications that could be taken down by a mere nmap. Moreover, such behavior would be in direct contrary to the contract, because it could hardly be referred to as "acting with maximal care". Therefore I started with testing the DHCP configuration. I changed the desktop PC's MAC address using ifconfig (ifconfig is used to configure or show the configuration of a network interface) and tried to connect to the network. And I found the first security drawback right away. Not only did I connect to the network (switch didn't reject me), but I even got an IP address from the DHCP server. And this address was from the very same range as the one I got officially. So I had the same rights and restrictions (for example the same Internet access restrictions). It was the first significant vulnerability because anyone who could get to the active ethernet could browse through the network and access the Internet using a client's address.

The next step was mapping of "living computers" in the user subnet. I did that with a mass ping to these computers. Of course I was aware that there could be a firewall on some of them and they may not reply. Nevertheless I got a broad survey for further orientation. Because I did this mass ping using nmap program with the right options I got also MAC addresses of the computers and the network card manufacturers. I used this information just for orientation because MAC address and therefore also the network card manufacturer could be easily spoofed, although that's not very common. I ran this using cron (system program that runs commands periodically) every 10 minutes to complete the list. Thus it listed even occasionally used computers.

Once I had this list I wrote a simple script which translated all the internal addresses to DNS names. Using another script I got names of the individual devices (host computer names). I went through the list of DNS names and host names and I figured out, for example, that host names of user PCs and notebooks contained the user surname and DNS name PC00x.domain.cz. The client apparently used DNS syntax name.domain.cz for devices in the internal network. Further the list contained some devices with DNS names Printer0x and the same host name. Another group of devices used names of characters from Czech fairy-tales (Køemílek, Amálka, etc.). So I came to a theory that the names are assigned as follows:

• PC00x are user stations;

• Printer0x are network printers;

• characters from fairy-tales are active elements, servers and other important devices.

Then I had two basic alternatives. I could accept this hypothesis and save quite a lot of routine work. But I chose the second one, more time-consuming, but in my opinion the right one and I checked the hypothesis further.

A d v e r t i s e m e n t

sum:

0 €