- Find a partner. If you have trouble, try posting to Piazza.
- Topic assignments: Review the list of topics below and assign each topic a preference score from 0–3 stars. Email your nonzero preferences, along with the uniqnames of you and your partner, to firstname.lastname@example.org by 5pm on Monday, January 16. Let us know if there are connections to your research area (e.g. machine learning or wireless networking), and we'll take these into account when making assignments. Many topics include optional bonus challenges; We'll award extra credit for these in proportion to the difficulty.
- Once you've been assigned an attack, your task is to understand it and write an original exploit. Don't borrow from pre-packaged attack tools; you may, however, use general purpose tools such as disassemblers and packet sniffers. Some vulnerabilities have been fixed in newer software, so you may need to target an old version.
- Per the course ethics policy, you must not test your attack against any systems “in the wild” except as noted. If you need demonstration targets, set up your own isolated test systems or VMs. Construct your demo with safety in mind: it should be difficult to use against real systems even if it were to fall into the wrong hands.
- Teach the class about the attack in a 20 minute presentation on the assigned date.
Be sure to:
- Describe how the attack works, how it was discovered, how it was disclosed, and what danger it poses.
- Talk about how you implemented it, including any technical challenges you faced.
- Give a demonstration of your exploit. (Carefully test your demo first!)
- Draw broader lessons from the attack. What does it teach us about security?
- Discuss defenses against the attack. If the attack has been fixed, describe how similar problems might be averted in the future; if it's still a threat, suggest some defenses that might be investigated in new research.
Note on early topics: Since the first few groups will have limited time to prepare, grading will be relatively generous.
|1/26/16||Control-flow exploitation||Pick a control-flow vulnerability discovered in a major application during the past few years and implement your own exploit. Explain how an attacker would bypassed modern defenses such as ASLR, DEP, and canaries, if applicable. These articles will help you get started. Bonus challenge: Find and exploit an undocumented buffer overflow in a popular program.|
|1/31/17||Compiler Trojan horse||Modify LLVM to implement the self-propagating compiler-resident Trojan horse suggested by Ken Thompson in Reflections on Trusting Trust. Your Trojan should propagate when LLVM builds a new copy of itself, and it should inject a demonstration payload when compiling some standard utility program. Bonus challenge: Make a single Trojan that works with two or more compilers, propagating when each builds itself or the other.|
|2/2/17||Kernel-level rootkit||For the operating system of your choice, construct a rootkit (like the one described here) that operates in kernel mode and hides from standard administrative tools; while running, it should not be visible in the file system, process list, or startup files. Bonus challenge: Implement a minimal hypervisor rootkit that contains a basic payload. You might adapt techniques from SubVirt.|
|2/7/17||Malicious code in websites||Part 1: Build a simple dummy social networking site and use it to demonstrate SQL injection, XSS, and CSRF vulnerabilities. Part 2: Construct an XSS worm to attack your site, like the Samy worm that infected MySpace. Part 3: Implement defenses against each threat. Bonus challenge: Discover an undocumented XSS vulnerability in a popular website.|
|2/9/17||Abusing cookies||Part 1: Build a simple dummy website and use it to demonstrate XSS-based session hijacking and session fixation vulnerabilities. Explain some basic defenses against these attacks. Part 2: Demonstrate how the evercookie technique combines multiple persistence mechanisms to resist deletion. Part 3: Evalute a popular browser’s private browsing mode and explain how attackers might be able to bypass them.|
|2/14/17||Smartphone spyware||Develop a demonstration spyware program for Android or jailbroken iPhones. Your program should illustrate the dangers of surreptitious data theft, recording, photographing, and location tracking. Think like an attacker: How would you convince users to install the software? How would you conceal it? How would you exfiltrate collected data? Make your demo as realistic as possible. Bonus challenge: Show how such spyware can be automatically installed to a user’s phones by malware running on the user’s computer.|
|2/21/17||CAPTCHA cracking||Start with a simple CAPTCHA (like one of these) and create a program that reliably defeats it. Extend your work to defeat a CAPTCHA used by an Alexa Top 500 site. You might adapt some of the techniques used by this work or this work.|
|2/21/17||Password cracking||Implement a fast password cracker based on the Rainbow Table data structure (more details here). Compute a table containing SHA-1 hashes for as many passwords as you can (assuming a length of 8-characters or less). Adapt the wordlist and letter frequency approaches used by programs like John the Ripper. In class, demonstrate that you can quickly recover passwords from the leaked LinkedIn password database (or another recent leak). Explain the time-memory trade-offs you faced and how you chose the parameters for your implementation.|
|2/23/17||Fooling web users||Build a simple mock bank site and demonstrate: (1) an SSL stripping attack, where a man-in-the-middle transparently proxies HTTP requests and rewrites HTTPS links to point to look-alike HTTP links; (2) a clickjacking attack, as described here; (3) picture-in-picture and homograph attacks; (4) enhance your SSL attack to demonstrate the null prefix vulnerability (I’ll provide a cert) and to defeat OCSP revocation.|
|3/7/17||DNS cache poisoning||Implement Dan Kaminsky’s fast DNS poisoning attack (another description), where the attacker brute forces responses to insert a false IP address into a DNS cache. Demonstrate the countermeasure described in this paper.|
|3/9/17||Rogue wireless access point||Modify an open-source wireless access point to conduct a man-in-the-middle attack against users who connect through it. Whenever a binary is downloaded via HTTP, modify it on the fly to insert a Trojan horse. I will provide a Linksys WRT54G router.|
|3/14/17||Firmware-resident malware||Demonstrate the potential harm of malicious firmware attacks in the context of a digital camera, using the CHDK framework: (a) Reprogram the camera so that it refuses to take a picture whenever a particular symbol (chosen by the attacker) is visible in the frame; and (b) steganographically embed the time (and location, if the camera has GPS) when each picture is taken in the pixel data, so that it cannot easily be stripped out or decoded by anyone except the attacker. (Other firmware-based attacks would also be acceptable; see me to discuss your ideas.)|
|3/16/17||Malicious peripherals||I’ll provide a PIC development board that can act as a man-in-the-middle between a PC and a USB device. Program it to simulate the behavior of any two of these malicious peripherals: (1) a keyboard that stores the last n keystrokes and replays them when you type a “secret knock”; (2) a printer that detects official election results and alters them, by shifting votes, to benefit a preset candidate; (3) a drive or a card reader that behaves normally, except during bootup, when it acts like a bootable disk containing malicious code. Bonus challenge: Build your own hardware, and conceal it inside a real peripheral.|
|3/21/17||TLS information leakage||Implement the BEAST, CRIME, or Lucky 13 attack against TLS. Explain how modern implementations attempt to defend against such side channels, and what the limitations of these defenses are.|
|3/23/17||Cold-boot attack||Targeting a popular disk encryption product, implement the attacks described here. Your tool should recover memory contents after a cold reboot, locate the encryption keys, and provide access to the disk contents. You may use existing memory imaging tools as part of your implementation. Bonus challenge: Target a moden system with DDR3.|
|3/28/17||Web tracking||Part 1: Implement and demonstrate CSS history sniffing, timing-based history sniffing, and browser fingerprinting. Part 2: Select a widely deployed web beacon and instrument your browser to monitor it. Display the data the web bug reports as it tracks you across various popular sites. Explain how sites could use client-side tracking to show targeted ads with far less invasion of privacy.|
|3/30/17||Traffic deanonymization||Consider a simple anonymizer service, in which clients use SSH tunnels to connect to a SOCKS proxy. Eve is monitoring some of the clients and wants to determine which of them visit a particular website. She enlists the help of Mallory, a man-in-the-middle on the web server’s upstream connection. Mallory inserts a watermark into the server’s outbound traffic—say, by manipulating packet timing to create jitter with a distinct distribution—and Eve tries to detect the watermark in each client’s inbound traffic. Demonstrate this attack, and introduce traffic analysis. Bonus challenge: Demonstrate it against Tor.|
|4/4/17||Rowhammer||Rowhammer is a hardware bug that allows attackers to manipulate data in memory without accessing it. More specifically, by reading many times from a specific memory location, somewhere else in memory a bit may flip (a one becomes a zero, or a zero becomes a one). Implement the rowhammer attack.|
|4/6/17||Hacking Smart Homes||We read the SmartThings Security analysis paper in week 2. Replicate the SmartThings attack.|