<![CDATA[The Duo Blog]]> https://duo.com/ Duo's Trusted Access platform verifies the identity of your users with two-factor authentication and security health of their devices before they connect to the apps you want them to access. Mon, 20 Nov 2017 08:30:00 -0500 en-us info@duosecurity.com (Amy Vazquez) Copyright 2017 3600 <![CDATA[Examining Personal Protection Devices: Hardware and Firmware Research Methodology in Action]]> tmanning@duo.com(Todd Manning) https://duo.com/blog/examining-personal-protection-devices-hardware-and-firmware-research-methodology-in-action https://duo.com/blog/examining-personal-protection-devices-hardware-and-firmware-research-methodology-in-action Duo Labs Mon, 20 Nov 2017 08:30:00 -0500

In a technical paper released today, Duo Labs details research into two personal protection devices based on ARM Cortex M microcontrollers. Tools and techniques are shared, and a novel bypass affecting readback protection in one microcontroller is shown.

The explosion of the Internet of Things in recent years has resulted in the proliferation of microcontrollers into devices that impact many aspects of our daily lives. One such area Duo Labs investigated recently is the personal protection device category of consumer devices. These devices present wearers with a simpler way to more easily notify personal contacts during their daily lives. These notifications can represent a check-in to let people know, “I’m doing ok,” or to notify those contacts, “I’m in trouble and need help.” The personal protection device endeavors to let a wearer do this in a way that doesn’t require retrieving, unlocking, and operating a phone. Now, discrete devices can enable this process faster and simpler.

Duo Labs researchers recently examined two personal protection devices based on ARM Cortex M microcontrollers. The two devices presented in the accompanying paper are the Revolar Instinct and the Athena by ROAR for Good. This paper describes a methodology for retrieving device firmware, and for loading firmware into IDA Pro, a common disassembler. This paper focuses on the disassembly of this firmware, and the discussion of a novel approach to defeating readback protection discovered in one ARM Cortex M implementation.

During the course of this research, I developed code for IDA Pro to assist in loading and grooming Cortex M firmware images. The IDAPython code is comprised of two modules. The first module annotates Cortex M vector tables, which gives IDA Pro hints about where code exists in the firmware image. The Cortex M module can automatically annotate firmware with a vector table located at the start of a firmware image, or can be tailored by the end user to work with relocated tables.

The second module, called Amnesia, uses byte-level heuristics to detect ARM instructions in the firmware. Amnesia also contains heuristics that operate at the ARM instruction level to determine function boundaries based on common ARM function prologues and epilogues.

This code has been released on the Duo Labs Github, and its use is detailed in the accompanying paper.

]]>
<![CDATA[Approve Your Authentication Requests With Just a Glance]]> tmccaslin@duo.com(Taylor McCaslin) https://duo.com/blog/approve-your-authentication-requests-with-just-a-glance https://duo.com/blog/approve-your-authentication-requests-with-just-a-glance Product Updates Tue, 14 Nov 2017 08:30:00 -0500

Shortly after Apple announced the iPhone X and Face ID back in September, the Duo team has been excited to test the security properties of this new technology, and consider how we would add support for facial recognition to Duo.

There has been a lot of criticism about Face ID: its lack of ability to secure more than one face, questions about recognition speed, as well as privacy implications of 3D facial scan data. Apple has responded to many of these concerns in an official statement and by releasing a security brief on Face ID’s inner workings.

However, in practice, our Duo Labs security research team has been satisfied with the security properties of Face ID as compared with Touch ID. Face ID builds on many of the security advancements Apple made with the introduction of the Secure Enclave when it added Touch ID to devices a few years back. There are also some great changes in iOS that put security first on the iPhone X, like defaulting to notification privacy without any loss in usability or convenience.

Now that we have a few iPhone Xs floating around the Duo office, we’ve put Face ID to the test—and we’re impressed.

Duo Mobile Login Request The combination of the TrueDepth camera, the Secure Enclave Processor (SEP), the new custom GPU architecture (A11 Bionic chip with Neural Engine), and on-device machine learning (Core ML in iOS 11): all result in ensuring Face ID is effective, secure and privacy-friendly. With Face ID, iPhone users can use longer and stronger device passcodes to strengthen their keychain security, while maintaining convenience and ease of use.

Face ID will likely bring usable facial recognition capabilities to consumers, and we certainly expect to see Apple add Face ID to future devices. With Face ID, Apple has created security that blends into the background and gets out of the way, making it extremely usable. Duo believes that usable security is effective security, and we certainly believe Apple has achieved that with Face ID.

With a stamp of approval from our Security team, our Mobile team has added support for Face ID and compatibility with the new form factor of the iPhone X with the release of version 3.19 of Duo Mobile, which we released on the eve of the first iPhone X deliveries, November 3rd.

And thanks to our Duo Restore feature—launched earlier this year—getting Duo Mobile up and running on your new phone is a breeze. Along with support for Face ID during authentication, we’ve also updated our Security Checkup feature to work with Face ID.

Duo administrators can create a biometric policy via the Duo Admin portal, which will add a biometric check when approving authentications to services protected by Duo. Our new biometric policy with support for Face ID replaces our fingerprint-specific policy, making it easy for administrators to add additional biometric checks regardless of whatever biometric factor their end users’ devices support—whether it’s Touch ID, Face ID, or Android Fingerprint.

Mobile Device Biometrics

In under a week, we’ve seen over 20k unique iPhone X devices running Duo Mobile quickly rising into our top 20 list of active device models, making it one of our fastest adopted mobile devices Duo has seen. To put that in perspective, in the past year, Duo has seen over 6,000 unique device models running Duo Mobile.

]]>
<![CDATA[Duo Security Summit San Francisco: Can Security Enable Velocity?]]> zoe@duo.com(Zoe Lindsey) https://duo.com/blog/duo-security-summit-san-francisco-can-security-enable-velocity https://duo.com/blog/duo-security-summit-san-francisco-can-security-enable-velocity Press and Events Thu, 09 Nov 2017 08:30:00 -0500

Duo Security hosted a security summit on October 26th, inviting experienced security leaders with wide-ranging backgrounds for a Q&A panel discussion. The core question for the discussion: can security measures go further than simply not slowing down your organization’s productivity, and help to accelerate it instead?

Keynote on Network De-Perimeterization and Evolving Security

Jon Oberheide, Duo’s Chief Technology Officer, opened the summit with a keynote reviewing the history and advancement of de-perimeterization, beginning with a 2006 research paper on de-perimeterized architecture. The Jericho Forum, responsible for this research, was an international group of CISOs and security leaders looking for a strategy to respond to “the erosion of the traditional ‘secure’ perimeters” and relying on those network boundaries as an indicator of trust.

As cloud-hosted and remotely-managed services grew in popularity, this erosion and how to address it became a critical concern. Progressive security organizations like Netflix and Slack adapted and expanded on these strategies, creating tools to increase visibility and prepare their teams to effectively participate in the security process regardless of their location.

Finally, Jon outlined how Duo built the Trusted Access model around the same “zero trust” philosophy, designing universal solutions to secure access for traditional, hybrid and cloud-forward environments.

Panel on Enabling Velocity Through Security

The panel discussion was introduced and hosted by Josh Yavor, Duo’s Director of Corporate Security. Panel participants included Marisa Fagan, Product Security Lead at Synopsys; Ben Hagen, Director of Corporate Security at Facebook; Julie Tsai, Senior Director of Security Operations at Box; and Brendan O’Connor, Security CTO for ServiceNow.

To open the conversation, Josh asked what “velocity” meant within each panelist’s business. Each panelist discussed the importance of not sacrificing quality for speed, and focusing on removing roadblocks where they are able.

When asked for examples from their experience where velocity was a challenge, Brendan highlighted the need to “get the ‘basic hygiene’ parts of security” right, and “make your organization excellent at the ordinary.”

Julie expanded on this idea, saying that developers may gravitate towards uncommon or unique problems, but the day-to-day processes and controls are more important. With security often being seen as “the blockers,” adding gates or process steps only when they were most effective was key, according to Marisa.

When asked for the foundational elements of velocity, Ben answered with clear communication for both expectations and processes. Marisa and Julie emphasized the need for reviewing and measuring what is happening in the environment today, as well as looking at past incidents for insight on areas of improvement.

As a common challenge for engineering-heavy organizations, Josh asked the panel about their methods to “go from being a team that says ‘no’ to the team that says ‘yes, but’ or ‘yes, and.’” All panelists agreed that building rapport and an understanding of each teams’ technical needs and business drivers was crucial.

Julie added,“Start with respect, users don’t want to be talked down to.” Brendan pointed out that security’s role was to bring a realistic perspective of risk: “Security is not the judge, we’re the prosecutor. We can present the indicators, and educate the leadership, but often we don’t get to make the final call.”

Panelists also spoke on the importance of education and metrics, with Ben clarifying that the useful metrics are those that move with the organization; a less-precise metric that reflects changes in the organization is more helpful than a precise, static indicator. Panelists stressed communication, user understanding and other people-focused “soft skills” as critical to enabling velocity throughout the conversation.

To close the panel, Josh asked each guest to share where process and automation fit into a streamlined strategy. Julie shared her preference for “self healing” tools that go beyond tracking history, to checking current status and automatically applying updates and fixes. Marisa answered that safeguards at the development stage and catching problems before they start was key in her product security role. Brendan and Ben both said to seek out the routine and repetitive tasks that can be automated, alerting security team members whenever there is an anomaly that merits review.

Following the panel, panelists and guests joined a happy hour peer discussion, sharing their own insights and lessons learned with one another over wine and appetizers. As the summit drew to a close, a common theme emerged that there is no “silver bullet” for high-velocity security, but many effective strategies to improve it. Armed with practical advice and strategies from their security peers and industry leaders, attendees went home with plenty of ideas how they could streamline their own organization.

]]>
<![CDATA[What You Need to Know About Complying With GDPR]]> hseddon@duo.com(Henry Seddon) https://duo.com/blog/what-you-need-to-know-about-complying-with-gdpr https://duo.com/blog/what-you-need-to-know-about-complying-with-gdpr Industry News Wed, 08 Nov 2017 08:30:00 -0500

The General Data Protection Regulation (GDPR) is high on the agenda for many companies, especially when they read some of the scare stories and blogs out there. It can seem daunting and impossible to know where to start to comply with the European Union’s (EU) data protection reform.

Indeed, there are so many scare stories out there about businesses being closed as a result of GDPR: “GDPR will stop dentists ringing patients to remind them about appointments,” or, “cleaners and gardeners will face massive fines that will put them out of business,” or, “all breaches must be reported under GDPR.”

Many new businesses have started on the back of GDPR; offering expert advice to solve your problem. And countless other companies are trying to sell everything under a GDPR banner. I met a new GDPR business owner last month who told me that he was going to buy his new boat on the back of the consultancy work he would be getting out of GDPR.

However, the reality is different. GDPR is about putting the protection of individuals’ personal data first, it is not a license for companies to offer ever-more complex systems to solve seemingly impossible problems. Most companies want to protect the personal data they have. Indeed, much of what is required for GDPR is already best practice for many companies.

What do you need to know about GDPR?

GDPR affects any organization that does business in the EU. The regulations try to ensure personal data is stored and transferred with strong data protection in place. You should know what is collected, how it is stored, who you share it with and how it is protected.

You should be ready to report a breach to your local data protection authority within 72 hours of learning of the breach and, in some cases, also be ready to report the breach to individuals impacted by it. And finally, you should be aware that fines for not doing this can be large, up to 4% of annual turnover.

So - what can you do?

Start to understand the data your business collects and uses. Record and limit who can access personal data - especially when you are sharing that data out of your organisation. Make sure that you encrypt as much of that personal data as possible, and anonymise or ‘pseudonymise’ it.

Most breaches are the result of stolen credentials. It is therefore critical to make sure users are who they say they are. It is no longer enough to simply rely on a password to do this as they can easily be stolen. Multi-factor authentication protects against unauthorized access using stolen credentials.

There is no single solution out there that will ensure compliance, but doing the security basics well will help you protect your company’s personal data and help you comply with GDPR. It is critical to make sure that the users who access sensitive data are who they say they are, use complex passwords, need access and are protected by using multi-factor authentication.

Using a solution like Duo’s MFA throughout the customer’s organization can help protect personal information against data breaches. Our Trusted Access solution, available in our Duo Access and Duo Beyond editions, ensures that only Trusted Users and Trusted Devices can access protected applications. This also helps customers exercise greater control over access to personal information on their systems.

]]>
<![CDATA[Potential Gaps in Suggested Amazon Web Services’ Security Policies for MFA]]> spiper@duosecurity.com(Scott Piper) https://duo.com/blog/potential-gaps-in-suggested-amazon-web-services-security-policies-for-mfa https://duo.com/blog/potential-gaps-in-suggested-amazon-web-services-security-policies-for-mfa Engineering Tue, 07 Nov 2017 15:00:00 -0500

During a recent review of current guidance from Amazon Web Services (AWS) for enforcing multi-factor authentication, Duo’s Production Engineering team noticed some documentation gaps with AWS’s suggested policies. Following coordination and discussions with AWS’s security team, we’re disclosing these gaps with the aim of generating further discussion and awareness to help customers maintain the security posture of their AWS hosted resources.

The policy in question was found in a tutorial, "Enable Your Users to Configure Their Own Credentials and MFA Settings." The goal of this policy is to improve the security of AWS Identity and Access Management (IAM) users by encouraging them to initialize a multi-factor authentication (MFA) device themselves as an additional authentication step before allowing them access to their AWS resources. The intent is that IAM users would need this MFA device to be able to perform actions for which they had been granted privileges.

We noticed, however, that an attacker could circumvent this MFA step if they had compromised a user's access keys, without needing the MFA device. Given that the purpose of this policy was to enforce MFA on users, including when access keys are used, we promptly reported this to AWS's security team and have been working closely with them to resolve the gaps. We greatly appreciate the responsiveness of the AWS team and shared this post with them prior to publication.

Specifically, we identified the following three gaps:

DeactivateMFADevice

The first gap identified was that although the documented policy allowed the ability to call "CreateVirtualMFADevice" without MFA, which was largely the purpose of this policy, it also allowed the ability to call "DeactivateMFADevice" without MFA.

As a result, if an attacker compromised your AWS keys, they'd be able to deactivate your existing MFA device that you control, and activate a new one that they control. By doing this, they would be able to use their MFA device along with the stolen access keys to authenticate as you!

AWS addressed this first gap by changing the policy on their site and sending out an email on September 25 to affected customers with the subject, "Update your AWS IAM policies to require IAM users to sign in with MFA before updating their credentials and MFA devices." An example of that email can be found below:

AWS IAM and MFA Policy Update Email

Policy as Applied to IAM Privileges

The next gap we spotted was the result of a common use case where this MFA enforcement would be applied to the most privileged users in the account, specifically the users that had Identity and Access Management (IAM) privileges.

The original policy did not enforce MFA on any IAM actions. An attacker that compromised your AWS keys could use this weakness to remove the MFA enforcement policy from your account, create a new user without any restrictions on them, or utilize a number of other techniques to circumvent the MFA policy.

AWS has released updated guidance for this second gap today, and we recommend that you update your policies if you were using AWS's previous guidance.

Race Condition on MFA Activation

A final gap we identified with this policy is an interesting race condition that can happen with MFA devices. If the other policy gaps were fixed and an attacker compromised your AWS keys, they could repeatedly attempt to activate a new MFA device that they control.

When you get a new device and deactivate your old device in order to activate your new one, the attacker would potentially be able to activate an MFA device that they control before you're able to activate yours.

That would give an attacker control of your user account.

You would quickly notice something was wrong, but the attacker would have a short window of opportunity with control of your user account before you'd be able to regain control.

Mitigation

This final gap is not fully resolved and will take more time for a complete fix. After discussions with AWS, it was decided to disclose this gap to ensure customers are aware of it. In response to this gap, AWS has implemented rate-limiting to reduce the likelihood of this attack being successful and they continue to investigate a more secure long-term solution.

As an AWS user, you can proactively safeguard your users by actively monitoring your CloudTrail logs. You can spot an attacker attempting to use this technique by looking for failed calls to "CreateVirtualMFADevice." Since the race condition is only in effect when you switch MFA devices, an additional safeguard would be to rotate your credentials just before you replace your device. Both of these best practices will soon be included in AWS documentation.

As part of this post, we're releasing rules for StreamAlert [https://github.com/airbnb/streamalert] to detect these gaps in your CloudTrail logs.

Conclusion

We'd like to thank the AWS security team for responding to our concerns to quickly fix their guidance and taking the steps to identify and reach out to their customers to disclose these gaps.

We hope that this post provides security benefit to you and your organization. If you’re interested in the intersection between security and running a highly-available service on AWS, please contact Duo's Production Engineering team at prodeng-ext@duo.com.

]]>
<![CDATA[State of the Auth: Experiences and Perceptions of Multi-Factor Authentication]]> oanise@duo.com(Olabode Anise)klady@duosecurity.com(Kyle Lady) https://duo.com/blog/state-of-the-auth-experiences-and-perceptions-of-multi-factor-authentication https://duo.com/blog/state-of-the-auth-experiences-and-perceptions-of-multi-factor-authentication Duo Labs Tue, 07 Nov 2017 08:30:00 -0500

In the past, Duo Labs has written several blog posts containing data analysis ranging from iOS adoption to user response to NIST’s guidance on SMS. This time, we decided to conduct research in an area that hits closer to home: two-factor authentication (also referred to as multi-factor authentication) adoption and perception.

In order to find out what the average person thinks of two-factor authentication (2FA), we conducted a U.S.-census-representative survey that asked questions about a participant’s 2FA usage, how they learned about it, which technologies they’ve used as as a second factor, and more.

Through this survey, we discovered that:

  • Only 28% of people use 2FA.
  • The majority of participants who did use 2FA (54%) began using it voluntarily.
  • Two-thirds of people who had used security keys or push notifications as an authentication method believed it to be convenient and quick.

While having data concerning 2FA adoption and perception on a national scale is very informative, it doesn’t tell the complete story. In the future, we hope to conduct a global survey so that we are able to better measure 2FA adoption over time and perceptions of it outside of the United States.

Details, Details, Details

In order to help our readers digest our results with graphics, we’re releasing a short paper to discuss the context of our research, our data and conclusions, and the process we went though, so other researchers can provide feedback and reproduce our results.

Read State of the Auth: A Survey of Users’ Authentication Experiences and Perceptions.

Data and More

In addition to the findings we present in the paper, we’re sure there are more things that could be uncovered and additional insights that could be drawn from our data. With that in mind, we’re releasing to the public a reformatted version of the survey responses on https://data.world/.

We hope that you will have fun conducting some analysis on your own, and we’re looking forward to hearing about any additional discoveries you uncover. Hit us up at @duo_labs or labs@duo.com.

]]>
<![CDATA[Malicious Chrome Extensions Steal Passwords & CPU Power]]> thu@duosecurity.com(Thu Pham) https://duo.com/blog/malicious-chrome-extensions-steal-passwords-and-cpu https://duo.com/blog/malicious-chrome-extensions-steal-passwords-and-cpu Industry News Thu, 02 Nov 2017 00:00:00 -0400

A recent attack called Catch-All spreads a Google Chrome extension via phishing emails, stealing data posted online by users.

The email had links to photos sent via WhatsApp - when users clicked on the links, they would actually download an executable that launched a fake Adobe PDF Reader install screen. The executable also downloaded and unzipped two files, executing a CAB file that contained two very large files that:

  • Ended Google Chrome processes
  • Attempted to disable Windows Firewall
  • Included code to bloat the file as a potential strategy to bypass antivirus solutions that typically don't inspect large files

There is a threshold size of downloaded files set to prevent system resources from becoming overloaded; an example is Fortiguard’s default setting of 10 MB.

Once one of the files had cleared a path, it installed the malicious Chrome extension and changed the Google Chrome launcher files to load it on next execution, according to the security researchers. To load the extension, the file disabled other security features, effectively:

  • Allowing Chrome to run plugins without authorization
  • Allowing extensions to inject script into file URLs, without user opt-in
  • Disabling Chrome's Safe Browsing download protection, allowing files to pass by unverified

Once installed, the extension stole user data posted by users on websites (including email addresses and passwords), and sent it back to the attacker’s command & control server.

This type of attack is different and perhaps more successful than others because it didn’t require any spoofed websites, forged SSL certificates, etc. - the attacker was able to stealthily steal leaked data as the user browsed legitimate websites.

Other Cases of Malicious Chrome Extensions

In mid-October, SwiftonSecurity found over 37,000 users had downloaded a malicious extension the Chrome Web Store that mimicked the look of AdBlock Plus ad blocker. It had been available for about a month. A day after Google removed the malicious extension, developers slipped two other malicious plugins into the Chrome Web Store.

Another malicious Chrome extension disguised as a URL shortener was actually stealing users’ CPU power without their consent; downloading Coinhive file, a JavaScript code that allows web admins to mine the cryptocurrency known as Monero, as reported by cryptocoins news. This was the second malicious mining extension discovered this month; earlier, an extension called SafeBrowse was pulled from the web store.

While there is ongoing discussion among Google engineers of features they could build into Chrome to stop cryptocurrency miners, protecting against unauthorized access and the use of stolen passwords remains the same, regardless of how they’re stolen - use strong methods of two-factor authentication, including U2F and push notifications can help keep access secure.

]]>
<![CDATA[Phish in a Barrel: Hunting and Analyzing Phishing Kits at Scale]]> jwright@duo.com(Jordan Wright) https://duo.com/blog/phish-in-a-barrel-hunting-and-analyzing-phishing-kits-at-scale https://duo.com/blog/phish-in-a-barrel-hunting-and-analyzing-phishing-kits-at-scale Duo Labs Tue, 31 Oct 2017 08:30:00 -0400

Phishing is a business, and business is booming.

To make phishing campaigns more efficient, attackers will often reuse their phishing sites across multiple hosts by bundling the site resources into a phishing kit. These kits are uploaded to a (typically compromised) host, the files in the kit are extracted, and phishing emails are sent pointing to the new phishing site. Sometimes, however, the attackers get lazy and leave the phishing kits behind, allowing anyone—including security researchers—to download them.

How Phishing Kits Work

In a technical paper released today, Duo Labs details the results of a month-long experiment in which we hunted and analyzed over 3,200 unique phishing kits. In addition to the technical paper, we’re open-sourcing the code we wrote to track down the phishing kits.

What We Found

Network Graph Click to view larger.

Over the course of a month, using community-driven URL feeds from Phishtank and OpenPhish, we found 3,200 unique phishing kits across 66,000 URLs. A high-level summary of our analysis is summarized below:

  • We found many phishing kits designed to evade detection through the use of .htaccess files and PHP scripts that block connections from threat intelligence companies based on attributes like the source IP address ranges, the HTTP referrer or the user-agent header.

  • We parsed each phishing kit for email addresses indicating both where the credentials are being sent as well as who may have originally created the phishing kit. We tracked individual attackers across multiple phishing campaigns, including one actor whose email address was found in over 115 unique phishing kits.

  • We tracked unique phishing kits across multiple hosts. We found multiple kits that were seen on as many as 30 different hosts, indicating actors launching multiple phishing campaigns with the same kit.

  • We identified over 200 instances of backdoored phishing kits. This shows that attackers who are selling or distributing these phishing kits to other criminals are actively backdooring them to give themselves access to the compromised hosts. Clearly there's no honor among thieves!

  • Our analysis revealed that phishing kits were most commonly found on compromised sites running Wordpress, and 16% of the time they were found on sites being served over HTTPS.

Get the Paper

This blog post only scratches the surface of the research we performed. Our technical paper Phish in a Barrel: Hunting and Analyzing Phishing Kits at Scale provides the full detail of the experiment, showing how we found, stored and analyzed phishing kits at scale.

The goal of our research is to offer a glimpse into the methods and tools attackers use to make their operations efficient. As part of these results, we’re open-sourcing the code we used to collect phishing kits. You can find the code on Github.

Conclusion

As a security practitioner, you can use the same techniques we describe in the technical paper to track down phishing kits targeting your organization, as well as to determine what information is being stolen and where the information is being sent.

We’d like to thank both OpenDNS (operators of Phishtank) and OpenPhish for their excellent community-driven feeds. This work wouldn’t be possible without the great services they provide to the security industry.

It’s important to note that all of the phishing kits we analyzed aimed to steal credentials for later reuse. One of the best things defenders can do to reduce the impact of stolen credentials is to set up multi-factor authentication (MFA) for every external-facing application used by your organization. Additionally, you can use the free Duo Insight phishing tool to test your organization’s exposure to phishing attacks.

]]>
<![CDATA[Protecting Against Bad Rabbit Ransomware Infection]]> thu@duosecurity.com(Thu Pham) https://duo.com/blog/protecting-against-bad-rabbit-ransomware-infection https://duo.com/blog/protecting-against-bad-rabbit-ransomware-infection Industry News Thu, 26 Oct 2017 08:00:00 -0400

There’s a new ransomware outbreak affecting users primarily located in Russia, Ukraine, Bulgaria, Turkey and Japan - and a small number of U.S. victims, including some of Russia’s banks, as BleepingComputer reported. Urkaine’s Kiev Metro and the Odessa international airport’s systems have failed, causing disruptions in service.

WeLiveSecurity has provided a comprehensive account of how this particular variant of ransomware, named Bad Rabbit and ranked as severe by Microsoft, has infected users. Cylance also provides a more technical overview. The strain is said to be a variant of Not-Petya, the rather destructive malware that spread globally back in June.

Bad Rabbit Ransomware Infection Methods

There are two observed ways of Bad Rabbit infection (though likely not the only methods):

Drive-By Download

JavaScript was injected into the HTML or .js files of popular websites. When a user of interest visits the website, the server adds content to the page, displaying a popup that prompts users to download a Flash Player update.

After the user clicks Install, an executable file is downloaded on their computer, launching the ransomware and locking their machine.

SMB + Stolen Credentials

The ransomware’s executable file scans networks for open SMB shares. Then Mimikatz, a publicly available tool that targets Windows users and can be used to steal passwords extracted from memory, is launched on a compromised computer.

The malware also uses a list of pre-selected hardcoded credentials to authenticate to the host. After finding valid credentials, the ransomware file is uploaded to the Windows directory and executed through the Service Control Manager.

Protecting Against Ransomware

The US-CERT’s advisory from July provides advice for ransomware, patching and phishing, since malware can spread in a number of ways. Here’s some of their tips, plus links to a few other resources:

  • Frequently back up your systems and important files on a device that can’t be accessed from a network; verify backups regularly.
  • Practice caution when clicking on links in emails or opening email attachments; verify web addresses/senders independently.
  • Microsoft has provided some guidelines on protecting against the malicious use of the SMB protocol, while the US-CERT’s SMB Security Best Practices refer to the mitigation of the SMB vulnerability used earlier this year
  • Microsoft’s threat advisory states that Windows Defender Antivirus version 1.255.29.0 and higher detects and removes Bad Rabbit - so be sure to update your systems to the latest versions.

Learn more about protecting against remote access threats that target users, devices and remote remote services in The Essential Guide to Securing Remote Access.

]]>
<![CDATA[SSH Key Exposure: Lapses in Server Access Security]]> thu@duosecurity.com(Thu Pham) https://duo.com/blog/ssh-key-exposure-lapses-in-server-access-security https://duo.com/blog/ssh-key-exposure-lapses-in-server-access-security Industry News Tue, 24 Oct 2017 08:00:00 -0400

SSH (Secure Shell) is a secure way to remotely connect to and communicate with servers, but the way in which the keys are handled can lead to access security issues and the potential exposure of sensitive data.

SSH keys are used to log into servers (more secure than just a username and password). These keypairs include a public key and private key that are cryptographically secure and used to authenticate a client to an SSH server. The private key should be kept secret - if compromised, the private key alone can allow attackers to log into servers or systems. The public key is kept on the server that you want to authenticate into.

Website owners or developers may accidentally upload their SSH private key to their public website, or commit their private keys into website source code via Github or SVN (subversion) repositories. Once uploaded, an attacker can scan public sites for SSH keys and get access to your servers.

Issues With SSH Security Management

A recent study from Threat Stack found that 73 percent of Amazon Web Services (AWS) users left their remote SSH service exposed to the public internet on their cloud instances.

A configuration error like this allowed attackers to log into servers from anywhere, bypassing traditional network controls, such as firewalls and virtual private networks (VPNs).

The study also found that 62% of AWS users at the companies analyzed were not using multi-factor authentication (MFA), also known as two-factor authentication (2FA) - an additional way to verify users’ identities through a variety of different methods. Amazon lists those different options on their website about MFA.

Additionally, the study revealed that less than 13% of companies kept their software up to date - some of the unpatched systems were kept online for more than three years.

According to Threat Stack, despite the enterprise investment on advanced, sophisticated security solutions, most of them are not taking full advantage of the most basic security tools already available to them.

Mismanaged SSH Keys

A survey from Venafi, as reported by InfoSecurity Magazine found that 61% of IT security professionals don’t practice least privilege - that is, they don’t limit or even monitor the number of admins who manage SSH.

Another 90% of respondents don’t have a complete and accurate inventory of all SSH keys, which can make it difficult to keep track of misuse or which keys should be trusted.

Examples of SSH Key Exposure

Back in May, it was reported that a leading U.S. government contractor exposed more than 60k unclassified sensitive files on a publicly accessible AWS server - including unencrypted passwords to sensitive government systems, contractor credentials, vulnerability reports on government source code, and more.

Plaintext data in the AWS S3 bucket also included the public and private SSH keys of an engineer working at the government contractor, and admin credentials to one of their data center’s operating systems.

While U.S. government servers hosted on Amazon are usually segregated on the GovCloud (an isolated AWS region protected by advanced cryptography and physical security), this particular AWS S3 bucket was not. The files were connected to the US National Geospatial-Intelligence Agency (NGA), which provides battlefield and drone surveillance imagery.

More recently, security researchers have reported a single entity that has been scanning systems, seeking out SSH private keys that can be used to compromise websites, according to Wordfence. Attackers are searching for the terms root, ssh or id_rsa to find public web directories that contain the private SSH keys.

For more information on SSH security best practices, check out Ari’s Blog.

]]>
<![CDATA[Bluetooth Hacking Tools Comparison]]> mloveless@duosecurity.com(Mark Loveless) https://duo.com/blog/bluetooth-hacking-tools-comparison https://duo.com/blog/bluetooth-hacking-tools-comparison Duo Labs Mon, 23 Oct 2017 09:00:00 -0400

The TL;DR

Are you wondering what the best Bluetooth scanner is? Or what the most commonly used Bluetooth software is? We’ve wondered that too. We’ve examined several, compared features and capabilities, and discovered that while the best appears to be the Nordic Semiconductor nRF-51DK, a number of selections exist that give good results for different situations. A solid strategy is to have multiple choices while focusing on the best one for the situation at hand.

Background

The idea of approaching IoT investigation with Bluetooth probing and sniffing is twofold. The first is to simply check to make sure the attack surface of Bluetooth is safe. The second is to assist in other areas of an IoT investigation, such as finding input points that could help map out attack vectors or identify how device information is leaked that could allow for easy tracking of an individual or their expensive new IoT device (or both).

Duo Labs has done research on multiple IoT devices that use Bluetooth, and like many people, we are left scratching our heads at how good or bad some of the testing tools are. Unfortunately, to perform every Bluetooth probe and scan perfectly requires a high dollar investment, so most of us are left with the choice of figuring out the best tool for the job.

There is nothing more frustrating than having a testing tool that is inconsistent, or one that does only one thing better than every other tool while performing additional tasks mediocre at best. Finding consistency when scanning and probing is hard, and this is in part due to the nature of Bluetooth itself - it is a frequency-hopping set of protocols stacked on top of each other that transmits data at a signal much weaker than Wi-Fi.

As a result, some hardware tools in certain environments do not perform well or consistently. Some hardware tools are specifically tailored to excel in specific environments only. And some do weird things like deliver that one thing - that single thing you wished every tool you had would do as well.

So we looked at tools with several different areas in mind:

  • Lab work, including sniffing and probing
  • Field work, with both the ability to quickly find close-range targets as well as longer range targets using more sophisticated hardware with larger antennas
  • Programmability, for the serious hacker doing serious experimentation.

We’ll touch a bit on platforms versus the tools that run on them, and speak about which tools work best on which platform. The platform choice list isn’t going to be comprehensive, but should cover enough to get you going and thinking. Normally, we’d specify our overall strategy for examining these tools with some type of guidelines, but in this case, we will stick to pointing out strengths and weaknesses - with an emphasis on strengths in terms of a good tool to have in a researcher’s toolbox.

Laptops

Before we get to applications on the computer, we need to discuss the computer itself- we’ll assume that users will choose a laptop over a desktop system. Bluetooth, by nature, implies mobility, and chasing it down via a mobile platform makes the most sense. With Bluetooth and Wi-Fi issues around IoT, the idea of “field work” makes sense, so your platform should do the same.

You can use any operating system (OS) you want - all will involve limitations to some degree.

OS Pro Con
Windows - Mature drivers - Most high-end ($$) software packages are supported on Windows only - Lack of quality freeware choices
macOS - More freeware choices than Windows - Many software utilities are ports, some with features removed or unsupported for macOS
Linux - Large selection of high-quality open-sourced choices of utilities - Many hardware solutions are better (or only) supported on Linux flavors - Lack of GUI interfaces in many utilities - Lack of consistent output formats - Driver support is sometimes lacking, partially dependent on the laptop hardware itself

On software alone, Linux comes out way ahead, especially if you are a command-line kind of hacker, but the driver support is an issue. This is that phenomena where you buy the HP or Dell laptop with Windows pre-installed, and then wipe it to install Linux - only to find that the Linux drivers for interacting with the hardware are somewhat generic.

The Windows drivers are usually written by the laptop vendor to ensure they work perfectly with their hardware. You can find this for Linux if you purchase your laptop from a company that ships their hardware with Linux and Linux only, and writes their own custom drivers for their hardware.

This is why System 76 is such a great choice, as they develop and maintain their own drivers for Ubuntu, which is the only operating system they ship with. As a result, their interaction with both Bluetooth and Wi-Fi is very high quality, and questionable wireless tools become a lot more stable and useful.

System76 Figure 1. The System76 Galago Pro. Lightweight with customized drivers to talk to their hardware.

While it is entirely a personal choice, we feel that running Ubuntu on vendor-supported hardware is a solid way to go, and from the experience of using all three operating systems in a research capacity, this seems to deliver really consistent results - especially with Bluetooth.

Don’t get us wrong, there may be features offered on other laptops that you can’t live without, like a specific keyboard that could outweigh other advantages, but speaking directly to Bluetooth and wireless protocols in general, you might be a leg up with Linux on a system designed with Linux in mind.

A word on Kali Linux: if your need is for an all-around research/penetration test system, this is a decent choice, but bear in mind that the selection of apps for Kali are geared more toward pentesting. For example, many of the Bluetooth utilities on Kali are for attacking and are often written for a single exploit (or class of exploits), and many of these exploits have been patched in modern systems.

Bluetooth Hardware Devices

There are tons of decent add-on hardware choices when it comes to Bluetooth. When we say add-on hardware choices, we are typically referring to USB devices that provide features and capabilities that the built-in Bluetooth in your laptop doesn't have. As previously stated, we don’t recommend a single one over another; we recommend using multiple, specialized devices. If that sounds like we are suggesting more than one, it is because that’s quite possibly the direction you will be headed.

The main thing to keep in mind is that the device should support modern Bluetooth - so if you see something like “Classic Bluetooth and Bluetooth Low Energy” or version 4.0 or later, you should be good. Both “flavors” were combined with version 4.0 of the Bluetooth spec, so it should support both if it is fully 4.0 or later. As of this writing, most IoT that supports Bluetooth also supports 4.0 or later.

Some IoT devices will refer to using LE, BLE, BTLE, or some other variance of the name for “Bluetooth Low Energy” - but again, if your USB plugin device supports 4.0 or later, you should be fine.

If any device claims to support Bluetooth 5.x, great - just make sure that extra care was used to cover some of the nuances of 5. Version 5 comes with greater speed, different battery usage, and so on, so make sure the device is truly supporting 5 from the firmware and isn’t just tweaked 4.x hardware that cannot take full advantage of something like higher performance while using less power.

Small Dongles

There are tons of choices when it comes to simple dongles. Even older ones like the SMK-Link Nano are probably fine. The main disadvantage is lack of decent support on macOS, and weird Windows support. Starting with Windows 8 there were changes made to the Bluetooth drivers, so some dongles will work fine up through Windows 7 only, whereas others only support Windows 8 and newer. If your choice is Linux, most will work with the normal Bluetooth drivers, such as Bluez, and should handle tasks like scanning with ease.

SMK Link Figure 2. SMK-Link Nano. Check the bottom of your computer bag, you might own one with no knowledge of how you got it.

Dongles in this class are not a great choice for sniffing, unless you are using Wireshark to sniff from the dongle while you are using a tool to do probing with the same dongle. Basic promiscuous sniffing capabilities with these dongles is usually nonexistent. Their strengths are in their ability to offer slightly better performance during basic scans for Bluetooth devices in the immediate area; for anything beyond that, you’re lucky if you get stable and consistent results. If you’re not getting any better performance out of them than the Bluetooth hardware built into the laptop, you might as well skip it.

Larger Devices

A more stable device is the Sena UD-100 which is a great USB device.

Sena UD100 Figure 3. Sena UD100 with included stubby antenna.

While it comes with a small antenna, opting for some of the accessories like a dipole and a patch antenna can greatly extend the range of the device - for example, the patch antenna can increase the range up to a kilometer. Again, pay attention to expected drivers on Windows, and on Linux there should be no issue.

Dipole Antenna Figure 4. This dipole antenna on the UD100 gives it a range of about half a kilometer (line of sight).

The big pluses with this setup is that even the larger antenna (when detached) fits neatly in a bag and substantially increases the range.The Sena UD100 is a solid USB Bluetooth device that works way better than the built-in hardware. For both scanning and probing, this is a rock star. However, the biggest minus is that it is hardly stealthy. Expect the possibility of being approached at a coffee shop by curious “normals” wanting to know what it is (a good diversion answer is “wireless broken, temporary fix until I can get it to the shop”).

Ubertooth

Entire presentations have been done around Ubertooth, and while it has its strengths, it also has limitations. When it works, it works decently and will help get you data that is generally fairly hard to get otherwise. But getting to that point is rather difficult. Expect dropped packets and a lot of restarts of whatever Bluetooth activity you are trying to capture, because getting a complete picture of what is happening Bluetooth-wise will take some patience - especially if you try sniffing.

As we talked about earlier, Bluetooth operates by hopping through frequencies within a specific range, or spectrum. Ubertooth is being stepped through this “chasing” in the spectrum via software, and due to various environmental factors and clocks not staying perfectly in sync, packets can get dropped and even part or an entire exchange can happen that the Ubertooth completely misses.

Being that it is programmable is definitely a plus, and all of the software utilities - including firmware - are open-source. You can hook up a more powerful dipole antenna and get better range out of it in a field setting, but frankly, the Ubertooth performs best in a controlled lab environment.

Nordic Semiconductor

The Nordic Semiconductor nRF51-DK device is a pretty good Bluetooth transmitter and receiver, with the sniffing abilities working better than expected. Like the Ubertooth, it is programmable, but the out-of-the-box firmware is fine for most quick hacker work, including sniffing.

The range is limited, but the quality is high. Nordic Semiconductor supplies a lot of the chips and hardware solutions in IoT, so they tend to make inexpensive hardware to help developers test their creations.

Nordic Semiconductor Figure 5. The Nordic Semiconductor nRF51-DK. This thing was made for serious developers and hackers alike.

While the Ubertooth might have a slight advantage as far as distance goes, this is a great USB device for the lab. Due to the amount of designers and developers building IoT devices and writing IoT software for the various chipsets that Nordic Semiconductor makes, the community support for this device is rapidly growing. Expect this (and the newer model as of this writing, the nRF52-DK) to become the hacker’s favorite choice due to the wide open platform.

High-End Hardware

We don’t recommend this unless you are seriously hardcore and you have a huge budget, but if you are willing to spend the cash, you can get perfect Bluetooth captures. For example, the Ellisys Bluetooth Explorer is excellent, but retails for $17,500 USD. There are other companies selling high-end devices as well, but you get the idea - $17,500 is the starting point and prices go up from there.

Ellisys Bluetooth Figure 6. The Ellisys Bluetooth Explorer BEX400 does both Bluetooth and Wi-Fi sniffing at the same time.

Why do these high-end tools cost so much? Because they work so well. The dongles we’ve mentioned can be used for sniffing, but they are basically chasing the Bluetooth session as it signal hops within the Bluetooth spectrum.

The high-end machines work differently, by simply grabbing the entire Bluetooth spectrum at once, capturing everything. Specialized software is used to help control the device and read the captured data, and typically only runs on Windows. These devices are built for lab work, but one could easily add beefier antennas, and, as long as they can meet the power requirements, this could be considered an excellent field device as well (some high-end models are even marketed that way - built for both lab and field).

Software Tools

All About The Command Line

For the Linux hacker, it is all about the command line interface (CLI). There are plenty of CLI tools for Bluetooth and many of them provide useful information, although not all of them provide output in any consistent manner.

This usually isn’t a problem when you are exploring and poking at a single device, but if you’re trying to look at a number of devices all at once (such as scanning a lot of devices while in a coffee shop), then you will have to come up with some scripting and parsing of the output to bring order to the different output formats.

Here are a number of tools commonly used by researchers (there are others, this is a sampling of the more popular ones used in Labs, check their main pages or run them with the -? or --help options for all of the functions).

hcitool - This utility can be used for command-line scanning and obtaining the ever-important MAC address when connecting with other tools.

gatttool - Included with the Bluez library, this is a great tool for honing in on specific values of a General Attribute, or GATT characteristic as defined in the Bluetooth specification.

ubertooth-btle - Included with the Ubertooth software; out of all of the Bluetooth tools, this one will be used quite a lot. While hopping and chasing through the Bluetooth spectrum, you’ll occasionally get a complete chunk of Bluetooth traffic while sniffing with this utility. Don’t let the BTLE part of this fool you - all pairing takes place in Bluetooth 4.x in the low energy realm, so if nothing else, this is a great way to get a sniffer trace of the pairing process. Just be prepared for multiple tries and some patience, and when completed, you will have a nice pcap-formatted output file to analyze.

Mobile Apps on Phones

While doing field work, you sometimes wonder if you should even bother getting out your laptop and setting up your dongles. Sometimes it helps to have a quick way to look at the traffic, and it is even better if it returns useful information - saving you time with what to focus on once you get the laptop out.

There are a number of free applications for your phone that will help with this. Some of the free apps have mixed results, but a basic guideline for choosing one is to select them by the developer.

There are a number of companies that sell tools for building various applications or IoT devices (or both) that write decent free Bluetooth apps for testing from your phone. These are usually fairly high quality because they are intended to complement your development process while using their purchased products.

A couple of decent ones that work good for security researchers are Punch Through’s Light Blue Explorer and Nordic Semiconductor’s nRF Connect.

Punch Through's LightBlue Explorer Figure 7. Punch Through’s LightBlue Explorer in action. From the above, you can see it is useful in finding unusual items. This was captured mid-flight during a business trip.

Nordic Semiconductor Figure 8. Nordic Semiconductor’s nRF Connect. Excellent app with decent logging capabilities.

Using Wireshark

Most of the hardware and even some of the software comes with Wireshark plugins compile and install all of them. While there are too many to name and plan for, there are some general rules to keep in mind.

Read the documentation, but note the date. Many of the tools have detailed instructions and requirements regarding which version of Wireshark source code you need to compile the plugin, and odds are you’re running a much newer version of Wireshark. If the instructions are old and refer to an old version of Wireshark, it is possible that the plugin comes included with the newer version of Wireshark. Most plugins will compile without incident with a newer version of Wireshark. In fact, most will compile with the Wireshark development package for your Linux version, for example, wireshark-dev on Ubuntu.

The purpose of the plugins is simply to interpret the raw Bluetooth packets inside the Wireshark app into something a little more readable, and since there are multiple protocols involved with Bluetooth, it helps to make some sense out of what is going on.

There are often a couple of different ways to sniff Bluetooth - directly within Wireshark and with one of the command line tools itself. For example, Ubertooth includes the aforementioned ubertooth-btle, which allows capturing of Bluetooth traffic and saving the data in pcap format that Wireshark can read and interpret (with the appropriate plugins). But you can also plug in your Bluetooth USB dongles and sniff from within Wireshark itself. And you can use more than one Bluetooth source during sniffing within Wireshark.

For example, one can sniff using the laptop’s built-in Bluetooth capabilities; use one USB port with a dongle to perform actions with one CLI tool; and use a second USB port with a second dongle to perform another action - you can sniff from all three at once. It sounds overly complicated, but it isn’t. If you are using one dongle to probe a device and another trying to flood it at the same time, you can see the results from both in the same sniffer session. And it helps when testing how one dongle or CLI performs against the other.

So What’s The Point?

The checklist for examining Bluetooth’s attack surface involves determining what version of Bluetooth has been implemented, if the implementation is susceptible to such things as denial of service, etc.

This also involves simply documenting what the device does during various stages. For example, can more than one device pair to it? Does it begin advertising itself immediately after applying power for the first time, or do you have to perform an action (such as a button press) before it will allow pairing? Does it cycle through periods of advertising versus not advertising, perhaps in an effort to conserve battery power? But even more importantly, seeing how much information can be read remotely to fingerprint or otherwise determine information about the device - particularly as the state of the device changes. And this gets into the second area.

Things such as the name of the device or a model number can come in handy. Often when fingerprinting a device, you find information that will assist your IoT investigation in other areas - such as Bluetooth chipset and perhaps firmware versions associated with that chipset.

Being able to remotely determine the firmware version down to the exact build version can be a massive timesaver - particularly if you are able to find firmware versions online. If you’re aware of a build version that contains a certain flaw but is only available on an earlier version, you can eliminate that flaw from your testing phase, saving time.

thegnome@fang:~$ hcitool -i hci1 leinfo 00:07:80:CF:76:BC 
Requesting information ... 
   Handle: 75 (0x004b) 
   LMP Version: 4.0 (0x6) LMP Subversion: 0x3 
   Manufacturer: Bluegiga (71) 
   Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
thegnome@fang:~$

With a little Googling, determining the Bluegiga chipset and the build version of 71 helped determine the exact firmware version from 2013. Even poking around with freeware apps on a phone can reveal interesting info:

Model Number String Figure 9. Scanning and finding a device’s model number string in plain English, instead of ascii hex.

In the above example, the model number string of BLE112 coupled with the hcitool output with Bluegiga and the build version helped confirm the exact firmware. For the record, using the command line tool gatttool one could also determine the exact same information, although not presented nearly as cleanly.

root@plague:~# gatttool -i hci1 -I
[                 ][LE]> connect 00:07:80:cf:76:bc
Attempting to connect to 00:07:80:cf:76:bc
Connection successful
[00:07:80:cf:76:bc][LE]> characteristics
handle: 0x0002, char properties: 0x0a, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0007, char properties: 0x02, char value handle: 0x0008, uuid: 00002a29-0000-1000-8000-00805f9b34fb
handle: 0x0009, char properties: 0x02, char value handle: 0x000a, uuid: 00002a24-0000-1000-8000-00805f9b34fb
handle: 0x000b, char properties: 0x02, char value handle: 0x000c, uuid: 00002a25-0000-1000-8000-00805f9b34fb
handle: 0x000e, char properties: 0x28, char value handle: 0x000f, uuid: 80c7b47e-0d04-44d9-9fa7-245e83c4fc66
handle: 0x0012, char properties: 0x2a, char value handle: 0x0013, uuid: 00002a26-0000-1000-8000-00805f9b34fb
[00:07:80:cf:76:bc][LE]> char-read-uuid 00002a24-0000-1000-8000-00805f
handle: 0x000a value: 42 4c 45 31 31 32
[00:07:80:cf:76:bc][LE]> char-read-hnd 0a
Characteristic value/descriptor: 42 4c 45 31 31 32
[00:07:80:cf:76:bc][LE]>

The steps above were as follows:

  • Go into gatttool’s “interactive” mode (gatttool -i hci1 -I).
  • Connect to the device via Bluetooth using the MAC address obtained from the hcitool lescan (connect 00:07:80:cf:76:bc).
  • Obtain a list of the common handles with their values (characteristics).
  • In this case, we’re interested in the 0x2a24 GATT characteristic, which contains the Bluetooth chipset’s model number (this line: handle: 0x0009, char properties: 0x02, char value handle: 0x000a, uuid: 00002a24-0000-1000-8000-00805f9b34fb).
  • The uuid value starting with 00002a24 is the one we’re looking for, and by using either the full uuid (char-read-uuid 00002a24-0000-1000-8000-00805f) or the char value handle (char-read-hnd 0a), we can obtain the string with the model number (42 4c 45 31 31 32, which is “BLE112” in hex, and refers to a specific Bluegiga product).

The character properties values are interesting - for example, 02 is read only (char properties: 0x02), and 0a is writable. But as you can see, after a bit of probing and poking, we’ve gained a ton of information to help us locate firmware, chipset specs, and so on.

Correlating With Source Code

Finding all of the interfaces that allow for the external writing of values is an important part of examining the attack surface, and having all of the UUID values are great for when it comes to grepping through decompiled code. This allows you to potentially map values that are inputted into the IoT device and see how these values are processed by, for example, the accompanied app on the phone.

If you’ve managed to obtain firmware for the IoT device and decompiled it, you have an idea about what interfaces you can probe with arbitrary data, or at least which ones might look the most promising.

Not Exactly Perfect

Bluetooth can be imperfect, and it helps to run tests several times. For example, look at the results against a device, ran within a couple of minutes of each other:

thegnome@claw:~$ hcitool -i hci1 leinfo 44:fe:d3:98:29:7e
Requesting information ...
    Handle: 3585 (0x0e01)
    Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

thegnome@claw:~$ hcitool -i hci1 leinfo 44:fe:d3:98:29:7e
Requesting information ...
    Handle: 3585 (0x0e01)
    LMP Version: 4.1 (0x7) LMP Subversion: 0x64
    Manufacturer: Nordic Semiconductor ASA (89)
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00

The first one did not receive a complete answer, while the second one did. This is why we recommend multiple passes of a test.

Summary

We hope that this information might provide a bit more direction when it comes to poking around with Bluetooth devices. Some of the areas might seem complex, particularly when dealing with multiple ways to provide input into an IoT device and trying to layer them when formulating attacks. But by using various devices with different antennas and repeating tests when they seem to fail for no reason, one can shorten research time and find actual flaws a bit quicker.

Using a System76 running Linux, a Sena UD100 with a larger dipole antenna, the Nordic Semiconductor nRF51-DK (or the new nRF52-DK), various Linux tools, and the Linux version of nRF Connect for Desktop is solid for covering most field and lab work. Coupled with some apps on the phone such as nRF Connect for either iOS or Android, and you have a quick way to check if it is worth getting out that laptop while out in the field - plus you have another source of information. But if you can use anything additional, such as more antenna choices or an Ubertooth - go for it.

Bluetooth research is like woodworking - you could do the entire project with just a hammer and nails, a chisel, sandpaper and a handsaw, but having a number of other tools like a jigsaw or an electric sander will certainly help get better results quicker.

]]>
<![CDATA[Frictionless E-Prescribing & EPCS in Healthcare]]> dcopley@duo.com(Doug Copley) https://duo.com/blog/frictionless-e-prescribing-and-epcs-in-healthcare https://duo.com/blog/frictionless-e-prescribing-and-epcs-in-healthcare Product Updates Thu, 19 Oct 2017 10:00:00 -0400

Addressing one of the most common types of medical errors, e-prescribing medication has provided great improvements in quality, errors and cost reduction since its inception. So even with government incentives pushing electronic prescribing, why don’t all physicians and clinics perform electronic prescribing?

The simple answer is friction.

Physicians, nurse practitioners, nurse anesthetists, etc. that prescribe anything from simple antibiotics to controlled substances can have extremely busy schedules and their daily activities can be very hectic and fast-paced. As such, any added steps injected by IT teams or security teams that delay activities they perform causes slow-downs in their processes, creating resistance, or “friction.”

From a business perspective, and certainly from a healthcare provider perspective, friction can be the enemy of progress and innovation. Friction can destroy value and friction can destroy trust in the processes, technologies and the leadership of the organization. “Frictionless” solutions drive value by being integrated, by not introducing delays and by leveraging ubiquitous technology to drive value.

Sometimes friction is caused by technology that was implemented to meet compliance requirements. Electronic Prescriptions for Controlled Substances (EPCS) is a great example of this. EPCS has strict requirements for verifying the identity of the practitioner and goes further to recommend two-factor authentication (2FA) to provide a high degree of assurance that the person prescribing the medication is actually the practitioner.

In fact, some states like New York, Maine and Minnesota are now requiring two-factor authentication for EPCS. The identity proofing requirement for EPCS has typically involved physicians traveling to a specific location to verify their identity in-person (still required for institutional providers), which caused them to take time out of their busy schedule - thus creating friction.

Frictionless EPCS with Duo and Identity.com

I’m happy to say that technology has evolved and the identity proofing and two-factor processes required for EPCS can now be “frictionless.” With the latest offering from Duo Security and Identity.com, a federally-approved credential service provider, the process for individual practitioners can be done completely remotely. The practitioner needs no badges or tokens to complete the process - just their smartphone. The process is so streamlined and effective that any practitioner can complete the process in less than five minutes via the web.

Here’s how simple the enrollment process is for providers new to EPCS:

  • The individual practitioner would receive an enrollment email with a link to enroll
  • Following the link, they would:
    • Provide the required personal information
    • Validate their identity via questions from a credit bureau
    • Validate their address information via a utility company or financial provider
    • Enroll their smartphone for two-factor authentication
    • Authenticate via the Duo Mobile app

That’s it! In less than five minutes and from anywhere, an individual practitioner can be setup to electronically prescribe controlled substances (caveat: they must be using an approved and compliant EHR application for e-prescribing).

“Duo has enabled us to use EPCS with a secure, easy-to-use, second factor of authentication.

— Kimberly Sucy, Supervisor, IAM, Rochester Regional Health System (Source: TechValidate. TVID: 419-ABF-AEA)

Being a veteran of the healthcare industry, I understand how important it is that technology and security solutions be streamlined, integrated and “frictionless.” I certainly anticipate that solutions like these will greatly increase adoption of electronic prescribing for individual practitioners. Although technology may not have solved for frictionless requirements for all aspects of a medical practitioner’s job yet, I’m very happy to see it solved for EPCS and electronic prescribing in general, as it’s such an important contributor to driving better outcomes in healthcare today.

Learn how to get started with Electronic Prescribing of Controlled Substances (EPCS) with guidelines from the DEA, and get more information on Duo’s EPCS offering by visiting Duo for Healthcare.

]]>
<![CDATA[Letter From Duo’s CEO on Building the Right Kind of Security Company]]> dugsong@duosecurity.com(Dug Song) https://duo.com/blog/letter-from-duos-ceo-on-building-the-right-kind-of-security-company https://duo.com/blog/letter-from-duos-ceo-on-building-the-right-kind-of-security-company Press and Events Wed, 18 Oct 2017 10:45:00 -0400

The following is a letter from Duo’s CEO Dug Song, addressing the Duo team:

Dear Duo,

Today marks a significant financial milestone and point of acceleration for us as a company. This morning we announced our Series D round, raising an additional $70 million in funding that now values our company at $1.17 billion (our "post-money valuation").

This is a tremendous milestone for Duo, and one that we should all be very proud of. It is all of your hard work - both individually and as a team - that has driven our growth and success.

You can see the press release here.

So what does this all mean? In order to understand where we’re headed, it’s important to look at where we’ve been.

Building the Right Kind of Company

Cybersecurity has become the biggest geopolitical problem of our time. We are at a point where every organization in every industry is challenged with the overwhelming cost and complexity of securing a modern workforce.

When we started Duo seven years ago, the security industry was broken. The biggest problem wasn’t just about technology, but the culture of our industry. Jono and I set out to build the right kind of company in order to build security the right way:

  • We wanted to make security easy & effective, and we’ve done that by building the right kind of company to do so. We design and deliver security that gets out of your way and just works, versus an industry full of impractical ideas and frustrating experiences. Our industry-leading measure of customer satisfaction (68 Net Promoter Score - NPS) is a testament to our relentless focus on customers, and solving for their needs.
  • We challenged ourselves to be the kind of trustworthy partner that we ourselves would want to work with. We’ve done that by building the right kind of company to do so. By being transparent and ethical, reliable and dependable, and demonstrating expertise across the organization, our customers and partners have come to value us as much for our character as our competence.

Now, we must become the enduring organization we always set out to be, again, by continuing to build the right kind of company to do so. This means taking a long-term view of our business, and owning our future as a company with the potential to disrupt an entire industry. To do this, it’s not enough for us just to be ahead -- we need to stay ahead, and our investments in people, process, and technology will help us sustain and grow our leadership position in an increasingly competitive market.

Product News

Now, we don't talk about ourselves without talking about what we've done for our customers, and alongside this financial news we also announced exciting product enhancements with our latest press release!

This is a very exciting time for us at Duo! Thank you from the bottom of my heart for all that you do, every day, to earn and grow our reputation as the most loved company in security.

Best regards,

Dug

]]>
<![CDATA[Introducing: Duo’s Remote Identity Proofing for Healthcare and EPCS]]> stevew@duosecurity.com(Steve Won) https://duo.com/blog/introducing-duos-remote-identity-proofing-for-healthcare-and-epcs https://duo.com/blog/introducing-duos-remote-identity-proofing-for-healthcare-and-epcs Product Updates Wed, 18 Oct 2017 07:15:00 -0400

Summary:

  • Duo & Identity.com announce remote identity proofing for healthcare
  • Level of Assurance 3 (LOA3) credential service provider
  • Easy-to-use and privacy-first two-factor authentication and ID proofing solution

Healthcare is one of Duo Security’s fastest growing verticals, and the critical use case in healthcare has been Electronic Prescriptions of Controlled Substances (EPCS) with our Epic Hyperspace integration.

Electronic prescription signing helps patients and physicians with more convenient and accurate prescription delivery, and our physician users love the convenience of using Duo Push to quickly sign prescriptions using their cell phone instead of always carrying hardware tokens or badges.

EPCS is a critical use case for many of our healthcare customers, particularly as states including New York, Maine and Minnesota began requiring strong identity verification (via two-factor authentication) for electronic signing based on DEA guidance.

So our customers came to us with a challenge: make it simple for physicians to remotely fulfill the identity proofing requirements of EPCS, including two-factor authentication (2FA).

EPCS + Duo

Historically, our customers have used the institutional method for enrolling users into our service. In most cases, this means manual, in-person verification of a provider’s identity. Now, manual enrollment might work in inpatient settings where physicians can go visit an IT help desk, but it can also lead to personnel overhead, which can be particularly challenging with extremely busy physicians

However, how do you manually verify the identity of ambulatory physicians at outpatient clinics?

Over the last two decades, consolidation has been the name of the game in healthcare. No longer do hospitals maintain a single campus, they are now a network of outpatient clinics combined with inpatient hospitals, in some cases, across timezones.

Frankly, it’s costly for customers to send employees out to outpatient clinics over the course of weeks or even months to enroll all their users. This often means that the same hospital system will support both paper-based and electronic prescriptions at the same time, creating an administrative burden for physicians, nurses, and pharmacists.

Considering the complexity of two-factor authentication enrollment, it’s no surprise that scaling EPCS is a huge challenge for healthcare customers.

Privacy First

The DEA guidelines around the electronic prescription of controlled substances require identity proofing at Level of Assurance 3 (LOA3), meaning a high level of of confidence in the user’s identity.

At Duo, we have a philosophy of using the least Personally Identifiable Information (PII) possible. Our customers love that about us, as it makes implementation easier, while ensuring that privacy is a number one priority. We also believe that separating authentication from identity is the right security decision to reduce risk.

We began by exploring solutions with the major credit bureau agencies, but we quickly realized that instead of building an integration directly with consumer databases, we could find a strong partner to help us solve this problem.

Duo is proud to announce a partnership with Identity.com to bring instant, LOA3 identity proofing for EPCS to our healthcare customers.

With over a decade of experience delivering on-demand verification, fraud prevention and risk management solutions to over 55,000 businesses, Identity.com has proven themselves invaluable to this partnership. We share similar cultural values, from privacy-by-design product mindset to an unwavering focus on customer experience. We look forward to introducing you.

Here’s How It Works

Duo and Identity.com's ID Proofing Diagram

Who is Identity.com?

Identity.com powers informed trust decisions through instant identity verification and background check services. Their trust and safety platform delivers the fast, customized and scalable technology businesses need to combat fraud and reduce risk all on one platform. As a federally approved CSP, certified by the DEA and FICAM (Federal Identity Credential & Access Management), Identity.com’s healthcare customers gain peace of mind knowing their identity proofing solutions meet EPCS compliance requirements.

What About Other Industries?

We started this integration to solve healthcare use cases, but we’re excited about future joint opportunities with Identity.com.

Please stay tuned in the upcoming year, as we address additional use cases with identity proofing.

]]>
<![CDATA[Now Available: Secure Single Sign-On for All Duo MFA Customers]]> ubarman@duosecurity.com(Umang Barman) https://duo.com/blog/now-available-secure-single-sign-on-for-all-duo-mfa-customers https://duo.com/blog/now-available-secure-single-sign-on-for-all-duo-mfa-customers Product Updates Tue, 17 Oct 2017 08:55:00 -0400

TL:DR: Secure single sign-on (SSO) is available to all Duo MFA customers at no additional cost. Try it out by logging into your Duo Admin Panel. We also made SSO easier to deploy for Office 365 and several other cloud applications.

We have seen a tremendous customer response since we launched our secure single sign-on (SSO) functionality last year. Organizations have integrated 600+ cloud applications with Duo to provide users with convenient and secure access from anywhere using any device.

Today, we are announcing the availability of SSO functionality for all Duo MFA customers at no additional cost. With SSO, end-users will be able access all their cloud applications by logging in just once. You can integrate unlimited number of cloud applications with Duo.

What Does Duo’s Secure SSO Offer?

In addition, Duo’s secure SSO extends consistent and strong authentication to all your applications, whether on-premises or in the cloud. Users have the flexibility to choose any of the available authentication methods such as Duo Push, one-time passcode (OTP), SMS, phone callback and Yubikeys.

Additionally, you have the option to set separate security policies for each cloud application. For example, you can allow users to authenticate once a week when they access a less sensitive application such as Box, but force users to log in once a day for Salesforce or Workday. For advanced security policies such as preventing access applications based on out-of-date operating systems (OS), browsers, Flash and Java, consider the Duo Access edition.

How Can I Start Using Duo’s SSO?

Duo’s secure SSO functionality is available to you immediately:

  • Log into your Duo Admin Panel and navigate to the Applications tab.
  • Click on Protect an Application and search for the cloud application you want to test/deploy with SSO.
  • For help and support setting up SSO, start from your Duo Admin Panel and navigate to Applications > SSO setup guide.

Alternatively, if you need help or support setting up, feel free to reach out to us through duo.com/support.

Improved SSO & MFA for Office 365

We have also improved our SSO and MFA functionality for Office 365 users. Office 365 has been the fastest growing enterprise application in 2017. Users can access Office 365 from any laptop or mobile devices.

To provide secure access to Office 365 organizations, integrate with an MFA solution such as Duo. For MFA to work, users need to connect with client apps that support modern authentication, such as Outlook 2016 - learn more about modern authentication. If the user prefers an app that does not support modern authentication, such as iOS and Android mail clients, the application fails to function, making it challenging for IT admins to deploy any MFA solution in a mixed environment of devices and applications.

With our new Office 365 functionality, you can test and integrate Duo with Office 365 applications, allowing users to connect from any mobile or desktop client. Follow our documentation for integrating Duo with Office 365 to set this up in your environment.

New Native Support for Additional Cloud Applications

We are not stopping here. We want to make it easy for admins to deploy and secure any cloud application. To this end, we have added new native support for several cloud applications such as Workday, Igloo, Bugsnag, Aha, NetDocuments and HackerRank, in addition to many popular ones already supported such as O365, Salesforce, Box, Dropbox, Google, AWS, etc. To learn more about all cloud applications supported by Duo, visit Duo’s Documentation.

]]>
<![CDATA[Mobile Device Security Made Easy with Duo’s Security Checkup]]> tmccaslin@duo.com(Taylor McCaslin) https://duo.com/blog/mobile-device-security-made-easy-with-duos-security-checkup https://duo.com/blog/mobile-device-security-made-easy-with-duos-security-checkup Product Updates Tue, 17 Oct 2017 08:50:00 -0400

Employees tend to become frustrated with Bring Your Own Device (BYOD) security policies. Installing updates, applying security settings, and setting up device certificates can be difficult, confusing, and usually involves interacting with the IT help desk.

At Duo, we believe that security should be easy to use and friendly for all users with varying levels of technology proficiency. That’s why we created Security Checkup, a new feature available in Duo Mobile for iOS and Android devices.

Duo's Security Checkup

Prior to Security Checkup, to enforce security features of employees’ mobile devices, IT admins relied on heavy-handed solutions like traditional Mobile Device Management solutions (MDMs) which employees hated and were expensive, or spent lots of time holding security trainings nagging users to protect their devices. This feature is an opt-in tool to help your IT team scale to secure all of your employees’ devices that access corporate resources — and keep them secure over time.

Through Duo Mobile, Security Checkup ensures common and well-accepted security measures are in place on Android and iOS devices. IT admins don’t have to nag users, or resort to heavy handed MDM solutions — employees are empowered to understand the security health of their mobile device and learn about ways to fix any issues from within Duo Mobile.

When a problem is found, the user is prompted with simple-to-follow remediation instructions, specific to their platform. No need to bother stopping by the IT help desk just to figure out how to apply the latest OS update — Duo Mobile has them covered.

Duo's Security Checkup for Users

Security Checkup empowers employees to always know their personal security posture and have a helpful tool to maintain the security hygiene of their mobile devices they use to access corporate resources. Employees don’t have to interrupt their day with a trip to the help desk, IT admins can do less troubleshooting and spend more time focusing on bigger problems, and everyone is more secure — ensuring your company’s data and corporate resources are protected and safe.

Duo administrators can learn more about Security Checkup in our KnowledgeBase article, and turn the feature on for their Duo users by enabling Security Checkup in the settings page of their Duo Admin panel.

]]>
<![CDATA[New Enhancements to Duo’s Trusted Access Focuses on the Security Fundamentals]]> isharpe@duo.com(Ian Sharpe) https://duo.com/blog/new-enhancements-to-duos-trusted-access-focuses-on-the-security-fundamentals https://duo.com/blog/new-enhancements-to-duos-trusted-access-focuses-on-the-security-fundamentals Product Updates Tue, 17 Oct 2017 08:50:00 -0400

What does it take to be successful in protecting your organization from cybersecurity risks? Security utopia would be a completely isolated environment, on an island, protected by sharks with lasers (think Dr. Evil’s headquarters). Ninety-nine percent of companies don’t have this secret hideout and require a dynamic environment to keep up with the demands of their business and workforce. This makes security challenging.

These challenges range in complexity and severity. From making sure your employees are equipped to spot targeted phishing campaigns to ensuring your security strategy aligns to the business while reducing overall company risk. These are not easy problems to address and require diligent planning and disciplined execution. They also require the support and voice of the executive leadership team.

It may be overwhelming to determine where to start or what direction to take. Don’t worry, we have your back. Duo Security is in the business of helping you tackle your cybersecurity challenges with our innovative Trusted Access platform. Over the first half of 2017, we have continued our innovative approach to security and are excited to announce additional enhancements to our platform. These enhancements strengthen the value of our Trusted Access vision and will help you build and maintain a highly successful security program.

Our approach - provide a trusted platform focused on security, ease of use and reliability. Our platform allows you to reduce complexities and confusion caused by point solutions while providing you greater control and visibility in your environment. We have coupled this with a design belief that security technologies should provide increased productivity and a pleasant user experience.

Superior Access Experience

NIST 800-53 recommends security controls for federal information systems and organizations and is a great framework to reference when determining cybersecurity risk priorities. A key recommendation is to implement strong multi-factor authentication for local and remote access.

Common attacker methodology targets unsuspecting users with phishing campaigns. Their objective is to compromise user credentials and leverage them to pivot deeper into the organization. To compound this, four in ten users tend to use the same passwords for most websites, according to a recent study by ofcom.org.uk. Can you blame them? Your company may have countless applications that are independent and require unique logins. What this means, however, is that one compromised account could provide access across many different systems.

Duo’s Secure Single Sign-On (SSO)

A way to mitigate this risk is to provide your users with easy access to these resources via Duo’s secure single sign-on (SSO). This, coupled with multi-factor authentication, will ensure the stolen password is as valuable as sand in a desert. We now provide our secure single sign-on for free for all Duo customers. Curious to learn more about Duo’s SSO and how it can help? Check out Now Available: Secure Single Sign-On for all Duo MFA Customers for more information.

Username Aliases to Support Multiple Usernames

We understand that each environment is unique and complex and that a user may have multiple usernames across these different systems. These systems may not speak the same username language (email address, sAMAccountName, userPrincipalName).

We now support username aliasing, which allows each Duo user object to have a parent username with four aliases, providing a total of five usernames per person. Our recent article, Solving the Identity Crisis with Username Aliases provided more information around this new and exciting functionality.

This combination provides an organization with the capabilities for seamless and secure access management.

Increased Visibility Across Your Environment

The Center for Internet Security (CIS) provides a prioritized list of the Top 20 actions a company should take to mitigate known cybersecurity risks. The first, and highest priority, is an inventory of authorized and unauthorized devices.

Duo’s Trusted Endpoints Allows for Mobile Security Visibility

Duo’s Trusted Endpoints enables your organization to quickly and efficiently accomplish this by providing native integrations with your existing EAM and mobile device management (MDM) inventory systems, which allows you to mark devices as trusted or untrusted. You can then easily garner visibility into the devices in your environment by leveraging our dashboard or by pulling this information via API to your internal tools.

Some organizations are faced with the challenge of not having an inventory system for their mobile devices, especially in BYOD environments. Trusted Endpoints can now leverage the Duo Mobile application for visibility into the security posture of the mobile device.

This visibility can then be married with policies to ensure mobile devices meet security baselines including passcode, encryption and screen lock prior to granting access to any application. Our early customers have found this to be an ideal solution for visibility into authorized or unauthorized mobile devices. Their benefit has been twofold because it also allows them to enforce basic security requirements on mobile device access without needing an MDM.

Security Checkup for iOS and Android Devices

Duo's Security Checkup To help your users understand what is required of them to have an authorized mobile device, we have introduced Security Checkup, available through the Duo Mobile app for iOS and Android devices.

This empowers them to improve the security posture and to maintain the security hygiene of their mobile device.

It also provides a friendly list of common security options that are being checked by Duo, and if their mobile device adheres to them. If there are any issues, easy-to-follow instructions on how to remediate are presented.

Users will not need to bother stopping by the IT helpdesk. Learn more about Duo’s Security Checkup in Mobile Device Security Made Easy with Duo’s Security Checkup.

New Reports for Visibility into Deployment and Authentication

In order to provide you with a greater understanding into your Duo deployment and give you additional visibility into the users and systems in your environment, we will also be launching two new report types.

Deployment Progress provides you information on the state of your Duo enrollment across your organization. Quickly determine a breakdown of which users have successfully authenticated, have not authenticated but enrolled, not enrolled and your unused license count.

Duo's Deployment Report

Successful Authentication provides information about the success rate of authentications, authentication activity over a period of time, authentication methods and top applications. It provides a great high-level understanding of how your organization is leveraging multi-factor authentication and the way it is being used by your organization.

Duo's Successful Authentication Report

Both should be shared liberally with your leadership teams.

Improved End User Experience

We design and build our product for the end user, focusing on simplicity and ease of use. With the annual fall release of new mobile devices, like the iPhone 8 and X, and the Google Pixel 2, as well as users’ affinity for the latest and greatest mobile consumer technology, we are excited to announce Duo Restore. This enables Android and iOS Duo Mobile users to back up their Duo-protected accounts and easily recover them when they get a new device.

We Are Here to Help - It’s How We Do Business

The beginning half of the year has been very exciting for us and we look forward to wrapping up the second half of 2017 in typical Duo style. It is our hope that our Trusted Access platform and the enhancements that we have highlighted above will continue to help you protect and secure your environment. We know that security is challenging and we are here to help. We are confident that through a trusted partnership, we can help you realize your security goals.

As always, we are open to your feedback and appreciate the opportunity to learn from you.

]]>
<![CDATA[Explaining KRACK: A Critical Attack Affecting A Wi-Fi Security Protocol]]> thu@duosecurity.com(Thu Pham) https://duo.com/blog/explaining-krack-a-critical-attack-affecting-a-wi-fi-security-protocol https://duo.com/blog/explaining-krack-a-critical-attack-affecting-a-wi-fi-security-protocol Industry News Mon, 16 Oct 2017 00:00:00 -0400

KRACK stands for key reinstallation attacks, published in the paper, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 by Mathy Vanhoef at KU Leuven and other security researchers from imec-DistriNet, the University of Alabama at Birmingham, Huawei Technologies and Ruhr-Universität Bochum.

What is KRACK and WPA2?

KRACK refers to a group of 10 key vulnerabilities affecting WPA2, Wi-Fi Protected Access 2, the current best-practice protocol that is used to secure wireless networks. Depending on the configuration of the wireless network, the KRACK vulnerabilities could allow an attacker to eavesdrop on users’ Internet communications or tamper with the traffic being sent across the network itself.

While users typically protect against such attacks by using a password to connect to a secure network, KRACK can decrypt network data without requiring the attacker to know the Wi-Fi password.

The researchers provided a high-level summary of how it works: The attacker can abuse the way in which cryptographic keys are set up between a Wi-Fi client and the Wi-Fi access point (AP) by replaying one of the key setup messages. As a result, the attacker knows certain information about the key that should be secret. Once the key setup is manipulated, the mathematical attacks to derive the encryption key become feasible.

Once an attacker derives the key, they can read data sent to and from the Wi-Fi client. Depending on the cryptographic algorithms being used on the Wi-Fi network, the attacker could also forge messages between the client and the AP.

What is the Impact?

Attackers can use the vulnerabilities to read network traffic, which could include sensitive data like passwords, cookies, credit card numbers, emails, etc. This affects all devices that support all Wi-Fi configurations. For certain Wi-Fi configurations using TKIP or GCMP encryption (rather than AES), data can be written to the network and spoofed from/to a Wi-Fi client.

One point that is important to understand is that this is a protocol-level bug that isn’t found in just one implementation or product - it affects nearly all Wi-Fi devices in our homes and businesses, as well as the networking companies that build them.

As this is a protocol-level issue, it will likely require fixes on both the network infrastructure (AP) and client sides. Given the number of AP vendors and the amount of products shipped with the vulnerabilities, this will be a difficult issue to address. Some systems may never have a fix released, meaning they may stay vulnerable.

In particular, devices with embedded Wi-Fi (such as Internet of Things - IoT devices like baby monitors, televisions, etc.) may be the most at risk, as patches may be very slow to come out or may never be available from the manufacturers.

How Does It Impact Authentication?

As mentioned previously, KRACK allows attackers to decrypt Wi-Fi data without recovering the Wi-Fi network password, which means changing your Wi-Fi network password won’t mitigate the attacks.

Being on a secure Wi-Fi network won't be enough to keep usernames and passwords safe from attackers, who can use the intercepted credentials to log into your accounts across other websites and services. Using an app or TLS for internal communications will retain their confidentiality even over a vulnerable Wi-Fi network.

Using two-factor authentication (2FA) across your different login accounts can help prevent unauthorized login attempts due to stolen credentials, as it requires another method to verify your identity, in addition to a password.

What Platforms Are Affected?

During their initial research, the security researchers discovered that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by KRACK, according to KrackAttacks.com. However, it’s important to note that KRACK does not actually work against Windows and iOS, as noted by the research paper, although they are both still vulnerable to the group handshake attack.

According to the researchers, users on Linux or Android 6.0 (currently, 41% of all Android devices) or higher are especially at risk, as Android and Linux can be tricked into installing an all-zero encryption key. This just means it’s easier to decrypt their data packets (data transmitted over the web) compared to other platforms.

Caveats

While serious, there are a few important caveats to keep in mind regarding KRACK:

  • Aruba and Ubiquiti, sellers of wireless access points to large corporations and government organizations, already have updates available to patch or mitigate the attacks, according to Ars Technica. See the Cisco advisory.
  • This can be patched on the client and server side. There are Linux patches available, as noted by the Debian advisory and OpenBSD, which silently patched before embargo (see FAQ). Security Architect Kevin Beaumont recommends that organizations ask Wi-Fi network providers for patches.
  • While researchers have demonstrated the attack against an Android device, there is no publicly available code that can be used to carry out attacks in the real world. Kevin also states that realistically, the attack doesn’t work against Windows or iOS devices, but mainly Android devices that don’t get patched. This is noted in section 3.2 of the researchers’ paper - “Windows and iOS do not accept retransmissions of message 3…This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake.”
  • If you’re using an Android device, it might be best to turn off your Wi-Fi until you can patch for KRACK.
  • HTTPS, Secure Shell and other security protocols can be used to encrypt web traffic in transit between computers and network access points.
  • Move to AES encryption if you’re currently using TKIP/GCMP. This limits exposure to only the loss of confidentiality (though does not fix the vulnerability, just limits its impact).
  • While some recommend using a virtual private network (VPN), that may introduce even more hidden security risks, as a number of providers don’t encrypt traffic, leak data, or use third-party tracking to monitor users’ activity.

Image source: Juanandresrosero.makes.org

]]>
<![CDATA[The Beer Drinker’s Guide to SAML]]> gseador@duo.com(Greg Seador) https://duo.com/blog/the-beer-drinkers-guide-to-saml https://duo.com/blog/the-beer-drinkers-guide-to-saml Product Updates Thu, 12 Oct 2017 08:30:00 -0400

What Is SAML, and Why Does It Exist?

There’s often a knowledge gap in IT organizations when it comes to understanding how exactly SAML works. Many administrators and engineers are familiar with traditional network-based authentication protocols like RADIUS, LDAP and SSH, but reliance on SAML will increase as organizations continue to transition to cloud-based vendors and services.

This blog post is intended to remove the mystery from SAML, explain the mechanics behind some of the most common SAML use cases, and draw parallels to the unfortunately-fictional BaaS – Beer as a Service, that is.

Simply put, Security Assertion Markup Language (better known as its acronym, SAML) is a protocol for authenticating to web applications. Federating identities is a common practice that amounts to having user identities stored across discrete applications and organizations. SAML allows these federated apps and organizations to communicate and trust one another’s users.

SAML provides a way to authenticate users to third-party web apps (like Gmail for Business, Office 365, Salesforce, Expensify, Box, Workday, etc.) by redirecting the user’s browser to a company login page, then after successful authentication on that login page, redirecting the user’s browser back to that third-party web app where they are granted access. The key to SAML is browser redirects!

To combine analogies, if you think of single sign-on (SSO) as “one password to rule them all,” think of SAML as the glue that binds them all together.

SAML is most frequently the underlying protocol that makes web-based SSO possible. A company maintains a single login page - behind it an identity store and various authentication rules - and can easily configure any web app that supports SAML, allowing their users to log in all web apps from the same login screen with a single password. It also has the security benefit of neither forcing users to maintain (and potentially reuse) passwords for every web app they need access to, nor exposing passwords to those web apps.

SAML in Action

Let’s start with an example of Beer Drinker Bob, who wants to buy a beer at a concert. Beer as a Service:

  1. Bob first walks over to the Wristband Tent, where his ID is checked and a wristband is provided.

    • The Wristband Tent is the identity provider; its purpose is to verify Bob’s identity and make sure he meets the necessary criteria to get a wristband.
  2. Next, Bob walks over to the Beer Tent. The Beer Tent guy sees Bob’s wristband and hands him a beer.

    • The Beer Tent is the service provider; it’s providing the thing Bob ultimately wants access to: beer!

Beer Drinker Bob demonstrates SAML with Beer as a Service analogy

Now for an example with Software User Stu, who wants to log in to Salesforce. Software as a Service:

  1. Stu first navigates to a dashboard his company has configured, where he’s asked to authenticate (username + password + two-factor) and then can see all the applications he has access to.

    • The login process and dashboard are part of the identity provider; its main purpose is to verify Stu’s identity
  2. Next, Stu clicks the Salesforce icon and is signed into Salesforce.

    • Salesforce is the service provider; it’s the thing Stu ultimately wants access to.

And that’s SAML in action! Stu logged into his company dashboard and automatically had access to every cloud app his company uses, including Salesforce. When Stu clicked on the Salesforce icon, his company's identity provider generated an SAML assertion (a message asserting his identity), his browser navigated to Salesforce, and finally Salesforce validated that SAML Assertion and granted him access.

Behind the Scenes With SAML

In SAML lingo, what happened? Let’s start by defining some terms:

  • Identity Provider (IdP) - The software tool or service (often visualized by a login page and/or dashboard) that performs the authentication; checking usernames and passwords, verifying account status, invoking two-factor, etc. This was the Wristband Tent.

  • Service Provider (SP) - The web application where user is trying to gain access. This was the Beer Tent.

  • SAML Assertion - A message asserting a user’s identity and often other attributes, sent over HTTP via browser redirects. This was the wristband itself.

Step 1 Explained: Beer Drinker Bob Goes to the Wristband Tent, and Software User Stu Goes to the Company Dashboard

This step is where authentication by the IdP happens.

For Bob, authentication entailed the Wristband Tent checking to make sure he was who he said he was (his face matched the picture on his ID) and making sure he met the requirements (he was of drinking age).

For Software User Stu, authentication entailed checking his username and password, making sure his account was active, and invoking two-factor authentication to make sure he actually was who he said he was.

This is a good time to explain that it’s best to think of the IdP as a role in the SAML authentication workflow, relative to the SP. The IdP is simply an authority that the SP trusts. What specifically the IdP does to verify a user isn’t of concern to the SP. The SP only cares if its one-and-only IdP approves of the user and issues a SAML assertion.

What the Wristband Tent does to verify a drinker’s identity before giving out a wristband is of no concern to the Beer Tent - they only care if the drinker has a wristband or not. The Wristband Tent could require each drinker present a driver’s license, passport, proof of residency, turn their clothes inside out, then do 20 pushups.

It could even require they visit another tent - maybe a Necklace Tent - then return to the Wristband Tent wearing a necklace to get a wristband. The Beer Tent has no idea about any of this, nor does it care. The only concern of the Beer Tent is whether or not a drinker arrives with a wristband.

Again, what the IdP does to verify a user’s identity is of no concern to the SP, Salesforce. Typically, IdPs ask for a user’s credentials, but they can also ask for certificates, invoke two-factor authentication, require the user be on a particular network - and, you guessed it, they can even redirect the user somewhere else to have the user pass yet even more tests. What an IdP does to verify a user’s identity is configured by the user’s company and can be influenced (or limited) by capabilities of the IdP solution itself.

Thinking of the IdP as a role can be helpful for understanding that many products on the market today fulfill the role of IdP. Duo Access Gateway, Microsoft AD FS, Okta, OneLogin, Ping, Centrify and Shibboleth all serve the role of the IdP, to name a few.

Beer Drinker Bob Goes to the Wristband Tent, and Software User Stu Goes to the Company Dashboard

After the user is successfully authenticated, many IdP products then display a dashboard with tiles or icons of all the SPs available for that user to click on and be logged into. In our example, Stu clicked the Salesforce icon, which told his IdP to generate a SAML assertion for Salesforce that adheres to all of Salesforce’s requirements: what attributes need to be included in that assertion, and how it should be formatted for Stu to successfully gain access to Salesforce.

Step 2 Explained: Bob Goes to the Beer Tent and Stu Goes to Salesforce

This step is where verification of the SAML Assertion by the SP happens.

For Bob, verification entailed the Beer Tent checking to make sure his wristband was legitimate and issued by the Wristband Tent they trust.

For Stu, verification entailed Salesforce checking the SAML assertion to make sure it came from the IdP that Salesforce trusts. In addition to checking the authenticity and validity of the SAML assertion, Salesforce also looks in the SAML assertion to see who Stu is and who he should be logged into Salesforce as.

There are often many SPs configured to a single IdP. So while Stu went to Salesforce this time, maybe next time he’ll go to Gmail and his company dashboard (IdP) will generate a different SAML assertion that adheres to Gmail’s requirements. This is like having many different tents - a Wine Tent, a Liquor Tent, and our favorite Beer Tent - all who trust a single Wristband Tent. The Wristband Tent can issue a different wristband for each of the Wine, Liquor or Beer Tents depending on where the drinker wants to go.

IdP-Initiated vs SP-Initiated

IdP-initiated versus SP-initiated refers to where the authentication workflow starts. It’s often asked about because some service providers support SP-initiated logins while others don’t. What’s unique about the SP-initiated login is a SAML request.

An IdP-initiated login starts with the user first navigating to the IdP (typically a login page or dashboard), and then going to the SP with a SAML assertion. This is like first going to the Wristband Tent, then going to the Beer Tent after having received a wristband. The examples above where a user is logging into Salesforce and getting beer were both IdP-initiated.

IdP-initiated login

An SP-initiated login starts with the user first navigating to the SP, getting redirected to the IdP with a SAML request, then redirected back to the SP with a SAML assertion. This is like first going to the Beer Tent, getting sent over to the Wristband Tent because you don’t have a wristband, then returning to the Beer Tent when you do have a wristband.

Why does this matter, and what does it mean? What is a SAML Request? It matters because these redirects (go to the Wristband Tent, then come back to the Beer Tent) require that the SP issue a SAML request. A SAML request says, “This user is trying to log in, but they don’t have a SAML assertion yet. Please help them get a SAML assertion, then send them back here.”

However, not all SPs can issue SAML requests, which limits logging into that SP only as IdP-initiated. (And seriously, SPs, if this is you it’s time to join the party.) A SAML request is like someone going to the Beer Tent without a wristband, the Beer Tent writing a note saying, “This guy wants beer. Give him a wristband and send him back,” pinning the note to his shirt and shoving him toward the Wristband Tent. It makes it easier for people who like to drink beer, and that’s why we prefer it.

SP-initiated login

Configuring SAML

We’ve covered the basics of what SAML is, how logging in with SAML works, and a few of the most common SAML scenarios. Now, let’s talk configuration specifics: setting up the tents.

Configuration for SAML must be done in two places: at the IdP and at the SP.

The IdP needs to be configured so it knows where and how to send users when they want to log in to a specific SP. This is like setting up the Wristband Tent and making sure its workers know they’re checking IDs so that people can be served beer (and that they shouldn’t let minors have a wristband), and after they issue a wristband to point people toward the Beer Tent (rather than, say, a T-shirt Tent or out of the concert venue).

The SP needs to be configured so it knows it can trust SAML assertions signed by the IdP. This is like setting up the Beer Tent and making sure its workers know to look for wristbands that match the wristbands that their trusted Wristband Tent are issuing (as opposed to a friendship bracelet someone just happens to be wearing).

IdP Configuration

Specifications for a SAML assertion - what it should contain and how it should be formatted - are provided by the SP and set at the IdP. This is like the Beer Tent dictating what they expect to be on a wristband and the Wristband Tent being made aware of those expectations.

The following values must be set at the IdP for each SP, and there’s often quite a few of them. This is like a Beer Tent, a Whiskey Tent and a Wine Tent all trusting the same Wristband Tent. Often, IdP products can set these automatically behind the scenes, but as an admin you’ll need to provide at least some of this information:

EntityID - A globally unique name for the SP. Formats vary, but it’s increasingly common to see this value formatted as a URL.

  • Real Example: <EntityDescriptor entityID="https://beertent.com/concert">
  • Beer Example: “Greg’s Concert Beers”

Assertion Consumer Service (ACS) - The URL location where the SAML assertion is sent.

  • Real Example: https://beertent.com/saml/consume/
  • Beer Example: “Arrive at the left side of the Beer Tent. That’s where the line starts.”

ACS Validator - A security measure in the form of a regular expression (regex) that ensures the SAML assertion is sent to the correct ACS. This only comes into play during SP-initiated logins where the SAML request contains an ACS location, so this ACS validator would ensure that the SAML request-provided ACS location is legitimate.

  • Real Example: ^https:\/\/beertent\.com\/saml\/consume\/$
  • Beer Example: “Make sure you’re going to this Beer Tent and not some other tent.”

Attributes - The number of and format of attributes can vary greatly. There’s usually at least one attribute, the nameID, which is typically the username of the user trying to log in.

  • Real Examples:
    NameID Format
    NameID Attribute

  • Beer Examples:
    “The wristband shows your name is Bob Boozer.”
    “The wristband shows that was your first name and your last name.”

RelayState - Not required. Deep linking for SAML. This tells the SP where to take the user once they’ve successfully logged in.

  • Real Example: https://beertent.com/taps/lager/
  • Beer Example: “After the Beer Tent approves of your wristband, ask for a lager.”

SAML Signature Algorithm - SHA-1 or SHA-256. Less commonly SHA-384 or SHA-512. This algorithm is used in conjunction with the X.509 certificate mentioned below.

  • Real Example: SHA-256
  • Beer Example: “The wristband has a hologram, so you know it’s real.”

SP Configuration

The reverse of the section above, this section speaks to information provided by the IdP and set at the SP. This would be the information we provide to the Beer Tent to give them a way to validate that the wristbands drinkers arrive with were truly issued by the Wristband Tent they trust.

X.509 Certificate - A certificate provided by the IdP, used to verify the public key as passed by the IdP in the metadata of the SAML assertion. It allows the SP to verify the SAML assertion is actually coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed. Typically, it’s downloaded or copied from the IdP and configured by uploading or pasting it to into the SP.

Issuer URL - Unique identifier of the IdP. Formatted as a URL containing information about the IdP so the SP can validate that the SAML assertions it receives are issued from the correct IdP.

  • Real Example: <saml:Issuer>https://access.wristbandtent.com/saml2/idp/metadata.php</saml:Issuer>
  • Beer Example: “Only accept SAML assertions that are issued from a Wristband Tent that matches this description.”

SAML SSO Endpoint / Service Provider Login URL - An IdP endpoint that initiates authentication when redirected here by the SP with a SAML request.

SAML SLO (Single Log-out) Endpoint - An IdP endpoint that will close the user’s IdP session when redirected here by the SP, typically after the user clicks “Log out.”

  • Real Example: https://access.wristbandtent.com/logout
  • Beer Example: “Go to this location at the Wristband Tent to have your wristband removed.”

How Is SAML Different From Oauth and Web Services Federation?

We hear about these other SAML alternatives in passing, but how do they differ? Should you have an opinion on which one is best? Understand that SAML, OAuth, and Web Services Federation (WS-Fed) all vary technically, as well as how they’re best put to use.

  • SAML - Most commonly used by businesses to allow their users to access services they pay for. Salesforce, Gmail, Box and Expensify are all examples of service providers an employee would gain access to after a SAML login. SAML asserts to the service provider who the user is; this is authentication.

  • WS-Fed - Web Services Federation is used for the same purposes as SAML, to federate authentication from service providers to a common identity provider. It’s well supported with certain IdPs, like Microsoft Active Directory Federation Services (AD FS), but it’s not prevalent with cloud service providers. WS-Fed is arguably simpler than SAML for developers to implement, but its limited support among IdPs and SPs alike make it a tough sell.

  • OAuth - Most commonly used by consumer apps and services so users don’t have to sign up for a new username and password. “Sign in with Google” and “Log in with Facebook” are examples of OAuth in the real world. OAuth delegates access to a person’s Google or Facebook account by a third party.

Typically the app the user is signing into can directly read information from the user’s profile or take actions (like post pictures or make updates) on their behalf; this is authorization. This would be like going to the Beer Tent and instead of the Beer Tent sending Bob to the Wristband Tent, they ask Bob to hand them his ID and sign off that the Beer Tent workers can go over to the Wristband Tent on his behalf and represent him; he is authorizing them.

What’s more important is to look at prevalence of each technology for each use case. SAML is ubiquitous in the workplace for cloud-based apps, while WS-Fed is not. Conversely, OAuth is ubiquitous among consumer apps.

Microsoft & AD FS Terminology

Microsoft’s Active Directory Federation Services has their own terminology and approach to SAML, so it warrants a short explanation. Microsoft AD FS is an identity provider. Think of it as Microsoft’s solution to the Wristband Tent: tricky to understand if you’re new to the world of Wristband Tents, but very customizable.

  • Relying Party is the term that Microsoft AD FS uses to mean Service Provider.

  • Claims Rules is another term that only Microsoft AD FS uses. Claims Rules are just that: rules you can apply to alter how or when to invoke authentication. For example, an admin could set up a claims rule that only applies when a user comes to AD FS as they’re trying to get to Dropbox. Plus, it prevents them from using a mobile device, allowing that user to log in with a laptop or desktop device but not their Android or iPhone. Some IdPs other than AD FS can create similar rules, but AD FS allows for some of the most robust and complex rule creation.

  • ImmutableID is the Microsoft Azure AD equivalent of an ObjectGUID. It’s not specific to AD FS, but it’s worth a mention.

  • WS-Fed is similar to SAML and abides by many of the same rules. It’s a protocol specifically created by Microsoft and not widely supported by IdPs other than AD FS.

Troubleshooting Basics

The best way to troubleshoot SAML is the same way I recommend troubleshooting most issues: start with the basics.

  1. Scope - Is the issue affecting all users, or just a few? If no users can sign in, that’s an immediate indicator of a service interruption or misconfiguration. If you’re setting up an IdP and SP for the first time, it’s probably a misconfiguration.

  2. Experience - What is the user experiencing that indicates an issue? Is the user getting an error on the IdP login page? Or is the user getting an error generated by the SP after they successfully authenticate to the IdP?

Because SAML “happens” via browser redirects, it’s usually pretty straightforward to determine where a problem is occurring - just look at the URL. If a problem is occurring while on a URL belonging to your IdP, well, it’s probably an IdP issue. Same goes if it’s the URL of your destination SP.

Error at the IdP

For just a few users:

  • Is there an error message? Does it give us any clues?
  • Is the username and password valid?
  • Is the user account unlocked?
  • Is the user successfully passing two-factor authentication or any other authentication steps?
  • Try again. Clear cache. Try in an incognito window. Try on a different machine. Is there a way to isolate and identify the issue?
  • What do the logs show?

For all users:

  • Is there an error message? Does it give us any clues?
  • Is the user able to resolve the URL of the IdP and actually view the login page?
  • Is your IdP able to communicate with your identity store (like Active Directory)?
  • If configurable, keep the authentication flow simple and get one step working at a time, i.e., work to make sure primary authentication is working successfully before moving on to troubleshoot two-factor authentication.

Error When Arriving to the SP

For just a few users:

  • What is the error? Does it give us any clues?
  • Does the user have a valid username within the SP?
  • Check to make sure the username stored in the SP matches what is being passed in the SAML assertion. My favorite tool for this is SAML Tracer, which allows you to easily view the contents of a SAML assertion.
  • Does the user need to be in a specific group?

For all users:

  • What is the error? Does it give us any clues?
  • Are any users already provisioned within the SP?
  • What does the SP expect the SAML assertion to look like? What are the required attributes and their formats?
  • Do all users need to be in a specific group?

Now that we've talked about the ins and outs of SAML, there's just one thing left to say: Cheers!

]]>
<![CDATA[How User Personas Guide a Great Duo User Experience]]> mtk@duo.com(Mark Thompson-Kolar) https://duo.com/blog/how-user-personas-guide-a-great-duo-user-experience https://duo.com/blog/how-user-personas-guide-a-great-duo-user-experience Design Wed, 11 Oct 2017 08:30:00 -0400

Customers frequently ask us how our teams so consistently make Duo’s products easy to use. Part of the answer is that we continually employ several UX research methods to connect us with users. Key among them is user personas, something we’ve used since the company’s early days.

What Are Personas?

A persona is a realistic description of a typical user. Duo’s engineers, designers and product managers rarely talk about “users.” Instead, we talk about how our personas would use a feature. “End user” and “IT administrator” don’t sound very personal, and those terms aren’t typically part of our conversation — our teams more likely would discuss, “How would Gary respond to this instruction?” or “Would Eve really set up this feature?”

We have a set of five personas. Each has a name, goals, pain points and a bit of bio info. They were developed through extensive UX research with real users, such as interviews, surveys, ethnographic on-site visits and thousands of comments during usability testing sessions.

Who Are Our Personas?

Duo’s teams develop products with these five familiar folks top of mind:

Eve the End User

Eve the End User

“I know security is important, but honestly, it’s never a top thing on my mind.” She becomes frustrated when security features slow or block her from getting to the applications she needs. She often makes guesses about what’s secure or not, based on past experience.

Henry the Help Desk Specialist

Henry the Help Desk Specialist

“I make sure Eve can access the tools she needs to do her work.” He handles support tickets, either solving problems or escalating them to Gary in just a few minutes. He knows every second Eve can’t work is lost productivity and growing frustration.

Gary the Systems Administrator

Gary the Systems Administrator

“The company counts on me to keep technology running, keep it secure and keep Eve happy.” He works mostly on scheduled IT projects to improve his company’s services. Security concerns may be all of his job, or just a part of it.

Max the MSP Vendor Manager

Max the MSP Vendor Manager

“I need to provide efficient, easy products to my Managed Service Provider company’s clients that give great business value.” His IT expertise is similar to Gary’s, but Max focuses on how to serve customers who are outside his own company. Scalability and easy rollout are high priorities.

Helen the CISO

Helen the CISO

“I support lines of business by ensuring Eve has secure and usable access to resources.” As Chief Information Security Officer, Helen’s responsible for protecting her company against cyber threats and data loss, and for improving the security posture through IT projects she champions.

How Do Personas Work in Practice?

Personas are a vital part of our user-centered culture. New employees meet them during onboarding. They are mentioned by name countless times every day in meetings, whiteboarding sessions and one-on-one conversation. As part of our shared vocabulary, personas are much easier to remember and build empathy for than some generic “users.”

Personas really help humanize the people we’re designing for. At our meetings, everyone in the room knows who we’re talking about when we say “Gary” or “Eve.” - Noureen Dharani, product designer

Product development puts personas at center stage. Requirements identify them in user stories, such as: “As Gary, I can access reports in CSV format from this screen easily.” Discussions grow out of these stories, delving into specifics such as which layout or instruction or button label Gary will find easiest to use — and why. Long-term familiarity with a realistic persona invokes people’s innate ability to think more clearly about tangible actions than abstract ones.

“I use them to talk about scenarios that our features will be used in, and to understand the context of use,” says Lulu Tang, a product designer. “They’re great for communicating that across my teams, too.”

Product Manager Trevor Hough says: “A lot of my persona use is guiding developers to better understand how Duo can help Gary make Eve’s life easier and more secure. Team debates around that question so often lead us to great solutions.”

Persona-driven thinking extends through Duo’s UX interview research and usability testing efforts. We often recruit real-life Henrys, Eves, Garys and Maxes as participants. The personas provide a helpful shorthand while also reminding us who we’re designing for.

“Before I arrived at Duo, I hadn't worked much in an environment that bought into user personas, and wasn’t familiar with how valuable they are,” says Bryan Witherspoon, Principal Software Engineer. “But now, I'm not sure how effective I would be as an engineer if I didn't have some sort of user persona document available when designing or building a feature.”

Ensuring ease of use across varied types of users doesn’t happen by accident at Duo. Personas help us remain focused on providing the products our real users need. We’re pretty sure Gary would agree.

User Personas FAQ

How detailed are the personas?
They need to be easily scannable and understandable, so their details all fit comfortably on one sheet of paper. That means some serious prioritizing and editing in the research process.

Aren’t they just educated guesses about users?
No. Many user interviews shape each persona’s heart, supplemented by additional insights from our Sales, Support and Product teams and a slew of published data. The mix of qualitative and quantitative data make them trustworthy tools for our teams.

How long does the research process take?
Typically, about two months. It depends on how quickly researchers can schedule interviews with users. How do we socialize the personas across the company? We talk about them openly, by name, as they’re being researched, which gives teams a preview. When a persona is ready, we roll it out at department and team meetings. They often appear as characters in employee workshops and presentations.

Do you ever change them after they’re rolled out?
We’re always improving personas as we discover new aspects of our users’ needs, goals and pain points. This comes from usability testing, research projects, support questions, beta testing and conversations with users.

Why is empathy with users so important?
The better our product managers, designers and engineers can understand and relate to customers’ pain points and goals, the more likely they’ll be utterly committed to serving their needs in an awesome way.

What don’t personas do for Duo?
Although we love our personas, we know they are archetypes. They don’t perfectly predict behavior or attitudes. Specific, actual users also surely have additional goals not described in the persona. We use other research methods such as user interviews to learn that information as we plan, develop and support our products.

Want to take part in a user interview?
Our personas are primarily based on interviews with real users. If you’d like to participate in a user interview, please email uxstudies@duo.com and tell us a bit about yourself and which Duo products you use. (We also interview some non-users, too.)

Where can I learn more about creating personas?
Two resources we recommend are Personas Make Users Memorable for Product Team Members from Nielsen Norman Group, and A Closer Look At Personas: What They Are And How They Work, Pt. 1 from Smashing Magazine.

]]>