Blocking main page to steal postmessage

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Ganhar RCs com Iframes

De acordo com este writeup do Terjanq, os blobs de documentos criados a partir de origens nulas são isolados para benefícios de segurança, o que significa que se você manter ocupada a página principal, a página do iframe será executada.

Basicamente, nesse desafio um iframe isolado é executado e logo após ele ser carregado a página pai vai enviar uma mensagem post com a flag. No entanto, essa comunicação postmessage é vulnerável a XSS (o iframe pode executar código JS).

Portanto, o objetivo do atacante é permitir que a página pai crie o iframe, mas antes de permitir que a página pai envie os dados sensíveis (flag), mantenha-a ocupada e envie o payload para o iframe. Enquanto a página pai está ocupada, o iframe executa o payload que será algum JS que irá ouvir a mensagem postmessage da página pai e vazar a flag. Finalmente, o iframe executou o payload e a página pai deixa de estar ocupada, então ela envia a flag e o payload a vaza.

Mas como você poderia fazer a página pai ficar ocupada logo após gerar o iframe e apenas enquanto espera o iframe estar pronto para enviar os dados sensíveis? Basicamente, você precisa encontrar uma ação assíncrona que você poderia fazer a página pai executar. Por exemplo, nesse desafio a página pai estava ouvindo as postmessages assim:

window.addEventListener('message', (e) => {
if (e.data == 'blob loaded') {
$("#previewModal").modal();
}
});

Portanto, era possível enviar um número inteiro grande em uma postmessage que será convertido em string nessa comparação, o que levará algum tempo:

const buffer = new Uint8Array(1e7);
win?.postMessage(buffer, '*', [buffer.buffer]);

E para ser preciso e enviar aquele postmessage logo após o iframe ser criado, mas antes de estar pronto para receber os dados do pai, você precisará brincar com os milissegundos de um setTimeout.

Last updated