[Owasp-brazilian] Firewalls de Aplicação WEB, Idiomas e Expressões Regulares - Condições de Bypass

Rodrigo Montoro(Sp0oKeR) spooker at gmail.com
Thu Nov 19 16:54:06 EST 2009


2009/11/19 Nash Leon <nashleon at yahoo.com.br>:
> Como vai, Rodrigo?

Eu to beleza, thread colocando a cuca pra pensar =)

E ai ?

>
> Sim, PCRE pega o assento, mas não na lista [A-Z] e nem na posix
> [[:alpha:]]. Que é o que o artigo tenta mostrar.
>
> Mas se você fizer uma simples regex "^S([A-Z]|É)LECT$" ela(pcre) já
> pegaria o SÉLECT, sem problemas.. isso pode ser testado no PoC
> que segue o artigo.
>

Se voce usar o \W+ ja cobre geral

  re> /\W+/
data> Ẽ
 0: \xe1\xba\xbc
data> Ê
 0: \xc3\x8a
data> É
 0: \xc3\x89
data> é
 0: \xc3\xa9
data> È
 0: \xc3\x88
data> E
No match
data> e
No match
data>


> Mas o ponto chave é que o analista terá que criar as expressões
> na mão para incluir É,Ë,Ê e etc.. para isso ele precisa saber
> que a aplicação faz essa mudança de letras com acentos
> para sem acentos.
>

Acho que um bom regex mataria o problema . Bem sincero vou usar uma
frase do Martin Roesch do Snort "Se o atacante sabe mais da sua rede
que seu IDS ele vai bypassa-lo" ou seja, se a pessoa que administra a
maquina não conhece suas aplicações, nao sabe como tudo funciona ,
como vai colocar a maquina para trabalhar corretamente ?


> Chamo isso de "abordagem manual" no email que enviei.
> Agora, quantos analistas estrangeiros sabem desse problema?
> Qual WAF estrangeiro vem por padrão com essas letras acentuadas
> nas regras de regex?
>
> - Esse é o X da questão.E na prática, se voce for ver nenhum
> WAF vem protegido contra isso... :)
>

Mas ai que está a questão, bypass no meu ponto de vista é algo que NÃO
tem como ser detectado e isso citado tem como ser detectado , tanto
com um regex como ainda estou verificando com o profile da imperva,
sei  que no profile da pra separar caracteres especiais como essa
imagem que tenho aqui
http://img97.imageshack.us/img97/9922/impervaprofile.png e habilitar
somente o que pode e dai usando conceito de whitelist

No caso isso pra mim é desconhecimento da sua rede/aplicação pois não
da pra usar tudo de fabrica =) .

Como citei quando tiver uma caixa quero ver a normalização do Imperva
na part do Charset que comentei nos primeiros emails mas infelizmente
não to com caixas demos aqui .

> Espero ter ficado claro agora.
>

Bem sincero acho legal isso como um melhores praticas e pra alertas
pessoal de websec na hora de configurar seu WAF mas como citei pra mim
isso não é BYPASS e sim erro de configuração. Não sei a opiniao do
restante da lista =)

>
> Um abraço,
>

Abs!!!

Sp0oKeR
> Nash Leon.
>
> --- Em qui, 19/11/09, Rodrigo Montoro(Sp0oKeR) <spooker at gmail.com> escreveu:
>
>> De: Rodrigo Montoro(Sp0oKeR) <spooker at gmail.com>
>> Assunto: Re: [Owasp-brazilian] Firewalls de Aplicação WEB, Idiomas e Expressões Regulares - Condições de Bypass
>> Para: "Nash Leon" <nashleon at yahoo.com.br>
>> Cc: owasp-brazilian at lists.owasp.org
>> Data: Quinta-feira, 19 de Novembro de 2009, 17:46
>> E ai Nash ,
>>
>>
>> 2009/11/19 Nash Leon <nashleon at yahoo.com.br>:
>> > Como vai, Spooker?
>> >
>> > Vamos por mais lenha na fogueira?:)
>> >
>>
>> Bora, esse tipo de discussão sempre é sadia =)
>>
>> >> Logicamente tem que ver como esse WAF no qual
>> ninguem sabe
>> >> o nome
>> >> estava configurado.
>> >
>> > Eu acredito que qualquer firewall que faz uso de pcre
>> está vulnerável..:)
>> >
>> > De "http://gambasdoc.org/help/doc/pcre":
>> >
>> > "In PCRE, POSIX character set names recognize only
>> ASCII characters. You  can use Q...E inside a character
>> class. "
>> >
>>
>> Eu fiz um test básico aqui
>>
>> Procurando so por elementos caracteres \w+
>>
>> spooker at notsecure:~$ pcretest
>> PCRE version 7.8 2008-09-05
>>
>>   re> /\w+/
>> data> SELECT
>>  0: SELECT
>> data> sElEcT
>>  0: sElEcT
>> data> SElecT
>>  0: SElecT
>> data> Sêlect
>>  0: S
>> data> SELÉCT
>>  0: SEL
>> data>
>>
>> Dai fiz um pra pegar o que não caracter \W+
>>
>> spooker at notsecure:~$ pcretest
>> PCRE version 7.8 2008-09-05
>>
>>   re> /\W+/
>> data> SELECT
>> No match
>> data> SELECT
>> No match
>> data> SeLeCt
>> No match
>> data> SÊLECT
>>  0: \xc3\x8a
>> data> SELÉcT
>>  0: \xc3\x89
>>
>> Com sua query do paper
>>
>>  re> /\W+/g
>> data> abcd ÚNÍÔN SÉLÊCT dados FRÔM tabela--
>>  0:  \xc3\x9a
>>  0: \xc3\x8d\xc3\x94
>>  0:
>>  0: \xc3\x89
>>  0: \xc3\x8a
>>  0:
>>  0:
>>  0: \xc3\x94
>>  0:
>>  0: --
>>
>> data> abcd UNION SELECT dados FROM tabela--
>>  0:
>>  0:
>>  0:
>>  0:
>>  0:
>>  0: --
>>
>> data> abcd UNION SELECT dados FRÔM tabela--
>>  0:
>>  0:
>>  0:
>>  0:
>>  0: \xc3\x94
>>  0:
>>  0: --
>> data>
>>
>> Trabalhando uma regra pegaria isso, não vi o PCRE como
>> problema. Ou
>> esqueci de algo ?
>>
>> Ou seja, PCRE pegaria o assento não concorda ?
>>
>>
>>
>> > Obviamente que se o profissional de segurança
>> 'souber' o que está
>> > fazendo, ele vai acrescentar nem que seja manual as
>> letras com
>> > acentos. Acontece que um estrangeiro não fará isso,
>> em especial
>> > se ele conhece apenas um idioma sem acentos.
>> >
>>
>> Logicamente sempre a grande diferença, treinar os
>> analistas,  pois so
>> boas ferramentas não resolvem =) . Infelizmente maioria
>> das vezes não
>> é assim .
>>
>> > Então se o imperva faz uso de pcre.. I´m sorry, ele
>> não
>> > vai conseguir proteger as aplicações usando apenas
>> > listas como [A-Z] e nem POSIX..:(.. Mas eu conheço
>> alguns
>> > que fazem uso.
>> >
>>
>> Não tenho caixa para realizar testes, verei se alguem
>> tem  informaçoes
>> sobre as configs e certamente testarei  hehehe
>>
>> > Como voces tem um impersa disponível verifiquem
>> isso.. isso
>> > daria um belo advisore para alguém que deseja mostrar
>> algum
>> > trabalho.
>> >
>>
>> Se imperva pega e a concorrencia não é um bom marketing
>> hahahah .
>> Embora não costumo falar das falhas dos outros , produto
>> tem bastante
>> qualidade hehehe.
>>
>> >> Quanto a problemas de aplicação o pessoal
>> aproveita muito
>> >> o legado
>> >> antigo e fica aquela colcha de retalhos.
>>  Infelizmente
>> >> WAF dentre
>> >> outras dezenas de produtos de segurança não
>> fazem
>> >> milagres
>> >
>> > Bom, estamos falando de bancos de dados gigantes que
>> > removem acentos nas palavras.. Quem desenvolve sabe
>> > que os acentos são complicados de manusear em
>> sistemas
>> > de busca.
>> >
>> > Acredito que esse esquema de remover os acentos seja
>> mais
>> > comum do que imaginamos, e pelo menos as maiores
>> lojas
>> > brasileiras na internet trabalham assim, desconheço
>> > uma que não trabalhe.. Se nenhum firewall de
>> aplicacao
>> > web estrangeiro consegue lidar com isso, então
>> > essas lojas realmente não deveriam usar essa
>> solução.
>> >
>>
>> É , ta ai uma boa pesquisa de mercado a se fazer =)
>>
>> > Um cordial abraço,
>> >
>>
>> Abs!
>>
>> Sp0oKeR!
>>
>
>
>
>      ____________________________________________________________________________________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>



-- 
Rodrigo Montoro (Sp0oKeR)
http://www.spooker.com.br
http://www.twitter.com/spookerlabs
http://www.linkedin.com/in/spooker


More information about the Owasp-brazilian mailing list