Este é o pior ataque da história do WordPress?
BBetter Stack
Internet TechnologyBusiness NewsComputing/Software
Transcript
00:00:00O WordPress teve uma série de vulnerabilidades recentemente, com a mais recente sendo tão grave
00:00:04que permite aos hackers assumir controle total do painel admin; estamos falando de injeção SQL, execução de
00:00:09comandos shell, coisas bem sérias, e talvez você não ligue para o WordPress, mas ele ainda roda mais de 44%
00:00:14dos sites do mundo, então muitos dos sites com os quais você interage e fornece seus dados
00:00:19podem estar rodando WordPress e essa versão vulnerável, então basicamente funciona assim:
00:00:25Eu tenho instalada localmente uma versão padrão do WordPress e posso rodar este
00:00:29primeiro script para ver se a vulnerabilidade está disponível e você pode ver que recebemos a resposta
00:00:34HTTP 207, o que significa que sim, está de fato vulnerável, e isso significa que agora podemos rodar a segunda verificação,
00:00:41que é entrar na shell interativa, então isso faz injeção SQL no site, cria um novo usuário admin
00:00:47e depois envia um plugin malicioso que me permite agora interagir com qualquer arquivo neste site,
00:00:52então vamos nos aprofundar no problema e ver exatamente como funciona.
00:00:58Então, este repositório que estou olhando mostra exatamente como fazer injeção SQL em sites WordPress vulneráveis, ou seja,
00:01:06qualquer site entre 6.90 e 6.94 ou 7.00 e 7.01. Todo o ataque começa chamando um endpoint não autenticado
00:01:14batch v1, que permite agrupar outras requisições que, por si sós, passam por validação e checagem
00:01:20de permissão. O manipulador de lotes tem dois arrays paralelos que deveriam permanecer sincronizados: validação e correspondências,
00:01:26mas um bug fez com que, quando a função wp pass URL falha devido a um caminho inválido, apenas a validação fosse atualizada,
00:01:33então agora o mesmo índice usado para olhar ambos os arrays fornecia resultados dessincronizados. A POC se aproveita disso:
00:01:41Ela envia um lote contendo apenas uma requisição, um POST para o endpoint v2 posts, que por sua vez carrega um corpo de requisição.
00:01:48Como a requisição pai foi corretamente validada como uma requisição POST, qualquer requisição no corpo acaba burlando a lista de métodos permitidos,
00:01:56permitindo que você envie requisições GET. Então, dentro desse lote interno, há uma requisição GET para um post que não existe, o que dispara a
00:02:02dessincronização anterior, fazendo o WordPress despachar a mesma requisição sob uma função chamada get items, onde o campo author
00:02:10exclude mapeia para author not in, que a versão vulnerável interpola no SQL como uma string; basicamente, como tudo isso está rodando,
00:02:18o SQL não é escapado. A POC usa uma série de requisições que por fim permitem que uma requisição POST para v2 users crie
00:02:25uma nova conta admin. O repositório na verdade detalha todos esses passos; os primeiros cinco são pré-autenticação, aproveitando o bug, mas o passo seis é apenas o comportamento normal do WordPress para
00:02:35usuários autenticados, que é enviar um pacote malicioso. Certo, então, como mencionado antes, esta é apenas a versão padrão do WordPress, a vulnerabilidade não é acessada por meio de algum plugin malicioso,
00:02:46você pode simplesmente instalar o WordPress padrão. Nós rodamos este script de verificação primeiro, que basicamente valida se a
00:02:52vulnerabilidade pode ser executada, e então podemos rodar este comando de leitura, por exemplo, que nos mostra coisas como o
00:02:57usuário e o nome do banco de dados. Agora também podemos rodar SQL contra o site, então podemos descobrir coisas como
00:03:03qual versão o banco de dados está rodando, e nada disso é o pior de tudo, esta é a parte realmente ruim
00:03:07onde realmente criamos uma conta de admin que tem acesso para poder enviar um plugin malicioso, neste
00:03:15caso chamado web shell. Isso nos permite acessar o shell do site, o que significa que agora podemos ter acesso a
00:03:22qualquer arquivo neste site, e este ataque acontece da maneira que explicamos anteriormente no vídeo, então,
00:03:27depois que o admin é criado, o plugin é enviado e, finalmente, esse usuário é excluído, então a existência
00:03:34do plugin e o que aconteceu ficam mais discretos. Para demonstrar o quão grave isso é, criei um script separado
00:03:38que cria um admin e o mantém no sistema,
00:03:40então aqui tenho um usuário e uma senha. De volta ao site, se eu for para a rota wp login, posso inserir esse
00:03:47usuário e senha, clicar em login e agora tenho acesso total ao painel admin. Agora, se algo disso for confuso, não se preocupe,
00:03:54eu também levei muito tempo para entender. A afirmação é que a cadeia de exploit resultante era tão absurdamente
00:04:00complexa que um pesquisador de segurança humano levaria semanas, se não meses, para descobrir e
00:04:05juntar as peças sozinho; nenhum pesquisador de segurança teria encontrado e completado essa cadeia de exploit
00:04:10em 10 horas sem IA, e isso é bem assustador porque mal-intencionados poderiam efetivamente ter bots varrendo
00:04:17repositórios, checando URLs, apenas esperando vulnerabilidades aparecerem e explorando-as em tempo recorde usando IA.
00:04:23Um usuário no Reddit disse que seu site foi comprometido apenas dois dias após a descoberta,
00:04:27e como eles só atualizam nos fins de semana, um atacante conseguiu criar um novo admin e fazer login para aqueles
00:04:33vulneráveis. O exploit foi corrigido na versão 7.0.2, então você pode atualizar para ela, mas essa foi bem insana.
00:04:40Você pode encontrar o repositório e o artigo nos comentários que usei para rodar a POC, e por que não
00:04:46se inscrever no Better Stack para ficar por dentro de todas as notícias de tecnologia? Espero que tenham gostado desta, pessoal, e
00:04:50é claro, como sempre, vejo vocês no próximo vídeo.