courses

Final Project CS596

Due Date: Friday of Finals Week

Option 1: Suricata

Introduction

So you have suricata installed. Now what? In mid-2020, JSOF released a series of vulnerabilities dubbed Ripple20 (PDF) (BlackHat presentation (PDF)). In late 2020, MS released a CVE dubbed Bad Neighbor, which is basically the Ping of Death but for IPv6. Fixing these vulnerabilities is difficult given the install base, variants of Treck used, and mission-criticality of some of the devices in question. In other words, this becomes a network filtering problem. Enter suricata!

What you must do

Pick one of the following CVEs: CVE-2020-11901 (Variant 1), CVE-2020-11901 (Variant 2), CVE-2020-11896, or CVE-2020-16898.

  1. Write a high level description of the vulnerability.
  2. Write a suricata rule to detect it. Most of these will actually require a script written in Lua to be part of the rule.
  3. Write up a document detailing your rule, your script, and why you believe that it will work.

OK, so it’s worth pointing out here that I helped write the commonly used rules for 4 of these 5 vulnerabilities, and logic checked the 5th – in other words, they are out there, publicly available. Try to do this on your own, but feel free to get a hint here or there as you need it. Just remember, you need to be able to explain it in your write-up!

Resources

Suricata rules description. Suricata Lua support.

What to turn in

You will be submitting this via your gitlab repo, in a markdown file called final/final.md. This should contain the high level description of the vulnerability, the suricata rule, and the Lua script. You should also include a pcap file that demonstrates the rule in action. This pcap file should be named final.pcap and should be in the final directory of your repo.

Option 2: Active network tap

Introduction

Don’t want to do the suricata work, eh? Well, that’s fine. Let’s do something else then. Let’s do a little bit of network MiTM (monster in the middle). But let’s do it via hardware! The inspiration for this idea is the Hak5 Packet Squirrel.

What you must do

Take the platform of your choice, and ensure you have multiple NICs available on it. You will be creating this MiTM as a transparent network tap, with optional packet modification. You will need to perform the following tasks:

  1. Create a network tap that will passively monitor traffic on a network. This should be able to handle at least 100Mbps of traffic without noticeable latency. The packets should be stored on the local device for later analysis, with optionally the ability to forward them to a remove device via the WiFi interface (if available).
  2. Create a proof of concept “attack” that will modify all TTL values in packets passing through the device. Set them all to 65.
  3. Create 2 additional proof of concept attacks that do some other active packet modification.
  4. Write it all up and document it.

What to turn in

You will be submitting this via your gitlab repo, in a markdown file called final/final.md. This should contain the high level description of how you went about the setup of the device, as well as the proof of concept attacks. You should also include a pcap file that demonstrates the rule in action. This pcap file should be named final_x.pcap (where x is an integer that maps to attack descriptions in your document) and should be in the final directory of your repo.

Option 3: AirSnitch

Introduction

Don’t like Suricata or MiTM attacks? OK, here’s another option: let’s abuse WiFi!

What you must do

Take a look at the AirSnitch attack. It’s all about how to make WiFi just as open as bare Ethernet. Then, do the following:

  1. Read the paper.
  2. In your own words, explain how the attack works.
  3. Work through the scripts they offer as PoC code, and explain what each does, and why it shows what it claims to show.
  4. Looking at the NetSec network in the Fishbowl, snag the camera stream being watched by one of the WiFi clients. (I’ll set this up and tell you which host if you let me know you are doing this exercise)
  5. Write about what you did and how you did it, and describe how you did step 4.

What to turn in

As usual, you will be submitting this via your gitlab repo, in a markdown file called final/final.md.