CSE 3140
Lab 2 - Malware: Viruses, Worms, and UTMs
Created: Fall 2022; Updated: Spring 2024
Monday sections submit by 10/6
Wednesday sections submit by 10/8
See instructions for all labs in Lab 0.
Hardware Requirements: For questions 3-5, we use the ACL laptops and Rubber Ducky devices; at the end of your lab, please pack the devices up and return them to your TA.
Background Info
Malicious software, aka Malware, is the most serious threat for most users and organizations. Malware is any software that is designed to benefit its “owner”, by running without authorization on a victim’s machine (a phone, computer, server, or other device). Malware can be distributed for different goals, such as Denial-of-Service attacks, exposure of sensitive information, unauthorized use of computing resources (e.g., for mining bitcoins), and many other nefarious goals; the functionality of the malware designed to meet these nefarious goals is called the payload.
Most malware also has functionality for distributing the malware, which we refer to as infection or propagation.
Malware is often categorized by its method of infection/propagation; the categories include:
• Virus: malware which searches the storage to identify other programs, and then changes them so they will contain a copy of the virus and execute it, in addition to their “ real” function. Viruses often infect a specific type of program, such as binary executables, macro files (e.g., of Office), or programs written in a specific language. In this lab you’ll write a very simple virus that will infect Python source-code programs.
• Worm: malware that searches a network to identify vulnerable machines, and then uses the vulnerability to copy itself to these machines (and run also from there).
• USB-Transmitted Malware (UTM): malware which is injected by connecting a rogue device to the USB interface of computer. The rogue device can appear to be a USB memory stick, a USB cable, or a USB charger. After being injected by the USB interface, the malware may further propagate as a worm and/or virus. In fact, many USB memory sticks on the market may be modified to become such rogue devices, using software on a computer to which the USB is connected. In this way, USB-port malware can also propagate on other USB sticks.
• Trojan (horse): malware, which is distributed disguised as a desirable application, relying on users to innocently install them. In a sense, this is the simplest type of malware, as it depends on the user installing it. However, this simple strategy is surprisingly effective. In fact, many smartphone apps, as well as different programs and utilities for computers, are Trojans!
You can find more information about different kinds of malware online, e.g., in thislink. In this lab, we will learn about malware by writing simple versions of a virus, a worm, and a UTM.
An Important Note About Passwords in CSE 3140
The passwords assigned to fictitious users are pulled randomly from areal-life source of leaked passwords that cybersecurity specialists often come into contact with professionally. Unfortunately, many of these passwords contain extremely vulgar and offensive language, and we do not condone their use. We are happy to substitute passwords from artificial sources at your request.
Submitting Code for this Lab
This lab will require you to submit a zip file containing the scripts you created for each of the programming questions. Your code will be graded on correctness, efficiency, structure, and readability. You should save all your .py scripts for questions 1 and 2 within Q1 and Q2 subdirectories within the Solutions directory within the Lab 2 directory. After completing this assignment, you can then:
• Archive the Solution directory by running the following command in your Lab 2 directory:
o zip -r lab2_sol.zip Solutions
• SCP (secure copy) the zip file to your local machine. On your local machine (after logging out of your VM) you can run the following command (you need to replace <vm_ip> and <local_path> with your own VM IP and destination file path on your local machine, respectively):
o scp cse@<vm_ip>:/home/cse/Lab2/lab2_sol.zip <local_path>
• Upload the lab2_sol.zip file you saved to your machine on HuskyCT
Question 1 (35 points): My First (?) Virus
In this question, you will be writing a simple virus. A virus is a program that can “attach itself” to other programs, so that when the other program is run, the virus is also run.
Your simple virus will be a Python script. that attaches itself to (other) source-code Python scripts (.py files) in the same folder. Typically, this is done by searching for other .py files on the same folder, opening each such file, and attaching the virus code to the script. (if it does not already contain the virus code). As a note, practical viruses often attach to machine-code programs, and many attach to different macro/script. files (e.g. MS Office files).
Note: your virus should not re-attach itself to a program which already contains the virus!
This question has three parts. During the first two parts we’ll learn how to implement an aspect of our virus functionality. Then, in part 3, we’ll be ready to construct the entire virus codebase.
Part 1 (10 points):
We will first write a Python script. named Q1A.py, that reads the files in the current (working) directory, and outputs a file, named Q1A.out, containing the names of all .py files, each on a separate line.
Your program should work on both Linux and Windows; you may want to read about, and possibly use, the Python's os module. On your VM, place the completed Q1A.py program in ~/Lab2/Solutions/Q1 directory.
Part 2 (10 points):
Next, write another script. named Q1B.py, that receives as a parameter (on the command line) the name of a .py file in the current directory, e.g., x.py.
Q1B.py should check two things:
1) Is the given Python file a script. (i.e., is it intended to be run directly)?
a. For our purposes, a Python file is considered a script. if it contains an if name == “ main ” : statement
2) Is it uninfected (i.e., does it not yet contain the virus code)?
If both checks are true, then the Q1B script. should re-write the input script. (e.g., x.py), so that the new “x.py” will contain a Python script. with the same functionality as of the original x.py, except that the new script. will also perform. the following simple spyware payload functionality:
Whenever the new “x.py” script. is run, it appends, to the end of a file called Q1B.out, a line containing the entire command line used to invoke it, i.e., the file/script. name (“x.py”) followed by the arguments (parameters) with which the script. (“x.py”) was run, if any. If Q1B.out does not exist when the new “x.py” is run, then “x.py” should create Q1B.out.
Part 3 (15 points):
Finally, we are ready to write the full virus. You should create another Python script, Q1C.py, to house the full virus code. Your Q1C.py must infect every .py script. in the current directory. By “infection”, we mean alter the original .py script. (e.g., x.py) so when the infected “x.py” would be run, it would retain its original functionality, but also have two additional functionalities:
1) The first additional functionality, the payload, is the spyware functionality we
implemented in Q1B. Whenever the modified script. “x.py” is run, it will append the entire command line used to invoke it to the end of a file called Q1C.out.
2) The second additional functionality is the infection functionality. Namely, the modified script. will also have the same functionality as Q1C.py, modifying all .py scripts in the directory in which it runs, by adding the same spyware functionality and infection functionality. Q1C (and the modified/infected scripts) should not modify scripts which have already been “ infected” by our virus.
Helpful tip : In Python, open( file , ‘r’) will allow you to read the file contents of the currently running module. This will be useful for injecting the virus code into the victim script.
Save all three scripts (Q1A.py, Q1B.py and Q1C.py) in the Lab2/Solutions directory, and include them as part of your solution in your lab report that will be uploaded to HuskyCT.
Note: your programs should be highly readable with good documentation.
Submission Requirements
No autograder submission required.
Show your running code to the TA for review and approval! Upload all solution code alongside lab report in a zip file.
In your lab report: Briefly explain how your Q1C works. Be sure to describe how you avoid reinfecting scripts that are already infected and how limit your code injection to only include virus code.
If you cannot get in-person TA approval: provide a screen recording showing its operation, including testing all relevant aspects.
Question 2 (35 points): My First (?) Worm
In this question, you will be writing a simple worm, Q2worm.py. A worm is malware that searches for machines that can be accessed over a network connection and has a specific vulnerability. Once such machine is found, the worm exploits the vulnerability to copy itself to the vulnerable machine, where it executes its payload – and deploys its infection functionality to infect other machines. (Of course, it may also propagate as a virus as well.)
Worm Behavior. Overview
Your simple worm will be a Python program, that uses the SSH and Telnet protocols to find vulnerable machines and infect them (some machines may support SSH, some Telnet, some both). Specifically, your worm will look for machines which have open SSH/Telnet ports and use a user/password pair from the list of “exposed” username-password pairs which you are given, in the file Q2pwd (in the Lab2 directory). Search for machines in the subnet 10.13.4.0/24, i.e., IP addresses in the form. 10.13.4.x where x is between 0 and 255.
Once your worm finds such a machine (and vulnerable account), you should copy the value in the file Q2secret from the home directory of the account, to your VM, in file Q2secrets in directory Lab2/Solutions. If you find several such machines, accounts, and Q2secret files, put all of the “secrets” on separate lines in your Q2secrets file. You should also copy Q2worm.py to
the home directory of the vulnerable VM, and to the Lab2/Solutions directory of your VM. There’s a lot to this question, so we’ll break it down into several incremental parts.
Some Python modules that will be helpful:
• socket– for checking open ports
• paramiko– for establishing SSH connections
• telnetlib– for establishing Telnet sessions
Part 1: Find vulnerable machines (10 points)
Write a function, find_vulnerable_machines, that searches for machines in the
10.13.4.0/24 subnet and outputs two files, open_ssh.log and open_telnet.log. These files should contain a list of IPs that correspond to machines that have open ssh and open telnet ports, respectively.
This function will probably take 10 - 20 minutes to run in its entirety over the whole list of subnet IPs, but you can test your port-checking logic on two known IPs before having your script. loop over all the IPs in the subnet. For testing SSH, your VM IP has an open SSH port. For testing telnet, 10.13.4.4 has an open telnet port.
Part 2: Find vulnerable accounts (10 points)
Write a function, find_vulnerable_accounts, that searches over of the IPs within the log files from Part 1 and finds the user/password combinations from the leaked password database Q2pwd that can be used to successfully log in to the vulnerable machines via either SSH or telnet. Your function should write the exfiltrated SSH/telnet credentials to ssh_accounts.log and telnet_accounts.log, respectively. These files should a line per found credential in the format of IP,user,password (e.g., 10.13.4.4,cse,cse3140).
This function will probably take 10 - 20 minutes to run in its entirety over the whole list of vulnerable IPs, but you can test your credential-checking logic on two known IPs before having your script. loop over all the IPs in the lists. For testing SSH logins, you know the username and password for you own VM. For testing telnet logins, 10.13.4.4 has a cse user with the coursedefault password of cse3140.
Your script. should find 3 vulnerable accounts (NOT including the cse user on 10.13.4.4) in total. It’s possible that you may have all three vulnerable accounts via a single protocol.
Part 3: Extracting Secret and Infecting with Worm ( 15 points)
Write a function, extract_and_infect, that performs the following two actions for each victim (i.e., vulnerable account) found in Part 2:
• Copies the content of the file Q2secret that is held in the victim’s home directory to a file named extracted_secrets.log VM. Your extracted_secrets.csv file end up with one line per victim with the format of IP,user,secret on each line (e.g., an example csv line would look like: 10.13.4.4,cse,test_secret).
• Copies your Q2worm.py malware to the home directory of the victim.
This function should not take long (< 1 min) to run since you will only be working over 3 IP addresses. You can tell if your code is functioning correctly by logging on to each victim’s machine (via the command line with their exfiltrated credentials) and checking their file contents compared to the files in your VM’s Lab2/Q2 directory.
Some helpful hints for transferring your Q2worm.py file to the victim’s machine:
• For SSH connections, utilize SFTP to upload your worm (paramiko has SFTP APIs).
• For telnet connections, you canutilize netcat.
Note : even if your exfiltrated credentials do not use one of the SSH/telnet, your code should include extraction/infection mechanisms for both protocols, as you have servers for testing both SSH and telnet connections.
Putting It All Together
We’ve now completed all the pieces needed to implement our attack. Simply executing each of the above three functions sequentially will yield our worm!
Some Fun History
Similar attacks (and worms) to yours have been found in the wild; often, the worms identify vulnerable machines which were left with default passwords, e.g., home routers and IoT devices. Note that a “ real worm” should follow the “ break-in” step which your worm is doing, by running malware from the victim machine, often running the worm itself, to make the infection more effective and robust to discovery of the “first” machine where the worm began attacking. Worms need to prevent multiple infections of the same machine; lack of attention to this detail can cause excessive overhead – leading to load on the network and discovery of the worm, as happened in the (in)famous and fascinating case of the Morris worm.
Submission Requirements
No autograder submission required.
Show your running code to the TA for review and approval!
Upload all solution code/files alongside lab report in a zip file.
In your lab report: Briefly explain how your worm code: decides whether a machine is vulnerable, decides whether victim credentials are valid on a machine, extracts files via SSH/telnet, and infects the victim machine via SSH/telnet.
If you cannot get in-person TA approval: provide a screen recording showing its operation, including testing all relevant aspects.
USB-Transmitted Malware (UTM)
In the following few questions, you will be writing a simple UTM. If you google it or learned a bit of Complexity Theory, you may think of writing a Universal Turing Machine, but no; we are talking about a very different type of UTM – a USB-Transmitted Malware.
For this task, we will use a Rubber Ducky, a USB device that emulates a keyboard when inserting into a machine. See below the background information on the Rubber Ducky, which you will need to write the scripts for all these questions.
LEGAL WARNING: You may only insert the Rubby Ducky devices into the
dedicated laptops provided by our lab. Inserting the Rubby Ducky devices into any other machines will result in a zero on this lab project (that cannot be dropped) and possible legal consequences.
Background : Rubber Ducky
A device we’ll be using in the rest of this lab is the Hak5 USB Rubber Ducky. The USB Rubber Ducky is a kit that is used for system administration and penetration testing. It is a USB device that looks like a normal flash drive. The ducky registers itself as a USB keyboard once plugged into a computer. It then starts firing keystrokes to execute some commands on the targeted machine. See how to program the Rubber Duckhere; there are also instructions elsewhere, e.g., the following may be helpful:https://blog.hartleybrody.com/Rubber Ducky-guide/.
The goal in this and the following question is to enact changes on your laptop (which will be the victim). Before starting, I encourage you to make sure your laptop is connected to the cse3140 network through the wired switch or the VPN.
We will be creating different inject.bin files which will serve as instructions to the Ducky dongle. The keystrokes are programed using a scripting language called Ducky Script. The script. can be written in any text editor, such as notepad, Vim, or Nano. When the script. is ready, a Duck encoder tool is used to convert these Ducky script. lines into an inject.bin file that will be ready to be launched on the targeted machine. The inject.bin file is stored on the microSD and the USB striker dongle is used to execute the commands on the targeted machine.
To aid you in your development on Q5, and, to allow you to do some of the work remotely (without the physical Ducky), you can opt to use a Ducky Emulator. You can use the emulator developed by UConn students (in Python, fromhere) in place of a physical Rubber Ducky.
Note: the USB Rubber Ducky does not receive interaction back from the computer. So, you need to carefully note which keystroke combination and delays will successfully accomplish the required task. This will require some trial and error on your part.
In the following questions, if using a physical Rubber Ducky, you will do the following process:
Step 0: Verify that the Chrome browser is installed on your laptop. If not, you may need to do this part of the project from a personal laptop/computer (with Chrome).
Step 1: Open Notepad (or any text editor you like) and enter your Ducky script. commands. Save the plain text (and submit it as part of your report). Again, see how to program the Rubber Duckhere.
Step 2 : Compile the Ducky Script. payload into the file inject.bin. There are two options for this:
1) Using the Javascript. Ducky Encoder “jsencoder.html”, which is a single HTML file which you can open and run in a browser locally, and which will encode Ducky script. into inject.bin files. If using the (disconnected) lab laptop, you can find jsencoder.html in your Lab2 directory, and can download it from there into the laptop.
2) Using Hak5’s (online) Payload Studio:https://payloadstudio.hak5.org/community/ .
Step 3: Put the MicroSD card in the MicroSD-to-USB adapter, connect it to the laptop, and copy the inject.bin to the MicroSD.
Step 4: Move the MicroSD to the Rubber Ducky, connect it to the lab laptop, and see if it does
the intended action. If not, adjust your script. and repeat till it runs correctly! Step 5: Show your work to your TA (attack and scripts).
Question 3 (10 points): A Step Toward My First (?) USB-Transmitted Malware
Write a simple Rubber Ducky script. that opens Notepad, writes a Windows script. (batch) file that echoes your name(s), saves the file and runs it (to echo your names). If you are not familiar with Windows scripts, learn a bit about this simple technology first, for example, see the
GeekforGeeks `Basics of Batch Scripting’ article.
Submission Requirements
Show your running Rubber Ducky attack (and script) to the TA for review and approval! No autograder submission required.
Upload your Ducky Script. code alongside lab report in a zip file. No lab report submission requirements.
Note: this UTM requires use of the physical Rubber Ducky, and therefore, cannot propagate further (as is) to other devices; of course, the malware we copy could be a virus/worm, but cannot propagate further using USB. However, it is actually possible to re-program many regular USB memory sticks to have the Ducky functionality, allowing the creation of an infecting UTM. But doing this is quite challenging and surely beyond this lab.
Question 4 ( 10 points) : Writing a Python Script
This will be the same as question 3, but this time your Rubber Ducky script. should write, save, and run a Python “ hello, world!” script.
Submission Requirements
Show your running Rubber Ducky attack (and script) to the TA for review and approval!
No autograder submission required.
No lab report submission requirements.
Upload your Ducky Script. code alongside lab report in a zip file.
Question 5 ( 10 points) : Writing Your Virus
This will be the same as question 4, but this time your Python script. that is to be uploaded, saved, and run will be the simple Python virus from question 1 (Q1C.py).
Helpful tips:
• In the past, some students have found it helpful to run their Q1C.py code through acode minifierin order to reduce the lines of source code.
• Since there’s a lot of code to write with the physical Rubber Ducky devices in this question, previous students have often used the emulator for this part to save time.
Submission Requirements
Show your running Rubber Ducky attack (and script) to the TA for review and approval! You may substitute the Ducky emulator in place of the physical Rubby Ducky device for this
question.
No autograder submission required.
No lab report submission requirements.
Upload your Ducky Script. code alongside lab report in a zip file.
If you cannot get in-person TA approval: provide a screen recording showing its operation, including testing all relevant aspects.