De (identieke) links naar Microsoft wijzen naar een uitleg met een schema, waarin twee exploit-paden, die voor CVE-2021-26858 en CVE-2021-27065, erop neerkomen dat een aanvaller die via een andere exploit (CVE-2021-26855) zich weten te authenticeren als een exchange-server bestanden kan schrijven naar elk pad op de server.

Het idee om een serverproces met beperkte rechten te laten draaien, zodat een aanvaller die zich naar binnen weet te werken in het serverproces niet meer dan die beperkte rechten tot zijn beschikking heeft, is ouder dan dat hele Exchange.

Naar elk pad op de server te schrijven verkrijgen vergt een privilege escalation die niet een bug in het proces met minder rechten kan zijn maar een bug in een proces met meer rechten (bijvoorbeeld de kernel zelf). Uit het feit dat deze CVE's als bugs in Exchange worden gepresenteerd meen ik af te kunnen leiden dat Exchange zelf draait met rechten om naar elk pad op de server te kunnen schrijven.

Ik vind het verbluffend dat in de 24 jaar die Exchange bestaat kennelijk nog niemand bij Microsoft heeft besloten dat het verstandig is om dit serverproces dat netwerkconnecties accepteert geen onbeperkte rechten te geven.

Mis ik iets?

ja je mist het advies van M$ om te migreren naar Exchange Online ;)

Ik denk het niet? (Jou skill level ligt een stuk hoger dan de mijne als ik je stukje zo lees). Maar ik denk (vermoeden) dat Exchange altijd "teveel" rechten heeft omdat de applicatie verwikkelt zit met het "zelf domain server zijn". Dit simpelweg omdat ze willen dat je als Exchange admin zelf de mailboxes/gebruikers aan moet kunnen maken vanuit de exchange applicaties. Kan me herinneren dat hiervoor ook een behoorlijke exchange vuln was die servers overnam.

Ik heb een "koppel alles maar aan elkaar vast met domeinen en site2site vpn's blik" nooit een goed idee gevonden, maar ja, kosten laag houden en beheers gemak hoog houden (mits geen ransomware natuurlijk lol).

Begin denk een beetje door te krijgen dat security meer een luxe is puur omdat het zo veel geld en kennis kost.

- RAMLETHAL

Dat klopt, dit soort processen draait in Windows vrijwel altijd als "Local System" wat ze onbeperkt rechten geeft op de machine zelf, maar niet op andere machines in het netwerk. Vergelijkbaar met "root" op een Unix systeem dus.
Ik kan me voorstellen dat dit wellicht niet in een dag om te bouwen is, maar in 24 jaar moet het wel lukken.
Of anders een protectie schil in de kernel inbouwen waardoor de rechten toch weer wat ingeperkt worden, ala SeLinux of AppArmor.

MS mode: het is geen bug, maar een ongedocumenteerde optie.

Ja, de verplichte open standaard (w3org) is dat poorten onder 1024 onbeperkte toegang op het systeem moeten hebben (root). https://www.w3.org/Daemon/old/UserGuide_2.16/PrivilegedPorts.html

Je kletst uit je soepslabbernek.
V.b. achter poort 80 zit een webserver proces dat met de rechten van nobody draait en verder nergens bij kan, behalve zijn eigen home. Daarnaast is het met handen en voeten gebonden aan selinux policies onder Linux.

Daarnaast ken ik exchange beheerders die maar alle poorten opzetten tussen Exchange in DMZ en achterland omdat het allemaal veel te veel werk is.

Je kletst weer eens uit je nek... dat staat er namelijk niet!
Alleen root/admin/system mogen servers starten op die poorten. Dat wil echter niet zeggen dat ze na het starten ook root moeten blijven!
Je komt met een link naar een Userguide uit 1995 en zelfs toen was er - op *nix - al inetd om dit probleem op te lossen. Sterker, de httpd server waar je naar verwijst kon zelf al z'n privileges opgeven!
Op Linux, FreeBSD, etc. worden servers weliswaar gestart door root, maar ze schakelen daarna over naar een UID met aanmerkelijk minder rechten. Net genoeg om hun werk te doen en niks meer.

Mijn homebrew smtp listener draait echt niet onder root. Met iptables kan je eenvoudig bv poort 25 doorzetten naar een hoog nummer.

Oswald

Alleen bij besturingssystemen die lichte consumententoepassingen als primair toepassingsgebied hebben is dat blijkbaar een niet op te lossen probleem (24 jaar?!). Hoe anders is dit bij de professionele besturingssystemen die hoofdzakelijk worden ingezet voor professionele, high-end systemen. Je hoeft het niet van mij aan te nemen, je kan het zo verifiëren in de broncode, want dergelijke software is vanzelfsprekend open source.

https://stackoverflow.com/questions/14949459/whats-the-standard-way-of-dealing-with-apps-that-need-to-access-privileged-port

Daar staat dat het onder Unix geen punt is omdat een daemon na openen van de poort zijn rechten kan verlagen naar een service-account en daarmee verder draaien. VMS heeft kennelijk een bypass-mechanisme om naar gepriviligeerde poorten te luisteren.

Windows wordt daar niet genoemd. Je reactie snijdt alleen hout als er in Windows geen oplossing is hiervoor. Kan een proces in Windows zijn rechten niet verlagen, met behoud van open poorten, file handles etc.? Is het in Windows, zoals in Unix/Linux wel kan, onmogelijk om de besturing aan een ander programma door te geven met behoud van open poorten, file handles etc.? Die twee mechanismen samen maken het in Unix/Linux een fluitje van een cent om de riskante privileges volledig in andere programmacode onder te brengen dan waar de riskante operaties zich bevinden. Mist Windows daar werkelijk voorzieningen voor?

Jij hebt op deze website regelmatig gekankerd dat de slechte gewoonte om geen service-accounts voor services aan te maken iets uit de Linux/OSS-wereld zou zijn [1]. Ik ben het er roerend mee eens dat dat een slechte gewoonte is, alleen zag en zie ik het op Linux- of *BSD-systemen niet terug, en nu blijkt Microsoft zelf het bij een toch wel heel belangrijk produkt op Windows niet toe te passen.

[1] Bijvoorbeeld: https://www.security.nl/posting/645837/Aanvallers+zoeken+actief+naar+kwetsbare+Exchange-servers#posting645914

Dat gedoe met poorten komt uit de unix wereld. Zie de link. De eis om het de laag genummerde poorten af te handelen is een open standaard en gewoon verplicht. Webservers gescheiden inrichten van die poorten is een uitdaging. Met shellshock is er een pleiter op geplakt niet het werkelijke probleem aangepakt. Komt uit de jaren 60 meer dan 60 jaar geleden PDP 8 PDP 11 toen dat de professionele stand alones waren. Alleen met VMS NT is er een echte stap gemaakt.
Mainframes benaderen het anders met SVC SNA en protected memory in ringen. Het was te duur het moest goedkoper
Sellinux is ook maar beperkt een pleister op het ontwerp dat met root alles open moet. Ik heb nog niemand gezien die daar zelf wat mee kon. Webshell hacks zijn nog vrij normaal , veel helpt het niet.

Als je het over beheerders hebt die van alles open zetten omdat het dan werkt. Dat is goedkoop en levert snel resultaat, heel agile en lean totdat het fout gaat. Zie je overal gebeuren.

Vandaar dat er met opensource zoveel mis is. Iedereen kan het zien dat het fout is maar niemand kijkt er echt want ze geloven dat een ander dat wel gratis en voor niets doet. Ken de geschiedenis en de huidige status aub.

Aangezien dat in de *nix-wereld helemaal geen uitdaging is neem ik aan dat je het nu over een ander besturingssysteem hebt en webserver die daarop draait. Laat ons eens delen in je inzichten zodat we ervan kunnen leren. Over welke software heb je het en waarom is het daar zo'n uidaging?

Wat je hier beweert is even onzinnig als roepen dat het automagisch goed zit bij open source. Er zijn projecten waar dit vreselijk goed gaat en ook projecten waar het een zooitje is. Net zoals er propriëtaire leveranciers zijn waar het vreselijk goed gaat en propriëtaire leveranciers waar het een zooitje is.

Het topic is een zeer ernstig probleem met een Microsoft product. Vervolgens begin jij over TCP/IP poorten die op een ander systeem als root afgehandeld zouden moeten worden. Zoals ik al zei. Je kletst uit je soepslabbernek. Het is beter om niet te trollen over zaken waar je geen verstand van hebt en ook nog een eens totaal offtopic is.

Ik dacht dat ik zowat de enige was die het een rommel vind daar bij microsoft.

Ze zijn eindelijk begonnen om naar mijn technet account problemen te kijken, en dan wordt ik ge cc, in email correspondentie waarbij de ene indische (dat moet ik er bij vermelden, zodat duidelijk is op welk niveau het gebeurd) support afdeling de andere support afdeling aan het bedanken is voor de support, met nog steeds als resultaat dat het niet werkt.

Jij hebt het nu niet over hoe ze technische ondersteuning hebben georganiseerd en hoe dat functioneert. In een bedrijf met wereldwijd 166.000 werknemers heeft dat vermoedelijk geen enkele relatie met de ontwerpkeuzes van softwarearchitecten. Ze zitten al heel lang niet meer met zijn drieën vanuit een garage te werken.

En zelfs al vind ik het verbluffend dat ze een serverproces met zoveel rechten laten draaien, daarmee zeg ik beslist niet dat alles aan die software of aan wat Microsoft in het algemeen maakt slecht in elkaar zit. Er is heel veel software, en er zijn heel veel andersoortige produkten, zeker als het complexe produkten zijn, die in sommige opzichten geweldig in elkaar zitten en in andere opzichten opeens verrassend knullig blijken te zijn. Dat komt omdat er aan complexe produkten onvermijdelijk grote aantallen mensen meebouwen die niet allemaal even goed zijn of op dezelfde lijn zitten.

Dat wil niet zeggen dat ik het daarmee oké vindt dat een serverproces als Exchange met zoveel rechten draait, ik vind dat werkelijk een slechte keuze. Maar ik heb geen idee waarom die keuze is gemaakt, en of er redenen zijn waarom dat moeilijk anders kan en wat die redenen dan zijn. Mede omdat ik dat soort dingen niet overzie vroeg ik of ik iets miste.

Er wordt gesmeten met termen als "Microsoft is rommel" omdat er ingebroken wordt maar tegelijkertijd willen we allemaal maar al te graag gebruik maken van de handigheidjes.

Gelukkig zijn er experts die het allemaal beter weten in de digitale wereld.
Gezien het in de echte wereld met fysieke sloten inbraak niet meer voorkomt, zou de digitale wereld hier dus voorbeeld aan moeten nemen.

..ow wacht maar fysieke inbraak komt ook nog steeds dagelijks voor, ondanks de fysieke beveiliging techniek duizenden en duizenden jaar oud is, is het nog steeds zo lek als een zeef. Ieder jaar wordt er wel in een bank ingebroken of gelddepot, waar de allerhoogste fysieke beveiliging beschikbaar is, naast digitale beveiliging.

kijk een product als asbest noem ik nou troep. daar is de mensheid op achteruit gegaan. Makers van innovatieve oplossingen waar de wereld beter op geworden is, kan je geen troep noemen. Dat er misbruik van gemaakt wordt, ja het zit blijkbaar in onze genen en zal altijd zo blijven het kat en muis spel..

Dit is een artikel uit 2001 dat beschrijft waarom MS met Exchange 2000 is afgestapt van service-accounts en LocalSystem is gaan gebruiken:
https://www.itprotoday.com/email-and-calendaring/running-exchange-services-localsystem
Kennelijk moesten systeembeheerders zelf de service accounts opzetten en was het nogal makkelijk om daar fouten bij te maken die kennelijk security-implicaties hadden. LocalSystem zou zelfs enkele eigenschappen hebben die de beveiliging ten goede komen.

Verdiep je eens in Windows, en dannkom je er achter dat er veel meer kan dan je denkt.
Zelfs services onder 'system' kan je beperken waar ze wel of niet kunnen schrijven op het filesysteem...
Dat vele applicaties (waaronder MS applicaties) hier al 10 jaar geen gebruik van maken weet ik niet.
De DHCP service is een voorbeeld service waarbij de rechten ingekort zijn, en welke niet overal kan schrijven.

In dit specifieke voorbeeld is het dus niet het OS dat te wensen over laat, maar de applicatie.
Het OS voldoet netjes aan de hoge eisen (waar je naar verwijst) van de 'professionele besturingssystemen '...

Ik dacht dat iedereen ondertussen wel bekend was met de redenen voor de objectief belabberde kwaliteit van genoemde niet-professionele software.


https://www.quora.com/Why-can%E2%80%99t-Microsoft-make-software-of-the-same-quality-as-Google