Difference between revisions of "ECE497 Project BoneSAW"
(→Executive Summary) |
(→Executive Summary) |
||
| Line 31: | Line 31: | ||
What Works: | What Works: | ||
| − | We developed a scanner to look at individual IP addresses and report back issues. It checks the condition of the publicly available network resources and reports back. | + | We developed a scanner to look at individual IP addresses and report back issues. It checks the condition of the publicly available network resources and reports back. It checks the following: |
| + | |||
| + | '''Default Port 22: SSH''' | ||
| + | |||
| + | Port 22 runs SSH. Many, many, many beaglebones run with either the default password or no password. | ||
| + | These are the configurations checked: | ||
| + | |||
| + | root/'' | ||
| + | |||
| + | root/'temppwd' | ||
| + | |||
| + | debian/'' | ||
| + | |||
| + | debian/'temppwd' | ||
| + | ''' | ||
| + | Default Port 53: DNSmasq | ||
| + | ''' | ||
| + | Port 53 runs DNSmasq. The version currently on this bone is 2.76. From what I can see from exploitdb.com all versions before 2.78 are vulnerable to a *several* remote code execution exploits. I have a couple POC exploits in [dnsmasq](dnsmasq) folder. Both of these I got to work on a webserver. However, I did not get it working on the bone. Though, I didn't spend much time on this. This is exploited, but not an exploit specific to the bone. Additionally, it is easily fixable by updating DNSmasq. | ||
| + | |||
| + | '''Default Port 80: Webserver''' | ||
| + | |||
| + | Port 80 runs a web service *as root* with bonescript. | ||
| + | Bonescript is a useful piece of JavaScript that runs client side and communicates using socket.io with the bone. | ||
| + | Bonescript contains two functions that can easily be used for an exploit: | ||
| + | |||
| + | digitalWrite(pin, value, [callback]) | ||
| + | |||
| + | writeTextFile(filename, data, [callback]) | ||
| + | |||
| + | The idea here is that if this service is exposed it is trivial to gain root on this device. This is accomplished by accessing the device over Port 80, executing [webservice.js](webservice.js) on the device to modify any file on the system, and taking advantage of the changes made. | ||
| + | |||
| + | Examples of files that could be exploited: | ||
| + | |||
| + | /etc/passwd | ||
| + | |||
| + | /etc/shadow | ||
| + | |||
| + | /etc/ssh/authorized-keys/%u | ||
| + | |||
| + | /etc/ssh/sshd-config | ||
| + | |||
| + | From this setup you can install keys, change passwords, or leak passwords and gain root. | ||
| + | |||
| + | '''Default Port 3000: Cloud9''' | ||
| + | |||
| + | Here we check to see if Cloud9 is running on the bone. If so, it alerts the user. The fact that this is on port 3000 typically means you can use the terminal in Cloud9 for at least user level priviledges. This could quite reasonably set up a system for password cracking, priviledge escalation, or basic botnet behavior. | ||
| + | |||
We developed a python flask server to monitor global beaglebone issues. Our web application connects to the Shodan API and can pull down a list of IP addresses for Beaglebones that are connected to the internet. It can also take an IP address as an input and either send it to the Shodan API and display the information Shodan returns like open ports and headers or use our own scanning utility to check for certain open ports and certain programs and return those results along with a security rating. The security rating is shown by changing the color of that part of the page where red is a high risk, yellow is a medium risk, and green is a low risk. | We developed a python flask server to monitor global beaglebone issues. Our web application connects to the Shodan API and can pull down a list of IP addresses for Beaglebones that are connected to the internet. It can also take an IP address as an input and either send it to the Shodan API and display the information Shodan returns like open ports and headers or use our own scanning utility to check for certain open ports and certain programs and return those results along with a security rating. The security rating is shown by changing the color of that part of the page where red is a high risk, yellow is a medium risk, and green is a low risk. | ||
What doesn't work: | What doesn't work: | ||
| − | We looked at a number of solutions with | + | We looked at a number of solutions with headless browsers to automate the process in our exploit in port 80 and 3000. These didn't pan out because of how they were handling web sockets. |
== Packaging == | == Packaging == | ||
Revision as of 20:42, 13 November 2017
Embedded Linux Class by Mark A. Yoder
Team members: Charles E. Beard and Luke Craig
Contents
Grading Template
I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!
00 Executive Summary 00 Installation Instructions 00 User Instructions 00 Highlights 00 Theory of Operation 00 Work Breakdown 00 Future Work 00 Conclusions 00 Demo 00 Late Comments: I'm looking forward to seeing this. Score: 10/100
(Inline Comment)
Executive Summary
Network utility to detect vulnerabilities in networked BeagleBones. Typically these will be a misconfiguration of some sort. We will also apply this to specific networked examples found on shodan.
What Works: We developed a scanner to look at individual IP addresses and report back issues. It checks the condition of the publicly available network resources and reports back. It checks the following:
Default Port 22: SSH
Port 22 runs SSH. Many, many, many beaglebones run with either the default password or no password. These are the configurations checked:
root/
root/'temppwd'
debian/
debian/'temppwd' Default Port 53: DNSmasq Port 53 runs DNSmasq. The version currently on this bone is 2.76. From what I can see from exploitdb.com all versions before 2.78 are vulnerable to a *several* remote code execution exploits. I have a couple POC exploits in [dnsmasq](dnsmasq) folder. Both of these I got to work on a webserver. However, I did not get it working on the bone. Though, I didn't spend much time on this. This is exploited, but not an exploit specific to the bone. Additionally, it is easily fixable by updating DNSmasq.
Default Port 80: Webserver
Port 80 runs a web service *as root* with bonescript. Bonescript is a useful piece of JavaScript that runs client side and communicates using socket.io with the bone. Bonescript contains two functions that can easily be used for an exploit:
digitalWrite(pin, value, [callback])
writeTextFile(filename, data, [callback])
The idea here is that if this service is exposed it is trivial to gain root on this device. This is accomplished by accessing the device over Port 80, executing [webservice.js](webservice.js) on the device to modify any file on the system, and taking advantage of the changes made.
Examples of files that could be exploited:
/etc/passwd
/etc/shadow
/etc/ssh/authorized-keys/%u
/etc/ssh/sshd-config
From this setup you can install keys, change passwords, or leak passwords and gain root.
Default Port 3000: Cloud9
Here we check to see if Cloud9 is running on the bone. If so, it alerts the user. The fact that this is on port 3000 typically means you can use the terminal in Cloud9 for at least user level priviledges. This could quite reasonably set up a system for password cracking, priviledge escalation, or basic botnet behavior.
We developed a python flask server to monitor global beaglebone issues. Our web application connects to the Shodan API and can pull down a list of IP addresses for Beaglebones that are connected to the internet. It can also take an IP address as an input and either send it to the Shodan API and display the information Shodan returns like open ports and headers or use our own scanning utility to check for certain open ports and certain programs and return those results along with a security rating. The security rating is shown by changing the color of that part of the page where red is a high risk, yellow is a medium risk, and green is a low risk.
What doesn't work: We looked at a number of solutions with headless browsers to automate the process in our exploit in port 80 and 3000. These didn't pan out because of how they were handling web sockets.
Packaging
If you have hardware, consider Small Build, Big Execuition for ideas on the final packaging.
Installation Instructions
Give step by step instructions on how to install your project.
- Include your github path as a link like this to the read-only git site: https://github.com/MarkAYoder/gitLearn.
- Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.
- Include a Makefile for you code.
- Include any additional packages installed via apt.
- Include kernel mods.
- If there is extra hardware needed, include links to where it can be obtained.
User Instructions
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.
Highlights
Here is where you brag about what your project can do.
Include a YouTube demo.
Theory of Operation
Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.
Work Breakdown
List the major tasks in your project and who did what.
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.
Future Work
Suggest addition things that could be done with this project.
Conclusions
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.
Embedded Linux Class by Mark A. Yoder
