Microsoft: aanvallers kregen via malafide OAuth-applicaties toegang tot e-mail
De groep aanvallers die op systemen van Microsoft wist in te breken en daarbij e-mail en bijlagen buitmaakte deed dit via malafide OAuth-applicaties, zo laat het techbedrijf in een update over het incident weten. Microsoft stelt verder dat meerdere organisaties door de groep zijn aangevallen en het begonnen is om deze organisaties te informeren. Eerder meldde Hewlet Packard Enterprise (HPE) al dat het slachtoffer van de groep was geworden, die bekendstaat als Cozy Bear en Midnight Blizzard. Eerder maakten de Amerikaanse en Britse autoriteiten bekend dat deze groep onderdeel van de Russische geheime dienst SVR is.
De groep had wekenlang toegang tot e-mailaccounts van Microsoft, waarbij er vooral werd gezocht naar wat het techbedrijf over de groep wist, aldus een verklaring van Microsoft zelf. Het bedrijf stelt dat het de aanvallen uiteindelijk opmerkte door loggegevens van Exchange Web Services (EWS) activiteiten en audit logging features te gebruiken. In een nieuwe blogposting over de aanval geeft Microsoft meer details over de werkwijze van Cozy Bear en wat organisaties kunnen doen om zichzelf te beschermen.
Cozy Bear maakt vooral gebruik van password spraying om toegang tot accounts en systemen te krijgen. Dit is een techniek waarbij een aanvaller veelgebruikte wachtwoorden probeert om op een account in te loggen. Om detectie te voorkomen gebruikt een aanvaller eerst één wachtwoord tegen een groot aantal accounts, voordat er een tweede wachtwoord wordt gebruikt. Door deze techniek voorkomt de aanvaller dat een account wordt geblokkeerd en de aanval wordt opgemerkt. Vaak wordt er ook vanaf allerlei verschillende ip-adressen ingelogd.
Malafide OAuth-applicaties
Via de password spraying-aanval kregen de aanvallers toegang tot een Microsoft 'test tenant account'. Vervolgens wisten de aanvallers via dit account een legacy OAuth-applicatie gebruikt voor testdoeleinden te vinden en benaderen. Deze OAuth-applicatie had verhoogde rechten tot de zakelijke Microsoft-omgeving. De aanvallers creëerden vervolgens meerdere malafide OAuth-applicaties en een nieuw gebruikersaccount. Dit account gaf vervolgens toestemming dat de malafide OAuth-applicaties toegang tot de Microsoft-omgeving hadden. Via de applicaties kregen de aanvallers vervolgens toegang tot mailboxes in Office 365 Exchange Online.
De aanvallers gebruikten bij hun aanval ook residentiële proxy-netwerken, waarbij het verkeer liep via ip-adressen van gecompromitteerde gebruikers. Via deze ip-adressen werd de gecompromitteerde tenant gebruikt en ingelogd op Exchange Online. Microsoft stelt dat dit geen nieuwe techniek is, maar dat het gebruik van residentiële proxies om verbindingen te verbergen detectie via traditionele Indicators of Compromise (IoC's), vanwege het grote aantal ip-adressen dat verandert, onpraktisch maakt. Om de aanvallen te voorkomen adviseert Microsoft onder andere om maatregelen tegen password spraying te nemen en op malaifde OAuth-applicaties te monitoren.
De 'fout' lijkt niet in de OAuth implementatie te zitten. Het zit in twee aspecten: de OAuth applicaties die toegang hebben tot de zakelijke Microsoft omgeving, en het gebrek aan fundamentele beveiligingsmaatregelen zoals MFA.
In de 'test omgeving' had een OAuth applicatie bestaande rechten in de zakelijke Microsoft omgeving. Het is opvallend dat Microsoft geen duidelijke scheiding heeft tussen test en productie-omgevingen. Ook is het opvallend dat er dus geen zicht of controle is op alle third-party applicaties die hoge rechten hebben in de zakelijke Microsoft omgeving. Dat staat los van de OAuth implementatie zelf en zegt vooral iets over de controle die Microsoft heeft op derde partijen die bij Microsoft's zakelijke tenant kunnen.
Daarnaast is het opvallend dat er initiële toegang verkregen kon worden tot een account met hoge rechten. Blijkbaar heeft Microsoft geen MFA geïmplementeerd op alle admin accounts, omdat dat niet nodig is in 'test omgevingen'. In feite is dit beveiligingslek ontstaan door het gebrek aan fundamentele beveiligingsmaatregelen. Dat is veel zeggend over de beveiliging van Microsoft, en iedereen die daarvan afhankelijk is.
Vreemd, want is dat niet expliciet de taak van een authentication app ?
Ow, wacht, het is amerikaanse software.. dan is het gewoon even pech... geen backdoor, geen bug, gewoon een tijdelijke feature...
brainwashing is begonnen sinds de marshal hulp verzonnen is... Wat eigenlijk nooit 'hulp' is geweest maar een 2 kanten snijdend mes waarbij afhankelijkheid van de VS en geldstromen richting de VS gegarandeerd werden...
In de 'test omgeving' had een OAuth applicatie bestaande rechten in de zakelijke Microsoft omgeving. Het is opvallend dat Microsoft geen duidelijke scheiding heeft tussen test en productie-omgevingen. Ook is het opvallend dat er dus geen zicht of controle is op alle third-party applicaties die hoge rechten hebben in de zakelijke Microsoft omgeving. ....
Kun je een organisatie noemen die dat wel op orde heeft met een globale beschrijving van de scheiding?
In de 'test omgeving' had een OAuth applicatie bestaande rechten in de zakelijke Microsoft omgeving. Het is opvallend dat Microsoft geen duidelijke scheiding heeft tussen test en productie-omgevingen. Ook is het opvallend dat er dus geen zicht of controle is op alle third-party applicaties die hoge rechten hebben in de zakelijke Microsoft omgeving. ....
Kun je een organisatie noemen die dat wel op orde heeft met een globale beschrijving van de scheiding?
In het algemeen kan iedere ontwikkelaar bij Microsoft een 'Microsoft 365 Developer Tenant' aanvragen. Deze omgevingen zijn bedoeld om nieuwe applicatie te ontwikkelen en testen. Op die manier is het niet nodig om nieuwe applicaties te koppelen aan een bestaande (productie) omgeving.
In het algemeen kan iedere ontwikkelaar bij Microsoft een 'Microsoft 365 Developer Tenant' aanvragen. ....Op die manier is het niet nodig om nieuwe applicaties te koppelen aan een bestaande (productie) omgeving.
Als je met macihine learning te maken hebt heb je juist opetationele productiegegevens nodig.
Gaat het siem of andere zaken die een operationeel process beschrijven dan zit je snel met productiegegevens.
Een kopie van een operationeell systeem met api's blijft met de api's en bijbehorende autorisaties zitten. De nuttige inzet wordt snel sterk ingeperkt. Wil je wel iets wat meer compleet is dan is er een hele kerstboom welke meekomt als het tenmiste veilig by design gebeurt
De 'fout' lijkt niet in de OAuth implementatie te zitten. Het zit in twee aspecten: de OAuth applicaties die toegang hebben tot de zakelijke Microsoft omgeving, en het gebrek aan fundamentele beveiligingsmaatregelen zoals MFA.
In de 'test omgeving' had een OAuth applicatie bestaande rechten in de zakelijke Microsoft omgeving. Het is opvallend dat Microsoft geen duidelijke scheiding heeft tussen test en productie-omgevingen. Ook is het opvallend dat er dus geen zicht of controle is op alle third-party applicaties die hoge rechten hebben in de zakelijke Microsoft omgeving. Dat staat los van de OAuth implementatie zelf en zegt vooral iets over de controle die Microsoft heeft op derde partijen die bij Microsoft's zakelijke tenant kunnen.
Daarnaast is het opvallend dat er initiële toegang verkregen kon worden tot een account met hoge rechten. Blijkbaar heeft Microsoft geen MFA geïmplementeerd op alle admin accounts, omdat dat niet nodig is in 'test omgevingen'. In feite is dit beveiligingslek ontstaan door het gebrek aan fundamentele beveiligingsmaatregelen. Dat is veel zeggend over de beveiliging van Microsoft, en iedereen die daarvan afhankelijk is.
De hoger verkregen rechten hebben vermoedelijk niet te maken met "admin-accounts" maar met rollen die toegekend zijn aan de Azure App Register [OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.]. Het is wel verstandig om de scope van dergelijke applicatie te beperken.
Het gaat om de informatie bepaalde achterliggende verwerkingen wat door projecten en techneuten ingevuld wordt.
Heel agile: als het maar werkt.
Geef eens een duidelijk algemeen ontwerp met Rbac over de hele organisatie wat ook de technische lagen goed invult. Het is er niet voor zover ik weet. Er wordt heel erg op technische incidenten geacteerd. Wat ontbreekt is behoorlijk logisch ontwerp.
In de 'test omgeving' had een OAuth applicatie bestaande rechten in de zakelijke Microsoft omgeving. Het is opvallend dat Microsoft geen duidelijke scheiding heeft tussen test en productie-omgevingen. Ook is het opvallend dat er dus geen zicht of controle is op alle third-party applicaties die hoge rechten hebben in de zakelijke Microsoft omgeving. ....
Kun je een organisatie noemen die dat wel op orde heeft met een globale beschrijving van de scheiding?
In het algemeen kan iedere ontwikkelaar bij Microsoft een 'Microsoft 365 Developer Tenant' aanvragen. Deze omgevingen zijn bedoeld om nieuwe applicatie te ontwikkelen en testen. Op die manier is het niet nodig om nieuwe applicaties te koppelen aan een bestaande (productie) omgeving.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
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.
