Saturday, August 31, 2013

Linux Distro for mobile forensics, malware analysis, and security testing (Santoku)

Blogging about Linux pentesting distros is one of the major things that we do here at the Concise Courses blog! Our interest lies within information security, and pretty much every distro we have reviewed falls within the category of either being used for penetration testing or for a particular aspect of IT security. Here are a few of our most popular Linux Distribution posts and other resources:
What was missing from our many reviews was a specific Mobile Phone Forensics Distro, and here is is: Santoku.
Santoku, made by mobile forensics experts viaForensics, has three purposes (or perhaps we could call them pillars), which are Mobile ForensicsMobile Forensics and Mobile Security.
Taking each of those in turn we notice that the Mobile Forensics focus of the distro has tools specifically designed to acquire and analyze mobile data, firmware flashing tools (that work on phones built by the major phone manufacturers) and a collection of free imaging tools for media cards. The developers have also bundled in free versions of some of the better and most widely used commercial forensics tools.
The next category that Santoku focuses on, is Mobile Malware, which frankly, is booming (for all the wrong reasons). A study by Juniper’s Networks Mobile Threat Center discovered that Mobile Malware grew a staggering 600% between 2012 and 2013, and the biggest rise has been aimed at Android. Pretty unbelievable stuff if you think about it, but also hardly surprising when you think about the undisputed rise in mobile and the decline in desktops. Quick side note, if mobile forensics and pentesting is your thing then we’d certainly recommend following news issued by Juniper’s Mobile Threat Center (MTC) team. Their sole purpose is to evaluate and investigate (24 hours) mobile vulnerabilities and malware threats.
Santoku hits Mobile Malware where it hurts by bundling many of the best known tools to assist with examining mobile malware and contains mobile device emulators. Included as well are decompilation and disassembly tools and access to malware databases.
The final tenet of Santoku is the concept of Mobile Security. The tools combined within this distro assess mobile apps, which again, is another huge growth threat out there. The same report researched by Junipers MTC outlined that nearly a quarter of a million apps are triggering SMS trojans and exploiting security vulnerabilities that in turn steal private data and force your phone to join a cyber botnet. Apparently the vast majority of these mobile app threats and malware are directed at Android. Santoku aids the battle against Android malware apps by giving their distro user an array of tools such as decompilation and disassembly tools and various scripts that have been written to detect common patterns in mobile applications that hide malware.
Why should you use Santoku?
When Linus Torvalds released Linux to the world, organizations, initially academic institutions, shaped the kernel to suit their needs. One branch of Linux is geared within the security space, i.e. Kali Linux, BackBox etc., and the same applies here, i.e. Santoku is a pure-play M‎obile Forensics Distro. Santoku, like every specialized Linux Distro out there has been created to save you time by curating all the tools you need to do your job whilst making sure that the drivers and updates all work efficiently. So, to answer the question, yes, you should absolutely try Santoku if you are interested in Mobile Security (Mobile penetration testing, auditing and forensics etc).
In Summary
As stated above, if mobile security is your thing then get yourself a copy here. Even if you are a student or just plain curious then you should immerse yourself into their forum. Seriously, viaForensics, the folks behind the distro, and a commercial organization (much like Offensive Security and Kali Linux) have done a really superb job in providing those new to this space with a range of helpful How-To tutorials and they also support an active forum. Since we are are on the subject, you should also take a look at CAINE as well (a distro which also address forensics).
Although the current Santoku distro is in an Alpha state it has solid foundations having been developed as a fork from the OWASP MobiSec Ubuntu distro.
Needless to say that this is a booming space. Mobile is under an increasing amount of sophisticated attacks and new threat vectors appear on a daily basis. If you can master Mobile Security skills then your employability will, we believe, go through the roof. Tell us what you think! Do you agree with us that mobile security skills will be in demand?

Tuesday, August 27, 2013

Remote Debugging on Android


Contents

Note: For information on the interaction protocol we use for our remote debugging, please see the Debugger Protocol documentation and chrome.debugger.

Remote debugging overview

The experience of your web content on mobile operates very differently than what users experience on the desktop. The Google Chrome DevTools allow you to inspect, debug, and analyze the on-device experience with the full suite of tools you're used to, meaning you can use the Chrome DevTools on your development machine to debug a page on your mobile device.
Debugging Chrome for Android using the Chrome Developer Tools
Debugging occurs over USB and as long as your mobile device is connected to your development machine, you can view and change HTML, scripts and styles until you get a bug-free page that behaves perfectly on all devices.
When debugging a web application served from your development machine, you can use reverse port forwarding to allow the mobile device to access a site from the development machine over USB. Reverse port forwarding requires Chrome 29 or later on the development machine, Chrome 28 or later on the mobile device.

Remote debugging with the ADB Chrome extension

To start debugging, you need:
  • An Android phone or tablet with Chrome for Android 28 or later installed from Google Play.
  • A USB cable to plug in your device. (Windows users will also need to install an appropriate USB device driver.)
  • Chrome 28 or later installed on your development machine.
  • The ADB Chrome extension installed on your development machine.

1. Install the ADB extension

The ADB Chrome extension simplifies the process of setting up remote debugging. The ADB extension includes the Android Debug Bridge (ADB), which lets you debug the device over USB from your development machine. The extension provides the following benefits:
  • Includes ADB so you don't have to install the full Android SDK.
  • Provides a UI for easily starting and stopping the ADB daemon, and viewing connected devices.

2. Enable USB debugging on your device

In order to debug over USB, you need to setup your Android device for development. Enable USB debugging on your device then system to detect your device as mentioned in the guide.
To enable USB debugging:
  • On most devices running Android 3.2 or older, you can find the option under Settings > Applications > Development.
  • On Android 4.0 and newer, it's in Settings > Developer options.
  • On Android 4.2 and newer, Developer options is hidden by default. To make it available, go to Settings > About phone and tap Build number seven times. Return to the previous screen to find Developer options.
USB debugging settings in Developer options
If you are developing on Windows, you need to install the appropriate USB driver for your device. See OEM USB Drivers on the Android Developers site.
For more information see Setting up a Device for Development on the Android Developers site.

3. Connect your device via USB

  1. Connect your mobile device to the development machine using a USB cable.
  2. On the mobile device, launch Chrome. Open Settings > Advanced > Developer Tools and check the Enable USB Web debugging option as shown here:
  3. Enable USB Web Debugging in Chrome for Android
When connecting your device to your development machine, you may see an alert on the device requesting permission for USB debugging from this computer.
USB debugging permission alert
To avoid seeing this alert each time you debug, check Always allow from this computer and click OK.

4. Start debugging with the ADB extension

When the ADB extension is installed, a gray Android menu icon appears beside the Chrome menu.
To start debugging:
  1. Click the Android icon, then click Start ADB.
    ADB extension menu
    Once ADB has started, the menu icon turns green and displays the number of currently connected devices, if any.
    ADB extension menu
  2. Click View Inspection Targets to open the about:inspect page that displays each connected device and its tabs.
  3. Find the mobile device tab you want to debug and Click the inspect link next to its URL.
If you don't see any connected devices:
  • Check that your device is connected to USB.
  • Ensure your device is listed as available by issuing the adb devices command. If not, check that you have USB debugging enabled on your device.
  • Ensure that USB debugging is enabled in the Chrome for Android settings.

5. Debug Your Application

Inspecting a remote page using the Chrome Developer Tools
For example, inspect an element in the page you have selected and the element highlights in Chrome mobile on your device in real time.
Element inspection on a remote device
Similarly, editing scripts or executing commands from the DevTools console affects the page being inspected on your device. You can also also use all of the other panels, such as Timeline and Profiles.

Notes

  • You may notice that the version of the DevTools you have access to during remote debugging differs to the version you have running on your development machine. This is because the tools are synchronized with the Chrome version on the Android device being used.
  • Because we're connected over USB, you can keep the device on a real cellular network, and view the network waterfall in the Network panel under actual network conditions
  • The hardware on mobile devices often runs your content much slower, so use the Timeline to analyze how to optimize rendering and CPU for the best effect.
  • If you're running a web server on your development machine, and network restrictions prevent your mobile device from accessing the server, see reverse port forwarding
  • .

Reverse Port Forwarding (Experimental)

Commonly you have a web server running on your local development machine, and you want to connect to that site from your device. If the mobile device and the development machine are on the same network, this is straightforward. But this may be difficult in some cases, like on a restricted corporate network.
A new feature in Chrome for Android called "reverse port forwarding" makes this simple to do. It works by creating a listening TCP port on your mobile device that maps to a particular TCP port on your development machine. The traffic through the forwarded port travels over USB, so it doesn't depend on the mobile device's network configuration.
To use this feature you need:
  • Chrome 29 or later installed on your development system
  • Android Debug Bridge (Chrome ADB extension or full Android SDK) installed on your development system
  • Chrome for Android 28 or later installed on your device
This procedure assumes that you already have remote debugging configured as described in Remote debugging with the ADB Chrome extension or

1. Connect your mobile device

  1. Connect your device to your development machine over USB.
  2. Stop all instances of Chrome currently running on the mobile device.
  3. Open Chrome for Android.
  4. Go to Settings > Developer Tools, and turn on Enable USB Web Debugging.
  5. Start ADB on your development machine:
    • If you're using the ADB extension, click the ADB icon and click Start ADB. You should see the icon turn green and display a number indicating the number of devices connected.
    • If you're not using the extension, open a terminal and run adb devices. You should see the IDs of your connected device(s) listed.

2. Enable reverse port forwarding

Perform the following steps on Chrome on your development machine:
  1. Open about:flags, turn on Enable Developer Tools experiments and restart Chrome.
    about:flags page
  2. Open about:inspect. You should see your mobile device and a list of its open tabs.
  3. Click Inspect next to any of the sites listed.
  4. In the DevTools window that opens, open the Settings panel.
  5. Under Experiments, turn on Enable reverse port forwarding.
    Experiments panel in Developer Tools settings
  6. Close the DevTools window and return to about:inspect.

3. Add a port forwarding rule

  1. Click the Inspect link again to open DevTools, and open Settings again. You should see a new Port forwarding tab.
  2. Click Port Forwarding.
  3. In the Device port field, enter the port number the Android should device listen on (defaults to 8080).
    Port Forwarding panel in Developer Tools settings
  4. In the Target field, append the port number where your web application is running on localhost.

4. Profit

In Chrome for Android, open localhost:<device-port-number>, where <device-port-number> is the value you entered in the Device port field (default is 8080). You should see the content being served by your development machine.

Tuesday, August 20, 2013

Top Ten Smartphone Risks

The top ten information security risks for smartphone users.
Market analysts predict that smartphones will outnumber PCs by 2013, and that they will be the most common device for accessing the internet. In 2010 we published a report about smartphone security, giving an overview of risks, opportunities for smartphone users, and making recommendations.
This is the list of the top ten smartphone security risks from our report. The (level of) risk was determined in consultation with the expert group. The level is intended to convey the relative risk in relation to others, rather than an absolute probability or impact level.
No.TitleRiskDescription
1 HighThe smartphone is stolen or lost and its memory or removable media are unprotected, allowing an attacker access to the data stored on it.
2 HighThe smartphone user unintentionally discloses data on the smartphone.
3Attacks on decommissionedsmartphonesHighThe smartphone is decommissioned improperly allowing an attacker access to the data on the device.
4Phishing attacksMediumAn attacker collects user credentials (such as passwords and credit card numbers) by means of fake apps or (SMS, email) messages that seem genuine.
5Spyware attacksMediumThe smartphone has spyware installed, allowing an attacker to access or infer personal data. Spyware covers untargeted collection of personal information as opposed to targeted surveillance.
6Network Spoofing AttacksMediumAn attacker deploys a rogue network access point (WiFi or GSM) and users connect to it. The attacker subsequently intercepts (or tampers with) the user communication to carry out further attacks such as phishing.
7Surveillance attacksMediumAn attacker keeps a specific user under surveillance through the target user’ssmartphone.
8Diallerware attacksMediumAn attacker steals money from the user by means of malware that makes hidden use of premium SMS services or numbers.
9Financial malware attacksMediumThe smartphone is infected with malware specifically designed for stealing credit card numbers, online banking credentials or subverting online banking or ecommerce transactions.
10Network congestionLowNetwork resource overload due to smartphone usage leading to network unavailability for the end-user.

Risk is defined as the product of the likelihood and the impact of a threat against the information assets of an organization or an individual. Threats exploit one or more vulnerabilities. The likelihood of a threat is determined by the number of underlying vulnerabilities, the relative ease with which they can be exploited and the attractiveness for an attacker.
We used the following list of possible affected assets throughout:
  • Personal data
  • Corporate intellectual property
  • Classified information
  • Financial assets
  • Device and service availability and functionality
  • Personal and political reputation

Monday, August 19, 2013

Tool to avoid Reverse Engineering......in ANDROID,....

ProGuard


The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are Licensing Your Applications.
ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode. Having ProGuard run is completely optional, but highly recommended.
This document describes how to enable and configure ProGuard as well as use the retrace tool to decode obfuscated stack traces.

Enabling ProGuard


When you create an Android project, a proguard.cfg file is automatically generated in the root directory of the project. This file defines how ProGuard optimizes and obfuscates your code, so it is very important that you understand how to customize it for your needs. The default configuration file only covers general cases, so you most likely have to edit it for your own needs. See the following section about Configuring ProGuard for information on customizing the ProGuard configuration file.
To enable ProGuard so that it runs as part of an Ant or Eclipse build, set the proguard.config property in the<project_root>/project.properties file. The path can be an absolute path or a path relative to the project's root.
If you left the proguard.cfg file in its default location (the project's root directory), you can specify its location like this:
proguard.config=proguard.cfg
You can also move the the file to anywhere you want, and specify the absolute path to it:
proguard.config=/path/to/proguard.cfg
When you build your application in release mode, either by running ant release or by using the Export Wizard in Eclipse, the build system automatically checks to see if the proguard.config property is set. If it is, ProGuard automatically processes the application's bytecode before packaging everything into an .apk file. Building in debug mode does not invoke ProGuard, because it makes debugging more cumbersome.
ProGuard outputs the following files after it runs:
dump.txt
Describes the internal structure of all the class files in the .apk file
mapping.txt
Lists the mapping between the original and obfuscated class, method, and field names. This file is important when you receive a bug report from a release build, because it translates the obfuscated stack trace back to the original class, method, and member names. See Decoding Obfuscated Stack Traces for more information.
seeds.txt
Lists the classes and members that are not obfuscated
usage.txt
Lists the code that was stripped from the .apk
These files are located in the following directories:
  • <project_root>/bin/proguard if you are using Ant.
  • <project_root>/proguard if you are using Eclipse.
Caution: Every time you run a build in release mode, these files are overwritten with the latest files generated by ProGuard. Save a copy of them each time you release your application in order to de-obfuscate bug reports from your release builds. For more information on why saving these files is important, see Debugging considerations for published applications.

Configuring ProGuard


For some situations, the default configurations in the proguard.cfg file will suffice. However, many situations are hard for ProGuard to analyze correctly and it might remove code that it thinks is not used, but your application actually needs. Some examples include:
  • a class that is referenced only in the AndroidManifest.xml file
  • a method called from JNI
  • dynamically referenced fields and methods
The default proguard.cfg file tries to cover general cases, but you might encounter exceptions such asClassNotFoundException, which happens when ProGuard strips away an entire class that your application calls.
You can fix errors when ProGuard strips away your code by adding a -keep line in the proguard.cfg file. For example:
-keep public class <MyClass>
There are many options and considerations when using the -keep option, so it is highly recommended that you read theProGuard Manual for more information about customizing your configuration file. The Overview of Keep options andExamples section are particularly helpful. The Troubleshooting section of the ProGuard Manual outlines other common problems you might encounter when your code gets stripped away.

Decoding Obfuscated Stack Traces


When your obfuscated code outputs a stack trace, the method names are obfuscated, which makes debugging hard, if not impossible. Fortunately, whenever ProGuard runs, it outputs a <project_root>/bin/proguard/mapping.txt file, which shows you the original class, method, and field names mapped to their obfuscated names.
The retrace.bat script on Windows or the retrace.sh script on Linux or Mac OS X can convert an obfuscated stack trace to a readable one. It is located in the <sdk_root>/tools/proguard/ directory. The syntax for executing theretrace tool is:
retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
For example:
retrace.bat -verbose mapping.txt obfuscated_trace.txt
If you do not specify a value for <stacktrace_file>, the retrace tool reads from standard input.

Debugging considerations for published applications

Save the mapping.txt file for every release that you publish to your users. By retaining a copy of the mapping.txt file for each release build, you ensure that you can debug a problem if a user encounters a bug and submits an obfuscated stack trace. A project's mapping.txt file is overwritten every time you do a release build, so you must be careful about saving the versions that you need.
For example, say you publish an application and continue developing new features of the application for a new version. You then do a release build using ProGuard soon after. The build overwrites the previous mapping.txt file. A user submits a bug report containing a stack trace from the application that is currently published. You no longer have a way of debugging the user's stack trace, because the mapping.txt file associated with the version on the user's device is gone. There are other situations where your mapping.txt file can be overwritten, so ensure that you save a copy for every release that you anticipate you have to debug.
How you save the mapping.txt file is your decision. For example, you can rename them to include a version or build number, or you can version control them along with your source code.

Wednesday, August 14, 2013

EASY WAY TO AUTOMATE TESTING

QTP Video & Text Tutorials

QTP Videos:

QTP DP (Descriptive Programming):

QTP & Excel:

QTP & XML:

QTP & PDF:


QTP & Browser:


QTP Scripts:


QTP & VBScript:

QTP & LoadRunner:

QTP Helps:

Others: