Google gaat betalen voor ontdekken van kwetsbaarheden in apps van derde partijen

Google gaat beveiligingsonderzoekers voortaan ook beloningen uitkeren als zij lekken vinden in apps van derde partijen. Die moeten in de Play Store staan en daar meer dan honderd miljoen installaties hebben.

Google breidt daarmee zijn Google Play Security Reward Program of GPSRP verder uit. Dat programma keert bug bounties uit aan ontwikkelaars en beveiligingsonderzoekers die lekken vinden in apps in de Play Store. Tot voorheen kon dat alleen bij apps die door de originele makers zelf waren aangemeld bij het programma. Google verbreedt de scope van het programma zodat iedere app met meer dan honderd miljoen downloads automatisch in aanmerking komt voor een beloning van Google zelf. Dat geldt ook als de makers van de app zelf geen bug bounty-programma hebben. Als zij dat wél hebben maken de ontdekkers kans een beloning dubbel te ontvangen.

Google zegt dat ontwikkelaars een melding krijgen via de Play Console als een lek is ontdekt. Dat is onderdeel van het App Security Improvement-programma, schrijft het bedrijf in een blogpost. Volgens Google heeft het programma inmiddels bugs verholpen in meer dan een miljoen apps van meer dan 300.000 ontwikkelaars. Via het Security Reward Program is bovendien al meer dan 265.000 dollar uitgekeerd, waarvan 75.500 dollar in juli en augustus van dit jaar.

Naast het uitbreiden van het GPSRP begint Google ook een ander, nieuw programma. Het Developer Data Protection Reward Program of DDPRP is een samenwerking met HackerOne. Het programma is bedoeld om datamisbruik in apps op te sporen. Dat geldt overigens ook voor OAuth-projecten, Googles api's, en Chrome-extensies. Het gaat om software die gebruikersdata onterecht verzamelt, gebruikt of doorverkoopt zonder dat de gebruiker daar vanaf weet. Onderzoekers die zulk datamisbruik in Google-diensten ontdekken kunnen daarvoor een beloning krijgen. Google zegt dat er op dit moment nog geen definitieve beloningslijst of een maximale beloning vastgesteld is, maar zegt tegelijkertijd wel dat onderzoekers 50.000 dollar of 45.000 euro kunnen krijgen voor een melding.

Reacties (25)

[jurroen]

Open source is alles behalve een kwaliteitsstempel. Dat de code open is, wil niet zeggen dat er iemand naar kijkt of dat die persoon de juiste expertise heeft.

Of zijn Heartbleed en Shellshock alweer in de vergetelheid geraakt? Bij die laatste zat er tussen de introductie van de kwetsbare code tot ontdekking maar liefst 25 jaar.

[jabwd]

Precies dit, en daarbij het lastige is dat je gewoon op veel verschillende manieren backdoors (of expres een bug) kan in werken in opensource projecten zonder dat iemand het merkt. Zo kan je bijv, al is deze niet heel sterk, een function call in de license header comment plaatsen die gewoon */evilShit()/* gebruikt. Daarnaast heb je in talen zoals swift de mogelijkheid om 0-width characters in unicode te gebruiken om gewoon delen code te verbergen van editors. Ik heb ook voorbeelden gezien van backdoors die bijna niet te vinden zijn zonder al je aandacht erbij te houden. Wat ik aan zulke backdoors interessant vind is dat het eigenlijk hetzelfde mechanisme / denkwijze is die vaak de logische bugs in protocollen / parsing veroorzaken waar DDOS aanvallen etc. mee gemaakt kunnen worden.

Even offtopic verder vind ik het redelijk bizar dat er zo hard gepushed wordt op 0days etc. terwijl 99,99% van de hacks gewoon phishing of password spraying zijn. De problemen die de menselijke factor veroorzaakt moeten we collectief als ontwikkelaars en onderzoekers echt gaan verhelpen.

[Reactie gewijzigd door jabwd op 23 juli 2024 12:18]

[RJG-223]

daarbij het lastige is dat je gewoon op veel verschillende manieren backdoors (of expres een bug) kan in werken in opensource projecten zonder dat iemand het merkt

Je doet het nu voorkomen of het hier om een uniek zwak punt gaat van open source. Dat is gewoon FUD. Ja Open source in niet immuun, maar commerciële software is dat ook niet. Daar kun 'je' ook op allerlei verschillende manieren backdoors in verwerken (*). Mischien dat de geheime dienst van Rusland wel een paar mannetjes 'gedetacheerd' heeft zitten bij Adobe, bijvoorbeeld... En zelfs als die er niet zitten, kunnen amerikaanse leveranciers een 'opdracht' van de NSA met een 'gag order' echt niet negeren. Daar kom je noooooit achter. Bij open source kan dát in ieder geval niet.

{*} En als je denkt dat dat niet kan, maar in open source wél, ik zou zeggen probeer jij dan maar eens een backdoor in een significant open-source project binnen te smokkelen. Gaat je niet lukken.

[Henkje.doc]

Vraag me dan toch af wat er met OpenSSL is gebeurt destijds. Misschien niet het juiste voorbeeld, maar wel iets waar veel vendors op leunen wat betreft SSL support.

[Gomez12]

[...]
Je doet het nu voorkomen of het hier om een uniek zwak punt gaat van open source. Dat is gewoon FUD.

Nope, dat is waarheid...
Geen enkel commercieel bedrijf gaat code accepteren vanuit een onbekende bron, bij OS is dat zo ongeveer de standaard.

{*} En als je denkt dat dat niet kan, maar in open source wél, ik zou zeggen probeer jij dan maar eens een backdoor in een significant open-source project binnen te smokkelen. Gaat je niet lukken.

Gaat je 100% wel lukken als je maar genoeg tijd en kunde investeert.

[RJG-223]

Nope, dat is waarheid...
Geen enkel commercieel bedrijf gaat code accepteren vanuit een onbekende bron

En ook geen enkel OSS projekt accepteert ongezien code van een onbekende bron. Als jij een leuk OSS projektje had, en iemand die jij niet kende stuurde jou code om een interessante feature toe te voegen, zou jij die code dan ongezien opnemen ? Echt niet. Dat is ongeveer hetzelfde als een leuke app die iemand op straat jou geeft zomaar op je telefoon installeren.

En al die bedrijven: die doen natuurlijk uitgebreide achtergrondchecks op alle mensen die ze aannemen. Not. Als bedrijf moet je de mensen die je aannneemt maar vertrouwen. Dat een werknemer 'bekend' is (dwz je hebt hem persoonlijk gesproken, en hem daarna aangenomen), betekent niet automatisch dat je hem kunt vertrouwen.

bij OS is dat zo ongeveer de standaard.

Dat klinkt alsof je wilt zeggen dat ze ongezien en ongetest random code van een random onbekende ontwikkelaar opnemen. Echt niet. Dat is ook weer FUD.

Projecten accepteren alleen code van bekende ontwikkelaars - mensen die al langere tijd aan het project werken, en die code wordt vaak minstens door één andere ontwikkelaar ge-reviewd. Code van een ontwikkelaar die niet tot het core team hoort wordt normaal gedetailleerd gereviewd en getest, en zeker niet ongezien geaccepteerd. Die procedures zijn waarschijnlijk minstens zo rigoreus als in het bedrijfsleven.

Nog afgezien daarvan zijn veel OSS ontwikkelaars in dienst bij bedrijven die hen betalen om aan die software te werken. Die bedrijven hebben ook een belang bij die software, en zouden het zeker niet op prijs stellen als de door hun betaalde ontwikkelaar random onbekende code zomaar accepteerde.

Gaat je 100% wel lukken als je maar genoeg tijd en kunde investeert.

En zo ook bij commerciële software.

En als je het lukt bij commerciële software is de kans veel kleiner dat het ooit ontdekt wordt dan bij OSS. Bij commerciële software kijken er veel minder mensen naar de source code (want die is geheim). Eigenlijk alleen mensen die daarvoor betaald worden door het bedrijf, en het bedrijf wil meestal niet, of beperkt betalen voor het zoeken naar problemen. Bij OSS kan iedereen die er belang bij heeft de code onderzoeken, of iemand anders daarvoor betalen.

Nogmaals: ik wil niet zeggen dat OSS immuun is voor allerlei problemen, maar dat is commerciële software evenmin. En als je een probleem waar beiden last van kunnen hebben enkel toeschrijft aan OSS, is dat pure FUD, zeker als je er onwaarheden bijhaalt, zodat OSS projekten 'zomaar' code van onbekenden accepteren, en zelfs dat dat standaard zou zijn. Belachelijk!

[Gomez12]

[...]
En ook geen enkel OSS projekt accepteert ongezien code van een onbekende bron. Als jij een leuk OSS projektje had, en iemand die jij niet kende stuurde jou code om een interessante feature toe te voegen, zou jij die code dan ongezien opnemen ? Echt niet. Dat is ongeveer hetzelfde als een leuke app die iemand op straat jou geeft zomaar op je telefoon installeren.

Dat is ook waarom het tijd kost, je stuurt eerst wat algemene fixes als onbekende dan wordt je vanzelf bekend binnen het OSS project. Daarna bouw je nog wat meer vertrouwen op, dan pak je een slecht te doorgronden / exotisch stuk op en introduceert daar je backdoor in.

[...]
Dat klinkt alsof je wilt zeggen dat ze ongezien en ongetest random code van een random onbekende ontwikkelaar opnemen. Echt niet. Dat is ook weer FUD.

Het is idd FUD hoe jij het neerzet, maar dat is niet wat ik zeg.

Projecten accepteren alleen code van bekende ontwikkelaars - mensen die al langere tijd aan het project werken, en die code wordt vaak minstens door één andere ontwikkelaar ge-reviewd. Code van een ontwikkelaar die niet tot het core team hoort wordt normaal gedetailleerd gereviewd en getest, en zeker niet ongezien geaccepteerd. Die procedures zijn waarschijnlijk minstens zo rigoreus als in het bedrijfsleven.

Dat geldt bij de giga-OSS projecten die het tot bijna commerciele status hebben gehaald, als een linux-kernel of een libreoffice of een firefox of een chromium.
Maar dat geldt zeker niet voor alle miljoenen OSS projectjes die daaronder vallen.

Nog afgezien daarvan zijn veel OSS ontwikkelaars in dienst bij bedrijven die hen betalen om aan die software te werken.

Jouw "veel" is in de praktijk een heel klein pietepeuterig gedeelte boven de 0%.
Jij negeert alle miljoenen OSS projectjes op Github etc waar mensen dagelijks gebruik van proberen te maken etc.

[...]
Bij commerciële software kijken er veel minder mensen naar de source code (want die is geheim).

Heb je hier cijfers voor, want ik betwijfel het ten zeerste. Bij OSS kan je naar de code kijken, maar praktisch niemand doet het....

Nogmaals: ik wil niet zeggen dat OSS immuun is voor allerlei problemen, maar dat is commerciële software evenmin. En als je een probleem waar beiden last van kunnen hebben enkel toeschrijft aan OSS, is dat pure FUD, zeker als je er onwaarheden bijhaalt, zodat OSS projekten 'zomaar' code van onbekenden accepteren, en zelfs dat dat standaard zou zijn. Belachelijk!

De verhouding waarin ze er last van hebben is niet 50-50 wat jij wel lijkt te willen impliceren (want dan zou het FUD zijn).

[Verwijderd]

Geef me eens een paar voorbeelden van open source Android apps waar door tweakers (niet door AV companies etc) gevaarlijke bugs in gevonden zijn? Wij leveren rond de 30.000 regels code als Open Source af per jaar en doen dat al een jaar of tien. Nog nooit (!) heeft naar mijn inzien iemand naar de source gekeken. De gecompliceerde versie krijgt rond de 500.000 download per jaar, de source code rond de 10 per jaar. Een deel daarvan door ons om te checken of alles er wel is. Verleden jaar bleek dat een module die al 7 jaar als deel van de Open Source geleverd werd niet uitgepakt kon worden. Blijkbaar had niemand dat ooit gezien.

Hoeveel bug heb jij al gevonden door sourcecode door te spitten? Heb je eigenlijk wel enig idee wat dat inhoud?

[blorf]

Een Android-app is technisch gezien een plugin voor een Linux-programma dat alleen draait op een specifieke aangepaste kernel van Google. Daar bugs in zoeken is achter de feiten aanlopen. De hele constructie is overcomplex en verre van transparant.

Een notepad app die zonder uitleg toegang tot je foto-album vraagt, heeft die een bug?
Naar mijn mening in ieder geval al 1. Of zullen we het een exploit noemen?

[Reactie gewijzigd door blorf op 23 juli 2024 12:18]

[Jerie]

Of zullen we het een exploit noemen?

Een bug kan een kwetsbaarheid veroorzaken. Beiden zijn iets geheel anders dan een expoit. Dat is een programma dat een kwetsbaarheid uitbuit.

[blorf]

Eenn bug is altijd een kwetsbaarheid, want inconsistente code en onvoorspeld gedrag.
Een exploit is een beschrijving van hoe een bug misbruikt kan worden tegen het betreffende systeem. Geen kwetsbaarheid meer maar een gat.

[Jerie]

Het zit zoals ik zei, en dat kan de lezer hier nalezen.

https://en.wikipedia.org/wiki/Exploit_(computer_security)

Niet iedere bug leidt tot een kwetsbaarheid in de zin van beveiliging.

[blorf]

Iets wat "tot een kwetsbaarheid leidt" is taalkundig incorrect... Je hebt een situatie of toestand nodig om heen te leiden, geen voorwerp of gebeurtenis. De kwetsbaarheid zelf kan tot dingen leiden...

[JeroenED]

Het is niet omdat iets open source is dat het per definitie veilig is. Open Source is ook niet bedoeld om per definitie veilig te zijn. De originele term "free" is bedoeld als in free speech. Dus vrij waarin de developer bepaald wat de software doet en waarin de gebruiker bepaald of hij daarmee akkoord gaat. Als ik een beveiligingsproduct maak en ik steek daar een backdoor voor de russen in, is het aan u om aan de hand van die info (de code dus) te bepalen of jij dat wilt gebruiken.

De wet van linus (given enough eyeballs, the bugs will shallow) haalt het argument ook niey want ik wil je duiden op het feit dat er "will shallow" staat en niet "will disappear". Vrij vertaald "zullen verminderen" en dus niet "zullen verdwijnen". Ook even duiden dat er ook eyeballs moeten gegeven worden en dit zijn niet het aantal eyeballs die het gebruiken.

[Ventieldopje]

Andersom is het ook niet beter en leun je eerder op "security through obscurity". Het kan een puinzooi zijn maar als de gebruiker dat niet ziet, ach. Met open-source kom je daar niet zo snel mee weg.

[Chinco]

Met open source kom je daar net zo goed mee weg, want wie gaat al die code lezen? Hoeveel projecten hebben een team dat specifiek naar security van alle code kijkt? Gratis? Hoeveel open code wordt gereviewed met beveiliging in het achterhoofd? Hoeveel audits? Je mag al blij zijn wanneer de functionaliteit grondig getest is.

Dat de code door iedereen gelezen kan worden wil niet zeggen dat de code uberhaupt gelezen wordt. Andersom heeft een commerciele partij er belang bij dat hun code wel op security getoetst wordt, wat het is hun brood. Wat dat betreft staat OSS eigenlijk 1:0 achter, al is voor beide geen garantie te geven.

Buiten dat: ook closed source code is blijkbaar op security te toetsen: de meeste bug bounty programma’s gaan tenslotte over closed source.

Edit: @jurroen was me uren voor...

[Reactie gewijzigd door Chinco op 23 juli 2024 12:18]

[Douweegbertje]

Je eerste stuk is wel erg kort door de bocht. Dat het open source is betekend niet dat er geen fundings zijn, noch dat er geen betaalde werknemers aan de "core" werken. Zeker als het gaat om dat wat grotere projecten. Om wat voorbeelden te noemen, je hebt de cloud native foundation: https://www.cncf.io/ , Linux Foundation, Mozilla Foundation en vele meer, afhankelijk van je segment/niche

Vanuit daar worden ook dit soort initiatieven georganiseerd (en betaald). Waarbij iedereen ook nog eens het rapport mag inzien.
https://github.com/kubern...g-security-audit/findings

Dan zijn er nog genoeg partijen die domweg opensource hun "applicatie" aanbieden maar wel degelijk geld verdienen op andere zaken. Denk hierbij aan Magento (Adobe tegenwoordig). Die draaien zelfs ook mee in bug bounty programs en zijn zelf ook enigszins actief m.b.t. security. Hoewel dus Magento zo op Github staat, open voor pull-requests, kan je ook bij security issues geld ontvangen.

Vergeet verder ook niet dat er ontzettend veel mensen wel actief zijn m.b.t. security ook al is daar geen geld in te verdienen. Het gaat soms om een status die iemand krijgt/verdiend of het feit dat ze iets zelf in productie gebruiken en zelf een audit hebben gedaan.

Dit is nog los van het feit dat "owners" van een project echt wel een realisatie hebben m.b.t. security. Dit zie je vaak terug in de verplichting van een OWNERS file in sommige projecten (https://github.com/helm/c...r/stable/aerospike/OWNERS) zodat er een aanspreek punt is.
Naast het gebruik van docker image scans om veilige images te hebben, automated tests/builds die moeten voldoen aan bepaalde eisen alvorens een PR überhaupt door mag en dat er door de community issues worden aangemaakt op eventuele security best practices.

de meeste bug bounty programma’s gaan tenslotte over closed source.

Dat is discutabel. Vele programma's zijn juist opgebouwd met opensource infrastructuur / software. Het gebruik van een bepaald framework (99% opensource), haproxy (https://github.com/haproxy/haproxy), varnish (https://github.com/varnishcache/varnish-cache), nginx (https://github.com/nginx/nginx), en loop zo de "chain" maar door. In mijn ervaring kan je vrij veel vinden waar de source van beschikbaar is. Uiteindelijk heb je absoluut een groot gedeelte closed source, zoals specifieke applicatie code. Echter als dat is gemaakt middels een opensource framework, dan weet je ongeveer ook wel de ins-outs...

[R4gnax]

Andersom is het ook niet beter en leun je eerder op "security through obscurity". Het kan een puinzooi zijn maar als de gebruiker dat niet ziet, ach. Met open-source kom je daar niet zo snel mee weg.

Right.. want OpenSSL was zo'n schoolvoorbeeld van een goed in elkaar stekende open source codebase zonder gaten in de security die verborgen konden blijven liggen onder stapels aan slecht vormgegeven code waar nooit iemand naar durfde te kijken. Toch?

Oh, wacht...


En wie zou er eerder gemotiveerd zijn om in zulke van de pot gepleurde code te gaan zoeken naar zaken die niet koosjer zijn? Maintainers die top-to-bottom aan bugs werken en aan nieuwe features? Of kwaadwillenden die weten dat er maar weinig naar gekeken wordt, en risico-vrij de directe source-code kunnen analyseren om er een zero-day uit te slepen?

[Reactie gewijzigd door R4gnax op 23 juli 2024 12:18]

[Fidesnl]

“Volgens Google heeft het programma inmiddels bugs verholpen in meer dan een miljoen apps van meer dan 300.000 ontwikkelaars. Via het Security Reward Program is bovendien al meer dan 265.000 dollar uitgekeerd”.

Moet ik dit dan lezen dat er gemiddeld €0,25 wordt uitbetaald per bug?

[Mushroomician]

• Total bounties paid: $266,000
• Average bounty: $1,000
• Top bounty: $5,000
• Hackers thanked: 29

[dasiro]

niet per sé als ze op hetzelfde framework bvb zijn gebaseerd.

[Mushroomician]

Wel bizar vind ik dit:

This program is only for requesting bonus bounties after the original vulnerability was resolved with the app developer. Only issues that have been patched within the last 90 days will qualify.

M.a.w., zolang de ontwikkelaar de bug niet fixt, krijgt de melder geen beloning... Beetje krom.

[Reactie gewijzigd door Mushroomician op 23 juli 2024 12:18]

[HenkEisDS]

Is vrij breed omschreven. Best kans dat google net zo aggressief handelt als ze op youtube doen en gewoon de app verwijderen uit de play store. Dan kun je het resolved noemen toch? Daarnaast denk ik dat ze de app bouwers ook demonitizen als ze niet luisteren op een gegeven moment, dus dan gaat zo’n app boer wel rennen.

[reinaertvdc]

Een mooie evolutie. Ontwikkelaars kunnen wel een extra stimulans gebruiken om op de Play Store te blijven, nu er meer en meer alternatieven komen en er zelfs apps zijn als Fortnite die je rechtstreeks van hun website moet downloaden. De Play Store neemt 30% van de inkomsten, dus dan weet je wel waarom grote ontwikkelaars met een vaste aanhang proberen om hun app op een andere manier aan de man te brengen. Dat die grote ontwikkelaars nu security audits krijgen als deel van de service, is hopelijk een win-win-win voor Google, de ontwikkelaars en de gebruikers.