Forensic Blogs

An aggregator for digital forensics blogs

November 26, 2018 by LCDI

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.

Read the original at: The Leahy Center for Digital InvestigationFiled Under: Digital Forensics, Uncategorized Tagged With: Blog Post, Champlain College, Digital forensics, network scanning, nmap, Projects, Python, Raspberry Pi, Senator Leahy Center for Digital Investigation, Student Work, Update

November 15, 2018 by LCDI

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.

Read the original at: The Leahy Center for Digital InvestigationFiled Under: Digital Forensics, Uncategorized Tagged With: Blog Post, Champlain College, computer forensics, Digital forensics, interns, LCDI, Microsoft, nmap, Projects, Raspberry Pi, Student Work, vulscan, windows

November 12, 2018 by LCDI

Network Scanning Version 1.0

New Progress

Welcome back to Automated Network Scanning % teams official blog. We have been up to some exciting things since our last post. The first and most exciting thing that we did this month was get our script working. This was the main focus of the team since the beginning of the semester and we spent the majority of our time working on it. We went above and beyond to make sure our script was fully functional and had no bugs. We also were able to get our Raspberry Pi’s working which included adding some servers onto them to test our scanner.

Our First Script

Our team worked hard this month on creating a basic version of our script. Through a lot of trial and error we ended up creating a pretty in depth script. It allows us to perform many different types of scans including a TCP SYN scan, a UDP scan, a TCP connect scan, and a SCTP INIT scan. We also added a feature that allows us to perform a full comprehensive TCP SYN and UDP scan on all available ports, not just the default 1,000.

From here, the team decided to choose email for our output option in our script. Every time we run a scan using our script, each member gets an email with the results of the scan. This email includes information like the IP address of the scanned host , the scan date and time, how long the scan took, the MAC address of the scanned host , the status of the host, what OS the host is using, which ports are open, what services are being run on those ports, and what OS those services are using. We are very happy with the current state of our scanner. We are farther along with it then we thought we would be at this point. Now, the only aspect of our script that we know needs improvement is automation.  

Raspberry Set Up

In October, the team made a lot of headway into setting up our Raspberry Pi. The first thing we did was configure the SD card. This entailed wiping the card and reinstalling all the services we would need. From there we needed to find a way to get our Pi connected to the internet. Our first idea was to use the USB WiFi adapter to connect to the school WiFi. While this method ended up working, but was extremely slow. We instead decided to connect to the internet using Ethernet. This method proved to be much faster. We used our new internet connection to install server software onto our Pi. We installed an SSH server, a file server using Samba, and a web server using Apache. Our Pi’s are now imaged and ready to go.

www.ebay.com/itm/EEEKit-for-Raspberry-Pi-B-2-3-Model-B-Protective-Enclosure-Box-Shell-Case-Cover-/401175589303.

Image from ebay

In the Next Month

We are making haste towards completing our project goal of creating an Automated Network Scanner. In the next month, we will be testing our script on our Pi and the servers we installed, as well as move to some more advanced networks. We hope that November will see us test our Network Scanner on the LCDI Network itself. We will be tweaking our script while we run these scans to try to get faster scan times and add more automation to it. In the meantime, stay connected to us by tuning into the LCDI twitter feed where we will post weekly updates as we continue working on our project.

The post Network Scanning Version 1.0 appeared first on The Leahy Center for Digital Investigation.

Read the original at: The Leahy Center for Digital InvestigationFiled Under: Digital Forensics, Uncategorized Tagged With: Blog Post, Projects, Raspberry Pi, Update

  • 1
  • 2
  • 3
  • …
  • 5
  • Next Page »

About

This site aggregates posts from various digital forensics blogs. Feel free to take a look around, and make sure to visit the original sites.

  • Contact
  • Aggregated Sites

Suggest a Site

Know of a site we should add? Enter it below

Sending

Jump to Category

All content is copyright the respective author(s)