F23 Lab2 Malware(2)
docx
keyboard_arrow_up
School
University Of Connecticut *
*We aren’t endorsed by this school
Course
MISC
Subject
Information Systems
Date
Dec 6, 2023
Type
docx
Pages
6
Uploaded by MasterMantis467
Lab 2, Malware: Viruses, Worms and UTMs
Created: Fall 2022, Updated: Fall 2023 (by Amir Herzberg and Yuan Hong)
Monday sections submit by 10/08/2023
Wednesday sections submit by 10/03/2023
See instructions for all labs in Lab 0.
Note: in this lab we use the Rubber-Ducky gadget; at the end of this lab, pack it and return to the TA.
Malicious software, aka Malware, is the most serious threat for most users and organizations.
Malware is any software that is designed to benefits 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 have 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. UTM is therefore a bit like STD; maybe that’s why we
refer to USB connectors as `male’ and `female’?
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 this
link
.
In this lab, we will learn about malware by writing simple versions of a Virus, a Worm and a
UTM.
Question 1 (40
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 (in .py files) in the same folder
. Typically, this is done by searching for other .py files
on
the same folder, opening each such file, checking if it contains a script (or only modules), and, if
so,
attaching the virus code to the script. Note: practical viruses often attach to machine-code
programs, and many attach to different macro/script files (e.g. of MS Office).
Note: your virus should not re-attach itself to a program which already contains the virus!
A.
First write a Python script, Q1A.py, that reads the files in the current (working) directory,
and outputs a file 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
Lib/os.py
library.
On the VM, place the completed program in directory
Lab2/Solutions (with name Q1A.py).
B.
Next, write another script, Q1B.py, that receives as parameter the name of a .py file in
the current directory (including the .py), e.g., x.py. Next, Q1B.py checks if the file
contains a Python script, and if so, if the script does not yet contain the Virus. If both
checks are Ok, Q1B re-writes the file (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. Specifically, whenever
the script in the new “x.py” is run, it would append, 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.
C.
Finally, write the virus. This would be another Python script, Q1C.py. Q1C.py will
infect
every .py script in the current directory, e.g., x.py. By `infection’ we mean that when the
modified script “x.py” would be run, it would retain their original functionality (of
original x.py), but also have two additional functionalities. The first additional
functionality (the
payload)
is a spyware functionality similar to what Q1B did, i.e.,
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. The second additional functionality is an
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 scripts) should
not modify scripts which were already been `infected’ by this `virus’.
D.
Save all three scripts (Q1A.py, Q1B.py and Q1C.py) in the Lab2/Solutions directory, and
include them as part of your solution uploaded to HuskyCT.
E.
Note: your programs should be documented, e.g., explain how you avoid re-infection of
an already infected script.
Show your running code to the TA for review and approval!
Submit in submission site (
submit.edu,
IP: 172.16.48.8):
the `approval code’ from your TA.
Include in your report uploaded to HuskyCT:
all of your code, as text (not screen shot), and a
screen recording
showing its operation, including testing all relevant aspects. Also include the
approval code.
Question 2 (30
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.)
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 has a user/password 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 172.16.48.0/24, i.e., IP addresses in the form
172.16.48.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 `own’ VM, in file
Q2secrets
in
directory
Lab2/Solutions.
If you find several such machines, accounts and
Q2secret
files, put
all of the `secrets’ in separate lines in your
Q2secrets
file.
You should also copy
Q2worm.py
to
the home directory of the vulnerable VM, and also to the
Lab2/Solutions
directory of `your’
VM
.
Note: similar attacks (and worms) 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
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
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
.
Show your running code to the TA for review and approval!
Submit in submission site:
the `approval code’ from your TA.
Include in your report uploaded to HuskyCT:
all of your code, as text (not screen shot), and a
screen recording
showing its operation, including testing all relevant aspects. Also include the
approval code.
Question 3 (10
points):
First step toward my first (?) 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.
To make it easier, we will use the
rubber-duckie,
a special USB device designed to emulate a
keyboard. See below the background information on the rubber-ducky, which you will need to
write the scripts for all of these questions.
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 duckie 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 Ducky in
https://docs.hak5.org/hc/en-
us/sections/360002180614-Getting-Started
; 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, textedit, Vim, Emacs, Nano or other. 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, and in particular, to allow you to do some of the work remotely
(without the physical Duckie), you should use a
Duckie Emulator.
You can use the emulator
developed by UConn students (in Python, from
here
) or a previously-developed emulator (in
C#, only for Windows, from
here
), as you prefer; see details on both (and some tips on Ducky
scripts) in the Rubber Duckie Emulator Documentation file.
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, 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). A helpful guide to Ducky commands
to be found
here
.
You will also find some valuable guidelines on the wiki page
here
.
Step 2
: Compile the Ducky Script payload into the file
inject.bin
. We recommend to use 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. You can download the latest
jsencoder.html
from
downloads.hak5.org;
if using the
(disconnected) lab laptop, you can find
jsencoder.html
in your
Lab2
directory, and can
download it from there into the laptop.
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 PC, and see if it does the
required function. If not, fix your script and repeat till it runs correctly!
Step 5:
submit your work (scripts and screen shots).
Goal for Question 3:
write a (simple) Rubber-Ducky script that opens Notepad, writes a
Windows script (batch) file that echos 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
.
Show your running Rubber Duckie (with script) to the TA for review and approval!
Submit in submission site:
the `approval code’ from your TA.
Include in your report uploaded to HuskyCT:
all of your code, as text (not screen shot), and a
screen recording
showing its operation, including testing all relevant aspects, in the emulator.
Also include the approval code.
Note:
this UTM requires use of the physical Rubber-Duckie, 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 Duckie functionality
, allowing the creation of an
infecting UTM
.
But doing this is quite challenging and surely beyond this lab.
Question 4 (10
points):
Same as question 3, but this time your Rubber-Ducky script should
write
and run
a Python `hello world’ script.
Show your running Rubber Duckie to the TA for review and approval!
Submit in submission site:
the `approval code’ from your TA.
Include in your report uploaded to HuskyCT:
all of your code, as text (not screen shot), and a
screen recording
showing its operation, including testing all relevant aspects, in the emulator.
Also include the approval code.
Question 5 (10
points):
Same as question 4, but this time your Python script, to be uploaded,
saved and run, will be the simple Python
virus
of question 1 (Q1C.py).
Show your running Rubber Duckie to the TA for review and approval!
Submit in submission site:
the `approval code’ from your TA.
Include in your report uploaded to HuskyCT:
all of your code, as text (not screen shot), and a
screen recording
showing its operation, including testing all relevant aspects, in the emulator.
Also include the approval code.
------------------------------------------------------------------------------------------------------------------------------
We hope you liked this lab. If you want to learn more about malware and malware analysis,
here is one great resource:
https://www.sans.org/blog/-must-have-free-resources-for-malware-
analysis/
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help