Assinatura digital é utilizada quando se necessita da certeza da origem de uma mensagem como se fosse uma assinatura escrita no papel. Para assinar um applet, o desenvolvedor empacota todo o código Java e arquivos relacionados dentro de um arquivo JAR (Java ARchive), que é um formato de arquivo de compactação de propósito geral, usado para compactar os componentes de uma aplicação Java. A plataforma Java assina e verifica arquivos JAR usando um par de chaves (chave pública e chave privada). A chave privada funciona como uma “caneta” eletrônica que assina o arquivo (ver Figura 1). Como o próprio nome sugere, esta chave só é conhecida pelo assinante do applet. O processo de verificação da assinatura pode ser feito por qualquer pessoa que possua a chave pública correspondente a chave que assinou o arquivo.

Figura 1 – Processo de assinatura

A chave pública é distribuída dentro de um certificado que é uma declaração assinada por uma entidade idônea, chamada Autoridade de Certificação (Certification Authority- CA), que confirma que a chave pública que está no mesmo é confiável. Existem várias Autoridades de Certificação, por exemplo, a VeriSign, Thawte, Entrust e Certisign (empresa brasileira). Toda CA requer um emissor para validar a sua identidade, até mesmo a de mais alto nível. Para estes casos, existem os certificados auto-assinados (self-signed), onde o emissor do certificado é o próprio sujeito.Os browsers Netscape e Internet Explorer (IE) não usam a codificação de assinatura do JDK. Existem basicamente três tipos diferentes de assinatura de applets, para o IE, para o Netscape, e para o plug-in Java da Sun. Este último fornece aos browsers citados acima a capacidade de utilizar applets assinados através da Java Security API do kit JDK.Algumas ferramentas necessárias para a assinatura, seguindo o padrão da Sun, encontram-se no JDK 1.2, são elas:

• Jar (JAR Creation Tool)

• Keytool (Key and Certificate Management Tool)

• Jarsigner (JAR Signing and Verification Tool)

• PolicyTool (Policy File Creation and Management Tool)

Para uma melhor compreensão, encontra-se descritos a seguir os passos utilizados no processo de assinatura e verificação do AppletClient.

Quais são os passos para assinar um Applet?

Os passos para assinar um Applet estão representados na Figura 2:

Figura 2 – Diagrama de blocos do processo de assinatura por parte do desenvolvedor

1. Criar o arquivo .jar

Deve-se criar um arquivo JAR contendo o(s) arquivo(s) .class da Applet e todas as classes que serão utilizadas e que farão uso de recursos fora do sandbox conforme indicado no item 1 da Figura 2. É importante ressaltar que a ferramenta jarsigner somente assinará arquivos JAR criados pelo JDK, ou arquivos ZIP.Uma ferramenta utilizada para criação deste arquivo é o jar do JDK. Para criar um JAR contendo o arquivo MeuApplet.class, com o nome MeuJar.jar basta fazer:jar cvf MeuJar.jar MeuApplet.class

Você também pode utilizar o Eclipse ou MyEclipse para criar arquivos tipo .jar, onde o processo é bem simples: basta clicar com o botão direito do mouse sobre o arquivo que deseja empacotar em .jar e escolher a opção exportar.

2. Gerar o par de chaves (pública e privada) Este passo deve ser executado se ainda não houver um par de chaves a ser usado no processo de assinatura (ver item 2 da Figura 2). Para criar o par de chaves utiliza-se a ferramenta keytool do JDK. Simplificando, você pode fazer o seguinte:

keytool -genkey -dname “cn=d377, ou=desenvolvimento, o=FelipeThomas, l=Fortaleza, c=BR” -alias key -keystore C:\Felipe -storepass 123456 -validity 180

onde:

dname: Nome da entidade que gerará o par de chaves. Siglas:

CN = nome comum

OU = unidade organizacional (departamento, divisão)

O = nome da organização

L = nome da localidade (cidade)

S = estado, C = código do país.

Keypass: Senha utilizada para a proteção da chave no keystore.

Validity: Número de dias que o certificado deve ser válido.

keystore: local da sua máquina onde as chaves serão armazenadas.

Storepass: Senha protetora do keystore.

Quando as chaves são geradas (comando –genkey) um certificado auto-assinado é criado. Caso deseje-se trocar este certificado por um certificado reconhecido por uma empresa confiável, deve-se fazer um pedido de certificado de assinatura (CSR CerticateSigning Request), e o resultado desta solicitação deve ser importado para o keystore.

3. Assinar o arquivo JAR

Deve-se assinar o arquivo JAR com a chave privada, para isto utiliza-se a ferramenta jarsigner do JDK, conforme esquematizado no item 3 da Figura 2. Antes de continuar certifique-se de que o arquivo que você assinará, esteja no mesmo diretório do arquivo que foi criado com as chaves. Isto facilitará seu trabalho. Para tal feito pode-se fazer o seguinte:

jarsigner -keystore C:\Felipe -storepass 123456 –signedjar NomeDoJarDepoisDeAssinado.jar NomeDoJarAntesDeAssinar.jar key

onde:

keystore: URL do keystore onde a chave está armazenada.

storepass: Senha protetora do keystore.

signedjar: Especifica o nome e o local de armazenamento do arquivo JAR assinado. Por default, o arquivo assinado irá sobrescrever o não assinado.

Estes passos são suficientes para que você consiga “liberar” teu applet para funcionar seguramente no seu browser. Alguns browsers não necessitam destas assinaturas, mas outras requerem. Sendo assim, é importante saber como proceder quando precisar assinar um applet.

Espero mais uma vez ter colaborado com seus conhecimento e auxiliado nas suas necessidades.

Obrigado e até o próximo.

Engenharia Social é o método de ataque mais eficaz que existe, pois ainda não há Firewall ou Anti-vírus que a detecte. Esse método utiliza, assim como os outros, a confiança equivocada no fornecimento de dados ou execução de ações no sistema. A única diferença entre as ameaças citadas e a Engenharia Social é que nesta os ataques ocorrem no mundo real, contra pessoas e não softwares. Fora do mundo do computador onde o alvo é a informação, que em alguns casos possui valor maior que o próprio patrimônio, a Engenharia Social é conhecida como o famoso estelionato.

Os atacantes sempre utilizam da ingenuidade dos colaboradores, incluindo a sua. Criar mecanismos de segurança é fácil, desde que você conheça as táticas utilizadas e os procedimentos que a sua empresa possui que acabam facilitando o trabalho do atacante. A educação dos colaboradores é a parte principal nesse processo de defesa. No entanto, criar cartilhas de alerta e uma política de distribuição de informações, também ajuda.

Os métodos mais comuns que a Engenharia Social utiliza são e-mails forjados e ligações nas quais as únicas identificações são a voz e o número de origem. Quando o e-mail é usado para ataque, o combate à fraude é pouco eficiente. Por isso, a prática de uso de assinaturas digitais é muito aconselhável. Com a assinatura, seus clientes e colaboradores terão certeza da origem do e-mail recebido. Entretanto, quando o uso de assinaturas não é possível, algumas precauções são necessárias:

- Verificar se as informações enviadas não são comprometedoras (Quando informações sigilosas são enviadas, a entrega pessoal é sempre melhor opção).

- Verificar a identidade dos colabores externos (fornecedores, consultores, etc.) e exigir, da matriz colaboradora, a notificação de mudança de colaboradores.

- Quando é necessário enviar senhas ou registradores, a fragmentação dessa informação é recomendada. Por exemplo, a primeira parte vai no e-mail cadastrado e a segunda no telefone celular.

Os ataques são executados de forma planejada e discreta. Antes do ‘grande’ ataque acontecer, é comum realizar pequenos ataques, até que se tenha acumulado grande quantidade de informações. Os atacantes, muitas vezes, ligam com o pedido de uma senha de servidor ou liberação de acesso no Firewall da empresa, mas a real intenção é acessar documentos nos servidores de e-mail, projetos ou banco de dados. E só você sabe o quanto pode ser prejudicial o vazamento destas informações. Por isso, cuidar da sua informação deve ser critério máximo. Apesar de não ser uma tarefa fácil, evitar esses ataques é necessário.

Abraços.

Fernando Chucre

A ideia principal do CAS é que a confiança de uma aplicação depende da identidade dos componentes que são usados. Por exemplo se a origem de um software é uma fonte confiável, tipo um componente shrink-wrapped instalado pelo usuário, todo aquele que sará verificado em runtime terá as permissões do usuário e poderá fazer ações definidas por essas permissões. Se a fonte do software é parcialmente confiável ou desconhecida, poderão ser adicionadas restrições ao código. Você poderia querer que rode na sua maquina um código com determinadas permissões, que faça parte de uma determinada categoria,e que não rode código procedente de outras categorias. O CAS engine é a resposta do .NET Framework a essas exigências. Muitas vezes a adoção do CAS no código pode gerar mau estar entre desenvolvedores por sem um sub-Framework bastante complexo e rico de classes.

Para começar é útil saber os conceitos básicos que estão por trás do CAS:

• Evidence(System.Security.Policy namespace): Objeto que representa a origem e a identidade do componente, informa Quem, Onde e Como verificar. As classes valores Publisher e StrongName indicam de quem está vindo o código. Zone, Site, Url, GacInstalled, e ApplicationDirectory, dizem de onde. Hash, serve como prova anti-adulteração, comprova a genuinidade do código. A CLR é em grau de construir uma instância Evidence com os devidos detalhes de uma parte de código, acessando a Assembly.Evidence property. Se um cogido é carregado com tipo ThirdPartyCode , pode ser acessada a Evidence via typeof(ThirdPartyCode).Assembly.Evidence .

• Code Group: è um grupo de códigos logicamente ordenados em categorias baseadas na Evidence de cada codigo e que tem carateisticas em comum.

• Permission(System.Security.Permissions namespace): è um nível de privilegio que pode ser cedido e negado pela CAS. Um permissão é uma instância que deriva de System.Security.IPermission e tem outros tipos quais:FileIOPermission, ReflectionPermission, and RegistryPermission. Permite ao código de requerer ou configurar permissões para rodar em determinados ambientes.

• Permission Set: um conjunto de permissions logicamente reunidas e que podem ser aplicadas ou removidas em grupo. Cada permissão desse grupo pode ter opções diferentes.

• Policy: o um conjunto de regras definidas por administradores que definem como os componentes CAS deverão se relacionar,por exemplo é o conjunto de permissões que devem ser aplicadas em um conjunto de maquinas e em quais partes de código vão interferir, qual a politica de acesso a um código, que tipo de membros, procedentes de qual meio(intranet,internet…).

O CAS verifica as permissões e as politicas percorrendo a stack e comparando as permissões requeridas por cada chamador e as permissões que o código chamado possui. Se tiver algum código que não corresponde ás necessidades do chamador então é disparada uma security exception e o acesso é recusado.Por enquanto essas são as ideias principais que sustentam o CAS. È um sistema bem eficiente mesmo sendo complexo…afinal nada é perfeito

Abçs

Claudio Ulisse

Essa semana recebi um e-mail de Pete Herzog indicando uma vídeo-palestra onde ele fala sobre uma nova versão de metodologia Open-source de testes de segurança. Agora totalmente reformulado e aperfeiçoado, o OSSTMM – Open Source Secutory Testing Methodology Manual tem como objetivo clarificar os métodos e os resultados dos testes de segurança e assim permitir uma decisão mais eficiente para qualquer modelo de negócio.

A palestra pode ser obtida em: www.dreamlab.net

Pete e uma série de colaboradores levaram 4 anos para chegar à versão 3 do documento. A metodologia é a compilação da evolução de uma série de normas, padrões e boas práticas. Mais que isso, ela permite ao auditor de segurança medir com precisão quão desprotegido está o seu negócio.

Acredito que essa metodologia será a futura ‘Best Practices’ de segurança e estou procurando criar uma parceria com a ISECOM, instituto do qual Pete é Diretor Geral, para trazer ao Brasil essa nova metodologia. Em um convite para ministrar uma vídeo-palestra a ser realizada aqui em Fortaleza, Pete se mostrou bastante empolgado. Espero conseguir realizar o mais cedo possivel esse evento!

Logo trarei mais detalhes.

Abraços.

Fernando Chucre