Em março de 2016, lançamos nosso programa público de recompensas por bugs. Graças ao trabalho árduo de centenas de pesquisadores de segurança, isto é o que temos visto nos primeiros 100 dias:

• Total de relatórios: 2.030;
• Taxa signal-to-noise: ~ 1: 6¹;
• Falhas de segurança encontradas e corrigidas: 161;
• Porcentagem de relatórios duplicados: ~ 20%;
• Tempo médio de primeira resposta: 23hrs, 51min;
• Total de pagamento para os pesquisadores (USD): $ 345,120.48.

Informações como essas estão disponíveis em: https://hackerone.com/uber. Esses números representam um saudável programa de recompensas por bugs. Especificamente:

• Signal to Noise: Executar um programa de recompensas leva um tempo considerável e um processamento de aproximadamente 6 submissões antes de encontrar uma questão legítima. Essa é uma relação que nos faz feliz. Isso é feito através de um agressivo low-signal filtrado através do Hacker1, um escopo de programa bem definido, e trabalhado para educar os pesquisadores;
• Tempo de resposta: Este é o tempo que uma submissão leva antes de obter sua primeira resposta do lado da Uber. Ele inclui fins de semana e feriados, e as primeiras semanas anormalmente ocupadas do programa quando ele se torna público;
• Pagamentos: Nós temos notado que problemas graves estão se tornando mais difíceis de encontrar, por isso pretendemos aumentar os nossos valores de recompensas para continuar a encorajar a investigação nessa área.

Eis um resumo de alguns dos bugs mais interessantes encontrados nos primeiros cem dias. Todos eles foram corrigidos, e verificamos que não foram previamente explorados.

Execução remota de código via Jinja Template Injection: $ 10.000

Código de execução remota (RCE, em inglês) acontece quando um atacante tem a capacidade de executar código arbitrário em um servidor. Executar um código do lado do servidor significa que o atacante tem a liberdade para fazer buscas no sistema de arquivos e executar chamadas de sistema que são acessíveis para o processo atual de execução.

Template injection é uma classe de vulnerabilidade que envolve o uso de um template de framework de funcionalidade de uma forma inesperada. Esses frameworks de modelagem muitas vezes têm a capacidade de fazer chamadas do sistema. No caso em que a entrada de usuário não confiável é fornecida a uma estrutura de modelo de forma perigosa, o resultado pode ser RCE.

Orange encontrou RCE através do template injection Jinja2 em nosso serviço que envia e-mails. Os e-mails incluem valores controlados pelos usuários, como nome, e esses valores poderiam ser mal utilizados. O serviço construía cadeias de valores controladas pelo usuário e as passava para o motor de templates Jinja2, que avaliou essa entrada como um código Python. O invasor podia executar qualquer código Python desejado, como código para ping no uber.com:

{{“”.__class__.__mro__[2].__subclasses__()[46](‘ping uber.com’, shell=True)}}

A solução é usar o método render com o template variables em vez do template de construção strings para valores controlados pelos usuários.

Cross-Site Scripting em developer.uber.com: $ 3.000

Cross-site scripting (XSS) é uma vulnerabilidade de aplicações web bem conhecida que pode ser resumida como valores controlados pelo usuário a serem incluídos em uma resposta HTTP sem codificação de saída adequada. Sem a codificação adequada, torna-se impossível para o navegador distinguir entre o código fornecido pelo servidor web e o código de um usuário mal intencionado. O impacto varia de acordo com algumas proteções de nível de navegador (HttpOnly, CSP), mas uma vulnerabilidade de XSS permite que um invasor execute qualquer ação que o usuário atual estiver visualizando na página.

Nesse caso, albinowax encontrou um caso inteligente de XSS através de templates Angular em nosso developer site, developer.uber.com, e você pode ver sua writeup para mais detalhes. O objetivo da Angular com sandboxing não é a segurança, mas muitas vezes vai um longo caminho no sentido de tornar XSS mais difícil, por isso foi um grande achado.

Bypass Surge Pricing: $ 3.000

Esse problema foi um surto de falhas. Caroneiros poderiam colocar o pin para baixo para obter um passeio de Uber, ver preços, mover o pin de fixação de preços para fora da linha, alterar o endereço para onde o seu pin inicial caiu e, em seguida, evitar o aumento de preços. O erro ocorreu porque a tarifa adicional inteiramente do lado do cliente foi calculada por padrão para precificação regular, a fim de evitar o potencial aumento múltiplo de preços out-of-date. Nós resolvemos o problema, mas isso continua sendo um grande exemplo do benefício do programa de recompensa de bugs percorrendo caminhos que não foram detectados por outros mecanismos e que bons relatórios não precisam ser sempre extremamente técnicos.

Mudanças de escopo

As vulnerabilidades com maior impacto para os serviços Uber envolvem serviços dentro de nossa infraestrutura de produção que lida com os dados dos usuários. Para garantir que os pesquisadores passem um tempo olhando para os serviços mais importantes, nós definimos explicitamente uma lista branca de domínios para o âmbito do nosso programa. A lista completa pode ser encontrada na nossa página de escopo HackerOne.

Um grande efeito dessa mudança de escopo é que na maioria das instâncias WordPress do Uber não está mais no escopo. Nossos sites WordPress – inclusive nosso blog, eng.uber.com – não estão hospedados na infraestrutura do Uber, estão em subdomínios separados e raramente contêm dados de clientes/funcionários do Uber. Das 2.030 submissões que recebemos, 16,1% foram em sites WordPress. Nós acreditamos o em ambos os lados do nosso programa de recompensas por bugs é melhor gastar no núcleo de software do uber.

Agradecemos todo o trabalho feito pelos pesquisadores, e quaisquer relatórios apresentados antes da mudança de escopo de hoje serão homenageados e premiados como trabalhar direto com eles.

Ferramentas e transparência++

Através da execução deste programa de recompensas, nós desenvolvemos algumas ferramentas para ajudar a gerar e analisar estatísticas em torno de nossos relatórios. HackerOneAlchemy é um pacote Python que interage com HackerOne e APIs Phabricator para gerar estatísticas sobre relatórios e identificar inconsistências (por exemplo, uma tarefa fechada em Phabricator cujo relatório correspondente no HackerOne está aberto). HackerOneAlchemy garante visibilidade nos relatórios que precisam de atenção extra enquanto rastreiam coisas como signal-to-noise, montante concedido, relatórios de spam, e duplicatas para nos ajudar a avaliar o sucesso do programa. Ele agora está em código aberto na nossa página GitHub, e melhorias e sugestões da comunidade de segurança são bem-vindas! Recentemente, nós também abrimos o código de um invólucro Go HackerOne, hackeroni, que pode ser usado para interagir com a API HackerOne.

A transparência é uma parte fundamental da construção de um programa de recompensas por bugs de classe mundial. Pouco tempo após o lançamento do nosso programa, nós começamos a acompanhar todas as mudanças de escopo em um repositório no GitHub para que os pesquisadores soubessem exatamente quando essas alterações seriam feitas e por quê. Isso já foi adicionado como um recurso na página de escopo do HackerOne.

Obrigado

Como sempre, nós somos gratos a todos os nossos pesquisadores. Nós encorajamos todo mundo a manter a caça ao bug e o reforço da segurança do Uber!

***

Este artigo é do Uber Engineering. Ele foi escrito por Rob Fletcher. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/bug-bounty-update/