# Homework 3: Cracking WiFI! For this homework assignment, I will demostrate cracking the `NetSec` WiFi network, and performing some reconissance. I will do this via the `mallory` machine, running kali ## Crack the NetSec WiFi network password with bettercap After connecting to mallory, I start by running `bettercap` on the `wlan0` interface. I then try to turn on wifi reconnaissance. ![start-bettercap](./start-bettercap.png) As issue is returned that bettercap cannot put wlan0 into monitor mode. This is strange, but I work around it by running `sudo iwconfig wlan0 mode Monitor` to do this manually ![manual-monitor](./manual-monitor.png) ### Find the BSSID and connected client of the NetSec Network Running `wifi.show` with bettercap, we see the BSSID of NetSec. That being 28:87:ba:75:7e:93 ![bettercap-wifi-show](./bettercap-wifi-show.png) with `wifi.recon 28:87:ba:75:7e:93` I can see the clients of the NetSec network. Here, we see the client with BSSID 70:f7:54:ff:1c:59 ![bettercap-wifi-recon](./bettercap-wifi-recon.png) ### Perform a deauth attack on the network with bettercap and capture the 4-way handshake With `wifi.deauth 70:f7:54:ff:1c:59` I can send a deauth message to the above client. We can see this worked, and the handshake was automatically captured ![bettercap-deauth](./bettercap-deauth.png) ### Use the hcx toolsuite to convert the captured handshake to a format that hashcat can understand Using hcxpcapngtool of the hcx toolsuite, I can convent this pcap file to a format hashcat will understand (after copying the file from /root to /home/kai) ![hcxpcapngtool](./hcxpcapngtool.png) ### Crack the password using hashcat and rockyou.txt Finally, I run `hashcat -m 22000 -a 0 -w 3 -o bettercap-cracked.txt handshake.hc22000 rockyou.txt` on the above converted handshake file, to crack the password and write it to `bettercap-cracked.txt`. ![hashcat-running](./hashcat-running.png) After ~7 minutes, we have cracked the password. That being `crackme1` ![cracked](./cracked.png) ### Connect workstation to the wifi network and show using nmtui Now that I have found the password, I can initiate a wifi connection from `mallory` to the NetSec network The first issue encountered was the the network manager was inactive. This is confirmed by running `systemctl status NetworkManager` ![network-manager](./network-manager-status.png) This was fixed by running `sudo systemctl start NetworkManager` Now with `sudo nmtui` I can finally attempt connect to NetSec with the password, `crackme1`. ![nmtui-connect](./nmtui-connect.png) The connection was successfull ![nmtui-connected](./nmtui-connected.png) ## Scan the network with nmap I now want to scan the network to identify the router, and devices connected to the router. A quick check with `iwconfig` and looking at the `wlan0` interface shows that as a client of this router, we are in the subnet `192.168.0.0/24` ![subnet](./subnet.png) Now running `sudo nmap -sn 192.168.0.0/24` (a simple ping scan) we have some interesting results. I've run this a few times on different days to see which hosts are persistant, and less likely to be other students ![nmap](./nmap.png) ![nmap-1](./nmap-1.png) ![nmap-2](./nmap-2.png) ![nmap-3](./nmap-3.png) To summerize this, the interesting devices, excluding ourselves (mallory) are ``` Nmap scan report for Archer (192.168.0.1) MAC Address: 28:87:BA:75:7E:98 (TP-Link Limited) Nmap scan report for bookworm (192.168.0.139) MAC Address: D8:3A:DD:7E:3C:31 (Unknown) Nmap scan report for 192.168.0.47 Host is up (1.2s latency). MAC Address: 70:F7:54:FF:1C:59 (Ampak Technology) Nmap scan report for 192.168.0.240 MAC Address: E4:5F:01:91:0C:52 (Raspberry Pi Trading) ``` We have one router/gateway (archer/28:87:BA:75:7E:98), one persistant client device (bookworm/D8:3A:DD:7E:3C:31). The other devices shown in some of these scans do not seem to persist and are not shown in my last scan which is at the time of writing. I will now scan for open ports on these available devices. Specifically, I will scan the default 1000 common ports. ### Open ports and services on archer As the router/gateway, I do not expect any interesting servcies to be running here. But let us make sure ![archer-scan](./archer-scan.png) As probably expected, our gateway is responding to DNS requests, upnp, and has web interfaces open on http/s. Using ssh tunneling from 192.168.0.1:80 to localhost:8080, I can take a look at the web page on http. As shown, it prompts for a password, but is otherwise unremkable. When looking at the page on https, it is also un-remarkable, and just says that https is not supported and to use http instead. (not shown) ![tp-link-page](./tp-link-page.png) I decided not to try any attacks against the router and will be moving on. ### Open ports and services on bookworm Bookworm is several different services, including an RTSP stream. This is interesting. I will explore the RTSP stream later on ![bookwork-scan](./bookworm-scan.png) ### Open ports and services on khadas Upon scanning, the machine with MAC 70:F7:54:FF:1C:59 revealed its hostname as Khadas and has a port for ipp (printing) service open ssh connection can be made to khadas with default credentials (root/khadas). This is interesting, but I did not find anything related to this assigmnet while exploring the khadas file system. ![khadas-scan](./khadas-scan.png) ### Open ports and services on Raspberry Pi Trading (reterm-i) The only interesting service running here is ssh. Moving on ![rpi-trading](./rpi-trading.png) ### Access the RTSP stream On bookworm, the RTSP stream is available on the RTSP alt port, 8554. Using ssh port tunneling of 192.168.0.139:8554 to mallory, and then to my local machine, I can view this rtsp stream in `mpv` ![stream](./stream.png) #### Camera make, model, brand, capacity, and manufacture date Not much can be understand about the camera hardware directly from RTSP stream information. We can see dimensions, codecs, and pixel formats with `ffprobe` as shown ``` ❯ ffprobe -v quiet -print_format json -show_format -show_streams rtsp://192.168.0.139:8554/cam { "streams": [ { "index": 0, "codec_name": "h264", "codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10", "profile": "Main", "codec_type": "video", "codec_tag_string": "[0][0][0][0]", "codec_tag": "0x0000", "width": 1920, "height": 1080, "coded_width": 1920, "coded_height": 1080, "closed_captions": 0, "film_grain": 0, "has_b_frames": 0, "pix_fmt": "yuv420p", "level": 41, "chroma_location": "left", "field_order": "progressive", "refs": 1, "is_avc": "false", "nal_length_size": "0", "r_frame_rate": "90000/2999", "avg_frame_rate": "30/1", "time_base": "1/90000", "start_pts": 14270, "start_time": "0.158556", "bits_per_raw_sample": "8", "extradata_size": 49, "disposition": { "default": 0, "dub": 0, "original": 0, "comment": 0, "lyrics": 0, "karaoke": 0, "forced": 0, "hearing_impaired": 0, "visual_impaired": 0, "clean_effects": 0, "attached_pic": 0, "timed_thumbnails": 0, "non_diegetic": 0, "captions": 0, "descriptions": 0, "metadata": 0, "dependent": 0, "still_image": 0 } } ], "format": { "filename": "rtsp://192.168.0.139:8554/cam", "nb_streams": 1, "nb_programs": 0, "format_name": "rtsp", "format_long_name": "RTSP input", "start_time": "0.158556", "probe_score": 100, "tags": { "title": " " } } } ``` I also tried sending an RTSP describe request, as shown ![describe](./describe.png) Additionally, I explored the web interfaces hosted on 8888 and 8889 and looked at the HTTP network requests. I could not find hardware information about the camera. My best guess is that some sort of "official" raspberry pi camera is utilized for this stream. Particularly one that is newer or of higher quality based on the 1080 HD stream.