Protect Location Data

January 15, 2019

Location tracking is sensitive business — one loaded with real and perceived risks and injustices.  There are global financial services business use cases where location data can be used to help resist fraud — for example: ‘is the customer present for the requested financial transaction?‘  Do so only with explicit customer consent.

Mobile phones constantly communicate with nearby cell phone towers to help telecom providers know where to route given calls and texts. From this, telecom companies also work out the phone’s approximate location.

Telecom companies doing business in the United States sell access to their customers’ location data, primarily to location aggregators. These data aggregators then sell it to others. Despite what carriers want us to believe, location data is not tightly controlled or carefully regulated. It is not.

Telecoms preach that they protect customer data and that location-based services require user’s notice and consent. That is not their behavior.

Carefully vet the use of location data services in your organizations and then carefully limit access to the resulting data.  In the long run, to do otherwise is a needless risk of brand damage.

Joseph Cox wrote an article on this topic published last week on MotherBoard.  It is worth reviewing to better understand how location services can be misused.

If you already employ these services — review your practices.

REFERENCES:
I Gave a Bounty Hunter $300. Then He Located Our Phone.” by Joseph Cox
https://motherboard.vice.com/en_us/article/nepxbz/i-gave-a-bounty-hunter-300-dollars-located-phone-microbilt-zumigo-tmobile

Advertisements

Some Upgrades Are Not Optional – Engineer Them For The Reality of Your Operations

December 5, 2018

Kubernetes enables complexity at scale across cloud-enabled infrastructure.

Like any other software, it also is — from time to time — vulnerable to attack.

A couple days ago I initially read about a CVSS v3.0 ‘9.8’ (critical) Kubernetes vulnerability:

“In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection.”

The default configuration for a Kubernetes API server’s Transport Layer Security (TLS) credentials grants all users (authenticated and unauthenticated) permission to perform discovery API calls that result in this escalation.  As a result, in too many implementations, anyone who knows about this hole can take command of a targeted Kubernetes cluster. Game over.

Red Hat is quoted as describing the situation as: “The privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes pod. This is a big deal. Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall.”

This level of criticality is a reminder about how important it is to engineer-in the ability to perform on-demand Kubernetes infrastructure upgrades during normal business operations. In situations like the one described above, these upgrades must occur without material impact on business operations.  In real business infrastructure that is a serious engineering challenge.

Today is not the day to be asking “how will we upgrade all this infrastructure plumbing in real-time, under real business loads?”

The recent Kubernetes vulnerability is a reminder about how complex is the attack surface of every global financial services enterprise. With that complexity, comes a material obligations to understand your implementations and their operations under expected conditions — one of which is the occasional critical vulnerability that must be fixed immediately.

Oh joy.

REFERENCES:
Kubernetes Security Announcement – v1.10.11, v1.11.5, v1.12.3 released to address CVE-2018-1002105
https://groups.google.com/forum/#!topic/kubernetes-announce/GVllWCg6L88
CVE-2018-1002105 Detail
https://nvd.nist.gov/vuln/detail/CVE-2018-1002105
Kubernetes’ first major security hole discovered
https://www.zdnet.com/article/kubernetes-first-major-security-hole-discovered/
CVE-2018-1002105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1002105


Oval Office Credential Theft is a Warning to All

October 13, 2018

IT architects cry foul about what they perceive as authentication fatigue…  “Security makes users login too many times and this must stop!”
It seems like investments attempting to reduce the number redundant workforce authentications are not often justified using the language of risk management. If they were, we might find identity technology evolving in new ways.

In a recent oval office press event, Kanye West inadvertently exposed his iPhone passcode to a crowd of news cameras. As a result, earth knows his six-digit passcode is an unbroken series of zeros “000000.” …not something too business-relevant, except that it is an example of a class of credential leakage that is already an issue for global financial services enterprises.

With increasing frequency, our increasingly mobile workforce enters passwords in the presence of live cameras. We should not assume that all the resulting recordings are secured in ways that match our obligation to keep business user name/password pairs confidential. Because credentials can be relatively easily monetized, a percentage of these recorded credentials are and will be used in unauthorized ways. The only variables are which credentials, at what time(s), and by whom.

We should assume that this scenario will become increasingly common for all workforce roles who are mobile-enabled.

Do you support your database, server, identity directory, or cloud admins, your financial officers, your investment or human resource professionals, your legal council, any other roles with elevated rights to work where they choose? If yes, tick your risk-pool meter up again. Assign someone to investigate and report on how vulnerable your organization is to unauthorized credential re-use. Large, global financial services enterprises have complex attack surfaces for this use case. For most, this analysis will not be easy, and will likely not result in a happy story.

Maybe authenticating less often is a part of addressing this risk.  I don’t know.  For some, multi-factor authentication plays a key role in resisting credential theft and reuse.  Some types of multi-factor authentication can resist some types of credential attacks. But “some” should not be a comforting qualifier. Working out the right mix of identity verification is going to require creativity, rigor, and serious risk management analysis — adult, professional, investigation and analysis.

Get started.

REFERENCES:

“The Cybersecurity 202: Kanye West is going to make password security great again.”
By Derek Hawkins, October 12, 2018
https://www.washingtonpost.com/news/powerpost/paloma/the-cybersecurity-202/2018/10/12/the-cybersecurity-202-kanye-west-is-going-to-make-password-security-great-again/


Facebook Identity Token Thefts Result in Breach

September 28, 2018

Facebook’s VP of Product Management, Guy Rosen said today that a vulnerability in the company’s  “View As” feature that enabled attackers to steal to user’s access tokens.  These tokens are presented to Facebook infrastructure in ways that allow users to remain authenticated and able to interact with their accounts over multiple sessions. Once in an attacker’s possession, these tokens would permit attackers to impersonate actual users and enable Facebook accounts takeover.  Facebook’s reported that the current risk mitigation is their invalidating at least 40 million authentication tokens and temporarily turning off the “View As” feature while they “conduct a thorough security review.”  He went on:

“This attack exploited the complex interaction of multiple issues in our code. It stemmed from a change we made to our video uploading feature in July 2017, which impacted “View As.” The attackers not only needed to find this vulnerability and use it to get an access token, they then had to pivot from that account to others to steal more tokens.”

Mr. Rosen wrote that Facebook engineers learned of this vulnerability three days ago on Tuesday, September 25 and that almost 50 million Facebook accounts were affected.

Writing safe-enough user-facing software that must interact with a complex ecosystem of applications and APIs is a serious challenge for all of us.  In that context, this latest Facebook vulnerability should be a cautionary tale for all organizations implementing apps and APIs incorporating persistent token-based authentication.  Could any of us market our way out of a situation where 40 or 50 million of customers, marketers, and other partners were vulnerable to account takeover?

Too many architects and developers seem risk-inappropriately infatuated by pundit pronouncements about authentication fatigue and the “best practice” of extending any given authentication across multiple sessions using persistent tokens.  At our scale (a trillion dollars U.S. AUM each, give or take a few hundred billion), global financial services enterprises ought to be able to reason our way through the fog of happy-path chatter to engineer session management practices that meet the risk appetites of our various constituencies.

REFERENCES:

“Security Update.” By Guy Rosen, VP of Product Management
Security Update

 

 


MacOS Firewall Bypass Demos

August 9, 2018

“You’re are not going to buy a car and expect it to fly?” Patrick Wardle, Chief Research Officer at Digita Security and founder of Objective-See, describing why he presented some of his research on MacOS firewall bypasses.

That sort of makes sense.  Nobody buys a Mac and expects it to resist attack?

In any case, we all have members of our workforce using Macs for non-trivial business operations.  We need to clearly understand the attack surface and Mac’s resistance to attack.  P.Wardle provides a little help on that exercise in his BlackHat presentation: “Fire & Ice: Making and Breaking macOS Firewalls.”

Tom Spring has a useful summary of the presentation on ThreatPost: “Black Hat 2018: Patrick Wardle on Breaking and Bypassing MacOS Firewalls.”  It is worth a read.  There is no reason for me to echo its content here.

REFERENCES:

“Fire & Ice: Making and Breaking macOS Firewalls”
https://www.blackhat.com/us-18/briefings.html#fire-and-ice-making-and-breaking-macos-firewalls

“Black Hat 2018: Patrick Wardle on Breaking and Bypassing MacOS Firewalls” By Tom Spring
https://threatpost.com/patrick-wardle-breaks-and-bypasses-macos-firewalls/134784/


Cloud File Sync Requires New Data Theft Protections

June 28, 2018

Microsoft Azure File Sync has been slowly evolving since it was released last year.
https://azure.microsoft.com/en-us/blog/announcing-the-public-preview-for-azure-file-sync/ and
https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=portal and https://azure.microsoft.com/en-us/roadmap/azure-file-sync/

The company also added “Azure:” [Azure Drive] to PowerShell to support discovery and navigation of all Azure resources including filesystems.
https://blogs.msdn.microsoft.com/powershell/2017/10/19/navigate-azure-resources-just-like-a-file-system/

Azure File Sync helps users keep Azure File shares in sync with their Windows Servers. Microsoft promotes the happy-path, where these servers are on-premise in your enterprise, but supports syncing with endpoints of any trust relationship.

What are my concerns?

The combination makes it much easier to discover Azure-hosted data and data exfiltration paths and then to get them set up to automatically ship new data into or out of your intended environment(s).  In other words, helping hostile parties to introduce their data or their malware into your organization’s Azure-hosted file systems, or helping hostile parties to steal your data while leaving a minimum of evidence describing who did what.

Why would I say that?

Many roles across global Financial Services enterprises are engaging in architecture risk analysis (ARA) as part of their day to day activities.  If we approach this topic like we were engaged in ARA fact finding, we might discover the following:

Too easy to share with untrustworthy endpoints:
It appears that anyone with the appropriate key (a string) can access a given Azure File Share from any Azure VM on any subscription. What could go wrong?
Microsoft customers can use shared access signatures (SAS) to generate tokens that have specific permissions, and which are valid for a specified time interval. These shared access signature keys are supported by the Azure Files (and File Sync) REST API and the client libraries.
A financial services approach might permit Azure File drive Shares on a given private Virtual Network to be secured in a manner so it would be only available via the Virtual Network using a private IP address on that same network.
https://feedback.azure.com/forums/217298-storage/suggestions/5993281-azure-files-on-a-virtual-network

Weak audit trail:
If you need to mount the Azure file share over SMB, you currently must use the storage account keys assigned to the underlying Azure File Storage.
As a result, in the Azure logs and file properties the user name for connecting to a given Azure File share is the storage account name regardless of who is using the storage account keys. If multiple users connect, they have to share an account. This seems to make effective auditing problematic.  It also seems to violate a broad range of commitments we all make to regulators, customers, and other constituencies.
https://feedback.azure.com/forums/217298-storage/suggestions/33477253-keep-track-of-the-file-owner
This limitation may be changing. Last month Microsoft announced a preview of more identity and authorization options for interacting with Azure storage. Time will tell.
https://docs.microsoft.com/en-us/rest/api/storageservices/Authorization-for-the-Azure-Storage-Services and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Missing link(s) to Active Directory:
Azure Files does not support Active Directory directly, so those sync’d shares don’t enforce your AD ACLs.
Azure File Sync preserves and replicates all discretionary ACLs, or DACLs, (whether Active Directory-based or local) to all server endpoints to which it syncs. Because those Windows Server instances can already authenticate with Active Directory, Microsoft sells Azure File Sync as safe-enough (…to address that happy path).  Unfortunately, Azure File Sync will synchronize files with untrusted servers — where all those controls can be ignored or circumvented.
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-faq#security-authentication-and-access-control

Requires weakening your hardened endpoints:
Azure File Sync requires that Windows servers host the AzureRM PowerShell module, which currently requires Internet Explorer to be installed. …Hardened server no more…
https://feedback.azure.com/forums/217298-storage/suggestions/31909372-add-support-for-server-core-installations-for-azur

Plans for public anonymous access:
Microsoft is planning to support public anonymous read access to files stored on Azure file storage via its REST interface.
https://feedback.azure.com/forums/217298-storage/suggestions/7188650-allow-anonymous-public-access-to-azure-file-storag and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Port 445 (again):
Azure file storage configuration is exposed via TCP port 445. Is it wise to begin opening up port 445 of your Microsoft cloud environment? Given the history of Microsoft vulnerabilities exposed on port 445, many will probably hesitate.
https://feedback.azure.com/forums/217298-storage/suggestions/15001032-allow-access-to-file-storage-configuration-to-use

Goal of hosting Windows File Server in Azure:
Microsoft intends to deliver Azure Files in a manner that ensures parity with Windows File Server.
https://feedback.azure.com/forums/217298-storage/suggestions/19693045-automatically-mount-an-azure-file-share-to-a-windo

What other potential issues or concerns should we investigate?

  • Does the Azure File Storage REST interface resist abuse well enough to support its use in specified use cases (since each use case will have given risks and opportunities)?
  • Can a given use case tolerate risks associated with proposed or planned Microsoft upgrades to Azure File Storage REST, Azure File Sync, or Azure:?
  • Are there impacts on or implications for the way we need to manage our Azure AD?
  • Others?

What do you think?

 


Another Exfiltration Tool

January 30, 2018

It is a challenge to keep up with the free HTTPS-enabled data exfiltration tools available.  As security professionals in global Financial Services enterprise, we have obligations to exhibit risk-reasonable behaviors.  Resisting easy, “invisible” data theft is a core deliverable in our layered security services.

Google is offering a cool “Cloud Shell” that falls into the category I was thinking of when I wrote the paragraph above.  It is a highly-functional Linux shell that is available to anyone with https access to the Internet.  There are lots of good reasons for Google to offer this service.  And they require an active credit card for initial on-boarding — allowing some to argue that there are limits to the anonymity this service might deliver.  There are also lots of global Financial Services enterprise misuse cases.  Quick, easy, difficult-to-understand data exfiltration being the first that came to mind.  Hosting “trustworthy” command and control applications is another.  With Internet access, sudo, and persistent storage the only limitations seem to be the creativity of any given hostile party.

Financial Services brands managing trillions of dollars for others need to protect against the misuse of tooling like this.  The challenge is that some of us use Google Cloud services for one or another subset of our business activities. And in those approved contexts, that represents risk-reasonable behavior.

This situation is just another example of external forces driving our internal priorities in ways that will require a quick response, and will also induce ongoing risk management workload.

So it goes.

REFERENCE:

Google Cloud Shell: https://cloud.google.com/shell/


%d bloggers like this: