Now, when everyone is obsessed with encryption, cryptocontainers and other methods of fighting with “software attacks” such seemingly obsolete things like intrusion bugs are regarded as artifacts from James Bond movies rather than a real threat. As a consequence, a network that is physically isolated from the Internet is considered to be almost invulnerable to hackers. Even if the length of the network is many kilometers, and there are no security people to protect many of its components, which are literally accessible to anyone, sometimes just open to anyone, the network is still considered to be absolutely secure. Actually, it is not, as experience has shown.
I had an opportunity to see this personally, in the framework of a project which involved testing a closed network, which its administrators believed to be absolutely unassailable. Perhaps they had reasons to believe that. The network in our project was actually protected from Internet with firewalls and a perimeter network. It was for some reason ignored that the network nodes were located literally in the street and were not equipped with any means of physical protection (in other words, not even a padlock on the box). This is where we used a small inconspicuous box without any marks, a device produced by Pwnie Express.
Let’s introduce the device
Pwn plug r2 is a mobile, subtle but powerful springboard for a hacker to penetrate a network. It is slightly larger than a pack of cigarettes, but looks can be deceiving — this little box contains a hacker’s arsenal.
First, let’s see what it looks like. Everything is clear here: there are two Ethernet connectors, it has two USBs, outlets for Wi-Fi and Bluetooth-antennas and connectors for an SD-card and a power supply. The body is of a neutral white color, without any markings or labels.
Electricity supply is perhaps the only thing that limits the mobility of our springboard: unfortunately, POE is not supported, there is no internal power source, but this 5 W device can be powered from virtually any source. On the other hand, wherever there are electronics, one can find power, and the power consumption of the device is low — only 5 W, according to the specification.
So, we are done with the external examination, and what’s inside? First, we see a fairly primitive web interface for the basic configuration, and here we can configure the external interfaces and change settings and passwords. The interface includes a big red button with the word “hack”, but we were not impressed by its functionality: it consisted of a few rather primitive exploits.
It’s time to connect via SSH. We enter the username and the password; inside, we have a complete assembly of Kali Linux with a complete set of various tools.
A description of all the wonders of the system will be enough for more than a dozen articles, so let’s feel impressed for a moment and go on with our business. The next step is to solve one more problem — how to control our hacker’s server in the “enemy” network. We would not connect a patch cord to it, that’s for sure! But the solution to this was already available, thanks to the developers from Pwnie Express: The Pwn plug came with a USB GSM modem and two scripts — one ran on Pwn plug through the web interface of the base configuration of the device and was connected to our server in the office via SSH, and the other was deployed by us for listening to incoming connections. The final step in the penetration was to protect our device and the modem from the elements. This was especially important for the modem, which was supposed to stick out of the steel box that contained the other equipment. We protected the device from wind and moisture with the help of a sandwich box and shrinkable foil. That’s all. We are ready. It’s time for some action.
Now let’s do the top man’s job…
Humming the famous tune about the top men, I climbed to install the device physically into our network. The network node that we had chosen for penetration was located in an open area, but it was not so easy to get close to it. It had no protection, however, and we were lucky to find a free power socket and an Ethernet socket in the switch. As a result, after a very long half an hour we spent in the cold, the only thing that could be noticed outside was the GSM modem wrapped in shrinkable foil. On my way to the office, I was full of anticipation of the upcoming pentest.
We got inside once again, and checked the connection. To do that, we perform the following operations: We enter our office server to which Pwn plug is to be connected via SSH, and start the listener to organize the tunnel. After that, if everything is configured correctly, we will be able to connect to the device through local interface
ssh pwnie @ localhost -p 3337.
Ready. We have access now.
Once inside, the first thing to do is to look around. We ran netdiscover to understand what IP-addresses are there in this segment where the gateway is and to get some other basic information.
Now, when the structure of the segment became clear to us, we give ourselves an IP-address (network 192.168.0.1/24), and then it is the work of Nmap. We collect as much information as we can:
nmap -sS -sV -vv -sC -p 0-65535 -O -Pn -oA "scan" 192.168.0.1/24. As it turned out, there are only three nodes in this segment: a router, a computer that is running Windows Embedded and an Ethernet adapter with COM. After a brief study of Windows Embedded, we were sure that there was nothing interesting for us, so we focused on the router instead.
In order to understand the structure of the network behind the router it was decided to use Wireshark — or rather its console version, tShark. We start the sniffer, and we are only interested in the address of the router:
tshark -R" ip.addr == 192.168.0.1 "-r / tmp / capture.cap. After gathering a sufficient number of packets, we can analyze the traffic dump (it is very convenient to use GUI Wireshark for this) and use it to find out what traffic is present in the subnet. After the addresses of some servers behind the router had been received, all we had to do was to enter the routes at our Pwn plug and get into the main network. This stage of our network penetration is shown in the scheme in Fig. 4.
I would like to express my gratitude to the developers of the penetration bug for the fact that Pwn plug has some foolproof features. For example, when we registered the router of our segment as the default gateway, we lost touch with Pwn plug, probably because all the traffic went through the gateway and not through our 4G-modem, so our external link was disconnected. I had already mentally prepared to climb up again and readjust our device manually, but less than in half an hour the settings came back to the initial mode, the connection was renewed and we were able to continue testing.
In the vast expanse of the network
So, we are in the main segment of the network, it’s time to look around. We are using Nmap, as we’ve already done before. Running ahead of the story, I can say that no one noticed our entire activity. To make the test as close as possible to real-life conditions, the management kept the network administrators unaware of our project. We were to remain undetected for a long time, despite the fact that all of the tools were used in aggressive mode.
Nmap scan results provided us with a list of quite interesting services. The most promising one was JNLP file downloaded from one of the servers. This file is Java Network Launching Protocol, which downloaded and installed the client for one of the services located in the internal network. After forwarding the appropriate ports and configuring NAT broadcast (we used the so-called “overloaded” NAT, or NAPT, which is a form of dynamic NAT displaying a number of unregistered addresses in a single registered IP-address by using various ports; eventually, what we had was a sort of VPN via SSH). In the command line this looked as follows:
ssh -L 8080:192.168.1.111:80 pwnie@localhost:3337
After such connection, port
192.168.1.111:80 of the internal network became available locally at our server at port
8080. This simple trick gave us an opportunity to use Java client on our computer in the office.
By studying the JAR-files we had with JAD decompiler, we have received multiple passwords for users with relatively high privileges on one of the internal network servers. I must say that the JAR-files that were downloaded had not even been obfuscated because it was obviously assumed that they could never get into the wrong hands.
Penetrating deep into the system
After one of the servers in the internal network had been captured, our Pwn plug became a channel through which we began turning the compromised server into a full combat bridgehead. We prescribed routes in the server settings and, using the Pwn plug channel on the Internet, downloaded all the tools we needed such as Ettercap, tshark, hydra and others from the repository. Now Pwn plug became a C&C (command and control) server for our internal botnet. There was only one computer so far, but it was only the beginning.
Further development of the attack
At this stage, compromising the network completely has become just a matter of time. By ARP-cache poisoning and the man in the middle attacks we received new account data to access more servers. The more servers passed under our control, the more intense our intervention could be to the operation of the network, and we went on to compromise new nodes and even adjacent subnets. Dictionary attacks using a hydra were also effective.
So, how did the network administrators react? They started to suspect that something had gone wrong after about a week from the day of our penetration into the network. However, by the time they started reacting, a significant part of the network had already been under our control, so it was very difficult for them to organize some countermeasures. As a result, their response was limited to changing the passwords on the computers we had already taken over, which did not produce any significant results, as nearly ten servers had been compromised by the time. Apparently, the administrators could not determine the exact source of our attacks, so our C&C-server remained active until the end of the project.
What do we have as a result?
The result of the project was that the customer’s network was completely compromised. Access was obtained to all kinds of data, including critical information like databases, office documents, e-mails. We also retrieved data that could be used to compromise the company’s affiliates. Naturally, we did not use this opportunity, as we acted in full compliance with the law, according to the client’s order and for the benefit of the client, but we registered such possibility in the documents.
The project showed that the threat of physical penetration still exists, especially for long networks, and the scale of this threat can hardly be overestimated. It can be concluded that the modern means of penetration are extremely effective and intrusion detection systems are necessary even for isolated networks in order to find and locate the attack before it’s too late.
And the most basic conclusion is that a padlock is still relevant as a means of protection even in the times of IPv6. Stay protected!