Android Application Assessment – Part III

This post covers some more android application specific attacks and tools which may further help you in pentesting your android app.

Please note for an android application that connects to internet via Wifi or GPRS, you need to inject a proxy and perform testing similar to web application testing. In this case, all applicable web application tests would apply. Check here to set up a proxy in android emulator.

Application Process and Inter-Communication Inspection

The objective is to look for internal system calls made by your application, screen grabbing without rooting your device, local data spoofing, view processes and application state information. The utility we use here is a GUI version of adb.exe i.e. ddms.bat. The default location of this utility is C:\Program Files\Android\android-sdk\tools. Below is how you can have access to all above mentioned data:

Browse to location \Android\android-sdk\tools via command prompt

Locate and execute ddms.bat to get below screen:

Insecure Cryptographic Storage

The objective of this test is to look for hardcoded keys the application may store to perform encryption and decryption of data at rest or in transit. Application decompilation should do most of your work which is detailed in my last post. Places to look for:

• Methods like javax.crypto.Cipher.init() in class file
• Class name should give you the direction
• Application homepage /login page may perform some encryption logic

Useful Tools

Below are some of the android application specific tools (apart from which I mentioned in this series) that may help you further investigate or look for more issues:

Intent Fuzzer – Supply random, invalid data to test how your application reacts to it.

Intent Sniffer – Monitor and intercept intent of your application

BusyBox – Bundle of Unix tools to test your android application

Wireshark – Most of you must be aware of its functionality. Combine it with RawCap to analyze the traffic

I hope you have found this series useful in pentesting your android applications. I await your feedback..:)

Happy Reading!!!

Android Application Assessment – Part II

I hope my last post helped you to kick off android application pentest. In this post, I will cover application specific attacks/checks using adb.exe (Android Debug Bridge) from SDK toolkit.

Android Application Decompilation

I assume you already have application installable .apk file saved onto your local drive (If not, please refer to my last post). In simpler terms, decompilation is the method to view application files. Steps for application decompilation are:

• Rename your application file from .apk to .zip or .rar
• Extract the zipped file to view application files

Files of interest are:

• AndroidManifest.xml - Contains application permission, configuration settings, filters, service settings. Look for application permission or any external service call. More information can be found here.
• Classes.dex – Contains application source code i.e. class files, java files, xml files, etc. Look for business logic implementation, encryption/decryption logic, hard-coded credentials, test data.

There are high chances of AndroidManifest.xml file being encoded, so you need to decode it using a third party tool before you can actually view it. Download AXMLPrinter2.jar utility from here. Below are the steps to decode AndroidManifest.xml file:

You should now be able to view your application AndroidManifest.xml in cleartext.

Another method to inspect AndroidManifest.xml file is to download and install Manifest Explorer application on to your android device as shown:

The next step is to decompile the classes.dex file. This is the most important file to inspect from security point of view. Here’s how you can decompile it:

• Download a third party tool named dex2jar from here
• Below is the command to convert dex file to jar:

• Locate the created jar file and rename it to rar or zip
• Extract the zipped file and view class files using your favourite java decompiler

Database Inspection

The objective of this test is to look for sensitive information stored in application database. There are high chances of getting the user credentials in cleartext or sensitive information  like user financial details, SSN numbers, etc. Android stores all application-related files under /data/data folder. You can access those files from adb.exe using the below commands:

adb devices – List of connected devices will be shown
adb shell
su
cd /data/data/
ls

Look for your application folder

cd com.android.applicationname
ls

Application database files will be stored in databases folder. To view database file, we need to use sqllite3 utility which comes along with SDK toolkit. Here’s how you can view them:

sqllite3 /data/data/com.android.applicationname/databases/databasename
.table – List all database tables
select * from user_id;

I will cover more application specific attacks and tool list which are essential from pentest perspective in my next post.

Happy Reading!!!

Android Application Assessment – Part I

Recently, I was engaged in testing an android application. The customer generously provided me his new Samsung 750 Tablet with the application installed on it. The application does not interact with any remote server which meant all application data, database schema and files had to be stored locally. From the tutorials and my learning I was expected to find an android installation file (.apk file), install it on a google android emulator and start testing. Unfortunately, the first step itself didn’t meet my expectations.

I shall be releasing the series of android application testing; so this post is focused on setting up an environment, common challenges and confirming all is well before we proceed

Challenge 1:

Extract android application installable file (.apk file) from tablet. The application is running in tablet but not sure whether installation files are removed or hidden by the developer.

Solution:

After searching and testing few apps/tricks found by Google results, I finally decided to go with Astro File Manager application. The application is less complicated and fulfils my expectation. Below are the steps to get the .apk file:

1. Download and install Astro File Manager on your android tablet or phone
2. Locate and open Astro File Manager
3. Browse to Application Backup menu
4. Locate your application from Installed Apps list and select the app (extreme right)
5. Hit “Backup” button
6. Check and confirm your application backup in Backup Apps list

Now, we have the backup of our application. Next steps:

1. Exit Astro File Manager application
2. Browse to Home Screen and go to My Files folder
3. Look for backups folder and you will find your .apk file there

Once you have your application .apk file, there are multiple ways to get it onto your PC. I installed a Dropbox application on tablet and then downloaded it onto my PC. Other alternatives are as below:

• Attach file to your inbox (< 5MB)
• Install Samsung windows driver from here and transfer it via USB.

Next step is to install the application on Android emulator. You can download it from here and installation steps are listed here. Once setup is done, you will have similar running emulator as below:

Installing Assessment Application on Emulator 

Post successful SDK toolkit installation; add below strings to your PATH environmental variables (Right click My Computer-->Properties-->Advanced-->Environment Variables):

C:\Program Files\Android\android-sdk\tools;C:\Program Files\Android\android-sdk\platform-tools
 

We are now ready to install application on android emulator from any location (of course a valid one). The utility to interact with emulator is adb.exe and it can be found under C:\Program Files\Android\android-sdk\platform-tools. Steps are as below:

Open AVD Manager from All Programs and click on Start to run Emulator
Open command prompt and browse till path where you have saved your application apk file
Issue command: adb devices to ensure your emulator is working properly
To install app: adb install app_name.apk
Here's a screenshot of above steps:

Happy Reading!!!

Facebook Like Widget – Spammers Tool???

Now a days, I get very curious to look at view-source of website where Facebook’s Like button is embedded. But why should I do this? Isn’t facebook Like button trusted? This is right.. Huh!!! The answer is NO. If there is a mismatch in the domain (you are visiting) and facebook’s Like button then there is surely a problem and it is a spam page.

How I concluded this?

Facebook’s Like widget can be integrated to any website and is free to use. More surprisingly it does not validate the host website.

How can it be used by Spammers?

Spammers use Like widget to make their fake page look-like very real and therefore inducing visitors to click on the Like button. The Like button can trigger any event of attacker’s choice and will run inside the user’s browser or may redirect the user to attacker’s website or may infect user’s system.

Root Cause Analysis

Facebook does not validate the host domain which is causing the issue. Validating the host domain with facebook (using API or XHR or hidden variable) may solve the problem.

Happy Reading!!!

Data Validation Framework – HDIV at a Glance

Security study has again proved that most of the web application security attacks (approx 85% as per Gartner and NIST) are generated from application layer. It has always been a challenge for developers to validate parameters in URL, HTTP header, HTP request and non-editable fields on the page. We also see many irregularities in fixing the parameter manipulation vulnerability i.e. when an attacker accessing data of other users/on behalf of other users. The traditional solution suggested and implemented is to map the user role with some hidden variable and then validating it on server side. But this solution doesn’t work well for everyone.

A JAVA Web Application Security Framework i.e. HDIV (HTTP Data Integrity Validator) is out for JAVA applications using Struts 1.x, Struts 2.x, Spring MVC and JSTL. The framework guarantees integrity, confidentiality and protection against CSRF attack. The framework divides HTTP request in two parts:

·         Editable Data – Includes textbox and textarea

·         Non-editable Data – Includes links, hidden fields, combo values, radio, buttons, destiny pages, cookies, etc.)

Working

HDIV appends a State parameter (_HDIV_State) with random token value for every request sent to the client. This token value is calculated based on chosen working strategy i.e. Hash/Cipher/Memory. The token validates all non-editable page contents on server side. A HDIV HTTP request looks like:

http://www.host.com/page.do?param1=0&_HDIV_STATE_=46bdsd687ajldfg9100

More importantly, HDIV can also hide/mask the original value of parameter. Let’s say we have an application in which admin user role is recognized by a parameter role=1001; now after implementing HDIV the parameter value will look like role=1 (any random value). This technique prevents attacker to guess original value of the parameter.

HDIV also allows using custom validations for input fields on a page which are configured in XML format. Move over, HDIV installation does not affect your application configuration.

Performance

Performance is the most important criteria when we chose to implement something extra to our application/server. As expected, HDIV also eats some extra megabytes of your server memory space but if you have a decent configuration server the response time is unnoticeable. HDIV performance depends on chosen working strategy.

Hope this helps your developer to fix many of your web application security problems.

Happy Reading!!!

Pentesting Thick Client Apps

Pentesting thick client applications is not a new concept instead the techniques adopted are new and interesting. I’m a bit lazy on explaining what thick client apps are, please refer here for more info. GTalk, Pidgin, Skype, MSN are few examples of thick client applications. These days many financial institutions are adapting the technology for internal transaction purposes.

The Challenges:

• Typical thick client apps do not communicate over HTTP/HTTPS (some of them do); so you cannot intercept traffic with regular web proxy tools
• Unknown modification to registry/system files
• Unknown technical details of architecture
• Manipulating client-server communication over the wire
• Encryption techniques adopted by client software
• Will used by only trusted users

 Above list just mentions a few challenges that we regularly face while pentesting thick clients.

Way To Go:

Understanding Architecture

  

Thick client applications are generally 2-tier applications, meaning, the request is constructed at user’s end (client) and sent to the server for processing. There is no web server or middle ware technology sitting in middle; it directly communicates to the database. This can be identified by observing the time lapse between request and response or analyzing the communication traffic on wireshark.

Architecture can also be hybrid i.e. listening on both HTTP/S and any unknown port. In this case we may have to use the combination of tools to intercept and modify the communication. 

Intercepting/Manipulating Client-Server Communication

The two most popular open source tools are EchoMirage and ITR. The tool I prefer the most is Echomirage; because of its simplicity. It directly hooks with your client executable and starts intercepting traffic on the go. There is also an option to hook your client exe with its associated process. Here’s how you can do the above steps:

After you do this successfully, all our traditional application security checks are applicable. If you are lucky, you may see SQL queries passing through our Echomirage Interceptor.

Local Storage of Sensitive Information

Sensitive information can be clear-text passwords, server configuration, user personal detail, user financial detail, etc. Look for .ini, ,cfg, dat, .log files in application folder for application related sensitive information. Generally, you will find server configuration in .ini files.

File and Registry Modification Analysis/Reverse Engineering

Another two most popular tools are Filemon and Regmon from sysinternals. These both tools are now packaged into one as Process Monitor. These tools identify files accessed or registry modified when you double click your client executables. Here, you need to look for interesting files and investigate further; filename can hint which file you should investigate. It will help in application reverse engineering.

Regmon list all registry entries which are accessed when you double click your client executables. Use the registry search feature to find keywords, passwords, and sensitive information.

Happy Reading!!!

Malware Attack Analysis

Recently, we have seen a massive increase in malware attacks. Hackers find weak holes (vulnerability) in system or application, exploit them to gain access and ends up infecting them with malware. The attack is usually targeted for huge set of audience i.e. website legitimate users. Malware can be spread by various means, an email attachment, file download, javascript via page load, broken links, page redirects, etc.

In a recent Malware analysis activity, I noticed hacker adopting different approach to infect website. Hacker exploited weak ftp credential to gain web folder access and infected application supported files i.e. js, cs, html files instead of infecting main application pages. The malicious script executes on user’s browser, gives an unavoidable pop-up of Microsoft Essentials and then pop-up disappears after user clicks on “OK” button. This script also executed a function from within the page which silently transferred all valid sessions opened in same browser tabs to attacker’s website. Eventually, compromising user account by session hijacking. Think of less secured website which sends authentication credentials in cookie!!!

There were two interesting points in this attack:

• Attacker injected the malicious code in Base64 encoded format and referenced to decode function from within the file to make it browser understandable
• Attacker infected very few application supported files ignoring all application files to get past the malware detection

The attack was identified and notified by a legitimate user, who knew something about security, noticing that Microsoft Essential was not installed on his system.

The Steps: Root Cause Analysis

Analyzing malware requires effort, time, skill and minimal application knowledge. Below are few mandatory questions that must be asked before you conduct RCA for a website:

• How many entry points does your application have?
• Do you have system and application logs?
• Why do you suspect your website is infected?
• How do you manage your website?

After gathering these answers, you will find a direction into which you need to look for. Ask website owner for web application files, application logs, system logs and firewall logs, if exists. Next step is to adapt the approach for analysis:

• Identify and block hacker access on your server
• Backup old infected code
• Identify the activity/action of malware like installing backdoor, stealing session cookie, fake redirects, etc
• Replicate the malware attack at your end to verify the malware behavior
• Analyze every application file for malicious injected script. Code file size may give you a hint of which files are infected. In my case, every infected file code size was increased by 2 KB as compared to original file
• Remove malicious script from all infected files
• Scan your website folder with anti-virus and malware detection tool
• Audit your server with Autoruns tool - Sysinternals
• Make your cleaned application files go-live ensuring website is functioning perfectly as before. Look for every page load, image, buttons that must be in place
• Scan your website with McAfee SiteAdvisor to ensure no malware exists on the website
• Issue a best practice guideline

Hackers are always on the run with our own evolving technology.  Be Aware to Be Safe.