fudsec.com

Showcasing Fear, Uncertainty and Doubt from the Information Security Industry

The Value of Multi-Factor Authentication with Amazon Web Services

This week, O'Reilly author George Reese assesses the real-world applicability of a recently announced cloud security control.  Meaningful security control or pleasing the checklist brigade?  My thanks to George for taking time out of his busy schedule to contribute to fudsec - much appreciated.

By George Reese

Amazon recently released a new service called Amazon Multi-Factor Authentication (MFA) for Amazon Web Services (AWS). Amazon’s MFA enables you to configure your AWS account to leverage two-factor authentication for access to the AWS console. The AWS MFA is based upon the Initiative for Open Authentication (OATH) HMAC-based One Time Password (HOTP) specification.

AWS and OATH HOTP

Amazon Web Services is a cloud computing infrastructure provider that enables you to provision virtualized hardware resources (servers, firewalls, block storage devices, etc.) via a web services API and pay for those resources by the hour. A typical systems administrator of a customer using AWS will login to Amazon’s web interface to launch servers and perform other actions. Because the system is based on a web services API, a number of third-party solutions exist that provide extended functionality.

When you create an AWS account, you leverage your existing Amazon consumer account. Each AWS account is then associated with exactly one Amazon user. In other words, one account = one user ID = one person.

As more enterprises are adopting AWS to support their IT infrastructure, AWS has been seeing demands for multi-factor authentication to address corporate security policies that require multi-factor authentication when performing administrative functions over systems that house sensitive data. Multi-factor authentication is a solid business best practice for such systems. When AWS introduced MFA, they described it as “[MFA] should be especially attractive to our enterprise-level customers, but we expect customers of all types to value the additional security.”

Under MFA, I purchase a device from Gemalto that synchronizes with AWS and generates a one-time password. Any time I attempt to login to my AWS account after configuration, I must provide two factors of authentication:

  • My user ID + password (something I know)
  • The next token from my device (something I have)

Does AWS Realize the Benefits of MFA?

Paradoxically, AWS MFA is wrong for the customers for whom it was designed and perfect for everyone else. If you are a small business with a single AWS account managed by one system administrator, AWS MFA is for you. It costs just $13 to purchase the device and access to the service is free.

As I noted in the quote earlier, AWS did not design MFA for that audience. Instead, AWS developed the MFA solution for organizations that have multi-factor authentication as a checklist security requirement for administrative access to information security systems housing sensitive data.

MFA suffers from an inherent problem in OTP solutions like OATH HOTP that rely on a key shared between the device and the server: you have to have a new device for every system you manage unless those systems are tied together via some kind of single sign-on solution. Having to remember a dozen passwords is painful; having to carry around a dozen key fobs is unmanageable.

If you have a single AWS account, there’s no need to carry around a dozen devices—one works just fine. An enterprise—the target market for this offering—is likely to have multiple people managing multiple AWS accounts. Both the “multiple people” and the “multiple accounts” aspects of the AWS authentication system make MFA unsuitable to the enterprise market.

I’ve already addressed why multiple accounts are problematic—you have to carry around a new device for each account. Though single sign-on is a solution to the multiple device problem, AWS does not support single sign-on across different AWS accounts. If you have multiple accounts protected by AWS MFA, you need multiple devices.

The multiple people problem is much more significant. It too is related to the one AWS account = one user = one person structure of Amazon Web Services. While one person = one user is proper, the fact that one user = one AWS account makes it impossible for those people who need multi-factor authentication to meet other policy needs. In particular, you cannot implement both of the following security policies with AWS:

  • One person = one user
  • Redundancy in administrative roles

If you want redundancy in administrative roles, you must share an AWS user and the supporting credentials between at least two individuals. If you want to support one person = one user, you cannot have a backup administrator for your AWS account. For a large enterprise, opting to comply with the one person = one user is just not operationally possible with AWS. By design, however, AWS MFA enforces one person = one user because only one person can have the device tied to the user (and only one person can carry the device at any time).

One final issue with enterprise adoption of AWS MFA: it’s US-only. In other words, businesses with systems administrators outside the US cannot use this service. Furthermore, no timeline exists for availability outside the US.

The Bottom Line

Given the current design of AWS authentication, AWS MFA looks like a checklist item poorly suited to the needs of people with the checklists (enterprises). AWS would have been better off implementing an SMS-based system. Though such a system supports attack vectors that the AWS system lacks, it is ultimately much more practical for enterprise IT operations.

I’m Not Secure and You Can’t Make Me.

It's that time again, and Kevin Riggins serves this weeks fudsec dish.  If you have any influence over infosec purchasing decisions where you are, you should read this.  My thanks to Kevin!

By

Kevin Riggins

Do a Google search for the following: 

"make.*secure" +"press release" computer network 

Go ahead, I’ll wait. 

When I sat down to write this piece, I searched for that phrase. My results? 303,000 items. Granted, many of them have nothing to do with information security, but the first three in my search results did. 

It seems like I see advertising or a press release just about everyday that spouts some sensationalist drivel about how you are going to get hacked in the next five minutes. This is followed up with “just install our product and you will be secure.” These ads and press releases are aimed at both individuals and companies. 

First, I want to make something clear. I am well aware that if you stick an unprotected machine on the internet, it is not going to last 60 seconds, let alone 5 minutes. I am not arguing that the threat isn’t real.  

The problem I have is the use of fear to sell an idea that is patently false. That idea is that any product can make a system or network secure. There is exactly one way to make a system or network completely secure. Keep it turned off. 

The best we can hope for is to increase the security of our systems and networks by:

  • making risk appropriate decisions about what technologies to implement
  • making appropriate design decisions, again, based on risk
  • ensuring that the products we use and build are engineered in a manner that addresses known issues and resists the introduction of new vulnerabilities.
Yup, I said it, risk management, intelligent design, and secure development will make your environments more secure. They will NOT however, MAKE you secure. Nothing will. Sorry.

Knowing Walls from Speed Bumps

This weeks guest post is from Balazs, an ex-senior malware analyst, who - despite his career change - remains interested in the field of information security. In his own words, "my goal is to bust FUD and provide solutions for preventing successful attacks (as opposed to selling products)".  I'd like to thank Balazs for encouraging us all to see the big picture and give recognition to his anti-FUD efforts (check his blog - link below) - fudsec salutes you!

It is a sad fact that in the security industry most of the people most of the time concentrate on point solutions and fail to consider the general impact those solutions will have and how easy is to circumvent them (how future proof are they). While the "I have this problem NOW" mentality is probably built into our genes (and accentuated by marketing), it takes only a little effort to research ones options more thoroughly and it can have a big (positive) impact in the future (much like counting to ten before saying anything one might regret).

Example: suffering a malware outbreak, company X calls up Anti-Virus vendor Y and asks desperately: "Do you detect malware Z, which is spreading in our network? We already have another product, but it doesn't detect it!". And so the decision is made to replace the old product with the new product, without considering the fact that for each Anti-Virus product there are tens of thousands of malware which they miss, and it just so happens that in this case the first product detected while the second product missed the particular malware, but it could easily have happened the other way around.

Taking a step back the company could have identified key issues which lead to the malware infection in the first place, and which - if corrected - could reduce the probability of the incident happening much more drastically than swapping out one AV product for an other:
- the ability of users to run arbitrary programs (which could be prevented by using a whitelisting solution)
- autorun being enabled (which could be disabled trough Group Policy, and in addiction solutions for disabling the USB ports could be used)
- the ability for users to write to the file-server (which could be prevented by clarifying the requirements for the given file-server and locking it down according to the policy)

Second example: at BlackHat USA 2009 a researcher suggested that because he was able to implant a bootkit (a rootkit running from the boot sector) while running under Windows with Truecrypt installed, Truecrypt is broken. He also suggested a simple patch (for Truecrypt to deny write access to the MBR) and was upset when his patch was rejected (you can find part of the discussion on his blog - http://peterkleissner.com/?p=11 - where all the arguments were already detailed, but he remains unconvinced).

Again, let us take a step back and check our assumptions:
- we are talking about code under Windows which is able to write to arbitrary locations on the harddisk. This already supposes that it has enough privileges to execute code in kernel mode. Any measures taken by Truecrypt could be easily circumvented by patching the Truecrypt driver on-the-fly
- second of all, if the code already runs in the live Windows session, it has full access to the decrypted data. It doesn't need the Truecrypt password at all! It can simply register itself to be started when Windows starts up and upload all the sensitive data bit-by-bit
- finally, even using BitLocker in a TPM-enabled environment (which is the other suggestion by him), there is still the threat of hardware keyloggers (which could be embedded directly in the keyboard - see the ''Reversing and Exploiting an Apple® Firmware Update" talk from BlackHat USA 2009)

Seeing the big-picture takes a considerable amount of knowledge and understanding about the internals of how computers and software operate. One can't expect any help from the sales persons either because, even if we abstract away from the fact that he is trying to sell you the product, most probably he doesn't know. Just try to find out from a whitelisting vendor if she is doing the enforcement of the rules in user mode or in kernel mode. Knowing walls from speedbumps can be very hard because both have the effect of stopping the attack if they are of low enough speed. Curmudgeons can help, but as can be seen from the second example, they aren't correct always either.

What is the conclusion? Do your own research. Distrust grandiose claims, whoever makes them. And eliminating the root of the problem is in most of the cases simpler, cheaper and effective in combating a larger set of issues, than just buying a "solution".