Digital Investigation Archives

April 26, 2017 by LCDI

Application Analysis: Conclusion

Introduction:

To close out our list of Web Apps, we finished up on Discord. It has been an interesting experience for us to work with the three diverse apps over the last semester. Our analysis on Discord brought our research to a close. Seeing several key similarities with our first application Slack, it was an ideal application to close out our research for the side by side comparison.

Our Process:

With our final app, we utilized similar testing methods to Slack; we created a set of Test Channels and generated user data. After that was done, our team made a clone of the Virtual Machine, then deleted Discord on the original and promptly analyzed the images. In our findings, we noticed very similar behavior in storage of cached images when compared with Slack, although the content they each stored varied greatly. To read more about this topic, check our report which will be published soon.

In comparison of these apps, Dropbox was the most straightforward. However, it lacked the robustness of the other Web Apps as it lacked the expansiveness of XML. The app did not change much from the front end in terms of design. For the User Data, Dropbox’s local sql database provided information of what files were found on the Machine, along with deleted files visible in the cache. In contrast, Slack and Discord were two sides of the same coin. They both featured a strong use of XML to manage their styles, and featured images of user profiles and stored the urls of certain cached images. Discord did end up having one major difference. We were able to find bits of the messages amongst Win7enterpriseTest1\C\Users\User\AppData\Roaming\discord\Cache in messages?limit=50. We’ll have a deeper indepth look at this in our final report.

Analysis: Discord Artifacts

Going into Discord, we expected to find close to nothing on the local files of the web application, but after getting a closer look, we found out we couldn’t be more wrong. Discord has a strong security statement stating that they take the reasonable steps to ensure a user’s information is protected.

Application

The uses of caching and SQLite formatting allowed us to recover artifacts such as the aforementioned chat logs to the images and files uploaded. Interestingly, one of Discords more interesting features is its database’s storage of frequently used Emojis. In comparison, the Business Web Applications tried to stick to the bare minimum and focus on the bare bones such as only having time stamps and ID values. Dropbox’s Local Database primarily focused on this with it having extensive storage on File information, though it was lacking in the niches of Discord, which, as mentioned before, even stored emoji usage. A more extensive comparison can be found in our Final Report.

Conclusion:

With increased integration of platforms such as Discord, Dropbox and Slack, there will be an increased need for privacy. Implementation without security will continue to allow various security flaws to exist. However, it must be remembered that with the need for Security comes the need of usability. To remain a strong web application with a following, an ease of use, and efficiency must be maintained.

Through the process, our group learned a lot and got deeper insights on Web App Forensics. We hope this Blog can hold you over before the final report drops. Stay tuned!

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Application Analysis: Conclusion appeared first on The Leahy Center for Digital Investigation.

April 21, 2017 by LCDI

Bluetooth Security Forensics Conclusion

Introduction

The Bluetooth Team has been working hard all semester and has finally finished testing with all bluetooth tools. This semester has been challenging for everyone as we learned about Bluetooth and its vulnerabilities. Our team has gained a lot of insight into the realities of modern Bluetooth security, using tools such as Econocom Digital Security’s Btlejuice, Pwnie Express’s BlueHydra, and the L2ping command within the Linux Bluez library.

Btlejuice Conclusion

Using Btlejuice had many difficult hurdles to overcome when working with it. The goal of using Btlejuice was to be able to intercept bluetooth packets (specifically GATTs) when it was being broadcast, and be able to use that information to control the bluetooth device. Some of the problems we faced as a team was Btlejuice did not working well with Firefox. It had trouble picking up devices consistently. The creator of Btlejuice, Damien Caquil, stated that it works best with Chrome. We tried installing Chrome but we were not able to install it onto our Kali distribution, so we had to resort to Chromium, which unfortunately did not fix our connection problems either.

Bluetooth

Figure 1: Network diagram of the actual configuration the team encountered

Figure 1 above is a diagram of the setup we had when using Btlejuice. The proxy is facilitating the Bluetooth connections and the web proxy is supposed to view the intercepted data. The problem we encountered (see letter A) was when our Schlage Smart Sense Lock was connected to the proxy was that the proxy would not relay back to the iPad and thus no information could be intercepted coming from the iPad. We have also demonstrated that the Smart Sense Lock will not send data to the proxy if it’s locked or unlocked status as evidenced by the fact that even when using the keypad or the turn lever to open the lock we did not intercept that information.

Bluetooth

Figure 2: Network diagram of the ideal configuration

In the above Figure 2, one can see the ideal process by which the proxy is supposed to work. It acts as a relay and any commands going to or from the controller or device will be intercepted by the proxy, captured, and then sent on to its destination. Letter A shows how the proxy is relaying information back and forth to both devices while letter B shows that the hci0 device is connected to the Smart Lock itself.

BlueHydra Conclusion

Initially, we wanted to use Bluehydra to find information about bluetooth devices in the area. Specifically, we wanted to determine the range of each device in an attempt to potentially track an individual around a building based on the location of their Bluetooth device. However, the team was never able to get this feature of BlueHydra to work. Conversely, the team was able to get important information on visible devices such as their MAC address, device name, Bluetooth version, and the device manufacturer. It was vital to obtain this information about our Bluetooth devices so that we could exploit them using the other tools in our vulnerability assessment repertoire, such as Btlejuice and L2Ping.

L2ping Conclusion

We first discovered L2ping as a means of detecting if a device was transmitting so we could begin testing. We discovered “Bluesmack”, the term used to describe the malicious use of L2ping command, shortly after and began testing its effectiveness against devices ranging from bluetooth keyboards to a Macbook Pro. Our testing revealed that L2ping’s effectiveness was varied in terms of the devices it could be used against. L2ping could completely shut down a smartwatch or keyboard, but in turn, could not cause any noticeable disruption to a larger device such as a laptop.

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Bluetooth Security Forensics Conclusion appeared first on The Leahy Center for Digital Investigation.

April 14, 2017 by LCDI

Mobile App Analysis Part 5

Introduction

The Mobile Application Forensics team is beginning to wind down on application analysis, and have started working on their final report. So far, both the iOS team and Android team worked on Open Whisper Systems’s Signal, an end-to-end encryption chat app, and Bumble, a new mobile dating app. The iOS team then did analysis on The Weather Channel app, and are now finishing analysis on Tumblr. The Android team began work on Facebook Lite and Facebook Messenger Lite, and are starting data generation for Strava, a run and cycling tracking social app.

In this week’s blog, the iOS team will showcase their findings for The Weather Channel app, and the Android team will showcase their findings so far for Facebook Lite, and Messenger Lite.

Analysis iOS

The iOS team conducted data analysis on The Weather Channel app this week and were able to find user account information, and user location data. Within The Weather Channel app, under the com.weather.TWCiPadMax/Library/PrivateDocuments folder, the iOS team found a database titled WXUPSService.coredata which contained 12 tables. The tables we will focus on for this blog post are ZCD_WXUPSDEMOGRAPHICS and ZCD_WXPUSPLOCATION.

User account information

Within the ZCD_WXUPSDEMOGRAPHICS table, we found user account information such as the user’s age range (ZAGERANGE column), email associated with the account (ZEMAIL column), user’s first name and last name (ZFIRSTNAME column and ZLASTNAME column), user’s gender (ZGENDER column), username on the account (ZUSERNAME column), and much more. Below, is an image of the ZCD_WXUPSDEMOGRAPHICS table within the WXUPSService.coredata database, showing the user account information we found for The Weather Channel app.

User location data

Within the ZCD_WXPUSPLOCATION table, we found Latitude and Longitude coordinates to locations our user was the last time the app ran in that location, and any locations the user saved on their app. Within the ZCD_WXPUSPLOCATION table, we also found the name of the city the user was in (ZCITYNAME column), the country the user was in (ZCOUNTRYCODE column), and the elevation the user was at the time the The Weather Channel app called out (ZELEVATION column). Below, is an image of the ZCD_WXPUSPLOCATION table, showing the cities, along with their country codes and county names, the user saved on The Weather Channel app.

Within the com.weather.TWCiPadMax/Library/Preferences folder, we found a pList titled com.weather.TWCiPadMax.plist which contained settings information for the first time The Weather Channel app was used. As you can see in the image below, the pList showed us the Longitude and Latitude coordinates, and city, where the app was first used.

Android

The Android team conducted data analysis on Facebook Lite, and Facebook Messenger Lite this week. We were able to recover a lot of information in regards to; user account and user activity information on both apps. For this blog post, we will be focusing on Facebook Messenger Lite, specifically on the messages sent and received through the Facebook Messenger Lite app. In order to create a realistic messaging scenario, we decided to send two images, one video, and an emoji, to see if we could recover all the media sent through this app, on top of the text messages themselves.

Within the com.facebook.mlite/databases exist two databases, core.db and omnistore.db. core.db stores a plethora of tables, the most important being the messages table. Within the messages table, we were able to find all the messages Joseph Mitchell (the account on the Nexus 5x) sent. This included the locations of any images Joseph sent from the Nexus 5x, and internet links to images and videos Aaron Guirre sent.

Image received by Nexus

During data generation, we had Aaron send Joseph an image of a question mark. The way Aaron got this image was by downloading it from the internet, and then sending it to Joseph through the desktop version of Facebook. When looking through the messages table within the core.db database, we found a link that seems to be pointing us to a facebook server which, when we followed the link, showed us the image Aaron sent to Joseph. Below, is an image of the messages table within the core.db database showing the message Aaron sent, as well as the media_playable_url column showing the link that took us to the image sent by Aaron.

As you can see on the image above, under the media_playable_url column, we got a url that points to a Facebook server which contains the image Aaron sent to Joseph.

Video received by Nexus

Just like the image we received from Aaron, we found a url that points to a Facebook server that allowed us to download the video sent by Aaron. Below, is an image of the messages table within the core.db database showing us that a video was sent, and the media_playable_url column showing the link that took us to the video Aaron sent.

Image sent from Nexus

During data generation, we had Joseph send Aaron an image of a security camera from the Nexus 5x mobile device. Unlike the message we received from Aaron, we did not get a URL, but, instead, got an absolute path to where the image was stored on the Nexus 5x mobile device. As you can see below, we got an absolute path under the media_playable_url column to the image Joseph sent to Aaron from the Nexus 5x mobile device.

Emoji sent Nexus 5x

As you can see in the image below, the emoji sent by Joseph to Aaron appears as a box in the db browser.

When we copied the text out and placed it in an Emoji keyboard (https://emojikeyboard.org/), we were able to see what emoji Joseph sent to Aaron through Facebook Messenger Lite. Below, is an image of what the online Emoji keyboard we used translated through the text Joseph sent to Aaron.

The Emoji seen above is the exact Emoji Joseph sent to Aaron.

Messages sent to and from Facebook Lite Messenger

Through the messages table in the core.db database, we were able to recover all the messages ever sent and received through Joseph’s Facebook account. The reason we were able to recover all the messages ever sent was because Facebook imports all the messages ever sent from the main Facebook app to the Messenger app once the user installs it. Because we are using a lite version of the Messenger app, we did not expect all the messages to be present within the core.db database.

Within the messages table, we were able to find user ID information, and a link to the user image, the timestamp information in respect to the actual message, if the message was a multimedia message (we were able to see what type of multimedia message it was under the attachment_meme_type column), and a link or absolute path to the multimedia message sent.

Conclusion

As the iOS team finishes data analysis on Tubmlr, and the Android team finishes analysis on Facebook Lite, Facebook Messenger Lite, and Strava, we hope to show all of our results in a detailed report that will be released later this semester.

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Mobile App Analysis Part 5 appeared first on The Leahy Center for Digital Investigation.