Elastic Security

Icon

Security for the Cloud

February 18, 2011 • 19:04 1

Amazon EC2 ‘broad character’ support and Security impact on third party tools such as Elastic Detector

The goal of this document is to enlighten security issues on third party tools that come from some features of the Amazon EC2 console. We are going to explain two security threats, a XSS (cross site scripting), and a command injection, using a second party tool as injection’s vector.

Taking our own product Elastic Detector as an example

First of all, let’s describe the context of our application. Then we will have a closer look at the security issues introduced using the Amazon EC2 console.

Elastic Detector is complementary to the Amazon EC2 console (or other management console). It retrieves security group information by the EC2 API and it helps users to have a global security overview of their infrastructure on Amazon EC2. In addition it performs analysis of potential security threats.

XSS

Amazon EC2 API supports broad characters in the Security Group name. If for example, we define the following Name: <script>alert(“Hello World!!”)</script>

A third party product that displays this Security Group Name without sanitizing the data, it will result on a nice Hello World !! alert popup when browsing this Security Group.

Command Injection

Due to the broad character support in Amazon EC2 in Security Group name, we could define the following Name: `cp /etc/passwd /tmp`

So, once this security group is stored in a database without sanitizing, a third party product using shell commands such as eval, exec, mail or printf, could potentially execute the injected command. So a new file name passwd would be added to the /tmp directory in the product as a simple example.

NB: This could also be done using Amazon EC2 Security Instance Tags, in fact every field supports broad characters in Amazon EC2.

Conclusion

These two security issues are examples that illustrate the fact that a third-party tool MUST check and sanitize user’s input (like all software), but also check and sanitize any data coming from other tools or service SaaS.

Thanks To

We would like to thank the Amazon Security Team that fully collaborated and confirmed that broad character support is a feature of Amazon Web Services (especially Don Bailey) and the Certilience Team that helped us as an external auditor of our code.

/fred

Filed under: AWS, Cloud Computing, Elastic Security, Secure Cloud, , , , , , , , , ,

February 17, 2011 • 21:15 3

Most annoying and at the same time most loved feature of Elastic Detector

During the beta test of Elastic Detector, we had a lot of queries concerning an important feature of Elastic Detector, that is :

  • Elastic Detector considers that an open port in the security groups should correspond to an available service in the instances that use the security group.

For example, if you have defined a security group web with the HTTP port open, Elastic Detector deploys an auto-check HTTP and if Elastic Detector does not get an answer, he raises a critical alert on it.

First of all, why Elastic Detector does this?

From the security point of view, it is a potential threat that can be exploited by an internal or external attacker. It means that the attacker can install a rogue application that has immediate access from everywhere. Imagine that the attacker (internal or external) deploys an e-commerce application to sell viagra on your infrastructure.

So, why sometimes this can be annoying to Elastic Detector Users?

I try to enumerate the reasons they gave us:

  • It is work in progress, so the service is going to be deployed later
  • It is a pain to manage a lot of security groups that should fit their services AND that must be changed whenever a service changes
  • I have IP restrictions to access this service

What are the solutions?

In order to cope with the first and second use case, we plan to allow for an acknowledgment of a temporary exception and for the third we have disabled auto-checks whenever Elastic Detector has no permission to access the service. Of course, once our users add Elastic Detector to the authorized IPs then an auto-check is deployed.

Finally, why is it loved by some Elastic Detector Users?

The administrators that are trying to control cloud usage love this feature. It gives an alert whenever one user changes the security groups, so administrators can at least follow the changes and drill-down if needed.

Conclusion

We strongly believe that the ports should be closed until the service is up and running for the sake of security.

Please let me know your thoughts about this feature, annoying or loved?

Filed under: AWS, Discussions, Elastic Security, IaaS, , , , , ,

February 10, 2011 • 12:29 11

How-To: Copy an EBS-Backed AMI from one region to another one

Goal:

The goal of this document is to describe the process for copying an Amazon EC2 EBS-Backed AMI from one region to another.
We have published an opensource project (CloudyScripts) to automatically perform this operation, but we get a lot of questions about it. We will continue to improve Cloudyscripts to better answer all specific issues but here goes the manual HowTo. ;)

Outline:

  1. Create an archive of the AMI file-system in the source region
  2. Copy the archive in the target region
  3. Create a volume containing the file-system
  4. Create a new EBS-backed AMI in the target region

Requirements:

  • A running instance with SSH access in both source and target region. I suggest to launch an Amazon 32bits micro instance-type from Basic 32-bit Amazon Linux AMI 2010.11.1 Beta in the source and target region.
    NB: On Linux, I’d suggest to export JAVA_HOME and EC2_HOME variables (they also could be added in the command line).
  • A temporary SSH key:
    I suggest to use a 1024 bits RSA key, that can be generated as follows (under a Linux system): 


    linux-box-source:~$ ssh-keygen -b 1024 -C "Temporary SSH Key" -t rsa -f temp_ssh_key
    linux-box-source:~$ ls temp_ssh_key*
    temp_ssh_key temp_ssh_key.pub

  • Get AWS account parameters from your AWS account page in the Security Credentials part:
  • Private Key file: AWS_EC2_PRIVATE_KEY.pem
  • Certificate Key file: AWS_EC2_CERT.pem
    NB: These files can be downloaded from the Access Credentials table, X509 Certificates tab.
  • Get all the parameters you might need from the EBS-Backed AMI:
  • AMI ID: AMI-XXXXXXXX
  • EBS Volume size: VOL_SIZE
  • Architecture: AMI_ARCH
  • Kernel ID (AKI): AKI_XXXXXXXX
  • Root Device: ROOT_DEVICE (usually /dev/sda1)
  • Find the Kernel ID (AKI) that will be used for registering your new EBS-Backed AMI in the target region
  • This is described at the end of the document.

NB: In this document, we will use to a Linux system (for command line) and Amazon Console (for Console Administration), but feel free to use your preferred tools. ;)
NB: The LABEL part is useful for some Linux distributions (such as RedHat, Fedora, Suse, OpenSuse) as they use labeled file system in their fstab file and in the root option of their GRUB configuration file.

Step 1: Create an archive of the AMI in the Source Region

  • Using Amazon console:
  • Launch an instance of the AMI (a micro instance-type should be enough)
  • Create a snapshot of the EBS volume
  • Create a volume from this newly created snapshot
  • Stop the instance
  • Launch an instance in the same availability zone of the EBS volume
  • Attached the newly created EBS volume to the running instance in that region and check the name of the device (/dev/sdx)
  • Using you favorite SSH tool, connect to the running instance in the source region and get root access:
  • Get the device label:

    [root@amazon-linux ~]# e2label /dev/sdx
  • Create a mount point:

    [root@amazon-linux ~]# mkdir /mnt/ebs_volume 

     

  • Mount the device on that mount point:

    [root@amazon-linux ~]# mount /dev/sdx /mnt/ebs_volume/
  • Create an archive of the device:

    [root@amazon-linux ~]# tar -zcpvf /mnt/system-YYYY-MM-DD.tar.gz /mnt/ebs_volume/
  • Using Amazon console:
  • Detached the newly created EBS volume to the running instance in that region

NB: If needed you can get root access as follows:

[ec2-user@amazon-linux ~]$ sudo su -
[root@amazon-linux ~]#

NB: Avoid bzip2 compression if you use a small CPU instance.

NB: Please note the file system type (ext2, ext3, …), as it will be reused in the target region while creating a new file system

NB: Please note the permissions while creating file system from archive (-p option)

Step 2: Copy the archive to the Target Region

  • Copy the temporary SSH Private Key on your running instance in the source region:
  • Using you favorite SSH tool to copy the file.
    This could be done as follows on a Linux system:

    linux-box-source:~$ scp -i ssh_key_4_amazon-linux_source.pem temp_ssh_key ec2-user@amazon-linux_source.compute.amazonaws.com:~/
  • Using the Amazon console, launch an instance in the target region (be careful with the availability zone)
  • Add the temporary SSH public key to the authorized key, and reload SSH daemon:
  • Using you favorite SSH tool, connect to the running instance in the target region and get root access
  • Edit file .ssh/authorized_keys and add you public temporary SSH key contained in file temp_ssh_key.pub
  • Reload SSH daemon

    [root@amazon-linux ~]# /etc/init.d/sshd reload
    Reloading sshd: [ OK ] 

     

  • Copy the archive from the source region to the target region as follows:

    [root@amazon-linux ~]# scp -i /home/ec2-user/temp_ssh_key /mnt/system-2011-01-20.tar.gz ec2-user@amazon-linux_target.compute.amazonaws.com:~/

Step 3: Create a volume containing the file-system in the Target Region

  • Using Amazon console:
  • Create an EBS volume in the target region in the same availability zone as your running instance and of the same size of the EBS volume of your EBS-Backed AMI in the source region
  • Attach that volume to the running instance in the target zone
  • Using you favorite SSH tool, connect to the running instance in the target region and get root access:
  • Create a file-system on the device (same file system as the one used by your EBS-Backed AMI):
    [root@amazon-linux ~]# mke2fs -t ext3 /dev/sdx
  • Set device label: LABEL

    [root@amazon-linux ~]# e2label /dev/sdx LABEL
  • Create a mount point:

    [root@amazon-linux ~]# mkdir /mnt/ebs_volume
  • Mount the device on that mount point:

    [root@amazon-linux ~]# mount /dev/sdx /mnt/ebs_volume/
  • Extract the archive to that mount point:

    [root@amazon-linux ~]# tar -zxpvf /mnt/system-YYYY-MM-DD.tar.gz -C /
  • UnMount the device:

    [root@amazon-linux ~]# umount /mnt/ebs_volume/
  • Using the Amazon console:
  • Detach the newly created EBS volume to the running instance in that region

NB: If needed you can get root access as follows:

[ec2-user@amazon-linux ~]$ sudo su -
[root@amazon-linux ~]#

NB: Be careful with the permissions while extracting the file system from archive (-p option)

Step4: Create an EBS-Backed AMI in the Target Region

  • Using the Amazon console, create a snapshot of the volume:
  • Register a new AMI from the previously created snapshot, using Amazon EC2 API tools:

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-register --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region TARGET_REGION -a AMI_ARCH -s SNAP-XXXXXXXX -d 'CopyAMI Generated' -n 'AMI_DESCRIPTION' --root-device-name /dev/sda1 --kernel AKI-XXXXXXXX

NB: The kernel ID AKI-XXXXXXX is found by the procedure at the end of this post

Cleanup

  • Using the Amazon console:
  • Terminate the running instance in the source region
  • Cleanup the EBS volume created in the source region
  • Cleanup the snapshot created in the source region
  • Terminate the running instance in the target region
  • Cleanup the EBS volume created in the target region
  • Cleanup the snapshot created in the target region

Find the right Kernel ID (AKI) for registering your EBS Backed AMI

Outline:

  1. Find the description of the original AMI used to create your EBS-Backed AMI in the source region
  2. Look for the same AMI in the target region using the description of the original AMI
  3. Get the Kernel ID (AKI) of the corresponding AMI in the target region

HowTo:

  • Retrieve all the AMIs in a specific region that use a specific KernelID (AKI):

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-describe-images --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region SOURCE_REGION -a -F kernel-id=AKI-XXXXXXXX
  • Retrieve a KernelID in a specific region that is used by a specific AMI:

    linux-box-source:~/ec2-api-tools-1.3-62308$ ./bin/ec2-describe-images --private-key AWS_EC2_PRIVATE_KEY.pem --cert AWS_EC2_CERT.pem -v -H --region SOURCE_REGION -a -F name="*AMI_NAME*"
  • Example: Suppose I made an AMI using a FreeBSD AMI: FreeBSD/EC2 9.0-CURRENT 2011-01-04 in US-West and I want to copy that AMI to US-East
  • I just have to retrieve the KernelID to use in the target region, as follows:

    debian-secludit:~/ec2-api-tools-1.3-62308# JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.20 EC2_HOME=/root/ec2-api-tools-1.3-62308 ./bin/ec2-describe-images -K ../amazon-ec2-keys/key-BK54TI5LZQMBWA3GVE4XXFYMCWSUCGVY.pem -C ../amazon-ec2-keys/cert-BK54TI5LZQMBWA3GVE4XXFYMCWSUCGVY.pem -H --region us-east-1 -a -F name="*FreeBSD*"
    Type ImageID Name Owner State Accessibility ProductCodes Architecture ImageType KernelId RamdiskId Platform RootDeviceType VirtualizationType Hypervisor
    IMAGE ami-c01aeca9 118940168514/FreeBSD/EC2 9.0-CURRENT 2010-12-12 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-409c852a 1
    BLOCKDEVICEMAPPING /dev/sdb snap-ce948da4 9
    IMAGE ami-a0fc0dc9 118940168514/FreeBSD/EC2 9.0-CURRENT 2010-12-29 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-7127841c 1
    BLOCKDEVICEMAPPING /dev/sdb snap-291ab944 9
    IMAGE ami-f4db2a9d 118940168514/FreeBSD/EC2 9.0-CURRENT 2011-01-01 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-dbe855b6 1
    BLOCKDEVICEMAPPING /dev/sdb snap-2fe35e42 9
    IMAGE ami-8cce3fe5 118940168514/FreeBSD/EC2 9.0-CURRENT 2011-01-04 118940168514 available public i386 machine aki-407d9529 ebs paravirtual xen
    BLOCKDEVICEMAPPING /dev/sda1 snap-1df57270 1
    BLOCKDEVICEMAPPING /dev/sdb snap-e1fe798c 9
  • I could register my new AMI using the following KernelID: aki-407d952

/fred

Filed under: AWS, Cloud Computing, Documentation, , , , , , ,

February 9, 2011 • 16:41 1

Is Cloud-Computing Centralized or Decentralized? (Part 4)

Previous [Part 3]

Cloud Computing – Centralized or Decentralized?

After this long excurse into history, let’s come back to our initial question: is cloud-computing centralized or decentralized? Well, the answer is: both! Consider a simple web-application: parts of it is running decentralized in your browser (Ajax). The data may be stored in a single data-center – centralized, but the database is replicated on different virtual machines – decentralized. The web-application may make use of other services – decentralized, but provides its features via the same URL to thousands of users – centralized.

Does the question even matter?

The terms centralization and decentralization have always been misused in the history of computers to simplify any form of change triggered by technological progress in a fad kind of way (something similar happened in organisation theory). But for me the history of computers does not show alternance between centralized and decentralized architectures, it shows that architectures have gotten more complex and differentiated fostering more specialization and abstractions, more dedicated software and hardware components, sophisticated layers, and specific solutions. Some are centralized, others are decentralized – the term does not make sense anymore. Discussing on the pros and cons of centralization can at best be done for individual components (like databases).

Cloud Computing is the answer to the increasing demand – of entreprises as well as of consumers – for ubiquitous information in a mobile world. It reflects new forms of communication and collaboration and is far beyond the discussion on pros and cons of decentralized architectures.

This post is part of a series. Click on the links below to read the other parts.
[Part 1] The first computers
[Part 2] Closer to the users
[Part 3] Home computers and the Internet
[Part 4] Centralized or Decentralized?

Filed under: Cloud Computing, Discussions, , ,

February 8, 2011 • 10:17 0

Reply to “Don’t Conflate Virtual with Dynamic”

This post is a reply to the blog post “Don’t Conflate Virtual with Dynamic” posted here and here, that was already a reply to our original post “Why the perimeter must become virtual“.

First of all, thanks to Lori for the very interesting blog post. Here goes my comments :

  1. Overall we agree. In the original block post we stated “Well, the short answer is: the perimeter must also become virtual, highly dynamic, and automated.”. Lori on the other hand says “In order to implement the kind of dynamic network perimeter … we do, in fact, need a more flexible, automated perimeter.” We agree on the dynamic and automation part.
  2. It seems that is the word “virtual” that triggered the discussion, for example Lori states “Dynamic is not a synonym for virtualization and virtualization does not inherently provide the fluidity of the network architecture required to address the challenges associated with highly dynamic environments.” And the fact that virtualization itself rises security, compliance and performance issues. We agree on the issues and for example the top threats to cloud computing from the Cloud Security Alliance refer to this in the item “Shared Technology Issues” (for example xen and vmware vulnerabilities).

So, everything boils down to the questions : Should the (security) perimeter be virtual or non-virtual ? Should we use a “toss another virtual appliance” approach to security (like we do for scaling) or more about “designing an architecture comprised of highly dynamic and interactive components that can be provisioned and managed on-demand” as Lori said ?

These are challenging questions in my opinion and I’d really appreciate to continue to discuss this topic. What are your thoughts?

Just to give some clues, I can think about trusted computing platforms and are they possible with virtualization? Can we establish trust on top of virtualization layers? Actually, these are some of the questions that the Virtualized Platform working group is trying to address.

Sergio

Filed under: CSA, Elastic Security, IaaS, Uncategorized

February 4, 2011 • 12:07 2

Is Cloud-Computing Centralized or Decentralized? (Part 3)

Previous [Part 2]

Home Computers and The Internet

Another technological breakthrough , the micro-processor in the early 70ties (the first commercially available micr0-process was the 4004 from Intel) changed the computer industrie in a way it never happened before. The Altair 8800 was a micro-computer construction set for around 500$ that laid the ground for computer pioneers in the USA and a democratization of access to computers. The first operating system CP/M and programming languages like BASIC created a thriving eco-system around micro-computers with applications outside the classical enterprise domain like gaming, music and graphics, learning vocabulary or maths. The computer found its way into the home – and becomes smaller, more powerful, better graphics: Apple 2, PET 2001, ZX81/Commodore 64, MacIntosh, and of course the triumph of the PC and Microsoft that somehow inherited the PC monopoly from IBM. In the entreprise, we see the raise of Mini-Computers and DEC – also for researches and smaller enterprises – that died with the raise of the PC.

Already In the 70s, computer started to be connected (remember the ARPANET project) and laid the basis for the Internet and the World Wide Web that began to conquer the world in the 90 of the last century. The first web-applications (E-Commerce, what else?) started to pop-up in the mid 90ies. Given the today definitions of cloud computing and its different flavors IaaS, PaaS, and SaaS, web-applications were the first form of cloud computing. Amazon’s web-shop, Yahoo’s directory service, Google’s search engine, Flickr’s photo sharing site, WordPress’ blogging-tool, Google’s Gmail and Docs are milestones in the history of web-applications – and what we call SaaS today. In 2006, Amazon launched S3 and EC2, services that allow to allocate computing ressources – storage and virtual servers – via the web. That means, not only applications, but complete data-centers can run somewhere else in the world. The term cloud computing was born – motivated by the little clouds used in network diagrams to describe a network like the Internet transparently.

Continue [Part 4]

Filed under: AWS, Discussions, , ,

February 3, 2011 • 15:35 3

Is Cloud-Computing Centralized or Decentralized? (Part 2)

Previous [Part 1].

Closer To The Users

In the 50s, the innovation of mechanical relays (instead of vacuum tubes) made computers (e.g. the UNIVACs) already much smaller and affordable for other governmental organizations like the US Census Bureau. The first computer language FLOW-MATIC appeared. IBM entered the market with their IBM 701. In 1956, around 100 machines are installed all over the United States. IBM invented the first hard drive system (RAMAC) that laid the foundation of modern hard disk systems and that replaced the awkward punchcard system.

IBMs System/360 started the era of mainframe computers with a modular architecture that allowed to support different configurations and to replace the processor unit for upgrades. In the mid-sixties, IBM sells around 1000 machines per month. Computers became interesting for the first business applications. Still they are only feasible for large enterprises and military applications. Software and hardware were bundled, the machines not even programmable by others.

The miniaturisation of circuits, the usage of transistors and integrated allowed to enter the era of mini-computers in the 60ties and the rising of DEC. The PDP-8 is considered the first commercial micro-computer. It still had the size of two large refrigerators, yet it could be started up by a single person, didn’t develop much heat and didn’t require a cooled location so that it could be situated closed to the people that used it. Most users were researchers and larger enterprises. The computer got closer to its users. And it got smaller and smaller: the PDP-8e in the early 70ties could be put on a table already. The prices went down to under 2000$.

Continue [Part 3]

Filed under: Cloud Computing, Discussions, , ,

February 2, 2011 • 11:25 2

Is Cloud-Computing Centralized or Decentralized? (Part 1)

The question if an architecture should be centralized or decentralized is one of the recurring questions in systems design, but also object of discussion in organizational and political theory. In most enterprises and especially IT departments, technical and organisational aspects fall together and even influence each other. To understand the possible impact of cloud computing on the structure of organisations, we would like to figure out if cloud computing is actually following a centralized or a decentralized architecture. Let’s therefore start with a journey through history – the history of cloud computing is nothing less than the history of computers and computer networks – and their alternation between centralization and decentralization.

The First Computers in Use

The first effectively used computer (ENIAC) occupied the space of a large building (around 300 m2), was targeted for very specialized military applications, and all instructions hardcoded and controlled by 6000 switches that could be manually controlled. The next computer (EDVAC) became more flexible, controllable and less error-prone with the use of punchcards. The next one (MIT’s Whirlwind) was the first with a rudimental user interface (a kind of radar screen). Until then, computers are large, extremely expensive, and specialized, and only one organization in the world could use it: military.

Giant monolytic building blocks on a fixed location. The first computers are without any doubt centralized.

Continue [Part 2]

Filed under: Cloud Computing, Discussions, , ,

Twitter Updates

Follow

Get every new post delivered to your Inbox.