BSides 2025 SP - SELECT * FROM code WHERE input != ‘sanitized’

Alo.

Obrigado.

Boa tarde, pessoal. Eh, meu nome é Jardel. Eu vou falar aqui sobre essa talk nome muito estranho que parece uma carry, parece não, né? É uma carry SQL. E a gente vai entender um pouquinho e o porquê, né, o intuito de eu ter colocado o nome, esse nome aqui na talk, né? Então, vamos lá. Eh, só uma pequena apresentação, né, quem eu sou. Então, eu sou do interior do Ceará, lá de Jaziro do Norte. Sempre gosto de frisar de onde eu vim, da terrinha, né? Eu sou engenheiro de software, minha profissão é engenharia de software já há muitos anos e mas na verdade no fim das contas a Infosc e Cyber Security é a minha

paixão, minha grande paixão e eu sempre tô nos eventos palestrando ou organizando campeonatos de CTF. E eu também sou um, digamos, entusiasta de pesquisa de vulnerabilidades, né? Não sou o maior especialista disso, mas estudo bastante e já encontrei algumas falhas, algumas CVs e eh sonho em um dia trabalhar e ser a minha profissão, isso, né? Eh, só que eu tenho algumas coisas que eu também me dedico, né? Então, por isso que eu não posso me dedicar totalmente a pesquisador. Eu sou um cfundador também do Raking Cariri, uma comunidade de hacking que estamos organizando o CTF aqui da BSIS este ano, o ano passado também. Eh, sou um carinha de TI mais ou menos competente aí, né?

Tento me esforçar para poder estudar. Eu tô um pouco nervoso, só para poder quebrar o gelo. Eh, a minha, um fato curioso, a minha cachorrinha, ela me ajuda nos estudos, né? Então, sou tão nerd que o nome dela é Ada Lovelas, então primeira programadora da história. Então, ó, eu tava fazendo o PR programming aqui, ela tava revisando o código comigo. Então, ela minha companheira aí nos estudos e nas pesquisas. Mas antes de eu falar de fato do que a gente vai ver aqui, que é da ferramenta, eh eu queria dar alguns passos para trás primeiro pra gente poder entender lá na frente, né? Então acho isso muito importante a gente sedimentar o nosso conhecimento agora. E o intuito que a

gente tá falando vai ser dessa talk vai ser sobre pesquisa de vulnerabilidades. Então é bom primeiro a gente começar e definir o que é para quem não entende ou para quem ainda tem um pouco de dúvida o que seria. Então, o processo de pesquisa de de vulnerabilidades é um é um processo aonde você vai analisar um protocolo, um software, um algoritmo, né, de algum produto relacionado, por exemplo, pode ser um Windows, o sei lá, o Linux ou qualquer um outro. E ele não necessariamente envolve apenas engenharia reversa, mas inúmeras outras técnicas, como por exemplo code review, análise estática, análise dinâmica e também fuzing, debuging e vários outros. Então o processo de pesquisa e vulnerabilidades vai utilizar

basicamente tudo isso que a gente vai que a gente tem aqui de possibilidade de ferramentas e técnicas, né? Gên reversa, fuzing, debug e tudo mais. Então, eh, esse é o a definição. Eh, e aí a gente pode fazer isso de várias formas, como foi comentado, né? A gente pode, por exemplo, num contexto de engenharia de software, que é o meu caso, né, enquanto profissão ali do dia a dia, é utilizar a modelagem de ameaças, encontrar falhas e vulnerabilidades numa aplicação antes dela ir pra produção. Esse é o objetivo da do threat modeling, tá? Na modelagem de ameaças. E existem, a mais conhecida é o stride, né? Ali tá EX. Ali eu botei tudo em inglês, mas ali o EX ficou em

português. Mas o stride é a ferr é a técnica mais conhecida de modelagem de ameaças criada pela Microsoft, onde você utiliza ele para uma gama de possibilidades de encontrar vulnerabilidades antes do código e paraa produção. Isso é mais no contexto de genera de software, mas eu coloquei aqui também. Tem outras formas, como por exemplo, eh, code auditing, né? Então, algumas ferramentas ali mais eh ativas, né, no seu código enquanto você tá desenvolvendo, como por exemplo, o Slink Plugin Security, o Bandit, que é para Python, Gosec, que é para Goleng e inúmeras outros. Como eu falei, tem análise dinâmica também, então a maior parte deles ali vai ser fuzing e debugging também. Então, é um isso só isso aqui de fuz,

debug dá só uma talk, mas inúmeras outras de cada técnica, ferramenta e outras coisas que dá para fazer. Mas o nosso foco tá até em aqui, é análise estática de código. E tem inúmeras inúmeras coisas e ferramentas que a gente pode utilizar, como por exemplo, softwares de composição de análise de composição de software, code QL, que é o que a gente vai ver, esse é o nosso principal foco de estudo aqui hoje, sem grip e sonar cube também. Então, eh, agora com algumas definições, vamos só mais algumas outras e aí a gente vai chegar no conteúdo de fato. E aí, o que que é a análise estática de código? A análise estática de código, ela se refere à prática de você utilizar

ferramentas para destacar vulnerabilidades de forma estática num código, né? onde você não vai de fato rodar o programa e mandar vários payloads lá de esclion, de command injection, alguma coisa do tipo. Você vai pegar o código estático, como sei lá, clonou do repositório do GitHub e ele vai e clona esse repositório. Então ele vai utilizar inúmeras técnicas para isso, como por exemplo tent analis e o data flow analysis, né, o fluxo dos dados naquele programa. E o T análise, a gente vai entender aqui de uma forma mais prática eh o que que ele é e porque que ele é muito importante. Realmente ele é muito importante para eh análise estática de código voltado para vulnerabilidades.

Então, eh quando a gente pensa em buscar alguma vulnerabilidade, por exemplo, vamos pensar em uma falha que é muito comum e que tá aí há muitos anos, né? Esquela injection, acho que é a falha mais manjada de do mundo, digamos assim. Eh, no SQL Injection a gente tem que ter um padrão e com esse padrão a gente consegue fazer essa análise estática, né? a gente consegue, digamos, entre aspas, procurar no código por strings que estão concatenadas com uma o input controlado pelo usuário. Esse é o principal padrão que a gente tenta identificar num análise estática, strings concatenadas que são controladas pelo usuário. Então, se a gente for imaginar isso, entre aspas, digamos que a gente queira fazer isso manualmente,

eu posso ir lá no código, né? Eu clonei um repositório de algum projeto open source, clonei um repositório e procuro, entre aspas, tá? Uma coisa bem rudimentar aqui, aspas duplas, aspas simples, mais isso representaria o quê? Aqui, ó, select, aspas duplas, aspas simples, mais e um input. Beleza? Uma coisa muito rudimentar isso, mas é um padrão que a gente sabe que a gente consegue identificar e isso é o que a análise estática faz. Tenta identificar esses padrões aqui, tá? O principal padrão, né, de um SK injection. Existem outros, existe do Cle injection e várias outras outras formas. Mas vamos definir aqui o padrão que é uma string concatenada em cares SQLs que são mandadas ao banco de dados

sem validação. Então já temos um padrão em mente, já sabemos o que procurar se a gente fosse fazer uma análise estática de código buscando SQL injection. Mas vamos ver outros exemplos também. Vamos ver um buoofer overflow, né? Um estouro de de buffer ali. Pode ser na pilha, na hip, qualquer um outro. Eh, qual que é um padrão de código aqui? Tá um padrão vulnerável. é uma string que é recebida pelo usuário como parâmetro e ela é copiada para esse buff com a função strop. Só que a função strop ela não faz bound checking, ela não faz o a verificação de tamanho pra string que ela tá copiando para o pra variável de memória. Então se eu mandar uma um input

maior do que ele vai receber na string, ele vai creschar, vai quebrar a aplicação e isso permite até a execução de código remoto em muitos casos. E aí, não só esse, mas inúmeras outras funções do C não fazem bound checking. A gente vê exemplo de bufferflow por aí, não é só de STCOP, mas existem números números outros, SN, print F, gets, FGS e vários outros. Então, eh, o como é que a gente pode definir esse padrão? Utilização de funções que não fazem bounding em uma variável de tamanho limitado. Esse é o nosso padrão. E vão guardando esses padrões aí para quando a gente chegar numa parte um pouquinho mais prática. que a gente vai ver como utilizar isso

para procurar esses padrões em um código. Então, a gente já vê o dois, eu vou mostrar mais dois aqui para vocês. Esse, essa falha não é tão conhecida, mas é muito comum em linguagens que têm o tipo de herança por protótipo e o principal que usa esse tipo de herança é o JavaScript. Então essa falha de prototype pollution, ela permite você eh em alguns casos fazer execução de código remo remoto, mas em todos os outros fazer pelo menos um DOS na aplicação. Então eu consigo com payload ali malicioso e especialmente construído, quebrar a aplicação, eh, em, enfim, em qualquer lugar e alguns casos execução de código remoto. Por exemplo, a gente vai ver uma falha aqui que foi

descoberta esse ano no Kibana, né? é uma ferramenta muito utilizada aí pelo pessoal de, enfim, de engenharia de software e tal. Eh, e ela tinha uma falha de em uma, não só uma falha, inúmeras falhas de SK de de prototype pollution e ela permitia a execução de código remoto. Então, vamos definir também para o prototype pollution qual seria o padrão de que a gente pode possibilizar em um código. Então, é a o a atribuição a um atributo de forma insegura em um objeto que herda do objecte. Então esse é o tipo de definição de prototype, é um pouquinho mais complexo, mas eh é essa, digamos, é a definição que a gente pode usar. Então vamos ver agora, por exemplo, eu acho

que é o tem mais tem essa e vai ter mais outra. Então, por exemplo, aqui o ridócio também é uma falha não tão conhecida, aonde a gente tem o padrão de uma rejex extremamente complexa. E vocês podem acreditar que não, mas essa rejex é complexa e ambígua não pra gente, mas pra ferramenta que vai fazer a interpretação dessa rejex e validar ela com a entrada do usuário, né? E aí, qual o padrão disso? é uma rejex excessivamente complexa e ineficiente que é processada por uma enginex que permite backtrack. Então é uma outra falha também bem específica, mas que ela eh também essa esse tipo de falha aqui só causa DOS em aplicação, ela não permite execução de código remoto, tá? E

a última aí, não menos importante, que a gente também vê muito por aí, é o commandjection, onde você consegue e injetar comandos em uma aplicação que faz o processamento daquele input. Então, por exemplo, aqui eu tenho uma aplicação que ela recebe um argumento da função main e concatena com o comando, né, e faz e manda pro system sem uma validação eh direta ali. Então, qual seria o padrão disso? o uso de um input concatenado com comandos de sistema operacional. Então, por exemplo, a gente vê aqui que ele vai concatenar com esse cara aqui, com o o Cats, né, que é do Linux. Beleza? Isso foram alguns padrões que a gente definiu. E agora a gente vai,

lembra que eu falei que a análise estática ela se baseia em algumas premissas, né? Então, uma delas é o tent analisis. Eu não vou tentar traduzir tentálisis porque nem tem uma tradução que seja boa pro português, mas é basicamente o tante análise o que que ele faz? ele tenta identificar variáveis que são marcadas, né, marcadas ali como eh controladas pelo usuário e que você pode tracear aquelas variáveis para funções vulneráveis que são conhecidas como syc. Também não vou tentar traduzir syc porque não tem uma tradução boa pro português, mas digamos que o tent análise ele vai fazer o trace, né, como se fosse um data flow. Ele vai tracear desde quando aquela aquela aquele dado é

recebido pelo usuário e pode ser via requisição, HTTP, via arquivo, via qualquer outra coisa. E vai fazer o trace daquela entrada do usuário para uma função que possivelmente pode ser vulnerável, como por exemplo do que a gente viu aqui dos outros exemplos, bufer overflow, né? Se eu tenho um input de numa função externa que é recebido via um arquivo e o usuário controla qual é aquele arquivo e dentro do programa ele passa por inúmeras camadas de funções e ao final se ele chegar aquele input dentro de uma função strop que não é feita em nenhuma verificação, isso tem-se uma característica, tem-se um sinal de que é uma falha de buferlow e a gente vai ver exemplos práticos disso

aqui, tá? Então essa é a definição aí de tentálisis. Vamos ver um exemplo prático aqui, tá? Eu tenho uma biblioteca eh do npm, que é essa systemation e ela tem 2 milhão, 2 milhões de downloads semanal, ou seja, é bastante utilizada por inúmeros engenheiros de programadores, né, aí pelo pelo mundo. Vamos teve uma falha nessa nessa biblioteca, não fui eu que descobri, né? também não foi descoberta com a ferramenta que a gente vai entrar, vai ver aqui, mas é para exemplificar o que seria um tent analisis e o que seria esse, né, essa esse ponto crítico no programa onde ele recebe esse entrado do usuário. Vamos identificar aqui essa função, essa biblioteca, ela tinha uma

função que era o inet checksite, né? Basicamente ela verificava ali o tempo de resposta de um site de uma determinada URL. Então ele fazia essa verificação com essa função. Essa é a função externa, tá? Então, digamos que eu instalei a Libora, dou NPNI, dou um NPMI, instalo a LIB, pego ela e vou utilizar na minha aplicação, né? E coloco esse checksite ali. Eu vou ter que passar um RL, tá vendo aqui, né? Então, se a gente for ver código como é que isso funciona, ele passa a URL para essa função aqui, né? A mesma função, Inet Checksite, URL e o CBAC. E mais para mais para frente, a gente avançando na identificação da lógica do

programa, ele faz, ele pega esse valor aqui da URL e ele perceba que ele concatena em algum momento isso, né, com um exec, né, no Node jss o executar programa, é comandos do sistema. Aí você vai me perguntar, ah, Jardel, mas aqui ele faz a verificação se o protótipo tá poluído, que era o que eu falei da fala de prototype pollution, ele faz uma sanitização da URL? Sim, ele faz, só que fizeram de uma forma, digamos, porca, né? Não fizeram de uma forma onde realmente ele valida isso. Daí, então, como é que a gente pode entender o que é o tent análisis com esse exemplo? O tent análisis aqui, ele vai tentar tracear essa entrada que o usuário controla, que

é a URL. Ou seja, eu posso controlar dependendo do software que foi construído, a URL, que eu quero que ele verifique. E ele vai fazer todo esse trace daqui da URL. E aqui eu cortei, tá? Mas existem um código aqui no meio imenso, que é o que ele faz as outras verificações do programa. E aí ele vai traciar essa URL com esse momento aqui que vai exemplificar uma falha de command injection. Então aqui, por exemplo, seria o sy, né? Seria o ponto crítico da vulnerabilidade. Eh, vamos ver agora um exemplo um pouquinho mais chatinho e complexo, né? Ali foi só uma chamada externa do da função até a concatenação da string. Esse outro exemplo aqui, essa foi de uma

falha que eu descobri, era não é uma falha muito complexa, era uma falha de redor, mas ela tinha um grande impacto. Ela, essa biblioteca aqui, ela tem quase 3 milhões de downloads semanal, então ela é muito utilizada. E um ponto interessante também dessa falha é que a biblioteca não tem mais atualização, né, na no npm. Ela não. Então, tipo, se você instalar a Lib agora, você vai estar vulnerável. e digamos assim, entre aspas, se vire com o que pode acontecer com isso. Isso é o exemplo, eu mostrei, vou mostrar um exemplo de ridoso, mas nessa biblioteca também tem várias outras falhas, como prototype pollution e inúmeras outras coisas. Então, o que acontece? Vamos come vamos

começar com a onde o usuário controla, o que que ele pode controlar e fazer todo o tent análise manual, né? Ele tem uma função read file, que é para ler um arquivo XLS. E nesse read file ele passa o nome do arquivo, tá? Então avançando, lendo o código, né? Eh, ele, aquele read file chama esse read sync e ele passa esse deira. Esse deira, se a gente for ver aqui, ele é atribuído a essa variável D, tá? Então vamos ficar com o D em memória. E perceba que aqui a gente vai ter um fluxo muito mais complexo de como o dado é controlado pelo usuário, como é que ele chega no ponto crítico do programa.

Pronto. Beleza. Aquela função R 5 é imensa, é muitas linhas. Tanto que veja aqui ó 23709 linhas. Então é imenso mesmo. Em algum momento, dependendo de um caso, ela vai chamar o read plan text raw, tá? E aí, lembra, ó, lembra do D? ele é passado aqui. Então aquele inbo controlado pelo usuário é passado pro de ora é passada pro D e o D passa pra frente para outra função. Esse deira ele vem para cá e ele é utilizado aqui, ó, no read plaxt, né? Se a gente for ver, se for um, como é um arquivo binário, um xlsx, é um arquivo binário, então ele cai nessa condição aqui, ó, de binary e atribui o data como

stra frente também. Read planex. Vamos ver agora o que que tem nesse read plan text. Isso tudo aqui é o tent analises. A gente tá fazendo a verificação de uma variável controlada pelo usuário que pode ser utilizada em uma função insegura. Então o read Painlex tem a função, tem o parâmetro dea e o dea chama o par XMLS. Então vamos de novo analisar essa função. Essa função aqui tem o dea e o dea chama o parte XML. XML. Vamos também analisar essa função. E veja que o input sai lá de fora e vem até aqui, né? E aí veja que é muito grande mesmo. Essa base de código aqui é imensa. Eh, o par XML XML

chama tem o parâmetro D e dentro dele ele atribui aqui ao STR. E lembrem aqui que ele atribui ao STR porque logo embaixo aqui ele o que que ele faz? Ele faz um replace com a com a com a Rejex. De novo, podem acreditar ou não, mas essa Rejex aqui para uma engine de rejex, ela é extremamente complexa e ambígua. E dependendo do input do usuário, isso daqui vai causar um DOS na aplicação. Então veja que a gente passou pel umas seis, sete funções, a gente até a gente identificar o input do usuário até uma função vulnerável. Isso daqui foi feito manualmente, tá? Então eh não recomendo, né? E isso é um exemplo de uma fha de ridose, mas poderia ser um

buffer overflow, poderia ser um prototype, poderia ser qualquer outra coisa. Então isso aqui foi feito manual. E aí depois vocês perguntam, tá? Como é que a gente pode automatizar isso? Porque ler uma base de código que tem mais de 23.000 linhas é uma coisa humanamente chata, pelo menos, né? Para não dizer outra palavra. É isso que a gente vai entender, tá? Eh, mas lemb, tá? O input foi traceado e aqui é o SENC, né? o ponto crítico aonde ele usa um input que não é que não é control que é controlado pelo usuário em uma função vulnerável. E aí, né, baseado em tudo isso que a gente viu de análise manual aqui, vamos ver o Codeq e como essa ferramenta pode

nos ajudar. Eh, o Codeq, ele permite você descobrir vulnerabilidades num base de código de forma usando análise estática, aonde a gente consegue construir car, por isso o título da palestra, né? a gente consegue construir car buscar exatamente ali o que eu tinha falado. Então, voltando nesse exemplo aqui, por exemplo, anterior, eu poderia fazer uma carry que dissesse assim: "Olha, procure no programa eh variáveis que são controladas pelo usuário e que essas variáveis não são sanitizadas em algum momento e que essas variáveis elas são utilizados em comandos de rejexs na aplicação." E aí, digamos que eu dou uma carry e encontrei a linha de código, né? Eu não precisaria fazer esse rolê todo que a gente fez aqui. Então, seria muito

mais fácil se a gente tivesse uma ferramenta dessa. E felizmente a gente tem várias. O code, opa, tô voltando aqui, o code é uma delas, tá? Então ele permite fazer tudo isso, né? Ele até interessante que ele ele fala aqui, ó, o code permite você consultar código como se você tivesse consultando dados em um banco. Então o que que ele permite fazer, né? O coach PL é uma ferramenta de análise de código estática, sempre faz uma análise semântica do código. Ele vai fazer o data flow análisis, né, todo o fluxo de dados desde o mundo externo até um ponto crítico do programa que é o sync. E depois ele também faz o t analisis. Um

ponto não tão legal é que ele não suporta todas as linguagens possíveis e imagináveis que temos por aí. Por enquanto, pelo que eu verifiquei hoje cedo, a gente tem o C, C++, o C#ARP, o GO Java Cotlin JavaScript Python Rub, Shirift e T e TypeScript. E aí, só pra gente tentar entender, a gente não vai ver cada um dos passos que o CoachQ faz, como que ele faz, porque é uma coisa muito complexa e seria, na verdade, nem seria uma toque, seria um treinamento disso, né? quem sabe numa posteridade eu possa fazer esse tipo de treinamento aqui. Eh, então ele vai basicamente pegar uma uma base de código aqui e ele vai utilizar um extrator, né,

para poder dessa base de código construir um banco de dados. Então ele vai transformar o código num banco de dados. E aí depois a gente pode utilizar carries, né, para poder a gente já tem car pré-construídas também, então a gente não vai ter que sair do total zero. Aqui a gente pode pegar essas carries, mandar para um para um analisador de carries e aí ele vai trazer os resultados. Por exemplo, essa carry que eu falei agora há pouco, né, de procurar por funções que são eh controladas pelo usuário, que são adas numa num comando de rejex, que podem ser vulneráveis. E pode, de novo, exercitem a mente. Aí pode ser utilizado para buscar funções que são controladas pelo

usuário e são utilizadas com funções como strop e que não fazem o bound checking, o fero overflow. Então, a gente vai ver agora uma coisinha praticazinha. Eh, se der pau, provavelmente vai dar. Eu vou mostrar um vídeo aqui que eu gravei mais cedo, eh, mostrando como é que acontece, tá? Então, basicamente o que que a gente vai precisar ver aqui? como que instala o codecli, como que utiliza as libs que já tem de cares pré-prontas, eh como pegar o pack de carries para uma determinada linguagem, por exemplo, JavaScript, Python e inúmeras outras. Como criar uma um banco de dados da base de código, como roda arc e como ser feliz hackeando, né? Então, deixa eu pegar

aqui rapidão, deixa eu mandar pra tela. Meu Deus, perdi o mouse aqui.

Pera aí que eu tô apanhando aqui com Ui.

Boa. Eh, a gente tá vendo aqui eh um repositório. Deixa eu dar um zoom. Beleza. Eh, aqui a gente vai ver eh todo aquele espaço que a gente viu, né? Eu não vou instalar o Codeq QL e o e o pack de ferramentas porque vai dar muito trabalho, vai consumir muito tempo aqui da nossa talk, mas eu vou mostrar pelo menos aonde que a gente pode procurar por ele, tá? Então, deixa eu pegar e subir isso aqui também.

Boa. Eh, quem quiser depois, né, eu aí recomendo depois praticar, testar, se interessar pelo tema, pode acessar o próprio site, né, do GitHub, o Codeq Q ferramenta que é suportada pelo GitHub/Microsoft, né? Então aqui vai ter o passo a passo de como você fazer o setup, instalar o code QLCI na sua máquina e na sua no seu enfim, no seu computador para poder começar a fazer essas análises, tá? E também deixa eu consigo passar aqui pro outro lado para poder mostrar o pack de carries, algumas, tá? Eh, aqui tem algumas bibliotecas que o code suporta. Então aqui vai ser muito mais fácil eu fazer uma carry porque já tem eh até carries padrões, tá? Ah, eu quero uma

carry para procurar buffer overflow. Ele já tem uma pronta para você. Se você quiser começar a procurar vulnerabilidades e falhas em softwares, faz o seguinte, instala o Codeq, baixa um monte de repositório da internet de código C e roda as cares de buffer overflow e seja feliz e tente hackear, encontrar falhas por aí. E até mesmo alguns eu vou mostrar dão bouns bem interessantes, tá? Eu vou mostrar aqui algumas alguns exemplos e o valor que foi pago esses bouns. Deixa eu ver aqui também outra coisa aqui. É um outro um outro ponto que é lá no repositório de do code, né? Ele fala que o pack de liberada eh determinada linguagem. Então, JavaScript, C+ mais e tudo que a gente

já viu. Mas beleza, agora vamos ver o vídeo aonde a gente vai, lembra de todo aquele processo que eu mostrei, aonde você vai precisar pegar uma base de código, transformar aquela base de código em um banco de dados e depois disso fazer caris? A gente vai ver isso aqui em vídeo, porque se eu for mostrar aqui na hora vai quebrar, eu tenho certeza.

Review finder. Ah, trouxe aqui para baixo.

Ah, ele trouxe aqui para baixo também. tá me trollando aqui.

Putz. Pera aí, vai dar certo.

Vou tirar aqui só para poder já colocar lá que é melhor.

Deu certo. Eh, eu vou dar o play aqui, tá? Isso é no repositório que eu vou mostrar já já para vocês, tá? Então, eu criei esse pequeno comando aqui, nada demais, tá? É só porque eu sou sou fresco mesmo. E aí, esse comando, ele vai fazer aquela criação do banco de dados que a gente viu, tá? Deixa eu dar o play aí. Então aqui eu vou criar o banco de dados, né? Eu vou passar qual é o caminho do diretório que eu quero criar o banco de dados, né? O D. Aí eu vou passar a linguagem que eu vou criar aquele banco, no caso JavaScript. Depois eu vou dar um um po eh o caminho

que eu vou mandar esse banco, quer dizer, a base de código da onde eu vou receber. E aí ele vai rodar por aí e vai fazer todo o processo de criação do banco de dados. Então, aí o banco foi criado com sucesso. Beleza? Eh, e aí ele vai mostrar todo a base de dados aqui do código. Show de bola. Agora vou tentar mostrar rapidão aqui como ele faz uma carry, tá? Deixa eu ver se eu consigo, até mesmo porque o tempo da talk está acabando. Então, vou subir aqui, vou dar um play. Ops.

Tô apanhando pro mouse aqui. Pessoa procura vulnerabilidades em software e apanha pro mouse. Aí vai dar certo, tá? Então aqui eu vou fazer aqui eu estra uma extensão do code que é o novo S code também só porque eu quis, mas você pode fazer tudo via CLI. Eu vou selecionar a linguagem, vou selecionar o banco de dados que eu vou fazer aquela carry. Então no caso aí, lembra que eu criei aquele banco de dados anteriormente? Eu vou selecionar qual é a pasta que tá aquele banco, vou criar o banco de dados e vou criar uma carry. Nesse caso, você bota para criar uma carry, ele já vai criar um automático, mas você pode é rodar uma carry própria. Então eu peguei

uma carry de command injection, tá? Eu vou pegar aqui a carry. Essa carry aqui é a carry de command injection. Não vale a pena eu explicar aqui porque inclusive vale isso um treinamento, não vale uma palestra porque é muito complexo para entender. Então basicamente essa carry vai procurar por com linhas de comando que são concatenadas com a entrada do usuário e eu vou rodar a carry. Um ponto interessante para quem depois quiser usar Code QL para começar a procurar vulnerabilidades e falhas, eh, use tem um PC muito bom, porque nesse meu Mac aqui que foi desse esse teste, eu só tenho 8 GB de RAM, é 1 M1 e ele travou, né? Demorou muito para poder

executar. Então tem uma tem um uma, um hardware muito bom para poder executar. Aí ele vai ficar rodando e tal, não vai valer a pena eu poder mostrar, até mesmo porque tem outras coisas na talk. Então, deixa eu voltar para ela para poder finalizar com o tempo aqui hábil, tá? Cadê? Acho que é aqui.

Vocês estão vendo o que key note aí? Ah, tá aqui. Beleza. Eh, depois se vocês quiserem a gente pode trocar uma ideia lá fora. Eh, e aí, eh, vocês pensam: "Ah, Jardel, você mostrou um exemplo aí que é um código seu, isso aí é tranquilo, até eu faço, tá? Mas a gente vai ver casos reais que foram utilizados para encontrar falhas críticas em softwares críticos e que deram um bom bountador." E um dos pontos que metivou a minha essa minha palestra foi essa ferramenta aqui, que é o Silent Spring, né? Foi esse, desculpa, essa ferramenta não, esse artigo aqui foi um artigo que ele foi apresentado na Defcon aqui, o Micaí Shabaov, né, que aqui é um dos

pesquisadores, eu troquei uma ideia, boa ideia com ele e ele falou que o coach qell foi uma das melhores ferramentas que ele encontrou para descobrir essas falhas de prototype pollution desse softwares. Então tem um pesquisador que tem PhD, que palestrou na Defcon, né, e que utilizou isso daqui para até na Black H também e utilizou o Codeq para encontrar essas falhas. Então mero mortal me senti no direito de também utilizar para encontrar essas falhas também. O Codeq ele também tem o o R da fama deles. Então aqui foi a quantidade de falhas que foram encontradas até então com o Coach Qwell. E aqui um outro exemplo, teve uma falha do Apch Struts, já tem um tempo, 2017

CVSS de 8.1, que é muito alto para quem não entende de vulnerabilidades. e ela tem um EPS EPSS de 94%, ou seja, o EPSS significa a probabilidade daquela falha ser explorada nos próximos 30 dias por trators, eh, enfim, criminosos e por aí a então essa falha aqui críticas criticasíssima, digamos assim, foi encontrada por meio de coach do coachel também. Outros casos reais aqui é o menor bount, um dos menores bouns que ele recebeu, tá? o pesquisador eh ele, eu troquei ideia com ele, ele mandou e-mail aqui com tudo que ele tinha descoberto e ele também utilizou Code QL e ele recebeu um pequena bagatela de $7.400. Para ele pode ser pouco, mas pra gente é uma

fortuna. Eh, e teve mais bouns que isso, tá? Mais do que 10.000. E ele encontrou uma falha de de comando, execução de comando remoto no Kibana utilizando o Codeq. E podem ver aqui que é de 2025, então bem recente, tá? Eh, não tem um EPSS grande, mas enfim, é uma falha bem crítica. E você pensa: "Ah, Jardel, mas aí, esses softwes aí são de boa, a parte strut, não sei o quê, eu quero coisa hardcore, eu gosto é do baixo nível mesmo." Isso é que me fascina, também me fascina, tá? Eh, o, e teve essa falha no Chrome que foi uns after free na lib de web áudio deles, né, de 2019, que também foi encontrada

com o Codeq. Então tô exemplificando casos reais para vocês tirarem da cabeça que a poquei com o código controlado que eu mesmo criei que tem um comand execution e que um command injection e o codec não vai conseguir pegar coisas mais complexas. Mas aqui a gente pode ver que conseguiu falha crítica no Chrome foi descoberta usando o CodeQL. Então, façam vocês mesmos, depois instalem o Codeq e façam essas análises. Eh, e por último, e não menos importante, eh, teve uma falha que foi descoberta de bootloaders, open source, como por exemplo GRB, eh, UFI e vários outros, utilizando CodeQL. Essa pesquisa foi liderada pela Microsoft e eles utilizaram aqui, ó, o Codeq QL como uma ferramenta para poder buscar e fazer

essas análises, né? E aqui é que você pode fazer as pesquisas no Chrome também, mas lembre-se, como uma vez o Fred Brook falou, na não existe bala de prata num só com Code QL a gente vai encontrar as maiores vulnerabilidades do mundo, a gente precisa de utilizar outras ferramentas. E maior parte de todos os outros exemplos reais que eu mostrei aqui, os pesquisadores também utilizarem utilizaram análise dinâmica, fuzing, enhaia reversa e várias outras coisas. Eu tô correndo porque minha tá já acabou meu tempo. Já tem tem alguns minutos, tem uns minutinhos. Boa. Então você fala: "Ah, Jardel, eu quero estudar CoachQL, eu quero descobrir, eu quero tentar encontrar falhas em softwares grandes e um dia eu quero ser

reconhecido e receber bounty por isso, como é que eu começo?" Eh, os próximos passos que você pode dar após essa talk aqui é que o próprio Code QL tem um capture the flag deles, então você consegue sair do nível básico para um nível mais complexo e evoluindo gradativamente com isso. Então eu recomendo bastante você jogarem CTF, ele é bem legal. E você também tem outras coisas que você pode fazer pro CodeQL, contribuir pro CodeQL, por exemplo, você pode eh e compartilhar suas cares que você construiu e encontrou falhas com outros pesquisadores. Por exemplo, vocês lembram da do artigo do Silent Spring, que foi a falha lá no Node, que foi apresentada na Blackhead, na Defcon, o

pesquisador ele compartilhou as flags com a comunidade. Então, digamos que eu pego aquilo ali e vou utilizar num outro projeto que, sei lá, tem 3 milhões de download semanal, numa libs. Eu não não fui eu que criei a carry, mas eu posso utilizar e eu encontrar as falhas. Então tenham esse espírito também se algum de vocês se aprofundar com coach que eu compartilhar isso com a comunidade. Então aqui são algumas outras formas, né? Contribuir com projeto, compartilhar as carries, corrigir bugs no no code também, quem gostar de desenvolver e codar aí. E outra coisa que eu recomendo é tentem replicar CVS que já foram encontradas com as cares do Codeq, porque você vai pegar experiência e prática com aquilo

ali. Então, por exemplo, ah, aquela falha do apast struts, pronto, pois eu vou fazer uma carry que vai procurar por aquela falha no código e vai trazer o resultado. E aí com isso você vai aprimorando o seu conhecimento e a prática de utilizar Codeq. E depois disso vá por aí meu mundo, encontrar suas próprias vulnerabilidades. Coisas que você podem ler também que eu recomendo. Esse livro aqui eu tô ganhando nada da No Start Press, tipo R$ 0 para poder divulgar o livro deles. Mas esse livro aqui eu comecei a ler ele. Inclusive ele também foi um dos que me inspirou a fazer essa talk do Codeq, porque tem um artigo que fala só sobre eh Codeq usando para buscar falhas de

integer overflow e várias outras coisas. Tem os artigos do website do Codeq, que eles têm uma série de artigos lá. E tem também eh esse livro que eu comentei. E basicamente é isso. Quem quiser meu contato, eh, pode escanear esse QRcode aí. Não é um Instagram que eu uso tanto ultimamente, mas pode escanear e aí a gente se fala. Ou também a recomendo melhor o LinkedIn porque aí realmente vai ter eh a gente pode trocar um papo lá depois. Beleza? E se é isso, todo mundo escaneou? Quem quiser falar comigo obrigado. [Aplausos]