2\7\2020

Intro to wifi pineapple and wifiphisher - WIRELESS ASSOCIATION ATTACKS AND captive portals

The Wi-Fi Pineapple and Wifiphisher were the tools of choice for a project on Wireless association attacks, which was done in the end of 2018 and finally came around to do the blog post. Both tools could perform the three common methods for association attacks which are:

1. Evil Twin mimics any existing legitimate wireless network or hotpot in the vicinity to appear like the real one. The way evil twin attack works is having the hacker position near any authentic Wi-Fi access point and discover its SSID and Frequency. The hacker can then replicate the same SSID Frequency as the legitimate Wi-Fi Access point and then use it to lure users to connect to the attacker hotspot by tricking or forcing users on to it.

2. The approach of KARMA is to stand-up an open wireless access point in attempt to have unsuspecting victims connect to the AP thinking it is a legitimate AP. It differs from Evil Twin in the sense that its not targeting or replicating an existing wireless network and instead is named and configured to the attackers liking.

3. Known Beacons is where the attacker monitors Wi-Fi client devices (mobile, laptop, etc.) for beacons. Every wireless enabled device contains a Preferred Network List (PNL). Regardless of the location of a device and with with wireless enabled, every device periodically emits beacons associated with a network on the PNL to check if it is in the vicinity and to automatically connect (if auto-connect is enabled). Once the attacker identifies a given networks information in the PNL beacons, they can stand-up and mimic a wireless network from that PNL. This tricks the client devices to think their home or saved network is being broadcasted and typically attempts to connect to it automatically.

I'd recommend following the Hak5 instructions and video in getting the Wifi pineapple online. (https://docs.hak5.org/hc/en-us/categories/360000979333-WiFi-Pineapple)

Once online, a web interface is provided where you can control and see all the AP's, clients, and configure everything.

5\30\2019

Intel NUC \ ESXI \ usb nics \ pfsense VM \ VLANS

I thought I would share my struggles with deploying my Intel NUC (nuc7i7bnh) environment using VMware esxi and pfsense as a Virtual Machine. The impetus was the desire to downsize from a Dell Precision 690, a monster Workstation with dual Xeon processors which is essentially a server. The fan noise on this machine feels like I'm in an airplane all the time, and considering I work from home, I was desperate to migrate my lab environment to a new silent hardware architecture. I had that server for over 7 years and had not maintained the VM's or updated esxi (still on 5.5), so that motivated me further.

Installing esxi on the NUC is straightforward, use a usb drive with the installer on it and install. Since I am running pfsense as a VM, I wanted to have multiple network interfaces on the nuc and not bottleneck the one interface the nuc comes with and use the 'the router on a stick' method ( 1 nic wan\lan separated by vlans). To avoid that, I purchased a dual 1GB usb nic from Amazon for under $40 dollars to increase my interface count to 3 total nics though this is where the struggles came in. https://www.amazon.com/gp/product/B00D8XTOD0/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Esxi by default doesn't support USB interfaces but fortunately and thanks to the vmware fling community, a team of developers but together the necessary fling to get usb interfaces to work on esxi. They do provide most of the instructions to get it to work though there was 2 critical lines of code that had me banging my head for a few days. The issue was with the persistence script provided, this script is necessary for the functionality of the usb nics since usb devices get identified late in the boot process.

https://labs.vmware.com/flings/usb-network-native-driver-for-esxi#instructions

The 2 lines of code are in bold and italic font in the persistence script below. Make sure you change out the appropriate esxi Port Groups and Switch names as the ones below are the default ones.

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

count=0

while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

do

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

esxcfg-vswitch -L vusb0 vSwitch0

esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

/etc/init.d/hostd restart

/etc/init.d/vpxa restart

fi

Without these 2 lines of code my nuc would identify the usb interfaces though upon reboot the interfaces would not be identified in the esxi gui nor could I make any changes to any of the switches associated to the usb interfaces.

My idea was to control my vlans all from pfsense, I didn't want multiple management GUI's to change\adjust when needed and therefore choosing the right esxi VLAN option is important to getting VLANS to work in esxi. If this sounds like what you are attempting to accomplish as well, then VLAN tagging at the switch level is what you want. This is the VGT (virtual machine vlan tagging) mode and can be explained in this vmware article (https://kb.vmware.com/s/article/1004252). The other method, EST (external switch tagging is when you would have an external switch or device responsible for the vlan tagging after it leaves the esxi environment which is not my case, and lastly, VST mode supports the VLAN tagging coming into esxi but does not support it within the port groups and therefore I believe would not specifically run a VM within a VLAN.

As my port groups show below, my wan or connection coming into my pfsense has the 4095 VLAN id which supports all VLAN tagged traffic, and my lab environment has VLAN 10 assigned.