Communityinterview met SchizoDuckie

'Ik kwam bij Philips binnen toen ik op de wc zat'

'Ik kwam bij Philips binnen toen ik op de wc zat'

Toen tweaker SchizoDuckie vorige maand de private keys van een Azure-adminomgeving van de Belastingdienst ontdekte in een openbare GitHub-repo, stond hij daar al een beetje van te kijken. Toen hij echter probeerde in te loggen én een fiscusmedewerker vervolgens de door hem opgevraagde mfa-prompt bevestigde, was dat toch wel een van de opvallendste keren dat hij bij bedrijven wist binnen te dringen. En dat lukt hem regelmatig. SchizoDuckie is van origine helemaal geen ethisch hacker. Toch doet hij regelmatig aan responsible disclosures op een whitehat-manier, alleen met heel simpele methoden. Het enige wat hij daarvoor doet, is in GitHub-repo's inloggegevens opzoeken die hem veel controle over systemen, netwerken, mailboxen en hele bedrijven kunnen geven. Hij noemt zichzelf daarom ook wel 'the lamest hacker you know'. Hoe lame hij ook zegt te zijn, hij komt opvallend vaak ergens binnen.

Je bent geen professionele hacker. Wat voor werk doe je?

"Ik werk bij een klein bedrijf in Delft dat automatisering doet voor het midden- en kleinbedrijf. Officieel ben ik daar programmeur, maar ik doe onder andere ook devops en alles wat daarbij komt kijken. Systeembeheer laat ik tegenwoordig vooral aan collega's over, maar als er webservers moeten worden ingericht, dan doe ik dat er soms ook nog bij. En ik monitor ons serverpark, zodat alle collega's lekker kunnen doorwerken."

Dat klinkt niet alsof je een specifieke infosec-achtergrond hebt of daar veel mee bezig bent. Hoe begin je dan toch met het zoeken van wachtwoorden?

"Dat begon een paar jaar geleden. Eigenlijk was het heel simpel. Als programmeur en nerd zit je veel op GitHub en kijk je op Twitter rond of je neust door wat forums. Toen zag ik een tweet voorbijkomen waarin iemand zei: 'Als je op deze en deze zoektermen zoekt, dan vind je zomaar wachtwoorden'. Dat ben ik toen gaan proberen, heel eenvoudig: ik zoek op GitHub naar 'bedrijfsnaam+wachtwoord'. Je slaat soms steil achterover van wat je dan tegenkomt en hoe snel je dat vindt. Ik wist eens bij Philips Medical binnen te dringen toen ik op de wc zat en even op GitHub een zoekopdracht deed. In de afgelopen jaren ben ik op die manier blijven werken. Ik heb zo inmiddels van meer dan 500 bedrijven de credentials gevonden om mee te kunnen inloggen."

Informatie over een (verlopen) certificaat dat SchizoDuckie online vond.

Heb je je werkwijze door de jaren heen ook veranderd?

"Nee, eigenlijk niet zo heel veel. Het blijft zoeken in zoekmachines en kijken of je ergens kunt inloggen. Ik ben er denk ik wel beter in geworden, ik vind steeds grotere dingen omdat ik nieuwe trucjes heb bedacht. Ik probeer bijvoorbeeld uit te zoeken waar de interne hostnames van bedrijven staan. Waar staan hun Jira-instance of GitLab-servers? Als je daarop gaat zoeken, kom je in negen van de tien gevallen interessante dingen tegen. Dan kun je bijvoorbeeld een netwerkmap van een hele infrastructuur maken. Of nog beter, die vind je soms gewoon ergens kant-en-klaar."

Dit blijft een 'hobby' voor je. Hoeveel tijd ben je er ongeveer aan kwijt?

Jelle Ursem

Nickname
SchizoDuckie

Herkomst Nickname
Laten we daar niet op in gaan :D

Hobby's
Houtbewerking, microquadcopters, micro-electronica, fotografie/Urban Exploring, Hacking the planet

Geboortedatum
Bouwjaar 1982

Op Tweakers sinds
April 2001, maar volgens mij hing ik al eerder rond

Favoriete onderdelen T.net
Frontpage

Studie
Ik mag koffie halen voor de systeembeheerders volgens m'n papiertjes

Beroep
Programmeur/Architect/Devops engineer

Smartphone
Galaxy S20, uiteraard geroot

Computer
Tricked out HP zBook van de zaak en stapels met laptops. Heb al 10 jaar geen desktop-pc meer aangezet, denk ik

Gameconsole
XBox One X, Wii, RG351M

Camera
EOS 40d, EOS 600d

Tablet
Vast wel ergens

Domotica
Geen commercieel iot-spul in mijn huis, maar m'n twee trappen gebruiken zes IP-adressen!

"Dat hangt er heel erg vanaf. Soms heb ik een avond niets te doen en zit ik op de bank een beetje op m'n laptop rond te klikken, maar ik heb er verder geen tijdslimiet op zitten. In sommige periodes ben ik er keihard mee bezig, andere keren probeer ik even wat meer op mezelf te letten. Het gaat met ups and downs.

Ik zie wel veel verschillen in hoe lang bedrijven met responsible disclosure bezig zijn. Je hebt bedrijfjes die een probleem drie uur nadat je ze belt al hebben gefixt, maar het komt vaker voor dat bedrijven helemaal niet te bereiken zijn. Dat is vooral zo bij Amerikaanse bedrijven waar je als iemand van overzee ineens naartoe belt. En met grotere bedrijven heb je soms ook de grootste problemen. Met Philips Medical ben ik wel een paar weken bezig geweest met over en weer mailen. Daarbij ging het ook om medische gegevens, dat maakt het lastig, maar dat was wel de meest dramatische procedure die ik heb meegemaakt."

Wat is het gekste dat je bent tegengekomen in die zoektocht?

"Even denken, ik ben de tel inmiddels kwijt, maar het gaat inmiddels al om meer dan 500 bedrijven waarbij ik iets heb gevonden. Het zijn vaak ook grote bedrijven; die herken je al aan de logo's. Het lijkt soms wel dat hoe groter het bedrijf is, hoe groter de kans dat ze ergens op internet hun gegevens laten uitlekken. En je kunt veel vinden. Persoonsgegevens, bankrekeningnummers, vpn-credentials: je kunt het zo gek niet bedenken.

Wat er onlangs bij de Belastingdienst gebeurde, was wel erg apart. Ik heb daarover getweet. Het kwam erop neer dat een medewerker admincredentials van Azure in een private GitLab-repo had staan. Toen ik ze probeerde, kon ik daar niet zomaar in omdat het systeem om multifactorauthenticatie vroeg. Maar toen ik dat aanvroeg, klikte de medewerker erop en kwam ik daadwerkelijk binnen in zijn systeem.

Ook wel apart: een van de repo's waarin ik iets heb gevonden, is mogelijk in de GitHub Arctic Code Vault terechtgekomen. Het ging om repo's waar een ontwikkelaar duizenden bestanden met medische diagnoses en persoonsgegevens in had laten staan. Ik kan dat alleen niet 100 procent verifiëren, want GitHub geeft die officiële lijst niet vrij."

Is het zo slecht gesteld met basic opsec? Waarom denk je dat het zo makkelijk is wachtwoorden zomaar online te vinden?

"Er zitten veel verschillen tussen incidenten. Soms gaat er iets mis door individuele gebruikers die een klein foutje maken, maar je komt ook medewerkers tegen die complete lijsten met wachtwoorden online zetten, of wachtwoorden waarmee je via Ansible hun hele serverpark kunt overnemen.

Toen ik in het vak begon, wist je dat je nooit wachtwoorden moest hardcoden in scripts. Niet dat dat toen nooit gebeurde, maar het lijkt soms alsof een grote groep programmeurs die lessen is vergeten.

Ik vind het heel lastig om te verklaren waar dat door komt. Wat ik inmiddels wel heb gezien, is dat hoe meer bedrijven restricties proberen af te dwingen met tools, hoe makkelijker medewerkers op zoek gaan naar een zijweg om hun werk toch te kunnen doen. Neem dat voorbeeld van de Belastingdienst. Dat was echt geen domme jongen, maar die zet gewoon even snel iets in een privérepository omdat hij verder wil met zijn dag. Trouwens, op GitHub is standaard iedere nieuwe repo publiek dus je moet heel bewust een vinkje zetten. Iedere kleine fout wordt anno 2022 bovendien keihard afgestraft door gasten als ik."

Wat doe je als je zo'n lek vindt? Ga je dan door het uitgebreide responsibledisclosurebeleid heen?

"Meestal begin ik met een mail opstellen. Dat is een concept waarin ik screenshots en logging opneem en beschrijf wat er aan de hand is. Ik probeer wel altijd te samplen wat ik in handen heb, dus hoe serieus een lek is. Het is belangrijk om te weten wat de dreiging is voordat je naar een bedrijf stapt. Als ik bijvoorbeeld een wachtwoord vind dat al is verlopen, dan ga ik dat niet melden. Daarmee verspil je ieders tijd en moeite. Hetzelfde geldt als je ergens binnenkomt, maar een foutmelding krijgt. Dat is minder serieus dan wanneer je een wachtwoord vindt waarmee je in Teams kunt inloggen.

Als ik iets meld, probeer ik altijd iemand aan de telefoon te krijgen. Ik wil niet iets in een inbox droppen en het daarbij laten. Als ik binnenkom in je systeem, is het ook serieus. Dan heb je niet te maken met een xss'je of zo, maar met iemand die in je servers kan. Dat brengt ook een bepaalde verantwoordelijkheid met zich mee. Als ik bijvoorbeeld in een SFTP-server kan, is het belangrijk dat een bedrijf mijn IP-adres weet en welke bestanden ik heb gedownload. Zo kunnen ze me uitsluiten uit hun logfiles."

Hoever ga je als je een lek zoekt?

"Voor mij houdt het op op het moment dat ik Metasploit of een andere hackingtool zou moeten installeren om verder te komen. Als ik ergens niet uit kom met mijn standaardwebbrowser of mijn FTP-client, ga ik het niet doen. Niet voor niets noem ik mezelf 'the lamest hacker you know'.

Dat is voor mij ook een goede beperking om geen grens over te gaan. Het is een grens voor mezelf; als je een goede, diepgaande scan uitvoert, kun je onbedoeld iets veranderen op een systeem. Ik ga niet op een server kijken of ik via RDP door een netwerk kan navigeren, omdat ik daar geen zin in heb, maar ook wel vanwege die grens. Je kunt er juridische problemen mee krijgen, omdat je dan met meer bezig bent dan alleen een probleem aanduiden. Kijk, als ik een FTP-server vind met daarop twee bestandjes van 2kB of 2MB, dan kijk ik wat er in dat laatste staat, dat is vaak toch interessanter. Ik ga niet die hele server leegtrekken, want dat gaat veel te ver.

Tot nu toe heb ik nog nooit een advocaat achter me aan gehad - even afkloppen. Ik heb wel met ze te maken gehad, maar dat was meer omdat ze wilden verifiëren dat ik data echt verwijderd had vanuit een compliance-standpunt. Als Europeaan heb je in het algemeen meer rechten dan Amerikanen hebben. Ik heb Amerikaanse vrienden die iets soortgelijks doen. Die raken medische gegevens echt niet aan, want dan worden ze helemaal kapotgemaakt met een aanklacht."

Je probeert het dus wel altijd zo 'responsible' mogelijk op te lossen.

Sommige bedrijven moet je heel simpel benaderen met 'hier is je probleem, dit is de oplossing'"Ja, maar dat doe ik niet altijd op dezelfde manier als wanneer ik het via een officieel programma als HackerOne zou laten lopen. Ik leg bedrijven geen eisen op, zoals dat ze een probleem binnen een bepaalde periode oplossen. Ik geef ze advies: zet deze servers dicht, haal deze repo's offline. Dat is vaak ook nodig; ik kom veel bedrijven tegen die nu en ook in de komende vijftien jaar geen responsibledisclosurebeleid hebben. Die moet je simpel benaderen: 'Hoi, hier is jullie probleem, dit is de oplossing.' Het heeft wel een paar jaar geduurd voordat ik daar de juiste toon in heb weten te vinden. Om diezelfde reden vraag ik ook nooit om een beloning. Ik zeg er altijd bij dat een bedankje fijn is om te krijgen, maar dat hoeft niet."

En dat enorme geldbedrag als beloning krijg je natuurlijk regelmatig, toch?

"Nadat ik laatst bij Philips Medical binnendrong, had ik echt veel gevonden. Als ik geen witte pet op had gehad, had hun hele broncode op het dark web kunnen staan. In ruil daarvoor kreeg ik een vermelding op de website. Nou, grote blij hoor! Meestal reageren bedrijven heel dankbaar. Soms krijg je ook rare verhalen te horen. Er was eens een bedrijf dat zich afvroeg waarom ze ineens zo'n hoge rekening hadden gekregen. Bleek er iemand allemaal server instances te hebben gestart in hun serverpark. 'Goed dat je belt; we snapten al niet waar dat vandaan kwam', zeiden ze toen.

Heel soms gaat het ook de andere kant op. Dan bel je een bedrijf en geloven ze je niet als je vertelt wat er aan de hand is. Of ze hangen boos de telefoon op. "Dat is niet van ons", zeggen ze dan als ik ze confronteer met m'n bevindingen. En het komt ook vaak voor dat bedrijven beloven iets leuks op te sturen, maar dat nooit doen."

Wil je dit ooit als werk gaan doen?

"Ik heb er weleens over getwijfeld; het speelt weleens door m'n hoofd. Als je dit echter professioneel gaat doen, moet je heel veel rapporten gaan schrijven en ik heb er al een hekel aan om documentatie voor m'n code te schrijven. Nu kun je dat wel automatiseren, maar ik weet het nog niet. Ik ben nu tegen de veertig en heb nog een kleine 25 jaar te gaan in m'n carrière; ik weet nog niet waar ik terecht ga komen."

Reacties (150)

[Orangelights23]

Het eerste gedeelte roept een vraag op: hij claimt een white hat hacker te zijn én hij probeerde in te loggen (wat ook nog gelukt is)? Menig ethisch hacker weet dat je dan al aangeklaagd kunt worden, het gaat immers om het wijzen op een kwetsbaarheid/lek, niet het misbruiken/exploiteren hiervan.

Voor de organisaties waar ik als security verantwoordelijke menig responsible disclosures heb geschreven en het beleid heb gevoerd, hebben we altijd expliciet beschreven dat daadwerkelijk toegang verkrijgen en/of het misbruiken van een lek/kwetsbaarheid niet is toegestaan.m, wat een beetje industriebreed het geval is.

[SchizoDuckie]

Het gaat om de intentie. Als jij ergens gaat inloggen met vanaf de eerste seconde de intentie om via Coordinated Vulnerability Disclosure je uiterste best te doen om een lekkend wachtwoord te melden bij een verantwoordelijke, zal er niemand bij het OM zijn tijd aan je willen verspillen:

Het Openbaar Ministerie vindt het belangrijk dat ethische hackers kwetsbaarheden kunnen blijven zoeken en melden zodat ICT-systemen veiliger kunnen worden gemaakt. We stimuleren organisaties om beleid over het melden van kwetsbaarheden in hun ICT-systemen vast te stellen in CVD beleid.

Het Openbaar Ministerie verwacht van ethische hackers dat zij zich in het CVD-beleid van een organisatie hebben verdiept of de ‘Leidraad Coordinated Vulnerability Disclosure’ van het Nationaal Cyber Security Centrum hebben geraadpleegd voordat zij starten met zoeken naar en melden van kwetsbaarheden.

Als aangifte wordt gedaan van het handelen van een ethische hacker door een organisatie die geen CVD beleid heeft, is dat voor het Openbaar Ministerie geen reden de ethische hacker direct als verdachte aan te merken. Er kan wel een onderzoek in worden gesteld om te kijken of er inderdaad sprake was van ethisch hacken. Bij de beoordeling om vervolging in te stellen tegen een ethisch hacker, zal de bijdrage die CVD levert aan een veilige digitale wereld zwaar wegen.

* https://www.om.nl/onderwe...sclosure---ethisch-hacken


Natuurlijk kan dit elders ter wereld anders zijn. Maar intentie en track record zijn goud waard.

[Reactie gewijzigd door SchizoDuckie op 22 juli 2024 19:15]

[Orangelights23]

Dat gaat specifiek om het beleid van de overheid, bedrijven hebben veelal ander beleid. Ik heb in genoeg security keukens gekeken en in werkgroepen en security committees in verschillende landen gezeten gekeken om te zien dat daadwerkelijk binnendringen tot vervolging kan komen. Gelukkig maar ook, want daadwerkelijk binnendringen is niet het doel van een ethisch hacker, alleen het aantonen hiervan.

Dus jouw comment gaat niet op in de praktijk.

[Reactie gewijzigd door Orangelights23 op 22 juli 2024 19:15]

[defixje]

Ik ben zelf Ethical Hacker, en heb keer op de Tweakers FP mogen staan, en deels heb je gelijk.

Maar voordat je bij een bedrijf aanbelt dat er een lek is, wil je er altijd zeker van zijn dat het ook daadwerkelijk een lek is anders verspil je teveel tijd. Een inlog verifiëren is in mijn ogen gewoon toelaatbaar zodra je er daarna geen misbruik van maakt.

Ik ben bij veel bedrijven binnen gekomen zowel in applicaties als direct op de servers en ik heb nog nooit een bedrijf meegemaakt die hier heel boos over werd, omdat ik altijd kon aantonen hoe ik aan die gegevens ben gekomen en dus de schuld niet bij mij ligt maar bij het bedrijf zelf.

Er is 1x politie langs de deur geweest toen ik een lek vond in een gemeente site (was een sql injection, dus database kon ik inzien) en ik hun daarover informeerde, geen reactie gekregen, half jaar later ineens politie aan de deur, dit scheen een normale procedure geweest te zijn omdat gemeentes dit verplicht zijn te melden. Is uiteindelijk met een sisser afgelopen en is het lek alsnog gedicht en heb ik mijn spullen weer teruggekregen.

[Nox]

Heeft de politie toen je huis leeg getrokken?

[defixje]

Ja alle gegevensdragers zijn toen inbeslag genomen voor onderzoek ja. Laptops en externe schijven en USB-drives.

Ben ze uiteindelijk 2 maanden kwijt geweest.

Edit: het was geen raid ofzo hoor, allemaal gemoedelijk gegaan omdat ik meewerkte met alles. Kreeg ook uitgelegd waarom het was. Verder heb ik op het politiebureau alles tot in de puntjes uitgelegd wat ik doe en zelfs referenties gegeven van bedrijven die heel blij waren met mijn werkwijze

[Reactie gewijzigd door defixje op 22 juli 2024 19:15]

[Nox]

2 maanden alle spullen kwijt, lekker dan. Je zal maar zzp'er zijn oid. Ga er vanuit dat je ook geen bestanden mocht overdragen.

[Tintel]

Malle wereld. De gemeente blundert en jij komt binnen. Net zoals dus de achterdeur van het gemeentehuis open laten staan. Als ze dan binnen betrappen - op heterdaad dus(!) dan mogen ze je idd vasthouden lijkt mij. Maar niet als je opbelt en zegt "je achterdeur staat open" en dan vervolgens komt de politie bij jou langs en halen ze jouw spullen weg...

Het binnendringen is wel een puntje. Het is zoiets als 'kijken of de deur open gaat" en opeens zwaait deze open. Ben je dan een inbreker? Ik denk toch dat menig bewoner dat wel zo zien. Ook al deed je het met de beste intenties.

[EwickeD]

huisvredebreuk, zegt die term je iets?

[Tintel]

Ja, daar doelde ik ook op. maar ik weet niet of dat automatisch doorgezet kan worden naar "inloggen met gevonden userid+password".

[EwickeD]

Lastig wel ja omdat de analogie met de fysieke wereld niet realistisch is denk ik.

Je vind toevallig een sleutel in de supermarkt met een labeltje er aan van welk huis die is.

Dan neem je aan dat het adres op het label klopt en breng je het naar de politie of je belt aan om aan te geven dat je dat ding gevonden hebt.

Dit huis blijkt een bedrijfspand en de receptioniste heeft geen idee welke sleutel dit eigenlijk is, dus moet je zelf op meer onderzoek uit, of je gooit het bij de digitale recherche...
Je bent echter niet toevallig in die supermarkt geweest waar je die sleutel vond, je bent op zich wel aan het zoeken geweest of er überhaupt een sleutel lag.

Mijn inziens is daarom de documentatie ook heel belangrijk omdat je daarmee de intentie aan kan tonen.

Heel eerlijk, als ik in mijn huis een briefje heb liggen dat mijn beleid is dat je niet ongeoorloofd mijn huis mag binnendringen, kan ik het je niet kwalijk nemen als ik mijn sleutels met een labeltje nota bene ergens heb laten slingeren.

De hele analogie gaat dan ook niet op, en een CVD is dan ook de grootste kolder lijkt me (niet mijn vakgebied overigens).

[Tintel]

Ik vond jouw voorbeeld juist wel een kloppende analogie.

Wat ook anders bij digitale toegang is dat niet bijgehouden kan worden of de huissleutel is verloren of niet. Dat is overigens de rode draad bij veel analogieen tussen fysieke wereld en ICT-systemen. Duplicaten zijn praktisch gratis te maken en ongemerkt. Diefstal van muziek/video/software is net zoiets. Is de eigenaar het kwijt dan? Nee.
Bij een toegangscode is dat net zo. De eigenaar heeft nog gewoon toegang en weet niet eens dat anderen ook toegang hebben. Maar bij een huissleutel is dat echt wel anders. Daar bestaat maar een beperkte set van en dupliceren kan alleen als het origineel ter beschikking wordt gesteld.
En juist omdat ze zo beperkt aanwezig zijn is het vinden van een sleutel met een adres eraan al voldoende om aan te nemen dat de sleutel werkt. Natuurlijk kan inmiddels het slot vervangen zijn. Maar de kans dat de sleutel nog werkt is gewoon vrij groot - dus controle is niet eens nodig.
Bij toegangscodes is de kans juist heel erg groot dat deze niet meer werkt. Het is bijzonder gemakkelijk om zelfs dagelijks het 'slot' te vervangen (dus het password zeg maar).

Dat CVD is idd een moeilijk verhaal. Want binnendringen blijft indringen en dat wil men nu juist niet.

[RoestVrijStaal]

Dus je zou in theorie ook je belastingaangifte o.i.d. niet kunnen doen, omdat je geen machine meer tot je beschikking hebt?

Dat de politie zomaar effe al je machinerie meeneemt, acht ik niet bij een normale procedure te horen. Ik heb het idee dat ze op zoek waren naar een stok om jou te slaan. Daarin faalden ze en nu heb je je spullen terug.

[Paultje3181]

"heb ik mijn spullen teruggekregen"
Zo te zien wel dus.

[Tha_Butcha]

Volgend wie was dat een normale procedure? De desbetreffende gemeente/politie, of staat dat ergens zwart op wit?

Want zon actie zou in mijn boekje staan als zware intimidatie. Zeker met de wetenschap dat de politie nogal eens slordige met data omgaat (zowel doe van anderen als van zichzelf)

[Gizz]

Bedrijven kunnen wel een ander beleid hebben, maar het OM bepaalt of tot vervolging wordt overgegaan en niet het bedrijf lijkt mij

[litebyte]

Exact, en dat tot vervolging overgaan in Nederland zal per bedrijf flink verschillen.

[Coolstart]

Ja zolang niemand een klacht neerlegt zal er geen onderzoek plaatsvinden. En waarom zouden ze, welk bedrijf wil er nu een vergrootglas op iets dat ze samen met tipgever onder de radar kunnen houden van justitie en publiek.

In het nieuws komen omdat uw broncode op straat ligt is geen goed nieuws.

[Rob Coops]

Aan tonen dat je binnen kunt dringen is niet echt mogelijk zonder binnen te komen.

Dat is als zeggen kijk daar is een deur, nou dat is dus niet veilig want ik kan binnen komen via die deur. Dat de deur een kluisduur is die beschermt tegen een atoombom is irrelevant want het is een deur en een manier om binnen te komen.

Dat is iets dat je nooit kunt verkopen ook bij een overheid niet. Het probleem is dat de meeste mensen die het beleid maken zelf weinig tot geen kennis hebben van hoe dit soort dingen werken en dat ze om die reden roepen je moet aan tonnen dat je iets kunt doen zonder het daadwerkelijk te doen.
Het aantonen dat het mogelijk is zo als je ziet bij bijvoorbeeld de Google groep die regelmatig bedrijven wijst op problemen met hun security is alleen mogelijk door ook daadwerkelijk een proof of concept te leveren. Wat zij doen met de 90 dagen om het probleem op te lossen zo niet geven zij de proof of concept vrij is een ander verhaal waar mensen over van mening verschillen maar dat is een ander verhaal. Zonder proof of concept is het heel erg moeilijk zo niet onmogelijk om aan te tonen dat er een probleem is.

Gelukkig zijn de meeste overheden en bedrijven inmiddels slim genoeg om te beseffen dat iemand die claimt de 100m in 10 seconde te kunnen rennen niet het zelfde is als iemand die bewijst dat ze dat kunnen doen.
Natuurlijk is er een groot verschil tussen bewijzen dat ik in kan loggen en inloggen en potentieel schade aan richten, data stelen en meer van dit soort dingen. Inloggen om aan te tonen dat het wachtwoord dat gevonden is in een publiekelijk beschikbare bron ook echt werkt en weer uitloggen is echt geen probleem omdat er totaal geen regels zijn overtreden. Zo lang het bij alleen het inloggen blijft en het netjes gemeld wordt is er helemaal niets dat de "hacker" fout heeft gedaan.

Het is een ander verhaal als iemand een brute force aanval uitvoert, social engineering toepast of bijvoorbeeld door middel van een andere aanval op de systemen de beveiliging weet te omzeilen. De truck is dat je dan met heel andere dingen bezig bent net het niet om publiekelijk beschikbare informatie gaat die gebruikt wordt. Dit is waar je kunt roepen dat zelfs het inloggen met gegevens die op zo'n manier verkregen zijn strafbaar kan zijn.
Maar proberen iemand te vervolgen omdat je ze de sleutels in je deur zagen hangen de deur open deden en de sleutels binnen neer leggen met een briefje er bij waar in ze uitleggen wat er gebeurt is dat is echt een heel ander verhaal.

[Verwijderd]

Je kan zelf wel beleid schrijven , maar of dat wettelijk dan ook zo is, is uiteraard weer een ander verhaal.
Ik zou niet weten of enkel inloggen op een extern netwerk strafbaar is. Zeker als die inlog gegevens openbaar via google en GitHub te vinden zijn

[Orangelights23]

Zoals @Bart ® schrijft, het is wettelijk strafbaar (anders is beleid ook niet uit te voeren natuurlijk). Zie het als een voordeur: als deze open staat, is dat nog geen uitnodiging om binnen te komen. Netjes aanbellen en melden dat de deur open staat is voldoende.

[Bor]

Je gaat veel te kort door de bocht:

Is ethisch hacken strafbaar?
Hacken is alleen strafbaar indien dit wederrechtelijk gebeurt. Indien computervredebreuk niet wederrechtelijk is, zal de rechter de hacker vrijspreken. In de praktijk wordt aangenomen dat – bijvoorbeeld – door ethisch hacken de wederrechtelijkheid kan komen te ontbreken.

Algemene uitgangspunten over ethisch hacken
Wil een ethisch hacker een beroep kunnen doen op het ontbreken van de wederrechtelijkheid van zijn inbraak, dan zal hij moeten voldoen aan drie voorwaarden:

1- Een wezenlijk maatschappelijk belang

Men kan alleen een beroep doen op de uitzondering voor ethisch hacken indien met het hacken een wezenlijk maatschappelijk belang wordt gediend.

2 – De eis van proportionaliteit

Deze eis stelt dat een hacker niet verder mag gaan dan noodzakelijk is om het lek aan te tonen. Zo is het bijvoorbeeld niet noodzakelijk om een hele database te kopiëren teneinde aan te tonen dat men toegang tot die database heeft verkregen.

3 – De eis van subsidiariteit

Deze eis stelt dat een hacker geen zware middelen mag gebruiken als minder vergaande middelen ook tot hetzelfde doel konden leiden. Deze eis is nauw verwant met de eis van subsidiariteit.

[Reactie gewijzigd door Bor op 22 juli 2024 19:15]

[aeon_flux]

De analogie gaat niet helemaal op, je weet pas of de gevonden sleutels passen als je deur(en) daar mee hebt proberen te openen.
Want de deur zat op slot en de sleutel hing zonder dat iemand dat wist voor iedereen heel makkelijk toegankelijk op het drukste plein van de stad onder een heel groot bord met de bedrijfsnaam en locatie van de voordeur.

Dan heb ik liever dat iemand de sleutel probeert en niets verkeerds doet en het bedrijf of politie verteld wat er aan de hand is ipv dat er iemand het bedrijf binnengaat en de boel leeg haalt, vernield, onderhands verkoopt of sloopt.

Het beleid wat je schets is dus eigenlijk alleen in het belang van de ITers die de fout maken de sleutel op een openbare plek te leggen (wij zijn niet fout! Die man met de illegaal verkregen sleutel is fout en hij moet op het schavot!) en in zijn geheel niet in het belang van het bedrijf, klanten en of gegevens.

Een reactie die je gelukkig steeds minder vaak ziet omdat die contra productief is.

[Bart ®]

Je redenatie is krom. Je weet uiteraard pas of de sleutel op de deur past als je ze probeert, maar het punt is dat je dat helemaal niet hoeft (hoort) te proberen. Je kunt de sleutel ook gewoon inleveren bij de eigenaar van de deur, en zeggen dat je een sleutel hebt gevonden die mogelijk/waarschijnlijk op de deur past. Zodra je de onrechtmatig verkregen sleutel in de deur steekt en hem omdraait, heb je een beveiliging omzeild, en ben je strafbaar, ongeacht je intenties.

Dat jij liever ziet dat iemand de sleutel zelf test, is voor de wet sowieso irrelevant. Dat het OM soepel met de wet omgaat als je de juiste intenties hebt, is goed, maar dat maakt de daad an sich niet minder in strijd met de wet.

[Bor]

Zodra je de onrechtmatig verkregen sleutel in de deur steekt en hem omdraait, heb je een beveiliging omzeild, en ben je strafbaar, ongeacht je intenties.

Zo zwart wit lijkt het helemaal niet in elkaar te steken. Zie ook mijn reactie hieronder. Zelfs over de stelling dat publiekelijk geplaatste credentials of een gevonden sleutel onrechtmatig verkregen zou zijn kan je discussiëren.

[Wizard]

Je weet uiteraard pas of de sleutel op de deur past als je ze probeert, maar het punt is dat je dat helemaal niet hoeft (hoort) te proberen. Je kunt de sleutel ook gewoon inleveren bij de eigenaar van de deur, en zeggen dat je een sleutel hebt gevonden die mogelijk/waarschijnlijk op de deur past.

Het probleem is dat als je hem inlevert bij de eigenaar van de deur dat je dan 9/10 keer te horen krijgt : Dat is een oude sleutel, die werkt niet meer hoor.
En dan probeer je hem 3 maanden voor de grap eens uit en dan blijkt hij nog steeds te werken, omdat de eigenaar de melding naast zich neergegooid heeft.

Been there, done that. Dat heeft nul effect.
Wil je dat men er iets mee doet dan moet je weten of hij werkt.

Anders kan ik ook wel een encyclopedie naar jou toesturen, met de melding dat je wachtwoord daar mogelijk instaat.

[Bor]

In het geval van gevonden credentials weet je niet of deze werken / de deur open staat. Ze hebben tot verificatie geen waarde.

[kodak]

Dat het geen waarde kan hebben wil niet zeggen dat het geen waarde heeft.
Het is daarbij redelijker om aan te nemen dat het wel waarde heeft: het zijn immers credentials en het feit dat iemand ze belangrijk genoeg lijkt te vinden om te willen testen geeft het al waarde. Het willen testen lijkt dus niet perse nodig, en zelfs onnodig. Het kan namelijk net zo goed getest worden door de verantwoordelijke van de credentials.

[Bart ®]

Het omzeilen van een beveiliging is strafbaar. Dus ja, enkel inloggen is dat ook, ongeacht hoe je aan de inloggegevens komt (tenzij je die rechtmatig gekregen hebt uiteraard, maar dan ben je ook geen beveiliging aan het omzeilen).

[MrFax]

Alleen is er geen beveiliging omzeild in technische termen.

[Bart ®]

Een inlog met wachtwoord is een beveiliging. Als je daarop inlogt met niet rechtmatig verkregen credentials, ben je die beveiliging aan het omzeilen.

[Reactie gewijzigd door Bart ® op 22 juli 2024 19:15]

[MrFax]

Als iemand jouw de MFA geeft, dan heeft diegene die de MFA code geeft jou toestemming gegeven om binnen te komen. De verantwoordelijke is op dat moment dus die medewerker die de code heeft gegeven. Ten minste, dat is dus jouw denkwijze.

[Reactie gewijzigd door MrFax op 22 juli 2024 19:15]

[SchizoDuckie]

Dan ga ik je een andere denk richting geven: Jouw auto wordt gestolen terwijl je de sleutels in het portier hebt laten zitten.
Denk je dat de verzekering jou gratis een nieuwe auto gaat geven?

[Bart ®]

Een verzekering gaat niet over de wet, een verzekering gaat over het contract wat jij met de verzekeraar afsluit . Een autodief die een auto steelt terwijl de sleutel nog in het slot zit, is volgens de wet nog steeds strafbaar, ook al keert jouw verzekering niets uit.

[laptopleon]

We willen allemaal altijd graag een zwart/wit antwoord, maar dat is niet altijd hoe de realiteit is.

Als een autodief tegenover de politie claimt dat hij toestemming van de eigenaar had en daarbij ook nog de sleutel kan laten zien – want zo kun je het verhaal ook vertellen – wordt het al een stuk lastiger om onomstotelijk te bewijzen dat hij de auto gestolen in plaats van meegekregen heeft. Als de dief en de eigenaar elkaar dan bijvoorbeeld ook nog blijken te kennen, wordt het voor politie/justitie al snel een welles/nietes verhaal, waar ze weinig mee kunnen.

[Bart ®]

De wet is heel zwart-wit. Wat voor verhaal een dief ook ophangt, het verandert niets aan de feiten: een auto stelen is strafbaar, ongeacht of de sleutel in het slot zit. Als de dief een rechter tegenkomt die heel dom of naief is, dan kan hij er misschien mee wegkomen. Het feit is en blijft echter strafbaar. Het verschil is dat niet elke strafbare situatie ook daadwerkelijk bestraft wordt.

[laptopleon]

De wet is vaak juist niet heel zwart/wit, helaas. Kijk maar naar garantietermijnen. Je hebt twee jaar garantie op ‘duurzame consumentengoederen’, maar waar die grens precies ligt, dat staat niet in de wet. Is een blender van € 15 ook nog een duurzaam product? € 35? € 75? Er zijn er ook van € 1000+

Na die twee jaar heb je nog steeds garantie maar geen recht meer op vervanging van het hele product. Maar wat dan wel?

Ook rechters moeten zich aan de regels houden. Die snappen heus wel dat die auto 99% kans gewoon gestolen is, maar bij een welles/nietes situatie kan er niet voldoende worden bewezen en wordt de zaak geseponeerd. Dit gebeurt regelmatig, juist omdat zelfs voor een officier van justitie het nog vaak onmogelijk is in te schatten hoe de rechter hier tegenaan kijkt, kortom: grijs gebied is.

[Bart ®]

Volgens mij hadden we het over wetgeving op het gebied van het omzeilen van beveiliging, niet over wetgeving op het gebied van garantie.

[MrFax]

Het was een voorbeeld denk ik. De wet zelf is vaak zwart wit, maar een rechter bepaalt uiteindelijk wat er met de wet gebeurt. Als een rechter iets onredelijk vindt, dan kan een wet dus opeens weggesmeten worden.

Als jij wilt bewijzen dat er daadwerkelijk een lek is, moet je wel inbreken, immers er kunnen bij veel lekken anti-exploit mechanismes zitten en security hardening. Een simpel voorbeeld is het niet kunnen inloggen met een bepaalde account buiten het interne netwerk om. Dat is een vorm van security hardening.

Zoals hierboven al gemeld is: het OM vervolgd mensen niet als ze kunnen bewijzen dat het om ethisch hacken gaat. Dat betekent dus alles wat je doet loggen en opnemen, en zodra je binnen bent, alleen bewijs verzamelen wat nodig en niet gevoelig is (zoals bijvoorbeeld een screenshot van de index page na het inloggen), en daarna gelijk wegwezen, want zodra je ergens langer in zit dan nodig, ben je wel strafbaar.

[Reactie gewijzigd door MrFax op 22 juli 2024 19:15]

[Tintel]

En de reden dat de verzekering niet uitkeert is omdat een andere regel is gebroken; namelijk zorgvuldig omgaan met de auto-sleutel. Echter gaat de vlieger niet altijd op (bij de verzekeraar) want als eerst de sleutels worden gestolen is het toch echt wel een auto-diefstal ook al heeft de dief de sleutel.

En gelukkig zegt de wet dat het diefstal is dat zou een aanknopingspunt kunnen geven bij een zaak tegen de verzekeraar die weigert uit te keren.

Overigens is verzekering een vervelende partij. Die probeert maar al te vaak de bewijslast om te draaien. "Inbraak is pas inbraak als er braaksporen zijn". Wat bij diefstal van sleutels of een goede lockpicker zeker niet zo hoeft te zijn. Allemaal om fraude te voorkomen welliswaar maar slaat ook nog wel eens door naar "het is beter voor de winst om zo weinig mogelijk uit te keren".

[D11]

Als de politie de auto met sleutels eerder vind kun je een bekeuring krijgen voor uitlokking ..

[Tachi]

En dat lijkt me vergelijkbaar als je inloggegevens op een openbare plek laat liggen.

[Bor]

Hoe verifieer je dan of het echt om een lek gaat en bijvoorbeeld niet om een false positive zoals niet werkende credentials? Er zit in mijn ogen een verschil tussen het verifiëren van een mogelijk lek / exploit en het misbruiken hiervan.

[Orangelights23]

In het ergste geval is het een false positive, niets aan de hand in dat geval. Elke organisatie met een dergelijk beleid heeft ook interne procedures om met dit soort meldingen op te gaan. Hoe dan ook is de organisatie/eigenar verantwoordelijk voor het verifiëren, een ethisch hacker is hierin alleen een melder.

[SchizoDuckie]

Als een organisatie überhaupt al een beleid heeft zijn ze al 90% verder dan de bulk van de bedrijven waar ik aangeklopt heb. Je moet al ergens > 100 man medewerkers hebben voor je überhaupt een security afdeling hebt. De meeste mensen die je initieel aan de lijn krijgt weten niet eens wat GitHub is, laat staan dat er een CISO in het bedrijf is.

[SchizoDuckie]

Als ik elk wachtwoord wat oud en verlopen is moest gaan melden had ik hier een dagtaak aan gehad en was niemand er iets mee opgeschoten. Zie het als alerts op je logging. False positives frustreren alleen maar.
En daarbij, en bot of een ransomware gang geeft geen zier om jouw Disclosure beleid, die ramt gewoon overal doorheen en dan is je hele bedrijf gelocked voor je het doorhebt.

De wereld is veranderd in een paar jaar.

[Bor]

Ik ben het helemaal met je eens. Los van de dagtaak is het pas een lek als de informatie klopt. Stellen dat de credentials proberen strafbaar is gaat veel te kort door de bocht en is veel te theoretisch bekeken.

[Blokker_1999]

En persoonlijk heb ik het moeilijk met zo een beleid. Pas op: als je zelfs maar inlogt dan komen wij achter je aan met alles wat we hebben en kunnen. Daarmee schrik je mensen met goede bedoelingen af terwijl diegene met slechte bedoelingen er eens mee lachen.

Want als ik een wachtwoord vind en dat gewoon meld dan heb je als bedrijf zo iets van: oei, das niet mooi. Moeten we eens corrigeren. Maar als je wel binnen mag en dan ziet dat je ineens de mogelijkheid hebt om eenvoudig andere dingen te vinden en verder door te dringen waarbij de veiligheid van alles op losse schroeven staat dan zal je als bedrijf ook sneller doorhebben dat je toch echt actie moet ondernemen.

Daarom dat ook ik de intentie belangrijker vind dan hoe ver men komt. Iemand die 1 record uit een database uitleest om te zien of het mogelijk is, is iets heel anders dan iemand die een hele database dumpt. Een hacker die 1 goedkoop item uit een webshop weet te bestellen zonder te betalen is iets anders dan een hacker die voor tienduizenden euro bestelt en achteraf gaat roepen dat hij white hat was en gewoon aan het testen was.

[Orangelights23]

Vervelend voor je dat je het persoonlijk niet met zo’n soort beleid hebt, maar voor organisaties kan de schade vele malen groter zijn. Daarnaast werken alle openbare bug bounty programma’s, zoals HackerOne, ook met dit beleid en dat werkt prima.

En waar je het in je tweede alinea over hebt, is het inhuren van cyberconsultants die onder meer penetratietesten uitvoeren. Dat is iets heel anders dan van buitenaf kijken waar lekken zitten, en waar je al gauw zo’n 130-150 euro per uur voor kunt betalen on een expert je interne beveiliging te laten testen. Dat toelaten binnen je responsible disclosure beleid is echt vragen om problemen.

Heel interessant om te lezen hoe de gemiddelde Tweaker denkt over dit soort situaties, het laat wel zien dat cybersecurity een apart vakgebied is en misschien niet helemaal overeenkomt met hoe de ‘gemiddelde IT’er’ denkt - uiteraard schrijf ik dit niet om tegen schenen te schoppen, maar in mijn jaren als CISO is het stukje communicatie altijd één van de leukste uitdagingen.

[Zoop]

Ik denk dat hier 2 uitersten zijn in de discussies, jouw ervaring als een CISO stopt je in 1 van de groepen.
Namelijk situatie: Er is een groot bedrijf met hun IT met een kwetsbaarheid erin, jij komt zoiets tegen, jij meld dat netjes zonder ook maar iets te proberen met die informatie. Het bedrijf heeft eigen een keurige IT afdeling en gaat aan de slag met deze melding.
Zo zou het horen te gaan, mits er competente mensen zitten van begin tot eind van dit traject.

Dan heb je de wazige bedrijven, de buurjongen heeft de website opgezet voor een mcdonalds voucher en een buskaart. De "it-er" is een gepensioneerde die maar wat aanhobbiet, geen idee/interesse/ervaring heeft met hackmeldingen.

Jij komt een ernstig lek tegen, talloze privegegevens zijn zo te pakken. Jij meld dat netjes. De beste man heeft geen idee waar je het over hebt/neemt het niet serieus/geeft er geen hol om. Vind jij dat je dan klaar bent, dat je alles gedaan heb wat je kon doen?

Wil je hier verder werk van maken, dan ontkom je er volgens mij niet aan om de exploit op zijn minst te bevestigen (dus uitproberen). Een voorbeeld aan deze man laten zien "kijk, dit zijn gegevens uit jouw db, doe er wat aan!" Zou je dit hoger willen brengen, wil zoiets serieus genomen worden, dan moet je toch kunnen laten zien dat dit inderdaad een serieus probleem is, en niet de zoveelste false-positive (hoevaak krijg je tegenwoordig wel geen "hoi ik ben een hacker en ik heb al je data, stuur mij bitcoins, or else!"-spammails).

Hoe dan ook, ik denk dat mensen die dit hiermee in hun professionele leven regelmatig mee te maken krijgen en daarmee dan ook in contact komt met andere professionals om dit soort zaken te melden/op te lossen, dat jij en deze mensen geloven in het systeem en dat daarom ook zullen verdedigen als de beste manier (de wet is het daarmee ook met je eens).

Dat het in de praktijk vaak heel anders uitpakt en vaak te maken heeft met incompetente mensen en beleid is de keerzijde van die munt. Mensen die met die kant regelmatig in contact komen zullen een hele andere mening over het process hebben dan jij, wat grofweg neerkomt op "het niet zo nauw nemen met de regeltjes als je maar resultaat boekt" en daar meestal ook wel mee wegkomen omdat de intentie en noodzaak duidelijk was.

[ACM]

Dat hangt er van af in hoeverre het 'doelwit' dat alsnog wel toelaat. Bijvoorbeeld via een 'Responsible Disclosure'-procedure.

Toegang verkrijgen lijkt me voor sommige bugs wel een beetje noodzakelijk om te bewijzen dat het inderdaad kon? Of anders gezegd; bij sommige bugs weet je pas dat het daadwerkelijk kwetsbaar is op het moment dat je toegang hebt gekregen.

Maar als je dan nadat je ineens een shell voor je hebt dan ook gaat zitten rondneuzen... dan wordt het een ander verhaal ja. En misbruik maken is per definitie verboden.

[FreakerTweaker]

Kan me niet vinden in je verhaal. Werk zelf al ruim 10 jaar in de cyber security en doe responsible disclosure meldingen oppakken ook.

Als de intentie goed is, zijn we alleen maar blij dat iemand de moeite heeft genomen om dit bij ons te melden! Dat iemand het heeft kunnen bevestigen door in te loggen en verder niks te doen is ok. Het liefst heb ik natuurlijk dat ze dat niet doen.

Maar goed, liever iemand met goede intenties die de credentials vindt en inlogt daarna vervolgens netjes een rapport voor je schrijft en naar je stuurt, zodat je het kunt fixen... dan iemand die de creds vindt en foute dingen ermee doet en je er maanden later zelf achter moet komen! Denk dat dit echt moet doordringen in veel van die bedrijven waar jij dan langskomt. Aan jou de eer om dat te veranderen ;-)

[Rataplan_]

En daarom hou ik de repositories op onze eigen storage... Just to be sure. Ik schrijf wel eens wataar niet genoeg programmeur om te snappen waarom je als commercieel bedrijf je code in een online publieke omgeving opslaat?

[Reactie gewijzigd door Rataplan_ op 22 juli 2024 19:15]

[SchizoDuckie]

Wat eigenlijk bijna altijd het geval is, is dat het bedrijf zelf zijn zaakjes wel netjes op orde heeft. Afgeschermde organisatie op GitHub of een eigen Gitlab die alleen privé te benaderen is, das standaard. Maar in bijna alle gevallen is er dan 1 bijdehante medewerker die zijn spullen wel "even" mee naar huis neemt en ze ff incheckt in een eigen of nieuw accountje op GitHub voor eenmalig gebruik.
Je kan je daar als bedrijf echt bijna niet tegen beschemen zonder zelf actief GitHub te scannen op je intellectuele eigendommen en interne hostnames.

[djwice]

Dat komt omdat de organisatie geen toegang geeft tot de code vanaf eigen devices. En dat de ontwikkelaar soms weken tot maanden moet wachten om een idee te kunnen testen in de corporate omgeving, waar dat thuis in een paar uurtjes of weekendje is gedaan.

Soms eisen bedrijven dat bijvoorbeeld Keys in een centrale kluis moeten worden opgeslagen. Een nieuwe key aanmaken of updaten kost dagen tot weken via een ticket systeem, geen api. De applicatie moet vaak dan worden verbonden aan het interne netwerk én een ip-adres op dat netwerk hebben. Het krijgen van een ip-adres kan weken en meerdere tickets en approval lagen kosten. Je moet dan aan de AD gaan hangen met je applicatie, anders mag je de key niet opvragen ... en waar sla je dat weer op.. etc. etc.

Stel je hebt een AWS serverless applicatie die normaal AWS SSM of KMS keys gebruikt via AIM kan alleen de IAM infra laag van je app kan er bij, je app leest de key niet en de key wordt automatisch gegenereerd buiten je code om.

Mijn indruk is dat beter te beheersen dan een centrale Vault op het interne netwerk met AD authenticatie. Toch zijn er bedrijven die Vault vereisen voor die app.

En even zo: test iets nieuws: kan intern niet of kost maanden doorlooptijd en tig overleggen met mensen die traditioneel denken. Test het in je privé omgeving in een paar uurtjes en je weet het.

Bedrijven zouden er goed aan doen meer test ruimte in niet traditionele zin en meer omgeving native beleid te ondersteunen.

En ontwikkelaars makkelijk vanuit privé omgeving veilige toegang te geven tot de code. Anders zei je juist meer uitwijk gedrag omdat mensen worden belemmerd hun werk te doen.

Maar inderdaad ik zie ook vaak dat zelfs senior medewerkers toch denken dat ze een kopie moeten maken van een interne api-key en de API open zetten naar buiten, zodat ze ook zonder in te loggen op VPN vanaf hun privé mobiel even iets kunnen regelen voor de opdrachtgever.
Of dat voorbeeld code van een leverancier een mens om een vast te leggen key vraagt in plaats van er een genereert.
Of dat als een bedrijf een emailadres opgeeft voor security issues, dat je na een week nog niet eens een ontvangstbevestiging krijgt.

De wereld is in geen zins perfect.

[Reactie gewijzigd door djwice op 22 juli 2024 19:15]

[GrooV]

Tja heb het zelf nooit gedaan maar vaak zat gezien dat collega’s “slimme” manieren hadden bedacht om dit soort dingen te omzeilen. Hoe meer policies hoe creatiever mensen worden.

Maar goed, het toppunt was wel een externe collega die een keygen gebruikte en op de netwerk schijf zette bij een miljoenen bedrijf en hij was er nog trots op was ook want een licentie kopen duurde weken.

Je moet een balans zien te vinden tussen gemak en beveiliging. En niet denken als je het maar intern zet dat het dan automatisch veiliger is

[closefuture]

Ik snap niet helemaal hoe het vinden van "Informatie over een (verlopen) certificaat dat SchizoDuckie online vond." iets aantoont? Als je een certificaat van Google wilt kun je dat gewoon inzien via je browser als je op google.com zit.

Een certificaat zonder de bijbehorende private key (ie. waarvan de public key in het certificaat zit) is niks waard. Sterker nog het certificaat word juist zo wijd mogelijk verspreid. Een certificaat is letterlijk de certificering door een vertrouwde partij dat de public key van persoon X wat waard is.

[SchizoDuckie]

Iets te kort door de bocht zeker bij deze repository.
Dit certificaat is het server certificaat van een dingetje wat verbinding maakt met de US DoD. Het vertelt je welke encryptie schemes er geaccepteerd worden, wat de Acceptable client certificate CA names zijn, etc.

Lijkt me best interessante informatie voor APT groups.

[Reactie gewijzigd door SchizoDuckie op 22 juli 2024 19:15]

[closefuture]

Dit certificaat is het server certificaat van een dingetje wat verbinding maakt met de US DoD. Het vertelt je welke encryptie schemes er geaccepteerd worden, wat de Acceptable client certificate CA names zijn, etc.

Bij mTLS staan de client certificates die geaccepteerd worden e.d. niet in het server certificaat. Dat is geconfigureerd in de aan de serverkant en word bij TLS door de server verteld aan de client zodra er connectie gemaakt word.

Wat je ziet in de screenshot is ook niet het server certificaat maar de output van een OpenSSL command zoals: "openssl s_client -showcerts -connect google.com:443". Dat je daar ook het server certificaat en informatie zoals namen van geaccepteerde client CA's is logisch want dat maakt onderdeel uit van het TLS protocol. Iedereen die met die server kan connecten kan die informatie dus altijd zien.

En ook al zou dit gaan om gegevens van een interne server dan nog zal waarschijnlijk niemand dit als geheime informatie zien. De DoD heeft regels waarin staat welke encryptie, ciphers, etc. ze moeten gebruiken. Maar los daarvan ook voor organisaties die dat niet specificieren word die niet als geheime informatie gezien. Ook voor bijvoorbeeld voor een protocol als SSH beschouwen we de geaccepteerde authenticatie methode, geaccepteerde ciphers, etc. niet als geheim.

Dat is gewoon teveel "security through obscurity".

[SchizoDuckie]

Inderdaad, did het voorbeeld is echt niet heel erg spannend. Maar wat er achter zit en in die repository staat geeft wel veel te veel vrij over hoe de DoD zijn zaakjes intern regelt. Dat kun je "security through obscurity" noemen, maar in de informatie beveiliging wereld noemen we dat gewoon "bad opsec"

[Reactie gewijzigd door SchizoDuckie op 22 juli 2024 19:15]

[closefuture]

Inderdaad, did het voorbeeld is echt niet heel erg spannend. Maar wat er achter zit en in die repository staat geeft wel veel te veel vrij over hoe de DoD zijn zaakjes intern regelt. Dat kun je "security through obscurity" noemen, maar in de informatie beveiliging wereld noemen we dat gewoon "bad opsec"

Ik stel dat het proberen geheim te houden van TLS settings, SSH settings, etc. die iedere server publiek adverteert naar iedereen die ook maar connect "security through obscurity" is.

Vervolgens trek jij dat opeens veel breder met: "Maar wat er achter zit en in die repository staat geeft wel veel te veel vrij over hoe de DoD zijn zaakjes intern regelt." en ga je verder met "Dat kun je "security through obscurity" noemen". Dat stel ik dus helemaal nergens en een dergelijike verdraaiing van woorden vind ik nogal bad-faith.

[SchizoDuckie]

Oh uh okay? Sorry dat je je aangevallen voelt. Dat was niet mijn bedoeling, ik probeer context te scheppen.

[TijsZonderH]

Dat kun je mij meer aanrekenen, ik zocht gewoon wat beeldopvulling en vond deze er wel interessant uit zien, zonder te veel aan de context te denken. Had inderdaad beter gekunnen.

[E-Flex]

Wel schrikken dat een slimme gozer die dit voor de hobby doet zover komt....

[SchizoDuckie]

Helemaal als je je realiseert dat ik lang niet de enige ben die dit doet. Er zijn nog duizenden andere mensen met verschillende kleuren petten op over de hele wereld bezig.. That's what scares me..

[E-Flex]

Ja precies, soms voltijd en getraind, scary shit.

Bedankt voor je verhaal!

[pasz]

Denk dat de meeste ontwikkelaars dit wel kunnen, maar niet eens de tijd nemen om aan te tonen dat de beveiliging van hun eigen bedrijf niet heel goed in elkaar zit. Laat staan die van anderen.

Ervaringen van @SchizoDuckie komen me bekend voor en dan vooral de negatieve.

Daarom grote respect dat je dit doet @SchizoDuckie . En knap dat je de goede toon hebt gevonden. Is toch iets wat bij veel bedrijven heel lastig is.

[svennd]

Opletten voor de Belgen, inloggen op een extern bedrijf (zoals beschreven) wordt aanzien als hacken en is strafbaar. Je hebt geen enkele bescherming! Nog erger : zelfs poging tot is strafbaar.

De wet hier zorgt bij professionals voor kopzorgen...

[Orangelights23]

Is praktisch wereldwijd het geval, niet alleen voor Belgen. Ligt natuurlijk ook aan de organisatie waar je een kwetsbaarheid vindt. Zo heeft een Amerikaanse journalist (volgens mij) wachtwoorden gevonden in broncode van een website van een overheidsorgaan, de journalist heeft een dikke claim aan zijn broek hangen

[SchizoDuckie]

Aah, dat is de reden dat ik nooit meer iets gehoord heb van dat Belgische advocatenkantoor waar ik melding maakte dat in Office365 kon inloggen en dossiers kon bekijken... Ghosted en wachtwoord gewijzigd. You're welcome

[belgianmadcow]

Bijzonder knap als iemand en de skills heeft om dergelijke kwetsbaarheden te vinden én de integriteit om ze niet uit te buiten.

@SchizoDuckie , wat ik héél erg vreemd vind: dit is toch bijzonder waardevolle informatie, ik zou echt denken dat bedrijven hiervoor méér dan een bedankje sturen - zodat je eerder uitkomt op "ik kan hier (goed) van leven"! Neen dus?

[SchizoDuckie]

Haha nee, was het maar zo. Ik heb echt wel leuke goodies gekregen hoor, tshirts, swag, bierpakketten, gift cards etcetera, maar omdat je dit compleet onuitgenodigd doet kun je niet zomaar een rekening gaan sturen of rekenen op een steady stroom aan inkomsten. Dan zou ik snel dakloos zijn.

Ik zie het dan ook voornamelijk als een manier om goede karma te collecteren en als er dan ook nog wat er extra komt is het leuk meegenomen. Soms steekt dat als je iets heel heftigs vindt (grote blij) maar that's part of the game.

[belgianmadcow]

Goeie karma collecteren is ook een prima reden. Het moet zijn dat je dit graag doet ook
En dat ware begrijpelijk. Soms ben ik ook maniakaal / nerdy bezig met wat uitzoeken, en geniet daarvan zonder meer.

[SirRosencrantz]

Het is niet voor niets een running gag in de infosec-community dat Red Bull responsible disclosure/bug bounties uitbetaalt in blikjes Red Bull, toch?

[Stufipower]

Leuk om te lezen. Ik vind wel dat bedrijven hier heel dankbaar mee moeten omgaan. Ze waren echt de pineut geweest als iemand kwaadwillend was.

En wbt de trappen: nu moet ik thuis ook zulke trappen hebben. Nòg een project

[SchizoDuckie]

Sorry
Ik ben bezig aan een uitgebreide writeup met instructies voor de trapleds!

[Reactie gewijzigd door SchizoDuckie op 22 juli 2024 19:15]

[Woy]

Heb je een short-versie over hoe het in elkaar zit? Welke sensoren, en wat voor aansturing?

[SchizoDuckie]

Time Of Flight sensoren die aan een heel simpele ESP8266 zitten zitten aan de onderkant en bovenkant van elke trap, en blaffen hun sensor reading naar MQTT.
Elke trap draait een raspi zero W met een mqtt host en nodejs, en bestuurt 2 PCA9685 bordjes die elk 16 poorten kunnen PWM'en.

Vanaf daar is het vooral heel veel UTP kabel en heel veel javascript

[Woy]

Netjes, enige vraag die bij mij opkomt is waarom je hiervoor javascript gekozen hebt

[SchizoDuckie]

Ik was eerst bezig op een esp32, maar toen wilde ik mn animation engine schrijven zodat ik effecten op een timeline kan renderen en daar een web UI bij die je met xhr kan controllen en dan voelt het in Arduino IDE al heel snel of je terug in 1998 beland bent en geen idee hebt wat je doet. Ik heb ook niet genoeg embedded C skills om dat memory leak free te bouwen dus ik besloot om terug te vallen op wat ik wel van binnen en buiten ken. In 2 dagen de hele meuk geport naar node en de engine die in mn hoofd zat ingeklopt. En it works

[Reactie gewijzigd door SchizoDuckie op 22 juli 2024 19:15]

[Kabouterplop01]

Heel tof verhaal en toffe gast als ik het zo lees.
Voor de witte hoed en de manier waarop hij te werk gaat niets dan respect.

En de mensen die de fouten hebben veroorzaakt die hij vindt... manmanman
"Hoe krijg je de onverschilligheid en onwetendheid uit dat soort lui?"

[SchizoDuckie]

Da's een beetje de reden dat ik iets meer publiciteit aan het zoeken ben de laatste tijd. "Awareness".
Als meer mensen zich bewust worden van het feit dat dit probleem bestaat doordat ze mijn voorbeeldjes gelezen hebben, misschien gaan ze dan iets beter nadenken over wat ze zelf beter kunnen doen.
Althans, dat is mijn hoop.

[Kabouterplop01]

Aan de andere kant moeten ze niet te veel perfect doen he, anders ben je je hobby kwijt.
Misschien leuk projectje om de programmeurs te leren om niet dit soort informatiebeveiligingsfouten te maken. Dan heb je je eigen Awareness programma.
(Tenzij je dat niet leuk vind natuurlijk )
Mij lijkt het heel tof (beroepsmatig) om te zien hoe je dat doet. Of je dat bijv doet met scripts, (je bent nl. een progger) of hoe het is gegroeid hoe je het doet zoals je dat doet. Handmatig of automatisch speuren.
Zoals je met de informatie omgaat kunnen heel wat beveiligings onderzoekers nog wat van leren, (imho) zoals het heurt, ethisch!

[SchizoDuckie]

Het zou echt fantastisch zijn als deze hele hobby zichzelf opheft, seriously! Ik ben ook in gesprek met de manager developer relations van GitHub om daar wat meer proactieve beveiliging tegen dit soort dingen in gang te zetten, maar dat is nogal een klusje met zoveel code.

Al het zoekwerk wat ik doe is nog steeds handwerk. Zelfs na 25 jaar programmeren kan ik me nog steeds niet voorstellen hoe ik dit goed zou kunnen automatiseren, al borrelen er wel plannen voor wat recon tooling in mn hoofd.

Qua awareness, ik ben letterlijk sinds gisteren aangesloten bij de DIVD en daar zijn heel goeie dingen aan het gebeuren, dus to be continued!

[Kabouterplop01]

[Afwezig]

Leuk verhaal! Zou toch ook denk dat wanneer het zo makkelijk te vinden is, dat dit ook geldt voor kwaadwillenden uit bijvoorbeeld het buitenland (bijvoorbeeld diefstal van intellectueel eigendom)

[SchizoDuckie]

De overlap met ransomware is groot.
Als ik ga zoeken na een nieuwsbericht dat $bedrijf_x geransomwared is, is het niet zeldzaam om dingen te vinden waarvan ik denk: "Mjah, als je dat hebt ben je met 1 phishing mailtje of 1 klein foutje overal binnen ja"

[Ulysses]

Wat een leuk artikel om zo "the lamest hacker you know" te leren kennen. Goed bouwjaar en wat een leuke voornaam. Aangenaam.

[Iblies]

Eigenlijk is het bouwjaar 9 maanden eerder 🤐

[surfin]

Bouwjaar is het moment dat het van de productielijn rolt toch?

[aadje93]

lekker off topic, maar bouwjaar is het jaar/datum dat een product van de band rolt. Niet wanneer het eerste schroefje geperst is.