Anatomia do Comprometimento de um dos meus Servidores, parte I

Um dos momentos mais difíceis de quando se trabalha em segurança de sistemas de informação é quando você tem de reconhecer que uma máquina sob sua guarda foi invadida. Ainda não dei a análise forense por encerrada e há muitas lacunas para preencher, mas, neste post, vou compartilhar com vocês o que descobri até agora.

NOTA: Este post foi uma pegadinha de Primeiro de Abril. Leia o próximo post para uma análise detalhada do que é fato versus ficção neste texto.

Eu achava que tinha tomado todas as precauções: o servidor web é o publicfile, que não tem vulnerabilidades conhecidas e dentro de uma jaula chroot com um usuário não-privilegiado. O servidor é um Linux com o patch combinado de vservers+grsec – a dobradinha considerada o supra-sumo de resistência a ataques. A máquina tinha um gerador de números aleatórios em hardware que eu mesmo fiz. Por isso, quando o firewall da rede desta máquina começou a acusar tentativas de conexão dela para um endereço na China (que são negadas pelo firewall), meu coração quase parou – como raios alguém conseguiu invadir essa máquina?!

Esse incidente me levou a uma investigação que tem me absorvido ao longo das últimas semanas e aponta para um tipo de ataque eu nunca tinha visto antes. Já tinha ouvido até falar de coisa vagamente semelhante, mas nada desta sofisticação técnica.

Não vou fazer suspense: parece tratar-se de um dos mais bem escondidos backdoors que eu já vi, em um lugar que ninguém normalmente julga vulnerável: a fonte de alimentação e a energia elétrica!

Explico: a fonte de alimentação de alguns modelos e marcas de servidores contêm um microcontrolador – um computador bem pequenininho, de um único chip, que controla a regulagem das diversas voltagens necessárias à operação da CPU e periféricos. Antigamente relgadas a mercados-nicho, essas fontes têm ganhado popularidade com a crescente preocupação com eficiência energética, na forma de "performance/watt", correção do fator de potência, etc.

Nesse microntrolador, como todo processador, roda um software, chamado de "firmware". Normalmente, o firmware de uma fonte de alimentação monitora a tensão de saída e ajusta o "duty cycle" do "chopper" (logo após a retificação DC do primeiro estágio). Por isso, achei estranho quando notei que, após um divisor de voltagem resistivo clássico e um acoplador ótico, a entrada AC desta fonte ia direto para um dos pinos do microcontrolador.

Monitorando a rede AC, descobri que, sobreposto à forma de onda de 60Hz, estavam sendo transmitidos dados digitais. Com o equipamento de monitoração que eu tinha, não consegui extrair direito os dados da linha elétrica – não entendo tanto assim de processamento de sinal para conseguir fazer a engenharia reversa da modulação. Tudo que eu via era uns borrões esquisitos na tela do osciloscópio – certamente não era algo tão simples quanto X10 ou INSTEON. Para piorar, a transmissão não acontecia o tempo todo, mas havia alguns padrões: por exemplo, ela sempre acontecia aos 3 minutos após cada hora inteira. Entretanto, também acontecia em outras ocasiões, aparentemente espúrios.

Chamei um amigo meu engenheiro eletrônico, que disse nunca ter visto nada parecido. Ele chegou a propor algumas estratégias para tentarmos capturar o sinal, mas as que tentamos implementar não deram muito certo e as que achamos que vai dar certo ainda estava dependendo de conseguirmos equipamento emprestado.

Passei vários dias empacado nesse ponto e tentando toda sorte de expedientes para tentar prosseguir, sem sucesso. Em uma das vezes, entretanto, dei a "sorte" de ver notar que logo após uma dessas transmissões, a máquina tentou novamente gerar uma conexão de rede proibida pelo meu firewall de borda. Novamente, meu coração pulou: eu estava monitorando quase tudo da máquina e algo aconteceu na minha frente que eu não consegui entender. Acalmei-me e lembrei-me dos procedimentos, de ser metódico e científico: tomei nota da data e hora em que o evento ocorrera e como estavam todos os parâmetros no momento que ocorreu.

Todavia, fui atropelado por uma sequência de novas tentativas de conexão. Elas se correlacionavam aproximadamente (mas não exatamente) com as formas de onda estranhas na corrente alternada vindo da tomada.

Após mais alguns dias de becos sem saída e progresso quase zero, notei o detalhe que me levou à solução do problema (ou, pelo menos, ao estágio atual da minha investigação): o BMC do servidor parava de responder a "pings" quando a transmissão acontecia.

O BMC (Baseboard Management Controller) é um sub-computador que existe dentro de certas marcas e modelos de servidores que implementa um sistema de gerenciamento remoto independente do sistema operacional. Ele "pega emprestado" uma das placas de rede da máquina para receber comandos através de um protocolo chamdo IPMI. Através dele, pode-se ligar e desligar o computador remotamente, saber a temperatura de vários subcomponentes, suas voltagens e clocks, a velocidade dos ventiladores ("coolers"), etc., tudo remotamente. Através dele, é possível até reinstalar o sistema operacional da máquina por completo de forma totalmente remota – recurso essencial para grandes "data centers".

Acontece que não existe conexão de dados entre o microprocessador da fonte e o BMC. A única conexão entre eles é, naturalmente, a voltagem de alimentação – e, até onde eu soubesse, não dá para transmitir dados digitais por ali. Contudo, se essa é a unica conexão que existe, então essa deve ser a maneira pela qual a fonte está interferindo no BMC.

Após ler o datasheet (esse é o sumário público, a versão completa eu não posso publicar devido aos copyrights) do chip do BMC diversas vezes, finalmente achei o detalhe que me escapou: o carregamento inicial do firmware do BMC pode ser feito de vários modos, mas um deles, chamado "programação de alta voltagem", funciona assim: o chip normalmente roda a 3.3V, mas se você aplicar 12V ao invés, ele entra em reset, onde uma máquina de estados (implementada direto no microcódigo) lê instruções para programar a memória flash embutida no chip.

Eu confirmei que, quando o BMC para de responder a pings, aparecem vários picos de 12V mais ou menos periódicos na alimentação dele – prova cabal de que a fonte está gerando esses sinais. Mas há um mistério que ainda não sei explicar: o sinal de 12V serve é apenas uma fase da programação da flash – as instruções de programação devem vir no barramento SPI, que fica em outros pinos. Ainda não entendo como é possível controlar exatamente o que está sendo programado na flash do controlador apenas modulando voltagem de VCC.

O BMC tem uma porta de depuração JTAG e, para minha grata surpresa, as trilhas ligadas a esses sinais vão parar no que provavelmente deve ser o menor conector que eu já vi. Depois de um delicado trabalho de solda, com ajuda de um amigo que tem equipamento para trabalho delicado em SMT, e muitas horas perdidas para fazer um cabo apropriado, mais ou menos consegui colocar o chip em modo de depuração e extrair parte do firmware do BMC, na esperança de passá-lo pelo disassembler e tentar entender exatamente o que acontece. Entretanto, por alguma razão que ainda não entendi, a transferência aborta após algumas poucas centenas de bytes.

Eis o que eu consegui baixar até agora (em formato Intel Hex):

:1000000012C02CC02BC02AC029C028C027C026C0BF
:1000100025C024C023C022C021C020C01FC01EC0D4
:100020001DC01CC01BC011241FBECFE5D4E0DEBF25
:10003000CDBF10E0A0E6B0E0EEECF4E002C0059029
:100040000D92A036B107D9F710E0A0E6B0E001C0EC
:100050001D92A036B107E1F702D037C2D1CF8BB1E4
:100060008570E9F381E38CB98BB18570E9F38FE694
:100070008CB98BB18570E9F380E28CB98BB1857056
:10008000E9F384E68CB98BB18570E9F385E68CB928
:100090008BB18570E9F380E28CB98BB18570E9F39F
:1000A00081E48CB98BB18570E9F382E68CB98BB1B0
:1000B0008570E9F382E78CB98BB18570E9F389E645
:1000C0008CB98BB18570E9F38CE68CB98BB18570F6
:1000D000E9F381E28CB98BB18570E9F381E28CB9E7
:1000E0008BB18570E9F38DE08CB98BB18570E9F344
:1000F0008AE08CB98BB18570E9F38AE08CB98BB159
:100100008570E9F383E58CB98BB18570E9F385E6F9
:100110008CB98BB18570E9F38AE68CB98BB18570A7
:10012000E9F381E68CB98BB18570E9F380E28CB993
:100130008BB18570E9F38FE68CB98BB18570E9F3EB
:1001400080E28CB98BB18570E9F380E78CB98BB113
:100150008570E9F382E78CB98BB18570E9F389E6A4
:100160008CB98BB18570E9F38DE68CB98BB1857054
:10017000E9F385E68CB98BB18570E9F389E68CB932
:100180008BB18570E9F382E78CB98BB18570E9F3A7
:100190008FE68CB98BB18570E9F380E28CB98BB1B5
:1001A0008570E9F381E68CB98BB18570E9F380E263
:1001B0008CB98BB18570E9F380E78CB98BB1857010
:1001C000E9F38FE68CB98BB18570E9F383E78CB9DD
:1001D0008BB18570E9F384E78CB98BB18570E9F355
:1001E00081E68CB98BB18570E9F382E78CB98BB16C
:1001F0008570E9F380E28CB98BB18570E9F381E613
:100200008CB98BB18570E9F380E28CB98BB18570C4
:10021000E9F380E78CB98BB18570E9F381E68CB99D
:100220008BB18570E9F38CE68CB98BB18570E9F3FD
:1002300081E68CB98BB18570E9F386E78CB98BB117
:100240008570E9F382E78CB98BB18570E9F381E6BB
:100250008CB98BB18570E9F380E28CB98BB1857074
:10026000E9F38DE68CB98BB18570E9F381E68CB941
:100270008BB18570E9F387E68CB98BB18570E9F3B2
:1002800089E68CB98BB18570E9F383E68CB98BB1C3
:100290008570E9F381E68CB98BB18570E9F380E272
:1002A0008CB98BB18570E9F382E28CB98BB1857022
:1002B000E9F38CE48CB98BB18570E9F388E48CB9EF
:1002C0008BB18570E9F385E48CB98BB18570E9F366
:1002D00082E48CB98BB18570E9F383E58CB98BB17D
:1002E0008570E9F382E28CB98BB18570E9F380E225
:1002F0008CB98BB18570E9F38EE68CB98BB18570C2
:10030000E9F38FE68CB98BB18570E9F383E78CB99B
:100310008BB18570E9F380E28CB98BB18570E9F31C
:1003200083E68CB98BB18570E9F38FE68CB98BB11C
:100330008570E9F38DE68CB98BB18570E9F385E6BC
:100340008CB98BB18570E9F38EE68CB98BB1857071
:10035000E9F384E78CB98BB18570E9F381E68CB958
:100360008BB18570E9F382E78CB98BB18570E9F3C5
:1003700089E68CB98BB18570E9F38FE68CB98BB1C6
:100380008570E9F383E78CB98BB18570E9F380E27E
:100390008CB98BB18570E9F385E68CB98BB185702A
:1003A000E9F380E28CB98BB18570E9F387E68CB90B
:1003B0008BB18570E9F381E68CB98BB18570E9F377
:1003C0008EE68CB98BB18570E9F388E68CB98BB178
:1003D0008570E9F385E68CB98BB18570E9F380E22D
:1003E0008CB98BB18570E9F385E78CB98BB18570D9
:1003F000E9F38DE68CB98BB18570E9F381E68CB9B0
:100400008BB18570E9F380E28CB98BB18570E9F32B
:1004100083E68CB98BB18570E9F381E68CB98BB139
:100420008570E9F38DE68CB98BB18570E9F389E6C7
:100430008CB98BB18570E9F383E78CB98BB185708A
:10044000E9F385E68CB98BB18570E9F384E78CB963
:100450008BB18570E9F381E68CB98BB18570E9F3D6
:1004600080E28CB98BB18570E9F384E58CB98BB1EE
:100470008570E9F385E68CB98BB18570E9F38DE67B
:100480008CB98BB18570E9F380E78CB98BB185703D
:10049000E9F385E68CB98BB18570E9F383E78CB914
:1004A0008BB18570E9F384E78CB98BB18570E9F382
:1004B00081E28CB98BB18570E9F38DE08CB98BB199
:0E04C0008570E9F38AE08CB90895F894FFCFB7
:00000001FF

Todavia, passando no disassembler específico para o chip do BMC, o resultado não parece fazer o menor sentido. Talvez haja um stub de decifragem mais adiante na memória, mas ainda não tenho como saber. Se algum dos prezados leitores tiver alguma pista do que isso significa, por favor postem suas análises aqui nos comentários!

Recapitulando: o que eu sabia até o momento era que alguém estava transmitindo dados modulados pela rede elétrica do datacenter e a fonte do computador estava recebendo esses dados e, de alguma forma, repassando-os para o BMC. Agora, o BMC é capaz de gerar pacotes de rede sozinho e tanto o sistema operacional quando o BMC "compartilham" a placa de rede – o que é consistente com o fato de eu não ter detectado nada de visivelmente anormal no Linux em si nem no software rodando sobre ele.

Todavia, às vezes a solução dos mistérios se apresenta para nós das formas mais inesperadas, e foi exatamente isso que aconteceu, em uma reviravolta espetacular que vou relatar no próximo post. Em todo caso, se algum dos leitores tiver observado comportamento anormal semelhante em seus servidores, por favor relatem aqui nos comentários.

Próxima parte

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.
Augusto P Barros | 2011-04-01 15:34:10 | permalink | topo

Um dos melhores deste ano, Kiko. Está no nível do Gmail Motion :-)

Pimpão | 2011-04-01 14:39:26 | permalink | topo

Huhaiuhaiuhaiuahiuahuai...

Sem sacanagem... essa é uma das melhores brincadeiras de 1º de abril que já vi veio... Criatividade sem limites!

Se alguem ainda tem dúvida... olhe a data do post: 2011-03-31 23:59:60, ou seja, 2011-04-01 00:00:00 hehehehe

Do mais, parabéns a kiko pela criatividade, referenciar e documentar todo o texto dão uma credibilidade tão grande, que se o post fosse em qualquer outra data do ano eu acreditaria fácil, fácil... hehehe

Abraço

Tímido Visitante Anônimo | 2011-04-01 12:38:25 | permalink | topo

Kiko,

Parece-me que vc está supondo que o datasheet 'completo' do chip do BMC é mesmo completo. O chip poderia estar lendo, além do SPI, também sinal modulado no sinal de alimentação quando em modo reset via 12V, sem que isso conste do datasheet 'completo'.

Imagino que a reviravolta teria ocorrido qdo vc seguiu o sentido oposto, em direção à fonte do 'ruído' na linha de VCC que alimenta o seu datacenter. Por fim, diante dessa sua aventura, 'enterrar' um servidor de certificação X.509 passa a ser uma idéia não tão paranóica assim...

sds

Rafael | 2011-04-01 11:47:34 | permalink | topo

<script>alert('Cai no 1 de abril. FAIL ahah')</script>

RODRIGO SANTOS SILVA | 2011-04-01 11:31:49 | permalink | topo

Primeiro de abril? (:

Daniel Gomes | 2011-04-01 11:25:53 | permalink | topo

Marco, isso está parecendo estórias de filme... Que situação hein...

Tímido Visitante Anônimo | 2011-04-01 09:52:15 | permalink | topo

Primeiro de abril wee

SUD Filipe | 2011-04-01 01:36:34 | permalink | topo

HO HO HO PRIMEIRO DE ABRIL