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.

Advertisements

Verizon Says Passwords are Not Enough

April 25, 2016

Lately, I’ve been spending a lot of time performing static code security assessments of web applications. That leads to working with developers and those who work around them. One thing many of them share with me is their faith in authentication infrastructure — infrastructure that generally sits “in front” of their applications and protects them from unauthorized users. Sometimes I still hear Architects talk about “security” as if it were really just authentication… In that context, the latest Verizon Data Breach Investigations Report (DBIR) reviews their 2016 dataset of over 100,000 incidents, including 2,260 confirmed data breaches across 82 countries.

The full paper is worth a read, but in the context of my comments above I wanted to highlight Verizon’s recommendations concerning passwords:

“…passwords are great, kind of like salt. Wonderful as an addition to something else, but you wouldn’t consume it on its own.”

“63% of confirmed data breaches involved weak, default or stolen passwords.”

The top 6 breaches included the following steps: “phish customer > C2 > Drop Keylogger > Export captured data > Use stolen credentials”

Recommendaton:
“If you are securing a web application, don’t base the integrity of authentication on the assumption that your customers won’t get owned with keylogging malware. They do and will.”

REFERENCES:
Verizon Data Breach Investigations Report (DBIR)
http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/insiders/

 


Mac Boot Hacked via Thunderbolt Port

January 14, 2015

Too many of us still have to deal with members of our workforce who hold groundless beliefs about the freedom from risk they enjoy while using their Macs.

Trammell Hudson described his most recent project at the last Chaos Communication Congress in Germany. It is called Thunderstrike and it can infect any modern Mac boot ROM via the Thunderbolt port — ultimately giving the attacker control of the endpoint. This “evil maid” attack gives us all another reason for concern. Anyone with physical access to a worker’s Mac could use this technique (or one of its predecessors) as a foothold into your network, as well as gaining “direct” access into any operations to which that user has been permitted. Traveling executives seem like obvious targets, but virtually any member of the workforce is a candidate.

Mr. Hudson describes the impact of his attack as:

“There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction. It could use SMM, virtualization and other techniques to hide from attempts to detect it.

Our proof of concept bootkit also replaces Apple’s public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker’s private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the hard drive has no effect.”

At a minimum, this should be used as input for traveler’s security awareness training.

It should also be injected into risk analyses of all BYOD scenarios.

REFERENCES
“Thunderstrike.” By Trammell Hudson.
https://trmm.net/EFI

“De Mysteriis Dom Jobsivs: Mac EFI Rootkits.” By Snare (Blackhat 2012)
http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Slides.pdf

“Apple’s Mac EFI found vulnerable to bootkit attack via rogue Thunderbolt devices.” By Sam Oliver, Dec 22, 2014
http://appleinsider.com/articles/14/12/22/apples-mac-efi-found-vulnerable-to-bootkit-attack-via-rogue-thunderbolt-devices

“Thunderstrike: The scary vulnerability in your Mac’s Thunderbolt port.” By Christina Warren, Jan 02, 2015
http://mashable.com/2015/01/02/thunderstrike-mac/

Macs vulnerable to virtually undetectable virus that “can’t be removed” By Adrian Kingsley-Hughes, Jan 12, 2015
http://www.zdnet.com/article/macs-vulnerable-to-virtually-undetectable-virus-that-cant-be-removed/


Another Reason to Disbelieve The Apple Security Story

September 2, 2014

Some subset of any Financial Services organization’s workforce has BYOD fever.  For many in our business, that fever has infected one or more senior leaders who cannot be ignored.  In Financial Services, we are collectively responsible for protecting $trillions of other people’s assets.

Most of the BYOD fever seems to be associated with new mobile devices.  From what I can observe, many Financial Services organizations are emphasizing their attraction to Apple iPads over Android or other alternatives.  That behavior seems out of phase with our due diligence obligations.

Apple has invested what must be a tremendous amount of resource and effort in building an image that incorporates something like “trust me, but I will not respond to your requests for transparency…”  For some reason, that seems to work.  This is in spite of regular patching of vulnerabilities that could have been discovered at architectural analysis, design, coding, static code security analysis, QA or penetration testing.  Apparently those activities do not incorporate effective secure software practices.

The latest example of Apple’s approach to software security made the news over the last weekend.  A vulnerability in iCloud enabled a trivial attack to discover the passwords of a number of targeted individuals.  Those passwords were then used to steal those user’s iCloud “protected” personal files.  Apple did not enforce a “max attempts” threshold for failed attempts to login to iCloud, which permitted attackers to pound away at the URL https://fmipmobile.icloud.com/fmipservice/device/$apple_id/initClient with basic auth attempts using scripts or malware that identified itself as ‘User-Agent’: ‘FindMyiPhone/376 CFNetwork/672.0.8 Darwin/14.0.0’.   An easy-to-understand proof-of-concept application is available on github.

Remember, in Financial Services, implementing some type of failed-login governor has been standard practice since we have been using the Internet for business.  Our constituents expect some type of “n-failed-login-attempts-and-you-are-locked-out.”  They may not consciously think through a detailed rationale, it is just a small but essential part of exhibiting a threshold level of Financial Services due diligence.  I assume that one possible root cause was that Apple engineers and architects must have reasoned that either nobody could format a basic auth HTTP POST with some json payload and sling it at their iCloud web service interface, or they believed that their closed ecosystem and black box approach to security implementations would keep their web service interface from being discovered.  Alternatively, they specified a max-failed-login-attempts feature into iCloud designs, but Apple management directed them to remove it based on non-technical rationale.  There could be other root causes of this vulnerability, but with the resources available to Apple, none seem in alignment with their “trust us” story-telling.  Their iCloud authentication implementation was just not fit for Financial Services workforce operating environments — while they have been arguing that “”iCloud is built with industry-standard security practices and employs strict policies to protect your data.”

Brute forcing passwords is a proven, decades-old practice that is highly effective unless resisted (because people, in large numbers, behave so predictably).  Financial Services-grade businesses understand this and implement and enforce policies that generally resist bald, brute force attacks.  It is a small, simple, basic, and essential characteristic of any Internet-ready system hosting non-public resources.  The fact that Apple implemented an Internet-facing authentication interface without resistance to brute force password attack, then failed to implement defense in depth (i.e., instrument the environment with effective IDS/IPS, identity fraud detection, and more) demonstrates — again — their unfitness for the Financial Services workforce environment.

Update 09-03-2014:

Could it be that Apple considers hackappcom’s proof of concept application and demonstrations of its use just another side-show?  They reacted to news about the celebrity data theft using what I read as legalistic and deflecting language:

“None of the cases we have investigated has resulted from any breach in any of Apple’s systems,” Nat Kerris, a company spokeswoman, said in a statement. “We are continuing to work with law enforcement to help identify the criminals involved.”

Update 09-06-2014:

Apple, via CEO Tim Cook continued the Apple ecosystem and its technology are safe theme, blaming users for the recent iCloud vulnerabilities and their exploit, saying in a WSJ interview that Apple would ratchet up user awareness communications about stronger and safer passwords, and apparently will not be investing in more effective engineering:

“When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he said. “I think we have a responsibility to ratchet that up. That’s not really an engineering thing.”

Mr. Cook also said that Apple would would begin sending users email messages and push notifications when certain AppleID events occur or when a user’s account data lands on a new device.

After a 40-hour investigation “concluded that there was no breach of its data servers. The company has said it discovered a number of celebrity accounts were compromised by targeted attacks…”

Sure.  Not ready for Financial Services.

 

REFERENCES:

“Hacker leaks dozens of nude celebrity pics in alleged iCloud hack.”
By Cody Lee, Aug 31, 2014
http://www.idownloadblog.com/2014/08/31/icloud-celeb-nude-pics-hack/

“Apple reportedly patches Find My iPhone vulnerability to hack Apple ID accounts.” By Christian Zibreg, Sep 1, 2014
http://www.idownloadblog.com/2014/09/01/icloud-hacking-patched-find-my-iphone/

“ibrute.” By hackappcom
https://github.com/hackappcom/ibrute

“Apple patches ‘Find My iPhone’ exploit.” By Adrian Kingsley-Hughes, Sep 1, 2014
http://www.zdnet.com/apple-patches-find-my-iphone-exploit-7000033171/

“iCloud: iCloud security and privacy overview.”
http://support.apple.com/kb/HT4865

“iCloud Keychain.”
http://www.slideshare.net/alexeytroshichev/icloud-keychain-38565363

“Privacy Collides With the Wild Web.” By Mike Isaac, Sep 2, 2014
http://mobile.nytimes.com/2014/09/03/technology/trove-of-nude-photos-sparks-debate-over-online-behavior.html?_r=0 (downloaded Wed 09/03/2014 5:46 AM)

“Apple Says It Will Add New iCloud Security Measures After Celebrity Hack.” By Brian X. Chen, Sep 4, 2014 http://mobile.nytimes.com/blogs/bits/2014/09/04/apple-says-it-will-add-new-security-measures-after-celebrity-hack/

“Tim Cook Says Apple to Add Security Alerts for iCloud Users — Apple CEO Denies a Lax Attitude Toward Security Allowed Hackers to Post Nude Photos of Celebrities.” By Daisuke Wakabayashi, Sep 5, 2014 http://online.wsj.com/news/article_email/tim-cook-says-apple-to-add-security-alerts-for-icloud-users-1409880977-lMyQjAxMTA0MDAwNDEwNDQyWj

“Apple Media Advisory: Update to Celebrity Photo Investigation.” http://www.apple.com/pr/library/2014/09/02Apple-Media-Advisory.html (downloaded Sat 09/06/2014 5:56 PM)


Another Remote Access-Enabled Breach

August 20, 2014

The same tools that help our workforce remain productive when outside their brick-and-mortar place of business are being exploited by cyber-criminals to break into business’s computer networks (I wrote about one facet of this issue late last week). Today we learned that this led to the theft of customer credit and debit data at 51 UPS franchises in the United States. Recently we read about it being used to hack into retailers like Target and Neiman Marcus.

In a recent report the Homeland Security Department warned that hackers are scanning Internet-accessible systems for remote access software. They appear to be omnivores, targeting platforms made by Apple, Google, LogMeIn, Microsoft, Pulseway, and Splashtop that help remote workers to access business computer networks over an Internet connection.

When the hostile actors identify targeted remote access software, they install malware and then have means to effectively ‘guess’ login credentials — or in some situations, the endpoint hosts unauthenticated remote access, requiring no password at all. Once the hostile actors acquire a foothold, they have a difficult-to-detect entry point into business networks.

Under any circumstances this is a problem, but for endpoints used by members of the workforce having elevated rights — consider database analysts, finance administrators or executives, investment pipeline or their back office settlement personnel, top-tier executives, and more (for most financial services enterprises the list goes on and on) — the potential for material harm is real and present.

In that context experts recommend:

Remote Desktop Access

  • Configure the account lockout settings to lock a user account after a period of time or a specified number of failed login attempts. This helps to resist unlimited unauthorized attempts to login whether from an unauthorized user or via automated attack types like brute force.
  • Limit the number of users and workstation who can log in using Remote Desktop. Perform risk assessments to help determine access.
  • Use firewalls (both software and hardware where available) to restrict access to remote desktop product/service listening ports (TCP 3389 et.al.).
  • Change the default ‘remote desktop’ listening port(s).
  • Define complex password parameters. Configuring an expiration time and password length and complexity can decrease the amount of time in which a successful attack can occur.
  • Require strong two-factor authentication (2FA) for remote desktop access.
  • Install and professionally-manage a ‘remote desktop’ gateway to restrict access.
  • Add an extra layer of authentication and encryption by tunneling your remote desktop through enterprise-managed IPSec, SSH or SSL.
  • Require strong two-factor authentication when accessing sensitive networks. Even if a virtual private network is used, it is important that strong two-factor authentication is implemented to help mitigate the risks associated with keylogger or credential dumping attacks.
  • Severely limit administrative privileges for remote users and applications.
  • Periodically review systems (local and domain controllers, and the rest of your directories) for unknown and dormant users.

Network Security

  • Review firewall configurations and ensure that only allowed ports, services and Internet protocol (IP) addresses are communicating with your network. This is especially critical for outbound (e.g., egress) firewall rules in which compromised entities allow ports to communicate to any IP address on the Internet. Hostile actors leverage this configuration to exfiltrate data to their IP addresses.
  • Segregate sensitive network segments from other networks.
  • Apply access control lists (ACLs) and other traffic verification technology on router configurations to help enforce defense in depth used to limit unauthorized traffic to sensitive network segments.
  • Create strict firewall rules and ACLs segmenting public-facing systems and back-end database (or other) systems that house sensitive non-public data.
  • Implement data leakage prevention/detection tools to detect and help prevent data exfiltration.
  • Implement tools to detect anomalous network traffic and anomalous behavior by legitimate users (compromised credentials).
  • Actively monitor, respond to, and follow through on security alerts.

REFERENCES:

“Checking In From Home Leaves Entry for Hackers.” By Nicole Perlroth, 07-31-2014. http://www.nytimes.com/2014/07/31/technology/checking-in-from-home-leaves-entry-for-hackers.html?_r=0

“Alert (TA14-212A) — Backoff Point-of-Sale Malware.” 07-31-2014 & Last revised on 08-18-2014 https://www.us-cert.gov/ncas/alerts/TA14-212A

“United Parcel Service Confirms Security Breach.” By Nicole Perlroth, 08-20-2014. http://mobile.nytimes.com/blogs/bits/2014/08/20/ups-investigating-possible-security-breach/

“Another BYOD Security Challenge – User-Managed Remote Access Software.” https://completosec.wordpress.com/2014/08/16/another-byod-security-challenge-user-managed-remote-access-software/

“Another BYOD Security Challenge — User-Managed Remote Access Software.” https://completosec.wordpress.com/2014/08/16/another-byod-security-challenge-user-managed-remote-access-software/

“Keylogger Revealed in the Apple iOS Ecosystem.” https://completosec.wordpress.com/2014/02/25/keylogger-revealed-in-the-apple-ecosystem/

“BYOD = Bring Your Own Demise?” https://completosec.wordpress.com/2013/06/22/byod-bring-your-own-demise/

“Another Reason to Resist BYOD Using Consumer Mobile Devices.” https://completosec.wordpress.com/2013/07/04/another-reason-to-resist-byod-using-consumer-mobile-devices/


Another BYOD Security Challenge – User-Managed Remote Access Software

August 16, 2014

In a recent Defcon presentation three researchers demonstrated that scanning the Internet — the entire Internet — is now a practical exercise.  That idea alone should force us all to re-frame our thinking about how we measure the effectiveness of our infrastructure’s defensive posture — but that is not a topic for this post.  As part of their work, the team demonstrated the scale of unauthenticated remote access set up on business and personal endpoints accessible from the Internet.  As families acquire more and more Internet endpoints, it appears that some in each household want to access or manage some of them remotely.  This might be as simple as accessing the “office Mac” from an tablet on the couch, or as crazy as unauthenticated remote access to that home office endpoint while traveling.  The use case doesn’t matter as much as the behavior itself.  If people are setting up unauthenticated remote access (or using default or ‘easily-guessable’ passwords) on the endpoints they also want to bring to work, we all have a problem…

Regardless of how ill-conceived, BYOD experiments, even formal BYOD programs seem to be a fever without a cure.  When a financial services workforce uses non-company endpoints we inherit all the risks associated with their all-too-often unprofessional and uninformed management practices.  Now we have evidence that one facet of that behavior is the installation and use of unauthenticated remote access software.  There are a number of popular approaches.  The Defcon presentation appears to have focused on VNC (virtual network computing), but there are other popular packages used to support convenient remote access – Wikipedia lists dozens.

We need to train our workforce that they need to limit their exposure (and the organization’s via BYOD) to the risks associated with remote access software. At the very highest level, they need to understand that for any endpoint used for financial services work:

  1. Don’t run software (whatever it is) that is not really needed
  2. If your really need it, learn how to manage it and configure it to deliver only the features you need — in the context of end user-managed BYOD environments, running software you don’t understand is not risk-reasonable in the context of performing financial services business (our regulators require and our customers and partners expect that we perform our business activities using risk management practices stronger than simple ‘hope’
  3. If you need remote access exercise the principle of least privilege
    1. Install and configure the software so that by default it is not turned on (if it is not running it will not support unintended remote access)
    2. Turn on your remote access software only when you need it, and then turn it off again as soon as is practical afterword
    3. Configure the remote access software to include a risk-reasonably short session timeout
    4. Permit only uniquely-authenticated users having a strong, unique, time-limited password
  4. Restrict remote access to your endpoint as much as possible
  5. Turn off all remote access you can get away with
  6. Use multiple layers of protection to implement defense in depth
    1. Run an endpoint firewall configured to reject all inbound communications attempts except those you explicitly authorize
    2. Don’t grant apps permissions that you don’t understand
    3. Don’t grant apps permissions that would enable access to business data or business communications
    4. Run one or more anti-malware packages
    5. Use security-centric web proxies
    6. Configure your browser(s) in their most paranoid settings
    7. Turn on your search engine’s ‘recommendation’ or anti-hostility service
    8. If your operating system supports it, perform your work in the absence of administrative rights (don’t make yourself equivalent to root or the local administrator)

In addition to end user education, and before permitting even the most limited BYOD experiment, financial services enterprises should have their infrastructure configured to resist the use of virtually all known remote access software on those non-company devices.  The port-blocking and protocol recognition will not be perfect, but it will stop the unauthorized use of the most casual installations.  As a result, we also need to have our SIEM infrastructure configured to alert and then staff to deal with those alerts.  In addition, and using the same signature and/or correlation logic configured in the SIEM, those with widespread IPS infrastructure can block BYOD remote access attempts (at least in some scenarios).

All of the security measures required to deal with BYOD fever will add expense that needs to be introduced into the BYOD economic equation.  All of the new risks also need to be introduced into the overall enterprise risk management pool.  The impacts will be different for various organizations.  For some, it seems reasonable to assume that the new costs and risks will far exceed any real benefits that could possibly be delivered in a financial services enterprise environment. 

REFERENCES:

“Thousands of computers open to eavesdropping and hijacking.” By Lisa Vaas on August 15, 2014, http://nakedsecurity.sophos.com/2014/08/15/thousands-of-computers-open-to-eavesdropping-and-hijacking/

“Mass Scanning the Internet: Tips, Tricks, Results.” By Robert Graham, Paul McMillan, & Dan Tentler, https://www.defcon.org/html/defcon-22/dc-22-speakers.html#Graham 

“Comparison of remote desktop software.” From Wikipedia, http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software

“Principle of Least Privilege.” From Wikipedia, http://en.wikipedia.org/wiki/Principle_of_least_privilege

“Defense in depth.” From Wikipedia,
http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29


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/

 


%d bloggers like this: