Veiligheidsdiensten balen nu dat het word gerepareerd. Zo wordt het moeilijker om alerte cybercriminelen te pakken.

Het wordt echt eens tijd dat we SMTPv2 krijgen, met standaard TLS en dingen als SPF, DKIM en DMARC in het protocol ingebouwd en waar we alle problemen die met HTTP zijn vastgesteld (waar deze ook ooit in zat) ook hebben gecontroleerd.

Even terug naar het begin: hoe kun je van een 'kwestbaarheid' spreken in een protocol wat uitsluitend functioneel bedacht is zonder enige voorziening voor vertrouwelijkheid of 'security'? Daar is het nooit voor bedoeld geweest!

SMTP is kwetsbaar. gôh.
Water is nat.

Omdat er met de tijd aanvullingen op de standaard worden gedaan en dan is het wel degelijk onderdeel van het protocol.

Om een gespoofte e-mail te kunnen versturen, moet je evengoed in kunnen loggen op de SMTP server. Je weet dus wie het doet.

Bovendien kan je sowieso alles spoofen aan de e-mail die je verstuurt. Ook al zullen DKIM, DMARC en SPF dat niet leuk vinden en gaan protesteren.

Mijn verwachting is dat deze "feature" in vele versies van SMTP server software aanwezig is(of was). SMTP is nooit voor secure email gescheven en het is jammer dat de industrie er zo lang over doet voordat protocollen uit worden gefaseerd. Dat is het echte probleem bij werkpaarden als SMTP, SSL, http. Niemand durft ze een op een redelijke termijn uit te faseren omdat backward compatibility zo belangrijk is. Vervangers zijn vaak wel beschikbaar maar worden pas heel erg laat afgedwongen.

En dat al sedert 1980 bestaat.

In deze _implementatie_ kun je wel spreken van een kwetsbaarheid .

Feitelijk wordt er voor een tweede onafhankelijke sessie meegelift op een (goedgekeurde) eerste sessie, als ik zo naar het plaatje kijk.

Door even naar het einde ervan te gaan en te beginnen met het wegnemen van al die zaken die nu wel relevant zijn.

SMTP est mort, vive Le SMTP \o/
(Maar het moet nog wel gebeuren, het opnieuw coden)

https://datatracker.ietf.org/doc/html/rfc2821 waarschuwde in 2001 al expliciet voor het probleem dat hier optreedt. Dit is dus niet een nieuwe ontdekking. Het is ook geen fout in het SMTP-protocol zelf, het gaat hier om fouten in de implementatie ervan in sommige servers.

Het probleem wordt veroorzaakt doordat het SMTP-protocol uit het heen en weer sturen van tekstregels bestaat, en dat er verschillen zijn in hoe regeleinden worden afgehandeld. Dat moet carriage return+line feed (CRLF) zijn. Er zijn echter mailservers die als ze mail doorgeven aan een andere SMTP-server LF laten staan (dat zijn GMX en Exchange Online), en er is er een die dat vervolgens als regeleinde interpreteert (Cisco Secure Email). Die servers houden zich daarmee alle drie niet volledig aan de SMTP-specificatie.

Als in SMTP een e-mail wordt afgeleverd is er eerst een aantal SMTP-commando's (met daarin de zender en ontvangers) en vervolgens een "data"-commando waarop de tekstregels van de e-mail volgen. Die moet worden afgesloten met een regel waarop alleen een punt staat.

Als nou de zender van een e-mail GMX of Exchange Online gebruikt en de ontvanger Cisco Secure Email, dan is het mogelijk om een e-mail te sturen die in de body de tekens LF . LF bevatten (dus een punt op een regel omgeven door voor SMTP foute regeleinden), gevolgd door een paar tekstregels die overeenkomen met de opdrachten in een volgende SMTP-dialoog, weer een "data"-commando, weer een e-mail-body en nu een juiste afsluiting: CRLF . CRLF

De eerste SMTP-server beschouwt dit geheel als één e-mail. Maar als die hem aanlevert bij een ontvangende SMTP-server die LF als regelovergang accepteert dan zal die het niet als één maar als twee e-mails verwerken.

SEC Consult beschrijft verder dat de afhandeling van SPF en DKIM in deze situatie niet waterdicht is, en dat DMARC het beter doet.

Je kan ESMTP, dat we sinds 1995 gebruiken, als v2 beschouwen, en er zijn meer wijzigingen en toevoegingen geweest, waaronder het gebruik van TLS. Ik zou dus om v3 of misschien nog hoger vragen ;-)

Maar van mij mag het nog veel grondiger op de schop. De manier waarop e-mails gecodeerd zijn, het MIME-formaat, is echt vreselijk om te interpreteren in software. Als je alleen al voor het ontleden voor een e-mailadres software moet maken die alle variaties, inclusief de mogelijkheid om commentaar op te nemen, het moeten ondersteunen van verouderde conventies, het rekening moeten houden met foutief gebruik in allerlei implementaties, dan heb je al best een pittig projectje.

Ik zou het helemaal niet erg vinden als de hele zooi werd ondergebracht in bijvoorbeeld BSON-formaat (binary JSON), met weglating van alle vervuiling en variaties die zich hebben opgehoopt in de loop van de jaren. Dan heb voor de verzending een protocol nodig dat niet meer aanneemt dat alles uit tekstregels bestaat, dus dan lijkt het vermoedelijk niet meer op SMTP.

Je realiseert je wel dat voor deze bug/implementatie keuze die hele set van TLS, SPF, DKIM/DMARC daar niet of beperkt tegen helpen ?

Verder, realiseer je je dat "SMTPv2" met "TLS + SPF + DKIM/DMARC" 'in het protocol ingebouwd' precies helemaal NIKS toevoegt aan "SMTPv1" met TLS + SPF + DKIM/DMARC als 'losse' eigen standaarden ?

Wat bedoel je nou eigenlijk met 'alle problemen die met HTTP zijn vastgesteld waar deze ook ooit in zat' - en in relatie tot SMTP ?

Als je een 'nieuw en verbeterd' volledig ander protocol wilt voorstellen kun je meteen uitgaan van heel andere randvoorwaarden.
X.400 is/was ECHT anders. DJB verzon 'internet mail 2000' waarbij mail bij de afzender blijft staan, en door de ontvanger opgehaald wordt. Ook echt anders.

In dit geval is het geen kwetsbaarheid in het protocol maar zitten er fouten in sommige implementaties ervan.

Los daarvan:

SMTP over TLS is allang mogelijk, en daar zijn ook standaards voor bedacht. Besef je trouwens dat HTTPS niets anders is dan HTTP over een met TLS versleutelde verbinding? De applicaties die met elkaar communiceren zien gewoon HTTP-requests en -responses en behandelen TLS als onderdeel van het transport. Het is heel goed mogelijk om een protocol zonder veiligheidsvoorzieningen in te pakken in een ander protocol dat die voorzieningen toevoegt.

Er is zelfs veel voor te zeggen om het zo te doen. Zo kan je namelijk de implementatie van de encryptie loskoppelen van de implementatie van de inhoudelijke applicatieprotocol-aspecten (de SMTP-commando's en -responses, HTTP-requests en -responses), wat beide implementaties eenvoudiger houdt, wat bevorderlijk is voor de veiligheid en robuustheid. Het betekent ook dat je de dezelfde TLS-implementatie voor verschillende applicatieprotocollen kan gebruiken. En zo werkt het ook.

Ter illustratie: ik heb, voordat in 2003 versie 5.2 TLS ondersteunde, Microsoft's dus nog onversleutelde Remote Desktop Protocol getunneld over SSH-verbindingen, die toen nog een Linux/Unix-ding waren waar Microsoft niets mee te maken wilde hebben. Dat deed ik in een omgeving waar zowel Windows als Linux gebruikt werd. Dat ging prima, opmerkelijk makkelijk zelfs, en de beveiliging en versleuteling van de RDP-verbindingen over het internet waren daardoor zo goed als die van SSH, terwijl RDP op zichzelf rammelde qua beveiliging.

Je kan TLS-versleuteling aan een protocol toevoegen en de combinatie tot standaard bombarderen met een eigen protocolnaam (zoals HTTPS). Je kan ook het aspect van het applicatieprotocol en het aspect van de versleuteling als bouwstenen beschouwen die naar believen gecombineerd kunnen worden. Dan kan HTTP opeens prima over andere dingen dan TLS getunneld kunnen worden (bijvoorbeeld SSH). De laatste benadering geeft enorm veel flexibiliteit, maar een vaste combinatie van protocollen tot standaard bombarderen en het samen een protocolnaam geven (zoals HTTPS) heeft weer als voordeel dat iedereen hetzelfde implementeert en dat niemand meer over bouwstenen hoeft na te denken maar hetzelfde doet.

Besef dat het zelfs als die combinaties samen een protocolnaam krijgen het nog steeds onder water twee afzonderlijke protocollen zijn, twee bouwstenen die gecombineerd worden, en dat dat in meerdere opzichten een goede opzet is.

Ik begrijp je verwarring. Deze conclusie van security.nl klopt volgens mij inderdaad niet helemaal.

Als ik het allemaal zo lees gaat het niet om een kwetsbaarheid in het officiële SMTP-protocol zelf,
maar in sommige omgevingen gaat het om een verkeerde implementatie ofwel configuratie van SMTP
die niet helemaal aan de officiële RFC voorschriften en aanbevelingen voldoet.

In https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ is o.a. te lezen:


En verder:

Sommige SMTP-servers zijn zo geïmplementeerd of geconfigureerd dat ze hier van afwijken,
en dát kan dan gespoofte e-mails mogelijk maken.

Dat was in het geval van HTTPv1.1 + TLS het geval, maar inmiddels zijn we bij HTTP 3 https://en.wikipedia.org/wiki/HTTP/3 en daar zit het ingebakken via QUIC. Eigenlijk is HTTP 3 zelfs 'HTTP/2 Semantics Using The QUIC Transport Protocol': echt encryption by default dus!

(Twijfel even, maar HTTP 3 over http:// zou dus niet eens mogelijk moeten zijn in standaard configs)

Dit heeft niet zozeer met SMTP te maken als wel met implementaties. Misleidende titel.

CRLF.CRLF is de standaard. Iets anders is niet de standaard.

Een punt op een lege regel (met CRLF line ends) moeten worden escaped met twee punten. Dat moet de client doen. Je kan dus als implementatie niet zomaar even zelf een regel verzinnen dat LF.LF óók het einde van DATA is.

Wat al langer niet goed is dat Unix/Linux implementaties ten onrechte CRLF vertalen naar LF en vice versa. Implementaties zouden zich gewoon moeten houden aan CRLF, ook bij lokale delivery. Ophouden met eigenwijs te zijn.

In content zul je vaak losse CR's of LF's tegenkomen, meestal veroorzaakt door knutselaars. Je mag best wilde LF of CR gebruiken in content, maar je bent dan wel verantwoordelijk voor correcte content encoding.

SMTP zou verder kunnen worden verbeterd door al die "robuustheid" verder af te wijzen en over te gaan op byte content. Dat maakt ook diverse encoderingen overbodig, zoals die voor attachments. Robuustheid die reparerende mail servers zoals Exchange toepassen zijn gevaarlijk en dat zijn ze in de praktijk al meer dan 20 jaar. De reparatiedrang van Exchange kan malware langs een perimeterscanner loodsen.

Nog erger, het is niet het protocol maar de implementatie van het protocol wat het probleem is. Als het namelijk het protocol zelf was geweest, dan waren alle SMTP implementaties per definitie kwetsbaar geweest en hadden partijen als Microsoft het niet zo maar even kunnen fiksen.
Of de redactie van deze site snapt niet wat een protocol is of dat security bedrijf doet zich groter voor dan ze daadwerklijk zijn. Mooi dat ze een implementatie bug hebben gevonden, maar dit is geen protocol kwetsbaarheid.

Mits de SMTP server goed staat ingesteld en sessies niet accepteert die niet authenticated zijn, geen verplichting namelijk.

Neem dan gelijk het concept opt-in mee in het protocol. Nu is dat 0.0 procent ondersteund door de techniek.

HUH ?

Ik denk dat je echt niet begrijpt hoe SMTP werkt.
Je "logt niet in" op een SMTP server - je maakt alleen maar verbinding - en pompt er een mail in.

Het enige dat de mail server heeft is een IP adres - de hele rest is informatie van de afzender die daar alles in kan zetten.

Vandaar al die IP-reputatie systemen om (al) bij de connectie mail te weigeren - en al die boze thuisnerds dat hun thuis-ip-block alleen om die reden al niet geaccepteerd wordt.

(leertip : de MX-smtp server werkt iets anders dan de 'smarthost SMTP server' die je in je mailclient instelt.


Works as designed - daar zijn precies SPF, DKIM/DMARC voor, om te protesteren, spamvlaggen, spamfolderen, rejecten als dingen niet kloppen.
Ze vangen niet alles af - maar wel een hoop.

nope, bepaalde implementaties van SMTP zijn onjuist. andere weer niet. klaag bij je fabrikant of leverancier die beloofd heeft dat alles op orde was enzo.

kuch: https://en.wikipedia.org/wiki/SMTP_Authentication