Make use of OWASP Mobile Top 10

February 14, 2017

OWASP “Mobile Security Project” team updated their Mobile Top 10 Vulnerability list this week. {in the process they broke some of their links, if you hit one, just use the 2015 content for now: https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad}

I was in a meeting yesterday with a group reviewing one facet of an evolving proposal for Office 365 as the primary collaboration and document storage infrastructure for some business operations.

Office 365 in global Financial Services? Yup. Technology pundits-for-sale, tech wannabes, and some who are still intoxicated by their mobile technology have been effective in their efforts to sell “cloud-first.” One outcome of some types of “cloud-enabled” operations is the introduction of mobile client platforms. Even though global Financial Services enterprises tend to hold many hundreds of billions or trillions of other people’s dollars, some sell (even unmanaged) mobile platforms as risk appropriate and within the risk tolerance of all relevant constituencies… My working assumption is that those gigantic piles of assets and the power that can result from them necessarily attract a certain amount of hostile attention. That attention requires that our software, infrastructure, and operations be resistant enough to attack to meet all relevant risk management obligations (contracts, laws, regulations, and more). This scenario seems like a mismatch — but I digress.

So, we were attempting to work through a risk review of Mobile Skype for Business integration. That raised a number of issues, one being the risks associated with the software itself. The mobile application ecosystem is composed of software that executes & stores information locally on mobile devices as well as software running on servers in any number of safe and wildly-unsafe environments. Under most circumstances the Internet is in between. By definition this describes a risk-rich environment.

All hostile parties on earth are also attached to the Internet. As a result, software connected to the Internet must be sufficiently resistant to attack (where “sufficient” is associated with a given business and technology context). Mobile applications are hosted on devices and within operating systems having a relatively short history. I believe that they have tended to prize features and “cool” over effective risk management for much of that history (and many would argue that they continue to do so). As a result, the mobile software ecosystem has a somewhat unique vulnerability profile compared to software hosted in other environments.

The OWASP “Mobile Security Project” team research resulted in the Top 10 mobile vulnerabilities list below. I think it is a useful tool to support those involved in thinking about writing or buying software for that ecosystem. You can use it in a variety of ways. Challenge your vendors to show you evidence (yes, real evidence) that they have dealt with each of these risks. You can do the same with your IT architects or anyone who plays the role of an architect for periods of time — then do it again with your developers and testers later. Business analysts, or those who act as one some of the time should also work through adding these as requirements as needed.  Another way to use this Mobile Top 10 resource is to help you identify and think through the attack surface of an existing or proposed mobile-enabled applications, infrastructure, and operations.

OK, I hope that provides enough context to make use of the resource below.

REFERENCES:

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

M1 – Improper Platform Usage
https://www.owasp.org/index.php/Mobile_Top_Ten_2016-M1-Improper_Platform_Usage
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

M2 – Insecure Data Storage
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M2-Insecure_Data_Storage  This new category is a combination of M2 + M4 from Mobile Top Ten 2014. This covers insecure data storage and unintended data leakage.

M3 – Insecure Communication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M3-Insecure_Communication This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

M4 – Insecure Authentication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M4-Insecure_Authentication This category captures notions of authenticating the end user or bad session management. This can include:
Failing to identify the user at all when that should be required
Failure to maintain the user’s identity when it is required
Weaknesses in session management

M5 – Insufficient Cryptography
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M5-Insufficient_Cryptography The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

M6 – Insecure Authorization
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M6-Insecure_Authorization This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure.

M7 – Client Code Quality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M7-Poor_Code_Quality
This was the “Security Decisions Via Untrusted Inputs”, one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That’s distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

M8 – Code Tampering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M8-Code_Tampering
This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

M9 – Reverse Engineering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M9-Reverse_Engineering
This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property.

M10 – Extraneous Functionality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M10-Extraneous_Functionality Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.


Protect Your USB

September 19, 2016

Physical and logical PC controls still matter.

Just one more reason to resist the shared madness of “bring your own device” and/or “anywhere/anytime/any-endpoint” in global Financial Services.  We hold trillions of dollars for our customers (under the guise of a broad and evolving range of relationships)!  To add value to those relationships, we turn that money into units that are inter-business (and Internet) friendly to enable complex webs of financial transactions and services.  The concentration of “cash” and its transformation into bits results in an attractive target for hostile parties of many types.  How could endpoint anarchy ever be a risk-appropriate behavior for any but a microscopically few roles within our ranks?  It seems like something we should expect to fail the “reasonable person” test.

I was just catching up on some of my random reading and bumped into this demonstration of Windows credential stealing with just 15 seconds of access to a PC’s USB port.

15 seconds of social engineering is not that hard to pull off, so all you have left are serious controls administering the use of your USB ports, physically destroying your USB ports (yes, that is a serious option), along with multi-layer physical & logical security to the location of the PC at any given time.

Take a look st the video below along with the supporting paper.  Then voice your professional opinion and conscience wherever appropriate to resist elevated risk endpoint behaviors.  And if your role permits, ensure that your Financial Services organization has the goals and resources to effectively deal with attacks like the ones enabled by this automated, USB enabled assault.

REFERENCES:

15 Second Password Hack, Mr Robot Style
Video:
https://www.hak5.org/episodes/season-21/hak5-2101-15-second-password-hack-mr-robot-style
Supporting Paper
https://www.hak5.org/blog/15-second-password-hack-mr-robot-style


Can Financial Services Explain How Mac OS X Security is Good Enough?

April 29, 2015

After years of attempting to generate love by claiming that a Mac “doesn’t get PC viruses. A Mac isn’t susceptible to the thousands of viruses plaguing Windows-based computers.” (apple.com 2012)”, Apple has introduced technology for at least 4 different approaches to strengthening OS X resistance to hostile malware.

These features include:

  • gatekeeper
  • xprotect
  • OS X sandbox
  • code-signing

Each of these features is an attempt to compensate for and overcome software architectures, designs, and implementations that are overly-permissive — resulting in software that too easily “trusts.”  They represent the type of “bolt on security” that Financial Services enterprises are expected to implement throughout their secure software practices.  “Secure-enough” software needs to be created or adapted with that goal in place throughout the entire SDLC and/or acquisition process and must not treat risk management as something that is applied to software only after it is finished.

There is a lot of evidence that these features are still far too little, too late. In a recent presentation at RSA, Patrick Wardle, Director of Research, Synack, described the current situation as “lots of Macs, feeble anti-malware protections, os x malware, and limited detection/prevention tools.” He then walked the audience methodically through exploits against each of the Apple OS X anti-malware protections, and then outlines a range of approaches to Mac malware persistance. Finally, he mentions a couple tools for detecting OS X malware: knockknock (ui) & blockblock.

Wardel’s presentation references OS X malware/exploit work by fG!. In one relatively recent talk at SyScan15, after 165 slides outlining OS X threat vectors and their exploit he concluded that “Apple product security strategy is reactive not proactive. If they have any strategy at all…”

These guys don’t represent an isolated fringe of the the professional risk management world.  They are serious professionals, attempting to help others “get it.”  Their work seems to be a shout for recognition that OS X malware-enabled exploits represent a foundational and (for most Financial Services enterprises) critically-important risk.

Why is this such a big deal?  Remember, each of our organizations needs to be diligent and effective at resisting attack along all vectors, while attackers need only be successful against one of them.  Attackers know that Macs are vulnerable via a number of vectors, that Mac security products are not great, and that Mac users are finding ways to “plug them into” corporate environments.

For many Financial Services enterprises, request by request, exception by exception, members of the workforce have been hosting an increasing range of business activities on Macs (on both unmanaged, and under-managed endpoints).  They are granted remote access.  They are plugged into our “trusted” internal networks.  And they get the same “trusted” access as heavily-managed, standard Windows endpoints.  Sometimes an organization has a fog of “managed” or “secured” and authorized Macs that mask this core risk management issue — which, for the most part, remains the same.

As a result, we need to help our leaders carefully think through:

  • Whether this is risk-appropriate for any given Financial Services use case,
  • What alternatives to current Mac-enabled practices exist, and should we migrate to them? Are isolation techniques “good-enough?”
  • How we are going to protect our assets and operations from the threat vector Mac endpoints pose?
  • How are we going to tell our Mac endpoints risk management story to all relevant stakeholders?

REFERENCES:

“Malware Persistence on OS X Yosemite” by Patrick Wardle (http://www.rsaconference.com/speakers/patrick-wardle).
Thursday, April 23, 2015
Session: https://www.rsaconference.com/events/us15/agenda/sessions/1591/malware-persistence-on-os-x-yosemite

Presentation: https://www.rsaconference.com/writable/presentations/file_upload/ht-r03-malware-persistence-on-os-x-yosemite_final.pdf

“BadXNU — A rotten apple!.” by fG!/@osxreverser (https://reverse.put.as/about/)
https://reverse.put.as/wp-content/uploads/2015/03/SyScan15-BadXNU_presented_slides.pdf

 

 


Exploits Violate OAuth 2.0 and OpenID Assumptions

May 14, 2014

Earlier this month, numerous outlets reported that Wang Jing, a PhD student in mathematics from Nanyang Technological University, uncovered serious security vulnerabilities in OAuth 2.0 and OpenID, the technologies used by many websites to authenticate users via third-party websites.

Almost all major providers of OAuth 2.0 and OpenID identity services are affected, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, Paypal, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru, Sohu, etc.

Remember, OAuth 2.0 and OpenID are ways that 3rd party applications can support user authentication without maintaining a robust identity directory and the identity life-cycle processes that come with it. It is commonplace today to bump into offers to use your Facebook, Google, Twitter, or github credentials on a 3rd party app or site.

That equation, an identity provider being used by a third-party client application requires a certain level of trust between all three parties involved: provider, 3rd party, and end user. The vulnerability uncovered by W.Jing shows how an attacker can exploit weaknesses in provider infrastructure and 3rd party applications to cause those 3rd party applications to untintentionally act as a bridge between the provider and the attacker.

Some days it seems like input validation is the solution to almost every software security issue…*
More effective validation of inputs by third party application developers and the providers could deliver significant resistance to attackers. White lists of trusted sources as well as more thorough verification procedures at the providers could materially tamp down the risks associated with this class of vulnerabilities. The white list approach would require a level of accuracy and maintenance that it seem (at least to this author) like it will not happen without external incentives being imposed.

This vulnerability is especially notable because:

  • It enables Open Redirect Attacks
  • It enables unauthorized access / identity fraud
  • It could lead to sensitive information leakage and/or customer information breaches
  • It has wide coverage: most of the major internet companies provide these types of authentication/authorization services — and some Financial Services organizations would like to offer these options as well, especially in (but not limited to) the moble device environment.
  • It is difficult to “patch”

Some in the security community are playing down the potential impacts of this class of vulnerabilities based on their assertion that “most of the websites using OAuth 2.0 and OpenID are social in nature,” or that the complexity of exploit means that the “majority of criminals won’t bother with it.” If you are in financial services and are using OAuth 2.0 and/or OpenID, think carefully through that logic in the context of your brand.

If you use any of those “sign in with my _____ ID” offerings, it seems rational for you to do some research to see if all the identity & authorization service providers involved are resistant to this new class of attack.

Some of the biggest identity-providers on earth are vulnerable to this new class of attack, including, but not limited to: facebook.com, google.com, linkedin.com, yahoo.com, live.com (Microsoft), vk.com, qq.com (Tencent), weibo.com (Sina), paypal.com, mail.ru, taobao.com (Alibaba), sina.com.cn (Sina), sohu.com, 163.com, github.com, alipay.com (Alibaba), and more.

For those of you who need to see the technical details, W.Jing has blog entries and youtube videos detailing proof of concept attacks against each of the properties identified above on his blog at: http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html#portfolio

* But not everyday…

REFERENCES:
“Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID.”
By WANG Jing, May 2014.
http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

“OAuth and OpenID Vulnerable to Covert Redirect, But Have No Vulnerability.”
By Anthony M. Freed, 05-04-2014
http://www.tripwire.com/state-of-security/top-security-stories/oauth-and-openid-vulnerable-to-covert-redirect-but-have-no-vulnerability/

“Security Flaw Found In OAuth 2.0 And OpenID; Third-Party Authentication At Risk.”
By Tim Wilson, 05-04-2014
http://www.darkreading.com/security-flaw-found-in-oauth-20-and-openid-third-party-authentication-at-risk/

 


Open Source CMS in Financial Services?

January 11, 2014

I ran a a small personal blog on Drupal for a number of years. Drupal can dramatically simplify some categories of web content management compared to competing technology options.

A quick job search this evening for financial services openings involving Drupal in New York suggests a range of banking, finance, investments, and insurance organizations use this stack today.

Drupal is an open source content management platform powering millions of websites and applications. It is built, used, and supported by an active and diverse community of people around the world. It is written in PHP that uses a MySQL database, and supports a range of other emerging web technologies.

One reason I drifted off my Drupal platform involved the level of effort required to keep it updated and patched as new security vulnerabilities and exploits were published.

Drupal has a well-established record of moderately-critical and critical security vulnerabilities. This is not necessarily a bad thing. There is an active Drupal security team using relatively-well documented processes (https://drupal.org/security-team and https://drupal.org/node/1424708) in the context of an exemplary level of transparency.

In 2013 there were 3 major collections of remotely-exploitable critical & highly-critical vulnerabilities in the Drupal core, as well as 97 (mostly) remotely exploitable vulnerabilities in Drupal extensions.

Implications:

  1. Running a Financial Services web site on Drupal with a range of typical features & integrations involves the same range of risk management obligations as with any other technology stack. As a result, security needs to be built into your software development lifecycle end-to-end — from requirements-gathering & architecture, through configuration, deployment & operations, and every step in between.
  2. We need to develop & document a set of core company-standard coding conventions & formal standards that attempt to incorporate exploit resistance and attack-awareness, along with security-centric logging/alerting/alarming/reporting practices throughout all Drupal-hosted application content (code, templates, configurations, CSS, etc.). If your organization does not support PHP development today, Drupal will drive you to PHP support. Building out a secure coding practice for a programming language without legacy support in your organization will require a non-trivial investment. The Drupal security team maintains code-level security guidance at: https://drupal.org/writing-secure-code, which should help boot strap company-specific efforts which should be enthusiastically-integrated into all code/configuration activities.
  3. We need to use careful, thoughtful, skeptical and paranoid security code reviews of all ‘code’ & configuration changes prior to deployment.
    Organizations should also invest in a regular service of centralized security code analysis, along with security assessments in a deployed context, and ‘certification’ of Drupal modules — permitting only ‘certified’ or approved modules in production and pilot environments. This type of review does not guarantee risk-free operations, but would help to demonstrate Financial Services-grade due diligence and help to deliver a certain degree of safety in the module code. Some static security code analysis SaaS vendors support PHP to help your staffing challenges here.
  4. We need to have enough trained technical and leadership personnel on deck at all times in order to react efficiently & effectively to security advisories or exploit announcements that require relatively-immediate site and/or code changes.
  5. Finally, revisit the first recommendation above again and follow-through across your entire SDLC. That said we also need to invest in ongoing platform penetration testing & web application vulnerability assessments in order to ensure that we are not exposed to a known or not-yet-announced vulnerability. Again, SaaS support opportunities abound in the dynamic application testing. ‘App pen testing’ is not the solution to your web application needs, it is only one facet of a multi-dimensional full life-cycle approach that is critically-important.

REFERENCES

Security Advisories – Drupal Core
https://drupal.org/security
Security Advisories – Contributed Projects
https://drupal.org/security/contrib
Security Advisories – Public Service Announcements
https://drupal.org/security/psa

“Security Issues in Drupal Content Management System.” (2013)
http://www.examiner.com/article/security-issues-drupal-content-management-system

The 10 most critical Drupal security risks. (2012)
http://www.cameronandwilding.com/blog/pablo/10-most-critical-drupal-security-risks

CVE Drupal Vulnerability Statistics:
http://www.cvedetails.com/vendor/1367/Drupal.html
CVE Drupal Vulnerability Details:
http://www.cvedetails.com/vulnerability-list/vendor_id-1367/product_id-2387/Drupal-Drupal.html

Drupal Administration Guide — Securing your Site
https://drupal.org/security/secure-configuration

Drupal Writing secure code. Last updated September 12, 2013
https://drupal.org/writing-secure-code

“Drupal Security Best Practices — A Guide for Governments and Nonprofits.”
By OpenConcept Consulting Inc. for Public Safety Canada
Principal Author: Mike Gifford, with a collection of contributors
http://openconcept.ca/drupal-security-guide

Public Example: Drupal Security at University of Pennsylvania
Drupal Security Considerations
https://www.sas.upenn.edu/computing/infosec_drupal
Drupal Secure Configuration
https://www.sas.upenn.edu/computing/drupal-security
Drupal Approved Modules
https://www.sas.upenn.edu/computing/drupal-approved-modules

“Mad Irish . net — Open source software security.”
http://www.madirish.net/tag/drupal


Updated Resource For Application Security – BSIMM-V

October 30, 2013

Gary McGraw, Cigital CTO, just began an enthusiastic program promoting the newest version of the Building Security In Maturity Model (BSIMM-V).

BSIMM is an observation-based measuring stick for software security.  67 firms are involved in the BSIMM community.  If your organization is not involved, you can join and compare your maturity against these 67 firms (and against your peers), along 111 software development activities.

There is no reason for me to summarize the excellent announcement at “Software [In]Security: BSIMM-V Does a Number on Secure Software Dev.”  Read it.  Review BSIMM-5.  And think about “what next” for you.

Financial Services enterprises have obligations to demonstrate a level of due diligence that disallows “auto-pilot” software security.  BSIMM-V is an excellent resource to begin building security into your applications, or to measure and enhance your efforts already underway.

REFERENCES:

Software [In]Security: BSIMM-V Does a Number on Secure Software Dev.
http://searchsecurity.techtarget.com/feature/Software-Insecurity-BSIMM-V-does-a-number-on-secure-software-dev

Build Security In Maturity Model.
http://bsimm.com/

BSIMM On-Line
http://bsimm.com/online/

BSIMM4 measures and advances secure application development.
http://searchsecurity.techtarget.com/feature/BSIMM4-measures-and-advances-secure-application-development


Standard Application Attack Vectors Still Viable – Injection and Access Control Vulnerabilities

September 2, 2013

Arul Kumar, a 21 year old electronics & communication engineer from Tamil Nadu, India, recently discovered a critical bug in Facebook that permits the attacker to delete any photo from Facebook without user interaction.

Initially, the Facebook security staff was unable to verify this vulnerability.  After sending them a video recording of his proof of concept, the Facebook team acknowledged his finding.  In that Video Mr. Kumar exploited Mark Zuckerberg’s account, creating a deletion request link for one of Mr. Zukerberg’s photos.

So, what use is this example to the Financial Services technical community?

Mr. Kumar took advantage of a commonly-identified vulnerability in web and mobile applications.  He manually modified two parameters upon which Facebook servers would take critical actions. This particular injection attack modified Facebook’s ‘Photo_id‘ & ‘Profile_id‘ parameters.

Apparently, Facebook applications simply trusted these inputs from what were clearly untrustworthy endpoints.

Remember, applications must never trust user input.  Developers can remember this using the phrase “all input is evil.”  User input needs some level of sanity-checking — generally called input validation.  The Open Web Application Security Project (OWASP) Top 10 refers to this as its #1 vulnerability — ‘Injection’ at https://www.owasp.org/index.php/Top_10_2013-A1-Injection.

Because this attack also allowed an attacker to perform the deletion of other’s content, Facebook access controls were also vulnerable to abuse. This vulnerability and approaches to dealing with is are also outlined in OWASP #7, https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control.

All Financial Services applications, even those shiny new mobile apps need to safety-check user input.  Applications also need to verify that access to functionality is granted only to those to whom it has been explicitly granted.

This work is a clear candidate for integration into your application security program.  Use it to show how creative individuals are able to exploit any and all input & access control vulnerabilities in your applications.  Any Financial Security organization could ignore such well organized and clearly stated work at their peril.

I also strongly recommend using OWASP resources.  They are free and easy to understand.  They include mature high level guidance as well as help for designers and developers.

REFERENCES:

“Delete any Photo from Facebook by Exploiting Support Dashboard.” by Arul Kumar
http://arulxtronix.blogspot.in/2013/09/delete-any-photo-from-facebook-by.html

Open Web Application Security Project (OWASP) Top 10
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Top 10 2013-A1-Injection
https://www.owasp.org/index.php/Top_10_2013-A1-Injection

Top 10 2013-A7-Missing Function Level Access Control
https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control


%d bloggers like this: