SMTP Smuggling

Support HackTricks

Basic Information

Aina hii ya udhaifu iligunduliwa awali katika chapisho hili ambapo inaelezwa kuwa inawezekana kutumia 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 kikoa kilichohusika (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 kutumia 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 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.\r. Lakini ikiwa seva ya SMTP ya Kuingia pia inasaidia \n., mshambuliaji anaweza kuongeza data hiyo katika barua pepe yake na kuanza kuashiria 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 hali hiyo itakuwaona barua pepe 2 badala ya 1 tu, hivyo mwishowe hii ndiyo desynchronization inayotumiwa katika udhaifu huu.

Data ya uwezekano wa desynchronization:

  • \n.

  • \n.\r

Pia kumbuka kuwa SPF inapita kwa sababu ikiwa unapasua barua pepe kutoka admin@outlook.com kutoka kwa barua pepe ya user@outlook.com, mjumbe bado ni outlook.com.

References

Support HackTricks

Last updated