Enabling MFA on your AWS account

One of the key components to cloud security and a question we hear all the time is around the use of multi-factor authentication (MFA).  Implementing MFA is considered more secure than a simple user name and password, because it requires anyone logging in to have something they know (user name and password) and something they have (MFA device). 

Implementing MFA on the Root Account is even more important to ensure the integrity of the entire environment.  JHC Technology always recommends protecting the Root Account.  To do this, we create various security groups and users under the Root Account.  Access is then controlled by the security groups and IAM users.  For more on IAM and assigning permissions, please click here.

MFA devices can either be physical or virtual.  For this entry, I’m going to walk you through the steps to implement an Android virtual MFA with an Amazon Web Services (AWS) account.

This entry does not cover the creation of an AWS account.  If you haven’t created an account, visit http://aws.amazon.com.  Before we get started, it’s also important to have downloaded and installed two applications:  AWS Virtual MFA and ZXing Barcode Scanner (both are free).  Before beginning, I highly encourage the review of the MFA FAQs, located here.

Let’s get started:

1. Sign in to your AWS Account:   
   
2. Select IAM from the Management Console.  
   
3. Under Security Status, you will see that the Root Account MFA is Disabled.  Click on “Manage MFA Device”.  
   
4. We are activating a virtual MFA device.  Ensure this option is selected and click Continue.  
   
5. Since we have already installed the AWS MFA-compatible application, select Continue.   
   
6. You will be prompted by the following screen, which is where you need to utilize your Virtual MFA Device.  Do not close this window.  
   
7. Launch the AWS Virtual MFA from your Android device.
8. Click on your device’s menu button and select Scan QR Code.
9. Once this code is scanned, it will present your associated account on the MFA application.
   
   
    
10. Now you are prepared to finishing authorizing your device.  Looking back at your browser window, you will see that in order to synchronize the device, you need to enter two consecutive Authentication Codes.  You will use your Virtual MFA to generate these codes.
11. Tap the account name on your Virtual MFA.  It will generate a six digit code such as this:    
    
12. Enter this code into Authentication Code 1 in your browser.  
13. Tap your account name on the Virtual MFA to generate another six-digit code. If it’s the same code, you’ll need to tap the name again until the code changes.  Keep in mind that the codes need to be consecutive, so you can’t wait five minutes in between entering codes.  
14. Once you generate the next code, enter that into the browser under Authentication Code 2.  Once you’ve done this, select Continue.
15. If you have entered the consecutive codes appropriately, you will get validation.  Click Finish.  
    
16. Now you need to test the MFA authentication.   
17. Logout of your account.
18. Begin the process of signing back into your account.  Once you have entered your associated email address and password, you will be prompted by a second screen.  
    
19. Open your Virtual MFA application and tap the associated account.  This will generate your six-digit code to enter.  Enter that number in the Authentication Code field and then click the link to sign-in.

Setting up MFA on your root account is a security best practice that is monitored by AWS’s Trusted Advisor (available to customers with Business Level support) and to third-party products such as CloudCheckr.

A few additional notes:

• MFA access can also be assigned to individual IAM users.  MFA is not just for the Root Account.
• Each Virtual MFA device can support only one MFA account.  Read more about this here.
• For AWS GovCloud accounts, Virtual MFA devices are the only option.  GovCloud does not currently support hardware MFA devices.
• If you lose your device, or experience other problems with an account that has MFA enabled, you will need to contact AWS to get the issue resolved.

Matt Jordan is the Cloud Services Manager for JHC Technology.  He can be reached at mjordan(at)jhctechnology.com, @matt_jhc, or connect with him on LinkedIn.

JHC Technology's Best Practices for Amazon Web Services

JHC Technology has utilizing Amazon Web Services (AWS) since its beginning in 2010, and is now an Authorized Government Partner, an Advanced Consulting Partner and a Channel Reseller for AWS. 

Not only do we recommend AWS as the Infrastructure as a Service (IaaS) platform for our clients but I am happy to say that JHC has never purchased any datacenter equipment/infrastructure for our internal systems or operations.  

All JHC infrastructure has been deployed in the AWS cloud platform since we started to include:  

• Blackberry Enterprise Server, 
• Exchange
• SharePoint
• Active Directory
• Citrix
• Test/Development environments

Through the course of the last three years, I have been mentally drawing up a list of JHC best practices for deploying solutions/datacenter operations on the Amazon Web Services platform.   Below are a few examples:

• Fail quickly, often, and cheaply.
• Architect a Zero Trust Model for your AWS Solution.
• Own your AWS accounts and use consolidated billing with a trusted AWS reseller.
• Design for Disaster Recovery and High Availability for both AWS infrastructure and applications deployed on AWS infrastructure.
• Utilize AWS Storage Gate, S3, and Glacier for full lifecycle backup and restores.
• Put in place least privilege administration security policies for AWS Identity and Access Management.
• Do not take a cloud and/or Infrastructure as a Service only posture.  Consider hybrid Cloud solutions that utilize on premise infrastructure, Platform as a service, and/or Software as a Service that integrate with your AWS solution.
• Architect for least viable solution and use business rules to auto scale up and down.
• Deploy your Development and User Acceptance Testing environments on AWS.  Design solution to turn on environments only when needed and automate shut down of environments.
• Deploy your infrastructure inside Virtual Private Cloud that crosses multiple availability zones within an AWS region.
• Decouple compute and storage when possible but realize that most clients’ applications can’t be deployed in this manner.  Consider deploying legacy applications inside AWS and provide roadmap for refactoring to make application more AWS cloud friendly/efficient.

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas(at)jhctechnology.com,@JHC_JamesHirmas, or connect with him on LinkedIn.

Excel Calculation Services Won’t Start? Here's a How-To on Making it Work

Recently I was working with a client and they had an issue with Excel Calculation Services. The user had an Excel Web Access web part to display an Excel spreadsheet chart on their site. The web part was throwing a ‘Unable to process the request … Please try again …’ error. 

First, I performed the following tasks to ensure that I wasn’t missing anything:

1. Open SharePoint Central Admin
2. Open “Services on server”
3. Make sure everything looked good there
4. Attempted to stop/restart “Excel Calculation Services” – but to no avail – Same error was still showing on the web part
5. I then decided to look through the MOSS ULS logs as my last and final resort and some interesting errors stood out to me. 

1. ExcelServerApp.ClearTempPath: Failed to create the Ecs temp path.
2. EngineInterop::LoadDll: Failed to load our engine (xlsrvol.dll)

To find these, I looked for “Excel Services Application service is starting” and the errors would directly follow.  

I ended up fixing this issue by performing the following steps:

1. Go to IIS Manager (Start, Administrative Tools, Internet Information Services (IIS) Manager) on the server running Excel Calculation Services
2. Expand the server and Sites nodes
3. Select the site running ECS (SharePoint Web Services in my case)
4. Choose the Authentication icon in the IIS area
5. Choose ASP.NET Impersonation in the list and disable it

Gary Arrington is the Cloud Consultant & SharePoint SME for JHC Technology.  He can be reached at garrington(at)jhctechnology.com or connect with him on LinkedIn.

Rubber Ducky Attack…with Simple-Ducky

This Demo is for testing purposes, not malicious activity

First, you must ask yourself, what is a Rubber Ducky and what would I use it for? The Rubber Ducky is essentially an HID (Human Interface Device).  For example, your keyboard, mouse and trackpad are HID's. Basically, a computer sees these devices differently than it would a USB thumb drive.  The mouse and keyboard in itself are non-threatening, meaning that they are not devices that would pull data from a computer and store that data. The keyboard and mouse are just simply an interface to type commands, documents or control your operating system.

Well, the Rubber Ducky is the same thing.  However, it looks like a thumb drive. The Rubber Ducky types and clicks things on your system (as if magic) and the whole time your computer thinks it is a keyboard. Below is a demonstration of how the Rubber Ducky works.

First, make sure you have the equipment and software (and Linux distro).

You can order your own Rubber Ducky here: http://hakshop.myshopify.com/products/usb-rubber-ducky

As you can see, the rubber ducky is not a USB drive, but a HID computer if you will. A HID is a Human Interface Device, much like your keyboard and mouse.

Make sure you visit this page to download the latest Simple-Ducky payload generator.

The site will explain what you need and how to install it. It is fairly simple. No pun intended.

https://code.google.com/p/simple-ducky-payload-generator/

I highly recommend you take the time to read the site and get familiar with the capacity of the payload generator software.

Also note that I used Kali Linux  for this demo.  I downloaded it here: http://www.kali.org

Kali Linux is a Debian based Linux Distro and is loaded with Security tools. It was previously known as Backtrack.

Here is a picture of my Rubber Ducky.  Looks innocent enough:

If you take it apart and see under the hood you can see that is looks simple. It also has a micro SD card slot.  You will also receive a micro SD to USB converter and a 256MB micro SD card when you order your rubber ducky.

Lets get started.

Grab your micro SD card and put it in the converter. Insert/connect the converter into your system and make sure your Linux distro sees your removable USB drive. In my case, it was automatically labeled 256MB removable.

Normally, the newer Linux distros have a quick shortcut that allows you to open the terminal (aka command prompt).

At the prompt, type in simple-ducky and hit Enter

Your menu should load up and look like this. Take some time to read all your options, especially #9:

Type "9" and hit Enter.

It will go to a series of checks and installs to make sure you have everything you need to create your own exploits/payloads.

When it is all done type "2" (Windows Reverse Shell Payloads) and Enter.

Then, you will see another menu. Again, take time to review your options.

Type in Option "3" (Persistence Reverse Shell (Win Vista/7)) and hit Enter.

There you will be prompted with a series of wizard questions to set the payload up for you.

The first question was to set username and then password:

The next question is asking for the IP of the system that your victim PC will connect to.  In this case I type 1.2.3.4 as a sample:

This next quest is in regards to what port your victim will connect on. I used 1337 in this sample.  So the victim will connect to IP 1.2.3.4 on port 1337.

You will also have to set a URL for the victim to go to, instead of the IP.  There are times where your listening server may be different than where you are creating this exploit. In this example, I name the URL www.h4ckm3-sys.com:

This next step is simply to set the time to wait to launch the exploit.  It is supposed to be set in milliseconds. I set this one in 5000 milliseconds (5 seconds).

The last question is in regards to see if you are using Kali.  If you are the software knows where to locate the ncat file and put it in the make believe webserver you just created. If you are not using Kali type n and Enter:

Now you should see the software generating the code (inject.bin file) with all the settings you just defined. Hopefully it all goes well.

You should see the files inject.bin and payload.txt in the /usr/share/simple-ducky folder. Make sure you copy the inject.bin file onto your micro SD card now, and you should review the payload.txt file.

The payload.txt is written in human readable code, so you should be able to see what it is doing.   For instance if you look at the things that are circled in the next screenshot, you can see some of the parameters that we set during the previous wizard:

You will be prompted to start listening on this machine.  In this case I said "yes" and was able to see this. It is just waiting for victim machines to make a call back.

Once you copied the inject.bin file to your drive/micro SD card, pull the card out and take the micro SD card out of the converter.

Put the micro SD card into your Rubber Ducky micro SD card slot and then insert into your victim’s pc.

If you put it back together, it should look like this. It looks like an innocent harmless USB drive.

If you connected the rubber ducky to test victim's PC you should see that it was able to connect back to the listening server.

The rubber ducky is not a USB thumb drive, but it looks like one. The sample payloads provided are good, but feel free to create your own.  You can always pair it up with other tools or software, but always keep in mind what your victim is using. You need to tailor your payloads, based on your victims OS and settings.

Thanks to Travis “Skysploit” Weather for the neat Simple-Ducky tool.

Here is another site with other payloads.  However, these payloads you have to create yourself, but the hard part is already done for you.

https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

Have fun Rubber Ducking.

Ernesto Fuller is the Senior Security Administrator for JHC Technology.  He can be reached at efuller (at) jhctechnology.com or connect with him on LinkedIn.

Deleted Emails? One More Step For Hope

Since my last blog, we reviewed several ways to recover deleted email items. From recovering files from the deleted items folder within MS Outlook to searching the dumpster on an exchange server. However, there is one more way to retrieve deleted email items. And that is through your system backups.

All businesses maintain some sort of disaster recovery model that includes regular backups of their email systems. Using a 3rd party tool like Symantec Netbackup and Microsoft Exchange, an entire email database containing user mailbox data can be restored. The information can then be imported back into the user’s mailbox. The steps are simple and as follows:

1. You want to obtain as much information as possible regarding the user’s missing emails. Particularly which email folders are missing mail (i.e. Inbox, Sent Items) and the dates the emails are missing from. This is very important because the restore point selected will be based on the date the exchange server was backed up.

2. You will need to create a Recovery database (RDB) in preparation for the restore process on your MS Exchange server. This recovery database will house an email database and log file information for the mailbox that you want to restore. The database must be dismounted and ready to be overwritten by a restore. These are options that can be selected once the RDB is created.

3. You need to use your third party backup tool to display a timeline of the backup jobs that were performed on the exchange server. You want to select a date prior to that of the missing email and one that will contain the latest backup information. Once obtained, you will start what’s known as a restore to process to pull the email database information from its stored location (backup tapes, disk space, etc.) which is usually rather large file so make sure that you have enough drive space in which to populate the data. The data is placed into the RDB based on a selected path that’s predetermined that tells the Netbackup where to place the restored files.

4. After the restore is completed, using MS Exchange Management Powershell, you can run a simple script to populate the missing emails directly into the users’ mailboxes with no user intervention required.

It’s that simple. You have now gone through the process of restoring missing email files from a recovery database.

Jeronna Freeman  is the Cloud Administrator for JHC Technology.  She can be reached atjfreeman (at) jhctechnology.com or connect with her on LinkedIn.

And the sky’s falling, too...

Last month, I took a look at some of the things the cloud isn’t, but I wanted to expand on those a little as we move forward, because there’s truly a misunderstanding about what the cloud can provide.  Some of that stems from traditional IT vendors that have spent millions and billions of dollars in building their own infrastructure to host agencies and commercial clients.  Other misunderstandings come from the standard competition between cloud vendors, so take that for what it’s worth.

Among the biggest misconceptions out there is that the Cloud is simply one big data center somewhere and everyone’s livelihoods are based on it always being up and running.  One of my biggest pet peeves are headlines screaming that the “cloud goes down.”  Take this instance, for example, about EC2 outages in AWS’ US East Region.  The headline is “Amazon Cloud Goes Down Friday Night, Taking Netflix, Instagram And Pinterest With It”.  But do they really mean the Amazon Cloud?

The Amazon Cloud is 30 services across nine distinct geographical regions around the globe.  Did that go down?  No.  

The Amazon Cloud is a minimum of two individual, geographically isolated availability zones in each region around the world.  Did all of those go down? No.

In fact, did the US East Availability Zone go down?  Did all of the services within the US East Region fail?  No.

So why is it that the “Amazon Cloud” went down?  It sounds to me like components of a network experienced a failure.

What actually happened is that there was service failure for 90 minutes (for Netflix, at least) that affected the virtual machine instances and some of the block storage components within a single availability zone in the US East Region.  No data loss, no viruses, no exposures.

Additionally, saying that the “Cloud” goes down, taking others with it is also slightly disingenuous.  Did Netflix cease to operate for 90 minutes?  Apparently not, because the tweet identified at the article’s open notes that some users were experiencing problems, not that the entire service was down.  

Forbes notes in the article that its Flipboard content wasn’t updating reliably 24 hours after the problem.  Here’s my question:  What do we know about the architecture of these services?  A follow up article notes Instagram’s response to the outage, which had ben caused by unnaturally violent storms that affected the East Coast:

“As of Friday evening of June 29, 2012, Instagram is experiencing technical difficulties. An electrical storm in Virginia has affected most of our servers, and our team of engineers is working hard to restore service.”  -- Instagram, per Forbes.com

Here’s what I make of that statement:  Instagram put all of its eggs in one basket.  Most of its servers are in US East?  Why no balance?  Why no servers in US West?  Why not in Dublin?  Cloud architecture should be designed for failures, just like traditional architecture.  Here’s what else is noted in the follow up article:  No problems from The Guardian, HootSuite, UrbanSpoon, EngineYard (PaaS).  Interesting, no?  Clearly, the Amazon Cloud didn’t go down, because these guys kept operating.

Cloud infrastructure is super cheap compared to traditional racking and stacking.  In most instances, you’re not even charged for servers that aren’t running.  There are load balancing tools, DNS routers, auto scaling devices, and on and on and on.

The truth of the matter is that the cloud didn’t go down.  Companies affected long term may not have properly architected their cloud infrastructure.  We don’t know.  To imply that AWS is the cause of Flipboard being slow to return or for Instagram to have gone down entirely may lay entirely too much blame at the foot of a cloud provider and too little blame at the foot of the company.

Until the Amazon Cloud, or any other, experiences a total and complete loss of service, it would behoove everyone to gain a much better understanding about what happens when there’s a service outage.  Let’s scale back on the ominous “Cloud Goes Down,” because that’s simply not the case.

Matt Jordan is the Cloud Services Manager for JHC Technology.  He can be reached at mjordan (at) jhctechnology.com, @matt_jhc, or connect with him on LinkedIn.

Amazon Web Service (AWS) - Trusted Internet Connection (TIC) Architecture

I have decided to deviate from my blog series about Non-Technical Cloud Barriers and talk about some of the solution architecture work JHC is performing for our Federal clients moving to Amazon Web Services.  One of the major design hurdles the Federal Government has to take into consideration when moving into the Cloud is how to implement Trusted Internet Connection (TIC).  What is Trusted Internet Connection?  Department of Homeland Security describes TIC as an initiative to:

“…optimize and standardize the security of individual external network connections currently in use by federal agencies, including connections to the Internet. The initiative will improve the federal government's security posture and incident response capability through the reduction and consolidation of external connections and provide enhanced monitoring and situational awareness of external network connections.” (You may also refer to OMB Memorandum M-08-05).  

My understanding is that currently, no public Cloud offerings have the capability/ability to natively provide TIC for their federal clients.  In most cases, internet traffic is routed back to the federal government datacenter and out a TIC router provided by a vendor through the vendor’s Managed Trusted Internet Provider Service (MTIPS).  Currently the following vendors are the only MTIPS providers available under the Networx contract:

• AT&T
• CenturyLink (formerly Qwest)
• Sprint
• Verizon Business

For Federal Agencies looking to expand and/or move all infrastructure operations into the Cloud, but still need to maintain a physical datacenter to allow for a TIC vendor provided router, it is not cost effective and from a networking prospective it is inefficient.  Using AWS features, JHC has been able to design a TIC solution that removes the requirement for Agencies to have to maintain physical datacenters for TIC compliance while providing a TIC solution that is High Availability and has built-in Disaster Recovery.  Below is a high level overview and sample architecture of the TIC Solution:

1. Utilize AWS Regions in US East and/or GovGloud
2. Deploy Virtual Private Cloud (VPC) within the AWS Region and associate subnets across Availability Zones.
3. Within your VPC deploy EC2 virtual routers and EC2 web content filters across Availability Zones for high availability and disaster recovery.
4. Establish VPN connection between your agency and EC2 virtual router.
5. (Optional) for additional high availability and disaster recovery connect your AWS regions via EC2 virtual router and load balance user internet traffic across the US.
6. Use AWS Direct Connect feature to route your internet traffic to Equinix facility in either Seattle Washington and/or Ashburn, VA utilizing AWS Virtual Private Gateway.
7. Drop TIC provider router into Equinix and connect AWS Direct Connect Router to TIC Router

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas (at) jhctechnology.com,@JHC_JamesHirmas, or connect with him on LinkedIn.