Dork busca syntax erro

Dork: inurl:.gov  +"syntax" +sql  inurl:.php

Nova dork pesquisa erros de sintaxe expostos pelo Google.

Dork pesquisa erros de sintaxe expostos pelo Google.

Dork: inurl:(sp|ma|rj|mg|bh|noticias)  inurl:(php?|aspx?)  +syntax +mysql -forum -blog -groups -bug -ext:pdf

O que é SQL Injection artigo muito bom

O que é SQL Injection

Sql Injection é conhecido pelo método utilizado para inserir, apagar, editar, entre várias outras funções SQL em ataques a banco de dados através de formulários do tipo texto e password, onde o atacante poderá inserir um usuário em sua tabela do banco de dados, dando-o permissão para acessar todo o sistema ou por exemplo, apagar todos os dados contidos nela .

Exemplos de Ataque

No exemplo abaixo, demonstraremos em ASP as possíveis falhas que podem ocorrer nos websites. Utilizaremos abaixo um exemplo, iremos construir uma tabela de usuário com as seguintes colunas :

- Login - varchar (255) 
- Senha - varchar (255) 

Após criada, executaremos a query :

SELECT * FROM usuarios WHERE login = '[login]' AND senha = '[senha]'; 

Nos scripts ASP, iremos concatenar esta query em uma variável para construir uma consulta dos dados do usuário usando a seguinte linha: 

var query = "SELECT * FROM usuarios WHERE login = '" + login +"' AND senha = '" + senha + "'" ;

Se o login for uma aspa simples (') a consulta que irá acontecer se torna:

SELECT * FROM usuarios WHERE login = ' ' ' AND password = '[password]' ;

Isto é uma sintaxe inválida de SQL e irá produzir uma mensagem de erro no browser do usuário:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]

Unclosed quotation mark before the character string and senha=.

A aspa simples fornecida pelo usuário fechou a primeira aspa simples e a segunda aspa simples gerou o erro pois não estava fechada. O atacante pode agora começar a injetar uma string na query para manipular o seu comportamento, por exemplo para efetuar o logon como o primeiro usuário na tabela de usuários você poderia colocar no campo de login:

' or 1=1 --

Isto converte a busca para:

SELECT * FROM usuarios WHERE login = ' ' or 1=1- - ' AND senha = '[senha]';

Os dois hífens significam um comentário em Transact-SQL, então todo o restante da linha é ignorado. Como 1 é sempre igual a 1, esta query irá retornar a tabela de usuários inteira. O script ASP irá aceitar o logon pois resultados foram retornados e o cliente será autenticado como o primeiro usuário da tabela.

Se conhecer um usuário, pode logar com o seu nome:

' or login='admin' --

O SQL Injection não ocorre apenas se o usuário não escapear as aspas simples, outra ocorrência é:

sql = "delete from tb_videos where vd_id = " & request("id") 

Neste caso se o usuário inserir como entrada "0 or 1=1" a query acima irá apagar todos os vídeos do banco de dados.

Visto até aqui pode-se ter uma idéia do quão exposto está uma aplicação que não implementa segurança contra esta técnica de invasão.

Formas de Correção

Estas informações abaixo são apenas exemplos de formas para correção de possíveis ataques ao Banco de Dados, porém, existem outros métodos também válidos, mas que por fugirem do escopo do artigo, não serão abordados aqui.

Em ASP uma forma simples para correção deste problema é utilizar uma instrução replace nos caracteres chave, como no exemplo abaixo:

strSenha = Replace(strSenha, "'", "");

Basicamente ele substitui o (') por nada, isto é uma forma de corrigir o problema.

Em PHP existem algumas formas de resolver o problema, uma é usar a função: mysql_real_escape_string(); e outra é usar a função: stripslashes();.

Exemplificando a solução com o stripslashes, temos:

Para toda variável inteira fornecida pelo usuário, passe a seguinte função: $var = intval($var);
Isto elimina todos valores não numéricos, deixando apenas valores inteiros

Para as demais variáveis, antes de fazer qualquer operação no banco, passe a seguinte função:

$var = addslashes($var);

Esta função retorna uma string com barras invertidas antes de caracteres que precisam ser escapeados. Estes caracteres são aspas simples ('), aspas duplas ("), barra invertida (\) e NULL (o byte NULL).

A função stripslashes() retorna uma string com as barras invertidas retiradas. (' se torna ' e assim por diante.) Duas barras invertidas (\\) se tornam uma (\).

Por fim, inclua o arquivo ctracker.php no cabeçalho de todas as páginas que recebem variáveis como parâmetro. Exemplo:

<?php
      require_once("ctracker.php");
      // Aqui em baixo fica o conteúdo
?>

Obs: Lembre-se de alterar a 5ª linha do código, nela é setada qual a página será exibida quando o sistema identificar uma tentativa de invasão.

Em Perl, a solução da SQL Injection é apenas baseada nas aspas. Na maioria dos casos a substituição de uma aspas simples por aspas duplas resolve o problema. A instução em Perl para isto é:

$sql = sprintf 'SELECT name FROM usuarios WHERE nome%s AND senha=%s,
   $dbh->quote($Q::nome),$dbh->quote($Q::senha);

Todas as soluções aqui apresentadas são baseadas no mesmo processo de escapeamento de caracteres especiais, no caso Aspas.

Fonte: http://www.netpoint.com.br/

Arqui filtro ant - sql

<?php
//****************** CONFIG ****************//
// pagina que será impessa quando a tentativa de invasao for detectada
$page = "http://[sua_pagina_de_invasao]";
//****************** CONFIG ****************//


// Cracker Tracker Protection System
// Created by: Christian Knerr - www.cback.de
// phpBB Users: Please use our complete phpBB2 Mod!
// Version: 2.0.0
//
// License: GPL
//
// Begin CrackerTracker  StandAlone
//
  $cracktrack = $_SERVER['QUERY_STRING'];
  $wormprotector = array('chr(', 'chr=', 'chr%20', '%20chr', 'wget%20', '%20wget', 'wget(',
        'cmd=', '%20cmd', 'cmd%20', 'rush=', '%20rush', 'rush%20',
                   'union%20', '%20union', 'union(', 'union=', 'echr(', '%20echr', 'echr%20',
                   'echr=','esystem(', 'esystem%20', 'cp%20', '%20cp', 'cp(', 'mdir%20', 
                   '%20mdir', 'mdir(','mcd%20', 'mrd%20', 'rm%20', '%20mcd', '%20mrd', '%20rm',
                   'mcd(', 'mrd(', 'rm(', 'mcd=', 'mrd=', 'mv%20', 'rmdir%20', 'mv(', 'rmdir(',
                   'chmod(', 'chmod%20', '%20chmod', 'chmod(', 'chmod=', 'chown%20', 'chgrp%20', 
                   'chown(', 'chgrp(','locate%20', 'grep%20', 'locate(', 'grep(', 'diff%20',
                   'kill%20', 'kill(', 'killall','passwd%20', '%20passwd', 'passwd(', 
                   'telnet%20', 'vi(', 'vi%20','insert%20into', 'select%20', 'nigga(', 
                   '%20nigga', 'nigga%20', 'fopen', 'fwrite', '%20like', 'like%20',' $_request',
                   '$_get', '$request', '$get', '.system', 'HTTP_PHP', '&aim', '%20getenv', 
                   'getenv%20','new_password', '&icq','/etc/password','/etc/shadow', 
                   '/etc/groups', '/etc/gshadow','HTTP_USER_AGENT', 'HTTP_HOST', '/bin/ps', 
                   'wget%20', 'unamex20-a', '/usr/bin/id','/bin/echo', '/bin/kill', '/bin/',
                   '/chgrp', '/chown', '/usr/bin', 'g++', 'bin/python','bin/tclsh', 'bin/nasm',
                   'perl%20', 'traceroute%20', 'ping%20', '.pl', '/usr/X11R6/bin/xterm',
                   'lsof%20','/bin/mail', '.conf', 'motd%20', 'HTTP/1.', '.inc.php', 
                   'config.php', 'cgi-','.eml','file://', 'window.open', '<SCRIPT>',  
                   'javascript://','img src', 'img%20src','.jsp','ftp.exe','xp_enumdsn',
                   'xp_availablemedia', 'xp_filelist', 'xp_cmdshell', 'nc.exe',
                   '.htpasswd','servlet', '/etc/passwd', 'wwwacl', '~root', '~ftp', '.js',
                   '.jsp', 'admin_', '.history','bash_history', '.bash_history', '~nobody',
                   'server-info', 'server-status', 'reboot%20', 'halt%20','powerdown%20',
                   '/home/ftp', '/home/www', 'secure_site, ok', 'chunked', 'org.apache',
                   '/servlet/con','<script', '/robot.txt' ,'/perl' ,'mod_gzip_status',
                   'db_mysql.inc', '.inc', 'select%20from','select from', 'drop%20', 
                   '.system', 'getenv', 'http_', '_php', 'php_', 'phpinfo()', 
                   '<?php', '?>', 'sql=');


  $checkworm = str_replace($wormprotector, '*', $cracktrack);


  if ($cracktrack != $checkworm)
    {
      $cremotead = $_SERVER['REMOTE_ADDR'];
      $cuseragent = $_SERVER['HTTP_USER_AGENT'];


      header("location:$page");
      die();
    }
?>

INDEX /OF site subdomínio nasa.gov

Pra você caro amigo navegador da net que gosta de fuçar em arquivos do governo ou só ter a sensação de navegar em algo proibido "Digamos assim kkk"

Aé vai um Index /Of que esta dentro do domínio Nasa.gov essa mesmo famosa Nasa.

LINK http://hesperia.gsfc.nasa.gov/ssw/soho/lasco/idl/database/include/
LINK http://hesperia.gsfc.nasa.gov/ssw/

O Governo da Colômbia pode premiar seu talento com dinheiro!‏

Recebo & Compartilhos

O Ministério da Tecnología da Informação e das Comunicações da Colômbia (Mintic) está desafiando você a apresentar sua ideia de um aplicativo para dispositivos móveis e websites em 12 diferentes categorias de interesse público. A ideia é facilitar a vida dos cidadãos colombianos, melhorando os trâmites e os serviços prestados pelo Estado. Caso a sua ideia seja pré-selecionada, você poderá participar da segunda fase e seguir na disputa para ser o grande vencedor.

O desafio contará com duas etapas, uma para a apresentação de ideias, e outra para o desenvolvimento funcional do projeto.

1. Na primeira, os campuseiros devem pensar e planificar, conceitualmente, uma APP para dispositivos móveis e websites focada em um dos serviços do Estado colombiano dentro de uma, ou mais, das 12 categorias disponíveis. Entre elas, é possível encontrar temas como educação, saúde, meio ambiente, serviços públicos, trabalho e emprego.
   
2. Na segunda fase, na qual participarão apenas os semifinalistas selecionados pela primeira etapa, será preciso entregar o desenvolvimento funcional da aplicação correspondente a ideia apresentada.
   
   PRIMEIRA FASE
   • Prêmio para a melhor ideia de APP em cada uma das 12 categorias: um tablet. 
   
   SEGUNDA FASE
   • rêmio ao melhor projeto de APP entre os 12 selecionados na primeira etapa: 7.500.000 pesos colombianos (aproximadamente US$ 4.200)

Você tem até 25 de julho para fazer a sua inscrição na primeira fase do desafio do Mintic na Campus Labs e seguir na disputa pelo prêmio principal!

Não perca esta oportunidade e dê asas as suas ideias!

Para mais informações acesse: campus-labs.com

Boa sorte!

Este e-mail foi enviado para o endereço disponibilizado através do cadastro de CAMPUSEIROS da Futura Networks S.L. porque você optou pela inclusão através do nosso site http://www.campus-party.com.br. A qualquer momento você poderá exercer o seu direito de acesso, retificação, cancelamento e oposição através do envio de um e-mail para [email protected], ou enviando uma carta a qualquer um dos seguintes endereços: Av. Angélica, 2163 (Salas 65/66) - São Paulo, SP CEP: 01227-200 BRASIL / Calle Aduana 33,4º, 28013 de Madrid, ESPAÑA. Caso você queira simplesmente deixar de receber este tipo de contato, basta enviar um e-mail ao mesmo contato indicado acima. Basta colocar no assunto da mensagem a palavra BAIXA.

Re: ICMBio - Instituto Chico Mendes de Conservação da Biodiversidade: Vulnerabilidade ativa

Caso encerrado.

Resposta : 

Boa tarde,
O  grupo Google INURL - Brasil
Ficamos satisfeitos pelo retorno.
Não postamos as falhas em nosso blog, vamos postar sua resposta assim 
Dando credibilidade e importância ao ocorrido.

Muito obrigado & Boa noite.
Estamos de olho.

Atenciosamente Grupo Google INURL - Brasil

---- Original Message ----
From: Uilson Azevedo
To: "Google INURL - BRASIL"
Cc: "Carlos Roberto Lacerda Cunha" , "Renata Gomes" , "Mauro Felipe" , "ICMBio Instituto Chico Mendes de Conservação da Biodiversidade"
Sent: Qui, Jul 5, 2012, 16:58 PM
Subject: Re: ICMBio - Instituto Chico Mendes de Conservação da Biodiversidade: Vulnerabilidade ativa no site http://www4.icmbio.gov.br/

Senhores,

Agradecemos pela observação.

Os sites hospedados no domínio citado (www4.icmbio.gov.br) estão em processo de desativação pois são aplicações legadas e que poderiam mesmo ter vulnerabilidades.

Todas as medidas de segurança e isolamento do host foram tomadas antes de publicar os sites.

Qualquer dúvida estamos à disposição.

Uilson Azevedo

Conforme orientação do Coordenador de Tecnologia

ICMBio

Em 5 de julho de 2012 13:19, Ascom ICMBio <[email protected]> escreveu:

Carlos e Uilson,

chegou este email e achei pertinente que vces analisem, por se tratar da segurança do portal.

Sandra Tavares

9290

---------- Mensagem encaminhada ----------
De: Google INURL - BRASIL <[email protected]>
Data: 5 de julho de 2012 11:52
Assunto: ICMBio - Instituto Chico Mendes de Conservação da Biodiversidade: Vulnerabilidade ativa no site http://www4.icmbio.gov.br/
Para: [email protected]


Este é um e-mail de pedido de informações via http://www.icmbio.gov.br/portal/ de:
Google INURL - BRASIL <[email protected]>

Bom dia,
Venho informa que o site icmbio.gov.br
esta com uma vulnerabilidade SQL INJECTION que da acesso as tabelas usuários administrador do site.

Nível:Critico.

Vulnerabilidade ativa no site Site: www.icmbio.gov.br


Espero um retorno com correção da brecha.

Atenciosamente http://blog.inurl.com.br

--
Divisão de Comunicação Social - DCOM
Instituto Chico Mendes de Conservação da Biodiversidade - ICMBio
Ministério do Meio Ambiente - MMA
EQSW 103/104, Complexo Administrativo, Bloco B, Térreo, Setor Sudoeste, CEP 70.670-350, Brasília-DF
Tel.: (61) 3341-9280 begin_of_the_skype_highlighting            (61) 3341-9280      end_of_the_skype_highlighting a 3341-9294
www.icmbio.gov.br
[email protected]

--
Uilson Azevedo

CTI - Coordenação de Tecnologia
ICMBio - Instituto Chico Mendes de Biodiversidade
Fone: (61) 3341 9606 begin_of_the_skype_highlighting            (61) 3341 9606      end_of_the_skype_highlighting
Celular: (61) 9805 5512 begin_of_the_skype_highlighting            (61) 9805 5512      end_of_the_skype_highlighting

Cross-site scripting (XSS) por Ahmed Elhady Mohamed

Introdução

[+] XSS por Wikipédia

Cross-site scripting (XSS) é um tipo de vulnerabilidade do sistema de segurança de um computador, encontrado normalmente em aplicações web que ativam ataques maliciosos ao injetarem client-side script dentro das páginas web vistas por outros usuários. Um script de exploração de vulnerabilidade cross-site pode ser usado pelos atacantes para escapar aos controles de acesso que usam a mesma política de origem.

[+] XSS é perigoso?

Sim, XSS é realmente perigoso, é de alta gravidade, porque ele poderia mudar o site e roubar as credenciais de administrador, nestes casos, o invasor pode controlar e comprometer o aplicativo.

Eu nunca tinha dado tanta importância para o XSS até ver uma palestra na CPBR5 que falava das 10 ameaças da OWASP mais usadas, vi coisas realmente incríveis com o XSS até mesmo roubo de sessões.

[+] O Que o atacante quer alcançar?

- Alterar configurações

- Roubar cookies

- Fazer uma publicação falsa

- Realizar roubos de Tokens para ataque CSRF

[+] Tipos de Ataques XSS

Persistent (stored) XSS
O ataque é armazenado no site.

Non persistent  (reflect) XSS
Usuário tem que ir através de um link especial para ser explorado.

DOM-based  XSS
problema existe dentro do script do lado do cliente

Vamos discutir cada tipo destes ataques em detalhes.

[+] Persistent (stored) XSS

O persistent (or stored) vulnerability XSS é uma variante mais devastadora da falha de cross-site scripting, ela ocorre quando os dados fornecidos pelo atacante é salvo pelo servidor e em seguida permanentemente exibida nas páginas retornadas para outros usuários na exibição regular da navegação. Um exemplo clássico disso é com quadros de mensagens de forum onde os usuários tem permissões para postar mensagens formatadas em HTML para que outros usuários possam ler.

Persistent XSS simplesmente ocorre quando o desenvolvedor armazena os dados de entrada do usuário no banco de dados ou simplesmente o escreve em um arquivo sem uma filtragem adequada, em seguida, envia-os novamente para os usuários.

[+] Exemplo de persistent XSS em PHP

'.mysql_error().'

'); } ?>

Os dois parâmetros em que o código ”message” e ”name” não são higienizados adequadamente e assim nós armazenamos estes parâmetros para a tabela no guestbook(livro de visitas), portanto, quando a exibição desses parâmetros voltar ao navegador do cliente, ele irá executar o código JavaScript malicioso.

< –

Dentro da caixa de texto vulnerável foi inserido um código em java script malicioso.

– >

Assim que o código é executado olha o resultado:

[+] Non Persistent (Reflected) XSS

A definição non persistent (ou reflected) XSS é de longe o tipo mais comum. Estes buracos aparecem quando os dados fornecidos por um cliente web, mais comumente em parâmetros de consulta HTTP ou envios de formulários HTML, é usado imediatamente por scripts do servidor para gerar uma página de resultados para o usuário, sem a correta higienização do pedido.

[+] Exemplo de non persistent XSS em PHP

'; 
echo 'Hello' . $_GET['name']; 
echo '

'; } ?>

Como você pode ver, o “name” é um parâmetro não higienizado e retornara para o usuário, assim quando o usuário injetar um código malicioso em JS ele será executado.

Vamos injetar o código   e vejamos o que vai acontecer.

Assim que inserimos o código no campo vulnerável ele retorna o erro e notem que na barra de navegação do browser que ele vai mostrar o código digitado também.

.

.

.

.

.

O restante do artigo fiquei com um pouco de preguiça de traduzir, mas é um bom artigo e vale a pena se visualizado.

Segue o link do PDF http://www.exploit-db.com/wp-content/themes/exploit/docs/18895.pdf

Fonte: http://unknownantisec.wordpress.com/2012/05/20/cross-site-scripting-xss-por-ahmed-elhady-mohamed/

Europa rejeita entrada na Acta, que busca controle da web.

http://pt.wikipedia.org/wiki/Acordo_Comercial_Anticontrafa%C3%A7%C3%A3o


O parlamento europeu rejeitou a assinatura do Acordo de Comércio de Anti-Contrafacção (tradução livre para Anti-Counterfeiting Trade Agreement, ou Acta), por 478 votos contra 39. As informações foram publicadas nesta quarta-feira (04/07) pelo blog TechCrunch.


Discussões sobre a Acta ressurgiram mais fortemente em janeiro deste ano, por conta da polêmica envolvendo os projetos de lei norte-americanos Sopa e Pipa, que visavam a buscar o controle de compartilhamento de arquivos na web. A Acta é datada de outubro de 2011 e já foi assinado por países como Finlândia, França, Irlanda, Itália, Portugal, Romênia e Grécia.  Mais recentemente, agora em janeiro de 2011, foi a vez da Polônia entrar para o grupo.

A regulação do tráfego de informações pela internet é apenas uma parte do documento, que conta com 22 páginas. A ideia é que os países colaborem uns com os outros na concessão de informações de usuários que se valham de conteúdo protegido por copyright na web. “Esses procedimentos devem ser implementados como forma de evitar a criação de barreiras para atividades legítimas, incluindo comércio eletrônico, e, condizente com a lei, preserve princípios fundamentais, tais como liberdade de expressão, processos jutos e privacidade”, diz o documento.

Segundo a notícia do TechCrunch, a rejeição dos países europeus pode tornar mais difícil a implantação das normas em países que já aprovaram a medida mais ainda não a ratificaram, tais como Austrália, Canadá, Japão, Coreia do Sul, Marrocos, Nova Zelândia, Cingapura e Estados.

O que é Session Hijacking

Hijacking - Corresponde a um ataque aonde uma sessão activa é interceptada e utilizada pelo atacante. Pode acontecer localmente se o PC for deixado desprotegido, ou remotamente via internet."

Introdução

O Termo “Session Hijacking” refere-se à exploração de uma sessão válida de um computador – as vezes também chamada de Session Key ou ID – para conseguir acesso não-autorizado a informações ou serviços em um sistema de computador.

Em particular, é usado para referir-se ao roubo do Magic Cookie, utilizado para autenticar um usuário em um servidor remoto. Isto é particularmente relevante para os desenvolvedores Web, já que os HTTP Cookies usados para manter uma sessão em diversos sites Web podem facilmente ser roubados por um atacante utilizando um computador que esteja no meio da comunicação ou então acessando os cookies salvos no computador da vítima.

Muitos web sites permitem que usuários criem e gerenciem suas próprias accounts, logando utilizando um username e password (que pode ou não ser criptografada durante o transito) ou outro método de autenticação. Para que o usuário não tenha que re-digitar seu usuário/senha em todas as página para manter sua sessão, muitos web sites utilizam-se de cookies: um token de informações solicitadas pelo server e retornada pelo user browser para confirmar sua identidade.

Se um atacante estiver habilitado a rouber este cookie, ele pode fazer requisições como se fosse o usuário legítimo, ganhando acesso à informações privilegiadas ou até modificando dados. Se o cookie for um Cookie Persistente, o roubo de identidade pode se estender por um tempo muito longo.

É claro que Session Hijacking não é limitada para a Web, qualquer protocolo cujo o estado é mantido através de uma key que é checada através de dois computadores é vulnerável, especialmente se não for criptografada.

Terminologia

Uma das grandes vantagens de utilizar o Mozilla Firefox é que você pode conseguir uma porção de plugins interessantes para explorar aplicações. Tamper Data, Cookie Culler, AEC Cookie Editor são alguns destes. Uma pequena introdução sobre estas tools.

- Tamper Data: É utilizado para rastrear a comunicação entre o browser e o servidor e esta funcionalidade permite interceptar e modificar os dados “on the Fly” e re-enviar para o servidor.

- Cookie Culler: É utilizado para visualizar os cookies e apaga-los caso seja necessário

- AEC Cookie Edito: Permite melhor controle sobre o Cookie que você modifica, e assim modificar seu conteúdo para testar vulnerabilidades em sua aplicação web.

Um Exemplo

Vamos verificar algumas tools mencionadas acima. Aqui, TamperData mostra a comunicação de outgoing onde eu fiz um search por “Session Hijacking” no google. Você pode ver ambos os Headers, tanto de request quanto de response assim como os parametros GET, POST e seus valores.

AEC Cookie Editar mostra informações a respeito dos Cookies no sistema e explica como um Web Server rastreia os clientes utilizando os cookies.

Exploitation Scenario

A maioria das aplicações web utilizam HTTP e HTTPS protocols juntos para suas comunicações dependendo da sensibilidade da informação que está sendo enviada através do canal de comunicação. Em geral o HTTPS é ativado para enviar username/password, informações financeiras e outras informações importantes. Uma vez que a informação é enviada a aplicação volta a utilizar HTTP novamente.

Normalmente se você observar uma aplicação web, ela joga seus cookies assim que você visita a página pela primeira vez e o cookie vai manter o seu Session ID. Este ID e uma importante peça de informação a qual poderá ser utilizada para rastrear a sessão toda vez que o usuário se logar. Muitas pessoas negligenciam a importancia deste ID. Todas as vezes antesde entrar num canal seguro, eles utilizam o mesmo Session ID. Aí é onde a vulnerabilidade existe. Sniffar uma rede é muito simples. Uma grande variedade de softwares estão disponiveis para sniffar informações de forma ativa e passiva.

Especialmente em redes wireless, sniffing é fácil como roubar doce de criança :-)

A maioria das web applications vai dar acesso ao Sniffer se este conseguir o Session ID se um usuário que ainda está logado no sistema e poderá permitir que ele acesse importantes informações da vítima. Esta vulnerabilidade existe na maioria dos sites comerciais que provem vários serviços. Provedores de E-mail, Sites de Shopping, etc todos estão vulneráveis à este tipo de ataque se implementarem a autenticação desta forma.

Obama ordenou aumento de ciberataques contra sistemas de usinas nucleares do Irã, diz jornal

O presidente dos Estados Unidos Barack Obama teria ordenado, já nos primeiros meses de mandato no cargo, que ataques “sofisticados” contra sistemas de computadores de usinas nucleares no Irã fossem intensificados, segundo reportagem do “New York Times” desta sexta (1º).

De acordo com participantes da ação, a decisão aumentou significativamente a primeira ação sustentada por armas cibernéticas do país. De acordo com o “New York Times”, Obama acelerou os ataques (iniciados na administração de George W. Bush), mesmo depois que o vírus, conhecido como Stuxnet, acidentalmente saiu das usinas nucleares iranianas e circulou na internet mundial.

O Stuxnet, desenvolvido em conjunto pelos Estados Unidos e Israel, foi descoberto por empresas de segurança logo após sua “fuga acidental” do Irã. O “New York Times” afirma que houve uma reunião logo após o ocorrido na Casa Branca, com a presença de Joe Biden, vice-presidente dos EUA, e o diretor da CIA (Agência Central de Inteligência) na época, Leon E. Panetta, na qual consideraram que o esforço “havia sido fatalmente comprometido”.

Obama teria perguntado “devemos desligar essa coisa?”, segundo membros da segurança nacional presentes na sala. Ao ser avisado que ainda não estava claro o quanto os iranianos sabiam sobre o código do vírus e que ele ainda estava “causando estragos”, Obama teria decidido continuar o ataque cibernético.

De acordo com o jornal americano, nas semanas seguintes, a usina nuclear iraniana de Natanz foi atacada com uma nova versão do vírus e mais uma vez depois também. Na última série de ataques, poucas semanas depois de o Stuxnet ser detectado no mundo, cerca de 1.000 a 5.000 centrífugas que enriquecem urânio foram paralisadas.

As informações foram obtidas pelo “New York Times” após 18 meses de entrevistas com ex-oficiais americanos, israelenses e europeus envolvidos na ação, além de outros especialistas.

O Irã inicialmente negou que suas usinas nucleares haviam sido atacadas por um vírus de computador, mas depois admitiram o fato. O país, após o ataque, criou uma unidade militar de ciberdefesa em 2011.

O governo dos Estados Unidso apenas recentemente admitiu desenvolver armas cibernéticas e nunca admitiu tê-las utilizado. 

Essa dork vai para os carinhas da net que gosta de um Scanner especifico pra vulneráveis php

Essa dork vai para os carinhas da net que gosta de um Scanner especifico pra vulneráveis php


Dork:  inurl:"*.php?*=*.php" intext:"Warning: include" -inurl:.html -site:"php.net" -site:"stackoverflow.com" -inurl:"*forums*"

Vários dispositivos on-line IPCam client

    Dork:  intitle:"HtmlAnvView:D7B039C1"

Se o seu site foi infectado com malware.

Se o seu site foi infectado com malware

Após ter certeza de que todo código malicioso foi removido, será possível solicitar uma análise de malware do seu site. O Google verificará o seu site e, se nenhum malware for detectado, removerá o marcador de aviso que aparece na listagem do seu site na página de resultados de pesquisa.

1. Na página inicial das Ferramentas do Google para webmasters, selecione o site que desejar.
2. Clique em Status do site e, depois, em Malware.
3. Clique em Solicitar uma análise.

Após a confirmação de que o seu site está limpo, pode demorar até um dia para que o aviso de malware seja removido do seu site nos resultados de pesquisa.

Se os invasores colocaram spam no seu site

Após o seu site estar livre de spam, será possível pedir ao Google para reconsiderar sua inclusão nos resultados de pesquisa.

Para pedir a reconsideração do seu site:

1. Acesse as Ferramentas do Google para webmasters com sua Conta do Google.
2. Certifique-se de adicionar e verificar o site que deseja reconsiderar.
3. Pedido de reconsideração do seu site.

Assim o Google vai verificar todo código do seu site, para constar que realmente não dispõem de nem outro  código malicioso, depois dessa etapa seu site volta aparece nos resultados, porem pode levar algum tempo para entrar no posição de antes.

Diretrizes para webmasters boas práticas.

Diretrizes para webmasters

Práticas recomendadas para ajudar o Google a encontrar, rastrear e indexar seu site

Siga as diretrizes abaixo para ajudar o Google a encontrar, indexar e classificar seu site. Mesmo que você decida não implementar as sugestões, recomendamos que preste atenção às "Diretrizes de qualidade", que destacam algumas práticas ilícitas que podem levar à remoção de seu site do índice do Google ou à ação manual ou por algoritmos de spam. Se um site for afetado por uma ação de spam, ele não será mais exibido nos resultados no Google.com.br ou em qualquer site parceiro do Google.

Diretrizes de conteúdo e design	Saiba mais...
Diretrizes técnicas	Saiba mais...
Diretrizes de qualidade	Saiba mais...

Quando o seu site estiver pronto:

• Envie-o ao Google em http://www.google.com/submityourcontent/.


• Envie um Sitemap utilizando as Ferramentas do Google para webmasters. O Google utiliza o seu Sitemap para obter informações sobre a estrutura do seu site e aumentar a nossa cobertura das suas páginas web.


• Verifique se todos os sites que devem saber sobre as suas páginas estão cientes de que o seu site está on-line.

Diretrizes de conteúdo e design

• Construa um site com uma hierarquia clara e links de texto. Cada página deve ser acessada a partir de pelo menos um link de texto estático.


• Mostre aos usuários um mapa do site que relacione o tópico às partes importantes do seu site. Se o mapa do site tiver muitos links, convém dividi-lo em várias páginas.


• Utilize um número razoável de links por página.


• Crie um site útil, com muitas informações e páginas que descrevam de forma clara e precisa o seu conteúdo.


• Pense nas palavras que os usuários digitariam para encontrar as suas páginas e verifique se elas aparecem no seu site.


• Tente usar texto, em vez de imagens, para exibir nomes, conteúdo ou links importantes. O rastreador do Google não reconhece texto contido em imagens. Se for necessário usar imagens para conteúdo de texto, avalie a possibilidade de usar o atributo "ALT" para incluir algumas palavras de texto descritivo.


• Verifique se os elementos

fonte..: http://support.google.com/webmasters/bin/answer.py?hl=pt-BR&answer=35769