Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Application authentication needs a reboot

October 20, 2017

  • Blog
  • Archive

Last week marked an exciting new first – ransomware on a Mac disclosed by Palo Alto who had seen it with a client. What’s simultaneously encouraging and disappointing is that it could have been prevented without detection using highly recommended best practices – application allow listing (yes, it is possible to do allow listing today – we do it with lots of our clients as do other providers).

Just 10 years ago, malware attacks came straight at us as scripts or executables sent on USB devices, through email or linked on websites. We compensated by securing removable devices, filtering email attachments and content and securing web browsers as much as we could without entirely disrupting productivity.

Today, attackers resort to more sophisticated tactics to penetrate applications that are exposed to content coming through the internet. Meta-analysis of today’s malware threats reveals that attacks tend to occur in multiple stages. The first stage often attacks in-memory vulnerabilities of web browsers, browser plugins and the applications that open business documents. The intent of the first stage is often to download and execute a secondary payload – typically a script or executable. This attack pattern is necessary because it’s increasingly difficult to “stay in memory” while performing sophisticated lateral attack or data theft.

So we’re right back at where we were 10 years ago – stopping malware scripts or binaries from running!

Why do we continue to fail at this since it can be stopped quite effectively with an effective application allow listing implementation? Allow listing has been notoriously difficult to operationalize in the enterprise due to the vast range of software in use and continual change. How do we know which applications to trust, and which to stop?

To address this issue of trust, the concept of code-signing certificates was introduced. Microsoft Authenticode is the most prevalent, and Apple has their own. In theory, code signing is intended to prove that the application you’re installing or running came from a provider verified as a real entity accountable for the product. Current cryptographic signatures are impossible to forge.

The provider has a “secret” (a very long complex password AKA a 256 bit cryptographic key) used to sign the application using algorithms everyone knows and can verify using a verification algorithm. It’s ok to know the algorithms because it’s the secret that makes it secure. This is much like applying your royal seal imprint to the wax seal of an envelope in medieval times. It was out of reach to recreate the royal seal then, and today it’s not practical to figure out the key used to sign software. That’s why people steal the code signing certificates instead. If attackers steal a code signing certificate they can make their malware appear as though a valid software vendor produced it. If we trust any signed software, it would be a mistake. If we trust any software signed by our known vendors, it could also be a mistake.

The KeRanger ransomware relied on a stolen certificate to bypass Apple’s Gatekeeper protections. Once discovered, Apple revoked the certificate, which meant it was no longer trusted and the malware would not be allowed to run on Apple OSX. Good thing that this malware wasn’t designed to hide in the background and quietly steal your corporate data, it may not have been discovered so easily! Of course, our malware writing friends can steal another code signing certificate and continue on with the same style of attack.

The problem is that we’re verifying applications based on a single secret. In the security industry, we’re actively looking to replace passwords (something that can be stolen) as the sole means of authenticating users because it’s too easily circumvented. Why are we not thinking the same way about the applications that inherit the privileges of users once they log on?

I love that Microsoft is making strides in security with Windows 10’s Device Guard feature (and others). However, Device Guard is fundamentally based on the premise that code signing certificates and the chain of trust remains secure. I don’t have to circumvent Windows security to bypass Device Guard, I just need to steal someone’s valid code signing certificate and use it. If you’re able to operationalize the full capabilities of Device Guard, it’s unlikely you’ll fall victim. I’ll let you know when I see a client with a fully realized DeviceGuard implementation – great tech, big fan here, though I’m not seeing a practical way to use it in the enterprise just yet. To their credit, MSFT has a great whitepaper on securing code signing certificates and using them securely as do others such as CA, Thawte and others.

What’s my point? Application authentication needs a reboot – lets add another measure of authenticity beyond code signing since it’s a single factor authentication. We should authenticate the vendor (holder of the certificate) and the application. I’d been thinking maybe I should start a company and do this, but it occurred to me we have authorities on such matters including the US National Institute of Standards and Technology (NIST) which maintains the National Software Reference Library (NSRL). It’s exactly what is states… a reference library of authentic software that’s used in legal matters and wherever you have to be really sure what application you’ve got at hand. Whether or not the application is code-signed, you can verify it’s exactly what it claims to be by comparing its hash (a unique condensed representation of the application binary) to the known hash for the application.

Another potential approach is for the certificate issuing authority to verify both the certificate validity, and that the application hash was registered by certificate owner (strong authentication of the cert owner to the CA using separate secrets). I saw that Verisign offers code signing services now. This is a step in the direction of being authority on publisher identity (certificate) and the artifacts knowingly signed by the publisher. This approach also greatly reduces the risk of a software provider being compromised and losing control of their certificates. It also has the implication of consolidating all application authentication to a single mechanism. I prefer the idea of independent verification via different channels.

If Google can organize the world's information and make it universally accessible and useful, it should be possible to organize the world’s software and verify it’s legitimate.

Brian Hanrahan

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Webcasts | February 09, 2021

Customer Webinar: Remote Support 21.1 Released!

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.