
Buffer overflow basato sullo stack in MiniShare 1.4.1 raggiungibile tramite una singola richiesta HTTP PUT.
Overflow del buffer basato su stack in MiniShare 1.4.1 raggiungibile tramite una singola richiesta HTTP PUT.
Questo repository fa parte del materiale che utilizzo quando insegno lo sfruttamento delle vulnerabilità di corruzione della memoria (oltre al mio lavoro regolare, insegno anche in diversi corsi di cybersecurity dove contribuisco a formare la prossima generazione di reverse engineer).
CVE-2020-13768 è un caso che uso quando voglio mostrare come semplici server esposti in rete possano presentare classici overflow del buffer basati su stack attraverso metodi di protocollo standard. L'endpoint vulnerabile non richiede autenticazione, l'overflow è una sovrascrittura diretta di EIP e il percorso di sfruttamento è pulito e ben definito. È un caso ideale per apprendere l'intera metodologia di sfruttamento in uno scenario realistico remoto senza autenticazione.
Ciò che rende questo caso interessante anche come esercizio didattico è che la stessa causa principale, input non sanificato copiato in un buffer stack di dimensione fissa, appare in molteplici voci CVE per lo stesso binario. CVE-2018-19861, CVE-2018-19862 e CVE-2019-17601 descrivono tutte la stessa classe di vulnerabilità, segnalate solo da ricercatori diversi attraverso diversi metodi HTTP o endpoint. Questo insegna agli studenti a guardare le cause principali piuttosto che i semplici numeri CVE.
Questa vulnerabilità interessa MiniShare 1.4.1, un server HTTP Windows leggero, non più supportato, progettato per la semplice condivisione locale di file. Il software è stato scritto senza tenere a mente le pratiche di sicurezza moderne. Ciò che rende questo caso particolarmente interessante dal punto di vista didattico è la combinazione di fattori coinvolti:
Questa combinazione rende CVE-2020-13768 un eccellente caso per insegnare i fondamenti dello sfruttamento degli overflow del buffer basati su rete in uno scenario realistico senza autenticazione.
MiniShare è un server HTTP Windows minimale originariamente progettato per la condivisione rapida di file locali su LAN. Ascolta sulla porta TCP 80 e gestisce un piccolo sottoinsieme di metodi HTTP, inclusi GET e PUT. Il gestore PUT elabora le richieste in arrivo e copia il percorso URI in un buffer stack di dimensione fissa senza validarne la lunghezza.
Dettagli tecnici chiave:
MiniShare elabora le richieste HTTP in arrivo e le smista al gestore appropriato in base al metodo. Il gestore PUT estrae il percorso URI dalla richiesta e lo copia in un buffer stack di dimensione fissa senza controllarne la lunghezza.
Una versione semplificata della logica vulnerabile assomiglia a questa:
char path_buffer[256];
strcpy(path_buffer, uri_path);
Poiché il buffer di destinazione ha una dimensione fissa e la lunghezza di input non viene validata, l'invio di un URI sufficientemente lungo nella richiesta PUT fa sì che la copia scriva oltre la fine del buffer, raggiungendo e sovrascrivendo infine l'indirizzo di ritorno salvato (EIP) nello stack.
Quando la funzione vulnerabile ritorna, la CPU carica il valore controllato dall'attaccante dallo stack in EIP e salta a esso. Se tale indirizzo punta a dati controllati dall'attaccante contenenti shellcode, si ottiene l'esecuzione di codice arbitrario.
Il crash può essere riprodotto inviando un URI di dimensioni eccessive in una richiesta HTTP PUT. Non è richiesta autenticazione. Esempio utilizzando Python:
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 3000
request = (
b"PUT /" + payload + b" HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Connection: close\r\n"
b"\r\n"
)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.send(request)
s.close()
Se eseguito sotto un debugger, il crash mostra EIP sovrascritto con dati controllati dall'utente:
EIP = 41414141
confermando che l'indirizzo di ritorno salvato è stato corrotto dall'overflow.
L'obiettivo di questo repository non è solo dimostrare il crash, ma anche guidare attraverso il processo completo di sfruttamento passo dopo passo, seguendo la metodologia utilizzata nello sviluppo di exploit basati su stack reali.
Per mantenere il README principale pulito, le note dettagliate sullo sfruttamento, gli script e i passaggi del debugger sono inseriti nella cartella Vulnerability 📂 di questo repository.
Lì troverai il flusso di lavoro completo utilizzato per sfruttare questo CVE, inclusi: