Microsoft: tienduizend organisaties doelwit van phishingaanval met proxyserver
Sinds vorig jaar september zijn meer dan tienduizend organisaties het doelwit van een phishingaanval geworden waarbij aanvallers een proxyserver inzetten om tweefactorauthenticatie te omzeilen en sessiecookies van het doelwit te stelen. De gecompromitteerde accounts worden vervolgens gebruikt voor het plegen van Business Email Compromise (BEC) fraude, zo stelt Microsoft in een analyse.
De aanval begint met een e-mail waarin wordt gesteld dat de ontvanger een voicemailbericht kan afluisteren. Wanneer de ontvanger de meegestuurde html-bijlage opent wordt hij doorgestuurd naar een phishingsite. Deze phishingsite draait op een proxyserver die zich tussen de gebruiker en de echte Microsoft-inlogpagina bevindt. Zodra de gebruiker zijn wachtwoord invoert wordt dat naar de echte inlogpagina doorgestuurd.
De echte inlogpagina vraagt vervolgens om de multifactorauthenticatie. De proxyserver laat dit verzoek aan de gebruiker zien. Zodra die de authenticatiegegevens invoert worden die doorgestuurd naar de inlogpagina, die een sessiecookie teruggeeft. De aanvaller injecteert het sessiecookie in zijn browser om het authenticatieproces over te slaan, ook als het doelwit van multifactorauthenticatie gebruikmaakt, zo laat Microsoft weten.
Sinds vorig jaar september zijn meer dan tienduizend organisaties op deze manier aangevallen, waarbij de aanvallers het hebben voorzien op Office 365-gebruikers. De phishingpagina doet zich namelijk voor als de online inlogpagina van Office. Zodra de aanvallers toegang tot een account hebben zoeken ze naar financieel gerelateerde e-mailconversaties of andere mogelijkheden om BEC-fraude te plegen.
Bij BEC, waar ook ceo-fraude onder valt, weten aanvallers via bijvoorbeeld phishing of zwakke of hergebruikte wachtwoorden toegang tot e-mailaccounts te krijgen. Via de gekaapte accounts, maar ook door gebruik te maken van gespoofte e-mailadressen of typosquatting, waarbij ze domeinen registreren die op die van een legitieme organisatie lijken, sturen de aanvallers malafide e-mails.
Zo doen de oplichters zich bijvoorbeeld voor als leverancier en verzoeken afnemers om betalingen naar andere rekeningen over te maken, of wordt de financiële administratie van een aangevallen organisatie verzocht om bepaalde facturen te betalen, waarbij het geld moet worden overgemaakt naar door de aanvallers opgegeven rekeningen. De door BEC veroorzaakte schade bedroeg tussen juni 2016 en december 2021 ruim 43 miljard dollar, aldus de FBI afgelopen mei.
Zodra de aanvallers een geschikte e-mailconversatie vinden proberen ze de fraude te plegen. Om detectie te voorkomen maken de aanvallers een inboxregel aan om toekomstige reacties van het beoogde doelwit te verbergen, alsmede verzonden berichten. Naast een analyse van de phishingaanval heeft Microsoft ook een overzicht gepubliceerd van de verschillende phishingdomeinen die de aanvallers gebruikten.
Reacties (25)
Creatief. Dat maakt deze industrie zo interessant. Kat en muis spelletje... Love it!
Het probleem is duidelijk. Maar wat is de oplossing? Three Factor Authentication? Four Factor Authentication? Five Factor Authentication? Langere wachtwoorden? Inloggen met gezichtsherkenning?
Mooi om te zien dat met WebAuthN/Fido2 iig het inloggen is te voorkomen.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Uit https://www.microsoft.com/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/:
We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
MFA can block over 99.9 percent of account compromise attacks
Dat was dus bull shit, net zoals de onzin destijds dat SPF (en later DKIM en nog later DMARC) spam en phishing zouden voorkomen.We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
Door Erik van Straten: Uit https://www.microsoft.com/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/:
We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
MFA can block over 99.9 percent of account compromise attacks
Dat was dus bull shit, net zoals de onzin destijds dat SPF (en later DKIM en nog later DMARC) spam en phishing zouden voorkomen.We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
Door Erik van Straten: Uit https://www.microsoft.com/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/:
We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
MFA can block over 99.9 percent of account compromise attacks
Dat was dus bull shit, net zoals de onzin destijds dat SPF (en later DKIM en nog later DMARC) spam en phishing zouden voorkomen.We bedenken te vaak oplossingen voor actuele aanvalstechnieken (en zetten die met veel poeha in de markt) zonder na te denken over hoe aanvallers zich kunnen (en dus zullen) aanpassen.
MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Door Anoniem: Het probleem is duidelijk. Maar wat is de oplossing? Three Factor Authentication? Four Factor Authentication? Five Factor Authentication? Langere wachtwoorden? Inloggen met gezichtsherkenning?
Bewustzijn en zorgvuldigheid. Het komt hier weer op het zelfde neer. "gebruiker wordt verwezen naar een onbetrouwbaar adres".
Je wil geen biometrisch relevante informatie op je computer en dan trek je trouwens weer een blik met wormen open/graaf je je alleen maar dieper in.
Door Anoniem: Mooi om te zien dat met WebAuthN/Fido2 iig het inloggen is te voorkomen.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Kan bij Fido niet de proxy een eigen hardware sleutel virtualiseren en de gebruiker zich laten registeren bij de proxy, die hetzelfde doet bij de aangevallen website? Een beetje leuke bewoording erom heen en de gebruiker trapt er weer in.
Zover ik weet is een Fido sleutel alleen maar een USB stick met een knopje erop dat je als gebruiker in moet drukken om toestemming te geven. Zowel voor registratie als voor login. Hetzelfde knopje.
Awareness trainingen voor gebruikers..zolang de gebruiker niet kan inschatten met wat voor website deze zaken heeft, blijft het dweilen met de kraan open.
Dan kun je meteen met technische oplossingen komen, maar die zullen maar deels de "stupidity of users" kunnen inschatten.
Dan kun je meteen met technische oplossingen komen, maar die zullen maar deels de "stupidity of users" kunnen inschatten.
Door Anoniem: Creatief. Dat maakt deze industrie zo interessant. Kat en muis spelletje... Love it!
Totdat je eigen business/private rekening geplunderd wordt (lol) Love it
prachtig de vooruitgang en digitalisering
Het probleem hier is dat de link tussen de gebruiker en in dit geval microsoft bestaat uit verschillende sessies.
En DAT zou nooit moeten kunnen gebeuren.
En DAT zou nooit moeten kunnen gebeuren.
Gewoon nooit via een email ergens op inloggen wanneer je die mail niet zelf hebt geïnitieerd.
Klinkt als een simpele evilginx2 site..
Wel komt MS binnenkort met de optie om sessies te laten verlopen, dat gaat de enige remedie zijn tegen het stelen van je sessiecookies.
Wel komt MS binnenkort met de optie om sessies te laten verlopen, dat gaat de enige remedie zijn tegen het stelen van je sessiecookies.
Kan bij Fido niet de proxy een eigen hardware sleutel virtualiseren en de gebruiker zich laten registeren bij de proxy, die hetzelfde doet bij de aangevallen website? Een beetje leuke bewoording erom heen en de gebruiker trapt er weer in.
Zover ik weet is een Fido sleutel alleen maar een USB stick met een knopje erop dat je als gebruiker in moet drukken om toestemming te geven. Zowel voor registratie als voor login. Hetzelfde knopje.
Nee, de client "de browser" stuurt het domein en een teller mee plus nog een hoop info.
Deze info wordt tevens ondertekent met de sleutelpaar, alleen geldig voor een site en accoutn, door de hardware sleutel.
De server krijgt deze informatie gesigneerd terug en kan controleren of het klopt.
Daarnaast moet je eerst ingelogd zijn bij Microsoft voor dat je je sleutel kan registeren.
Deze video legt aardig uit hoe het werkt en wat er heen en weer wordt gestuurd.
https://www.youtube.com/watch?v=RFACQvL_8S4
Door Anoniem:
Kan bij Fido niet de proxy een eigen hardware sleutel virtualiseren en de gebruiker zich laten registeren bij de proxy, die hetzelfde doet bij de aangevallen website? Een beetje leuke bewoording erom heen en de gebruiker trapt er weer in.
Zover ik weet is een Fido sleutel alleen maar een USB stick met een knopje erop dat je als gebruiker in moet drukken om toestemming te geven. Zowel voor registratie als voor login. Hetzelfde knopje.
Door Anoniem: Mooi om te zien dat met WebAuthN/Fido2 iig het inloggen is te voorkomen.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Helaas het openen van de site niet.
WebAuthN checkt ook het domein om de bijbehorende certificaat te kiezen.
Bij deze aanval match dat niet en komt je dus ook niet verder.
Kan bij Fido niet de proxy een eigen hardware sleutel virtualiseren en de gebruiker zich laten registeren bij de proxy, die hetzelfde doet bij de aangevallen website? Een beetje leuke bewoording erom heen en de gebruiker trapt er weer in.
Zover ik weet is een Fido sleutel alleen maar een USB stick met een knopje erop dat je als gebruiker in moet drukken om toestemming te geven. Zowel voor registratie als voor login. Hetzelfde knopje.
Voor het registreren van een nieuwe beveiligingssleutel moet je eerst inloggen, wat dus niet kan door de proxy heen.
In de praktijk zal je zien dat FIDO2 sleutels alleen ook niet voldoende zijn. Andere loginmethoden moeten namelijk expliciet uitgeschakeld worden om een downgrade naar SMS codes te voorkomen. ( dit is bijvoorbeeld het idee achter Google Advanced Protection)
En als laatste toevoeging: er is ook een visuele prompt in de browser of besturingssysteem die aangeeft of je gaat inloggen of dat je een nieuw account registreert. Dat onderscheid is dus wel aanwezig, ook al is de 'gesture' van het indrukken van een knop hetzelfde.
13-07-2022, 16:05 door
Erik van Straten
Door Anoniem: MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat je "eeuwig aangelogd blijft" is een ander probleem - nl. als jouw device gecompromitteerd is (of in verkeerde handen valt) en aanvallers zich, via jouw device (of met een session-cookie gekopieerd van jouw device), op jouw accounts kunnen voordoen als jou in de cloud en op systemen aan het lokale netwerk.Echter, als jouw device (of jouw account op jouw device) gecompromitteerd is, helpt helemaal niets meer - ook geen MFA.
MFA is in het redactie-artikel wel degelijk het probleem, want het doel van MFA is voorkómen dat anderen als jou op jouw cloudaccounts kunnen inloggen met hun eigen device (of van derden), omdat ze jouw e-mailadres kennen en jouw wachtwoord kunnen raden, brute-forcen of achterhalen (bijv. doordat jij jouw inloggegevens invoert op een nepsite). Dit alles zonder dat jouw device (of jouw account op jouw device) gecompromitteerd is.
Door Erik van Straten:
Het kernprobleem is dat het web stateless werkt en de gebruikers stateful willen werken. "ik ben ingelogd" dat is een state die het web niet kent.Door Anoniem: MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat je "eeuwig aangelogd blijft" is een ander probleem - nl. als jouw device gecompromitteerd is (of in verkeerde handen valt) en aanvallers zich, via jouw device (of met een session-cookie gekopieerd van jouw device), op jouw accounts kunnen voordoen als jou in de cloud en op systemen aan het lokale netwerk.Dus wordt er gerotzooid met placebo oplossingen zoals "sessiecookies". Die zijn niet aan de inlogsessie gekoppeld dus kunnen ze gecopieerd en gestolen worden. Dat is dus geen oplossing.
Er moet een nieuwe "sessie laag" gemaakt worden (dat wisten we al in de tijd van het ISO/OSI model, voor dat TCP/IP populair werd en de bovenste lagen als overbodig aan de kant geveegd werden) die een cryptografisch veilige sessie tussen een client en een service kan opzetten die niet onderweg ge-hijacked kan worden.
Dat zal wellicht nog best lastig zijn in een wereld waarin we met "cloud" services werken ipv met een specifieke server communiceren, en waarin het gebruiken van globaal unieke ID's om clients te identificeren ook al met gefrons benaderd wordt.
Door Anoniem:
Dus wordt er gerotzooid met placebo oplossingen zoals "sessiecookies". Die zijn niet aan de inlogsessie gekoppeld dus kunnen ze gecopieerd en gestolen worden. Dat is dus geen oplossing.
Er moet een nieuwe "sessie laag" gemaakt worden (dat wisten we al in de tijd van het ISO/OSI model, voor dat TCP/IP populair werd en de bovenste lagen als overbodig aan de kant geveegd werden) die een cryptografisch veilige sessie tussen een client en een service kan opzetten die niet onderweg ge-hijacked kan worden.
Dat zal wellicht nog best lastig zijn in een wereld waarin we met "cloud" services werken ipv met een specifieke server communiceren, en waarin het gebruiken van globaal unieke ID's om clients te identificeren ook al met gefrons benaderd wordt.
Door Erik van Straten:
Het kernprobleem is dat het web stateless werkt en de gebruikers stateful willen werken. "ik ben ingelogd" dat is een state die het web niet kent.Door Anoniem: MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat je "eeuwig aangelogd blijft" is een ander probleem - nl. als jouw device gecompromitteerd is (of in verkeerde handen valt) en aanvallers zich, via jouw device (of met een session-cookie gekopieerd van jouw device), op jouw accounts kunnen voordoen als jou in de cloud en op systemen aan het lokale netwerk.Dus wordt er gerotzooid met placebo oplossingen zoals "sessiecookies". Die zijn niet aan de inlogsessie gekoppeld dus kunnen ze gecopieerd en gestolen worden. Dat is dus geen oplossing.
Er moet een nieuwe "sessie laag" gemaakt worden (dat wisten we al in de tijd van het ISO/OSI model, voor dat TCP/IP populair werd en de bovenste lagen als overbodig aan de kant geveegd werden) die een cryptografisch veilige sessie tussen een client en een service kan opzetten die niet onderweg ge-hijacked kan worden.
Dat zal wellicht nog best lastig zijn in een wereld waarin we met "cloud" services werken ipv met een specifieke server communiceren, en waarin het gebruiken van globaal unieke ID's om clients te identificeren ook al met gefrons benaderd wordt.
Een "nieuwe laag". Goodie. Typisch software engineer: "Elk probleem kent een technische oplossing." Kijk eens in de spiegel en vraag je af hoe we in deze situatie beland zijn...
Door Anoniem: Voor het registreren van een nieuwe beveiligingssleutel moet je eerst inloggen, wat dus niet kan door de proxy heen.
De eerste keer zal dit inloggen echter zonder beveiligingssleutel zijn. En mensen worden steeds meer verplicht door Microsoft en Google om accounts steeds verder te beveiligen.
Een aanvaller kan dus zich voordoen als Microsoft of Google, en de gebruiker laten upgraden naar een veiliger account, terwijl de aanvaller dit nieuwe account zelf aanmaakt via de proxy. Alles werkt. Microsoft blij, gebruiker blij. Tot de aanvaller zich begint te manifesteren en de identiteit van de gebruiker volledig overneemt.
Gebruikers zijn niet blij als ze niet meer kunnen inloggen bij Microsoft of Google. Maar dan is het te laat en is het tijd om paspoorten in te gaan scannen.
Mensen in de comments hier weten totaal niet hoe een webproxy werkt. Je kan hier bijna niets aan doen omdat de sessie niet wordt gekaapt maar in de plaats van het slachtoffer wordt gecreëert. Het is de proxy die aanmeld en niet de gebruiker.
De enigste beveiliging hier is de gebruiker die niet in phishing mag trappen. En aan de kant van Microsoft het actief opvolgen van de IP adressen die proxyservers gebruiken.
Ikzelf ben webdeveloper met een blackhat verleden en kan je vertellen dat dit 1 van de beste aanvallen is die er zijn.
De enigste beveiliging hier is de gebruiker die niet in phishing mag trappen. En aan de kant van Microsoft het actief opvolgen van de IP adressen die proxyservers gebruiken.
Ikzelf ben webdeveloper met een blackhat verleden en kan je vertellen dat dit 1 van de beste aanvallen is die er zijn.
Door Anoniem:
Wat je beschrijft bestaat al en heet TLS. Echter de enige vorm van (client) authenticatie in TLS, met Client Certificates, had vele UX en privacy problemen. Bovendien was de koppeling met HTTP nooit goed gespecificeerd, wat verschillende security problemen gaf. (Naar mijn weten zijn een aantal problemen wel opgelost in TLSv1.3, echter is er nog steeds geen goed koppeling tussen Client Certificates en HTTP2. Wat vooral aangeeft dat je weinig ondersteuning moet wachten op dat gebied.)Door Erik van Straten:
[...] Er moet een nieuwe "sessie laag" gemaakt worden (dat wisten we al in de tijd van het ISO/OSI model, voor dat TCP/IP populair werd en de bovenste lagen als overbodig aan de kant geveegd werden) die een cryptografisch veilige sessie tussen een client en een service kan opzetten die niet onderweg ge-hijacked kan worden. [...]Door Anoniem: MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat je "eeuwig aangelogd blijft" is een ander probleem - nl. als jouw device gecompromitteerd is (of in verkeerde handen valt) en aanvallers zich, via jouw device (of met een session-cookie gekopieerd van jouw device), op jouw accounts kunnen voordoen als jou in de cloud en op systemen aan het lokale netwerk.Een recentere oplossing was de token binding specificatie, zie https://en.wikipedia.org/wiki/Token_Binding.
Helaas is dat uiteindelijk ook een stille dood gestorven.
14-07-2022, 00:07 door
Erik van Straten
Door Anoniem: Mensen in de comments hier weten totaal niet hoe een webproxy werkt.
Volgens mij valt dat best mee.Door Anoniem: De enigste beveiliging hier is de gebruiker die niet in phishing mag trappen. En aan de kant van Microsoft het actief opvolgen van de IP adressen die proxyservers gebruiken.
Er zijn meer mogelijkheden - mits het account al bestaat (er helpt bar weinig tegen een aanvaller die erin slaagt om een slachtoffer een account te laten aanmaken op een nepsite).Bij FIDO2 (hardware) keys wordt per eerder aangemaakt account, naast user-ID en unieke private key, ook de domeinnaam van de server opgeslagen. Het zijn ondingen, maar tenzij een aanvaller een geldig certificaat voor z'n proxy voor de domeinnaam in jouw FIDO-key heeft verkregen (bijv. door het DNS-record te hacken en er een Let's Encrypt cert op te zetten, of door een CSP om te kopen), is het knap lastig om een MitM aanval met succes uit te voeren.
De door alle grote techbedrijven aangekondigde PassKeys werken ook met WebAuthn, en zijn daarmee min of meer vergelijkbaar met FIDO2 hardware keys. Het gebruiksgemak is echter een stuk groter dan bij hardware keys, maar er zijn ook nieuwe risico's.
Er zijn ook andere technieken denkbaar waarbij MitM's worden uitgesloten, zelfs het type aanvallen met een onterecht verkregen certificaat (vanzelfsprekend uitgaande van een bijpassende private key, want aan alleen een certificaat heb je niks).
tijd voor oAuth-DPoP.
Microsoft heeft al zoiets met z'n Contious access evaluation in combinatie met AzureAD.
Microsoft heeft al zoiets met z'n Contious access evaluation in combinatie met AzureAD.
Door Anoniem:
MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat ligt aan de instellingen. Microsoft is naar consumentengebruikers niet zo streng en het geeft toch een beetje extra veiligheid met zo min mogelijk ongemak, gezien het apparaten vertrouwt.
Wij hebben Microsoft's SSO hier zo ingesteld dat op kantoor je nooit om de 2de factor gevraagd wordt, maar werk je buiten het kantoor dan mag je elke keer dat je inlogt ook de 2de factor even uitvoeren.
Door Anoniem:
Dat ligt aan de instellingen. Microsoft is naar consumentengebruikers niet zo streng en het geeft toch een beetje extra veiligheid met zo min mogelijk ongemak, gezien het apparaten vertrouwt.
Wij hebben Microsoft's SSO hier zo ingesteld dat op kantoor je nooit om de 2de factor gevraagd wordt, maar werk je buiten het kantoor dan mag je elke keer dat je inlogt ook de 2de factor even uitvoeren.
Door Anoniem:
MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat ligt aan de instellingen. Microsoft is naar consumentengebruikers niet zo streng en het geeft toch een beetje extra veiligheid met zo min mogelijk ongemak, gezien het apparaten vertrouwt.
Wij hebben Microsoft's SSO hier zo ingesteld dat op kantoor je nooit om de 2de factor gevraagd wordt, maar werk je buiten het kantoor dan mag je elke keer dat je inlogt ook de 2de factor even uitvoeren.
Idd, is configureerbaar.
Daarbij is het ook belangrijk om mee te nemen dat er direct verband zit tussen het aantal MFA-prompts en de waarde daarvan. Hoe meer MFA-prompts, hoe groter de kans dat gebruikers blindelings "OK" tappen. Dat is precies waarom Microsoft en anderen al langer adviseren om te streven naar een minimale hoeveelheid prompts.
Door Anoniem:
Nee dat klopt niet... TLS is onderdeel van de transportlaag. Wat je had moeten hebben is een aparte sessielaag die een sessie beschrijft met een service, en waar een of meer transportlaag verbindingen deel van uitmaken.Door Anoniem:
Wat je beschrijft bestaat al en heet TLS. Door Erik van Straten:
[...] Er moet een nieuwe "sessie laag" gemaakt worden (dat wisten we al in de tijd van het ISO/OSI model, voor dat TCP/IP populair werd en de bovenste lagen als overbodig aan de kant geveegd werden) die een cryptografisch veilige sessie tussen een client en een service kan opzetten die niet onderweg ge-hijacked kan worden. [...]Door Anoniem: MFA is hier niet het probleem, wel dat Microsoft het maar 1 keer vraagt en je dan eeuwig aangelogd blijft ...
Dat je "eeuwig aangelogd blijft" is een ander probleem - nl. als jouw device gecompromitteerd is (of in verkeerde handen valt) en aanvallers zich, via jouw device (of met een session-cookie gekopieerd van jouw device), op jouw accounts kunnen voordoen als jou in de cloud en op systemen aan het lokale netwerk.Dus je doet een onderhandeling vergelijkbaar met TLS, inclusief man-in-the-middle detectie mbv certificaten, en uiteindelijk heb je een sessie die je die hele dag gaat gebruiken met die service. Daarbinnen maak en verbreek je meerdere TCP verbindingen voor je "web gebruik" die allemaal onderdeel uitmaken van die gevalideerde sessie.
Dan is het niet meer mogelijk om ergens onderweg die info te onderscheppen en te copieren.
Reageren
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.
