Dit zal nog wel veel vaker voorkomen. Het is kinderlijk eenvoudig om een dergelijk netwerk op te zetten met de flipper met wifi devboard of via de vele ESP32 gebaseerde gadgets.

Het risico op AitM (Attacker in the Middle) aanvallen kunt u enorm verkleinen door, in uw browser, "https only" aan te zetten - zoals ik beschreef in punt 9 in https://security.nl/posting/840236/Veilig+inloggen en, afgelopen nacht, in (Engelstalig https://infosec.exchange/@ErikvanStraten/112714124837257580.

Nb. het aanzetten van "https only" betekent niet dat u geen http meer kunt gebruiken; zie https://security.nl/posting/840518 voor details.

Een VPN als security-oplossing aandragen is sowieso al niet juist. Zie https://www.tunnelvisionbug.com/ bijvoorbeeld

Wat ik uit het artikel haal gaat het niet om een MitM aanval, maar juist om het stelen van credentials op een fake login portal. Een VPN of HTTPs doen hier niets tegen.
De beste manier om hier tegen te beschermen is geen openbaar wifi te gebruiken, mocht je dit wel willen doen, dan in geen geval login gegeven prijs geven van bestaande accounts. Naar mijn inziens is dit ook wel een probleem van Google, dat te pas en te onpas vraagt of je niet met Google wilt inloggen. Ik kan me voorstellen dat mensen zo gewend zijn om dit te zien dat het logisch is dat je hiermee ook op een openbaar wifi netwerk kunt inloggen.

Je bent ook wel een idioot ook als je zoiets doet tijdens een vlucht. Of je wilt graag wat meer beton zien in je leven, dat kan ook.

Ook dat is een AitM aanval, maar een puur psychologische. Uiteindelijk maakt een Evil Twin AitM daar ook gebruik van, maar zo'n aanvaller kan handig profiteren van zijn primaire aanvalstechniek (de Evil Twin).

Een "evil twin" is een kwaardaardig WiFi access point met dezelfde naam (SSID) als het echte access point.

Als je daar onbedoeld en onwetend gebruik van maakt, en vervolgens bijvoorbeeld almere.nl of gemeente.amsterdam intikt in de adresbalk van jouw browser, of op een link zoals http://www.buitenhoftv.nl klikt, of de QR-code op een bus Pringles scant (http://pringles.eu/1W9vz52), dan zullen de meeste browsers eerst (stilletjes) https proberen.

Maar die poging kan de AitM blokkeren, en zo de browser dwingen om http te gebruiken.

Zodra dát gebeurt, kan software van de aanvaller ofwel zichzelf voordoen als de betreffende website (*) - echter via http, dus zonder "hangslotje", ofwel de aanvaller kan, nu er sprake is van http, jouw browser onmiddelijk doorsturen naar elke gewenste website (*) die wél https ondersteunt - precies zoals http://gemeente.amsterdam en genoemde BuitenhofTV link doen.

(*) Als de AitM de juiste software gebruikt, zal de inhoud van de nepwebsites identiek zijn aan die van de gespoofde websites, terwijl de aanvaller alles kan meekijken en desgewenst informatie wijzigen.

Probleem: je hoeft niet te zien dat er in een flits van http gebruik gemaakt wordt, en jouw browser wordt doorgestuurd naar een https-ondersteunende website.

Daarom is het uitermate verstandig om een browser te gebruiken die "https only" goed ondersteunt, waarbij je dat dan natuurlijk wel aan moet zetten en het "onthouden" moet uitzetten indien nodig.

In plaats van "https only" gebruiken, kun je hopen dat HSTS () je redt, maar nog veel te veel webservers ondersteunen dat niet of implementeren het onjuist (zoals almere.nl). Bovendien werkt HSTS hooguit als je de website met de betreffende domeinnaam, niet te lang geleden, met dezelfde browser (op hetzelfde apparaat) hebt bezocht.

Aanvulling 14:06 Als je een browser een url laat openen die expliciet met https:// begint (gevolgd door een geldige domeinmaam, zoals security.nl), is het voor een AitM aanvaller onmogelijk (uiterst zeldzame situaties daargelaten) om jouw browser, zonder certificaatfoutmelding, op een andere website uit te laten komen. De enige die jouw browser kan doorsturen is https://security.nl - nadat de browser die server heeft geauthenticeerd en de versleutelde TLS-verbinding tot stand is gekomen.

Overigens is dat doorsturen exact wat https://security.nl doet, namelijk naar https://www.security.nl (een server met een ander IP-adres).

Op een onvertrouwd netwerk kun je er dus het beste op letten om zelf zoveel mogelijk https-links te gebruiken; ik ken geen browser die http probeert als je expliciet om https gevraagd hebt.

Nb. zoals ik onderaan https://infosec.exchange/@ErikvanStraten/112714124837257580 schreef: als je "https only" aanzet en handmatig een http-verbinding met een specifieke domeinnaam toestaat, zullen de meeste browsers die keuze (voor die specifieke website) "een tijdje" onthouden. Bijv. Firefox (Android) moet je geheel sluiten om deze dat te laten "vergeten". In Chrome (Android) helpt sluiten niet; even de instelling "https only" uit en weer aanzetten wel.

Dus ga je van publiek WiFi gebruik maken (bijv. op vakantie)? Als je Firefox (Android) gebruikt, sluit dan eerst jouw browser; in Chrome: zet de instelling "https only" uit en weer aan.

De "https only" instelling in Chrome voor iOS is onbetrouwbaar: http://http.badssl.com is één van de weinige websites waarop ik gewaarschuwd word (niet bij bijv. http://gemeente.amsterdam - wat natuurlijk wel zou moeten). Verder ken ik geen andere browser voor iOS die "https only" (deels) ondersteunt.

Onjuist, die helpen wel.

Aanvulling 14:11: maar een commerciële VPN kan, bij uitstek, een AitM-aanval uitvoeren. Het nemen van alle eerder door mij genoemde maatregelen om http-verbindingen te vermijden, is dus sowieso aan te raden.

Veel mensen gaan binnenkort op vakantie. Wat denk je dat er dan gebeurt?

Ik bezoek zeer veel verschillende websites en word zelden gevraagd om met Google in te loggen (iets wat ik overigens nooit zal doen; ik gebruik op mijn apparaten geïnstalleerde wachtwoordmanagers.

Bovendien heb ik nog nooit gezien dat je "met Google" op WiFi kunt inloggen, en noch het bovenstaande, noch het Australische, artikel vermelden dat. Waarop baseer je die aanname?

Niet dezelfde anoniem, maar uit het artikel :

Niet vreemd dat 'mail' gezien wordt als 'gmail' , aangezien andere mail providers vzviw amper als federated login fungeren, afgezien van O365 .

Dank voor je uitgebreide reactie, ik zie dat je redelijk ingelezen bent in het onderwerp en mij graag verteld waar ik het mis heb.
Ik zal mijn bovenstaand bericht even wat beter toelichten aangezien ik bejegend word van foutieve aannames.

Helaas wordt uit het artikel, noch de onderliggende bronnen duidelijk welke technische implementatie gebruikt is, dus moet ik wat aannames doen.

Ze hebben het specifiek over een malafide wifi pagina om inlog gegevens te stelen, dit doet mij vooral denken aan een evil portal. Naamgeving is niet zo belangrijk, in essentie komt het erop neer, zoals ik eerder schreef, dat je een login portaal maakt waar mensen met hun gegevens verbinding kunnen maken met het internet. Dit is vrij gebruikelijk in hotels en heb ik ook wel vaker gezien bij leveranciers voor openbaar internet.

Ze hebben het hier niet over dat mensen aan het browsen zijn via deze malafide verbinding, waar ik een aanname doe is dat dit een ESP32 chip of een vergelijkbare variant is gedaan, ze hebben het over dat een access point in beslag is genomen, deze dingen zou je ook kunnen omschrijven als access point. Het punt is vooral dat deze dingen geen internet connectiviteit hebben, ze zenden een wifi signaal uit en je verbind met een netwerk, maar het heeft geen internet connectiviteit. Zonder internet connectiviteit heb je dus ook geen connectiviteit met een VPN en heb je in principe ook niet te maken met HTTP vs HTTPs verkeer tenzij dit binnen dit gesloten netwerk is opgezet.
Dus ik blijf bij mijn stelling, dat voor een malafide login portaal heb je niets aan HTTPs of een VPN simpelweg omdat dit al plaats vind voordat je verbinding kunt maken met het internet.

Dat lijkt me een correcte interpretatie .

Het zal zich gepresenteerd hebben als een Wifi-internet access portal, en de optie gegeven hebben om met een van de federated login opties (google, facebook, microsoft, instagram etc) ervan gebruik te maken.

Er zijn op dit forum een hoop mensen die niet meer dan een titel lezen en dan hun stokpaardje (Linux ! VPN ! ) als wondermiddel aanbevelen.

Erik heeft meer kennis, maar de ongelukkige neiging om _alle_ mogelijke technische risico's, groot, klein, verwaarloosbaar waar hij iets van vindt in z'n postings erbij te halen , ongeacht of die veel, deels, of niks te maken met het onderwerp van het artikel .

Suf van mij, daar heb ik overheen gelezen; mijn excuses.

Ik vermoed echter dat het hierbij niet ging om "log in with Google" o.i.d., want als ik het mechanisme daarvan (federated login) goed begrijp krijgt de betreffende website dan een "token" van Google met het bewijs dat jij jij bent - dat, als het goed is, uitsluitend geldig is voor die betreffende website (de exacte domeinnaam daarvan). De aanvaller kan daar dus niet, als zijnde jou, mee inloggen op een andere website, en heeft daar in de praktijk weinig aan.

Hoewel het mogelijk niet ging om het actief onderscheppen van willekeurige http-verbindingen (de klassieke aanvalstechniek), maar om het -zogenaamd- moeten inloggen op het WiFi access point, gebeurde hoogstwaarschijnlijk wel wat ik beschreef.

Namelijk, de aanvaller toont (niet op jouw verzoek maar op dat van de aanvaller) een website met de vraag aan jou om in te loggen met user-ID en wachtwoord (en evt. 2FA code). Dat zou je zogenaamd op de server van de de door jou gebruikte e-mail provider moeten doen - maar in werkelijkheid is dát dus een nepserver in het midden tussen jouw browser en de echte server.

Vermoedelijk kregen slachtoffers daarbij eerst een keuzemenu met bekende e-mail providers te zien, waar zij uit moesten kiezen, waarna de nepserver waarschijnlijk een lijkt-op-de-echte inlogpagina toonde (vergelijkbaar met nepwebshops die je, voor een iDEAL betaling, een bank laten kiezen en vervolgens een op maat gemaakte neppagina tonen).

Met die gegevens kan software van de aanvaller vervolgens inloggen op het e-mail account van het slachtoffer (bij een kortstondig geldende 2FA code moet dit snel, maar dat is geen probleem voor software). En zodra een aanvaller toegang heeft tot het e-mailaccount van een slachtoffer, kan die aanvaller meestal ook andere online accounts van het slachtoffer kapen.

Dubbel-check, onmiddellijk voordat je ergens inlogt, altijd of de domeinnaam niet afwijkt van de verwachte.

Beter, gebruik een wachtwoordmanager die dat voor jou doet (zie o.a. punt 4 in https://security.nl/posting/840236). Software trapt niet in lijkt-op, zou-kunnen-zijn-van, of ogenschijnlijk correcte "IDN's", International Domain Names.

Man in the Middle of Down Under, who cares. Laptop ligt nu bij de overheid, die hadden je gegevens toch al doorverkocht.... dan geef ik mijn gegevens liever weg aan een of andere Australiër die niet eens kundig genoeg is om onder de radar te blijven

Mij lijkt het best nuttig om inlog-credentials te oogsten.
Als dat lukt, is de resterende bescherming (voor later) alleen de 2e factor die een gebruiker kan (maar niet hoeft te) hebben.

Inderdaad is een 'echte' federated login erg veilig, maar hier zal gewoon een dummy pagina van de bekende opties getoond zijn .

Waarschijnlijk zal de dummy pagina ook 'gewoon' over http getoond zijn - en dan vervallen allerlei checks die bij HTTPS wel mogelijk zijn. De domein naam klopt gewoon.

In de context (onderweg in een vliegtuig - en betrapt) betwijfel ik of de aanvaller de zaak uberhaupt "werkend" gemaakt had.
In wat luxere vliegtuig setups is dan tegenwoordig "Internet" mogelijk , maar het is best duur .

Ik speculeer dat de aanvaller iets presenteerde als "gratis in-flight internet, test onze nieuwe service, log in met google/microsoft/fb/insta" , de credentials oogstte, en dan een error gaf als "sorry network is overloaded" .

Het feit dat ie betrapt is geeft me het idee dat het ook niet 'gewerkt' zou hebben - en dan gaan mensen natuurlijk klagen bij de cabin crew dat "de nieuwe internet service niet werkt" , en wordt duidelijk dat er iets 'fishy' is .

Als het na login 'gewoon' gewerkt zou hebben moet ie de forse pech hebben dat er een behoorlijk alerte technerd ook op de vlucht zit. Of dat hij heel erg opvallen en zichtbaar zit te klooien met allemaal tech spul , plus dat er iets zichtbaar "niet als normaal" werkt.

Maar ik denk dat de voornaamste alert gekomen is vanuit klagende passagiers 'hij doet het niet' , en de cabin crew (na realiseren dat er een "hoort er niet te zijn" netwerk in de lucht was) . actief gekeken/gezocht heeft naar de bron.

Graag gedaan!

Klopt, ik heb het niet goed gelezen, zie mijn reactie hierboven.

Die lijkt mij wat zwakjes voor dit doel. Ik denk eerder aan een PineApple [1], FlipperZero [2] of een notebook met bijv. Kali Linux en een extra draadloze adapter [3] (vaak met opgevoerd zendvermogen). Daarmee kun je ook bestaande verbindingen verbreken door een soort "reset" netwerkpakketjes ("Deauth Attack") naar het echte WiFi access point te sturen, en zo apparaten van slachtoffers verbinding laten maken met de Evil Twin.

Voorheelden (na kort zoeken):
[1] https://medium.com/@crashwire1/tools-of-the-trade-evil-twin-attack-with-hak5-wi-fi-pineapple-part-1-86a15cd8d087

[2] https://www.reddit.com/r/flipperzero/comments/1dstbao/man_charged_over_creation_of_evil_twin_free_wifi/

[3] https://www.geeksforgeeks.org/evil-twin-in-kali-linux/

Dat is denkbaar, maar niet gangbaar. De aanvaller kan zijn apparatuur via het echte WiFi access point met internet laten verbinden [4], of bijv. van 4G/5G gebruik laten maken.

[4] (uit [3]): https://media.geeksforgeeks.org/wp-content/uploads/20221102112221/image16.png

Erik heeft inderdaad de (ongelukkige?) neiging om zoveel mogelijk risico's te benoemen, uit te leggen waarom het risico's zijn én te schrijven wat hij denkt dat je daar het beste tegen kunt doen. Naast dat hij daar zelf van leert (hij wordt héél graag gecorrigeerd en/of aangevuld), hoopt hij anderen daarmee te helpen. Gratis en voor niks.

Als je zo'n hekel aan mij en/of mijn posts hebt, en het overslaan van mijn epistels te ingewikkeld vindt (ik post zelden als Anoniem, koppensnellen volstaat): wellicht is https://tweakers.net (daar ben ik weg), of (on)juist https://x.com, https://linkedin.com of https://facebook.com (op geen van die laatsten heb ik ooit een account gehad) méér geschikt voor jou?

Oh wacht, daar kun je niet anoniem brallen, janken en haatzaaien...

Ik ben wel benieuwd, wat hier strafbaar aan is. En of dit in NL ook strafbaar is en waarom

Goed opgelet, door die medewerkers van de luchtvaartmaatschappij.
En niet zo handig van die Australiër.
Een goedbetaalde baan in de ict-sector lijkt me toch heel wat beter voor je gemoedsrust dan dit soort praktijken.
Maar ja, je bent evil of je bent het niet.

Misschien waren het wel oplettende passagiers die het hebben doorverteld aan personeel.
Hoe dan ook is het niet handig om dit op een vliegtuig te doen inderdaad, ingesloten tube mensenvleespasta met vleugels onder toezicht, dat is vragen om problemen.