Droidbox, Study of Android Dynamic Analysis (✖╭╮✖) (day 4)

My teacher always encourage me about reading paper of research in order to up to date with the current method whether it is android malware or android pentest topic. I have read a lot of awesome research that truly open my eyes in the field of research and development in mobile security. So when i try to do my daily search of interesting topic, i came across with this really cool tool called "DROIDBOX".

Credit goes to the author, this post is inspire from the following link: https://www.honeynet.org/node/1317

Before we going to talk more about "DROIDBOX". Let me explain some simple concept.

In the field of security there are two analysis that is typically known. One is static analysis and the other one is dynamic analysis.

Static analysis is where you try to find some interest(e.g: malicious class, vulnerable component) in the application without executing it in the safe environment. So long story short most of the time you will do reverse engineering and string analysis.  The point of static analysis is to give you better overview of the application so that you can get enough information that will lay foundation of the next step of your analysis which is dynamic analysis.

Dynamic analysis is analyzing the application with executing the application in the safe environment whether in docker or virtual machine. The point of dynamic analysis is to have better insight on the behavior of the application. Dynamic analysis could be achieve by network analysis, debugging, memory analysis or sending an event to the application to trigger an interesting behavior.

Droidbox is the dynamic analysis platform sandbox built based on taintdroid. It will record and generate information based on the dynamic behavior that happened from the application.

The following information is described in the results, generated when analysis is complete:

• Hashes for the analyzed package
• Incoming/outgoing network data
• File read and write operations
• Started services and loaded classes through DexClassLoader
• Information leaks via the network, file and SMS
• Circumvented permissions
• Cryptographic operations performed using Android API
• Listing broadcast receivers
• Sent SMS and phone calls

(i copy paste it from the github page :p)

you could check the official repository of the droidbox in the following github page: https://github.com/pjlantz/droidbox 

what so cool about droidbox development is that it's already provide with docker container that could be use right away for analyzing application.

link: https://hub.docker.com/r/honeynet/droidbox/

it is really simple first you just have to pull the image and you are ready to go(mind your internet connection because the image is pretty big):

~# docker pull honeynet/droidbox

first you need to create a directory that will have the analyzed application for this post i will try to analyze the triada malware apk that i got. The name is not really that important you can name it anything you want.

all of the result of the analysis will go into this directory. Fire up the docker by putting these command.

Notice that if you use this command after you deploy the docker it will automatically delete itself from the process. I set Droidbox to analyze the application time limit to be 10 seconds(longer the better)

When the droidbox is running it will take your CPU power massively(and your computer fan maybe will go crazy) but don't worry it doesn't take your memory much.

Don't worry if the format is not really that good to read, you can check the result in more readable format in directory called "out" that will contain all the result of the analysis.

lets open the analysis.json file (i use lolcat)

first thing that make me confuse is the "proc/PID/cmdline" it shows that the apk access and read the following file. Why android malware application want to access cmdline file ?

i try to read the manual about the file but it still make me confuse, it explain like this:

/proc/[pid]/cmdline
    This holds the complete command line for the process, unless the process is a zombie.  In the  latter
    case, there is nothing in this file: that is, a read on this file will return 0 characters.  The com‐
    mand-line arguments appear in this file as a set of strings separated by null bytes  ('\0'),  with  a
    further null byte after the last string.

all i can get from this explanation is that when you try to do command line execution the process will be store in the /proc/[pid]/cmdline file based of the reserved PID. But it still don't show any motive about why malware wants to access this file.

after several minute of research i think i found the answer, it is from the research paper called "Mobile Root Exploit Detection based on System Events Extracted from Android Platform", it explain like this:

"When  rooting  process  begins,  firstly BinBreak searches  and  finds  out  PID  of  Volume  Daemon.  It  can  be  accomplished  by  looking  for  each  file  named  /proc/<PID>/cmdline, where PID means currently running processes’ PID. Currently running process  can  be known  from  /proc/net/netlink  file.  Once  identifying Volume Daemon’s PID, malware retrieves device-related information from  /etc/vold.fstable  that  is  a  file  system  table  of  Volume  Daemon. With use of Volume Daemon’s PID, socket connection is established. Finally,  it  sends  specific  message  through  the  connection  and  gains root privilege. "

link:https://pdfs.semanticscholar.org/5a9d/f5f40da8363e99300b37ac01cd6f31f0c00f.pdf

what i could i summarize from the following explanation is that in order the malware to gain root privilege first it will check the Volume daemon PID by checking the "/proc/<PID>/cmdline". Volume daemon or so called volume management daemon(vold) is the who responsible for mounting and unmounting SD card. These particular daemon always listening connection from NETLINK socket and the bad things about the service is that never check where the source is of the packet originally come from. So any application could create a NETLINK socket connection and send a specifically crafted message to the vold that will lead to memory corruption, execution of arbitary code and gain root privilege.

these mechanism of exploitation is known as gingerbread(CVE-2011-1823)

link to more detail explanation:https://books.google.co.id/books?id=AKbNBgAAQBAJ&pg=PA18&lpg=PA18&dq=volume+daemon+android,+root&source=bl&ots=Mbm7whKFiL&sig=VnTitgGAYP1XfiI0CROY94az__E&hl=en&sa=X&ved=2ahUKEwjs_sfpxeXeAhUJ2o8KHaOSCVw4ChDoATAAegQIChAB

another interesting information that i could obtain is the "com.hd.android.tubede" package from dexclass.

i'm just being honest i have no idea what this package for. All i can find is that the following apk have connection to trojan application:

link: https://blog.zimperium.com/wp-content/uploads/2016/08/HummerTrojan-IOCs.pdf

(i will try to research application next time and update this post)

That's all that i could mustard up for this post. I'm sorry if my power of analyzing android malware really not that good