Technology #4: Hacking from home
Penetration testers and ethical hackers often have to visit client offices to perform their magic in the organizations’ internal network or Wi-Fi networks. In times of Corona and lockdown, this is no longer possible. Fortunately, technology allows us to continue to tele-hack. This blog post will describe the high-level setup and will provide some insights into the underlying techniques that are used.
Get the hacking devices on-site
In this scenario, we will use small hacking devices called ‘Pwn Plugs’. These are basically standard penetration testing devices in a small, portable format that come with an ethernet connection, onboard Wi-Fi antenna, Bluetooth, … . The devices run Kali linux with its entire arsenal of penetration testing tools.
Pwn Plugs are often used in ‘Red Team’ assignments, where we try to plant them as rogue devices into the target network. The devices are configured to connect back to an external Virtual Private Server (VPS), providing access and a permanent foothold in the internal network. The technical details will be discussed later.
Typical setup
When using the Pwn Plugs in a ‘hacking from home’ scenario, the device is simply shipped to the customer instead of being planted. It is then plugged into a representative network segment. This is typically the user’s VLAN containing the workstations, laptops… as it is a prime candidate for malicious activity. ? Once the Pwnie is connected to the network (Ethernet), it should automatically get its IP configuration via DCHP.
The diagram below shows a typical setup with a Pwnie device deployed.
As mentioned above, the device is pre-configured to try to establish an outbound connection to an external VPS via different protocols and tunneling techniques (1). Once the outbound connection to the VPS is established, a reverse shell configuration will create an inbound connection from the VPS to the Pwnie through the initial SSH tunnel (2). At that point, we can access the device and the internal network as if we were on-site at the customer’s (3).
With a successful connection, we can start the penetration test in nearly identical conditions as when being physically on-site. This includes vulnerability scanning, segmentation testing, Active Directory attacks, Wi-Fi audits…
It is important to note that this setup will work very often without any additional actions or whitelisting at the customer end. This comes as a surprise for many organizations as it is remarkable how the expensive firewalls can be bypassed so easily. The next chapters will explain some of the basic concepts.
SSH Tunneling
The main concept used here is SSH port forwarding or SSH tunneling. It is a built-in mechanism within SSH for tunneling application ports from the client machine (Pwnie) to a server machine (VPS) or vice versa. It can be used for adding encryption to legacy applications but, in this case, it is (ab)used for opening a backdoor into the internal network.
Several types of port forwarding exist:
- Local port forwarding
- Remote port forwarding
- Dynamic port forwarding
We will focus on the remote port forwarding, as this is the main technique used in this setup.
The diagram below shows an example of what actually happens. If the Pwnie can connect to the VPS over SSH, an initial SSH tunnel is created (big purple arrow). With remote port forwarding configured, port 2222 will be opened on the VPS. All traffic to that port on the VPS will be forwarded back to the SSH server on the Pwnie through the initial SSH tunnel (black line). At this point, we can remotely access the Pwnie bypassing the inbound enterprise firewall rules.
Of course, this is the basic principle and most enterprise firewalls will probably block outbound SSH traffic. This is where some additional tunneling foo kicks in.
Additional tunneling foo
As mentioned, most enterprise firewalls will block plain outbound SSH traffic. But what about other protocols like HTTP, HTTPS, ICMP, DNS, …? Chances are real that one or more of these protocols will actually be allowed outbound. We often see that protocols like ICMP or DNS are considered more or less ‘innocent’ and are not actively being blocked by firewalls.
So, to bypass the firewall in case SSH is being blocked, we will encapsulate the initial SSH tunnel in another allowed protocol. This principle is shown below.
The initial SSH tunnel packets are wrapped into other protocols that are likely to pass the firewall like HTTP(S) requests, DNS requests, ICMP packets… (purple arrow). From there, everything else stays the same. The initial SSH tunnel is created, followed by the reverse tunnel.
Pwn Plugs come with a set of out-of-the-box reverse shell and listeners. These are basically pre-installed tools and scripts that can be configured to have the pwnie connect to the external VPS using different protocols, ports and tunneling techniques discussed earlier.
Obviously, the shells and listeners have to be pre-configured before shipping the pwnie. Once booted on the network, the pwnie device will constantly try all enabled shell configurations to connect to the VPS.
Listeners are scripts that handle the different reverse shells. They are downloaded upfront from the Pwnie and installed on the VPS. When the customer plugs in the Pwnie, the listener(s) are started on the VPS and we then wait for the Pwnie to connect.
Below is a sample session with the HTTP shell/listener. As explained earlier, this shell will encapsulate the initial SSH tunnel inside plain HTTP requests (see later).
First, we launch the HTTP listener …
Once connected, we can SSH from the VPS into the Pwnie via the reverse tunnel (here via port 10103) and are basically on the remote network.
IP configuration
Host on the subnet
By sniffing the traffic on the pwnie we can inspect the data streams between the Pwnie and the VPS.
Below is the traffic generated using the HTTP reverse shell/listener. Note that these are ‘normal’ HTTP POST requests with the SSH tunnel data packed in the body.
HTTP Stream
Sample HTTP Request
Using the ICMP reverse shell results in a stream of ICMP packets.
Firewalls should be able to detect and block these ‘suspicious’ traffic flows, but even then, there are several other options. One option is to configure and use a HTTPS shell that might pass if HTTPS is not inspected at all. We also have seen instances where state-of-the-art firewalls were misconfigured and could be tricked in allowing HTTP over port 443 or HTTPS over port 80 …
And in the end, if all of the above fails and since this is not a Red Team, we could still ask the customer to whitelist our box ?
Malicious hacktivity
Obviously, the same principles and techniques as described above are also used by more malicious actors. Hackers and malware within your network will typically try to use these tunneling techniques to hide their tracks, exfiltrate data, contacts C2 (Command & Control) servers, …
It is crucial to detect and block this kind of suspicious traffic as soon as possible in order to identify and isolate possibly infected hosts.
Following some commonsense guidelines can already greatly reduce the risk and make things much harder for hackers and malware to contact their homes …
By default, restrict all outbound traffic and only allow what is necessary.
- Always try to use a whitelisting approach: e.g. if a DMZ server needs an outbound connection to an external service (for updates, data retrieval, …) then only allow outbound traffic from the source to the destination over the protocol/port used.
- Make sure that your network equipment has the capabilities to inspect, detect and block this kind of traffic. If so, enable and properly configure all those nice features like Deep Inspection (including SSL inspection or decryption), IDS/IPS, …
- A process to review the perimeter logs and alert you about suspicious activity, will help to detect active infections that were not identified by other controls, such as endpoint protection.
As usual, there is no silver bullet and we all know that security only works with a holistic approach. So, make sure to implement all the necessary security controls in order to defend your organization.
Security
The security of our customers is obviously one of our biggest concerns. That is basically also why we do the assessment in the first place. We absolutely want to prevent some malicious actors to abuse this configuration and attack our customers via our backdoor.
We take all necessary precautions to prevent intruders from getting into our VPS or the Pwnie. This is done by systematically patching the Pwnie and VPS, hardening the VPS and SSH implementations, restricting access to Pwnie and VPS, implementing firewall rules on the VPS to limit access to the listeners, logging and monitoring… Also, all SSH sessions, including shells and listeners enforce and require public key authentication.
8. Final thoughts
Even though tele-hacking is a valuable alternative in times of Corona and lockdown, it lacks much of the human interaction. This interaction with both colleagues and customers while doing our testing is very valuable, both for us testers and for our customers (we hope ?).
We really hope to be able to hit the roads very soon again and meet you in person. Take care and stay safe.
A practical checklist
The following is a checklist to consider when reviewing your security:
- Are we only allowing the necessary outbound traffic?
- Are we detecting and blocking malicious outbound connections with deep inspection techniques?
- Are we regularly reviewing the logs of our firewall to detect infections in our network?
How can we help?
Orange Cyberdefense can help you with:
- Scanning vulnerabilities in your infrastructures, systems and IoT, both internal and external
- Performing penetration tests in your infrastructures, systems and IoT, both internal and external
- Advising on remediation of weak spots in your infrastructures, systems and IoT
- Elevating the security posture of your firewall
- Reviewing the security logs of your firewall