usnistgov / mobile-threat-catalogue

NIST/NCCoE Mobile Threat Catalogue

Mobile Threat Catalogue

In order to fully address the inherent threats of mobile devices, a wider view of the mobile ecosystem is necessary. This repository contains the Mobile Threat Catalogue, which describes, identifies, and structures the threats posed to mobile information systems. The associated report providing context and describing the origins of this repository is available here: NISTIR 8144: Assessing Threats to Mobile Devices & Infrastructure.

Readers of the catalogue may notice threats that are not tied to a documented source or lack countermeasures, and other threats may exist that are not identified here. This catalogue is intended as a living document. Though the initial public comment period is now closed, feedback on mobile threats addressed in the catalogue as well as ideas for additional threats are still encouraged.

mobile-threat-catalogue's Issues

CEL-27 details missing

General Comment

Threat ID: CEL-27
Type of Comment: T
Proposed Change: Fill in details or remove
Justification: All of the details are blank on this threat other than the title

New APP threat: modifying program instructions to cause program to perform unauthorized operations

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application/Malicious or privacy-invasive application

Threat:
Installing malicious code or modifying program instructions to cause the program to perform unauthorized operations.

Threat Origin:
OWASP Mobile Top 10 2016 - M9

https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

Exploit Example:

1. Technical Risks of Reverse Engineering and Unauthorized Code Modification

https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification

1. iOS App Reverse Engineering

https://www.owasp.org/images/b/b9/OWASP_Mobile_App_Hacking_(AppSecUSA_2014)_Workshop_Content.pdf

1. Swizzle with Code Substitution

https://arxan.wistia.com/medias/cv1rh3lpqf

1. Baksmali Code Modification

https://arxan.wistia.com/medias/iubm2r6al8

CVE Example:
- If this threat is related to a published CVE, provide one or more CVE numbers.

Possible Countermeasures:

1. Follow secure coding guidelines
2. Protect application binary from code tampering attacks and malware insertion, by ensuring following security controls are built into the applications -
   a. Ensure binary code of the software application has not been modified by computing (during protection time) and verifying the checksum (during runtime)
   b. Swizzle detection controls to ensure the Objective-C runtime will not invoke the adversary’s malicious form of the method rather than the original and safe one
   c. Debugger Detection or Anti-Debug controls to detect whether the application process is running in debugger
   d. Jailbreak / Root Detection controls to detect whether the application is running on a jailbroken device
   e. Hook detection detection controls to detect whether an attacker is attempting to override a user-defined function in the application
   f. Android Root Detection controls to detect whether the application is running on a rooted device
   g. Software Diversification and Randomization techniques to eliminate BORE (Break Once Run Everywhere) attack tools
   h. Resource verification control to verify resource files or shared library in the Android APK, at runtime, have not been altered or tampered
3. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:

Additional Information:
Hackers are increasingly targeting binary code to launch attacks on high-value mobile applications. A few easy steps and widely available (and often free) tools make it easy for adversaries to directly access, compromise, and exploit application’s code -

a. Analyze or reverse-engineer the binary, and identify or expose sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation

b. Lift or expose proprietary intellectual property out of the application binary to develop counterfeit applications

c. Modify the binary to change its behavior. For example, disabling security controls, bypassing business rules, licensing restrictions, purchasing requirements or ad displays in the mobile app — and potentially distributing it as a patch, crack or even as a new application

d. Inject malicious code into the binary, and then either repackage the apps and publish it as a new (supposedly legitimate) app, distribute under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device

Sept 13th Workshop: Editorial comment

General Comment

Threat ID:
None

Type of Comment:
Enter the letter that best describes the nature of your comment

• E - Editorial

Proposed Change:
Make sure to use the same term consistently across the document. Of note, Wi-Fi (a trademarked term) is not referred to correctly throughout the catalogue. It is also presented incorrectly as WiFi and WIFI.

Justification:

Update Google Analytics code

We should update the GA code with the new one provided by NIST.

Add column for countermeasure actor.

This is in reference to #13

Sept 13th Workshop: LPN-1 technical comment

General Comment

Threat ID:
LPN-0

Type of Comment:

• T - Technical

Proposed Change:
Differentiate between tracking a device by passively listening for SSIDs periodically transmitted by a tracked device, versus actively spoofing SSIDs to entice a response from a tracked mobile device.

Justification:
Different mechanism of attack may require distinct countermeasures to be mitigated effectively.

New APP threat: Intercepting API requests between connected-car app on mobile device and services on back-end server

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Inspecting, intercepting and controlling API requests between connected-car app running on mobile device and the services running on the back-end server.

Threat Origin:
Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs

https://www.troyhunt.com/controlling-vehicle-features-of-nissan/

Exploit Example:
None

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Protect API from reverse-engineering and code tampering/modification attacks
3. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Sept 13th Workshop: General comment

General Comment

Threat ID:
None

Type of Comment:

• G - General

Proposed Change:
After looking at the countermeasures for several threats, it is obvious they are not all directed at the same audience. It would be good to indicate who the countermeasure would be implemented by, such as the device user, enterprise IT, device manufacturer, or cellular service provider.

Justification:
It would make the catalogue a lot more usable by helping the reader to focus on the countermeasures that they are able to implement.

Sept 13th Workshop: LPN-0 Added mitigation

General Comment

Threat ID:
LPN-0

Type of Comment:

• T - Technical

Proposed Change:
Added countermeasure that trusted WiFi access points (AP) also have known and verifiable locations; geo-fencing could be used to prevent mobile device users from being tricked into connecting to rogue access points that spoof the SSID of known access points (e.g. Starbuck's free WiFi). This forces the attacker to set up a rogue AP in close proximity to the trusted AP, which both decreases the chance mobile devices connect to the rogue AP over the trusted AP, and increases the chance the rogue AP will be detected as such.

Justification:
Improve completeness of presented countermeasures.

Sept 13th Workshop: General comment

General Comment

Threat ID:
None

Type of Comment:

• G - General

Proposed Change:
Further identification of threats that are heightened when attack targets are OCONUS.

Justification:
Many threats have a low probability when operating within the continental US, but dramatically increase when OCONUS.

Add information about "Pending" label to contributing.md

The contributing documentation should be updated with information about the "Pending" issue label.

APP-29 editorial issue

General Comment

Threat ID: APP-29
Type of Comment: E
Proposed Change:
Add space between traffic. and On in title

New APP threat: Decompiling IoT apps, looking for "secrets", MiTM attacks on all communications

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Decompiling IoT apps, looking for “secrets”, MiTM attacks on all communications

Threat Origin:
Hacking IoT Devices

https://www.iotvillage.org/slides_DC23/IoT11-slides.pdf

Exploit Example:
None

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines for IoT apps
2. Protect apps from reverse-engineering and code tampering/modification attacks
3. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys/secrets are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Add search functionality

We should implement the ability to search for threats.

One possibility is using the lunr.js library as outlined here http://jekyll.tips/jekyll-casts/jekyll-search-using-lunr-js/

Remove ECO-26

As specified by @sdog-mitre, We should remove ECO-26 from the catalogue as it has no origin or example and contains no information that is not also in ECO-18, which is more complete.

September 13th Workshop - Ecosystem Breakout session - Countermeasures - General comment

General Comment

Threat ID:

Type of Comment:

• G - General comment/question - Are we looking at the backend of apps?

Proposed Change:
N/A - general question posed by attendee

Justification:
General comments, feedback, questions by the breakout session attendee to help improve countermeasures

Workshop comment - STA-0 new countermeasure

General Comment

Threat ID:
If the comment is specific to a given threat, provide the ID for that threat. Otherwise, leave this blank.

Type of Comment:
Enter the letter that best describes the nature of your comment

• E - Editorial comments (e.g. spelling, grammar, or formatting)
• G - General comments on how information has been presented (e.g. format, organization, phrasing, diction, or terminology)
• T - Technical comments on what information has been presented (e.g. correctness of facts, validity of any assumptions or conclusions, level of detail, or contextual relevance)

Proposed Change:
With as much detail as possible, what change should be made.

Justification:
Provide reasoning as to why the proposed change is necessary. For technical comments, providing references to supporting sources is encouraged.

New Threat

Threat Category:
Identify the category you feel the threat falls under.

Threat:
Provide a description of the threat.

Threat Origin:
- If possible, provide at least one resource that describes the nature of this threat.

Exploit Example:
- If possible, provide at least one source that evidences the threat has been realized, either in a laboratory setting or in-the-wild.

CVE Example:
- If this threat is related to a published CVE, provide one or more CVE numbers.

Possible Countermeasures:
- Provide any measures that hinder the successful realization of, reduce the impact of, or improve recovery following incidents involving this threat.

References:
- Author(s), "Name of Document", in Name of Publication, [type of resource], Date of Publication, URL (if available online)

Sept 13th Workshop: LPN-4 Added mitigation

General Comment

Threat ID:
LPN-4

Type of Comment:

• T - Technical

Proposed Change:
Include mention that both Windows Phone and Windows desktop operating systems also perform MAC address randomization.

Justification:
Improve completeness of countermeasures implemented at the OS-level.

New exploit example for AUT-2

General Comment

Threat ID:
AUT-2

Type of Comment:
T

Proposed Change:
Add new exploit example https://arxiv.org/ftp/arxiv/papers/1609/1609.04327.pdf

Justification:
Recent example of bypass with physical possession of the device.

New APP threat: Discovering the cryptographic keys in the code or device memory and lifting it for malicious purposes

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Discovering the cryptographic keys in the code or device memory and lifting it for malicious purpose.

Threat Origin:
None

Exploit Example:

1. Practical attacks against Obfuscated Ciphers

https://www.blackhat.com/docs/eu-15/materials/eu-15-Sanfelix-Unboxing-The-White-Box-Practical-Attacks-Against-Obfuscated-Ciphers-wp.pdf

1. HIDING KEYS IN SOFTWARE

http://www.whiteboxcrypto.com/files/2012_misc.pdf

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
3. Protect application binary from reverse-engineering and code tampering/modification attacks
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Change all links to reflect repository location

All links in the contributing.md file should be changed to reflect being located on the NIST github.

Sept 13th Workshop: General comment - Cybersecurity Framework Integration

General Comment

Threat ID:
None

Type of Comment:

• G - General

Proposed Change:
Indications of what, if any, proposed countermeasures align with existing standards, such as 800-53 controls or the Cyber Security Framework.

Justification:

Revise Comments Due Date

The comments due date should be changed to November 10th

Sept 13th Workshop: General comment

General Comment

Threat ID:
None

Type of Comment:

• T - Technical

Proposed Change:
Threats need to be further categorized or qualified to help readers distinguish those that are of concern to them. Considerations could be the scope of the threat if realized (e.g. geographic region, individual user), the nature of the loss incurred by the target (confidentiality, integrity, availability), or the prevalence of the threat.

Justification:
The catalogue is more usable if readers have additional ways to filter threats.

New APP threat: reverse engineering of binary applications to discover secrets

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Reverse engineering and analyzing the application binary to discover source-code, algorithms, sensitive information and vulnerabilities, for malicious use.

Threat Origin:
OWASP Mobile Top 10 2016 - M9
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

Exploit Example:

1. Technical Risks of Reverse Engineering and Unauthorized Code Modification

https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification

1. iOS App Reverse Engineering

https://github.com/iosre/iOSAppReverseEngineering/blob/master/iOSAppReverseEngineering.pdf

1. OWASP Workshop - reverse engineering iOS apps

https://www.owasp.org/images/b/b9/OWASP_Mobile_App_Hacking_(AppSecUSA_2014)_Workshop_Content.pdf

1. Andriod APK Reverse Engineering

https://arxan.wistia.com/medias/dfobh06p52

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines

2.Protect application binary from code analysis and reverse-engineering attacks, by ensuring following security controls are built into the application -
a. Control Flow, Code & Data Obfuscation controls to transform the software program into code that’s difficult to disassemble and understand
b. Symbol stripping to remove unused program symbols (which usually convey sensitive information to adversaries) from application binaries
c. Symbol renaming to change easy-to-understand program symbol names (that cannot be removed from applications) to irrelevant names
d. Encrypting parts of or the whole application when stored on disk and when unused at runtime. Also, encrypting data within the application
e. String encryption to hide plaintext string encodings (e.g., sensitive text-based SQL queries or private messages sent to remote trusted servers)
f. Damage to replace sensitive regions with decoy or garbage code when not in use and replace with the original code when in-use
g. Software Diversification and Randomization techniques to eliminate BORE (Break Once Run Everywhere) attack tools

1. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:

Additional Notes:
Hackers are increasingly targeting binary code to launch attacks on high-value mobile applications. A few easy steps and widely available (and often free) tools make it easy for adversaries to directly access, compromise, and exploit application’s code -

a. Analyze or reverse-engineer the binary, and identify or expose sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation

b. Lift or expose proprietary intellectual property out of the application binary to develop counterfeit applications

c. Modify the binary to change its behavior. For example, disabling security controls, bypassing business rules, licensing restrictions, purchasing requirements or ad displays in the mobile app — and potentially distributing it as a patch, crack or even as a new application

d. Inject malicious code into the binary, and then either repackage the apps and publish it as a new (supposedly legitimate) app, distribute under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device

Correct Application Threat Categories

In the data migration it seems the sub-categories for application threats got changed. These should be corrected.

STA-27 suggest removing or rephrasing

General Comment

Threat ID: STA-27
Type of Comment: T
Proposed Change: Suggest removing or rephrasing
Justification: This threat is worded poorly, seems overly specific, and there are no examples provided. Could either remove the threat entirely, or remove the phrase "misinterpreted disallowances on the parameters of commands could lead to surprising results" from the threat title along with potentially adding some examples.

Sept 13th Workshop: General comment

General Comment

Threat ID:
None

Type of Comment:
Enter the letter that best describes the nature of your comment

• G - General

Proposed Change:
Some threats presented are specific to technologies that are primarily used in certain parts of the world should include that information to help reader's discriminate the applicability of threats.

Justification:
More complete threat information.

September 13 Workshop - Ecosystem Breakout session - Countermeasure General Comment

General Comment

Threat ID:
ECO-1

Type of Comment:

• G - EMM could store hashes to backups.

Proposed Change:
N/A - suggestion

Justification:
Feedback from breakout session attendees to improve countermeasures

STA-30 suggest removing

General Comment

Threat ID: STA-30
Type of Comment: T
Proposed Change: Remove
Justification:
This does not look like a threat

September 13 Workshop - Ecosystem Breakout session - Countermeasure General Comment

General Comment

Threat ID:
ECO-2

Type of Comment:
G - Assumption - Apply applicable data encryption for data in transit and at rest. Note - compliance and certification versus data protection and depends on type of data

Proposed Change:
N/A - attendees recommended that the proper data encryption be applied for data at rest and in transit.

Justification:
Feedback from breakout session attendees to improve countermeasures

Sept 13th Workshop: General comment

General Comment

Threat ID:
None.

Type of Comment:

• G - General

Proposed Change:
It would be helpful to identify the implications of implementing countermeasures when they potentially conflict with other security goals. For example, requiring a 15-character complex password counters many attacks on passwords. However, that hurts usability of the password for end users.

Justification:
Help readers make more informed decisions regarding the proposed countermeasures to adopt.

APP-25 editorial issue

General Comment

Threat ID: APP-25
Type of Comment: E
Proposed Change: fix double ' in title

ECO-13 ECO-21 ECO-25 have the same title

General Comment

Threat ID: ECO-13 ECO-21 ECO-25
Type of Comment: E
Proposed Change:
All 3 have the same title. However, the content of each is slightly different, so not sure what we want to do with these. Could either consolidate into 1 threat, or change the individual titles of all 3.

New APP threat: copying, distributing and re-publishing the application illegally

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Copying, distributing and re-publishing the applications illegally.

Threat Origin:
None

Exploit Example:

1. Trend Micro Research Paper - Fake Apps Feigning Legitimacy

http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-fake-apps.pdf

1. Play Drone: Columbia University Engineering Team Finds Thousands of Secret Keys in Android Apps - A Measurement Study of Google Play

http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdrone.pdf

1. Repository contains the code used for Play Drone project by Columbia University

https://github.com/nviennot/playdrone

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Download the apps from official stores
3. Ensure security controls are built into application to protect against code analysis and reverse-engineering attacks
4. Ensure security controls are built into application to protect against code tampering attacks and malware insertion
5. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Additional Information:
Hackers are increasingly targeting binary code to launch attacks on high-value mobile applications. A few easy steps and widely available (and often free) tools make it easy for adversaries to directly access, compromise, and exploit application’s code -

a. Analyze or reverse-engineer the binary, and identify or expose sensitive information (keys, credentials, data) or vulnerabilities and flaws for broader exploitation

b. Lift or expose proprietary intellectual property out of the application binary to develop counterfeit applications

c. Modify the binary to change its behavior. For example, disabling security controls, bypassing business rules, licensing restrictions, purchasing requirements or ad displays in the mobile app — and potentially distributing it as a patch, crack or even as a new application

d. Inject malicious code into the binary, and then either repackage the apps and publish it as a new (supposedly legitimate) app, distribute under the guise of a patch or a crack, or surreptitiously (re)install it on an unsuspecting user’s device

APP-32 editorial

General Comment

Threat ID: APP-32
Type of Comment: E
Proposed Change:
fix double ' in title (device''s)

Sept 13th Workshop: General comment

General Comment

Threat ID:
None

Type of Comment:
Enter the letter that best describes the nature of your comment

• G - General

Proposed Change:
Provide definitions for potentially contentious terms like 'countermeasure'. In some communities, such as the Defense Community, those terms may carry additional meaning that you may or may not be intending in the context of your document.

Justification:
Avoid potential misinterpretation of the intent of proposed actions a reader could take to respond to presented threats.

September 13 Workshop - Ecosystem Breakout session - General comment

General Comment

Threat ID:
ECO-0

Type of Comment:

• G - General comments on Countermeasures for ECO-0.

Proposed Change:
Suggestions to make less platform specific.
Samsung comments: management of backups. Storage of backups to be managed from MDM. Make sure you have good backup policies. Use authentication tool to device. As appropriate, block backups.
Focus on GFE (Gov't furnished equipment).
Google comment - break up countermeasures by user, device, and management system

Justification:
Inputs recommended by attendees of breakout session to improve countermeasures

Sept 13th Workshop: CEL-28 added countermeasure

General Comment

Threat ID:
CEL-28

Type of Comment:
Enter the letter that best describes the nature of your comment

• T - Technical

Proposed Change:
Mention that some cellular carriers may offer additional encryption services that would counter eavesdropping of the backhaul.

Justification:
Improved completeness of countermeasures.

APP-7 CVE Example link is malformed

General Comment

Threat ID: APP-7

Type of Comment: E

Proposed Change:
Fix link to CVE

New APP threat: Attacks on mobile health apps and medical devices

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Attacks on mobile health apps and medical devices.

Threat Origin:
None

Exploit Example:
http://www.computerworld.com/article/2837413/security0/dhs-investigates-24-potentially-deadly-cyber-flaws-in-medical-devices.html

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines for medical apps
2. Protect apps from reverse-engineering and code tampering/modification attacks
3. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys/secrets are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Add CVE to threat APP-36

General Comment

Threat ID:
APP-36

Type of Comment:
Technical

Proposed Change:
Please add the following CVEs as they are associated with the Samsung exploit.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4640
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4641

Justification:
No CVEs are currently referenced.

September 13 Workshop - Ecosystem Breakout session - Countermeasure General Comment

General Comment

Threat ID:
ECO-3

Type of Comment:
G - Within app stores you can enforce whitelisting of apps. Ensure use of Trusted app sites. Isolation or quarantine of apps. Verify signature of apps. Need behavior based detection. Signature based detection along with Continuous Monitoring.

Proposed Change:
Suggested implementation of the above recommendations

Justification:
Feedback from breakout session attendees to improve countermeasures

EMM-9 editorial

General Comment

Threat ID: EMM-9
Type of Comment: E
Proposed Change: Countermeasures - "Reduce the risk a" should be "Reduce the risk of a"

New APP threat: Analysis of SmartApps (Smart Home apps) running on mobile devices

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Application: Vulnerable Application

Threat:
Analysis of SmartApps (Smart Home apps running on Mobile device) causing privilege elevation, spoofing, code modification, information disclosure.

Threat Origin:
Security Analysis of Emerging Smart Home Applications

https://iotsecurity.eecs.umich.edu/#summary

Exploit Example:
None

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Protect SmartApps from reverse-engineering and code tampering/modification attacks
3. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

ECO-11 editorial

General Comment

Threat ID: ECO-11
Type of Comment: E
Proposed Change:
Change appstore to app store in the title to be consistent with other entries

New PAY threat: Vulnerabilities of HCE-based NFC Mobile Payment for code tampering and cryptographic key lifting attacks

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Payment

Threat:

1. Vulnerabilities of HCE-based NFC Mobile Payment for code analysis/tampering and cryptographic key lifting attacks
2. Attacks on storage of HCE-based NFC Mobile Payment

Threat Origin:
None

Exploit Example:

1. Secure Element Deployment & Host Card Emulation

http://paybefore.com/wp-content/uploads/2014/04/Secure-Element-Deployment-Host-Card-Emulation-v1.0.pdf

1. A SMART CARD ALLIANCE MOBILE & NFC COUNCIL WHITE PAPER - Host Card Emulation (HCE) 101

http://www.smartcardalliance.org/downloads/HCE-101-WP-FINAL-081114-clean.pdf

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
3. Protect application binary from reverse-engineering and code tampering/modification attacks
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None

Additional Information:
HCE (Host Card Emulation) will allow a smartcard to be emulated on the mobile phone without using an SE (hardware secure element), which introduced following key security risks that were not present in SE-based NFC services:

• Attacker could gain access to sensitive information such as payment credentials and cardholder information

• Malware applications could attack the OS and exploit the device and mobile payment app

• Malicious user could gain access to information stored within the mobile payment application and use it to make fraudulent payments

Security implications of bypassing the hardware SE must be considered because applications running on the Android OS are much more vulnerable to malicious attacks.

Fix category list on mobile

Before the site breaks to a single column layout, the category list in the left sidebar gets pushed too far to the right. This should be aligned correctly.

AUT-0 editorial

General Comment

Threat ID: AUT-0
Type of Comment: E
Proposed Change:
Malformed sentence in 4th bullet under Possible Countermeasures
Looks like 'users from creating new credentials which are similar to recently used ones (re-use policy)' should be put in its own bullet, with 'Prevent' added to the beginning of the sentence.

New PAY threat: Vulnerabilities of 3rd party payment API for tampering and cryptographic key lifting attacks

On behalf of Prashanth Thandavamurthy of Arxan Technologies, Inc.

New Threat

Threat Category:
Payment

Threat:
Vulnerabilities of 3rd party payment API for code analysis/tampering and cryptographic key lifting attacks.

Threat Origin:
API Attacks

http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c18.pdf

Exploit Example:
None

CVE Example:
None

Possible Countermeasures:

1. Follow secure coding guidelines
2. Use cryptographic key protection solution such as Whitebox Cryptography to ensure -
   a. Cryptographic keys are not discovered at any time, and are not present in static form or in runtime memory
   b. Data is protected at rest, in transit and in-use
3. Protect API from reverse-engineering and code tampering/modification attacks
4. Leverage vulnerability/penetration testing and ensure that known risks – including those identified in the OWASP mobile top 10 list, in particular, are addressed

References:
None