Duitse onderzoeker veroordeeld voor gebruik van hardcoded wachtwoord
Een Duitse beveiligingsonderzoeker is in Duitsland veroordeeld tot een boete van drieduizend euro nadat hij een hardcoded wachtwoord in een databaseproduct aantrof en dit gebruikte om op de database van de leverancier in te loggen. Na zijn onderzoek rapporteerde hij het probleem bij de leverancier. Via het hardcoded wachtwoord bleken de gegevens van 700.000 klanten op straat te liggen. Het softwarebedrijf verhielp het probleem, maar deed ook aangifte tegen de onderzoeker. Volgens de rechtbank is er sprake van ongeautoriseerde toegang tot een systeem en het bespioneren van gegevens.
De onderzoeker, een programmeur, was door een klant van het Duitse Modern Solution gevraagd om problemen met de software van de it-leverancier te onderzoeken. De software van Modern Solution bleek veel te veel logberichten te produceren. De programmeur ontdekte dat de software van Modern Solution een MySQL-verbinding naar een MariaDB-databaserver van de leverancier opzette.
Het wachtwoord om toegang tot de databaseserver te krijgen was onversleuteld in plain text in het bestand MSConnect.exe opgeslagen. Alleen het openen van het bestand met een editor was voldoende om het hardcoded wachtwoord te zien. De onderzoeker ontdekte verder dat de database niet alleen de gegevens bevatte van de klant voor wie hij het onderzoek deed, maar van alle klanten van Modern Solution.
Na zijn ontdekking waarschuwde de onderzoeker de leverancier. Die werkte vervolgens aan een oplossing, maar besloot ook de onderzoeker aan te klagen. Daarnaast waarschuwde het bedrijf klanten voor een datalek (pdf) waarbij toegang tot hun gegevens mogelijk was. Volgens de leverancier was het door een 'ethische hacker' over het probleem ingelicht.
De aanklacht stelt dat de onderzoeker zich schuldig heeft gemaakt aan onrechtmatige toegang tot data, waarbij wordt verwezen naar een wetsartikel waarin staat dat het bekijken van met wachtwoord beveiligde gegevens een misdrijf is. Afgelopen juni kreeg de programmeur nog van de rechter gelijk, die stelde dat de software van Modern Solution onvoldoende beveiligd was. De zaak kwam vervolgens voor bij een districtsrechtbank die van mening is dat de onderzoeker de wet heeft overtreden.
De Duitse blogger Mark Steier, die over de zaak bericht, noemt de boete schokkend en fundamenteel verkeerd. "Een wachtwoord dat nagenoeg in plain text is opgeslagen vormt geen 'speciale beveiliging', zoals het wetsartikel vereist. Het is begrijpelijk dat een rechter dit niet kan beoordelen, maar dan had een expert hierover moeten worden gehoord, wat helaas niet is gebeurd."
Wladimir Palant, onderzoeker en ontwikkelaar van Adblock Plus, noemt de uitspraak van de rechter een gevaarlijke ontwikkeling omdat het beveiligingsonderzoek een riskante onderneming maakt. Hij hoopt dan ook dat de uitspraak wordt teruggedraaid. "Maar het is precies waar mensen bang voor waren: hoe slecht ook de veronderstelde 'beveiliging', alleen de aanwezigheid ervan maakt beveiligingsonderzoek onder Duitse wetgeving strafbaar. Dit heeft een chilling effect op legitiem onderzoek, waardoor bedrijven weg kunnen komen met inadequate beveiliging en gebruikers gevaar lopen."
Reacties (23)
19-01-2024, 12:22 door
Anoniem
Of de uitspraak juridisch steek houdt kan ik niet beoordelen, maar als dat zo is lijkt me dat een hiaat in de wetgeving. Een beveiligingsonderzoeker die in good faith handelt, zou naar mijn mening bescherming vergelijkbaar met die van een klokkenluider moeten genieten.
19-01-2024, 12:29 door
Anoniem
Een Duitse beveiligingsonderzoeker is in Duitsland veroordeeld tot een boete van drieduizend euro wegens het vinden en rapporteren van een hardcoded wachtwoord in een databaseproduct, dat hij tijdens zijn onderzoek ook gebruikte om op de database in te loggen.
Ik ben zelf beveiligingsonderzoeker geweest, maar je dient al helemaal niet tijdens jouw onderzoek in te loggen dankzij een kwetsbaarheid of wachtwoord dat je hebt gevonden. De voorwaarden staan duidelijk op de websites van de organisaties vermeld, dus hoe precies moet worden gerapporteerd (via PGP-versleuteld e-mail) en ook dat je geen misbruik maakt. Doe je dat toch, dan zet je de deur zelf open voor een Justitieel onderzoek, zoals dat ook op de websites is vermeld ingeval van responsible disclosure.
19-01-2024, 12:32 door
Anoniem
Het rechtssysteem is op deze manier totaal nutteloos... Dan kan je net goed alle data van de klanten op straat leggen
19-01-2024, 12:33 door
Anoniem
De onderzoeker is dus niet veroordeeld voor het rapportern van het hardcoded wachtwoord.
Maar is veroordeeld voor het gebruiken van dat hardcoded wachtwoord en rondneuzen hoeveel er dan te zien was met dat wachtwoord.
Aan de ene kant moet je dat als onderzoeker wel doen, omdat bedrijven zullen liegen over wat er dan zichtbaar zou zijn geweest als je het wachtwoord gebruikte.
Aan de andere kant; Als je weet dat dat strafbaar is volgens de wet in je eigen land?
Is dit gebruikt als proefproces?
Maar is veroordeeld voor het gebruiken van dat hardcoded wachtwoord en rondneuzen hoeveel er dan te zien was met dat wachtwoord.
Aan de ene kant moet je dat als onderzoeker wel doen, omdat bedrijven zullen liegen over wat er dan zichtbaar zou zijn geweest als je het wachtwoord gebruikte.
Aan de andere kant; Als je weet dat dat strafbaar is volgens de wet in je eigen land?
Is dit gebruikt als proefproces?
19-01-2024, 13:24 door
Anoniem
De titel lijkt een beetje misleidend, omdat het een andere oorzaak-gevolg-relatie suggereert. Het is "na het gebruik van een gevonden hardcoded wachtwoord", niet na het melden ervan.
19-01-2024, 13:54 door
Anoniem
Wel gek.
Als programmeur heb je een aantal opties.
1. Controleren of je inderdaad een lek hebt gevonden door even in te loggen. Dit kan leiden tot grote problemen omdat je zogezegd verkeerd bezig bent.
2. Je er niks van aantrekken; niet jouw probleem...
3. Er twee dagen voor uittrekken om uit te zoeken wat de regelgeving is omtrent dit soort dingen. Responsible disclosure zoeken want die is niet altijd (eenvoudig) te vinden. Dan netjes een rapport schrijven. En dat allemaal in je eigen tijd. Want je krijgt er geen cent voor betaald.
4. De informatie verkopen op het dark web waar en hoe het lek misbruikt kan worden.
Zou de juiste oplossing niet ook het meeste op moeten leveren?
Als programmeur heb je een aantal opties.
1. Controleren of je inderdaad een lek hebt gevonden door even in te loggen. Dit kan leiden tot grote problemen omdat je zogezegd verkeerd bezig bent.
2. Je er niks van aantrekken; niet jouw probleem...
3. Er twee dagen voor uittrekken om uit te zoeken wat de regelgeving is omtrent dit soort dingen. Responsible disclosure zoeken want die is niet altijd (eenvoudig) te vinden. Dan netjes een rapport schrijven. En dat allemaal in je eigen tijd. Want je krijgt er geen cent voor betaald.
4. De informatie verkopen op het dark web waar en hoe het lek misbruikt kan worden.
Zou de juiste oplossing niet ook het meeste op moeten leveren?
19-01-2024, 14:17 door
Anoniem
De je huurt een pentester in om je landschap na te gaan. De pentester doet e.e.a. aan bevindingen, controleert of z'n aannames correct zijn en rapporteert dit vervolgens netjes aan opdrachtgever en leverancier.
Vervolgens klaagt de leverancier de pentester aan voor inzage in gegevens.
Maar, het zijn toch geen gegevens van de leverancier? Volgens mij had de opdrachtgever die aangifte moeten doen. Hebben ze in Duitsland dan niet zoiets als een 'responsible disclosure' richtlijn of gewoon goed ende fatsoenlijk opdrachtgeverschap?
Als ik opdrachtgever was van de pentester, en mijn leverancier flikt zo'n kunstje, zou ik toch op z'n minst de accountmanager van die leverancier even uitnodigen voor een 'goed gesprek'. Die 3k boete zou ik ook doodleuk verhogen met BTW, marge en transactiekosten en in rekening brengen bij die accountmanager.
Vervolgens klaagt de leverancier de pentester aan voor inzage in gegevens.
Maar, het zijn toch geen gegevens van de leverancier? Volgens mij had de opdrachtgever die aangifte moeten doen. Hebben ze in Duitsland dan niet zoiets als een 'responsible disclosure' richtlijn of gewoon goed ende fatsoenlijk opdrachtgeverschap?
Als ik opdrachtgever was van de pentester, en mijn leverancier flikt zo'n kunstje, zou ik toch op z'n minst de accountmanager van die leverancier even uitnodigen voor een 'goed gesprek'. Die 3k boete zou ik ook doodleuk verhogen met BTW, marge en transactiekosten en in rekening brengen bij die accountmanager.
19-01-2024, 14:29 door
Anoniem
Even inloggen om te checken dat dat wachtwoord daadwerkelijk correct is lijkt mij heel normaal.
Zeker als je verder geen rare dingen doet en na een `SHOW TABLES;` direct uitlogt en rapporteert.
Als dat niet mag, dan zou ik het "absoluut niet" verkopen voor geld dat ik hard nodig heb ofzo... :)
"If they don't allow good deeds, do bad deeds instead"
Zeker als je verder geen rare dingen doet en na een `SHOW TABLES;` direct uitlogt en rapporteert.
Als dat niet mag, dan zou ik het "absoluut niet" verkopen voor geld dat ik hard nodig heb ofzo... :)
"If they don't allow good deeds, do bad deeds instead"
19-01-2024, 14:41 door
Anoniem
No good deed goes unpunished ;) Zo regel je wel dat de ethische hackers er weinig zin meer in hebben om de organisaties op de hoogte te stellen van zaken die fout zijn.
19-01-2024, 14:59 door
Anoniem
Door Anoniem: Ik ben zelf beveiligingsonderzoeker geweest, maar je dient al helemaal niet tijdens jouw onderzoek in te loggen dankzij een kwetsbaarheid of wachtwoord dat je hebt gevonden. De voorwaarden staan duidelijk op de websites van de organisaties vermeld, dus hoe precies moet worden gerapporteerd (via PGP-versleuteld e-mail) en ook dat je geen misbruik maakt. Doe je dat toch, dan zet je de deur zelf open voor een Justitieel onderzoek, zoals dat ook op de websites is vermeld ingeval van responsible disclosure.
Dit was (in tegenstelling tot waar het artikel mee begint) geen beveiligingsonderzoeker maar een programmeur die was ingehuurd door het bedrijf dat de software gebruikt om te onderzoeken waarom de software overdadig veel logmeldingen produceerde. Hij vond de connectiegegevens in de executable en maakte er verbinding mee in de veronderstelling dat hij alleen data van zijn eigen opdrachtgever te zien zou krijgen. Zodra hij zag dat er gegevens van andere klanten verschenen heeft hij de connectie weer verbroken en het gemeld.Heise beschrijft het (in het Duits) uitgebreider:
https://www.heise.de/news/Warum-ein-Sicherheitsforscher-im-Fall-Modern-Solution-verurteilt-wurde-9601392.html
Als hij als beveiligingsonderzoek bezig was geweest dan was had hij moeten weten op welk punt hij dingen ging proberen waar hij niet voor geautoriseerd was. Maar hij was bezig met een onderzoek naar een applicatie waar kennelijk ook applicatiedata een rol in speelde, en hij veronderstelde dat hij vanuit zijn opdracht geautoriseerd was om die te benaderen.
Wat ik problematisch vind aan deze uitspraak is dat er zonder opzet geen misdrijf is. Hij heeft zich wel opzettelijk toegang verschaft tot een ander systeem, maar hij dacht alleen bij data uit te gaan komen waarvoor hij geautoriseerd was en heeft zich dus niet opzettelijk ongeautoriseerde toegang tot een ander systeem verschaft.
19-01-2024, 15:18 door
Anoniem
Ik neem aan dat het bedrijf een fikse hogere boete/straf te wachten staat?
19-01-2024, 15:43 door
Anoniem
Door Anoniem:
Een Duitse beveiligingsonderzoeker is in Duitsland veroordeeld tot een boete van drieduizend euro wegens het vinden en rapporteren van een hardcoded wachtwoord in een databaseproduct, dat hij tijdens zijn onderzoek ook gebruikte om op de database in te loggen.
Ik ben zelf beveiligingsonderzoeker geweest, maar je dient al helemaal niet tijdens jouw onderzoek in te loggen dankzij een kwetsbaarheid of wachtwoord dat je hebt gevonden. De voorwaarden staan duidelijk op de websites van de organisaties vermeld, dus hoe precies moet worden gerapporteerd (via PGP-versleuteld e-mail) en ook dat je geen misbruik maakt. Doe je dat toch, dan zet je de deur zelf open voor een Justitieel onderzoek, zoals dat ook op de websites is vermeld ingeval van responsible disclosure.Even een vraag hierover. Dat je met het hard-coded ww bij de eigen gegevens kan is logisch, dus dat hoef je eigenlijk niet te testen (en de leverancier kan je daar ook niet op aanspreken, je doet het namens de klant op gegevens van je klant). Maar om te controleren of het WW generiek toegang geeft (dus ook naar andere klanten)moet je iets. Zou de volgende actie ook problemen hebben opgeleverd?
- doe een query met het WW naar een ander record (niet van je klant)
- kijk of er een foutmelding komt, maar kijk niet naar het resultaat van de query (dus je bekijkt geen gegevens, alleen toegang)
- meldt bij de leverancier dat er een vast WW is, dat je daarmee bij de eigen gegevens (van je klant) kan, maar dat het er op lijkt dat je ook bij andere klanten kan, want je hebt één query gedaan en kreeg geen foutcode. Meldt daarbij dat je de opgehaalde gegevens niet bekeken hebt en gelijk vernietigd hebt, zodat de gevraagde informatie nooit naar buiten is gekomen.
Ik begrijp de leverancier wel: je moet reageren als iemand onterecht toegang tot je gegevens heeft gekregen (is je plicht naar je klanten toe). Maar ze hadden dit natuurlijk ook anders aan kunnen pakken en in gesprek gaan etc.
Ik denk dat als ze te fel achter deze ethical hacker aan gaan, terwijl ze een giga-beginnersfout hebben met forse security impact voor hun klanten, dit uiteindelijk negatief voor ze uit gaat vallen: één hard-coded WW voor alle klanten! Ik ben benieuwd of ze een security certificering hebben (ISO27000 of zo iets) want die kan dan ook gelijk door de plee (inclusief de auditor organisatie) en dat kost klanten!
19-01-2024, 15:45 door
Anoniem
"Aufgrund dieser Sicherheitslücke war es möglich, das Passwort zu unserer Datenbank abzugreifen und auf unverschlüsselte Passwörter und personenbezogene Daten zuzugreifen"
Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
19-01-2024, 16:56 door
Anoniem
De data die toegankelijk is toch van de klant niet van Modern Solution? de klant vraagt om onderzoek naar de problemen, de klant had Modern Solution moeten aanklagen om het niet zorgvuldig en veilig om gaat met de data van de klant.
19-01-2024, 18:03 door
Anoniem
Door Anoniem:
[..]
Wat ik problematisch vind aan deze uitspraak is dat er zonder opzet geen misdrijf is. Hij heeft zich wel opzettelijk toegang verschaft tot een ander systeem, maar hij dacht alleen bij data uit te gaan komen waarvoor hij geautoriseerd was en heeft zich dus niet opzettelijk ongeautoriseerde toegang tot een ander systeem verschaft.
[..]
Wat ik problematisch vind aan deze uitspraak is dat er zonder opzet geen misdrijf is. Hij heeft zich wel opzettelijk toegang verschaft tot een ander systeem, maar hij dacht alleen bij data uit te gaan komen waarvoor hij geautoriseerd was en heeft zich dus niet opzettelijk ongeautoriseerde toegang tot een ander systeem verschaft.
Zonder opzet geen misdrijf is een wat dubieuze generalisatie. Het is over het algemeen een verzachtende omstandigheid , maar zo generiek zou ik het niet stellen.
In de categorie doodslag e.a. kun je absoluut schuldig zijn aan een variant doodslag/dood door schuld (op basis van ernstige onvoorzichtheid , nonchalance e.d.) zonder dat er de *opzet* was tot iemands overlijden.
Ik vrees dat als je per vergissing door de verkeerde openstaande deur loopt er nog steeds sprake kan zijn van insluiping .
(andersom gezegd : insluipers hebben geen 'get out of jail card' door alleen maar te claimen dat ze zich vergisten in de open deur waar ze naar binnen gingen ).
En - op moment dat je gaat kijken in een server die duidelijk NIET van je bedrijf/opdrachtgever is , is je "automatische" autorisatie dat het om je eigen gegevens gaat al heel wat twijfelachtiger geworden.
Dat hangt ontzettend af van de contractuele relatie met die derde partij. "Recht op de gegevens" is niet hetzelfde als "ze zelf ophalen door een API te hacken" .
Ik begrijp die programmeur wel, en ook het probleem dat min of meer te goeder trouw melders afgeschrikt worden, maar juridisch lijkt dit oordeel me niet onmogelijk.
19-01-2024, 19:54 door
Anoniem
Door Anoniem: "Aufgrund dieser Sicherheitslücke war es möglich, das Passwort zu unserer Datenbank abzugreifen und auf unverschlüsselte Passwörter und personenbezogene Daten zuzugreifen"
Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
Je leest het goed.Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
Beveiliging verondersteld ook het juiste omgang met bv password en dat ten minste af te schermen. Een executable is ook gewoon een bestand.
In dit geval is m.i. geen sprake van een beveiliging op z'n best obfuscatie.
19-01-2024, 21:15 door
Anoniem
Door Anoniem:
Beveiliging verondersteld ook het juiste omgang met bv password en dat ten minste af te schermen. Een executable is ook gewoon een bestand.
In dit geval is m.i. geen sprake van een beveiliging op z'n best obfuscatie.
Door Anoniem: "Aufgrund dieser Sicherheitslücke war es möglich, das Passwort zu unserer Datenbank abzugreifen und auf unverschlüsselte Passwörter und personenbezogene Daten zuzugreifen"
Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
Je leest het goed.Lekker dan. Niet alleen lag het wachtwoord van de database op straat, ook hadden ze plain-text passwords in de database staan. Of lees ik dit verkeerd?
Beveiliging verondersteld ook het juiste omgang met bv password en dat ten minste af te schermen. Een executable is ook gewoon een bestand.
In dit geval is m.i. geen sprake van een beveiliging op z'n best obfuscatie.
In de Nederlandse juridische situatie maakt dat voor de strafbaarheid niet (meer) uit.
https://www.iusmentis.com/beveiliging/hacken/computercriminaliteit/computervredebreuk/
Gezien de veroordeling in Duitsland is daar voor strafbaarstelling ook geen hoge kwaliteit van beveiliging nodig .
Het is natuurlijk een heel lange discussie wanneer beveiliging 'goed genoeg is' om "beveiliging" genoemd te mogen worden.
(en ook nog tijdsafhankelijk - vandaag goed genoeg, na dinsdag "loopt achter in patches" )
20-01-2024, 11:10 door
Briolet
Door Anoniem:
Een Duitse beveiligingsonderzoeker is in Duitsland veroordeeld tot een boete van drieduizend euro wegens het vinden en rapporteren van een hardcoded wachtwoord in een databaseproduct, dat hij tijdens zijn onderzoek ook gebruikte om op de database in te loggen.
Ik ben zelf beveiligingsonderzoeker geweest, maar je dient al helemaal niet tijdens jouw onderzoek in te loggen dankzij een kwetsbaarheid of wachtwoord dat je hebt gevonden. Het ligt hier wel iets genuanceerder. Deze onderzoeker handelde in opdracht van een gebruiker van deze software die vond dat er teveel gelogd werd. Hij ziet dat er data naar de software leverancier gestuurd wordt. Dat is dus data van de klant en het lijkt mij zijn goede recht om te controleren of de software leverancier niet zelf veel te veel data opslaat.
Als je dan het wachtwoord leest waarmee hij bij de data van de klant kan komen, lijkt het mij nog steeds legitiem. Tot dan kan hij nog steeds denken dat dit een eigen wachtwoord van de klant is in wiens opdracht hij handelt. Pas na het inloggen ziet hij dat dit wachtwoord ook toegang geeft tot de data van alle klanten en waarschuwt de software leverancier. Ik lees nergens dat hij na de ontdekking uitgebreid is gaan kijken in de data van de andere klanten.
20-01-2024, 13:24 door
Anoniem
Door Briolet:
Het ligt hier wel iets genuanceerder. Deze onderzoeker handelde in opdracht van een gebruiker van deze software die vond dat er teveel gelogd werd. Hij ziet dat er data naar de software leverancier gestuurd wordt. Dat is dus data van de klant en het lijkt mij zijn goede recht om te controleren of de software leverancier niet zelf veel te veel data opslaat.
Door Anoniem:
Een Duitse beveiligingsonderzoeker is in Duitsland veroordeeld tot een boete van drieduizend euro wegens het vinden en rapporteren van een hardcoded wachtwoord in een databaseproduct, dat hij tijdens zijn onderzoek ook gebruikte om op de database in te loggen.
Ik ben zelf beveiligingsonderzoeker geweest, maar je dient al helemaal niet tijdens jouw onderzoek in te loggen dankzij een kwetsbaarheid of wachtwoord dat je hebt gevonden. Het ligt hier wel iets genuanceerder. Deze onderzoeker handelde in opdracht van een gebruiker van deze software die vond dat er teveel gelogd werd. Hij ziet dat er data naar de software leverancier gestuurd wordt. Dat is dus data van de klant en het lijkt mij zijn goede recht om te controleren of de software leverancier niet zelf veel te veel data opslaat.
Nou nee, inbreken om zelf te controleren is zeker NIET je goede recht.
De software reversen, of gewoon aan de client zijde kijken wat er gestuurd wordt zijn daarvoor genoeg .
De formele manier is contractuele afspraken, en als je heel belangrijk bent als klant audits oid afspreken.
(of andersom - leverancier die audit recht eist bij klant, zoals Oracle ).
Zelf maar gaan rondneuzen is niet je goede recht.
(Als je spullen bij shurguard opslaat mag je ook niet inbreken om te kijken of ze opletten)
Als je dan het wachtwoord leest waarmee hij bij de data van de klant kan komen, lijkt het mij nog steeds legitiem.
Het begint dan al glad ijs te worden. Het is NIET MEER het systeem van de klant waar de data staat.
Tot dan kan hij nog steeds denken dat dit een eigen wachtwoord van de klant is in wiens opdracht hij handelt. Pas na het inloggen ziet hij dat dit wachtwoord ook toegang geeft tot de data van alle klanten en waarschuwt de software leverancier. Ik lees nergens dat hij na de ontdekking uitgebreid is gaan kijken in de data van de andere klanten.
Uitgebreid is niet duidelijk , maar
De onderzoeker ontdekte verder dat de database niet alleen de gegevens bevatte van de klant voor wie hij het onderzoek deed, maar van alle klanten van Modern Solution.
Dat zal toch wel even gecontroleerd zijn en niet allleen gespeculeerd.
Je kunt zeggen dat de wet te strak is toegepast, maar ik denk wel dat naar de letter de programmeur net fout zat.
En - misschien - een beetje te bot gecommuniceerd zal hebben en eventueel op wat tenen gestaan heeft.
Qua 'cover your ass' - het lijkt er nogal op dat hij de 'pen test' en waarschuwing op eigen initiatief gedaan heeft.
Het was misschien voorzichtiger geweest om z'n werkgever/opdrachtgever ertussen te schuiven, en even een "ja kijk maar of dat password werkt" mailtje van een chef te krijgen , en de waarschuwing naar de software leverancier door de klant te laten sturen.
Ik gok dat dat als bliksemafleider om de formele verantwoordelijkheid meer/deels richting bedrijf wel effect gehad zou hebben.
[puur formeel - een werkgever kan je niet vrijwaren cq opdracht geven om de wet te overtreden , dat blijft eigen verantwoording . Speelt typisch voor chauffeurs en rijtijden/snelheids limiet ] .
Maar in zo'n twijfel geval - en waarbij de software leverancier dan (ook) een aanklacht jegens een klant zou moeten doen, en niet alleen naar een (zzp?) ITer denk ik dat zo'n briefje " het was in opdracht van de klant" wel helpt.
20-01-2024, 14:22 door
Anoniem
Je proeft de weerzin tegen full disclosure.
Als dat zo is, moeten we er rekening mee houden dat de positie van sjoemelaars weer versterkt wordt.
Als je weg wil komen met halfslachtige beveiliging, legt men je niet veel in de weg.
Kwalijke ontwikkelingen, maar het is al heel lang aan de gang.
Als dat zo is, moeten we er rekening mee houden dat de positie van sjoemelaars weer versterkt wordt.
Als je weg wil komen met halfslachtige beveiliging, legt men je niet veel in de weg.
Kwalijke ontwikkelingen, maar het is al heel lang aan de gang.
20-01-2024, 15:59 door
Anoniem
Maar als je het ontdekt en onder de pet houdt, kan je het gebruiken als cybercrimineel en statelijke acteur.
Twee klassenvan overtreders, die men feitelijk op gelijke voet kan beschouwen. Mag niet, edoch.
Alle anderen zijn klokkenluiders, eigen richting zoekers en bedreigers van de gevestigde orde van data versjacheraars.
Alle informatie die u deelt, kan dus later eventueel tegen u gebruikt worden.
U blijve vooral dom en onwetend, des te gemakkelijker valt er over u te heersen.
Daar zal voorlopig wel niet veel aan te veranderen zijn helaas.
luntrus
Twee klassenvan overtreders, die men feitelijk op gelijke voet kan beschouwen. Mag niet, edoch.
Alle anderen zijn klokkenluiders, eigen richting zoekers en bedreigers van de gevestigde orde van data versjacheraars.
Alle informatie die u deelt, kan dus later eventueel tegen u gebruikt worden.
U blijve vooral dom en onwetend, des te gemakkelijker valt er over u te heersen.
Daar zal voorlopig wel niet veel aan te veranderen zijn helaas.
luntrus
20-01-2024, 17:50 door
Anoniem
Door Anoniem: Zonder opzet geen misdrijf is een wat dubieuze generalisatie. Het is over het algemeen een verzachtende omstandigheid , maar zo generiek zou ik het niet stellen.
In de categorie doodslag e.a. kun je absoluut schuldig zijn aan een variant doodslag/dood door schuld (op basis van ernstige onvoorzichtheid , nonchalance e.d.) zonder dat er de *opzet* was tot iemands overlijden.
Je hebt gelijk dat er naast opzet ook schuld bestaat in het strafrecht.In de categorie doodslag e.a. kun je absoluut schuldig zijn aan een variant doodslag/dood door schuld (op basis van ernstige onvoorzichtheid , nonchalance e.d.) zonder dat er de *opzet* was tot iemands overlijden.
Vind je dat er sprake is van schuld als een programmeur die is ingehuurd om de oorzaak van overdadig veel logberichten te onderzoeken (en die dus geen beveiligingsonderzoeker is) pas beseft dat de gegevens die hij vond voor een databaseconnectie toegang geven tot meer dan alleen gegevens van zijn opdrachtgever, en op het moment dat dat duidelijk wordt goed reageert? Ik niet.
Ik denk wel dat hij naïef was, maar ik heb (helaas) zoveel naïviteit bij ontwikkelaars gezien in mijn leven op het gebied van beveiliging, maar bijvoorbeeld ook op het gebied van auteursrechten, dat dat me totaal niet verrast.
21-01-2024, 00:16 door
Anoniem
Door Anoniem:
Vind je dat er sprake is van schuld als een programmeur die is ingehuurd om de oorzaak van overdadig veel logberichten te onderzoeken (en die dus geen beveiligingsonderzoeker is) pas beseft dat de gegevens die hij vond voor een databaseconnectie toegang geven tot meer dan alleen gegevens van zijn opdrachtgever, en op het moment dat dat duidelijk wordt goed reageert? Ik niet.
Door Anoniem: Zonder opzet geen misdrijf is een wat dubieuze generalisatie. Het is over het algemeen een verzachtende omstandigheid , maar zo generiek zou ik het niet stellen.
In de categorie doodslag e.a. kun je absoluut schuldig zijn aan een variant doodslag/dood door schuld (op basis van ernstige onvoorzichtheid , nonchalance e.d.) zonder dat er de *opzet* was tot iemands overlijden.
Je hebt gelijk dat er naast opzet ook schuld bestaat in het strafrecht.In de categorie doodslag e.a. kun je absoluut schuldig zijn aan een variant doodslag/dood door schuld (op basis van ernstige onvoorzichtheid , nonchalance e.d.) zonder dat er de *opzet* was tot iemands overlijden.
Vind je dat er sprake is van schuld als een programmeur die is ingehuurd om de oorzaak van overdadig veel logberichten te onderzoeken (en die dus geen beveiligingsonderzoeker is) pas beseft dat de gegevens die hij vond voor een databaseconnectie toegang geven tot meer dan alleen gegevens van zijn opdrachtgever, en op het moment dat dat duidelijk wordt goed reageert? Ik niet.
Ik kan best van alles vinden, en ook speculeren hoe dingen mogelijk gegaan zijn. Ik ken het complete dossier niet, ben geen jurist, en al helemaal geen jurist in de Duitse wetgeving. Ik heb hooguit een redelijke natte vinger hoe dit soort dingen formeel kunnen uitpakken, en natuurlijk gewoon een mening op een forum.
Natuurlijk is er een grijs gebied tussen 'verboden terrein' en wanneer dat betreden wordt, en of iemand beter had kunnen of moeten weten, of dat er een hoger belang is waarom het toch maar achteraf goedgekeurd moet worden.
Uiteindelijk - de programmeer heeft iets als mysql -h <EEN.ANDER.DOMEIN.DAN.ZIJN.OPDRACHT.DE> ingetikt, en dat is waar het mijnenveld begint. En , ook voor een programmeur - wat voorzichtigheid in acties (en communicatie) aan te raden is.
En al helemaal als daarna bij queries het beeld verschijnt dat alle klanten toegankelijk zijn.
Dat de juridische context van pentesten niet z'n vakgebied is moge zo zijn - maar de wet niet kennen is geen vrijbrief.
Schuld heeft nogal een morele lading - maar ik sluit zeker niet uit dat hij inderdaad _schuldig_ is aan het overtreden van bepaalde specifieke wets artikelen , en de rechter niet genoeg reden vond om vrij te spreken, of schuldig verklaren zonder strafoplegging bijvoorbeeld.
Ik denk wel dat hij naïef was, maar ik heb (helaas) zoveel naïviteit bij ontwikkelaars gezien in mijn leven op het gebied van beveiliging, maar bijvoorbeeld ook op het gebied van auteursrechten, dat dat me totaal niet verrast.
Eerder (19 jan 13:24) heb ik ook in die richting gespeculeerd.
Het zou me zeker niet verbazen als hij in de 'melding' een heel verkeerde toon gebruikt heeft voor iemand die op glad ijs zit . (ik doe xyz op jullie server, ik zie alle klanten, als ik kwaadwillend was zou ik ABC kunnen doen , ik EIS onmiddelijke actie )
En het lijkt erop - en dat is opmerkelijk - dat hij voor werk in opdracht dan de "pentest" of 'rapportage' onder eigen vlag gedaan heeft, en niet via de opdrachtgever (en klant van de lekke leverancier) voor wie hij naar de logfiles keek.
We hebben in NL ook wel eens zaken hier zien langskomen waar een ongevraagde pentest feitelijk een afpersing werd (uit mijn hoofd) - we hebben dit gat gevonden, en we gaan het voor E <veel> repararen of anders maken we het publiek.
Stel dat hij bij de vulnerability melding ook meteen hard vroeg om een beloning (of een opdracht om het op te lossen) dan wordt het nog dubieuzer dan "naïef" .
Het voornaamste wat eenieder hier uit kan halen - scherp je 'natte vinger gevoel' voor wanneer je op juridisch twijfelachtig terrein zit goed aan voordat je acties - of communicatie - doet . En al helemaal als je een grote broek aan trekt .
Een hoop ITers hebben gewoon een wereldbeeld dat fors afwijkt van de werkelijkheid , vooral als het om informatie/publicatie/(prioriteit van) security gaat - en dat kan wel eens een heel koude douche worden als de zaken scherp gesteld worden.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?