During the last days, some of our guys (including me) had some great days in Dayton. Rene, Christopher, Hendrik, Sergej, and me flew in to give workshops and presentations at Day-Con as well as to compete in the infamous PacketWars game. While Day-Con is a one day event, the two days before the conference comprised workshops on secure iOS integration (given by Rene) and IPv6 security (given by Christopher). Since the overall topic of the conference was trust, Rene gave a keynote on broken trust which was based exemplary trust analysis, development of a trust metric, and different trust factors. Those trust factors were also used in my talk about evaluation methodologies for cloud service providers (regular followers will recognize some of the content of both talks from differentposts 😉 ). There were also talks from Sergey Bratus, Graeme Neilson and Angus Blitter. While Sergey proposed a sound (not to say academic 😉 ) definition on the classification of vulnerabilities and their connection to turing complete input languages, Angus gave an introduction to PowerLine technologies and laid out, that these technologies still suffer from naive assumptions about trusted networks (he also refered to this). The day after the conference, the ERNW Allstars had to defend their championship title in PacketWars. Since the first battle was scheduled for 10AM, we had quite some time to tan in the sunny 30°C weather, recover from the conference and prepare the expected victory celebration (some of you might remember some “Champagne tradition” from Troopers). In face of this motivation, we rushed through the 3 battles and were able to score first place second year in a row. At this point, kudos to the two other participating teams who gave us a tough battle, especially during the reversing challenges.
We recently performed a Proof-of-Concept (PoC) implementation of certificate based auth with iPads in some large environment. So far the focus has been mainly on WLAN access; VPN and EAS authentication are going to follow in the next step.
As we figure that the topic might be of interest for some of you, we’ve extracted a certain, not-too-customer-specific part of the deliverable and converted it into an ERNW newsletter. Special thanks go to Rene Graf for leading the project! 😉
Of course, this stuff is going to be covered in much more detail in the Troopers12 edition of our “iOS Security Workshop” (see here for the agenda of this year or here for a German version of the current one).
After having introduced the basic elements of our concept of trust, control and confidence in this post, today I’ll try to strengthen your (and maybe even my own as well ;-)) understanding of these ideas by applying them to another candidate, that is Dropbox. Hence this post is mainly about performing a certain analysis method to some object; conclusions as for the question if Dropbox is suited to be used in enterprise environments processing sensitive data are out of scope and are left entirely to you, the valued reader.
Two more preliminary remarks might be helpful to further understand the direction and intent of this post:
a) I don’t have any practical experience with Dropbox. I don’t use it personally and at ERNW using it for company-related data would require a risk acceptance, which – probably not too surprisingly – no company member has ever filed (and which would have a quite high likelihood of being turned down by the CEO anyway ;-)). In other words: I can’t imagine any occasion we’d use cloud based storage services for any of our data. It’s just that – given our idea of “highly skilled, thoughtful and responsible humans working here” – we don’t use terms like “xy is strictly forbidden” very often…
So feel free to jump in by PM or comment to this post if this stated lack of practical experience has lead to wrong conclusions or factual errors.
b) This post is not about blocking Dropbox in corporate networks by technical means (which – afaik – is relatively easy compared to, say, blocking Skype, as DB seems to operate mainly from a well-defined /24 network range). Doing so (technically blocking DB on corp firewalls) would not solve the underlying problem of potentially misplaced trust (or ignorance) and might just lead to yet-another-risk-acceptance popping up on the ISOs’ desks (I know, I know: some of you would be happy if at least a risk acceptance existed for DB within your organization…). And, of course, the corp_fw way would not address the aggregate problem of running Dropbox on mobile devices (at least assumed that no cloud based proxy services are in use for those, which is currently the case in most networks I know).
However this post is about asking a certain set of questions and clarifying some company’s or service’s attributes to induce a reasonable discussion about the exact company’s/service’s suitability for processing sensitive assets. To us, such an approach is aligned with our understanding of an ISO as a trusted business advisor (as opposed to the “paranoid pitbull” or “unfortunately unheard master of governing guidelines” mission understanding of ancient times).
Now let’s have a look at the object of today’s trust exercise, that is Dropbox. Founded in 2007 and fueled by US$ 7.2 million venture capital (as of this Forbes article) the California-based company provides cloud-based file storage services with a simple GUI and some nice collaboration capabilities for groups of users sharing files. The description in the CrunchBase profile goes: “Always have your stuff, wherever you are”. A technical overview can be found in this paper recently presented at USENIX Security.
Transparency – “How much do we know about $TRUSTEE?”
Consistency – “What happened in the past?”
Integrity – “[How] Do we notice if $TRUSTEE changes?”
Value of Reward – “What do we gain by trusting?” (that’s the one that Ponzi schemes are based on)
Components – “Which resources does $TRUSTEE rely on?”
Porosity – “How separated is $TRUSTEE from its environment?”
Applying all these to Dropbox might yield the following answers:
While this might seem a simple one given Dropbox is a not-too-big company presumably held by their founders and some investors/venture capital providers (plus maybe employees holding stocks or options or sth) it should be noted that, more or less obviously, there’s more entities in the overall picture => see below at section “Components”.
Usually this one is hard to apply to B2C scenarios, so I’ll skip it here.
Honestly, as I’m not a user of their service I don’t have a ultimate attitude here. However from a trust analyst point of view I just note there’s a number of people out there who think that DB failed severely in this regard. And there’s a (still pending?) complaint for injuctive relief filed to the FTC stating that Dropbox “continues to make deceptive statements to consumers regarding the extent to which it protects and encrypts their data.”
So overall this one (transparency) seems at least debatable; see also discussion on factor “Integrity” below.
d) Consistency: well, probably most of you know that three months ago DB suffered a breach which exposed all online storage lockers to anyone entering any password for ~ 4 hours.
Strictly taking the “consistency road” this does not contribute to their trustworthiness, from my humble evaluation.
This post from the Hunton & Williams privacy blog provides an overview how Dropbox’ security statements (on its website) changed over time. I tend to assume the majority of users is/was not aware of those changes. In general it seems that one of their main communication channels is their blog. Which – given that most of you probably read a blogpost right now 😉 – might certainly be a valid channel… for B2C scenarios in modern times at least. Not sure if this is the right channel for the security properties of corporate information assets though.
This is a particularly interesting one. As obvious as this may be, most users are probably not aware that DB does not operate the servers providing the service themselves. To the best of my knowledge the (Dropbox) service heavily relies on Amazon S3 and EC2 instances, in a certain setup that Mulazzani et.al., in their paper, comment on as follows: “However, the fact that encryption and storage is done at the same place seems questionable to us, as Amazon is most likely able to access decryption keys”.
We can’t provide an evaluation here as we do not dispose of any information as for clear demarcation lines on the financial (e.g. who might potentially influence DB’s decisions due to simple ownership of shares ;-)) or organization/infrastructure (which 3rd parties actually provide which type of supporting service, e.g. do they share their office space with other parties in a business/office incubator etc.) sides of things.
So, once again, taking a structured approach when evaluating some party’s trustworthiness (to counter the fact that trust – by it’s very (Diego Gambetta’s) definition that we used in the initial post – is sth subjective) leads to – hopefully – interesting insight and results. Still, in this particular case, there’s another potential use of this way of looking at things: when dealing with (business’ desire to use) Dropbox in your organization, you might convert this points into a simple (one slide ;-)) checklist containing questions like
Do you know who owns the company Dropbox?
Do you know where their servers are located?
Do you know if they own the servers providing the service themselves or who else does this on their behalf? And where the servers of that “other party” are located? Which legislation applies there?
Do you know that they just suffered a breach temporarily allowing anyone in the world to access any one of its 25 million customers’ online storage lockers, simply by typing in any password?
Do you know who owns the keys necessary to decrypt data stored under your account?
[in case you like to promote your concerns the FUD way – which we do not like or recommend – you might add: “If you were a well-funded attacker, maybe from an emerging market, would Dropbox be an interesting target for you?”…]
If some people within your organization are still going to use DB for corporate data then, well, that’s an “educated decision by business” [no, no, the quotes are not put here to hint there might be a contradictio in adjecto ;-)].
Stay tuned for more stuff to come in this series & have a good week,
btw: we’ll probably have a talk about Dropbox at next year’s Troopers which takes place on 03/21 and 03/22 2012 in Heidelberg.
… the corrupt DEA agent in Luc Besson’s great movie “Léon (The Professional)”. I’m sure quite some of you, dear readers, know the plot…
Just before the final shootout, when sending the first men of the NYPD ESU team into Léon’s apartment, he tells them to “Be careful!”. After learning those men got killed he just comments: “I told you”.
[btw: before yelling to bring “EEEEEEEVERYONE!!!!”, as those familiar with the piece will certainly remember ;-)].
I’m fully aware that I risk playing “the arrogant scumbag card” today and that it’s generally not very nice to refer to one’s own earlier statements with an “I told you” attitude (especially if harm was caused to some party), but this is exactly how I feel when reading these news. And – pls believe me – it’s an expression of utmost despair.
How often do organizations have to be told that running Adobe Flash might not be the greatest idea in the world, security-wise? How many statistics like this one (see section “Vulnerabilities” in the bottom part of it) have to see the light of the world until people realize that (quoting from this blogpost) “running Flash on corporate desktops is simply asking for trouble. Asking for trouble loudly. Very loudly.”?
When we wrote this document on configuring IE8 securely we pointed out that using Adobe Flash required a risk acceptance, from our perspective. Man, how I was attacked! for this very statement afterwards in the customer environment that document was initially developed for. I’ve since mentioned Flash in this blog here, here and here.
Furthermore we’ll include a talk on Flash in next year’s Troopers line-up, I promise. And be it only to avoid this post sounding like a crusade of a bitter old man… (yes, this was a wordplay referring to some character from the movie ;-).
A few days ago the European Network and Information Security Agency (ENISA) published this quite interesting document with the exact title. Here’s what it covers:
“The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.”
Just read through it and while I’ve never been a big fan of STRIDE (mainly due the application centric approach which simply is not my cup of tea) I have to say it’s applied elegantly to the “app ecosystem” described in the paper.
The doc somewhat accompanies this one titled “Smartphones: Information security risks, opportunities and recommendations for users” (released by ENISA in late 2010), which is a valuable resource in itself.
Overall excellent work from those guys in Heraklion, providing good insight from and for practitioners in the field.
A few weeks ago, I released version 0.9 of a web application testing tool called tsakwaf (The Swiss Army Knife for Web Application Firewalls) together with an ERNW Newsletter about web application firewalls. tsakwaf is based on perl and supports fingerprinting of some supported WAFs and code generation methods to circumvent filter rules. Today, version 0.9.1 will be released, which adds SSL support for the WAF fingerprinting function (Big thanks to Simon Rich!) and a bug fix regarding the detection of WAF reactions which may lead to false positives. Additionally, I’m happy to announce that at least one talk at next year’s Troopers will cover attacks against WAFs (like this one from the 2009 edition) . So mark your calendar – Troopers12 will happen on 21st and 22nd March 2012, with the usual workshops before the conference and the round table sessions the day after – and enjoy playing with tsakwaf!
I’m currently involved in a “Remote Access Security Assessment” and you might be wondering what exactly this means. Well, so did we. At least to some degree (btw: last year we provided some notes on types of security assessments here).
It happens quite often we’re brought into an organization to perform “a security assessment” of “some item” (“our network”, “that new procurement portal”, “the PKI” etc.). It happens as well the customer does not have a very clear idea of the way such an assessment should be carried out (telling us “you are the experts, you should know what to do”). Or the five people from the customer’s side present in the kick-off meeting have five different concepts (ok, four. as one of them only wants “to get that damned assessment done so we can finally go live”) and we end up moderating their arguments on what should be tested, how this should be done, when this is going to happen, which type of report format is needed (obviously, there’s different ones, depending on the goal/scope/methodology of the assessment…) etc.
In such “vague cases” we usually define a set of (~ 10) categories/[security] criteria to be fulfilled by the item in question, based on different sources like the organization’s internal policy framework, potentially the project-to-be-assessed’s security goals, relevant standards and “common security best practices” (often the latter only to a small degree as we have a mostly risk based security approach which does not necessarily fit very well with [assumption-based] “best practices”; more on this philosophical question in yet-another-post ;-))
For example, in the case of a “Firewall & DMZ assessment” these categories/criteria could include stuff like “Dedicated LAN switches” (from $ORG’s internal guidelines), “Logging of denied packets” (same source), “Secure management” (from ISO 18028-3), “Scalability” (based on business needs as for $ITEM) or “Proper vulnerability mgmt” (ISO 27001).
We then perform a combination of assessment methods to obtain the necessary information to evaluate those categories in terms of “fulfilled”, “major/minor non-compliance”, “leads to relevant business risk”, “documentation missing” and the like.
Figuring the individual categories/criteria which are suited to the customer, their needs and the assessment’s (time, budget, political) constraints usually is intellectually challenging and thus “hard work”. Still, this approach (hopefully ;-)) ensures we can “answer the customer’s relevant question[s] in a structured way and with reasonable effort”.
So why do I tell you all this (besides the implied shameless self-plug)? I faced the very situation in the mentioned “Remote Access Security Assessment” and made some observations that I think are worthwhile sharing.
Let’s have a look at the potential sources for the approach laid out above:
a) internal policies: if I told you that “no formal document written, say, in the last five years, covering the topic and/or available to the people engaging us” could be identified, you wouldn’t be surprised, would you? 😉
[ok, I didn’t give you any details as for the customer… but does it really matter? how many organizations do you know which have an up-to-date “remote access policy”… I mean, one that actually provides reasonable guidance besides “all remote access must be secured appropriately” …]
b) standards & “best practices”
To discuss these I’d first like to introduce some level of abstraction shortly – regular readers of this blog might remember my constant endeavor to “bring structure into things”- by breaking down “a remote access solution” to the following generic entities involved:
network transmission incl. protocols & algorithms
Traditionally there have been 3-4 relevant standard documents in the remote access space, that are ISO 18028-4 Information technology — Security techniques — IT network security — Part 4: Securing remote access (latest version from 2005), NIST SP 800-77 Guide to IPsec VPNs (2005), NIST SP 800-113 Guide to SSL VPNs (2008) and potentially revision 1 of NIST SP 800-46 Guide to Enterprise Telework and Remote Access Security (Rev. 1 published in June 2009).
[Of course, feel free to notify me by PM or comment on this post if you’re aware of others].
Those documents are mainly focused on the first two of the above “abstract elements”, that are gateways and network transmission, which results in lengthy discussions of gateway architectures or protocol specifics and ciphers. It becomes clear that back then the main threats were considered to be “attacks against gateways” or “attacks against network traffic in transit” (whereas today the main risk is probably “unauthorized physical access to endpoint”, after loss or theft of device/smartphone).
But times have changed, and in 2011 I tend to assume that these two elements (gateways, network transmission) are sufficiently well handled & secured in the vast majority of organizations. Ok, just when I write this I somehow hesitate, given I recently worked in an environment where the deployed gateways (based on the – from my perspective – market lead SSL gateway solution) were configured to support stuff like this:
AES256-SHA – 256 Bits
DES-CBC3-SHA – 168 Bits
AES128-SHA – 128 Bits
RC4-SHA – 128 Bits
RC4-MD5 – 128 Bits
DES-CBC-SHA – 56 Bits
EXP-DES-CBC-SHA – 40 Bits
EXP-RC2-CBC-MD5 – 40 Bits
EXP-RC4-MD5 – 40 Bits
AES256-SHA – 256 Bits
DES-CBC3-SHA – 168 Bits
AES128-SHA – 128 Bits
RC4-SHA – 128 Bits
RC4-MD5 – 128 Bits
DES-CBC-SHA – 56 Bits
EXP-DES-CBC-SHA – 40 Bits
EXP-RC2-CBC-MD5 – 40 Bits
EXP-RC4-MD5 – 40 Bits
Not that I regard this as a relevant risk, it’s just interesting to note. I mean, it’s 2011…
Back to track: so, while gateways and protocols might no more constitute areas of “deep concern”, nowadays “the endpoint” certainly does. When the mentioned standards were written, endpoints were supposed to be mostly company managed Windows systems. In the meantime most organizations face an “unmanaged mess”, composed of a growing number of smartphones and tablets of all flavors, some – to some degree – company managed, quite some predominantly “free floating”.
And unfortunately there is – to the best of my knowledge – no current (industry) standard laying out how to handle these from a security perpective. Which in turn means once an “authoritative framework” is needed (be it for policy reasons, be it for assessments using the approach I described above) there’s nothing “to rely on”, but this has to be figured by the individual organization.
To get a clearer picture I went out contacting “some of my ISO colleagues” in the “how do you handle this?” manner. In the following I’ll lay out “the results how mature organizations address the topic”, together with some recommendations from our side, based on our usual approach to balance security and business needs.
In the end of the day the task can be broken down to the question: “which types of endpoints should be allowed which type of access to which (classification level of) data?”.
To answer this one in a comprehensive and consistent way a number of factors has to be taken into account:
different types of endpoints.
different types of “access methods”.
classification of data to be processed.
potential prerequisites for certain use cases (type of authentication, employee signing an acceptable use policy [AUP], additional [technical] security controls on endpoints and the like).
Classifying types of endpoints
I personally think that the “traditional distinction” between (just) company-managed and non company-managed – which is used for example in ISO 18028-4 and NIST SP 800-113 – does no longer work, but that it makes sense to differentiate roughly between three types of endpoints. To characterize those I quote from a policy I wrote some time ago:
“Company managed device
Any device owned and managed by $COMPANY, e.g. corporate laptops.
Private trustworthy device
Any device that is owned by an individual employee which is used solely by named invidual and which is kept in an appropriate state as for security controls (up-to-date patch level, anti-malware protection and/or firewall software if feasible etc.). It might be (partly) managed by company driven controls (e.g. configuration policies).
If used for local processing of restricted data appropriate encryption technologies protecting said data must be in place.
In no instance shall any competitors, business partners, and/or other business-relevant parties be allowed to physically access such a device, even if such persons are otherwise related to the employee or are personal friends or acquaintances of the employee. Furthermore information classified ‘strictly confidential’ shall never be processed on this type of device.
All other devices, for example systems in a cyber café or devices in an employee’s household which are shared with family members or friends.”
Pls note that both NIST SP 800-46r1 (where the party responsible for the security of the device is taken into account. and this one can be: organization, teleworker, third party.) and Gartner (classifying into “platform”, “application” and “concierge” types of services) use a similar three-fold classification approach.
By “access method” I mean the way the actual data processing is performed. Let’s classify as follows:
“full network access” by means of a tunneled IP connection, provided by a network stack like piece of code. This is where the traditional full-blown IPsec or SSL VPN clients come into play.
“application based” access. This includes all HTTP(S) based portals (with MS Outlook Web Access [OWA] being the most prominent example) and the portals provided by typical SSL VPN gateways that enable users to run certain applications (MS Outlook, SAP GUI, File Browsing and the like).
“restricted application based”: same as above but usually without file exchange between remote network and local system, e.g. OWA without attachments, or remote desktop access without use of local drives, no copy+paste in TS client etc.
“(just) presentation logic”: here no actual data processing on the endpoint takes place. The best known example is probably Citrix based stuff, in different flavors (ICA client, Citrix Receiver, xd-agent et.al.).
Classification of data to-be-processed
Another aspect to take into account is the classification of the data that is allowed to be processed on a “remote device”. While this may seem a no-brainer at the first glance, in reality this is a tricky one as most organizations do not dispose of a (“widely used in daily practice”) data classification scheme anyway and usually there’s no file (other information entity) attributed meta-information that allows the easy identification of its classification level, together with a subsequent enforcement of technical controls (which, btw, is one of the main reasons why DLP is so hard to implement correctly. which could be discussed in more detail in another post 😉
And, of course, for an employee who has access anyway technically it’s usually easy to process higher classified data “than allowed”. The most common approach addressing this is having the employees siging AUPs prohibiting this/such type of handling, combined with some liability in case of breaches of such data (this approach, again, might be a minefield in itself, depending on the part of the world and associated juridical system you’re [located] in ;-)).
For the following discussion let’s assume that organizations use a scale of four classifications/ classes designated SC0 to SC3 (where SC = “security class” or “security classification”) with 3 being the highest (e.g. “strictly confidential” or “top secret”) and 0 being the lowest (e.g. “public”, “unclassified”).
Prerequisites for certain use cases
Frequently additional organizational or technical prerequisites for certain use cases (e.g. types of devices, potentially in combination with certain access methods) are induced. In this space can be found:
Acceptable Use Policies (AUPs) prescribing what can or should be done, which lay out “prohibited practices” (that might still technically possible, see above), the handling of backups, the separation of business and private use etc.
the level of authentication required for certain usage scenarios.
additional security controls on the endpoint (anti-malware, local firewall, local disk/file/container encryption and the like), with their presence on the endpoint potentially verified by some “host integrity checking” technology, e.g. “UAC” in Juniper space. In this context it should be noted that in most environments UAC or similar approaches from other vendors do not provide an actual security benefit (“enforce that only a trustworthy and secure endpoint can connect”) but simply differentiate between “company managed” and “unmanaged” in the way “look for a certain registry key and if present assume that’s a company managed device” (“no idea if the associated piece of security software is really present, let alone correctly configured, not to mention that it provides any actual security benefit”…).
Putting it all together
Now, putting all this together I came up with the following table. It displays what we feel “is common best security practice” nowadays for handling remote access (endpoint) security, balancing business and security needs:
Type of device
Classification of data (allowed) to be processed
Allowed access methods
usually all, some organizations do not allow highest on mobile devices at all
private trustworthy (which means, as of definition, disposing of appropriate capabilities/controls)
depends. some organizations do not allow highest in this scenario. We recommend: no SC3 here.
usually all, but “application based” preferred over full network connect
MFA, appropriate capabilities, sometimes AUP
all (others) including “private” devices without appropriate capabilities (e.g. apps on iPads that do not use the “data protection” feature)
SC3 not allowed at all. In case of SC2…
no data processing on device, only presentation logic
MFA, Employee signed AUP
SC0, SC1 only
“restricted application based” recommended
all others when gateway deployed sandbox technologies (e.g. Juniper Secure Virtual Storage for Win32 systems) are used.
depends, usually sth in the range SC 0-2, pretty much never SC3. We recommend: no SC3.
MFA, Employee signed AUP
Pls note: evidently, “everything else” (other combinations of devices, access methods or data classification levels to-be-processed) can be implemented as well (and this actually happens in environments I regularly work in). I mean, “infosec follows, supports and enables business”. It’s just – from our perspective – a risk acceptance needed then 😉
So, this is what I finally took as the “baseline to evaluate the actual implementation against” (for the “endpoint” category) in the course of that assessment mentioned in the beginning of the post. Hopefully laying out the sources of input, the classifications and the rationale leading to certain restrictions turns out to be helpful for some of you, dear readers.
“In the period of December 2010 until August 2011, Cisco shipped warranty CDs that contain a reference to a third-party website known to be a malware repository. When the CD is opened with a web browser, it automatically and without warning accesses this third-party website. Additionally, on computers where the operating system is configured to automatically open inserted media, the computer’s default web browser will access the third-party site when the CD is inserted, without requiring any further action by the user.”
The approach is smart as it potentially avoids the malware scanning stage that is presumably part of the preparation and shipping process of those CDs. And as it exploits the trust relationships pertinent to the network equipment supply chain…
We’ll probably see (yet) more such stuff in the next years.
During our ongoing research on the security of cloud service providers and cloud based applications, we performed a regular audit of our AWS account password. Thinking of popular incidents and evergreens in attack vectors, we were wondering which consequences an online bruteforce attack on our AWS password would have. So we decided to perform a bruteforce attack against our own account. Analyzing the login process of AWS, the following requirements for the bruteforce tool to be used could be derived:
HTTP 3xx support.
It turned out that it was pretty hard to find a password testing tool which fulfilled these requirements and would be able to actually handle the complex AWS login process — eventually there was none. Since we use and like Burp Suite pretty much, the Intruder suggested itself as an alternative which is straight forward to configure even though it might lack the speed and efficiency of special bruteforcing tools. Using burp’s history, we were able to identify the request which triggered the login process:
After the request is sent to the Intruder, the password field is marked
and the payloads to be used are configured.
Using exemplary payloads, it is possible to identify a successful login attempt, since it results in a redirect to the authenticated area/SSO server/whatever whereas a wrong passwords results in HTTP 200 presenting the AWS login page again:
Having this basic bruteforcing process established, the wordlist to be used must be generated. To decide which complexity should be covered, the Amazon password policy must be analyzed — if the restrictions in place deserve to be called a policy. The only restriction is that the password is between 6 and 20 characters (though the upper limit was determined regarding the maxlength field parameter when changing the password using the webfrontend, since there is no documentation about this available. Thinking of business needs, this behavior might be understandable since Amazon loses “endusers” and therefore money if their password policy is too strict). So we decided to use a wordlist which contains all passwords of 6 characters consisting of numbers (which can be generated pretty easy reactivating some old perl scripting skills: perl -le ‘printf “%06d”, $_ foreach(1..999999)’ 😉 ). Such passwords even might be pretty common when thinking of “birthday passwords”.
After performing about 400k requests, we paused the attack and searched for requests which resulted in a HTTP 302 response, just as the baseline request did.
And indeed, it was possible to bruteforce the password — which is not such a big surprise though. The bigger — and worse — surprise is, that it was still possible to login to our amazon account after performing about 2 million requests (including some dry runs) within two days originating from one single IP adress without having the account locked, being throttled down or notified in any way. And we were performing about 80k requests per hour.
Coming back to the title of the blogpost: At the moment of our investigation, there were no protection mechanisms against bruteforce attacks for the key to your datacenter — which your AWS credentials actually can be, if you are hosting a large amount of your services in EC2. Following a repsonsible disclosure policy, we contacted the AWS Security Team and got a very comprehensive answer. As we supposed, they pointed us to their MFA solution, which is basically, even though there was a major incident recently, a viable security control when authenticating users for data center access. But in addition, we had a long and beneficial dialog about potential mechanisms such as connection throttling and account locking. The outcome of our discussion is a CAPTCHA mechanism which kicks in after a brute force attempt is detected — and was also re-tested several times by our bruteforcing attempt. It was quite impressive to see that it was possible for Amazon to implement additional security measures in such a short time frame, regarding the huge size and complexity of the AWS environment. So we were really glad to get in touch with the committed AWS Security Team and were really happy to see that those guys are really into security and trying to communicate with their customers.