Reference no: EM133063874

UFCFVN-30-M Computer & Network Security - University of the West of England

Symmetric (Secret-Key) Encryption Lab

Aims & Objectives

The aim of this lab is to give students a hands-on experience of using OpenSSL command-line and C libraries, and symmetric encryption (i.e. stream and block) ci- phers. This lab is assessed and consists of 7 tasks. All tasks must be answered. By finishing the lab, students will learn how to use OpenSSL to perform encryption using different ciphers, the different modes of encryption, and the need for padding for some ciphers. Also, the lab will help students learn to practice how to cryptanalyze some ciphers. Additionally, the students will learn the requirements of post-quantum secure ciphers compared to classically-secure ciphers. Special attention should be paid to Section 3 and the What to Submit subsections of each task which list what exactly needs to be submitted for this lab.

Lab Tasks

This section contains the specification of the required tasks.

Task 1: Crypanalysis of Substitution Cipher

This task requires you to decrypt a ciphertext encrypted using the substitution cipher. Since the substitution cipher has a relatively large key space (26! possible keys), brute- force is not effective against such a cipher. Utilizing English language letter and word frequency is a more effective approach in attacking such a cipher.

Task Requirements

You are given the following (highlighted) ciphertext (which can also be found in the text file Task1CT.txt in Blackboard) and your task is to recover the corresponding plaintext using frequency analysis. Note that in practice, spaces as well as numbers and punctuation marks are removed from the plaintext before encryption but to make it easier for you, we have left the spaces in the text.

The following resource might be useful for the frequency analysis:

For substituting the letters, you can use any of the above (or any other) tool of your choice. You can also use the Linux command tr. Below is an example of how we can use the command to substitute 'a' 'Y', 'f' 'R' and 'n' 'T' in the text in the file infile.txt and store the translated text in the file outfile.txt. When doing the translation for this task, it is advisable to use a different letter case from the letters in the plaintext and those in the ciphertext.

Task 2: Using OpenSSL Command-Line

In this task you will explore using the OpenSSL command-line commands to encrypt using different symmetric ciphers and different modes of encryption.

Task Requirements

You need to provide 2 examples of encrypting/decrypting with 2 different block ciphers. What to Submit: You need to include screenshots of the commands/steps you used as well as screenshot of plaintext/ciphertext files content. Also, you are free to include
any interesting observations you have made/learnt from doing the task.
Guidelines

To encrypt/decrypt, you can use the OpenSSL enc command. The general syntax of the enc command is as follows where you replace -e with -d when decrypting:
Note: The symbol is to ensure that we are continuing on the same line and not inserting a newline character.
Where:
-ciphertype: is the name of the cipher you want to use, e.g. -aes-128-cbc,

-aes-256-cfb. To find out the list of supported ciphers, you can run the command man enc.
Inputfile: is the name of the file containing the plaintext if encrypting or the ciphertext if decrypting.
Outputfile: is the name of the file where to output the ciphertext if encrypt- ing or the plainext if decrypting.

KeyValue: is the value (in hexadecimal) of the key you want to use.

IVValue: is the value (in hexadecimal) of the initialization vector (IV) you want to use. Note that this is not required for some ciphers/modes.
Note: If the number you provide as a key/IV is shorter than the required length, it will be padded with zeros to reach the required length. This can be problematic in practice.
To geneate random keys/IVs you can use the OpenSSL rand command. The below example generates a random 16-byte (128-bit) long hexadecimal random value:

If you need help converting between ASCII/hexadecimal, the below examples which use the Linux hex dump tool xxd might come in handy. In all the examples, the option
-p ensures that the output is in plain hexdump style.

ˆ Below is an example of how to convert from hexadecimal to ASCII:
echo "41420a" | xxd -p -r

ˆ Below is an example of how to convert from ASCII to hexadecimal, where we add the option -n so that the echo command does not append the newline character (ASCII code: 0x0a) to the output:
echo -n "AB" | xxd -p

ˆ Below is an example which produces a hexdump of a (supposedly) existing file test.txt:
xxd -p t e s t . t x t

Task 3: CBC mode vs. ECB Mode

This task requires you to compare the use of electronic codebook (ECB) and cipher block chaining (CBC) modes of encryption.

Task Requirements
In Blackboard you will find a BMP image called Task3Image.bmp .

You are required to encrypt this image using AES 128 once in ECB mode and another time in CBC mode.

What to Submit: You need to submit a screenshot of both versions of the encrypted image, the commands/steps you used, and briefly discuss the difference of the quality of the confidentiality of the obtained encrypted images. Also, you are free to include any other interesting observations you have made/learnt from doing the task.

Guidelines

In BMP images, the first 54 characters in the image file are reserved for the header which identifies this image format. Thus, unless you replace the header of an encrypted image, it would not be classified as a valid image anymore. Follow the below example steps to copy the file header from the original BMP image (e.g. original.bmp) and the encrypted image (e.g. encrypted.bmp) into a new image file (e.g. newencrypted.bmp).

1. Copy the first 54 characters from original.bmp to a file named header.
head -c 54 o r i g i n a l . bmp > header

2. Copy the rest of the encrypted image (excluding the encrypted header) into a file named body.

tail -c +55 e n cryp ted . bmp > body
3. Merge the original header and the encrypted body into file newencrypted.bmp.
c a t header body > newencrypted . bmp

Task 4: Plaintext Padding

Since block ciphers operate on blocks of the plaintext, there might be a need to pad the plaintext if its length is not a multiple of the required blocksize. The PKCS#5 padding scheme is widely used by many block ciphers. This task requires you to observe how the different encryption modes use padding.

Task Requirements

In this task you are required to observe how the ECB, CBC, CFB, and OFB modes of encryption use (if any) padding. You can use any block cipher of your choice.

What to Submit: You need to report which of those modes require padding and which do not, justifying your answer in each case. You need to submit a screenshot of the commands/steps you used to reach your conclusion. Also, you are free to include any other interesting observations you have made/learnt from doing the task.

Guidelines

Here you should attempt to encrypt a file containing a plaintext whose length is not a multiple of the block size in question and then attempt to decrypt the ciphertext file and compare the decrypted text with the original plaintext. Note that by default the openssl enc -d command removes the padding when decrypting so that you always obtain the original plaintext when decrypting the ciphertext. To stop the decryption command from removing the added padding, you need to add the option -nopad when invoking the decryption command. Also, you should be aware of any (invisible) special characters, e.g. the newline character, as those would affect the length of the plaintext. Below is an example of using the Linux echo command to write the plaintext ABC (ASCII) to the file plaintext.txt while ensuring no newline character is added.

Task 5: Incorrect use of IVs

It is crucial for the security of block ciphers that the used IVs do not repeat, and to achieve stronger security when using some encryption modes, it is required that the IVs are generated randomly so that they are unpredictable. This task requires you to recover the plaintext from insecurely encrypted ciphertext without knowing the key.

Task Requirements

In this task you are provided with a pair of plaintext (P1) and corresponding cipher- text (C1) which was encrypted with AES 128 OFB mode. Also, we provide you with another ciphertext (C2) corresponding to an unknown plaintext (P2) which was also produced using AES 128 OFB and the same key and IV as that used in encrypting P1. Your task is to use the provided information to recover the plaintext P2. Below is the information you need:

Guidelines

Figure 1 shows encryption and decryption using the OFB mode. Below is an example of how to compute the XOR of 2 hexadecimal values a and b using the Linux command line:
echo $ ( ( 0 xa ˆ 0 xb ) )

The guidelines we provided for the previous tasks might come in handy for answer- ing this task.

Task 6: Brute-Force using the OpenSSL C Library

This task requires you to use the OpenSSL C library to perform a brute-force attack to recover the encryption key.

Task Requirements

We provide you with a plaintext and a corresponding ciphertext (encrypted using AES 128 in CBC mode) as well as the IV used, and your task is to use brute-force to recover the key. You must use the OpenSSL C library for this task as using the command-line commands will not be accepted as an answer for this task.
To make your task feasible, the key we used is an English word and is contained in the file WordList.txt which can be found in Blackboard. Note that if the word (key) is shorter than 16 characters (the required 128-bit length), we have appended the character '*' (ASCII Code 0x2a) to the word to reach the required key length. For example, if the word is hello, the key used is hello***********.

What to submit: You need to submit the recovered key as well as the code you have used to recover the key. Also, you are free to include any other interesting obser- vations you have made/learnt from doing the task.

Guidelines

There are many online resources which explain how to use the OpenSSL C library, e.g.: Also, in Blackboard we included a toy example ToyEnc.c which shows how to en- crypt/decrypt a short message using the OpenSSL library.

Note: When using gcc to compile a program that uses the OpenSSL library, you need to include the option -lcrypto. Below is a command-line example showing how to compile ToyEnc.c.
gcc -o ToyEnc ToyEnc . c - l c r y p t o

Also, be aware of the case of the words when performing your brute-force as the word case of the key you attempt should be as in the provided word list file.

Task 7: Post-Quantum Ciphers (Research Task)

It is well-known that some of the currently deployed cryptographic constructs used in protecting communication cannot withstand attacks by quantum computers and thus as soon as a high-scale quantum computer sees light, such protocols will be immediately rendered insecure. This task requires you to undertake some research regarding how quantum computers would affect currently deployed symmetric encryption ciphers.

Task Requirements

Write a short report (750 words max) discussing how would quantum computers affect currently deployed symmetric encrypting schemes and what measures need to be taken to offer protection against quantum computers in the context of symmetric encryption. Your report should include relevant references from the literature and your discussion should cover efficiency and security aspects, e.g. key sizes.

Public-Key Infrastructure (PKI)

Aims & Objectives

The aim of this lab is to give students a hands-on experience of Public-Key Infrastruc- ture (PKI) and help them understand its benefits, some of its inherent shortcomings, and the possible alternatives. This lab is assessed and consists of 7 tasks. All tasks must be answered. By finishing the lab, students will learn how to issue and deploy digital certificates and how PKI can protect against some attacks. Additionally, the students will learn the shortcomings of (certificate-based) PKI and be able to discuss possible alternatives. Special attention should be paid to Section 3 and the What to Submit subsections of each task which list what exactly needs to be submitted for this lab.

Lab Tasks
This section contains the specification of the required tasks.

Important Note: In some of the tasks you will be required to create a domain of the form UWEFirstNameLastName.com. You need to replace FirstName and LastName with your own first and last names, respectively. For instance, my domain would be UWEEssamGhadafi.com. No marks will be given for the tasks in question if your domain does not correspond to your own name.

Task 1: RSA Key Cryptanalysis

This task requires you to recover the private signing key belonging to a server from partially leaked information and the public key.

Task Requirements

In the file Task1.txt in Blackboard you will find an RSA public key (e, N ) (all in hexadecimal). Also, one of the two prime factors (p) of the modulus N is in the same file. Your task is to recover the private exponent d which would allow anyone to sign on behalf of (and hence masquerade as) the server to whom this key belongs.

What to Submit: You need to submit the value of the private exponent d (in hexadecimal), the code snippet you used, and a screenshot of the steps you used to complete the task. Also, you are free to include any interesting observations you have made/learnt from doing the task.

Guidelines

The lecture slides and lab sheet concerned with Public-Key and Digital Signatures might come in handy when answering this task.

Task 2: Creating a Certificate Authority (CA)

In this task you will learn how to use OpenSSL to create a self-signed certificate for a certificate authority (CA).

Task Requirements

You need to create a key and self-signed certificate for a certificate authority. Some related guidelines can be found in Section 2.2.2.

Important Note: The CA key you generate must be 4096-bit RSA key and the used hash function to self-sign the CA certificate need to be SHA 512.

What to Submit: You need to include a screenshot of the steps and commands you used to complete the task. Also, you are free to include any interesting observa- tions you have made/learnt from doing the task.

Guidelines

To create a self-signed certificate for a CA, we can use the OpenSSL req -x509 to generate a key and self-signed certificate for the CA. The syntax of the command is as follows:
Where:
KeySize: is the desired size in bits of the key.
KeyFile: is the name of the file to which the key will be stored.

CertFile: is the name of the file to which the certificate will be stored.

ConfigFile: is the name of the file containing the configuration. In Blackboard you can find an example configuration file openssl.cnf.
Note that there are other options of the command than the above. For instance, one can choose the hashing algorithm to be used in the signing by adding, e.g.-sha256,
-sha512, -md5, etc.

Using the configuration file (openssl.cnf) requires creating some directories and files. After copying the configuration file into your current directory, you need to create several sub-directories as specified in the configuration file (which can be found under the [CA default] section in the file):
Towards that end, under your current directory create a directory with the name specified in dir. Then under the newly created directory create the above 3 directories (i.e. cert, crl and newcerts). Also, along with those 3 subdirectories, you need to create 2 files: index.txt and serial. The file index.txt can be left empty, whereas in the file serial put a single number in string format (e.g. 1000).
You can also specify the default hash function to be used by modifying the following line in the openssl.cnf file:
Where you can replace md5 with any other supported hash function, e.g. sha256.

When you run the above command, you will be prompted for some information (e.g. Country, Organisation Name, etc.) and a password. You need to remember the chosen password as this will be needed every time you need this CA to issue a certificate. For the other requested details, you can fill them however you want.
To view the content of a certificate, you can use the following command:
Where:
CertFile: is the name of the file containing the certificate.

Task 3: Using your CA to Issue Certificates
In this task you will learn how to use a CA to issue certificates to servers.
Task Requirements

Using the CA you created in the previous task, issue a certificate to a sever. Some related guidelines can be found in Section 2.3.2.

Task 4: Deploying Certificates in OpenSSL HTTPS Server

In this task you will explore how PKI and digital certificates can be used to secure the web. In particular, you will learn how to deploy digital certificates in OpenSSL web server.

Task Requirements

You are required to link the server's certificate you created in the previous task to the server's domain and report the behaviour of the web browser before and after trusting the issuing CA. Follow the guidance in Section 2.4.2 and report your findings.

Important Note: As stated in Section 2.4.2, you must update the file index.html to replace FirstName and LastName with your own first and last names, respec- tively. No marks will be given for this task if you do not do that.

What to Submit: You need to submit a screenshot of the commands/steps you used, and your observations and findings.

Guidelines

To resolve the IP address of the server (i.e. UWEFirstNameLastName.com) for which you have issued your server's certificate, you need to add the following line to the file (/etc/hosts):

Of course, you can use any other preferred editor than gedit, e.g. nano, to edit the file if you wish.
The next step is to launch the OpenSSL web server using your server's certificate.
This can be achieved by performing the following steps:
1. Combining your Server's Key & Certificate:

The aim here is to combine the server's certificate (you created in the previous task) and the corresponding server's key into one file. This can be achieved by the following command:
c a t S e r v e r K e y F i l e S e r v e r C e r t F i l e > NewFileName
Where:
ServerKeyFile: is the name of the file containing your server's key. ServerCertFile: is the name of the file containing your server's certificate. NewFileName: is the name of the file where the combination of key and cer-
tificate of the server will be stored. You can choose whatever name you
wish but it is a good idea to make the extension of the file .pem.

Note that if you are running the above command from a directory different from that where the first two files are stored, you need to provide the full path to those two files.

2. Launching the OpenSSL Web Server:

The aim here is to launch the OpenSSL web server using the combined key and certificate file from the previous step. This can be achieved by the following command:

Where NewFileName is the same file name as that you used in the previous step. Note that the default port on which the server will listen is 4433. This can be overridden by adding the option -accept PortNo to the above command, where PortNo is the port number you wish the server to listen on instead of port 4433. Also, note that you need to the leave the window from which you ran this command open so that the server is still running.

3. Accessing the Server's Web Page:

Assuming you have finished the first 2 steps, download the the simple web page index.html from Blackboard and save it to the same directory from within which you have executed the command in the previous step. Then using an editor of your choice, e.g. nano, gedit, etc., edit index.html and replace

Task 5: Deploying Certificates in Apache HTTPS Server

In this task you will explore how PKI and digital certificates can be used to secure the web. In particular, you will learn how to deploy digital certificates in the Apache web server.

Task Requirements

Similarly to the previous task, you are required to deploy your server's certificate you created in Task 3 in the Apache web server (installed on the UWE VM) and report the behaviour of the web browser. Follow the guidance in Section 2.5.2 and report your findings.

What to Submit: You need to submit a screenshot of the commands/steps you used, and your observations.

and key files, respectively. Note that to edit the above file your need to be a super user. Also, it might be a good idea to backup the file before you edit it just in case things go wrong and you need to revert to the original version.

In order for these entries to be recognised by the Apache server, you need to execute the following steps from the command-line:
1. Testing the Apache configuration file:
This can be done by executing the following command:
sudo a p a c h e c t l c o n f i g t e s t
2. Enabling the SSL module:
This can be done by executing the following command:
sudo a2enmod s s l
3. Configuring Apache for HTTPS:
This can be done by executing the following command:

sudo a 2 e n s i t e d e f a u l t = s s l
4. Restarting the Apache Server:
This can be done by executing the following command:
sudo s e r v i c e apache 2 r e s t a r t

Again, FirstName and LastName are replaced with those of your own.

Task 6: Impersonating a Website (Man-in-the-Middle)
In this task you will explore how PKI could help prevent man-in-the-middle attacks.

Task Requirements
Follow the steps in the guidelines in Section 2.6.2 and report your findings.
What to Submit: You need to submit a screenshot of the commands/steps you used and your observations/findings.
Guidelines

Here you will attempt to impersonate the UWE website www.uwe.ac.uk so that instead of the visitor being redirected to the genuine IP address, they will be redirected to our fake server. In particular, we will redirect the visitor to the server's web page you used in the previous task. Please follow the below steps and report your findings: 1.Add the following line to the file ( /etc/hosts):

Remember that to edit the above file you need to be a super user.

2. As in the previous task, add the 2 entries for www.uwe.ac.uk to default-ssl.conf.

The entries you need to add are identical to those you added for your server in the previous task. The only difference is that instead of the server name being
UWEFirstNameLastName.com as it was for your sever, it will be www.uwe.ac.uk. The rest of the details will remain the same as they were for your server in the previous task. More precisely, add the following entries to the file:

Task 7: Alternative Approaches to (Certificate-Based) PKI (Research Task)

It is well-known that (certificate-based) public-key infrastructure, which relies on using certificates form trusted authorities to ensure authenticity of entities' public keys, has some inherent limitations, such as the high trust placed in the certificate authorities and the overhead associated with revoking certificates. This task requires you to undertake some research regarding alternative approaches to (certificate-based) PKI for managing and distributing public keys.

Task Requirements

Write a short report (750 words max) discussing alternative approaches to (certificate- based) PKI and how they might overcome some of the inherent PKI limitations. Your report should include relevant references from the literature and your discussion should cover advantages and disadvantages of the alternative approaches.

Environment Variable and SET-UID Lab

Aims and Objectives

The learning objective of this lab is for students to understand how environment variables affect program and system behaviours. Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. They are used by most operating systems, since they were introduced to Unix in 1979. Although environment variables affect program behaviours, how they achieve that is not well understood by many programmers. As a result, if a program uses environment variables, but the programmer does not know that they are used, the program may have vulnerabilities.

In this lab, students will understand how environment variables work, how they are propagated from parent process to child, and how they affect system/program behaviours. We are particularly interested in how environment variables affect the behaviour of Set-UID programs, which are usually privileged programs.
This lab covers the following topics:
• Environment variables
• Set-UID programs
• Securely invoke external programs
• Capability leaking
• Dynamic loader/linker

Task 1: Understanding login shells
In this task, we study the commands that can be used to set and unset environment variables. We
are using the Bash shell in the ‘uwe' user account.
The default shell that a user uses is set in the /etc/passwd file (the last field of each entry). You can change this to another shell program using the command chsh (please do not do it for this lab).
Here is the output from the tail of the default UWECyber VM /etc/passwd file:
$ tail /etc/passwd geoclue:x:122:127::/var/lib/geoclue:/usr/sbin/nologin pulse:x:123:128:PulseAudio daemon,,,:/var/run/pulse:/usr/sbin/nologin
gnome-initial-setup:x:124:65534::/run/gnome-initial- setup/:/bin/false
gdm:x:125:130:Gnome Display Manager:/var/lib/gdm3:/bin/false ubuntu:x:1000:1000:Ubuntu,,,:/home/ubuntu:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin sshd:x:126:65534::/run/sshd:/usr/sbin/nologin vboxadd:x:998:1::/var/run/vboxadd:/bin/false uwe:x:1001:1001::/home/uwe:/bin/bash telnetd:x:127:133::/nonexistent:/usr/sbin/nologin

Question: What is the difference between a user shell of /usr/sbin/nologin and /bin/false? Explain the difference.

Task 2: Manipulating Environment Variables

Please execute the following tasks:
• Use the printenv or env command to print out the environment variables.
If you are interested in some particular environment variables, such as PWD, you can use "printenv PWD" or "env | grep PWD".
• Use export and unset to set or unset environment variables. It should be noted that these two commands are not separate programs; they are two of the Bash's internal commands (you will not be able to find them outside of Bash).
Proof: Demonstrate proof of executing the above commands.

Task 3: Passing Environment Variables from Parent Process to Child Process
In this task, we study how a child process gets its environment variables from its parent. In Unix, fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent; however, several things are not inherited by the child (please see the manual of fork() by typing the following command: man fork). In this task, we would like to know whether the parent's environment variables are inherited by the child process or not.
Step 1. Please compile and run the program in Code Listing 1, and describe your observation. Because the output contains many lines, you should save the output into a file, such as using a.out
> child (assuming that a.out is your executable file name and you are testing the child process functionality).

Step 2. Now comment out the printenv() statement in the child process case (Line ?), and uncomment the printenv() statement in the parent process case (Line).
Compile and run the code again, saving the output in another file.
Question: Describe your observations between the two programs and suggest why this may be.

Task 4: Environment Variables and execve()
In this task, we study how environment variables are affected when a new program is executed via execve(). The function execve() calls a system call to load a new command and execute it; execve() does not return on success, and the text, initialized data, uninitialized data (bss), and stack of the calling process are overwritten according to the contents of the newly loaded program.
Essentially, execve() runs the new program inside the calling process.
If the set-user-ID bit is set on the program file referred to by execve(), then the effective user ID of the calling process is changed to that of the owner of the program file.
You should refer to the manual page for execve() for more details about the parameters that are passed to it. Execute the command man execve on the command line to see the manual page for this program.
We are interested in what happens to the environment variables; are they automatically inherited by the new program?
Step 1. Please compile and run the program in Code Listing 2 and describe your observation. This program simply executes a program called /usr/bin/env, which prints out the environment variables of the current process.

Question: Describe your observations of the program and explain what you think is happening.

Step 2. Change the invocation of execve() in Line ? to the following;
execve("/usr/bin/env", argv, environ);
Question: Describe your observations of the changed program.

Step 3.
Question: Please draw your conclusion regarding how the new program gets its environment variables.

Task 5: Environment Variables and system()
In this task, we study how environment variables are affected when a new program is executed via the system() function. This function is used to execute a command, but unlike execve(), which directly executes a command, system() actually executes "/bin/sh -c command", i.e., it executes /bin/sh, and asks the shell to execute the command.
If you look at the implementation of the system() function, you will see that it uses the function
execl() to execute /bin/sh
execl() subsequently calls execve(), passing to it the environment variables array. Therefore, as we saw in the previous task using system(), the environment variables of the calling process is passed to the new program /bin/sh.

Task 6: Environment Variable and Set-UID Programs
Set-UID is an important security mechanism in Unix operating systems. When a Set-UID
program runs, it assumes the owner's privileges. For example, if the program's owner is root, then when anyone runs this program, the program gains the root's privileges during its execution.
Set-UID allows us to do many interesting things, but it escalates the user's privilege when executed, making it quite risky. Although the behaviours of Set-UID programs are decided by their program logic, not by users, users can indeed affect the behaviours via environment variables. To understand how Set-UID programs are affected, let us first figure out whether environment variables are inherited by the Set-UID program's process from the user's process.
Step 1. Write the following program that can print out all the environment variables in the current process.

Step 2. Compile the above program, change its ownership to root, and ma
ke it a Set-UID program.

Step 3. In your shell (you need to be in a normal user account such as uwe, not the root account), use the echo and export commands to check the following environment variables:

Ensure that you change the <YOUR_SURNAME> to be your surname These environment variables are now set in the user's shell process.
Now, run the Set-UID program from Step 2 in your shell. After you type the name of the program in your shell, the shell forks a child process, and uses the child process to run the program.
Please check whether all three environment variables you set in the shell process (parent) are visible in the Set-UID child process.
Question: Describe your observation. If there are differences, describe them and why you think this may be happening.

Task 7: The PATH Environment Variable and Set-UID Programs

Because the /bin/sh program is invoked, calling system() within a Set-UID program is quite dangerous. This is because the actual behaviour of the shell program can be affected by environment variables, such as PATH.
An environment variable such as $PATH is provided by the user, who may be malicious. By changing these variables, malicious users can control the behaviour of the Set-UID program.
In Bash, you can change an environment variable such as the PATH variable in the following way (this example adds the directory /home/uwe to the beginning of the PATH environment variable):
$ export PATH=/home/uwe:$PATH
The Set-UID program in Code Listing 5 is supposed to execute the /bin/ls command; however, it has a security flaw as the programmer only uses the relative path for the ls command, rather than the absolute path:

Please:
• Compile the program in Code Listing 5
• Change its owner to root
• Make it a Set-UID program.
Without modifying the code in Code Listing 5, use this Set-UID program to give you a root shell prompt instead of running ls. Prove that you have gained a root shell by issuing the whoami command in the new shell prompt.
Question: Describe and demonstrate how you gained a root shell by exploiting the security flaw in the program from Code Listing 5

Suggest how the programmer could have avoided the security flaw in the program.

Task 8: The LD_PRELOAD Environment Variable and Set-UID Programs

In this task, we study how Set-UID programs deal with some of the environment variables.
Several environment variables, including LD_PRELOAD, LD_LIBRARY_PATH, and other LD * influence the behaviour of dynamic loader/linker. A dynamic loader/linker is the part of an operating system (OS) that loads (from persistent storage to RAM) and links the shared libraries needed by an executable at run time.
In Linux, ld.so or ld-linux.so, are the dynamic loader/linker (each for different types of binary). Among the environment variables that affect their behaviours, LD_LIBRARY_PATH and LD_PRELOAD are the two that we are concerned with in this lab.
In Linux, LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories. LD_PRELOAD specifies a list of additional, user-specified, shared libraries to be loaded before all others. In this task, we will only study LD_PRELOAD.
Step 1. First, we will see how these environment variables influence the behaviour of dynamic loader/linker when running a normal program. Please follow these steps:
1. We will now build a dynamic link library. Create the program as shown in Code Listing 6, and name it mylib.c.

If we run a program that uses our dynamically linked library it will override the default sleep() function in libc and print our text out instead:

2. We can compile the above program using the following commands (in the -lc argument, the second character is a lower case ‘L' not a ‘1'/'one'):

3. Now, set the LD PRELOAD environment variable so that the system knows about out dynamic link library:

4. Finally, compile the program in Code Listing 7 and call it task8.c. Ensure that it is in the same directory as the above dynamic link library libmylib.so.1.0.1:

5. Make four copies of the executable. Call them task8-a, task8-b, task8-c, and task8-d

Step 2. After you have done the above, please run the task8 executables under the following conditions, and observe what happens. (NOTE: pay close attention to the instructions!). If the program picks up our dynamic library, it should print our text. If it uses the default system sleep() library, then it will sleep for 1 second and return the CLI prompt without printing anything.
1. Leave task8-a as normal program and run it as the normal uwe user.

2. Change task8-b so that it is a root owned, Set-UID program (Use chown and chmod), and run it as the uwe user.

3. Change task8-c so that it is a ubuntu owned, Set-UID program. (ubuntu is another user that is already present in this VM). Run this program as the uwe user.

4. Change task8-d so that it is a root owned, Set-UID program. Change the shell to the root account using the command "sudo su". We are now running this program as the root user in the root account.

Export the LD_PRELOAD environment variable again in the root account and run the
task8-d program.

Question: You should be able to observe two different behaviours in the scenarios described above, even though you are running the same program. Note the different behaviours of the 4 programs here.

Step 3. Explain why the behaviours in the four different programs in Step 2 are different.

Task 9: Invoking External Programs Using system() versus execve() Although system() and execve() can both be used to run new programs, system() is quite dangerous if used in a privileged program, such as Set-UID programs.

We have seen how the PATH environment variable affect the behaviour of system(), because the variable affects how the shell works. execve() does not have the problem, because it does not invoke a shell. Invoking a shell has another dangerous security consequence, and this time, it has nothing to do with environment variables. Let us look at the following scenario.
Bob works for an auditing agency, and he needs to investigate a company for a suspected fraud. For the investigation purpose, Bob needs to be able to read all the files in the company's Unix system; on the other hand, to protect the integrity of the system, Bob should not be able to modify any file.
To achieve this goal, Vince, the superuser of the system, wrote a special set-root-uid program (see Code Listing 8), and then gave the executable permission to Bob. This program requires Bob to type a file name at the command line, and then it will run /bin/cat to display the specified file. Since the program is running as a root, it can display any file Bob specifies. However, since the program has no write operations, Vince is very sure that Bob cannot use this special program to modify any file.

Step 1: Compile the program in Code Listing 8, make it a root-owned Set-UID program. Initially, the program will use the system()command to invoke the ‘/bin/cat' command.

Without modifying the code exploit the security flaw in the program and gain a root shell prompt.

Demonstrate your attack and describe how it works.

Step 2: Comment out the system(command) statement, and uncomment the execve() statement; the program will use execve() to invoke the command. Recompile the program. Make it a root-owned Set-UID again. Does your attack from Step 1 still work?
Question: Please describe and explain the behaviour change.

Task 10: Capability Leaking

To follow the Principle of Least Privilege, Set-UID programs often permanently relinquish their root privileges if such privileges are not needed anymore. Moreover, sometimes, the program needs to hand over its control to the user; in this case, root privileges must be revoked. The setuid() system call can be used to revoke the privileges.

According to the manual, "setuid() sets the effective user ID of the calling process. If the effective UID of the caller is root, the real UID and saved set-user-ID are also set". Therefore, if a Set-UID program with effective UID 0 calls setuid(n), the process will become a normal process, with all its UIDs being set to n.

When revoking the privilege, one of the common mistakes is capability leaking. The process may have gained some privileged capabilities when it was still privileged; when the privilege is downgraded, if the program does not clean up those capabilities, they may still be accessible by the non-privileged process. In other words, although the effective user ID of the process becomes non- privileged, the process is still privileged because it possesses privileged capabilities.

Compile the program in Code Listing 9, change its owner to root, and make it a Set-UID program. Run the program as the uwe user and describe what you have observed. Before running this program, you should create the file /etc/uwe file first.

Question: Will the file /etc/uwe be modified? Please explain your observation as to why or why not the file is able to be modified.

Lab Clean-up
Restore the symlink for /bin/sh to point to /bin/dash which we modified in section 2.7 - Task 7: The PATH Environment Variable and Set-UID Programs

Further research and a real-world case study
Produce a 500 to 800-word report detailing the following:
1. Investigate and explain how the dash shell countermeasures work with regard to dash preventing itself from being executed in a Set-UID process. (Guidance - 200 words)

2. A real-world case study involving security issues with privileged SetUID binaries. For example, CVE-2021-41387 was published on 17th September 2021, which demonstrates that these basic issues security principles can still be lacking today.

Find and research a real-world case study involving SET-UID programs. Explain in your own words what the security incident was, how the incident arose, and any potential mitigations that could have been taken to avoid the issue. (Guidance - 500 words)
You are expected develop your academic writing and to be succinct yet clear in your answer to address the required word count. Your report should include relevant references from the literature, referenced and cited correctly using UWE Harvard style.

Attachment:- Computer and Network Security.rar