My name is David. Now that you know my name, you should know technology is my passion. I've participated in the FIRST Robotics Competition, and I'm deeply knowledgeable about computer programming languages and software. But throughout my learning, I've always known cybersecurity would teach me and play an important part in my future career, regardless of whether I chose to be an inventor, investor, engineer, programmer or a designer. That's why I decided to take an internship with Tripwire over the summer of 2016. During the internship, my partner Jake and I built a Raspberry Pi robot with which I learned the basics of an Apache server setup and Python programming. Using my familiarity of App Inventor and Unity with C#, skills I picked up before the internship, I built an Android program to control the robot over WiFi. My skills improved even further as a result. After building the robot by the instruction manual, we found many security flaws by which any other person could take control of the robot. Because of that, I decided to create my own Python code from scratch with the end goal of closing off control of the robot to all foreign users. The first security control I addressed revolved around communicating with the robot. I learned about the differences between a GET and POST request, as well as how to send these requests manually. GET requests usually direct a server to request a certain file or HTML page, while a POST sends a form of data, which can be encrypted over SSL and also receive an output. Originally, the robot had an open port on which it listened for GET requests. When it received a URI such as “/motor/run,” python code executed it using the appropriate function (i.e. Flask). After I added an SSL certificate to our Apache server, I changed the whole code to listen for a POST form on “/post” where I could just send a form with variables and values like “turning=42&camera_x=-3” instead of multiple GET requests to accomplish the same thing. Next, to protect the information being passed to the robot, I modified Apache to use a self-signed certificate to encrypt all communication. Now, prying eyes couldn't see which pages the robot would use for control or what type of data would be used to control the robot’s movement. The third security control we implemented was basic authentication. Now, when a user visited any web page on the server, the server asked for credentials. Once authorized, the user could browse pages and POST forms to control the robot. Since credential information is POST data, it would also be automatically encrypted through SSL on port 443. To finalize the robot’s security, I changed the basic authentication and SSH passwords from defaults to long and complex passwords. TCP port 80 was also blocked by the firewall, which meant any web traffic would be encrypted through TCP port 443. I also looked for other ways to make the server bulletproof. Specifically, I found ways to hide Apache version number, hide website directory indexes, and change Apache and SSH passwords, among other small tweaks. All of these modifications added up to make a difference during our final security pen-testing. The robot’s security proved itself when we invited Tripwire employees to try to hack the robot. I gave them one hour to try and bypass any of the controls that we had implemented over the summer. I’m proud to say that after one hour, no one succeeded in compromising the robot. If you're interested in learning more, the source code for the robot can be found here: https://github.com/Quantum-Helix/RaspberryPi_Video_Car
About the Author: David Mishchenko was a summer intern at Tripwire in 2016. He currently is taking Computer Engineering major at George Fox University with aspirations to assemble a team and create a business after graduation. He previously took Mechanical Engineering course at the Center for Advanced Learning, several programming classes at Gresham High School, and participated in FIRST Robotics Competition for every year at both schools. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
