COMP6[48]43 26T1 Assignment 1
Report 1
Marks 15% of overall marks for the course.
Due Date 9am, 30th of March (Monday, Week 7)
Version v1.0.1 (see changelog)
Task
The team at QuoccaCorp has been very impressed to see the progress you have made
this past month. So the executives have decided to ask for an interim document describ­
ing how the company is vulnerable to attack.
In this assignment, you will work in groups of 3 from the same course (i.e. all members
enrolled in COMP6443, or all in COMP6843 ­ combined UG/PG groups are fine) to find as
many vulnerabilities as you can from Topics 1-3 and write a report detailing your findings.
You may only include vulnerabilities in your report from challenges that are tagged
as Reportable in CTFd.
Your report must be submitted as a PDF file to Moodle.
Group Work
One member of your group will need to register your group via this form (https://forms.
office.com/r/skrQ1vVYQv) by 11:59pm, 6th of March (Friday, Week 3). You should also
submit this form if you wish to be randomly placed in a group.
Every year there are always some groups with members who do not meaningfully con­
tribute to their group’s submission. If this is the case in your group, reach out to your tutor
or cs6443@cse.unsw.edu.au as soon as possible, and we will do our best to help resolve
the issue. If you wait until the last minute, there may not be much we can do. We strongly
recommend all groups set up a shared document/workspace early on, on a platform that
tracks contributions (e.g. Google Docs, Microsoft Word via OneDrive, GitHub, etc.).
You will be asked to fill in another form like the one above before starting the second
report, where you can ask to be (randomly) placed in a different group for the second
report.
Correctly following the instructions for the above form and report submission (see
Submission) will award you a 5% bonus for this assignment (see Marking).
Suggested Structure
The report should be made up of the following sections, which are then described in
more detail below. You are welcome to change them as you see fit: combine/separate
them, change their titles, or have entirely different sections; so long as all the necessary
information is covered.
• Executive Summary
• Vulnerability Classification
• For each vulnerability:
1
COMP6[48]43 26T1 Assignment 1 Report 1
‣ Summary
‣ Exploitation
‣ Remediation
‣ Impact and Risk
• Appendix
We would also strongly recommend including a table of contents, with page numbers.
Executive Summary
A key part of this assessment is understanding the audience you are writing for. This
section should be a short (1 page at most) summary of what you’ve done, your findings,
and their overall risk. It should be aimed at executives and managers with little technical
knowledge.
Vulnerability Classification
To help companies prioritise patching vulnerabilities, reports like this one usually include
a method of classifying vulnerabilities according to their risk. Recall from COMP6[48]41
that risk is the combination of impact and likelihood. As a result, this section should
include a risk matrix that will be used to classify your findings, in addition to descriptions
of the impact and likelihood categories.
When classifying impact, it is important to consider both the technical impact (e.g. priv­
ilege escalation) and business impact (e.g. financial losses). For likelihood, you should
consider both the difficulty of the attack, and any access it requires (e.g. if an attack
requires a privileged user, perhaps it can only be performed by an insider).
Below is an example risk matrix and brief descriptions of each category. We would
recommend you start with it, and make changes as you progress through this assignment.
2
Impact
Insignificant Minor Moderate Major Extreme
Possible Low Low Low Low Medium
Unlikely Low Low Low Medium High
Likely Low Low Medium High Critical
Li
ke
lih
oo
d
Very Likely Low Medium High Critical Critical
Impact Description
Insignificant Exploiting this vulnerability cannot affect the company, staff, or users outside of the
attacker’s own information or systems.
Minor Attackers may use this vulnerability to moderately impact individual users.
Moderate Attackers may exploit this vulnerability to affect many other users at once, or severely
impact a targeted user, including account takeover or exfiltrating sensitive information.
Major May lead to total control of the system, exfiltration of many users’ sensitive information,
and/or major damage to a company’s reputation or finances.
Extreme May cause catastophic consequences including irrevokable harm to the company’s repu­
tation/finances and/or total compromise of the organisation.
Likelihood Description
Possible Vulnerability requires special access not publicly available or specific user account(s).
Exploiting also requires detailed knowledge of the organisation, or specific skills/knowledge
of systems that are rare.
Unlikely Vulnerability requires authenticated access and a high degree of technical knowledge or
knowledge regarding the organisation.
Likely Vulnerability is discoverable with moderate recon or requires some technical knowledge and
specialised targeting.
Very Likely Vulnerability is discovered in a high traffic or easy to find location and can be exploited using
off the shelf tooling, potentially automatically.
Table 1: An example risk matrix and category definitions you may use as a starting point.
As you write about your findings, you may feel that this matrix doesn’t quite fit, or that the
impact and likelihood categories are not specific or broad enough, or the definitions could
be improved. For example, a vulnerability that has safety implications (e.g. exploiting
it may result in someone being injured) may warrant a higher impact category than is
available.
Vulnerabilities
Each vulnerability should have its own section, broken up into further sub­sections
described below. Vulnerabilities should be (roughly) in order of descending risk (see
Risk).
Keep in mind that ‘vulnerability’ is not equivalent to ‘challenge’ or ‘flag’. In the challenges
‘Support 1’ and ‘Support 2’, the same vulnerability is exploited. This vulnerability (IDOR)
should only appear once in the report. A similar example would be Payportal 1 and 2 (were
they reportable), where both challenges are solved by exploiting the same SQL injection
vulnerability.
3
COMP6[48]43 26T1 Assignment 1 Report 1
Similarly, the challenges ‘Secrets 1’ and ‘Secrets 2’ have very different vulnerabilities,
even if you must find one to gain administrator access and exploit the other. These
vulnerabilities should each have their own section.
Further, many challenges have very similar, yet distinct, vulnerabilities. For instance,
there are several challenges utilising SQL injection in Topic 3. In this situation, we would
suggest only writing about the most interesting/advanced version of the vulnerability. For
example, you may write a section for an SQL injection that requires an understanding of
the database schema, or bypassing some sort of filtering/protection, rather than the one
that doesn’t, which may be solved with simply ' or 1=1;-- a.
If you are ever unsure about whether a vulnerability should have its own section, get your
tutor’s advice.
Summary
This section should summarise the vulnerability and it’s impact, at a level that someone
unfamiliar with the application or the vulnerability can understand.
Exploitation
This section gets into the weeds of how the vulnerability is actually exploited, and should
be aimed at developers who work on the application. It should be a step by step guide
on exploiting the vulnerability. You should include screenshots and code snippets where
applicable.
In typical bug bounty writeups/penetration test reporting, this is enough, however for
this assignment we would like you to also include your information gathering steps. For
instance, if the final exploit involves accessing a file via a specific path, document how
you determined this path. This is also expected in your exam writeups, so it’s good to get
started now.
Remediation
This section should also be aimed at the developers of the application and should be a
series of recommendations on how the vulnerability can be patched.
These recommendations should be specific to the vulnerability and include as much
detail as possible. Where possible, try to include exact version recommendations (for
patching vulnerable libraries) and/or code snippets (when you have or can make educated
guesses at source code).
It’s also good to provide recommendations of “defense in depth”, i.e. recommendations
aimed at mitigating impact, despite the presence of a vulnerability. An example of this
might be recommending fixing a Cross Site Scripting (XSS) vulnerability, while also rec­
ommending a Content Security Policy (CSP) that will prevent the execution of untrusted
JavaScript code ­ the CSP will ensure that even if the XSS patch is unsuccessful or
another XSS vulnerability is found, it will likely prevent it from being a useful exploit.
Risk
This section should be aimed at people unfamiliar with the application or vulnerability,
similarly to the vulnerability summary. This section is used in justifying the allocation
of resource and priotising the remediation of vulnerabilities, which is why vulnerabilities
should be in order of descending risk.
4
This section should, using the definitions from your Vulnerability Classification section,
justify why this vulnerability is in specific impact and likelihood categories, and then
determine the overall risk from there.
For example, you may justify that an SQL injection vulnerability has ‘major’ impact as
the data contained in the database is personally identifying information and it allows
exfiltrating many users’ data using SQL.
When writing this section, you are free to assume that flags represent some kind of
sensitive information or that you have privileged access. Specifically what kind of infor­
mation or access they represent is left up to your interpretation, based on the context of
the challenge.
For example, for the ‘Support v0’ challenge, the flag is the content of a support ticket for a
bank. Many people provide sensitive information in support tickets, including addresses,
contact details, etc. so it would be reasonable to say that this flag represents the personal
information of a user.
Appendix
This section is for any additions that you want to include but don’t quite fit in a
vulnerability’s section. The main thing we expect in this section is a copy of any long
scripts you wrote to solve challenges. You may also want to include screenshots (beyond
what you included in the exploitation section) or output from automated tools.
Marking
The marking criteria for this assessment has four aspects:
5
COMP6[48]43 26T1 Assignment 1 Report 1
Criterion Description
Breadth (20%) Breadth marks are given for writing about a wide variety of challenges. Breadth
marks are influenced by the difficulty of challenges (i.e. you can either write about
many easy challenges, or fewer hard ones).
The below table outlines an approximate number of stars that we expect you to
write about to achieve the given mark.
Course CR 100%
6443 25 50
6843 35 60
i.e. To achieve a credit in 6443, we’d expect a group to write about vulnerabilities
from challenges that have a total of approximately 25 stars.
Breadth however also encompasses the variety of vulnerabilities written about ­
a report with only SQLi vulnerabilities will receive a lower breadth mark than one
that also writes about other kinds of vulnerability, even if the total number of stars
is the same.
Depth (30%) Depth marks are given for technical detail when explaining vulnerabilities and
exploits. Depth marks are not specifically given for challenge difficulty, but it is
easier to write in­depth explanations about more difficult challenges.
Remediation (30%) Remediation marks are given for the quality of your remediation recommendations.
This includes their accuracy (would they patch the vulnerability) and technical
detail (see Remediation for suggestions).
Presentation (20%) Presentation marks are given for how the report is presented. This includes for­
matting, ease of reading, and keeping in mind the target audience of each section.
Table 2: Description of marking criteria.
The marking does not differ between COMP6443 and COMP6843 except that
COMP6843 will have a higher expectation on the quality of Breadth (expecting more
difficult challenges) and Depth (expecting the extra depth that comes with harder chal­
lenges).
In addition to the above, following all the instructions for group registration and report
submission (see Group Work and Submission) will award you a 5% bonus for this assign­
ment (note that your mark is capped at 100%).
Submission
Your report must be submitted as a PDF file to Moodle. You may choose to use Google
Docs/Microsoft Word/LaTeX/Markdown/Typst/etc. but you must export to a PDF file
before submission.
Only one person from your group needs to submit, and your first/title page must include
the full names and zIDs of each person in your group.
Due Date and Late Penalty
This assignment is due at 9am, 30th of March (Monday, Week 7). Short extensions are
not available.
Following the standard UNSW late policy, you may submit up to five days (120 hours)
late. The penalty for late submission of this assignment is 5% of the maximum marks
deducted per day. For example, if an assignment is given an 83 (out of 100), but it had
6
been submitted two days late, the late penalty will be 10 marks, resulting in a mark of 73
being awarded. You cannot submit later than 5 days after the due date.
Plagiarism
UNSW takes plagiarism very seriously and if you are found to have engaged in plagiarism
there can be major penalties. Plagiarism at UNSW means using the words or ideas of
others without giving clear credit, i.e. passing them off as your own.
You should read the full text of UNSW’s policy regarding academic honesty and plagia­
rism: https://www.student.unsw.edu.au/plagiarism
If you have any questions about any of this please ask us. You really don’t want to
accidentally fall foul of the plagiarism rules.
Use of AI
In completing this assessment, you are permitted to use standard editing and referencing
functions in the software you use to complete your assessment. Students are permitted
to use translation, spell­check, and grammar correction tools only. You must not use any
functions that generate or paraphrase passages of text or other media, whether based
on your own work or not.
If your convenor has concerns that your submission contains passages of AI­generated
text or media, you may be asked to account for your work. If you are unable to satis­
factorily demonstrate your understanding of your submission you may be referred to
UNSW Conduct & Integrity Office for investigation for academic misconduct and possible
penalties. For more information on Generative AI and permitted use please see: https://
www.student.unsw.edu.au/assessment/ai
Changelog
• v1.0.1 (2025-03-03) : Fixed cross­tutorial groups note from last year.
• v1.0.0 (2025-03-03) : Initial release.
7

学霸联盟