No ano em que a InterCon comemora seus 10 anos, dois colaboradores da Conviso, Ulisses Castro e Leandro Rocha, foram convidados a participar de uma arena hacker durante o evento, realizado das 20h do dia 8 de novembro até as 3h da madrugada do dia 9 de novembro. Eles foram convidados a fazer um hacking ao vivo com a finalidade de mostrar como as pessoas estão vulneráveis, muitas vezes por falta de atenção em pequenos detalhes, e também, pela não pratica de simples procedimentos que possam ser tomados antes do trafego de dados ou a inserção de uma senha, como é mostrado mais detalhadamente no vídeo abaixo:
segunda-feira, 9 de dezembro de 2013
quarta-feira, 20 de novembro de 2013
DevOps e a estratégia de segurança de aplicações
O que é DevOps?
segunda-feira, 28 de outubro de 2013
Cross-Site Scripting usando CSS
Quando estamos executando um projeto de revisão de código, sempre que encontramos algum trecho de código suspeito, investimos um certo tempo para ter a certeza que aquele ponto é ou não uma vulnerabilidade.
Em um destes projetos, nos deparamos com um trecho de código similar ao abaixo:
Arquivo: arquivo_teste.php
---
1 <html> 2 <head> 3 <style> 4 <?php echo strip_tags($_GET['style']); ?> 5 </style> 6 </head> 7 <body> 8 </body> 9 </html>---
Neste caso, a chamada a função strip_tags() não será suficiente para evitar que ataques de Cross-Site Scripting sejam realizados com sucesso. Através de códigos CSS, que não precisam das tags que são removidas pela função strip_tags(), é possível inserir códigos Javascript que serão interpretados por alguns browsers. É o caso do método expression()[1] para o Internet Explorer (IE) e a propriedade CSS -moz-binding para o Gecko, utilizado pelo Firefox. Aqui iremos falar apenas sobre o caso do IE. O método 'expression()' funciona por padrão no IE versão 5 até 7 e 8 ou superior em modo compatibilidade [2].
Com base nisso, utilizei o seguinte payload para chamar o método alert() e imprimir a mensagem 'CODIGO_MALICIOSO_EXECUTADO' no IE versão 10 executado em modo de compatibilidade.
Com base nisso, utilizei o seguinte payload para chamar o método alert() e imprimir a mensagem 'CODIGO_MALICIOSO_EXECUTADO' no IE versão 10 executado em modo de compatibilidade.
body{
left:expression(alert(String.fromCharCode(0×43,0×4f,0×44,0×49,0×47,0×4f,0×5f,0×4d,0×41,0×4c,0×49,0×43,0×49,0×4f,0×53,
0×4f,0×5f,0×45,0×58,0×45,0×43,0×55,0×54,0×41,0×44,0×4f)));
}
Foi necessário usar o método '.fromCharCode' do objeto 'String' porque no ambiente de teste, a opção magic_quotes do PHP estava habilitada, evitando a inserção do carácter aspas-simples.
Em [3] também há outros exemplos, inclusive a utilização do -moz-binding para execução de códigos Javascript.
[1] - http://msdn.microsoft.com/en-us/library/ms537634.aspx
[2] - http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-expressions.aspx
[3] - https://code.google.com/p/google-caja/wiki/CssAllowsArbitraryCodeExecution
quarta-feira, 23 de outubro de 2013
[Update CSC] - Novas funcionalidades: Tags e Dashboard interativo
Sempre buscando inovar e facilitar a gestão das vulnerabilidades, bem como melhorar a granularidade das métricas, adicionamos a funcionalidade de Tags ao produto. A antiga aba Áreas agora chama-se Tags, sendo que as Áreas já existentes agora são Tags.
Um dos grandes diferenciais dessa nova funcionalidade é que os projetos agora podem participar de várias Tags, não somente uma como eram com as Áreas.
Com essa granularidade em potencial, os Dashboards ficaram mais poderosos pois podem ter filtros e comparações entre múltiplas Tag. Abaixo um passo a passo com exemplos e uso da nova funcionalidade :
1. Adição de Nova Tag
Ao criar ou editar um projeto (Figura 1), você poderá simplesmente digitar a nova Tag que deseja, apertar Enter e quando salvar a edição ou novo projeto, a Tag será salva. Na opção Tags do menu, você poderá clicar em “Nova Tag”, digitar o nome e salvar (Figura 2).
 |
| Figura 1 |
[1] – Para criar uma nova Tag, simplesmente digite e salve a edição, no próximo projeto ela estará na listagem.
 |
| Figura 2 |
2. Editando um projeto
Um projeto agora pode pertencer a várias Tags (Figura 3), não somente a uma Área como era anteriormente, essa configuração também poderá ser feita de duas maneiras. O mesmo processo pode ser feito na opção Tags do menu (Figura 4).
 |
| Figura 3 |
[1] – Clicando em lista você terá acesso a todas as Tags cadastradas no seu escopo
[2] – Nessa campo caso comece a digitar o nome da Tag, terá a opção de auto complete. Caso queira uma Tag ainda não existente, simplesmente digite e salve a edição, no próximo projeto ela estará na listagem
 |
| Figura 4 |
[1] Selecione a Tag que deseja ver os projetos associados ou que adicionara algum projeto
[2] Selecione os projetos que deseja selecionar a Tag selecionada, os projetos já marcados já são parte da Tag, quando clicar aparecerá que está salvando. O projeto já está como parte da Tag.
3. Dashboard
No Dashboard é possível é comparar projetos buscando por Tags distintas. Na Figura 5 comparamos dois departamentos que contenham servidores que façam parte do escopo PCI.
No Dashboard é possível é comparar projetos buscando por Tags distintas. Na Figura 5 comparamos dois departamentos que contenham servidores que façam parte do escopo PCI.
 |
| Figura 5 |
[1] Listagem das tags, para selecionar
[2] Tags selecionadas no filtro, pode digitar e tem o sistema de auto completar.
[3] Opção de especificar período que deseja as dashboards, por padrão pegará tudo cadastrado.
4. Drill down nos gráficos
O resultados dos filtros da dashboard (Figura 6) podem ser clicados, dando opção rápida para análise detalhada das falhas.
 |
| Figura 6 |
[1] Clicando em cima do Path traversal por exemplo, ele respeitará o filtro da dashboard além de especificar esse ataque, resultando no resultado da Figura 7.
[2] Caso queira listar as 11 falhas críticas, bastaria clicar no Alto conforme apontado na imagem.
 |
| Figura 7 |
Clientes com dúvidas poderão solicitar uma Conferência Web para melhor explicação, teremos enorme prazer em detalhar as novidades.
quarta-feira, 16 de outubro de 2013
Gestão de Segurança em Banco de Dados
Além da aplicação que é a interface com os usuários, existem outros recursos que trabalham em conjunto, cooperando entre si para que seu serviço consiga entregar valor a quem o usa e que se não estiverem protegidos adequadamente poderão ser explorados por um atacante, comprometendo seus investimentos.
Quando se discute segurança em aplicações geralmente a primeira coisa a se pensar é fazer um trabalho de Pentest na interface da aplicação para encontrar vulnerabilidades. Por outra perspectiva, eu pergunto: "e seu Banco de Dados, está seguro?".
Nesta dissertiva será evitado especificar uma tecnologia como DB2, Oracle, SQL Server, PostgreSQL, MySQL etc. Inclusive os Bancos de Dados conhecidos como NoSQL. Veremos uma versão global de gestão para proteção de repositórios de dados.
De acordo com a estrutura da NBR ISO/IEC 27001, o Item 3 (três) que especifica os "Termos e Definições", podemos destacar três importantes itens (existem outros que não será foco da nossa proposta atual) que descrevem bem o que será tratato aqui:
Você pode estar se perguntando sobre a demanda que não é um termo de segurança da informação e sim apenas uma questão de recursos computacionais como configuração, adicionar mais memória, usar um melhor processador, adicionar redundância ou distribuição dos recursos. Mas existe uma outra faceta da disponibilidade. Imagine agora se o seu servidor de Banco de Dados estiver sofrendo um ataque de Denial of Service (DoS). Isto, também, pode afetar no atendimento a sua demanda. E pior, isso pode deixar o serviço indisponível. Logo disponibilidade por demanda é, também, item de segurança da informação.
Outro ponto importante é a administração de usuários de um Banco de Dados. É comum encontrar um mesmo usuário que tenha acesso a várias databases sem que as databases se relacionem. Ou seja, uma mesma empresa com diferentes aplicações e um único usuário no Banco de Dados. Esta prática é condenável, pois se alguém indevidamente consegue as credenciais de uma aplicação todas as databases serão afetadas e não apenas uma. Para piorar não é novidade aplicações usarem a senha de administrador (ou de root ou do system) do Banco de Dados que, em posse do atacante, dará autonomia completa ao repositório de dados.
Para mitigar esse problema é necessário que cada diferente aplicação tenha seu próprio usuário
(diferente do usuário administrador ou root ou system)
no Banco de Dados limitado a certa(s) database(s). Para cada database é possível, também, dizer
se o usuário tem acesso apenas read-only (só leitura) e/ou de escrita. Indo mais além, é possível
limitar o acesso por endereço IP de origem. Isso completa o que chamamos de Confidencialidade.
A grande maioria dos SGDBs (Sistemas Gerenciadores de Banco de Dados) tem o conceito de ACID (Atômicidade, Consistência, Isolamento e Durabilidade) que caracteriza as transações em um Banco de Dados. Transações são unidades lógicas de trabalho. Ou seja, quando iniciadas não devem sofrer interferências externas até chegar ao seu fim.
Outras dicas importantes:
Quando se discute segurança em aplicações geralmente a primeira coisa a se pensar é fazer um trabalho de Pentest na interface da aplicação para encontrar vulnerabilidades. Por outra perspectiva, eu pergunto: "e seu Banco de Dados, está seguro?".
Nesta dissertiva será evitado especificar uma tecnologia como DB2, Oracle, SQL Server, PostgreSQL, MySQL etc. Inclusive os Bancos de Dados conhecidos como NoSQL. Veremos uma versão global de gestão para proteção de repositórios de dados.
De acordo com a estrutura da NBR ISO/IEC 27001, o Item 3 (três) que especifica os "Termos e Definições", podemos destacar três importantes itens (existem outros que não será foco da nossa proposta atual) que descrevem bem o que será tratato aqui:
- Disponibilidade: propriedade de estar acessível e utilizável sob demanda por uma entidade autorizada
- Confidencialidade: propriedade de que uma informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados.
- Integridade: propriedade de salvaguarda da exatidão e completeza de ativos
Você pode estar se perguntando sobre a demanda que não é um termo de segurança da informação e sim apenas uma questão de recursos computacionais como configuração, adicionar mais memória, usar um melhor processador, adicionar redundância ou distribuição dos recursos. Mas existe uma outra faceta da disponibilidade. Imagine agora se o seu servidor de Banco de Dados estiver sofrendo um ataque de Denial of Service (DoS). Isto, também, pode afetar no atendimento a sua demanda. E pior, isso pode deixar o serviço indisponível. Logo disponibilidade por demanda é, também, item de segurança da informação.
Outro ponto importante é a administração de usuários de um Banco de Dados. É comum encontrar um mesmo usuário que tenha acesso a várias databases sem que as databases se relacionem. Ou seja, uma mesma empresa com diferentes aplicações e um único usuário no Banco de Dados. Esta prática é condenável, pois se alguém indevidamente consegue as credenciais de uma aplicação todas as databases serão afetadas e não apenas uma. Para piorar não é novidade aplicações usarem a senha de administrador (ou de root ou do system) do Banco de Dados que, em posse do atacante, dará autonomia completa ao repositório de dados.
Para mitigar esse problema é necessário que cada diferente aplicação tenha seu próprio usuário
(diferente do usuário administrador ou root ou system)
no Banco de Dados limitado a certa(s) database(s). Para cada database é possível, também, dizer
se o usuário tem acesso apenas read-only (só leitura) e/ou de escrita. Indo mais além, é possível
limitar o acesso por endereço IP de origem. Isso completa o que chamamos de Confidencialidade.A grande maioria dos SGDBs (Sistemas Gerenciadores de Banco de Dados) tem o conceito de ACID (Atômicidade, Consistência, Isolamento e Durabilidade) que caracteriza as transações em um Banco de Dados. Transações são unidades lógicas de trabalho. Ou seja, quando iniciadas não devem sofrer interferências externas até chegar ao seu fim.
- Atômicidade: Uma transação não pode ser dividida.
- Consistência: Uma transação deve ser iniciada a partir de um estado consistente do Banco de Dados para outro estado, também, consistente.
- Isolamento: Conjunto de técnicas para que transações paralelas não interfiram uma nas outras.
- Durabilidade: Os efeitos de uma transação devem ser persistidas (commit) no Banco de Dados
Outras dicas importantes:
- Se todas as conexões do seu Banco de Dados são realizadas de um único IP de origem configure-o para só aceitar conexões deste IP.
- Atualize sempre o executável e as bibliotecas do Banco de Dados, atento as correções de falhas de segurança.
- Faça com que o sistema de arquivos onde fica os dados do banco fique protegido para que só o Administrador de Sistemas (ou, no caso do Linux, o root) tenha acesso.
- Utilize senhas fortes para o usuário administrador ou root ou system.
Assinar:
Postagens (Atom)