Your SlideShare is downloading. ×
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Generic threats to mobile application
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Generic threats to mobile application

794

Published on

This paper covers security issues that a security analyst may look for during vulnerability assessment and penetration testing on case–by-case basis. Issues covered in the paper are generic and can be …

This paper covers security issues that a security analyst may look for during vulnerability assessment and penetration testing on case–by-case basis. Issues covered in the paper are generic and can be considered across all the mobile platforms.

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

  • Be the first to like this

No Downloads
Views
Total Views
794
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Generic Threatsto MobileApplications Vikrant Kansal Information Security Analyst vikrant.kansal@gmail.com 21/Jan/2013 1Page 0 of 11
  • 2. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONSTable of ContentsAbstract………………………………………………………………………………………………………………………………2Background…………………………………………………………………………………………………………………………2Fingerprinting………………………………………………………………………………………………………………………2Authentication and Authorization……………………………………………………………………………………….3Data & Information Management……………………………………………………………………………………….4Input Validation…………………………………………………………………………………………………………………..6Information Leakage in Transit………………………………………………………………………………………….6Session Management Issues………………………………………………………………………………………………7Secure Coding & Development Practices……………………………………………………………………………8Known Vulnerability & Patch Issues……………………………………………………………………………………8System Privilege Issues………………………………………………………………………………………………………9Weak Cryptography…………………………………………………………………………………………………………….9Cross Site Scripting……………………………………………………………………………………………………………..9Cross Site Request Forgery……………………………………………………………………………………………....93rd Party Application Integration Issues…………………………………………………………………………….9About The Author……………………………………………………………………………………………………………….10References………………………………………………………………………………………………………………………….10 1 21 Jan 2013 | Vikrant Kansal
  • 3. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONSAbstractAs we all know that "Mobile/Smart Phone" usage is increasing day by day, people are switchingfrom their Laptop/PC to mobile phone to get connected to the Web World.Mobile applications for social networking, corporate e-mailing, financial transactions, monitoringand reporting are very common amongst Mobile/ Smart phone users.We have also observed that as the usage of Mobile phone is increasing, the cases of mobilesecurity issues are also increasing. Attackers are now targeting Mobile/Smart phone users to getsensitive information like credit card details, confidential documents, contact information to namea few.This paper covers security threats to mobile applications and helps security analysts duringvulnerability assessment.BackgroundThis paper covers security issues that a security analyst may look for during vulnerabilityassessment and penetration testing on case–by-case basis. Issues covered in the paper aregeneric and can be considered across all the mobile platforms.Security issues are covered under the below mentioned points  Fingerprinting  Authentication & Authorization  Data & Information Management  Input Validation  Information Leakage in Transit  Session Management Issues  Secure Coding & Development Practices  Known Vulnerability & Patch Issues  System Privilege Issues  Weak Cryptography  Cross Site Scripting  Cross Site Request Forgery  3rd Party Application Integration Issues1. FingerprintingWhile identifying security threats in an application, it is recommended to start with fingerprinting.Fingerprinting helps security professionals to gather information that is available without puttingmuch effort. What we can look for is covered as below:1.1 Mobile Application Port ScanningPerform port scanning after installing the application and look for opened/listening ports. Anyopened port may allow the attacker to attack. Make sure that all the opened/listening ports have apurpose in application functioning. 2 21 Jan 2013 | Vikrant Kansal
  • 4. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS1.2 Mobile Application Banner GrabbingBanner grabbing can help to identify initial level threats to the application. Easy availability ofapplication version, contact information and any other important information helps the attacker toplan the attack in the respective application. Attacker can exploit a known vulnerability in anunpatched application version. Ensure that banner should not reveal any sensitive informationabout application that helps the attacker.2. Authentication & Authorization2.1 Default Login CredentialsApplication that allows some default login credentials is prone to unauthorized access toinformation. Confirm that no default login credentials are allowed.2.2 Clear Text PasswordConfirm that an application does not show password in clear-text. It allows an attacker to grab theuser’s password easily which can further provide access to unauthorized information.2.3 Simple Username, Password or Username/Password combinationsMake sure that authentication credentials are strong enough and cannot be guessed. Weakusername and password lead to unauthorized application access.Avoid using swipe based passwords as they are unsafe and prone to smudge-attacks.2.4 Repeat/Consecutive Failed Password HandlingIdentify whether application has proper handling for repeated password failure or not. Ifapplication does not have any challenge question, Captcha or locking mechanism then applicationis prone to brute force attack.2.5 Multiple factor authenticationIt is good that application use multiple factor authentications to access sensitive information, likeperforming financial transactions.If application has 2-factor authentication in place and is using one time password (OTP) techniquethen check for any flaw in OTP implementation. If possible avoid sending OTP using SMS. Attackermay install the SMS receiver on device to get the SMS and can further access the user account.2.6 Unique Identification Key Generation issueCheck whether unique identification key used for validation and authentication is strong or not.Weak algorithm, that uses common identifier like IMEI number as key, can be spoofed by anyattacker. “OAuth” based token implementation can be helpful to avoid such attacks.2.7 Same password for all purposesMany applications have multiple services. Especially in case of financial applications a user canperform multiple transactions. So make sure that the same password should not be used formultiple purposes. If possible, use a separate password for critical transactions.2.8 Captcha SupportCheck for Captcha implementation within application. Weak Captcha implementation can bevulnerable to brute force attack. 3 21 Jan 2013 | Vikrant Kansal
  • 5. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS2.9 Invalid Certificate HandlingInvalid certificates should be rejected by application. If application does not handle invalidcertificate like expired certificate then an attacker can craft a certificate and use it duringauthentication.2.10 Access to highly sensitive data should be PIN or password protectedCheck whether application asks for a PIN or password while accessing highly sensitive data.If highly sensitive data is not protected by a PIN or password, attacker might get access to theapplication or user data.2.11 Consent of user for any cost implications - behavior of applicationCheck for any warning or acceptance windows during any cost based transaction.User should be informed before deducting any money. If user consent is not implemented, then incase of application compromise, user will lose money.2.12 Provision to update/renew password and unique identification tokenApplication should have functionality to expire password /token. It should also provide feature toupdate/renew password or identification token after the expiry period.2.13 Check for application user permissionMobile application provides different permissions using the configuration files, like in case ofAndroid platform configuration file “AndroidManifest.xml” file includes permissions details. Dropany unwanted permission that is not used or required by application.2.14 Phishing AttackConfirm that how application safeguards itself against phishing attacks. Check for any flaw in thetechnique used.3. Data & Information Management3.1 Store sensitive data on server sideIt is always good to store sensitive data on a server such as authentication credentials, tokens andapplication license details. If authentication credentials are available within application binary thenattacker can reverse engineer the application to get the sensitive data.3.2 Encrypt or Hash the sensitive data or file stored on device.Any sensitive information like password, unique token, session information, account number orany file ,log file, backup file stored on device should be encrypted or hashed using standard APIprovided by a platform or any trusted party and stored on a restricted storage area.Encrypting the file or information makes the attacker’s life difficult in getting the sensitiveinformation. Also in case of device loss, the sensitive information encrypted is not revealed to theother person.3.3 Avoid use of removable media to store informationConfidential data should not be stored on removable media like SD card. Also avoid storing theapplication data in standard folders provided by mobile phone, as these folders are shared amongother applications. 4 21 Jan 2013 | Vikrant Kansal
  • 6. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS3.4 Weak Permissions –Application Data in Shared MemoryIn case application needs to share data with other applications using shared memory then checkthe permissions of application data in shared memory. It should be read-only. Always try to getand disclose minimum information, which is desired for application/s to work properly. Any failurein handling, leads to corruption or leakage of data.3.5 Weak Error Message handlingError handling should be done properly and should not include any sensitive information.Some error handling code reveals the sensitive information that can be used by the attacker.3.6 No backup, caching and logging of sensitive dataCheck no sensitive data is stored in backup or log files. Also, ensure that the cache is clear.Failure leads to data leakage attack.3.7 Remote data wipeCheck whether remote data wipe feature is provided by application or not as it is important in caseof device loss or theft. If remote data wipe is unavailable then in case of device loss or theft,someone can easily access the application or corporate data.3.8 Weak File PermissionsCheck application’s file permissions are in place. Improper file permissions may allow an attackerto modify/corrupt/delete the file.3.9 Deletion of sensitive data from database on application exitCheck that the sensitive data is flushed from database when a user exits from application. Failureleads to data leakage attack.3.10 Data deletion practicesDelete data/information when not required. Do not keep historical data of location information forlong. Keep the data as per data retention policy in place. Refer NIST-800-88 for more on thisissue.3.11 Certificate and Key ManagementCheck that the Certificate and Key are not disclosed to any other program. Disclosure of key andcertificate leads to unauthorized access3.12 Deletion of Keystroke and Screen Snapshot cacheDelete all Keystroke and Screen Snapshot cache files. Failure leads to data leakage attack.3.13 Sharing of user data with other applicationsMany applications share the user personal information with other applications or websites likesocial networking, advertising, etc. In such cases, user consent is important otherwise it leads toprivacy policy violation.Always check that user gives his consent whenever personal information is stored or shared. 5 21 Jan 2013 | Vikrant Kansal
  • 7. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS3.14 Maintain data and transaction Logs on server side for Audit purposeData and transactions logging should be done on server so that in case of any incident, auditor canrefer the log files especially in case of financial transactions and user consent. Logging on deviceis under user control and can be tampered with.3.15 Limited access based on contextual informationAccess to sensitive information can be restricted based on the geographical location and distance.Example: - Enterprise data is not accessible using mobile application if device is outside officepremises.4. Input Validation4.1 Input FuzzingCheck application and its components for handling fuzz data. If application crashes then it can beexploited.4.2 Buffer WeaknessCheck the buffer length used in application. Invalid buffer size can lead to buffer overflow orunderflow attack.4.3 Input Injection FlawsAttacker can exploit the application and run executable code or script. Therefore, validate inputvalues provided by users.4.4 Mobile Client Format String Input FlawsFailure to handle format string issues can lead to application corruption.4.5 Runtime interpretationValidate the 3rd party inputs at runtime like payment gateways. Runtime interpreter’s validationfailure leads to arbitrary code execution.4.6 DOS vulnerability-Employment of rate limit and throttlingVerify the throttle values, the limit on user inputs and user request handled by the application. Nothrottle and limit check can lead to Denial of service attack4.7 Validation of data received from non-trusted 3rd partyValidate data received from any untrusted source before processing. No validation can lead toarbitrary code execution attack.5. Information Leakage in Transit5.1 Encryption of sensitive dataInformation transferred over wireless or air (edge, 3G/4G) can be intercepted by the attacker. Souse end-to-end encryption of sensitive data transfer over network. Clear data transfer lead tocredentials compromise, sensitive data leakage etc. 6 21 Jan 2013 | Vikrant Kansal
  • 8. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS5.2 SSL weaknessCheck for known SSL weakness or vulnerability in implemented SSL version. Known vulnerabilitiescan be exploited by the attacker to get access to sensitive data.5.3 Handling of request redirection from HTTPS to HTTPMany applications switched from HTTPS to HTTP to reduce encryption overhead when no sensitivedata is transferred. So as security analyst we need to check for any flaw in redirection from HTTPSto HTTP. Failure leads to data leakage attack.5.4 Sensitive data transfer within file metadataMany applications share information in metadata for SEO purposes. Make sure that no sensitiveinformation should be transferred as Metadata.5.5 Trusted CA and SSL chain validation issueIt is recommended to use the SSL certificates issued by trusted CA instead of self-signedcertificate. Also check application does not ignore SSL chain validation during end to endcommunication.5.6 SSL establishment with the end points having the trusted certificates in key chainSecure connection between application and server should only be established after verifying theidentity of the remote server. To ensure this check that SSL is only established with end-pointshaving the trusted certificates in the key chain. Failure leads to man-in-middle (SSL proxy) attack5.7 SMS, MMS or notifications having sensitive data or information issueCheck no SMS, MMS is used by application for notification which includes sensitive data. Failureleads to data leakage attack.5.8 Web Services/SOAP/REST-Security issuesEnsure that information is available only after authentication and user can access the informationthat is allowed as per privilege policies. Check for best security practices. Failure leads to dataleakage attack.5.9 Data transfer using mobile Wallet, NFC communication, In-App BillingInformation used during NFC communication is highly confidential so make sure for any possibleflaws in it. Information used by Wallet, in-app billing and NFC should not be in plain text. Alsocheck for any known issue in technology.6. Session Management Issues6.1 Weak Session IdentifierSession identifier should be unpredictable and should be unique per session. Weak Identifiers likeIMEI number or UDID can be predicted by the attacker and help in conducting session hijackingattack.6.2 Session FixationApplication should invalidate all old session identifier, cookies etc. 7 21 Jan 2013 | Vikrant Kansal
  • 9. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS6.3 Session Timeout FeatureApplication should have a session timeout feature. In case of sensitive transactions, session timeout value should be small.6.4 Session Timeout HandlingAll the session data and session cache should be deleted after logout. Failure leads to data leakageattack.7. Secure Coding & Development Practices7.1 Test Code within release version of applicationLook for any source code which was added during testing phase.7.2 Backdoor entry codeLook for any source code which was added by developer for backdoor entries. This code may leadto unauthorized access to application.7.3 Encoding and escaping of output dataCheck for escaping and encoding before representing/processing and transferring the output data.Data escaping failure leads to execution of code. No encoding leads to data leakage.7.4 Usage of Weak API and FunctionsIdentify use of weak API or functions as per security guidelines. Weak API or functions leads toapplication compromise.7.5 Disabling privileges granted by default APICheck the source code whether developer programmatically disabled the weak privileges of APIwhich were granted by default or not. Default privileges of API are always known and failure todisable some weak privileges leads to application access attack.7.6 Using OS communication mechanism instead of opening SocketCheck the implementation of communication channel. Always prefer to use the OS providedcommunication mechanism instead of opening a socket.Attacker can get the open port information via performing port scanning on the device and thenconduct DOS attack7.7 Super user privilege within codeCheck the source code for granting super user privilege. Avoid granting super user privilege, but ifrequired then no other program can access this piece of code.7.8 Obfuscate application codeObfuscate application code so that it is difficult to reverse engineer. Development platformsprovide some basic level of obscuration. For e.g. On Android platform, ProGraud can be used forbasic level obfuscation. 8 21 Jan 2013 | Vikrant Kansal
  • 10. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS8. Known Vulnerability & Patch Issues8.1 Check for Identified Vulnerability Issues in Native languageCheck for any identified vulnerability in native language. Known vulnerability can be easilyexploited by attacker8.2 Check for third party library/API known Security IssuesCheck for any identified vulnerability of third-party API or library used by application.8.3 Check for Identified SDK/API version specific VulnerabilitiesCheck for any identified vulnerability of SDK/API version that application supporting. Knownvulnerability can be easily exploited by an attacker.9. System Privilege Issues9.1 System Privileged Command ExecutionCheck the source code if it executes any system level privileged command or not. If codeimplementation has some flaw then it can be exploited by the attacker to execute the command.9.2 System Privileged Device SettingsCheck the source code if it can change the system settings of privilege code. If codeimplementation has some flaw then it can be exploited by the attacker to change the devicesettings.10. Weak Cryptography10.1 Weak Cryptographic AlgorithmCheck no weak cryptographic algorithm, hash function, encryption key length is used or supportedby application.11. Cross Site Scripting11.1 Input validation for any scripting codeCheck all possible XSS vector. Failure leads to XSS attack. Please refer OWASP guidelines to knowmore about this attack.12. Cross Site Request ForgeryLook for possible CSRF vector. Failure leads to CSRF attack. Please refer OWASP guidelines toknow more about this attack.13. 3rd Party Application Integration Issues13.1 Sensitive data leakageCheck for any data leakage during integration of 3rd party application. 9 21 Jan 2013 | Vikrant Kansal
  • 11. January 21,2013 GENERIC THREATS TO MOBILE APPLICATIONS13.2 Insecure data connectionCheck for insecure data connection between application and 3rd party application. Insecuretransfer leads to data leakage.13.3 Session ValidationCheck for any session hijacking issues during data transfer between application and third party.Failure leads to Session hijacking.About The AuthorVikrant Kansal is an Information Security Analyst based out of India. Vikrant has over 8 years ofindustry experience in the Security domain. He is a graduate in Computer Science & Engineeringand having experience in vulnerability analysis and assessment, mobile and web applicationanalysis, penetration testing and secure code review.References[MacAfee] http://www.mcafee.com/in/resources/white-papers/foundstone/wp-pen-testing-iphone-ipad-apps.pdf[Google] http://developer.android.com/training/articles/security-tips.html[OWASP] https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Controls[MacAfee] http://www.mcafee.com/in/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf[Apple] http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf 10 21 Jan 2013 | Vikrant Kansal

×