Adeus Skype

Depois da noticia que a eBay comprou o Skype, prontamente o desinstalei da minha maquina e passei a buscar alternativas. Talvez a mais interessante foi um programa chamado GIZMO que ao contrario do Skype, utiliza SIP como protocolo de VoIP e Jabber como protocolo de IM.
Por utilizar um protocolo padrão, é prometido por parte da equipe que desenvolve o GIZMO, fazer o mesmo conversar com qualquer dispositivo que entenda SIP, além de ser mais facil gerenciar o trafego que entra/sai da sua rede via Firewalls (O Skype usa porta 80 mas nao o protocolo HTTP, o que acaba gerando problema com alguns firewalls/proxies mais "inteligentes") e ser garantida a segurança do protocolo por ser um padrão aberto. Dois unicos problemas do ponto de vista de segurança existentes no GIZMO: Comunicação centralizada (No skype é peer-to-peer) em alguns servidores e algoritimos de criptografia até agora não foram revelados (skype utiliza AES 256 + RSA 1024).
Eu já estou utilizando, se alguem quiser testar, me avise!

WebServices Security

Estou comecando um projetinho utilizando webservice com intuito de prover interfaces de acessos a algumas bases de dados corporativos. Lendo uns docs da MS, vi algo que me deixou assustado:

"One of the first questions newcomers to SOAP ask is how does SOAP deal with security. Early in its development, SOAP was seen as an HTTP-based protocol so the assumption was made that HTTP security would be adequate for SOAP. After all, there are thousands of Web applications running today using HTTP security so surely this is adequate for SOAP. For this reason, the current SOAP standard assumes security is a transport issue and is silent on security issues. "

O Engraçado é que o protocolo SOAP, nada mais é do que um xml arranjado. Ora, não é dificil de pensar que os ataques em cima de aplicações web tb funcionem em cima de web services e lendo o texto acima fica a impressão que aplicações que utilizam SOAP, não precisam se preocupar com session-id, cookies, filtro na entrada de dados, replay attacks e etc. Essas colocações soam de forma perigosa, pelo jeito vai ter muito nego falando "Estou seguro, uso SSL" por muito tempo.

CNASI - SP

Hoje madruguei para ir assistir a palestra do meu amigo Augusto Quadros Paes de Barros sobre o futuro das backdoores.

Além da palestra ter sido muito bem feita e conduzida, ele mostrou uma prova de conceito de um backdoor implementado em BHO (Browser Helper Object) e como já estou mexendo com esta tecnologia pude tirar algumas conclusoes a respeito.

- O IE precisa urgentemente entrar no processo de Trustworthy Computing por consequencia utilizar a SDL. O IE infelizmente não é "secure by design". É preciso que a Microsoft antes de implementar uma nova feature, pense no novo leque de oportunidades que os atacantes terão para explora-la.

- O IE6 e IE7 Beta 1, não conseguem controlar de maneira efetiva o que é attachado a ele, é preciso um maior controle. Segundo a MS isso será melhorado no IE7 Beta 2. Mas ainda não é o suficiente, queremos uma capacidade heuristica no IE para identificar se o BHO attachado é malicioso ou não (Será que não é suspeito alguem reescrever um post/get, ou gravar um log das paginas navegadas, dados digitados em entry boxes ?)

- Gracas ao metasploit fizemos um payload que instala um BHO ao explorarmos a vulnerabilidade ms-05-29 e acreditem, nenhum barulho foi gerado, o IE simplesmente instalou. Esse sem duvida é o pior dos mundos... e eu nao gostaria de enfrenta-lo

Windows Syscall ShellCode

Paper legal na SecurityFocus:
http://www.securityfocus.com/infocus/1844

Só acho que será um saco tratar cada versao de OS, Service Pack e etc uma vez que os numeros das syscalls mudam. Apesar de a maioria de shellcodes utilizam enderecos hardcoded de funcoes que variam tb a cada SP, lingua e etc.
Bom que essa tecnica bypassa a protecao do VS.NET contra buffer overflows e qualquer outro tipo de checking feito em nivel de API/ring3, uma pena que o XP SP 2 + Data Execution Prevention (DEP) já consegue derrubar esse tecnica uma vez que, se o hardware suportar DEP, mesmo em ring 0 vc nao consegue bypassar a protecao.
DEP vai ser a solução ? Provavelmente não a curto prazo pois todos aplicativos que rodam alguma coisa JIT terão problemas por normalmente rodarem codigos no stack, além dos desenvolvedores terem que passar a se acostumar a marcar a memoria como executavel ou somente leitura quando chamarem a funcao Virtualloc() e utilizar a funcao VirtualProtect().
As empresas deverão passar o seus aplicativos pelo crivo do Application Compatibility Toolkit da MS ou pelo menos instruir o seus usuários a cadastrarem seus aplicativos na sessão de exceptions do DEP. Alias, alguem malicioso pode cadastrar um aplicativo vulneravel e pronto bau bau protecao :-)

GSM SECURITY

Estou com minha leitora de smart-card / SIM fritando tentando puxar o IMSI e o Ki de alguns SIM cards que eu tenho.
Para quem nao sabe, o IMSI é a sua identificação na rede e o KI a chave de autenticação do usuário, ambos sao usados para montar a pergunta de um processo de challenge response.
No algoritimo utilizado em cartões mais antigos (COMP128-v1), era possivel se acessar diretamente estes dados no SIM Card.Acho que por causa da necessidade de phone banking, java e etc, as operadoras no brasil já estão utilizando COMP128-v2/v3, que infelizmente (para mim, neste contexto :-)) ainda ninguem quebrou. Aproveitei este meio tempo para configurar o framework da opencard, instalar o eclipse e começar a mexer com javacard (Para quem falava com saudosismo do limite maximo de 64k :-)) que parece muito bacana.

As 6 ideias mais idiotas

Excelente texto do Ranum http://www.ranum.com/security/computer_security/editorials/dumb/ .

Engraçado que me deparei com a primeira regra do "Default Permit" outro dia.

Vi em uma empresa de um colega meu, o Filtro de conteudo web funcionando no "Default Permit", pois caso o Filtro de conteudo ficasse fora, nao pararia a navegação (!!) - É um risco assumido, ele me disse.

Pensei na hora o quao importante é a navegação x o risco de um worm postar via urls na china com informações dos ips de zombies internos, acessos indevidos a partir da rede interna, a falta de controle de funcionamento do filtro de conteudo pois a equipe de TI nao precisa se preocupar em por o servico no ar afinal "é transparente para o usuário", funcionarios tentando acessar sites bloqueados o dia todo uma vez que "Em alguns momentos o orkut funciona", alem de reverse backdoors (Igual aquele perlzinho maneiro da THC) que passariam numa boa para o mundo... preferi não discutir pra nao perder o amigo...

Resposta do Schneier sobre o algoritimo SEED :-)
Eu perguntei algumas coisas alem disso mas o "core das questoes":

>you wrote:
>Korea Information Security Agency (KISA) are trying to add SEED Cipher Suites
>to TLS, and if (even) you never heard about it, has IETF skill to analyze
>how strong is this "new" algorithm ?
No.
It would take years of analysis.
Bruce

Engraçado, será que esse algoritimo vai passar ?

Em nome da soberania nacional

Quando a politica de controle de utilização de criptografia de 128 bits para usuários de fora do U.S era eficaz, a Korea do Sul desenvolveu um algoritimo simetrico proprio 128 bits chamado SEED.

Vi que já saiu uma RFC descrevendo o algoritimo, s-boxes e vetores de teste. O Algoritimo foi criado para ser utilizado com acesso a internet banking, mas com o passar do tempo perceberam a sua baixa utilização de memoria comparado a outros algoritimos e agora tem sido sugerida a sua utilização em equipamentos com poucos recursos como dispositivos moveis e smart cards.

Vi em julho que existe um draft já publicado para inclusão do algoritimo no pacote TLS, vamos ver se outros produtos (Como por exemplo firewalls) irão passar a suportar o SEED.

Postei uma mensagem pro Bruce Schneier pedindo um overview dele sobre o algoritimo, vamos ver o que ele acha.

Pedi também o codigo em C para a KISA, vamos ver se eles o enviam para um terceiro-mundista qualquer ;-)

Multiplas politicas de senha por dominio

Alguem já tentou configurar diversas politicas de senhas dentro de um mesmo dominio (Active Directory) ? Pois é acreditem, não funciona!

A politica de senhas é domain wide. É comum termos cenarios onde um grupo de contas em especifico tenham uma politica mais forte, mas infelizmente não há como obrigarmos.
Na verdade caso você queira especificar uma politica em uma determinada OU, as contas que estiverem dentro da OU (somente máquinas, pois esta politica se aplica a máquinas... mas pera, eu quero aplicar a politica em contas de usuarios, pq essa politica só se aplica a máquinas ? já explico...) terão a politica valendo somente para contas locais, ficou claro ? Claro que não!

A Microsoft diz oficialmente que a politica de senhas se aplica a máquina, pois como tudo para o ad é uma conta (seja usuarios ou maquinas) e aplicando a politica em nivel de dominio, todas as maquinas receberao estas politicas e por consequencia os usuarios.

A resposta nao oficial é que setar esta politica pra cada usuário seria muito trabalho. Pois quando um usuário quisesse trocar sua senha, seria necessário verificar a politica daquele usuário, depois da maquina, ver quem faz overhide em quem e ai fazer valer a politica correta. Sendo tudo por máquina, se N usuários tentarem trocar a senha a partir daquela maquina, a politica verificada será a mesma.

Um ponto de atencao: Se vc tiver N politicas que definem a politica de senhas, prevalecerá a ultima politica a ser aplicada, portanto tome cuidado com as wide domain policies, você pode estar enfraquecendo as politicas de senha do seu dominio.

Agora, qual seria a solução onde é necessário uma politica de senhas para usuários (10 chars, alfanumericos, politica de desbloqueio mais rigida) e precisa de outra politica para senhas de servicos (20 chars, aflanumericos, sem politica de desbloqueio ou politica de desbloqueio mais "light") ?

A principio temos duas soluções:

1. Criar contas locais nos servidores que contem os servicos, jogar essas maquinas numa OU e aplicar a politica de senhas em cima desta OU
2. Criar um dominio separado para as contas de servico, fazer trust entre os dominios e criar uma politica de senhas separadas

Como vocês podem ver, nenhuma das duas é boa em "Facilidade de gerenciamento". Acredito que a Microsoft poderia melhorar este controle, garantindo apenas que politicas pontuais aplicadas em OUs não enfraquecessem a politica default.

Researchers....

Eu tava dando uma olhada num projeto da ms chamado Shield bem interessante de proteção contra worms. O Shield implementa uns filtros genericos utilizando a tecnologia de LSP, (Layered Service Provider) e analise o trafego fazendo match contra assinaturas de ataque. Lembro que numa empresa que trabalhei, participei do desenvolvimento de um prototipo de filtro web em cima de LSP, uma tecnologia pouco documentada, obscura e mal vista até mesmo pela a equipe de desenvolvimento da MS. Lembro que o maior problema era pra cadastrar o LSP na pilha tcp/ip, pois havia diferencas entre versoes do windows (A instalação tinha que ocorrer em 9x,NT,W2K,XP,etc. Vou varrer meus arquivos em casa pra ver se tenho algo feito, quem sabe eu encontre algo e poste aqui.
Infelizmente esse projeto não oferece pacote para download. Não acredito que ele vá pra frente, alguem discorda ?

Limite do Desktop Heap

Tive serios problemas aqui na minha maquina ao tentar abrir mais do que 40 apps simultaneos.
Dando uma buscada na net achei a seguinte possibilidade de configuração

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems]Windows="%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16"

Na sessão SharedSection que tem o valor 3072 para outro valor como por exemplo 4096. Esta opcao diz respeito a kilobytes utilizados pelo heap de cada desktop interativo dentro do WinSta0.

Mais informações: http://support.microsoft.com/default.aspx?scid=kb;EN-US;184802

Mexendo nas permissões do Exchange

Se alguem aqui já precisou mexer nas ACLs de acesso a caixa postal de um objeto usuário no AD, sabe que isso é um saco. Depois de alguns dias brincando e fuçando (thanks god msdn), construi um monstrinho para negar todos acessos a caixa postal. Trabalho importante para uma boa revisão de acesso :-)

Codigo Aqui

Metodo Invoke: Solução para a preguica dos desenvolvedores do .NET

Para quem mexe com ADSI, já deve ter notado que algumas propriedades não foram incluidas e você acaba ficando sem acesso, a unica forma de acessar estas propriedades é via o metodo Invoke da classe DirectoryEntry.

//Funcao para setar o logonHour do funcionario via invoke
private static void SetLHo(DirectoryEntry entry, byte[] bb)
{
entry.Invoke("Put","logonHours",bb);
}

Na verdade o Invoke é só um wrapper para se chamar a função Put. Detalhe, isso não é só no .NET, vi também que no Delphi é a mesma coisa. A unica forma de se acessar todas as propriedades sem "perrengue", é via o bom e velho C.