small tweaks

This commit is contained in:
David Westgate 2024-06-15 00:20:08 -07:00
parent c62e3a908c
commit 987ef1d741
2 changed files with 3 additions and 4 deletions

View File

@ -207,7 +207,7 @@ The result is that for a brief period of the wireshark capture while I have the
![ttl](./photos/attack/ttl.png) ![ttl](./photos/attack/ttl.png)
[`final_1.pcap`](./captures/final_1.pcap) demonstrates the result of this attack. [`final_1.pcap`](./captures/final_1.pcap) demonstrates the result of this attack. In an attack like this, setting a high TTL with an invalid destination could overload network resources
#### 6b. HTTP - OK -> NO #### 6b. HTTP - OK -> NO
@ -215,7 +215,7 @@ At this point I realize my approach with a simple scapy script is flawed. Sniffi
To proceed, I will install `nftables` from `apt`, and `netfilterqueue` from `pip`. `nftables` seems to provide stong capabilities at both layer 2 and 3 traffic, and may help with filtering and queueuing to user space. I first considered just using `ebtables` but queueing traffic to user space with that was not non-trivial To proceed, I will install `nftables` from `apt`, and `netfilterqueue` from `pip`. `nftables` seems to provide stong capabilities at both layer 2 and 3 traffic, and may help with filtering and queueuing to user space. I first considered just using `ebtables` but queueing traffic to user space with that was not non-trivial
I want to modify HTTP responses, so I will use the following `nftables` rules (created with the `nft` utility) to place the packets we want to modify into a user space queue (`NFQUEUE`). Then, a python script can accesses, modify, and explicitly send them I want to modify HTTP responses, so I will use the following `nftables` rules (created with the `nft` utility) to place the packets we want to modify into a user space queue (`NFQUEUE`). Then, a python script can access, modify, and explicitly send them
```bash ```bash
sudo nft add table bridge filter sudo nft add table bridge filter
@ -240,4 +240,4 @@ The final attack will be slightly deeper in the stack. I have written the script
A more sophisticated version of a similar attack might involve buffering a sequence of TCP packets containing a PNG image, carefully modifying those packets to contain a new PNG image loaded from a local resource, and sending the buffer out all at once. This would be a challenge to do on a live tcp stream. A more sophisticated version of a similar attack might involve buffering a sequence of TCP packets containing a PNG image, carefully modifying those packets to contain a new PNG image loaded from a local resource, and sending the buffer out all at once. This would be a challenge to do on a live tcp stream.
Another interesting attack would be to modify RTP packets of my RTSP stream (like shown in section 5) to show a new video feed, still image, play a new sound, or show a modified version of the video feed. This would be an ambitious challenge, and I have not yet taken the Introduction to Multimedia Computing course. Another interesting attack would be to modify RTP packets of my RTSP stream (like shown in section 5) to show a new video feed, still image, play a new sound, or show a modified version of the video feed. This would be an ambitious challenge, and anyways I have not yet taken the Introduction to Multimedia Computing course.

View File

@ -79,7 +79,6 @@ def process_packet(nfqpacket: NFQPacket):
new_css_content = replace_colors_with_random_3(css_content) new_css_content = replace_colors_with_random_3(css_content)
new_encoded_content: bytes = bytes(new_css_content, 'utf-8') new_encoded_content: bytes = bytes(new_css_content, 'utf-8')
# Combine the headers and new body content
new_load = new_encoded_content new_load = new_encoded_content
scapy_packet[Raw].load = new_load scapy_packet[Raw].load = new_load
del scapy_packet[IP].chksum del scapy_packet[IP].chksum