Niels de Blaauw: Een analyse van onderbelichte risico’s van informatielekken in WordPress
Ik kacht ze in het vertaal van de mensen, van de druik, van zo'n goede ervaring. Ik hoop dat wij een derde ervaring hebben. Nou, het is een heel goede miss. Dat geeft me hier wat te kijken. Ik werd gegaan. Ik kom nu zo'n drikking en daar zag ik net een hele eeuw spiezen voorbij komen. Ik heb een kistel op de achterhoofd die ik overtuigde. Ik ben echt gek op de ketten. Ik zag ze even in de spreken. Ja. Zijn er net al even de titel van de dronk in? Mij komt niet te schrijven. Mijn hoofdweerder is toch niet zo eermang mijn lief. En analyse van de informatie, let je in WordPress. Dus ik wil het aan de warmte laten zien. Om te beginnen, wie gelooft dat dat 75% van de gehakte CMS WordPress is? Kan ik aan hetje zien? Het is niet helemaal waar. Het is namelijk nog schokkender. Het is 83% van alle gehakte CMS is WordPress. En ik vind dat we daarover moeten hebben. Ik vind dat dat geen goede ontwikkeling is. Ik ben Niels en ik heb 150.000 websites geanalyseerd op wat er beter kan en moet. Dus de afgelopen jaar is het best veel gebeurd op gebied van data lekken. En de belangrijkste daarvan is de introductie van de AVG-wetgeving in mei 2018. Er zijn allemaal geconverteerd met de manier waarop wij gegevens verzamelen. En hoe we die delen met anderen en hoe we dat ken maken aan gebruikers. Zodat die kunnen kiezen wat we allemaal overstelen. Dus we zijn daar allemaal heel bewust mee om gegaan. Een andere ontwikkeling die we zien is dat WordPress steeds groter wordt. In de afgelopen jaar is het van 27% marktendeel naar 30% marktendeel gaan. En een ontwikkeling die nog iets harder loopt is het aandeel van gehakte WordPress-installaties die erbij horen. Want ook al groeit WordPress hard. Het aantal hacks op WordPress groeit nog veel harder. Daar heeft Luc Prince afgelopen juni een artikel overgeschreven op basis van data van security. En dat gaat erover dat het niet per se komt omdat WordPress zelf gevaarlijk is of lek is. Maar het komt meer omdat de instap zo ontzettend laag is om met WordPress in de slag te gaan. Dat er heel veel situaties zijn waarin misconfiguratie plaatsvindt. Of mensen installaties doen die ze niet helemaal zelf begrijpen.  Of niet update omdat ze daar de middelen niet voor hebben. Dus het is niet per se dat WordPress als geheel onveilig is. Maar ook een stukje bewustzijn in de community wat daar mee kan helpen. Om dat te verkomen. Dit is de quote van Luc uit het artikel van juni. Last year WordPress was responsible for 38% of infected content management sites. En als community hebben wij bij meerdere wordcams advies gehoord over hoe we deze problemen met het hekken van WordPress kunnen verkomen. Er zijn er altijd een aantal standaard advies hier nog even samengevat. Alles moet update zijn. Dus op het moment dat jij een WordPress-installatie hebt die een plug-in bevat die al twee plus jaar niet is geupdate. En er zijn wel updates voor beschikbaar. Dan is de kans groot dat dat problemen gaat opletten. Het kiezen van goede wachtwoorden. Natuurlijk help WordPress daar al heel erg mee door aan te geven wanneer je een onveilig wacht wordt kiezen. Maar ook dat is gewoon een super belangrijk ding. En voldoende logging is dat als er iets fout gaat en er blijkt iemand op je website rond te zitten. Dat we snel kunnen zien wat er gebeurd is, hoe iemand binnen is gekomen. Inzicht krijgen op wat er überhaupt op je website gebeurt. En die drie standaard advies worden vaak aangevuld door nog een hele hoop. Een beetje site-specieke advies zoals veranderen tabellnaam, veranderen je admin-gebruikersnaam. Verstop de WP admin, dissebel, XML, RPC. Het gaat er niet om dat je precies weet wat al die dingen doen of waarvoor ze zijn. De belangrijkste samenvatting is, dit zijn allemaal manieren om het zo moeilijk mogelijk te maken om voor geautomatiseerde aanvallen jouw website te proberen te hacken. Dus op het moment dat een geautomatiseerde bot lag soms, en je probeert op de gebruikersnaam admin, probeert die 100.000 verschillende wachtwoorden en daar zit er eentje bij die heel makkelijk tradis, dan heb je een probleem. Dus al deze advies er zijn eigenlijk om die geautomatiseerde aanvallen proberen zo moeilijk mogelijk te maken. Een analyse van WordFans in oktober 2017 liet zien dat er vanaf één russisch IP-adres, hoeveel waren er? 15 miljoen aanvallen zijn geprobeerd op WordPress en dat is niet één gast die achter zijn toetsenbord zit te klikken, maar het is gewoon een soort serverfarm die gewoon automatisch probeert zoveel mogelijk WordPress in Slice State.  Recht tegenover de ontwikkeling om het zo moeilijk mogelijk te maken om automatisch daden te verzamelen en heel bewust te zijn van welke daten we aan het delen zijn, is er in december 2016 de WordPress API deel geworden van de WordPress Core en dat is een hele belangrijke ontwikkeling geweest voor het delen van daten want de missie die de WordPress API zelf in de handbook omschrijft is de WordPress API provides an easy-to-use set of HTTP endpoints that let you access your site's data, including users. Dus waar we aan de ene kant het zo moeilijk mogelijk maken om automatiseerd met die WordPress-insulation te gaan, zijn we aan de andere kant bezig om het zo makkelijk mogelijk te maken om met computers WordPress te besturen om te makkelijk mogelijk te maken om data uit te lezen. Bijvoorbeeld, we kunnen de user-lijst van de WordPress site heel makkelijk uitlezen door de toevroeging bpjson.v2.slashusers in te vullen en als we in de browser naar deze pagina zouden gaan dan krijgen we een resultaat dat ongeveer zo uitziet.  En dit is in mijn geval één gebruiker maar dit kunnen er 10 of 100 zijn en daar wordt data overgedeeld zoals de volledige naam van de gebruiker de URL die de gebruiker zelf als verwijzende website dus ook al ben ik op level.level.com geregisterd kan ik daar een verwijzing maken naar mijn persoonlijke website de slug, dat is de gebruikerstaand die mensen gebruiken om in te loggen en wat belangrijk is om hier te zien is dat hier zo gegevens als email adres en telefoonnummers niet standaard in voorkomen het is namelijk zo dat WordPress heeft bedacht we kunnen wel gebruikseinformatie delen maar we willen ook weer niet teveel delen en zeker geen data die privé zou moeten zijn dus er is nagedacht over hoe we dit zo veel mogen kunnen beperken in informatie die meegegeven wordt dus ik had bedacht van hoe kunnen we nou proberen in plaats van die ene website deze informatie op te halen dat van 1 miljoen websites te doen dus ik heb op alexapp.org die publiceren elke maand een lijst van de 1 miljoen populairste websites op het internet en ik heb een schipje gegeven wat vervolgens van alle miljoen websites probeerd om de WPJs en userlijst op te halen en op het moment dat ik dit een avondje lidra had dan had ik van 5000 verschillende websites informatie over welk gebruikstijg registreerd aan en vervolgens kun je met een heel simpel commandootje het is even door hebben wat je aan het doen maar met 1 commando kan ik bijvoorbeeld analyseren hoeveel admin gebruikers er in die lijst van 5000 websites plaatsvinden vervolgens heb ik het schriptje opgehaald en wat verder geautomatiseerd en rekening gehouden dat sommige websites niet op geen teruggever dat je zou willen en na 1 miljoen websites geanaliseerd te hebben heb ik informatie verzameld over 156.000 verschillende WordPress installaties wat in totaal 752.000 unieke gebruikers opleverde het toverwoord thuis unieke gebruikers en zal ik straks hem even uitleggen wie was er de eerste dag bij de keynote van Anton hij had erover dat bijvoorbeeld Google en Facebook dit soort data verzamelen maar het is dus ook voor mij in mijn eentje op m'n eigen laptop mogelijk om over hele grote getale informatie te verzamelen door middel van wat WordPress beschikbaar stelt en ook al heb je maar 1 website op het moment dat heel WordPress 30% van het internet is dan heb je toch te maken met hele grote schaal van informatieverzamelen op het moment dat we dan gaan kijken wat er in die verzamelde informatie staat dat betekent dat dat ongeveer 20% van verzamelde websites een gebruiker heeft die admin heet en informatie op de website publiceert terwijl wij juist altijd advies geven je moet geen admin gebruiken op de website hebben vervolgens heeft nog eens 10% heeft een gebruiker met admin in de gebruiksnaam dus die hebben een gebruiker die noemen ze dan admin 2 want dan hebben ze voldaan aan het veranderen van de username of ze noemen hem wet admin of ze noemen hem administrator maar uit de naam is nog steeds heel duidelijk te herleiden wie de admin gebruik gaat zijn ook dit is nog steeds pretsbaar voor geautomatiseerde aanvang dus op het moment dat wij op admin 2 dezelfde wachtwoord analyse gaan loslaten heb je nog steeds dat je kwetsbaar bent voor die geautomatiseerde aanvang dit is de top 10 van gebruikersname in de lijst van 700.000 plus wat opvalt is dus dat bij een aantal gebruikersname heel snel te zien is dat dit waarschijnlijk een beheeraccount is en weet je dus als aanvaller heel snel welke je moet hebben om proberen aan te vallen wat verder opvalt is dat eigenlijk alle naam in de top 10 verder zijn westense mannennamen en nummer 11 is dan vervolgens Laura dus dat was wel leuk omdat hij net bijtoe de top 10 valt nou heeft WordPress over het lekker van gebruikersname hebben ze een standpunt op security.werpers of op de security lijst staan en daarbij zeggen ze wij vinden de gebruikersname geen gevoelige informatie je kiest er zelf wat voor gebruikersname je gaat delen heel veel websites die delen meer dan alleen een gebruikersname over je dus voor WordPress of in ieder geval de WordPress community als geheel is de gebruikersname geen gevoelige informatie dus we gaan in de WordPress aan te kijken wat we daar nog wel voor gevoelige informatie kunnen krijgen en in de eerste of het moment dat je dus de WordPress API ophalt dan krijg je naast gegevens over een username en de URL die mensen opvoeren krijg je ook een graventaurel en de graventaurel dat is een geanonymiseerde versie van het emailadres van meegereerstriben op een website dat betekent dat wij voor verschillende websites dezelfde gebruikers aan elkaar kunnen koppelen ook al hebben ze daar een andere gebruikersname of ook al hebben ze niks met website te maken dus op het moment dat ik mij als Niels de Blauwe registreer op level level met het emailadres niels at level level.com en volgens op een totaal ongerelateerde site met dezelfde emailadresregistreer dan kan ik die twee graventaurels die op de twee verschillende websites gegenerëerd worden dan kan ik aan elkaar koppelen dus ik kan in de 150.000 websites die ik heb geanonymiseerd dezelfde gebruikers over meerdere sites kan ik die trekken dat levert vervolgens zoiets op dit is een visualisatie die ik heb gemaakt van vijf websitejes die dezelfde WP Engine gebruiker hebben hier zien we bijvoorbeeld dat Joost.com een gebruiker heeft die WP Engine heeft waarschijnlijk worden daar gehost en hebben ze support gehad en is er een WP Engine admin die een post op Joost heeft gepubliceerd dat ik best interessant vind maar je kan ook zien dat dezelfde gebruiker ook bestaat op ConvertKit en op agoda.com dus ik kan heel snel relaties leggen tussen één gebruiker met een emailadres die op meerdere sites is geregisterd nou kan het zo zijn in het geval van TechCrunch bijvoorbeeld dat jij super veel maatregelen aan het nemen bent om te zorgen dat jouw website niet op een automatiseerde manier aangevallen kan worden bijvoorbeeld door de WP admin te verbergen bijvoorbeeld door te zorgen dat mensen niet meer dan drie keer met een verkeerd wachtwoord kunnen inloggen en een website als TechCrunch die kan daar een flink budget voor vrijmaat maar op het moment dat er een gebruiker is die bij TechCrunch een account heeft en ook op een andere website in de twee zijn aan elkaar te koppelen stel je dan voor dat CineCalidad.to niet het budget heeft om al die veiligheidsmaatregelen te nemen en dat die geen rate limiting heeft op het aantal keer dat iemand een verkeerd wachtwoord kan proberen dan ontstaat vervolgens het probleem dat na onderzoek van Troy Hunt ongeveer twee derde van mensen hetzelfde wachtwoord gebruikt over verschillende websites dus op het moment dat het wachtwoord gekraakt wordt op de ene website en we kunnen herleiden op welke andere websites die gebruiken nog meer een account he is het heel waarschijnlijk dat we met dezelfde gegevens die website kunnen kunnen wat ver nog is is dat de woordenlijst online gepubliceerd van eerder hacks en in 86% van de gevallen of moet ik het anders uitleggen er was een nieuwe hack gevonden met ongeveer 2 miljoen gebruikers en 86% van de gebruikers die daarin voorkwamen waren al bekend in eerderen lijsten met emailadres en het wachtwoord wat erbij wordt dus wat we bijvoorbeeld kunnen doen is we kunnen zo'n lijst downloaden voor alle emailadressen een eigen graventar URL genereren daarvan kijken op welke websites die graventar URL allemaal vak komt en proberen met het wachtwoord wat bekend is daar in te logen een probleem ervan is dat we dat verkeer niet kunnen onderscheiden van een legitieme inlog omdat het één keer met de juiste gebruikersnaam met de juiste wachtwoord en je zit er meteen in sinds 1 januari 2018 zijn er volgens WP Vulability Database 33 zogenaamde authenticate kwetsbaarheden gewonnen en die houden in dat je alleen maar de informatie kan uitbuiten op het moment dat je als ingelogd gebruikt werd de website in en bijvoorbeeld WooCommerce die heeft gezegd van wat, vieer om te update maar omdat je het alleen als ingelogd gebruikt kunt misbruiken is het minder kwetsbaar maar op het moment dat je van zoveel websites informatie kunnen verzamelen is dat nog maar de vraag of het echt minder kwetsbaar is Laten we nog even terug gaan naar de AVG waar we mee begonnen en een discussie die ik jullie voor wil leggen de AVG vraagt namelijk aan ons om alle datalecken te documenteren en alle datalecken te melden in dit geval is het zo dat je via je WordPress site al dan niet onwetend geanonymiseerde gegevens deelt over misschien 10, misschien 20, misschien 100 gebruikers en op zichzelfstaand is die informatie niet heel waardevol op het moment dat je die 150.000 website analiseert en daar wel kwetsbare gegevensheid kunt halen wie moet dat dan vervolgens gaan melden wie heeft de verantwoordelijkheid over die data want op jouw eigen website kun je er weinig mee waarschijnlijk kun je niet eens zeggen dat er data gelekt is want het is een legitieme gebruik van hoe de WordPress API werkt dus wie zou dit moeten melden als laatste wil ik nog twee advies geven die wat breder gaan dan verander je admin gebruikersname en zorg dat je backups hebt slaag geen data op die je niet hoon nodig hebt het is natuurlijk al wat we met de AVG allemaal hebben geleerd om te doen maar ook deel geen data die anderen niet nodig hebben want het is heel makkelijk om te zeggen dat het internet ook moet zijn en dat er zoveel mogelijk gegevens vrij moeten maken dat past ook heel goed bij de WordPress community alleen tegelijkertijd is het zo dat op het moment dat je informatie deelt die niemand gebruikt totdat iemand het op de verkeerde manier gebruikt dan ben je misschien ook niet helemaal goed bezig dankjewel dat was hem dankjewel dankjewel dankjewel dankjewel dankjewel aan de rest API dichtzetten? ja er zijn filters onder de rest API dichtzetten dat is niet heel moeilijk je kunt zelfs een plugin downloaden die het voor je doet en je hebt ook nog een plugin waarbij je precies kan bepalen welke data je wel of welke datapunt je wel wilt delen en welke niet dus daar kun je zeggen informatie over de berichten die we posten wel delen en informatie over gebruikers niet dus daar kun je redelijk specifiek kiezen wat er allemaal gedeeld wordt ja inderdaad en anders straks even naar ben toekomen en dan hebben we het erover dat klopt misschien ook nog belangrijker te noemen ik geloof dat ik het ook in mijn speakernood had met deze manier van data verzamelen is er eentje en hoewel dit in ieder geval voor mijn situatie de makkelijkste manier is om op hele grote schaal data verzamelen heb je bijvoorbeeld ook je sitemaps die data lekken over en niet de sitemaps de RSS-fiets die data lekken over wie post produceert je comments-fiets er zit een graventauroling op het moment dat je in de metadata van een post gaat kijken dan kun je daar auteurs informatie over vinden je kunt door vraagteken p at er is 1 kun je informatie over auteurs vinden er zijn heel veel manieren wat op deze informatie te achterhalen was dit is voor mij de makkelijkste geweest maar het is zeker niet wanneer je de rest de API dichtzet weet je dan helemaal veilig maar het is alleen moeilijker geworden om die informatie heel snel te verzamelen klopt dus ook de plan te geven uit Hoekommer is eigenlijk vrij eindpouder de lijst die door in ieder geval de WPJs en APU wordt gedeeld is beperkt dat mensen die een bericht hebben gepubliceerd op de website dus voor het geval van orders in Hoekommer die staan er niet in maar op het moment dat het verkeerd geconfigreerd is staan bijvoorbeeld de gebruikers van een forum kunnen er wel in staan op het moment dat jij een afgeschermd forum hebt voor psychologische aandoening en je kunt er alleen maar met een uitnodiging opkomen want het is misschien heel erg privé wat er allemaal plaatsvindt dan nog zou ik kunnen dat die gegevens omdat zij bericht te publiceren wel in die lijst staan dus dat is even iets waar je heel bewust van moet zijn dat gaat alleen om gebruikers die bericht te publiceren maar er zijn vaker mensen die bericht te publiceren waarvan je het niet verwacht zoals de WP Engine gebruiker op de Joost site overigens is WP Engine dan meteen één van de boos doen want op het moment dat ik de WP Engine gebruikers naam opzoek heb ik twee, driehonderd website waarop zij bericht te publiceren dus er is iemand en dan is het ook nog heel apart om te zien dat zij dat...