Securing Your Cloud Services – Watch that admin console!

New take on an old joke: If a cloud service is hacked and no one is around, does it make a sound?

We’re living in a golden age of disruptive technologies, least of which is the rise of the “cloud”.  Cloud computing is one of those terms that varies based on your perspective, so for the sake of our discussion today, we’re going to break it down to the basics:  There is no cloud, only other people’s computers.  Cloud is a nifty way to sell tiny slices of those computers resources, like storage and computing.  That’s really all it is.  But make no mistake, it’s someone else’s computer running with your data.

There are tremendous advantages to be gained from leveraging these services, without a doubt.  The flexibility to pay for what you use, to scale up or down as necessary, to avoid capital expenses related to hardware and software, the redundancy and DR capabilities, the ubiquitous Internet access, all awesome things.  We’re just going to take a look at how you can leverage these technologies safely.

Administrative Controls

Virtually every public cloud service provides you, the subscriber, with access to an administrative portal, usually a web application, where all of the administrative functions happen.  Which makes sense, because your are using someone else’s computers after all, so they need to give you control over just your stuff.

May or may not be the actual control panel for modern cloud services….

How do you prevent unauthorized actions within this portal?

Well, usually the group of people designated as “admins” are given access to the portal, usually secured with a username and password.  So technically they are the only people with access.  Unless their password is easily guessable.  Or they are victims of a phishing attack and disclose it.  Or if it’s the password they use everywhere, and one of their other accounts is compromised.  Oh, or if an attacker installs a key-logger on their system.  Or if they log in from an unprotected wireless network.

Yeah, I know, the whole password thing isn't great...
Yeah, I know, the whole password thing isn’t great…

Maybe your cloud provider has a two factor authentication solution you can utilize.  That would help.  Some private cloud service providers (including EI’s Cloud+) don’t even expose the admin console to the Internet to provide additional security.

Of course, if this system were hosted in our own data center, we would find a way to monitor that kind of login activity, both to log for patterns of brute forcing attempts, or to catch login attempts from unusual locations (someplace in Asia, let’s say).  Unfortunately, most cloud providers do not provide the ability to log this type of data, and certainly not in anything like the real-time type nature we have grown accustomed to.

What this basically means is that the detective parts of your controls go out the window, and you are left with hoping that the authentication controls are sufficient.

Consider the case of Code Spaces, a service providing hosting for teams to collaborate on software projects.  Their entire business was built using cloud services (in this case, Amazon’s Infrastructure as a service offering).  Late on a Tuesday, the Code Spaces team realized they were the target of a massive distributed Denial of Service (DDoS) attack.  The Code Spaces team was able to reach out to the attacker, who demanded a ransom to stop the attack.  How did the Code Spaces team know how to contact the attacker?  Because the attacker left their contact details inside of the admin dashboard of their Amazon account!

Realizing that the attacker had access to their control panel, they began to attempt to regain control over all of their accounts, but the attacker had created a few additional accounts, and started deleting everything inside of the Code Spaces account.  Everything.  All of the virtual machines, all of the virtual machine snapshots, all of the storage, and all of the backups.

Really easy to delete things unfortunately....
Really easy to delete things unfortunately….

Code Spaces had touted their ability to protect customer data from catastrophic events as one of their main selling points.  To be fair, they probably were pretty well set up to recover from specific hardware or site failures, but no one had taken into account recovering from an instance where all of their data was deleted from the admin console.

As a result, Code Spaces is closing their doors.  The cost of recovering their customer’s data plus the damage to their reputation was too much to overcome.

We don’t have many details on the exact nature of the attack at this point, but what little we know seems to indicate that a phishing attack targeted key individuals at Code Space, and was successful enough for the attacker to gain access to the Amazon dashboard.

So, how can you secure the admin console for your cloud services?

First, securing the admin portal should be as important to the cloud provider as it is to you.  In most cases, the admin portal should be restricted, not just to authorized users, but from the Internet in general.  While remote access is great, very rarely will you need access from absolutely anywhere on the Internet.  Incorporating a VPN (with different credentials) to access administrative functions can provide an additional buffer.  Most managed private clouds will work with you to only provide access to admin consoles through very restricted access.  Obviously you can’t request physical access to most cloud service providers, which would enable physical access controls as well as logical ones.

Physical access controls are generally not an option for you in cloud services...
Physical access controls are generally not an option for you in cloud services…

Second, there should be some logging and alerting built in.  Basic things like looking for series of incorrect passwords or connections from unusual locations is a good start.

Redundancy Outside of the cloud

Offiste (or off-service) backups are crucial
Offiste (or off-service) backups are crucial

Backups are such a critical component of DR/BC plans because you can always restore the app, but once you’ve lost the data, well that’s it.  The Code Spaces team had designed their solution to handle lots of adverse conditions, just not one in which an attacker had access to their admin console.  Had they leveraged a backup solution that kept their data outside the Amazon cloud (and away from the control of the attacker) they would have suffered an outage, but would have been able to restore to full functionality.

Cloud Security – Lots more!

The proliferation of various cloud services provides lots of additional attack surface that needs to be secured.  We’ll be discussing additional cloud security concerns in upcoming blog posts.

Thanks for reading!

More details on the Code Spaces story can be found here:


How To Pick a Good Password

As a regular reader of this blog, you’ll know we’re sticklers for good passwords.  And if this is your first visit, welcome to the show!


To be completely honest, a username and password is actually not an ideal way to secure a system.  Usernames are almost always easily guessable, and passwords usually are too.  But, for a lot of systems, that is what we have, so it’s important to pick good strong passwords to protect your information.

Before we dive into good password rules, I’d like to look at how passwords get compromised in the first place, so you’ll know what we’re up against.

Generally speaking, there are 4 ways that your super secret password becomes, well, not so secret:


  1. Your password is really easy to guess
  2. One of the websites you use experiences a breach (and you use that password everywhere!)
  3. Someone is able to use a “Forgot My Password” function to reset your password
  4. You get tricked into telling someone your password

Easy to Guess?

Why did I use "password" as my password?!
Why did I use “password” as my password?!

Just about everyone knows that your password shouldn’t be obvious.  Hilariously bad examples exist like “password”, “123456”, and “password1” (you know, to make it complex).   I know I sound like the stuffy old security guy when I say that, but it’s not something I just think, I know that those passwords are used all the time.  How could I possibly know, you ask?  Well, lots and lots or websites suffer breaches every year, and lots of those websites do a really crumby job of taking care of your password, and then the attacker usually ends up posting them for everyone to see, so security nuts like me get to chart these things.  In 2013, “123456” was the MOST POPULAR password in use, followed by “password”.  Not kidding:

You also shouldn’t use your username as you password.  It sounds silly, but it happens.   Not too long ago we were performing a security audit on a web application, and one of the concerns the client had was over their ability to detect password guessing activity.  We scripted up some automated login actions, fed it a list of 2000 common usernames, and tried logging in with either “password” or the exact same word as the username.  To the client’s surprise (not ours) about 130 of the accounts used the same word for their username and their password. Another 35 or so used “password”.  It took us about 30 minutes.  Seriously.  Don’t use your username as your password.

One of your favorite websites is breached! (Gasp!)


OK, so let’s say you’ve figured out a super awesome password.  It has numbers, capital letters, special characters, the works.  It’s 15 characters long, and no one would ever guess it.  Awesome, nice job.

So you take your super awesome password, and register on a site that sends you coupons for things like spray tans and dog spas (hey, no judgement here).

Also not good at protecting passwords, it turns out....
Also not good at protecting passwords, it turns out….

Turns out that the oddly orange dog loving entrepreneurs aren’t good at securing their website, and someone steals the user database and posts it for the world to see.  The usernames and the passwords are stored in cleartext, which means they look just like you type them.  It has your email address, and your password, right there, plain as day.  Your super awesome password is no longer secret, super, or awesome.  If you used this password on everything (Facebook, LinkedIn, your email account, your bank), it’s just a matter of time before someone bothers to try it.

Now let’s say that a few months later, another website you use suffers a breach, only they do something called hashing.  A hash is a one-way math function, that takes in your password and spits out a stream of numbers and letters.  Think of it like a meat grinder.  You put a steak in one end, and ground beef comes out the other side.


In this case, the “grinder” always spits out the same hash value when you enter the same password, so instead of storing your actual password, they compare the hashed results of the password you just entered, and the hashed results they have on file.  And just like a meat grinder, there is no way to reverse the process. (How many times have you seen someone put a steak together from ground beef? Exactly.)

Attackers know this, and so have built these enormous tables called Rainbow Tables, where they take huge lists of potential passwords, perform the same hashing function, then use those tables to compare the hash values they just stole from the web site.  There are some things that you can do to make that harder, but lots of websites just get to the hashing part, and not further.

Note: Not an actual rainbow table.
Note: Not an actual rainbow table.

So the moral of this story is to use different passwords for different sites.  That way, if the above scenario unfolds, you only have one site to worry about, instead of your entire online identity.

Forgot your password?

You see these same questions every time you register on a site.  Mother’s maiden name?  City you were born in?  Maid of Honor at your wedding?  These are the questions you get asked when you want to reset your password.  And this is great, since you are now using separate passwords for all of your sites (right?) its possible from time to time you may need assistance getting into one of these.

Some sites handle the password reset issue well, some not so much.  Most sites will ask you a question, then send you a temporary code to your registered email address, which is good.  Even if someone guesses the answer, they still need access to your email.  Other sites will ask a security question, then let you reset the password right there if you get the right answer.  Those are dangerous, so you need to make sure the answers to those questions can’t be discovered in 2 minutes or looking at your Facebook profile.

OK, let’s pick a good password!

Now that we’ve seen the different ways that passwords can be compromised, let’s look at what makes a good password.

We know it shouldn’t be easy to guess, so regular words are out.  And since the attackers can use those Rainbow Tables to compare possible passwords, we need to use a password that is pretty long and has lots of different characters in it.


Some rules to use:

  1. Make sure your password is at least 10 characters long
  2. Use capital and lower case letters
  3. Use a number (or several)
  4. Use some punctuation (!@#$%^&*)

If you follow the above rules, an attacker would need a rainbow table roughly 100 pedabytes to ensure they have your password hash in their table.  If you drop one of those out though, it reduces fast.  Let’s say you only use letters and numbers.  That drops the rainbow table to 13 pedabytes.  Still huge, but not nearly as huge as before.  Let’s say you use a shorter password, like 7 characters.  Even if you follow the other rules, we’re down to about 250 gigabytes, much more manageable.  Let’s not make it manageable.   Every additional character you put in your password makes it exponentially harder for the attacker.