SMTP Smuggling

Reading time: 3 minutes

Basic Information

Aina hii ya udhaifu iligunduliwa kwanza katika chapisho hili ambapo inaelezwa kuwa inawezekana kutumia tofauti katika jinsi itifaki ya SMTP inavyotafsiriwa wakati wa kumaliza barua pepe, ikiruhusu mshambuliaji kusafisha barua pepe zaidi ndani ya mwili wa ile halali, ikiruhusu kuiga watumiaji wengine wa eneo lililoathirika (kama admin@outlook.com) kupita ulinzi 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 zitasafisha 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 moja tu lakini seva ya SMTP ya Kuingia inadhani kuna barua 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.\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 kuisafisha 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 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, mtumaji bado ni outlook.com.

References

• https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/