Eh nee, F12 indrukken bij een website is geen criminele handeling

| AE 12980 | Ondernemingsvrijheid, Security | 24 reacties

(Geen zorgen, nog een keer F12 en je scherm is weer normaal.) Het ziet er misschien heel imponerend uit, maar dit is gewoon het onderwaterscherm waarmee je onder meer de broncode van de huidige site in beeld krijgt. Dan kun je soms net iets meer informatie zien. Zoals recent journalist Josh Renaud uit Missouri ontdekte: de social security nummers van tienduizend docenten uit de staat. Mag dat? Nee, dat is crimineel, aldus gouverneur Mike Parson. Moehaha kom nou, aldus de hele wereld.

Het bronbericht geeft een 451 error (lawyer says no) vanuit Europa, maar het betrof een zoekfunctie voor docenten, waarbij de zoekresultaten werden meegegeven aan de resultaatpagina inclusief hun social security number, zeg maar hun bsn. Bij het programmeren van de site bedacht iemand toen dat dat niet echt handig is om te publiceren, dus werd het verborgen in de uitvoer. Maar het stond dus nog gewoon in de broncode, en die krijg je te zien met een druk op de knop.

Een datalek, zouden wij in Europa zeggen. Een beperkte security. Want als die data niet zichtbaar hoeft te zijn in resultaten, dan hoeft deze ook niet mee naar de webpagina om daar vervolgens buiten beeld te blijven. Dan houd je dat gewoon lekker op de server. Afijn, de melding werd opgepakt, de fout werd hersteld, daarna pas publiceerde men, weinig bijzonders.

Bijzonder was wel de reactie van de gouverneur, want in de vertaalslag omhoog naar het politieke ging iets mis. “Onze server stuurde bsn’s mee en dat kon iedereen zien die op F12 drukt” werd namelijk dit:

Through a multi-step process, an individual took the records of at least three educators, decoded the HTML source code, and viewed the SSN of those specific educators.
Die meer dan drie klopt (het waren er 100.000), de rest is laten we zeggen een ietwat complexe voorstelling van zaken. Die multi-step is namelijk dat je een zoekopdracht doet, de resultaatpagina krijgt, F12 drukt en in de broncode scrollt tot je “ssn” ziet. “Decoding the HTML source code” is, eh, zeggen dat je langs <tags> kunt lezen?

En dan gaat men nog verder:

A hacker is someone who gains unauthorized access to information or content. This individual did not have permission to do what they did. They had no authorization to convert and decode the code.
Het punt is alleen dus dat de code in kwestie is wat er naar je computer wordt gestuurd, en dat deze voor mensen leesbaar is. Of nou ja, leesbaar:
<div class=”text”><h1><a reF=”https://blog.iusmentis.com”>Internetrecht door Arnoud Engelfriet</a></h1> <p>Arnoud Engelfriet is ICT-jurist, gespecialiseerd in internetrecht.Hij werkt als partner bij juridisch adviesbureau <a Href=”http://ictrecht.nl” rel=”external” target=”_blank”>ICTRecht</a>. Zijn site <a hRef=”http://www.iusmentis.com/”>Ius mentis</a> heeft meer dan 350 artikelen over internetrecht.</p></div>
Ik wil niet zeggen dat dit metéén net zo helder is als een gemiddeld juridisch contract, maar om dit nu een “code” te noemen die je moet “ontcijferen” gaat wel erg ver. Maar hoe dan ook is het absurd om te zeggen dat hier sprake is van “toegang zonder toestemming”, dit is gewoon wat de server je geeft en het is juist je browser die er wat moois van maakt.

En natuurlijk, voor computercriminaliteit is niet perse nodig dat je een moeilijke technische truc uithaalt. Zodra je ergens bent waarvan je weet dat je er niet mag zijn, ben je eigenlijk al in overtreding. Vandaar die discussie over URL-manipulatie, het aanpassen van een URL om te gokken dat je elders nog informatie kunt vinden waarvan je zo snel niet de navigatie erheen kunt bepalen. Maar hoe je het ook bekijkt, zelf een URL aanpassen om te raden wat elders staat, is complexer dan bekijken welke HTML broncode een site naar je stuurde.

Arnoud

 

 

Deel dit artikel

  1. Ik wil niet zeggen dat dit metéén net zo helder is als een gemiddeld juridisch contract

    Ik lees liever door HTML heen dan door een gemiddeld juridisch contract hoor 😉

    Maar hoe je het ook bekijkt, zelf een URL aanpassen om te raden wat elders staat, is complexer dan bekijken welke HTML broncode een site naar je stuurde.

    Verschil daarin is ook nog dat je in het eerste geval zelf een handeling moet doen (de URL aanpassen) om andere resultaten te ontvangen. In het tweede geval krijg je de informatie gewoon aangeleverd vanaf de website zonder dat je daar een extra handeling voor moet doen. Dat is gewoon een enorme faal van de overheid in dit geval.

    Zijn er situaties waarbij je wél in overtreding zou kunnen zijn in een geval als dit (waarbij je dus enkel naar een (openbare) site gaat waar je naartoe mag en verder geen vreemde dingen doet als URL’s aanpassen enzo), of is het hierbij altijd de schuld van de partij achter de website, onder het mom van ‘dan had je die informatie maar niet naar de ontvanger moeten sturen’?

  2. Sterker nog, die HTML krijg je al te zien, wanneer je het bestand opent, door het in de open-functie van een tekstverwerker te plakken. Dus het is gewoon data die je aangeboden krijgt. De browser is niet meer dan een leesprogramma, dat door de tags weet, hoe de verzender de opmaak wil zien. Maar wanneer je een opgemaakt tekstdocument opent met een platte tekstverwerker, dan zal je soortgelijke effecten zien. Bekend voorbeeld is in een spreadsheet de gegevens van een cel “verbergen”, door de tekst dezelfde kleur te geven als de achtergrond. Ja, je kunt het niet lezen en nee, om het te lezen hoef je niets moeilijks te doen. Gewoon de achtergrondkleur aanpassen is heel simpel. Anders wordt het , wanneer je een passwordbeveiliging moet uitschakelen. Waar dat bij een spreadsheet een mogelijke beveiliging is, is dat er bij HTML niet.

  3. Het is alsof je een VOG bij de gemeente graag aanvragen en je een map overhandigt krijgt met een kopie van alle VOG’s en of je de jouwe er dan even uit wil halen. Owja en de map hoef je niet terug te geven want het was makkelijker om gewoon mappen met kopien van alle VOG’s klaar te hebben liggen dan de ambtenaar een specifieke VOG te laten opzoeken en uitprinten. Dus of je zelf even er voor wil zorgen dat die map netjes vernietigd wordt.

    Kan je de andere partij nu niet aansprakelijk stellen voor het feit dat ze je opgezadeld hebben met PII’s, zonder een verwerkersovereenkomst. Want deze broncode blijft op jouw computer staan (browser cache) en eventueel je backups. Stel die data lekt dan, ben je aansprakelijk of niet? Hoe moeilijk is het om die aansprakelijkheid af te wenden.

  4. Ik kende dat niet, F12, maar het scherm wel, wat ook verschijnt als ik bij vergissing shift-ctrl-C indruk. En dat doe ik best vaak, want in Linux Mint commandoregelprogramma’s, zoals de door de mij zeer veel gebruikte teksteditor nano, zijn shift-ctrl-c en shift-ctrl-v de alternatieven voor ctrl-c en ctrl-v, voor kopiëren en plakken. Dit omdat ctrl-c sinds jaar en dag (minstens sinds 1985) betekent: stop het lopende programma.

    Ctrl-insert en shift-insert, die doen ook al 500 jaar copy en past. Was ooit een IBM-standaard, en zat in Borland-C. Zitten ook in m’n vingers, maar gebruik ik niet meer altijd, hoewel nu eigenlijk weer handiger.

  5. En natuurlijk, voor computercriminaliteit is niet perse nodig dat je een moeilijke technische truc uithaalt. Zodra je ergens bent waarvan je weet dat je er niet mag zijn, ben je eigenlijk al in overtreding.

    Het equivalent zou wat mij betreft zijn dat je ergens loopt waar je op zich wel mocht komen, maar ineens een geheime code kon zien nadat je voor een muurschildering een handstand deed. De wandelaar zegt ‘maar de tekst stond daar gewoon op de muur’. De gouverneur zegt ‘maar je mocht daar die handstand helemaal niet doen!’

  6. Ik stel dat de URL aanpassen minder complex is dan de SSN’s scrapen. Een URL aanpassen is een handeling die elke web gebruiker dagelijks doet. De formele regels van het web, en de zoekmachines, zeggen beiden dat dit een normale manier dient te zijn om een site te kunnen navigeren. Zo kan ik deze URL aanpassen naar https://blog.iusmentis.com/2021/10/ en uit de URL halen waar deze pagina over zal gaan. En dat werkt. Je zit volgens mij echt zelf fout als je iets publiekelijk openbaart, zonder “geen toegang”-bordje of slot. Grens licht bij mij bij XSS, waar je de URL manipuleert om database queries uit te voeren, of javascript uit te voeren op computers van andere bezoekers. Je bent dan meerdere akties aan het uitvoeren, waarvan je kan verwachten dat ze de publicatie aanpassen. Maar manipuleer ik slechts een web address zelf, stel die /2021/10/ URL geeft de jaarnota en geplande posts in deze maand. Dikke pech.

    Hier doen ze extra handelingen. Eerst voeren ze een zoekopdracht uit, waardoor ze direct een database uitlezen. Dan in de resultaatpagina gaan ze in alle code speuren. Ze decoderen Base64 json blobs. Ze infereren dat de unieke tabel-cell identifier een SSN is. Ze stoppen niet meteen, maar doen meer gerichte zoekopdrachten, en verzamelen SSN’s voor een artikel. Ja, dat is wel een geavanceerdere hack te noemen. Als je dit met slechte intentie doet, dat vind ik dat zelf strafbaar (en laakbaar van de site bouwers), en met slechte intentie een /45006.html naar /45005.html veranderen weer niet (ook niet met slechte intentie f12 drukken, maar afhankelijk wat je daarna doet).

    Natuurlijk is die man een kluns. Was het een stuipreaktie. En gaat het zoiezo 50 miljoen dollar kosten om de gehele situatie op te lossen. De melding viel onder responsible disclosure (maak ook grijs, want volgens mij was het artikel er eerst, toen pas de IT paniek met een rot PR.).

    • De sterke politieke reactie tegen de journalist, wordt iets begrijpelijker als:

      • nagegaan wordt hoe men deze SSN’s verzamelde (die SSN’s zaten niet eens in de broncode, maar werden dynamisch ingevuld via javascript, gepresenteerd als een random blob, zonder duidelijke keying met SSN’s, alleen goed crawlbaar met speciaal-gemaakte generieke zoektermen die veel resultaten geven — maar ga dit maar eens uitleggen aan een gouverneur) en

      • hoe de publicatie is verlopen (die lijkt met een politiek smaakje, de bug gebruiken om politieke oppositie in kwaad daglicht te zetten, het was duidelijk een journalist op zoek naar een verhaal, geholpen door hackers, die reeds maanden van de bug afwisten, maar dit ook niet hadden gemeld).

      Kan het dat iedereen hier gewoon fout zat? En dat dit verhaal heel anders had afgelopen, als men werkelijk nog ethische hackers had gemotiveerd door bescherming van persoonsgegevens?

    • De controversieele analogie: Een advocaat schrijft een toegankelijk blog en levert daarmee een publieke dienst. Het blog heeft zelfs een zoekfunctie. Daarmee kunnen gebruikers artikelen zoeken op trefwoorden. Iemand in een chatkanaal zit te kloten en komt erachter dat er in sommige zoekresultaten een extra stuk javascript wordt meegeleverd:

      SGlqIHdlcmt0IGFscyBwYXJ0bmVyIGJpaiBqdXJpZGlzY2ggYWR2aWVzYnVyZWF1IDxhIEhyZWY94o CdaHR0cDovL2ljdHJlY2h0Lm5s4oCdIHJlbD3igJ1leHRlcm5hbOKAnSB0YXJnZXQ94oCdX2JsYW5r4 oCdPklDVFJlY2h0PC9hPi4gWmlqbiBzaXRlIDxhIGhSZWY94oCdaHR0cDovL3d3dy5pdXNtZW50aXM uY29tL+KAnT5JdXMgbWVudGlzPC9hPiBoZWVmdCBtZWVyIGRhbiAzNTAgYXJ0aWtlbGVuIG92ZXI ”

      Het chatkanaal komt erachter dat door een bug in een WordPress-plugin voor javascript zoeken, ongepubliceerde snippets van een te verschijnen boek zitten. Sterker, het boek is nog niet geheel ontdaan van voornamen en zo is te herleiden wie wie is. Waarom de advocaat zijn WordPress site gebruikte voor het schrijven en editen van het boek is niet geheel duidelijk. Hij dacht met de dure uitbesteding van IT nooit tegen zulke security bugs aan te lopen.

      In plaats van een mailtje naar info@ (nadat security.txt niet bestond, en security@ bounced), ga je door. Je gaat zoeken op “eh” “giechel” “even” “het” “een” “is”, en je trekt zo bijna het hele boek leeg. Daar haal je alle voornamen uit, gaat correleren, en komt met een hele complete lijst van alle prive-gegevens.

      Die lijst zet je door naar een juristenjournalist. Deze stuurt nog even netjes een bericht, een paar dagen voor publicatie, zodat de site plat kan, en niet iedereen de privegegevens kunnen lezen. Tenminste, niet iedereen die bij de privegegevens kunnen, die hopelijk in een kluis naast het koffiezet-apparaat liggen. In het artikel zeg je natuurlijk: Hey, die gegevens konden we zo in de broncode vinden! Die advocaat bakt er maar niets van, en geeft niets om je. Volgende keer maar goed uitkijken als je zaken met hem moet doen.

      En iedereen hard lachen natuurlijk. Nu, zeg het maar… Heeft die advocaat een poot om op te staan? Ik zou die journalist niet graag wezen.

    • Ter vergelijking: In plaats van een zoekformulier (en zonder base64 decode) deed Weev iets als: example.com/searchemail/?q=INCREMENTALIDENTIFIER

      As a member of the hacker group Goatse Security, Auernheimer exposed a flaw in AT&T security that compromised the e-mail addresses of iPad users. In revealing the flaw to the media, the group also exposed personal data from over 100,000 people, which led to a criminal investigation and indictment for identity fraud and conspiracy. Auernheimer was sentenced to 41 months in federal prison, of which he served approximately 13 months before the conviction was vacated by a higher court.

      Auernheimer has remained unapologetic about the offense, telling Business Insider that all he did was access a public and unsecure Web server — an action which, if the prosecution’s logic is followed, would make all Internet users criminals.

  7. “Vandaar die discussie over URL-manipulatie, het aanpassen van een URL om te gokken dat je elders nog informatie kunt vinden waarvan je zo snel niet de navigatie erheen kunt bepalen.”

    Vind ik vergelijkbaar met een ruimte een winkel binnenlopen, die de eigenaar eigenlijk als magazijn gebruikt. Is me een keer gebeurd en zijn reactie was: “Je begaat geen misdaad, maar dit is alleen een opslag.” Een URL aanpassen is voor mensen, die al minstens twee decennia internet gebruiken gewoon een manier om te surfen. Dat de smartphonegeneratie denkt, dat internet synoniem is met Google, kunnen wij oude rotten niet helpen. Verder kijken dan je neus lang is, maakt je geen crimineel.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS