During our last audit, we encountered a network architecture that aroused our curiosity. The architecture was composed of two segregated networks. Those two networks completely separated but could both access a storage filesystem replicated in both networks by a central black-box, connected to the filesystem servers using a non-ip protocol.
The network is as shown in this simplified diagram:
Our thought process was the following: Without trying to exploit the filesystem in any way, is it possible to take advantage of a shared folder and create a VPN to interconnect the two networks?
Short answer, yes it is possible, provided that they both have access to a shared folder, on which they have both read and write permissions.
The idea we had is to create a really simple VPN between the two networks, using the filesystem as crossing point, by writing requests into text files. Here goes the first VPN-through-text-files script.
Let’s say that a user is allowed to interact once with a machine on the network 2, or gets with some social engineering a user to run the script for him on the Network 2. He could take advantage of this one time only access to deploy the VPN-through-text-files script on the Network2 that would grant himself a permanent access from the network 1.
This network diagram (Figure 2 – VPN in action) is a high level representation of how the VPN-through-text-files script would works once executed.
The VPN would function like this (refer to Figure 2):
Having a general idea of how the script was going to work, it was time to implement a proof-of-concept of the script.
The VPN-through-text-files script was developed in Python, using the well know Python network library: Scapy.
The VPN-through-text-files script has three main components, each component is threaded:
The major problem faced during the development is with the receiver component.
In the scenario described in “Figure 2 – VPN in action (simplified)”, the user would have no control on the machines in the “Network 2”.
The problem aroused here is: How could we be sure to redirect all network responses of the machines to our VPN, without interacting with them, adding new routes, etc.?
When contacting the server on Network 2 through the VPN, if we decided to use as source IP the IP of the first network, it is unlikely that the server was going to respond. This is due to the fact that the server might not have a route to the particular address plan of Network 1, resulting in a “No route to host” error, as shown in the diagram below.
Secondly, we could not use the IP of the computer hosting the script on Network 2, because we would not have been able to create TCP connections across the VPN. This is due to the fact that the TCP stack of the machine hosting the script would be handling the TCP connection and would cause the TCP connection through the VPN to reset (see diagram below).
By creating several virtual IPs, we were able to circumvent this problem. In the “Figure 2 – VPN in action (simplified)” example, we would create a virtual IP in the range 10.200/16 and respond to any ARP request looking for our virtual IPs, indicating to all computers that we are hosting those fictive IPs.
The two problems explained in the two previous diagrams are solved by this simple solution. The server is able to route its responses to the virtual IPs, and the responses are not treated by the TCP stack of the machine, because the IP in the request does not match the IP of the machine (see diagram below for a detailed explanation).
The VPN script keeps track of the connections made and which virtual IP belongs to which host in the Network 1 and replaces back the virtual IP by the original IP before writing back the request to the folder, and the trick is done.
Testing the script
The VPN-through-text-files script offers a simple connection between the two networks, without any encryption or compression. Supported protocols include TCP (http, ssh, etc.) and ICMP for now.
The script was tested on a Kali Linux 4.6.0 x86_64, using Python 2.7.12+ and Scapy 2.3.2.
The screenshot below represents the test environment that was used for testing.
As we can see in the screenshot below, the client at 10.200.1.103 (bottom left in the screenshot) is able to establish a SSH connection with the server at 10.100.1.104 (bottom right in the screenshot) thought the VPN, even if the two networks are supposed to be segregated.
The prerequisite in order for this script to work is that the attacker has had to have access at least once to the second network in order to implant and run the VPN-through-text-files script.
As we demonstrated with this proof of concept, it is possible using our VPN-through-text-files script to interconnect two segregated networks, using a shared file system.
The source code of this project will be available shortly.