Network And Device Forensic Analysis Of Android Social ... · DFRWS 2015 US Network and device...

DIGITAL FORENSIC RESEARCH CONFERENCE

Network And Device Forensic Analysis Of

Android Social-Messaging Applications

By

Daniel Walnycky, Ibrahim Baggili, Andrew Marrington,

Frank Breitinger and Jason Moore

From the proceedings of

The Digital Forensic Research Conference

DFRWS 2015 USA

Philadelphia, PA (Aug 9th - 13th)

DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics

research. Ever since it organized the first open workshop devoted to digital forensics

in 2001, DFRWS continues to bring academics and practitioners together in an

informal environment.

As a non-profit, volunteer organization, DFRWS sponsors technical working groups,

annual conferences and challenges to help drive the direction of research and

development.

http:/dfrws.org

DFRWS 2015 US

Network and device forensic analysis of Androidsocial-messaging applications

Daniel Walnycky a, Ibrahim Baggili a, *, Andrew Marrington b, Jason Moore a,Frank Breitinger a

a University of New Haven Cyber Forensics Research and Education Group (UNHcFREG), ECECS Department,Tagliatela College of Engineering, USAb Zayed University, Advanced Cyber Forensics Research Laboratory, College of Technological Innovation,United Arab Emirates

Keywords:Network forensicsAndroid forensicsInstant messagingPrivacy of messaging applicationsApplication security testingDatapp

a b s t r a c t

In this research we forensically acquire and analyze the device-stored data and networktraffic of 20 popular instant messaging applications for Android. We were able to recon-struct some or the entire message content from 16 of the 20 applications tested, whichreflects poorly on the security and privacy measures employed by these applications butmay be construed positively for evidence collection purposes by digital forensic practi-tioners. This work shows which features of these instant messaging applications leaveevidentiary traces allowing for suspect data to be reconstructed or partially reconstructed,and whether network forensics or device forensics permits the reconstruction of thatactivity. We show that in most cases we were able to reconstruct or intercept data such as:passwords, screenshots taken by applications, pictures, videos, audio sent, messages sent,sketches, profile pictures and more.© 2015 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access

article under theCCBY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Introduction

Digital evidence from smartphone instant messagingapplications is potentially useful in many types of criminalinvestigation and court proceedings. Text messages havebeen an important component of the evidence presented innumerous high profile cases in recent years, such as Ashbyv. Commonwealth of Australia (Ashby v Commonwealth ofAustralia (No 4), 2012) and The State v. Oscar Pistorius (S vOscar Pistorius (CC113/2013), 2014). In the latter, the mes-sages concerned were not sent via Short Message Service(SMS) but by the instant messaging application WhatsApp.Applications like WhatsApp offer users a free or very lowcost alternative to SMS for text messaging purposes, andfrequently offer other additional features. It is therefore

unsurprising that such instant messaging applications havebecome extremely popular, as a result of which, it isreasonable to expect that more and more cases will involvemessages originally sent via such applications.

In this work we perform an experimental forensic studyon twenty social-messaging applications for the Androidmobile phone operating system. The sum total of the usersof the tested applications exceeds 1 billion. Our study il-lustrates the potential for acquiring digital evidence fromthemobile device, data in transit, anddata storedon servers.

The remainder of this paper is organized as follows. Inthe “Related work” section, we discuss related work fromthe digital forensics and security literature. In the“Methodology” we discuss the research methodology andexperimental setup. In the “Experimental results” sectionwe provide an overview of our results, which we discuss inthe “Discussion”. We propose future work in “Future work”and conclude in “Conclusion”.* Corresponding author.

E-mail address: [email protected] (I. Baggili).

Contents lists available at ScienceDirect

Digital Investigation

journal homepage: www.elsevier .com/locate/di in

http://dx.doi.org/10.1016/j.diin.2015.05.0091742-2876/© 2015 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Digital Investigation 14 (2015) S77eS84

Related work

Smartphones are typically kept in close physical prox-imity to their owners as compared to other potentialsources of digital evidence, like computers. This enhancesthe potential value of digital evidence found on smart-phones e suspects may interact with them continuouslythroughout the day and may take them to the crime scene.In addition to traces of the suspect's communications, asuspect's phone may contain evidence pertaining to theirlocation, and with the advent of the smartphone, they maycontain the same rich variety of digital evidence whichmight be found on computer systems (Lessard & Kessler,2010). Mobile phones and their applications may beinvolved in a huge variety of criminal cases, including fraud,theft, money laundering, illicit distribution of copyrightedmaterial or child pornographic images, or even distributionof malware in cybercrime cases (Taylor et al., 2012).

Even before modern smartphones, SMS text messagesstored in the GSM SIM card were an important target forforensic examiners (Willassen, 2003). With modernsmartphones, mobile applications providing messagingcapability may supplement or even supplant SMS, meaningthat there may be multiple message repositories on thephone for examiners to retrieve (Husain & Sridhar, 2010).

The majority of new smartphones are shipped with theAndroid operating system. There have been many differentapproaches to forensic acquisition of secondary storage ofAndroid devices in the literature since 2009, encompassingboth logical and physical acquisition, with some techniquesrequiring more potential modification to the Android de-vice under examination than others (Barmpatsalou et al.,2013).

Generally speaking, logical acquisition can be per-formed on an Android device through various backuputilities, and requires no modification of the device or itssystem software. Physical acquisition techniques describedin the literature, on the other hand, often require theinstallation of a rootkit (modifying the device's systempartition) in order to facilitate full access to the device'ssecondary storage for acquisition through a tool like dd, asin Lessard and Kessler (Lessard & Kessler, 2010).

Since these rootkits are often of unknown provenance(in fact, they are most easily sourced from the hackingcommunity), and since any modification to a device underexamination ought to be minimized if not outright avoided,Vidas et al. proposed that the Android recovery partitionmight be more safely overwritten with a known safeforensic boot environment to facilitate physical acquisitionof the remaining partitions (Vidas et al., Aug. 2011). Bydoing so, the system partition is notmodified by the rootkit,but full access to the device's secondary storage is obtainedby rebooting the device into a modified recovery modeincorporating the necessary software to perform a physicalacquisition. This is similar to how a boot CD might be usedto facilitate forensic acquisition on a computer system.

From a completeness perspective, physical acquisition isgenerally preferable to logical acquisition, as a physicalimage will include any data which exists in unallocatedspace, such as files that have been deleted but not yetoverwritten. Despite this, logical acquisition can still yield

significant quantities of digital evidence (Lessard& Kessler,2010) and is still employed in many studies in the literature(Barmpatsalou et al., 2013; Al Mutawa et al., Aug. 2012;Grover, 2013).

Mobile applications for popular instant messaging orsocial networking platforms have been the subject ofnumerous studies in digital forensics literature. Early workon instant messaging applications on smartphones, such asHusain and Sridhar's study on the iPhone (Husain &Sridhar, 2010), examined platforms which were originallyreleased for the Personal Computer (PC) either as a stand-alone application or via the web. Computer forensic tech-niques are described in the literature for the examination ofartifacts from AOL Instant Messenger (AIM) (Reust, 2006;Dickson, 2006a), Yahoo! Messenger (Dickson, 2006b),other installed instant messaging applications (Dickson,2006c; Dickson, 2007), web clients for popular instantmessaging applications (Kiley et al., 2008), and instantmessaging features of social networking websites such asFacebook (Al Mutawa et al., 2011).

As these instant messaging platforms from the PC worldmigrated to the smartphone with their own mobile appli-cations, so did the digital forensics community move on toinvestigate activity traces left by these applications onmobile devices (Husain & Sridhar, 2010; Al Mutawa et al.,Aug. 2012). In addition to these imports from the PC,instant messaging and social networking applications weredeveloped primarily for the smartphone.

An example of a mobile messaging application is What-sApp. Anglano analyzed WhatsApp on software-emulatedAndroid devices in recent work providing forensic exam-iners with information about what data is stored on theAndroid device by the WhatsApp application, facilitatingthe reconstruction of contact lists and text conversations(Anglano, 2014). Most of the applications examined in thiswork fall into the same category as WhatsApp in that theyarefirst and foremost smartphone applications, not PC port-overs to Android.

Given the popularity of smartphones, it is not surprisingthat they have become targets for cyber attacks. Smartphonemalware is a growing concern, and the sheer volume of mo-bile applications brings with it a plethora of potential attackvectors. For example, Damopoulos et al. developed malwarewhich performed DNS poisoning on the iPhone's tethering(also known as personal hotspot) feature, and exposedimportant user data (such as location and account creden-tials) when the user employed the Siri service (Damopouloset al., 2013). In their work on Android inter-applicationcommunication and its attendant attack vulnerabilities,Chin et al. found 1414 vulnerabilities in the top 50 paid andtop 50 free applications then available for Android on whatwas then called the Android Market (Chin et al., 2011).

Instant messaging smartphone applications are noexception, as shown by Schrittwieser et al. who examined aset of nine popular instant messaging applications forAndroid and iPhone, and found vulnerabilities to accounthijacking, spoofing, unrequested SMS, enumeration orother attacks on all of them (Schrittwieser et al., 2012).Especially given that smartphones contain so much per-sonal information, it is clear that such threats to their se-curity pose serious risks to user privacy.

D. Walnycky et al. / Digital Investigation 14 (2015) S77eS84S78

While some of these security flaws may assist the dig-ital forensics community to recover more digital evidencefrom these devices, it is clear that the potential forexploitation of these vulnerabilities by malicious agentswill lead to higher incidents of cybercrime targeting mo-bile devices. Our work complements existing literature byemploying network forensics as well as device forensics toprovide a more holistic view of what evidence may beobtained frommessaging applications on Android devices.Our work also sheds a light on the potential privacy issuesthat arise from weak security implementations in thetested applications.

Methodology

We selected 20 instant messaging/social messagingapplications from the Google Play store based on two fac-tors: keyword results and the number of downloads. Thekeywords usedwhen searching the Google Play Storewere:“chat”, “chatting”, “date”, “dating”, “message”, and“messaging” to select the 20 applications. Within thesesearch results we wanted to pick a wide range of applica-tions based on a spectrum of popularity. The applicationsselected range from 500,000 downloads to over 200million downloads. We would also like to note that wefocused on the sections of these applications with one onone communication. For example, we only studied the“Instagram Direct Feature” and not the Instagram feedfeature. Another example is that we only studied the directmessages in Snapchat and not “Snapchat Stories”.

We performed network forensics to examine thenetwork traffic to and from the device while sending mes-sages and using the various features of these applications.This testing was performed in a controlled lab environmentto reduce network variability due to smartphone devicesoften operating in changing network boundaries. We alsoperformed a forensic examination of the Android deviceitself to retrieve information from the device pertaining toour activities using each of the applications. Table 5 shows alist of the tested applications in the order they were tested,their version numbers, and the features they support. Videodemonstrations of these tests can be viewed at www.youtube.com/unhcfreg.

Network analysis experimental setup

In our research we used an HTC One M8 (Model #:HTC6525LVW, running Android 4.4.2) as well as an iPad 2(Model #: MC954LL/A, running iOS 7.1.2). We created twoaccounts for each application using the Android and iPad 2a week prior to data collection. The Android device was thetarget of our examination, and the iPad was used simply asa communications partner to exchange messages with thetarget device. We used a Windows 7 computer with WiFiand an Ethernet connection to the Internet to set up awireless access point. This PC was used to capture networktraffic sent over WiFi to and from both mobile devices. Thisset up is shown in Fig. 1.

In order to intercept the network traffic, we created awireless access point to which both mobile devices wereconnected. This was established using the Windows 7

Virtual WiFi Miniport Adapter feature. This feature allowsusers to create a virtual network that can act as a wirelessaccess point for multiple devices. To do this, the hostcomputer was connected to the Internet via an Ethernetcable so that the wireless card was not in use. The Ethernetconnection was set to share its Internet access with thevirtual WiFi Miniport Adapter. We executed the commandnetsh wlan set hostednetwork mode ¼ allow ssid ¼ testkey ¼ 1234567890 in order to setup the virtual network.

The network was then enabled using the commandnetsh wlan start hostednetwork. Thus, we were now able tosee and connect to the network test from our targetAndroid device (the HTC One) and the iPad. Next, westarted to sniff the network traffic to and from the mobiledevices by capturing data sent over the virtual connection.The number of packets dropped and the capture rate werenot recorded, as we did not view it as relevant to the goal ofthis research. Wewere focusing solely on the monitoring ofreal time, low-hanging, unencrypted traffic and whetherevidence was captured or not.

Wireshark was used to capture and save the networktraffic. These network traffic files (pcap files) can bedownloaded from our website (www.unhcfreg.com) underData & Tools upon request. After acquiring the traffic cap-ture files, we examined them with Wireshark, Network-Miner, and NetWitness Investigator. A full diagram of thissetup is shown in Fig. 1. We developed an application tostreamline this process, which is highlighted in 6.1.

User activity

Once the network had been setup and the trafficcapturing programs were started, we performed a series ofactions, which we would subsequently attempt to recon-struct through forensic analysis of the Android device andthe captured network traffic. Since every application in ourtest bank had different capabilities (as listed in Table 5), theactions we performed varied between each applicationbecause we wanted to examine all of the messaging typessupported. The actions we performed using each applica-tion are listed in Table 5.

The content of each message sent with each applicationwas different. We used a pool of evidence types to selectfrom: pictures, videos and plain text words. We pulled one

Fig. 1. Experimental network setup.

D. Walnycky et al. / Digital Investigation 14 (2015) S77eS84 S79

item randomly from each evidence type pool based on eachapplication's capabilities. Messages sent and received wereselected from this pool because they deal with thecommunication aspect, which we advocate should be pri-vate, and is a rich source of digital evidence. When a singleactivity trace was found for an evidence type it was docu-mented. We then proceeded to the next network trafficevidence type on our list of application capabilities in Table5 until all capabilities were tested.

Data storage experimental setup

After all network analysis was completed, we imagedthe phone for data storage analysis. We used Micro-systemation's. XRY to perform a logical acquisition of theAndroid device. XRY is trusted by law enforcement,military, and forensic labs in over 100 countries to assistin digital forensic investigations. We cross validated ourresults using the free alternative: Helium backup toretrieve application .db files, then using android backupextractor and sqlite database browser to view contents ofthe .db files. When a single activity trace was found foran evidence type it was documented. We based ourstorage evidence types on chat logs and clear text userprofile data within unencrypted database files. Evidencedocumented for each application was found in a single.db file that contained the chat logs and/or userinformation.

Apparatus

Before beginning our examinations, we installed theentire list of instant messaging applications shown inTable 5 on both of the mobile devices. Table 1 shows a listof all software and hardware used during research.

Experimental results

Four out of the twenty applications, namely Snapchat,Tinder, Wickr, and BBM, encrypted their network trafficusing HTTPS encryption using SSL certificates. We were notable to reconstruct any data from these applicationsthrough traffic analysis, data storage analysis, and serverstorage analysis due to encryption. The overall results areshown in Table 2.

Packet inspectionwas not possiblewith these encryptedapplications. However, during our research we found that16 of the 20 applications tested had unencrypted networktraffic and/or unencrypted data storage of some kind. Thelack of end-to-end encryption may be due to resourcesavailable to developers or because companies deem thisdata as non-privacy invasive. We posit that organizationsthat do not expend resources to encrypt their traffic arecreating potential security/privacy holes.

No terms of service or security/privacy policies wereread before the research. Application pages on theGoogle Play Store either did not acknowledge security/privacy or reference security/privacy as a key feature.The only exception was Wickr, which emphasized secu-rity/privacy.

We would also like to note that false positivesoccurred when advertisements and profile picturethumbnails were unencrypted, but user content wasencrypted. These cases were not documented as evi-dence. False negatives also occurred when we found ac-tivity traces using one tool, but not in another. Therefore,for the traffic reconstruction, we made sure to cross-validate our results using Wireshark, NetworkMiner,and NetWitness Investigator.

Table 1Devices and tools used for application testing.

Device/Tool Use Company Software/OS version

Laptop Create Test Network Using Virtual Mini Port Adapter Windows Windows 7 SP2One M8 (UNHcFREGdroid) Connected to Test Network HTC Android 4.4.2IPad 2 (UNHcFREGapple) Connected Outside Test Network Apple iOS 7.1.2NetworkMiner Observe Live Network Traffic NETRESEC 1.6.1Wireshark Observe Live Network Traffic Wireshark 1.10.8NetWitness Investigator Analyze Network Traffic EMC 9.7.5.9XRY Logical Image Creator/Viewer Micro Systemation 6.10.1Helium Backup Create Android Backup ClockWorkMod 1.1.2.1Android Backup Extractor View Android Backup dragomerlion 2014-06-30SQLite Database Browser View Sqlite/DB files Erpe,tabuleiro,vapour 3.2.0

Table 2Applications tested with no vulnerabilities found.

Applications Capabilities Performed activity Encrypted network traffic, data storage,and server storage

Emphasized security

Tinder Text chat Sent/Received message Yes NoWickr Text chat

Image sharingSent/Received messageSent/Received image

Yes Yes

Snapchat Audio, Video and image sharing Sent imageSent videoReceived video

Yes No

BBM Text chatImage sharing

Sent/Received messageSent/Received image

Yes No


Captured text messages

There were four instances where we were able torecover the actual text messages that were exchanged be-tween the two devices using network traffic analysis.MessageMe, MeetMe, and ooVoo showed when messageswere both sent or received, while we were only able toretrieve text from Okcupid from messages being sent (notreceived).

Captured multimedia content

We were able to reconstruct different types of mediafiles from the network traffic, including images, videos,locations, sketches and audio.

We reconstructed images when testing Instagram,ooVoo, Tango, Nimbuzz, MessageMe, textPlus, TextMe,Viber, HeyWire, Grindr, and Facebook Messenger. The ap-plications Instagram, ooVoo, Tango, Nimbuzz, MessageMe,textPlus, TextMe, Viber and HeyWire did not encrypt im-ages when they were being received, while Grindr failed toencrypt images when they were being sent.

Some applications include a sketching feature, whereone can draw something on the screen and send it to theother party in the communication. We were able toreconstruct sketches from all of the applications listed inTable 5 with sketching features. Furthermore, wewere ableto reconstruct sketches that were received by our device viaViber and MessageMe, and sketches sent by our device viaKik.

Many of the applications allow users to transmit theirlocation using Google Maps; however, most do not protectthis location from being reconstructed by an eavesdropper.We were able to reconstruct location images from TextMe,Viber, and MessageMe when a location was being sent orreceived. We were also able to reconstruct location imagesfromWhatsApp, Nimbuzz, HeyWire, and Hike only when alocation was sent.

As noted in Table 5, numerous messaging applicationshave the capability to share audio and video between users.Out of all the 10 applications that allow video sharing, wewere able to fully reconstruct videos transmitted withViber, Tango, Nimbuzz, and MessageMe.

Out of all the applications tested that can send/receiveaudio transmissions, we could only recover the audio filesfrom MessageMe when the audio was being sent from ourdevice.

Beyond multimedia content sent in messages, we werealso able to reconstruct all of the images from Tango'snewsfeed from the network capture, as well as profilepictures of other Tango users. Interestingly, these profilepictures were not only of contacts we had on our device butseemed to include the profile pictures of other users wecould not identify. This is shown in Fig. 2.

Captured URLs for server-side content

During our network traffic testing we combed pcapfiles using Wireshark to recover links to applicationservers. It was found that these links were still active andled to the media that was sent/received during our testing.This meant that these applications were storing the mediaon servers in an unencrypted fashion and with no meansof user authentication. This allows for any investigatorwith access to these links to download the data. All theselinks were still active weeks after our testing. Table 3shows some of the URLs found in network traffic fromViber, Instagram, ooVoo, Tango, MessageMe, Grindr, Hey-Wire, textPlus, and Facebook Messenger, which point touser content stored on servers belonging to thoseapplications.

Chat logs from device storage

As discussed in Section “Network analysis experimentalsetup”, we employed Microsystemation's.XRY to perform alogical acquisition of our target Android device after the

Fig. 2. Captured profile images from Tango.

Table 3Unencrypted user files on application servers.

Application URL for server-side media

Viber https://s3.amazonaws.com/share2014-04-21/0d1b42b9f6be43c8b83f0ea4b141f8fae4fb5d775093a17c0e06861c6e2e9300.mp4Instagram http://photos-e.ak.instagram.com/hphotos-ak-xaf1/10553994_908375655855764_354550189_n.jpgooVoo http://g-ugc.oovoo.com/nemo-ugc/40051d186b955a77_b.jpgTango http://cget.tango.me/contentserver/download/U8gkjgAAvvzybrAuOcfZPw/9b4IqEqkMessageMe http://watercooler.msgme.im/u/1079175176443879424/m/p3joe2.mp4Grindr http://cdns.grindr.com/grindr/chat/aa0e6063299350a9b80278feb56a8606acae1267HeyWire http://mms.heywire.com/cs/GetImage.aspx?c¼p-&p¼0%2fmms1%2f20140725%2fp-ec2f6715-afeb-4db4-a5c0-8aaf8ac80689.jpegTextPlus https://d17ogcqyct0vcy.cloudfront.net/377/549/1Kw7ihM5Ri1OkDoXWa.jpgFacebook

Messengerhttp://scontent-lga.xx.fbcdn.net/hphotos-xpf1/v/t34.0-12/11156748_10152706456535706_749142264_n.jpg?oh¼efbf52c9c9f74525ced5d3d17642ae69&oe¼553AE540


activities described in the “User activity” section. A logicalacquisition of a mobile device, much like a logical acquisi-tion of a computer hard drive, misses deleted files andother remnants of data which might otherwise be found inunallocated space. Despite this, we were able to locate thedatabase files that applications use to store data, and fromthose files we were able to retrieve full chat logs in plain-text of the text messages sent and received by 8 applica-tions (listed in Table 4).

Other user data from device storage

Our examination of the Android device itself revealedsome additional user data that could be useful during aninvestigation. During the examination of the databases thatthe applications created on the device, we found thatTextMe and Nimbuzz stored sensitive user data, includingthe user's username, email, phone number, birth date, andpassword in plaintext. Fig. 3 shows user data obtained fromTextMe.

Most surprising was a discovery when analyzing thedatabase file for textPlus that the application took andstored screenshots of user activity. When we retrievedthese screenshots from the device storage we becameconcerned that they might be sent from the device to the

application's publisher or to a third-party, but we couldfind no trace of the images in the captured network traffic.If the screenshots were being sent over the network (andwe have no reason to think that they were at the point ofwriting this paper), then they were first encrypted. Weposit that these screenshots could be useful for an inves-tigator seeking to reconstruct user activity on the device.

Summary of results

A summary of all the results of our experiment is shownin Table 5.

Discussion

It is clear from the results shown in Table 5 that theoverwhelming majority of the applications in our experi-ment have significant problems from a user privacyperspective. Users may believe that they are sendingmessages only to their intended recipient, but in the ma-jority of cases their messages or components of theirmessages can easily be recovered by network sniffing or bya logical examination of the device itself.

Investigative significance

From a user privacy perspective our results are obvi-ously problematic, but from a lawful surveillance and fo-rensics perspective, it is welcome. With the combination ofnetwork traffic analysis and device storage analysis, wecreated a 360" view of a user's interactions within theseapplications through an observation of data.

Even though we did not create a new method foranalyzing traffic, we contend that our findings areextremely relevant to the forensics community. Thesefindings serve as commentary specifically on the state ofmessaging applications on the android market today. Weaimed to increase user awareness by showing a layer oftransparency to the applications tested to eliminate as-sumptions about security and privacy within them, but alsoto show investigators how some digital evidence can beeasily reconstructed. This “low hanging fruit” that isunencrypted network traffic and unencrypted data storagehas proven to be a rich source of digital evidence for po-tential cases. Protocols used by these applications leaveusers open to wiretapping because their developers do notoffer end-to-end encryption.

Notifying developers

We notified application developers of the vulnerabilitiesin their software, which permitted us to retrieve so manyforensic artifacts. Our experience in attempting this taughtus that there is no standardized method to inform appli-cation developers of these security issues. We found thatthere was generally no way to truly notify developers ofsecurity issues found from their websites. Even when wesent the companies e-mails through their support contactaddresses we rarely ever received a response. This hintstowards future research in building a system that canstreamline the process of informing companies of security

Table 4Unencrypted chat logs in App DB files.

Application Location of chat logs on android device

textPlus com.gogii.textplus.ab/textPlus.dbNimbuzz com.nimbuzz.ab/Nimbuzz.dbTextMe com.textmeinc.textme.ab/Database.sqlMeetMe com.myyearbook.m.ab/Chats.dbKik kik.android.ab/kikDatabase.dbooVoo com.oovoo.ab/Core.dbHeyWire com.mediafriends.chime.ab/HWProvider.dbHike com.bsb.hike.ab/chats.db

Fig. 3. TextMe's database with user data in plaintext.


issues to ensure that decision makers receive these find-ings. Research like this is important to push both de-velopers and users to care more about security and privacy.A wide range of applications that we tested failed toencrypt their data in one way or another.

Future work

Work still needs to be conducted in this area. For one,these applications change constantly, they receive addedfeatures, updated security, etc. An example of this is

Table 5Application capabilities, actions, and traces.

Applications Capabilities Performed activity Network traffic traces Data storagetraces

Server traces

WhatsApp (2.11) Text chatAudio, video, image, location,and V-card sharing

Sent/Received messageSent/Received voice noteSent/Received imageSent videoSent V-cardSent/Received GPS location

V-Card Location (Sent)

Viber (4.3.0.712) Text chatVoice callAudio, video, image, sketch,and location sharing

Sent/Received messageSent/Received sketchSent/Received imageSent/Received voice noteReceived voice callSent/Received GPS location

Images (Received)Sketches (Received)Video (Received)Location (Sent/Received)

Images,Video,Sketches

Instagram (6.3.1) Text chatVideo and image sharing

Sent/Received image Images (Sent/Received) Images

Okcupid (3.4.6) Text chat Sent/Received messageSent/Received image

Text (Sent)

ooVoo (2.2.1) Text chatVoice callVideo callVideo and image sharing


Text (Sent/Received)Images (Sent/Received)

Chat Log Images

Tango (3.8.95706) Text chatVoice callVideo callAudio, Video, and image sharing


Images (Sent/Received) Videos

Kik (7.3.0) Text chatVideo, image, and sketch sharing

Sent/Received messageSent/Received imageSent/Received sketch

Sketches (Sent) Chat Log

Nimbuzz(3.1.1)

Text chatVoice callAudio, video, image, and locationsharing

Sent/Received messageSent/Received imageSent/Received GPS LocationSent/Received Video

Location (Sent)Images (Sent/Received)Video (Sent)

Plain TextPasswordChat Log

MeetMe (8.6.1) Text chatImage sharing


Text (Sent/Received) Chat Log

MessageMe (1.7.3) Text chatAudio, video, image, sketch,and location sharing

Sent/Received messageSent/Received imageSent/Received sketchSent/Received GPS LocationSent/Received VideoSent/Received Music

Location (Sent/Received)Text (Sent/Received)Images (Sent/Received)Sketches (Received)Music (Sent)

Videos

TextMe (2.5.2) Text chatVoice callVideo callVideo and image sharing

Sent/Received messageSent/Received imageSent Dropbox fileReceived video

Location (Sent/Received)Images (Received)

Plain TextPasswordChat Log

Grindr (2.1.1) Text ChatImage and location sharing


Images (Sent) Images

HeyWire (4.5.10) Text chatVoice callAudio, image, and location sharing

Sent/Received messageSent/Received imageSent/Received GPS Location

Location (Sent)Images (Received)

Chat Log Images

Hike (3.1.0) Text chatVoice callAudio, video, image, location,and V-Card sharing

Sent/Received messageSent/Received imageSent/Received GPS Location

Location (Sent) Chat Log

textPlus (5.9.8) Text chatVoice callAudio and image sharing


Images (Sent/Received) App TakenScreenshots,Chat Log

Images

Facebook Messenger(25.0.0.17.14)

Text chatVoice callAudio, video, image, location,and stickers

Sent/Received messageSent/Received imageSent/Received videoSent/Received audioSent/Received GPS locationSent/Received stickers

Images (Sent/Received)Video Thumbnails (Received)

Images,VideoThumbnails


Facebook Messenger's new in-app downloads. Applica-tions, whether in Facebook Messenger or not, can storedata differently depending on user settings, OS version, andmanufacturer. Therefore, continuous testing needs to beperformed on new versions of these applications/OSs asthey are released to determine what has changed and howmuch of the prior knowledge of these applications stillholds true.

Checking each version of an application for digitalforensic artifacts in the manner that this research wasconducted would take a long time. This is why the future oftesting needs to move towards a more automated process.In our research group, we have been working on a projectto analyze the activity of applications installed on a deviceto determine network traffic encryption and what servicesthe applications are communicating with (see Section“Datapp”).

The 20 applications chosen are not the only messagingapplications on the Android market, and there is clearlyplenty of scope for similar testing to be conducted on othermessaging applications. As mentioned before, many of thesocial media applications, such as Facebook, have their ownmessenger systems, which also require network trafficanalysis. Furthermore, applications that could store andsend data securely on one operating system may not do soon another, so testing needs to be performed acrossdifferent operating systems.

Datapp

There is very little effort required to reconstruct thediscussed digital evidence; the tools we used automatedthe process. Our results can be attained with free tools, andby anyonewith a laptop and two small scale digital devices.After we completed our research, we developed our owntool called “Datapp” to further automate the process tomake it even easier for anyone to conduct application se-curity and privacy testing. Datapp leverages open sourceprojects like NetworkMiner. The tool automatically createsa wireless network, and sets up packet capture on a system,and displays the results in real-time. This tool was mostlycreated for the laymen, so that in the future they can testtheir own applications. Datapp is available for downloadfrom our website (www.unhcfreg.com) under Data& Tools.

Conclusion

In this paper, we investigated 20 Android applicationsthrough network traffic analysis and server/device storageanalysis. This was performed in order to examine the digitalevidence that could be of value to forensic examiners andalso to evaluate application security in sending/receivingdata and application privacy in storing data. Our workshowed a variety of results.

We were not able to retrieve any user related informa-tion from Snapchat, Tinder,Wickr, or BBM. In the remaining16 applications, we were able to reconstruct at least someevidence of unencrypted data that was sent and/orretrieved by our device. Despite the advantages for thedigital forensics community, these findings are

troublesome from a user privacy perspective. It would bequite easy for a nefarious user to sit in a public place withfree WiFi, like a caf!e, airport or library, and capture largevolumes of personal communications, both in the form oftext messages and shared photos. The fact that many ofthese applications store sent/received media on theirservers in an unencrypted format with no user authenti-cation method is also troublesome. It appears that the onlyuser privacy protection in place for such content is theanonymity of the URL.

Overall our work shows that many popular messagingapplications have some major vulnerabilities in terms ofhow they store and transmit data. From a forensicsperspective this facilitates the potential reconstruction oflarge parts of user instant messaging activity, but from aprivacy perspective it also exposes the personal com-munications of users to potentially malevolent thirdparties.

References

Al Mutawa N, Al Awadhi I, Baggili I, Marrington A. Forensic artifacts ofFacebook's instant messaging service. In: Internet Technology andSecured Transactions (ICITST), 2011 International Conference for;2011. p. 771e6.

Al Mutawa N, Baggili I, Marrington A. Forensic analysis of socialnetworking applications on mobile devices. Digit Investig Aug. 2012;9:S24e33.

Anglano C. Forensic analysis of WhatsApp messenger on Androidsmartphones. Digit Investig 2014;11(3):1e13.

Ashby v Commonwealth of Australia (No 4) [2012] FCA 1411.Barmpatsalou K, Damopoulos D, Kambourakis G, Katos V. A critical review

of 7 years of Mobile device Forensics. Digit Investig 2013;10(4):323e49.

Chin E, Felt A, Greenwood K, Wagner D. Analyzing inter-applicationcommunication in Android. In: Proc. 9th …; 2011. p. 239e52.

Damopoulos D, Kambourakis G, Anagnostopoulos M, Gritzalis S, Park JH.User privacy and modern mobile services: are they on the same path?Pers Ubiquitous Comput 2013;17:1437e48.

Dickson M. An examination into AOL Instant messenger 5.5 contactidentification. Digit Investig 2006a;3(4):227e37.

Dickson M. An examination into Yahoo messenger 7.0 contact identifi-cation. Digit Investig 2006b;3(3):159e65.

Dickson M. An examination into MSN messenger 7.5 contact identifica-tion. Digit Investig 2006c;3(2):79e83.

Dickson M. An examination into Trillian basic 3.x contact identification.Digit Investig 2007;4(1):36e45.

Grover J. Android forensics: automated data collection and reporting froma mobile device. Digit Investig 2013;10:S12e20.

Husain M, Sridhar R. iForensics: forensic analysis of instant messaging onsmart phones. Digit Forensics Cyber Crime 2010;31:9e18.

Kiley M, Dankner S, Rogers M. Forensic analysis of volatile instantmessaging. In: Advances in digital forensics IV, vol. 285. Boston:Springer; 2008. p. 129e38.

Lessard J, Kessler GC. Android forensics: simplifying cell phone exami-nations, small scale digit. Device Forensics J 2010;4(1).

Reust J. Case study: AOL instant messenger trace evidence. Digit Investig2006;vol. 3(4):238e43.

S v Oscar Pistorius (CC113/2013) [2014] ZAGPPHC 793 (12 September2014).

Schrittwieser S, Frühwirt P, Kieseberg P, Leithner M, Mulazzani M,Huber M, et al. Guess who's texting you? evaluating the security ofsmartphone messaging applications. In: Proc. 19th Annu. Symp. Netw.Distrib. Syst. Secur.; 2012. p. 9.

Taylor M, Hughes G, Haggerty J, Gresty D, Almond P. Digital evidence frommobile telephone applications. Comput Law Secur Rev 2012;28(3):335e9.

Vidas T, Zhang C, Christin N. Toward a general collection methodology forAndroid devices. Digit Investig Aug. 2011;8:S14e24.

Willassen SY. Forensics and the GSM mobile telephone system. Int J DigitEvid 2003;2(1).


Network And Device Forensic Analysis Of Android Social ... · DFRWS 2015 US Network and device...

Documents

Transcript of Network And Device Forensic Analysis Of Android Social ... · DFRWS 2015 US Network and device...