Showing posts with label Android OS. Show all posts
Showing posts with label Android OS. Show all posts

Sunday, June 14, 2015

Android Copy and Paste - what risks?

This discussion may be relevant and useful to the process of evidence gathering, eDiscovery investigations and examiner procedures. Experienced examiners or investigators, new to industry or students that may be unaware of this subject matter.

The Android clipboard-based framework (Android Content Provider) enables copy and paste directly to and from the clipboard not only of simple text but also complex data structures, text and binary stream data and application assets.


Key Classes

- ClipboardManager
- ClipData
- ClipData.Item
- ClipDescription
- Uri
- ContentProvider
- Intent
This content provider enables the distribution of objects stored on the clipboard to be distributed among user applications subject to the permission granted for copying and pasting outside of a particular application.
The practical application for using clipboard copy and paste might be generally understood by smartphone users but the less experienced smartphone user may not know or realise that items stored on the clipboard may still reside in memory on particular smartphones long after the paste function was used. The same might also apply to examiners relying on extracted and harvested data from a DUT (device under test) using a particular examination tool of choice. The tool may not logically recover clipboard objects. Moreover, the copied data may not be distinguishable from a deleted SMS message when carving data from a physical extracted dump (JTAG/chip off), so checking the clipboard identifies is important.
 
 
Conduct a test on a smartphone of your choice. Tests run on a random number of makes/models not all were found to allow revisiting pasted data from previous copying, not all allowed data copied in one application (e.g. WhatsApp) to be made available to another (e.g. text messaging). Thus, manual examination might need to be applied during an examination process in order to determine during discovery any vital data (evidence) excluded during a tool’s recovery procedure.
As there are variances between makes/models it equally raises concerns of any missed opportunities to recover data during past examination.
DUT – Samsung GT-I9100P
 
 
Android OS version – Ice Cream Sandwich

COPY AND PASTE

The manual examination test applied: select a new, blank SMS test message page and apply continued finger pressure to the text message field. The DUT vibrates and the dialogue box offers two options: PASTE or CLIPBOARD (see image below). Select CLIPBOARD.



The DUT responds with multiple choice of previously copied data that may be reused.  The first entry box is a copy message from the Samsung SMS text message application. The copied data with a stated date and time stamp in the fourth entry box is data copied from a message in WhatsApp.



Note the format change of the date and the clock is out by one minute, when cross-referenced to the WhatsApp image below. Is this down conversion from one application to another?  Are there two clocks being used on the same smartphone? Was the SMS message created first and copied and pasted into WhatsApp? Or is it something else?



Further issues to be considered. Subject to the matter as mentioned above regarding permission granted to copy and paste outside of a particular application; Android in itself does not require any permission to be entered to write data to or read data from the clipboard. Consequently, this can leave a security loophole in place where an application requires a user to copy their credentials (passwords, PINs etc.) first before the user may make use of an application.
Moreover, the android.content.ClipboardManager.OnPrimaryClipChangedListener is an interface within Android SDK enabling listener call-back that is invoked each time a clipboard item changes. A change in password, PIN etc updated by a particular application could update the clipboard previously stored data. This could be problematical by causing a breach in security if malware were to be unintentionally installed to the smartphone and then credentials leaked to an outside source. The smartphone security for copy and paste therefore can only be as good as the permission granted within the applications being installed and used.

Observations. When making analysis of security an examiner/investigator simply referring to the latest makes/models of smartphones or apps on the market may well be flawed in using that analytical approach. There are a considerable number of handsets out there which are in use on a day-to-day basis for work and personal activity. These can be e.g. 5yrs to 10yrs old. Operators are currently offering an alternative to subsidised handsets by offering SIM ONLY contracts. The smartphone won’t be updated. Companies may well fail in their fiduciary responsibilities and duty of care at board level owed to the company to offload natural company expenditure by avoiding providing communication devices to company employees. To foster the notion to employees to BYOD (bring your own device) the employee is in fact playing a part in subsidising a company’s communications system and therefore its security; retains the opportunity for security loopholes to be created by employers assuming that smartphone users know everything about their smartphone, which is a fallacy.

Saturday, April 04, 2015

Android Botnet for SMS

Another area where SMS text messages may not have received as much scrutiny is regarding messages sent by mobile botnets. If I may I will re-emphasise the following point, the purpose of the discussions here and below are not as a criticism about tools or processes that are used in extracting, harvesting and/or treating recovered data but that data analysis is still required and cannot be rushed. If the examiner doesn't perform the analysis task does the officer or investigator (who may have considerably less experience) left to perform that role?

To avoid confusion a starting point about reference to botnets is required. One contribution is this intro into botnets: https://www.usenix.org/legacy/event/leet11/tech/slides/xiang.pdf 

The video below shows how one hacker, Georgia Weidman (2011), developed an Android Smartphone Botnet to send SMS text messages.




A brief description of the code (botPoCrelease-android.c) that use the smartphone to spawn messages using a Master/Slave/Target combination to hide the identity of the Master to the Slave.

==============================================================
Compile with arm-gcc with the -static flag set
Copy to anywhere on the underlying OS that is writable (/data/ is good).
Rename /dev/smd0/ to /dev/smd0real/
Start the bot application
Kill the radio application (ps | grep rild)
The radio will automatically respawn and now the bot proxy will be working
==============================================================

The original botnet code has been in the hacking community since 2011 but currently the code is hard to find. There is a sanitised version available though.














This proof of concept mobile botnet to generate SMS text messages still relies upon knowing the target's mobile number. The analysis thus focussing on the sending party (Master) knowing the recipient mobile number (Target) to hand to the donor (Slave). In the alternative, harvested mobile numbers returned from ICMP (or similar) pings via the internet could generate a high harvest of returned MSISDNs without the Target knowing his/her MSISDN has been acquired to send messages(SMS spam, etc.).


Saturday, June 15, 2013

Android z7.logs

A SDcard logs examined from a:

1. Samsung Galaxy SII NFC
2. Android OS
3. z7logs
4. z7.log.x (x = 1 or 2)

The log examined z7.logs.2 using notepad reveals the sample of the data below:

    - z7.log.2
    3 Sep 2012 11:45:35 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Timescape deactivated
    3 Sep 2012 11:45:35 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(-)
    3 Sep 2012 11:46:20 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(+)
    3 Sep 2012 11:46:20 INFO[0][ANSharedCommon[Thread[main,5,main]]]Intent action: com.sonyericsson.android.timescape.plugin.intent.action.ACTIVATE
    3 Sep 2012 11:46:20 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Timescape activated
    3 Sep 2012 11:46:20 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Notifying Timescape to requery TimescapeProvider.
    3 Sep 2012 11:46:20 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(-)
    3 Sep 2012 11:46:29 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(+)
    3 Sep 2012 11:46:29 INFO[0][ANSharedCommon[Thread[main,5,main]]]Intent action: com.sonyericsson.android.timescape.plugin.intent.action.ACTIVATE
    3 Sep 2012 11:46:29 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Timescape deactivated
    3 Sep 2012 11:46:29 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(-)
    3 Sep 2012 11:47:31 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(+)
    3 Sep 2012 11:47:31 INFO[0][ANSharedCommon[Thread[main,5,main]]]Intent action: com.sonyericsson.android.timescape.plugin.intent.action.ACTIVATE
    3 Sep 2012 11:47:31 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Timescape activated
    3 Sep 2012 11:47:31 WARNING[0][ANSharedCommon[Thread[main,5,main]]]Notifying Timescape to requery TimescapeProvider.
    3 Sep 2012 11:47:31 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(-)
    3 Sep 2012 11:48:04 INFO[0][ANSharedCommon[Thread[main,5,main]]]onReceive(+)
    3 Sep 2012 11:48:04 INFO[0][ANSharedCommon[Thread[main,5,main]]]Intent action:

The history to this SDcard is that it is currently being used in :

- Samsung Galaxy SII NFC

It was used in a:

- Samsung Galaxy Ace2
- Android OS

The card originated from an:

- Song Ericsson Xperia X10 mini Fashion Edition
- Android OS

The last entry SDcard z7.log.2 file date is 08/09/2012 although the last record entry in the log is 03 September 2012. The 08/09/2012 date is correct because the Samsung Galaxy Ace2 was received on the 04/09/2012 but the SD card was migrated to the Samsung Galaxy Ace2 when it was first used 08/09/2012 and later again migrated to the Samsung Galaxy SII NFC on the 05/12/2012.

Just one thing the Xperia was never used for internet or email etc only calls and texts.