Introdução / Introduction

A Cloud apresenta-se como uma nova tendência e a virtualização por sua vez é amplamente usada neste tipo de paradigma. Hoje em dia parte do conteúdo já foi migrado para este tipo de infraestruturas e muitos dos ataques web-based ou cross-Virtual Machine (VM) representam um sério problema para os provedores de cloud. Este artigo apresenta uma proposta para um mecanismo de proteção de informação contra ataques web na cloud. Uma das maneiras de proteção para este tipo de ataques é o uso de VMs. Para motivar este trabalho são também discutidas algumas linhas sobre o potencial impacto deste tipo de ataques no laboratório apresentado ao longo do artigo.

Cloud is presented as a new trend in this era and virtualization is extensively used in this kind of infrastructure. Nowadays, part of the content has been migrated towards this type of infrastructure and many of the web-based and cross-Virtual Machine (VM) attacks pose a serious problem for cloud providers. This article elaborates on data protection mechanisms against web attacks in the Cloud. Furthermore, usage of VMs demonstrates a security efficiency manner to protect the information available on this architecture. To motivate this work, some lines about the potential impact of the analyzed attacks are discussed herein.

Termos como Computação na Nuvem e Infraestrutura na Cloud têm sido objeto de destaque nestes últimos tempos. Muitas companhias como a  Amazon [1], Google [2], IBM [3] e Microsoft [4] fornecem este tipo de serviços. Com o crescimento da Web e dos serviços Information Technology (IT) o uso da cloud cresceu de forma exponencial. De notar que preocupações relativas a largura de banda, espaço de armazenamento, tempo de processamento, segurança, entre outros, deixaram de ser uma preocupação maior. Dessa forma, não é surpresa que uma ligação à cloud (nuvem, em português) signifique satisfazer as necessidades em termos de tecnologia da informação (um assunto examinado na secção Trabalho Realizado – A. Cloud Computing). Uma tecnologia descrita ao longo deste trabalho é a virtualização (brevemente discutida em Trabalho Realizado – B. Virtualização). Esta peça de software é muitas vezes associada ao conceito de abstração porque ela ocorre em muitos níveis, p.ex., um interpretador é considerado uma camada de virtualização que fornece uma VM a diferentes aplicações (e.g., Java Virtual Machine (JVM)). Existem, assim, diferentes tipos de virtualização, contudo este artigo apresenta algumas linhas sobre virtualização relativa a VMs e Virtual Machine Monitors (VMMs) (muitas vezes denominados por Hypervisors) que emulam e correm imagens na integra de Sistemas Operativos (SOs). Este artigo também discute de uma maneira breve algumas experiências relacionadas com VMs num ambiente cloud, nomeadamente um laboratório projetado para evitar ataques despoletados via web (web-attacks). Este assunto é discutido na secção Laboratório. O restante artigo é estruturado da seguinte forma. Na secção Ataques e seus Efeitos são apresentados os ataques e o seu impacto no laboratório proposto. Na secção Potencial Impacto dos Ataques Analisados em Ambientes Cloud é apresentado o possível impacto destes ataques na cloud e por fim a secção Conclusão entrega algumas linhas relativas ao trabalho realizado neste artigo e direções de trabalho futuro.

Terms like Cloud Computing and Cloud Infrastructure have been making headlines in recent years. Many companies such as Amazon [1], Google [2], IBM [3] and Microsoft [4] provide these type of services. With the growth of the Web and Information Technology (IT) services, Cloud usage has increased exponentially. In fact, concerns about bandwidth, storage space, processing power, reliability and security ceased to be a major concern. Thus, it is no surprise that a connection to the cloud  means “meeting the needs” within the information technology landscape (a subject discussed at the Work section Realized – A. Cloud Computing). In this context, and a thematic depicted along this work is virtualization (briefly discussed in Background – Virtualization). This piece of software is usually associated with abstraction because virtualization occurs at many levels, e.g., an interpreter is considered a virtualization layer that provides a VM to different applications (for example, Java Virtual Machine (JVM)). Thus, different types of virtualization exist, however, this article discusses virtualization related to VMs and Virtual Machine Monitors (VMMs) (also referred as Hypervisors) that emulate and run integral images of real Operating Systems (OSs). This article also presents, in a brief manner, experiments related to VMs in a cloud environment. In addition, an experimental setup to demonstrate a data protection mechanism and most frequent attacks in the cloud was performed. This is detailed in the section Experimental Setup. The remainder of this article is structured as follows: Section  Attacks and its Effects which discusses the result of the used attacks and its effects in the experimental setup herein produced; Section Potential Impact of the Analyzed Attacks in the Cloud Environment describes the potential impact of the analysed attacks in the cloud environments; and Conclusions and Future Work concludes this article and elaborates on future work directions.

Trabalho Relacionado / Background

Esta secção está dividida em duas subsecções. A primeira apresenta um breve trabalho sobre cloud computing. A segunda descreve um estado da arte bastante resumido sobre virtualização.

This section is divided into two subsections. The first one briefly discusses a work concerning cloud computing. The second describes a brief state-of-the-art about virtualization.

A. Cloud Computing

Cloud Computing, também designada como cloud, constitui um modelo que fornece acesso a uma pool de recursos compartilhados sobre uma rede de computadores. Durante décadas companhias de IT, organizações e uma grande quota de clientes guardavam seus recursos em soluções mais caseiras. Do ponto de vista de utilização e manutenção, estes sistemas exigiam um grande e dispendioso esforço humano. Os computadores eram agrupados formando um cluster. Esta técnica, chamada clustering, foi muito usada por companhias IT. Em meados de 90, Ian Foster and Carl Kesselman apresentaram o conceito de The Grid [7]. Mais tarde, alguns provedores como os de cloud usaram este conceito nos seus serviços. Um dos mais antigos e famosos provedores é a Amazon S3 (Simple Storage Service) [1].

Cloud Computing, also designated as cloud, constitutes a conceptual model that provides access to a pool of shared computing resources across a computer network. During decades, IT companies, organizations and a wide quote of customers kept their resources in homemade solutions. From the point-of-view of utilization, system maintenance, support and processing costs  was considered as a hard task in order to maintain the information totally available. Computers were grouped together to form one large supercomputer processing power. This technique, so-called clustering, was common among many IT departments. In the early 90s, Ian Foster and Carl Kesselman presented the concept of The Grid [7]. Afterwards, entities related to Cloud Computing, as data center providers, have used the concept of Grid Computing in service offerings. One of the most famous cloud computing service provider is Amazon S3 (Simple Storage Service) [1], and also a large storage receiver to the Internet.

Hoje em dia, e de acordo com o National Institute for Standards and Technology (NIST), o provedor de cloud pode manter os recursos disponíveis sem grande esforço. O autor refere ainda que o modelo de cloud é composto por cinco características essenciais, três modelos de serviço e quatro modelos de implementação [5]. Com base na definição do NIST, as características essenciais são definidas como: (i) On-demand self-service, (ii) Broad network access, (iii) Resource pooling, (iv) elasticidade rápida e (v), serviço medido. Em relação aos modelos de serviço, eles refletem a relação entre um consumidor e a cloud (por favor, ver figura abaixo). Assim, eles podem ser enumerados em três modelos de serviço, a saber: (i) Software como um Serviço (SaaS), que oferece aos consumidores a capacidade de as aplicações serem executadas em uma infraestrutura na cloud, (ii) Plataforma como um Serviço (PaaS), o consumidor é capaz de colocar na cloud as aplicações desenvolvidas via linguagens de programação, bibliotecas, serviços e ferramentas suportadas pelo provedor, e (iii), Infraestrutura como um Serviço (IaaS), o consumidor tem a possibilidade de provisionar processamento e armazenamento, redes e outros recursos da infraestrutura. Por fim, os modelos de implantação podem ser brevemente descritos como: (i) Coud privada, a cloud está provisionada para uso exclusivo por uma única organização, (ii) Cloud comunitária, pode ser fornecido para uma determinada comunidade ou organização, (iii) Cloud pública, a infraestrutura está provisionada para uso aberto, e (iv), Cloud híbrida, a cloud é uma composição de duas ou mais distintas infraestruturas que permanecem entidades únicas.

Nowadays, and according to National Institute for Standards and Technology (NIST), the cloud provider can maintain the resources available on cloud without a great effort. The author refers yet, that cloud model is composed of five essential characteristics, three service models and four deployment models [5]. Based on the NIST definition, the essential characteristics are defined as (i) On-demand self-service, (ii) Broad network access, (iii) Resource pooling, (iv) Rapid elasticity and (v), Measured service. Regarding the service models, they reflects the relation between a consumer and cloud (please, see figure below). Thus, them can be enumerated in three service models, namely: (i) Software as a Service (SaaS), it offers to consumer the capability to running applications on a cloud infrastructure, (ii) Platform as a Service (PaaS), the consumer is capable to deploy applications created using programming languages, libraries, services and tools supported by the provider onto the cloud, and (iii), Infrastructure as a Service (IaaS), the consumer has the possibility to provision processing, storage, networks and other computing resources. Finally, the deployment models can be briefly described as (i) Private cloud, the cloud is provisioned for exclusive use by a single organization, (ii) Community cloud, it can be provisioned for a specific community or organization, (iii) Public cloud, the infrastructure is provisioned for open use, and (iv), Hybrid cloud, the cloud is a composition of two or more distinct infrastructures (private, community, et cetera) that remain unique entities.

a

Perspectiva integrada sobre os componentes e modelos de serviço da cloud. [6]

 Integrated perspective about components and service models in the cloud [6].

B. Virtualização / Virtualization

A virtualização consiste num paradigma com aproximadamente quatro décadas, embora atualmente tenha sido renascida com o objetivo de fornecer resposta a muitos desafios, nomeadamente o da segurança. Dentro deste contexto e de acordo com Miguel P. Correia em Segurança no Software, a virtualização opera sobre uma premissa crítica, ela pode ser resumida em algumas palavras: Os SOs representam um ponto nevrálgico no horizonte de segurança [8]. As primeiras VMMs surgiram no final dos anos 60 nos mainframes da IBM (System /360). Um dos grandes objetivos da virtualização passa por diferentes utilizadores e aplicações usarem a mesma máquina para realizar as suas tarefas. No final dos anos 90 começou a grande ascensão das VMMs e prolongou-se até aos dias de hoje. Atualmente existem diferentes tipos de serviços de virtualização, o VMware [9], Xen [10], VirtualBox [11], Microsoft Hyper-V e Virtual PC [12] e por fim, Parallels [13]. Mais recentemente existiu um interesse massivo à volta da virtualização. Em termos de  partilha e recursos dinâmicos ela fornece grande eficiência, por exemplo em serviços de cloud. Virtualização é categorizada em dois tipos: (i) Tipo 1 de Virtualização, ou Máquina Virtual Nativa, onde os VMMs correm diretamente ligados com os componentes de hardware (ver figura do lado esquerdo abaixo), e (ii), Tipo 2 de Virtualização, ou Máquina Virtual Convidada, os VMMs correm sobre um SO real (ver figura do lado direito abaixo). De uma maneira breve é importante perceber que a virtualização compreende algumas particularidades,  p.ex., é mandatório o processador suportar virtualização (Virtualization Technology or Vanderpool), bem como virtualização de memória (alocação dinâmica de memória). Este tema podia ser escrutinado de forma mais detalhada, no entanto este artigo é focado sobre um laboratório proposto a seguir e baseado no Tipo 2 de Virtualização bem como num mecanismo para proteger os dados na Cloud contra web-attacks, nomeadamente Cross-site Scripting (XSS) e SQL Injection (SQLi).

Virtualization represents a paradigm with approximately four decades nonetheless, it has been reborn in recent years to respond to many challenges, namely the security. Within this scope and accorded to Miguel P. Correia in Segurança no Software, virtualization operates under a critical premise, it can be summed up in a few words: OSs represent a neuralgic security point in the virtualization landscape [8]. The first VMMs emerged in the late 60s on IBM mainframes, e.g., the System /360. One motivation to use virtualization is focused on distinct users and applications can use simultaneously the same machine, once the last one have a high cost. In the late 90s began the rise of VMM that we are now attending. Nowadays, exists different types of virtualization services, for example, VMware [9], Xen [10], VirtualBox [11], Microsoft Hyper-V and Virtual PC [12] and Parallels [13]. More recently, there was a massive commercial interest around the virtualization. In terms of sharing and dynamic resources, this provides a great efficiency and capabilities, for example in cloud computing services. Currently, virtualization is categorized into two types: (i) Type 1 of Virtualization, or Native Virtual Machine, where VMMs run directly connect with the hardware components (see figure on the left side), and (ii), Type 2 of Virtualization, or Guest Virtual Machine, VMMs run over a real OS, e.g., Linux, Windows and Mac (presented on figure in the right side). In a brief manner is important to understand that virtualization comprises several particularities, for example, supporting of processor virtualization is needed (namely, Virtualization Technology or Vanderpool), as well as memory virtualization, i.e., dynamic memory allocation, and I/O virtualization (virtualization of hardware components). This subject could be deeply scrutinized, nonetheless, the motivation this work is focused on a proposed laboratory setup based on Type 2 of Virtualization as well as on a mechanism to protect information against Hypertext Transfer Protocol (HTTP) attacks, i.e., Cross-site Scripting (XSS) and SQL Injection (SQLi).

hyp2hip1

Esquerda: Tipo 1 de Virtualização; Direita: Tipo 2 de Virtualização.

Left-side: Type 1 of Virtualization; Right-side: Type 2 of Virtualization.

 

Laboratório / Experimental Setup

O recente uso de VMs tem sido bastante requisitado para a conceção de domínios de segurança tanto a nível local como em sistemas mais distribuídos. É importante a redução  dos ataques neste tipo de sistemas, pois se parte do sistema é atacado todo o sistema é comprometido. A virtualização é parte integrante da infraestrutura de cloud dos dias atuais, pois reduz o uso de várias máquinas físicas dentro de um domínio público e privado. Por outro lado, outra aplicação de máquinas virtuais é também a possibilidade de isolamento, para o propósito deste artigo: a criação de honeypots de forma a simular um sistema totalmente real. Um honeypot consiste num ou mais computadores que parecem fazer parte de um  sistema em produção mas na verdade são isolados e semi desprotegidos, embora eles possuam monitorização que recolhe informação de intrusões que possam ocorrer. Dentro deste contexto foi elaborado um laboratório baseado em (i) virtualização, (ii) análise de tráfego através de uma proxy-firewall caseira, e (iii) um conjunto de honeypots com a finalidade de construir um ecossistema seguro na cloud (ver imagem abaixo). Este laboratório apresenta um setup experimental baseado no modelo 2 de virtualização concebido sobre uma distribuição Arch Linux denominada Antergos [14].

In the field of security, recent use of VMs to build up protection domains within a machine or distributed system represents the first application of virtualization nowadays. Therefore, reducing the impact of attacks on those environments is seen as a crucial goal, i.e., if something compromises part of the system component, it can not jeopardize the entire system, et al. In this sense, virtualization constitutes part of the cloud infrastructure nowadays, because it can reduce the use of multiple physical machines either in a public or private domain. A second application of virtualization is also related to the confinement offered by this technology, namely honeypots. A honeypot consisting of one or more computers that appear to be part of a production system, but in reality are isolated and semi unprotected, although they contain monitoring that records information about intrusions that may occur. Within this scope, a laboratory apparatus based on (i) virtualization, (ii) traffic analysis through a homemade firewall and (iii), honeypots were used to built a controlled and secure ecosystem in the cloud (vide figure below). The aforementioned laboratory presents an experimental setup based on the model two of virtualization produced under an Arch Linux distribution called Antergos [14].

b

 

Notar que, este tipo de arquitetura não permite uma comunicação direta com os compoenentes de hardware da máquina pois eles estão localizados sobre outra camada (designada por layer 2). Então, neste caso, o VMM VirtualBox gera uma interrupção para o SO e este gere todos os componentes de hardware e a troca de mensagens entre eles. A VM 1, denominada como VM 1 – Final, e posicionada sobre a esquerda na imagem, corre uma plataforma confiável e legítima num servidor linux Xubuntu. Ela aceita pedidos exclusivamente da VM 2, i.e., pedidos efetuados pela Network Interface Controller (NIC) com o endereço de Internet Protocol (IP) 192.168.1.42 (estas regras foram definidas via iptables). Em seguida é apresentada uma listagem onde se pode observar que apenas a VM 2 recebe pedidos de qualquer ponto da rede, seja ele interno ou externo.

Notice that this kind of architecture does not communicate straightly with hardware components, in fact, it is located under other communication layer (often designated by layer 2) . Then, VMM, VirtualBox in this case, it generates an interruption towards to OS and it manages all requests to hardware components. VM 1, denominated as VM 1 – Final, and positioned on the left side, hosts a trusted web-based platform and runs upon a Xubuntu distribution. However, in order to protect the system, this VM only accepts requests performed exclusively from VM 2, or better, requests executed from a Network Interface Controller (NIC) defined with the 192.168.1.42 Internet Protocol (IP) address. Notice that the schema previously discussed was performed on each VM via iptables. To corroborate that effort, listing 1 shows an echo request (ping) executed from Arch Linux (external system) to the three VMs.

1

 

Qualquer tentativa de comunicar com a VM 1 ou Vm 3 são barrados, pois apenas a VM 2 possui essa visibilidade. Quando um pedido entra na VM 2, daqui para a frente identificada como proxy-firewall, é processado e filtrado através de uma firewall que opera segundo regras definidas em duas bases de dados, nomeadamente a base de dados blacklist e SQLi XSS rules. A seguinte figura apresenta um esquema do funcionamento da proxy-firewall elaborada no contexto deste artigo.

From listing above, and as an expected result, packages arrive exclusively to VM 2. When a request comes to VM 2, hereinafter identified by proxy-firewall, it is filtered and processed through a firewall that operates based on rules defined in two databases, namely blacklist and SQLi XSS rules. The following figure presents a diagram activity in order to deliver a more concise information about this piece of software.

activity

Através da imagem é possível verificar que esta possui um conjunto de regras de forma a interpretar todos os pedidos recebidos. Se o endereço de IP origem do pedido estiver registado na base de dados blacklist, ele é automaticamente entregue na VM 3 (honeynet). Em seguida, o pedido é submetido também a uma segunda verificação contra XSS e SQLi. Caso uma destas verificações falhe o pedido é enviado para a Honeynet, caso contrário é catalogado como confiável e enviado para a VM 1 (a VM com o sistema legítimo). De notar que na VM da proxy-firewall corre também um script via crontab que elimina as entradas da blacklist passados x minutos (neste caso 5 minutos para efeitos de teste). Sempre que um pedido não passar as regras de verificação da proxy-firewall este é enviado para a honeynet. Esta representa um sistema com vários honeypots que são replicas do sistema legítimo (VM 1). Para construir a honeynet foi usada a tecnologia de virtualização Docker. Ela permite correr diferentes kernels de sistemas operativos [15], neste caso imagens do sistema operativo Linux (um Ubuntu e um CentOS). O  propósito desta honeynet é convidar os atacantes a despoletarem ataques com a finalidade de serem depois analisados e incrementar a segurança do sistema real.

As shown in diagram the proxy-firewall has the role to interpret all received requests. If request origin denotes a registry on blacklist database, it is redirected to the VM 3 (denominated as honeynet now). Next, the request is submitted to a second verification against XSS and SQLi malicious codes. Once failed, it is delivered to the honeynet, in otherwise labelled as trusted and processed towards VM 1. Notice that proxy-firewall VM runs a job in order to clean all the entries of the blacklist database every five minutes. This process was performed and based on schedule tasks using the crontab (identified as cronj on diagram). Finally, when the request is labelled as malicious and reaches to proxy-firewall is sent instantly to the honeynet. Here, there is a proxy which forward requests for various honeypots that represent system clones of VM 1. For this end, we used the Docker technology. It allows to run kernels of different OSs [15], in this case, images of Ubuntu and CentOS distributions. The purpose this honeynet, that combines a set of honeypots, is to invite attacks so that a malicious activities and methods can be studied and that information used to increase system security. As a final note, in order to protect VMs against Denial of Service (DoS) attacks, some specific configurations were also placed on iptables.

Ataques e seus Efeitos / Attacks and Its Effects

Esta secção discute brevemente alguns ataques na cloud e entrega algumas linhas sobre a segurança e resiliência da solução proposta. Neste sentido foram despoletados ataques XSS e SQLi para perceber qual o seu impacto na solução apresentada. Os ataques do tipo XSS foram conduzidos através do script mxsscanner disponível neste mesmo blog (link). Testes de SQLi foram elaborados a partir da ferramenta sqlmap, uma ferramenta bastante requisitada e conhecida no mundo da Information Security (Info Sec) para exploração de vulnerabilidades de injeção de SQL. De notar que foi posicionado um proxy de debug do lado do atacante com o objetivo de perceber o impacto e consequências do ataque (Charles proxy [16]]. Para agilizar esta tarefa foi enviada uma sequência de pedidos devidamente preparados. Estes foram enviados primeiramente para a proxy-firewall. Os pedidos legítimos foram endereçados para a VM 1 e estão destacados na seguinte imagem com o número de index 1, 2, 14, 15 e 16. Todos os outros representam pedidos maliciosos e desviados para a honeynet na VM 3.

This section elaborates on attack perspective in the cloud and aims to give some lines about the security and resilience of the implemented solution. For this end, XSS and SQLi attacks were performed in order to understand its effects on these systems. XSS attacks were carried out via a tool called mxsscanner available at seguranca-informatica.pt. To execute and evaluate the system from the security point-of-view was used the command-line-tool sqlmap, a well-know SQLi tool available on sqlmap.org. Notice that a web debugging proxy application positioned on the attacker side is suggested to reach a concise analysis of all received requests (Charles proxy available at [16]). To begin this task, a sequence of requests were prepared. In the first place, trusted requests are sent and interpreted on VM 2. As presented in figure 6, those requests are highlighted with the identifiers: 1, 2, 14, 15 and 16. Others represent malicious requests addressed to the honeynet available at VM 3.

capture

A partir da figura é possível verificar que os dois primeiros pedidos demoraram mais tempo que os restantes (120 e 102 milisegundos). Este resultado deve-se ao facto de a página não estar em cache, e foi, portanto, realizado o download dos ficheiros necessários aos pedidos e armazenados em cache para futuras ligações. Analisando os restantes pedidos, de entre eles pedidos submetidos à honeynet e à VM legítima, o tempo de execução mantém-se uniforme, isto é, não existe delay na entrega de mensagens derivado ao processamento middleware da proxy-firewall. As ferramentas de XSS e SQLi mencionadas acima demonstram ser ineficientes aquando do ataque uma vez que as regras estabelecidas via iptables e a filtragem de pedidos na proxy-firewall impediram que os pedidos maliciosos chegassem ao destino pretendido pela entidade maliciosa. Em seguida é apresentado um payload de teste executado pela ferramenta SQLi aquando do teste.

From figure, it is possible observing that first and second requests took more time to finish (120 and 102 milliseconds) in accordance with others. This result concludes that the page was not available in web-browser cache, therefore, the download of all files from server was done firstly, a slow procedure regarding other requests addressed along this experience. Most of the present requests on graph are delivered to honeynet, by which is concluded that the time to delivery the messages towards VM 3 is not directly affected by the local proxy, i.e., there is not a big delay during the message delivery process. The aforementioned tools to proven to be incapable pieces of software to attack the system because rules that block massive messages on proxy-firewall via iptables were established. In order to fight this problem an one-time payload, based on an article available at [17] was suggested (see listing below).

1

O payload apresentado é primeiramente interpretado pela proxy-firewall, baseado nas regras da base de dados XSS SQLi rules e o pedido é enviado de imediato para a honeynet por se tratar de um pedido do tipo malicioso. Em seguida é apresentado um trecho do log registado na proxy-firewall.

The presented payload is firstly interpreted by the proxy-firewall and based on the rules available at XSS SQLi rules database. The request is sent immediately to the honeynet because it was labelled was malicious. Then, a log excerpt recorded in proxy-firewall is displayed.

2

Depois de observar o trecho do log é possível identificar que na linha nove consta o payload malicioso. Este pedido foi portanto identificado como abusivo e direcionado para a honeynet. A partir deste momento todos os pedidos daquela origem são encaminhados para um dos honeypots disponíveis uma vez que foi adicionada uma regra de encaminhamento na proxy-firewall. Mais, a representação da palavra-passe obtida através de ataques desta natureza é uma representação de um dos honeypots (uma hash Message Digest 5 (MD5) falsa). O atacante com alguma perícia à mistura pode verificar que no header de cada pedido a máquina que consumiu cada um dos pedidos é diferente, pelo menos o  tipo servidor que consumiu o evento (Ubunto ou CentOS, ver abaixo). Esta informação foi obtida através da firewall local no lado do atacante (Charles proxy).

Regarding to proxy output file, in the nine line is depicted the SQLi malicious payload which gets the password representation stored in the MySQL metadata. However, this attempt was labelled as malicious and recorded in the blacklist, i.e., the attacker was automatically directed to the honeynet as result. At this moment, all triggered attacks are directed in an undesired direction, and the obtained password corresponds to a Message Digest 5 (MD5) representation from one clone system available on honeynet. The attacker could analyze what was mentioned, since that the HTTP header from request has embedded that information (vide listing 4). To carried out this task was used the referred Charles proxy.

3

Potencial Impacto dos Ataques Analisados no Ambiente Cloud / Potential Impact of the Analyzed Attacks in the Cloud Environment

Esta secção apresenta uma breve discussão sobre o impacto de ataques XSS e SQLi na cloud. Foi endereçado na secção anterior um grande interesse sobre este assunto uma vez que este ataques são facilmente reproduzidos em tais infraestruturas e as notícias diárias presentes na Info Sec são uma prova disso. Este facto confirma o crescimento exponencial de grupos hackivistas observado nesta era da informação. Por exemplo, estes grupos usam e abusam de campanhas phishing de forma a persuadir vitimas a clicar em anúncios ou links em campanhas maliciosas com a finalidade da vitima descarregar para o seu computador um malware, p.ex., um trojan, ou até links mascarados com XSS refletido. Por outro lado, o SQLi carateriza-se por se um ataque bastante requisitado e severo dentro do contexto da segurança da informação e das aplicações embebidas em ambientes cloud. Ele é visto como um canal de comunicação malicioso com a finalidade de obter informações confidenciais de bases de dados através do envio de payloads através de uma comunicação HTTP. A maior parte das vezes que um atacante obtém uma combinação utilizador/palavra-passe, o próximo passo reflete-se no acesso à página administrativa do sistema (backoffice). Este tipo de plataformas possui mecanismos para upload de ficheiros, geralmente imagens ou ficheiros Portable Document File (PDF), e isso acaba por ser um ponto de partida para o atacante. A integridade do sistema e a sua disponibilidade é posta em causa pois este é um ponto nevrálgico da segurança de qualquer sistema. Quando não são aplicados mecanismos de proteção neste tipo de mecanismos de upload de ficheiros esses indivíduos têm o habito de efetuar o upload de webshells via web-browser, como é exemplo a c99.php. Um dos problemas em ambientes cloud é que as supostas máquinas não passam de VMs. Mais, não passam de clones de VMs onde as definições transitam de clone para clone. Isto pode ser um grave problema de segurança, uma vez que permissões, processos e serviços sensíveis não são cuidados e desativados a priori, p.ex., chamadas a funções como  <php system(“cat /etc/passwd”); ?>. Neste caso em especifico o atacante executa comandos numa pagina web e eles são interpretados e executados nativamente na máquina. Um dos graves problemas é que um indivíduo malicioso pode tirar partido e obter informação sensível como é o caso do ficheiro /etc/passwd no linux, que contém os nomes dos utilizadores registados no sistema. Dentro deste cenário, o atacante pode tirar proveito de vulnerabilidades conhecidas em aplicações, bibliotecas ou simplesmente no OS. Uma vez que uma webshell permite acesso como um terminal o atacante pode tirar partido de atributos como integridade e isolamento de VMs, no pior dos casos acesso a outras VMs, criação de túneis de comunicação, acesso privilegiado ao VMM que gere outras VMs, entre outros. Para terminar esta secção considerar a importância dos honeypots em tais sistemas. Eles possibilitam obter uma arquitetura de monitorização que permite registar todos os tipos de ataques e incidentes no sistema (ver projeto honeypot [18]). Esta é uma maneira crucial para corrigir vulnerabilidades no sistema real e também protegê-los contra ataques desta natureza.

This section provides a discussion regarding the impact of XSS and SQLi attacks in the cloud environment. As noticed in the previous section, exists a stalwart motivation about this matter, once these attacks are easily reproduced on such infrastructures. Furthermore, on (Information Security) InfoSec community, a great amount of novel attacks and news have emerged. This fact confirms the fast growth of hacktivist groups observed in this era. XSS attacks produce a malicious effect associated to phishing, i.e., they have the action of persuade the user to perform actions with malicious intent, for example, creation of a malicious schema to force the victim to download a trojan malware. Nevertheless, SQLi characterizes an attack much more severe within this context. It is seen as a malicious communication channel in order to obtain sensitive information from databases by sending payloads via an HTTP communication. Once obtained authentication data from database (e.g., a user-password combination), next step is typically composed by the access to system administration backoffice. Features related to upload of files, usually denoted by images and (Portable Document File) PDF files is a function embedded in this kind of platforms. In this sense, this feature is widely used by hackers in order to load malicious files onto the machine which supports the system. Such persons, typically send web shells through an HTTP form, for example, c99.php, which allows to establish a connection with the machine via a web-browser. Many times, a server is simply a VM, and configurations related to functions/calls such as <?php system(“cat /etc/passwd“); ?> are not disabled. In these cases, the attacker executes commands on a web page that are sent, interpreted and executed natively in a terminal. One of the serious problems is the possibility to obtain sensitive content from files as /etc/passwd, which contains the usernames registered in the system. Within this scenario, the attacker can take advantage of known vulnerabilities in applications, libraries or simply on OS. Since there is access to the OS shell via a web-browser, if it is based on an VM architecture, the attacker can take benefit of attributes such as completeness and isolation in VMs. In most cases, access to other VMs, creating of communication tunnels, direct access to VMM that manages a great quantity of VMs, et cetera, represents an uncomplicated mission and a dangerous issue that emphasizes the security and its importance within this matter. To end this section consider the importance of honeypots in such systems. Normally, it is constructed a monitoring architecture that allows to register all type of attacks and incidents on system (see honeypot project [18]). This is a crucial manner to fix vulnerabilities in the real system, and protect them against such attacks.

Conclusão e Trabalho Futuro / Conclusion and Future Work

Este artigo apresenta um estudo e um contributo para a segurança de sistemas em ambientes na cloud. O principal objetivo deste trabalho foi descrever e analisar algumas linhas sobre este tema e produzir uma montagem experimental para demonstrar a eficiência e a resiliência deste tipo de mecanismos. Ele também descreve uma série de experiências efetuadas com uma honeynet neste tipo de contexto.  Os resultados mostram que não existe uma grande demora entre os pedidos enviados tanto para o sistema real como para o sistema falso (a honeynet). Outra questão interessante está relacionada com o proxy-firewall que representa uma camada crucial da comunicação e filtragem de pedidos e que impede a entrada de potenciais pedidos maliciosos na infraestrutura. Esta peça de software corresponde a uma solução caseira com base em regras para filtrar todos os pedidos em um canal em particular. Finalmente o uso de honeypots corrobora a necessidade de implementar este tipo de mecanismos de segurança em ambientes distribuídos como é a cloud, a fim de melhorar a segurança de todo o serviço e promover uma maior confiança por parte do cliente neste recente paradigma. Para trabalho futuro fica a melhoria do sistema, nomeadamente através da integração de monitorização de honeypots. Para concluir este artigo seria interessante testar ataques Distributed Denial of Service (DDoS) neste tipo de ecossistemas e verificar o seu impacto.

This article presents a study within the scope of the virtualization in the cloud infrastructure. The main goal this work was to describe and analyze some lines about this matter and to produce an experimental setup in order to demonstrate the efficiency and resilience this kind of mechanisms. It also describes a series of experiments conducted on the honeynet. The results show that does not exist great delay when requests are sent to the available honeypots. Other interesting matter is related to the proxy-firewall that represents a crucial layer of communication carried out along this paper. This piece of software corresponds to an homemade solution based on rules to filter all requests on a particular channel. Finally, the use of honeypots corroborates the necessity to implement mechanisms in order to capture malicious entries, so that a malicious activities and methods can be studied and that information used to increase system security. Future lines of work include the improvement of system, namely via the integration of honeypots monitoring. To conclude this article, it would be interesting to test Distributed Denial of Service (DDoS) attacks and its effects in the system.

Referências / Reference

[1] Amazon EC2 webpage, https://aws.amazon.com/pt/ec2/
[2] Google Cloud webpage, https://cloud.google.com/
[3] IBM Cloud Solution webpage, http://www.ibm.com/cloud-computing/us/en/
[4] Microsoft Cloud webpage, http://www.microsoft.com/enterprise/microsoftcloud/
[5] National Institute for Standards and Technology, Cloud Computing Standards Roadmap, June, 2013. http://www.nist.gov/itl/cloud/upload/NIST SP-500-291 Version-2 2013 June18 FINAL.pdf
[6] Diogo A. B. Fernandes, Liliana F. B. Soares, Joo V. Gomes, Mário M. Freire, and Pedro R. M. Incio, Security Issues in Cloud Environments - A Survey, International Journal of Information Security (IJIS), 13(2):113- 170, April 2014. ISSN 1615-5262. Institute for Scientific Information (ISI) Impact Factor (2012): 0.480.
[7] Foster and Kesselman: The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 2003 (secound edition in 2004 with the title GRID2).
[8] Miguel P. Correia and Paulo J. Sousa, Segurança no Software, pag:339- 363. ISBN 978-972-722-662-7, fca.pt.
[9] VMware official webpage, http://www.vmware.com/
[10] Xen Project webpage, http://www.xenproject.org/
[11] VirtualBox official webpage, https://www.virtualbox.org/
[12] Microsoft Virtual PC, https://www.microsoft.com/pt-pt/download/details.aspx?id=3702
[13] Parallels official webpage, http://www.parallels.com/
[14] Antergos, Arch Linux distribution webpage, https://antergos.com/
[15] Docker official webpage, https://www.docker.com/
[16] Charles, Web debugging proxy application, http://www.charlesproxy.com
[17] SQLi article available on seguranca-informatica blog, http://blog.
seguranca-informatica.pt/advanced-topics-in-sqli/
[18] Honeypot project official webpage, https://www.honeynet.org/project,

 

Código da proxy-firewall / Proxy-firewall source code

load 'lib.rb'

#---------- configuration IPs --------#
$legitim_ip  = "192.168.1.41:80"
$honeynet_ip = "192.168.1.43:8080"
#-------------------------------------#

class AppProxy < Rack::Proxy
  #Delivery request to destination
  def rewrite_env(env)
    request = Rack::Request.new(env)
    @uri=env["REQUEST_URI"]
    @[email protected]_s
    @remote_host=env["REMOTE_ADDR"]
    env=firewall(env, request)
    env['rack.input'].rewind
    env
  end

  # read rules
  def read_rules(name)
     array=[]
     file = File.new(name, "r")
     while (line=file.gets)
       array << line
     end
     array
  end

  #Simple firewall to filter malicious content 
  def firewall (env, request)
     # Verify black-list IPs
     black_list=read_rules("black-list")
     black_list.each do |ip|
       if @remote_host == ip
          puts "********* BLACK-LIST : Forwarding to Honeynet [#{$honeynet_ip}] ********"
          env["HTTP_HOST"] = $honeynet_ip
          return env
       end
     end

     #load XSS rules
     rules=read_rules("xss_sqli.rules")

     malicious=false
     rules.each do |rule|
       if @uri.include?(rule)
         malicious=true
         break
       end
     end

     if malicious
      puts "********* Forwarding to Honeynet [#{$honeynet_ip}] ********"
      env["HTTP_HOST"] = $honeynet_ip
      puts "======== IP added to blacklist [#{@remote_host}] ==========="
      File.open("black-list", "w") { |file| file.write(@remote_host)}      
     else
      puts "********* Forwarding to Legitim VM [#{$legitim_ip}] *********"
      env["HTTP_HOST"] = $legitim_ip
     end
    return env
  end
end

post '/*' do
  AppProxy.new.call(request.env)
end

run AppProxy.new