Anatomia do Comprometimento de um dos meus Servidores, parte II

Uma das coisas mais legais de se trabalhar em TI é o senso de humor de seus praticantes. No "dia da mentira" isso fica particularmente evidente, com várias empresas grandes dando um show de criatividade com suas pegadinhas. Entre as que eu mais gostei se destacam o Google Motion, toda uma linha de produtos fictícios da ThinkGeek e algumas matérias hilariantes na Slashdot. Agradeço de coração a todos que me parabenizaram nos comentários, mas, sejamos justos: comparado com a grandiosidade, esmero e detalhismo dessas iniciativas, o meu post anterior fica parecendo brincadeira de criança.

Apesar da história principal ser fictícia, há muita verdade naquele post. Pelo feedback que recebi, muita gente notou logo o horário "23:59:60 do dia 31-03-2011", um instante de tempo que não existe e que muita gente tende a considerar equivalente a '00:00:00 01-04-2011'. Mas aquilo está errado por pouco – na realidade, o instante 23:59:60 pode existir sim na escala de tempo UTC. Isso se chama segundo bissexto e é inserido de tempos em tempos para manter o UTC e o TAI (o padrão atômico de tempo) próximos um do outro. Segundo o padrão, o segundo bissexto pode ser inserido no final de qualquer mês, muito embora, até hoje, só tenha sido inserido no final dos meses de julho ou dezembro. Todavia, 23:59:60 UTC corresponderia a 21:59:60 no horário local de Recife, devido ao nosso fuso de -3 horas em relação ao UTC.

Os projetos vserver e grsec existem mesmo e são, de fato, uma das dobradinhas mais virtuosas em segurança para sistemas Linux. Vocês ainda vão me ouvir muito falar desses caras em futuros posts.

O publicfile existe mesmo e é um servidores web com o histórico mais longo de zero vulnerabilidades conhecidas.

É verdade que muitas fontes de alimentação modernas têm microcontroladores e alguns modelos oferecem, mesmo, diversas vantagens interessantes em termos de performance/watt e outras características "ecológicas". E não se pode descartar a possibilidade de que alguém coloque algum backdoor no firmware desses microcontroladores – por exemplo, para viabilizar um ataque de negação de serviço, o firmware poderia ser programado para ficar aguardando um sinal específico e, quando o recebesse, desligaria o sistema. Para sabotagens seria perfeito! E se fosse bem orquestrado, poderia ficar indistinguível de um defeito ou pane "legítima".

Todavia, até hoje e até onde eu sabia, isso é apenas uma possibilidade. O lance que eu teria tropeçado em uma fonte troianizada em algum computador meu foi o principal ponto fictício da história.

Transmissão de dados por sobre as linhas de energia elétrica é algo que existe, sim, e o X10 e INSTEON são exemplos reais, embora suas velocidades sejam muito baixas (dezenas a poucos milhares de bits por segundo) e não sejam lá muito confiáveis. É, sim, verdade, que a modulação deles é bastante simples e pode ser vista sem muita dificuldade com certos osciloscópios e um pouco de eletrônica. Existem até redes de alta velocidade (da ordem de dezenas de megabits por segundo) por sobre a linha de energia.

É verdade, sim, que muitos computadores (sobretudo os modelos 'rackmount' para datacenters) têm um sub-computador chamado Baseboard Management Controller. Existem, sim, vários chips que implementam esse treco e o chip cujo datasheet eu citei é, de fato, um desses.

Existe, sim, pelo menos uma família de microcontroladores que podem ser programados enviando sinais de 12V. Mas esses chips são os microcontroladores da família AVR da Atmel e, neles, o sinal de 12V é enviado pelo pino de RESET e não pelo VCC. O barramento SPI existe mesmo e a quase totalidade dos microcontroladores da família AVR podem, sim, ser programados usando esse barramento, mas não no modo de programação de "alta voltagem" (para circuitos que operam entre 1.8 a 5V, 12V é considerado "alta voltagem").

Todavia, o lance de que aquele BMC específico adotasse esse sistema de programação foi pura invenção. Uma rápida checada no diagrama de blocos que consta no datasheet mostra que aquele BMC não tem uma porta SPI, mas ele tem sim, de fato, uma porta JTAG.

Apesar disso, a possibilidade de backdoors nos BMCs é real e precisa, sim, ser levada a sério. Uma das chatices envolvendo esses sistemas proprietários é que não temos como auditá-los até esses mínimos detalhes. Ficamos à mercê dos fabricantes. Contudo, se formos por essa linha e quisermos ter um mínimo de consistência, teremos que nos preocupar até com possíveis backdoors no processador principal e no chipset. A flagrante impraticalidade de se auditar isso é uma das principais razões pelas quais esse quesito nem costuma entrar nos modelos de ameaça de muita gente – se eu não tenho como verificar, pra que considerar?

Apesar disso, defendo que esse item tem, sim, de estar presente nas modelagens de ameaça, nem que seja apenas para ficar registrado que ele foi levado em conta. Pode ser aceitável para uma instituição privada tolerar backdoors. Mas para organizações públicas, isso coloca a soberania em xeque; e para uma instituição militar, um backdoor desses pode significar não ter chance nenhuma contra o inimigo em caso de conflito.

A propósito: o bloco em hexadecimal era código objeto executável em linguagem de máquina da arquitetura AVR. Se executado em certos modelos desses microcontroladores, ele enviaria a seguinte mensagem pela porta serial:

1o de Abril!!

Seja o primeiro a mencionar a palavra magica "LHEBS" e ganhe
uma camiseta da Tempest!

Pena que ninguém descobriu isso, mas vou guardar a camiseta para uma outra oportunidade.

Uma das tarefas ingratas de quem trabalha com segurança é imaginar maneiras pelas quais as coisas podem dar errado e tentar se precaver contra elas. Como parte do meu trabalho, eu escrevo um bocado desses cenários hipotéticos e adaptei um deles para compor o texto do post anterior.

Se esse ataque tivesse acontecido de verdade, o caminho mais interessante teria sido rastrear de onde estariam vindo os tais sinais elétricos que estariam sendo interpretados pela fonte troianizada – exatamente como comentou um leitor anônimo. O mesmo leitor também comentou algo muito importante: quem disse que a gente pode assumir que os datasheets são completos, no sentido que não haja funcionalidades escondidas? Existem, sim, dezenas de casos de "instruções não documentadas" nos vários processadores da família x86 e x86_64 que os pesquisadores da área vez por outra descobrem. Um backdoor seria só mais um desses "recursos não documentados".

Apesar do ataque que eu descrevi no post anterior não ter acontecido de fato, ele é, como tentei mostrar aqui, perfeitamente plausível. Toda a tecnologia necessária já existe e já está dentro dos nossos computadores. Basta alguém na cadeia de produção de algum desses produtos implantar, ou ser coagida ou compelida a implantar, backdoors como esses.

Por isso, não ficaria nem um pouco surpreso se, daqui a alguns anos, algum ataque semelhante como esse vier a acontecer de verdade. Precedentes parecidos existem: em 2008, veio a tona uma história sinistra sobre roteadores Cisco falsificados e ano passado o mundo se assombrou com o Stuxnet, que é muito mais tecnicamente sofisticado do que o ataque que eu descrevi.

Se esses dois posts te abriram os olhos para algo que você antes não tinha considerado, ou pelo menos te fez dar uma ou duas risadas, acho que eles cumpriram bem suas funções.

Parte anterior

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.