Assignment 3 - Research Project

Description

The Research Project is the deep-dive counterpart of the survey-style assignments in this course. Instead of describing what a vulnerability does, each group must understand why it exists and rebuild the exploit from first principles with code of their own.

You select one vulnerability, read the affected code around the flaw, explain the root cause and the fix, stand up the vulnerable version in a lab you build yourself, and then write your own proof of concept that turns the flaw into a concrete, measurable impact. Running someone else’s exploit script is not a pass condition for this assignment.

The emphasis is on the quality of the analysis and on the reproducibility of what you deliver: a third party must be able to take your material, build the environment, run your PoC, and see the same result.

The assignment is deliberately balanced the other way from how you might expect: the easier a target is to break, the deeper into the codebase you are expected to go. A flaw that takes an hour to exploit must be repaid with a thorough study of why it exists, where else the same pattern appears, and how far the consequences can be taken. A target that takes days to exploit is repaid with the same rigour and earns a bonus. See the scope ladder below.

Learning outcomes

After completing this project you should be able to:

• Read unfamiliar code and locate the exact faulty logic, including the trust boundary it sits on;
• Reconstruct the exploit primitive from the flaw alone, using the advisory and the patch diff rather than a published exploit;
• Reason about mitigations and state precisely which ones your PoC does and does not defeat;
• Assess and justify impact, detectability and remediation, and verify that the patch actually fixes the problem;
• Write a technical security report that another engineer can reproduce without asking you questions.

Choosing a target

Your target must not be the CVE you analysed in Assignment 1: that work already required a proof of concept demonstrating the flaw, so it cannot be the subject of this project.

The target must satisfy all of the following:

• A patched and a vulnerable version of the product are both obtainable, with the fix identifiable as a diff, commit or release change.
• A public advisory or equivalent description of the root cause exists (the fix may be public, a working exploit should not be).
• No mature public PoC exists for the exact flaw. If a public exploit does exist, you must show staff, before approval, what remains for you to do: derive the primitive for a different build, reach a different impact, bypass a mitigation, or analyse a distinct vulnerable code path.
• The product runs in a lab you can build in a machine you control (source build, container, appliance image).
• The faulty operation is in the product’s own code, not in a dependency that it merely bundles or configures. An application that ships a vulnerable library is not a study of that library: pick the project whose code is actually wrong.
• The advisory names a version range covering at least two releases of the product, and the fix was released upstream. Projects without a release history fail here, and the release history is part of what you analyse.
• The scope is one vulnerability and its immediate variants, not a product survey.
• Choose a level you can finish. Simpler targets are graded by exactly the same criteria and carry no penalty; see the effort table below.

Admissible areas include memory corruption (stack, heap, format string, integer, use-after-free), injection and deserialisation flaws with a reachable sink, authentication and authorisation logic errors, time-of-check/time-of-use and concurrency flaws, and parser or deserialisation bugs found through your own fuzzing.

Staff approval is required: submit the target, the affected versions, the advisory reference and one paragraph on what you expect the PoC to achieve. The approval message must also state that the target is not your Assignment 1 CVE.

Staff set your required scope at approval. If a target is small or easy to break, expect to be asked for more of it: additional vulnerable paths, the variant sweep extended further, a deeper chain, or a mitigation characterised rather than bypassed. If the scope cannot fit the weeks remaining, staff may ask you to change target. The scope agreed at approval is what you are graded against.

What you must do

1. Threat model and context

State the deployment in which the flaw lives, the assets at stake, the attacker’s starting position and the trust boundary that is crossed. Be concrete about privileges, network exposure and default configuration. Say explicitly whether the flaw is reachable with default settings.

2. Root cause analysis

Walk through the affected code: the entry point, the path to the faulty logic, and the exact operation that is wrong. Quote the relevant code (short excerpts, with file and line references). Show the patch diff and explain why the fix works. Then sweep the rest of the codebase for the same pattern: state how you searched, list the candidates, and triage each one. This sweep is part of the 30% criterion, not an optional extra. State the weakness type (CWE) and the class of bug.

3. Reproducible environment

Build the vulnerable version from source or a pinned image, with the exact versions, commits, compiler and flags recorded. Provide a script or composition that rebuilds it from scratch. Enable debug symbols where possible. Keep the patched version available so you can prove the flaw is gone after the fix.

4. Instrumentation

Show how you confirmed your understanding of the flaw: debugger sessions, breakpoints at the faulty operation, crash triage and stack traces, sanitizers or logging, and the specific values that must be controlled for the flaw to trigger. Crash reports and screenshots are evidence, not decoration: annotate them.

5. Custom proof of concept

Write your own PoC. It must progress from “the flaw is reachable” to “the impact is achieved”, and you must be able to narrate each stage: the input that reaches the sink, the primitive it yields (out-of-bounds read, write-what-where, control-flow hijack, auth bypass, and so on), and how that primitive is chained into an outcome. State which mitigations are present (ASLR, DEP/NX, stack canary, PIE, RELRO, sandboxing, WAF, parameterised queries) and what your PoC does against each. A partial primitive with an honest “we did not get further, here is why” scores better than an undisclosed copied exploit.

6. Impact, detection and remediation

Score with CVSS v4 and justify every vector you chose. Show the impact concretely on data or on a system. Describe how the attack can be detected at network or host level, and how it can be mitigated when patching is not immediate. Verify the patch: run your PoC against the fixed version and show that it no longer works.

7. Report and presentation

Deliver the report and demonstrate the PoC live to the class, with the impact visible.

Deliverables

The PoC material must follow this layout, so that it can be checked mechanically:

report.pdf
environment/
  build.sh          # builds the vulnerable version, pinned commits/versions inside
  docker-compose.yml (if used)
  NOTES.md          # exact versions, compiler, flags, known build caveats
poc/
  README.md         # how to run; expected output; what is safe and what is not
  poc.py | poc.c    # your own code, commented at every stage
  run.sh
evidence/
  crash.log, traces, screenshots   # annotated
patched/
  verify.sh         # proves the PoC fails against the fixed version

The delivered material must contain no build trees, disk images, virtual machine exports, captures larger than a few megabytes, and no credentials of any kind. Raw tool output from the sweep stays out too: keep the candidate list, drop the dumps.

Rules

Groups

Groups of 2 or 3 students. Every member must appear in the target approval message and must have a clearly identifiable contribution. Every member must be able to explain any part of the code and the analysis when asked.

Rules of engagement

Work only against software you have installed in your own lab, in containers or virtual machines you control. Never point the PoC at systems you do not own, including the university network, staging systems or third-party hosts. Keep repositories private, including after the course ends. Do not open issues, pull requests or public disclosures against the affected project unless you have agreed it with staff in advance and followed the vendor’s disclosure process. If you find a previously unknown flaw, report it to staff first.

Custom code requirement

The PoC must be written by the group. Existing tools (debuggers, pwntools, fuzzers, static analysers, sanitizer builds) are expected and encouraged. Any borrowed snippet must be cited in the PoC header and in the report, and you must be able to explain it line by line. Passing a downloaded exploit off as your own is treated as academic misconduct.

Use of generative AI

AI assistants may be used for boilerplate, tooling and wording. They must be declared, with what was used for, in the report. The root cause analysis and the exploit logic must be yours: you will be questioned individually about them, and being unable to explain your own code will reduce the grade for that component.

Language

Report and slides in English. The demonstration may be given in Portuguese or English. English is mandatory if there are non-portuguese speakers in the classroom.

Grading

This project contributes 6 points over the 20-point final grade (see the course grading table), and is graded per group. Bonuses are applied to the group grade.

Bonus for binary-based targets

A target whose vulnerable component is a compiled binary, and whose vulnerable revision you cannot build from upstream source, earns a 10% bonus on the group grade. The bonus is not a reward for difficulty for its own sake but to scale the grading ladder.

All five conditions must hold to qualify:

1. The vulnerable component is native code, and the vulnerable revision is not available to you as source you can compile: shipped binaries, firmware, an appliance image, or a vendor build only.
2. The PoC reaches its impact against the build as the vendor ships it, with the mitigations the vendor enables. Turning mitigations off in a local rebuild forfeits the qualification, unless you also show how to defeat them as shipped.
3. The root cause analysis is done at instruction level: the vulnerable function located in the binary, the faulty operation shown as disassembly with the relevant register and memory state annotated, and the offsets and addresses the PoC relies on explained rather than asserted.
4. The mitigations table in the report is complete, and states what your PoC does against each mitigation present in the shipped build.
5. environment/NOTES.md records the exact binary or image used, where it came from, and its checksum, so the reviewer can obtain the identical build.

If a condition is not met, the work is simply graded in the source-available class. The bonus is withheld; there is no other penalty, and no attempt to argue it back.

Effort, and what level to aim for

Students are not expected to reproduce vulnerabilities harder than a classic buffer overflow unless they arrive with previous training, for example from CTFs or from work. Everything above that level is optional. The 10% bonus for binary-based targets exists precisely because those targets ask more than this course requires.

Choosing an easier target is a legitimate and sensible decision, and it carries no penalty whatsoever. The rubric does not change with the class you pick: a complete, well analysed and reproducible study of an authentication bypass or an injection flaw is a full-mark submission, while an ambitious target left half-demonstrated is not. Judge your own level honestly at the approval stage. If you do have previous experience with binary exploitation, say so: we will expect more from you and question you accordingly, but nothing beyond the stated level is required of anyone.

Two things to keep in mind. The lectures cover heap corruption, ROP and format strings, and explaining those classes is part of the course; building one yourself in the remaining weeks is not. And the binary bonus compensates only part of the extra effort, so it is a recognition that you took the harder route, never a reason to take it.

Scope ladder

The effort table above shows that classes differ by hours. They are brought back in line by required scope, not by points: cheaper exploitation is repaid with more analysis. Your agreed scope is set at approval; the minimum for each tier is below. The tier follows the class of target, not the size of the codebase.

Tier A. Logic, authentication, authorisation, SSRF, configuration and injection flaws with source available. Minimum scope:

• A variant sweep of the whole codebase for the same faulty pattern: the query or tool used, every candidate found, and each one triaged as vulnerable or not with a reason. An empty result is a valid and reportable finding.
• Either a second vulnerable path, or a bypass of one control that really exists in the deployment (input validation, a WAF rule, parameterised queries, an access check). Say what you bypassed and how.
• The chain continued one step past the advisory: what you can do after the initial flaw, in the deployment you built.

Tier B. Classic stack overflows and format string flaws, built locally. Minimum scope:

• The same variant sweep over the available source.
• One rebuild with a mitigation that the vendor ships enabled (stack canary, NX, PIE), then show and explain what changes in your PoC. Bypassing it is not required; characterising it is.
• The exact offsets and values your PoC depends on, explained rather than asserted.

Tier C. Native binaries as shipped, meeting the five bonus conditions. Minimum scope: the bonus conditions themselves, plus the variant discussion performed at the extent the disassembly allows, stating clearly what you could not sweep and why.

Whatever tier you are in, the ceiling is the same: complete, reproducible, well argued. A Tier A submission at full scope is a full-mark submission.

Other recognition

Up to 10% more is given for:

• reaching an impact beyond the original advisory
• defeating a mitigation enabled by default,
• discovering an additional variant of the same bug class
• finding the flaw through your own work

Bonuses do not accumulate. The highest single bonus applies, and the cap is 10%, so the maximum grade for this assignment is 110% of 5 points. Bonus points never raise the final course grade above 20: the cap is applied to the final grade, so a bonus only helps if you still have room below 20.

Timeline

Report template

1. Summary (half page): the product, the flaw, your impact, one figure.
2. Product and threat model: deployment, assets, attacker position, trust boundary, default configuration.
3. Root cause: code walkthrough with excerpts, CWE, the faulty operation, the patch diff and why the fix works.
4. Environment: versions, commits, build flags, instrumentation setup, how to rebuild.
5. Finding the path: how you confirmed reachability (debugger, sanitizers, logs, fuzzing if used), with annotated evidence.
6. The PoC: design, stages, primitives, chained outcome, mitigations present and what you did about each.
7. Impact and detection: CVSS v4 with per-vector justification, observed impact, detection opportunities, mitigation and workaround.
8. Patch verification: PoC executed against the fixed version.
9. Lessons and limits: what you would do with more time, what you did not achieve and why.
10. Contributions and declarations: who did what, tools and code borrowed, AI tools used, sources cited.

FAQ

May we reuse the CVE from Assignment 1? No. That CVE was already demonstrated through a proof of concept, so it cannot be the subject of this project. Choose a different target; the two assignments are assessed independently and may not share deliverables.

We found a bug nobody has reported. Can we present it? Report it to staff first. Public presentation is only possible once the vendor has been contacted and a coordinated disclosure agreement exists.

Do we need full code execution? No. Impact must be concrete and demonstrated; a well-argued out-of-bounds read that leaks memory across a trust boundary is a complete result.

Can we use our own target instead of taking a known CVE? Yes, provided you can bound the work to the previous classes. Agree it at the approval stage.

Can we use a public exploit as a reference? Only if approved at target-approval, and only for a target where substantial work remains for you. It must be cited, and the delivered PoC must be your own.