VirtualBox: better to use NAT or Bridged Adapter for a malware test machine?

Some references:
https://forums.virtualbox.org/viewtopic.php?f=8&t=24687
https://forums.virtualbox.org/viewtopic.php?f=6&t=24348
https://forums.virtualbox.org/viewtopic.php?f=1&t=44336
https://forums.virtualbox.org/viewtopic.php?f=2&t=32958
https://www.wilderssecurity.com/showthread.php?t=283264
http://www.dedoimedo.com/computers/virtualbox-network-sharing.html

Looks like I ought to be using Bridged Adapter instead of NAT.

 

http://serverfault.com/questions/490043/differences-between-bridged-and-nat-networking

 

On the other hand see http://www.neowin.net/forum/topic/1193623-install-updates-in-vm/#entry596176165.

 

I was able to ping the host's internal IP address from a virtual machine using NAT mode (and host Windows 7 Firewall location=Public Network), which some online references claim isn't possible.

 

VirtualBox client OS (using NAT) is able to access host's LAN - How come?

 

Using Bridged Adapter in virtual machine, and host Windows 7 Firewall location=Public Network, ping (run from virtual machine) to host's internal IP address failed ("request timed out").

Using Bridged Adapter in virtual machine, and host Windows 7 Firewall location=Home Network, ping (run from virtual machine) to host's internal IP address succeeded.

Using Bridged Adapter in virtual machine, and host Windows 7 Firewall location=Work Network, ping (run from virtual machine) to host's internal IP address succeeded.

Preliminary conclusion: Bridged Adapter might be the better choice if you're using appropriate firewall settings on the host and also appropriate firewall settings on the guest. I'd be glad to hear your opinions on this.

 

I've got bad news for users of NAT mode!

I used Nmap to do a TCP port scan of the host from inside a virtual machine that uses NAT mode. There were a number of open ports on the host reachable from the virtual machine, including some standard Windows ports. The host machine uses Windows 7 Firewall with location=Public (the most restrictive location). Malware on the guest machine could spread to the host via vulnerabilities in any of the reachable open ports on the host.

I also did the same Nmap test but with Bridged Adapter instead of NAT. No open host TCP ports were reachable from the virtual machine . Your results may differ though, depending on the software, software settings, firewall, and firewall settings used on the host machine.

 

Neither? That is, use an internal network.

While I'm no malware expert, it seems like providing any access to the same LAN as the host is a bad idea. Use a pfSense VM as a VPN client, and let the malware-containing VM see the Internet through the VPN.

 

I use host-only adapter, I block everything coming from it with a firewall on my host, and if I want outside connectivity I use an external NAT solution (not the one provided by VirtualBox). Note that this setup is used on an XP host, so I don't know exactly how to do it on a Win7.

Problem with bridged network: you let malware full access to you real network.
Problem with VBox NAT: you cannot control connectivity at will (the way you can do with an external NAT solution).

 

Post #7 at http://forums.anandtech.com/showthread.php?t=2047764 contains a solution that I believe will work for those who don't want to use Bridged Adapter. If you want each virtual machine isolated from each other also (unlike the solution there), then I believe you'll have to use a different pfSense virtual machine, VirtualBox internal network, and subnet for each virtual machine.

 

Here are the open ports listed in an Nmap TCP port scan (all ports tested) of the host (Win 7 x64) from inside a virtual machine that uses NAT mode:
25
110
119
135
139
143
445
465
563
587
993
995
49152
49153
49154
49155
49156

Here are the open ports listed in an Nmap TCP port scan (all ports tested) of a non-existent host from inside a virtual machine that uses NAT mode:
25
110
119
143
465
563
587
993
995

Subtracting these "phantoms" leaves these open ports on the host reachable from the virtual machine:
135
139
445
49152
49153
49154
49155
49156

You can use CurrPorts to see what processes these ports correspond to:
135: C:\Windows\system32\svchost.exe (services RpcEptMapper, RpcSs)
139: System
445: System
49152: C:\Windows\system32\wininit.exe
49153: C:\Windows\system32\svchost.exe (services AudioSrv, Dhcp, eventlog, lmhosts, wscsvc)
49154: C:\Windows\system32\svchost.exe (services AeLookupSvc, Appinfo, EapHost, gpsvc, IKEEXT, iphlpsvc, LanmanServer, ProfSvc, Schedule, seclogon, SENS, ShellHWDetection, Themes, Winmgmt, wuauserv)
49155: C:\Windows\system32\services.exe
49156: C:\Windows\system32\lsass.exe (services EFS, KeyIso, SamSs)

I also verified with Hercules that data sent from inside the virtual machine was indeed received by host.

Note: I disabled a few Windows services in my host, so your results may differ from mine.

 

Is anyone troubled or even bothered by my NAT results?

 

It surprises me you get those results given you have the firewall enabled on the host. I'd also have to understand things a lot better than I do before I can really comment much. In VMWare NAT sets up a separate private network on the host machine, so if it's similar in VBox I don't know why you'd be able to see open ports on the host from the virtual guest It's strange to me but, again, I would need to gain a much better understanding of how it all works.

*EDIT*

Bridged

NAT

https://www.vmware.com/pdf/desktop/ws10-using.pdf

Well I guess it might just be better to go with Bridged mode and use firewalls on both the host and guest machines if security is of paramount importance. But this does have me wondering if those open ports are really host-related and not the private network created by the vm when NAT is used?

 

I wondered about that too. But I used Hercules to open a TCP port on the host. Nmap in the virtual machine found the open port when doing a port scan of the host IP, but not when scanning the virtual machine's IP. Also, I additionally scanned the Win 7 host from a Windows XP virtual machine, which doesn't have some of the same ports open as Win 7 does; I got the same results. And as I indicated in post #11, I successfully sent data from the virtual machine to a port opened on the host with Hercules.

 

I see you answered your own question already. The reason is because to the host's firewall, the traffic appears to be self-traffic and is thus allowed.

 

If you're looking to test your own system, instead of Nmap you could use the simpler SuperScan. You need to change two SuperScan settings though: 1) uncheck "Host discovery" 2) set the TCP scan type to Connect.

 

i might test later on. I'm just taking in the gold medal hockey game now

 

I wonder who knocked my nation (USA) out . Good luck .

 

Not really. There are two possibilities:

1. If your host firewall is not filtering the traffic on the virtual interface that is used for NAT, then the results are normal.
2. I'm not 100% sure how VBox implements NAT, but if they do it at a very low level, than NAT might bypass your host firewall altogether.

If your host has no firewall, then it is normal that ports appear as opened.

 

That's true. But my host does have a firewall (the built-in Windows firewall), with its networks set to Public location, the most restrictive location. When I use a port scanner to scan the host from another physical computer behind my router, no host TCP ports are open (your results may vary though). When I use a port scanner to scan the host from a virtual machine in bridged mode, no host TCP ports are open (your results may vary though). When I use a port scanner to scan the host from a virtual machine in NAT mode, there are various host TCP ports open (see post #11). To me, that's an important difference.

 

I only NAT or bridge pfSense router/firewall VMs. All other VMs use internal networks.

 

The problem is with the way VBox sets up the virtual NAT (because it is NOT working the same as the real thing). I agree that this is an issue, and that is why I recommended in my first post to use external NAT software instead of the virtual NAT that comes with VBox.

 

If one wants VMs to be isolated from one another, there needs to be a separate pfSense VM paired to each VM, right? (I haven't used pfSense before.)

 

I did a further test on this. I restored an older image of my host, one that is vulnerable to MS12-020. This image uses Windows 7 Firewall with network location=Public (the most restrictive location). I turned on Remote Desktop on the host. I installed Metasploit in a virtual machine.

Test #1: virtual machine uses Bridged Adapter
Result: No apparent effect on host when using Metasploit in virtual machine to send specially crafted packets to host's internal IP to try to crash it using vulnerability in MS12-020. This result was expected, since Windows 7 Firewall was using Public network location.

Test #2: virtual machine uses NAT
Result: Blue screen of death on host when using Metasploit in virtual machine to send specially crafted packets to host's internal IP to try to crash it using vulnerability in MS12-020. This result was expected although undesirable, given the results in my earlier posts. The MS12-020 exploit in Metasploit merely crashes computers, but according to http://technet.microsoft.com/en-us/security/bulletin/ms12-020 it's also possible to achieve remote code execution.

Conclusion: data sent from virtual machine is indeed being received by listening process on the host. This may be difficult or impossible to stop when using a virtual machine in NAT mode.

 

What do you guys/gals think should be done about this (i.e. NAT mode) by virtual machine software vendors?
1) nothing
2) note security issues in the manual
3) note security issues in the user interface
4) stop using NAT as default like VirtualBox does
5) something else?