DigiLocker é uma loja on-line digital, onde o governo nos permite armazenar dados e arquivos digitalmente. Porém, recentemente, um especialista em segurança descobriu uma nova vulnerabilidade no DigiLocker que comprometeu mais de 3,8 milhões de contas.
É uma falha de autenticação que colocou em risco o núcleo dos dados dos usuários. Inicialmente, esse problema foi identificado pela primeira vez por um pesquisador de segurança Ashish Ghalot no mês passado e sobreviveu no método de entrada do serviço.
Esse tipo de vulnerabilidade ajuda os hackers a evitar a autenticação de dois fatores e obter acesso a algumas informações privadas delicadas dos usuários, mas agora a falha já foi determinada e corrigida.
Bem, Ashish Ghalot havia encontrado a falha no DigiLocker quando ele estava analisando o mecanismo de autenticação. Além disso, ele também afirmou que obteve o mecanismo padrão, que solicita uma senha de uso único (OTP) e um PIN para efetuar login no armazenamento digital.
Depois de obter o OTP, ele foi capaz de burlar o mecanismo de autenticação depois de colocar um número Aadhaar e impedir o link para o DigiLocker, simplesmente modificando os parâmetros.
Incluindo mais de 38 milhões de usuários registrados, o DigiLocker é um armário baseado em nuvem que serve como plataforma digital para ajudar no processamento on-line de vários registros e no desempenho mais rápido de diferentes assistência de governo a cidadão. Mais importante, o DigiLocker está conectado ao número de celular de um usuário e ao Aadhar ID (um número de identidade exclusivo (UID) atribuído a todos os cidadãos da Índia).
Além de Ashish Ghalot, outros especialistas em segurança também investigaram essa vulnerabilidade do DigiLocker, e também encontraram a principal razão por trás dessa falha e esclarecerão tudo em breve.
Constatações
Em 10 de maio, o pesquisador de segurança, Ashish Ghalot, resumiu todas as suas descobertas no CERT-IN, e o problema foi determinado em 28 de maio. Aqui estão as análises detalhadas descobertas pelo Ashish Ghalot neste evento:
- Desvio de OTP devido a falta de autorização - Marcado como crítico
- Ignorar / aquisição secreta de PIN - Marcado como crítico
- Mecanismo de sessão ruim nas APIs - marcado como alto
- Mecanismo de fixação SSL fraco no aplicativo móvel - Marcado como Médio
1. Desvio de OTP devido à falta de autorização
A primeira descoberta é o desvio do OTP devido à falta de autorização, e a falta de autorização torna a situação mais confortável para o invasor. E fica fácil implementar a validação do OTP, apresentando os detalhes de qualquer usuário válido e, em seguida, o fluxo de manipulação para efetuar login como um usuário completamente distinto.
2. Desvio / aquisição secreta de PIN
Em seguida, temos o segredo PIN Bypass / takeover, bem, é uma das falhas, que também é marcada como descoberta crítica. Como qualquer pino de API / URL, ajuda facilmente os hackers a redefinir um pino totalmente novo de qualquer usuário sem autenticação. Em suma, é uma das maneiras mais fáceis de comprometer os dados do usuário, e é por isso que eles foram marcados como críticos.
3. Mecanismo de sessão ruim nas APIs
Depois disso, temos o 'mecanismo de sessão ruim nas APIs', é uma das descobertas marcadas como altas. E nessa descoberta, você perceberá que as chamadas de API do celular estavam utilizando autenticação primária para recuperar quaisquer dados ou realizar transações procuradas.
Mais importante, todas as chamadas são criptografadas, o que implica que todos os usuários devem apresentar suas credenciais, em um formato básico de autenticação que também é criptografado com o algoritmo: AES / CBC / PKCS5Padding.
4. Mecanismo de fixação SSL fraco no aplicativo móvel
Por fim, temos o pobre mecanismo de fixação SSL no aplicativo móvel e, nessa descoberta, o aplicativo usa a fixação SSL fraca, que pode ser ignorada com eficiência em dispositivos como Frida e também em alguns métodos reconhecidos.
De acordo com o Digilocker, a essência da vulnerabilidade era tão forte que a conta DigiLocker de um indivíduo provavelmente poderia ser arbitrada se o invasor percebesse o nome de usuário dessa conta apropriada. Portanto, a falha foi abordada nos dados de preferência e a equipe técnica começou a receber um alerta do CERT-IN.
