Hyperv 1803

[BoogleCloud]

New fork of latest metasploitable3 with update to support Hyper-V as a packer/vagrant provider. Works on the latest 1803 version of Hyper-V (both Win10 and Server 2016).

For the Ubuntu system, Vagrant can't set a known private IP address on Hyper-V (see https://www.vagrantup.com/docs/hyperv/limitations.html) so I added a message when building with Hyper-V on updating the Linux share mount script with the correct IP address. Vagrant certainly knows the IP address of the client as it prints it during the 'vagrant up' phase, but I couldn't find any documentation on how to programmatically access this value. Assuming it can be accessed, it should be possible to dynamically alter the setup_linux_share.bat script before provisioning the Win2k8 system which would allow for more varied networking setups across all Vagrant providers.

For the Win2k8 system, the most major change was that the Hyper-V tools need to be added during the autounattend first boot stage so that the packer provisioner can find it on the next boot. I attempted to do this in a manner congruent with the other builders.

[stewartadam]

Just tried this but installation fails due to lack of network connectivity. Have you set your hyperv-iso switch to External access?

[BoogleCloud]

Which Windows OS are you on? On my Windows 10 1803 client (and 1703 before it), the packer hyperv switch was auto created as an 'internal' switch but with external access through NAT. On my Windows server system, it was easiest to simply create a packer config line with an existing hyper-v switch (removed for the pull request). I can add a note to do that in the config if the packer behavior isn't consistent on at least Windows 10 systems.

[stewartadam]

I'm on Win 10 1803 as well. It created an internal switch, but the machine didn't have a DHCP address and had no external access.

I have used Hyper-V before manually, and also have Docker installed which has its own switch, so perhaps there's some conflict due to that.

[BoogleCloud]

Have you tried manually creating a VM and assigning it to the Hyper-V default switch to see if it gets an IP address? (like a liveboot Linux or something quick)

I'll do a few more tests tonight to try to validate the behavior.

[stewartadam]

I'm also seeing the build script hang near the end of the provisioning:

==> hyperv-iso: Provisioning with shell script: C:\Users\stewartadam\Development\metasploitable3\packer\templates/../../scripts/configs/packer_cleanup.bat
    hyperv-iso:
    hyperv-iso: C:\Users\vagrant>rmdir /S /Q C:\vagrant
==> hyperv-iso: Provisioning with Powershell...
==> hyperv-iso: Provisioning with powershell script: C:\Users\stewartadam\AppData\Local\Temp\packer-powershell-provisioner761680867
    hyperv-iso: =SilentlyContinue : The term '=SilentlyContinue' is not recognized as the name
    hyperv-iso: of a cmdlet, function, script file, or operable program. Check the spelling of
    hyperv-iso: the name, or if a path was included, verify that the path is correct and try
    hyperv-iso: again.
    hyperv-iso: At line:1 char:55
    hyperv-iso: + ... -Path variable:global:ProgressPreference){='SilentlyContinue'};. c:/W ...
    hyperv-iso: +                                               ~~~~~~~~~~~~~~~~~~~
    hyperv-iso:     + CategoryInfo          : ObjectNotFound: (=SilentlyContinue:String) [], C
    hyperv-iso:    ommandNotFoundException
    hyperv-iso:     + FullyQualifiedErrorId : CommandNotFoundException
    hyperv-iso:
    hyperv-iso:
    hyperv-iso:
    hyperv-iso:     Directory: C:\
    hyperv-iso:
    hyperv-iso:
    hyperv-iso: Mode                LastWriteTime         Length Name
    hyperv-iso: ----                -------------         ------ ----
    hyperv-iso: d-----        9/11/2018   5:55 PM                startup
==> hyperv-iso: Uploading C:\Users\stewartadam\Development\metasploitable3\packer\templates/../../scripts/configs/disable_firewall.bat => C:/startup/disable_firewall.bat
1 items:  45 B / 45 B  0s
==> hyperv-iso: Uploading C:\Users\stewartadam\Development\metasploitable3\packer\templates/../../scripts/configs/enable_firewall.bat => C:/startup/enable_firewall.bat

Apart from 'command not found' there doesn't seem to be any other errors that would indicate that it was fatal to the provisioning sequence, but hyperv-iso is stuck there until I ctrl+c.

[BoogleCloud]

So for the switch I confirmed that the packer Hyper-V provisioner will default to any existing External interface if it exists. If not, it will create an 'Internal' type virtual switch without any of the Windows NAT functionality (like the Default switch has) so it has no automatic internet connectivity. I can add a note to the Readme to make sure to have an external switch before running the build.

As for the second issue, that is new and appears related to packer 1.3.0. I replicated it on my laptop which I just updated today, but had not previously seen it with packer 1.2.x. Near as I can tell it is a relic of merging in this issue hashicorp/packer#4916 but I am going to need to do a bit more digging to find out why exactly. It may note be related to Hyper-V.

[BoogleCloud]

Did some more digging and yes, because Packer is provisioning via (non-Microsoft) SSH, some extra escaping needs to be done. Likely this didn't matter with the simpler inline PowerShell command before the referenced Packer merge above.

I added the 'execute_command' option from this document to the window_2008_r2.json template and it seems to work now.
https://www.packer.io/docs/provisioners/powershell.html#combining-the-powershell-provisioner-with-the-ssh-communicaton

[stewartadam]

After digging a bit deeper this looks to be a variable escaping/expansion issue, where the variable assignment meant to be executed inline is instead substituted by the parent shell causing syntax errors. Adjusting the default inline execution (copied from Packers docs here) to use Set-Variable instead has addressed the issue:

{
      "type":"powershell",
      "inline": [
        "mkdir -p C:/startup"
      ],
      "execute_command": "powershell -executionpolicy bypass \"& { if (Test-Path variable:global:ProgressPreference){Set-Variable -Name ProgressPreference -Value 'SilentlyContinue'};. {{.Vars}}; &'{{.Path}}'; exit $LastExitCode }\""
    },

[BoogleCloud]

There is an version of packer released (v1.3.1). I updated to this and it got past the stall point in the build where it was copying the startup script. I set this to be the new minimum packer version in the build script.

I also rebased against the new master commit (basically adding libvirt support on Linux). Both boxes now build correctly on Windows 10 1803, Vagrant 2.1.4 and Packer 1.3.1.

[stewartadam]

BTW - v1.3.1 with the execute_command change works well for me.