Sobre uma vulnerabilidade em ...



Há um ano, 21 de março de 2019, em um programa de recompensas de bugs Mail.ru no HackerOne, veio um relatório muito bom da maxarr . Ao incorporar um byte zero (ASCII 0) no parâmetro POST de uma das solicitações da API de webmail que retornou um redirecionamento HTTP, foram vistas partes de memória não inicializada nos dados de redirecionamento, nos quais fragmentos dos parâmetros GET e cabeçalhos de outras solicitações para o mesmo servidor.

Esta é uma vulnerabilidade crítica porque pedidos incluem cookies de sessão. Algumas horas depois, foi feita uma correção temporária, que filtrava um byte zero (como se viu depois, isso não foi suficiente, porque havia a possibilidade de injetar CRLF / ASCII 13, 10, que permite manipular os cabeçalhos e os dados da resposta HTTP, isso é menos crítico. ainda desagradável). Ao mesmo tempo, o problema foi encaminhado para analistas de segurança e desenvolvedores para encontrar e eliminar as causas do bug.

O Mail.ru é um aplicativo muito complicado, um grande número de componentes front-end / back-end diferentes, tanto de código aberto (muito obrigado a todos os desenvolvedores de software livre) quanto nosso próprio desenvolvimento, podem participar da resposta. Foi possível excluir todos os componentes, exceto nginx e openresty, e localizar o problema antes de chamar ngx.req.set_uri ()em um script OpenResty, que não se comportou conforme o esperado (coloque um byte zero ou avanço de linha nos parâmetros GET de reescrever para ngx_http_rewrite_module, que, de acordo com a documentação, é usado e, ao que parece, deve funcionar da mesma maneira). Possíveis consequências foram eliminadas, a filtragem mais rigorosa foi adicionada e foi verificado que a filtragem elimina todos os possíveis vetores. Mas o mecanismo que levou ao vazamento do conteúdo da memória permaneceu um mistério. Um mês depois, o relatório de erros foi fechado conforme autorizado e a análise das causas do erro foi adiada para tempos melhores.

O OpenResty é um plug-in muito popular que permite escrever scripts Lua dentro do nginx e é usado em vários projetos Mail.ru, portanto, o problema não foi considerado resolvido. E depois de algum tempo, eles voltaram a ela para entender as verdadeiras causas, possíveis consequências e fazer recomendações para os desenvolvedores. O código fonte foi escavado por Denis Denisov e Nikolai Ermishkin . Descobriu-se que:

  • nginx rewrite directory traversal ( SSRF) , , Nginx Amplify Gixy (, , ). OpenResty , .

    :

    location ~ /rewrite {
        rewrite ^.*$ $arg_x;
    }
    
    location / {
        root html;
        index index.html index.htm;
    }




    curl localhost:8337/rewrite?x=/../../../../../../../etc/passwd
    root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
    bin:x:2:2:bin:/bin:/usr/sbin/nologin
    ...


  • nginx , , rewrite . nginx , , , , , . .

    (^@ )
    
    location ~ /memleak {
        rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
    }
    
    location / {
        root html;
        index index.html index.htm;
    }



    curl localhost:8337/secret -vv
    ...
    curl localhost:8337/memleak -vv
    ...
    Location: http://localhost:8337/secret
    ...

  • Nginx GET- rewrite GET-. nginx . POST . OpenResty GET POST , POST OpenResty .

    :

    location ~ /memleak {
        rewrite_by_lua_block {
            ngx.req.read_body();
            local args, err = ngx.req.get_post_args();
            ngx.req.set_uri( args["url"], true );
        }
    }
    
    location / {
        root html;
        index index.html index.htm;
    }
    


    :

    curl localhost:8337 -d "url=secret" -vv
    ...
    curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
    ...
    Location: http://localhost:8337/{... secret...}
    ...



O problema foi relatado aos desenvolvedores do nginx e do OpenResty; os desenvolvedores não consideram o problema como um erro de segurança no nginx, porque no próprio nginx, não há como explorar o erro através da injeção de caracteres especiais; a correção para revelar o conteúdo da memória foi publicada em 16 de dezembro. Nos quatro meses desde o relatório, nenhuma alteração foi feita no OpenResty, embora houvesse um entendimento de que era necessária uma versão segura da função ngx.req.set_uri (). Em 18 de março de 2020, publicamos as informações; em 21 de março, o OpenResty lançou a versão 1.15.8.3 , que adiciona uma verificação de URI.

Portswigger escreveu Peguei um bom artigo do OpenResty e Nginx (embora o comentário de que apenas uma pequena parte da memória seja revelada seja incorreto e enganoso, isso é determinado pelo comprimento da linha após o byte zero e, na ausência de restrições óbvias de comprimento, pode ser controlado pelo invasor).

Então, qual foi o erro e o que fazer para evitá-lo?


Houve um erro no nginx? Sim, porque um vazamento de memória é um erro de qualquer maneira.

Houve um erro no OpenResty? Sim, pelo menos a questão da segurança da funcionalidade oferecida pelo OpenResty não foi investigada e documentada.

Foi cometido um erro de configuração / uso do OpenResty? Sim, porque na ausência de uma indicação explícita, foi feita uma suposição não verificada sobre a segurança da funcionalidade usada.

Qual desses erros é uma vulnerabilidade de segurança de recompensa de US $ 10.000?Para nós, isso geralmente não é importante. Em qualquer software, especialmente na junção de vários componentes, especialmente aqueles fornecidos por diferentes projetos e desenvolvedores, ninguém pode garantir que todos os recursos de seu trabalho sejam conhecidos e documentados e que não haja erros. Portanto, qualquer vulnerabilidade de segurança surge exatamente onde afeta a segurança.

Em qualquer caso, é uma boa prática normalizar ou limitar / filtrar os dados de entrada, que vão para qualquer módulo / API externo, se não houver indicações explícitas e um entendimento claro de que isso não é necessário.

Errata


De acordo com a experiência do artigo anterior , a fim de preservar a pureza da linguagem:

uma competição de bugs - competição de caça por bugs
relatório de bugs -
redirecionamento de notificação de erro - redirecionamento de notificação de erro -
opensorsny de redirecionamento - código aberto
conhecido como errata - trabalho sobre os bugs

All Articles