Programa Bug Bounty

1. Sobre o programa Bug Bounty

O programa Bug Bounty tem como objetivo reforçar a segurança das aplicações e dos serviços da Vivid Money.
O programa Bug Bounty destina-se a investigadores externos que aceitem os termos e condições deste programa.
Todos os pedidos de investigadores externos são analisados individualmente.
As recompensas ao abrigo do programa Bug Bounty só são possíveis nos termos e condições descritos neste programa.
A Vivid Money reserva-se o direito de não responder a pedidos de investigação, de recusar o direito a remuneração, de solicitar informações adicionais e de alterar as regras e condições do programa.

2. Política de privacidade

Quaisquer interações no âmbito do programa Bug Bounty só são possíveis após a assinatura de um NDA (acordo de confidencialidade) entre a Vivid Money e o investigador.
Sem o consentimento escrito da Vivid Money, os investigadores estão proibidos de divulgar as vulnerabilidades descobertas, informações sobre as vulnerabilidades descobertas e quaisquer informações sobre o trabalho relacionado com a procura de vulnerabilidades nas aplicações e nos serviços da Vivid Money.
A Vivid Money reserva-se o direito de recusar pedidos de divulgação pública de vulnerabilidades encontradas nas aplicações e nos serviços da Vivid Money.

3. Âmbito para os investigadores

A Vivid Money é um ecossistema composto por várias aplicações e serviços, disponíveis através de uma interface unificada da aplicação móvel e de recursos web.
O âmbito da procura de vulnerabilidades inclui:
Os pedidos que não se enquadrem neste âmbito não serão considerados.

4. Restrições

O programa Bug Bounty limita-se apenas às vulnerabilidades técnicas e lógicas que possam existir nas aplicações e nos serviços da Vivid Money.
O programa Bug Bounty não abrange vulnerabilidades que se enquadrem numa das seguintes categorias:
  • Spam.
  • Vulnerabilidades que exijam engenharia social/phishing.
  • Comunicações de phishing e de outras técnicas de engenharia social.
  • Ataques DDOS.
  • Problemas hipotéticos sem qualquer impacto prático.
  • Vulnerabilidades de segurança em aplicações/bibliotecas de terceiros e em sites de terceiros integrados com a Vivid Money.
  • Resultados de scanners ou relatórios gerados por scanners.
  • Problemas encontrados através de testes automatizados.
  • Erros divulgados publicamente em software da Internet nos 30 dias seguintes à sua divulgação.
  • Ataques Man-in-the-Middle.
  • Injeções no cabeçalho Host sem um impacto concreto e demonstrável.
  • Self-XSS sem possibilidade de atacar outros utilizadores.
  • CSRF no início/fim de sessão.
  • CSRF e XSS sem impacto em dados sensíveis.
  • Contorno da verificação de root e jailbreak.
  • Comunicações sobre a possibilidade de engenharia reversa da aplicação móvel.
  • Informações sobre endereços IP, registos DNS e portas abertas.
  • Divulgação de informações públicas sobre utilizadores.
  • Clickjacking.
  • Comunicações sobre as desvantagens da utilização de códigos SMS.
  • A possibilidade de envio ilimitado de SMS e e-mails.
  • Comunicações de implementação incorreta do arredondamento nas conversões de transferências entre contas de liquidação, de poupança e de corretagem.
  • Falta de mecanismos de segurança recomendados sem um vetor de ataque adicional (por exemplo, cabeçalhos de segurança HTTP, flags de segurança de cookies ou proteção contra CSRF).
  • TLS ou SSL configurado de forma insegura sem um vetor de ataque.
  • Open Redirect sem um vetor de ataque adicional (por exemplo, roubo de token de autorização).
  • Substituição de conteúdo na página.
  • Vulnerabilidades que exijam a concretização de cenários complexos ou improváveis de interação do utilizador.
  • Tabnabbing.
  • Full Path Disclosure.
  • Vulnerabilidades cuja exploração exija, como condição necessária, a presença de software malicioso, permissões de root ou jailbreak no dispositivo.
  • Utilização de software desatualizado ou potencialmente vulnerável sem um vetor de ataque adicional.
  • Divulgação de informações técnicas ou não sensíveis (por exemplo, versões de produtos ou software utilizado).
  • Problemas relacionados com Cache-Control.
  • Falta de flags de segurança nos cookies.
  • Erros de UX/UI e erros ortográficos.
  • Broken Link Hijacking.
  • Problemas com a aplicação móvel:
    • o Não foi creditado cashback pela compra.
    o As funções da aplicação não estão disponíveis.
    o A aplicação móvel falha.

5. Regras e condições

5.1 Regras gerais

Ao procurar vulnerabilidades nas aplicações e nos serviços da Vivid Money, devem ser cumpridas as seguintes regras:
  • Para os testes, devem ser utilizadas apenas contas próprias.
  • É permitido utilizar as credenciais de outros utilizadores para os testes, desde que estes tenham consentido expressamente em fornecê-las.
  • A Vivid Money não disponibiliza acessos nem contas adicionais (incluindo contas de teste) para os testes.
  • São proibidas quaisquer tentativas de acesso às credenciais de outros utilizadores das aplicações e dos serviços da Vivid Money.
  • Ao procurar vulnerabilidades, é proibido violar as condições de integridade, disponibilidade e confidencialidade das aplicações e dos serviços da Vivid Money.
  • É proibida qualquer atividade que possa causar danos às aplicações, à infraestrutura, aos clientes e aos parceiros da empresa.
    Nota: exemplos de atividades proibidas: engenharia social, phishing, ataques de negação de serviço, comprometimento
  • Para confirmar a existência de vulnerabilidades, deve ser utilizado o conjunto mínimo adequado de verificações. As verificações não devem afetar outros utilizadores nem o desempenho das aplicações e dos serviços da Vivid Money
    Nota: se esta condição não for cumprida, a investigação de vulnerabilidades é estritamente proibida.

5.2 Ordem de prioridade dos pedidos

Os pedidos relacionados com as seguintes vulnerabilidades podem ser analisados com prioridade:
  • Execução remota de código (RCE).
  • Injeções (por exemplo, injeções de SQL).
  • XXE.
  • LFR/LFI/RFI.
  • SSRF.
  • Fugas de memória.
  • Vulnerabilidades de lógica de negócio.
  • IDOR.
  • Vulnerabilidades de controlo de acesso.
  • Divulgação de informações sensíveis.
  • Apropriação de contas.
  • Falta de autenticação / autorização.
  • XSS e CSRF com impacto em dados sensíveis.

5.3 Regras de teste de RCE

Durante os testes de RCE, são proibidas quaisquer ações no servidor, exceto:
  • Execução dos comandos ifconfig (ipconfig), hostname, whoami.
  • Criação de um ficheiro vazio no diretório do utilizador atual.
Todas as outras ações devem ser coordenadas com a equipa de segurança da Vivid Money.

5.4 Regras de teste de injeção de SQL

Durante os testes de injeção de SQL, são proibidas quaisquer ações no servidor, exceto:
  • Obter informações sobre a base de dados atual, a sua versão, o utilizador atual ou o nome do host.
  • Obter o esquema da base de dados, a lista das suas tabelas e os nomes das colunas das tabelas.
  • Executar consultas matemáticas, de conversão ou lógicas (incluindo com SLEEP) sem extrair dados (além dos indicados acima).
Todas as outras ações devem ser coordenadas com a equipa de segurança da Vivid Money.

5.5 Regras para carregar e ler ficheiros

Durante os testes de carregamento e leitura de ficheiros, é proibido realizar as seguintes ações:
  • Ler, alterar, modificar, eliminar e substituir quaisquer ficheiros no servidor (incluindo ficheiros de sistema).
  • Carregar ficheiros que possam causar uma negação de serviço (por exemplo, ficheiros de grandes dimensões).
  • Carregar ficheiros maliciosos (por exemplo, malware ou spyware).

6. Determinação da criticidade da vulnerabilidade

O nível de gravidade das vulnerabilidades encontradas é determinado pela equipa de segurança da Vivid Money.
Após receber o relatório dos investigadores, a equipa de segurança da Vivid Money realiza as suas próprias verificações e determina o nível de gravidade da vulnerabilidade encontrada.
Na determinação do nível de criticidade, são também tidos em conta os seguintes fatores:
  • O nível de privilégios necessário para concretizar o ataque.
  • A dificuldade de deteção e de exploração.
  • A existência de um requisito de interação com o utilizador.
  • O impacto na integridade, disponibilidade e confidencialidade dos dados afetados.
  • O impacto nos riscos de negócio e nos riscos reputacionais.
  • O número de utilizadores afetados.

7. Requisitos dos relatórios

Cada relatório deve descrever uma vulnerabilidade. As exceções são os casos em que as vulnerabilidades estão ligadas entre si ou podem ser combinadas numa cadeia.
O relatório de vulnerabilidade deve conter as seguintes informações:
  • Descrição da vulnerabilidade (pontuação, impacto, criticidade, etc.).
  • Vetor de ataque.
  • Passos de reprodução.
  • Análise da criticidade.
  • Recomendações para a correção.
  • Tipo de vulnerabilidade.
  • Capturas de ecrã ou vídeo que confirmem a existência da vulnerabilidade e demonstrem os passos de reprodução.
  • Um exemplo de um pedido formatado.
O incumprimento dos requisitos do relatório pode levar a uma redução do valor da remuneração.
Se o relatório não contiver dados suficientes para verificar a vulnerabilidade, não é efetuado o pagamento da compensação.

8. Prazo de análise do relatório

Cada relatório é analisado individualmente pela equipa de segurança da Vivid Money.
A duração da análise do relatório depende do grau de criticidade da vulnerabilidade encontrada e da carga de trabalho da equipa.
Em média, cada relatório é analisado no prazo de DUAS SEMANAS.

9. Recompensas

A recompensa é paga apenas pela descoberta de vulnerabilidades anteriormente desconhecidas.
O pagamento é efetuado mediante o cumprimento de todas as condições, regras e restrições deste programa; em caso de violação, o pagamento não é efetuado.

10. Pagamento da recompensa

A recompensa é paga apenas pelo primeiro relatório recebido sobre a vulnerabilidade encontrada.
O pagamento é efetuado desde que o relatório contenha todas as informações necessárias para confirmar a vulnerabilidade.
Quaisquer relatórios posteriores que abranjam a mesma vulnerabilidade ou contenham vetores de ataque semelhantes serão marcados como duplicados.
O valor da recompensa paga é definitivo e não negociável.
O pagamento é efetuado na condição de o investigador enviar todas as informações solicitadas na fatura. A fatura será enviada separadamente para preenchimento.

11. Contactos

As informações sobre as vulnerabilidades encontradas devem ser enviadas para [email protected].
O assunto do e-mail deve começar com a expressão [BugBountyReport]. Exemplo: [BugBountyReport]: SQL injection.