Forensic Blogs

An aggregator for digital forensics blogs

by

Automated Network Scanner! The Final Blog

Testing Our Script

Automated Network Scanning ! team has successfully completed their project by capping off the testing phase. The testing phase was divided into four phases. As we had configured our script to execute on boot, we would start each cycle by rebooting the Raspberry Pi. To implement this, we enabled auto-login on boot with the raspi-config command. In the process of booting to command line, Raspbian runs the commands stored in the .bashrc file. We used the .bashrc to start a bash script on boot. This bash script uses the cat command to read a file in the system that contained the network’s connectivity status and launched the scan when appropriate, moving our test cycle to the next step.

Flowchart of scan cycles

Once our team entered the scan running portion of the scanning cycle, our team would log into the Raspberry Pi with PuTTY, an SSH client. SSH clients allow remote control of computers through a command line. Although interacting solely through a command line may be considered an inconvenience, we were quite comfortable with the Linux Command line. To check if our scan was running, we used htop, a command line process viewer. Our team would inspect the htop window for a python3 process running our script and an nmap process. If both were present, as shown below, we could be sure that our script was running.

htop, a process manager service operated from the command line on our Raspberry Pi

Once our script finished, the report was automatically sent to an email address, alerting our team, no matter where they were, that the scan had finished. Our team would read through the report and would then move onto changing the scanner’s settings on the Raspberry Pi. Through PuTTY we were able to remotely interface with the Raspberry Pi. Once we finished this, we rebooted the Pi to start the cycle again.

 

Conclusion

Throughout this iterative cycle, we became intimately familiar with the function of an SSH client, and learned about several tools that allow operating Linux systems through command line to become easier, such as htop, a process manager, and ranger, a file explorer.  Overall, in this semester, we learned much more about the process of maintaining security on a network through mapping the network.

The post Automated Network Scanner! The Final Blog appeared first on The Leahy Center for Digital Investigation.

by

Automated Network Scanning ! Update

Our Progress

The Automated Network Scanning ! team ran into several issues writing our scanner. The first approach we took was incredibly slow and inefficient, as we scanned every host with a separate Nmap scan. This meant that our program had to start up a new Nmap process every time. While this approach worked well on our smaller network of four Raspberry Pis, it ran into issues with large-scale tests on the LCDI network; it took over two hours to scan sixteen hosts. Our team decided to switch to scanning every host simultaneously. As you can see in the diagram, we initialized Nmap very few times, increasing the efficiency of our scan.

 

Our initial solution compared to our revised version.

During this process, we ran into issues with our OS fingerprinting process and the heartbleed-ssl vulnerability scanning. The OS fingerprinting had extreme issues fingerprinting the Windows IOT Raspberry Pi as the scan would throw errors and not complete. Specifically, the SYN Stealth scans used in OS Fingerprinting would return a packet with a negative travel time. Although we ensured synchronicity of the times on the Pis, we were unable to overcome this issue. Due to this setback, we decided to remove OS fingerprinting from the scope of our network scanner.

Because of the change in structure of our scans, we removed our script’s heartbleed-ssl functionality. Initially, we were able to use a regular expression, or regex to find if the host scanned was vulnerable, as each heartbleed-ssl scan corresponded to a single host. However, once we scanned all of the hosts simultaneously, we had to change our approach to use inbuilt functions in the python-libnmap package we used. These functions were unable to retrieve the data from the script, so we ultimately had to remove this heartbleed-ssl functionality.

Conclusion

Although our team started development with great ideas, we had to scale back to create a more efficient network scanner. Sometimes, you have to take a step backwards before you can take two steps forward!

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 Automated Network Scanning ! Update appeared first on The Leahy Center for Digital Investigation.

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.