Dit zijn dus de SMTP servers van, bijvoorbeeld, providers?

POP en IMAP kan je dus gewoon op blijven halen (dan is het maar weg bij je provider).

Alleen geen mail versturen (via SMTP) tijdelijk totdat dit is opgelost? Die servers kunnen namelijk gehackt zijn?
Of is dit heel kort door de bocht?

Nogal,
want de meeste communicatie tussen 2 mailservers over het internet loopt over SMTP. Er word wel al meer en meer overgeschakeld naar de beveiligde verbindingen over TCP/465 en TCP/578, maar zeker nog niet overal, daarom dus dat (bijna) alle mailservers TCP/25 (SMTP) op zijn minst open hebben staan. Ook is het artikel niet helemaal duidelijk als het probleem enkel bij SMTP zicht voordoet, of ook bij afgeleide implementaties (STARTTLS, SMTPS, ...)

Het bug record voor deze CVE -absoluut de moeite waard om te lezen- leert een aantal zaken:
a) voor deze CVE is binnen 2 dagen een fix gemaakt
b) totdat die is uitgerold, is er een simpele 100% work-around beschikbaar
c) misbruik van de kwetsbaarheid is vooralsnog theoretisch, aangetoond "remote code execution" ontbreekt nog
en misschien wel het meest leerzaam
d) de kwetsbaarheid is per ongeluk door de ontdekker in de buglist geopenbaard
d) het project heeft direct haar procedure voor het melden van dit soort kwetsbaarheden verbeterd om onbedoelde vroegtijdige openbaringen te voorkomen.

Kortom:
Fouten worden gemaakt, maar dankzij de FOSS cultuur snel verholpen.

Beter te omschrijven als snel de fouten gemaakt die niemand ziet en enkel met wat pleisterwerk ogenschijnlijk verholpen wordt. Hoe belazer je jezelf.

Workaround: "chunking_advertise_hosts =" toevoegen aan configuratie.

Controle:

telnet mailserver 25
In vet de in te typen commands


BDAT staat dus nog wel in het rijtje geadverteerde opdrachten (Debian Stretch).

Kevin Beaumont geeft aan dat hij het vermoeden heeft dat de exploit vorige week al tegen zijn honeypot is ingezet:
https://twitter.com/GossiTheDog/status/935292002652082176

@lordpan: nee. Communicatie tussen mailservers (MTA's) loopt *altijd* over poort 25 (receiving end). Communcatie tussen MUA (client) en MTA (verzendende mail) kan via poort 25, 465 of 587. SMTPS of STARTTLS is niet relevant voor de kwetsbaarheid, dat is alleen het transport. Het pakket wordt 'uitgepakt en bekeken' op de mailserver en dus eventueel uitgevoerd.

Ik geloof er overigens helemaal niets van dat exim zo populair is (56%), postfix is m.i. veel vaker gebruikt. Het aantal microsoft servers volgens dit rapport is volstrekt ongeloofwaardig. Ook het aantal servers zonder banner is m.i. veel en veel te laag. Ik weet niet hoe ze hebben getest, maar kan aan dat rapport niet veel waarde hechten. Het is ook niet in overeenstemming met de statistieken die ik zie.

1 - Snel een fix beschikbaar (2 dagen)
2 - Een workaround tot deze fix te implementeren is.

Meer kun je niet wensen.

Ben het met Joep eens, zeer netjes.

Mailservers communiceren onderling altijd via poort 25... al dan niet met STARTTLS.
De poorten 465 (SSL) en 587 (STARTTLS) zijn enkel bedoelt om klanten hun mail te laten versturen!

b.

"Exim Internet Mailer Found Vulnerable to RCE And DoS Bugs; Patch Now"

https://thehackernews.com/2017/11/exim-internet-mailer-flaws.html

Met PoC en eenvoudige test.

Joep heeft een goede weergave van de gang van zaken rond deze bug gegeven en zijn conclusie, die jij citeert, is eenzijdig omdat deze gang van zaken net zo goed bij een goede closedsourceleverancier had kunnen optreden en omdat er opensourceprojecten bestaan waar het niet zo gesmeerd loopt.

Maar jouw reactie daarop gaat nog een stuk verder. Met "snel de fouten gemaakt die niemand ziet" beweer je (onder voorbehoud van misverstanden door jouw slordige taalgebruik) dat ze bij Exim maar wat aanrommelen en je zegt dat de patch pleisterwerk is die het probleem alleen maar ogenschijnlijk verhelpt. Kan je dat onderbouwen, of is daar een vooroordeel tegen FOSS aan het werk waarmee je vooral jezelf belazert?

En voor je daarover begint, ik ken je rants over de Linux-beheerders die jij in je werk meemaakt. We hebben het hier over hoe men bij het Exim-project zelf werkt. Dat staat los van hoe het er bij jouw werkgever aan toegaat, en los hoe het er bijvoorbeeld bij internetproviders aan toe gaat die hun Linux-infrastructuur wel goed beheren. Als je aan de puinhopen bij je eigen werkgever refereerde in je reactie stel ik voor dat je hem terugtrekt en reageert op waar Joep het wel over had.

Kennelijk is de moderator nogal streng met het posten van een controlemiddel (die heb je wel nodig als beheerder). Zoekt en gij zult vinden. Beste moderator: een controle is volledig volgens de huisregels, het is helemaal niet illegaal.

Er is ook een makkelijk te gebruiken PoC gepubliceerd, dus denk niet dat remote control niet is aangetoond.

Als poort 587, zoals ik op diverse plaatsen lees, veiliger is, waarom wordt dat dan niet sneller op meer plaatsen geïmplementeerd.

Waarom worden "best policies" niet eerder en algemener ingevoerd? Doe een quick and dirty scan voor een domein hier: https://mxtoolbox.com/domain/ en je krijgt minimaal 8, 9 of meer problemen.

Server versie proliferatie, het had toch eigenlijk al niet meer moeten bestaan en overal waar mogelijk dicht moeten worden gezet. Veel draait nog beveiligd door "Security through Obscurity".

Haal die slecht opgeleide, incompetente lui uit het veld of van de werkvloer a.u.b. Ze vormen een gevaar voor de hele infrastructuur, vooral hun leidinggevenden zonder verstand van zaken, die de informatie voorziening alleen maar weten te versjacheren voor een hogere bonusuitkering.

Als ik een fietsband had met zoveel onbekende gaten, zou ik er niet op durven rijden. Al zijn ze nog zo klein, er ontsnapt toch lucht door.

Werkvloer? Systeembeheerders worden aangestuurd door managers. En als je die managers verkeerd beloont, door bijvoorbeeld kwartaaldoelen te stellen, dan reageren de mensen voorspelbaar.

Je hebt het NIET begrepen. Poort 587 is alleen voor MUA-MTA communicatie. Niet voor MTA-MTA communicatie.

[snip de rest van een niet terzake doende betoog]

587 is voor MUA's zoals hierboven al aangegeven word, MTA to MTA transport is *altijd* via poort 25. Veiligheid heeft hier niets mee te maken. De reden dat jij leest dat de mail submission port veiliger zou zijn is omdat deze gebruikt worden voor SSL. Dit is niet van toepassing op MTA to MTA verkeer, waar gebruik gemaakt word (kan worden) van STARTTLS over poort 25.

mxtoolbox zou ik niet te veel komen. Ze hebben een leuke presentatie maar geven iets te vaak nutteloze informatie en presenteren dit als waarschuwing/error. Het is ook erg jammer dat jij de verschillende beheerders al meteen incompetent noemt zonder dat je blijkbaar zelf weet waar je het over hebt :)

Ik weet niet waarop 'altijd' tussen sterretjes staat, maar bijna altijd is beter geformuleerd.

Ik heb b.v. een eigen mailserver en heb eens per ongeluk poort 25 van mijn router dichtgegooid. Ik had het niet direct door omdat de gmail smtp server nog wel mail bleef afleveren op mijn mailserver. Dat moet via poort 587 gebeurd zijn. Ik kan niet nagaan of die poort de eerste of tweede keus is van gmail, maar het is in elk geval niet zo dat zij *altijd* poort 25 gebruiken.

Edit: Even getest. Default pakt gmail wel poort 25, indien beschikbaar.

Waarom is dit dankzij de FOSS cultuur snel verholpen? Ik zie niet echt iets specifieks dat alleen geld voor FOSS?

Even afgezien dit een beste grote bug is, welke er dus al een tijdje in zit, maar wel voor iedereen te vinden is/was. Wat wel een eigenschap van FOSS is, immers de bron code is voor iedereen toegankelijk.
Blijkbaar heeft men de procedures niet in in orde. Is dat ook een eigenschap voor FOSS cultuur?

Daarnaast bijna het hele Internet draait op FOSS, dus voordat deze patch overal geïnstalleerd is, zal menig data lek / Email onderschepping flink misbruikt kunnen worden. Juist Email is hier zeer gevoelig voor. Menig wachtwoord (reset) wordt immers via Email toegezonden.

Deze bug is dus een recept voor grote privacy issue. Maar daar hoor je natuurlijk weer niemand over. Terwijl dat menig keer op deze site juist een heel hekel punt is.

Mee eens.
Ik weet niet hoe veel dit nou echt uitmaakt. Er zullen natuurlijk mensen zijn die broncode van dit soort mainstream-projecten doorspitten om fouten te zoeken, maar of dat de software kwetsbaarder of juist robuuster maakt hangt af van welk aandeel van die mensen kwade intenties heeft. Afhankelijk van dat aandeel kan het totaaleffect zowel negatief als positief zijn.
Nou maak je bijna precies dezelfde uitglijder als Joep maakte. Waaruit blijkt dat de procedures niet in orde zijn? Ja, men heeft een bug in produktie genomen. Dat is echt niet specifiek voor FOSS, bij closed source gebeurt dat ook aan de lopende band. Als er procedures zouden bestaan die alle fouten voor zijn dan zouden we in een bugvrije wereld kunnen leven. Dream on.
Een bug in Exim raakt Exim, en niet Postfix of Apache of de Linux-kernel. Wat relevant is is niet dat het hele internet op FOSS draait maar dat kennelijk 56% van de SMTP-servers Exim gebruikt. Dat maakt dit inderdaad groot. Maar een zero day lek overkomt ook closed source leveranciers wel eens, ook dat is niet uniek voor FOSS. En net als bij die leveranciers doet de reactiesnelheid van de leverancier er toe. En die is in dit geval gewoon goed.
Ja, maar de verantwoordelijkheid ligt nu bij de beheerders van de diverse installaties. Bij mainservers mag je daar enige professionaliteit van verwachten. Het is net zo onzinnig om tekeer te gaan tegen Exim of FOSS in het algemeen op basis hiervan als het is om tekeer te gaan tegen Microsoft of closed source in het algemeen als daar een belangrijke patch beschikbaar als zich daar zoiets voordoet.

Je had gelijk dat dit voorval niet illustreert hoe geweldig FOSS is, het zegt inderdaad niet zoveel, maar draai het nou niet om, het toont evenmin aan dat er iets mis is met FOSS.

Ik kan me niet voorstellen dat gmail "mail in het algemeen" op een andere manier aflevert dan door een DNS MX
lookup gevolgd door een connectie op poort 25.

Wellicht is het anders als je in gmail opgeeft dat je alle mail die in jouw mailbox komt wilt forwarden/dupliceren naar
een ander mail account. Je geeft dan kennelijk een server, account en password op en dan kan ie ook poort 587
proberen. Maar voor verzenden van mail naar een willekeurige bestemming weet gmail niet die account en password
gegevens (mag ik hopen) en dan is poort 587 dus geen optie!

Ik denk dat er een enorme bias is tussen het tellen van SMTP servers en "een percentage van de SMTP servers" waarbij
je dan min of meer telt het aantal SMTP servers wat daadwerkelijk in gebruik is.
Bedenk dat als je een default Debian (dus ook Ubuntu) install doet er Exim op geinstalleerd wordt zelfs als je nooit
wat doet met mail op die machine. Het ding kan dan geen mail afleveren want dan moet je eerst configureren wat ie
daar mee moet. Of die situatie vulnerable is weet ik niet.
Maar het lijkt me buitengewoon onwaarschijnlijk dat het totale mailverkeer op internet voor een belangrijk deel door Exim
verwerkt wordt, en zeker geen 56%.

MTA-MTA transport is per definitie poort 25. Daarom staat het tussen sterretjes. Zo staat het in de RFC's. Vandaar. Als er MTA's zijn die het anders doen, dan houden zich niet aan de definities van MTA-MTA transport.

Weet je wel heel zeker dat je niet toevallig nog een staande verbinding had?

Waarom ik reageerde is enkel zijn afsluiting dat het met FOSS allemaal zo perfect is. Dat is het niet.

Een goede ict_er beleidsmaker iv zou juist kritisch tegenover elke softwareleverancier moeten zijn.
Ik zeg elke omdat de eenzijdigheid in een bepaalde richting ergerlijk beschamend en voor de praktijk lastig is.
Lastig omdat het die kritische blijk onderuit haalt.

Als er niet meteen door de exim beheerder is geupdate naar de laatste versie met fe laatste flitsebde features is er weinig aan de hand. De oude versie heeft dat specifieke issue niet
Voor je het weet loop je in de discussie "maar je had de laatste Update kunnen doen, was beschikbaar".

De meeste open source projecten worden tegenwoordig door de grote commerciëlen gedaan. Die verdienen er goed aan als niet onderscheidend iets in de rest van het gesloten geheel.

Kleine correctie voor iedereen die hier de fout in gaat: een MUA communiceert niet met een MTA maar met een MDA, die op zijn beurt zijn post ontvangt en verstuurd via de MTA.

Als de MTA (in dit geval Exim) onder een beperkte user draait en er geen exploits op het systeem aanwezig zijn, dan kan men met een hack van de MTA, in theorie, alleen nieuwe mails onderscheppen.

Tja Sendmail is veiliger zeggen ze... Maar wel een configuratiedrama...

Het lijkt me heel erg onmogelijk dat gmail enige andere poort dan 25 gebruikt om verkeer naar de MX van een domein af te leveren.
poort 587 is daar zeker niet voor bedoeld en een MTA heeft ook geen rijtje "alternatieve poorten om te proberen als 25 niet lukt" .

(wel hebben MTAs meestal wel de mogelijkheid om een bepaalde bestemming met een bepaald transport hard te configureren inclusief poort , maar dat is anders dan internet mailers proberen een paar poorten )

Het lijkt me wel heel erg goed mogelijk dat 'poort dichtzetten' op een router nieuwe sessies blokkeert maar een bestaande flow laat lopen.

Ik zou zeggen, probeer het nog eens, die poort dicht zetten en laat een capture meelopen om te zien of en op welke poort je mail aangeboden wordt.

Daar zijn we het over eens en daar sprak ik je ook niet op aan. Maar het lukt me niet om wat je nu schreef te relateren aan deze zin:
Die komt op mij over (juist door de zin die je citeerde) als een rant tegen FOSS die de plank nog verder misslaat dan Joep deed. Het kan zijn dat je het niet zo bedoeld had, maar schrijf dan alsjeblieft je reactie meteen zorgvuldig op, zodat overkomt wat je dan wel bedoelt. Je ageert regelmatig tegen (al dan niet terecht veronderstelde) fouten en slordigheden van anderen, maar heb je eigenlijk wel door hoe hypocriet dat overkomt als je eigen taalgebruik vaak zo vol fouten en slordigheden zit dat moeilijk te interpreteren is wat je ermee bedoelt en dus ook heel makkelijk interpretatiefouten optreden? Als je op kwaliteit staat, lever dan zelf ook kwaliteit, ook in je taalgebruik.

Ze leggen uit hoe ze te werk gaan. De mailservers die ze bekijken halen ze uit de MX-records op van de domeinnamen van de websites die ze inventariseren. Van de totale verzameling websites die ze kennen is dat het deel dat ze "well-known" noemen. Een website is "well-known" als een andere "wel-known" website ernaar linkt. Ze vinden ze door hun lijst bekende websites met een crawler te blijven bezoeken, en zijn al bijna 20 jaar bezig met het onderhouden van hun verzameling domeinen. Van de websites die ze kennen voldoet zo'n 90% niet aan hun "well-known"-definitie omdat er niet naar gelinkt wordt, en die nemen ze dus niet mee in de statistieken.

Kan jij daar een vergelijkbare grondigheid tegenover zetten? Dat jij heel andere statistieken ziet in de logs van maiservers die jij beheert (ik neem aan dat je daaraan refereert) hoeft helemaal niet vreemd te zijn. De verdeling van gebruikte mailservers kan er heel anders uitzien dan de volumes die die mailservers verwerken, en als jij bijvoorbeeld in een bedrijfstak werkzaam bent die sterk op Microsoft-platforms georiënteerd is is het waarschijnlijk dat je daar ook veel meer van langs ziet komen. Dat hoeft niet representatief te zijn voor de hele wereld.

Die verschijnen dan ook niet in een overzicht van publiek benaderbare mailservers die in gebruik zijn bij domeinen waar ook websites aan gekoppeld zijn.
Dat staat er ook niet. Er zijn in dat overzicht mailservers geteld, geen mailverkeer.

Het gaat me er overigens niet om die 56% als ultieme waarheid te verdedigen. Je ziet bijvoorbeeld bij browserstatistieken dat niet iedereen die meet tot precies hetzelfde resultaat komt omdat er nou eenmaal verschillen in methodiek zijn. Maar de tent die tot 56% Exim kwam is zo te zien niet bepaald over een nacht ijs gegaan. Dat aanvallen met een onderbouwing die niet dieper gaat dan "ik zie zelf wat anders" of die zelfs duidelijk maakt dat je niet tot je hebt laten doordringen wat ze eigenlijk meten vind ik wat al te makkelijk. Securityspace lijkt me als bron vooralsnog een stuk betrouwbaarder dan jullie inbreng.

Onnauwkeurig. Iemand die met Exim communiceert doet dat rechtstreeks met de MUA. De rol van Exim is dan MTA (en MDA, maar dat is in dit geval totaal niet relevant).


Ook incorrect. Met een hack van de MTA heb je toegang tot de mail spools, en je weet niet wat daar (nog) in zit.


En de laatste incorrecte. Wie zijn 'ze'? Monolithische mailmeuk loopt een veel groter risico (zie Exim) dan losse threaded oplossingen(zie Postfix).

BTW degene die roept dat het onderzoek zo transparant is, vergist zich. Hoe zijn de maildomeinen gekozen? Niet @random, want dan waren veel meer MS oplossingen tegen gekomen, daar blijf ik bij. Vrijwel ieder bedrijf heeft een MS oplossing (helaas, helaas). Soms worden die afgeschermd door appliances zoals Barracuda, of McAfee.

Tenslotte: uit security oogpunt haal je identificatie spul uit de headers weg...

Ze zijn transparant genoeg om duidelijk te maken dat hun selectie niet random is. Op basis waarvan klaag je over gebrek aan transparantie als je zelfs dat niet had opgemerkt? En dat ze andee resultaten hebben dan jij zou verwachten kan andere verklaringen dan gebrek aan transparantie hebben.

Wees jij eens transparant door te beschrijven waar jouw conclusies op zijn gebaseerd, zou ik zeggen.

De reikwijdte is een stuk minder dan In het bericht wordt gemeld (56% van alle mailservers). Het gaat om versie 4.88 en hoger. Die is vorig jaar kerst uitgebracht, en zal dus alleen draaien op sites waar mensen dit zelf compileren, of de nieuwste versie uit bv Ubuntu draaien (wat in dat specifiek geval voor productie sites onwaarschijnlijk is aangezien de tussenliggende Ubuntu versies niet LTS zijn). Het zit niet meer in redhat, Debian Stretch heeft wel Exim 4.89.
Realistische aandeel zal alles bij elkaar dus veel kleiner zijn, ik gok minder dan 1%.

Ja inderdaad ik heb ook van die slimme klanten die meteen denken dat zo'n tool altijd correct is. Laatst zag ik dat die 'domme' developers een mail test deden met een niet resolvable/bestaande domein. Waarop onze mail server met een penalty reageerd en dan rapporteren ze dat de server traag/overbelast is etc etc.