OPNSense UPnP

Configuring UPnP on OPNSense for many is likely not as straightforward as installing the UPnP service.

While this may open unnecessary ports, this is what my final state was for functional UPnP.

1. Disable IGMP Snooping on your client network(s)

2. Install the UPnP plugin (os-upnp) from System->Firmware

3. Change UPnP to default-deny due to security issues

- Add an allow rule for the required hosts e.g. `allow 1024-65535 192.168.1.10 1024-65535`

4. Firewall->Rules->Your Client Network add

- Rule 1

- Interface: Your client network interface

- Direction: in

- Protocol: UDP

- Source: Clients requiring UPnP

- Destination Port: 1900

- Destination: 239.255.255.250/32

- Rule 2

- Interface: Your client network interface

- Direction: in

- Protocol: UDP

- Source: Clients requiring UPnP

- Destination Port: 5351

- Rule 3

- Interface: Your client network interface

- Direction: in

- Protocol: TCP

- Source: Clients requiring UPnP

- Destination Port: 2189

If this is a Windows device (which is recommended, I suggest limiting to gaming consoles) then you're AntiVirus Firewall may be causing issues.

You also need to set the client devices to use static port mappings - use Hybrid NAT for the least impact on your network's security.

Multi-Host and OS Pivoting Using Secure Socket Funneling

During some recent self-study, I encountered a scenario where I wanted to use WinRM on a machine and couldn't from Kali due to the limitations of Powershell Core. The target machine was also two pivots deep, so I needed a way to move through those networks to connect to WinRM.

My VPN was running on Kali, and while I could disconnect it and switch to a Windows machine, I still wanted tools on Kali to be available.

Secure Socket Funneling (SSF) to the rescue.

But first, an example of what the environment looks like.

Network Layout

This a sample of what the network looks like. Hopefully it's not too difficult to follow.

• Windows Machine
  • VM Network 192.168.11.3
• Kali Machine
  • VM Network 192.168.11.4
  • VPN Network 10.0.1.14
• Target Environment Host A - Linux
  • External IP 10.0.0.100
  • Internal IP 172.16.1.100
• Target Environment Host B - Windows - this machine is running OpenSSH.
  • Internal IP 172.16.1.5
• Target Host C
  • Internal IP 172.16.2.20
• Kali can connect to Host A only.
• Host A can connect Host B only.
• Host A is firewalled and can't listen on on any extra ports on 10.0.0.100

Setting up the SSF Daemons

SSF binaries: https://securesocketfunneling.github.io/ssf/#download

Host B

We need to get SSF onto the machine, so grab the Windows binaries from the SSF website. We can these over using SCP.

To do this, we need to jump via Host A. Assuming we have some way of unzipping on the Windows machine, perform the following:

scp -J root@10.0.0.100 ./ssf-windows.zip user@172.16.1.5:

If we don't have an easy way to unzip the file, you can recursively the directory over using the following:

scp -r -J root@10.0.0.100 ./ssf-windows/extracted/ user@172.16.1.5:

If the host weren't running OpenSSH, you would need to use another method such as WinRM using this same process.

Once complete, we can now ssh in and set up the daemon by doing the following:

ssh -J root@10.0.0.100 user@172.16.1.5

Then followed by kicking off the ssfd daemon to listen on port 63000:

Expand-Archive ssf-windows.zip
cd .\extracted
.\ssfd -p 63000

Host A

For Host A, grab the Linux binaries and them over. This process is the same as Host B but without the jump host '-J' option.

In this scenario, due to the firewall, we only listen on localhost.

scp ./ssf-windows.zip root@10.0.0.100
ssh root@10.0.0.100
./ssfd -p 63000 -l 127.0.0.1

Kali Machine

Since we need to get the traffic through to Host A, we'll use ssh local port forwarding to get around the firewall issue.

The below command sets up ssh to listen on 1111 and forward it to 63000 on Host A:

ssh -L 1111:127.0.0.1:63000 root@10.0.0.100

Now we set up ssfd on our Kali host. Unzip SSF on Kali and from within the extracted folder run:

./ssfd -p 63000

If you have an SSH server running on your Kali host, you could use SSH forwarding from Windows, but I think that's a bit messier.

Windows Machine

SSF supports routing via several intermediate hosts. To do this, we configure the below JSON config file:

{
  "ssf": {
    "circuit": [
      {"host": "192.168.11.4", "port":"63000"},
      {"host": "127.0.0.1", "port":"1111"}
    ]

    }
  }
}

This config does the following

1. Connects to Kali
2. Connect to Host A via localhost on Kali (the SSH local port forward)

Info on configuring the relay hosts can be found at https://securesocketfunneling.github.io/ssf/#how-to-use-relay-servers

Host B is the last hop, so we don't need it in the config. To connect, we run the following:

.\ssf.exe -c config.json -D 9000 -p 63000 172.16.1.5

We now have dynamic port forwarding on the Windows machine listening on port 9000, which is essentially a socks proxy. Dynamic port forwarding isn't necessarily what we want as we need WinRM. With SSF, you can perform both TCP and UDP forwarding.

We can set up SSF to forward to the WinRM HTTP port on 5985:

.\ssf.exe -c .\c.json -L 6666:172.16.2.5:5985 172.16.1.20 -p 63000

And now we can finally connect to WinRM:

$s = New-PSSession -Port 6666 -ComputerName 127.0.0.1 -Credential 'username'
Enter-PSSession $s

Local UDP/TCP Forwarding Example and Notes

I don't think it's evident in the SSF docs, but you can perform multiple forwards much like SSH, and you can forward both UDP and TCP for the same port.

Here's an example of forwarding some Domain Controller ports to a Windows host on Kali a lot of the UDP ports aren't requried but I assembled this with regex and it was easier.

./ssf  -L 445:172.16.2.5:445 -U 445:172.16.2.5:445 -L 636:172.16.2.5:636 -U 636:172.16.2.5:636 -L 389:172.16.2.5:389 -U 389:172.16.2.5:389 -L 464:172.16.2.5:464 -U 464:172.16.2.5:464 -L 139:172.16.2.5:139 -U 139:172.16.2.5:139 -L 135:172.16.2.5:135 -U 135:172.16.2.5:135 -L 593:172.16.2.5:593 -U 593:172.16.2.5:593 -L 3268:172.16.2.5:3268 -U 3268:172.16.2.5:3268 -L 3269:172.16.2.5:3269 -U 3269:172.16.2.5:3269 -L 88:172.16.2.5:88 -U 88:172.16.2.5:88 -L 137:172.16.2.5:137 -U 138:172.16.2.5:138  -p 63000 172.16.1.20

With the above, you could run enum4linux or crackmapexec against 127.0.0.1. Note that you may need to also provide a DC IP for some commands that talk to Kerberos. Check your command's options and if this is required, set it to 127.0.0.1 in addition.

And that's it.

The SSF docs are available at https://securesocketfunneling.github.io/ssf/#home

Depending on the environment, a lot of this can be achieved using SSH forwarding.

Extracting Public IPs from an Azure Tenant

The below one-liner allows you to extract all Public IPs (PIPs) assigned in your Azure tenant. Please note that this only covers PIPs and not address prefixes and other resources. You can easily modify the command to output other resources though.

# Output to console
Get-AzSubscription | ForEach-Object {Set-AzContext -Subscription $_.Name *>$null; Get-AzPublicIpAddress} | Where-Object {$_.IpAddress -ne 'Not Assigned'} | Select-Object -Property Name,PublicIpAllocationMethod,ipAddress,ProvisioningState,Location,ResourceGroupName,Id

and

# Write to CSV
Get-AzSubscription | ForEach-Object {Set-AzContext -Subscription $_.Name *>$null; Get-AzPublicIpAddress} | Where-Object {$_.IpAddress -ne 'Not Assigned'} | Select-Object -Property Name,PublicIpAllocationMethod,ipAddress,ProvisioningState,Location,ResourceGroupName,Id  | Export-Csv -Path .\pips.txt