Assignment 1
Due: October 8, 2021 11:55PM
Late penalty: 20% if handed in up to 24 hours late. Not accepted after that.
Hand in: Electronic submit ….. Please upload
your solution keeping the directory structure in a1 and upload to MarkUs, according to the submit checklist.
Marking: see A1MarkingScheme.txt
Groups: Groups of at most size 2.
Note:
This assignment is to be done under the RH7.2 Virtual Machine.
Remember, you prepared this during Lab0
Some code for this assignment is on the VM EXCEPT for account.c and race.c. There is an update below on what to do with these files.
We will run your exploit on unmodified, original source code on a newly installed RH72 VM.
Download a1.zip, extract it, your solution to this assignment will be placed in this directory.
You might want to consider taking a snapshot of the VM before you begin in case you destroy it accidentially.
This assignment is heavily based on last years A1. I am providing you a marking guide which is still available from
last year, but have modified the marks to match this year’s assignment.
The marking scheme from last year can guide you to the right answers, or will be referenced directly in
some questions. Use it to your advantage, this is providing you with a lot of hints and direction. Last year’s
marking scheme and questions form the basis for this year’s assignment. In some cases this will provide guidance
to you, in other cases it will serve as the basis from which you will answer this year’s questions.
Because this is made available to you, we will be a bit more reserved in providing additional hints via piazza though.
[10 Marks] Race Conditions. Replace /questions/race/race.c with the race.c file from the starter code.
Then solve the questions in race.c. You should perform the following steps.
You should then run race as hacker and compare
what happens when you run race as other (non-root) users.
This setuid program (race) will restrict access to the owner of the
file, no matter which owner it is. Since hacker owns it, other non-root
users will not be able to manipulate the file with race. (Find other non-root users
on the VM to try this with).
Find the steps(questions) inside the race.c file.
[25 Marks] Your VM has code installed in /vulnerable.
IMPORTANT: As root on the VM, replace /vulnerable/account.c with this account.c
and then setup.bash. You may have to chmod +x setup.bash
Your task for this question is to identify vulnerabilities, demonstrate exploits and explain the
exploits impact and fix the vulnerabilities. See for example, cert.org vulnerability notes and Common Vulnerabilities and Exposures.
You do not have to exploit buffer overrun vulnerabilities for this part of the assignment, just identify vulnerable code
and explain the potential impact.
Look at A1MarkingScheme, and pick any 10 out of the 20 vulnerabilities listed.
Write a report (see REPORT.txt) listing each vulnerability you choose,
include a collection of exploits for the vulnerability (code, inputs, scripts etc. we can run to
see the exploit in action), the impact of the vulnerability, and identify a category (CIA) for the impact (see the list below).
Include inputs, scripts, code etc. demonstrating each exploit.
To think about this question, consider the following:
Secure properties (CIA)
Confidentiality
Integrity
Availability
In other words: These vulnerabilities include, buffer overruns, integer overflows, canonical naming, directory traversals,…
Once you identify a vulnerability, demonstrate associated exploits (code/inputs). Describe the impact of the
exploit. Impacts include things like denial of service, authentication issues, accountability issues,
priviledge escalation (see principle of least priviledge), …
Finally identify the impact as a violation of Confidentiality, Integrity or Availability and justify your answer.
Hint: Thinking in terms of the above list is a good way to start thinking about potential exploits
and you can map them to the vulnerabilities mentioned in A1MarkingScheme. Look through A1MarkingScheme,
identify 10 vulnerabilities of your choice from this list in the code file, and complete REPORT.txt
Finally fix the code, explaining how you fixed the vulnerabilities and prevented the exploit and restored CIA.
Copy accounts.c to accounts_fixed.c and fix the vulnerabilities you identified.
In REPORT.txt note for each issues whether you have fixed this vulernability
in accounts_fixed.c.
Grading
10 marks for correctly identifying vulnerable code
(be precise, only include vulnerable line numbers, don’t say “addUser() is vulernable to bufferoverrun”,
that is already given to you,
instead provide exact line numbers and examples),
completing the report correctly for each issue and including a fix.
Upto 15 marks for providing exploits for any number of unique vulnerabilities in the original file. (exploit must be listed in REPORT.txt)
==> Your report will contain the writeup, description, examples of the vulernability and notes whether you fixed it, etc. (up to 10 points),
and the exploit, or identify the exploit in the exploit directory which you can create (up to 15 points).
==> You will also provide accounts_fixed.c where you fixed the vulnerabilities. (marks for this are part of the 10 marks for the report).
[12 Marks] xinetd is the internet super server, it can turn any unix program that reads stdin and writes stdout into
a ‘web service’. Take a look at /etc/xinetd.d in the VM to see a collection of programs that
are running under xinetd on your RH7.2 VM. One of these is palindrome.c, please take a look
at /etc/xinetd.d/palindrome to see how this service is run (which port etc). For convenience,
I am having it run out of /root/a1 where you can find the source code as well. Simply recompiling
/root/a1/palindrome.c will cause the online service to update. If you want to restart xinetd you should
execute /etc/rc.d/init.d/xinetd restart.
You will investigate this service, show how
a user from outside the RH7.2 VM (ie on the host machine) can gain unauthorized access to the VM. You might
want to take a look at tcpclient.pl. Fix tcpclient.pl so that it has the IP address of your VM.
(might be already done for you).
Yes, you will have to learn a bit of perl.
[1 Mark] Fuzzing the palindrome service for buffer overruns.
Submit a modified tcpclient.pl, called tcpclientA.pl which explores
the service from the outside and determines if there is a potential buffer overrun vulnerability.
Do this by sending input to the service and seeing what happens.
[5 Marks] Submit a modified tcpclient.pl (called tcpclientB.pl) which obtains a root
shell on the remote server running palindrome. The console user running tcpclientB.pl
should be able to interactively enter commands and see the result.
Note: Entering commands
may not be as smooth as running a real console, this is ok. At the very least, a user should be able to
execute ls a couple of times. To help you, we have supplied makeShellCode.pl.
[1 Mark] Fuzzing the palindrome service for another vulnerability.
Submit a modified tcpclient.pl, called tcpclientC.pl which explores
the service from the outside and determines if there is another potential vulnerability.
Do this by sending appropriate input to the service. This one should be really easy!!!!
[5 Marks] Fix the palindrome service so that it is no longer vulnerable to the two vulnerabilities you found above.
Submit the modified code as well as a discussion of any other changes you feel are
necessary to make the palindrome service more secure. Submit scripts etc. that will allow us to install
your secure version of the service.
[7 Marks] Reverse Engineer Obfuscated Malware
Open instructions.txt in the mystery directory of a1 and answer the questions in it.
You are working at a software security firm. Your team is in charge of
reverse engineering malware. Once a piece of code is identified as malware,
it is important to identify what the malware is doing, how specifically it is doing this
(i.e., does it connect to Command and Control servers to receive new instructions,
which servers is it connecting to, is it replicating or changing itself,
what other nefarious activities is it performing
(e.g., mining cryptocurrency or using CPU cycles for other tasks
on the infected machine, recording audio/video, stealing files and corporate secrets, etc),
when are these actions taking place, etc.).
To avoid detection, malware is often obfuscated (i.e., instructions
are intentionally changed or made more complicated to hide their true purpose).
This obfuscation is not only applied to the malicious pieces of the code
(i.e., the functions that are actually bad), but also all other functionality
that is relatively common (e.g., opening/closing files,
printing to stdout, getting the time of day, etc.).
One of your team members has analyzed two functions in the suspected malware
in order to narrow down what this particular piece of code is doing.
But now your colleague is stuck and comes to you for help.
Use your knowledge of assembly (look up any instructions you don’t know)
to help identify what this piece of code does. (like code tracing, but for assembly).
End of A1