Por que um SDK de código fechado é essencial para combater fraudes - AppsFlyer (Portuguese)
7 Min. Read

Por que um SDK de código fechado é essencial para combater fraudes

Michel Hotoveli Michel Hotoveli Aug 27, 2019

Em uma fala famosa de um de seus stand ups, Chris Rock disse que “não há investimento na cura, apenas no remédio.“. Ele se referia às grandes empresas farmacêuticas, que supostamente têm mais interesse em fornecer medicamentos para tratar os sintomas do que em encontrar curas reais para as doenças. Chris Rock ironizou que as empresas farmacêuticas preferem manter os clientes sempre voltando do que de fato curá-los.

Embora eu não tenha certeza de como funciona a estrutura econômica de uma empresa farmacêutica, isso faz sentido economicamente e não estritamente no que se refere a fabricantes de medicamentos. 

Ao examinar a economia de hoje, empresas multibilionárias e de capital aberto são obrigadas a mostrar lucro e crescimento, e muitas delas oferecem soluções e serviços para os “problemas” e “doenças” da vida moderna.

Com exceção de certas indústrias, é possível aplicar essa lógica à indústria de publicidade on-line e à “doença” que a assola – a fraude. Os últimos anos mostraram não só o crescimento de esquemas de fraude e a facilidade de operação destas , mas também uma consciência crescente da fraude e suas implicações sobre os anunciantes e editores. Voltando à economia básica: quando há crescimento da demanda, também há crescimento da oferta. Assim, com o aumento da conscientização sobre fraudes, novas empresas aproveitaram a ocasião e surgiram para oferecer soluções first-party e de terceiros para combater a fraude.

Como entidades financeiras, essas empresas podem diferir em preço, mensagem, percepção e tipo de solução, mas as mesmas perguntas ainda se aplicam a todos: será que elas realmente fariam tudo para eliminar sua principal fonte de renda? Existe demanda por soluções de prevenção de fraudes em um mundo sem fraude?

Pense bem nessa caça de gato e rato que é a prevenção à fraude para responder à pergunta acima e procure as brechas que uma parte deixaria para a outra para se manter no mercado. Elas podem ser pequenas, mas certamente estão lá. Isso pode ser tão simples quanto oferecer serviços pagos às partes interessadas de ambas as pontas (anunciantes e parceiros) – e potencialmente prejudicar a natureza imparcial necessária para eliminar as fontes fraudulentas.

Por exemplo: os fornecedores de soluções contra fraudes podem depender dos negócios gerados por uma determinada parte ou entidade (de ambos os lados) que, por sua vez, pode danificar seu raciocínio e intenções quando confrontados com uma decisão comercial sobre um caso de fraude que afeta potencialmente seus negócios em comum.

Nessa observação, também é importante examinar onde seu provedor de soluções de fraude está situado na cadeia de entrega de anúncios, mesmo quando não é imparcial. 

Um alerta mais importante que eu gostaria de fazer é a dependência de uma solução de SDK de código aberto na base do pacote de prevenção de fraudes.

 

Por que o código aberto não pertence à sua solução de fraude

Alguns fornecedores de soluções contra fraudes podem se orgulhar do uso da tecnologia de código aberto como parte de sua configuração de prevenção de fraudes. De fato, muitas ferramentas on-line usam código aberto para fornecer uma solução melhor, pois isso se encaixa na visão e operação de sua solução. Wikipedia, Google e Adobe são apenas alguns dos grandes nomes que usam código aberto para aproveitar os muitos benefícios permitidos pela iniciativa da comunidade de melhorar e desenvolver melhores produtos juntos.  

As soluções de código aberto são realmente excelentes, no entanto, juntamente com seus muitos benefícios, uma grande falha se torna aparente ao discutir segurança e proteção em relação a fraudes. 

Embora uma solução de código aberto a torne transparente e disponível para revisões e aprimoramentos, também se torna mais suscetível a engenharia reversa e manipulações. Isso seria como investir no sistema de segurança mais avançado para sua casa, mas depois deixar sua porta da frente destrancada. 

Mais propensas a violações de segurança de diferentes tipos, as soluções de atribuição baseadas em SDKs de código aberto deram origem a um novo tipo de fraude: falsificação de SDK.

A falsificação do SDK refere-se a instalações com aparência legítima, geradas por fraudadores sem que ocorram instalações reais. Isso significa orçamentos de publicidade indo por água abaixo e dados de segmentação enganosos, causando efeitos a longo prazo em atividades futuras e na alocação de orçamento.

Um fraudador que está tentando imitar a atividade de um SDK com o objetivo fazer hijacking com a atribuição para verba de publicidade precisa apenas dar uma olhada no código, investir um pouco em engenharia reversa para, então, ter esse acesso. O fraudador agora pode entender a lógica do sistema de mensagens HTTP com muito mais facilidade, ver como cada valor de campo é coletado e, em seguida, usar a solicitação HTTP em seu benefício.

 

A maior parte da discussão sobre falsificação do SDK se concentra em ataques de rede como MITM (do inglês, “o homem no meio”) ou Replay, mas esse é apenas um ponto em que os dados do SDK podem ser falsificados. Os dados podem ser coletados, manipulados e falsificados antes mesmo de serem enviados pela rede. Existem muitas ferramentas para análise e instrumentação dinâmicas, permitindo monitorar e manipular quaisquer dados no aplicativo atacado antes de serem enviados para o back-end (durante o tempo de execução do aplicativo).

O uso correto dessas ferramentas permite que os fraudadores manipulem os dados que desejarem, deixando intactos os mecanismos de “proteção” da rede (leia-se: os dados de back-end aparecem como legítimos e “assinados”). É importante observar que qualquer software (de código aberto ou não) pode ter engenharia reversa; os fornecedores de software que alegam o contrário não têm conhecimento dos riscos que enfrentam, são ingênuos ou as duas coisas.

A pergunta é: o que essas empresas estão fazendo para proteger seu software contra tentativas de ataques?

 

Como isso tem relação com o código aberto

  • O código aberto torna o processo de hacking mais rápido e mais barato – os fraudadores sabem exatamente como os dados são coletados e empacotados dentro do SDK, o que faz com que seja significativamente mais fácil encontrar o local onde os dados podem ser falsificados para criar uma “fraude de qualidade”.
  • Qualquer mecanismo de proteção contra esse tipo de fraude é claramente visível e pode ser contornado. Manter a lógica do SDK em segredo significa que os fraudadores precisarão investir em muito mais recursos para engenharia reversa.
  • Nas soluções de código aberto, os mecanismos criptográficos implementados no código são expostos e podem ser estudados ou facilmente revertidos.
  • Ao lidar com código aberto, a responsabilidade de proteger o software recai amplamente sobre o cliente – se o cliente não tomar todas as medidas necessárias para proteger seu código-fonte, ele será inerentemente mais fácil de entender, reverter e manipular.

A proteção contra o MITM, se implementada da maneira correta, pode realmente impedir o roubo de dados pessoais em redes remotas (um cenário em que os hackers tentam roubar informações privadas entregues pela rede a partir de um local remoto).

Mas este caso é diferente. A forma como se protege o SDK e o autentica no servidor é crucial, pois os fraudadores desejam gerar tráfego que parece ser legítimo. Nesse caso, tudo o que eles precisam é acessar o aplicativo para o qual desejam gerar tráfego e ter o conjunto de ferramentas correto. O código do aplicativo pode ser modificado, mesmo no nível do sistema operacional, para gerar tráfego falso para atender às necessidades do fraudador.

A proteção MITM fica completamente sem sentido.

Cada uma dessas violações pode ser solucionada quando detectada, mas exigirá atualizações urgentes do SDK pelo proprietário do aplicativo, independentemente da atualização original ou do cronograma de lançamento do recurso. Isso significa que os proprietários de aplicativos correm o risco de entrar em um ciclo caro, frustrante e demorado de investir recursos de engenharia adicionais, enquanto seu SDK ainda está em aberto para o próximo esquema acontecer… e assim o ciclo continua.

 

Lições-chave

Fraude não tem graça.

Ela acaba com os orçamentos de publicidade e alimenta fontes ilegítimas que farão o possível para encontrar a próxima brecha na segurança. Como profissionais de marketing responsáveis, devemos adotar uma abordagem mais cuidadosa e avaliar os benefícios de quaisquer soluções de proteção contra fraude que estamos usando. Apenas se inscrever em um provedor de soluções e acreditar que estamos seguros não é suficiente.

Ao discutir fraude, nenhuma solução é perfeita; o trabalho para acabar com os fraudadores é longo e complexo. Quanto mais empresas participarem dessa batalha, melhor, mas devemos parar e perguntar se estamos aqui com as intenções e o arsenal certos.  

Na AppsFlyer acreditamos em oferecer uma solução de prevenção altamente eficiente para qualquer coisa, desde o hijacking de atribuição até usuários falsos gerados por bots.

Como parte do compromisso da AppsFlyer para combater a fraude de publicidade móvel, o SDK da AppsFlyer aplica as melhores ferramentas no mercado para proteger seu código de engenharia reversa. O Protect360, solução de proteção de fraude da AppsFlyer, usa ofuscação sofisticada e criptografia em suas fontes de código e é o mais avançado conjunto de proteção de fraude de publicidade móvel disponível.  

 

 

Agende sua demonstração do Protect360 hoje mesmo