The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers (32 page)

Looking at the Configuration of the 3COM Device The guys now understood that the 3COM device was behind the fire- wall, and that the administrator's mistake had provided a circuitous path, making it possible for an attacker to connect behind the firewall through the open high port.

Now that they had access to the 3COM console, they looked at the configuration records, including the unit's assigned IP address, and pro- tocols being used for virtual private network connectivity. But they dis- covered that the device also sat on the same address range as the mail server and outside of an internal firewall, on the DMZ. "We concluded that it actually sat behind the perimeter firewall and was protected from the Internet using some sort of filtering rules."

They tried to look at the configuration of the device itself to see how the incoming connections were set up, but through that interface they couldn't get enough information. Still, they guessed that when any user connected to port 4065 on the Cisco router from somewhere on the Internet, the connection was likely being made to the 3COM device that was plugged into the Cisco router.

So at this point we were very confident that we were going to be

able to get access to the back end networks and gain more control

over the internal network. At this point, we were in very good

spirits but what the British call "pretty fagged," already having

put in the equivalent of two full working days. 202 The Art of Intrusion

We went to the pub and talked about how the next day was going

to be great because we were going to then start by looking at some

more end systems and kind of find our way deeper into the network.

Curious about this 3COM device, they had set up to capture the real- time console log. If any activity happened overnight, they would be able to see it when they came in the next morning.

The Third Day When Brock inspected the console log in the morning, he found that var- ious IP addresses had come up. Louis explained:

After looking around the 3COM device a little more, we realized

it was some sort of VPN that remote users were using to connect

to the company network from somewhere on the Internet.

At this point, we were certainly enthused that we would get to

gain access, in the same way that the legitimate users were gain-

ing access.

They tried to set up their own personal VPN interface on the 3COM device by bringing up another interface on the 3COM box, with a dif- ferent IP address, one that the firewall wasn't explicitly filtering.

It didn't work. They found that the device couldn't be configured without disrupting legitimate services. They couldn't bring up an identi- cally configured VPN system, and the way the architecture was set up, it restricted enough so that they couldn't do what they wanted to.

So this avenue of attack strategy faded quickly.

We were a little bit down, a little bit quiet at this point. But it

was very much the case that it's the first try and there's bound to

be another way. We still had enough incentive, we still had access

to this one device; we still had that foothold. We became kind of

intense on taking this thing a little bit further.

They were in the DMZ of the company's network, but when they tried getting connections out to their own systems, they were stymied. They also tried doing a ping sweep (trying to ping every system on the net- work) on the entire network, but from the 3COM system behind the firewall, to identify any potential systems to add to their target list. If they were any machine addresses in the cache, it meant that some device was blocking access to the higher-level protocol. "After several attempts," Louis said, "we did see entries in the ARP cache, indicating that some Chapter 9 On the Continent 203

machines had broadcast their machine address." (ARP, the Address Resolution Protocol, is a method for finding a host's physical address from its IP address. Each host maintains a cache of address translations to reduce the delay in forwarding data packets.)

So there were definitely other machines in the domain, "but [they] weren't responding to pings -- which is a classic sign of a firewall."

(For those not familiar with pinging, it's a network scanning technique that involves transmitting certain types of packets -- Internet Control Message Protocol, or ICMP -- to the target system to determine whether the host is "alive" or up. If the host is alive, it will respond with an "ICMP echo reply" packet.) Louis continues, "This seemed to con- firm our impression that there was another firewall, there was another layer of security between the 3COM device and their internal network."

Louis was beginning to feel they had reached a dead end.

We got access to this VPN device, but we couldn't set up our own

VPN through it. At that point, the enthusiasm levels went down

a little bit. We kind of started to get the feeling that we're not

actually going to get any further into the network. And so we

needed to brainstorm for ideas.

They decided to investigate the IP addresses that they had discovered in the console log. "We kind of saw that a next step was to have a look and see what was remotely communicating to this 3COM device, because if you could break into that device, you might be able to hijack an exist- ing connection to the network." Or they might be able to obtain the necessary authentication credentials to masquerade as a legitimate user.

They knew some of the filtering rules, Louis said, and were looking for ways of bypassing these rules on the firewall. His hope was that they'd be able to "find systems that were trusted and maybe had the leverage to actually pass through this firewall. The IP addresses that were coming up were of great interest to us."

When they were connected to the 3COM system console, he explained, anytime a remote user connected or a configuration change was made, it flashed up an alert message at the bottom of the screen. "We were able to see the connections going on in these IP addresses."

The registration records detailed the organization that particular IP addresses were registered to. Additionally, these records also include the contact information for administrative and technical personnel responsi- ble for the organization's network. Using these addresses, they again turned to the registration database records on RIPE, which gave them information on what company these IP addresses were assigned to. 204 The Art of Intrusion

In fact, this search brought another surprise. "We found the addresses were registered to a big telecommunications provider within this partic- ular country. At this point we couldn't completely put it all together, we couldn't really understand what these IP addresses were, why people were connecting from a telecoms company," Louis said, using the British term for what we call an ISP. The two guys began to wonder if the VPN connections were even from remote users of the company, or something entirely different that they couldn't at the moment even guess at.

We were very much where we needed to sit down and have a real

brain dump. We needed to really put together this picture so we

can actually start to try and understand.

The promise of the early morning had not been fulfilled. We had

access to the system, but yet we didn't manage to get any further,

and felt that we had not made any progress during the day. But

instead of just disappearing home and kind of coming back in the

next morning and picking up there, we thought we'd go to the

pub, have a drink and kind of de-stress and clear our heads before

we got on public transport and made our way home.

This was early springtime with a little bit of a nip in the air. We

left the office and went around the corner to a kind of quite dark

and dingy traditional English pub.

I was drinking lager, Brock was drinking peach schnapps and

lemonade -- a good drink, you ought'a try it. And we just kind

of sat there and chatted and commiserated between ourselves with

how the day hadn't gone as planned. After the first drink we were

a little bit more relaxed and a piece of paper and a pen came out.

We just started throwing out some ideas about what we were

going to do next.

We were very kind of keen to get something laid out so when we

came back in the morning. we could quickly sit down and try

something. We drew up the network architecture as we mapped it,

and tried to identify what users would need VPN access, where

the systems were physically located, and the likely steps the system

implementers thought out when setting up the remote access serv-

ice for this company.

We drew up the known systems and then from that point tried to

work out some of the detail and where some of the other systems

were located [see Figure 9-1]. We needed to understand where in

the network that 3COM device was situated. Chapter 9 On the Continent 205

Fully Patched Fully Patched Unpatched Primary

External External IIS Web Domain

Mail Server Web Server Server Controller

DMZ Network Internal Network

Firewall

3Com VPN

terminator

Cisco Router RADIUS Server Application Providing IP Server

Filtering

Internet

PPTP VPN Session

Security Van

Bank of

Modems

Laptop Brock Louis

Telecoms Provider

Cell phone base station

Figure 9-1: Illustration of what the two hackers thought might be the configuration, which would explain what they had observed about the network and the operations.

Louis wondered who besides the internal employees might also need to have access to this network. This was a company proud of its technolog- ical innovation, so Louis and Brock thought that maybe they had devel- oped a "really great distribution application" that would enable guards to log in after they had made a delivery, and then find out what their next pickup would be. This application may have been programmed to make the process idiot-proof through automation. Maybe the driver would click an icon, which would tell the application to connect to the applica- tion server and obtain his orders.

We were thinking that these drivers are not going to be very com-

puter savvy, they're going to have a system set up that's very

easy to use. We started to think of it from a business point of

view: What kind of system would be easy to set up, what kind of

system would be easy to maintain and would be secure?

They thought about a dial-up service, "perhaps from a laptop computer in the cabin [the driver's compartment]. And the company would either 206 The Art of Intrusion

have to host these servers that we'd gotten into, or they would have to outsource them with a third party. We hypothesized that the third party was a telecoms company, and information would have to pass from the telecoms company to our target company, and that had to pass over the Internet through a VPN tunnel." They conjectured that the guards would call into the ISP and authenticate there, before being allowed to connect into the target company's network.

But there was also another possibility. Louis went on:

We hypothesized, "Let's see if we can work out an architecture

whereby a guy in a van can dial up, pass his authentication cre-

dentials across and they are actually authenticated by the target

company rather than the telecoms provider. How could that com-

pany VPN be set up so that any information being passed from

the guard to the target company would not go unencrypted across

the Internet?"

They also thought about how the company was going about authenti- cating users. If a guard has to dial up to one of these systems located at the telecoms company and authenticate to the telecoms company, they reasoned, then the authentication services were simply being outsourced. Maybe there was another solution, they figured, whereby the authentica- tion servers were actually hosted by the target company rather than the telecoms provider.

Often the authentication task is passed off to a separate server that pro- vides this function. Maybe the 3COM device was being used to access an authentication server on the internal network of the target company. Calling from a cellular modem, a guard would connect to the ISP, be passed to the 3COM device, and his username and password would then be sent off to the other server for authentication.

So their working hypothesis at this point was that when a security guard initiated a dial-up connection, he established a VPN between himself and the 3COM device.

Louis and Brock figured that to gain access to the internal network, they first had to gain access to the telecommunications system at the ISP that the van drivers connected with. But "one thing we didn't know was the phone numbers of these dial-up devices. They were located in a foreign country and we didn't know what kind of phone lines they were, and we didn't have much chance to find that information on our own. The big thing we knew was that the type of protocol for the VPN was PPTP." The reason this was significant is because Microsoft's default VPN instal- lation just uses a shared secret, which is usually the Windows login and password to the server or domain. Chapter 9 On the Continent 207

They had had a few drinks by this time, and they decided on a "no- holds-barred approach" to solving the problem.

At this stage you're going to keep this piece of paper you've scrib-

bled all this stuff down on because this could be a really good hack

if we get in. And there was almost a sense of pride between the two

of us about how we were going to accomplish this.

Some Thoughts about "Hackers' Intuition" The guess the pair made that night would turn out to be quite accurate. Louis remarked about this insight that good hackers seem to have:

It's very hard to explain what causes you to get that feeling. It just