final pt5

This commit is contained in:
David Westgate 2024-06-13 01:38:41 -07:00
parent 6b62de7d35
commit ab6835ceeb
5 changed files with 35 additions and 1 deletions

View File

@ -155,6 +155,40 @@ Like before, discarded/dropped frames number only 1 or 2 over a period of severa
Now it is time to do something interesting with pitap by capturing and forwarding the traffic.
The script [`capture.py`](./capture.py) is intended to do just this. Using scapy, the script works by sniffing all traffic on an interface provided from arguments, and saving those to a unique timestamped file. Every time a file is saved, it attempts to transmit them to a supplied ip address and port with the intention that a listening netcat server can capture and save the contents.
The script [`capture.py`](./capture.py) is intended to do just this. Using scapy, the script works by sniffing all traffic on an interface provided from arguments, and saving those to a unique timestamped file. Every time a file is saved, it attempts to transmit them to a supplied ip address and port (defaults to my workstation on LAN) with the intention that a listening netcat server can capture and save the contents.
The professional thing to do here would be to connect the raspberry pi via wifi to an entirely seperate network, or even to set it up as an access point so that way it can communicate with a netcat server running off the network I am snooping on. However, since we are no longer evaluating the transparency of the pitap I will keep things simple for the sake of time by just connecting pitap via wifi to my router again. I will also be running the netcat server on my workstation, which is the same one consuming the RTSP stream from reolink while I capture. This should all be fine, since transmission to the netcat server will be exclusively over wifi and not on ethernet.
Here's what the capture process looks like using the script
![script](./photos/capture/script.png)
In the top left terminal, pitap is running `capture.py` with `br0`. In its current state, this does a scapy sniff for 30 seconds, after which the pcap file is saved and transmitted over a socket connection. In this case, I did not provide an ip or port for that socket, so it defaults to 192.168.0.56:5000 which is my workstation. Also, I manually cut the last capture short to test a graceful stop.
The right terminal is on my local workstation, and I sequentially run `date && nc -l -p 5000 > received_file-{num}.pcap && date`. This causes netcat to listen on port 5000 and save the incoming contents to a file once the socket closes. I run this a few times to coincide with the 30 second capture windows of the script.
On the bottom left is VLC playing the reolink RTSP stream on my workstation to generate some traffic through pitap.
In a real deployment, I would make improvements to the capture script such as adding the ability to fine tune the capture time, cleaning up old captures that have already been transmitted, running the script as a cron or daemon, etc. Likewise, the netcat server could be made smarter by saving better file names, or be converted to a bash or python script to run automatically/perpetually. However, there is more work to do so let's move on.
The end result is that we have 4 capture files now transmitted off the pitap. These are a consitent 7M in size, with the last one being smaller since the last capture was not 30 seconds.
#### Analysis
Here is a look at `received_file-1.pcap` in wireshark. For this capture, I started the stream shortly after capturing, and closed the stream near the end.
![wireshark-1](./photos/capture/wireshark-1.png)
*Top of stream - things look good here, setting up the RTSP connection*
![wireshark-2](./photos/capture/wireshark-2.png)
*Middle of stream - Most of the capture looks like this, a stream of RTP packets from the camera to my workstation. This is expected, aside from the transmissions to an external IP geo-located in northern Virginia...*
![wireshark-3](./photos/capture/wireshark-3.png)
*End of stream - This looks ok too, we see the teardown of the RTSP stream. It also seems that APR packets from the pitap wireless interface are making their way back to `br0` through the gateway, which makes some sense in our configuration*
### 6. Attack

Binary file not shown.

After

Width:  |  Height:  |  Size: 401 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 379 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 403 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 439 KiB