section{HoneyDrone understanding of the concept of HoneyDrone in

section{HoneyDrone – Prototype Implementation}
This chapter deals with the prototype implementation of the HoneyDrone architecture proposed in the previous chapter. The goal of the implementation is to provide an understanding of the concept of HoneyDrone in an environment of drone activity. The implementation covers some of the frequently used protocols in drones namely Telnet, SSH and MAVLink.
subsection{System Design}
In this section, we describe the hardware and software used for the implementation of the HoneyDrone and explain the reasons behind choosing the described hardware and software.
subsubsection{Hardware}
HoneyDrone is designed to run on Linux distributions and tested under Ubuntu 16.04 and Raspbian. Our hardware of choice for our implementation is the Raspberry Pi. Raspberry Pi is a tiny and portable computer and an excellent choice to be deployed across the borders of a drone network. Another advantage of using a Raspberry Pi is that, it is cost effective.
par In order to set up the wireless access point, the Alfa AWU036NH wireless adapter is used. This supports AP(Access Point) mode among other modes. It works on the 2.4GHz frequency band with MIMO (Multiple Input Multiple Output). It supports WEP, WPA, WPA2, TKIP and AES wireless data encryption standards and compatible with operating systems such as Ubuntu, Windows, Raspbian, etc. This hardware setup can be used to emulate any drone that runs on Linux with a 2.4GHz Wi-Fi access point.

subsubsection{Software}
Our choice of operating system for the implementation is Linux. One of the reasons for choosing Linux is that a number of existing libraries and software that could be used to emulate the drone’s services are based upon Linux ac{os}. The second reason is that, most of the open source drone hardware and software are moving towards Linux-based operating systems. These open source drone hardware, in their earlier stages were mainly built upon arduino based controllers, which limited innovation due to their limited computing power. Linux-based drones, on the other hand, provide the ability to build highly complex drone systems due to the computing power available. Erle-Brain, 3DR Solo, Parrot AR Drone 2.0 are some of the examples for drones that use Linux-based operating systems. Airware, an analytics company, uses Linux to power its drone based solutions. Therefore, our implementation can be easily adapted to these Linux based drone systems.
par The programming language used for the implementation is Python 2.7. Python framework ‘Twisted’ is used for network programming. ‘Twisted’ is an event-driven network engine written in Python. It is an asynchronous framework and comes packed with functionality such as Telnet, SSH, etc. It is highly flexible, extendable and open source. The protocols covered in this implementation namely SSH and Telnet use the libraries provided by the Twisted framework.
par In addition to the Twisted framework, some other python libraries are used in the implementation. Pymavlink, a python implementation for the MAVLink protocol, is one such library. It contains readily available functions to connect to a ac{mavlink} connection through TCP, UDP, serial port or a log file. It provides functions to receive, parse, pack and send ac{mavlink} messages. Pymavlink is implicitly used by the ac{gcs} software called MAVProxy. Pyaml is a python library which has been used in this implementation to read and write, from and to YAML files. YAML is primarily used to create human-readable configuration files. Finally, PyMongo is used to interact with the MongoDB database.

par The open source software packages used in this implementation are Ardupilot and MAVProxy. Ardupilot, is an autopilot software used on flight controllers. However, it also provides a simulator called SITL (Software in the Loop)footnote{http://ardupilot.org/dev/docs/sitl-simulator-software-in-the-loop.html}. SITL can run a Copter, Plane or Rover without the need for any hardware. If the emulation needs to be near to perfection, there is also an option of HITL (Hardware in the Loop) where a real flight controller hardware is included in the simulation. MAVProxy is a simple, command line ground station software. It is specifically used by developers to test the drone software and contains a number of useful modules such as maps, console, etc.

MongoDB is used to log the information about the attacks. Since it is a document based database, it is flexible to store information that are very distinct to every protocol and every drone, that is being emulated.

The following table summarizes the above software and libraries along with the type of license of each.
egin{table}h
centering
egin{tabular}{|c|c|}
hline
extbf{Library/project} & extbf{License}\
hline
Mavproxy & GNU General Public License v3.0\
hline
Pymavlink & GNU Lesser General Public License v3 or later\
hline
Pymongo & Apache License 2.0\
hline
Pyaml & MIT\
hline
Ardupilot & GPLv3 \
hline
MAVLINK & LGPL\
hline
Twisted framework & MIT \
hline
end{tabular}
caption{Software used and their license type}
end{table}

subsection{Database Design}
In order to store the information gathered by the HoneyDrone, MongoDB, a document based database has been chosen. The reason behind the choice is that, the document based databases are more suitable to work with RESTFul services that serve data in the JSON format, since the objects in a document database have the same structure as a JSON object. The database maintains one collection for each protocol supported and the collection is named after the protocol they represent. All the relevant information of a particular protocol are stored in the corresponding collection. For example, the collection that represents ac{ssh} protocol is named ‘ssh’ and all ac{ssh} specific data are inserted into this collection. The documents in each collection consist of clientinfo and eventinfo, where clientinfo stores any information specific to the client connection and eventinfo refers to the actions that are been carried by an attacker. An event could be a successful connection, a failed connection attempt or a command issued by the attacker. The value of these two fields vary depending on the protocol that the collection represents. Figure 5 shows some sample documents that contains the commands issued by an attacker connected to a ac{mavlink} port (default is UDP: 14550). The clientinfo contains the ip address and port number of the attacker and the eventinfo contains an array of all the ac{mavlink} commands.
egin{figure}h!
centerline{includegraphicsscale=0.9{graphics/mavlinklog.png}}
caption{Sample mavlink document from the database}
label{fig:MAVLOG}
end{figure}

subsection{System Implementation}
HoneyDrone is responsible for the creation of access points and the emulation of services such as Telnet, ac{ssh} and ac{mavlink}. The below subsections will describe each of these functions in detail.
subsubsection{Creation of Access points}
par For the attackers to connect to the HoneyDrone, we need to create access points that resemble the access points created by a real drone. The access point could be based on Wi-Fi, bluetooth or any other radio protocol. In this prototype, a Wi-Fi access point is setup and this will enable the HoneyDrone to emulate most of the drones that have a Wi-Fi based telemetry. It is important that the newly created Wi-Fi access point is indistinguishable from the access point created by a real drone. The following libraries are used for the creation of a Wi-Fi access point.
egin{enumerate}itemsep-0.5ex
item extbf{Hostapd}: Hostapdfootnote{https://w1.fi/hostapd/} (Host Access Point Daemon) is a user space daemon that can turn normal network interface cards into access points and authentication servers. It implements IEEE 802.11 protocol, IEEE 802.1X/WPA/WPA2/EAP authenticators, etc. Hostapd uses the settings from hostapd.conf for the access point setup.
item extbf{Dnsmasq}: Dnsmasqfootnote{https://wiki.debian.org/HowTo/dnsmasq} is a DHCP server and DNS forwarder. It is easy to configure and is lightweight. Dnsmasq is designed to work in smaller networks.
end{enumerate}
par Using the above libraries it is possible to create an access point in any Linux-based machine. The steps can be found in Appendix B.
par While emulating a drone, it is necessary that the access point exactly resembles a real drone’s access point. The following are the notable settings that needs to be properly set.
egin{enumerate}
item The ssid of the drone must be specifically set to resemble that of the real drone. For example drones like Parrot AR Drone use the default ssid of the form ardrone\_XXXXXX where XXXXXX is derived from the MAC address of the drone.
item The MAC address of the drone must be set specific to the emulated drone. The drone companies are known to own a specific block of MAC address which they use across their drones. For example the Parrot AR Drone uses blocks of addresses ’90-03-B7′, ‘A0-14-3D’, ’00-26-7E’ etc footnote{http://standards-oui.ieee.org/oui/oui.txt}.
item The Wi-Fi encryption method must be setup specific to the emulated drone. Some drones such as Parrot AR Drone 2.0 uses open Wi-Fi to connect the user to the drone while the drones such as DJI Phantom 3 use WPA-2 encryption to connect.
item In case of drones that use encryption, there is usually a default password that the company uses for the users to connect to the drone. This password should also be set specific to the emulated drone.
end{enumerate}
par From the above mentioned settings, it is observed that the values for SSID, BSSID(MAC address), the encryption standard used and the password, need to be configurable. Therefore, these values are captured in config.yml and the file hostapd.conf is dynamically created with the new values from config.yml. A template file hostapd.tmpl is used to achieve this. During the setup of access point the hostapd.conf is created from the template file with the new values taken from config.yml. This can be illustrated from the below diagram.
egin{figure}h!
centerline{includegraphicsscale=0.67{graphics/hostapd.png}}
caption{Creating configuration file for hostapd}
label{fig:HOSTAPD}
end{figure}

subsubsection{Telnet Emulation}
The extbf{Telnet} emulation of the HoneyDrone uses the ‘protocolFactory’ class from the telnet package, which extends ‘twisted.internet.protocol.ServerFactory’, to create the instances of the ‘TelnetUnix’ for the incoming connections. The login to the Telnet console can either be password protected or open, depending upon the drone that is being emulated. An instance of the twisted class ‘AuthenticatingTelnetProtocol’ is used for authentication. This class is responsible for validating the username and password, entered by the attacker and, if valid, allows access to an instance of the ‘TelnetUnix’ class which extends ‘twisted.conch.telnet.StatefulTelnetProtocol’. The ‘StatefulTelnetProtocol’ in turn extends the ‘LineReceiver’ and the ‘TelnetProtocol’ classes. Once the user has logged in, the subsequent data are received by this instance. It accepts the input, as entered by the attacker in the Telnet console. If the input matches any of the commands whose implementation is available, the command is executed by the file system emulator and the result is written back to the attacker’s console.
par The file system emulator is a class with a set of functions which works on the pickle file, either adding, modifying or removing files and directories from the pickle file. A pickle file is used for serializing and deserializing the python objects. The file system of a particular drone is emulated by respective pickle files. At the time of setting up the HoneyDrone, the pickle file corresponding to the emulated drone is selected, based on the configuration settings. To create the pickle files, our implementation makes use of the file ‘createfs’ provided by Cowriefootnote{https://github.com/micheloosterhof/cowrie/blob/master/bin/createfs} honeypot. HoneyDrone, by default, provides the ability to emulate the Parrot AR Drone 2.0 file system.
egin{figure}h!
centerline{includegraphicsscale=0.65{graphics/telnet.png}}
caption{Telnet Emulation – Class diagram}
label{fig:TELNET}
end{figure}

par The authentication is enabled or disabled by setting the flag ‘authentication’ in the configuration file to either ‘true’ or ‘false’. The other values from the configuration file that the Telnet implementation is dependent upon are ‘name’, ‘enabled’, ‘prompt’, ‘banner’ and ‘port’. The value of ‘name’ denotes the name of the protocol, in this case ‘telnet’. The value of ‘enabled’, denotes whether the protocol is enabled or disabled, ‘prompt’ specifies the prompt string that is to be used in the Telnet console, ‘banner’ specifies the welcome message to be shown once the attacker has logged in and the value of ‘port’ denotes the port number on which the created Telnet service must run.
subsubsection{SSH Emulation}
The extbf{ac{ssh}} server emulation of the HoneyDrone makes use of the ‘protocolFactory’ class from the ac{ssh} package, which extends the ‘twisted.conch.ssh.Factory.SSHFactory’ class, which is responsible for creating instances of the ‘SSHDroneProtocol’ for the incoming connections. We have used ‘twisted.cred’ for authentication. The server authentication is based on ssh-rsa keys while the client authentication is based on username and password. Once the login is successful, an instance of ‘SSHDroneProtocol’, which extends ‘twisted.conch.recvline.HistoricRecvLine’, handles the connection. The commands entered by the attacker are received by this instance which executes them, making use of the file system emulator.
egin{figure}h!
centerline{includegraphicsscale=0.65{graphics/ssh.png}}
caption{SSH Emulation – Class diagram}
label{fig:SSH}
end{figure}

par The working of the file system emulator is similar to that of the Telnet emulation which has been discussed in section 5.3.2. It works on the respective pickle file as provided in the configuration file. The ac{ssh} emulation uses the values ‘name’, ‘enabled’ and ‘port’ values from the configuration file at the time of setup of the HoneyDrone.
subsubsection{MAVLink Emulation}
extbf{ac{mavlink}} emulation is based on the open source autopilot software ArduPilot and the open source ac{gcs} called MAVProxy. In a real mavlink supported drone, the mavlink commands are continuously exchanged between the ground station and the flight controller. The flight controller sends the parameters about the drone such as the current position, speed, pitch, etc to the ground station at regular intervals. In our implementation, we achieve this using the Ardupilot simulator SITL. It is used to simulate a real drone that can send and receive ac{mavlink} commands through the tcp port 5760.
egin{figure}h!
centerline{includegraphicsscale=0.65{graphics/mavlink.png}}
caption{Components in MAVLink implementation}
label{fig:MAVLINK}
end{figure}

par Mavproxy is used to connect to the tcp port and channel the output through one or more UDP ports, typically 14550. When a ac{gcs} application connects to this UDP port, the mavlink commands are exchanged between the ac{gcs} and the simulator through the MAVProxy port. In this implementation, the MAVProxy source code is modified to log information such as the IP and port of the connected ac{gcs} along with the mavlink commands exchanged between the attacker and the HoneyDrone, in the mongodb database. The GPS location for the SITL and the path of the SITL installation are taken from the config.yml. Figure illustrates the different components in the MAVLink protocol Emulation.

Related Posts

© All Right Reserved