Tweet
Autor: Placker
Parte 4
Expedientes de Segurança:
Quando um bug é descoberto deve informar-se correctamente. Para isso cada fabricante de software costuma manter sua própria forma de codificar os expedientes de segurança, mas surgiram na Internet muitas empresas que se dedicaram a manter suas próprias bases de dados de expedientes de segurança. O trabalho é árduo se pensarmos na quantidade de projectos de software e o rápido que se descobrem novos bugs, com o qual é impossível dizer que um banco de dados tem todos os erros conhecidos. O que se está claro é que algumas se transformaram em um standard de facto. As duas bases de dados mais utilizadas pela gente que se dedica a segurança são Bugtraq de SecurityFocus [Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... e CVE (Common Vulnerabilities and Exposures) [Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... Ambas bases de dados codificam cada erro com um identificador e a partir daí se analisa o software vulnerável, o software não vulnerável que poderia ser susceptível de sê-lo por ser parte da família de produtos ou versões, se discute sobre qual poderia ser o alcance de dito bug, se existe ou não o exploit disponível para esse erro e qual é a solução oferecida pelo fabricante. A vantagem destas bases de dados, é que em qualquer momento se podem consultar todos os expedientes de segurança relativos a um determinado produto e versão para ver quais são as soluções a aplicar.
Imagem: Últimos expedientes em Bugtraqid
Imagem: Expediente de Segurança de um Bug
Como se pode ver na imagem, os expedientes de segurança armazenam os exploits associados a estes erros, depois, se o servidor tem um erro sem regular e o exploit é público nosso servidor está em um claro risco, mas, mesmo que o exploit não seja público se devem aplicar as medidas de solução que recomende o fabricante já que, muitos exploits, devido a sua importância ou impacto são de pagamento e pode que existam e estejam circulando por Internet. É preciso lembrar que os rumores falam de preços exagerados para exploits de produtos populares ou de alto nível de credibilidade. Na imagem se pode apreciar como security focus, relaciona sua codificação com a codificação CVE.
Scanners de Exploração:
Uma das ferramentas que costumam aparecer justo depois que se tenha tornado público o bug é o exploit associado são scanners que implementam motores de busca de servidores vulneráveis a esse erro e um mecanismo para executar dito exploit. Estão preparados para atirá-los de forma cômoda, já que a maioria das vezes se requer fazer modificações nas POC para que estas funcionem em diferentes ambientes, isto é, se requer certo nível técnico para poder utilizá-los, enquanto com estas ferramentas costuma ser tão fácil como aplicar botões. Alguns exemplos destas ferramentas nas seguintes capturas:
Imagem: “RPC Jode Jode”. Antigo scanner para um erro RPC.
Imagem: WebDAVScan. Para detectar Servidores com WebDAV activado.
Imagem: WebDAV Exploit. Associado ao WebDAVScan
Atualizações de Segurança ou paths:
A maioria das soluções que se aplicam aos erros de segurança do software costumam ser as actualizações de Segurança ou também chamados paths que nos oferece o próprio fabricante. Estes remendos devem ser aplicados o mais rápido possível, após haver realizado previamente as comprovações que estes não afectam ao funcionamento normal de nossa infra-estrutura certamente. A premência na aplicação dos remendos se deve a que no momento em que se publica um remendo se está acelerando a criação dos exploit. Por que? Pois porque o contar com o software sem patchear e com o software patcheado permite aos criadores de exploits realizar engenharia inversa localizada. A ideia é simples, se realiza uma imagem do sistema sem parchear e depois outra imagem com o sistema patcheado, se comparam e se buscam as diferenças. Quando se têm localizados os arquivos modificados se realizam comparações desses arquivos e mediante as técnicas de debugging, similares às utilizadas para a criação craques, se procura o ponto de erro no programa. Digamos que publicar um remendo é marcar o lugar do problema por isso é muito importante actualizar o mais rápido possível. Isto fez com que agora se fale que o segundo terça-feira de cada mês, dia que Microsoft há públicas suas actualizações de segurança seja o dia do remendo e que o segunda quarta-feira de cada mês seja o dia do exploit.
Microsoft Baseline Security Analyzer:
O primeira ferramenta que se deve utilizar para realizar uma auditoria de whitebox sua ou minha empresa é o MBSA, que vai a permitir-nos comprovar se alguma equipe ou servidor de B]nossa empresa lhe falta alguma actualização de segurança. Esta ferramenta é da Microsoft e portanto só nos vai comprovar as actualizações de segurança dos produtos Microsoft, por isso se temos software de outras empresas, o primeiro é ver como se distribuem, se actualiza e se comprova se nossos produtos têm ou não todas as actualizações de segurança aplicadas.
Imagem: Microsoft Baseline Security Analyzer
MBSA não é só uma ferramenta para buscar remendos não instalados, mas além disso é o que denominamos uma ferramenta de Auditoria de whitebox, porque nos vai apanhar informação sobre o sistema relativa a segurança, desde a política de senhas, a configuração de segurança do servidor web ou os serviços correndo. É whitebox porque exige a utilização das credenciais de um usuário e é o primeiro que se deve realizar em qualquer auditoria de segurança de servidores Microsoft. Mais informação sobre MBSA na seguinte URL: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Na mesma linha que MBSA, Microsoft oferece mais duas ferramentas, todas gratuitas, que são MS Exchange Best Practices Analyzer e MS SQL Server Best Practices Analyzer. Estas ferramentas não ficam só na configuração de segurança mas além disso ajudam a ajustar os servidores para poder aplicar meias de defesa em profundidade ou ajuste do rendimento. Se vamos analisar a segurança e um servidor os relatórios oferecidos por estas ferramentas são importantes e a ter muito em conta.
E o ultimo artigo:
Pois no último artigo desta série veremos as ferramentas de scaneamento de vulnerabilidades e como se deve realizar um processo completo da auditoria que será no capitulo 6.
Parte 4
Expedientes de Segurança:
Quando um bug é descoberto deve informar-se correctamente. Para isso cada fabricante de software costuma manter sua própria forma de codificar os expedientes de segurança, mas surgiram na Internet muitas empresas que se dedicaram a manter suas próprias bases de dados de expedientes de segurança. O trabalho é árduo se pensarmos na quantidade de projectos de software e o rápido que se descobrem novos bugs, com o qual é impossível dizer que um banco de dados tem todos os erros conhecidos. O que se está claro é que algumas se transformaram em um standard de facto. As duas bases de dados mais utilizadas pela gente que se dedica a segurança são Bugtraq de SecurityFocus [Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... e CVE (Common Vulnerabilities and Exposures) [Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... Ambas bases de dados codificam cada erro com um identificador e a partir daí se analisa o software vulnerável, o software não vulnerável que poderia ser susceptível de sê-lo por ser parte da família de produtos ou versões, se discute sobre qual poderia ser o alcance de dito bug, se existe ou não o exploit disponível para esse erro e qual é a solução oferecida pelo fabricante. A vantagem destas bases de dados, é que em qualquer momento se podem consultar todos os expedientes de segurança relativos a um determinado produto e versão para ver quais são as soluções a aplicar.
Imagem: Últimos expedientes em Bugtraqid
Imagem: Expediente de Segurança de um Bug
Como se pode ver na imagem, os expedientes de segurança armazenam os exploits associados a estes erros, depois, se o servidor tem um erro sem regular e o exploit é público nosso servidor está em um claro risco, mas, mesmo que o exploit não seja público se devem aplicar as medidas de solução que recomende o fabricante já que, muitos exploits, devido a sua importância ou impacto são de pagamento e pode que existam e estejam circulando por Internet. É preciso lembrar que os rumores falam de preços exagerados para exploits de produtos populares ou de alto nível de credibilidade. Na imagem se pode apreciar como security focus, relaciona sua codificação com a codificação CVE.
Scanners de Exploração:
Uma das ferramentas que costumam aparecer justo depois que se tenha tornado público o bug é o exploit associado são scanners que implementam motores de busca de servidores vulneráveis a esse erro e um mecanismo para executar dito exploit. Estão preparados para atirá-los de forma cômoda, já que a maioria das vezes se requer fazer modificações nas POC para que estas funcionem em diferentes ambientes, isto é, se requer certo nível técnico para poder utilizá-los, enquanto com estas ferramentas costuma ser tão fácil como aplicar botões. Alguns exemplos destas ferramentas nas seguintes capturas:
Imagem: “RPC Jode Jode”. Antigo scanner para um erro RPC.
Imagem: WebDAVScan. Para detectar Servidores com WebDAV activado.
Imagem: WebDAV Exploit. Associado ao WebDAVScan
Atualizações de Segurança ou paths:
A maioria das soluções que se aplicam aos erros de segurança do software costumam ser as actualizações de Segurança ou também chamados paths que nos oferece o próprio fabricante. Estes remendos devem ser aplicados o mais rápido possível, após haver realizado previamente as comprovações que estes não afectam ao funcionamento normal de nossa infra-estrutura certamente. A premência na aplicação dos remendos se deve a que no momento em que se publica um remendo se está acelerando a criação dos exploit. Por que? Pois porque o contar com o software sem patchear e com o software patcheado permite aos criadores de exploits realizar engenharia inversa localizada. A ideia é simples, se realiza uma imagem do sistema sem parchear e depois outra imagem com o sistema patcheado, se comparam e se buscam as diferenças. Quando se têm localizados os arquivos modificados se realizam comparações desses arquivos e mediante as técnicas de debugging, similares às utilizadas para a criação craques, se procura o ponto de erro no programa. Digamos que publicar um remendo é marcar o lugar do problema por isso é muito importante actualizar o mais rápido possível. Isto fez com que agora se fale que o segundo terça-feira de cada mês, dia que Microsoft há públicas suas actualizações de segurança seja o dia do remendo e que o segunda quarta-feira de cada mês seja o dia do exploit.
Microsoft Baseline Security Analyzer:
O primeira ferramenta que se deve utilizar para realizar uma auditoria de whitebox sua ou minha empresa é o MBSA, que vai a permitir-nos comprovar se alguma equipe ou servidor de B]nossa empresa lhe falta alguma actualização de segurança. Esta ferramenta é da Microsoft e portanto só nos vai comprovar as actualizações de segurança dos produtos Microsoft, por isso se temos software de outras empresas, o primeiro é ver como se distribuem, se actualiza e se comprova se nossos produtos têm ou não todas as actualizações de segurança aplicadas.
Imagem: Microsoft Baseline Security Analyzer
MBSA não é só uma ferramenta para buscar remendos não instalados, mas além disso é o que denominamos uma ferramenta de Auditoria de whitebox, porque nos vai apanhar informação sobre o sistema relativa a segurança, desde a política de senhas, a configuração de segurança do servidor web ou os serviços correndo. É whitebox porque exige a utilização das credenciais de um usuário e é o primeiro que se deve realizar em qualquer auditoria de segurança de servidores Microsoft. Mais informação sobre MBSA na seguinte URL: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Na mesma linha que MBSA, Microsoft oferece mais duas ferramentas, todas gratuitas, que são MS Exchange Best Practices Analyzer e MS SQL Server Best Practices Analyzer. Estas ferramentas não ficam só na configuração de segurança mas além disso ajudam a ajustar os servidores para poder aplicar meias de defesa em profundidade ou ajuste do rendimento. Se vamos analisar a segurança e um servidor os relatórios oferecidos por estas ferramentas são importantes e a ter muito em conta.
E o ultimo artigo:
Pois no último artigo desta série veremos as ferramentas de scaneamento de vulnerabilidades e como se deve realizar um processo completo da auditoria que será no capitulo 6.