[FUG-BR] Security Incident on FreeBSD Infrastructure

[Patrick Tracanelli]

Em 19/11/2012, às 13:11, Renato Frederick escreveu:

> Patrick,
> 
> quem fez um cvsup para atualizar o free de release para stable, por 
> exemplo, pode correr risco? Não ficou claro esta questão.
> 
> eu sempre uso o csup e o fastest_cvsup para achar os mirrors mais perto, 
> normalmente o cvsup2.br.freebsd.org

Pois é não ficou claro mesmo o que é bem ruim.

Esses 2 nós do pointyhat são consideradas maquinas "legado" no que tange a não estarem dentro do esquema SVN/CVS recente. O /home estava todo acessível ao usuário mas estava read-only (não, o invasor não teve root, era privilegio de desenvolvedor que raramente é de root).

O que ja foi verificado e está clean/confiável:

hub, freefall, svn, perforce, www, mx

Ou seja espelhos, especialmente os regionais como .br.freebsd.org que se penduram nessas máquinas ou mirrors dela pra construirem seu proprio mirror estão livre de risco.

Outras coisas ja validadas:

- Binarios em ftp.freebsd.org foram todos testados e coparadas assinaturas e estão todos OK
- Imagens ISO e afins estão todos OK

O que não esta validado nem tem como ser:

- Pacotes pra 9.1 (então que tem PRERELEASE ou -RC e instalou pacotes, atualizem!)

A maquina comprometida eu vi no #bsdcode que apontava pra cvsup5.us.freebsd.org que é a mesma que aponta pra cvsup9.freebsd.org e teoricamente so quem fez cvsup nesses hosts poderia correr risco. Eu perguntei pro Gavin Atkinson se ele confirma que era essa maquina.

No entanto o src dessa maquina foi comparado e se mostrava íntegro no momento que se descobriu o incidente.

O que é uma boa noticia mas não livra a janela entre o acesso inicial de 11/Setembro até a data de teste.

Então inciou-se um processo de auditoria forense pra saber se antes, também estava integro.

Ou seja se alguem fez cvsup e caiu nesse server não existe ainda indicio de risco mas não há certeza plena de ausencia de risco então um buildworld extra apos novo cvsup n faz mal.

Se alguem sincronizou com esses servers o ideal é pedir pra fazer uma copia do /usr/src e sincronizar com SVN da mesma data e tirar um diff recursivo.

Mas são tantas variaveis (quem se lembra o mirror q usou? quem se lembra a data de inicio e de fim?) que é até dificil pedir pros usuarios mesmos os mais paranoicos fazerem isso ne? E devido a natureza do cvs/svn não adianta comparar o que voce tem com o que existe de mais recente hoje, ja haverão diferenças mesmo.

Qq coisa relevante eu menciono aqui.




> 
> Acredito não ter problema né?
> 
> Em 19/11/2012 11:48, Patrick Tracanelli escreveu:
>> Mas não foi falha do sistema.
>> 
>> Historicamente o Projeto FreeBSD teve um único comprometimento técnico, em um injection num arquivo CGI na década de 90, época do FreeBSD 3 mas nada além do próprio script CGI foi comprometido.
>> 
>> Esse incidente agora não é técnico.
>> 
>> O elo explorado da corrente foi, "segundo especialistas" o mais fraco da corrente: pessoas.
>> 
>> Um desenvolvedor com acesso autêntico teve sua chave SSH vazada, e demorou até perceber que alguém acessou 2 máquinas do Ports Cluster com suas credenciais.
>> 
>> Eu pessoalmente discordo que pessoas sejam o elo fraco. Pra mim são processos. O mero processo de cruzar histórico de login com endereço IP e alertar ou auto-lockar se não houver confirmação positiva daquele acesso, teria ajudado nesse caso. Independente da postura segura do usuário.
>> 
>> De volta ao foco, quem deve se preocupar:
>> 
>> - Quem instalou pacotes (não ports) de 11/Setembro a 17/Novembro (pkg_add -r);
>> - Quem baixou fontes via cvs(1) anônimo na mão;
>> 
>> Isso porque as máquinas comprometidas tem 2 funções, ser mirror secundário de repo cvs e ser parte do cluster de package build.
>> 
>> Fala-se no canal #bsdcode no IRC que menos de 15% dos pacotes binários foram construídos nessas máquinas mas ainda assim por precaução todos que instalaram pacotes devem atualizar. Não existe qualquer indício de problema nos pacotes, eles inclusive estão sendo auditados (sei la como) pra saber se houve qq modificação, mas por hora isso parece improvável.
>> 
>> Ainda assim o projeto FreeBSD alertou então negligência de quem não substituir os pacotes binários por ports novinhos :-)
>> 
>> E fica a dica, sempre usar SVN/Portsnap, ports preferencialmente ao invés de pacotes porque pacotes pre compilados apesar de assinados, só evitam ataque do tipo MITM, o comprometimento direto no repositório pode ter a própria assinatura comprometida.
>> 
>> Ja via ports é feito download do MASTER_SITE original, testado checksum, etc, processo q envolve tanto o projeto FreeBSD quando os projetos de onde os sources são baixados, e um comprometimento de ports precisaria de alguem apontar pra um MASTER_SITE comprometido e modificar os distinfo (checksum), o que teria que ser através de commit (dificil ninguem perceber) ou faria um barulho danado na construção dos snapshots do portsnap e chamaria atenção rapidamente. Ou mais dificil comprometer tanto o ports quanto o MASTER_SITE original ao invés de apenas modifica-lo, mais "barulhento" ainda.
>> 
>> Apesar do comprometimento não ter natureza técnica, é uma pena de qualquer forma.
>> 
> 
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"