Kritisch zijn op gebruik (openbare) WiFi netwerken

[Hoicks]

Wij zijn op kantoor bezig met een awareness programma op gebruikers te wijzen op risico's bij het gebruik van openbare en ter beschikking gestelde draadloze netwerken van derden.

Bij het lezen van een factsheet van het nationaal cyber security center kom ik onderstaand stukje tekst tegen: (https://www.ncsc.nl/binar...08%2B01%2Bwifi%2Bv2.0.pdf)

Hoe kan ik veilig surfen op een publieke wifi-hotspot?
Bepaal als eerste wat u wilt doen en wat de gevolgen voor u zijn als u
daarbij wordt afgeluisterd. Bij het lezen van het weerbericht kan er
weinig misgaan, maar als u bijvoorbeeld inlogt op een sociaal
netwerk dan kan een aanvaller uw wachtwoord misschien aflezen
en zich vervolgens als u voordoen.

Op de achtergrond van mobiele apparaten (welke het meeste gebruikt zullen worden) draaien over het algemeen apps die op de achtergrond synchroniseren. o.a. Mail (ActiveSync of imap/pop), Facebook, Twitter etc. die vaak met authenticatie werken. Ik neem aan dat deze apps regelmatig moeten authenticeren waarbij de data over het netwerk wordt verzonden. (Ik weet alleen niet hoe dat werkt met Ping, dus dat de server de synchronisatie initieert).

Kortom, de stelling dat het veilig is om het weerbericht te lezen is eigenlijk onjuist. Ook op laptops, daar laptops op de achtergrond tegenwoordig ook authenticeren met bijvoorbeeld Windows account, en de apps die daar op draaien, evenals Apple ID's etc.

Nu weet ik wel dat waarschijnlijk alle apps (maar ook dat is niet met zekerheid te zeggen) via https synchroniseren , maar ook dat is af te vangen door de beheerder van het netwerk waarop men zit. (https openbreken, opvangen en weer versleuteld doorsturen).

Eigenlijk komt het er op neer dat de enige wijze waarom men enigszins veilig kan werken als er ook maar enige gerede kans is op achtergrond synchronisatie , gebruik maken van VPN of werken over 4G (dan is alleen de ISP nog die data af kan vangen).

Klopt mijn redenering een beetje?

[ Voor 3% gewijzigd door Hoicks op 22-06-2017 12:51 ]

[lier]

Je redenering klopt (volgens mij).

Overigens weet ik niet wat je bedoelt met "https openbreken", gevaar zit bij man-in-the-middle attack.

[RGAT]

Simpel gezegd is een open wifi netwerk niet veilig, de naam klopt dan ook
Het is een open netwerk, alles en iedereen kan erin, de default setting op iig oudere Androids om met elk open netwerk te verbinden om te kijken of er internet is is dan ook bijzonder handig om je kansen om gehackt te worden te vergroten.
Maar dit geldt ook voor 'beveiligde netwerken', de NAS bij de buren kan ook een cryptolocker hebben welke jouw telefoon/laptop infecteert als je er een keer gebruik van mag maken, WPA2/WEP/open maakt dan niet uit, zelfde voor bedrade netwerken, dit soort zaken moet je met een firewall afvangen waar mogelijk en op onbekende netwerken niet verbinden of met een VPN naar een netwerk wat wel veilig is.

[Hoicks]

lier schreef op donderdag 22 juni 2017 @ 12:59:
Je redenering klopt (volgens mij).

Overigens weet ik niet wat je bedoelt met "https openbreken", gevaar zit bij man-in-the-middle attack.

Er zijn apparaten waar je het netwerkverkeer kunt openbreken en vervolgens weer versleuteld kunt aanbieden. Wordt o.a. ook gebruikt om Deep Packet Inspection toe te passen op https verkeer. (meestal binnen bedrijven, maar als het bedrijfsmatig kan, kunnen hackers 't ook) Dus Man in the middle ja.

[Mijzelf]

Hoicks schreef op donderdag 22 juni 2017 @ 12:50:
Nu weet ik wel dat waarschijnlijk alle apps (maar ook dat is niet met zekerheid te zeggen) via https synchroniseren , maar ook dat is af te vangen door de beheerder van het netwerk waarop men zit. (https openbreken, opvangen en weer versleuteld doorsturen).

Klopt mijn redenering een beetje?

Nee. Je kunt https niet 'openbreken'. Voor iedere verbinding wordt een andere sleutel gebruikt, en de client kiest de sleutel, versleutelt die met het publieke deel van het SSL certificaat van de server, waardoor alleen de server (die het private deel heeft) hem kan ontsleutelen. Meelezen heeft dus geen zin.

Jezelf voordoen als 'de server' om een man in the middle attack te doen kan ook niet, omdat je niet het juiste servercertificaat kan geven.

Er zijn apparaten waar je het netwerkverkeer kunt openbreken en vervolgens weer versleuteld kunt aanbieden. Wordt o.a. ook gebruikt om Deep Packet Inspection toe te passen op https verkeer. (meestal binnen bedrijven, maar als het bedrijfsmatig kan, kunnen hackers 't ook) Dus Man in the middle ja.

Dat lukt alleen als je een root certificaat op de client kunt installeren. Daarmee kun je wèl een juist (lijkend) servercertificaat afgeven, die getekend is met dat root certificaat.
Lukt alleen binnen een bedrijf, waar de clients worden voorbewerkt. Niet bij een open wifi 'in het wild'.

[RGAT]

Dat zal vooral op proxies en een rootcertificaat hangen en niet zomaar op systemen kunnen.
(Tenzij je iets als Superfish op je Lenovo laptop hebt )
Zolang het certificaat klopt en de CA niet gehackt is zou het veilig moeten zijn, mocht de CA gehackt worden ben je thuis ook niet veilig op je netwerk meer...
Over het algemeen is HTTPS als veilig te beschouwen, maar zou gewoon als vuistregel aanhouden dat alles wat HTTPS nodig heeft niet over een open netwerk moet.

[Hoicks]

Mijzelf schreef op donderdag 22 juni 2017 @ 13:21:
[...]
Nee. Je kunt https niet 'openbreken'.

[...]
Dat lukt alleen als je een root certificaat op de client kunt installeren. Daarmee kun je wèl een juist (lijkend) servercertificaat afgeven, die getekend is met dat root certificaat.
Lukt alleen binnen een bedrijf, waar de clients worden voorbewerkt. Niet bij een open wifi 'in het wild'.

Ok, dat is positief. Maar je kunt niet zien welke app op welk https niveau babbelt.

Dus de bottomline is dan nog steeds gebruik maken van VPN.

Er zijn zoveel bedrijven, die wel e-mail op de mobiel ontsluiten, maar niet de moeite nemen om een VPN server in te richten voor haar medewerkers, dat zou dan toch een logische stap zijn qua internetbeveiliging? Waarom is dat?

[RGAT]

Kosten. Leg aan de manager maar uit dat je een nieuwe server nodig hebt (tenzij je een hypervisor hebt...) en even zoveel extra licenties moet kopen zodat mensen thuis kunnen mailen, dan nog meer uren betaalt moet krijgen om het allemaal in te stellen en te beheren.

[Manu_]

Ik snap echt niet zo goed waarom men het altijd heeft over "onveilige" open WiFi netwerken en andere netwerken als veilig beschouwen. Dingen die niet veilig zijn op een open WiFi netwerk moet je ook niet doen op een ander netwerk. Dit is toevallig laatst ook opgeschreven door iemand anders: https://blog.xot.nl/2017/06/16/alle-netwerken-zijn-onveilig/.

[Hoicks]

Dit is ook interessant:

However, when accessed via HTTPS, many sites will only carry out the authentication step over HTTPS, and then drop back to HTTP for the rest of the session. So, your password itself is safe, but the session ID used by the server to identify you for that session is transmitted in the clear by your browser. This reduces the load on the webserver (because encryption/decryption is CPU-intensive) but makes the site much less secure. Gmail is safe because it uses HTTPS for the whole session, but Facebook and many other sites do not.

Interessante materie dit.

[batumulia]

Als het echt zo'n probleem is om op publieke WiFi te zitten, waarom wordt er geen gebruik van VPN gemaakt dan? Ik heb zelf een VPN server thuis staan waar ik op inlog als ik van een publiek WiFi punt gebruik moet maken.

[Hoicks]

batumulia schreef op donderdag 22 juni 2017 @ 14:04:
Als het echt zo'n probleem is om op publieke WiFi te zitten, waarom wordt er geen gebruik van VPN gemaakt dan? Ik heb zelf een VPN server thuis staan waar ik op inlog als ik van een publiek WiFi punt gebruik moet maken.

Veel gebruikers realiseren zich nog niet wat de risico's zijn op het moment dat zij gebruik maken van dit soort WiFi punten.

[Mijzelf]

Hoicks schreef op donderdag 22 juni 2017 @ 13:35:
Er zijn zoveel bedrijven, die wel e-mail op de mobiel ontsluiten, maar niet de moeite nemen om een VPN server in te richten voor haar medewerkers, dat zou dan toch een logische stap zijn qua internetbeveiliging? Waarom is dat?

Wat probeer je te beschermen? Als alle bedrijfsgerelateerde zaken (e-mail, ...) al via ssl lopen, waarom zou je dan nog een VPN willen? Het enige wat dat dan nog beschermt zijn mogelijke privé accounts van werknemers.
Dus de (bedrijfs-)baten zijn gering.
Terwijl de kosten hoog kunnen zijn. Buiten de infra moet je de medewerkers opleiden. Deze moeten altijd een 2-traps handeling uitvoeren om te kunnen 'internetten'. Sommige openbare wifi netwerken blokken VPN's, dus dan krijg je weer 'die VPN doet het ook nooit'. Het wordt allemaal trager, door de langere routes.

[SmokingSig]

Mijzelf schreef op donderdag 22 juni 2017 @ 13:21:
[...]
Nee. Je kunt https niet 'openbreken'. Voor iedere verbinding wordt een andere sleutel gebruikt, en de client kiest de sleutel, versleutelt die met het publieke deel van het SSL certificaat van de server, waardoor alleen de server (die het private deel heeft) hem kan ontsleutelen. Meelezen heeft dus geen zin.

Dit kan wel hoor. Google maar even.

[Manu_]

SmokingSig schreef op donderdag 22 juni 2017 @ 15:22:
[...]


Dit kan wel hoor. Google maar even.

Je claimt dat https gewoon gebroken kan worden en als argument breng je "google maar even" aan. Goed verhaal.

[SmokingSig]

Manu_ schreef op donderdag 22 juni 2017 @ 16:01:
[...]


Je claimt dat https gewoon gebroken kan worden en als argument breng je "google maar even" aan. Goed verhaal.

Breken niet wel man in the middle doen. Vroeger nog getest voor LAN. Was een eindwerk Maar goed dat is wel al enkele jaren geleden.

[Manu_]

SmokingSig schreef op donderdag 22 juni 2017 @ 16:03:
[...]


Breken niet wel man in the middle doen. Vroeger nog getest voor LAN. Was een eindwerk Maar goed dat is wel al enkele jaren geleden.

Het hele punt van https is MITM voorkomen, dus als een aanvaller wel MITM kan doen (en dus de communicatie tussen user en server kan lezen) zou ik dat wel https breken noemen.

Wat @Mijzelf al beschreef is dat je als je eencertificaat op de user's device hebt staan je dit natuurlijk wel kunt doen, maar dat is natuurlijk niet een realistisch scenario voor een aanvaller. In de andere gevallen kun je echt niet zomaar (zonder een CA te zijn) de berichten van (een correcte implementatie van) een https verbinding lezen.

[Question Mark]

SmokingSig schreef op donderdag 22 juni 2017 @ 16:03:
[...]


Breken niet wel man in the middle doen. Vroeger nog getest voor LAN. Was een eindwerk Maar goed dat is wel al enkele jaren geleden.

Leuk en aardig (MITM attack is peanuts), maar het enige wat je voorbij ziet komen is versleuteld verkeer. Daar heb je niet zo heel veel aan...

Hoicks schreef op donderdag 22 juni 2017 @ 14:02:
Dit is ook interessant:
[...]


Interessante materie dit.

Wat een onzintekst... Facebook is wel degelijk volledig encrypt... D'r zijn weinig sites die zo bewust met security omgaan als Facebook.

Voor de rest zit de crux hem in dit stukje:

Hoicks schreef op donderdag 22 juni 2017 @ 12:50:
Mail (ActiveSync of imap/pop),

Je noemt hier al drie protocollen, waarbij één altijd via een secure sessie loopt (ActiveSync), en bij de andere twee ligt de keuze bij de beheerder. Zowel POP als IMAP kán secure aangeboden worden. Het ligt maar net aan de instellingen. Zomaar stellen dat een protocol veilig of onveilig is, is te kort door de bocht.

[ Voor 26% gewijzigd door Question Mark op 22-06-2017 16:33 ]

[The Lord]

Het hangt er van af of MITM mogelijk is. Zelfs als gebruik wordt gemaakt van HTTPS zijn er legio potentiële kwetsbaarheden.

Afhankelijk van de implementatie van de aanbieder van de dienst (/applicatie / site /...) is het simpel tot nagenoeg onmogelijk om HTTPS MITM uit te voeren.

Wil je dit uitsluiten dan moet je zelf aanvullende maatregelen invoeren.

[Hoicks]

Inmiddels zijn we er wel achter dat een VPN eigenlijk onontbeerlijk is, of men moet direct de dataverbinding van de telefoonaanbieder gebruiken.

Nog een vraag die in mij opkwam:

In de tijd dat men verbind met een WiFi netwerk om een VPN verbinding op te kunnen bouwen, is er op de achtergrond tijd zat om allerhande synchronisaties te starten. Het lijkt mij dus dat wanneer je apps hebt draaien op de achtergrond waarvan niet zeker is of ze HTTPS babbelen, het best eens zo zou kunnen zijn dat vóór de VPN actief is, er al authenticatiegegevens over de lijn zouden kunnen zijn gegaan.

Voorbeeld;

Ik ben in het buitenland en ik heb roaming uitstaan en ik ben in een of andere schimmige bar met "Free WiFi". Ik verbind met het WiFi netwerk en moet vervolgens op mijn iPhone de VPN verbinding nog handmatig starten.

Juist het feit dat mijn achtergrond apps een tijdje out of sync zijn (dankzij mijn reisschema) en ik ineens weer verbinding heb met het internet, zal op de achtergrond direct een sync actie plaatsvinden en zijn er misschien al onversleuteld gegevens over de lijn gegaan voordat de VPN de verbinding gaat versleutelen.

Kun je met MDM dan bijvoorbeeld afdwingen dat er alleen maar verbinding kan worden gezocht naar een VPN server zodat de VPN eerst actief wordt vóór de telefoon ook maar iets op de actieve WiFi kan synchroniseren?

[Question Mark]

Hoicks schreef op maandag 26 juni 2017 @ 15:51:
Kun je met MDM dan bijvoorbeeld afdwingen dat er alleen maar verbinding kan worden gezocht naar een VPN server zodat de VPN eerst actief wordt vóór de telefoon ook maar iets op de actieve WiFi kan synchroniseren?

Als je toch MDM hebt en volledige controle hebt over de mobile devices, dan sta je toch alleen maar goedgekeurde applicaties toe? En dat zijn dan bv. alleen maar applicaties die alle data encrypted versturen, op basis van een server én client certificaat.

Je kunt de verbindingen wel volledig gaan controleren, maar als de gebruiker alsnog een malifide app/keylogger/trojan installeert die alsnog alle lokale data doorstuurt schiet je daar niet heel veel mee op.

[Hoicks]

Question Mark schreef op maandag 26 juni 2017 @ 15:56:
[...]

Als je toch MDM hebt en volledige controle hebt over de mobile devices, dan sta je toch alleen maar goedgekeurde applicaties toe? En dat zijn dan bv. alleen maar applicaties die alle data encrypted versturen, op basis van een server én client certificaat.

Je kunt de verbindingen wel volledig gaan controleren, maar als de gebruiker daarnaast een malifide app installeert die alsnog alle lokale data doorstuurt schiet je daar niet heel veel mee op.

MDM is nu nog niet ingericht. Ik snap je (goede) punt, maar ben ook benieuwd naar het antwoord wat betreft de tijd tussen verbinding met een WIFi punt en het maken van een VPN verbinding.

[Standeman]

Hoicks schreef op donderdag 22 juni 2017 @ 13:35:
[...]


Ok, dat is positief. Maar je kunt niet zien welke app op welk https niveau babbelt.
....

Inmiddels (of binnenkort) is het bij Apple apps verplicht om met HTTPS te communiceren, anders kom je de store niet meer in met je app. Dus wat dat betreft dekt apple het redelijk goed af.

[Question Mark]

Hoicks schreef op maandag 26 juni 2017 @ 15:57:
[...]


MDM is nu nog niet ingericht. Ik snap je (goede) punt, maar ben ook benieuwd naar het antwoord wat betreft de tijd tussen verbinding met een WIFi punt en het maken van een VPN verbinding.

Ja...

Vijf minuten zoekwerk in google leverde mij al op dat dit een native feature in IOS is, en afhankelijk van de MDM oplossing is het ook mogelijk in Android. "Per-App" VPN is wat je zoekt...

Dit soort vragen zijn redelijk eenvoudig zelf uit te zoeken...

[ Voor 6% gewijzigd door Question Mark op 26-06-2017 16:09 ]

[Hoicks]

Ah. Ik zocht meer naar een generieke vulnerability voor de VPN actief zou worden. Kreeg niet direct terug dat het per app te regelen is. Thanks!

[laurens0619]

Voor apple (android ook geloof ik) heb je een zogenaamde always on profiel

“Always-on VPN” is designed for businesses and other organizations, so it must be enabled with a configuration profile or a mobile device management server. After enabling it, the VPN will always be activated. If the VPN connection fails, apps on your device won’t be allowed to connect to the Internet until it comes back up.

Is alleen (op iOS) niet zomaar aan te zetten, moet je met device profielen aan de slag.

Maar je hebt altijd zoiets als Risk (Likelihood x Impact). De risk dat je een applicatie hebt die unencrypted verkeer verstuurd + dat je met een open netwerk verbonden bent + dat er een aanvaller op je netwerk een mitm aan het doen is + dat die interesse heeft in de info is gewoon vrij laag. Dat is de reden waarom bedrijven hier niet heel "overspannen" over doen.

De risk gaat sowieso omlaag omdat steeds meer applicaties full https doen. Facebook deed in het verleden alleen https bij het inloggen waardoor je makkelijk op een open wifi de sessie kon stelen. (heb het wel eens op mijn eigen open wifi getest). Facebook is nu ook full https dus daar kun je niet zoveel meer.

Waar nog wel een risico in zit is dat mensen vaak naar de http site surfen die hierna een redirect naar https geeft. Deze redirect is af te vangen en kun je dus een mitm uitvoeren:



Maar dan nog, er zijn voor aanvallers relatief gemakkelijkere manieren om aan je login gegevens/data te komen. Het is als aanvaller vaak eenvoudiger om via malware/phishing/social engineering binnen te komen dan je te achtervolgen, hetzelfde wifi netwerk in te loggen en een mitm uit te voeren

[Frogmen]

En draai het allemaal nu eens om ga eens een dagje sniffen met free AP in een kroeg en probeer in die berg data nou eens orde te krijgen en informatie te vinden. Zijn daar al tools voor? Want wat ik merk als ik alleen naar de logs kijk van zo'n open AP is het knap lastig en moet je doelgericht aan de slag gaan wil je er iets in kunnen vinden.
Iets kunnen en bruikbaar toe kunnen passen zijn nog wel eens erg verschillend.

PS er zijn ook mensen die ieder slot open krijgen.

[ Voor 16% gewijzigd door Frogmen op 26-06-2017 19:33 ]

[laurens0619]

De tools zijn er wel hoor, Kali (of los rlsnarf, dsniff and driftnet) of een pineapple geeft je al op een hele makkelijke manier de data Sterker nog, met 1 druk op de knop heb je een auto rickroll
https://www.hak5.org/hack/auto-rickrolling-wifi-pineapple

Maar als ik naar de breaches kijk van de afgelopen jaren dan ken ik geen breaches waarbij een hack via open wifi de aanvalsmethode was...

[Question Mark]

laurens0619 schreef op maandag 26 juni 2017 @ 19:19:
Waar nog wel een risico in zit is dat mensen vaak naar de http site surfen die hierna een redirect naar https geeft. Deze redirect is af te vangen en kun je dus een mitm uitvoeren:

Beetje website heeft tegenwoordig allang HSTS geimplementeerd. Daarmee wordt de client agent door de server verteld dat communicatie via https moet lopen. Het afvangen van redirects of het gebruik van een tool als "sslstrip" werkt dan simpelweg niet. Tenminste, als er geen antieke browser gebruikt wordt.

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

[laurens0619]

Ik dacht, ik vermeld hsts even niet om het niet nog complexer te maken maar je hebt gelijk

Alhoewel die adoptie ik nog wel mijn vraagtekens bij heb. Vorig jaar was de adoptie nog maar 5% (https://news.netcraft.com...trivial-mitm-attacks.html) maar tegelijk kun je ook stellen dat 90% van het verkeer richting google/youtube/facebook/instagram gaat die deze zaken wel op orde hebben.

[keesvb78]

Bij voorkeur zou ik gebruik maken van onbeperkt 4g internet en op die manier je telefoon verbinden aan je computer. Maar [url="http://.nl/"]VPN is wel een goedkoper optie![/url]

[ Voor 3% gewijzigd door F_J_K op 10-04-2019 10:23 ]

[johnkeates]

keesvb78 schreef op woensdag 10 april 2019 @ 10:10:
Bij voorkeur zou ik gebruik maken van onbeperkt 4g internet en op die manier je telefoon verbinden aan je computer. Maar [url="http://.nl/"]VPN is wel een goedkoper optie![/url]

Ik weet niet of dat in 2017 al een optie was.

[ Voor 1% gewijzigd door F_J_K op 10-04-2019 10:23 ]

[rens-br]

keesvb78 schreef op woensdag 10 april 2019 @ 10:10:
Spam

Hoe goed bedoeld ook. Reageren op oude topics heeft niet zoveel zin, kicken is dan ook niet gewenst.

[ Voor 29% gewijzigd door rens-br op 10-04-2019 10:27 ]