Bem antes das I.A.s surgirem com seu vibe-coding mágico, o "poder" de criar soluções em forma de software costumava estar nas mãos de programadores. E isso era vez ou outra romantizado em filmes.
Nosso personagem acreditava nisso, tanto que tinha tal capacidade criativa mas sempre lhe faltava as habilidades de vendedor. O primeiro cliente pra quem vendeu um site até tentou o ajudar, inclusive emprestando um livro de vendas mas ele não ouviu os conselhos e optou for focar no desenvolvimento das habilidades compatíveis com a função.
Por isso, sempre buscou seu parceiro, ou parceira, de vendas. A pessoa-chave que venderia a solução e os lançaria na brincadeira. Tentou algumas vezes: irmão, esposa, amigo, amigos até que surgiu um cara boa pinta, multi-empresário bem sucedido.
Acreditou que tinha encontrado a componente faltante pra receita do sucesso, o cara do negócio e das vendas. Então, sem perder muito tempo, abriu o jogo e mostrou toda a ideia com grande potencial: plano de ação, key-features, branding, tudo para o novo app de mobilidade. Na época basicamente uma unica opção dominava o mercado e quase não tinha concorrência.
"Entrega já!" era o nome.
O sujeito se demonstrou bastante interessado e aceitou a oferta de sociedade. Além do capital, cuidaria do marketing e demais operações de vendas.
Le coup
Após uns dias de trabalho no MVP e apresentadas as necessidades de compras (expandir equipe e etc) um problema novo surgiu: "Entrega lá!" - o abençoado havia contratado uma empresa de SC para desenvolver o projeto. ( E pqp, nem pra disfarçar um pouco com o nome...) 🤡
A raiva de ser feito de trouxa serviu como lenha na fogueira da sua vingança e ele logo tratou de ir atrás da sua vitória.
Descobriu a empresa que havia vendido o software e o valor, na época: R$ 6.000,00.
Desenvolvido em PHP puro, sem nenhum framework, a API do aplicativo tinha mais falhas que recursos.
Logo de cara encontrou um IDOR 1 no endpoint de usuários. O primeiro usuário cadastrado, com ID 1, era o admin. Depois disso, pôde listar todas as informações dos usuários: endereço completo, dados pessoais e etc. Por sorte, o sistema não gerenciava pagamentos, entao não havia dados de cartão de credito armazenados.
Le contrecoup
Em seguida, tentou o que talvez tivesse sido o ponto de entrada de qualquer pentester ou hacker: SQLinjection 2 no formulário de login. Advinha? Totalmente vulnerável!
Voilà! O sistema era dele!
A partir dali, ele poderia:
- exfiltrar os dados do sistema todo;
- promover o caos total no sistema com pedidos falsos e bagunça em informações;
- deixar a plataforma toda indisponível com ataques de DoS 3;
- e até mesmo comprometer todo o servidor com um ataque de RCE 4!
Coup de grâce?!
Seus dedos se apressaram em encontrar as teclas e digitar. Mas, ao invés de elaborar um ataque e o executar, tratou de gerar um relatório.
Entrou em contato com a fabrica de software, se apresentando e listando os problemas encontrados. Em vão! A ignorância e prepotência do gestor foram como um balde de agua fria.
Mais uma vez, aquele serzinho no seu ouvido esquerdo tentou convence-lo a tocar o terror:
- "Ladrão que rouba ladrão, tem sete anos de perdão!" - dizia...
Mas ele não flertava com um "emprego" que envolvesse ser acordado logo depois das 05h pela PF. E, sim, uma hora ou outra quem faz besteira acaba sendo pego. Por melhor que seja o hacker...
Além do mais, ética é sobre agir de forma correta independente da situação e, basta uma ação errada para manchar toda uma história correta.
Du coup
Resultado? Deixou tudo como estava e o caso se converteu em "mais um CD debaixo da cama"...
O "Entrega lá!" não durou muito: em poucos meses o aplicativo havia sumido da Play Store e o domínio não mais apontava para um IP.
Depois disso, sequer pesquisou sobre a empresa que desenvolveu a plataforma. Pode ser que, em algum lugar da internet, um app de "mobilidade" cheio de falhas ainda expõe seus usuários. Mas isso não é problema dele.
"A vingança nunca é plena, mata a alma e a envenena." - Seu Madruga
Notas
- OWASP: Referência Direta Insegura a Objeto (IDOR) A Referência Direta Insegura a Objetos (IDOR) é uma vulnerabilidade que surge quando atacantes conseguem acessar ou modificar objetos manipulando identificadores usados em URLs ou parâmetros de uma aplicação web. Isso ocorre devido à ausência de verificações de controle de acesso, que não conseguem verificar se um usuário deve ter permissão para acessar dados específicos.
- OWASP: Injecao de SQL (SQLi) Um ataque de injeção de SQL consiste na inserção ou "injeção" de uma consulta SQL através dos dados de entrada do cliente para a aplicação. Uma exploração bem-sucedida de injeção de SQL pode ler dados sensíveis do banco de dados, modificar dados do banco de dados (inserir/atualizar/excluir), executar operações administrativas no banco de dados (como desligar o SGBD), recuperar o conteúdo de um determinado arquivo presente no sistema de arquivos do SGBD e, em alguns casos, emitir comandos para o sistema operacional. Ataques de injeção de SQL são um tipo de ataque de injeção, no qual comandos SQL são injetados na entrada do plano de dados para afetar a execução de comandos SQL predefinidos.
- OWASP: Negação de Serviço (DoS) O ataque de Negação de Serviço (DoS) tem como objetivo tornar um recurso (site, aplicativo, servidor) indisponível para a finalidade para a qual foi projetado. Existem muitas maneiras de tornar um serviço indisponível para usuários legítimos, manipulando pacotes de rede, explorando vulnerabilidades de programação, lógica ou gerenciamento de recursos, entre outras. Se um serviço receber um número muito grande de solicitações, ele poderá deixar de estar disponível para usuários legítimos.
- CloudFlare: Execução Remota de Código (RCE) Um ataque de execução remota de código (RCE) é quando um invasor executa um código malicioso nos computadores ou na rede de uma organização. A capacidade de executar códigos controlados pelo invasor pode ser usada para várias finalidades, incluindo a implantação de malware adicional ou o roubo de dados confidenciais