Internetfilter Solcon gaf accountnamen klanten vrij aan iedere bezochte site

De Nederlandse provider Solcon gaf de accountnaam van een deel van zijn klanten met een geactiveerd InternetFilter vrij aan alle sites die ze bezochten. Het ging waarschijnlijk om duizenden klanten van het bedrijf die zo onbedoeld hun naam vrijgaven tijdens het internetten.

Niet iedere gebruiker lekte zijn accountnaam. Alleen de gebruikers die ervoor kozen de standaardinstellingen aan te passen en zelf via profielen sites op de zwarte lijst te zetten deden dit. Dan nog gaat het waarschijnlijk om duizenden gebruikers: ongeveer de helft van de 24.000 klanten neemt het filter af. Solcon prijst het toevoegen of verwijderen van sites van de zwarte lijst, als functionaliteit van het InternetFilter, nadrukkelijk aan.

Het lek kwam aan het licht door een klant van Solcon, die Tweakers inlichtte via het anonieme klokkenluiderplatform Publeaks. Tweakers heeft het bestaan van het lek vervolgens kunnen verifiëren: na een half uur loggen waren de accountnamen van 29 Solcon-klanten al in te zien. De meeste daarvan waren gebaseerd op de echte naam van de klanten.

Solcon biedt zijn klanten tegen een meerprijs het InternetFilter aan. De dienst werkt op basis van een zwarte lijst en moet voorkomen dat gebruikers op pagina's komen die ze schadelijk vinden. "Geweld en erotiek zijn letterlijk maar één klik van uw kinderen verwijderd. Het InternetFilter van Solcon beschermt ze hiertegen", prijst het bedrijf de dienst aan. In 2013 verscheen een nieuwe versie van het filter, die het verwijderen of toevoegen van websites van de zwarte lijst mogelijk maakte. Sinds die tijd geeft het filter waarschijnlijk al de namen vrij.

De namen waren zichtbaar in de requestheaders die browsers sturen naar sites. De abonneenaam werd verzonden in één van de headers die de filter-proxy toevoegt. Bij https-sites was de naam niet zichtbaar.

Solcon heeft het probleem binnen een dag na hier op gewezen te zijn opgelost. Sinds vrijdagavond lekken de namen niet meer uit via het filter. Tweakers heeft kunnen controleren dat de fout hersteld is. De provider licht zijn klanten maandag in over de stappen die ondernomen zijn.

Voorbeeld van de requestheader met gefingeerde accountnaam

Reacties (60)

Waarom worden er extra headers meegestuurd wanneer er een filter aanstaat? Doen webservers hier iets mee?

Debugging van je filter, maar ook om aan te geven dat het een filter/proxy is. Vooral de X-Forwarded-For header is daar een goede indicatie van.

En als een site veel 'fout' verkeer vanaf 1 IP ziet komen die een X-Forwarded-For header zet, dan hoef je niet de hele proxy te blokkeren maar kun je volstaan met alleen dat IP te blokkeren. Ook in het geval van misbruik heb je dan het 'echte' IP. Een filter/proxy als deze is uitdrukkelijk niet bedoeld als 'anomyzer' service, alleen was dat hier iets te uitdrukkelijk

Voor debugging of je filters het doen kan het best ideaal zijn

Waarom worden er extra headers meegestuurd wanneer er een filter aanstaat? Doen webservers hier iets mee?

Nee, maar waarschijnlijk wel Solcon's eigen proxies.

Hun architectuur zal wel load balanced zijn en zal gebruikers dus vanuit één of meerdere front-servers doorsluizen naar één van de filtering proxies die hen met het internet verbindt.

Hoe zorg je dan dat requests die bij gebruiker X horen op de filtering proxies de bijhorende block-list van gebruiker X gebruiken voor blokkades? Juist ja; door die gebruikersnaam mee te sturen. En hoe doe je dat zonder met de payload van een request te morrelen? Juist; via een custom HTTP header. De filtering proxy zelf moet deze header dan natuurlijk ook wel weer weghalen voordat een request doorgestuurd wordt het internet op. En juist daar zal het fout gegaan zijn.

Al met al een zeer amateuristische fout die met één simpele integratietest aan het licht had moeten komen en dat is dus niet gebeurd. De achterliggende reden of oorzaak daarvoor is voor ons als buitenstaander natuurlijk giswerk, maar persoonlijk zou een flater als deze voldoende zijn voor mij op zeer korte termijn mijn klandize bij een concurrent onder te brengen.

Één groot geluk bij dit ongeluk: HTTPS verkeer heeft deze custom HTTP header niet, wat in elk geval betekent dat Solcon niet al het HTTPS verkeer ontsleutelt en herversleutelt via een eigen trusted root certificate.
(Bij HTTPS verkeer zijn ook de headers versleuteld en kunnen dus niet aangepast worden door een proxy zonder dat er smerige zaakjes als herversleuteling plaats vinden.)

[Reactie gewijzigd door R4gnax op 26 oktober 2015 20:26]

Dat https verhaal betekent dus ook dat het zonder aanpassen van headers ook werkt. Waarom ze dat dan wel doen bij http is me een raadsel.

Nee want bij https websites werkt het niet.

Wat, het filter? Dus met https naar een porno site gaan werkt gewoon?

Volgens mij wel. Ik weet dat er vroeger tig manieren waren om het filter te omzeilen. Wij hebben het thuis ook jaren gehad toen het beheer van de instellingen nog bij solcon (toendertijd filternet) zelf lag. Dat hield in dat als websites onterecht geblokkeerd werden (zoals megaupload wat ik gebruikte om bestanden uit te wisselen), je er maar een melding van moest maken en dan afwachten of het werkte. Dat was voor mij geen optie dus was google translate en allerlei proxies een goed alternatief.

Aan de andere kant hebben ze het probleem wel binnen een dag opgelost. Er zijn maar weinig bedrijven die een bug zo snel opgelost hebben, hoe simpel het soms ook lijkt.

Daar kunnen een heleboel andere bedrijven nog een voorbeeld aan nemen.

Aan de andere kant hebben ze het probleem wel binnen een dag opgelost. Er zijn maar weinig bedrijven die een bug zo snel opgelost hebben, hoe simpel het soms ook lijkt.

Daar kunnen een heleboel andere bedrijven nog een voorbeeld aan nemen.

Als het probleem daadwerkelijk is geweest wat ik beschrijf, dan is het voor veruit de meeste proxy software één of twee regeltjes extra configuratie toevoegen om een header onvoorwaardelijk te strippen op uitgaande requests en meer niet.

Dan kun je het nog gaan hebben over bedrijfsprocessen, papierwerk, red tape, etc. maar als een nieuwe feature voor productie deployment niet eens een integratie test traject ondergaat dan zal daar ook weinig sprake van zijn...

[...]
Één groot geluk bij dit ongeluk: HTTPS verkeer heeft deze custom HTTP header niet, wat in elk geval betekent dat Solcon niet al het HTTPS verkeer ontsleutelt en herversleutelt via een eigen trusted root certificate.[/small]

Dat betekent het helemaal niet, hoewel 't wel de waarschijnlijke oorzaak is.

Zeer onhandig en voedt zeker twijfel over de professionaliteit van de orgainsatie, maar het siert ze dit probleem zo snel op te lossen.

In 2013 verscheen een nieuwe versie van het filter, die het verwijderen of toevoegen van websites van de zwarte lijst mogelijk maakte. Sinds die tijd geeft het filter waarschijnlijk al de namen vrij.

Nou ja noem het maar snel.

Maar sinds die tijd is de bug niet bekend. Een bug die niet bekend is, kun je niet oplossen.

Nee, maar in dit geval (uitgaande dat het zo gegaan is als in het artikel is vermeld) dan mag je verwachten dat dit veel en veel eerder was opgemerkt.

Sja, wat kan ik zeggen, ik geef zelf ook aan dat een deuk is in het vertrouwen. Maar tegelijk toch props dat ze dit een dag na melding oplossen? Dat is alles wat ik wil zeggen, maar blijkbaar niet mag zeggen of zo....

Ik wou net hetzelfde quoten maar dan met de opmerking dat het woordje 'waarschijnlijk' wel erg gevaarlijk is. Het kan ook twee weken aan hebben gestaan of zo.

De bug zat in een functie die in 2013 werd geintroduceerd. Solcon heeft dit bericht ter inzage gehad en het niet weersproken.

Je moet je eerst bewust zijn van een probleem voor je het kan oplossen. Uiteraard had de developer die hiervoor verantwoordelijk is zoiets nooit in productie mogen toepassen, maar dat bied geen uitkomst aan hoe snel men het oplost na het bekend maken van het lek.

Het lijkt bijna alsof iemand een debug optie heeft laten aanstaan in de filtersoftware.

Dat zou kunnen verklaren dat de oplossing zeer snel is doorgevoerd.

Het veranderen van een string-concat is evengoed snel door te voeren.

Klopt, kortom, filosoferen over wat er precies is gebeurd heeft weinig zin...

Lijkt er op dat Solcon hun hostnames voorziet van de gebruikersnaam? Als dat inderdaad zo is ligt het probleem niet bij het filter. Erger nog, iedereen zou een gebruikersnaam bij een IP kunnen opzoeken met nslookup.

sidenote: FFI-IP hoeft natuurlijk geen hostname te zijn, maar het lijkt er verdacht veel op.

[Reactie gewijzigd door DeTeraarist op 26 oktober 2015 18:12]

Nee, de IP's uit de headers die ik voorbij zag komen resolven naar ftth-$ip.solcon.nl om een voorbeeld te geven. De 'FFI-IP' header was een concat van de gebruikersnaam en het IP van de gebruiker, niet de reverse hostname.

Je kan zeggen wat je wilt, maar Solcon is en blijft in mijn optiek één van de betere providers. Ze hebben een degelijke klantenservice, en hebben (vrijwel) nooit een storing. Dit is wellicht een of andere stagiair geweest die de debugging optie aan heeft laten staan. Kan gebeuren. Is wel jammer, want dit soort nieuws kan een kleine provider de kop kosten.

Aan de andere kant: Wat kan een website met je username? Praktisch niets.

Hangt er vanaf.... qua diensten verschillen ze niet zoveel met bijvoorbeeld XS4ALL, persoonlijk krijg ik een beetje jeuk van bepaalde "optieken" waar Solcon voor staat. Maar ik zou me kunnen voorstellen dat mensen uit een bepaalde hoek hier zich juist wel thuis bij vinden.

Ik ben niet zo van de internetfilters, ik geloof meer in een vrije beschikbaarheid en door openen communicatie (met name kinderen) laten zien hoe de wereld echt in elkaar zit. Op een bijna panische manier bepaalde dingen wegstoppen is niet mijn visie qua opvoeden. Maar goed, ieder zijn keuze.

Natuurlijk kan je heel veel met een username, bij veel mensen is deze vaak het zelfde gekozen als het hoofd-emailadres. @scolcon.nl en je komt dus erg ver.... Iets wat juist bedoelt is om de wereld af te schermen zorgt dan voor een toegang voor bijvoorbeeld spampraktijken...

Of te wel, het is een ontzettend domme fout. Lekker handig, een filter zo instellen dat hij juist triviale data doorgeeft...

Ik ben niet zo van de internetfilters, ik geloof meer in een vrije beschikbaarheid en door openen communicatie (met name kinderen) laten zien hoe de wereld echt in elkaar zit. Op een bijna panische manier bepaalde dingen wegstoppen is niet mijn visie qua opvoeden.

Met een paar tikken en klikken kun je de goorste zaken op je scherm krijgen. Dit is zó makkelijk, dat ik niet anders kan zeggen dat Internet juist een extreem slecht beeld geeft van hoe de wereld in elkaar zit. Filteren, zeker als het gaat om jongere kinderen, heeft in het geheel niets met panisch te maken, als wel met gezond ouderschap.

Het blokkeren van "informatie over voorbehoedsmiddelen" heeft niets te maken met gezond ouderschap, zelfs het tegenovergestelde naar mijn mening.

Dit heeft niks te maken met voorbehoedsmiddelen. Dit heeft te maken met keiharde p0rn. Klein verschil. Kinderen moet je daar niet aan blootstellen en al helemaal niet als ze het niet verwachten.

en voorbehoedmiddelen laat ie gewoon door, als je je instellingen daarop aanpast.

Dit filter is niet preuts, maar effectief tegen grensoverschrijdend geweld, misbruik etc.

[Reactie gewijzigd door D-Day op 27 oktober 2015 12:29]

Precies. Maar voor kinderen van 13 die hun huiswerk maken mbv internet totaal niet interessant.

Het internetfilter is bij solcon optioneel

Je username is al de helft van wat je nodig hebt om binnen te komen.

Ligt eraan, als je bedenkt dat veel mensen overal dezelfde login gegeven gebruiken..
Zet even een website op waar men in moet loggen, en hup je hebt de login.
Naja vaak hebben deze mensen ook een @solcon.nl email adres, daar kan je gelijk bij.
En je kan in theorie aardig wat kwaard verrichten.

Al hoop ik dat dit mensen niet weg schrikt van Solcon, ben al een aantal jaren tevreden klant.
Wat je zegt, amper last van storingen en aardig nette klantenservice.
Al heb ik nooit gebruik gemaakt van de internet filter.

[Reactie gewijzigd door esholmwood op 26 oktober 2015 19:00]

Vals sentiment. Ik heb meerdere internetproviders gehad en ik heb praktisch nooit een storing gehad bij wie dan ook. Helpdesks voor internet. Pardon? En een stagiair die dit soort zaken inricht lijkt me ook erg onwaarschijnlijk. Het is gewoon slordig daarmee is de kous af. Wat ze siert is dat alles snel opgelost is.

Ik zag al een relatie tussen de oproep op het forum of er Internetfilter gebruikers waren en het spoedonderhoud van Solcon aan dit filter

En nog wel als beste getest door de consumentenbond.Toegegegeven het is wel lastig om overal expert in te zijn.

Waarom meldt die klant het aan tweakers ipv aan z'n provider?

het is gemeld aan publeaks....kun je daar vast wel nazoeken waarom hij/zij het zo gedaan heeft, kan best zijn dat ze er niet op reageren, of bang zijn dat het bedrijf hen gaat aanklagen ofzoiets....

Wij waren heul vroeger klant toen het begon als Filternet. Tegenwoordig (bij mijn ouders thuis) gewoon KPN klant, maar als je eens een supportvraag hebt kun je een paar avonden achter elkaar aan de telefoon hangen. Solcon heeft snelle responsetijden op de helpdesk. In mijn werk hebben we diverse klanten met een zakelijke Solcon aansluiting onder onze partnerovereenkomst en de zakelijke helpdesk is beter dan Ziggo zakelijk en KPN zakelijk bij elkaar.

De filteropties juich ik van harte toe, wanneer je als ouders/verzorgers graag je kinders enigszins beschermd het internet wil laten gebruiken dan is dit ideaal. Het is dan wel de bedoeling dat je als ouders de dialoog met je kinders aangaat, en niet net doet alsof alles wat ze niet kunnen zien ook daadwerkelijk niet bestaat.

Verder kwalijke zaak, ben het ermee eens dat dit intern toch wel naar voren had moeten komen bij tests van het product. Mogelijk was het inderdaad om (tijdelijk) te loggen en heeft iemand dat niet uitgezet. Feit dat het binnen 1 dag was opgelost siert de technische dienst en tekent de snelle response van de helpdesk zoals ik al eerder aangaf. En na een nieuwsvermelding als deze zullen ze vast wel iets inbouwen om dit in te toekomst te voorkomen. Problem solved. Lijkt me een beetje te panische reactie om dan gelijk een andere ISP te gaan zoeken, want nogmaals zover ik kan beoordelen heeft Solcon zijn zaakjes het beste op orde.

En ook meteen naar Publeaks toestappen zonder eerst Solon de kans te geven het netjes op te lossen. Meteen weer aan de grote klop hangen. (aanname maar wordt niet vermeld in het artikel)

Dat is natuurlijk de tijd waarin we leven: digitale schandpalen, naming and shaming.

Je mag er niet van uit gaan dat een lek nog niet gebruikt wordt.
Je moet er van uitgaan dat dit actief misbruikt wordt door kwaadwillenden. Dus dan heeft het geen nut meer om het stil te houden, ze weten er toch al van.
Beter nog, als je het publiekelijk maakt, dan weten de slachtoffers ook van het probleem af, en kunnen ze een tussentijdse oplossing voorzien, totdat het lek gedicht is.

Security through obscurity is no security at all

[Reactie gewijzigd door efari op 26 oktober 2015 21:32]