Escalação de Privilégio no SAGRES via Manipulação dos Parâmetros idPessoa / perfil

Divulgação de uma vulnerabilidade. Reportada à TecnoTrends em outubro de 2024. Tornada pública em maio de 2026, após verificação da correção.

Bypass completo de autorização (leitura e escrita) em sistema autenticado, acessível pela rede, manipulando dados sensíveis de registro acadêmico.

O que é o SAGRES

O SAGRES é um sistema proprietário de gestão acadêmica composto por portal web, API mobile e aplicativos Android/iOS. É o sistema de registro de várias universidades brasileiras para matrícula, notas, frequência, conteúdo de aulas, mensagens internas e solicitações administrativas. A API mobile é uma API REST no estilo ServiceStack.

A vulnerabilidade

A API mobile do SAGRES autentica usuários via HTTP Basic Auth. Ocorre que, depois da autenticação, o servidor não verificava de forma consistente se os valores de idPessoa e perfil informados na requisição correspondiam de fato ao usuário autenticado. Ambos os parâmetros aparecem em URLs e corpos de requisição na maior parte dos endpoints de dados (/diario/aulas, /diario/faltas, /diario/recados, endpoints de notas, entre outros). Em uma parcela significativa desses endpoints:

• Substituir idPessoa pelo identificador de outro usuário retornava os dados desse usuário.
• Trocar perfil de 1 (aluno) para 2 (professor), e em alguns casos valores como 99, concedia acesso a campos e operações de escrita restritas a professores.

Em outras palavras, o servidor confiava no cliente para declarar quem ele era e qual papel ocupava a cada requisição, quando o único fato em que deveria confiar era o principal já autenticado por ele próprio.

A falha era atingível a partir de uma conta comum de aluno. Sem roubo de token, sem MITM, sem manipulação de sessão, apenas dois parâmetros de query.

Como a falha foi descoberta

O primeiro indício veio em 2018. Como aluno de Engenharia da Computação, ao explorar por que alguns endpoints retornavam dados diferentes em função do valor de perfil, percebi que alterá-lo de 1 (aluno) para 2, ou em alguns casos valores não relacionados como 99, fazia com que a API expusesse dados que eu não deveria conseguir ver, especialmente quando combinado com os parâmetros embutir e campos que o SAGRES disponibiliza publicamente.

A observação ficou guardada por anos. O retorno ao tema veio em 2024, em um contexto prosaico: eu estava trabalhando em melhorias de heurística e otimização na forma como o UNES (aplicativo mobile de código aberto desenvolvido por estudantes para alunos da UEFS, que consome a mesma API mobile do SAGRES) busca dados do servidor. No meio dessa instrumentação, me lembrei do comportamento estranho do perfil que tinha visto em 2018 e decidi olhar com mais rigor até onde ele ia.

A escalação foi gradual. Primeiro substituí apenas o idPessoa por o de outro aluno e confirmei que o servidor retornava os dados desse aluno. Em seguida tentei o mesmo com o id de um professor e observei como a camada cliente reagia às respostas; vinham limpas, com todos os campos de escopo privilegiado preenchidos.

Foi nesse ponto que decidi parar de improvisar requisições por conta própria e adotar uma abordagem menos arriscada para investigar a superfície de escrita: em vez de tentar reproduzir as chamadas a partir do zero (com o risco evidente de montar um POST mal-formado e, sem querer, de fato alterar algo que eu não pretendia), patcheei uma cópia do aplicativo oficial da TecnoTrends para aceitar, no momento do login, a identidade que eu quisesse. A build alterada aceitava o nome de usuário no formato usuario:<id> junto com a minha senha real; o cliente fazia o login autenticado normalmente e, somente depois da autenticação ter sucesso no servidor, substituía a identidade armazenada localmente pelo id que vinha após os dois pontos. Como o aplicativo deles já tem todos os endpoints corretamente mapeados e sabe a forma exata de cada chamada, ele próprio cuidava de montar requisições bem-formadas; a minha modificação só interferia em qual identidade ele assumia em seguida.

Isso confirmou a falha: o servidor servia dados e aceitava escritas para qualquer identidade que o cliente passasse a apresentar, contanto que o cliente já tivesse um login válido de algum usuário. Ao substituir o id por o de um professor, eu obtinha controle total sobre as aulas, notas e faltas de todas as turmas associadas àquele professor. O bypass também se estendia a endpoints de coleção de escopo amplo (por exemplo, aproveitamento-alunos), em que a manipulação combinada de embutir e perfil ampliava ainda mais a superfície.

A capacidade de escrita foi verificada com consentimento explícito: um professor da UEFS concordou em ter sua turma usada como ambiente de teste, permitindo demonstrar que o bypass deixava uma sessão de aluno alterar registros de aula e frequência sob a conta dele. Deliberadamente não testei a alteração de notas mesmo com consentimento; a fronteira entre teste de segurança autorizado e fraude acadêmica é fina demais para arriscar atravessá-la, e a confirmação dos demais vetores de escrita já era suficiente para caracterizar o impacto.

Impacto

Enquanto a falha esteve em produção:

• Confidencialidade: qualquer conta de aluno podia enumerar e ler o histórico acadêmico de todos os alunos da instituição, além de dados internos de docentes.
• Integridade: qualquer conta de aluno podia alterar notas, frequência e conteúdo de aulas como se fosse o professor titular de qualquer turma. A instituição não teria como distinguir, retrospectivamente, uma alteração forjada de uma legítima; ambas apareceriam como mutações autenticadas no sistema.
• Multi-instalação: o SAGRES é instalado em diversas universidades brasileiras. A vulnerabilidade estava na plataforma em si, não na configuração de uma instituição específica, o que significa que toda a base de clientes do SAGRES esteve potencialmente exposta enquanto a versão vulnerável esteve em uso.

Para um sistema acadêmico, esta é a pior classe de bug que existe. Não é um vazamento; é a ruína completa do modelo de autorização do sistema, incluindo as garantias de integridade nas quais diplomas e históricos escolares se apoiam.

Linha do tempo da divulgação

Resposta da empresa

Cinco dias após o reporte, o CEO da TecnoTrends respondeu. A íntegra do e-mail:

“Caro João Paulo,

Meu nome é Ricardo Nery e sou diretor executivo da TecnoTrends.

Recebi da área comercial seu e-mail abaixo.

A fim de lhe passar maiores informações, preciso, por favor, saber a sua instituição, desconfio que seja a UEFS, e se o problema referido se refere ao portal de aplicações ou ao aplicativo mobile.

Explico..

Segundo o setor de tecnologia a fragilidade apontada foi realmente encontrada na API do Mobile devido a uma alteração indevida feita voltada ao ensino básico no sentido de permitir pais e responsáveis terem acesso as informações dos seus alunos.

Contudo, tal fragilidade não foi detectada no portal de aplicações.

Como em seu e-mail há uma série de referências expressas ao PORTAL, ficamos sem entender se é uma fragilidade que não detectamos ou a referência feita em seu e-mail diz, em verdade, ao aplicativo mobile já que estamos enfrentando um ataque de engenharia reversa feita através da plataforma Android, algo bem conhecido na área de segurança de aplicativos, que expõe a API.

Até onde investigamos, a API está sendo utilizada por um aplicativo desenvolvido pelos alunos de Computação chamado UNES.

Mas este é um assunto que estamos tratando internamente com o corpo técnico da UEFS.

Fico no aguardo da suas considerações.

Grato!”

O CEO confirmou a existência da vulnerabilidade na API mobile e atribuiu a regressão a uma funcionalidade adicionada para permitir que pais e responsáveis acessassem informações de seus filhos no contexto do ensino básico.

A mesma resposta também caracterizou o trabalho como “um ataque de engenharia reversa feito através da plataforma Android”, realizado via “um aplicativo desenvolvido pelos alunos de Computação chamado UNES.” Vale registrar com clareza: o UNES é um cliente mobile estudantil de código aberto que consome a mesma API pública que qualquer outro cliente do SAGRES consome. A vulnerabilidade era um defeito de autorização do lado do servidor; a engenharia reversa do aplicativo oficial revelou a falha, mas não a criou. Uma falha em uma API pública é uma falha, independentemente de alguém ter ou não decompilado o APK do fornecedor.

Por que isso pôde acontecer

A causa raiz, segundo o próprio fornecedor, foi uma alteração feita para um caso de uso pontual (pais e responsáveis acessando registros dos filhos no ensino básico) que afrouxou a verificação de identidade da qual o restante da plataforma dependia. É um padrão familiar em sistemas monolíticos com autorização por rota fraca: uma flexibilização, feita para uma única funcionalidade, vira um bypass transversal em todo o sistema.

De forma mais simples: a única identidade em que um servidor de API deveria confiar é aquela que ele próprio autenticou. No momento em que um endpoint aceita um idPessoa ou perfil declarado pelo cliente e o utiliza para decidir autorização, já há uma vulnerabilidade, antes mesmo de alguém explorá-la.

Recomendações

Para instituições que usam o SAGRES:

• Confirmem por escrito com a TecnoTrends que sua instalação recebeu o patch pós-2024.
• Considerem auditoria retroativa dos logs de acesso para identificar leituras ou escritas de escopo administrativo originadas a partir de contas não administrativas no período anterior à correção.
• Avaliem que controles a instituição teria, hoje, para detectar adulteração retroativa de registros de notas caso uma falha similar volte a ocorrer.

Para a TecnoTrends:

• Estabeleçam um endereço security@ e uma política pública de divulgação coordenada de vulnerabilidades. Direcionar reportes de segurança para comercial@ introduz fricção e risco evitáveis para pesquisadores.
• Tratem reportes de pesquisadores como sinal, não como “ataques”. O enquadramento usado na resposta de 2024 é uma postura de comunicação; a realidade técnica é que um pesquisador com login de aluno poderia ter reescrito o histórico de qualquer aluno em qualquer universidade que rodasse o software de vocês, e uma divulgação subsequente em boa-fé é o desfecho mais favorável que vocês poderiam ter obtido.

Para a comunidade brasileira de tecnologia educacional:

• Plataformas acadêmicas proprietárias que processam registros sensíveis sob a LGPD deveriam estar sujeitas às mesmas expectativas de revisão independente de segurança, divulgação coordenada e atribuição de CVE que regem o restante do setor.

Agradecimentos

Ao docente da UEFS que levou meu reporte a sério e o escalou internamente antes de eu reunir coragem para escrever direto à empresa. À administração da UEFS, por tratar o assunto com a seriedade que ele merecia. Ao professor que consentiu em ter sua turma usada como ambiente de teste para confirmar o vetor de escrita. À TecnoTrends pela correção.

Sobre o tempo decorrido

Esperei 18 meses entre o reporte e a divulgação. É bem mais do que os 90 dias que viraram norma na indústria. Esperei porque queria certeza razoável de que a correção tinha sido implantada e mantida, e porque sou identificável: sou ex-aluno de uma das instituições afetadas e mantenho o aplicativo UNES, citado nominalmente na resposta da empresa. A discrição foi precaução contra retaliação, não cortesia ao fornecedor.

A correção do bypass específico está em produção e foi confirmada. A instituição está informada. O fornecedor teve toda a oportunidade razoável de coordenar. A divulgação agora serve à comunidade mais ampla: outras instituições que rodam o SAGRES, a comunidade de pesquisa em segurança no Brasil, e qualquer pessoa que venha a se ver, no futuro, com uma descoberta semelhante e a mesma incerteza sobre se publicar é seguro.

João Paulo Sena