Mobile app intrusion diary (on)

[0x00]-Overview

[0x01]-application monitoring

[0x01a]-insecure Data Storage

[0x01b]-decompilation program installation package

[0x02]-Man-in-the-middle attack

[0x02a]-tool preparation

[0x02b]-Man-in-the-middle attack

[0x03]-server attack

[0x03a]-Scan

[0x03b]-Get Permissions

[0x03c]-bypassing anti-virus software

[0x03d]-win the system !!

[0x03e]-no end !!

[0x04]-Thank you

 

-----------------------------------------

 

"Over the past few years, we have witnessed the rapid development of mobile phones from simple to complex. As these devices become more and more intelligent, mobile network speeds are getting faster and faster. People not only use mobile phones to send messages, but also make phone calls. It is more used for sending emails, surfing the Internet, playing games, querying flight information and online banking services.

The company began to develop exclusive applications for customers to provide various services. Today, we can use mobile apps to synchronize files to the cloud, log on to social networking websites, and even chat with frogs (Note: The game "Talking frogs ").

Because the data stored, processed, and transmitted by mobile phones are often important or private, it is necessary to ensure that mobile phones have a good security control mechanism. "

-- SANS penetration test blog

 

 

To study Android applications (Android is a linux-based operating system developed by google and the Open Mobile Alliance. Applications are written in Java and the software stack of the Android operating system is composed of a series of Java applications running on the Dalvik Virtual Machine (DVK ). We conducted penetration tests.

This article summarizes our testing skills. The main features of apps on Android are similar to those of the famous Apple icloud: synchronizing photos, videos, and contacts to the personal cloud.

Let's get started! (￣)

 

[0x01]-application monitoring
 

"Normally, a client software is installed on a mobile phone and acts as a front-end to interact with users. Software packages can be downloaded through the app store or the website of software developers. These apps may contain many vulnerabilities.

It should be pointed out that if we want to test the client device, we need to perform root or jailbreak on the device. This is because the system generally does not allow you to access all files on the local machine. In addition, the software package may be decompiled and modified through reverse engineering. You certainly do not want to restrict the software you have installed ."

-- SANS penetration test blog

Our first task is to monitor the running status of the application software. This is done to understand how the application works, and then try to find sensitive information from the files stored on the local machine, or even mine more information, therefore, the software package is decompiled into the source code format.

 

[0x01a]-insecure Data Storage

To start our first task, we need to build an Android penetration testing platform (install Android SDK, Android Emulator and Burpsuite) and then use ADB (Android Debug Bridge, http://developer.android.com/tools/help/adb.html) to connect to our mobile phone. ADB is a powerful command line tool that allows us to interact with Android devices or simulators.

First, we log on to the mobile terminal, and then connect to the mobile phone using the "ADB devices" command in debug mode.

---------------------------------------------------------------[zeq3ul@12:03:51]-[~]> adb devices* daemon not running. starting it now ** daemon started successfully *List of devices attached3563772CF3BC00FH device---------------------------------------------------------------

 

Then we use the "adb shell" command to connect to the mobile phone and access the internal directory.

 

Before making a step, you must confirm the real name of the target application installation package, which is usually stored in the "/data/app/" file in the form of a ". APK" file.

We found that the real name of our target app "com. silentm. msec-v12" is "/data/app/com.silentm.msec-v12.apk ".

Finally, in "/data", the folder of the application is most likely the location where the sensitive information of the application is stored. As expected, we found the following important information in "/data/com. silentm. msec-v12/shared_prefs.

---------------------------------------------------------------[zeq3ul@12:05:24]-[~]> adb shell# cd /data/data/com.silentm.msec-v12/shared_prefs# cat PREFS.xml<?xml versions='1.0' encoding='utf-8' standalone='yes'?><map><string name="Last_added">9</string><boolean name"configured" value="true"/><string name="package">Trial</string><string name="version">1.2</string><string name="username">zeq3ul</string><string name="password">NXBsdXM0PTEw</string><string name="number">089383933283</string><string name="supportedextension">{&quote;D&quote;:&quote;HTML,XLS,XLSX,XML,TXT,DOC,DOCX,PPT,PDF,ISO,ZIP,RAR,RTF&quote;,&quote;M&quote;:&quote;MP3,MP2,WMA,AMR,WAV,OGG,MMF,AC3&quote;,&quote;I&quote;:&quote;JPEG,JPG,GIF,BMP,PNG,TIFF&quote;,&quote;V&quote;:&quote;3GP,MP4,MPEG,WMA,MOV,FLV,MKV,MPEG4,AVI,DivX&quote;}</string>...</map>---------------------------------------------------------------

 

 

In the file PREFS. the username and password are found in xml, but the password is encrypted. However, after careful reading, we will find that the password is encrypted by base64 and can be easily decrypted." NXBsdXM0PTEw ">" 5plus4 = 10 ″

Tip: This program is a negative example. It stores sensitive information locally and uses base64 to store passwords.
Encode (encoding! = Encrypted). This is not correct !!! The code used is as follows:

---------------------------------------------------------------        public void saveCredentials(String userName,String password)        {        SharedPreferences PREFS;        PREFS=getSharedPreferences(MYPREFS,Activity.MODE_PRIVATE);        SharedPreferences.Editor editor = PREFS.edit();        String mypassword = password;        String base64password = new String(Base64.encodeToString(mypassword.getBytes(),4));        editor.putString("Username", userName);        editor.putString("Password", base64password);        editor.commit();        }---------------------------------------------------------------

 

[0x01b]-decompilation program installation package

 

Next, we need to get the program source code to gain a deep understanding of the application's working mechanism. For Android apps, you can use the android Program Package (.apk.

Android Program Package (.apk ") is essentially a ZIP file, including AndroidManifest. xml, classes. dex, resources. arsc, and other parts. You can rename the package, and then open it in a ZIP file to view its content.

We use the "adb pull" command to extract the Android app from the mobile phone:

 

---------------------------------------------------------------[zeq3ul@12:08:37]-[~]> adb pull /data/app/com.silentm.msec-v12.apk1872 KB/s (5489772 bytes in 2.862s)---------------------------------------------------------------

Next, we will use the dex2jar (http://code.google.com/p/dex2jar/ plugin to decompile our own. APK file. Dex2jar can convert ". dex" into a readable ". class" file in Java.

 

Note! Your class.dex.pdf file is stored in every Alibaba .apk file we just picked up. You can verify the structure of the ".apk file by converting the ".apk.pdf file to the ".zip file.

---------------------------------------------------------------[zeq3ul@12:09:11]-[~]> bash dex2jar.sh com.silentm.msec-v12.apkdex2jar version: translator-0.0.9.8dex2jar com.silentm.msec-v12.apk -> com.silentm.msec-v12_dex2jar.jarDone.---------------------------------------------------------------

 

Finally we use JD-GUI (http://java.decompiler.free.fr /? Q = jdgui) is used to read the decompiled source code (the ". jar" file generated by dex2jar ). In this example, it is the file "com. silentm. msec-v12_dex2jar.jar.

 

Note: The JD-GUI is a graphical interface tool that we can use to view the ". class" file. You can through the JD-GUI to browse the source code refactoring, so that you can directly view the method in the source code, there is a domain Oh.

 

In the end, we found that "Config. class" stores hard-coded information. The Code is as follows:

Config.class---------------------------------------------------------------package com.silentm.msec;public class Config{public static final String CONTACT_URL = "http://203.60.240.180/en/Contact.aspx";public static final String Check_Memory = "http://203.60.240.180/en/CheckMem.aspx";public static final String BackupSMS = "http://203.60.240.180/en/backupsms.aspx";public static final String Forgot_Password = "http://203.60.240.180/en/ForgotPassword.aspx";public static final String FTP_URL = "203.60.240.183";public static final String FTP_User = "msec1s";public static final String FTP_Password = "S1lentM!@#$ec";public static final String Profile = "http://203.60.240.180/en/Profile.aspx";public static final int MAX_MEMORY = 500;public static final int LOG_COUNT = 30;...}---------------------------------------------------------------

 

Let's explain it here !! We found the URL and FTP username and password in the source code (unbelievable !!). Now we know that this application uses the FTP protocol to transmit images, text messages, and contact information to cloud servers. Because it is hard-coded and FTP is insecure, it is extremely dangerous to transmit data in this way.

---------------------------------------------------------------public void saveCredentials(String userName,String password){SharedPreferences PREFS;PREFS=getSharedPreferences(MYPREFS,Activity.MODE_PRIVATE);SharedPreferences.Editor editor = PREFS.edit();String mypassword = password;String base64password = new String(Base64.encodeToString(mypassword.getBytes(),4));editor.putString("Username", userName);editor.putString("Password", base64password);editor.commit();}---------------------------------------------------------------

 

[0x02]-Man-in-the-middle attack

"The second layer of the attack is the channel for attacking the client to communicate with the server. Although applications are using increasingly secure transmission methods to transmit sensitive information, this is not always the case. During the test, we can use the HTTP proxy to interrupt and modify the information.

If the application does not use the HTTP protocol for communication, you can use transparent TCP and UDP proxies, such as Mallory. By using a proxy, You can interrupt, analyze, and modify the communication between the client and the server ."

── SANS penetration testing blog

 

Because we already know that our application uses the HTTP protocol, the next step is to install an HTTP Proxy tool, such as ZapProxy or burpsuit (in this example, select burpsuite ).

To demonstrate man-in-the-middle attacks on the application, a web Proxy is used to interrupt requests. Starting from this, we will use similar technologies as general web penetration testing.

We use burpsuite (http://www.portswigger.net/burp/) to intercept every HTTP request and response. By intercepting HTTP requests, we find sensitive information (username and password) sent to the server, because it uses HTTP to transmit plaintext information (which can be seen by intermediate nodes in communication, this application is really bad !!), As shown below.

 

 

---------------------------------------------------------------POST http://203.60.240.180/en/GetInfo.aspx HTTP/1.1Content-Length: 56Content-Type: application/x-www-form-urlencodedHost: 203.60.240.180Connection: Keep-AliveUser-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)imei=352489051163052&username=zeq3ul&password=5plus4=10---------------------------------------------------------------

In addition, we also found amazing information in the HTTP Response: Someone's email account and password (which we later found to be an administrator's email) are displayed in front of us!

 

Burpsuite: HTTP Response

---------------------------------------------------------------HTTP/1.1 200 OKCache-Control: privateContent-Type: text/html; charset=utf=8Server: Microsoft-IIS/7.0X-AspNet-Version: 2.0.50727X-Powered-By: ASP.NETDate: Fri, 07 June 2013 12:15:37 GMTContent-Length: 2405{"AppVersion":"1.2","FTP_USER":"msec1s","FTP_PASS":"S1lentM!@#$ec","FTP_SERVER":"203.60.240.183","MAX_MEMORY":"500","LOG_COUNT":"30","Smtp":"smtp.gmail.com","FromEmail":"mseccloud@gmail.com","FromEmailPwd":"M[Sec)0/",................---------------------------------------------------------------

 

To sum up, we can sniff the user name and password transmitted in plain text (neither SSL nor encryption, there is also an administrator's mailbox account "mseccloud@gmail.com" and password "M [Sec) 0/" in the HTTP response /".

 

At this point, our attack is half done. The previous stage is the information collection stage. The more information the target is collected, the smoother the attack that follows. Countless painful cases tell us that the target will be attacked without collecting information. In the future, only half of the success will be achieved, and the other administrator will be easily informed of your attack behavior.

 

Link: http://www.exploit-db.com/papers/26620/