The provided VM runs the following services:
On TCP port 7070, the server accepts appropriate input from a remote client in order to execute a specific linux command. The server program appears in three different versions:
- version 1: The server accepts from a client appropriate input and performs an nslookup linux command to get information about a specific domain.
- version 2: The server accepts from a client appropriate input and performs a ping linux command to find out if some ip address is reachable from the server. Only IP addresses should be allowed
- version 3: The server accepts from a client appropriate input and performs a curl linux command to get information about a specific url and check if it is reachable from the server.
- version 4: The server should accept from the client appropriate input to view the files of the folder test
You can find the code for this server in Listing-1. The program has a vulnerability.
- a) Identify the vulnerability.
- b) Exploit the vulnerability in order to:
- version 1: Recover the /etc/shadow file in Linux.
- version 2: Get a reverse shell from the server back to a malicious client thus giving this client shell access to the server
- version 3: change the privilege level to read, write and execute for all files in the folder called hidden
- version 4: add a user to the linux system called nuser
- c) Change the code so it is no longer vulnerable to the identified attack.
On TCP port 6061 to 6065 (depending on the version), the server runs a network wrapper for a legacy program without networking capability to allow access through network to this program simple functionality. The legacy code authenticates users and retrieves the content of corresponding file for the authenticated user. You can find the code for this server in Listing-2 and Listing-3. The legacy program is vulnerable to several vulnerabilities. Note that there are 5 versions of the above server, each one of them is a little different from the others.
- a) Exploit some vulnerabilities and get a reverse shell from the server to your client.
- b) Exploit some vulnerability and get access to the file without having knowledge of a username and a password.
- c) Change the code so it is no longer vulnerable to the identified attacks.
Info: How to choose the correct version to work with?
In the link that exists in the Moodle, place your studentID and then click on the download button to get the versions for the above tasks that you will be using for the assignment. In the provided VM the files of each version have the following names:
- T1,1 version 1 : filename to execute codeserver1
- T1,1 version 2 : filename to execute codeserver2
- T1,1 version 3 : filename to execute codeserver3
- T1,1 version 4 : filename to execute codeserver4
- T1,1 version 1 : filename to execute codeserver1
- T1.2 version 1 : filename to execute asgm1_serv1 and port 6061
- T1.2 version 2 : filename to execute asgm1_serv2 and port 6062
- T1.2 version 3 : filename to execute asgm1_serv3 and port 6063
- T1.2 version 4 : filename to execute asgm1_serv4 and port 6064
- T1.2 version 5 : filename to execute asgm1_serv5 and port 6065
Info: To setup the provided VM (it is an oracle VirtuaBox VM) just double click the file or use file open from the oracle VirtuaBox to include it in the oracle VirtuaBox. Then you can setup the network tab in the VM setting to set the network adapter to Host only adapter mode. You can use a simple client (eg. using netcat) in another VM (eg. one of the VMs that we used in lab 3) to connect to the server inside the assignment 1 provided VM. You need to also set the client VM in Host-only adapter
Mode. Alternatively, you can set both VMs in the same NAT network (as was described in the setup instructions of lab 3). The username and the password in the assignment 1 provided VM is student and fit5003 respectively.
To start any of the servers (i.e. a version of the server) in the main folder of the user account you can find all possible versions of the task 1.1 and 1.2 Use the versions that are assigned to you by executing sudo ./filename
In the Android Studio project that is provided, there is a sketched Android Application that is using a series of Keystore files stored inside the android app internal storage area in order to perform some security related operations. The user should be able to login with a username and password and then get access to a secure SMS service. The Android Application consists of two Activities, a public one (called PrivateUserActivity and a private one called PrivateActivity. When the application start, the activity (PrivateUserActivity) is loaded. The PrivateUserActivity provides text areas for the user to add his username and password and two buttons, an OK button that when pressed transfers the username and password information to the PrivateActivityand a CANCEL button that closes the App. The Application has been created only for a few users and each one of them has his/her own keystore file.
Authentication Mechanism: The PrivateActivity collects the username and password information from the PrivateUserActivity, generates its hash value (uses SHA256) after concatenating username and password strings and uses the first 5 digits of the hash function result as the password of the provided keystore. If the keystore is accessible then the the user is authenticated otherwise a Toast message is generated and the App returns to the PrivateUserActivity.
Inside the keystore there should be entries of at least 3 certificates (public keys) of other users (SMS receivers) and the user’s public key cryptography key pair. The PrivateActivity has a textfield where a mobile phone number can be placed (for sending securely an SMS), a textfield where the SMS message can be written and a textfield where the alias of the public key inside the keystore to be used for secure communication must be provided by the user. Apart from the above, there is also a textview area where information about the alias can be seen.
When the SECURE SMS button is pressed, the following SMS securing mechanism is taking place:
- The public key of the sms message receiver is chosen (using aliases inside the keystore that have the receiver’s trusted certificate)
- A random symmetric key is generated (for AES 256 in CBC mode)
- The SMS message is encrypted using the generated secret key (AES 256 in CBC mode)
- The secret key is encrypted using the receiver’s public key
- The encrypted SMS and encrypted secret key are concatenated
- The result is encoded into a base64 string and the result is sent as an SMS
- After the submission of the message, the digital signature of the message is generated (using the user’s private key)
- This information is been sent as an intent result to the PrivateUserActivity and is visualized using the Toast message mechanism.
Info: A Android Studio starting project is provided in the unit’s Moodle to assist you in the App development. For compatibility reasons, it is suggested to used Android Oreo and test the program in a virtual Nexus 5 device.
Implement the functionality of the Activity PrivateActivity as well as any additional functions needed in PrivateUserActivity so that:
- it collects and processes the information coming from PrivateUserActivity
- it verifies the username and password using the above described mechanism.
- it extracts from the keystore the information regarding the keys and certificates and shows in the textview area of the activity the key aliases, the certificate type and the cipher that is been used.
- the SMS secure transmission mechanism is implemented
- the provided digital signature is returned to PrivateActivity and is printed in the application screen using the Toast class (see relevant code inside the provided Android project)
Based on the existing design approach and functionality that appears on the provided Android Application as well as the code that you have developed to solve Task 2.1 explain possible design issues that can compromise the security of this Android Application as well as possible solutions to those problems.