Ehm, hebben ze nog nooit van spf gehoord? Verhelpt de meest voorkomende kiddy spoofing.

Alsof m365 magisch is. SFP man.

Door de gehele mail-spool naar een Amerikaans bedrijf te uploaden en ook alle toekomstige e-mails via servers van dit bedrijf te laten lopen kon de universiteit voorkomen dat derden mails uit naam van universiteitsaccounts konden versturen.

waarschijnlijk een linux, netware of andere oude meuk servertje wat gebruikt werd om vanuit lab opstellingen unauth mail te versturen, in de trend van 'backup grlukt', disk vol, proef klaar enz...
erg spannend, not... wat wel spannend is dat dit niet gezien is door scansoftware...tenzij deze scansoftware dezelfde mail relay gebruikt.om de scan. resultatrn te mailen...

Klinkt als een SMTP server is vanaf interne bekende IP adressen mag relayen voor bekende domainen.

Wat natuurlijk niets oplost, als je via een bekende SMTP server mag relayen.

Haha alle heil van Microsoft. Het probleem zit o.a. in de MTA Dat gaat 365 niet oplossen.

Voor wie SPF roept, kijk eens naar wat ze hebben staan:

Als ik het artikel goed begrijp is het probleem dat de servers de gespoofde emails accepteren, daar gaat SPF je niet tegen helpen.

Dat komt omdat er ~all staat. Dit wordt een soft fail genoemd.
Maak er -all van en klaar. Dat is de hard fail. Zo heb ik ook mijn eigen spf records. Zowel zakelijk als prive.

Jij begrijpt de werking van spf blijkbaar niet. Dat is onwerkzaam in dit geval, net als DMARC.

Begrijpend lezen is te moeilijk? Er staat "De migratie naar Microsoft 365 zal het probleem volledig oplossen, aldus Delta, het weekblad van de TU Delft." en dan denk jij aan Linux? Nee hoor, het is gewoon zoals altijd Microsoft bagger die hierbij de klok slaat.

en ook met MS 365. test het zelf maar. pak een eigen domein. zet spf en dkim op maar *geen* dmarc voor je smtp server en zie dat jou server gewoon als relayer werkt voor MS 365 maar en nu komt de rare twist: zet je voor je domein wel een dmarc record op [, dan volgens de rfce hoort die niet geraadpleegd te worden], dan blokkeert MS je relayer weer wel. de o265 MS mail wijkt af van de rfc en heeft een 'gaatje'. er hoeft maar een open relayer zo opgezet te zeten en je kunt weer spoofen via die relayer. neen, dat dmarc en spf enzo, dat is geen fix en het resulteert in veel problemen met valide mail stromen in de praktijk. en dat komt omdat MS afwijkt van rfcs en omdat vele windows exchange beheerders niet goed onderricht zijn in de protocollen en interne werkingen daarvan volgens de rfcs. geloof je me niet? prima, test het lekker zelf dan maar eens.

Er lijkt sprake van twee verschillende problemen, waar we allemaal wat van kunnen leren:

1) Iedereen met toegang tot het netwerk van een organisatie (in dit geval: tudelft.nl) kan e-mails versturen namens andere accounts binnen die organisatie;

2) Iedereen met toegang tot het netwerk van een organisatie kan e-mails versturen schijnbaar afkomstig van afzenders buiten die organisatie.

Probleem 1 heeft niets met SPF en dergelijke te maken; dat bijvoorbeeld niet elke gmail.com-afzender zich voor kan doen als elke andere gmail.com-afzender, is iets dat Gmail "intern" moet oplossen, bijv. met SMTP AUTH.

Probleem 2 betekent dat er, in de organisatie, minstens één mailserver is die e-mails met extern afzenderadres accepteert zonder op DMARC plus (SPF of DKIM) te checken, en vervolgens "wordt vertrouwd", vaak op basis van diens IP-adres.

De combinatie is natuurlijk ook mogelijk. Als er ergens een (wellicht vergeten) interne mailserver staat die (nog) wordt vertrouwd (door de "echte mailservers"), die op TCP poort 25 elke mail accepteert (zonder te checken op SMTP AUTH, noch op SPF etcetera), heb je een "mooie" backdoor in je organisatie.

Maar ook zonder luisterende SMTP-service: als een PC of ander "IoT" apparaat in een organisatie wordt vertrouwd (bijv. op basis van diens IP-adres), mogelijk omdat deze (soms of vaak) e-mails verzendt, en zo'n apparaat wordt gehacked, kan dat voor een boel extra ellende in een organisatie zorgen.

Als je echt voor "zero trust" gaat, zul je dit soort achterdeurtjes moeten dichten.

In elk geval kun je het afzenderdomein in het afzenderadres in alle "van binnenuit" verzonden mails checken (allowlisten - zowel envelope- als mail from, of op SPF etc. checken). Uit apparaten die "zelf" mailen kun je vermoedelijk het beste het hele afzenderadres allowlisten. En wellicht de sirene laten loeien als er iets onverwachts voorbijkomt. Achtergebleven interne mailservers zou ik op z'n minst distrusten (evt. als "tripwire" gebruiken).

Het is jouw leesvaardigheid die faalt .

Het is de BESTAANDE - (dus nog niet O365) mailserver die alle interne IPs vertrouwd om mail voor te relayen.

Dat zou inderdaad best een Linuxje kunnen zijn . Het was een klassieke setup, smarthost die "de mail" verstuurt indien afkomstig van "interne" IPs. Hoeft niet Linux te zijn - 'alles intern is vertrouwd' want is een configuratie keuze die je op elk platform kunt maken. Maar in de goede oude tijd, toen alle echte hosts Unix draaiden - zo gemaakt werd, of het nu Sendmail op SunOS op Solaris, op Linux (of postfix of whatever).

_dat_ probleem wordt ook echt opgelost met een migratie naar O365 (of naar gmail, of naar een nieuw ingericht platform) - want inderdaad, O365 laat niet meer ongeauthenticeerd mail relayen.

Als iemand misbruik maakt(e) moest aan de hand van timestamp en IP uit de mail van de klager de werkelijke gebruiker (of in elk geval : bron systeem) gevonden worden.

Nou, de jonge generatie is me wel een partij diepgravend zeg .
Klassieke open mailrelay gevonden, maar een klein beetje rondtesten breder testen zit er niet bij, dat blijft 'vermoeden' .

Kom - testje intern TU, testen Eduroam TUD , testen TU gasten wifi , testen Eduroam anders (TUE,TUT, RUL , je moet toch wel iemand kunnen vinden die je even kan helpen testen) , testen NL thuis ISP , testen VPNetje met NL of buitenlandse exit .

De reden is - zoals genoemd door de TU - wel plausibel . 'onderzoeksopstellingen' zijn feitelijk een soort van IOT dingen, met typisch heel beperkte protocol support en soms natuurlijk ook stokoud . Kortom - smtp auth suppport is een probleem.
Nog meer een probleem dat het liefst een 'eigen' user account moet hebben, ook als smtp auth wel gesupport is.
De researcher van het moment gaat vrij snel weer weg - zou , terecht - niet z'n eigen credentials moeten willen gebruiken in allerlei gedeelde opstellingsapparaten, en zou dan ook nog bij iedere password wijziging de hele onderzoeksopstelling langs moeten om dat weer aan te passen.
Ook als de TU naar O365 gaat blijft het een uitdaging om het type IOT / OT spul dat meldingen via mail stuurt te laten werken. Of het nu onderzoeksopstellingen, airco's/klimaat of ander soort klein spul met summier protocol support is.

Ik lach, maar eigenlijk is het om te huilen

Sinds wanneer kun je een mailserver in een lab terugvinden?
Hebben we daar niet speciaal beveiligde serverhokken voor?

Voor een SPF record is dat inderdaad prima, maar dat gaat je nog steeds niet helpen als je mailserver zelf niet goed geconfigureerd is.

Zeggen dat de techniek begrepen en dan smtp relay niet kennen. Inderdaad helpt spf dkim daar niet het lijkt er op dat wat security kiddies een en ander napraten. Wat er om heen zetten kan helpen.

Ik lees niet dat de server zelf in het lab staat.
Maar dan nog, het probleem zit hem hier totaal niet in de fysieke beveiliging van een machine (of VM) .

Je mag je natuurlijk helemaal goed voelen wanneer de machine in een beveiligd hok staat, en de "trusted client" die alles mag relayen in het lab staat.

pfff Ik dacht dat het het een technische universiteit was, lekker kundig zijn ze daar dan dat ze zelf niet eens mail kunnen regelen. Laatste wat je als universiteit wil is dat je data bij de Amerikanen staat. Kan me nog herinneren dat die balgehakten daar een defecte solar race auto in het dorre gras parkeerden, waardoor brand ontstond.

Wat een hoop loze zooi hier. Gewoon een oude smtp server die gebruikt is voor labopstellingen. Ook bij Wageningen-UR is in het verleden zo'n smtp server geweest. Vroeger was dat allemaal niet zo in beeld en geen probleem. Maar met de cybercriminelen van tegenwoordig is het niet verstandig meer. Verder als ik het artikel leest van Delta, verbaasd het me over de angst voor santies. Dat zou wat zijn als op mijn universiteit dat soort dingen niet bespreekbaar zou zijn en santies op zouden zitten. Bizar dit ! Men maakt dit artikel en het probleem groter dan dat het is. Van een mug een olifant maken heet dat !

Ze hebben hun ziel verkocht aan Microsoft software.

Dus jullie zijn het erover eens dat het SPF wel de oplossing zou zijn mits correct toegepast.

Beter lezen.
En zelf leren snappen wat het concept van SPF is, en wat deze smtp smarthost op de TUD doet .

"We" zijn het erover eens dat voor een smt relay server met deze (mis)configuratie SPF NIET de oplossing is.

Inderdaad, niet heel verstandig. OTOH, als de 'open relay' inderdaad - zoals de studenten vermoeden maar niet getest hebben - beperkt is tot TUD-interne IPs is het probleem ook weer niet zo groot.


Ik heb van afstand de indruk dat TUD-IT een stuk stugger geworden dan in de hacktic-tijd. Misschien niet helemaal uitgesloten dat er 'gedoe' zou komen of de vrees ietwat terecht is en het even wat moeite kosten voordat een wat verstandiger iemand dat platslaat met 'netjes gemeld, bedankt, gaan we naar kijken' .

En, moet ik zeggen, ook in die vervlogen tijden waren er op de TUD ook wel systeembeheerders die helemaal in aanvalsstand gingen toen het zoontje van een medewerker netjes meldde dat er wat gaten zaten in de config.


Yep.

Daarvoor hadden ze een cyrus imap server. Heel slecht voor een technische universiteit om te standaardiseren op een systeem dat onveilig is en dat niet bestudeerd kan worden. Voor ICT opleidingen kan je veel beter naar Twente gaan.

Tip : de productie infrastructuur is niet voor en door "onderzoek" .
Tweede tip : universitair (IT) onderwijs/onderzoek gaat niet over cursus systeembeheer voor een bekend platform.

Wat is hier nou zo bijzonder aan? Er is geen authenticatie van headers in SMTP email. Je kan er letterlijk nooit op vertrouwen dat From aangeeft van wie de email vandaan komt. Dit is bij elke pure SMTP server zo.

Autorisatie op basis van IP maakt het geen open relay. Dat ontstaat pas als ongeauthenticeerde "gasten" in staat worden gesteld SMTP email te verzenden. Een gastnetwerk dient geen toegang tot mail servers te hebben.

Dus men heeft niets nieuws of belangrijks ontdekt.

@Erik van Straten: SMTP authenticatie heeft geen invloed op headers, dus spoofing is in principe mogelijk.

Alleen een filter op headers kan dit voorkomen. Bijvoorbeeld een controle of de geauthenticeerde user gerechtigd is bepaalde afzenderadressen te gebruiken in specifieke headers.

Overigens kan ik me nog de tijd herinneren (in deze eeuw nog) dat het universteitsnetwerk wereldwijd open stond bij de TU Delft. Je kon bijvoorbeeld als buitenstaander printopdrachten sturen naar printers. Academische vrijheid.

Met een simpel aan te maken SMTP relay en SEToolkit op kali linux krijg je al gevaarlijk veel voor elkaar.. Het is te gek voor woorden dat deze jarenoude techniek bij veel bedrijven nog gewoon werkt.

"@Erik van Straten: SMTP authenticatie heeft geen invloed op headers, dus spoofing is in principe mogelijk."

met SMTP auth weet je dat er niet zo vlug een buitenstaander van een andere toko via eduroam de delftse mailer misbruikt. de stelling heeft geen invloed is onjuist. heeft wel invloed maar is ook weer niet 100% dekkend want er kunnen nog immers delftse mensen doen alsof ze mail versturen van anderen.

Het probleem in Delft is dat het een Microsoft tent geworden is. Je kan niet eens met een Linux laptop werken want wordt niet gesupport (terwijl Citrix zelf wel Linux support). Beter naar Twente gaan. Veel meer open source minded. Dat zie je ook aan de Linux maintainers/ontwikkelaars die er van dan komen. Die interne smtp smart host zal wel een overblijfsel zijn uit een roemrijk verleden.

Dank! Bovendien is de "pakkans" na klachten zeer groot: met de juiste logging weet je wie de dader is of wiens account is gehacked. Binnen de meeste organisaties (waaronder universiteiten) is het onvermijdelijk dat je medewerkers, studenten etc. tot op zekere hoogte moet kunnen vertrouwen, waarbij je het restrisico kunt beperken middels (de dreiging van) sancties.

Ik noemde eerder bewust gmail: ook (nauwelijks te pakken) criminelen maken daar accounts aan. Ik heb het niet getest, maar het zou mij verbazen als je met een gmail-account namens een andere gmail-gebruiker (d.w.z. diens SMTP-adres) mail zou kunnen verzenden (zowel wat betreft envelope-from als het in mail clients getoonde afzenderveld).

Echter, spoofing door de naam tussen "" in die van een ander te veranderen kan mogelijk wel, en is in de praktijk uiterst effectief voor phishing-mails omdat mail clients (MUA's), vooral op mobiele devices, het SMTP-afzenderadres niet tonen achter From (of ontvangers dat niet checken of niet weten dat het niet klopt).

Spoofing van namen kan overigens op veel meer (mogelijk onverwachte) plaatsen, check bijv. deze maar:
https://twitter.com/realDonaldTrump/status/890617797956456448 (dat is géén tweet van Donald J. Trump, terwijl je wel bij zijn account uitkomt als je
https://twitter.com/realDonaldTrump opent).

Dat geldt precies zo voor papieren post. Bijna niemand lijkt zich er druk om te maken dat een afzender achterop een envelop en/of genoemd in de brief hartstikke nep kan zijn.

Niet onbeperkt; goed geconfigureerde pure SMTP servers proberen al heel lang te voorkómen dat ze als open relay misbruikt kunnen worden (d.w.z. dat e-mail van een externe afzender naar een externe ontvanger wordt geblokkeerd, maar of dat ook altijd voor het in mail clients getoonde from veld geldt, betwijfel ik).

Met wisselend succes zijn er bovendien allerlei lapmiddelen tegenaan gegooid, waaronder SPF, DKIM en DMARC. In https://security.nl/posting/785673 beschreef ik de situaties die ik ken waarin je niets hebt aan DMARC. Zie https://security.nl/posting/767981 voor details over de ellende met Microsoft's "safe senders" (waarvan ik de huidige status niet ken).

Dat was niet omwille van academische vrijheid, maar omdat het zo gegroeid was. Toen het door mij aangelegde lokale netwerkje (in een Natuurkunde-vakgroep aan die TU), met daarin enkele DOS PC's (met PC-NFS) en een door mij beheerde Sun computer, aan "internet" gekoppeld werd, moesten firewalls nog worden uitgevonden en bevatte /etc/password op die Sun ("world" readable) zwakke wachtwoordhashes van voornamelijk zwakke wachtwoorden. Later heb ik luid en veelvuldig aangedrongen op allerlei TU-brede beveiligingsmaatregelen - waarvan de implementatie altijd langer duurde dan wenselijk/noodzakelijk was.

Puur reactieve beveiligingsmaatregelen zijn, allesbehalve beperkt tot universiteiten, gebruikelijk; voor nagenoeg alle organisaties (ook dienstverleners zoals cloudproviders) geldt dat er eerst een kalf moet verdrinken voordat men de put dempt. Voor die 2,6 miljard mensen wiens gegevens in de afgelopen twee jaar op straat zijn beland, is dat helaas te laat (https://www.apple.com/ca/newsroom/2023/12/report-2-point-6-billion-records-compromised-by-data-breaches-in-past-two-years/).