Executando verificação de segurança...
24

Como hackei o Facebook (recompensa de $3000) e porquê LLM gera código inseguro

Como hacker ético, sigo uma regra importante: só falo sobre uma falha de segurança depois que ela for corrigida. Às vezes, isso leva meses. Felizmente, empresas como a Meta têm políticas claras para isso. Depois que o problema é resolvido, a falha pode ser divulgada com autorização — um bom equilíbrio entre segurança e transparência.

Em um fim de semana de 2024, encontrei o que parecia ser o sonho de qualquer hacker: uma forma quase mágica de acessar contas do Facebook. A equipe da Meta corrigiu tudo com agilidade.

Mas este texto não é sobre essa falha em si — é sobre o que ela representa para o futuro. Se quiser detalhes técnicos, tem um link com todas as informações.

Mesmo empresas com grandes times de segurança são hackeadas todos os dias. Isso mostra que segurança não é um destino, mas uma corrida constante contra novas ameaças. E com o crescimento das IAs que geram código automaticamente, essa corrida ficou ainda mais complicada.

Surgem então algumas perguntas inevitáveis: essas IAs pensam em segurança? Elas entendem o contexto em que o código vai rodar? (Spoiler: não.)

Na prática, esses modelos foram treinados com códigos públicos de plataformas como GitHub e StackOverflow. Mas quem garante que esses códigos estavam certos? Quem revisa se o que a IA sugere não tem falhas, backdoors ou práticas inseguras?

Muitas vezes, quem está usando a IA não tem conhecimento técnico para perceber o risco — ou pior, confia apenas porque “foi a IA que sugeriu”. Por isso, é comum que essas ferramentas gerem código inseguro.

Segurança não pode ser um pensamento de última hora. E mesmo com ajuda da IA, a responsabilidade pelo que construímos ainda é nossa.

:) valeu, devs

Carregando publicação patrocinada...
5

Meus 2 cents:

Codigo mal feito, configurações mal aplicadas, patchs nunca utilizados, usuarios inocentes, funcionarios mal-intencionados: seguranca de IT eh um pesadelo.

Dizem que se voce ver como salsichas sao fabricadas voce nao come.

Bem, se voce ver como as empresas (grandes ou pequenas) tratam sua cyberseguranca - voce provavelmente jogaria fora celulares e computares, usaria apenas dinheiro nas suas transacoes e retringiria suas compras a vendinha do bairro.

1
1
1

Posso ter entendido errado o bug, mas como pode uma bigtech, com diversos funcionários, metodologias ágeis e diversos processos ter um problema de segurança como esse?

Com certeza esse dado criptografado ai deve ser um id apenas do usuário para fazer a construção da session dele depois, em uma empresa cheia de processos como ninguém olhou e pensou que isso pode ficar sucetivel a comportamentos inesperados como o de troca de senha e tals.

De novo, posso estar errado, mas acessos como esse deveriam ser validados não dessa forma mas sim com uma tabela preparada para conter os registros de quando a pessoa fez a solicitação do login e um tempo limite para a validade disso.

1

Seu entendimento seria melhor com mais dados, mas por questão de segurança ainda não posso expor todos os detalhes. Você está correto em afirmar que deveriam fazer uma validação (foi como resolveram junto de outras questões de segurança). O token recuperado no endpoint deveria expirar por tempo e uso, e uma verificação do estado da conta (ex: mudou senha) deveria quebrar o token. Como envolve central de contas (conexão entre contas da meta) é mais complexo que lidar com um "jwt". Bugs de segurança como esse são mais comuns do que você imagina, mesmo em bigtchs.