This document summarizes an expert presentation on hacking Android apps. It discusses the top 10 most common Android app vulnerabilities according to OWASP, including weak server-side controls, insecure data storage, lack of transport layer security, unintended data leakage, poor authorization and authentication, broken cryptography, client-side injections, making security decisions via untrusted inputs, improper session handling, and lack of binary protections. Specific attack examples for each vulnerability are provided.
Video at http://mrkn.co/andsec
With Android activations reaching a million devices per day, it is no surprise that security threats against our favorite mobile platform have been on the rise.
In this session, you will learn all about Android's security model, including application isolation (sandboxing) and provenance (signing), its permission system and enforcement, data protection features and encryption, as well as enterprise device administration.
Together, we will dig into Android's own internals to see how its security model is applied through the entire Android stack - from the Linux kernel, to the native layers, to the Application Framework services, and to the applications themselves.
Finally, you’ll learn about some of the weaknesses in the Android's model (including rooting, tap-jacking, malware, social-engineering) as well as what can be done to mitigate those threats, such as SE-Linux, memory protection, anti-malware, firewall, and developer best practices.
By the end of this session you will have a better understanding of what it takes to make Android a more trusted component of our personal and professional lives.
Video at http://mrkn.co/andsec
With Android activations reaching a million devices per day, it is no surprise that security threats against our favorite mobile platform have been on the rise.
In this session, you will learn all about Android's security model, including application isolation (sandboxing) and provenance (signing), its permission system and enforcement, data protection features and encryption, as well as enterprise device administration.
Together, we will dig into Android's own internals to see how its security model is applied through the entire Android stack - from the Linux kernel, to the native layers, to the Application Framework services, and to the applications themselves.
Finally, you’ll learn about some of the weaknesses in the Android's model (including rooting, tap-jacking, malware, social-engineering) as well as what can be done to mitigate those threats, such as SE-Linux, memory protection, anti-malware, firewall, and developer best practices.
By the end of this session you will have a better understanding of what it takes to make Android a more trusted component of our personal and professional lives.
When Encryption is Not Enough...Sumanth Naropanth, Chandra Prakash Gopalaiah ...Shakacon
Communication protocols are core to computing devices. They have evolved from the traditional Serial and LAN ports to complex (and lightweight) protocols of today, such as Bluetooth Low Energy (BLE), ANT+, ZigBee, etc.
Bluetooth Low Energy (BLE) is a popular protocol of choice for low energy, low performance computing systems. While versions of the BLE specification prior to 4.2 allowed simple key mechanisms to encrypt the communication between connected nodes, the more recent specification of BLE (4.2) provides better channel encryption via the Secure Simple Pairing (SSP) mode to protect data against snooping and man-in-the-middle style attacks. These protocols are used extensively by wearables such as smart watches and activity trackers.
Most wearables work in conjunction with a companion mobile application running on a platform that supports BLE with the aforementioned security mechanisms. We looked at Android and iOS for our study. We observe that there are fundamental assumptions (leading security limitations) in the adoption of the BLE security specifications on these two platforms. Relying on the standard BLE APIs for Android and iOS may be insufficient and may even project a false sense of security. It is critical to understand the degree of security that the BLE specifications can offer, and clearly separate that from the developers’ responsibility to design application level security in order to assure confidentiality and integrity of data being transmitted between a wearable device and its companion application.
Hacking Tizen : The OS of Everything - Nullcon Goa 2015Ajin Abraham
Tizen is an operating system which is built to run on various kinds of devices. Tizen OS defines following profiles based on the devices types supported.
Tizen IVI (in-vehicle infotainment)
Tizen Mobile
Tizen TV, and
Tizen Wearable
Samsung's first Tizen-based devices are set to be launched in India in Nov 2014. This paper presents the research outcome on the security analysis of Tizen OS. The paper begins with a quick introduction to Tizen architecture which explains the various components of Tizen OS. This will be followed by Tizen's security model, where Application Sandboxing and Resource Access Control powered by Smack will be explained.
The vulnerabilities in Tizen identified during the research and responsibly disclosed to Tizen community will be discussed. This includes issues like Tizen WebKit2 Address spoofing and content injection, Buffer Overflows, Issues in Memory Protection like ASLR and DEP, Injecting SSL Certificate into Trusted Zone, (Shellshock) CVE-2014-6271 etc. Applications in Tizen can be written in HTML5/JS/CSS or natively using C/C++. Overview of pentesting Tizen application will be presented along with some of the issues impacting the security of Tizen application. There will be comparisons made to Android application, and how these security issues differ with Tizen.
For eg: Security issues with inter application communication with custom URL schemes or intent broadcasting in Android as opposed to using MessagePort API in Tizen. Issues with Webview & JavaScript Bridge in Android compared to how the web to native communication is handled with Tizen etc.
Tizen is late to enter into the market as compared to Android or iOS, which gives it the benefit of learning from the mistakes impacting the security of mobile OS, and fixing these issues right in the Security Architecture. To conclude, a verdict would be provided by the speaker on how much Tizen has achieved with regard to making this mobile OS a secure one.
Android Application Penetration Testing - Mohammed AdamMohammed Adam
Android Penetration Testing is a process of testing and finding security issues in an android application. It involves decompiling, real-time analyzing and testing android application for security point of view. This Slides covers real-time testing of android applications and some security issues like insecure logging, leaking content providers, insecure data storage and access control issues.
Hacking Tizen: The OS of everything - WhitepaperAjin Abraham
Samsung’s first Tizen-based devices are set to launch in the middle of 2015. This paper presents the research outcome on the security analysis of Tizen OS and it’s underlying security architecture.
The paper begins with a quick introduction to Tizen architecture and explains the various components of Tizen OS. This will be followed by Tizen’s security model where application sandboxing and resource access control will be explained. Moving on, an overview of Tizen’s Content Security Framework which acts as an in-built malware detection API will be covered.
Various vulnerabilities in Tizen will be discussed including issues like Tizen WebKit2 address spoofing and content injection, Tizen WebKit CSP bypass and issues in Tizen’s memory protection (ASLR and DEP).
Applications in Tizen can be written in HTML5/JS/CSS or natively using C/C++. As a bonus, an overview of pentesting Tizen applications will also be presented along with some of the security implications. There will be comparisons made to traditional Android applications and how these security issues differ with Tizen.
Hacker Halted 2014 - Reverse Engineering the Android OSEC-Council
Introduction to the Android OS. the Android Developers Kit, Android Emulators, Rooting Android devices, de-compiling Android Apps. Dex2jar, Java JD_GUI and so on. During the presentation I will pull an App apart and show how to bypass a login screen.
What better way to express the Zombie Apocalypse then with mobile devices. They are ubiquitous. they are carried everywhere, they go everywhere. Having a decent understanding of the Operating System and it’s vulnerabilities can go a long way towards keeping your device protected.
This talk is going to give an overview of Android operating system and it´s apps ecosystem from the security point of view of a penetration tester.
So lets dive into topics like Pentest Environment Setup, Tools of the Trade, App Analysis and some security hints for Android developers.
Smart Bombs: Mobile Vulnerability and ExploitationTom Eston
Kevin Johnson, John Sawyer and Tom Eston have spent quite a bit of time evaluating mobile applications in their respective jobs. In this presentation they will provide the audience an understanding of how to evaluate mobile applications, examples of how things have been done wrong and an understanding of how you can perform this testing within your organization.
This talk will work with applications from the top three main platforms; iOS, Android and Blackberry. Kevin, Tom and John have used a variety of the top 25 applications for each of these platforms to provide real world examples of the problems applications face.
When Encryption is Not Enough...Sumanth Naropanth, Chandra Prakash Gopalaiah ...Shakacon
Communication protocols are core to computing devices. They have evolved from the traditional Serial and LAN ports to complex (and lightweight) protocols of today, such as Bluetooth Low Energy (BLE), ANT+, ZigBee, etc.
Bluetooth Low Energy (BLE) is a popular protocol of choice for low energy, low performance computing systems. While versions of the BLE specification prior to 4.2 allowed simple key mechanisms to encrypt the communication between connected nodes, the more recent specification of BLE (4.2) provides better channel encryption via the Secure Simple Pairing (SSP) mode to protect data against snooping and man-in-the-middle style attacks. These protocols are used extensively by wearables such as smart watches and activity trackers.
Most wearables work in conjunction with a companion mobile application running on a platform that supports BLE with the aforementioned security mechanisms. We looked at Android and iOS for our study. We observe that there are fundamental assumptions (leading security limitations) in the adoption of the BLE security specifications on these two platforms. Relying on the standard BLE APIs for Android and iOS may be insufficient and may even project a false sense of security. It is critical to understand the degree of security that the BLE specifications can offer, and clearly separate that from the developers’ responsibility to design application level security in order to assure confidentiality and integrity of data being transmitted between a wearable device and its companion application.
Hacking Tizen : The OS of Everything - Nullcon Goa 2015Ajin Abraham
Tizen is an operating system which is built to run on various kinds of devices. Tizen OS defines following profiles based on the devices types supported.
Tizen IVI (in-vehicle infotainment)
Tizen Mobile
Tizen TV, and
Tizen Wearable
Samsung's first Tizen-based devices are set to be launched in India in Nov 2014. This paper presents the research outcome on the security analysis of Tizen OS. The paper begins with a quick introduction to Tizen architecture which explains the various components of Tizen OS. This will be followed by Tizen's security model, where Application Sandboxing and Resource Access Control powered by Smack will be explained.
The vulnerabilities in Tizen identified during the research and responsibly disclosed to Tizen community will be discussed. This includes issues like Tizen WebKit2 Address spoofing and content injection, Buffer Overflows, Issues in Memory Protection like ASLR and DEP, Injecting SSL Certificate into Trusted Zone, (Shellshock) CVE-2014-6271 etc. Applications in Tizen can be written in HTML5/JS/CSS or natively using C/C++. Overview of pentesting Tizen application will be presented along with some of the issues impacting the security of Tizen application. There will be comparisons made to Android application, and how these security issues differ with Tizen.
For eg: Security issues with inter application communication with custom URL schemes or intent broadcasting in Android as opposed to using MessagePort API in Tizen. Issues with Webview & JavaScript Bridge in Android compared to how the web to native communication is handled with Tizen etc.
Tizen is late to enter into the market as compared to Android or iOS, which gives it the benefit of learning from the mistakes impacting the security of mobile OS, and fixing these issues right in the Security Architecture. To conclude, a verdict would be provided by the speaker on how much Tizen has achieved with regard to making this mobile OS a secure one.
Android Application Penetration Testing - Mohammed AdamMohammed Adam
Android Penetration Testing is a process of testing and finding security issues in an android application. It involves decompiling, real-time analyzing and testing android application for security point of view. This Slides covers real-time testing of android applications and some security issues like insecure logging, leaking content providers, insecure data storage and access control issues.
Hacking Tizen: The OS of everything - WhitepaperAjin Abraham
Samsung’s first Tizen-based devices are set to launch in the middle of 2015. This paper presents the research outcome on the security analysis of Tizen OS and it’s underlying security architecture.
The paper begins with a quick introduction to Tizen architecture and explains the various components of Tizen OS. This will be followed by Tizen’s security model where application sandboxing and resource access control will be explained. Moving on, an overview of Tizen’s Content Security Framework which acts as an in-built malware detection API will be covered.
Various vulnerabilities in Tizen will be discussed including issues like Tizen WebKit2 address spoofing and content injection, Tizen WebKit CSP bypass and issues in Tizen’s memory protection (ASLR and DEP).
Applications in Tizen can be written in HTML5/JS/CSS or natively using C/C++. As a bonus, an overview of pentesting Tizen applications will also be presented along with some of the security implications. There will be comparisons made to traditional Android applications and how these security issues differ with Tizen.
Hacker Halted 2014 - Reverse Engineering the Android OSEC-Council
Introduction to the Android OS. the Android Developers Kit, Android Emulators, Rooting Android devices, de-compiling Android Apps. Dex2jar, Java JD_GUI and so on. During the presentation I will pull an App apart and show how to bypass a login screen.
What better way to express the Zombie Apocalypse then with mobile devices. They are ubiquitous. they are carried everywhere, they go everywhere. Having a decent understanding of the Operating System and it’s vulnerabilities can go a long way towards keeping your device protected.
This talk is going to give an overview of Android operating system and it´s apps ecosystem from the security point of view of a penetration tester.
So lets dive into topics like Pentest Environment Setup, Tools of the Trade, App Analysis and some security hints for Android developers.
Smart Bombs: Mobile Vulnerability and ExploitationTom Eston
Kevin Johnson, John Sawyer and Tom Eston have spent quite a bit of time evaluating mobile applications in their respective jobs. In this presentation they will provide the audience an understanding of how to evaluate mobile applications, examples of how things have been done wrong and an understanding of how you can perform this testing within your organization.
This talk will work with applications from the top three main platforms; iOS, Android and Blackberry. Kevin, Tom and John have used a variety of the top 25 applications for each of these platforms to provide real world examples of the problems applications face.
Presentation I gave at ISSA DC on June 21, 2011. It introduces the OWASP Mobile Security Project, and covers at a high level: Overview of the Android platform, Mobile Top 10 Risks, Threat Modeling for Android.
The OWASP Mobile Top 10 is a nice start for any developer or a security professional, but the road is still ahead and there is so much to do to destroy most of the possible doors that hackers can use to find out about app’s vulnerabilities. We look forward to the OWASP to continue their work, but let’s not stay on the sidelines!
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
The Metaverse and AI: how can decision-makers harness the Metaverse for their...Jen Stirrup
The Metaverse is popularized in science fiction, and now it is becoming closer to being a part of our daily lives through the use of social media and shopping companies. How can businesses survive in a world where Artificial Intelligence is becoming the present as well as the future of technology, and how does the Metaverse fit into business strategy when futurist ideas are developing into reality at accelerated rates? How do we do this when our data isn't up to scratch? How can we move towards success with our data so we are set up for the Metaverse when it arrives?
How can you help your company evolve, adapt, and succeed using Artificial Intelligence and the Metaverse to stay ahead of the competition? What are the potential issues, complications, and benefits that these technologies could bring to us and our organizations? In this session, Jen Stirrup will explain how to start thinking about these technologies as an organisation.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
2. Agenda
Introduction to android application security model
Mobile app security – why should we care?
Top 10 of the most common android app
vulnerabilities
DEMOS !
3. About me
Application security expert
Founder & CEO of AppSec Labs
Book author - Managed Code Rootkits
Speaker - BlackHat, Defcon, RSA, OWASP, etc.
Trainer - Secure Coding / Hacking
4. Android Security Model
Well established OS, based on Linux
Sandboxed VM runtime (“Dalvik”) similar to Java’s JVM
The OS creates unique user for each app
Each app runs in a sandbox using its UID
Security is enforced at the OS and the App level
Each app is signed
Applications are totally isolated by default
So where’s the problem ???
5. Top 10 – most common
vulnerabilities (OWASP)
1. Weak Server Side Controls
2. Insecure Data Storage
3. Insufficient Transport Layer Protection
4. Unintended Data Leakage
5. Poor Authorization and Authentication
6. Broken Cryptography
7. Client Side Injection
8. Security Decisions Via Untrusted Inputs
9. Improper Session Handling
10. Lack of Binary Protections
6. Things an attacker will probably do
Reverse engineering the APK – peek into code, manifest file,
etc
Grab all app files stored in /data/data/
Debug the running app & Setting breakpoints
Hook important runtime calls
Monitor & manipulate network traffic (sniffing, proxying)
Monitor process activity
Observing file access
Analyze memory dumps (MAT, hprof dumps)
8. Weak Server Side Controls
Using the android mobile app to attack the server
business logic
Not a risk specific to the mobile platform
Common server side vulnerabilities such as SQL
injection, XSS, insecure authentication, etc.
Often by redirecting the phone’s request to a proxy
and manipulate with it
11. Insecure Data Storage
Many of the most publicized mobile application security incidents have
been caused by insecure or unnecessary client-side data storage.
Sometimes app developers assume the app data cannot be accessed by
an attacker
Sensitive information – usernames, passwords, Encryption keys,
Credit cards, session identifiers, tokens, etc.
Private information - Phone numbers, Addresses, Emails, locations
Interesting places that might contain sensitive data
SQLite databases
Log Files
XML Data Stores or Manifest Files
Binary data stores
SD Card
Cloud
12. Insecure File Permissions
In general, app files are sandboxed
Writing files with poor permissions
Files on /data/data/APP/ with “everyone read”
Files stored on SDcard (no permissions !!)
Allows AppA to steal files from AppB
Example – Skype bad permissions - steal contacts !
14. Insufficient Transport Layer
Security (no HTTPS)
“10% of apps fail doing SSL cert validation” - CERT
HTTPS (TLS or SSL), are cryptographic protocols that
provide communication security over the Internet:
Encrypting the transport layer
Authentication the server side
Any request sent without HTTPS is vulnerable to..
Information disclosure
Data tampering
Server spoofing and phishing
15. Another common Mistakes – no
cert validation
• usage of out of date/self signed SSL certificates
TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {};
}
public void checkClientTrusted(X509Certificate[] chain, String authType)
throws CertificateException { }
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException { }
}};
17. Unintended Data Leakage
Unintended data leakage occurs when
a developer accidentally places sensitive data in a location on the
mobile device that can be accessed by other apps / physical access
Another case is during sensitive data processing, a side-effect (that is
unknown to the developer) results in that information being placed
into an insecure location
Examples - places to look for
URL Caching (Both request and response)
Keyboard Press Caching
Copy/Paste buffer Caching
Application backgrounding
Logging
HTML5 data storage
Browser cookie objects
Analytics data sent to 3rd parties
18. Example - Insecure Log Exposure
Some apps store their own logs inside the local folder
Logs can contain info such as
Important events (app start, user login details, page load)
Exceptions
Sensitive variables (encryption keys, serial numbers)
Sensitive information (credit cards, passwords)
Often such files are stored without any protection at
the file system
Sometimes such files don’t even have any file
permission protection – any app can steal such info
19. Common Pitfall - Leaking
Information to Runtime Logs
Private information is often written to logs
Location, Phone identifiers ,Passwords, CC, URL, etc
21. Poor or missing authentication
Attacker van to anonymously execute
functionality
Can also allow to impersonate other
users
Sometimes weak passwords can lead to
broken authentication
Strong passwords are hard to enter on a
mobile device
Short passwords (4-digit PINs) are often
used
22. Poor Authorization and
Authentication
Example - Device authentication based on IMEI,
IMSI, UUID is not sufficient
Hardware identifiers persist across data wipes and factory resets
Don’t use device identifier as session token
Another example - When security is enforced at the
client side
The UI shows the user only what he can do. What he cannot is
disabled or just not visible
Attacker can bypass this quite easily
25. Broken cryptography
(“Encraption”)
Usage of a broken or risky cryptographic algorithm may result
in the exposure of sensitive information.
Configuration files or databases belonging to the app may
contain some encrypted data
Many times the app does bad encryption
Hard-coded key is stored in the source code
Same key for all users
Key can be stolen by other apps due to bad permissions
Key is stored right next the encrypted data
Custom, easily defeated crypto implementations (“encraption”)
Encrypting some data while storing the encryption key at the
client side does not help that much
26. Spot the bug
what’s wrong with this code?
Spot 3 different bugs related to encryption!!!!
Hard
coded
key
Bad
algorithm
Bad
crypto
mode
28. Client side injections
Results in the execution of malicious code
Malicious code is provided in the form of input that
is processed by the app
During processing, the input is interpreted as
executable code which is executed by the app,
running with its access permissions
Input can come from
Another app via intent/content provider
Shared file (ex: sdcard) manipulated by another app
Server side response
3rd party web site
29. Some examples
SQL Injection – embedding untrusted input into raw SQL statements
String query = "select * from table where columnName=‘“+external_input+”’”;
db.rawQuery( query, null );
Command Injection – embedding untrusted input into OS command execution
Process process = Runtime.getRuntime().exec("top -n “ + external_input );
Directory traversal – using a manipulated file name
basePath = “/sdcard/DCIM/”;
Filename = getInput();// “../../data/data/target.app.packagename/shared_prefs/preferences.xml”
openFileOutput(basePath+filename, Context.MODE_WORLD_READABLE);
XSS/Javascript injection into WebView – embedding input into HTML
String htmlCode = "<html><body><button type="button" onclick="myFunction()">+ external_input
+"</button></body></html>";
webView.loadDataWithBaseURL("null", htmlCode, "text/html", "UTF-8", null);
31. Insecure IPC
(Inter Process Communication)
Interoperability - A unique aspect of the Android system design is that any
application can start another application’s component
Apps are sandboxed, and cannot directly activate a component from another
application.
Therefore, to activate a component in another application, apps deliver an
asynchronous message to the system (“intent”)
The system then activates the target component
32. Exposed components
Components are not visible to other apps by default. Unless….
It has At least one <intent-filter> tag
It is declared as exported “exported=true”
<receiver android:name="com.appsec.hackmepal.BrReciever" android:exported="true"> </receiver>
It is a dynamically registered broadcast receiver
public
33. Insecure IPC
(Inter Process Communication)
If it is exposed, and you didn’t use android:permission than
you’re screwed.. ☺☺☺☺
Some examples
Unauthorized caller/intent spoofing
Permission re-delegation/Confused deputy
Phishing/CSRF
Intent sniffing
DoS
Component hijack/identity theft
36. Improper Session Handling
Mobile apps often use session tokens to maintain
state over stateless protocols like HTTP or SOAP
Client authenticates with the backend server
gets a session cookie in response
Cookie is added to all requests sent to the server
Server can enforce authentication and authorization
Common mistakes
Insecure Token Creation
Failure to Invalidate Sessions on the server side
Lack of Adequate Timeout Protection
Failure to Properly Rotate Cookies (timeout, changing user role, etc).
38. Lack of Binary Protections
Exposure of the application to a variety of risks
Results in a mobile app that can be analyzed,
reverse-engineered, and modified
It is extremely common for apps to be deployed
without binary protection.
39. The Problem of Reversing &
Decompilation
Major risks
Code exposure
Business logic (secret algorhithms, etc)
Security vulnerabilities in the code
Secrets in code (passwords, Encryption keys, etc)
Software piracy
Code modification
Add backdoors to original code
Patching - Change the application logic, add or remove
functionaliy, etc
40. Reverse engineering
Extract application from device (adb pull app.apk)
Reverse Engineering the apk
Extracting the APK content
apktool d someapp.apk –o outputDir
Disassembly
Smali/baksmali
Decompile the APK
dex2jar - Converting the classes.dex file to a jar
Decompiling the jar file and getting java source code
Analyzing the app
Locating sensitive files on device storage, Insecure file permissions, Locating
secrets in code/config files, Tracking insecure IPC, etc.
Patching the apk
Rebuilding the APK content
apktool b outputDir –o new.apk
Re-Signing modified apk’s
Signapk new.apk new_signed.apk
Put it back (adb push new_signed.apk)
41. Obfuscated Code and
anti-debugging
Although it’s a bit harder to read, class and member types
must stay the same..
Encrypted values must have the key somewhere near
Anti debugging code can be removed…
42. Summary
Android application level vulnerabilities put the service and
the end user at risk
Never take any security decisions at the Android side!
Remember this: “APK = open source code”. This way you’ll
avoid doing stupid things (security wise ☺)
Integrate security into your development lifecycle
Performing penetration testing on your Android apps