'Beveiligde delen UvA en HvA-sites vatbaar voor man-in-the-middle-aanval'

De inlogpagina's van de Hogeschool van Amsterdam en de Universiteit van Amsterdam zouden vatbaar zijn voor een man-in-the-middle-aanval. Studenten stapten naar de ict-afdeling van de onderwijsinstellingen, maar kregen naar verluidt nul op het rekest.

Dat vertellen de studenten tegen Folia. Met een Raspberry Pi maakten ze een afgeleid netwerk van eduroam aan, waarna ze vervolgens het certificaat stripten. De studenten gebruikten daarvoor de tool SSLStrip die het proces automatiseerde.

Volgens de studenten gebruikten de HvA en de UvA voor hun inlogpagina's respectievelijk een oud en een zwak ssl-certificaat, maar het is zeer onwaarschijnlijk dat er iets mis was met de certificaten. Wel is het zo dat de gebruikte protocollen, SSLv2 en SSLv3, kwetsbaar zijn.

In een video laten de studenten zien hoe ze te werk gaan. "Stel je voor dat we ons netwerk ‘eduroam’ hadden genoemd. Alle studenten en medewerkers loggen daar nietsvermoedend op in, waardoor we al hun HvA- en UvA-inloggegevens hadden kunnen inzien", zeggen ze tegen Folia. De studenten trokken naar eigen zeggen bij de ict-afdelingen aan de bel, maar hoorden sinds september niets meer van ze. Daarom lichtten ze de media in.

Volgens de HvA is nog niet zeker of de aanval ook direct is gelinkt aan het 'slechte' beveiligingsniveau van de onderwijsinstellingen. Wel laat de school weten zich continu te richten op de implementatie van de protocollen, vanwege de kwetsbaarheden die regelmatig bekend worden.

Update, zondag - Artikel iets herschreven na feedback.

Update, maandag - Volgens één van de studenten ging het niet om zwakke of oude certificaten, zoals Folia meldde, maar om een gebrek aan beveiligingsprotocollen.

Reacties (56)

[elmuerte]

root@raspberrypi:~/logs# ./sslstrip.log
bash: ./sslstrip.log: Text file busy

L33t H4x0r!

Ze gebruiken dus gewoon sslstrip: http://www.thoughtcrime.org/software/sslstrip/
Niks bijzonders behalve het falen van de sysadmins.

[Reactie gewijzigd door elmuerte op 23 juli 2024 20:42]

[kodak]

Als ik de artikel van Tweakers en Folia lees snapt geen van de personen, zowel de journalisten als de studenten, wat nu de onderliggende zwakte is en welk probleem ze nu aankaarten. Dit komt voornamelijk door het summiere bewijs wat hier is aangegeven bij de claims, en waarschijnlijk ook het gebrek aan achtergrondkennis van wifi-netwerken, HTTPS/HTTP, certificaten en hun tools.

Wat hier lijkt te gebeuren:
"Kijk mam, ik kan versleuteld verkeer uitlezen door zwakke certificaten."
"Nee jongen, je verkeer is niet versleuteld tussen jou en de gebruiker omdat jij de gebruiker bent. Je bent alleen een proxy aan het spelen waar andere gebruikers liever gebruik van maken dan van de echte service."

Het filmpje toont gebruik van SSLStrip. Dat is een man-in-the-middle tooltje om een HTTPS-verbinding om te zetten in een HTTP-verbinding en die aan de gebruikers voor te schotelen. Hoe gebruik je dat? Je doet je als aanvaller voor als het echte access-point (bijv via arp-spoofing of een net echt lijkende SSID) en zorgt dat je slachtoffers met jou access-point verbinding maken. Vervolgens redirect je al de HTTPS-verzoeken naar je tooltje die de gebruiker alleen HTTP-verkeer probeert te laten gebruiken. Trapt de gebruiker er in doordat die niet oplet of de verbinding beveilgd is dan zie je dus onversleuteldverkeer langskomen. Het tooltje gebruik je om het dan zelf (man-in-the-middle) te communiceren met de echte HTTPS-service.

Kan je dat bij ieder open netwerk doen? Zolang je gebruikers hebt die klakkeloos hun persoonlijke informatie via HTTP verzonden, JA.

In de artikelen gaat het ook over zwakke SSL-certificaten. Dat staat geheel los van een werkende aanval die je met sslstrip. Het is geen tool waarmee je 'verouderde SSL versies kunt omzeilen'. Sommige oude certificaten kan je mogelijk gebruiken in een chain van certificaten om een nep-certificaat te maken, maar dat lijkt niet niet aan de orde.

Ik hoop dat die studenten gaan leren om eerst te doorgronden waar ze mee bezig zijn en wat ze in werkelijkheid bewijzen. Het concept van hun tools en de relatie tussen hun proof-of-concept en zwakke certificaten is iets wat ze duidelijk nog niet begrepen hebben.

[Reactie gewijzigd door kodak op 23 juli 2024 20:42]

[dupy]

Even goed lezen.
Deze studenten kaarten dit aan nadat de eigen organisatie 'niet thuis' gaf aan hun oproep.
Dit heeft niets te maken met intellectuele capaciteiten maar veel meer dat om het even wie zomaar in kan loggen op de sites van hun opleidingsinstituut.

[kodak]

Even goed doorgronden. Wat hebben de studenten ontdekt: dat ze als client verbinding maken met een service en vervolgens de diensten van de service onversleuteld gaan aanbieden aan gebruikers. Dat kan met _iedere_ HTTPS-site. Tegen gebruikers die klakkeloos HTTP accepteren als wie dan ook het ze aanbied valt niets te doen. Het concept van HTTPS is juist dat de gebruiker controleert of het wel HTTPS gebruikt en of dat met de juiste partij is. Zie je HTTP, dan is er iets mis als je vertrouwelijke gegevens gaat verzenden. Maar gebruikers doen dat niet als ze in een website die ze heimelijk via sslstrip is aangeboden en toch door gaan.

De acties over het aantonen van het 'lek' en het neerleggen van het probleem bij iemand die HTTPS aanbied zeggen dus wel degelijk iets over intellectuele capaciteiten. Ze horen de techniek en protocollen beter te doorgronden voor ze een partij kiezen om te gaan klagen en vervolgens niet het gehoor krijgen wat ze willen. Wat is het volgende, dat ze bij google, iedere willekeurige bank, de staat, alle HTTPS-sites in de wereld gaan klagen dan die hun beveiliging niet op orde zouden hebben??!!

[Reactie gewijzigd door kodak op 23 juli 2024 20:42]

[dupy]

Doorgronden gaat het hier niet om.
Studenten kaarten hier aan dat het systeem niet veilig is en krijgen nul op hun rekest als ze dit aankaarten bij de ICT-ers van hun instituut.
Zou me niets verbazen als de studierichting van deze studenten niets te maken heeft met ICT.

[sdevos13]

Inmiddels is er wel gereageerd en gaan we zelfs samenwerken met de ICT om dit soort lekken op te sporen. Wij doen beiede de studie Informatica met de richting Software Engineering.

[dupy]

Bedankt voor de opheldering, en sterkte met de studie.

[sdevos13]

Thanks, zal wel lukken

[sdevos13]

Op basis waarvan ga je ervanuit dat de studenten hier geen kennis van hebben? Dat de media dingen anders verwoord zegt niet meteen dat de studenten dat ook deden...

[kodak]

Uiteraard moet ik als eerste de personen die als proxy voor het verhaal dienen wantrouwen

Maar ik mag er nmm ook vanuit gaan dat studenten trachten ze helder mogelijk te verwoorden wat er gebeurt. Uit het filmpje bij het gebruik van sslstrip:

"Ik ga inloggen." (mobiel met browser waarbij de URL niet te zien is of die beveiligd is)
"Login op ip.hva.nl. Toevallig nu met een fout wachtwoord. Maar in het log komt dus mijn gebruikersnaam en wachtwoord tevoorschijn terwijl het over een sslverbinding gaat."

Daarnaast nog de quote:
"Op internet staat een tool waarmee je die SSL verbindingen kunt strippen, en je dus de verouderde SSL versies kunt omzeilen."
Dit laatste is een geschreven verwoording, maar zelfs als je onder een moderne SSL versie het gebruik van HSTS zou verstaan dan is al maanden bekend dat dat ook te omzeilen is.

[sdevos13]

In het filmpje wordt het uitgelegd voor het publiek van FoliaWeb. Dat Tweakers een artikel zonder aanvullende technische details overneemt van een studentenblad moeten zij zelf weten. Het is dan ook logisch dat in een filmpje voor leken een duidelijke technische uitleg achterwege blijft.

[kodak]

Ik verzin de quotes, en ik mag aannemen die studenten en journalisten ook niet. J Zelfs als je aanneemt dat ze het 'simpel' uitleggen, dan nog kloppen de beweringen niet. Met de tool is er geen sprake van een beveiligde verbinding, ze laten het ook niet zien en de tool heeft niets te maken met een verouderde SSL versie. punt.

[sdevos13]

En daar zit dat stukje miscommunicatie of interpretatie dan ook. Misschien hebben de studenten helemaal niet gezegd dat het aan de certificaten ligt?! Dat het niet compleet wordt uitgelegd op camera vind ik verstandig. Want anders gaat iedereen dit natuurlijk proberen.

[kodak]

Wil je eigenlijk zeggen dat je weet wat de studenten wel hebben proberen aan te kaarten of hou je ze gewoon uit aaibaarheid de hand boven het hoofd? Ik sta graag open voor een goed weerwoord tegen verdraaide vertalingen van verslaggevers, zeker als het om sensatielust gaat rond onbeveiligde ICT.

Maar uit de quotes van de student maak ik niet op dat die echt snapt wat het probleem is wat hij aankaart met het gebruik van zijn tooltje. Anders had hij zn woorden beter moeten gebruiken, en dus beter moeten snappen wat de basis van het probleem is. Dat samen met miepen dat die universiteit/hogeschool een onveilig website zou hebben klopt van geen kant. sslstrippen werkt op nagenoeg alle, ik herhaal alle, websites. Het protocol is namelijk niet bedoeld om te controleren of een client zich vervolgens als mitm gaat gedragen door de communicatie onbeveiligd door te zetten naar een niet zo slim slachtoffer dat geen zin heeft om te controleren of die te maken heeft met een beveiligde verbinding.

[sdevos13]

-

[Reactie gewijzigd door sdevos13 op 23 juli 2024 20:42]

[SirRosencrantz]

Nee, wat deze zegt. Het is ook best lastig het zo uit te leggen dat leken (redactieleden van een universiteitsblad) het snappen. Zelfs als je met een laptop langskomt om te laten zien wat je doet.

[Verwijderd]

Kan je dat bij ieder open netwerk doen? Zolang je gebruikers hebt die klakkeloos hun persoonlijke informatie via HTTP verzonden, JA.

Je kan het simpelweg voorkomen door het gebruik van HSTS. Het ligt dus wel aan hun implementatie.

[kodak]

HSTS is een poging om het te voorkomen. Het is feitelijk een melding van de service aan de gebruiker om enkel een beveiligde verbinding te accepteren. Client-side bescherming werkt alleen goed als je de client kan vertrouwen. Dat kan niet.

Er is inmiddels dus een nieuwe versie van sslstrip waarbij HSTS niet werkt.

Zie oa:
https://www.blackhat.com/...ct-Transport-Security.pdf

[Verwijderd]

Je kunt je website toevoegen aan HSTS lijsten in bijv. chromium. Dit valt tot op heden niet te omzeilen.

Hier een link waar je je website kunt toevoegen aan chromium.
https://hstspreload.appspot.com/

En hier vind je websites die al toegevoegd zijn.
http://src.chromium.org/v...ecurity_state_static.json

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:42]

[kodak]

Wederom een client-side issue.

[Verwijderd]

Wederom een client-side issue.

Tenzij de gebruiker een malafide versie van Chrome gebruikt valt HSTS niet te omzeilen op de websites die in de json lijst staan waarbij snionly op false staat.

[kodak]

Ik ga niet proberen om het concept "een client kan je niet vertrouwen" aan je uit te leggen. Hopen dat een gebruiker een bepaalde versie van een een bepaalde browser gebruikt bij het gebruik van een wifi-netwerk mag natuurlijk altijd.

Het punt wat de studenten maken is dat ze mitm kunnen spelen omdat de netwerkbeheerder een onveilige dienst levert. Naar de client wijzen ze niet, als we het artikel en het filmpje mogen geloven.

[Kain_niaK]

Bedankt voor een van de weinige reacties die de kern van de zaak blootlegt.
Af en toe lees ik een titel en dan het artikel en dan denk ik: hier gaan we weer ....

Man man man, wat is het moeilijk vandaag de dag om op het internet genuanceerd artikels te vinden die ergens over gaan zonder een hoop misvattingen en drukte om het verkeerde aspect ...

[chaoscontrol]

Ik denk dat ze dus nog SSL 2.0 en 3.0 ondersteunen i.p.v. alleen TLS 1.0,1.1 en 1.2. Dat kan ook echt niet meer deze tijd, los nog van welke cipher(suites) ze ondersteunen.

Trouwens, de enige support die je verliest door enkel TLS te ondersteunen, zijn de XP browsers.

Maar volgens mij hebben ze het al snel aangepast. https://www.ssllabs.com/s...cure.uva.nl%2Fcas%2Flogin

[Reactie gewijzigd door chaoscontrol op 23 juli 2024 20:42]

[elmuerte]

Trouwens, de enige support die je verliest door enkel TLS te ondersteunen, zijn de XP browsers.

Windows XP, en Windows Server 2003. Niet alleen browser communiceren met HTTPS servers. Er is ook genoeg (verouderde) server software die alleen SSL3 kent, en nog gebruikt wordt.

[SKiLLa]

Mag hopen dat ze niet nog SSLv2 ondersteunde, die wordt al 10+ jaar als 'broken' beschouwd.

En met SSLv3 uitschakelen verlies je NIET WinXP SP3 of Win2K3 R2 support; alleen WinXP SP2 + IE (en Android v2.3 of ouder). Op WinXP SP2 kun je Firefox of Chrome gebruiken; die hebben ook op XP SP2 gewoon TLS support. Worden er echter ook SHA-256 certificaten gebruikt ipv SHA-1, dan is Firefox de enige optie (want: eigen OpenSSL stack), Chrome/IE op XP (SP3 of ouder en ook Win2K3 server) ondersteunt slechts SHA-1, tenzij je een 'hotfix' van MS opvraagt (je weet wel: zo'n semi-publieke update waarvoor je eerst moet bellen / support-ticket met openen).

Jammer dat ze echter geen 'preferred server order' voor de SSL ciphersuites hebben geconfigureerd en ook nog eens RC4+SHA1 en RC4+MD5 ondersteunen; dat is ook niet meer van deze tijd. Gewoon moderne AES varianten gebruiken en slechts 3DES_CBC voor legacy OS compatabiliteit en klaar ben je ...

[chaoscontrol]

Je hebt helemaal gelijk(!), alleen RC4(128/128) wordt op een of andere manier nog als "PCI complient" beschouwd, daar zou ik dus nog in kunnen komen. En met 3DES leg je de perfomance hit bij je server neer, gewoon gebruiker instrueren te updaten en geen support leveren op oude meuk. (Ik snap dat dat niet altijd kan, maar in een ideale wereld blabla)

IIS, ook in Win2012(R2) en en server preview 10 enabled default nog gewoon oudere SSL vormen, wordt in de praktijk te weinig rekening mee gehouden.

[BCC]

In sommige landen mag je niet meer dan rc4 of 3des met twee dezelfde keys doen. Secure != PCI complient

[Treenaks]

(kleine correctie, Firefox gebruikt de library "NSS" voor TLS/SSL, niet OpenSSL)

[Jan-E]

Chrome/IE op XP (SP3 of ouder en ook Win2K3 server) ondersteunt slechts SHA-1, tenzij je een 'hotfix' van MS opvraagt (je weet wel: zo'n semi-publieke update waarvoor je eerst moet bellen / support-ticket met openen).

Nee, hoor. Op een XP SP3 met alle normale patches ondersteunt Chrome ook SHA256 ciphers. Ik kan https://www.sessiondatabase.net gewoon met Chrome benaderen.

[chaoscontrol]

Ja maar die loggen niet in op het intranet van UvA en HvA via deze pagina.

[Pikoe]

Het probleem is volgens mij vooral dat UvA een wifi netwerk gebruikt zonder wachtwoord, waarbij je via een tool moet inloggen op je uva account.
Door dus zelf een netwerk te maken met dezelfde naam kan je mensen ertoe verleiden in te loggen op jouw netwerk en zo inloggegevens stelen.

[GoT]

De video is mij nog steeds onduidelijk hoe of wat.
Maar deze tekst: "Stel je voor dat we ons netwerk ‘eduroam’ hadden genoemd", iets zegt mij dat ze van hun Notebook een WiFi hotspot hebben gebruikt en een login pagina van HvA / UvA hebben nagemaakt. Daarna met hun eigen smartphone op hebben ingelogd.
Dat zegt niks over een "slechte implementatie van SSL".

PS: zit er in hun notebook een Raspberry Pi ?

[CornNatron]

Volgens mij hebben ze een WiFi hotspot van de Rasberry gemaakt en daar op ingelogt met de smartphone en de laptop en hebben ze op de Rasberry tevens en pakketsniffer draaien welke wordt uitgelezen op de laptop .
Zo doende hebben ze de website niet na hoeven maken maar lezen ze gewoon de pakkets die worden toe gestuurt aan de orginele website welke dus slecht zijn beveiligt en inlogs/ww in plain text verzend .

[SirRosencrantz]

Jep, zo deden ze het.

[Verwijderd]

Ze hadden gister nog een dikke vette F op ssllabs. Daarnaast maken ze geen gebruik van HSTS, en daardoor kun je gemakkelijk alle "beveiligde" gegevens onderscheppen die over het netwerk gaan.

[Wacky Weed]

Ik snap niet helemaal wat ze hiermee bereiken...
Ik zit zelf dan op de HvA en heb één keer moeten inloggen op id.hva.nl(die zij dus hebben nagemaakt?) om mijn account te activeren. Zoas je ziet heeft deze site geen TLS 1.2 en 1.1 maar wel nog SSL3 en 2,
https://www.ssllabs.com/ssltest/analyze.html?d=id.hva.nl.
Maar wat dan nog? niemand gebruikt deze website...

Edit: blijkbaar is het nu al een B en hebben ze SSL3 en SSL 2 uitgezet!

[Reactie gewijzigd door Wacky Weed op 23 juli 2024 20:42]

[sdevos13]

Je zou door dit lek de inloggegevens van een docent kunnen achterhalen en je cijfers aanpassen

[SirRosencrantz]

Ze hebben inderdaad de boel vannacht/vanmorgen geüpdate. Gisteravond crisisoverleg.

Overigens, de twee studenten hebben laten zien dat het net zo makkelijk werkt bij SIS en dlwo. Ik neem aan dat je dat wel gebruikt.

[alienfruit]

Komt vaak genoeg voor hoor. Bij Volkskrant.nl moet je ook inloggen zonder HTTPS.

[wscheper]

Voor de wet ben je verplicht een ssl certificaat te gebruiken wanneer je met persoonlijke gegevens werkt. Beetje lomp van zon grote krant als de Volkskrant...

[kodak]

En dan is de vraag waarom mensen een onbeveiligde verbinding accepteren om hun persoonlijke gegevens over te versturen. En waar ligt dan de grens voor de personen om het te accepteren en wanneer doen ze dat niet? Bij sslstrip is het heel helder: zolang je daarmee gegevens kan onderscheppen is de interesse om die gegevens veilig te versturen niet groter dan de drang om het wel te doen. Bij wie moet je het probleem dan aankaarten? De studenten hebben het klaarblijkelijk bij de netwerkbeheerder gedaan. Als ze het niet bij de gebruiker aankaarten, vinden ze dan dat het enkel een probleem van de netwerkbeheerder is, of vinden ze wellicht dat gebruikers geen blaam treft omdat die 'onwetend' zijn? Ik zou persoonlijk graag zien dat ieder die een probleem met sslstrip tracht aan te tonen alle kanten op moet kijken voor een oplossing en niet enkel naar een netwerkeigenaar. Het zijn tenslotte de gegevens van de gebruiker die de gebruiker zelf onveilig gaat verzenden, terwijl die met een beetje moeite zelf kan controleren of het veilig gaat.

[sdevos13]

Jij stapt zeker ook niet in een auto voor zelf de motor onderzocht te hebben?

[alt-92]

Je gebruikt dan om een analogie in reverse aan te halen vóór het wegrijden het motor diagnose lampje als visuele indicator net als het slotje bij een SSL verbinding.

[kodak]

Wat alt-92 zegt.
Je hoeft geen it-beveiligingsspecialist te zijn om op zijn minst te controleren of je browser aangeeft dat je met een beveiligde verbinding te maken hebt.

[wscheper]

Verbaasd me niks. Ik heb ruim voor de zomer ook al de IT afdeling van de UvA ingelicht betreft de site van het USC die helemaal geen SSL certificaat gebruikt, maar wel met persoonlijke gegevens werkt voor het inschrijven van abonnementen etc. Kreeg als antwoord dat het probleem bekend was, ze hard werken aan een nieuwe site (die nog steeds niet online staat) en het erg lastig is om een verbinding af te luisteren.

Als ze zoiets als dat al niet eens kunnen verbeteren, vraag ik mij af hoe het met de rest van hun netwerk gesteld staat. USC registreert bijv. ook je vingerafdruk, mag toch hopen dat ze dat soort dingen wel op de goede manier beveiligd hebben!

[vali]

Is dit nieuws? SSL-strip techniek gebruiken uit 2009 en dat op de interne website gebruiken? Dat is al jaren bekend dat je hiermee wachtwoorden van zowat iedere website kan achterhalen (zelfs digit).

Enige paar websites die niet vatbaar zijn, zijn grotendeels websites van banken(en die maken geen gebruik van HSTS). Tenminste, hier kwam ik na een project op school achter.

Je moet gewoon goed opletten wat je doet met je laptop/tablet/smartphone. Als men met een Wifi jammer het Wifi platlegt van een school, is het niet zo dat je automatisch inlogt op een non-secure wifipunt.

[Reactie gewijzigd door vali op 23 juli 2024 20:42]

[WhatsappHack]

Laten we het er maar op houden dat de UvA en HvA niet de enige zijn met slechte IT policies en bar slecht beveiligde systemen... De HU vestigingen bijvoorbeeld zijn ook problematisch, ook gigantische privacy lekken te vinden, slechte e-mail setups, etc. De UTwente leek de zaakjes echter wel goed voor elkaar te hebben.

[Boy]

offtopic, maar beetje vreemd dat ik middels Googlen erachter moest komen waar HvA en UvA voor staat...

[Kapiteiniglo]

*ahum* Geachte redactie - GoT *ahum*

[Reactie gewijzigd door Kapiteiniglo op 23 juli 2024 20:42]

[Boy]

ow, sh*t! Maak ik me er zelf schuldig aan! Sorry..vind het altijd irritant dat er spelfouten en zo gemeld worden bij reacties, maar dit valt ook ongeveer daaronder...excuses...