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.

Automating Nessus Capabilities

In the process of automating network scans for large networks there is a necessity to automate Nessus scans as well. The major advantage and most important point of this automation is that it allows you to do a Schedule scan in Home Feed version (which is only available in Pro feed) and the easiest part is your scans would run as if you are running from your Nessus web interface client.

Below Nessus automation perl script takes the first policy defined in your Nessus web browser client to run the scans. The script is based on my previous concept of Automating NMAP:

use Net::Nessus::XMLRPC;

$file = "ipadr.txt";

my $n = Net::Nessus::XMLRPC->new ('','admin','admin');  #Enter nessus username and password

die "Cannot login to: ".$n->nurl."\n" unless ($n->logged_in);

print "Logged in\n";

my $polid=$n->policy_get_first;

print "Using policy ID: $polid ";

my $polname=$n->policy_get_name($polid);

print "with name: $polname\n";

my $targets;

my $scanid=$n->scan_new_file($polid,"report",$targets,$file);

print "Performing scan on:\t$scanid\n";

while (not $n->scan_finished($scanid))

{

print "$scanid: ".$n->scan_status($scanid)."\n";

sleep 15;

}

print "$scanid: ".$n->scan_status($scanid)."\n";

my $reportcont=$n->report_file_download($scanid);

my $reportfile="report.html";

open (FILE,">$reportfile") or die "Cannot open file $reportfile: $!";

print FILE $reportcont;

close (FILE);

How to Run:

1.       Install perl and Net::Nessus::XMLRPC module

2.       Create a file named “ipadr.txt” and dump your entire IP list here; one entry on each line. For ex:

       

       10.0.0.1

       10.0.0.2

       10.0.0.3

3     Copy the above script in a textpad and save as nessus.pl

4.       Place nessus.pl and ipadr.txt in same folder. Ex: C:\Auto_Nessus

5.       Go to command prompt and browse till C:\Auto_Nessus.

6.       Fire command:

       perl nessus.pl

7.       The report will be saved in same folder as report.html. Alternatively, you can login to Nessus web client and view your report from there as well.

The next task is to make this script to work with the Windows Scheduler. Copy the below code in a textpad and save it as “Nessus_scan.bat”:

@ECHO OFF

REM cd to folder location

cd C:\Auto_Nessus

perl nessus.pl

Open your windows scheduler and schedule the batch file to execute at your desired time.

Happy Scanning!!!

Automating NMAP Capabilities

Many times I have encountered a problem with projects where large scanning of network host is required. In that case, you simply cannot expect your consultant to scan each host individually, analyze output and list down all vulnerable ports/services. Yes..we can even detect open ports with Nessus but still it has a host limitation per scan.

I thought to automate this process to get a list of open port for each host and dump the output in a single file. You just need to have perl installed on your machine to see how this works. Here’s a perl script to automate 

NMAP scan:

open FH, "ipadr.txt" or die $!;

my $line = <FH>;

my $s1="-sS -sV -P0"; #place your nmap scan command here

my $ip;

$file = ipadr.txt;

open (file) or die $!;

foreach $line (<file>)

{

chomp($line);

$ip=$line

$str="nmap $s1 $ip";

print "IP is:\t$str\n";

system($str);

}

close FH or die $!;

How to Use:

1.       Install perl from here

2.       Create a file named “ipadr.txt” and dump your entire IP list here; one entry on each line. For ex:

10.0.0.1

10.0.0.2

10.0.0.3

3.       Copy the above script in a textpad and save as nmap.pl

4.       Place nmap.pl and ipadr.txt in same folder. Ex: C:\Auto_NMAP

5.       Go to command prompt and browse till C:\Auto_NMAP.

6.       Fire command:

perl nmap.pl>output.txt

7.      Output.txt file will be created in the same folder and your entire nmap results will be dumped here.

Furthermore, you can use this script to run any NMAP command and get the output dumped in a single file. For running other commands you just need to edit below line:

my $s1="-sS -sV -P0";

Happy Scanning!!!