# Exemplos de Pool de Conexões {{#include ../../banners/hacktricks-training.md}} ## Sekaictf2022 - safelist No desafio [**Sekaictf2022 - safelist**](https://github.com/project-sekai-ctf/sekaictf-2022/tree/main/web/safelist/solution), [**@Strellic\_**](https://twitter.com/Strellic_) dá um exemplo de como usar uma **variação** da técnica de **Connection Pool** para realizar um **XS-Leak**. Neste desafio, o objetivo é exfiltrar uma bandeira que aparecerá na sessão web do bot dentro de um post. Estes são os ativos que o atacante possui: - O **bot** irá **visitar** uma **URL** fornecida pelo atacante - O atacante pode **injetar HTML** na página (mas sem JS, dompurify é usado) abusando de um **CSRF** fazendo o **bot criar um post** com esse HTML. - O atacante pode abusar de um CSRF para fazer o **bot** **deletar** o **primeiro** **post** dentro da web. - Como os **posts** são ordenados **alfabeticamente**, quando o **primeiro post é deletado**, se o conteúdo **HTML** do atacante é **carregado**, significa que estava **alfabeticamente antes da bandeira**. Portanto, para roubar a bandeira, a solução proposta por @Strellyc\_ é que, **para cada caractere a ser testado**, o bot deve: - Criar um **novo post** que **começa** com a parte conhecida da **bandeira** e vários **img** **carregados**. - **Deletar** o **post** na posição **0**. - Bloquear 255 sockets. - Carregar a página com os posts. - Realizar 5 requisições aleatórias para um site (example.com neste caso) e medir o tempo que isso leva. > [!WARNING] > Se o **post deletado** era a **bandeira**, isso significa que todas as **imagens** **injetadas** no HTML estarão **competindo** com as **5 requisições aleatórias** por aquele socket **desbloqueado**. O que significa que o tempo medido será maior do que no outro cenário. > > Se o **post deletado** era o **HTML**, as **5 requisições aleatórias** serão **mais rápidas** porque não precisam competir por aquele socket com o HTML injetado. ### Exploit 1 Este é o código do exploit, retirado de [https://github.com/project-sekai-ctf/sekaictf-2022/blob/main/web/safelist/solution/solve.html](https://github.com/project-sekai-ctf/sekaictf-2022/blob/main/web/safelist/solution/solve.html): ```html
``` ### Exploit 2 Mesma tática, mas código diferente de [https://blog.huli.tw/2022/10/05/en/sekaictf2022-safelist-xsleak/](https://blog.huli.tw/2022/10/05/en/sekaictf2022-safelist-xsleak/) ```html ``` ## DiceCTF 2022 - carrot Neste caso, o primeiro passo do exploit foi abusar de um CSRF para modificar a página onde a flag está contida, de modo que tenha **muito mais conteúdo** (e, portanto, carregá-la leva mais tempo), e então **abusar do pool de conexões para medir o tempo que leva para acessar a página** que poderia potencialmente ter a flag. No exploit, você pode ver: - Abusar do CSRF - Ocupação de todos os sockets, exceto 1 - Calibrar a resposta - Começar a força bruta acessando a página potencial com a flag - A página potencial será acessada e imediatamente uma URL controlada pelo atacante também será acessada para verificar quanto tempo ambas as requisições levam. ```htmlStep 1: CSRF the admin user, to set a super long title for the flag note (LAX + POST form only possible for 2 minutes after cookies is created)
Step 2: XS-Search with connection-pool timing leak, we have to use window.open (LAX cookie)