Casa de ferreiro, o espeto não é de pau: evoluindo uma plataforma segura para competições de segurança

Abstract

Capture-The-Flag (CTF) are information security competitions. Even though they are organized by experts in the field, the platforms used to run the events are subject to vulnerabilities, just like any other software. Although literature has proposed the NIZKCTF (Non-Interactive Zero-Knowledge Capture the Flag) protocol, in which participants submit a zero-knowledge proof that they have the answers to competition challenges, the implementation of this protocol lacks usability requirements which have only been realized with its use over the years. This paper discusses lessons learned and the adaptations to NIZKCTF made by the organizers of the Pwn2Win CTF from 2017 to 2021.

Full text

Casa de ferreiro, o espeto n˜
ao ´
e de pau: evoluindo uma
plataforma segura para competic¸ ˜
oes de seguranc¸a
Lorhan Sohaky de Oliveira Duda Kondo, Bruno de Azevedo Mendonc¸a,
Andr´
e de Freitas Smaira, Paulo Matias
Federal University of S˜
ao Carlos (UFSCar)
Rod. Washington Lu´
ıs km 235 – 13565-905 – S˜
ao Carlos – SP – Brazil
{lorhan,bruno.azevedo}@estudante.ufscar.br, {afsmaira,matias}@ufscar.br
Abstract. Capture-The-Flag (CTF) are information security competitions. Even
though they are organized by experts in the field, the platforms used to run the
events are subject to vulnerabilities, just like any other software. Although li-
terature has proposed the NIZKCTF (Non-Interactive Zero-Knowledge Capture
the Flag) protocol, in which participants submit a zero-knowledge proof that
they have the answers to competition challenges, the implementation of this
protocol lacks usability requirements which have only been realized with its
use over the years. This paper discusses lessons learned and the adaptations
to NIZKCTF made by the organizers of the Pwn2Win CTF from 2017 to 2021.
Resumo. Capture-The-Flag (CTF) s˜
ao competic¸ ˜
oes voltadas `
a´
area de
seguranc¸a. Mesmo sendo organizadas por especialistas da ´
area, as platafor-
mas utilizadas para a realizac¸˜
ao dos eventos est˜
ao sujeitas a vulnerabilidades,
assim como qualquer outro software. Embora a literatura tenha proposto o pro-
tocolo NIZKCTF (Non-Interactive Zero-Knowledge Capture the Flag), em que
os participantes enviam provas de conhecimento zero de que possuem as res-
postas aos desafios da competic¸ ˜
ao, a implementac¸ ˜
ao desse protocolo carece de
quesitos de usabilidade que s´
o foram percebidos com sua utilizac¸˜
ao ao longo
dos anos. Este trabalho discute lic¸ ˜
oes aprendidas e adaptac¸˜
oes ao NIZKCTF
realizadas pelos organizadores do Pwn2Win CTF de 2017 a 2021.
1. Introduc¸ ˜
ao
Competic¸ ˜
oes de seguranc¸a cibern´
etica tˆ
em sido muito utilizadas como instrumentos edu-
cacionais em instituic¸ ˜
oes de ensino para dirigir esforc¸os de recrutamento, qualificac¸ ˜
ao
continuada e promoc¸ ˜
ao da marca de empresas ou at´
e mesmo como forma de lazer para
grupos que tratam esse tema como passatempo. Apesar desses eventos poderem ser clas-
sificados em diversos tipos, os mais f´
aceis de organizar e mais comuns s˜
ao as competic¸ ˜
oes
de Capture-The-Flag (CTF) no estilo Jeopardy.1Nesse tipo de evento, os competi-
dores tˆ
em como objetivo resolver a maior quantidade poss´
ıvel de desafios no decorrer
da competic¸ ˜
ao. Os desafios s˜
ao divididos em v´
arias categorias, tais como criptografia,
explorac¸˜
ao de bin´
arios, engenharia reversa, explorac¸ ˜
ao de vulnerabilidades web, dentre
outras. Ao resolver um desafio, o competidor toma conhecimento de uma cadeia de
caracteres conhecida como flag. A flag pode surgir, por exemplo, como resultado da
decifrac¸ ˜
ao de uma mensagem, como conte´
udo de um arquivo lido de um sistema remoto
1https://ctf-br.org/sobre

comprometido, como entrada aceita por um programa verificador de flags analisado pelos
participantes ou como texto colocado em uma p´
agina de administrac¸ ˜
ao de um aplicativo
web. Ao obter a flag, o participante deve submetˆ
e-la para uma plataforma disponibili-
zada pelos organizadores da competic¸˜
ao, a fim de obter a pontuac¸ ˜
ao correspondente `
a
resoluc¸ ˜
ao daquele desafio. Geralmente, atualiza-se essa pontuac¸˜
ao ao vivo em um placar
p´
ublico, a fim de incentivar a competitividade e a corrida por pontos das demais equipes.
As principais competic¸ ˜
oes de CTF internacionais s˜
ao atualmente reunidas no
site CTFtime,2que permite a qualquer interessado cadastrar e promover sua pr´
opria
competic¸ ˜
ao. As competic¸ ˜
oes nas quais determinada equipe obtiver seus 10 melhores
resultados s˜
ao utilizadas para computar a m´
edia ponderada da equipe, utilizada para a
ordenac¸ ˜
ao de classificac¸ ˜
ao em um placar geral, que reflete desempenho desta ao longo do
ano. Ap´
os o t´
ermino de cada competic¸ ˜
ao, o CTFtime promove uma votac¸˜
ao da comuni-
dade, cujo objetivo ´
e determinar o n´
ıvel de dificuldade e a qualidade da competic¸˜
ao. Os
votos determinam o peso que a edic¸˜
ao seguinte da competic¸˜
ao ter´
a no c´
alculo da m´
edia
ponderada para o placar geral. Qualquer equipe que tenha participado da competic¸ ˜
ao e
obtido pontuac¸ ˜
ao superior a zero pode votar. Para evitar que competic¸ ˜
oes de baixa qua-
lidade (com enunciados incompreens´
ıveis ou desafios insol´
uveis) ou de pouco interesse
(com problemas demasiadamente f´
aceis, atraindo apenas iniciantes) obtenham um peso
injustificavelmente alto, as equipes que tenham figurado entre as 50 mais bem classifi-
cadas no placar geral do ano anterior tamb´
em podem votar, mesmo que n˜
ao tenham se
inscrito ou que tenham obtido pontuac¸ ˜
ao zero na competic¸ ˜
ao.
Em 2016, cadastrou-se no CTFtime pela primeira vez uma competic¸ ˜
ao organi-
zada por brasileiros — o Pwn2Win. Esse marco foi importante pois, apesar de algumas
equipes estrangeiras j´
a terem participado anteriormente de competic¸ ˜
oes brasileiras, os
enunciados dos desafios geralmente eram disponibilizados apenas em l´
ıngua portuguesa,
e as competic¸ ˜
oes n˜
ao eram amplamente divulgadas ao p´
ublico internacional. Al´
em de
divulgar o trabalho dos brasileiros no ˆ
ambito internacional, esse movimento contribuiu
para que equipes brasileiras ficassem a par de competic¸ ˜
oes organizadas por outros pa´
ıses
e tomassem iniciativa de participar destas. Ap ´
os 2016, notou-se um aumento de equipes
brasileiras participando de competic¸ ˜
oes listadas no CTFtime [Matias et al. 2018].
O Pwn2Win ´
e atualmente uma competic¸ ˜
ao de relevˆ
ancia internacional. Em 2021,
a votac¸˜
ao do CTFtime atribuiu ao Pwn2Win o peso de 99,41%,3qualificando-a como
segunda melhor competic¸˜
ao no estilo Jeopardy do ano at´
e o momento de escrita deste tra-
balho, atr´
as somente do 0CTF, organizado pela Shanghai Jiao Tong University. Em 2020
e em 2021, o Pwn2Win obteve resultados de votac¸ ˜
ao superiores aos das qualificat´
orias
principais do DEF CON CTF, a competic¸ ˜
ao de CTF mais tradicional e antiga que se tem
not´
ıcia. Todo ano, os organizadores do DEF CON CTF escolhem algumas das principais
competic¸ ˜
oes do mundo para servirem como qualificat´
orias adicionais, convidando o pri-
meiro colocado destas para participar das finais do DEF CON CTF em Las Vegas. Em
2021, o Pwn2Win foi escolhido como uma das quatro dessas qualificat´
orias.
Este trabalho relata as lic¸ ˜
oes aprendidas pelos organizadores do Pwn2Win man-
tendo e evoluindo a plataforma de submiss˜
ao de flags no per´
ıodo entre 2017 e 2021. Em
2017, ap´
os observar casos de competic¸ ˜
oes depreciadas devido a incidentes de seguranc¸a
2https://ctftime.org
3https://ctftime.org/event/1186

em suas plataformas, o Pwn2Win optou por adotar a plataforma NIZKCTF, que utiliza
um protocolo criptogr´
afico para evitar que advers´
arios obtenham flags `
as claras caso a
plataforma de submiss˜
ao seja comprometida [Matias et al. 2018].
Desde a adoc¸ ˜
ao inicial do NIZKCTF, os organizadores do Pwn2Win observaram
diversos problemas de usabilidade, tentando san´
a-los em edic¸ ˜
oes posteriores. Os rela-
tos demonstram que mesmo quando os usu´
arios de um software s˜
ao profissionais de
seguranc¸a cibern´
etica, estes podem vir a colocar a usabilidade como prioridade em de-
trimento de propriedades de seguranc¸a. Adequar os quesitos de usabilidade sem abrir
m˜
ao da seguranc¸a pode ser um trabalho ´
arduo que exige diversos ciclos de desenvol-
vimento, principalmente quando n˜
ao houve um planejamento pr´
evio para utilizar pes-
quisas de opini˜
ao padronizadas nem demais ferramentas do estado da arte em interac¸ ˜
ao
humano-computador, obscurecendo assim os reais problemas e dificuldades enfrentadas
pelos usu´
arios.
Este trabalho relata, em ordem cronol´
ogica, as diversas tentativas de adequac¸ ˜
ao
do protocolo NIZKCTF, contrastando com variac¸ ˜
oes em indicadores coletados a partir
de opini˜
oes p´
ublicas e question´
arios anˆ
onimos direcionados aos competidores. Primei-
ramente, os organizadores tentaram manter o protocolo original, adequando somente a
usabilidade de sua implementac¸ ˜
ao. Em 2021, optou-se por relaxar algumas propriedades
de seguranc¸a, modificando o protocolo criptogr ´
afico. Com isso, alcanc¸ou-se pela primeira
vez a ausˆ
encia de reclamac¸ ˜
oes de usabilidade relacionadas ao emprego do protocolo.
Por fim, o trabalho discute como, mesmo ap´
os v´
arios anos de adoc¸ ˜
ao de um pro-
tocolo criptogr´
afico, podem surgir maneiras de utiliz´
a-lo fora dos prop´
ositos originais.
Classificar essas formas de utilizac¸ ˜
ao como ataques ou como emprego leg´
ıtimo do proto-
colo pode n˜
ao ser trivial, mesmo quando tomadas como base as opini˜
oes da comunidade.
Este trabalho relata uma instˆ
ancia desse problema observada no NIZKCTF em 2021, con-
cluindo com sugest˜
oes de modificac¸ ˜
ao do protocolo para trabalhos futuros.
2. Trabalhos relacionados
Mesmo CTFs relacionados a seguranc¸a da informac¸ ˜
ao sendo organizados por profissio-
nais ou at´
e mesmo especialistas, ´
e consenso que nenhum sistema digital ´
e completamente
livre de vulnerabilidades, de forma que ´
e de extrema relevˆ
ancia para a comunidade como
um todo a divulgac¸˜
ao das dificuldades enfrentadas na organizac¸˜
ao de um evento desse
porte (que frequentemente conta com dezenas de milhares de competidores simultˆ
aneos)
e a opini˜
ao dos envolvidos. Com isso em mente, ´
e comum a publicac¸ ˜
ao de artigos rela-
cionados a tais eventos, tanto analisando a usabilidade de uma determinada plataforma
quanto relatando as lic¸ ˜
oes aprendidas com a organizac¸˜
ao desses grandes eventos.
Em 2013 e 2014, respectivamente, foram publicados os artigos relatando lic¸ ˜
oes
aprendidas com as organizac¸ ˜
oes do picoCTF,4organizado por estudantes da Carnegie
Mellon University [Zhang et al. 2013], e do iCTF,5inicialmente organizado por um pro-
fessor da UC Santa Barbara [Vigna et al. 2014].
Em 2017, pesquisadores dos Estados Unidos propuseram uma nova gerac¸ ˜
ao
de CTFs com maior realismo, melhor custo, acessibilidade e aplicac¸ ˜
oes em educac¸ ˜
ao
4https://picoctf.org/
5https://ctftime.org/event/175

[Taylor et al. 2017].
Em 2018, foi publicado um manuscrito por integrantes de algumas entidades dos
Estados Unidos, incluindo a Universidade de Idaho, descrevendo a linguagem ADLES e o
sistema a ela relacionado visando disponibilizac¸ ˜
ao de exerc´
ıcios de seguranc¸a cibern´
etica
para uso na educac¸ ˜
ao [de Leon et al. 2018].
Desde 2018, a ENISA (Agˆ
encia de Seguranc¸a Cibern´
etica da Uni˜
ao Europeia) pu-
blica anualmente em seu site6um relat´
orio sobre o ECSC (Desafio Europeu de Seguranc¸a
Cibern´
etica) e as lic¸ ˜
oes aprendidas em decorrˆ
encia de sua organizac¸˜
ao. Em 2021 a ENISA
publicou um relat´
orio bem completo sobre eventos de CTF, mostrando o estado da arte e
pr´
aticas comuns nesses eventos.
Em 2019, pesquisadores dos Estados Unidos propuseram uma revoluc¸˜
ao no visual
das plataformas de CTF com o intuito de atrair um p´
ublico ainda maior para esses eventos
e o estudo da ´
area [Senanayake et al. 2019].
Em 2020, foram publicados artigos comparando diversas plataformas de
CTF de c´
odigo aberto quanto `
as suas func¸ ˜
oes, configurac¸ ˜
oes e utilidades
[Kucek and Leitner 2020,Karagiannis et al. 2020].
3. Metodologia
Ao final de cada edic¸ ˜
ao do Pwn2Win, enviou-se um formul´
ario aos participantes contendo
dois campos de texto livre: impress ˜
oes (impressions) e sugest˜
oes (suggestions). Para
a an´
alise dos resultados, os coment´
arios enviados como resposta aos formul´
arios foram
juntados aos coment´
arios p´
ublicos presentes na p´
agina de cada edic¸ ˜
ao do Pwn2Win no
CTFtime. Primeiramente, foram separados apenas os que fizessem alguma referˆ
encia `
a
plataforma. Em seguida, foram manualmente classificados quanto a conter elogios ou
cr´
ıticas `
a plataforma. Por fim, tamb´
em manualmente, foram agregados quando tratavam
do mesmo assunto, a fim de identificar palavras ou conceitos chave.
Em seguida, os coment´
arios foram utilizados para guiar as prioridades de desen-
volvimento e evoluc¸ ˜
ao da plataforma para a pr´
oxima edic¸ ˜
ao. As sec¸ ˜
oes a seguir apresen-
tam um resumo das opini˜
oes coletadas na edic¸ ˜
ao anterior `
a do ano indicado, seguidas das
ac¸ ˜
oes que foram implementadas como resposta a essas percepc¸ ˜
oes dos usu´
arios.
4. Pontuac¸ ˜
ao dinˆ
amica, isolamento de desafios e NIZKCTF (2017)
Em 2016, o Pwn2Win utilizou uma plataforma customizada desenvolvida em linguagem
PHP com MySQL e que n˜
ao era de c´
odigo aberto. Essa plataforma era um sistema antigo
de quando a competic¸ ˜
ao havia sido concebida, em 2014, como uma pequena competic¸˜
ao
nacional ocorrendo dentro de um evento beneficente.
Na edic¸ ˜
ao de 2016, participaram 312 equipes que resolveram ao menos um de-
safio da competic¸ ˜
ao e foram coletados 231 coment´
arios. Destes, foram identificados 6
que faziam referˆ
encia `
a plataforma. Trˆ
es coment´
arios criticavam a infraestrutura ou a
plataforma, mas n˜
ao eram espec´
ıficos quanto ao problema enfrentado e n˜
ao forneciam su-
gest˜
oes. Dois coment´
arios elogiavam a est´
etica da plataforma, ao passo que um criticava.
Um coment´
ario sugeria adicionar um filtro `
as not´
ıcias, mas sem especificar qual tipo de
filtro.
6https://www.enisa.europa.eu/publications/

Um coment´
ario sugeria que a escala de pontuac¸ ˜
ao dos desafios fosse mais linear
em func¸ ˜
ao da dificuldade dos problemas. Como resposta a essa cr´
ıtica, adicionou-se o re-
quisito de que a nova plataforma deveria utilizar pontuac¸˜
ao dinˆ
amica, em que a quantidade
de pontos de um problema decresce de acordo com o n´
umero de times que resolveram esse
problema. ´
E importante ressaltar que a pontuac¸ ˜
ao dinˆ
amica n˜
ao fornece incentivos para
que equipes resolvam determinados desafios antes das outras, pois quando a pontuac¸˜
ao
de um desafio decresce, os valores novos s˜
ao refletidos na pontuac¸ ˜
ao de todas as equipes,
inclusive as que haviam resolvido esse desafio anteriormente. A vantagem da pontuac¸˜
ao
dinˆ
amica ´
e que os organizadores n˜
ao precisam estimar a dificuldade relativa entre proble-
mas — todos iniciam com a mesma pontuac¸ ˜
ao e, no decorrer da competic¸ ˜
ao, naturalmente
ajustam-se a um valor supostamente justo, dado que problemas f´
aceis s˜
ao resolvidos por
mais times. Uma das primeiras competic¸ ˜
oes a adotar essa abordagem foi a edic¸ ˜
ao de 2017
do Google CTF,7cuja f´
ormula de c´
alculo de pontos foi adotada pelo Pwn2Win.
Outro coment´
ario fazia referˆ
encia ao fato de que alguns desafios deveriam ser
isolados, fornecendo um ambiente separado para cada equipe. De fato, em alguns tipos
de problema, a disputa por recursos computacionais compartilhados pode tornar dif´
ıcil
a resoluc¸ ˜
ao caso v´
arios participantes tentem explorar vulnerabilidades ao mesmo tempo.
Como resposta a essa sugest˜
ao, a edic¸ ˜
ao de 2017 provisionou ambientes isolados para
cada equipe, acess´
ıveis por VPN, para alguns dos desafios. Como n˜
ao existiam recursos
computacionais suficientes para fazer isso para todas as equipes inscritas, utilizou-se um
provisionador autom´
atico [Magalh˜
aes et al. 2017] que constru´
ıa os ambientes apenas para
as equipes que resolvessem pelo menos 8 dos desafios que n˜
ao eram isolados e, portanto,
estavam dispon´
ıveis para todas as equipes desde o in´
ıcio da competic¸ ˜
ao.
Por fim, um coment´
ario fazia referˆ
encia ao fato que as p´
aginas da plataforma n˜
ao
atualizavam sozinhas. A ausˆ
encia de atualizac¸ ˜
ao autom´
atica do placar e de outras p´
aginas
da plataforma era intencional na plataforma utilizada em 2016, uma vez que os organi-
zadores sabiam que se tratava de uma plataforma mal dimensionada para competic¸˜
oes
de larga escala. Mesmo sem atualizac¸ ˜
ao autom´
atica, os organizadores notaram que as
p´
aginas passaram a apresentar lentid˜
ao inaceit´
avel nos minutos finais da competic¸˜
ao,
muito embora essa lentid˜
ao n˜
ao tenha sido citada pelos participantes nos coment´
arios.
Para resolver os problemas de escalabilidade e, simultaneamente, lidar com
preocupac¸ ˜
oes de seguranc¸a, uma vez que algumas competic¸ ˜
oes haviam `
a´
epoca sofrido
ataques que levaram ao vazamento de flags ou `
a manipulac¸ ˜
ao de placar, os organizadores
optaram por migrar para o protocolo NIZKCTF proposto por [Matias et al. 2018].
O protocolo NIZKCTF consiste em apenas dois tipos de comando que um cliente,
operado por um participante da competic¸ ˜
ao, pode requisitar a um servidor, gerenciado
pelos organizadores da competic¸˜
ao:
•Cadastro de time: O cliente gera um par de chaves Ed25519 p´
ublica e privada
(pkt, skt)e, em seguida, envia pkte o nome do time tpara o servidor por meio de
um canal protegido por TLS ou SSH (em que a identidade do servidor ´
e atestada
por um certificado ou chave p´
ublica pinada).
•Submiss˜
ao de flag: O cliente computa um par de chaves Ed25519 (pkc, skc) =
KeyPair(PBKDF(φc, fc)), onde KeyPair ´
e um gerador de par de chaves deter-
7https://ctftime.org/event/455/

min´
ıstico que opera a partir de uma semente, PBKDF ´
e uma func¸ ˜
ao de derivac¸˜
ao
de chaves baseada em senhas (como scrypt ou Argon2), φc´
e um salt aleat´
orio e
p´
ublico associado ao desafio (challenge) que est´
a sendo submetido e fc´
e a flag
que comprova a resoluc¸˜
ao do desafio. O cliente verifica se pkccorresponde `
a
chave p´
ublica do desafio e, caso contr´
ario, aborta a operac¸ ˜
ao e avisa que a flag
est´
a incorreta. Por fim, o cliente gera uma prova σ= Sign(skc,Sign(skt, c)), ou
seja, assina o identificador cdo desafio com a chave privada de time e assina o
resultado dessa operac¸ ˜
ao com a chave privada de desafio. O cliente envia (c, t, σ)
para o servidor, que verifica se ambas as assinaturas s˜
ao v´
alidas e, em caso afir-
mativo, publica (c, t, σ)em uma trilha p´
ublica de auditoria e atualiza o placar para
atribuir a pontuac¸˜
ao do desafio cao time t.
Como trilha de auditoria, a implementac¸ ˜
ao original8do NIZKCTF utiliza um re-
posit´
orio Git hospedado nos servic¸os GitHub ou GitLab e configurado para n˜
ao aceitar
force pushes, de forma a evitar que o hist´
orico de alterac¸ ˜
oes do reposit´
orio seja rees-
crito. Como canal de comunicac¸ ˜
ao, utiliza-se o pr´
oprio protocolo Git (que pode operar
sobre SSH ou sobre HTTP+TLS). As tuplas (c, t, σ)s˜
ao enviadas na forma de registros
de alterac¸ ˜
ao (commits) a um fork do reposit´
orio da competic¸ ˜
ao de propriedade do parti-
cipante e, em seguida, s˜
ao submetidas como requisic¸ ˜
oes de integrac¸˜
ao (pull requests)`
a
linha principal do reposit´
orio oficial da competic¸ ˜
ao. Um robˆ
o de integrac¸˜
ao cont´
ınua atua
na figura de servidor, aceitando pull requests que validem corretamente de acordo com as
regras do protocolo e atualizando o placar da competic¸˜
ao.
Como essa implementac¸ ˜
ao usa plataformas de grande porte (GitHub ou GitLab)
para hospedar os dados consultados pelos participantes, e como o enderec¸o IP do robˆ
o
de integrac¸˜
ao cont´
ınua n˜
ao era divulgado ao p´
ublico, esperava-se obter capacidade de
atender a um grande n´
umero de acessos e at´
e mesmo resiliˆ
encia a ataques de negac¸˜
ao de
servic¸o.
5. Melhorias no cliente de linha de comando (2018 a 2019)
Na edic¸ ˜
ao de 2017, participaram 207 equipes que resolveram ao menos um desafio
da competic¸ ˜
ao. A reduc¸ ˜
ao de equipes participantes com relac¸ ˜
ao `
a edic¸ ˜
ao anterior foi
atribu´
ıda pelos organizadores `
a necessidade de se instalar um software cliente para parti-
cipar da competic¸ ˜
ao. Foram coletados 55 coment´
arios dos participantes, dentre os quais
foram identificados 12 que faziam referˆ
encia `
a plataforma. Dois elogiavam a plataforma
sem nenhuma ressalva, ao passo que um solicitava que qualquer utilizac¸˜
ao do GitHub
ou de cliente customizado fosse abolida. Um coment´
ario afirmava que a plataforma se
sobressa´
ıa (stands out), mas n˜
ao ficou claro para os organizadores se isso era um elo-
gio ou uma cr´
ıtica. Dois coment´
arios diziam que a plataforma precisava de melhorias de
experiˆ
encia de usu´
ario ou de interface com o usu´
ario, mas n˜
ao eram espec´
ıficos nem for-
neciam sugest˜
oes. Um coment´
ario dizia que o isolamento de problemas e fornecimento
de VPN era desnecess´
ario. Por fim, um coment´
ario sugeria tornar mais f´
acil compartilhar
uma mesma chave SSH para acesso ao GitHub entre diversos integrantes de uma mesma
equipe, e quatro coment´
arios sugeriam tornar mais f´
acil a instalac¸ ˜
ao da plataforma.
Os organizadores entenderam que havia insatisfac¸˜
ao com relac¸ ˜
ao `
a plataforma,
mas a maior parte das cr´
ıticas parecia estar relacionada `
a dificuldade de instalac¸ ˜
ao ou
8https://github.com/pwn2winctf/2017

adaptac¸ ˜
ao da plataforma para necessidades espec´
ıficas de determinado ambiente (por
exemplo, mapear uma chave SSH de um diret´
orio fora do padr˜
ao). Para resolver es-
ses problemas, o cliente NIZKCTF da edic¸ ˜
ao de 2018 foi empacotado nas opc¸ ˜
oes de
contˆ
einer Docker e de contˆ
einer LXC.9
A edic¸ ˜
ao de 2018 teve um decr´
escimo para 163 times que resolveram ao menos
um desafio da competic¸ ˜
ao, provavelmente devido a um conflito de datas que ocorreu com
outra competic¸ ˜
ao importante. Assim, foram recebidos tamb´
em menos coment´
arios de par-
ticipantes. De 29 coment´
arios dessa edic¸ ˜
ao, foram identificados 5 que faziam referˆ
encia
`
a plataforma. Desses, um era um elogio sem ressalvas. Dois criticavam a estabilidade
da VPN ou diziam que alguns dos desafios que foram colocados atr´
as da VPN n˜
ao preci-
sariam estar em ambientes isolados. Por fim, dois coment´
arios sugeriam que a interface
com o usu´
ario deveria ser mais amig´
avel, e um que ela deveria ser baseada em web.
Devido ao aumento de coment´
arios negativos com relac¸ ˜
ao ao uso de VPN e iso-
lamento de alguns dos desafios, os organizadores optaram por n˜
ao utilizar mais esse tipo
de infraestrutura a partir da edic¸ ˜
ao de 2019. Em vez disso, passaram a focar em tentar
tornar o isolamento desnecess´
ario e, quando n˜
ao era poss´
ıvel, passaram a utilizar filas
para dar acesso a um participante por vez aos servic¸os, utilizando mecanismos de prova
de trabalho como o Hashcash [Back 2002] para evitar que a fila fosse monopolizada por
um ´
unico participante.
Com relac¸ ˜
ao `
a plataforma para submiss˜
ao de flags, considerou-se pela primeira
vez a possibilidade de implementar um cliente web para o protocolo NIZKCTF. No en-
tanto, n˜
ao foi encontrado tempo h´
abil para realizar essa implementac¸ ˜
ao. Com isso, os
organizadores restringiram-se a implementar um script denominado dctf para facilitar
o uso do contˆ
einer Docker, a atualizar e melhorar a documentac¸˜
ao e a melhorar a redac¸ ˜
ao
das mensagens de erro.10
6. Construc¸ ˜
ao de um cliente baseado em web (2020)
A edic¸ ˜
ao de 2019 contou com 220 equipes que resolveram ao menos um desafio, ou seja,
foi a primeira vez que o n´
umero de participantes subiu com relac¸ ˜
ao `
a edic¸ ˜
ao anterior desde
2016. Antes do t´
ermino dessa edic¸ ˜
ao, os organizadores anunciaram que tinham planos
de desenvolver uma plataforma web compat´
ıvel com o NIZKCTF para a edic¸˜
ao do ano
seguinte. Dentre 26 coment´
arios coletados, foram identificados 6 que faziam referˆ
encia
`
a plataforma. Trˆ
es elogiavam o uso de Git pela plataforma, mas diziam que ela ainda
era dif´
ıcil de usar ou que ainda faltava documentac¸˜
ao. Dois diziam que n ˜
ao fazia sentido
usar o GitHub e sugeriam que o Pwn2Win passasse a usar o CTFd,11 plataforma que ´
e
utilizada em grande parte das competic¸ ˜
oes de CTF, mas que n˜
ao fornece as propriedades
de seguranc¸a do NIZKCTF. Por fim, uma pessoa dizia que n˜
ao era f˜
a da plataforma, mas
que confiava que ficaria melhor ano seguinte (dado que seria uma plataforma web).
Apesar dos coment´
arios sugerindo abolir o uso de Git, havia uma quantidade
maior de pessoas que elogiavam esse mesmo aspecto da plataforma. Desta forma, os
organizadores entenderam que a principal queixa dos usu´
arios era, ainda, com relac¸ ˜
ao ao
uso do cliente por linha de comando.
9https://github.com/pwn2winctf/2018
10https://github.com/pwn2winctf/2019
11https://ctfd.io

Assim, para a edic¸ ˜
ao de 2020, foi implementada uma vers˜
ao web do cliente
NIZKCTF totalmente compat´
ıvel com a primeira vers˜
ao do protocolo.12 Essa foi uma
mudanc¸a bastante impactante, uma vez que os jogadores n˜
ao precisavam mais instalar um
programa para participar do evento. A partir desse momento, todo o processo de prova de
resoluc¸ ˜
ao de desafio e cadastro do time foi realizado pelo navegador, ou seja, os processos
criptogr´
aficos, autenticac¸ ˜
ao com o GitHub e todas as interac¸ ˜
oes com GitHub para criac¸ ˜
ao
de forks,pull requests ecommits eram realizadas por meio do navegador do participante.
A interface gr´
afica foi desenvolvida em Vue. Para criptografia, foi utilizada a
libsodium compilada para WebAssembly. A autenticac¸ ˜
ao com o GitHub foi feita por meio
do protocolo OAuth. Os commits no reposit ´
orio de submiss˜
oes foram implementados por
meio de uma API espec´
ıfica para essa tarefa disponibilizada pelo GitHub, em vez de
usar diretamente o protocolo Git. O cliente de linha de comando j ´
a realizava as demais
tarefas relacionadas ao reposit´
orio Git por meio da API do GitHub, portanto estas foram
puramente transcritas para JavaScript. Como a API do GitHub tem restric¸ ˜
oes de Cross-
Origin Resource Sharing (CORS),13 os organizadores da competic¸˜
ao tiveram de hospedar
um pequeno servidor intermedi´
ario (proxy) para o GitHub, a fim de adicionar cabec¸alhos
permitindo a realizac¸ ˜
ao de CORS para o site da plataforma.
7. Autenticac¸ ˜
ao por senha e eliminac¸ ˜
ao do reposit´
orio Git (2021)
Na edic¸ ˜
ao de 2020, participaram 401 equipes que resolveram ao menos um desafio da
competic¸ ˜
ao. Foram coletados 60 coment´
arios dos participantes, dentre os quais foram
identificados 11 que faziam referˆ
encia `
a plataforma. Um elogiava a plataforma sem res-
salvas, e afirmava ser bom existir algo diferente do CTFd. Duas pessoas afirmavam n˜
ao
gostar da plataforma, sem especificar o motivo ou fornecer sugest˜
oes. Oito coment´
arios
criticavam o uso do GitHub.
Observou-se, assim, desconforto com relac¸˜
ao `
a autenticac¸ ˜
ao por meio do GitHub.
Grande parte das reclamac¸ ˜
oes era relacionada `
a granularidade de permiss˜
oes disponibili-
zada pelo servic¸o. A plataforma tinha acesso a outros reposit ´
orios p´
ublicos dos jogado-
res, ou seja, n˜
ao existia granularidade para garantir que projetos armazenados em outros
reposit´
orios p´
ublicos n˜
ao seriam sabotados. Apesar do c´
odigo fonte da plataforma ser
aberto, os competidores n˜
ao quiseram audit´
a-lo para ter certeza de que esta n˜
ao causaria
alterac¸ ˜
oes em seus outros reposit´
orios e tampouco podiam ter certeza de que o c´
odigo
que estava sendo executado durante a competic¸ ˜
ao era de fato o disponibilizado publica-
mente. A necessidade de usar um proxy CORS tamb´
em gerou em alguns participantes um
receio com relac¸ ˜
ao `
a possibilidade de roubo do token OAuth por terceiros que viessem a
comprometer esse proxy.
Al´
em disso, notou-se que alguns participantes preferem permanecer no anoni-
mato, sem ter que estabelecer uma ligac¸ ˜
ao entre sua participac¸ ˜
ao na competic¸ ˜
ao e suas
atividades profissionais cotidianas no GitHub ou GitLab, nem criar uma conta apenas para
participar da competic¸ ˜
ao, o que ´
e contraindicado pelos pr´
oprios servic¸os.
Reagindo a essas reclamac¸ ˜
oes por parte dos competidores, em 2021 foi imple-
mentada uma terceira vers˜
ao ainda executada a partir do navegador,14 mas em que a ne-
12https://github.com/pwn2winctf/NIZKCTF-js/tree/v2.1.1
13https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
14https://github.com/pwn2winctf/nizkctf-v2

cessidade de conta Git foi substitu´
ıda por autenticac¸ ˜
ao comum com e-mail e senha im-
plementada por meio do servic¸o de autenticac¸ ˜
ao do Firebase. Al´
em disso, substituiu-se a
necessidade de compartilhar uma chave privada entre os membros do time (para identifi-
car quem faz parte de qual time) pelo uso de uma ´
unica conta por time. Os organizadores
tomaram essa decis˜
ao pois era comum que alguns times registrassem-se com muita ante-
cedˆ
encia e perdessem sua chave privada, ou que tivessem dificuldade para compartilh´
a-la
entre os membros, gerando demanda para a equipe de suporte da competic¸ ˜
ao.
Assim, o protocolo foi simplificado para o seguinte conjunto de operac¸ ˜
oes:
•Cadastro de time: O cliente, previamente autenticado por e-mail e senha, envia o
nome do time tpara o servidor por meio de um canal protegido por TLS (em que
a identidade do servidor ´
e atestada por um certificado).
•Submiss˜
ao de flag: O cliente computa um par de chaves Ed25519 (pkc, skc) =
KeyPair(PBKDF(φc, fc)), onde KeyPair ´
e um gerador de par de chaves deter-
min´
ıstico que opera a partir de uma semente, PBKDF ´
e uma func¸ ˜
ao de derivac¸˜
ao
de chaves baseada em senhas (como scrypt ou Argon2), φc´
e um salt aleat´
orio e
p´
ublico associado ao desafio (challenge) que est´
a sendo submetido e fc´
e a flag
que comprova a resoluc¸˜
ao do desafio. O cliente verifica se pkccorresponde `
a
chave p´
ublica do desafio e, caso contr´
ario, aborta a operac¸ ˜
ao e avisa que a flag
est´
a incorreta. Por fim, o cliente gera uma prova σ= Sign(skc, t), ou seja, assina
o identificador tdo time com a chave privada de desafio. O cliente envia (c, t, σ)
para o servidor, que verifica se o usu´
ario est´
a autenticado como membro do time
te se a assinatura em σ´
e v´
alida e, em caso afirmativo, publica (c, t, σ)em uma
trilha p´
ublica de auditoria e atualiza o placar para atribuir a pontuac¸˜
ao do desafio
cao time t.
A proposta original do NIZKCTF protege contra um advers´
ario que compromete
o software da plataforma e, em seguida, envia uma resposta (de conhecimento do ad-
vers´
ario) em nome de diversos participantes, pois mant´
em a chave privada do time apenas
do lado do cliente, e assina todas as submiss˜
oes com essa chave. No entanto, isso gera
o inconveniente do participante ter que gerenciar manualmente essa chave, copiando-a
para colegas de equipe ou para outros computadores que deseje utilizar no decorrer da
competic¸ ˜
ao. Argumentamos que, caso o advers´
ario conhec¸a a resposta de um desafio, ele
pode simplesmente publicar essa resposta na internet, por exemplo na sala de bate-papo
da pr´
opria competic¸ ˜
ao, atingindo o mesmo objetivo que o NIZKCTF prop˜
oe-se a evitar,
por´
em sem a necessidade de comprometer o software da plataforma. Dada a impossibi-
lidade de proteger contra esse ataque mais simples, pode-se desconsiderar o ataque mais
complexo que NIZKCTF prop˜
oe-se a evitar, dispensando a necessidade da chave de time.
Com a remoc¸ ˜
ao do Git, tornou-se necess´
ario armazenar os dados da competic¸ ˜
ao
em algum outro meio. Para isso, optou-se por utilizar uma base de dados tradicional,
em PostgreSQL. Embora possa parecer que o requisito de um terceiro confi´
avel para a
preservac¸˜
ao do hist´
orico tenha sido quebrado, apenas houve uma adaptac¸˜
ao para um pro-
grama externo15 que periodicamente coleta dados da plataforma, realiza uma conferˆ
encia
do placar com a trilha de auditoria e, em seguida, salva uma instantˆ
anea da trilha de audi-
toria e do placar em um reposit´
orio no GitHub, atestando os commits por meio de registro
de provas de existˆ
encia em um blockchain p´
ublico [Mendonc¸a and Matias 2021].
15https://github.com/pwn2winctf/nizkctf-admin-toolkit

A existˆ
encia de um software de auditoria externo permitiu que uma falha de
implementac¸ ˜
ao do servidor web que causava ordenac¸˜
ao incorreta do placar fosse iden-
tificada e corrigida logo no in´
ıcio da competic¸ ˜
ao, antes mesmo que o suporte fosse acio-
nado pelos participantes. Como o placar apresentado pela plataforma web n˜
ao batia com
o computado pela ferramenta de auditoria, os organizadores da competic¸ ˜
ao receberam
alertas e notificaram os desenvolvedores para correc¸ ˜
ao da falha.
Com relac¸ ˜
ao aos detalhes de implementac¸ ˜
ao, houve a alterac¸˜
ao do framework uti-
lizado para o desenvolvimento da interface gr´
afica de Vue para NextJS, a fim de tentar ob-
ter p´
aginas com menor tempo de carregamento, por meio do uso de dados pr´
e-carregados.
O servidor foi inteiramente implementado em JavaScript, a fim de promover uniformi-
dade de linguagens de programac¸ ˜
ao entre cliente e servidor. O servidor foi colocado atr´
as
da Content Delivery Network (CDN) da Cloudflare, e as pol´
ıticas de cache de todos os
endpoints foram revisadas para que o cache da CDN obtivesse alto ´
ındice de acerto (74%).
A edic¸ ˜
ao de 2021 contou com a participac¸ ˜
ao de 720 equipes que resolveram ao
menos um desafio. Foram coletados 35 coment´
arios, dentre os quais 5 faziam referˆ
encia `
a
plataforma. Dois reclamaram de lentid˜
ao na atualizac¸ ˜
ao das p´
aginas, que ocorreu devido
a pol´
ıticas do lado do cliente implementadas pelo NextJS. Dois relataram a existˆ
encia de
bugs na plataforma, mas n˜
ao mencionaram quais, muito embora provavelmente estives-
sem se referindo `
as falhas de ordenac¸˜
ao do placar observadas e corrigidas logo no in´
ıcio
da competic¸ ˜
ao. Um sugeriu que uma tabela com os problemas resolvidos fosse exibida
na mesma p´
agina do placar.
8. S´
ıntese e discuss˜
ao dos resultados
Figura 1. Hist ´
orico de cr´ıticas por assunto
Detalhada ano a ano a evoluc¸˜
ao da plataforma utilizada no Pwn2Win CTF, pode-
se agora analisar o resultado dessas alterac¸ ˜
oes ao longo dos anos, por meio de um gr´
afico
mostrando a incidˆ
encia de assuntos nos coment´
arios. O gr´
afico da Figura 1, que exibe o
percentual dos coment´
arios negativos em que aparecem cada um dos assuntos destacados,
mostra como a plataforma melhorou na vis˜
ao dos competidores em t´
opicos espec´
ıficos
(filtro, pontuac¸ ˜
ao, isolamento e carregamento), especialmente depois de 2018, quando
se retirou completamente o uso de ambientes isolados. Em relac¸˜
ao ao carregamento, a
melhora se manteve na verdade somente nos anos intermedi´
arios, mas o problema voltou
a ser muito relatado em 2021, e ser´
a o pr´
oximo desafio para os organizadores em 2022.
J´
a o uso do GitHub e a usabilidade da plataforma (assuntos relacionados) tiveram
um grande aumento nas reclamac¸ ˜
oes at´
e o ano de 2020, enquanto tentava-se contornar os

problemas de forma puntual sem prejudicar o uso do protocolo, mas ainda mantendo a ne-
cessidade do uso do GitHub pelos competidores, o que fez com que as cr´
ıticas em relac¸ ˜
ao
a esse servic¸o aumentassem ao longo do tempo, chegando a 100% das reclamac¸ ˜
oes rela-
cionadas `
a plataforma em 2020.
Em 2021, quando foi retirada definitivamente qualquer interac¸˜
ao direta entre os
competidores e o GitHub e a plataforma foi inteiramente baseada em web, reclamac¸ ˜
oes
quanto `
a dificuldade de uso da plataforma ou ao GitHub em si cessaram completamente,
restando apenas cr´
ıticas quanto `
a eficiˆ
encia da plataforma e considerac¸ ˜
oes puntuais diver-
sas relacionadas a opini˜
oes individuais de alguns jogadores, estas presentes em todas as
edic¸ ˜
oes. Essa melhora na percepc¸ ˜
ao refletiu-se na pontuac¸ ˜
ao do evento no CTFTime, a
maior da hist´
oria da competic¸ ˜
ao e a segunda maior dentre todos os CTFs realizados em
2021 at´
e o momento da escrita deste artigo: 99,41%.
9. Ac¸ambarcamento de flags
Ac¸ambarcamento de flags (no inglˆ
es, flag hoarding)´
e a pr´
atica de esconder as flags
que s˜
ao encontradas ao resolver os desafios, submetendo-as apenas pr´
oximo ao final da
competic¸ ˜
ao. Algumas equipes usam essa t´
atica para deixar o primeiro colocado confi-
ante de que ningu´
em vai pass´
a-lo no placar, na esperanc¸a de que este reduza os esforc¸os
depreendidos na resoluc¸ ˜
ao de um n´
umero maior de desafios.
Na edic¸ ˜
ao de 2021, a equipe DiceGang16 utilizou a t´
atica de ac¸ambarcamento
contra a equipe uuunderflow, que at´
e pr´
oximo do t´
ermino da competic¸ ˜
ao, encontrava-se
na primeira colocac¸ ˜
ao, como ilustrado na Figura 2.
Figura 2. Evoluc¸ ˜
ao dos 10 melhores colocados no Pwn2Win 2021
Muito embora essa pr´
atica n˜
ao tenha sido mencionada nos coment´
arios coleta-
dos de participantes, posteriormente a equipe DiceGang publicou, em conjunto com a
resoluc¸ ˜
ao de um dos desafios,17 uma nota informando que eles haviam feito uso de propri-
edades do NIZKCTF para praticar o ac¸ambarcamento com maior seguranc¸a. Como o pro-
tocolo permite validac¸˜
ao offline das flags, devido `
a chave p´
ublica dos desafios ser divul-
gada logo no in´
ıcio da competic¸ ˜
ao, participantes que desejam praticar o ac¸ambarcamento
podem validar as flags com antecedˆ
encia sem submetˆ
e-las, adquirindo a certeza de que
elas ser˜
ao aceitas quando do final da competic¸ ˜
ao.
16https://ctftime.org/team/109452
17https://ctf.harrisongreen.me/2021/pwn2win/highest_power

A validac¸˜
ao offline de flags originalmente havia sido introduzida propositalmente
no protocolo NIZKCTF. O objetivo era possibilitar que as equipes conseguissem conti-
nuar participando do CTF caso a plataforma de submiss˜
ao sa´
ısse do ar pois, apesar de n˜
ao
ser poss´
ıvel submeter as flags imediatamente, seria poss´
ıvel ao menos valid´
a-las.
Para entender melhor o quanto a pr´
atica de ac¸ambarcamento era enxergada como
um problema pela comunidade, e se as vantagens proporcionadas pela validac¸˜
ao offline
eram percebidas como superiores aos riscos da pr´
atica do ac¸ambarcamento, os organi-
zadores enviaram um formul´
ario de m´
ultipla escolha anˆ
onimo aos e-mails de contato
cadastrados pelas 20 equipes mais bem colocadas no Pwn2Win 2021.
Como resposta `
a pergunta “como seu time se sente sobre ac¸ambarcamento de
flags?”, 28% responderam que “faz parte do jogo”; 36% responderam que “´
e uma con-
duta antidesportiva, mas os organizadores do CTF n˜
ao devem interferir”; e 36% responde-
ram que “´
e uma conduta antidesportiva, e os organizadores do CTF devem tentar coibir”.
Desta forma, percebe-se que se trata de pr´
atica polˆ
emica, que a maioria considera como
antidesportiva e que uma parcela significativa dos participantes acredita que os organiza-
dores deveriam tentar coibir.
Como resposta `
a pergunta “das flags que seu time encontrou durante o
Pwn2Win 2021, alguma resultou em erro de validac¸˜
ao (ou seja, vocˆ
e encontrou uma flag
falsa ou inv´
alida)?”, 8% responderam “sim”; 52% responderam “n˜
ao”; e 40% responde-
ram “n˜
ao lembro / n˜
ao sei”. No entanto, a baixa incidˆ
encia de erros de validac¸˜
ao pode ser
utilizada para argumentar tanto a favor quanto contra a validac¸˜
ao offline. Por um lado, ela
demonstra que times que desejem fazer ac¸ambarcamento ganham pouco conhecimento
adicional devido `
a possibilidade de validac¸˜
ao offline, pois quaisquer flags encontradas
provavelmente ser˜
ao verdadeiras. Por outro lado, argumenta-se que como a validac¸ ˜
ao of-
fline n˜
ao ´
e necess´
aria para ter certeza de quaisquer flags encontradas, ela n˜
ao deveria ser
permitida, pelo princ´
ıpio do m´
ınimo privil´
egio.
Como resposta `
a pergunta “os benef´
ıcios da validac¸˜
ao de flags do lado do cliente
sobrepujam os riscos relacionados ao ac¸ambarcamento?”, 12% responderam que “con-
cordam fortemente”; 16% que “concordam”; 32% que “n˜
ao concordam nem discordam”;
20% que “discordam”; e 20% que “discordam fortemente”. Desta forma, percebe-se que
a maioria dos participantes da pesquisa acredita que a plataforma n˜
ao deveria permitir a
validac¸˜
ao offline.
A fim de remover a possibilidade de validac¸˜
ao offline e preservar as demais propri-
edades de seguranc¸a do protocolo, o NIZKCTF poderia ser alterado para usar o esquema
de assinaturas Ed25519-MuSig [Maxwell et al. 2019]. Cada prova de resoluc¸ ˜
ao de um
desafio precisaria ser assinada por duas chaves de desafio, uma do cliente e outra do ser-
vidor. A chave privada de desafio do cliente poderia ser derivada de uma semente gerada
a partir da flag, exatamente como ´
e hoje, mas a chave p´
ublica correspondente n˜
ao seria
divulgada. O par de chaves de desafio do servidor tamb´
em seria mantido em sigilo. Ape-
nas a chave p´
ublica combinada de cada desafio (agregando chave de cliente e de servidor)
seria divulgada, permitindo assim a conferˆ
encia da trilha de auditoria publicada pelo ser-
vidor. Pretende-se realizar provas de seguranc¸a, implementac¸ ˜
ao e testes dessa alterac¸ ˜
ao
do protocolo em trabalhos futuros.
Por fim, al´
em das perguntas j´
a mencionadas, o question´
ario sugeriu diversas

poss´
ıveis mitigac¸ ˜
oes para o problema do ac¸ambarcamento, avaliando-as em escala Likert
[Likert 1932] (em parˆ
enteses, da forte aprovac¸˜
ao `
a forte rejeic¸ ˜
ao):
• dar bˆ
onus ao primeiro time que resolver um desafio (24%, 16%, 12%, 20%, 28%);
• ap´
os cada resoluc¸ ˜
ao, reduzir a pontuac¸ ˜
ao do desafio apenas para equipes que ainda
n˜
ao o resolveram (16%, 16%, 12%, 16%, 40%);
• limitar taxa, n´
umero de submiss˜
oes por tempo (12%, 20%, 12%, 20%, 36%);
• rotacionar flags (e.g. a cada 20 minutos) sempre que poss´
ıvel (4%, 24%, 16%,
32%, 24%);
• abolir flags convencionais, pedir aos competidores para executar um bin´
ario no
servidor de cada desafio passando o nome do time como argumento (0%, 12%,
28%, 32%, 28%);
• esconder a pontuac¸ ˜
ao e os desafios resolvidos, revelar aos times apenas sua
posic¸ ˜
ao no placar (12%, 4%, 4%, 36%, 44%);
• proibir o ac¸ambarcamento nas regras e deixar que os organizadores julguem casos
suspeitos (24%, 16%, 24%, 16%, 20%).
Dentre as mitigac¸ ˜
oes propostas, a que alcanc¸ou menor rejeic¸ ˜
ao foi a ´
ultima. Em
campo de coment´
arios aberto, alguns participantes sugeriram acrescentar a proibic¸ ˜
ao ao
ac¸ambarcamento nas regras, mas sem investigar casos suspeitos, apenas para deixar claro
que a pr´
atica n˜
ao ´
e bem vista pela comunidade.
10. Conclus˜
oes
Este trabalho discutiu a evoluc¸˜
ao da plataforma utilizada para o Pwn2Win CTF partindo
de uma plataforma implementada em PHP com MySQL em 2016, introduzindo o pro-
tocolo NIZKCTF em 2017 como ele foi proposto e melhorando sua implementac¸ ˜
ao a
cada ano, levando em considerac¸˜
ao os coment´
arios fornecidos pelos competidores de-
pois de cada edic¸ ˜
ao do evento. Demonstrou-se, assim, a dificuldade de coletar a real
percepc¸ ˜
ao dos usu´
arios, pois coment´
arios negativos relacionados ao uso do protocolo
NIZKCTF cessaram somente em 2021, quando o cliente da plataforma foi implemen-
tado totalmente no navegador e independente de interac¸˜
ao direta dos competidores com o
GitHub. Desta forma, restaram cr´
ıticas somente quanto a detalhes de implementac¸ ˜
ao, tais
como eficiˆ
encia, que poder˜
ao ser mais facilmente melhorados nas pr´
oximas edic¸ ˜
oes.
Com o uso do protocolo NIZKCTF e mitigados problemas mais fundamentais
relacionados `
a plataforma em si, outra discuss˜
ao veio a tona nas horas finais da edic¸˜
ao
de 2021 do evento, quando o time vencedor mostrou que estava usando a t´
atica de
ac¸ambarcamento de flags. Ao levantar essa pauta, a organizac¸˜
ao fez uma pesquisa quanto
`
a opini˜
ao dos times com relac¸ ˜
ao `
a pr´
atica e os resultados mostraram que a maioria dos
times a consideram uma pr´
atica antidesportiva, mas n˜
ao h´
a consenso se a organizac¸˜
ao do
evento deve ou n˜
ao tentar mitig´
a-la. O protocolo NIZKCTF fornece publicamente para
cada desafio uma chave p´
ublica que permite ao jogador saber se a flag ´
e v´
alida, de forma a
permitir auditoria do resultado, por´
em isso permite aos times praticar o ac¸ambarcamento
de flags sem risco de guardar uma flag incorreta. Em edic¸ ˜
oes futuras, pretende-se impedir
a validac¸˜
ao offline de flags por meio de novas alterac¸ ˜
oes no protocolo NIZKCTF.
Al´
em disso, em trabalhos futuros pretende-se melhorar a forma como a trilha de
auditoria ´
e atestada. Na ´
ultima vers˜
ao da implementac¸ ˜
ao, a atestac¸ ˜
ao ocorre com a con-
sulta do servidor por uma ferramenta externa em intervalos peri´
odicos. Pretende-se subs-

tituir esse mecanismo por comunicac¸ ˜
ao baseada em eventos, de forma que a atualizac¸˜
ao
da trilha seja atestada o mais r´
apido poss´
ıvel ap´
os a submiss˜
ao de uma flag.
Referˆ
encias
Back, A. (2002). Hashcash - a denial of service counter-measure. http://www.
hashcash.org/hashcash.pdf.
de Leon, D. C., Goes, C. E., Haney, M. A., and Krings, A. W. (2018). Adles: Specifying,
deploying, and sharing hands-on cyber-exercises. Computers & Security, 74:12–40.
Karagiannis, S., Maragkos-Belmpas, E., and Magkos, E. (2020). An analysis and eva-
luation of open source capture the flag platforms as cybersecurity e-learning tools. In
IFIP World Conference on Information Security Education, pages 61–77. Springer.
Kucek, S. and Leitner, M. (2020). An empirical survey of functions and configurations of
open-source capture the flag (CTF) environments. Journal of Network and Computer
Applications, 151:102470.
Likert, R. (1932). A technique for the measurement of attitudes. Archives of psychology.
Magalh˜
aes, L., Petri, A. C. F., Alves, G. d. S., Marcondes, C. A. C., and Matias, P.
(2017). Provisionamento automatizado de servidores para competic¸ ˜
oes de seguranc¸a
da informac¸ ˜
ao. In Sal ˜
ao de Ferramentas do Simp´
osio Brasileiro em Seguranc¸a da
Informac¸ ˜
ao e de Sistemas Computacionais, Bras´
ılia. SBC.
Matias, P., Barbosa, P., Cardoso, T. N., Campos, D. M., and Aranha, D. F. (2018).
NIZKCTF: A noninteractive zero-knowledge capture-the-flag platform. IEEE Secu-
rity & Privacy, 16(6):42–51.
Maxwell, G., Poelstra, A., Seurin, Y., and Wuille, P. (2019). Simple Schnorr
multi-signatures with applications to Bitcoin. Designs, Codes and Cryptography,
87(9):2139–2164.
Mendonc¸a, B. d. A. and Matias, P. (2021). Auditchain: a mechanism for ensuring logs
integrity based on proof of existence in a public blockchain. In 2021 11th IFIP Inter-
national Conference on New Technologies, Mobility and Security, pages 1–5.
Senanayake, R., Porras, P., and Kaehler, J. (2019). Revolutionizing the visual design of
capture the flag (CTF) competitions. In International Conference on Human-Computer
Interaction, pages 339–352. Springer.
Taylor, C., Arias, P., Klopchic, J., Matarazzo, C., and Dube, E. (2017). CTF: State-of-
the-art and building the next generation. In 2017 USENIX Workshop on Advances in
Security Education.
Vigna, G., Borgolte, K., Corbetta, J., Doupe, A., Fratantonio, Y., Invernizzi, L., Kirat, D.,
and Shoshitaishvili, Y. (2014). Ten years of iCTF: The good, the bad, and the ugly. In
2014 USENIX Summit on Gaming, Games, and Gamification in Security Education.
Zhang, K., Dong, S., Zhu, G., Corporon, D., McMullan, T., and Barrera, S. (2013). pi-
coCTF 2013-toaster wars: When interactive storytelling game meets the largest com-
puter security competition. In 2013 IEEE International Games Innovation Conference,
pages 293–299. IEEE.