Validação do Similarity-Seeker após Autenticação Manual 138

6.3.1 Validação do Similarity-Seeker após Autenticação Manual

Na verdade, a validação do algoritmo Similarity-Seeker não era muito o objetivo desta pesquisa, já que o mesmo já havia sido validado e atestado em bancas e pesquisas anteriores (METWALLY, AGRAWAL, ABADDI, 2007), inclusive com cargas de testes bem superiores à realizada por esta pesquisa. No entanto, diante do cenário exposto na seção 6.3.1, decidimos extrapolar a carga de testes anteriormente realizada para validar também o cenário modificado que apresentamos.

Os cliques duplos seguem um ciclo de identificação muito simples do Similarity- Seeker e são o grau mais simples de similaridade existente, como já descrevemos. O algoritmo simplesmente considera cliques duplos como erro do usuário e os desconsidera para questões de contabilidade. Ao ajustarmos aspectos de ruído, imediatamente cerca de 25% dos cliques foram identificados como fraudulentos. No entanto, a busca de similaridades não parou por aí.

É interessante notar que quando l, ou seja, o número de sites além dos quais os IPs foram desconsiderados, estava configurado para 1.000, 98,84% dos pares tinham menos que 1% de similaridade. Os resultados estão todos demonstrados na Figura 6.3, com uma escala logarítmica no eixo vertical. Quando l estava configurado para 10, 99,98% dos pares tinham menos que 1% de similaridade também. Claramente, a similaridade é irrelevante e, para cada rodada, o algoritmo dá como saída de retorno todos os pares de IP com similaridade maior que 10%, os quais são marcados no banco de dados para investigação posterior. A ideia é que, com esses dados em mãos, os fraudadores sejam expostos e coligações possam ser descobertas.

Figura 6.9 – Variação do Número Pares de IPs com Similaridade Específica Excluindo IPs compartilhados por l ou mais sites

Nesse caso, quando l foi configurado para 10, a saída do Similarity-Seeker após o experimento apontou 81 pares com similaridade de fator ‘s’ 0,1. Os 81 sites continham 5 coligações de “tamanho” 3, o que significa dizer que consistiam de 5 computadores distintos com algum grau de semelhança (endereço IP, ID do host, ID da máquina) rodando scripts automatizados que buscavam inflar os resultados de três publicadores distintos. Na medida em que os valores de l aumentavam, mais pares foram sendo descobertos – por exemplo, quando o valor de l virou 30, 189 pares de sites foram achados. Na medida em que mais IPs que compartilhavam componentes disjuntos, e o algoritmo foi capaz de entender esses componentes como coligações maiores – muito embora, na verdade, muitos deles fossem simplesmente cliques sobrepostos, outro efeito típico de cliques duplos, de fácil detecção.

Quando o número foi aumentado para 100, 647 pares foram encontrados. Tornou- se claro que os cliques descobertos eram sobrepostos e com uma taxa de ruído muito alta, que acontece quando endereços IP populares são compartilhados por muitos sites legítimos que não foram suficientemente descartados. Na medida em que aumentamos o valor de l, mais pares legítimos de cliques foram reportados como similares mesmo sem seres fraudadores, já que sites de IPs populares compartilhados por esses sites passaram a ser considerados. Para resolver esse problema, é necessário aumentar outros parâmetros tais como o tráfego mínimo requerido para reportar similaridade ‘s‘ na medida em que se aumenta l.

Assim, de maneira a reduzir o ruído, aumentamos gradualmente a taxa de similaridade para além de 0,1, até que ela chegou a 0,5 e a saída do Similarity-Seeker foi comprimida para 406 pares de IP que foram traduzidos a uma coligação de 29 clientes com 100% de similaridade. Decidimos então analisar o banco de dados de cliente para essa detecção e descobrimos algumas informações interessantes.

A maior parte desses (93%) se inscreveram na rede de anúncios na mesma data. Mesmo tendo o tráfego originário de IPs diferentes, o tráfego tinha um padrão de navegação. Depois de investigações adicionais, o campo “Referer” das requisições HTTP tinha origem de páginas que não continham anúncios da rede de anúncios e algumas vezes nenhum anúncio ou anunciante sequer. A suspeita é que os atacantes possuíam os links prontos através de uma rede de robots ou Trojans e quando a rede de anúncios enviava os e-mails de ativação, os atacantes simplesmente obtinham os segredos de ativação e os utilizavam em máquinas comprometidas nos domínios. Isso significa que as mesmas tinham origem unicamente em computadores de coligação, que acessavam os anúncios por meio dos scripts ativados após a autenticação manual ou inscrição no serviço.

Essa foi sem dúvidas uma detecção perfeita de um ataque de coligação, como podemos perceber na descrição do algoritmo na seção 5.7.

Em um mundo real, tal configuração poderia ser semelhante a uma rede de Trojans trabalhando em função de diversos domínios diferentes. Ou seja, os usuários eram humanos utilizando redes de anúncios infectados com Trojans, que estavam programados para atacar a rede de anúncios em background. Na verdade, o código dos mesmos poderia ser desenhado para atacar redes de anúncios diferentes ao mesmo tempo, já que os usuários navegam sem perceber o padrão de cliques em background. É interessante notar que a nossa abordagem parece menos exposta a esse tipo de ataque por causa da dupla abordagem: os usuários infectados precisariam responder os desafios esporadicamente para continuar os ataques automatizados em background e, como demonstrado nesta seção, o algoritmo Similarity-Seeker é um complemento interessante para apontar cliques potencialmente fraudulentos que conseguiram passar na coligação de fraudadores que utilizava usuários humanos.