Executando verificação de segurança...
26
obrunoanastacio
7 min de leitura ·

Eu anotei aqui todos os termos e conceitos do vídeo do YuriRDev invadindo a plataforma do Ruyter

O vídeo do YuriRDev hackeando a plataforma de cursos do Ruyter já alcançou mais de 700 mil views (até o momento de publicação desse post).

E se você está aqui, eu vou assumir que você sabe quem são YuriRDev e Ruyter, portanto, não me alongarei com apresentações.

E se você ficou boiando em vários termos e ferramentas daquele vídeo, pegue sua cerveja e se junte a nós, porque comigo foi a mesma coisa.

Então, para fins de estudo, eu fui parando o vídeo, anotando e pesquisando os termos que não conhecia, ou que, mesmo conhecendo, reconheco que são importantes. E eu estou disponibilizando isso aqui, pois pode ser de serventia para alguém.

E se você é alguém que já domina o assunto, sinta-se livre para complementar e corrigir nos comentários, conforme rege as melhores práticas da cultura colaborativa do open source. 🤓

Bora pro glossário.

1:12 GoBuster

GoBuster é uma ferramenta que ajuda a varrer diretórios de servidores web e encontrar coisas que não deveriam estar disponíveis ao público, como scripts antigos e arquivos diversos, ainda que eles não estejam disponíveis "oficialmente" por uma rota.

Se esse arquivo existe e está disponivel via uma rota (www'.'exemplo'.'com/pdf-secreto), é normal que você consiga acessa-lo, desde que não haja uma camada de autenticação o protegendo. Mas, e se você resolveu indisponibilizar esse arquivo?

Talvez você tenha apenas retirado os links do seu site, mas não tenha "matado" essa rota devidamente. É ai que o GoBuster entra: de posse de uma lista de palavras (wordlist), ele vai, na força bruta (tentativa e erro), "chutar" todos os nomes de arquivos e pastas possíveis, na tentativa de achar alguma coisa.

No vídeo, o Ruyter explica que só conhecia o endereço principal do site (ruyter"."com). Com o uso do GoBuster, ele descobre todos os subdomínios pertencentes ao site. É assim que ele encontra o subdomínio de reeembolso da plataforma, que é por onde ele começa a penetração.

1:59 Supabase e RLS

Investigando o código fonte da página de reembolso, ele descobre URLs de chamada para o Supabase, que é um serviço de Backend as a Code que, entre outras coisa, oferece funcionalidades de gestão de tabelas de banco de dados.

Uma parte importante nesses serviços é o citado RLS, Row Level Security, ou Segurança de Nível de Linha. É através disso que os administradores de bancos de dados definem papéis de acesso, ou seja, quem tem direito a ver e fazer o quê, dentro de um BD. Ou, seja, é através disso que você define quem tem direito a fazer operações de CRUD (e quais dessas operações) dentro do banco de dados.

No vídeo, aparentemente, o RLS não estava ativo, o que facilitou o acesso ao invasor à tabela que guardava os pedidos de reembolso, incluindo os contatos dos clientes que haviam pedindo os reembolsos. Dessa forma, como vemos no vídeo, foi fácil ao invasor entrar em contato com esses clientes, se passando por alguém da equipe de suportes, e assim, obtendo uma senha real de acesso à plataforma. A famosa engenharia social.

3:36 Burp Suite

Nessa etapa do vídeo, já dentro da plataforma como se fosse um usuário comum, o invasor investiga o código-fonte e descobre os papéis de acesso definidos na plataforma, como "estudante" e "admin".

Com essa informação, o invasor usa a ferramente Burp Suite para interceptar e alterar as respostas enviadas do backend. Ele usa a ferramenta para sempre mudar a definição de papel de "estudante" para "admin", e assim ele consegue ter "superpoderes" dentro da plataforma.

Agora, se passando pelo administrador da plataforma, o invasor consegue acesso a um menu exclusivo de admin, conseguindo incluir, alterar e deletar aulas e principalmente à uma opção onde ele pode inserir scripts na página sem qualquer verificação, o que, como ele mesmo deixou claro no vídeo, poderia ser utilizado para redirecionar o acesso à plataforma para endpoints de golpistas, que poderiam assim, roubar senhas e dados de cartão de crédito dos usuários da plataforma.

5:00 Falta de flag 'secure' em um token de acesso

Explicando de forma bem fula, um token de acesso é uma string codificada fornecida por um servidor de autenticação após garantir que "você é você", o que normalmente é feito via os procedimentos de login, senha e autenticação de múltiplos fatores.

Se você dar um F12 no navegador e procurar em "Aplicativos", encontrará essa string de acesso, (espero que) devidamente marcada com as flags "http only" e "secure". São essas marcações que impedem que esse token

  1. seja enviado via conexões não protocoladas por HTTPS
  2. esteja acessível para consulta via código no cliente.

Em outras palavras, essas duas flags impedem que um código malicioso injetado na página (como citado no video) capture o token que atesta a identidade do usuário e o envie para um interceptador.

Imagem

5:13 APIs "vazando" dados

O vídeo deu a entender que, ao consumir o endpoint que deveria abastecer uma seção de comentários da plataforma, a API retornava dados como telefones, CPF, emails e nomes completos dos usuários.

Pelo que pesquisei, a OWASP fala sobre risco de exposição excessiva de dados, onde o backend confia ao frontend a filtragem dos dados recebidos, enviando mais dados que o necessário para uso.

APIs confiam em clientes para ações de filtro de informação. Desde que APIs são utilizadas como fonte de informações, algumas vezes os desenvolvedores as implementam de maneira genérica sem considerar o quão sensíveis são os dados que elas expõem. Ferramentas de análise automatizada geralmente não podem detectar este tipo de vulnerabilidade em razão de ser difícil da legitimidade dos dados retornados pela API, e dados considerados sensíveis não devem ser retornado sem uma profunda análise e compreensão da aplicação. (OWASP)

O recomendado, neste caso, é um mapeamento eficiente para enviar apenas dados necessários ao bom funcionamento das interfaces de usuário, e também um bom mapeamento para identificar e tomar decisões a respeito de dados sensíveis. Lembrando que aqui no Brasil a LGPD define o que são "dados pessoais" e "dados sensíveis".

Conclusões

  1. O vídeo mostra como muita manipulação foi feita do lado do cliente, bastando o invasor conseguir o acesso às credenciais. O OWASP nos alerta sobre a necessidade de uma validação de dados robusta, tanto no lado do cliente como no lado do servidor. Lembrando que o servidor não pode confiar tão prontamente na solicitação do cliente, pois ele nunca sabe se realmente é o cliente ou um invasor quem está solicitando.
  2. O vídeo mostrou que uma invasão bem sucedida é resultado de várias vunerabilidades aninhadas. O invasor abriu a caixa de pandora encontrando uma rota mal protegida, mas precisou encontrar mais e mais vulnerabilidades para alcançar seu objetivo, o que me faz pensar que todas as etapas de desenvolvimento precisam de atenção.
  3. Como usuário, é sempre importante alertar como, no vídeo, o invasor conseguiu obter login e senha de um usuário tão facilmente. Fica o alerta para nós e para os nossos familiares. Quando estamos nessa jornada como a de reembolso, onde estamos fragilizados, em dúvida se e quando receberemos nosso dinheiro de volta, viramos alvos fáceis de golpistas que podem entrar em contato conosco se passando por funcionários e abocanhando nossos dados. Atenção.
  4. Fiquei com a impressão de que a falta de configuração das RLS foi a vulnerabilidade mais importante, pois foi ali que ele teve acesso a informações dentro do BD que, normalmente, são restritas até mesmo a alguns papéis de administradores do sistema. Alguém que entende bastante de segurança: estou certo? Pergunta sincera.

Eu tenho fortes opiniões à respeito do tal Ruyter, mas elas não importam agora. Como desenvolvedor, me importa mais entender se as aplicações que eu desenvolvo diariamente estão tão expostas a invasores quando a demonstrada no vídeo. Eu mesmo, terminei esse estudo entendendo que preciso estudar e entender mais sobre segurança. Espero que você tenha chegado a mesma conclusão.

Lembrando que este é um post que pode ser construído a muitas mãos. Comentem, critiquem, sugestionem. Meu objetivo não é dar aula de segurança à ninguém, e sim compartilhar o que estou aprendendo.

Carregando publicação patrocinada...
7
Pilati

Fiquei com a impressão de que a falta de configuração das RLS foi a vulnerabilidade mais importante

Não, não foi, eu trabalho há mais de uma década com banco de dados e jamais configurei RLS.

O maior problema é o banco ser acessado do front.

Se fosse usa a arquitetura padrão:

Front-end <----> Back-end <----> DB

Jamais vai acontecer um vazamento de dados nessa proporção (a menos que você faça uma cagada muito grande, tem que realmente se esforçar)

É basicamente essa onda de saas em cima de saas que gerou todo esse problema.

O segundo maior problema:

mudar a definição de papel de "estudante" para "admin"

Como ******** uma plataforma não faz uma validação BACKEND do papel do usuário?

essa simples troca de papel é alvo frequente de hackeamento de plataforma vibecoder

é simplesmente tu abrir a porta da tua empresa pra qualquer um se auto-declarar funcionário.

1
maiaravericimo

A Configuração do RLS deve ocorrer em que situação?
Se a plataforma não fez uma validação de BACKEND do ''papel do usuário'', está errado por lei?

Porque se uma pessoa que tem conhecimento prévio disso tudo e caiu nesse curso, a pessoa merece ganhar um belo processo né?

1
Pilati

A Configuração do RLS deve ocorrer em que situação?

Multitenant:

Ex. um serviço em que diversos e-commerces compartilham o mesmo banco de dados

Controle de acesso:

Quando determinados usuários podem acessar as informações do DB, ex: só admin pode ver os usuários

LGPD

Esconder informações dos usuários.

RLS é uma alternativa pra fazer tudo, mas geralmente dá muito mais trabalho que fazer direto na aplicação. pode ser muito útil em ambientes com diversos microserviços utilizando o mesmo banco de dados.

Se a plataforma não fez uma validação de BACKEND do ''papel do usuário'', está errado por lei?

A lei é o menor dos problemas, o cara tava com acesso de apagar o DB inteiro hahahahah

Porque se uma pessoa que tem conhecimento prévio disso tudo e caiu nesse curso, a pessoa merece ganhar um belo processo né?

Como você vai processar alguém que não mora no Brasil?

1
1
maiaravericimo

''essa onda de saas em cima de saas que gerou todo esse problema''

quais problemas?
você pode me explicar com detalhes e quais motivos?
gostaria de aprender melhor, porque eu também quero criar um saas futuramente....

Fiquei curiosa com essa afirmação sua...

(O banco ser acessado do front), é algo ruim? Qual é o certo?

4
Pilati

Foi a galera vendedora de curso que popularizou a arquitetura de usar serviços free.

Supabase pra DB, vercel pra front, nada de back, essa mania de separar a aplicação em locais diferentes, procurando plataformas "grátis" que te apunhalam pelas costas quando vc menos espera.

São ferramentas incríceis? até que são, mas a facilidade que elas oferecem tem um trade-off que custa muito

como exemplo o supabase. Nada mais é que um postgres com uma interface bonitinha. (sim, todas as funções que ele oferece tem no postgres.)

Qual o custo de você não precisar configurar o DB? planos EXTREMAMENTE CAROS se você atingir o limite.

Sim, é muito mais caro que vc pegar uma máquina na cloud e configurar.

A vercel a mesma coisa, lembro de quando eles mudaram a política de cache e a fatura do Tabnews ia subir pra MILHARES DE REAIS

(O banco ser acessado do front), é algo ruim?

imagina assim, o banco de dados é como uma biblioteca gigantesca que tem alguns documentos oficiais, o backend são os atendentes e seguranças.

O banco de dados ser acessível do front é tipo "entra aí e pega os documentos que tu precisar, vamos confiar que você não vai pegar nenhum que não pode"

O banco de dados ser acessível só do backend obriga ao usuário perguntar o que precisa aos atendentes. Eles só vão entregar os documentos que o usuário tem acesso, e não vão deixar ele se passar poroutra pessoa.

(Se o código for construído certinho, claro)

Qual é o certo?

O certo NA MINHA OPINIÃO é fugir totalmente do que vendendor de curso fala, e de todo o hype.

Qual empresa realmente grande que usa supabase e vercel? não conheço nenhuma.

1
2
kht

(O banco ser acessado do front), é algo ruim? Qual é o certo?

O código que acessa o banco precisa da URL/porta, usuário e senha. Se isso está no frontend, então é fácil para qualquer um obter essas informações. Afinal, o código do frontend é baixado pelo browser e qualquer um que saiba mexer no developer tools vai conseguir encontrar.

E não é só isso: o frontend roda no browser, então se ele acessa o banco diretamente, quer dizer que o servidor do banco de dados está aberto na internet. Qualquer um de qualquer lugar consegue acessá-lo diretamente. E uma vez tendo acesso, qualquer pode rodar qualquer query que quiser.

Pior, nesse caso o código do frontend terá algumas queries, então vc também está entregando de mão beijada a estrutura do banco (nomes das tabelas e colunas), o que facilita muito ataques de SQL Injection. Sem contar que facilita o vazamento de informações, pois basta fazer SELECT * em todas as tabelas para obter todos os dados. Se o usuário tiver permissão de UPDATE ou DELETE então, imagine o estrago que ele pode fazer...

Agora se existe um backend no meio, o acesso é mais controlado.

O frontend acessa o backend via rotas previamente configuradas, como por exemplo http://servidor.com/api/fazAlgo. E essa URL fazAlgo executa o respectivo código que acessa o banco, mas rodando somente as queries que foram programadas no backend.

O frontend não precisa (e nem deve) saber os dados de acesso ao banco, pois isso fica escondido lá no backend. O frontend não fica sabendo quais queries rodaram, nem o nome das tabelas e colunas envolvidas (pois o backend pode retornar apenas parte das informações, e não necessariamente refletem a estrutura do banco, pois ele pode formatar os dados antes de retorná-los, juntar informações em um campo só, etc).

Mesmo se o backend fizer um UPDATE ou DELETE, também é mais controlado, pois ele pode restringir quais informações podem ser alteradas ou apagadas, em vez de permitir queries que apaguem qualquer coisa.

O backend pode controlar o acesso, retornando erro caso o usuário não tenha permissão para acessar/modificar/apagar aqueles dados, pode aplicar restrições (só pode consultar X registros a cada Y minutos, pode limitar a quantidade de requests por segundo para evitar ataques de DDOS, etc), pode usar cache para determinados dados (não onerando desnecessariamente o banco), etc etc etc. Além de fazer outras validações e melhorias, como higienizar/validar os dados antes de mandar pro banco, tratamento para evitar SQL Injection, usar um pool de conexões (em vez de cada cliente abrir uma nova conexão do seu browser) e por aí vai.

O código do frontend pode até fazer essas coisas, mas como vc já entregou os dados de acesso ao banco e a estrutura dele, qualquer um vai poder passar por cima de tudo isso, acessando o banco diretamente e rodando as queries que quiser.

Agora se o frontend só acessa o backend (o único que está aberto na internet), e o backend é o único que acessa o banco (cujo servidor não precisa ficar exposto na internet), e claro, supondo que o backend foi bem feito, aí vc elimina (ou pelo menos minimiza bastante) esses problemas.

2
1
maiaravericimo

Eu amei saber disso, nem quero fazer esse passo a passo, mas isso me lembra desde quando os ''lançamentos'' surgiram no Youtube, como forma de atrair os clientes do instagram onde está o público aquecido daquela pessoa.

Isso me fez decidir que comprar cursos não vale mais a pena, especificamente por conta dessa falha enorme, imagina quando começou surgir vários lançamentos desde 2012 na internet, será que houve esse erro, já sabemos que nossos dados estão sempre vazando, esse pode ser um dos buracos mais perigosos onde muita gente cai com facilidade.

Diante disso, aconselho a maioria investir em mentoria individual somente com o profissional X, fazer call só com o mentor e pronto.

Só de pensar nessa frase: Como usuário, é sempre importante alertar como, no vídeo, o invasor conseguiu obter login e senha de um usuário tão facilmente. Fica o alerta para nós e para os nossos familiares. Quando estamos nessa jornada como a de reembolso, onde estamos fragilizados, em dúvida se e quando receberemos nosso dinheiro de volta, viramos alvos fáceis de golpistas que podem entrar em contato conosco se passando por funcionários e abocanhando nossos dados. Atenção.

Isso redobra a nossa atenção para tudo, é uma pena que a grande população não tem conhecimento que os nossos direitos de contratar um bel advogado seria a única saída, porque ninguém merece ficar caindo em golpe, já basta o nosso país, o dono do Banco Master está ai pra provar por trás de tudo e o que vai acontecer pela frente.