Forensic Blogs

An aggregator for digital forensics blogs

by

Windows IoT, Vulscan, and Other Problematic Programs

Introduction

Last time we touched base, we described our journey into starting our work at the LCDI and our growth as interns, as well as some of the things we learned so far. Today, however, we wanted to touch on a different subject. Many forget that the mistakes, accidents, hiccups, and small failures of any project are just as important as the successes. Sometimes they’re more important as their lessons are greater than those you learn miraculously getting something right the first try. Although we’d like you to think we’re hyper-intelligent computer networking wizards who are ahead of the game, we aren’t. We have made some blunders, a decent number of errors, and a handful of happy accidents on this quest—but we are all the better for it.

“I have some choice words for Windows IoT”

The first scans we ran were on a small network of Raspberry Pis which were all running different services. One of these services was a Windows machine, and the unexpected hassle of setting up such a device was grueling. The only Windows OS “optimized” to work on a Pi is Windows IoT Core, which is Microsoft’s crack at a lightweight Internet of Things (IoT) operating system. If you’ve never heard of it, it’s probably because Microsoft would rather not advertise it. The service is free to download, but is not, in fact, designed optimally.

After first burning Windows IoT to a microSD, we plugged the SD into the Pi and turned it on. Windows IoT failed to boot, not once, not twice, but so many times we lost count. Even after we followed instructions step-by-step from both Microsoft and other websites, it refused to cooperate. After about two hours of attempting to boot Windows IoT, reburning it to the SD, trying a different SD, and failing some more, Windows IoT booted successfully without us doing anything differently the next day.

Once we logged onto Windows IoT, we needed to set it up to work with SSH so that we could input commands to it from our workstations. We didn’t need Windows IoT for anything specific, we just needed some sort of Windows machine to secure a connection to. However, getting Windows IoT to establish SSH connections required another three hours of trial, error, and scratching heads. Finally, we turned the machine off, reburned the SD with another fresh copy of Windows IoT, turned it on, and lo and behold, it worked—again without us doing anything differently. This worked for about a week until one day, the password and SSH key randomly changed during a scan cycle.

The palpable frustration we experienced as a team cannot be understated. But the moral of the story is keep working at it. We didn’t necessarily have to use Windows IoT. In fact, we would have preferred we didn’t, after the problems it caused. But we got it to work, and that’s what really counts.

What’s the deal with Vulscan?

Vulscan is a plugin for Nmap that adds vulnerability database checking functionality. It’s designed to take advantage of Nmap (which, if you remember from last time, is the software we’re using to scan the network) and its more invasive functions to diagnose potential problems that may occur with the machine automatically. This service was the thing we were looking for; without it, a person would have to diagnose all vulnerabilities by looking at our reports, which are sometimes very long, and may not provide all the necessary information.

We set up Vulscan early, but ran into problems as it didn’t run due to how we set up Nmap. Once we figured out our mistake and got Vulscan working, it became clear that the script was not optimized. Because it uses Nmap’s scripts for parsing potential vulnerabilities, the best Vulscan can do is guess what vulnerabilities are present. And it will give you every single guess it has, even the ones it knows aren’t likely to be true.

This headache was compounded when we learned that Vulscan would not run in our own script. It turned out we were actually using a slightly different version of Nmap, called libNmap. This version of Nmap is designed to run in a Python script which meant Vulscan didn’t recognize it as Nmap. So, our choice was to either scrap the completed script we made, which worked as intended, putting us at least a week or two behind, or abandon Vulscan and stick with what we had.

Ultimately, we decided to ditch Vulscan rather than sacrifice the valuable time spent on our script. Although it contradicts the last anecdote, sometimes it’s better to cut your losses and stick with what works rather than fix what’s broken.

Conclusion

Now, I know that these stories may leave the reader on a sour note, and that was somewhat intentional. Our team experienced these major frustrations and it helps to understand them for the reasons I described above. I hope that if people in the future ever try to replicate this project, they heed the advice presented here.

 

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook,  Twitter, or Instagram. 

The post Windows IoT, Vulscan, and Other Problematic Programs appeared first on The Leahy Center for Digital Investigation.

by

Python & Nmap

Automated Network Scanner! Team

 

Network Scanning Overview

So far, the Automated Network Scanning Team ! has learned about Python and Nmap. We are planning to use Python to create an automated network scanner and report generator with Nmap. To do this, we had to learn how to install various Python packages, such as libnmap, a package that enables the execution of Nmap. We also installed argparse, which allows users to change how a program runs without changing the code of the program, and smtplib, which allows Python to send emails from an SMTP server.

Python

The Python scanning portion will first take inputs from the command line using the argparse package, allowing the user to run it with different inputs, specify target IP’s, and identify the output destination of the email report. The team added these features  to the program. Which was intended to run remotely from a Raspberry Pi integrated into a network. After the user specifies these parameters, the program launches a scan utilizing the libnmap package. Unlike all the other packages, to install libnmap we had to learn how to use pip, a python package installation tool. This was a new experience for the team, but we successfully learned how to install packages using pip.

After the scan completes, it is re-organized for readability, and then the smtplib package is used to send the results in .csv file to the target destination. Throughout this process, we had to learn from the documentation of all three of these packages, which we had never worked with before. It improved our understanding of the Python language and sharpened our programming skills.

Network Mapper – Nmap

While using Nmap, we studied different types of scans to obtain all the information needed to compile a full report. We began by examining a ping scan, which scans through a range of IP’s for promising IP addresses to scan. A ping scan uses the same packets as a standard ping request. This scan was done first in our program in order to discover any viable hosts that were up and running, while being relatively fast compared to other host discovery scans. It also provided enough information to execute our next scans. The next scan that ran was the OS Fingerprinting scan.

This scan sent packets to a host, then ran dozens of tests on that host. After this, Nmap compared the results to a database of more than 2,600 OS fingerprints, trying to find a good match. We used this scan type to gather additional information on the target hosts/network.

Conclusion

One added feature of our automated network scanner is to find known vulnerabilities. We decided to scan for a cryptographic vulnerability, the Heartbleed Bug. This vulnerability allows the stealing of information encrypted with OpenSSL, a popular encryption protocol. There are Nmap scripts designed to scan for targets that are vulnerable to this bug. Nmap maintains a database of scripts that other users have found useful for security applications, and individual users can expand their nmap abilities by scripting to obtain new and different information.

Throughout the past few weeks, our Automated Network Scanning Team has learned about several Python packages, like libnmap, argparse, and smtplib. We have explored the functionalities of Nmap, bringing both together in our Python automated network scanner.

 

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook,  Twitter, or Instagram. 

The post Python & Nmap appeared first on The Leahy Center for Digital Investigation.

by

Experiences, Accomplishments, and Lessons Learned

Introduction

When people join a new workforce, they often find themselves saying: “I am in way over my head.” I experienced that during my first week as an intern at the Leahy Center for Digital Investigation (LCDI). It was only my second week of my first year of college, and I couldn’t wait to get my foot in the door and start my internship at the LCDI. I was a part of a team of three (Matthew Eckhardt, Jordan Kimball, and Jessica Hunsberger), and immediately I noticed that our project was more complicated than anything we had done before. None of us knew where to begin with an “Automated Network Scanner.” We didn’t have the answers right off the bat. Luckily for us, the LCDI is a place for people who don’t always know all the answers, as the truth is, nobody does. My team and I got to work, and found out we were a lot more capable than we previously thought. The following is the culmination of our work and research into Nmap, port scanning, and Raspberry Pi’s.

What we learned so far

First, we should explain what it is we are actually doing. Our team was tasked with creating an “Automated Network Scanner”—that is, a device that could be plugged into the network at the LCDI and scan it for available ports, hosts, and services, as well as give a report on what it found. In pursuit of this goal, we learned how to use Nmap, an industry staple for scanning and testing a network for vulnerabilities.

This, by itself, was not too difficult. If you do your research, you can download Nmap and figure it out, no problem. The difficulty comes in the “automated” part of “Automated Network Scanner.” We solved this problem with Python 3. It turns out that Nmap can be inserted as a part of a Python script. One of the great boons in this project was that almost everything we were working on was well documented online, albeit small pieces individually. Using this knowledge, we learned we could inject the script into a Raspberry Pi’s startup protocols, and run the script as soon as the Raspberry Pi turned on. Furthermore, using Python allowed us to create a formatted report, and send it to a private email account automatically.

Conclusion

All in all, our research and effort put towards this project have proved successful. Our team has been moving at a steady rate, and our Automated Network Scanner is almost complete. This technology has a lot of widespread utility as this machine could be used by just about any person or organization who is heavily invested in a computer network. Creating a map of your network and potential vulnerabilities is extremely useful, especially in this current digital age. The next step for our team is perfecting our scripts, making sure our scanner is as efficient and informative as possible, and then setting up a mock network out of Raspberry Pi’s and testing the scanner on it, before testing it on the LCDI network.

 

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook,  Twitter, or Instagram. 

The post Experiences, Accomplishments, and Lessons Learned appeared first on The Leahy Center for Digital Investigation.