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

Rodrigo Montoro(Sp0oKeR) spooker at gmail.com
Tue Nov 24 18:44:20 EST 2009


Estava montando o lab para o treinamento de snort na próxima semana e
testei uso de sélêct etc etc e o http_inspect do snort detectou o
enconding. Vejo algumas situações:

1-) Legal, o snort detectou isso embora vale salientar que IDS não é WAF =D!
2-) Os alertas de enconding do snort geralmente são ignorado pelos
adminstradores
3-) Muitos falsos positivos serão gerados visto que "Zezé de camargo e
Luciano" alertará

Abaixo Alerta + Payload

[**] [119:7:1] (http_inspect) IIS UNICODE CODEPOINT ENCODING [**]
[Priority: 3]
11/24-17:38:52.918906 192.168.0.100:38311 -> 200.234.200.133:80
TCP TTL:64 TOS:0x0 ID:58149 IpLen:20 DgmLen:519 DF
***AP*** Seq: 0xB0972F99  Ack: 0x6B03BE49  Win: 0x16D0  TcpLen: 20

[**] [119:7:1] (http_inspect) IIS UNICODE CODEPOINT ENCODING [**]
[Priority: 3]
11/24-17:38:55.810799 192.168.0.100:38313 -> 200.234.200.133:80
TCP TTL:64 TOS:0x0 ID:19857 IpLen:20 DgmLen:519 DF
***AP*** Seq: 0xB35C8054  Ack: 0x3BAC7C05  Win: 0x16D0  TcpLen: 20


Dai os payloads =)

root at notsecure:/var/log/snort# tcpdump -r tcpdump.log.1259091509 -A -s0
reading from file tcpdump.log.1259091509, link-type EN10MB (Ethernet)
17:38:52.918906 IP notsecure.local.38311 > hm856.locaweb.com.br.www:
Flags [P.], seq 2962698137:2962698616, ack 1795407433, win 5840,
length 479
E....%@. at ..O...d.......P../.k..IP...{@..GET /id=SEL%C3%8ACT HTTP/1.1
Host: www.dynsec.com.br
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5)
Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: dhtmlgoodies_tab_menu_tabIndex=index%3A%206
Cache-Control: max-age=0


17:38:55.810799 IP notsecure.local.38313 > hm856.locaweb.com.br.www:
Flags [P.], seq 3009183828:3009184307, ack 1001159685, win 5840,
length 479
E...M. at .@......d.......P.\.T;.|.P....Y..GET /id=SEL%C3%8ACT HTTP/1.1
Host: www.dynsec.com.br
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5)
Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: dhtmlgoodies_tab_menu_tabIndex=index%3A%206
Cache-Control: max-age=0

Não testei uma segunda opção que o snort tem no modo inline que seria o replace

3.7.9 replace
The replace keyword is a feature available in inline mode which will
cause Snort to replace the prior matching
content with the given string. Both the new string and the content it
is to replace must have the same length. You can
have multiple replacements within a rule, one per content.
See section 1.5 for more on operating in inline mode.
replace: <string>;

Tipo

alert tcp any any <> any 80 ( msg: "Mudança É"; content:"É"; replace:"E";)

Não tenho como testar isso agora, mas ele ja faria o trabalho porco
que a aplicação faz rsrs  =)


Happy Snorting =)

Abs



2009/11/20 Rodrigo Montoro(Sp0oKeR) <spooker at gmail.com>:
> Alguns testes não com o WAF em si  mas das aplicações e minha opinião
> geral (baseado no post). Fiz alguns regex no qual acredito que
> mitigaria o problema :
>
> Regra SELECT
>
> /(S\W+LECT|S\W+L\W+CT|SEL\W+CT)/gi
>
> re> /(S\W+LECT|S\W+L\W+CT|SEL\W+CT)/gi
> data> select
> No match
> data> seléct
>  0: sel\xc3\xa9ct
>  1: sel\xc3\xa9ct
> data> SeLêCT
>  0: SeL\xc3\xaaCT
>  1: SeL\xc3\xaaCT
> data> SÉLECT
>  0: S\xc3\x89LECT
>  1: S\xc3\x89LECT
> data>
>
>
> Regra FROM
>
> /FR\W+M/gi
>
> re> /FR\W+M/gi
> data> from
> No match
> data> frôm
>  0: fr\xc3\xb4m
> data> FRÓM
>  0: FR\xc3\x93M
> data> FRõm
>  0: FR\xc3\xb5m
> data>
>
> REGRA UNION
>
> /(\W+NION|UN\W+ON|UNI\W+N|\W+NI\W+N|UN\W+N|\W+N\W+N)/gi
>
>  re> /(\W+NION|UN\W+ON|UNI\W+N|\W+NI\W+N|UN\W+N|\W+N\W+N)/gi
> data> UNION
> No match
> data> ÚNION
>  0: \xc3\x9aNION
>  1: \xc3\x9aNION
> data> ùNioN
>  0: \xc3\xb9NioN
>  1: \xc3\xb9NioN
> data> Uníon
>  0: Un\xc3\xadon
>  1: Un\xc3\xadon
> data> UNIÕN
>  0: UNI\xc3\x95N
>  1: UNI\xc3\x95N
> data> ÚNÍÔN
>  0: \xc3\x9aN\xc3\x8d\xc3\x94N
>  1: \xc3\x9aN\xc3\x8d\xc3\x94N
> data>
>
>
> Logicamente adicionar alguns comandos como insert , update, drop,
> concat  , delete entre outros .... POREM para minha supresa o
> submarino não bastanto a normalização das vogais ele normaliza acento
> em consoante? WTF ?
>
> 1- ) Submarino
>     Fiz o teste com a palavra ṕato e o mesmo retorna monte de cd do Pato  Fu =D
>
> 2-) Americanas
>     Digitei ṕato e o mesmo retornou uns negocios nada a ver e parece
> nao ter normalizado Pato o que ainda da um chance dos regex
> adicionados aos WAF .
>
>    Tentei Uńion e GRAÇAS não normalizou tambem
>    "Sua pesquisa por: "UŃION"
>    Não encontrou nenhum resultado ."
>
> Achei até engraçado não sao do mesmo grupo as empresas? Mas isso não
> vem ao caso.
>
> Baseado nisso o que resta :
>
>
> 1-) Criar 1 regra de whitelist (o resto pode ser blacklist) para o
> campo de busca e/ou outros campos vulneraveis proibindo caracteres nao
> Ascii no geral
>     Contras: Cliente digita Zezé de Camargo e Luciano e volta tela de
> bloqueio =)
>
> 2-) Utilizar novas regras no modelo negativo adicionando os regex
> acima e o logicamente mais alguns (funcionaria americanos apenas visto
> que submarino normaliza coisa demais  =)  )
>
>
> 3-) Monitorar o Banco de Dados visto que a query seria anomala pros
> padrões da app .
>
>
> O que acham ?
>
> De qualquer forma como citei não acho isso problema do WAF (diga-se
> usar o mesmo em modo padrão e auto piloto sem tuning e customizações
> que fazem parte de um deploy de WAF), ele não pode fazer milagre em
> aplicações milagrosas com idioma pt_submarino por exemplo pq tirar
> acento de tudo .
>
> Mas seu paper é legal, abre os olhos dos analista bem como
> alternativas pro pentester em WAF em modo auto pilot =)
>
>
> Abs!
>
> 2009/11/20 Luiz Eduardo Dos Santos <luiz at imperva.com>:
>> Salve!
>>
>> Vamos lá.. como sempre, eu devo estar perdendo alguma coisa no meio do caminho aqui... então, tenham paciência.
>>
>> Vejo o problema aqui em duas partes. Uma: as operações dos bancos de dados, Outra: os caracteres com acento e tal.
>>
>> Acho que parte da discussao é se o waf ou web app vai traduzir o ÚNÍÔN SÉLÊCT, para UNION SELECT e com isso rolar um bypass e que por assinaturas poderia ser muito complicado, ou até impossível, resolver esse problema.
>>
>> É isso?
>>
>> Em termos de WAF, DEPENDENDO COMO ESTIVER CONFIGURADO, você poderia definir certo(s) campo(s) para não aceitar um ÚNÍÔN SÉLÊCT, então, não chegaria a bater na assinatura.
>>
>> Abs
>> -le
>>
>>
>>
>>
>> -----Original Message-----
>> From: owasp-brazilian-bounces at lists.owasp.org [mailto:owasp-brazilian-bounces at lists.owasp.org] On Behalf Of Rodrigo Montoro(Sp0oKeR)
>> Sent: Friday, November 20, 2009 8:48 AM
>> To: Nash Leon
>> Cc: owasp-brazilian at lists.owasp.org
>> Subject: Re: [Owasp-brazilian]Firewalls de Aplicação WEB, Idiomas e Expressões Regulares - Condições de Bypass
>>
>> Aloha ,
>>
>> 2009/11/20 Nash Leon <nashleon at yahoo.com.br>:
>>> Olá, Spooker!
>>>
>>> Voce pode criar uma regra específica para acentos.. mas o ponto
>>> em questão é que você não pode usar o conceito de 'listas' em
>>> expressão regular ou mesmo posix(quando o WAF usa pcre, por exemplo).
>>
>> Dai concordo que não se pode criar lista mas não vejo isso como um
>> problema . Vale frisar que não testamos nada alem do que voce tem
>> testado e não sabemos da normalização do charset em outros WAF . Na
>> verdade não que voce esteja certo ou errado, so quero saber exato como
>> eles estão preparados =)
>>
>>>
>>> E quando eu falo Bypass, é que por padrão costuma-se usar isso
>>> (por exemplo, lista [A-Za-z0-9]). Você usando outra coisa na regex
>>> pra detectar cai naquilo que eu falei de 'saber o que está fazendo'
>>> e não estará usando a lista pensando que nela está coberto todo
>>> o alfabeto brasileiro inclusive com acentos.
>>>
>>
>> Eu concordo que o saber o que esta fazendo é fundamental. Quem
>> trabalha mais com pentest podera ver faciltmente por exemplo em
>> IDS/IPS quantos não tem target based configurado corretamente e voce
>> pode simplesmente fazer o evasion usando o fragrouter . Mas eu ainda
>> vejo como erro de config e não bypass, mas isso é meu modo de pensar
>> =)
>>
>>> Se voce analisar todas as regras padrões do modsecurity que eh um WAF
>>> público, verá que elas detectam muito bem SQL Injection, por exemplo,
>>> mas não estão preparadas para o cenário que eu citei, logo, no meu
>>> modo de ver, o conjunto de regras 'default' do modsecurity
>>> permitem um bypass(Posso estar sendo presuncoso, mas acho que isso se aplica a todos os outros WAFs estrangeiros que trabalham em modo negativo tambem).
>>>
>>
>> Bom , eu sou daqueles que acho que o modo negativo vulgo
>> blacklist/signature base sempre serão falhos eles pegam arroz com
>> feijão .
>> Por isso saliento o modo positivo ou whitelist =) .
>>
>>>
>>> E como analista de teste de intrusão, eu "imagino" que esse tipo de bypass é muito útil, já como analista de segurança, eu acho que não devemos negligenciar esse problema.
>>>
>>
>> Concordo se voce tiver os vetores como:
>>
>> 1-) Aplicação que normaliza os caracteres acentuados (não sei exato
>> como isso é utilizado em larga escala) e isso é algo FORA de um padrão
>> de melhores praticas .
>> 2-) Estiver usando em blacklist. Usar regras padrões não atende TODOS
>> os ambientes na sua totalidade ainda mais com caracteristicas
>> especificas .
>> 3-) Deixa-lo rodando em piloto automatico , ou seja, usando tudo
>> padrão e achar que os WAF tem que conhecer todas as estruturas
>> possiveis no mundo .
>>
>> Voce já viu firewall vir configurado pra sua rede? Ou voce vai la e configura ?
>>
>> Mas certamente é um otimo ponto pra pentester bem como algo que os
>> analistas de segurança que administram/instalam WAF se atentar  =) .
>> Coisas configuradas erroneadas é o que mais se tem por ai.
>>
>> Como a empresa tem uma aplicação especifica visto isso não ser um
>> padrão mandatoriamente ele tem que criar algo especifico se for usar
>> negative model .
>>
>>> Então, o foco, o X do problema reportado não é todas as regex,
>>> mas a utilização de listas, posix e bibliotecas sem suporte
>>> ao nosso idioma. Que sao coisas 'transparentes' para os estrangeiros
>>> e quem nao manja de regex. Entao, o analista criar a lista [A-Z]
>>> e pensa que ali dentro estao todas as letras, inclusive as com
>>> acentos e ai ele comete um erro.
>>>
>>> Quanto a imagem que voce colou, não vi nela a possibilidade
>>> de colocar letras acentuadas(ÀÉÍÔÜ). Eu acho que esse WAF pode
>>> estar vulnerável, hein!:).. Note que se o desenvolver nao for
>>> flexivel ao ponto de disponibilizar a possibilidade de criar
>>> as regex na mao, fica dificil se proteger no cenario citado.
>>>
>>
>> Bom, como citei so tive a tela aqui, nao tive como testar mas acredito
>> que aquilo entre como caracteres ascii normalmente . O que acho é
>> quando eu usar whitelist, quando vier algo acentuado o sistema entende
>> como NÃO ascii e bloqueara no caso .  Mas no caso estamos falando de
>> modelo negativo .
>>
>> Criar regex no modsec, imperva isso eu sei que dá =)
>>
>> Mas certamente voce levantou uma bola bem legal sobre esse possivel
>> problema, so precisamos testar em diferentes WAF para ver exato onde
>> funciona ou não  .
>>
>>>
>>> Um cordial abraço,
>>>
>>
>> Absss!
>>
>>> 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, 19:54
>>>> 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.
>>>
>>>
>>>
>>>
>>>      ____________________________________________________________________________________
>>> 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
>> _______________________________________________
>> Owasp-brazilian mailing list
>> Owasp-brazilian at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>
>
>
> --
> Rodrigo Montoro (Sp0oKeR)
> http://www.spooker.com.br
> http://www.twitter.com/spookerlabs
> http://www.linkedin.com/in/spooker
>



-- 
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