GitHub versus securityonderzoekers

Op zoek naar de toelaatbaarheid van malware

GitHub versus securityonderzoekers: op zoek naar de toelaatbaarheid van malware

GitHub is de afgelopen jaren een waardevolle bron geworden voor beveiligingsonderzoekers, maar de laatste tijd ontstaan er steeds meer scheurtjes in die symbiotische relatie. Het platform moet nu nadenken over fundamentele vragen over het plaatsen van malware.

In maart van dit jaar kwam GitHub onder vuur te liggen bij beveiligingsonderzoekers. Dat gebeurde nadat de Vietnamese beveiligingsonderzoeker Nguyen Jang een proof-of-concept op GitHub had gezet voor een exploit rondom vier ernstige kwetsbaarheden in Exchange. De vier kwetsbaarheden waren zerodays, die volgens Microsoft werden misbruikt door Chinese hackers die er bedrijven mee bespioneerden.

Waarschuwingen

De Exchange-kwetsbaarheden leidden tot veel rumoer in de securitywereld. Wereldwijd waarschuwden officiële instanties voor de gevolgen voor bedrijven als die de kwetsbaarheden, die samen de naam ProxyLogon kregen, niet zouden patchen. In Nederland deed onder andere het Nationaal Cyber Security Centrum dat. "De gevolgen van de kwetsbaarheden in Exchange zijn groot voor Nederlandse organisaties en bedrijven", schreef de instantie, die stelt dat de kwetsbaarheid kan leiden tot datadiefstal, malware, achterdeurtjes en gestolen mailboxen. In de waarschuwing noemt het NCSC ook expliciet het proof-of-concept dat een week daarvoor online werd gezet. "Hierin staat op welke manier misbruik gemaakt kan worden van de kwetsbaarheden. Kwaadwillenden kunnen dit gebruiken om digitale aanvallen uit te voeren."

Dat proof-of-concept, of PoC, bleek kort daarna een splijtzwam te worden voor beveiligingsonderzoekers. Jang zette het op GitHub om andere beveiligingsonderzoekers te informeren, al veranderde hij de code wel zodat die niet makkelijk in de praktijk te gebruiken was. Dat maakte niet uit. GitHub verwijderde de code een paar uur na publicatie. Het bedrijf bevestigde dat aan Motherboard: "We begrijpen dat het publiceren en verspreiden van de proof-of-concept van de exploit educatieve en onderzoekswaarde heeft. Ons doel is om dat te balanceren met het veilig houden ons platform", zei GitHub.

Ethische kwestie

En dus verdween de code van GitHub, dat sinds 2017 in handen is van Microsoft. Al snel daarna kwamen fundamentele vragen op. Want het is wel erg toevallig dat GitHub uitgerekend deze malware verwijdert, dat betrekking heeft op kwetsbaarheden in een Microsoft-product. Veel andere malware-PoC's op GitHub kunnen worden gebruikt om flinke schade te doen aan bedrijven, maar die blijven vaak gewoon staan. Maakte Microsoft deze beslissing echt in het algemeen belang, of vooral voor dat van het bedrijf zelf?

Securityonderzoekers hebben soms verschillende meningen over het publiceren van malware-PoC'sOnder securityprofessionals ontstond al snel discussie over de ethiek van het publiceren van malware. De algemene concensus: dat moet kunnen, maar onder voorwaarden. Sommige onderzoekers zijn bijvoorbeeld van mening dat malware pas gepubliceerd moet worden als er een patch is uitgebracht voor een kwetsbaarheid. Het is al vaker voorgekomen dat bewijs van een kwetsbaarheid openbaar is gemaakt uit onvrede over de scope van een responsibledisclosurebeleid, maar dat zijn uitzonderingsgevallen. De meeste ethisch hackers wachten tot er een definitieve patch beschikbaar voor ze erover publiceren, een cruciaal onderdeel van responsibledisclosurerichtlijnen. Dat stelde ook Dave Kennedy van securitybedrijf TrustedSec. Volgens die logica had Jang de code best kunnen publiceren, want dat gebeurde nadat Microsoft de ProxyLogon-patch had uitgebracht. Tegelijkertijd weet menig systeembeheerder hoe dat gaat met patches. Die worden lang niet altijd tijdig geïnstalleerd - op het moment dat Jang zijn PoC uitbracht waren naar schatting de helft van de kwetsbare servers nog niet gepatcht, en naar alle waarschijnlijkheid zijn er nu ook nog genoeg kwetsbare servers te vinden.

Toegankelijkheid van PoC's

Sommige beveiligingsonderzoekers en pentesters waar Tweakers mee sprak stellen dan ook dat onderzoekers bij het plaatsen van PoC's altijd een afweging zouden moeten maken. Daarbij zouden ze de potentiële schade van een exploit kunnen meenemen, of de ernst ervan; een remote code execution is bijvoorbeeld een stuk gevaarlijker dan een privilege escalation of een denial-of-service-aanval. "Enerzijds wil je voor de credits natuurlijk de eerste zijn met een bepaalde PoC", zegt redteamer Cas van Cooten die ook privé een paar PoC's op zijn GitHub-pagina heeft gezet. "Maar anderzijds wil je niet degene zijn waarvan de exploit code as-is over het hele internet wordt gesprayd." Een andere belangrijke afweging is hoe toegankelijk je PoC's maakt voor de gemiddelde gebruiker of hacker.

Sommige proofs-of-concept worden bewust onbruikbaar gemaaktEen proof-of-concept is uiteraard niet hetzelfde als een actieve exploit. Een PoC is alleen het bewijs dat een exploit zou werken zonder ook echt schade aan te brengen aan een systeem. De manier waarop onderzoekers dat kunnen doen verschilt. Soms maken ze bijvoorbeeld alleen een video waarin staat hoe ze iets kunnen uitvoeren maar vervolgens alleen de Rekenmachine in Windows openen. In andere gevallen delen ze ook de code zelf. In dat geval is het de truc om de code zo te obfusceren dat belangrijke praktische aspecten eruit wegblijven, vertellen beveiligingsonderzoekers die wel eens PoC's publiceren. "Vaak wordt het bewust bij PoC's gehouden, enkel om een techniek aan te tonen", zegt Van Cooten. "Dan heb je alsnog je eigen exploit of andere technieken nodig om het in de praktijk toe te passen." Er is dan een andere kwetsbaarheid naast nodig, bijvoorbeeld een privilege escalation. Andere onderzoekers publiceren alleen code waarvan ze weten dat niet iedereen die een-op-een kan overnemen. Malware-makers moeten dan altijd nog zelf de code compilen en dat is voor sommige aanvallen te veel moeite. Dat nuanceert Van Cooten wel een beetje: "Als je .sln bestanden in Visual Studio opent kun je eigenlijk ook gewoon dubbelklikken zodat er een .exe uit komt rollen. Dat kunnen de meeste mensen wel."

'Script kiddie-gebied'

Belangrijk om te weten is dat de PoC die Nguyen Jang uitbracht ook niet out-of-the-box werkte. Hij had de malware dusdanig aangepast dat die niet werkte als een gebruiker het inzette, waardoor het programma meteen zou crashen. Wel beschreef hij, in het Vietnamees, in een blogpost hoe hij bij de exploit terecht was gekomen. Een hacker met goede skills - en Google Translate - had met Jangs blogpost en proof-of-concept ongetwijfeld wel malware kunnen maken om kwetsbare Exchange-servers aan te vallen, maar dat was niet weggelegd voor iedereen die 'hoe hack ik het mainframe' moet googelen. Deze week publiceerde Jang echter weer wel een PoC van de exploit van CVE-2021-28482. Dat is een andere kwetsbaarheid binnen ProxyLogon, maar de nieuwe exploit is alleen uit te buiten als een aanvaller al op een systeem is binnengedrongen. Dat is anders dan bij zijn eerste exploit, waarbij het mogelijk was op grote schaal naar kwetsbare servers te scannen en die binnen te dringen.

Bij Jangs nieuwe PoC is het al een stuk makkelijker die in de praktijk uit te buiten, merkt beveiligingsonderzoeker Will Dormann op tegen BleepingComputer. "We komen nu in script kiddie-gebied", zegt hij. Met andere woorden: zelfs mensen zonder diepgaande hackingskills kunnen dergelijke exploits inzetten. Daardoor komt opnieuw de vraag op of de kwetsbaarheid moet zijn toegestaan op GitHub.

Metasploit

In het algemeen kun je vraagtekens zetten bij het bannen van software, uitgerekend op een platform dat gemaakt is om code te delen. Zelfs als GitHub nu weer zou optreden tegen Jangs PoC zou het dat ook al moeten doen tegen de 26 forks die er inmiddels zijn gemaakt. Het is maar de vraag of je daartegen kunt optreden, zelfs geautomatiseerd.

Maar dat het rommelt tussen GitHub en beveiligingsonderzoekers is niet iets van de afgelopen week. In het algemeen is de hele discussie over het publiceren van malwarecode voor onderzoeksdoelen niet nieuw. Inmiddels zijn tools zoals Metasploit en Mimikatz niet alleen gemeengoed geworden, ze zijn zelfs een onmisbaar onderdeel voor pentesters. Metasploit en Mimikatz bevatten zelf ook gewoon manieren om simpele exploits in te zetten, en dat is al jaren het geval. Soms is het verschil tussen beveiligingsonderzoek en misbruik overduidelijk; bekende malwaregroepen die GitHub gebruiken voor campagnes, daarover is geen twijfel. Die moeten van het platform af. Maar in veel andere gevallen ligt dat genuanceerder. De kritiek die nu op GitHub komt draait dan niet om de vraag óf exploits openbaar moeten worden, maar wie de grens daarover bepaalt. Is dat de brede gemeenschap van securityprofessionals, of toch GitHub?

Tools zoals Metasploit worden al jaren gebruikt voor malware-onderzoek en pentesting.

Auteursrechten

De kritiek op GitHub gaat niet alleen om securityissues, maar ook om hele andere zaken. Ook vorig jaar was er ophef toen GitHub de bekende tool youtube-dl offline haalde. Dat gebeurde na een auteursrechtenclaim van een Amerikaanse belangenvereniging. Later werd zelfs de Readme rondom auteursrechtenmateriaal aangepast, zodat ook gebruikers konden worden geblokkeerd die zulk materiaal als fork aanboden.

Wat is 'actieve malware'?

Sinds vorige week zijn er allerlei nieuwe problemen ontstaan. Die begonnen met een controversiële blogpost. De nieuwe cso Mike Hanley schreef daarin dat GitHub het beleid rondom het hosten van malware en securityonderzoek nader ging bekijken. "We willen duidelijker worden over onze ideeën om GitHub en de vele package registries daarop veilig te houden", zei Hanley. Het gaat om een beleidswijziging die volgens de Chief Security Officer nodig is om 'het verschil te tonen tussen actief schadelijke content en at-rest code die wordt gebruikt voor beveiligingsonderzoek'. Het bedrijf zegt het niet met zoveel woorden, maar lijkt wel gedreven te zijn door de situatie rondom ProxyLogon, en vroeg de mening van de community.

GitHub wil een betere definitie van wat 'actieve malware' isCentraal in de discussie staan bijvoorbeeld vragen zoals wat de definitie is van een exploit of van malware. GitHub gebruikte al langer de term 'active malware and exploits' als het ging om welke content wel of niet is toegestaan. Daarvan zegt het bedrijf nu dat die term te breed is. Want wat betekent 'actieve malware'? Het is malware die door criminelen wordt ingezet, maar dat op allerlei niveau's gebeuren. Een kritiekpunt dat veel onderzoekers in de pull request noemen is dat code die door criminelen wordt 'overgenomen' uit een repo al snel 'actief' is, zegt een onderzoeker. Een ander punt is dat GitHub daarmee op de stoel van de rechter gaat zitten over wat wel en niet acceptabel is als schade. "Een simpele exploit inzetten tegen een lokale koffiezaak kan worden gezien als iets dat een bedrijf kapot kan maken, terwijl een bank een goede strategie tegen diezelfde exploit heeft", zegt een ander. Na een paar dagen discussie - of beter gezegd, veel negatieve feedback van beveiligingsonderzoekers - besloot GitHub de term te vernauwen naar 'malware en exploits die direct onwettige activiteit ondersteunen'. GitHub benadrukt dat het 'software met dubbel gebruik', zoals PoC's voor malware, blijft toestaan. Maar, vervolgt het bedrijf, 'onze intentie is om duidelijk te maken wat de grens overschrijdt en een beleidsovertreding wordt'. Een echt heldere definitie is er dus nog steeds niet en er zal er waarschijnlijk geen komen waar iedereen zich in kan vinden.

Verwachte storm

Veel beveiligingsonderzoekers zagen de ruzie tussen GitHub en de community al langer aankomen. De overname van Microsoft was voor sommigen een voorteken, wat in hun ogen werd bevestigd toen GitHub eind 2019 een contract aanging met de Amerikaanse immigratiedienst. Een grote groep ontwikkelaars protesteerden daar tegen. Als er dan ook nog discussie komt over DMCA-takedowns zoals youtube-dl, en nu met het arbitrair verwijderen van proofs-of-concept, dan zijn dat druppels die de emmer voor critici doen overlopen. Ondertussen heeft GitHub wel 56 miljoen gebruikers en is het daarmee het grootste platform om code te delen. Dan zijn conflicterende belangen onvermijdelijk.

Reacties (19)

[S.McDuck]

Het zal wel een -1 score worden maar ik vind het plaatsen van deze zaken juist prima. Je laat zien welke zaken er niet goed zijn met een POC en dwingt bedrijven de zaken op orde te brengen. Dit zijn zowel de bedrijven die de gaten moeten dichten maar ook bedrijven die ermee moeten werken. Het is in deze tijd geen excuus meer om je beveiliging en security niet op orde te hebben.
Dit dwingt de 'experts' ook gewoon om alert te blijven, monitoren en te doen waar ze betaald voor worden. Uiteraard is het ethisch om bedrijven een periode te gunnen om zaken te regelen en te fixen. Maar je kan ook vraagtekens zetten bij de hoeveelheid bugs, fouten, exploits die er in de software zit en of dit wel verkocht mag worden. We hebben het hier over een serieus aantal fouten die bedrijfsvoeringen bedreigen.

Aangezien de auto vergelijking altijd populair is: Als je een auto koopt met zoveel fouten die zo bedreigend zijn zou het niet bij een terugroep actie blijven of een gratis garage bezoekje. Dit zou serieuze boetes opleveren voor de fabrikant als het al door de testen heen komt om vrij op de markt te verkopen.

[Mavamaarten]

Ik vind het gecompliceerder dan dat. Het is eerder vergelijkbaar met een gat vinden in de beveiliging van auto's zodat je ze snel kan jatten. Ofwel breng je daarvan de autofabrikant op de hoogte, geef je ze de kans om de het probleem op te lossen door een terugroepactie. Ofwel klets je het online onder de noemer "how to open every BMW car with this easy trick" en zie je hoe criminelen overal bmws gaan stelen alsof het niets is.

[kimborntobewild]

Het is in deze tijd geen excuus meer om je beveiliging en security niet op orde te hebben.

Als je voorop wilt lopen, ontkom je er niet aan dat je regelmatig te snel software uitbrengt. Als je niet voorop wilt lopen, zal je bedrijf vanzelf failliet geraken.
Dit komt omdat we 'vrije markt' ontzettend hoog in het vaandel hebben staan. 'Vrije markt': d.w.z.: geen afdoende druk, toezicht/controle, afstraffing op bedrijven, als ze onveilige software uitbrengen.
Dus... mijn insteek: zolang wij op deze aardbol de 'vrije markt' zo extreem hoog in het vaandel hebben staan, is het niet mogelijk om je beveiliging en security op orde te hebben.
Een ander groot nadeel van die 'vrije markt' is dat we (daarmee) zeer groot belang hechten aan zelfregulering. Zelfregulering in het bedrijfsleven heeft nog nooit goed gewerkt (voor de mensheid), doet dat nu ook totaal niet, en dat zal ook nooit goed werken. Waren deze week weer een paar programma's over op TV: o.a. het bedrijf verantwoordelijk voor de brand in de Grenfelltoren, is zelf toezichthouder op NEN-normen inzake brandveiligheid in NL. En dat soort verhalen hoor ik 'dagelijks'. We moeten het bedrijfsleven niet zelf de boel laten reguleren; dat is vragen om problemen. De vraag 'De kritiek die nu op GitHub komt draait dan niet om de vraag óf exploits openbaar moeten worden, maar wie de grens daarover bepaalt. Is dat de brede gemeenschap van securityprofessionals, of toch GitHub?' uit dit artikel, klopt dan ook niet: je moet géén van beiden de grens laten bepalen; dat moet een overheid doen. Uiteraard dan wel een linkse overheid; de verantwoording bij een rechtse overheid leggen heeft het geen zin.

Een ander groot nadeel van die 'vrije markt' is het extreem destructieve karakter ervan op ons milieu en klimaat. (Met name in NL is het oliedom als je rechts stemt: je stemt daarmee op partijen die ervoor zorgen dat ons lage landje uiteindelijk onder zal stromen. Weg, hoofdinternetknooppunten in de buurt van Amsterdam. (En natuurlijk weg, 17 miljoen mensen, op een klein groepje mensen in Limburg na.))
Links stemt inzake privacy/security-zaken aan de kant van de gebruiker, i.p.v. het bedrijf. Dit i.t.t. rechts: rechts stemt voor 'zo weinig mogelijk regels' voor de bedrijven. Mijn conclusie is dus: stemt allen op de PvdD; de meest linkse partij in NL.
Maar mensen denken vooral op korte termijn; aan lange termijnbelangen voor de mensheid kan de kiezer niet denken. Ik zie dat ook bij mensen om mij heen, die ik anderszijds wel als intelligent zou willen bestempelen.

[RoestVrijStaal]

Voor die beveiligingsonderzoekers moet het toch niet moeilijk zijn om zelf een Git-repository-service te draaien d.m.v. self-hosted GitLab of Gitea (of zelf een wrapper om git heen bouwen als die laatste twee te onveilig zijn)?

Dat GitHub tegenwoordig een morele agenda volgt, toont aan dat het te groot is geworden.

Vroegâh toen SourceForge the-place-to-be was voor open source projecten en code hosten(¹), bleef code van bedenkelijke aard langer online dan ooit bij GitHub zal zijn.

¹ Dat was voordat installers van populaire applicaties hergebundeld werd door Sourceforge. Die dat nu niet meer doet.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 21:38]

[bush]

ze zouden ook een private repository op GitHub kunnen maken, en die enkele delen met collega's ipv public

[Vedette.]

En daarmee een soort exclusieve community creëren waarbij je mensen moet kennen om toegang te krijgen? Dat lijkt me niet bevorderlijk voor het vakgebied.

[wica]

Als mensen kennen, inhoud dat het een soort screening wordt. Zou het best wel eens kunnen werken.
Je houd een hoop prutsers buiten de deur, zolang de PoC niet naar buiten lekt.

Maak de NCSC's van deze wereld lid van zo'n groep zodat ze actief kunnen scannen en waarschuwen.

[nst6ldr]

Notoir slecht idee, dit maakt het nodeloos slecht toegankelijk voor particuliere beveiligingsonderzoekers en je lost er werkelijk niks mee op.

[svennd]

De reden waarom PoC's nodig zijn is omdat je moet kunnen aantonen dat een bepaalde exploit ook echt impact kan hebben; Dat moet zo breed mogelijk worden gedragen;

Zodat ook huis-tuin keuken scriptkidies, zoals mezelf kunnen aantonen aan het security un-aware management dat letterlijk iedere downtime teneinde updates te installeren echt wel nodig is.

[Ludewig]

Ik zou liever zien dat er een onafhankelijk organisatie komt die (vrijwillige) regels maakt voor beveiligingsonderzoekers en bij conflicten kan bemiddelen of een uitspraak doen wie er volgens hun regels gelijk heeft. Een standaard regel bij het publiceren van exploits is bijvoorbeeld dat het bedrijf genoeg tijd moet hebben gehad om de bug te patchen, maar wat een redelijke periode is hangt wat mij betreft af van de middelen die het bedrijf heeft en hoe snel de gebruikers geupgrade kunnen worden.

Dan kunnen onderzoekers, softwaremakers en bedrijven zoals GitHub zich vrijwillig daarbij aansluiten.

Wanneer GitHub zijn eigen regels maakt is het altijd maar de vraag of ze hun eigen belangen niet voorop gaan stellen. Wat doen ze bijvoorbeeld als er een exploit wordt gevonden in GitHub zelf? GitHub is immers zelf ook een softwaremaker en daarmee belanghebbende.

[Niemand_Anders]

Je kunt PoC code welke Microsoft producten als target hebben natuurlijk ook op GitLab of BitBucket hosten. Elke git platform heeft zijn voor- en nadelen, maar deze drie platformen zijn in groten lijnen identiek.
Maar als IT professional moet je niet raar opkijken als Microsoft PoC in public repositories verwijderd van hun platformen..

Ik denk dat het heel erg lastig is om een onafhankelijke organisatie neer te zetten. De grote tech reuzen zullen dan toch al snel een poppetje van hun in de organisatie willen hebben. Ook diverse security onderzoek teams/organisatie willen dat. Uiteindelijk kom je dan toch vaak uit bij een touwtrek wedstrijd want iedereen heeft een belang..

[wica]

WIl je voorkomen, dat iets wat je publiek neer zet, verwijderd kan worden?
Plaats je bericht (kan tot 32MB) in een BTC betaling.

Als genoeg mensen dit doen komen er vanzelf wel tools of websites om het gemakkelijk toegankelijk te maken.

[ShellGhost]

Ik heb al jaren een github repository met malware. Van Formbook tot Sodinokibi.
Maar ik vermoed dat deze niet meer actief zijn, als in dat de infrastructuur al plat ligt.
Wel kan het interessant zijn om te kijken hoe de malware in elkaar zit en dat je dat kan delen met peers.
Uiteraard hoeft dat niet op Github, kan ook via bijvoorbeeld VirusTotal.

[Anoniem: 316512]

Hmm dit was echt 1 dagje in mijn timeline een dingetje. Nu hoor ik er niemand meer over. Genoeg andere platforms om code te delen. Kan wel begrijpen dat Microsoft liever niet allerlei PoC's van hun eigen software op github ziet, alhoewel ik mij afvraag in hoeverre je er nou iets mee tegenhoudt.

[dez11de]

Ook relevant https://arstechnica.com/g...sota-researchers-apology/

[thePiett]

Als ik de code van de PoC https://gist.github.com/t...30f7a501e35e67f2fcaa57bda zie, dan is dat dus een berg XML waarin letterlijk staat "Start programma X".

Wtf? Als je bij Microsoft werkt en je werkt aan Exchange en je bouwt deze functionaliteit dan moeten er toch allemaal rode vlaggen gaan wapperen in je hoofd?

[kodak]

Github lijkt me niet gemaakt om specifiek malware te delen. Dan kan je ook niet vreemd opkijken dat anderen dat delen niet waarderen, ongeacht het aantal gebruikers.

Het heeft veel gebruikers omdat het nauwelijks iets kost. Aan de andere kant probeert de eigenaar winst te maken. Misschien als de eigenaar de klanten kan laten zien hoe ze aan publiceren van malware op hun platform kunnen verdienen (weten welke malware er is en wie daar gebruik van maakt en actieve malware stoppen is geld waard) en dus de kosten en overlast voor klanten laag houden de klachten wat doet verminderen.