No momento, existem tantos tipos de vulnerabilidades que os desenvolvedores esquecem completamente as elementares. No outro dia, consegui ignorar a autorização no novo aplicativo WOG (TOV "VOG RETAIL" - a segunda maior rede de postos de gasolina da Ucrânia). Em 2017, encontrei exatamente a mesma vulnerabilidade na aplicação de um dos provedores móveis da Ucrânia (também o segundo maior). Situações idênticas - uma nova aplicação e falta de proteção contra força bruta.
Há pouco tempo, recebi uma notificação - a empresa lançou um novo aplicativo e oferece a instalação. Sinceramente, gostei da funcionalidade do aplicativo - visualizar bônus na conta para a qual você pode comprar combustível. A capacidade de anexar um cartão bancário e pagar por mercadorias sem contato ou pelo código QR. O perfil também exibe meu nome e detalhes de contato, um histórico completo de transações - uma lista de mercadorias e seu valor no momento da compra.
A autorização no aplicativo ficou mais fácil - agora você não precisa digitar o número do cartão de fidelidade, basta especificar o número do celular. No entanto, mesmo na entrada, eu suspeitava que alguém pudesse ver meus dados - especialmente, mais de 5 vezes, digitei um código diferente do que recebi no SMS. Porque - Como anteriormente, em um aplicativo semelhante a uma operadora de celular, encontrei uma vulnerabilidade que dava acesso total ao gerenciamento da conta de um assinante.
Ao inserir o código incorreto, foi possível descobrir que a proteção contra força bruta provavelmente não é.
Eu estava certo - o aplicativo não tem proteção. Você pode acessar qualquer conta e, além disso, "seqüestrar" sua conta - vincule-se a outro número, gaste os fundos de outras pessoas.
Tive a impressão de que os desenvolvedores de aplicativos esquecem completamente que o tráfego de rede não é difícil de interceptar, mesmo solicitações https.
Pessoalmente, uso o programa violinista - essa ferramenta possibilita o proxy de tráfego, o visualiza ou altera. Para acessar o conteúdo das solicitações https, além das configurações de proxy, nas propriedades de conexão do smartphone, você deve instalar adicionalmente o certificado confiável gerado pelo programa.
Antes de tudo, fiquei satisfeito com a auto-estima dos desenvolvedores do aplicativo - a API que usa o aplicativo está localizada no domínio
bestb4app .wog.ua. Apenas examinando as URLs, eu pude descobrir que o
IIS 7.5 e
1C: Enterprise 8 vivem no servidor, bem como uma imagem do cabeçalho (talvez os fãs do Machinarium tenham escrito a API?).
O esquema de autorização é simples - uma solicitação com uma "solicitação" para enviar um código ao SMS voa para um dos
métodos da API. E aqui a primeira vulnerabilidade é a ausência de limites. No mesmo número de telefone, a partir de um IP, você pode "pedir" quantos SMS desejar.
Mais tarde, nas propostas da empresa, encontrei
informações de que eles planejam enviar até 1.000.000 de SMS por mês (eles estão prontos para gastar ~ US $ 98.000 nisso por um ano). Acontece que a vulnerabilidade pode causar à empresa perdas de ~ US $ 8.200 por dia, se 12 solicitações forem enviadas por segundo.
É importante notar que, para o servidor processar solicitações corretamente, é necessária
uma autorização básica - este é um dos métodos de proteção que os desenvolvedores usaram. Porque Não está claro - não vejo sentido - interceptar o
login / senha ou o cabeçalho http necessário não é um problema.
Depois que o usuário recebeu o SMS e inseriu o código no aplicativo, ele envia uma
solicitação para verificar a confiabilidade do código e receber um token. A próxima e mais crítica vulnerabilidade estava aqui - não há proteção contra força bruta. A seleção de um código, que consiste em 4 (!) Dígitos, não requer muito tempo.
Após receber o token, você pode usar outros métodos de API. Uma delas permite alterar o código PIN do cartão de fidelidade. O procedimento é padrão - digite o PIN antigo, digite um novo. Quero me concentrar nesse método, porque aqui o desenvolvedor usou outro método de "proteção" inútil. Naturalmente, também não havia proteção contra a força bruta, mas o pino antigo foi enviado em forma oculta. A idéia é boa - apenas classificar as combinações 0000-9999 falhará. A implementação está ruim - em vez do código, um hash md5 é enviado. Sem substituições de sal ou qualquer outra coisa.
Honestamente, não tenho idéia de como acessar o código do aplicativo e se isso é possível - portanto, mesmo o md5 desatualizado me impediria se o sal fosse usado.
Também consegui não apenas forçar brutalmente um token para uma conta "estrangeira", mas também inseri-lo no aplicativo - escrevi um pequeno script no node.js que fazia proxy de tráfego e substituía apenas as respostas do método gettoken.
O artigo foi escrito depois de conversar com o "diretor adjunto do departamento de TI" da empresa. Os caras reagiram rapidamente - consegui contatos para comunicação em 24 horas. Enviei uma descrição das vulnerabilidades e uma pergunta sobre a presença de recompensas por bugs.
Em resposta, recebi uma carta com informações que supostamente foram "descobertas" - "
Vimos você (380958302 ---) imediatamente e os bloqueios funcionaram ... Não vou contar sobre todos os bloqueios, mas muitos deles apareceram ontem "
Quanto a mim, parece mais geada - pois, como respondi a esta carta, “a
piada é que esse número não me é familiar. Eu testei nos números 095866 ... "
Ao contrário da empresa WOG, o chefe do departamento de segurança da informação da operadora de telefonia móvel era muito mais comunicativo e montou um smartphone como agradecimento =)