Onde vc quer chegar divulgando dados pessoais de centenas de clientes deste site? Qual o objetivo disso tudo?
[]s, MM
Usuário Registrado
os dados sao dados pessoiais e bancarios do site gestao do futuro ,
sao dados de clientes de eventos do site onde gastam em media de 700,00 a 8,000,00 *reais.
ai vai a lista.
correcao o site é gestaodofuturo.com.br
***SNIP*** Trecho editado pelo moderador
Eu só trabalho aqui
Onde vc quer chegar divulgando dados pessoais de centenas de clientes deste site? Qual o objetivo disso tudo?
[]s, MM
Usuário Registrado
caro mmachado,
acho que os admin deste site nao se preocupam com segurança eles nao me deram nenhuma resposta nem corrigiram a falha.
por isso resolvi divulgar,mas ainda bem que vc tirou os nomes pois me arrempendi de ter divulgado os nomes.
quanto as falhas nao me arrependo.
Eu só trabalho aqui
Que bom... seria interessante vc explicar aos demais usuários um pouco mais sobre a falha que vc encontrou. Afinal o objetivo do fórum é discutir a segurança dos sites.
E depois de dar a dica, você ainda pode enviar o link deste tópico para os administradores do site. Aposto que eles vão tomar providências rapidinho e o susto vai realmente valer a pena.
[]s, MM
Usuário Registrado
a falha encontrada foi uma das mais facei a do sql injection
ultimamente tenho procurado muitos estas falhas de programacao .
tenho encontrado muitas site com areas restritas vulneravei com por exemplo estecamara municpal de diadema
e este vitalitys clinic e cenetnas de outros sites.
coisa facil de hackear coisa simples de resolver
Usuário Registrado
f4r3j4d0r Realmente issu não é nenhuma novidade.
Eu concordo com o f4r3j4d0r são muitos sites que tem a mesma vul...
O Pessoal injeta muitos código inseguro. E f4r3j4dor o SQL Injection, nada mais é do que injetar código SQL não esperado numa aplicação com fins não muito amigáveis.
(correto) ????
Então...
Gostaria f4r3j4d0r q vc falace um poco mais sobre os códigos q forão injetados, assim tb os admin poderião ficar sabendo etc.
Alguem aqui ja tentou acessar uma página dinâmica dessa forma: exp: ta pessoal
http://www.site.com.br/produtos/produto?id=77;DELETE FROM produtos
Usuário Registrado
cara os comandos usados ja sao bem conhecidos ,
isso ja foi muito divulgado,
so que eu mandando esses codigos poderia estar contribuindo com mais uma lammer(não estou chamando vc de lammer).
mais existem caras que nao sabem nem usar linux ou o que é um exploits e vivem contribuindo para denigri a nossa imagem.
mais me mande um email possote dar umas dicas.
contact is f4r3j4d0r@yahoo.com.br
Usuário Registrado
Opa td jóia pessoal?!
Bom como você mesmo disse f4r3j4d0r a vulnerabilidade que você citou já foi bem divulgada, então não vejo por que não repassar as informações sobre a mesma.. No mais vamos ocupar nosso tempo com coisas novas, pra que procurar oque já foi encontrado?! .. bom segue o texto abaixo..
Como burlar Sites Pagos em ASP
Hoje em dia é uma prática comum os sites pedirem um cadastro do visitante, e criar-lhe um login, dando acesso a áreas restritas e especiais do site. Cadastro esse que na maioria das vezes é gratuito, com a intenção apenas de fidelizar o usuário e claro, ter mais um e-mail para uma possível divulgação, que neste caso não se caracteriza spam, pois o devido usuário previamente aceitou informações vindas daquele site.
Em sites onde o cadastro é pago, aí a coisa muda de figura. O site imagina estar vendendo alguma informação ao visitante, e por isso, pode pedir alguns dados sigilosos do usuário e guardá-los seguramente no seu banco de dados.
O que venho apresentar, jogará seu login no vento e o site arderá no mármore do inferno, mas só vou falar como funciona porque Alah mandou e estava escrito com o bit sagrado.
Essa técnica geralmente é chamada de SQL Injection, ou seja, injeção de SQL. Funciona em sites que testam a entrada do login em scripts ASP com chamadas internas de SQL.
Vamos a lógica:
O programador, iniciante ou não, pensa em criar uma área restrita para o site, logo precisará de um login e senha para os usuários. Então é criado dentro do banco de dados (em sql ou mdb, mais comum em mdb) uma tabela chamada Users, com alguns campos, dentre eles Usuario, Senha, Nome e Admin. Esses campos informarão exatamente o que o nome diz, ou seja, o login do usuário, a sua respectiva senha, seu nome e um campo flag indicando se é admin do site ou não. Se for admin, geralmente tem acessos a cliques extras, do tipo incluir/editar/deletar alguma informação.
Feito isso, cria dentro da sua página um bloco onde pede o login e senha para o usuário ter acesso as devidas áreas. Geralmente, o formulário tem apenas os dois campos mesmo, user e senha. Esses dois campos são enviados para um script .asp, que validará ou não o login informado. Se for válido, redireciona para a área restrita, senão, volta ao login ou no máximo, informa que o login estava errado.
Bonito não!? Teoricamente funciona.
Vamos a prática:
Dentro desse script .asp, o programador colocou algo desse tipo:
*****
' Isso pega o usuário e senha informados no formulário
cUser = trim(request("usuario"))
cSenha = trim(request("senha"))
'Isso verifica no banco de dados se o usuário e senha conferem
' (vamos supor que o banco já esteja aberto com o nome de objConn)
SQLOpen = "select usuario, senha, nome, admin from Users where usuario='" & cUser & "' and senha='" & cSenha & "'"
objRS.Open SQLOpen, objConn
' Verifica se achou um usuário com o login e senha informados
if not objRS.bof then
response.write "Bem vindo " & objRS.fields("nome") & "!"
else
response.write "Login inválido."
end if
*****
Na prática inocente, isso funciona. Funciona muito bem. Testa os usuários, se a senha não for a correta, realmente não entra. Se um usuário foi digitado errado, também não dá acesso.
Mas, na prática hacker, isso funciona melhor ainda, pois permite entrarmos como qualquer usuário do sistema. Até mesmo com status de admin.
Vamos pensar um pouco:
"select usuario, senha, nome, admin from Users where usuario='" & cUser & "' and senha='" & cSenha & "'"
Essa é a string do SQL. Em VB e ASP, sabemos que para concatenarmos uma string dentro de outra, devemos usar aspa simples, invés de aspa dupla, pois a aspa dupla é para a string mestra, e a aspa simples é para a string interna.
Traduzindo a string acima, teríamos:
select usuario, senha, nome, admin from Users where usuario='geek' and senha='s3nh4'
Dessa forma, trocamos as variáveis cUser e cSenha, pelos seus respectivos conteúdos.
Repito, isso funciona muito bem, quando usamos de forma inocente. Vale lembrar que de 10 sites em asp que pedem login e senha, 8 tem essa forma de consulta e estão sujeitos a algum tipo de invasão, dependendo do nível de acesso que permita aos seus usuários.
"Você falou, falou, falou.... mas e daí!? Cadê o erro nisso?"
Ok. Vamos ao erro:
Se quando formos digitar um login, tivermos essa string de programação do sql na cabeça, podemos formar outra facilmente, que injeta um comando de sql, dentro do que o programador já fez.
Ou seja, se eu digitar Mario no username, o sql ficará:
select usuario, senha, nome, admin from Users where usuario='Mario' and senha='s3nh4'
Repare que as aspas simples continuam e fazem realmente parte do comando, que mostra ao sql que aquele campo deve ser comparado com um dado do tipo string.
Agora, se digitarmos no username Ma'rio (com uma aspa simples no meio), a página dará um erro, pois o comando ficaria desse tipo:
select usuario, senha, nome, admin from Users where usuario='Ma'rio' and senha='s3nh4'
Analisando, vemos que quando fomos comparar o campo usuário, abrimos uma aspa simples, colocamos o conteúdo Ma e fechamos a aspa simples. Para o sql, a comparação terminou aí, o que vem depois, deveria ser comandos. Mas não era. Era a continuação do username, a palavra rio e mais uma aspa simples, que deveria estar fechando a primeira (antes da palavra Ma), mas na realidade está abrindo uma nova string no SQL, e como não é comparado com nada, o SQL retorna erro de programação.
Então, já que o SQL aguarda ansiosamente por outra aspa simples para fechar aquela primeira, porque nós não damos a ele, e aproveitando, injetamos um comando nele.
Imagine se usarmos a string ' or '1 (isso mesmo: aspa simples + espaco + or + espaco + aspa simples + 1), ficaria assim:
select usuario, senha, nome, admin from Users where usuario='' or '1' and senha='s3nh4'
Lendo o comando, seria a mesma coisa que falar pro SQL: me retorne o usuario que seja igual a vazio OU 1. Lembrando que 1 em informática é a mesma coisa que True (verdadeiro). Lendo novamente: Me retorne o usuário que seja igual a vazio (não existe nenhum) OU verdadeiro (opa.. verdadeiro é verdadeiro, então achei). Nisso, a tabela pega todos os usuários, pois todos dão verdadeiro. Não são igual a vazio, mas o 1 garante que todos sejam válidos. Agora falta só filtrar a senha.
Se usarmos a mesma string mágica na senha, nós seremos o primeiro usuário da tabela, pois:
select usuario, senha, nome, admin from Users where usuario='' or '1' and senha='' or '1'
Me retorne o usuário que seja igual a vazio (nenhum) OU verdadeiro (todos) E que tenha a senha igual a vazio (nenhum) OU verdadeiro (todos).
Isso traz todos os usuários da tabela, porém com o ponteiro no primeiro usuário.
Quando fazemos uma tabela de usuários, e colocamos no ar, qual o primeiro usuário que incluímos? Nós mesmos, claro. E com nível de administrador. E é exatamente esse que viramos quando usamos essa falha.
Alguns outros casos, são quando queremos entrar com o username de uma determinada pessoa. No username, colocamos o nome dela corretamente, e na senha, como não sabemos, usamos essa string que nos foi enviada por Alah. O SQL, muito esperto, entende que é pra retornar o usuário com o nome informado e que tenha uma senha igual a vazio OU verdadeiro. Ou seja, na verdade, ele irá ignorar a senha, e apontará para o registro que o username seja igual ao que foi informando no campo do formulário.
Outro ponto, é quando não sabemos o nome do usuário, e o site tem muitos cadastros. Então, entramos como qualquer um, e com seus respectivos direitos. No usuário colocamos a string mágica, e na senha chutamos qualquer coisa, por exemplo, 123456 (num site com mais de 200 cadastros, é 99% de certeza que alguém tenha usado essa senha.). Então, o SQL apontará o registro para o primeiro usuário que tenha essa senha no seu cadastro. Outras senhas usadas são: 123123, 123321, 121212, 111222, (o próprio nome do site), abc, abcd, abcdef, abc123, 123abc, e coisas fáceis desse tipo.
E no caso do login pedido ser um e-mail, essa string não funcionará, pois talvez exista uma validação no campo do login para atestar que o que foi digitado tem um formato de e-mail (digo talvez, pois já vi sites pedindo e-mail login mas que não validavam nada...)
Daí, usamos a string que passa por essas validações (como o campo de e-mail é grande, por não se saber qual o mail do usuário, podemos utilizar essa string maior. A string anterior é pequena para caber em qualquer campo de login e senha).
A string que passa pelos e-mails é:
eu@eu.com'or'.11'='.11
Dessa forma, caso verifiquem se existe @, esta string passará pois tem 1 @ só.
Se verificarem se tem alguma coisa antes da @... ela é válida e também passa.
Se verificarem de trás pra frente na string.. procurando por uma TLD válida (com um ponto na terceira ou quarta casa, de trás pra frente), encontrarão o ponto (.) na terceira casa, que significa uma TLD brasileira (.br) ou de outros países. E se ainda verificarem mais pra trás, por domínios, encontrarão outros 2 pontos, o que torna esse e-mail pertencente a um dominio com subdomínio.
"Ok. Sou dono de um site em asp, e uso essa forma de verificação. Agora que você já me ferrou e que todo mundo vai me invadir, pode me dizer como conserto isso?"
Claro. É pra isso mesmo que eu estou falando desse erro. Para alertar os sites que estejam com esse problema. Vamos a correção:
O problema todo é que o script só verifica se achou ou não um usuário, não faz um check-up para atestar a veracidade do que foi encontrado. Então, bastaria adicionar o seguinte comando dentro daquele script:
*****
' Isso pega o usuário e senha informados no formulário
cUser = trim(request("usuario"))
cSenha = trim(request("senha"))
'Isso verifica no banco de dados se o usuário e senha conferem
' (vamos supor que o banco já esteja aberto com o nome de objConn)
SQLOpen = "select usuario, senha, nome, admin from Users where usuario='" & cUser & "' and senha='" & cSenha & "'"
objRS.Open SQLOpen, objConn
' Verifica se achou um usuário com o login e senha informados
if not objRS.bof then
if objRS.fields("usuario") = cUsuario and objRS.fields("senha") = cSenha then
response.write "Bem vindo " & objRS.fields("nome") & "!"
else
response.write "Login inválido."
end if
else
response.write "Login inválido."
end if
*****
Dessa forma não há furos de aspa simples ou aspa dupla, pois o IF não se confunde com isso.
Outra forma também, seria tratar o caractere da aspa simples dentro dos campos de usuario e senha, não deixando ele estar contido nesses campos. Mas é um pouco mais trabalhoso.
Outra coisa que é bom lembrar, é que esse erro não afeta somente a internet. Sistemas feitos em Delphi e Visual Basic com esse tipo de verificação de usuário também estão passíveis a esse erro. Portanto, verifique-os também.
** Matéria publicada na H4CK3R 4, de junho de 2002. Autor: Marcelo Gomes
È isso, t+..
Usuário Registrado
ehehe você não esta enendendo.. Como o Mm falow vamos discutir as falhas etc para manda este topico para os admin ...esto querendo que vc de mais detalhes amigo... issu todo mundo ja sabe. hehehhe.Originalmente enviado por [b
Usuário Registrado
cara o que eu tenho para acrecentar é o seguinte as strings que sao essas.
login 'or'
senha 'or'
login 'or'1
senha 'or'1
login admin'=
senha admin'=
agora vc me pregunta como achar um host vulneravel.
usa um mass scan, eu prefiro procurar no google as seguintes strings
allinurl: /admin/login.asp
allinurl:adm/login.asp
allinurl:manager/login.asp
allinurl:login.asp
nada mais a acrescentar o resto ja foi explicado a cima
obrigado
There are currently 1 users browsing this thread. (0 members and 1 guests)
Regras de envio