Email Injections
Usa Trickest per costruire e automatizzare flussi di lavoro alimentati dagli strumenti della comunità più avanzati al mondo. Accedi oggi:
Inietta in e-mail inviate
Inietta Cc e Bcc dopo l'argomento del mittente
Il messaggio verrà inviato agli account recipient e recipient1.
Inject argument
Il messaggio verrà inviato al destinatario originale e all'account dell'attaccante.
Inject Subject argument
L'oggetto falso verrà aggiunto all'oggetto originale e in alcuni casi lo sostituirà. Dipende dal comportamento del servizio di posta.
Cambiare il corpo del messaggio
Inietta un'interruzione di riga di due linee, quindi scrivi il tuo messaggio per cambiare il corpo del messaggio.
Sfruttamento della funzione PHP mail()
Il 5° parametro ($additional_parameters)
Questa sezione si baserà su come abusare di questo parametro supponendo che un attaccante lo controlli.
Questo parametro verrà aggiunto alla riga di comando che PHP utilizzerà per invocare il binario sendmail. Tuttavia, verrà sanitizzato con la funzione escapeshellcmd($additional_parameters)
.
Un attaccante può iniettare parametri estratti per sendmail in questo caso.
Differenze nell'implementazione di /usr/sbin/sendmail
L'interfaccia sendmail è fornita dal software MTA email (Sendmail, Postfix, Exim, ecc.) installato sul sistema. Sebbene la funzionalità di base (come i parametri -t -i -f) rimanga la stessa per motivi di compatibilità, altre funzioni e parametri variano notevolmente a seconda dell'MTA installato.
Ecco alcuni esempi di diverse pagine man del comando/interfaccia sendmail:
Sendmail MTA: http://www.sendmail.org/~ca/email/man/sendmail.html
Postfix MTA: http://www.postfix.org/mailq.1.html
Exim MTA: https://linux.die.net/man/8/eximReferences
A seconda dell'origine del binario sendmail, sono state scoperte diverse opzioni per abusarne e leakare file o persino eseguire comandi arbitrari. Controlla come in https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html
Iniettare nel nome dell'email
Nota che se riesci a creare un account in un servizio con un nome di dominio arbitrario (come Github, Gitlab, CloudFlare Zero trust...) e verificarlo ricevendo l'email di verifica nel tuo indirizzo email, potresti essere in grado di accedere a posizioni sensibili dell'azienda vittima
Parti ignorate di un'email
I simboli: +, - e {} in rare occasioni possono essere usati per il tagging e ignorati dalla maggior parte dei server email
E.g. john.doe+intigriti@example.com → john.doe@example.com
Commenti tra parentesi () all'inizio o alla fine verranno anch'essi ignorati
E.g. john.doe(intigriti)@example.com → john.doe@example.com
Bypass della whitelist
Citazioni
IP
Puoi anche usare IP come nomi di dominio tra parentesi quadre:
john.doe@[127.0.0.1]
john.doe@[IPv6:2001:db8::1]
Codifica dell'email
Come spiegato in questa ricerca, i nomi delle email possono anche contenere caratteri codificati:
Overflow PHP 256: La funzione PHP
chr
continuerà ad aggiungere 256 a un carattere fino a diventare positivo e poi eseguire l'operazione%256
.String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @
L'obiettivo di questo trucco è terminare con un'iniezione come RCPT TO:<"collab@psres.net>collab"@example.com>
che invierà l'email di verifica a un indirizzo email diverso da quello previsto (pertanto per introdurre un altro indirizzo email all'interno del nome dell'email e rompere la sintassi durante l'invio dell'email)
Diverse codifiche:
Payloads:
Github:
=?x?q?collab=40psres.net=3e=00?=foo@example.com
Nota l'
@
codificato come =40, il>
codificato come=3e
enull
come=00
Invierà l'email di verifica a
collab@psres.net
Zendesk:
"=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com
Stesso trucco di prima ma aggiungendo una normale virgolette all'inizio e la virgolette codificata
=22
prima dell'@
codificato e poi iniziando e chiudendo alcune virgolette prima della prossima email per correggere la sintassi utilizzata internamente da ZendeskInvierà l'email di verifica a
collab@psres.net
Gitlab:
=?x?q?collab=40psres.net_?=foo@example.com
Nota l'uso dell'underscore come spazio per separare l'indirizzo
Invierà l'email di verifica a
collab@psres.net
Punycode: Utilizzando Punycode è stato possibile iniettare un tag
<style
in Joomla e abusarne per rubare il token CSRF tramite esfiltrazione CSS.
Tooling
Esiste uno script Burp Suite Turbo Intruder per fuzzare questi tipi di combinazioni per cercare di attaccare i formati email. Lo script ha già combinazioni potenzialmente funzionanti.
È anche possibile utilizzare Hackvertor per creare un attacco di splitting email
Other vulns
Terze parti SSO
XSS
Alcuni servizi come github o salesforce ti permettono di creare un indirizzo email con payload XSS su di esso. Se puoi utilizzare questi fornitori per accedere ad altri servizi e questi servizi non stanno sanitizzando correttamente l'email, potresti causare XSS.
Account-Takeover
Se un servizio SSO ti consente di creare un account senza verificare l'indirizzo email fornito (come salesforce) e poi puoi utilizzare quell'account per accedere a un servizio diverso che si fida di salesforce, potresti accedere a qualsiasi account. Nota che salesforce indica se l'email fornita è stata o meno verificata, ma l'applicazione dovrebbe tenere conto di queste informazioni.
Reply-To
Puoi inviare un'email utilizzando From: company.com e Replay-To: attacker.com e se viene inviata una risposta automatica a causa dell'email inviata da un indirizzo interno, l'attaccante potrebbe essere in grado di ricevere quella risposta.
Hard Bounce Rate
Alcuni servizi, come AWS, implementano una soglia nota come Hard Bounce Rate, tipicamente impostata al 10%. Questo è un indicatore critico, specialmente per i servizi di consegna email. Quando questa soglia viene superata, il servizio, come il servizio email di AWS, potrebbe essere sospeso o bloccato.
Un hard bounce si riferisce a un'email che è stata restituita al mittente perché l'indirizzo del destinatario è invalido o inesistente. Questo potrebbe verificarsi per vari motivi, come l'email inviata a un indirizzo non esistente, un dominio che non è reale, o il rifiuto del server del destinatario di accettare email.
Nel contesto di AWS, se invii 1000 email e 100 di esse risultano in hard bounce (a causa di motivi come indirizzi o domini non validi), questo significherebbe un tasso di hard bounce del 10%. Raggiungere o superare questo tasso può attivare AWS SES (Simple Email Service) per bloccare o sospendere le tue capacità di invio email.
È cruciale mantenere un basso tasso di hard bounce per garantire un servizio email ininterrotto e mantenere la reputazione del mittente. Monitorare e gestire la qualità degli indirizzi email nelle tue liste di distribuzione può aiutare significativamente a raggiungere questo obiettivo.
Per informazioni più dettagliate, puoi fare riferimento alla documentazione ufficiale di AWS sulla gestione dei bounce e dei reclami AWS SES Bounce Handling.
Riferimenti
Usa Trickest per costruire e automatizzare flussi di lavoro alimentati dagli strumenti della comunità più avanzati al mondo. Ottieni accesso oggi:
Last updated