Quando a divulgação responsável não é suficiente
moonpig é uma empresa de cartões bem conhecida no Reino Unido. Você pode usar seus serviços para enviar cartões personalizados para seus amigos e familiares. [Paul] decidiu fazer alguns cavando e descobriu algumas vulnerabilidades de segurança entre o aplicativo android do Moonpig e sua API.
Primeiro de tudo, [Paul] notou que o sistema estava usando a autenticação básica. Isso não é ideal, mas a empresa foi pelo menos usando criptografia SSL para proteger as credenciais do cliente. Depois de decodificar o cabeçalho de autenticação, [Paul] notou algo estranho. O nome de usuário e senha sendo enviados com cada solicitação não eram suas próprias credenciais. Seu ID de cliente estava lá, mas as credenciais reais estavam erradas.
[Paul] criou uma nova conta e descobriu que as credenciais eram as mesmas. Ao modificar o ID do cliente no pedido HTTP de sua segunda conta, ele foi capaz de enganar o site para cuspitar todas as informações de endereço salvas de sua primeira conta. Isso significava que não havia realmente autenticação. Qualquer usuário pode representar outro usuário. Puxar informações de endereço pode não parecer um grande negócio, mas [Paul] afirma que todo pedido de API era assim. Isso significava que você poderia ir tão longe quanto colocação de pedidos sob outras contas do cliente sem o seu consentimento.
[Paul] usou arquivos de ajuda da API da Moonpig para localizar métodos mais interessantes. Um que se destacou para ele era o método GetCreditCardDetails. [Paul] deu um tiro, e com certeza o sistema despejou detalhes do cartão de crédito, incluindo os últimos quatro dígitos do cartão, data de validade e o nome associado ao cartão. Pode não ser números de cartão completos, mas isso ainda é obviamente um grande problema que seria corrigido imediatamente … certo?
[Paul] divulgou a vulnerabilidade responsável ao moonpig em agosto de 2013. Moonpig respondeu dizendo que o problema era devido ao código legado e seria fixado imediatamente. Um ano depois, [Paul] seguiu com o MoonPig. Ele foi dito que deveria ser resolvido antes do Natal. Em 5 de janeiro de 2015, a vulnerabilidade ainda não foi resolvida. [Paul] decidiu que o suficiente foi o suficiente, e ele também poderia publicar suas descobertas on-line para ajudar a pressionar o problema. Parece ter funcionado. O MoonPig desabilitou desde a sua API e lançou uma declaração via Twitter alegando que “todas as informações de senha e pagamento são sempre seguras”. Isso é ótimo e tudo, mas significaria um pouco mais se as senhas realmente importassem.