GitHub gaat malware en exploits voor 'dual-use-securityonderzoek' toch toestaan

GitHub gaat proofs-of-concept van malware niet langer verwijderen als onderzoekers die gebruiken voor 'dual-use'. Dat betekent dat actieve malwarecampagnes en command-and-controlservers kunnen worden verwijderd, maar veel onderzoek kan blijven staan.

GitHub heeft de regels rondom malware en conceptversies van malware aangescherpt. Voortaan staat de site 'dual-use securitytechnologieën expliciet toe' op het platform. Hetzelfde geldt voor ander onderzoek naar kwetsbaarheden, malware en exploits. Dat 'dubbele gebruik' betekent in dit geval malware die zowel in actieve campagnes wordt gebruikt als die door beveiligingsonderzoekers wordt geüpload om ervan te leren.

Veel beveiligingsonderzoekers plaatsen exploits of proofs-of-concept van bekende malware op het platform zodat de community kan bestuderen hoe die precies werken. GitHub zegt dat het voortaan 'uitgaat van positieve intenties' als onderzoekers zulke dual-use-malware uploaden.

In het nieuwe beleid dat GitHub rondom die proofs-of-concept heeft opgesteld, schrijft het bedrijf dat content wel verwijderd kan worden 'in zeldzame gevallen'. Dat is het geval als GitHub zelf als cdn wordt gebruikt om malware of exploits te verspreiden. In zo'n geval zal GitHub naar eigen zeggen er eerst voor kiezen toegang tot content te beperken door bijvoorbeeld extra authenticatie te eisen. In zo'n geval is een blokkade 'waar mogelijk tijdelijk'. Beheerders van dergelijke repo's worden dan ook sneller gewezen op het bezwaarproces.

GitHub reageert met de nieuwe regels op commotie die in maart ontstond. Het platform verwijderde een proof-of-concept van een kwetsbaarheid in Exchange, terwijl die door een beveiligingsonderzoeker was geüpload voor educatieve doelen. Onderzoekers waren ontevreden over die beslissing, en over het algemene beleid van GitHub dat ambigu en tegen onderzoekers zou zijn. GitHub zei toen het beleid rondom malware ter discussie te stellen, wat het platform weer op nieuwe kritiek kwam te staan. GitHub zei daarop in gesprek te gaan met onderzoekers.

Reacties (27)

[Verwijderd]

Altijd een spagaat dit. Maar snap wel dat ze zeggen dat het niet meer leuk is als de exploit dankzij GitHub werkt (CDN enzo)

[kipppertje]

Nooit een spagaat geweest. Veel hacktools worden op Github gereleased, en pocs voor nieuwe exploits ook. Dit was altijd toegestaan, totdat er op Github (wat van Microsoft is) een exploit werd gereleased voor een ander Microsoft product.

[dutchgio]

Het was inderdaad wat discutabel om het te verwijderen toen het om een lek in Exchange (Microsoft) ging, waar Microsoft tegenwoordig ook de eigenaar van Github is.
Terwijl eerdere exploits, PoC etc. nooit verwijderd is. Het nieuwe beleid schept daar in ieder geval wat meer duidelijkheid in, als het wordt gebruikt als hosting (CDN) verwijder je het, ten behoeve van informatiedeling, onderzoek etc. kan het blijven staan.

[jwywy17276]

content == informatie

[Morrar]

Eigenlijk valt de spagaat wel mee denk ik. Denk over de redenen waarom je een hack of exploit publiek zou willen delen of vooral waarom je dat *niet* zou willen.

Je zult de hack of exploit waarschijnlijk liever prive willen houden als jij er goed geld aan kunt verdienen (al dan niet via derde partijen die ervoor betalen). Bijvoorbeeld om er met malware een slaatje uit te slaan (vb cryptolockers) of door het te verkopen voor spionage doeleinden.

Een publiek repo is dan eerder onhandig; je loopt dan het risico op detectie door de producent van het door jou gehackte product zou zomaar het einde van je business kunnen betekenen.

Dus waarom zetten mensen hacks en exploits publiekelijk online? Wellicht weigerde de producent het veiligheidsgat te dichten. Wellicht voor hun persoonlijke eergevoel. Misschien gewoon voor de lol.

Al deze redenen zijn echter minder schadelijk dan dat men het prive houdt en er geld aan gaat verdienen. Een publiek repo dwingt een producent om actie te ondernemen en daarmee geeft het de consument uiteindelijk veiligere software.

Het enige wat een fair argument is, is dat de producent wel de tijd / mogeljikheid geboden moet worden om het product te fixen. Maar dan zou Github gewoon het repo X tijd prive kunnen houden als gedetecteerd wordt dat het om een exploit gaat.

[bergkid]

Wat mij een logische stap lijkt is dat github verplicht dat dit soort applicaties in een private repository komen te staan en dat alleen gecertificeerde bedrijven dit soort dingen er op mogen zetten.
Dan kan github vervolgens stellen dat het bedrijf verantwoordelijk is voor de toegang tot de repository en de eventuele verspreiding er van.

[kodak]

Er zijn miljoenen mensen die zich legaal bezig houden met onderzoek. Dat zijn juist niet alleen bedrijven. Ook komen en gaan er dagelijks duizenden mensen die het legaal willen delen. Dat vooraf controleren kost dus waarschijnlijk veel tijd en geld, gaat ten kosten van andere zaken, terwijl het risico er nauwelijks lijkt te zijn en wegstoppen achter een prive ruimte nauwelijks nut heeft om de informatie te kunnen delen. Het lijkt eerder logisch dat github niet zomaar uit gaat van slechte bedoelingen.

[TheVivaldi]

Inderdaad. En ik vraag me ook serieus af hoeveel bedrijven er nu eigenlijk gebruikmaken van GitHub. Er zitten er best wat op, maar volgens mij is het aantal individuele ontwikkelaars of kleine teams zonder bedrijf vele malen hoger.

[kuurtjes]

Hoe minder bekend een exploit is hoe gevaarlijker hij is.

[souplost]

Ze moeten wel anders gaan ze naar github of bitbucket.

[kipppertje]

Dit gaat over GitHub. Of bedoel je GitLab?

[souplost]

Ja natuurlijk bedoelde ik gitlab. Bedankt!

[ThePendulum]

Ik had een gitea installatie met open registratie, en dat heb ik geweten. Ik kwam er een paar weken geleden achter dat iemand een account had gemaakt en die helemaal had volgeladen met allerlei exploit utilities, verwijzend naar GitHub.

Ze hebben dus blijkbaar niet alleen GitLab en BitBucket in gedachten, maar neuzen ook allerlei adressen af om onafhankelijke git repository servers te vinden.

[Reactie gewijzigd door ThePendulum op 26 juli 2024 13:41]

[Tintel]

Security by obscurity is geen oplossing.

[n9iels]

Grappig dat we hier eigenlijk gewoon een soortgelijke discussie te pakken hebben als over het wel/niet open-source maken van normale code. Men kan beargumenteren dat het open-source maken van een project kan leiden tot het vinden van 0-days door een hacker. Aan de andere kant, uitgaande van goede intenties, worden deze zelfde 0-days gemeld en verholpen.

[Tadsz]

Dan heb je ook wel de capaciteit om een goede CDN op te zetten en niet van Github afhankelijk te zijn

[Dark Angel 58]

Als je een malware of exploit op github zet, dan kun je hun code inzien?
Zo ja... dan kan iedereen de code voor criminele doeleinden bestuderen...

[dutchgio]

Ja en je kunt de code inzien om dergelijke malware te detecteren dan wel te blokkeren. Dat is dus het 'dual-use' waar GitHub op doelt.

[jaapzb]

Wat als een gestoorde geest of AI erin slaagt dat hij malware heeft gemaakt die niet door anti malware programma's getedecteerd kan worden,

Dit gebeurt aan de lopende band...

Je weet dat de terminator films fictie zijn toch?

[kipppertje]

Wacht, was dat geen documentaire?

[Tintel]

Jawel - een van de betere...

[Dark Angel 58]

[...]


Dit gebeurt aan de lopende band...

Je weet dat de terminator films fictie zijn toch?

Dat is waar, maar ze hadden wel een boodschap... dat je het misschien rekening mee houden dat het mogelijk in de toekomst gebeurt. Dat wilden de schrijvers ons vertellen.

[jaapzb]

Ik denk dat de schrijvers ons vooral een mooie actiefilm wilden laten zien

[n9iels]

Het spelletje tussen de anti-virus makers en virus-makers is al zo ouds als de 1e virussen En dan nog voorkomt een anti-virus programma niks als je het uit heb staan of niet hebt geinstalleerd. Kijk bijvoorbeeld eens naar not-petya, dat was echt heel groot en niet zo lang terug.

[Razwer]

"nooit meer" wanneer was de vorige keer? 29 Augustus, 1997?
Of 18 juni 2021
https://terminator.fandom.com/wiki/Judgment_Day

[Reactie gewijzigd door Razwer op 26 juli 2024 13:41]

[Dark Angel 58]

"nooit meer" wanneer was de vorige keer? 29 Augustus, 1997?

Nee, ik kom net uit de toekomst, daar ging het behoorlijk mis