[alg] Oplossing voor veiligheidslek plaxo?

[youngster]

Quote van http://www.zdnet.nl/News.cfm?id=34928:

Wood demonstreerde het script ook voor ZDNet. Deze code legde op de Plaxo-site een extra laag over de ruimte waar leden hun gebruikersnaam en wachtwoord invullen. Als een gebruiker dan zijn gegevens invult wordt deze informatie eerst naar de website van de aanvaller gestuurd en dan pas naar Plaxo om de gebruiker in te loggen. Gebruikers hebben in dat geval geen idee dat hun gegevens zijn gestolen.

"Hierbij maken we gebruik van een kwetsbaar veld op de voorpagina van Plaxo om hun formulier voor de gebruikersgegevens te bedekken met een Javascript-element dat uit een laag bestaat, een zogenoemde 'Div". Als je op deze manier een laag over een website legt, hem dezelfde kleuren geeft en dezelfde informatie laat weergeven is hij voor een gebruiker niet van de echte te onderscheiden."

Wood legt uit dat gebruikers verschil niet kunnen zien omdat de extra laag over de echte website van Plaxo wordt gelegd, hoewel de site gebruik maakt van een beveiligde SSL-verbinding. Ook als de gebruiker op het bekende slot in de browser zou klikken wordt de site weergegeven als een oorspronkelijke pagina, ondanks de aanpassing.

Iemand enig idee wat een oplossing is om dit te voorkomen?

[Bosmonster]

Het is een html probleem dus hoort in W&G

Er is vooralsnog niks aan te doen. In feite is niet de div de boosdoener, maar het iframe.

[justmental]

Volgens mij maak je het met een challenge-response oplossing al een heel stuk lastiger.

[Bosmonster]

justmental schreef op 18 maart 2004 @ 09:34:
Volgens mij maak je het met een challenge-response oplossing al een heel stuk lastiger.

Kwam deze toevallig tegen in de search en nee hier valt weinig mee te doen. Je moet het zien als dat mensen letterlijk opvangen wat je intypt door de fake inputs over die van de originele site. Je username/password worden dus letterlijk opgevangen.

http://www.bosmonster.nl/files/test.html

Daar zie je een testje van het principe.

[ Voor 10% gewijzigd door Bosmonster op 25-03-2004 14:48 ]

[justmental]

Bosmonster schreef op 25 maart 2004 @ 14:41:
Kwam deze toevallig tegen in de search en nee hier valt weinig mee te doen. Je moet het zien als dat mensen letterlijk opvangen wat je intypt door de fake inputs over die van de originele site. Je username/password worden dus letterlijk opgevangen.

http://www.bosmonster.nl/files/test.html

Daar zie je een testje van het principe.

username/password kunnen ze idd. gewoon onderscheppen, maar het 'door-inloggen' zodat de gebruiker niks merkt wordt wel lastiger.

[Bosmonster]

justmental schreef op 25 maart 2004 @ 14:50:
[...]

username/password kunnen ze idd. gewoon onderscheppen, maar het 'door-inloggen' zodat de gebruiker niks merkt wordt wel lastiger.

Maar dat boeit toch niet meer Je hebt hun username/password. Redirect daarna naar de homepage van de betreffende site en mensen denken 'huh?!'.. en loggen gewoon nog een keer in.

Niet dat het iets is om trots op te zijn, maar zoiets heb ik ook gemaakt op de hogeschool toen ik daar nog zat Een fake login scherm (DOS). Mensen logden in, ik sloeg het username/password op en reboote de computer. Mensen dachten gewoon dat de computer gecrashed was. Uiteraard allemaal onschuldig en uit naam van 'experimenteren', maar het principe bestaat dus al langer en er is heel weinig tegen te doen

Enige nadeel is de URL, maar met de wazige urls/redirect die je bijvoorbeeld bij passport.net al voorbij ziet komen let niemand op een url als:

http://ip98.passport.x15.nl/login?s=sk38nsak3jnkjsndoifj

etc...

Magoed.. fake-sites zijn zo'n beetje de meest gebruikte manier om onoplettende gebruikers hun gegevens afhandig te maken.. dit is hier geen uitzondering op..

[ Voor 8% gewijzigd door Bosmonster op 25-03-2004 14:58 ]

[man-o-script]

Bosmonster schreef op 25 maart 2004 @ 14:55:
[...]

Niet dat het iets is om trots op te zijn, maar zoiets heb ik ook gemaakt op de hogeschool toen ik daar nog zat Een fake login scherm (DOS). Mensen logden in, ik sloeg het username/password op en reboote de computer. Mensen dachten gewoon dat de computer gecrashed was. Uiteraard allemaal onschuldig en uit naam van 'experimenteren', maar het principe bestaat dus al langer en er is heel weinig tegen te doen

Dat heb ik een keer precies hetzelfde gemaakt op de HHS
NT login scherm helemaal nagemaakt, startbalk en desktopicons hiden, in laten loggen, password automatisch mailen, foutmelding geven en restarten
Zo heb ik zelfs een keer een helpdesk-muts laten inloggen

[youngster]

Ok, het principe is me nu wel een stuk duidelijker geworden (thanks to bosmonster),
maar wat kan je nou doen tegen fake-sites?
Wat is bijv. een challenge-response?

[Infinitive]

Dat heb ik een keer precies hetzelfde gemaakt op de HHS
NT login scherm helemaal nagemaakt, startbalk en desktopicons hiden, in laten loggen, password automatisch mailen, foutmelding geven en restarten
Zo heb ik zelfs een keer een helpdesk-muts laten inloggen

Bij het NT login scherm heb je toch de ctrl+alt+delete beveiliging voor om dat te voorkomen? Of riep je de helpdesk-muts erbij nadat je als het ware zelf al aan het inloggen bent en daardoor ctrl+alt+delete al ingedrukt zou hebben?

Het challenge-response mechanisme was toch d.mv. http-headers en dat je browser dan zelf met met het login-venster komt? Als dat via een middle-man gaat werkt dat ook niet echt.

[Spider.007]

youngster schreef op 26 maart 2004 @ 10:16:
Ok, het principe is me nu wel een stuk duidelijker geworden (thanks to bosmonster),
maar wat kan je nou doen tegen fake-sites?
Wat is bijv. een challenge-response?

Challenge response wordt gebruikt om de communicatie tussen de client en de server te beveiligen. Hier is met de search vrij veel over te vinden. Dat lost echter niets op mbt dit probleem.

Ik kan ook niets bedenken om deze manier van aanvallen tegen te gaan

edit:

Infinitive schreef op 26 maart 2004 @ 10:32:
[...]

Het challenge-response mechanisme was toch d.mv. http-headers en dat je browser dan zelf met met het login-venster komt? Als dat via een middle-man gaat werkt dat ook niet echt.

Nope.. Korte uitleg, server verstuurd een randomwaarde die een beperkte tijd geldig is; de browser plakt achter de unieke randomwaarde het wachtwoord en maakt hier een hash van. Deze hash wordt vervolgens verstuurd. Bij elke inlogpoging is de randomwaarde uniek, en de verstuurde hash dus ook

[ Voor 36% gewijzigd door Spider.007 op 26-03-2004 10:58 ]

[Verwijderd]

Je kunt het in principe wel tegenhouden. Je kunt niet zomaar een extra element pushen richting de client, er moet een schil omheen zitten of je moet uitkomen op een andere website zoals het geval was met de paypal affaire.

Wat ik vreemd vind is hoe het wordt toegepast. Het is een ongeschreven regel dat er tussen 2 verschillende domeinen geen source en cookie wijzigingen kunnen plaatsvinden. Al zou je een iframe gebruik om de website te laden, en vanuit de parent van dat iframe een div positioneren op de juiste plek, dan kun je nog steeds dmv referers, ssl, sessions, etc. diverse checks uitvoeren.

Zodra er echter vanuit de iframe een div wordt gepositioneerd, betekend dit dat je via een valse url toegang krijgt. Dat risico loop je zowiezo altijd met beveiligingen. Dat is ook niet echt gerelateerd aan de website, behalve dat je dus het kan voorkomen door login functionaliteiten niet op je homepage te plaatsen waar er geen check is op referers etc.

[ Voor 23% gewijzigd door Verwijderd op 26-03-2004 11:27 ]

[Mithrandir]

Ik heb een oplossing bedacht, die meestal wel goed werkt:

met javascript checken of er een adult frame is. Als dat zo is kun je de src aanpassen.

Een nadeel is dat je dat niet altijd kunt toepassen, maar meestal is het wel mogelijk.

/edit:

oh, hmm, laat dan maar

[ Voor 45% gewijzigd door Mithrandir op 26-03-2004 21:13 ]

[Spider.007]

Mithrandir schreef op 26 maart 2004 @ 21:05:
Ik heb een oplossing bedacht, die meestal wel goed werkt:

met javascript checken of er een adult frame is. Als dat zo is kun je de src aanpassen.

Een nadeel is dat je dat niet altijd kunt toepassen, maar meestal is het wel mogelijk.

Ik zal even de code opsnorren, momentje.

code:

if (location != top.location) top.location = location

soms? Dat werkt niet vanuit een iFrame

[Bosmonster]

Dat werkt uberhaupt niet, want dan krijg je een security error Je kunt namelijk niet de location aanpassen van een document dat niet op hetzelfde domein staat.

parent.location.href zou overigens moeten werken mits het hetzelfde domein is. (location.href bevat de url, location is het location object, die moet je dus niet vergelijken ).

[ Voor 5% gewijzigd door Bosmonster op 27-03-2004 10:55 ]

[ACM]

Er zijn twee aspecten nodig om dit te beschermen:
- Geen html-injection toelaten, wat blijkbaar wel het geval was, anders werkte die hele ssl-verbinding niet icm de javascripts?
- Een challenge/response toevoegen, zodat het formulier iig niet geaccepteerd wordt. Maar dan ben je idd al te laat als dat je enige verdediging is.

Overigens kan je als je detecteert dat het formulier foutief was wel de gebruiker vermelden dat hem een nieuw wachtwoord is opgestuurd vanwege mogelijk account-hijacking.

[Verwijderd]

ACM schreef op 27 maart 2004 @ 11:56:
Er zijn twee aspecten nodig om dit te beschermen:
- Geen html-injection toelaten, wat blijkbaar wel het geval was, anders werkte die hele ssl-verbinding niet icm de javascripts?
- Een challenge/response toevoegen, zodat het formulier iig niet geaccepteerd wordt. Maar dan ben je idd al te laat als dat je enige verdediging is.

Overigens kan je als je detecteert dat het formulier foutief was wel de gebruiker vermelden dat hem een nieuw wachtwoord is opgestuurd vanwege mogelijk account-hijacking.

In dit geval gaat het helaas om een heel andere "attack". Het gaat om een vreemd formulier, een formulier dat totaal geen relatie heeft met de website. Dat betekend ook dat je challenge response features nog niet eens aan de orde komen.

Het is ook puur een formulier dat bedoelt is als data mining. Voer je gebruikersnaam en wachtwoord in en een andere partij krijgt het, en kan vervolgens inloggen bij plaxo met jouw gegevens, en daarbij alle contacts kapen.

[youngster]

Ik heb de test van bosmonster ook is uitgeprobeerd bij plaxo en hotmail.

Plaxo test
Hotmail test

Bij plaxo werkt het gewoon volgens mij, maar hotmail heeft toch een oplossing gevonden. Hier wordt je meteen geredirect, en ook als je die url probeert werkt het niet.

Hotmail test (http://login.passport.net/uilogin.srf?id=2)

Hoe hebben ze dat toch gedaan, en waarom zou bijv. Plaxo het niet zo oplossen?