Netwerkactiviteit inlezen

[tommekentom]

Ik zag net dit bericht op de website van volt: http://www.een.be/programmas/volt/grati ... gevaarlijk

Zijn er mensen onder jullie die weten welk programma je precies nodig hebt hiervoor of hoe je dit voor elkaar kan krijgen om de gegevens in te lezen op je netwerk? Voor alle duidelijkheid willen we dit enkel thuis intern gebruiken, zeker niet voor openbare wifi ofzo.

[krisken]

Bvb een pineapple : http://hakshop.myshopify.com/products/w ... t=81044992

[Kenw00t]

Inderdaad, de WiFi Pineapple is een kant-en-klaar oplossing. Sinds kort wordt deze ook verkocht door een Europese verdeler (geen last meer met eventuele douanekosten dus).

Het programma dat ze daar ook nog gebruiken is Burp Suite. Speel daar zelf eerst eens mee op je eigen PC om goed te begrijpen wat het juist doet. Ik vermoed dat er op het net wel genoeg tutorials te vinden zijn voor dit programma.

[heist_175]

Hoe kan je u daar tegen beschermen? VPN?
Want wifi is wel heel gemakkelijk natuurlijk

[tommekentom]

Maarja welke vpn is dan het beste? Er zijn er tegenwoordig wel heel veel

[Dima_2005]

Ik heb nu Ipvanish omdat die gratis bij mijn usenet abo zit. Zeer tevreden over... Behalve dat hun app op android niet werkt :-\

[cyberbozzo]

Volt beweert dat ze weten wat je op facebook hebt uitgespookt. Is dat tegenwoordig dan geen HTTPS verkeer?
Misschien kan je via de URL's nog wel iets achterhalen qua wat je aan het doen bent, maar anders is het point to point versleuteld (heartbeat daargelaten).

[ubremoved_539]

Volt beweert

TV programma's zorgen nogal graag voor sensatie.

Misschien kan je via de URL's nog wel iets achterhalen

De URL's vallen evenzeer onder https hoor ! Zonder een MITM attack is meelezen niet mogelijk.

[8balljunkie]

Als je effectief in je balk ziet staan HTTPS dan is er geen probleem.
Maar er is een leuk fenomeen genaamd ssl stripping, FB werkt namelijk ook gewoon over http.
Je zet een interne dns op dat alle verkeer wijzigt van https naar http...BOEM!

Dus moet je zelf goed opletten dat er https staat, maar heel weinig mensen doen dit. Er bestaan ook addons die hier kunnen helpen.

[ubremoved_539]

Je zet een interne dns op dat alle verkeer wijzigt van https naar http...BOEM!

Een DNS die verkeer kan wijzigen... je zal een transparent proxy bedoelen denk ik.

Maar als ik https:// intyp in m'n browser (en die dus een SSL handshake gaat doen) dan kan je niet zomaar unencrypted data teruggeven hoor.

[8balljunkie]

Het is gewoon een simpele man in the middle aanval, jij typt https en ik redirect u naar http.
Jij weet dat je https intypt en als je erop let dan is de aanval makkelijk te ontdekken, maar in de meeste gevallen let je er niet op.
Maar dan moet er een redirect via een proxy zijn en niet via dns gebeuren, mijn fout.

[ubremoved_539]

jij typt https en ik redirect u naar http.

Nonsens... als ik https intyp dan start m'n browser een SSL handshake... en die kan jij nooit correct beantwoorden (want dan zou je het certificaat van bv. Facebook moeten hebben !), laat staan dat je een redirect zou kunnen terugsturen !

[8balljunkie]

http://null-byte.wonderhowto.com/how-to ... p-0130360/

Vanaf het moment dat jij enter duwt is er helemaal nog geen handshake gebeurd. Uw pakket komt eerst bij de aanvaller terecht stript ssl ervan.

The client then forwards requests to the attacker, and the attacker takes the requests and retrieves them from the server for the client. After they recieve it, the SSL layer gets stripped and the page is sent to the target. The victim then forwards their packets to the attacker unknowingly, while their private information is picked out of it. SSL Strip puts the SSL layer back on, fills it out, and sends it to the server. Everything looks fine to the server and client, except the attacker gets the information they desire.

[ITnetadmin]

Dat zou je browser toch moeten merken, aangezien hij die handshake checkt?
En met een MITM aanval ben je niet veel als de data geencrypteerd is met de public key van de server.

Mij lijkt die beschreven aanval te gaan over de MITM die de SSL link met de server opzet, en dan met jou verbindt met een gewone http link (door jouw arp table te vervuilen met hun gegevens). Dus de transmissie van jou tot de MITM is http, van de MITM tot de server is https.
Dat zou dus moeten opvallen als je geen https link ziet.
Wat het wel kan aanvallen is servers die automatisch https opzetten met nontech users, die daarna niet zien dat hun link geen https maar gewoon http is.

[ Post made via mobile device ]

[ubremoved_539]

Uw pakket komt eerst bij de aanvaller terecht stript ssl ervan.

En hoe denk je dat hij die SSL eraf gaat strippen... zonder de handshake te voltooien ?

Dat zou je browser toch moeten merken, aangezien hij die handshake checkt?

Een browser moet dat zeker merken... die MITM moet jou SSL handshake volbrengen en dat kan hij enkel met een fake certificaat (waarop je browser gaat zeuren dat het voor een andere website is). Dat sommige andere programma's zoals mail clients en dergelijke dit misschien niet rapporteren is een andere issue, maar iedere browser die ik ken doet het zeker.

[Kenw00t]

Volt beweert dat ze weten wat je op facebook hebt uitgespookt. Is dat tegenwoordig dan geen HTTPS verkeer?

Aangezien ze zelf een malafide gratis WiFi hadden opgezet zullen enkel het verkeer kunnen sniffen hebben van gebruikers die met een browser naar Facebook surften die geen HTTP Strict Transport Security ondersteunt (zoals alle versies van Internet Explorer, behalve die op Windows 10).

Het probleem ligt er hem in dat browsers van oudsher eerst naar de gewone HTTP van een website proberen gaan, voordat diezelfde website tegen de browser zegt dat er via HTTPS gecommuniceerd moet worden. Doordat zij een MITM uitvoerden konden zij de eindgebruiker de hele tijd voor de zot blijven houden dat alles HTTP moest blijven, terwijl zij het echte verkeer naar Facebook toe wel netjes afhandelden via HTTPS.

Enkel IT'ers zoals wij letten er namelijk op of er "https" in de adresbalk van de browser wordt getypt (of vanzelf verschijnt), maar de meeste mensen typen enkel de domeinnaam in de adresbalk zonder http of https prefix.

Om dit probleem op te lossen hebben moderne browsers zoals Chrome en Firefox een beperkt lijstje met de meest populaire websites achter de hand die HTTP Strict Transport Security implementeren, zodat aanvallen tegen deze websites meteen gedetecteerd zouden worden door de browsers.

Voor uitleg in detail, zie ook dit antwoord: https://security.stackexchange.com/a/44976

[ubremoved_539]

Het probleem ligt er hem in dat browsers van oudsher eerst naar de gewone HTTP van een website proberen gaan, voordat diezelfde website tegen de browser zegt dat er via HTTPS gecommuniceerd moet worden.

Enkel en alléén als je zelf geen https:// opgeeft. Op zich heeft het dan ook niets met SSL te maken (laat staan het strippen ervan).

[Kenw00t]

Juist, maar dat is het punt net: niemand buiten IT'ers typt die https in de adresbalk!

Je snapt trouwens de SSLstrip aanval niet goed denk ik. Graag dit doornemen vanaf slide 50: https://blackhat.com/presentations/bh-d ... ng-SSL.pdf

Ik verdedig hier trouwens allerminst wat 8balljunkie schrijft: het is inderdaad niet mogelijk om een HTTPS-verbinding die door de gebruiker werd aangevraagd om te zetten naar HTTP.

[ubremoved_539]

Je snapt trouwens de SSLstrip aanval niet goed denk ik.

Toch wel... maar technische gezien heeft het niets met strippen van SSL te maken end-to-end.

Het is dus eerder het "verwarren" van een user dan effectief iets "breken" (daarvoor bestaan zwaktes in protocols).

[ITnetadmin]

Ze onderscheppen de browser request naar de webserver, sturen die in de browser zijn plaats (en bouwen zelf de SSL connectie op), en sturen dan de ontvangen data zonder SSL door naar de browser.
Standaard MITM dus, met een extraatje, maar zeker geen zwakte in het protocol, eerder in de user.

[ Post made via mobile device ]

[8balljunkie]

Zelfs als er een ssl verbinding is dan, kun je die sessies allemaal sluiten en dan een nieuwe login moet forceren.
Leer elke dag iets bij thx @Kenw00t

slide 80
https://blackhat.com/presentations/bh-d ... ng-SSL.pdf

De titel zegt al genoeg "Defeating SSL"

[Kenw00t]

Op zich heeft het dan ook niets met SSL te maken (laat staan het strippen ervan).

Toch wel... maar technische gezien heeft het niets met strippen van SSL te maken end-to-end.

Dat met end-to-end heb ik ook nergens geschreven. Jij geeft duidelijk een eigen interpretatie aan "SSL stripping". Ik gebruik gewoon het vakjargon; bijna alle verwijzingen die je op Google en OWASP kan vinden over "SSL stripping" hebben het over de eerder beschreven MITM-aanval. Indien jij een relevante bron hebt voor jouw definitie dan hoor ik dat graag.

Hier is alvast mijn bron: https://en.wikipedia.org/wiki/Moxie_Mar ... _stripping

Het is dus eerder het "verwarren" van een user dan effectief iets "breken" (daarvoor bestaan zwaktes in protocols).

Daar ben ik het volledig mee eens.

[ubremoved_539]

Als je gaat kijken bij de auteur van sslstrip dan staat het duidelijker beschreven;

It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links

Het gaat dus HTTP (niet secuur) traffiek onderscheppen en in die pagina's links met https vervangen door http links. De naamgeving SSLstrip is dus heel verwarrend omdat het niets met SSL te maken heeft laat staan het strippen ervan ! Het enige wat het doet is de inhoud van onbeveiligde webpagina's aanpassen.

[Kenw00t]

Het is zoals ITnetadmin ook al 2x zei: de beveiligde verbinding wordt opgebouwd tussen de aanvaller en server. Nadat de aanvaller antwoord heeft van de server moet hij hier alle sporen verwijderen die er op kunnen wijzen dat dit van een beveiligde verbinding kwam, waaronder inderdaad de links, de secure bit op de cookies, de favicon, ...

Het slachtoffer krijgt dus een plaintext HTTP voorgeschoteld, zoals bijvoorbeeld een loginpagina van Facebook die via een rechtstreekse verbinding nochtans anders alleen bereikbaar is via HTTPS. Als het slachtoffer inlogt krijgt de aanvaller de credentials uiteraard in plaintext doorgestuurd, waarna die op zijn beurt terug een beveiligde verbinding met Facebook opbouwt om met die credentials in te loggen, van Facebook dan een antwoord krijgt, en dat antwoord dan doorstuurt naar het slachtoffer.

Tijdens dit hele proces moet de aanvaller de hele tijd alle trafiek naar het slachtoffer filteren op links en cookies, maar ook als het slachtoffer een GET of POST doet moet hij dit eerst omzetten alvorens een legitieme request te plaatsen bij Facebook. Aan de kant van Facebook lijkt er dus niets aan de hand omdat er een legitieme verbinding werd opgezet, aan de kant van het slachtoffer is het verschil enkel subtiel op te merken aan de adresbalk van de browser.

Als je het hele proces van bovenaf bekijkt wordt SSL dus gestript naar het slachtoffer toe, en dat is zo speciaal omdat de server de nodige content enkel wil afleveren via SSL en niet via een plaintext HTTP-verbinding. Het gaat dus wel degelijk om pagina's die eerst beveiligd waren, maar door de MITM van de SSL ontdoen worden zonder dat server noch slachtoffer dit merken.

Nogmaals, als je het niet eens bent met de naamgeving moet je je wenden tot de auteur. Die heeft de term uitgevonden, maar als jij daar duidelijk anders over denkt vraag ik je nogmaals om met een relevante bron te komen waar de term "SSL stripping" niet in verband met deze MITM-aanval gebruikt wordt. Je moet dus al met iets afkomen van voor 2009.