SMTP Smuggling
Basic Information
Aina hii ya udhaifu iligunduliwa awali katika chapisho hili ambapo inaelezwa kuwa inawezekana kufaidika na tofauti katika jinsi itifaki ya SMTP inavyotafsiriwa wakati wa kumaliza barua pepe, ikiruhusu mshambuliaji kusafirisha barua pepe zaidi ndani ya mwili wa ile halali, ikiruhusu kuiga watumiaji wengine wa eneo lililoathirika (kama admin@outlook.com) kwa kupita kinga kama SPF.
Why
Hii ni kwa sababu katika itifaki ya SMTP, data ya ujumbe inayopaswa kutumwa katika barua pepe inasimamiwa na mtumiaji (mshambuliaji) ambaye anaweza kutuma data iliyoundwa kwa makusudi ikitumia tofauti katika parsers ambazo zitasafirisha barua pepe za ziada kwa mpokeaji. Angalia mfano huu ulioonyeshwa kutoka kwa chapisho la awali:
How
Ili kufaidika na udhaifu huu, mshambuliaji anahitaji kutuma data ambayo seva ya SMPT ya Kutoka inadhani ni barua pepe 1 tu lakini seva ya SMTP ya Kuingia inadhani kuna barua pepe kadhaa.
Watafiti waligundua kuwa seva tofauti za Kuingia zinachukulia wahusika tofauti kama mwisho wa data ya ujumbe wa barua pepe ambayo seva za Kutoka hazichukui.
Kwa mfano, mwisho wa kawaida wa data ni \r\n.. Lakini ikiwa seva ya SMTP ya Kuingia pia inasaidia \n., mshambuliaji anaweza kuongeza data hiyo katika barua pepe yake na kuanza kuonyesha amri za SMTP za mpya ili kuisafirisha kama ilivyoonyeshwa katika picha ya awali.
Kwa kweli, hii inaweza kufanya kazi tu ikiwa seva ya SMTP ya Kutoka haitibu data hii kama mwisho wa data ya ujumbe, kwa sababu katika kesi hiyo itaona barua pepe 2 badala ya 1 tu, hivyo mwishowe hii ndiyo desynchronization inayotumiwa katika udhaifu huu.
Data ya uwezekano wa desynchronization:
\n.\n.
Pia kumbuka kuwa SPF inapita kwa sababu ikiwa unapasua barua pepe kutoka admin@outlook.com kutoka kwa barua pepe ya user@outlook.com, mtumaji bado ni outlook.com.
References
Last updated
