Forensic Blogs

An aggregator for digital forensics blogs

by

Application Analysis Blog 1

What is Application Analysis?

Artifacts are a subject of fascination, full of information from their time and location.  An application leaves markers on systems that often go undetected by the user. These digital artifacts are small bits of information, ranging from profile icons to private messages. This information could be a threat, and it’s crucial that any consumer be aware of their app’s security. This means that if someone else gets into your system, they might be able to unearth info that could allow them to steal from or impersonate you.

The goal of this project is to find out what information remains after one removes an app from the system. Through this, we can learn what programs are secure and prevent any security risks.

Image stating

Browsers and User Privacy

In the first few weeks of the semester, we spent time examining the artifacts left by internet browsers. Through this, we uncovered a treasure trove of information in the “Appdata” folder. This folder is where every desktop application stores it’s information. Because it’s deemed unnecessary for user interaction, the Appdata folder is full of user input for most programs. If a normal consumer stumbled upon this, it wouldn’t mean much to them. However, this is all the juicy bits of data that were part of your account on a program. This could be very useful for someone trying to take control of your accounts.  For example, one of the files within this folder holds your Cookies, small temporary files that are responsible for holding small, session-long pieces of data.  

We took a look at the browser Firefox, made by the company Mozilla. There are three folders under Appdata: Local, LocalLow, and Roaming. The browser stores data that it accesses in a local server so that it can access it again, like your browser homepage.

Your credit card information that was put into Amazon is held in that file, as is your Facebook password. This is a risk for everyone and it needs to be addressed to make users more aware of their safety online and offline.

An image of the information under the Firefox tab in Roaming

An image of the information under the Firefox tab in Roaming

What types of applications will we be looking at? 

After working with browsers, we started researching other applications to investigate.  We decided to investigate Steam, Google Drive, Dropbox, Viber, and Twitter. Steam is a popular gaming PC gaming platform that, as of April 2019, has a billion accounts and 90 million users. It’s important that such a giant in the video game industry keeps its users’ information private. Google Drive is similar to Dropbox, but is better funded and more used. We are curious to see how much of a difference this makes security-wise for each user. Viber is a small Peer-to-Peer (P2P) application for smartphone and desktop use. P2P gives users equal permissions, allowing for fast data movement. Finally, Twitter is a large worldwide social media application that has had a history of insecurity in its system.

Conclusion

During the course of this semester, we will these desktop applications on our virtual machines. Doing this will generate data from the program into the Appdata folder. After this, we will completely uninstall the applications from the system, and investigate the data leftover, analyzing the trail of data to see if one could abuse it.

We will start next week with analyzing our first application, and we will be sure to let everyone know the verdict on our next blog!

 

Stay up to date with Twitter, Instagram, and Facebook by following @ChampForensics so you always know what we’re up to!

 

The post Application Analysis Blog 1 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

by

Mobile App Forensics Final Update

Introduction

During this semester, the Mobile Forensics team analyzed social media apps such as Snapchat, Telegram, and LinkedIn. 

Snapchat

As for a conclusion on our Snapchat analysis, we couldn’t find much outside of prior research within the community. A big concern we had was how much data would remain on a device  twenty-four hours after it was generated. An immediate pull from the device yielded evidence of what stories the user viewed and also a log of messages exchanged with other users (but not the content of the message). This log showed who sent and received the message and the timestamp of the event. The text of messages was only viewable if either user had saved the message. Some pictures were also recovered that had the contents of stories that were viewed. This could provide some information on the interests of a user, but nothing incriminating. An interesting artifact found on the device that could not be decoded was location data found in  /data/data/com.snapchat.android/cache. We could not parse these files and believe they may related to ArcGIS.

We aquired Snapchat after a few days to see what information would still be available. Logs of conversations were not deleted and remained on the device. However, there were still no contents of the conversation again with the exception of any messages that either user saved. It appears Snapchat does not store data from the user directly on the phone, it may simply be processed and erased while in memory. There was little evidence of user activity.

Telegram

When testing Telegram we did two pulls of the tablets. We first did a pull with all three of the members and then a pull with just two members on the different operating systems. When we did the first pull, the data between the group was very easy to analyze, but the solo data was very confusing, so we did the second pull. When we tested Telegram, we were interested in the secret chats the most to see if we could find any information about them. Telegram advertises that the messages are encrypted and we were interested to see if we could verify this. The only chats that were encrypted were messages in a secret chat. This is definitely a note for a forensic investigator. When we did the pull, we could see each message in the chat log as well as any pictures and images. The one thing we could not find was any videos or voice messages that did not get saved.

LinkedIn

While analyzing LinkedIn, we once again didn’t find all the data we were looking for. We had hoped to be able to find the user’s whole work profile but that was not the case. We were able to pull and reconstruct all their chat messages, a summary of their profile, and users they connected with, but we couldn’t find any search history, viewed articles, or viewed jobs. Even when looking in the chat, we didn’t find images or voice messages in the same location as the other chats. We had some temporary files for images, but we weren’t able to confirm what the images were. They could have been images from the chat logs or they could have been images from an articles or profile.

Versions

Readers of previous blog posts may note that we were comparing differences in Android operating system versions. There has been little to no evidence found that the version of the OS has an impact on our examined applications. The only major change we found was occasionally an app on Android 6 would generate a few extra folders, but they were always empty. However, it is important to note the biggest changes would be found with differing application versions.

 

Different operating systems don’t affect the data we pulled because OS updates focus more on new features and security fixes rather than how app data is stored on the device. If we looked into different versions of the application then there would be differences in the pulls. The updates of the apps will have bug fixes as well as security fixes that make the app more secure. If we could test an older version of one of the apps to the most current update then we would find different data.

 

This is clear in the below screenshots:

Snapchat on Android 6

Snapchat on Android 7

As you can see the files may be slightly different. Any files that were not common between the two extractions were empty.

Conclusion

Our work this semester has been a good test of our examined applications to ensure that they work as advertised. One may believe that mainstream applications are secure because of their size and amount of users. Previous reports, which can be found here and here, have shown that Snapchat has been less secure in the past, and we have seen clear improvements in the amount of data that is stored on the device. With Telegram, the application works as it should and doesn’t store data on the phone to be viewed later on. However, this was only the case when using “secure messaging” and is not on by default. With LinkedIn there was little data we were able to recover from the phone. That by no means infers that LinkedIn is not storing your personal data. This simply means that that data is not stored on the device.

 

There has been a lot of hands on with tools such as ADB and Cellebrite to find efficient ways to examine these phones, and one should always question the applications they use every day with their private information. We are glad to have formed a plan of analysis for these apps, and look forward to seeing what research will be performed on the apps we use every day. As always, stay up to date with the LCDI on our social media.  Follow us on Twitter @ChampForensics, Instagram @ChampForensics, and Facebook @ChamplainLCDI.

The post Mobile App Forensics Final Update appeared first on The Leahy Center for Digital Investigation.

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.