OWASP MobileTop 10explained withTestingTechniques                                                        Sayasmito Ghosh  ...
1.Insecure   What is the      •   Sensitive data left unprotectedData         Issue            •   Applies to locally stor...
2.Weak     What is the     •   Applies to the backend services.Server     Issue           •    Not mobile specifically, bu...
3.Insufficient   What is the     •   Complete lack of encryption for transmitted dataTransport        Issue           •   ...
4.Client What is the         •   Malicious inputs from client sideSide      IssueInjection Impact             •   Device C...
5.Poor           What is the     •   Weak User Authorization and AuthenticationAuthorization    Issue           •   Weak A...
6.Improper   What is the       •   Mobile app sessions are generally MUCH longer because ofSession      Issue             ...
7.Security   What is the      •   This threat can leverage to bypass permissions and security modelsDecisions    Issue    ...
8.Side    What is the      •   Mix of not disabling platform features and programmatic flawsChannel   IssueData      Impac...
9.Broken       What is the      •   Attacker gets hold of decryption mechanismCryptography   Issue            •   Sensitiv...
10.Sensitive   What is the       •   Sensitive information if obtainable, Applications can be reverseInformation    Issue ...
Upcoming SlideShare
Loading in …5
×

Mobile top 10 with testing techniques

1,021 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,021
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mobile top 10 with testing techniques

  1. 1. OWASP MobileTop 10explained withTestingTechniques Sayasmito Ghosh 1 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  2. 2. 1.Insecure What is the • Sensitive data left unprotectedData Issue • Applies to locally stored data + cloud syncedStorage Impact • Confidentiality of data lost • Credentials disclosed • Privacy Violations • Non-compliance Root • Not encrypting data Causes • Caching data not intended for long-term storage • Weak or global permissions Not leveraging platform best-practices Testing • Check what algorithms are used for encrypting the data are Technique standard algorithm for encryption • Looking into the database tables in the device (SQLite for Android Phone). -Check if the data is stored in clear text -Check if encrypted using weak mechanism • Identify the cached files • Look into files and search for sensitive information (like credit card numbers, user credentials) Prevention • Store ONLY what is absolutely required. It is unsafe to store techniques banking and payment system PIN numbers, credit card numbers, or online service passwords • Never use public storage areas (i.e., Storing sensitive data without encryption on removable media such as a micro SD card is especially risky) • Leverage secure containers and platform provided file encryption APIs • Do not grant files world readable or world writeable permissions • Identify and protect sensitive data on the mobile device • Handle password credentials securely on the device References • http://stackoverflow.com/questions/2149438/tool-to-see- android-database-tables-and-data • www.youtube.com/watch?v=9h8kzHTp6fA • androidreversing.blogspot.com/ Tools • Baksmali(decompile Android Applications) • Otx, an advanced disassembler based on tool • Class_dump_z, an updated version of the old class-dump for the iPhoneOS, to extract Objective-C class interfaces • Hex-Rays, the most advanced decompiler ever, also supports ARM binaries (based on Datarescue’s IDA Pro) • SQLite database browser 2 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  3. 3. 2.Weak What is the • Applies to the backend services.Server Issue • Not mobile specifically, but essential to get right for any application,Side regardless of the target endpoint.Controls Impact • Confidentiality of data lost • Integrity of Data not Trusted Root • For many reasons, mobile apps are usually not talking with Causes www. but rather with a different server (sometimes known as mobile.) • These servers are configured differently and we are usually somewhat under the assumption that the attacker wont be able to find/access them. • The result is web servers which are poorly configured (e.g. default files, loose SSL settings and etc.) Testing • Identify the server from where the mobile application is being Technique served. • Browse for default files of web servers, Old or backup files, unreferenced files to check if accessible • Check the servers certificate • Check the version of SSL supported by the server. Report if server supports SSLv2 Prevention • Understand the additional risks mobile apps introduce into techniques existing architectures • Leverage the wealth of knowledge that is already out there OWASP Web Top 10, Cloud Top 10, Web Services Top 10,Cheat sheets, development guides, ESAPI • Keep the backend APIs (services) and the platform (server) secure References • https://www.owasp.org/index.php/Testing_for_SSL- TLS_%28OWASP-CM-001%29 Tools • thcsslcheck.exe 3 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  4. 4. 3.Insufficient What is the • Complete lack of encryption for transmitted dataTransport Issue • Weakly encrypted data in transitLayer Impact • Confidentiality of data lostProtection • Man-in-the-Middle Attacks • Tampering with Data in Transit Root • Sometimes sensitive data is not encrypted in transmission Causes and it may be eavesdropped by attackers. • Mobile devices are especially susceptible because they use wireless communications exclusively and often public Wi- Fi, which is known to be insecure. • Downgrade attacks if it allows degrading HTTPS to HTTP. • Failing on invalid certificates. This would enable that a man-in-the-middle attack. • Ignoring certificate validation errors and falling back to plain text after failures • Strong encryption, but ignoring security warnings Testing • Check the protocol used by the application Technique Prevention • Ensure that all sensitive data leaving the device is techniques encrypted • This includes data over carrier networks, Wi-Fi , and even NFC • When security exceptions are thrown, analyze them • Ensure sensitive data is protected in transit References • http://it.toolbox.com/wiki/index.php/Man-in-the- Middle_Attack • openmaniak.com/wireshark.php • sites.google.com/site/clickdeathsquad/Home/cds-ssh- mitmdowngrade Tools • Wire shark • Burp 4 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  5. 5. 4.Client What is the • Malicious inputs from client sideSide IssueInjection Impact • Device Compromise • Toll Fraud • Privilege Escalation Root • Apps using browser libraries Causes - Pure web apps - Hybrid web/native apps • XSS and HTML Injection • SQL Injection • Abusing phone dialer + SMS • Abusing in-app payments Testing • Inject SQL injection and XSS tests in the application according to Technique the cheat sheets • Check if the client side validation is preventing injection of special characters. In such a case, use proxy tools Prevention • Sanitize or escape untrusted data before rendering or executing it techniques • Use prepared statements for database calls. Concatenation is always bad • Minimize the sensitive native capabilities tied to hybrid web functionality • Pay particular attention to validating all data received from and sent to non-trusted third party apps before processing • Carefully check any runtime interpretation of code for errors References • http://intrepidusgroup.com/insight/2010/04/webos-examples- of-sms-delivered-injection-flaws/ • http://info.veracode.com/xss-cheat-sheet.html • http://info.veracode.com/sql-injection-cheat-sheet.html • http://www.securestate.com/Services/Profiling/Pages/Client- Side-Attack-and-Penetration.aspx Tools • SQL cheat sheet • XSS cheat sheet • BURP 5 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  6. 6. 5.Poor What is the • Weak User Authorization and AuthenticationAuthorization Issue • Weak Authenticatorsand Impact • Privilege EscalationAuthentication • Unauthorized Access Root • Partly mobile, partly architectural flaw Causes • Some apps rely solely on immutable, potentially compromised values (IMEI, IMSI, UUID) • Hardware identifiers persist across data wipes and factory resets • Adding contextual information is useful, but not full proof Testing • Try privilege escalation techniques, like changing the Technique values going from the client to server via proxy tool. • Try to access the pages where you don’t have the access by parameter manipulation in url or in request trapped in proxy or force querying. • Check if the requests are containing the mobile number or IMEI number • Try to modify the mobile number or IMEI number in the requests via proxy tool and send it to server. Analyze the response Prevention • Contextual info can enhance things, but only as part of a techniques multi-factor implementation • Never use device ID or subscriber ID as sole authenticator • Implement user authentication/authorization correctly • Authenticate all API calls to paid resources References • http://blog.dasient.com/2011/07/hashing-imei- numbers-does-not-protect.html Tools • BURP 6 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  7. 7. 6.Improper What is the • Mobile app sessions are generally MUCH longer because ofSession Issue convenience and usabilityHandling • Often due to long sessions the attackers exploit the scenario Impact • Privilege Escalation • Unauthorized Access • Circumvent Licensing and Payments Root • Exploitation of sessions via Causes - HTTP cookies - OAuth tokens - SSO authentication services • Using a device identifier as a session token Testing • Via the proxy tool check the session ID’s : Technique - length - randomness -session id changing or not before and after login. • Check the session properties: -the secure bit is set or not -HttpOnly is set or not -path is set or not. • Check if the cookies are persistent -check for the expires attribute • Try change the session ids via proxy tool to check: -the server is keeping the track the active sessions or not. -managing the sessions at all or not. • If found that after changing the session the server is still responding properly then session fixation is possible. Prevention • Don’t be afraid to make users re-authenticate every so often techniques • Ensure that tokens can be revoked quickly in the event of a lost/stolen device • Utilize high entropy, tested token generation resources • Use non-persistent identifiers Implement user session management correctly References • Expires Attribute - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded, the browser will delete the cookie. Alternatively, if this attribute is not set, then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends. • http://www.allaboutcookies.org/cookies/persistent- cookies-used-for.html • www.acros.si/papers/session_fixation.pdf • https://www.owasp.org/index.php/Session_fixation • http://xs-sniper.com/blog/2008/09/09/secure-cookies/ Tools • BURP 7 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  8. 8. 7.Security What is the • This threat can leverage to bypass permissions and security modelsDecisions Issue • This flaw occurs if a mobile has any malicious application installed orVia when a malicious application finds another application running inUntrusted which client side injection is possibleInputs Impact • Consuming Paid Resources • Data Exfiltration • Privilege Escalation Root • Depending on platform Causes - iOS- Abusing URL Schemes - Android- Abusing Intents • Malicious apps • Client side injection Testing • Check the permissions of the application(the lesser the Technique better) • Check whether the application is asking for authentication or not while performing any critical operation. • Where permission checks cannot be performed, Check if the application ensures mandatory additional steps to launch sensitive actions. Prevention • Check caller’s permissions at input boundaries techniques • Prompt the user for additional authorization before allowing • Where permission checks cannot be performed, ensure additional steps required to launch sensitive actions • Run interpreters at minimal privilege levels References • http://cwe.mitre.org/data/definitions/807.html • http://cwe.mitre.org/top25/ • http://stackoverflow.com/questions/2149438/tool-to-see- android-database-tables-and-data • www.youtube.com/watch?v=9h8kzHTp6fA • androidreversing.blogspot.com/ Tools • Baksmali(decompile Android Applications) • Otx, an advanced disassembler based on tool • Class_dump_z, an updated version of the old class-dump for the iPhoneOS, to extract Objective-C class interfaces • Hex-Rays, the most advanced decompiler ever, also supports ARM binaries (based on Datarescue’s IDA Pro) 8 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  9. 9. 8.Side What is the • Mix of not disabling platform features and programmatic flawsChannel IssueData Impact • Data Retained IndefinitelyLeakage • Privacy Violations Root • Sensitive data ends up in unintended places like Causes - Web caches - Keystroke logging - Screenshots (i.e., iOS back grounding) - Logs (system, crash) - Temp directories • Inability to Understand and handle what third party libraries in the apps are doing with user data (i.e., ad networks, analytics) Testing • Check the logs Technique -check log of both systems logs -crash logs Credentials or other sensitive data should not be logged by application. • Check Web cache. Caching should be disabled(No store/No cache) • Check Temp directories for sensitive information • Check for Key stroke logging • Check if the application is allowed to take screen shot. If allowed check whether the application is removing the sensitive data before taking the screen shot. • Check the files created by the application and check which files are getting modified while the application runs. • Review the third party libraries to check what type of data they are consuming. Prevention • Never log credentials, PII, or other sensitive data to system techniques logs(Check whether you are collecting PII, it may not always be obvious) • Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content • Debug your apps before releasing them to observe files created, written to, or modified in any way • Carefully review any third party libraries you introduce and the data they consume • Test your applications across as many platform versions as possible • Audit communication mechanisms to check for unintended leaks (e.g. image metadata) References • http://www.iphonehacks.com/jailbreak_iphone • http://www.addictivetips.com/mobile/how-to-root-your- android-phone-device/ • http://www.appleiphonereview.com/iphone-jailbreak/iphone- jailbreak/ Tools • A jail broken Iphone( if testing an application for iOS) • A rooted Android phone (if testing an application for Android) • UnlockJailbreakTool 9 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  10. 10. 9.Broken What is the • Attacker gets hold of decryption mechanismCryptography Issue • Sensitive information falls into wrong hands Impact • Confidentiality of data lost • Privilege Escalation • Circumvent Licensing and Payments Root • Broken implementations using strong crypto libraries Causes • Custom, easily defeated crypto implementations • Encoding ,Obfuscation , Serialization mistaken for Encryption Testing • Check the algorithms used by the device to encrypt the data Technique to be sent to the server. This can be done by decompiling the application. • Check for weak encryption algorithms like weak md5,ROT13,A5/1,SSLv2 Prevention • Storing the key with the encrypted data negates everything techniques • Leverage battle-tested crypto libraries vice writing your own • Utilize file encryption API’s • Leverage secure containers References • www.youtube.com/watch?v=9h8kzHTp6fA • androidreversing.blogspot.com/ • md5encryption.com/ • http://ali.vg/2011/05/enforcing-ssl-3-0-and-removing- weak-encryption-vulnerability-over-ssl/ • www.airdemon.net/gsmdecryption3.html Tools • Baksmali(Android app decompile) • MD5 decrypter • Otx, an advanced disassembler based on tool • Class_dump_z, an updated version of the old class-dump for the iPhoneOS, to extract Objective-C class interfaces • Hex-Rays, the most advanced decompiler ever, also supports ARM binaries (based on Datarescue’s IDA Pro) 10 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)
  11. 11. 10.Sensitive What is the • Sensitive information if obtainable, Applications can be reverseInformation Issue engineered with relative easeDisclosure Impact • Credentials disclosed • Intellectual Property Exposed Root • From commonly found “exploitables” like: Causes - API keys - Passwords - Sensitive business logic • Code obfuscation is not full proof Testing • Try to generate the error message on the application by: Technique -entering too much data in text fields -entering special characters in the input fields -requesting unauthorized data or non-existing page or data. • Check if error messages are disclosing -any system related information -any business logic as an error message(Stack trace) • While decompiling the application check for: -IP addresses -hard coded user names/passwords -database name -connection string -internal file name -any other information not supposed to seen by a normal user Prevention • Private API keys are called that for a reason…keep them off of techniques the client • Keep proprietary and sensitive business logic on the server • Almost never a legitimate reason to hardcode a password (if there is, there must be some other problem) • Do not store any passwords or secrets in the application binary References • www.youtube.com/watch?v=9h8kzHTp6fA • androidreversing.blogspot.com/ Tools • Baksmali(decompile Android Applications) • Otx, an advanced disassembler based on tool • Class_dump_z, an updated version of the old class-dump for the iPhoneOS, to extract Objective-C class interfaces • Hex-Rays, the most advanced decompiler ever, also supports ARM binaries (based on Datarescue’s IDA Pro) 11 Prepared by Sayasmito Ghosh (Sayasmito.ghosh@gmail.com)

×