PenTest Magazine Mobile Pentesting

Share Embed Donate

Short Description

PenTest Magazine Mobile Pentesting...


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.

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 customer’s 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

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 Titania’s 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.

Mobile Pentesting

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

Table of Contents INTRODUCION


An Overview on Mobile Security by Senthilraj Gnanasekar

In today’s world smart phones, IPAD’s 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


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.



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


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 [email protected] Managing Editor: Magdalena Jaroszewska [email protected] 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 [email protected]


Production Director: Andrzej Kuca [email protected] DTP: Ireneusz Pogroszewski Art Director: Ireneusz Pogroszewski [email protected] Publisher: Hakin9 Media Sp. z o.o. SK 02-676 Warsaw, Poland ul. Postepu 17D Phone: 1 917 338 3631 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.


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?

[ IT’S 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 > 877.UAT.GEEK Please see 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 user’s 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.


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


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


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 Android’s 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 B’s files, -Ensures that user A does not exhaust user B’s memory, -Ensures that user A does not exhaust user B’s CPU resources, -Ensures that user A does not exhaust user B’s 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.


Mobile Pentesting

Figure 3. Mobile devices security threats In this article we’ll cover some tecniques for the application framework and application layers in order to give an oreview over the real Android Application Security surface.

Let’s start To start in Android p.t. appropriately, you have to install the SDK,NDK,and some other important tools like drozer (we’ll use it in our exemples).Drozer was developed at [email protected] (https://www. 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 – MWR’s advanced exploitation payload. It’s 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:// When you have installed the agent onto your device/or emulator and you’ve 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’


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


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

The list of the activities of some packages. We will now only consider vulnerabilities exposed through Android’s 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


So we want now to know which activities this app exported: dz> run -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

Now we want the list of content providers of this package: dz> run -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


Mobile Pentesting And now we’re enumerating the services of an app: dz> run -a com.vodafone.smhs Package: com.vodafone.smhs Permission: null

And now the broadcast receivers: dz> run -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 other’s 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 -v 1000

In this manner we’ll see our application randomly tapped and we’ll log all events searching for some useful strings in the logcat. A facebook vulnerability ( 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 ( and see the informations about recent intents:


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:

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

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.


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 ( Projects/OWASP_GoatDroid_Project)

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 doesn’t necessarily mean that it’s 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 ( blob/master/OWASP%20GoatDroid-%20FourGoats/src/org/owasp/goatdroid/fourgoats/broadcastreceivers/ 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


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.


[1] [2] [3] [4] [5] [6] [7] owasp/goatdroid/fourgoats/services/

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 i’m mobile developer in the north east of Italy but i’m looking for a company in order to work fulltime in security.


Reduce Time, Reduce Cost, Reduce Risk


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 [email protected] 402-261-8688 Communication Systems Solutions

6030 S. 58th St. STE C

Lincoln, NE 68516


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 today’s 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. Let’s 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.


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 (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 “I’m just sitting here reading a magazine...” gives the following output by using SHA256: 6e7ac84298c8fac86f3ca5c02b6d9f7a7472856ac92fa0d2a8ae97fcfb38c98a

If you input this line “I’m 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.


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 Euler’s 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, that’s why I would recommend the book “Rainbow of Primes” by Joao da Silva [3].

Real Uses of Cryptography Blackberry’s 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.”


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, it’s 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 Snowden’s 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 victim’s 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.


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: intelligence/2013/10/cryptolockerransomwarewhatyouneedtoknow/.

Microsoft’s 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.NET’s 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 (we’ll 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:


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 Microsoft’s Membership Providers. If you go to the Microsoft’s 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 User’s mobile PIN (currently not used) User’s e-mail address User’s 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 we’ll 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, let’s 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 Threema’s 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, Threema’s 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 bitcoin’s 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 user’s 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:

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 not’s 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.


View more...


Copyright ©2017 KUPDF Inc.