Verbaasd. Pc sessie overnemen

[Verwijderd]

Beste Tweakers.

Ik ben aan het spelen geweest met Zanti2 (android app)
Tot mijn grote verbazing kon ik zomaar een sessie overnemen van mijn pc via "cookieforge"

Hieronder een video die laat zien wat er gebeurt.

[YouTube: https://www.youtube.com/watch?v=SWAp_mhlJyY]

Hoe kan het nou zijn dat dit zo makkelijk gaat?
En nog belangrijker, Hoe voorkom ik dat dit mogelijk is?

Ik begrijp dat de tool gebruik maakt van MITM Attack.
Hoe kan ik dan het verkeer beveiligen?

Bedankt voor jullie tijd!

[Janoz]

Voor cookieforge heb je geen MITM nodig. Je snift gewoon het verkeer en als er een http request voorbij komt kun je zo de cookiegegevens achterhalen en overnemen. Hierna heb je de sessie over genomen. Aangezien je vaak achter dezelfde NAT router zit zul je ook hetzelfde IP hebben waardoor die check niet werkt. Ook kun je alle eigenschappen gelijk maken (browsertype en versie) zodat het aan serverkant helemaal niet te achterhalen is dat het request plots vanaf een ander device komt.

Hiertegen beveiligen kan alleen als je altijd https gebruikt of wanneer je de hele keten tussen browser en server kunt vertrouwen.

[Wiebeltje]

Dit werkt alleen met apparaten die op het wifi zitten / op een hub aangesloten zitten of niet? Een PC via kabel aan een router/switch broadcast het verkeer toch niet naar alle apparaten? Dan valt er niks te sniffen lijkt me.

Ik dacht dat je wifi verkeer met een beveiligde verbinding niet makkelijk kon decrypten maar blijkbaar is dat voor o.a. WPA-personal wel te doen voor andere apparaten als je de passphrase maar weet.

[ Voor 4% gewijzigd door Wiebeltje op 08-01-2015 12:08 ]

[Verwijderd]

Als ik het dus goed begrijp kan ik een willekeurig wifi hotspot gebruiken en dan alles van iedereen overnemen?

Janoz schreef op donderdag 08 januari 2015 @ 11:48:
Voor cookieforge heb je geen MITM nodig. Je snift gewoon het verkeer en als er een http request voorbij komt kun je zo de cookiegegevens achterhalen en overnemen.
Hiertegen beveiligen kan alleen als je altijd https gebruikt of wanneer je de hele keten tussen browser en server kunt vertrouwen.

Zoals je ziet in mijn video op 1:19 kan je ook een SSL strip uitvoeren.
Dus https is dan ook niet meer veilig?

[ Voor 0% gewijzigd door Verwijderd op 08-01-2015 12:19 . Reden: Typo ]

[Trebbors]

Welke optie gebruik je bij select script?

[Verwijderd]

Trebbors schreef op donderdag 08 januari 2015 @ 12:20:
Welke optie gebruik je bij select script?

DNS service discovery

[Janoz]

Verwijderd schreef op donderdag 08 januari 2015 @ 12:18:
Als ik het dus goed begrijp kan ik een willekeurig wifi hotspot gebruiken en dan alles van iedereen overnemen?

Klopt! Tenzij je een vpn gebruikt of altijd via https gaat.

Zoals je ziet in mijn video op 1:19 kan je ook een SSL strip uitvoeren.
Dus https is dan ook niet meer veilig?

https is zeker wel veilig genoeg, mits je het gebruikt. SSL Strip zorgt er voor dat je alsnog http gebruikt ipv https. Je kunt dat ook in de browser zien (geen slotje). Het is echter wel een stuk lastiger te detecteren.

De beste optie blijft om alleen maar vertrouwde mensen op je netwerk te laten, en geen gebruik te maken van hotspots. En mocht je alsnog gebruik willen maken van hotspots, gebruik dan een VPN. Deze zorgt er voor dat je een compleet vertrouwde tunnel op kunt zetten naar een vertrouwde server (bijvoorbeeld thuis) en vanaf daar het internet op kunt. Je bent dan net zo veilig alsof je achter die specifieke server aan het internetten bent.

[CAPSLOCK2000]

Verwijderd schreef op donderdag 08 januari 2015 @ 11:37:
Hoe kan het nou zijn dat dit zo makkelijk gaat?

Hoi. Welkom op internet!

Dit kan omdat bijna niemand echt om veiligheid geeft. Als puntje bij paaltje winnen gemakkelijk en goedkoop het steeds weer van veilig.

Als je geen HTTPS gebruikt is alles eenvoudig af te luisteren en over te nemen. Als je het niet goed gebruikt is moeilijker, maar nog steeds mogelijk. Leer hoe je met HTTPS om moet gaan en gebruik het overal waar nodig. Doe nooit iets belangrijks op een website als er geen (goede) HTTPS wordt gebruikt.

Mijn mening is dat alle webverkeer HTTPS zou moeten zijn. De gemiddelde webmaster is niet in staat om te bepalen of het nodig is of niet.

[Umbrah]

Zelfs HTTPS blijft een lapmiddel, zei het een erg goede lap. Zodra je bij de eerste handshake het asynchrone keypair weet te bemachtigen (een eerste handshake gebeurt niet erg vaak gelukkig, en kan lang valide blijven), heb je in feite hetzelfde idee als een oauth/kerberos sessie overnemen. Het zou háást zo kunnen werken (erg simpel uitgelegd, het is ZDnet immers...):

http://www.zdnet.com/arti...-intercept-and-break-ssl/

Totdat je zeker weet dat het resultaat veranderd door alleen te kijken (kwantum-encryptie iemand?) is 100% niet mogelijk. Sneakernet-certificaatuitwisseling is overigens wél een optie.

[Orion84]

Wat een nonsense artikel bij zdnet. Eerst claimen dat je geen fake certificate of rogue CA nodig hebt en dan op de proppen komen met oplossingen in de vorm van commerciële proxy appliances die juist exact dat doen: een fake certificaat gebruiken voor een MitM aanval. Enige verschil is dat dat soort oplossingen doorgaans geïmplementeerd wordt in een bedrijfsomgeving waarin dat certificaat bewust geïnstalleerd wordt op alle clients.

Als attacker heb je niks aan zo'n appliance zonder het certificaat van de appliance op een of andere manier te laten vertrouwen door je slachtoffers. Dat is dus exact dezelfde aanval als met andere vormen van fake certificates, al dan niet ondertekend door een rogue CA.

Je kan ClientKeyExchange anders namelijk helemaal niet bemachtigen, want die wordt versleuteld verstuurd (met behulp van het server certificaat).

[CyBeR]

Umbrah schreef op maandag 12 januari 2015 @ 15:26:
Zodra je bij de eerste handshake het asynchrone keypair weet te bemachtigen

Hoe wilde je dat doen, precies?

[Orion84]

Sowieso, wat is een asynchroon keypair?

De client stuurt een pre-master secret op (versleuteld met public key van de server). Server ontsleuteld dat met zijn (geheime!) private key. Server en Client berekenen ieder voor zich uit de pre-master de Master Key die vervolgens gebruikt wordt om session keys te genereren.

Enige aanval die daarop (voor zover mij bekend) mogelijk is, is als je de private key van de server weet. Praktisch gezien is dat dus alleen door de client een fake certificaat voor te schotelen met niet de public key van de server, maar de public key van een keypair waar jij als aanvaller zelf de private key van hebt.

[ Voor 7% gewijzigd door Orion84 op 12-01-2015 16:31 ]

[CyBeR]

Ik nam aan dat 'ie de asymmetrische keypair bedoelde. Net zoals bij bandbreedte symmetrisch en synchroon steeds verward wordt.

[CAPSLOCK2000]

Umbrah schreef op maandag 12 januari 2015 @ 15:26:
Zelfs HTTPS blijft een lapmiddel, zei het een erg goede lap. Zodra je bij de eerste handshake het asynchrone keypair weet te bemachtigen

Gelukkig kunnen we dat proces nog verbeteren. Zo heb je DANE waarbij je de fingerprints van je certificaten publiceert in DNS. Een client die DNSSEC ondersteunt kan dan controleren of hij het juiste certificaat heeft gekregen. Eigenlijk verschuift dat het probleem van de "eerste handshake" naar de sleutel die je nodig hebt voor DNSSEC, maar die kun je deel van het OS maken, net zoals we dat nu met de SSL CA's doen.

Een andere aanpak is Moxy Marlinspikes Convergence. Dat controleert bij vertrouwde servers of je wel het juiste SSL-certificaat hebt gekregen. Zo'n vertrouwde server controleert dan zelf welk certificaat er bij een bepaald adres hoort. Als dat afwijkt van het certificaat dat jij hebt gekregen (als je er uberhaupt al eentje hebt ontvangen) dan weet je dat er iets niet in de haak is.