#396 – Ataque bancário bilionário

(00:02) [Música] Sejam todos muito bem-vindos e bem-vindas. Estamos de volta com o Segurança Legal, seu podcast de segurança da informação, direito da tecnologia, tecnologia e sociedade. Eu sou o Guilherme Goulart e aqui comigo está o meu amigo Vinícius Serafim. E aí, Vinícius, tudo bem? E aí, Guilherme, tudo bem? Olá aos nossos ouvintes, olá aos internautas.

(00:27) Muito bem, sempre lembrando que para nós é fundamental a participação de todos por meio de perguntas, críticas e sugestões de temas. Para isso, estamos à disposição, como você já sabe, pelo e-mail podcast@segurançalegal.com, YouTube, Mastodon, Bluesky e Instagram.

(00:50) Também temos a nossa campanha de financiamento coletivo no Apoia.se, em apoia.se/segurançalegal. No blog da Brownpipe, www.brownpipe.com.br, você consegue ver as notícias mais importantes de segurança e também se inscrever no nosso mailing semanal para receber essas atualizações periodicamente.

(01:13) Que semana, hein, Vinícius? Pois é. Uma semana de confusão mental ao redor desse golpe bilionário. Não foi em dólares, foi em reais mesmo. Nem se sabe se foi 1 bilhão, mas já se falou em 400 milhões, já se falou em 3 bilhões. Eu já vi notícias falando de 3 bilhões, 800 bilhões.

(01:40) É de todo tipo de valor. Teve bastante coisa nesses últimos dias. O ataque foi divulgado no dia primeiro de julho. Hoje, gravamos no dia 7, uma semana depois. Que ataque! Talvez tenha gente que não saiba do que estamos falando, embora eu ache difícil. Se você ouviu, viu televisão, saiu no Fantástico, Jornal Nacional, em todos os portais de notícias.

(02:11) Um ataque divulgado agora no dia primeiro de julho de desvios milionários ou talvez bilionários de contas de clientes de uma empresa chamada CM. A gente vai falar um pouco depois sobre os papéis de cada um no sistema financeiro, no sistema de pagamentos brasileiro e também no sistema Pix. Mas ela é um provedor de serviços de tecnologia da informação que conecta instituições financeiras aos serviços e à rede do Banco Central e também intermedeia uma série de serviços para empresas.

(02:47) Que não querem se conectar diretamente com a rede do Banco Central, elas utilizam serviços de intermediação. Então, o que se sabe até agora é que foi realizado o desvio de valores de clientes da CM. A CM não é a dona do dinheiro, ela só faz a intermediação.

(03:12) Então, quem sofreu o golpe e quem sofreu financeiramente, pelo menos diretamente, foram os bancos. Os valores maiores teriam saído do banco BMP, que é um dos clientes da CM. No primeiro momento, ficou-se especulando como eles teriam tido acesso à infraestrutura da CM, uma empresa autorizada pelo Banco Central para fazer esse serviço de intermediação.

(03:38) Mas logo depois descobriu-se que um funcionário teria sido aliciado e vendido as suas credenciais. Por quantos milhões, Vinícius? R$ 15.000. R$ 15.000. Não só as credenciais, mas a cooperação ativa, pelo que a gente viu nas notícias, ao longo dos meses que antecederam essa operação, que foi agora no início do mês passado. Foi em junho a operação.

(04:09) 30 de junho começou, na virada para julho. Então, ele ficou alguns meses nesse processo e não foi “recebeu 15.000 e entregou as credenciais”. Ele cooperou estando dentro. E isso acho que foi um pouco desconsiderado pela mídia, a ideia de “somente as credenciais”.

(04:34) Não, não foi somente as credenciais, porque ele teria sido aliciado ainda em março deste ano. Ele era um funcionário de 48 anos, foi eletricista predial, técnico de instalação de TV a cabo, entra na faculdade de tecnologia aos 42 e, pelo que eu li, trabalhava há 3 anos na CM. Em maio, veja, ele é aliciado em março.

(04:58) Nesse período, ele recebeu valores por motoboy, tinha um protocolo de descartar celulares depois que se comunicava com os criminosos. Trocava de celular a cada 15 dias. Mas o que a gente leu até agora é que desde maio ele teria começado a inserir comandos maliciosos no ambiente da CM. Diga. Eu ia dizer o seguinte, que quando a gente fala “inserir comandos maliciosos”, não é que ele estaria inserindo necessariamente operações a serem executadas, mas eu diria que ele estava recebendo comandos do pessoal que o contratou.

(05:35) O que se faria? Pensando como quem faz pen test, nós não chegamos a fazer esse tipo de operação de aliciar funcionário para testar.

(05:55) Isso a gente não faz. Mas se colocando no lugar do criminoso, e não do hacker, no lugar do criminoso: eu pediria para esse cara levantar informações sobre o ambiente, o que tem, como é feita a gestão, que antivírus usam, se tem controle de acesso, como é organizada a rede. Tem um monte de informação que eu pediria se eu tivesse tempo como criminoso, até chegar a um ponto em que eu daria um jeito de estabelecer algum tipo de acesso remoto, se fosse possível, ou constatar que não era, e aí teria que seguir outro caminho.

(06:34) Então, quando falam que ele estava executando comandos desde maio… Dentro dessa expressão “executar comandos”, muita coisa fica escondida, implícita.

(07:01) Essa questão dele estar levantando informação, fazendo print de tela, tirando foto com celular, mostrando o ambiente físico onde ele estava, que dependendo da situação pode ser relevante… Esse cara estava levantando informação há um tempão. Pode ser que, à medida que a Polícia Federal for investigando, ela vá descobrindo mais coisas. Talvez não seja uma mera coincidência.

(07:25) Talvez esse cara não tenha sido aliciado a partir do momento que ele entrou na empresa. Ele pode ter entrado na empresa já como parte de um ataque mais amplo, com investimento. Se o ganho potencial é grande, você investe mais tempo, mais recursos. E aí é importante dizer, Vinícius, e deveríamos ter dito antes, que estamos no campo de estabelecer algumas hipóteses para como o ataque se deu. Isso que você está fazendo agora é levantar algumas hipóteses.

(07:55) Porque no exterior é bem mais comum, até em questões de Estado, colocar pessoas dentro de ambientes propositalmente para que elas façam levantamentos e contribuam com criminosos. Você tem, às vezes, até grupos criminosos que financiam faculdades de pessoas.

(08:19) Não estou dizendo que foi esse o caso. Mas, diante dos valores que foram desviados, e claro, ainda tem que se chegar aos cabeças dessa organização criminosa, que até o momento não se sabe quem são, o valor possível como fruto desse crime justificaria medidas até mais longas. Enfim, o ataque teria ocorrido no dia 30 de junho.

(08:43) Isso resultou em 166 transações fraudulentas via Pix. O próprio BMP teria notado algumas movimentações atípicas em suas contas, e também algumas exchanges de criptoativos, porque eles começaram não somente a distribuir dinheiro para outras contas, mas também a tentar lavar e distribuir o dinheiro pela via da compra de criptomoedas. No dia 1º de julho, a CM comunica o Banco Central, que desliga os acessos da empresa (desse PSTI) de maneira preventiva. Dia 2 de julho, o BC torna público o ataque e abre-se o inquérito.

(09:20) Dia 3 de julho, a CM anuncia a retomada parcial das operações e, à noite, o funcionário é preso. Pulamos aqui para o dia 7. O mais relevante é que a polícia revela uma tabela de quem recebeu os valores, que seriam 29 instituições financeiras.

(09:43) Desses valores desviados, 270 milhões que saíram do BMP já foram bloqueados, e esses 270 milhões teriam ido para a instituição SOF, segundo as informações da polícia. Até agora, foram suspensas sete instituições financeiras que teriam recebido esses valores. Houve uma suspensão, acredito eu, preliminar. Não que elas vão deixar de operar, mas para se investigar se eventualmente teriam algum papel. Mas também não se sabe qual foi o grau de participação delas. Até onde se sabe, elas somente receberam esses valores. E ao suspendê-las, elas não conseguem movimentar esses valores.

(10:20) Então essa é uma boa razão para suspender rapidamente. Os valores foram parar nas contas que elas administram; perdendo o acesso ao sistema financeiro, elas não conseguem movimentar isso. Então, fica tudo bloqueado automaticamente. Deixa eu te jogar a bola aqui, Vinícius, no seguinte sentido.

(10:45) Vamos fazer uma tentativa de falar um pouco sobre o funcionamento do sistema de pagamentos brasileiro de maneira geral, e também do sistema de pagamentos instantâneo, que abriga o Pix e que, de fato, foi utilizado. Porque tem bastante coisa aí sobre como se dá essa interação entre essas empresas. Temos instituições financeiras que são participantes diretas e indiretas, mas também temos instituições financeiras que querem se comunicar à infraestrutura do Banco Central.

(11:22) Querem se comunicar com a rede do Banco Central, a RSFN (Rede do Sistema Financeiro Nacional), mas não conseguem, ou porque pode ser custoso, ou um trabalho que não querem ter. E aí, elas acabam tendo algumas estratégias para fazer isso.

(11:45) Mas, enfim, como a coisa funciona? Os detalhes de tudo que estamos falando estão na documentação do Pix, nos padrões de mensagens, no nível de segurança requerido, nos protocolos. Está tudo aberto, é algo altamente regulado, está lá no site do Banco Central do Brasil.

(12:11) O link para a documentação estará no Show Notes. Lá tem tudo detalhadamente. Vamos dar um overview necessário para conseguir entender de onde partem algumas hipóteses que levantamos. E, repetindo, aliás, obrigado ao pessoal do grupo do Telegram do Segurança Legal, dos nossos apoiadores, que mandaram relatórios, informações que foram colhendo. Nós olhamos todas essas informações.

(12:46) Não vamos citar os nomes dos relatórios ou das empresas que os fizeram para não parecer que estamos criticando. Vimos várias suposições que talvez não se sustentem e informações que, no nosso entender, não deveriam estar sendo tornadas públicas, a não ser pela própria CM.

(13:12) Se ela contratou algum desses relatórios, deveria estar deixando bem claro que está tornando isso público. Porque temos relatórios de empresas sobre os quais não se sabe exatamente como verificaram as informações, se foram contratadas pela CM, etc. Bom, feito esse agradecimento ao pessoal do nosso grupo, vamos ao funcionamento, da maneira mais simples possível. As instituições financeiras precisam se comunicar.

(13:46) O dinheiro não é transferido por malote, como antigamente. As transferências são feitas por meio de “documentos eletrônicos”, transações eletrônicas que movimentam o valor. Elas não circulam diretamente pela internet, pelo menos não normalmente. Por quê? Porque existe uma rede, a Rede do Sistema Financeiro Nacional (RSFN).

(14:28) Que conecta as instituições participantes, direta e indiretamente, a ela. A internet funciona como contingência para esta rede.

(14:52) Eventualmente, a comunicação entre as instituições pode acontecer via internet em uma situação de contingência. Mas, se não, é só pela RSFN. Em ambos os caminhos, tudo é cifrado. Mas, o ideal é que, funcionando adequadamente, seja sempre essa rede fechada do sistema financeiro nacional.

(15:18) Então, não é qualquer um que, ao conseguir uma credencial, vai conseguir se meter lá dentro desta rede. É físico, você contrata um provedor, um link. Existem provedores autorizados. Só que, para você conectar um sistema seu ao Pix, que é o SPI (Sistema de Pagamentos Instantâneos)…

(15:43) Temos o SPB (Sistema de Pagamentos Brasileiro) e o SPI, que também está nessa mesma rede. Para conectar um sistema seu a esta rede e falar com o SPI, você tem que cumprir uma série de requisitos, desde o protocolo de comunicação, as trocas de mensagens, o que deve ser esperado, o que deve ser respondido, etc.

(16:12) Você tem que implementar esse protocolo na sua aplicação e todos os mecanismos de segurança que o Banco Central demanda. Então, entre sua aplicação e o SPI, vai ter, por exemplo, autenticação via mTLS, ou seja, as duas pontas (SPI e sua aplicação) terão um certificado digital, uma chave privada, e ambos vão se autenticar, um validando o certificado e as assinaturas do outro. Esse é um exemplo de demanda para falar com o SPI diretamente.

(16:49) Sem contar outros requisitos de funcionamento que dizem respeito, por exemplo, a tempo de resposta. Você não pode receber uma demanda para fazer um Pix e levar um minuto para responder. Há até multa prevista para isso. Então, é uma série de requisitos a se cumprir para poder conectar seu sistema. E, claro, sua empresa não se conecta diretamente, ela terá um sistema que vai se conectar em seu nome no SPI.

(17:18) Fazer isso é custoso, trabalhoso. Há um monte de coisas a se observar, sem contar as questões de segurança naturalmente envolvidas. Por isso, muitas vezes é mais fácil e barato contratar um PSTI. O que é o tal do PSTI? É a empresa que vai fazer a implementação para falar com o SPI diretamente.

(17:59) Ela vai te fornecer uma API. Vamos pegar o caso da CM. A CM é um PSTI e um dos seus serviços, o Corner, faz essa integração com o Pix e outras formas de pagamento. O que eles fazem? Eles implementam essa complexidade toda para falar com o SPI do Banco Central, se homologam e te vendem um serviço de “banking as a service”.

(18:37) “Olha, você não precisa implementar tudo isso para falar com o Banco Central. Está aqui a minha API, você consome, fala comigo e eu faço as operações para você. Você não precisa estar conectado direto à Rede do Sistema Financeiro Nacional.”

(18:54) A CM está conectada. Você não precisa implementar seu software para falar com o SPI, você usa as APIs da CM e ela implementa o software para falar com o Banco Central como tem que ser. A partir daí, você se preocupa mais com o seu negócio, o seu core business, e deixa essa parte para um terceiro.

(19:16) Assim como existe a CM, há várias outras empresas que atuam como PSTI. OK. Acho que pode falar um pouquinho também, não sei se você ia chegar nesse ponto, sobre o processo de assinatura de um Pix. Porque existe um protocolo que permite que, quando eu faço um Pix para outra pessoa, isso siga um certo caminho, o que é importante para entender o crime que foi cometido aqui.

(19:51) A questão é a seguinte. Imaginem vários círculos concêntricos. O Banco Central é o nível zero. Isso me lembra muito a organização do Kernel do Linux. O Banco Central tem que ter um nível de segurança bastante alto.

(20:14) Ao redor dele estão essas empresas que, ou por meio de um PSTI, conectam-se ao sistema do Banco Central para fornecer serviços a terceiros, ou os próprios bancos que implementam seus sistemas e se conectam direto.

(20:40) Esses caras estão em um primeiro nível, em volta do Banco Central. A comunicação com esse primeiro nível é controlada pelo Banco Central, que determina os protocolos de comunicação, não só a cifragem da comunicação com autenticação mútua, mas também a assinatura digital das operações.

(21:05) E o Banco Central diz qual é o formato dessas operações, que é XML. Existe uma estrutura XML para essas operações que diz, de forma bem abstrata: “Fazer um Pix da conta do fulano de tal, do banco tal, para a conta tal, com a chave tal…”. E ele assina essa operação, que vai assinada.

(21:39) Vai assinada por quem? Não pelo Vinícius na ponta, o titular da conta que está fazendo o Pix. A operação vai assinada pela instituição que gerencia a minha conta. Então, imaginando de forma mais abstrata, quando eu faço um Pix, se estou usando o serviço de um PSTI, eu dou a ordem para a minha instituição.

(22:09) Essa minha ordem vai ser processada pelo sistema do banco para verificar saldos antes de a mensagem ir para o Banco Central. Confere? Sim, confere. Mas perceba que, para o Banco Central, desse primeiro nível para o nível zero, basta que a operação esteja assinada digitalmente. Os bancos usam o certificado SPB para realizar essas assinaturas. Isso. Ele assina digitalmente, de maneira análoga a como a gente assina no gov.br.

(22:45) Essa assinatura das transações é feita por essas instituições que se conectam ao Banco Central. Notem que, nesse primeiro nível, o Banco Central tem um controle de segurança bastante grande, porque ele não aceita uma transação que não tenha sido assinada digitalmente, o que é um nível de segurança robusto. Agora, do primeiro nível para o segundo, digamos assim… Vamos pegar a CM.

(23:17) Ela está no primeiro nível e fornece serviços para um segundo nível de empresas, fintechs e tudo mais, que contratam seu serviço para não falar direto com o SPI. A CM, então, do primeiro para o segundo nível, vai definir qual é o protocolo de segurança dela com seus clientes. E note, não é a pessoa física final, são as empresas que têm as contas ou as fornecem.

(23:49) São as instituições financeiras que estão interagindo ali. Aí começa nosso primeiro problema, porque não sabemos exatamente quais são os critérios de segurança entre a CM e seus clientes.

(24:06) Procuramos por documentação de API, manual de integração, algo parecido. Se alguém encontrar, nos mande, pois ajuda a esclarecer dúvidas. Então, nesse segundo nível, a segurança começa a ficar mais fraca à medida que se distancia do Banco Central e de sua regulação.

(24:37) E o PSTI da CM, por exemplo, como diz no site deles, é “Integrado aos principais sistemas legado do mercado nacional”.

(25:01) Para se integrar com sistema legado, não que todo sistema legado seja ruim em termos de segurança, mas em geral é preciso abrir mão de certas coisas, porque você não vai conseguir ajustar o sistema sem trocá-lo ou fazer uma mudança muito grande, e o pessoal não quer mexer.

(25:20) Então, a solução é: “Eu ponho o seu sistema legado, cuja segurança não é lá essas coisas, para falar com o SPI”. Esse tipo de solução acaba fazendo uma tradução que cria um desnível de segurança entre ela e o Banco Central, e entre ela e o cliente que está atendendo. Então, há esse enfraquecimento. Depois, você pode considerar o terceiro nível, da instituição financeira com o cliente dela.

(25:59) E vocês sabem, hoje com esses bancos via app, todo mundo já abriu várias contas em vários bancos. Vocês veem que os bancos têm níveis de segurança diferentes para a autenticação dos clientes. Tem bancos que priorizam a segurança e sacrificam um pouco a usabilidade, exigindo mais etapas para certas operações.

(26:38) Outros fazem o contrário: “Não vou atrapalhar a vida do usuário. Vou checar a senha, se o aparelho é o mesmo, e é isso.”

(27:06) “Não vou ficar pedindo biometria. O que tiver de fraude, depois eu pago. Considero que a quantidade de fraude será pequena.” Então, você enfraquece ainda mais o processo. No final das contas, quem autentica o cliente dono da conta na ponta é a instituição financeira, e ela autentica como quer. Claro, se ela for muito displicente, pode acabar sofrendo sanções do Banco Central, dependendo da situação.

(27:43) Num segundo nível, da instituição que fornece as contas com o PSTI (no caso, a CM), é entre eles que se define o processo de integração. E da CM para o Banco Central, aí sim, o Banco Central determina como é.

(28:03) Então, notem que, à medida que nos distanciamos do Banco Central, a tendência é que o nível de segurança se reduza. E já vimos isso acontecer, Guilherme. O Banco Central tem um esquema, “você tem que estar na Rede do Sistema Financeiro Nacional…”.

(28:29) E, de repente, você vê alguns bancos por aí permitindo consultas enlouquecidas no dicionário de chaves do Pix. Tem o famoso caso do Banese, que já comentamos, com mais de 300 mil chaves Pix vazadas. E isso aconteceu com mais de uma entidade. Eventualmente, o Banco Central publica em seu site um incidente de vazamento de chaves Pix. Exato.

(29:02) Se você conseguir acessar o SPI por meio de uma dessas instituições, você manda fazer um Pix da conta tal para a conta tal e acabou. Não vai acionar o usuário para ele autorizar no aplicativo. A instituição financeira ou mesmo o PSTI no meio do caminho simplesmente comanda isso. Então, isso não necessariamente envolve o titular da conta.

(29:33) E acho que você falou algo importante aí: como o dinheiro transita entre as contas. Porque houve uma série de alegações sobre de onde o dinheiro saiu. Voltando àquela ideia, como funciona quando fazemos um Pix? O Vinícius falou da assinatura, dos certificados, chaves privadas. O BC reconhece que a mensagem do Pix foi assinada por aquela instituição e segue o baile.

(30:05) Agora, como funciona quando eu transfiro um Pix para o Vinícius? O dinheiro que vai para o Vinícius não sai da minha conta. Se eu vou mandar R$ 100, o meu banco primeiro verifica se eu tenho saldo naquela conta.

(30:38) Uma vez que eu tenho R$ 100, o dinheiro do Pix não sai diretamente da minha conta, ele sai de algo chamado “conta PI”. A conta PI é um grande cofre onde está o dinheiro do banco, e essa conta tem que ter liquidez para permitir os Pix daquela instituição. A instituição financeira precisa manter liquidez naquela conta PI. Os meus R$ 100, que o banco já viu que eu tinha na minha conta…

(31:12) Ele vai mandar via conta PI, através do SPI, o dinheiro do meu banco para o banco do Vinícius. Do outro lado, quando o dinheiro chega, o banco vai entender que aquele Pix foi para o Vinícius e o valor será creditado na conta dele.

(31:34) Mas não é uma transferência direta entre contas dos correntistas. Os clientes não têm valores nas contas PI, que são as contas que o próprio banco mantém com liquidez para alimentar as transações. Essas contas PI são de titularidade das instituições. Por isso se disse: “A instituição financeira sofreu as perdas e nenhum cliente sofreu perda financeira.”

(32:09) Porque os fundos dos clientes ficam fora das contas PI. As contas PI e o STR são infraestruturas centrais de liquidação entre os próprios bancos. E aí começamos a entrar talvez na hipótese de como isso se deu. Eu coloco a hipótese aqui, depois você pode abordar os aspectos mais técnicos. Como o fraudador conseguiria retirar dinheiro da instituição financeira sem invadir as contas dos correntistas?

(32:47) Porque uma coisa é eu invadir sua conta, seu aplicativo, por essas fraudes comuns, e retirar dinheiro da sua conta. Outra coisa, e parece que foi isso que aconteceu, é conseguir acesso ao sistema que faz a intermediação das transações Pix e conseguir criar transações que não foram lastreadas em pedidos dos próprios correntistas. Me parece que essa é a hipótese mais possível.

(33:22) Ou seja, ele não “simulou”. Eu nem usaria essa palavra. Ele falsificou. Ele criou operações de Pix não lastreadas, que não estão fundamentadas num pedido de um correntista. Sim.

(33:44) E como o dinheiro do Pix sai da conta PI… Primeiro o banco verifica se há saldo na sua conta, mas o dinheiro sai da conta PI, por isso ela tem que ter grande liquidez. Se eu rompo esse primeiro pedido do usuário e consigo interagir com o sistema, fazendo transações não solicitadas por ele, vou estar tirando dinheiro da conta PI sem tirar dinheiro da conta dos usuários. Então, parece que foi isso que aconteceu.

(34:23) Quando peço um Pix, eu, Vinícius, não estou pedindo diretamente ao Banco Central. Estou fazendo essa solicitação a um procurador, que é o banco. Ao fazer esse pedido, o banco movimenta as contas que o Guilherme explicou e faz a transferência. O próprio banco diz: “Olha, isso aqui é da conta do Vinícius, ele tem saldo”, e faz isso em meu nome.

(34:59) Notem que existe um procurador no meio do caminho. Estou falando só de Vinícius, meu banco e o Banco Central, tirando o PSTI do caminho por agora. Agora, se o banco, por qualquer razão, quiser dizer ao Banco Central que o Vinícius pediu um Pix, o Banco Central vai fazer. Acabou.

(35:35) Tendo o Vinícius saldo ou não. O Banco Central não verifica se o Vinícius tem saldo. Depois, o banco que se vire com a liquidez. Mas o banco consegue fazer uma operação sem eu ter solicitado. “Ah, mas meu Deus, então é inseguro.”

(35:54) Não, gente. Por isso temos que contratar serviços de entidades confiáveis, reguladas pelo Banco Central: os bancos. Porque há entidades que não são exatamente reguladas pelo Banco Central, e aí há outro problema.

(36:13) Então, eu tenho que confiar nesse meu procurador. É como dar uma procuração. Quando você dá uma procuração para alguém, você confia nessa pessoa. Posso dar uma procuração para o Guilherme vender meu carro, para alguém casar em meu nome, reconhecer filho…

(36:31) Você confia no seu procurador. O seu banco é seu procurador perante o Banco Central. O Banco Central não sabe se você autorizou ou não. Ele confia que, se o banco está pedindo para fazer um Pix da sua conta, é porque obteve sua autorização de maneira razoavelmente segura.

(37:05) Agora, a mesma coisa acontece com o PSTI, dependendo de como é implementado. Vocês lembram que o Guilherme ressaltou que as transações têm que ser assinadas pelo banco que as solicita.

(37:29) Só que, quando você contrata um PSTI, normalmente é para não se incomodar com a implementação que vai falar com o SPI. Faz parte da ideia de não se incomodar, de alguma forma, entregar sua chave privada para o PSTI, para que eles possam te dar uma API simples de chamar. E isso pode variar muito de acordo com a implementação de cada PSTI.

(38:06) “Ah, mas é um software instalado na minha rede.” Não importa. É um software sob controle do PSTI. Ele vai ter que ter essa chave para conseguir assinar as transações em nome do banco. Então, se alguém tiver acesso ao sistema do PSTI, e esse sistema tiver as chaves de assinatura lá dentro, e esse alguém conseguir fazer um bypass na autenticação (não ter que se autenticar como banco X, Y ou Z), ele pode solicitar diretamente ao back-end:

(38:45) “Faz uma transação para mim em nome do banco tal…”, e o sistema vai fazer. Ele vai assinar e vai enviar, porque o dinheiro está saindo da conta PI.

(39:05) Dificilmente você faria diferente. Você, como PSTI, poderia dizer: “Eu sou a CM, mas não quero sua chave privada nos meus sistemas”.

(39:23) Então, o cliente teria que mandar a transação para o Pix já assinada. Aí volta toda a trabalheira de ter que montar a mensagem, em vez de só usar a API fácil. Então, eu penso que uma das hipóteses que levantamos é que sim, essas chaves privadas estão em ativos (servidor físico ou virtual) aos quais a CM, de alguma forma, tem acesso. Nem que seja num HSM.

(40:08) O pessoal está dizendo que a CM não tinha HSM. Eu não sei. HSM é um Hardware Security Module. A ideia é que você gera seu par de chaves lá dentro e sua chave privada nunca sai de lá. Esse é o ideal.

(40:26) Mas vários HSMs aceitam que você importe a chave privada. Portanto, você poderia gerá-la fora e importar. Depois que está lá dentro, você não consegue mais ler a chave. E como se faz para assinar? Você manda o payload (o que quer assinar) para o HSM, e ele assina. O HSM pode ser um hardware que você compra ou um serviço na nuvem, como o da Amazon.

(40:54) Para dúvidas sobre certificação digital, escutem nossos episódios 7 e 8. Porque uma das hipóteses que se levantou foi justamente essa: “Como eles conseguiram assinar?”. É uma pergunta interessante. Se as chaves privadas estivessem num diretório de um servidor, você pegaria a chave privada.

(41:22) Claro, você ainda teria que ter a senha dela, mas com a colaboração de um desenvolvedor… Enfim, você conseguiria assinar mensagens com a chave privada armazenada em um diretório. Agora, o fato de a chave privada estar no HSM impediria esta fraude?

(41:46) Não. Quer ver? Boa parte dos que nos escutam tem o gov.br e acesso ao assinador digital de lá. Você já viu sua chave privada do gov.br? Não, né? Mas ela está lá, guardada em algum lugar.

(42:17) Espero que em um HSM. De um jeito ou de outro, os documentos são assinados mediante uma autenticação que o gov.br faz comigo. Depois que ele me autentica, ele pega minha chave privada, que está lá, e assina o documento como se eu tivesse assinado.

(42:45) Funciona de forma idêntica com as assinaturas dessas transações. Então, ainda que a CM tenha um HSM com as chaves privadas de todos os seus clientes (o que seria o ideal), se o criminoso achou um jeito de fazer um bypass na autenticação… Por exemplo, eu teria que me autenticar como o BMP. Se eu tenho as credenciais do BMP, é um jeito. Se não tenho, mas tenho como dizer ao sistema: “Faça uma operação em nome do BMP”,

(43:23) Ele vai fazer. Vai mandar para o HSM, que vai assinar e mandar adiante. O HSM só vai impedir que as chaves sejam roubadas, que alguém possa copiá-las e usá-las em outro lugar.

(43:47) Só que isso teria pouca utilidade, porque para usar o SPI, você tem que estar na Rede do Sistema Financeiro Nacional, que é restrita. O Vinícius não pode simplesmente se conectar a ela. Eu, com um certificado desses, não consigo fazer nada.

(44:07) Agora, eu com acesso a uma chave privada dessas, mesmo em um HSM, a partir da estrutura da CM, aí é outra figura. Porque também se falou sobre uma vulnerabilidade no serviço de mensageria utilizado. Mas o serviço de mensageria faz parte de uma arquitetura maior, que envolve o envio e a validação dessas mensagens, que são as ordens Pix, que serão assinadas digitalmente. Isso faz parte de uma cadeia muito grande de softwares.

(44:44) Na verdade, ali na CM é praticamente só a CM falando com o SPI. O que você tem é uma API da CM pela qual você poderia comandar o pagamento de Pix. Agora, como é essa API? Não sei.

(45:09) Essa API tem alguma chamada que um operador possa fazer diretamente? Não sei. Ou, por exemplo, o cara que estava cooperando com os criminosos, que está preso, ele era desenvolvedor. Será que ele não tinha acesso a um endpoint de uma API que permitisse transferir dinheiro de quem ele quisesse para quem ele quisesse, sem autenticação, com a requisição controlada por IP, acessível apenas de um servidor específico?

(45:53) Aí vai lá o desenvolvedor que tem acesso a essa API, faz uma chamada e realiza a transferência. E aí? Lembrando, não foi somente a questão das credenciais dele. O fato de ele ter dado as credenciais para os criminosos significa que elas foram usadas em algum momento. Por que ele as venderia se não fossem usadas? Então, efetivamente, algum tipo de interação ocorreu.

(46:23) Claro que, quando vemos a notícia, às vezes ela não tem nada a ver com o que aconteceu na realidade, porque é o jornalista tentando explicar. Talvez o “vender credenciais” tenha sido muito mais um pagamento para ele apoiar tecnicamente os criminosos, sem necessariamente ser a venda de uma credencial para acessar uma VPN. Poderia ser várias coisas. A questão é que ele, um desenvolvedor, colaborou tecnicamente com criminosos.

(46:52) Pelo menos de março a maio, você pode ter uma fase de reconhecimento, de entendimento. Não sabemos se outras pessoas que trabalharam lá e saíram, ou que ainda trabalham, colaboraram de outras formas, indicando como a infraestrutura funciona internamente. Porque, se o lucro é de 1 bilhão, R$ 15.000 não é nada.

(47:25) Ou seja, posso pagar muito mais. A organização dessas organizações criminosas não é algo como “vou chegar ali e vou invadir”. Houve uma etapa, me parece, bem longa de planejamento para chegar a esse resultado.

(47:50) Sim. E com esse cara apoiando, e ele como desenvolvedor… Frequentemente, quem está na área sabe, desenvolvedores têm acesso a uma série de credenciais de produção: de banco de dados, de painéis administrativos que não são para uso do cliente.

(48:22) Ou lugares onde se pode, efetivamente, fazer manualmente algum tipo de operação, seja para teste, debug ou uma situação emergencial. Existem esses caminhos. Então, quando ele “vende credencial”, sim, pode ter vendido uma, mas credencial para quê? De quê?

(48:51) Dependendo do que é, a credencial só serve dentro da rede da CM. Agora, dependendo da situação, o cara pode ter conseguido instalar algo dentro da rede da CM, como em “Mr. Robot”, plugar um Raspberry Pi na rede. Dependendo do controle que a CM tem, talvez o equipamento funcione, feche uma VPN com o atacante e dê a ele acesso remoto.

(49:23) Esse “vendeu credenciais” é uma maneira rápida de explicar. Pode não ter sido como se logar no home banking e transferir. Pode ser uma série de coisas. Mas, dado o tempo e a cooperação de alguém de dentro…

(49:55) E dado que não foi só um cliente (atacaram uns quatro ou cinco), tudo indica que a CM de alguma maneira foi o foco. Aí resta saber, por exemplo: ele fez essas transações se autenticando como cada um desses clientes ou com um tipo de credencial que permitia operar em nome deles, fazendo aquele bypass que eu falei? Assim como o banco pode fazer um Pix na nossa conta sem a gente autorizar.

(50:36) Depois a gente vai ter que brigar com o banco, mas o banco pode fazer. Então, foi esse o caso? Até porque, Vinícius, ele conseguiu assinar transações com chaves privadas de várias instituições que estavam sob o controle da CM.

(51:00) Sim. Tudo indica que ele teve algum acesso na CM que permitiu fazer um bypass dessa autenticação, ou ele conseguiu as credenciais efetivas desses quatro ou cinco clientes. Por isso seria importante ver a documentação da API, da integração que a CM oferece, mas talvez ela tenha optado por não deixar isso aberto, comunicando apenas para quem contrata seus serviços. O que eu acho tranquilo, deveria ser assim mesmo.

(51:26) O resto é especulação. Vimos o pessoal comentando sobre uma vulnerabilidade no sistema de mensageria que a CM utiliza. E não estou reduzindo a importância disso, mas encontrar uma versão de uma biblioteca sujeita a um CVE conhecido não quer dizer que, nas condições daquele ambiente, ela possa ser explorada.

(52:42) A vulnerabilidade depende da configuração do software, do ambiente, da rede. Ela pode não ser explorável na prática. E, ao mesmo tempo, tendo uma pessoa dentro cooperando, pensando como criminoso, acho que há caminhos mais fáceis do que ficar caçando vulnerabilidades para explorar.

(53:13) Sobretudo se for um desenvolvedor. Exato. Se eu tenho tempo, acesso a código… O que mais interessa são as credenciais, que muitas vezes estão nos repositórios ou no ambiente de produção. O desenvolvedor pode não conseguir alterar, mas consegue ler. Consegue ver variáveis de ambiente com senhas de banco de dados, do HSM…

(53:39) De repente, está tudo lá, e ele tem acesso de leitura. Talvez não para alterar, mas o suficiente para ver.

(53:57) Então, há caminhos, a meu ver, mais fáceis. E se foi o vazamento de uma API, não duvido de um uso indevido de API, sabe, Guilherme? É perfeitamente possível. Alguém pegou as credenciais que o BMP usa para se autenticar na API da CM e fez as operações.

(54:24) Claro que, dado que há vários clientes da CM envolvidos, tudo indica que a CM de alguma maneira foi o foco. E, de novo, óbvio, tinha o desenvolvedor lá dentro ajudando os caras.

(54:49) Essa é a peça em comum. E também, eu estava dando uma pesquisada em fraudes financeiras…

(55:11) Em fevereiro, para vocês terem uma ideia, o maior roubo da história das criptomoedas foi de US$ 1,46 bilhão, de uma exchange, a Bybit, a segunda maior do mundo. Então, a gente tem que ter muito cuidado ao sair dizendo o que aconteceu, o que é mais seguro ou inseguro, ou dizer “como é podre o sistema do Banco Central”.

(56:03) Tem coisa sendo dita nesse sentido. É uma questão de confiança. O Banco Central vai ter que confiar em alguém. A não ser que ele entregue chaves privadas para cada correntista, para o Vinícius aqui assinar o Pix com a chave privada dele e o Banco Central verificar. Eu poderia fazer isso, mas, obviamente, isso não vai acontecer.

(56:36) Quem sabe em um caminho futuro, com identidade digital muito bem estabelecida, com celulares mais seguros, talvez seja viável o próprio correntista assinar a transação. Mas, por enquanto, não é o que temos.

(57:12) A grande questão é que a arquitetura pensada pelo Banco Central exige chave privada para assinatura de transações, o que é uma segurança razoável. E para se conectar ao SPI, há todo um manual de segurança, uma série de regras, resoluções, instruções normativas que passamos estudando e revisando.

(58:06) É muita coisa, são muitas normas, e saem atualizações. E perceba que, se o Banco Central resolver regular para além da comunicação dele com o primeiro nível (as empresas que se conectam diretamente a ele), ele vai começar a criar empecilhos. Por exemplo, “esquece sistema legado integrado”, como a CM anuncia. Sistema legado, dependendo, não vai ter mTLS.

(58:52) Então, coisas não poderão ser feitas, sistemas ficarão de fora. E uma coisa que existe muito no universo do sistema financeiro é sistema legado. E dali para diante, os próprios bancos, com seus clientes, também fazem o cálculo de reduzir a segurança na ponta, comparado com a segurança que o BC exige do outro lado. Não dá para tornar o sistema inviável para o usuário.

(59:32) É a velha história da conveniência versus segurança. Nós temos um sistema financeiro bastante sólido e reconhecido mundialmente como sólido e rápido.

(59:55) Definitivamente. Em 2024, passaram pelo SPI R$ 26,5 trilhões, com mais de 63 bilhões de transações. 1 bilhão perto disso não é nada. O que eu acho que vai acontecer agora, para já irmos terminando…

(1:00:21) É o seguinte: de certa forma, é um alerta para as instituições que ainda não acreditam no potencial dos cibercriminosos hoje. Mesmo que o processo de cometer a fraude não tenha sido tão sofisticado, ele foi muito trabalhoso.

(1:00:45) Exigiu um planejamento, me parece, bastante grande, com o envolvimento de muitas pessoas. Então, acho que é um alerta para as instituições. E aqui é futurologia: acredito que o Banco Central vai começar a aprimorar suas práticas de segurança e a exigir mais demonstrações. Porque, no processo de habilitação para aderir ao SPI, a instituição, em alguns casos, faz uma autodeclaração.

(1:01:23) E isso é normal. Ela declara que tem os controles de segurança exigidos pelo manual do Pix e outras regras. O Banco Central pede que ela mantenha essas informações por um período, caso as requeira.

(1:01:55) Mas me parece que o que vai acontecer agora é que o Banco Central será muito mais intenso no acompanhamento, na solicitação e na verificação dessas informações. Porque é preciso confiar, senão você não precisa de bancos, teria só o Banco Central.

(1:02:20) E o sistema brasileiro também foi se abrindo nos últimos anos, com a questão das fintechs. É comum ver uma série de serviços financeiros sendo oferecidos que, eventualmente, podem não ser adequadamente alcançados pelas boas práticas de segurança impostas pelo Banco Central.

(1:02:48) E essa foi uma decisão de abertura. E esse modelo de autorregulação supervisionada, onde se permite que as instituições conectadas tenham responsabilidade em cumprir as regras, também tem seus inconvenientes. A instituição se autodeclara e o Banco Central acompanha.

(1:03:24) É algo que faz parte dessa arquitetura, por meio da geração de evidências que o Banco Central pode solicitar. E, claro, com punições severas. Se você está operando sem o que disse que tinha, será excluído do sistema e pode tomar multas bem sérias. Por fim, Guilherme…

(1:03:55) As empresas têm que ter um cuidado muito grande, a CM e outras que fornecem esse tipo de serviço, principalmente nas integrações entre sistemas. Aí surgem situações como gerenciamento de credencial inadequado.

(1:04:23) Por exemplo, ao fornecer um serviço via API, você pode adotar uma solução como a da Amazon, onde você gera uma chave de API no seu painel de administração, com MFA, tudo bonitinho.

(1:04:46) Ou você pode gerar uma chave e mandar por e-mail para o desenvolvedor do outro lado. Acho que os problemas da segunda opção ficam muito claros.

(1:05:15) O e-mail fica na lixeira, no arquivado, no histórico. Vai saber onde o cara guardou essa chave. Às vezes, os problemas estão nas próprias APIs ou nos frontends, mesmo com as APIs OK. E nós sabemos do que estamos falando, porque na Brown Pipe fazemos testes de invasão em APIs, aplicações web, mobile. A gente vê essas coisas acontecendo.

(1:05:55) E quando você ataca um sistema que tem como função fazer Pix, em última análise, se achar um problema, você vai conseguir fazer um Pix. Enfim, nossa intenção não era dar a notícia, mas pegar o caso concreto para pensarmos e transportarmos para outras situações.

(1:06:31) Você que nos ouve, tem que olhar para as situações que conhece e se perguntar: “De que forma isso é semelhante ao que eu tenho aqui, com gerenciamento de credenciais, APIs, back-ends?”. Temos que nos fazer essas perguntas para tirarmos algo de útil.

(1:07:05) Para não ficarmos só no “invadiram os caras, foi o maior ataque do Brasil…”. Pode ter sido, mas nós vamos ver outros. Esse é o problema. A questão é saber exatamente o que aconteceu.

(1:07:24) Talvez nunca venhamos a saber exatamente. Mas temos que olhar o que aconteceu, tentar extrapolar os pontos frágeis e cuidar de todos eles. Não adianta se vier à tona “ah, foi um CVE”, e focarmos só nisso. Beleza, nesse caso pode ter sido isso.

(1:07:50) Mas, em toda a cadeia de comunicação e integração entre empresas, isso é só um pedacinho, e cada pedacinho pode gerar um problema gigante. Quem cuida de segurança tem que fechar tudo; quem ataca só precisa achar um furinho. Foi o que eles fizeram. Falando em boas práticas…

(1:08:14) O próprio manual de segurança do Sistema Financeiro Nacional fala sobre gestão de chaves: as instituições são responsáveis pela segurança física e lógica do acesso à chave, devem armazená-la em dispositivo especializado para diminuir a exposição a falhas, devem proteger o acesso aos recursos geradores de mensagens para o SPB e não devem reutilizar certificados para outras finalidades.

(1:08:38) Claro, mais uma vez, são hipóteses. A CM é uma empresa consolidada, com grande market share, 20 anos de mercado, contribuiu até na questão do Pix. Então, temos que olhar com cuidado e deixar bem claro que estamos falando no campo das hipóteses, não para macular a imagem de ninguém. Mas, de fato, incidentes ocorrem.

(1:09:12) E, infelizmente, incidentes ocorrem com empresas que às vezes estão muito preparadas. Porque segurança da informação não é eliminar todos os riscos, é conseguir geri-los, às vezes transferi-los, diminuir o impacto. É impossível eliminar todos os riscos de uma atividade complexa com tantos entes diferentes.

(1:10:03) A velha história: o que você faz é aumentar o custo do ataque. E esse caso é clássico. Se seu ganho com o ataque é na ordem de milhões, o funcionário saiu muito barato.

(1:10:31) R$ 15.000 foi troco. Se a perspectiva de ganho são alguns milhões, você tem grana para investir em um ataque que compromete pessoas da instituição. E ele foi fácil. R$ 15.000, pelo amor de Deus.

(1:10:55) Talvez tenha alguma outra relação desse funcionário com a quadrilha. É mais uma intuição, porque é muito pouco. É que, como o pessoal comentou, e acho que você concorda, o ataque não custou R$ 15.000.

(1:11:19) Você tem todo o custo dessa organização criminosa que está, pelo menos desde março, planejando e se preparando. Na verdade, esse custo eu nem considero tanto. O custo é anterior, é o custo de formação, de adquirir o conhecimento para se envolver.

(1:11:50) Não falo do desenvolvedor, mas de quem estuda o ambiente, entende de API. Mesmo que o grupo tenha aprendido sozinho, leva tempo para aprender a programar, etc. É uma construção. Dali em diante, o maior custo é o tempo investido.

(1:12:10) Então não chega a ser um custo tão grande. Agora, claro, eles se arriscaram bastante. Esse é um custo. E deram um jeito de reduzir esse custo pagando R$ 15.000 para um cara que, em tese, não tem contato nenhum com eles.

(1:12:35) Mas acho difícil alguém com a trajetória daquele funcionário… Fazer faculdade aos 42, estar com 48 trabalhando, desenvolvendo, e jogar tudo no lixo por R$ 15.000. Não que seja pouco dinheiro, mas…

(1:12:59) Arruinar sua vida por R$ 15.000? Acho que 15.000 é muito barato para arruinar sua vida. Mas há pessoas que se arruínam por muito menos. Tem. Por quanto dá para comprar a honra de um cara? Às vezes, R$ 1.000.

(1:13:22) Às vezes, R$ 200. Por isso acho delicado. Acho que teremos mais informações sobre esse aspecto. Mas o custo, Guilherme, é o custo de adquirir o conhecimento necessário para o ataque.

(1:13:49) Depois que se tem o conhecimento, é tempo. Às vezes, achamos que o atacante não vai entender toda a arquitetura do SPI, mas os caras estudam. Se você que trabalha na instituição financeira consegue entender, o criminoso também consegue. A própria questão de ele ir direto na conta PI, sabendo que não tiraria dinheiro dos correntistas, já denota um planejamento e uma sofisticação.

(1:14:23) Além da questão técnica, ir no “cérebro” de tudo, no elo que, talvez, seja difícil de explorar, mas que trouxesse um retorno muito maior do que sair invadindo contas de correntistas para tirar R$ 1.000 ou R$ 5.000. Certo. É isso aí.

(1:14:47) Vamos ver o que acontece, se saem mais novidades. Exatamente. Eu gostaria de algo que viesse da própria CM, ou do Banco Central também.

(1:15:07) Entrei no site do Banco Central hoje e não vi nenhuma manifestação, embora a imprensa tenha dito que ele se manifestou. Acho que o Banco Central deveria se manifestar de forma mais ostensiva, trazendo mais informações para tranquilizar. Tem muita gente achando que o sistema agora é inseguro, que vão tirar dinheiro do Pix dela. Não é bem assim. Pelo amor de Deus, gente, não entrem nessa.

(1:15:32) Não entrem nessa de que o Sistema Financeiro Nacional é inseguro. Por favor. Mas é isso, vamos ver o que vem por aí. Vamos lá. Agradecemos a todos que nos acompanharam. Nos encontraremos no próximo episódio do Segurança Legal. Até a próxima. Até a próxima. Isso aí. Feito.

(1:15:57) Fraude. Sempre teve, sempre vai ter. O que se pode fazer é reduzir a fraude. E, claro, todo sistema pode ser aperfeiçoado. Essa é outra lição aprendida. Me parece que o Banco Central é quem vai tirar as lições aprendidas daí.

(1:16:19) Acho que vai exigir mais fortemente das instituições. O Pix vai continuar, não vai acabar. Então, é preciso também corrigir eventuais desvios. E talvez o Banco Central possa caminhar para exigir algum nível de segurança maior entre o primeiro e o segundo nível que eu mencionei antes.

(1:16:56) E modular. Dar algumas opções: “Ou você faz isso, ou aquilo”, para evitar implementações muito malucas, sem segurança nenhuma. “No segundo nível, você tem que implementar pelo menos estes mecanismos.”

(1:17:21) “Não precisa implementar mTLS, porque vai quebrar sistemas legados. Mas, no mínimo, tem que garantir isso, ou ter um processo de auditoria em tempo real mais robusto.” Sim.

(1:17:51) Mas note que já existe regulação sobre uso de nuvem, segurança, aplicáveis às instituições financeiras. A questão é que, como o Banco Central adota a autorregulação supervisionada, você tem autodeclarações, boas práticas, e o Banco Central supervisiona, mas não “faz”. É bastante complicado, a não ser que você elimine os bancos e faça tudo direto no Banco Central.

(1:18:28) Não pode. Não tem como. Você quebra o sistema financeiro. A gente se esquece, mas parece que sempre vivemos com o Pix. Antigamente, dependendo da hora, você não conseguia transferir dinheiro.

(1:18:51) Já era. Essa instantaneidade do Pix traz riscos adicionais, como o da dispersão muito rápida dos valores. E eles conseguiram bloquear 270 milhões, de um montante que saiu do BMP. Porque existem mecanismos de retorno do Pix, tudo previsto na regulação. Mas a instantaneidade coloca desafios adicionais, com o sistema funcionando o tempo inteiro.

(1:19:30) Não é como um TED que só vai ser liquidado no dia seguinte, dando tempo para o Banco Central olhar. Com um Pix instantâneo, o dinheiro cai numa exchange, você compra Bitcoin e acabou.

(1:19:56) Foi o que eles tentaram fazer, e em alguns casos conseguiram. No momento em que você tem algo instantâneo, quando vê, já foi. O cara já comprou criptomoeda, já transferiu para outra carteira e o dinheiro está em uma cold wallet que ninguém sabe de quem é. Agora é esperar.

(1:20:50) Teremos que ver quem está por trás dessa quadrilha. Não acredito que vão ficar só no funcionário. Porque é possível fazer o “follow the money” até certa medida, já que as transações foram para instituições reais. Alguém é dono daquelas contas.

(1:21:19) Claro que muitas vezes são contas fraudulentas, abertas com dados vazados. Às vezes, o titular nem sabe que tem a conta. Mas acho que a polícia vai conseguir chegar aos responsáveis. Com esse valor, não vão deixar barato. É, acho que não. Vamos ver o que acontece. O interessante é que nosso ouvinte já sabe como fazemos nosso trabalho aqui.

(1:21:51) Temos que ir sempre com muita cautela, não dá para sair dizendo “foi tal coisa”. Porque, quando se investiga um incidente, mesmo que pareça óbvio, às vezes surge uma evidência nova que derruba sua hipótese.

(1:22:21) É necessário olhar com cuidado. Esse lance de ficar tentando detonar o sistema financeiro, dizer que é podre, que o Banco Central não tem segurança nenhuma… Por favor. Pode ter alguma falha, nenhum sistema é invulnerável, mas há que se considerar o ambiente onde ele está.

(1:22:53) Chegamos a comentar sobre isso em um episódio depois das eleições passadas. São coisas que têm que ser olhadas com calma. Mas é isso. Obrigado a quem ficou aqui. Falamos mais alguns minutos.

(1:23:19) 1 hora e 23 minutos. Falou, galera, abração. Abraço. Até mais.