Storing Rackspace door beveiligingsincident in hosted Exchange-omgeving
Hostingbedrijf Rackspace heeft al een aantal dagen te maken met een storing in de hosted Exchange-omgeving die is veroorzaakt door een beveiligingsincident. Op 2 december meldde Rackspace dat er een probleem was met de hosted Exchange-omgevingen waardoor klanten problemen met de toegang hadden. De wachttijden van klanten met vragen werd zo groot dat Rackspace naar eigen zeggen duizend man extra personeel inzette om support te verlenen.
Na verschillende updates meldde Rackspace op 3 december dat de storing is veroorzaakt door een beveiligingsincident. Om wat voor soort incident het precies gaat laat het hostingbedrijf niet weten. Gisteren waren er nog steeds problemen met de Exchange-omgevingen waardoor klanten niet bij hun mail konden, tenzij ze verschillende workarounds doorvoerden. Tevens is Rackspace begonnen om alle getroffen klanten te bellen.
Volgens beveiligingsonderzoeker Kevin Beaumont draaide één van de Rackspace-servers mogelijk een kwetsbare versie van Exchange. Dit is niet door Rackspace bevestigd en Beaumont weet het ook niet met zekerheid, aangezien Exchange-buildnummers niet altijd betrouwbaar zijn, maar het is wel opvallend, aldus de onderzoeker. De server in kwestie zou op basis van het buildnummer sinds augustus niet meer zijn bijgewerkt met patches en daardoor kwetsbaar zijn voor het actief aangevallen ProxyNotShell-lek waarvoor Microsoft in november met updates kwam.
Rackspace laat vanochtend weten dat het de e-maildiensten al voor duizenden klanten heeft hersteld en bezig is om dit voor alle getroffen klanten te doen.
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
Dan kunnen die de boel zelf veilig houden, ze hebben daar vast de updates eerder dan de rest van de wereld.
(er zijn zelfs geruchten dat ze daar heen heel andere versie draaien, onder Linux)
Helemaal mee eens, ook alle alternatieven zijn mogelijk kwetsbaar wanneer ze niet goed worden onderhouden.
Het begint toch echt bij het op orde houden van de basishygiene. Het is opvallend hoe vaak een veiligheidsincident is terug te leiden naar slecht uitgevoerd lifecycle management (LCM).
Een welgemeend advies, zorg dat jouw IT leverancier transparant over het risico van LCM rapporteert. De afnemer is veelal risico-eigenaar en draagt de lasten als het mis gaat.
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
Er is geen duidelijke relatie tussen de geinstalleerde patches en buildnummers. Het buildnummer wijzigt als je patches installeert (en daarom kun je dus ook zien of er patches zijn geinstalleerd). Het vertelt echter niet welke patches niet zijn geinstalleerd.
Peter
Er is geen duidelijke relatie tussen de geinstalleerde patches en buildnummers. Het buildnummer wijzigt als je patches installeert (en daarom kun je dus ook zien of er patches zijn geinstalleerd). Het vertelt echter niet welke patches niet zijn geinstalleerd.
wel- of niet geinstalleerd kunnen worden. Wil je het overzichtelijk een beheersbaar houden dan moeten alle patches
cumulatief zijn en leiden tot 1 bepaald buildnummer. Maar dan haal je de optie weg om bepaalde patches niet te
installeren (bijv omdat ze problemen geven in je organisatie) en latere patches wel.
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
Er is geen duidelijke relatie tussen de geinstalleerde patches en buildnummers. Het buildnummer wijzigt als je patches installeert (en daarom kun je dus ook zien of er patches zijn geinstalleerd). Het vertelt echter niet welke patches niet zijn geinstalleerd.
Peter
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
Er is geen duidelijke relatie tussen de geinstalleerde patches en buildnummers. Het buildnummer wijzigt als je patches installeert (en daarom kun je dus ook zien of er patches zijn geinstalleerd). Het vertelt echter niet welke patches niet zijn geinstalleerd.
Peter
dan ga jij maar lekker met rackspace en Kevin hier over discusieren.
citaat uit originele post:
"Volgens beveiligingsonderzoeker Kevin Beaumont draaide één van de Rackspace-servers mogelijk een kwetsbare versie van Exchange. Dit is niet door Rackspace bevestigd en Beaumont weet het ook niet met zekerheid, aangezien Exchange-buildnummers niet altijd betrouwbaar zijn, maar het is wel opvallend, aldus de onderzoeker."
Helemaal mee eens, ook alle alternatieven zijn mogelijk kwetsbaar wanneer ze niet goed worden onderhouden.
Het begint toch echt bij het op orde houden van de basishygiene. Het is opvallend hoe vaak een veiligheidsincident is terug te leiden naar slecht uitgevoerd lifecycle management (LCM).
Een welgemeend advies, zorg dat jouw IT leverancier transparant over het risico van LCM rapporteert. De afnemer is veelal risico-eigenaar en draagt de lasten als het mis gaat.
Een goed voorbeeld is de mailserver banner (smtp), die je kan aanpassen; je kan dan ook een nep-build nummer tonen.
"aangezien Exchange-buildnummers niet altijd betrouwbaar zijn"
en hoe weet je dan zeker dat je up to date bent?
Inderdaad, maar ik zou niet teveel klagen op QA want dan wordt je account gewoon verwijderd.
Dat heeft weinig zin als de source gestolen is en programmeerkwaliteit van laag niveau is.
Dat heeft weinig zin als de source gestolen is en programmeerkwaliteit van laag niveau is.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
