Encontrei um sistema de gestão de imóveis a expor dados de inquilinos sem autenticação

Começou com um simples favor

Estive há pouco tempo à conversa com um amigo. Contou-me que estava a ter dificuldades em transferir o extrato de rendas do portal de gestão do seu imóvel. Havia qualquer coisa que não carregava bem.

«Posso ver?», perguntei. Ele enviou-me um link.

Cliquei. Nenhum ecrã de início de sessão. Nenhum pedido de autenticação. Nenhuma página a pedir a palavra-passe.

Apenas o seu nome completo, número de telefone, número da fração e todos os pagamentos de renda que fez desde janeiro de 2023. Seis páginas de histórico financeiro. Acessíveis a qualquer pessoa com o URL.

Nenhum token de sessão. Nenhuma validação de cookies. Nada entre aqueles dados e a internet aberta.

O que significa o modo debug na produção

Peguei eu próprio no URL base para ver o que mais estava exposto. O que apareceu era ainda pior.

O sistema estava a correr em modo debug num servidor de produção. Para quem não é programador, eis o que isso significa em linguagem simples:

O modo debug é algo que os programadores ativam durante o desenvolvimento para os ajudar a encontrar erros. Mostra mensagens de erro detalhadas, caminhos de ficheiros, números de linha do código e a configuração do servidor. Nunca deve ficar ativo quando há utilizadores reais a aceder ao sistema.

O que estava exposto:

• Caminhos completos dos ficheiros no servidor: mostram exatamente onde está o código da aplicação
• Versão da framework e dependências: dizem aos atacantes exatamente que software está a correr
• Lógica interna dos controladores, com números de linha: um mapa de como a aplicação funciona
• Dados do ambiente do servidor: detalhes de configuração que deviam ser secretos
• Informação de cookies e sessões: dados que podiam ser usados para se fazer passar por utilizadores

É o equivalente a um banco deixar as plantas do cofre, os códigos do alarme e os horários dos guardas afixados na porta da rua.

CVEs conhecidas: explorações documentadas publicamente

Assim que vi a versão da framework, comparei-a com a base de dados CVE (Common Vulnerabilities and Exposures). É um registo público onde os investigadores de segurança documentam falhas conhecidas de software.

A versão instalada neste sistema tinha várias vulnerabilidades conhecidas. Não eram riscos teóricos. Eram explorações documentadas, com instruções passo a passo disponíveis na internet.

Um atacante não precisa de ser criativo nem habilidoso. Basta-lhe:

1. Abrir a página de erro (acessível publicamente)
2. Ler a versão da framework
3. Procurar essa versão na base de dados CVE
4. Seguir o guia de exploração publicado

Isto não é pirataria como nos filmes. É ler documentação disponível publicamente e seguir instruções. Um estudante universitário conseguia fazê-lo numa tarde.

O risco da Daraja do M-Pesa

É aqui que a situação se torna verdadeiramente perigosa.

Este sistema cobra as rendas pelo Paybill do M-Pesa. Isso significa que, algures no código, existe uma integração com a API Daraja: consumer keys, consumer secrets, URLs de callback e a lógica de processamento das transações.

Com o nível de exposição que eu estava a ver (modo debug, nenhum controlo de acessos, dependências desatualizadas), um atacante com paciência poderia:

• Aceder às credenciais da API: a consumer key e o consumer secret usados para autenticar junto da Safaricom
• Intercetar os URLs de callback: desviar as confirmações de pagamento para o seu próprio servidor
• Manipular os registos das transações: marcar pagamentos como recebidos quando não o foram, ou desviar fundos
• Recolher números de telefone: o M-Pesa está ligado aos números de telefone, e estes estão ligados ao dinheiro

A API Daraja do M-Pesa é segura em si mesma. A Safaricom construiu-a bem. Mas se o software que a integra estiver tão exposto, a segurança da API deixa de contar. É como ter um carro blindado a entregar dinheiro num edifício sem portas.

Porque escolhi a ética em vez da oportunidade

Vou ser honesto. Ao olhar para aquele sistema, via várias formas de o explorar. Só a falha de autenticação já tornava os registos dos inquilinos acessíveis. O modo debug exposto tornava legível a arquitetura do servidor. As dependências desatualizadas tornavam aplicáveis explorações conhecidas.

Não vou fingir que a ideia não me passou pela cabeça. O sistema estava praticamente aberto.

Mas não sou assim. Fechei os separadores.

Em vez disso, escrevi um e-mail à empresa a explicar exatamente o que tinha encontrado e como corrigir. Indiquei-lhes passos concretos:

• Desativar de imediato o modo debug
• Exigir autenticação em todos os URLs destinados aos inquilinos
• Atualizar a framework para corrigir as CVEs conhecidas
• Auditar a forma como guardam as credenciais da API Daraja
• Implementar controlo de acessos por funções

Espero que o corrijam.

Se não o fizerem, o meu próximo e-mail vai para o Office of the Data Protection Commissioner (ODPC). Porque isto não é só má engenharia: é uma violação da Kenya Data Protection Act, 2019 (Lei de Proteção de Dados do Quénia).

O que diz a lei: a KDPA 2019 do Quénia como exemplo

Muitos países africanos têm hoje leis de proteção de dados, e os pormenores variam de país para país. A do Quénia é a que este sistema violava: a Kenya Data Protection Act (2019) obriga quem recolhe dados pessoais a:

• Aplicar medidas de segurança adequadas para proteger os dados pessoais (Secção 41)
• Notificar o Comissário no prazo de 72 horas após tomar conhecimento de uma violação (Secção 43)
• Garantir que os dados não ficam acessíveis a pessoas não autorizadas (Secção 42)

Um sistema que expõe nomes, números de telefone e históricos de pagamento dos inquilinos sem qualquer autenticação está claramente em infração. O ODPC pode emitir notificações de cumprimento e aplicar coimas até KES 5 milhões ou 1% do volume de negócios anual.

Se é senhorio no Quénia e usa um software que trata dados de inquilinos, é o responsável pelo tratamento desses dados perante a lei. A negligência do seu fornecedor é responsabilidade sua. Seja onde for que tenha o seu imóvel, verifique como a lei do seu país trata os senhorios que guardam dados de inquilinos.

Como auditar o seu atual software de gestão de imóveis

Quer tenha desenvolvido o seu sistema, quer o tenha comprado ou use uma plataforma SaaS, faça estas perguntas:

1. Autenticação

• Alguém consegue aceder aos dados dos inquilinos sem iniciar sessão?
• Os URLs dos extratos dos inquilinos são fáceis de adivinhar ou sequenciais?
• Existe autenticação multifator?

2. Tratamento de erros

• O que acontece quando abre um URL errado no sistema?
• A página de erro mostra detalhes técnicos, caminhos de ficheiros ou código?
• Se mostrar uma página de erro «bonita», provavelmente está tudo bem. Se mostrar código, é um sinal de alarme.

3. Atualizações do software

• Quando foi a última atualização de segurança?
• O sistema tem manutenção ativa?
• Pergunte ao seu fornecedor: «Que versão da framework estão a usar?»

4. Controlo de acessos

• O seu encarregado do prédio consegue ver dados financeiros que não devia?
• Um inquilino consegue ver a informação de outro inquilino?
• Existe um registo de auditoria que mostre quem acedeu a quê?

5. Segurança dos pagamentos

• Como são guardadas as credenciais das APIs de pagamento (M-Pesa, PesaPal, o seu banco)?
• Os URLs de callback são validados?
• Os dados de pagamento são encriptados em repouso?

Como o HomeManager trata a segurança

Quando construí o HomeManager, a segurança não foi uma reflexão tardia nem uma funcionalidade a acrescentar mais tarde. Foi um princípio de conceção desde o primeiro dia. Porque já vi o que acontece quando não é.

Medida de segurança	O que significa
Nenhum acesso sem autenticação	Cada URL, cada endpoint, cada dado exige uma sessão iniciada válida. Sem exceções.
Encriptação AES-256 em repouso	Todos os dados guardados na base de dados estão encriptados. Mesmo que alguém ficasse com o disco, não os conseguiria ler.
TLS 1.3 em trânsito	Todos os dados que circulam entre o seu navegador e os nossos servidores são encriptados com o protocolo de transporte mais recente.
Controlo de acessos por funções (25 permissões)	Proprietários, gestores, contabilistas, encarregados e pessoal de manutenção veem apenas aquilo de que precisam.
Registo de auditoria completo	Todas as ações ficam registadas: quem fez o quê, quando e a partir de que endereço IP. Um registo inalterável.
Correção contínua das dependências	Nenhuma CVE conhecida na nossa infraestrutura de software. Dependências monitorizadas e atualizadas regularmente.
Integração M-Pesa protegida de ponta a ponta	Credenciais da API encriptadas, URLs de callback validados, dados das transações nunca expostos nos registos.
Infraestrutura AWS	Alojado na Amazon Web Services, com cópias de segurança automáticas, escalamento automático e 99.9% de disponibilidade.
Em conformidade com a KDPA 2019	Construído de raiz em conformidade com a Data Protection Act do Quénia.

Conclusão

Os seus inquilinos confiam-lhe os seus dados pessoais: nomes, números de telefone, números de identificação, histórico de pagamentos, detalhes do contrato de arrendamento. Em cada vez mais países africanos, essa confiança tem um nome legal: uma lei de proteção de dados. No Quénia, é a Data Protection Act 2019.

Se o software que trata esses dados não consegue responder a perguntas básicas de segurança, não tem um problema tecnológico. Tem um problema de responsabilidade legal.

Pergunte ao seu fornecedor atual: «O que acontece quando alguém escreve um URL errado?»

Se não gostar da resposta (ou se não lha souberem dar), talvez seja altura de mudar para algo construído com a segurança como alicerce, e não como funcionalidade.