CIS

551 Homework Project #2 UFO Security

Services: You have started a promising career as a
security engineer for autonomous flying vehicles. A
customer has come in complaining about UFOs, and
while you are initially inclined towards believing the
customer may be a lunatic, when they elaborate on their
discussion of their needs, you see a variety of
opportunities to improve their autonomous vehicle, a
drone they are calling their UFO. You propose a three
phase plan to improve the security properties of the
drone, with each the name for each phase of the plan a
play on UFO.
Tools: For this homework we will use a cross-compiler for the ARM processor
architecture, available on Linux. Just as a reminder, a cross-compiler operates on
one architecture (in our case Intel x86, either on your laptop or eniac/speclab)
and outputs a binary runnable on another architecture.
For this homework, we will use a gcc cross-compiler for ARM processors:
$ sudo apt-get install gcc-arm-linux-gnueabi
To produce a binary that will run on the AR Drone, execute the compiler on the
program you want to run on the drone:
$ arm-linux-gnueabi-gcc badbuf.c -o badbuf
To get the binary onto the drone, use ftp:
$ ftp 192.168.1.1
Connected to 192.168.1.1.
220 Operation successful
Name (192.168.1.1:jms):
230 Operation successful
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put badbuf
local: badbuf remote: badbuf
200 Operation successful
150 Ok to send data
226 Operation successful
8663 bytes sent in 0.01 secs (884.0 kB/s)
ftp> quit
221 Operation successful

See if you were successful:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

BusyBox v1.14.0 () built-in shell (ash)

Enter 'help' for a list of built-in commands.
# cd data/video
# ls -l
-rwxr-xr-x
1 root
root
# ./badbuf
login: jms
password: jms
Welcome to The Machine!
# ./badbuf
login: jms
password: smj
Invalid identity, exiting!
#

8663 Jan

1 00:03 badbuf

Phase 1: Unauthenticated Flying Objects (due 10/22/14, before class). In this phase,
you will use badbuf.c to create a login program that listens on port 10551 and
checks a table of <name,password> pairs to decide whether to allow access to the
drone or not.
Turn in all source code (with compilation instructions) and data files, a typescript
obtained with the script command (demonstrating that you have authentication
working show both a success a failure, and show how to add a user name and
update a password).
Phase 2: Unprotected Flying Objects (due 10/29/14, before class). Since you are
acutely (!) aware of problems with the badbuf codes input-checking, you decide to
use iptables (see man iptables on any Linux box) to:
(1) force all traffic to initially go through your new authentication server
(2) filter out shellcode used to attack badbuf.c
In addition, to secure the channel, you will use a very simple form of cryptography,
where the characters that are sent between the client and the drone are encrypted
by adding a value between 0 and 25 to each character to hide the cleartext password.
Be very careful with iptables and closing the telnet port until you are sure you
know what you are doing, since without a working tenet or similar way to reach a
shell you cant fix things (i.e., the drone is bricked). One thing I suggest is to set up a
safety script that restores the original iptables values after 5 minutes; e.g.,
sleep 300; restore.
Turn in all table files for iptables, one or more typescripts obtained with the
script command (demonstrating that you have set up iptables to deny access
to the ordinary root telnet) and a packet capture captured with tcpdump that
demonstrates that the encryption is in place.