Onderzoeker ontdekt Instagram-lek en raakt in conflict met Facebook

Door Sander van Voorst, vrijdag 18 december 2015 15:43, 114 reacties • Feedback

Beveiligingsonderzoeker Wesley Wineberg ontdekte tijdens een bug bounty program een beveiligingslek op een Instagram-server, dat toegang bood tot zeer gevoelige gegevens. Facebook betaalde vervolgens een bescheiden vergoeding en claimt dat de onderzoeker te ver is gegaan.

Beveiligingsonderzoeker Wesley Wineberg beschrijft zijn versie van het verhaal op zijn blog. Nadat hij een beveiligingslek had vastgesteld op een Instagram-server besloot hij zijn bevindingen aan moederbedrijf Facebook te melden. Het bedrijf betaalde hem een beloning uit ter hoogte van 2500 dollar, omgerekend 2300 euro. Wineberg was echter een aantal interessante bestanden tegengekomen en besloot verder op onderzoek uit te gaan. Volgens hem bevond hij zich toen nog binnen de regels van het bug bounty program van Facebook. Dit is waar de standpunten van de twee partijen uit elkaar lopen. Facebook-cso Alex Stamos stelt dat alles wat tot aan het vinden van het lek op de Instagram-server gebeurde volgens de regels was, maar dat Wineberg daarna zijn boekje te buiten is gegaan. De site Forbes heeft een uitgebreid artikel gewijd aan het conflict.

De bevindingen van Wineberg begonnen met een tip van een bekende die hem wees op een mogelijk kwetsbare Instagram-server. Er draaide een Ruby-app op de server genaamd 'Sensu-Admin' met een ingebakken geheime Rails-token. Met behulp hiervan lukte het Wineberg na enig onderzoek om een cookie te fabriceren die hem de mogelijkheid tot remote code execution op de Instagram-server opleverde. Dit betekende dat hij in feite alles met de server kon doen. Dit was het eerste moment waarop hij zijn bevindingen aan Facebook meedeelde.

Hij vond een aantal interessante bestanden op de gekraakte server, waaronder een met bcrypt versleutelde database met zestig accounts van Instagram- en Facebook-medewerkers. Normaal gesproken zou het enige tijd duren om dergelijke bestanden te ontsleutelen, maar hij besloot een poging te wagen. Tot zijn verbazing had hij na enkele minuten al twaalf wachtwoorden gekraakt, waaronder 'changeme', 'password' en 'instagram'. De gevonden gegevens gaven hem vervolgens weer met een sleutel toegang tot verschillende aws-diensten, waaronder een S3-opslagdienst van Amazon.

Vandaaruit was hij in staat om een nieuw sleutelpaar te vinden in een oud configuratiebestand. Dit laatste sleutelpaar gaf hem ten slotte toegang tot 82 verschillende buckets met allerlei verschillende, zeer gevoelige gegevens. Wineberg heeft het over gegevens zoals de broncode voor recente versies van de Instagram-back-end, ssl-certificaten en privésleutels voor instagram.com, inloggegevens van een e-mailserver en sociale-media-api's. Hij stelt zelf dat het niet onwaar zou zijn om te claimen dat 'hij toegang tot alle geheime sleutels van Instagram' had.

Reacties (114)

windwarrior
18 december 2015 20:20

Ik denk dat beide partijen over de streep gegaan zijn. Ik heb zowel de reddit en HN thread gelezen en beide blogs (die van facebook en van hemzelf), en maak daar het volgende uit op:

De security reseacher (vanaf nu Wes) heeft een exploit gevonden in een management systeem van Instagram dat (perongeluk) user facing was.
- Dit is uiteraard netjes verwerkt geraakt, hier is een security report over geweest, de (wat mij betreft prima) resolution was een bounty van $2500.
Wes heeft het lek misbruikt om een database dump van de gegeven server te maken, en de wachtwoorden te kraken middels (speculatie?) iets van rainbowtables.
- Hier is wat mij betreft wes te ver gegaan, hij had geen databases mogen downloaden via de remote exploit. Inloggen op het systeem was al helemaal te ver gaan. Echter heeft hij ook deze "bug" gemeld en is hier door facebook gereageerd met "user error". Opzich staat in veel whitehack manifesten dat je zwakheden van users niet mag misbruiken, dat dat geen vunerabilities zijn die voor het bug bounty programma in aanmerking komen.
Middels de credentials heeft Wes verschillende keys gevonden van AWS buckets, en is deze gaan inspecteren.
- Het downloaden van data van verschillende buckets (ook degene die geen user data bevatten) lijkt me een slechte zaak, dus ook dit is wat mij betreft te verwijten aan Wez.
Middels de geminede data heeft Wes een nieuwe key gevonden met nog meer access.
- Deze vunerability in keymanagement is gemeld (wederom) en heeft gezorgd dat de zaak escaleerde. Het melden van de vunerability was het beste van twee kwaden, Wes moest wel. Als hij de vunerability niet gemeld had, dan was Facebook er niet achter gekomen dat ze AWS keys hebben met te veel access, als hij niet gemeld had dan was de hele zaak niet aan het rollen geraakt maar had Facebook nog een lek.
CSO Facebook (Alex) belt baas Wes.
- Dit is waar -wmb- Facebook de fout in gaat, hoewel Wes te ver gegaan is in zijn poging de veiligheid van het interne netwerk van FB te testen, lijkt hij nooit malicious intent gehad te hebben. Het eleveren van de zaak naar een werkgever lijkt mij dus ook buitenproportioneel, waar Alex ook gewoon met Wes had kunnen bellen.
Wes publiceert en licht media in.
- Mja, lastig, als security researcher wil je gehoord worden, maar of het proportioneel is vraag ik me af. Ik laat mijn mening hier in het midden.

Al met al, als beide partijen spijt betuigen voor de zaken die wat mij betreft fout waren dan is er niets aan de hand. Verder lijkt het me voor FB verstandig om in hun whitehackers TOS op te nemen dat een pivot aanval niet gewenst is, dan gebeurd het niet nog een keer

.

P.s. wat is formatting soms toch kut. EN GELUKT!
P.s.2 Tweakers: wat is het record post wijzigen, het is me ondertussen 10 keer gelukt ofzo

[Reactie gewijzigd door windwarrior op 19 december 2015 12:38]

Paul C
@windwarrior • 18 december 2015 22:17

Echter heeft hij ook deze "bug" gemeld en is hier door facebook gereageerd met "user error". Opzich staat in veel whitehack manifesten dat je zwakheden van users niet mag misbruiken, dat dat geen vunerabilities zijn die voor het bug bounty programma in aanmerking komen.

Maar het betreft hier de wachtwoorden van medewerkers en niet van gewone "users". Ik zou dan ook stellen dat dit een admin-error is en niet een "user"-error.

E.g. al heeft Facebook de allerbeste software, dat stelt niets voor als de admins geen goede practices hanteren. Van medewerkers die het netwerk beheren mag je (veel) meer verwachten dan van gewone users. Anders kun je ook wel argumenteren dat die managementtool die per ongeluk user facing is ook een user error is, want tja, verkeerd geconfigureerd door een "user".

windwarrior
@Paul C • 18 december 2015 22:40

Mja.. Eens, maar ook het statement van tech bedrijven snap ik wel. Zo kan je ook wachtwoorden social engineeren, of uit reeds gelekte dbs halen, enz. Daar kan een tech bedrijf zich slecht tegen wapenen, en bij een 'breach' is er weinig anders te doen dan de desbetreffende admin van rechten te ontdoen. (mobiele reactie, stukje bondiger haha).

Mensen zijn in een veilig systeem altijd de zwakke schakel.

[Reactie gewijzigd door windwarrior op 18 december 2015 22:42]

Superstoned
@windwarrior • 19 december 2015 10:25

Ja, op zich ben ik het daar wel mee eens maar deze wachtwoorden waren wel idioot zwak...

"password" en "instagram" zouden voor mij redenen zijn de sysadmin te ontslaan. Nou ja, bijna tenminste, een heel goed gesprek lijkt me wel nodig.

En je wilt dit als bedrijf toch wel weten he...

+2 svenslootweg
@windwarrior • 20 december 2015 14:42

Zoals ik ook elders al schreef: het bekritiseren van de stappen die Wes genomen heeft, mist volledig het doel van een bug bounty - namelijk, om onderzoekers over te halen lekken te melden i.p.v. doorverkopen op de grijze of zwarte markt. De methodologie die Wes toepaste, is een geheel normale manier voor een "echte" aanvaller om zijn werk te doen; en dus ook de manier waarop je je bug bounty wilt draaien.

Bovendien moet je niet vergeten dat Facebook overduidelijk zelf zijn werk niet heeft gedaan - de AWS-keys waren immers niet ongeldig gemaakt, ondanks dat zij niet vast konden stellen of het gerapporteerde lek ook daadwerkelijk misbruikt was (dat kun je namelijk nooit). Dit is dus wederom een punt dat laat zien waarom Wes' verdere onderzoek noodzakelijk was - anders was dit lek uberhaupt nooit gefixt.

Tot slot, wat betreft de publicatie: het tegengaan van publicatie van beveiligingslekken is nooit acceptabel. Ieder lek moet gepubliceerd worden - dit geeft gebruikers namelijk een eerlijk beeld van wat zij kunnen verwachten van de dienst waar zij op vertrouwen. Dat wil natuurlijk niet zeggen dat een dienst niet eerst een (redelijke) kans moet krijgen om het gat te verhelpen - maar als de betreffende dienst zo aggressief reageert op een volkomen normale manier van pentesting, tja, dan gooi je wel een beetje je eigen glazen in.

Laten we vooral niet vergeten dat Facebook hier niet in de positie is om regels vast te stellen - zij zijn degenen die in eerste instantie het lek hebben laten ontstaan, en ze mogen in hun handen wrijven dat iemand uberhaupt de moeite neemt om het te rapporteren, omdat ze er op de zwarte market vermoedelijk twee nulletjes meer voor hadden kunnen krijgen.

Uiteindelijk is het Facebook die in eerste instantie verantwoordelijk is voor de brakke beveiliging, en ze kunnen dan wel heel hard over ethics gaan roeptoeteren, maar dat gaat dus geen enkele echte aanvaller tegenhouden. You don't get to make demands when you're the one who's fucked up.

EDIT: Overigens betaalt Google uit voor het maximale niveau van toegang dat de onderzoeker had kunnen vergaren, zelfs als ze hier zelf niet achter gekomen waren. Dat is de enige manier om daadwerkelijke escalatie binnen het netwerk te voorkomen, en had Wes dan ook heel wat meer op moeten leveren dan $2500 als Facebook hetzelfde beleid had gehad.

[Reactie gewijzigd door svenslootweg op 20 december 2015 14:45]

Eagle Creek
@svenslootweg • 21 december 2015 11:53

Het feit dat Facebook fouten heeft gemaakt en dat men een programma in stand houdt om white hackers te belonen, doet niets af aan het feit dat ook die white hackers zich dan aan bepaalde regels "moeten" houden.

Natuurlijk kun je stellen dat een hacker met kwade bedoelingen zo ver gaat als hij/zij maar kan komen om diens doel te bereiken. Maar het doel van een "good guy" is om kwetsbaarheden aan te tonen, niet om ze tot het uiterste te misbruiken met eventueel verdere risico tot gevolg.

Ik kan mij wel vinden in de opmerking van winwarriror dat Wes een bepaalde grens over is gegaan. Echter denk ik ook dat het uiteindelijk alleen een rechter zal zijn die mag bepalen of dat de richtlijnen gevolgd of getreden zijn.. Klakkeloos erop loshakken onder het mom van "maar ik ben een brave burger, ik heb goede intenties en de andere partij heeft z'n zaken niet op orde" lijkt mij niet de juiste invalshoek

0 svenslootweg
@Eagle Creek • 23 december 2015 14:28

Wederom: Facebook is niet in een positie om regels en grenzen te stellen. Je kunt over ethiek gaan roepen totdat je blauw ziet, maar dat verandert niets aan de realiteit - dat als je onderzoekers niet behandelt zoals ze behandeld willen worden, ze het lek wel aan een andere partij verkopen.

Ik ben het ook zeer oneens met je woordgebruik: "misbruiken". Er is hier helemaal niets "misbruikt". De sleutels zijn gebruikt om aan te tonen dat het probleem dieper ligt dan een enkele RCE, in het voordeel van Facebook, gebruikersdata omzeilend. Dit is een geheel normaal ding om te doen bij een pentest, en hier lagen duidelijk geen kwade bedoelingen achter.

Op het moment dat jij zegt "ja, breek maar in, als je het ons maar laat weten", en dan niet heel duidelijk stelt wat je van een onderzoeker verwacht, dan is er ook helemaal geen sprake van "misbruik" als zij precies datgene doen waar je ze toe uitgenodigd hebt. Dat Facebook de regels niet duidelijk gedefinieerd heeft is hun probleem.

windwarrior
@aval0ne • 19 december 2015 12:39

Ik ben sterker in informatica dan in spellen, "known issue".

Verder hoor ik graag waar nog meer fouten staan, kan ik vast van leren.

[Reactie gewijzigd door windwarrior op 19 december 2015 12:41]

+2 GnrlSchnavy
18 december 2015 16:23

Ik vind het ook niet zo netjes van Facebook. Zoals hij zelf al zei ging het hem niet om het geld. Als je kijkt naar de communicatie tussen hem en Facebook voelt het alsof hij tegen een of andere domme klantenservice medewerker aan het praten is. Je zou verwachten dat Facebook toch wel een stuk dankbaarder zou zijn.

Mensen die zulke grote beveiligingsfouten vinden wil je toch dichtbij je houden? Ik kan me voorstellen dat deze man "bij wijze van spreken" de volgende keer dat hij iets vindt ook denkt, stik er maar in, ik verkoop het wel voor een flinke veelvoud in geld en dankbaarheid aan iemand anders.

0 Jowwy
@GnrlSchnavy • 22 december 2015 00:30

Ik ben het volkomen met je eens. als beveiliger kan jij dit ook even makkelijk op deepnet verkopen maar ipv black of gray hatters af te straffen lijkt fb vanuit mijn perspectief white hattters in feite te willen straffen.

Bovendien erg jammer sinds dit wel echt een 1 miljoen dollar bug was (tenminste zoveel zou je er wel aan verdienen als je de exploot zou verkopen).

Dus alweer ondanks dat ik snap dat in feite de programmeur niet verder 'mocht' zie ik de fout alleen aan de kant van Facebook ik bedoel in een echt aanval gaat niemand zich aan zulke domme regeltjes houden en dan opeens is het heel jammer dat je niet al die white hat reports binnen hebt over hoe je in feite een God key hebt gecreëerd.

Maar ja wat verwachten we dan ook, een eerlijke wereld?

+2 Alpha Bootis
18 december 2015 19:56

Ik vind dat ze niet zo moeten piepen.
Veel systeembeheerders en ontwikkelaars krijgen last van hun ego als iemand een fout in hun systemen vind en dat is gewoon een houdingsprobleem aan hun kant.
Blijkbaar heeft deze man terecht wat werk aan de winkel gebracht en voor zover ik kan lezen zonder echt de boel te saboteren. Daar kan je er m.i. niet genoeg van hebben.
Als je een dienst hebt die je aanbied aan letterlijk iedere internetgebruiker zijn kritieke en minder kritieke bugs een feit van het leven. Zeker als je dienstverlening volledig bestaat uit een eigengebakken applicatie. Hoe meer iemand er voor je vind hoe meer je er aan kan doen. Dat je het dan niet helemaal ethisch vind exact hoe ver er gegaan wordt is een detail. De causale factor is nog altijd gewoon een security probleem met je systeem.

[Reactie gewijzigd door Alpha Bootis op 18 december 2015 19:57]

+1 Rob Coops
18 december 2015 16:16

Ik heb niet het hele verhaal goed gelezen maar ik kan me Facebook wel een beetje begrijpen. De onderzoeker melde een lek. Vervolgens heeft deze zelfde onderzoeker dat lek gebruikt om door te graven en nog meer problemen bloot te leggen.
Dit terwijl het bug hunt programma tot doel heeft dat de gemelde bug wordt opgelost en dus de hack die vervolgens plaats vond niet meer mogelijk is.

Als de eerste bug niet gemeld was maar gewoon was door gegraven tot het punt waar toegang tot de S3 server en de buckets was verkregen en het op dit moment gemeld was dan had Facebook waarschijnlijk meer betaald voor het aantonen van dit enorme lek en veder niet geklaagd maar dat is niet gebeurt en dus zat de hacker/onderzoeker fout in deze.

Als ik de beschrijving zo lees van wat er op die server rond zwerft dan klinkt het er erg naar dat Instagram een groot bedrijf is waar veel te veel mensen veel te weinig van beveiliging weten en toch erg veel toegang hebben.
Dat zie je heel erg vaak bij grote bedrijven en dit is dan ook de reden waarom zo veel mensen die een beetje weten waar ze het over hebben roepen dat bijvoorbeeld cloud opslag voor gevoelige data misschien niet het beste idee is.

+3 Niemand_Anders

Beheer en beveiliging

@Rob Coops • 18 december 2015 19:21

Instagram is natuurlijk een startup geweest welke in zeer korte tijd extreem populair is geworden. Om de boel dan draaiend te houden worden vaak pragmatische keuzes gemaakt.

Welke Administrator heeft niet mee gemaakt dat na een release een service/daemon het niet meer goed werkt. Uiteraard probeer je dan eerst netjes het probleem op te lossen, maar als er uiteindelijk tientallen collega's achter je staan en continue vragen of het al werkt, dan krijgt de user waaronder de service/daemon draait als (local) administrator/root rechten zodat de rust terug keert.

Vervolgens is er daarna geen tijd meer om het probleem structureel te fixen omdat men snel nieuwe functionaliteiten moet bouwen. Als developer kun je dan wel aangeven dat het slechts een quickfix betreft, maar een directie komt al snel met de dooddoener "Maar nu werkt het toch". Als jij nu een week bezig met het correct repareren van die bug/issue, dan heb je 40 uur besteed aan iets, wat precies hetzelfde doet als nu. Terwijl als jij feature X bouwt, wij daarmee duizenden dollars/euros verdienen.

En als developer/beheerder wordt je dan weer duidelijk wat het verschil is tussen theorie en praktijk. En bedrijven zijn vooral geinteresseerd in de praktijk. Dat is waarom backup oplossingen vaak zo'n lage prioriteit heeft bij bedrijven. Want 1 je bent tijd kwijt met het inrichten en onderhouden van backup oplossingen, en dat allemaal voor iets wat je nooit hoopt te hoeven gebruiken.

Uit tijd en/of geld nood worden vaak beslissingen genomen welke achteraf niet zo handig waren.

Aan de andere kant, als jij toegang hebt door een exploit tot een webserver met een ssl/tls certificaat, moet je toch ergens in plaintext dat wachtwoord doorgeven aan apache/nginx. Zeker op de schaal van instagram kun je als systeembeheerder niet bij elke systeem elke keer handmatig het wachtwoord invoeren op duizenden machines. Het Letsencrypt programma verlangt zelfs dat je het vernieuwen van het certificaat automatiseert en onderdeel daarvan is de update van de webserver.

Maar in het configuratie bestand van je webserver staan zeer waarschijnlijk ook de credentials om verbinding met de database te maken. Een user dump is dan al snel gemaakt..
J website maakt gebruik van een cdn? Grote kans dat de webserver credentials bevat om verbinding met AWS te maken voor het uploaden van een user image (avatar). Of een rsync met een password less ssh key..

Dat is dus de voornaamste reden dat je volgens het bounty programma stoppen zodra je binnen bent. Laat ik het anders stellen: Ben je als systeembeheerder zo zeker dat op je server alles zo perfect is ingesteld dat jij iemand 12 uur root toegang durft te geven om rond te snuffelen op jouw server zonder limitaties. Want dat is wat deze hacker eigenlijk deed nadat hij binnen was.

+1 Rob Coops
@Niemand_Anders • 18 december 2015 21:37

Ik werk vele jaren in vele verschillende functies binnen grote bedrijven en voor een aantal startups en ik zie toch een aantal dingen in je verhaal die je bij mij onmiddellijk tot een functioneringsgesprek zouden leiden.

"maar als er uiteindelijk tientallen collega's achter je staan en continue vragen of het al werkt, dan krijgt de user waaronder de service/daemon draait als (local) administrator/root rechten zodat de rust terug keert."
Nou nee hoor... Om te beginnen tientallen collega's gaan gewoon aan het werk en laten de administrator dit probleem op lossen eventueel met hulp van de ontwikkelaars.
Een applicatie die niet bedoelt is om als root/admin/poer user te draaien zal dat NOOIT doen en zeker niet als "oplossing" voor een vreemd probleem.

"Als developer kun je dan wel aangeven dat het slechts een quickfix betreft, maar een directie komt al snel met de dooddoener "Maar nu werkt het toch". Als jij nu een week bezig met het correct repareren van die bug/issue, dan heb je 40 uur besteed aan iets, wat precies hetzelfde doet als nu. Terwijl als jij feature X bouwt, wij daarmee duizenden dollars/euros verdienen."
Een development team of een developer hoort ten alle tijden minimaal 10% van zijn tijd vrij te houden voor het oplossen van dingen die de directie niet ziet. Of dat nu via een formeel verhaal van prioriteiten zetten gebeurt of dat het inhoud dat andere taken simpel weg iets overschat worden het is altijd zaak om als developer te zorgen dat je tijd hebt om problemen op te lossen.
Een directie die alleen maar stuurt op geld is een bedrijf dat alleen maar slechte mensen in dienst heeft en dus waardeloze onstabiele en onveilige producten bouwt. Daar wil je als weldenkende IT'er niet werken.

Natuurlijk moet je een wachtwoord dan wel een key ergens opslaan. Iedereen die denkt dat het anders kan snapt nog niet zo veel van de techniek. Maar je laat NOOIT oude wachtwoorden op een systeem slingeren en ruimt oude deployments inclusief configuratie bestanden gewoon op. Systemen waar bijvoorbeeld een bestand opstaat met gebruikers namen en wachtwoorden al dan niet encrypted mag nooit binnen een DMZ staan dan vraag je gewoon om problemen.

Een administrator die iemand die dat niet hoort te hebben voor bijvoorbeeld een change of zo root toegang geeft tot een machine dient onmiddellijk de toegang tot het netwerk ontnomen te worden. Alle machines die deze persoon met root toegang heeft weten te bezoeken moeten als verloren worden beschouwd, geisoleerd worden en geheel gewist worden voor ze opnieuw worden opgebouwd.

+2 Niemand_Anders

Beheer en beveiliging

@Rob Coops • 18 december 2015 22:18

Bij ons werkt het ook niet zo, maar bij veel bedrijven waarvoor wij integratie verrichten gaat dat wel zo. Maar ik merk ook dat wij als extern bedrijf het sneller voor elkaar krijgen om een bedrijf ergens in te laten investeren dan interne medewerkers. Dat heeft ook voor een deel te maken met onervarenheid van developers waardoor zij te technische blijven door veel directie leden, maar daarnaast ook niet altijd met de juiste argumenten weten te komen.

Vooral bij startups zie ik dat de structuur pas na een aantal jaren komt en men zichzelf verkeerde procedures heeft aangeleerd want er was niemand om ze te corrigeren.

Maar een document of spreadsheet met daarin de admin/root wachtwoorden is echt niet zo zeldzaam als je zou willen. Staan bijna altijd op de workstations, maar die zijn (gelukkig) vaak niet remote benaderbaar. Maar men heeft geen zin in het weekend naar kantoor te rijden, dus werd zo'n wachtwoord bestand naar een server gekopieerd.. Tegenwoordig met de cloud drives is dat sterk afgenomen..

Het afgelopen jaar ben ik bij zo'n 16 (kleine) bedrijven over de vloer geweest, slechts twee hadden een administrator welke aan rechten beheer deed.. Want voor die drie computers waarmee ze beginnen, zetten ze geen DC neer. Dus iedereen is local admin. Bij 1 bedrijf met een DC kwam ik wel een aparte constructie tegen. De beheerder had gelezen dat om AD goed werkend te krijgen hij twee domain controllers nodig had. Dus wat had hij gedaan: Op een oude computer had ie Hyper-V geinstalleerd en virtueel twee keer Windows 2008 R2 geinstalleerd en beide VM instances als DC ingesteld.. Ik had op dat moment er veel moeite om mijn lach in te houden..

Ik wou alleen even aangeven dat ik wel degelijk weet hoe situaties zoals bij Instagram ontstaan. Maar ook bij bedrijven welke gespecialiseerd zijn in beveiliging gaat het niet altijd goed. Vandaag een bericht dat bij Juniper onbekende code in de VPN client is terecht gekomen voor enkele jaren. Moet een hacker toch toegang gekregen hebben tot version control en dus zal er toch iets in de autorisatie niet goed hebben gestaan..

H!GHGuY

@Rob Coops • 19 december 2015 09:45

Waar solliciteer ik?

De feedback die ik van verschillende kanalen hoor is dat het tegenwoordig bij alle bedrijven hetzelfde is: zo snel mogelijk nieuwe features buiten duwen, al de rest is bijzaak. Bij ons was het ook ooit anders, maar nu...

MAX3400
18 december 2015 15:51

Tja, wat moeten we hier mee? Als je bewust bcrypted bestanden gaat proberen te ontsleutelen en dat lukt je binnen enkele minuten en daarna "redelijk random" de gevonden data gaat invoeren in andere diensten/omgevingen om aan te tonen dat mensen een fout maken (het niet wijzigen van passwords), dan ben je wel enigszins naief bezig.

Op het moment dat "de bekende bekende" de tip geeft over een server die niet goed beveiligd zou zijn, dan lijkt het me niet meer dan denkbaar dat je dat ook doorgeeft aan de eigenaar van de server. Mogelijk krijg je daar dan een beloning of bedankje voor en klaar.

In tegenstelling tot anderee berichten op Tweakers, zoals het voorstel van de Nederlandse overheid om de politie ook vrije hand te geven in het doorbreken/aanpassen/installeren van machines; de overeenkomst is wel heel erg duidelijk nu. Als je je beroept op "bounty bugs" mag je ineens van alles claimen maar als je je beroept op "staatsveiligheid" dan staat Bits of Freedom en het halve internet op zijn achterste benen.

+2 jaquesparblue
@MAX3400 • 18 december 2015 16:26

Misschien inlezen in de Bug Bounty regels? Er is niks dat stelt dat bugs zoeken enkel bij de deur moet stoppen, als ze maar gemeld worden zodra ze aangetroffen worden, redelijk repliceerbaar zijn en verder geen misbruik van wordt gemaakt. Waarom zou hij bij A moeten stoppen als B en C duidelijk gaten vertonen?

Facebook maakt het voor zichzelf niet echt makkelijk door de publiciteit te zoeken. Blijkbaar zijn de achterliggende systemen zo lek als een vergiet.

Vexxon

@jaquesparblue • 18 december 2015 18:00

Het is volgens mij Facebook die de publiciteit op zoekt.
Als de regels inderdaad zo zijn zoals jij zegt dan vind ik nog steeds dat hij te ver is gegaan. Hij heeft een lek gevonden en is het daarna gaan misbruiken om nog meer te vinden.

Noeandee
@Vexxon • 18 december 2015 19:26

Wat is daar mis mee..? Wat deze man heeft gedaan valt gewoon onder een goede pen-test. Penetration tests gaan gewoon door tot ze admin rechten hebben en gevoelige/bedrijfskritische data kunnen benaderen en manipuleren. Wat heb je anders aan een penetration test als ze alleen testen of ze kunnen binnen komen?

+2 Rmg
@Noeandee • 18 december 2015 21:41

Als je ons voldoende tijd geeft om op je melding te reageren voordat je informatie openbaar maakt, en een bonafide inspanning levert om schending van de privacy, vernietiging van gegevens en onderbreking of aantasting van onze service tijdens je onderzoek te voorkomen, dienen we geen aanklachten tegen je in en vragen we de politie niet om een onderzoek naar je te doen.

Geen interacties uitvoeren met andere accounts zonder toestemming van hun eigenaren.

Aan een bug bounty hangen gewoon regels. En met het decrypten en gebruiken (!) van accounts, het downloaden van programmatuur, data van email servers enz enz, is hij buiten de regels gegaan.

Een ingehuurde penetrationtester houd zich ook aan de 'spelregels'.

Facebook heeft met betrekking tot de bug juist gehandeld en snel opgelost. Wat ze met de useraccounts en keys hebben gedaan is gissen. Misschien is Wineberg daar iets te weinig voor beloond en heeft Facebook op dat punt fouten gemaakt.

Wineberg is verder gegaan dan nodig was en mocht volgens de 'regels van het spel'

Beiden zijn ze niet vrij van blaam

[Reactie gewijzigd door Rmg op 18 december 2015 21:44]

+1 Red_inc
@Vexxon • 18 december 2015 19:18

Is er misbruik gepleegd? Ik vind van niet. Heeft hij alles door verkocht aan 3de partijen. Nee, Heeft hij systeem om zeep geholpen? Nee. Hij heeft wel gevonden dat Facebook zijn beveiliging totaal niet op orde heeft. Dat er totaal stomme wacht woorden gebruikt worden. In feite brengt hij totale onkunde aan het licht. En wat doet hij met die informatie.? Die levert hij netjes af bij jawel Facebook. Voor een zakcentje... Pfff. een miljoenen bedrijf maar Incompetentie eerste klas bij de systeem beheerders van Facebook een gigantische blamage. Ipv deze man bedanken voor het feit dat hij vertelt dat zodra je binnen bent bij face book is de totale beveiliging niet op orde. Nee proberen ze hun onkunde te verbergen dat de backend van Facebook zo lek is als een mandje en hem als hacker te bestempelen... Pfff dit is idd ook iets wat kwaad willen hadden kunnen doen. denk daar maar eens over nawat een chaos dat gegeven had ik denk dat Facebook de deuren wel had kunnen sluiten als alle gegevens op straat hadden komen te liggen. .

kwakzalver
@Red_inc • 18 december 2015 20:24

Ipv deze man bedanken voor het feit dat hij vertelt dat zodra je binnen bent bij face book is de totale beveiliging niet op orde. Nee proberen ze hun onkunde te verbergen

Precies de reactie van Facebook zorgt voor een averechts effect.
En wat voor effect sorteert dit voor Facebook?

Met deze akties krabt eenieder zich even achter de oren als ze een bug vinden om het te melden...

0 Omnicron
@kwakzalver • 18 december 2015 21:12

Pcsies,Reden dus om vooral weg te blijven met je gevoelige data !

0 Jael_Jablabla
@Red_inc • 19 december 2015 10:17

Is er misbruik gepleegd? Ik vind van niet.

Je beschrijft duidelijk dat er geen sprake is van misbruik. Ik vraag me af wat er zou gebeuren als hij over een jaar zegt "Ik heb 10 lekken ontdekt, maar ik hou mijn mond en kijk toe hoe dit gaat uitpakken". Wat ik hiermee wil zeggen is dat ik mij afvraag of Facebook zijn hackresultaten wel zou waarderen. Hoe je binnenkomt in een systeem van Facebook lijkt mij behoorlijk waardevolle informatie, maar die informatie wordt kennelijk niet door Facebook gewaardeerd.

0 Red_inc
@Jael_Jablabla • 19 december 2015 11:04

Facebook heeft de bug Hunt. Iedereen die bugs vind kan daar aan deel nemen. Of dat verstandig is.... Het koste deze onderzoeker zijn baan. Dus front end bug melden, ernstige beveilings lekken in de backend lekker laten zitten. Is de filosofie. Ik heb iedereen die ik ken een berichtje gestuurd met de link naar forbs en de sterke aan beveling er bij zijn paswoord te resetten

+1 dnrb
@Vexxon • 18 december 2015 19:09

Ik ben het hier niet mee eens, je hebt lekjes, lekken en dijkdoorbraken.
Dit valt onder de categorie dijk doorbraak. Je kan namelijk code injecteren in zeer veel gebruikte software, en daarmee dus ook met de computers van de gebruikers.
Een lekje is als je de namen kan zien van alle gebruikers.
Een lek als adres of email ook te vinden is
Dit of credit card gegevens... Dijkdoorbraak.
Hier moet onmiddellijk met alle mankracht 24/7 aan gewerkt worden. Zeker als je in het achterhoofd houd dat overheden dit soort lekken ook erg graag misbruiken.
Daarvoor moet je ook de impact van een lek analyseren. En monitoren of het lek gezien de impact snel genoeg gedicht wordt.

0 Jowwy
@dnrb • 22 december 2015 00:59

Heb je ook helemaal gelijk in maar er zijn simpelweg niet genoeg black/grey/white hatters om jouw reactie de aandacht te geven die hij verdient.

Het is ook simpel om te bedenken wat voor een "shitstorm" het zou zijn geweest als al deze data lekker werd gedownload en doorverkocht maar ja nu dat niet is gebeurd is het makkelijk de beveiliger de 'boze wolf' te noemen dan Facebook.

Maar ja, men moet nooit naïviteit onderschatten.

+1 Nicael
@MAX3400 • 18 december 2015 15:59

Dat komt omdat "staatsveiligheid" te pas en te onpas word gebruikt en de illusie geeft dat er dingen gebeuren die het daglicht niet kunnen verdragen.

Daarentegen is "bounty bugs" bedoeld om problemen op te lossen. Als die problemen verder gaan dan alleen de outer wall dan is het, naar mijn mening, een goed vervolg. Omdat je bent ingehuurd om het probleem op te lossen.

Als je iemand inhuurt om je huis te beveiligen en deze alleen aangeeft de sloten te verbeteren. Terwijl de scharnieren van de deur ook verrot zijn. Dan wil je toch dat diegene dat ook aangeeft anders zet het ook geen zoden aan de dijk,

xoniq
@Nicael • 18 december 2015 16:18

Of je vraagt iemand die de sloten van de buitendeuren moet nalopen, en die gaat vervolgens afgesloten kamers kraken omdat die ook zwakke sloten hebben om daar rond te neuzen waar ie niks te zoeken heeft. Dat is een vergelijking die wat meer op z'n plek is lijkt me.

+2 maxtrash
@xoniq • 18 december 2015 19:03

hij vindt een fout in het slot van een van de 200 deuren van de bank. Tot zover niet zo veel aan de hand, want dan kun je normaal gesproken alleen wat kantoor meubilair meenemen. Vervolgens vindt hij onder het bureau een briefje geplakt met de code van de kluis. Daar blijkt 100 miljoen in te liggen.

De 2e (en 3e en 4e) fout was nooit aan het licht gekomen als hij niet verder gekeken had (wat waarschijnlijk inderdaad niet mocht)

De bounty rules zijn dat je betaald krijgt op basis van de impact die de fout kan hebben. Omdat de bank te stom was om onder het bureau te kijken, kwamen ze uit op 2500 dollar.

...en nu FB heeft hun reputatie op dit gebied grondig verneukt

vSchooten
@xoniq • 18 december 2015 17:11

ik denk eerder dat ie hiermee laat zien hoe gevaarlijk deze lek wel niet is...

0 koelpasta
@vSchooten • 18 december 2015 17:28

Als je vanaf het begin al remote code execution hebt dan is het lek al eigenlijk maximaal gevaarlijk. Wat hij heeft gedaan is dat lek nog eens misbruiken om weer andere dingen te doen.

0 Jowwy
@koelpasta • 22 december 2015 01:05

Niet misbruikt sinds hij de data nooit heeft beschadigd of kenbaar heeft gemaakt, dat hij deed is de technische limieten van het gevonden betalingsproblemen testen, je haalt de twee door de war

+1 Annihlator
@xoniq • 18 december 2015 17:32

Nee, hij heeft gewoon de kluizen open gemaakt die met behulp van dezelfde voordeursleutel (in dit geval een 'loper').
Hoe ver je kan komen met één sleutel, óók al verschaft die je alsnog andere sleutels, is alsnog van oorsprong van die ene sleutel.
Je wilt niet weten in hoe veel andere gevallen blijkt dat je van het ene administratieve account je sleutels van een andere entiteit kan ontfutselen, terwijl dat van oorpsrong niet per sé nodig had geweest. Dít soort risico's zijn op vooral deze wijze aan te tonen, net zoals v Schooten eigenlijk ook al stelt.

+1 Durandal
@xoniq • 18 december 2015 17:37

Of je vraagt iemand die de sloten van de buitendeuren moet nalopen, en die gaat vervolgens afgesloten kamers kraken omdat die ook zwakke sloten hebben om daar rond te neuzen waar ie niks te zoeken heeft. Dat is een vergelijking die wat meer op z'n plek is lijkt me.

Zoals ik het lees is gevraagd de sloten na te lopen, niet enkel de sloten van de buitendeuren. Dat de sleutels van de binnendeuren op tafel liggen is natuurlijk niet echt veilig.

0 Gomez12
@xoniq • 19 december 2015 01:35

Allebei gaan ze krom, want er is niemand gevraagd.

Bounty bugs zijn meer briefjes op de voordeur of inbrekers aub niets willen stelen en netjes op papier willen zetten hoe ze zijn binnengekomen inclusief adresgegevens zodat je wellicht een stuiver naar de inbreker kan overmaken.

0 mae-t.net
@xoniq • 20 december 2015 01:07

De eerste les, letterlijk, van een vak als computerveiligheid stelt dat je de beveiliging altijd moet afstemmen op wat er beveiligd moet worden. Nadat de consultant de sleutel onder de deurmat heeft gebruikt om het huis binnen te komen, doet hij vanzelfsprekend een evaluatie van de benodigde beveiliging en daarvoor wandelt hij een paar keer door het huis om te voelen aan deurklinken en te kijken achter schilderijen. Na een opvallend boek uit de boekenkast genomen te hebben ontdekt hij een weggemoffeld briefje met de code van de kluis die hij al eerder achter een schilderij zag zitten. Hij concludeert dat de beveiliging van de buitendeur in elk geval beter moet, maar dat het ook nog steeds een luilekkerland is voor een inbreker die per ongeluk op een andere manier binnenkomt.

Zoiets bedoel je?

[Reactie gewijzigd door mae-t.net op 20 december 2015 01:08]

+1 Boender
@MAX3400 • 18 december 2015 16:22

Hij heeft het toch goed gedaan. Hij hoorde van een bekende dat een server niet goed beveiligd was, dat heeft die ook kunnen bevestigen en gemeld. Daarna heeft die het 'fout' gedaan volgens Facebook, hij is verder gaan zoeken doormiddel van de fout dat die net gemeld had. Mij lijk dat niks meer dan logisch want zo kon die aantonen, dat de lek groter bleek dan dat die in eerste instantie leek. (al hoewel remote code execution is al een grote lek)

[Reactie gewijzigd door Boender op 18 december 2015 16:24]

+1 Wampa1
18 december 2015 15:50

Je zou denken dat je zou moeten stoppen na het aankaarten van een probleem en het vervolgens neerleggen bij de engineers bij Facebook. Snap inderdaad niet waarom hij doorging.

En misschien ligt dit aan mij, maar een maandsalarisje als beloning bij een miljardenbedrijf voor het aankaarten van toch een serieus probleem..

+1 R3dJ3
@Wampa1 • 18 december 2015 15:50

Door het doorgaan heeft hij wel meerdere issues kunnen vinden. Ik zou dit als FB toch ten harte nemen en niet direct een tegenaanval starten.

[Reactie gewijzigd door R3dJ3 op 18 december 2015 15:52]

David Mulder
@R3dJ3 • 18 december 2015 16:06

Het lastige is dat je onderscheid moet kunnen maken tussen malafide hackers en gray hat hackers. Als Facebook nu zo iets zou hebben van: Oh, prima, bedankt! Dan kan iedere hacker doen wat hij wilt en zich daarna op hun bounty programma beroepen mocht hij toevalligerwijs gepakt worden. Er is gewoon een bepaald moment dat je te ver gaat en dit was dat duidelijk en ja, daar moet je je als bedrijf gewoon tegen verdedigen.

vSchooten
@David Mulder • 18 december 2015 17:13

Hoezo is hij te ver gegaan?
Wat ik zie is een poging om het potentiële gevaar van die lek te ontdekken...
Voor zover ik het heb kunnen volgen heeft hij geen data vrijgegeven en heeft hij dat netjes gemeld bij facebook...

David Mulder
@vSchooten • 18 december 2015 17:15

En hoe moet Facebook weten wat hij met die data heeft gedaan? Hij heeft een lek gevonden op een publiek toegankelijke plaats: prima. Maar als je eenmaal binnen bent mag je niks, maar dan ook niks doen. Alles wat je daar wel doet is te ver. Voor wat er achter de muur is heb je white hat hackers, als je daar als gray hat hacker gaat rondklooien dan zet je een zwart hoedje op, zo simpel is het.

vSchooten
@David Mulder • 18 december 2015 17:19

dus als je een gat in de deur hebt gevonden mag je ook niet verder kijken of er iets anders kapot is? is dat niet de reden waarom ze deze bounties hebben?

David Mulder
@vSchooten • 18 december 2015 18:08

Nope, het idee is juist dat je iemand bedankt voor het melden van een gat in je deur. Op het moment dat je iemands huis binnenkruipt via een gat in de deur en daarna z'n kluis probeert open te forceren ben je echt niet meer goed bezig. Dan kun je niet zeggen 'oh ik was alleen even aan het kijken of het wel goed beveiligd was'. Facebook huurt haar eigen mensen in om security audits intern te doen (white hat hackers), als ik plots iemand in mijn huis aantref en hij me verteld dat hij een security expert is die het gewoon even aan het testen was dan bel ik ook de politie.

Rutix

@David Mulder • 18 december 2015 18:43

Dat is jou idee. Maar op https://www.facebook.com/whitehat staat nergens dat je moet stoppen als je een lek hebt gevonden. Er staat zelfs in de Eligibility hoofdstuk dit:

Report a bug that could compromise the integrity of user data, circumvent the privacy protections of user data, or enable access to a system within our infrastructure, such as:

Dus je mag zeker wel access to a system onderzoeken.

Er staat ook dit:

Responsible Disclosure Policy
If you give us reasonable time to respond to your report before making any information public, and make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.

En volgens mij heeft hij zich daar gewoon aangehouden.

Uit die hele pagina blijkt juist dat facebook het aanmoedigt om via dit program bugs te vinden. Ik vind het dus ook kinderachtig dat als iets uit komt waaruit blijkt dat ze zo lek waren als een mandje ze lopen te klagen.

David Mulder
@Rutix • 18 december 2015 19:44

Ja, en Facebook heeft zich exact gehouden en bij de eerste bug gewoon netjes hem beloond. Let wel, je eigen document stelt

and make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.

Actief misbruik maken van een bug om prive gegevens van Facebook te achterhalen valt daar niet onder hoe je het ook went of keert.

Rutix

@David Mulder • 18 december 2015 20:45

Ten eerste heeft hij geen misbruik gemaakt van de bug maar een keten aan security holes aan de kaak gesteld, hij heeft de service niet onderuit gehaald, hij heeft geen data geleakt, hij heeft geen data vernietigd en hij heeft ook geen privacy violations begaan. Dus even in jou woorden "hoe je het ook went of keert" heeft deze whitehat zich gewoon gehouden aan de regels die facebook heeft gesteld. Ze mogen blij zijn dat hij er zo achter kwam en het aan ze heeft gemeld ipv van een malafide hacker.

David Mulder
@Rutix • 18 december 2015 21:36

He? Data weg downloaden uit een beveiligde omgeving is plots okay? Serieus? Ik weet nu niet eens meer of je aan het trollen bent of nog serieus bent...

En ja, dat is exact wat hij heeft gedaan... dat is zelfs iets wat nog eens expliciet in de wet verboden is en tot extra zware straffen leid (gegevens uit een ingebroken computer vastlegt, zelfs al is het alleen voor jezelf). En om het nog eens extra leuk te maken heeft hij de ingebroken computer ook gebruikt als startpunt voor een verdere inbraakpoging wat een ander punt is waar hij in Nederland extra zware straffen voor zou krijgen. Dus nee, het weg downloaden van extreem gevoelige informatie uit een beveiligde omgeving om daarop binnen te proberen te breken op z'n lokale computer is echt niet okay.

[Reactie gewijzigd door David Mulder op 18 december 2015 22:07]

ItsNotRudy
@vSchooten • 18 december 2015 18:33

In dit geval klimde deze meneer door het gat naar binnen en rende hij met een handvol spullen weer naar buiten.

0 Bruin Poeper
@David Mulder • 18 december 2015 18:11

Ik zie niet in waarom een nette hacker zich netter moet gedragen dan een malafide hacker.

Hacken is nu eenmaal dat je je niet aan de 'normale' regels houdt.
Of simpelweg niet aan een verwachtingspatroon voldoet...

David Mulder
@Bruin Poeper • 18 december 2015 18:13

Naja, als je je niet aan de normale regels houdt dan is er toch niks mis mee als je door de normale regels (wetten) vervolgt word net zoals de malafide hacker?

+1 Bruin Poeper
@David Mulder • 18 december 2015 21:57

Aan welke regels moet een hacker zich dan houden volgens jou?
Alsof er een wetboek voor boeven(-bestrijding) bestaat.

Nu ja, er zijn ongeschreven regels. Maar die gelden zo lang ze gelden. Eén van de bekende strategieën om verder te komen is: 'breaking the rules'

Droom jij maar lekker verder met je 'normale regels (wetten)'... ik vind ze niet normaal.

[Reactie gewijzigd door Bruin Poeper op 18 december 2015 22:00]

David Mulder
@Bruin Poeper • 18 december 2015 22:03

Ehm, wat denk je van computervredebreuk, het 'opzettelijk en wederrechtelijk binnendringen in een geautomatiseerd werk of in een deel daarvan'. En binnendringen is relevant als:

1. er een beveiliging is doorbroken
2. door een technische ingreep
3. met behulp van valse signalen of een valse sleutel, of
4. door het aannemen van een valse hoedanigheid.

En ja, daar kun je gewoon voor de gevangenis in worden gegooid (maximaal een jaar). En vastleggen van gegevens voor zich zelf bijvoorbeeld (wat deze hacker dus deed) en de ingebroken computer gebruikt als startpunt voor een verdere inbraakpoging in een andere computer (wat deze hacker ook deed) kan dat nog eens vervierdubellen naar maximaal 4 jaar. Meer hierover op wikipedia: http://www.wikiwand.com/nl/Computervredebreuk

+1 Bruin Poeper
@David Mulder • 18 december 2015 22:23

Tsja, het gesnuffel van Facebook is natuurlijk 'legaal'.

Welja, maar persoonlijk vind ik het illegaal. Zo 'immoreel' ben ik nou.
De wetgever laat me danig in de steek. Waarom zou ik zo'n wetgever nou respecteren?
Waarom zou ik een wetgever respecteren die zelf snuffelt?

[Reactie gewijzigd door Bruin Poeper op 18 december 2015 22:25]

0 Gomez12
@David Mulder • 19 december 2015 01:31

White / Gray hatters zijn enkel black-hatters die gepakt zijn of die van 2 walletjes proberen te eten

+1 Wampa1
@R3dJ3 • 18 december 2015 15:54

Ja als je het zo bekijkt is dat ook weer waar. Maar toch moet het niet goed voelen dat terwijl je de boel probeert op te lossen, iemand remote nog verder zit te wroeten

+1 Gomez12
@Wampa1 • 19 december 2015 01:28

Ja als je het zo bekijkt is dat ook weer waar. Maar toch moet het niet goed voelen dat terwijl je de boel probeert op te lossen, iemand remote nog verder zit te wroeten

In principe is het irrelevant of er iemand verder zit te wroeten als je niet nog meerdere flaws hebt.

Gaat die persoon niet verder wroeten dan ga je die diepere flaws nooit fixen (want je weet er niet van)

0 olivierh
@R3dJ3 • 18 december 2015 16:03

Beetje offtopic, maar in Amerika is dat geen maandsalaris, de salarissen liggen daar aanzienlijk hoger dan hier.

0 killzonex
@olivierh • 18 december 2015 16:27

Levensonderhoud ook dus eigenlijk compenseert het weer

beun92
@killzonex • 18 december 2015 16:32

dan is juist de waarde van het uitbetaalde beloning lager dan wanneer wij het zouden ontvangen in euro's.
natuurlijk is het een mooi bedrag om te krijgen maar als je ziet wat de waarde van de bug echt is (schade wat het bijv kan aanrichten als het in verkeerde handen komt bijv.) dan is het naar mijn mening een beschamende beloning voor zo'n groot bedrijf.

+1 gladius1983
@beun92 • 18 december 2015 21:37

Je zou bijna zeggen dat het interessanter is om je verhaal te verkopen aan een nieuwsbureau? Dan vang je er meer voor dan om het goede te doen.

0 Gomez12
@killzonex • 19 december 2015 01:30

Nope, het maakt het verschil enkel maar groter.

Want met die 2500 kan je dus ook slechter in je levensonderhoud voorzien omdat die ook hoger ligt.

+1 Rivanni
@Wampa1 • 18 december 2015 16:47

Je zou denken dat je zou moeten stoppen na het aankaarten van een probleem en het vervolgens neerleggen bij de engineers bij Facebook. Snap inderdaad niet waarom hij doorging.

Wie zegt dat de engineers van Facebook er mee aan de slag zouden zijn gegaan. Zouden zij ook die nieuwe zaken gevonden hebben of enkel het punt aangepakt hebben waarmee hij als eerste bij Facebook aanklopte?
Facebook vraagt mensen om te zoeken naar fouten dus moeten ze niet moeilijk gaan doen als er nog meer gevonden wordt. Laat ze er blij mee zijn en de problemen oplossen.

Een paar duizend dollar voor een miljarden bedrijf die door de kwetsbaarheden flinke schade kan oplopen is natuurlijk ook een lachertje.

+1 RGAT
@Rivanni • 18 december 2015 17:14

Dat is verder niet het probleem van de hacker of de partij waar het lek zit er (genoeg/iets) aan doet.
En het kraken van wachtwoorden en daarmee vervolgens inloggen op S3 storage heeft ook niets meer met het bug bounty programma te maken maar puur met kijken hoe ver je kan gaan. Prima, maar dan weet je zelf ook al heel goed dat je de spelregels al lang gebroken hebt...

Seroczynski
@Wampa1 • 18 december 2015 15:52

Hij heeft hiermee wel aan kunnen tonen dat los van de eerste breach er nog veel meer mankeerde aan de beveiliging. Het lijkt erop dat de medewerkers zo veel vertrouwen hebben gehad in hun 'outer wall' dat ze vervolgens onzorgvuldig zijn geweest met het kiezen van wachtwoorden.

+1 mkools24
@Wampa1 • 18 december 2015 15:56

Puur uit nieuwsgierigheid denk ik ik snap dat wel. Indrukwekkend om te zien hoe je met wat in eerste instantie een klein gaatje lijkt steeds verder door kunt gaan en uiteindelijk zo'n beetje superadmin van heel Instagram kunt worden.

M-Opensource
18 december 2015 15:50

Oei, dit is toch wel een flink lek.. Wellicht niet helemaal netjes van hem om zo ver het systeem in te duiken, maar hij heeft het aan Facebook gemeld en niet openbaar gemaakt. Ik denk dat ze hem best dankbaar mogen zijn.

Weet niet wat de normale beloning is, maar iets meer dan 2500 dollar klinkt wel op zijn plaats als je het mij vraagt. Als dit lek misbruikt was had Instagram echt een klap gehad.

+1 mkools24
@M-Opensource • 18 december 2015 15:57

Ik denk inderdaad dat hij er op de zwarte markt een veelvoud voor had kunnen krijgen. 2500 dollar is echt een fooi zeker voor facebook en zeker voor een lek van deze magnitude.

+1 bbob1970

Facebook
Beheer en beveiliging

@mkools24 • 18 december 2015 16:27

Het is een typsiche reactie van een groot bedrijf als iemand echt een groot gat kan vinden.
Als je het artikel lees dan zijn de wachtwoorden bovendien zwak om het zacht uit te drukken.

Voor mij tonen dit soort zwakke wachtwoorden zelfs aan dat men het niet zo nauw neemt met de beveiliging, want van het ene zwakke wachtwoord krijg je als een domino toegang tot vele andere zaken.

Hij laat zet hiermee facebook voor schut en dat doet pijn. Dat verklaard de trieste reactie om te stellen dat hij te ver gegaan is.

Te ver zou pas zijn het misbruiken en op de markt gooien.

Dit wetende moet je je als gebruiker van facebook / instagram dus heel sterk afvragen of jou dat daar echt niet voor andere toegankelijk is als me zulke zwakke wachtwoorden gebruikt.

+1 Gomez12
@bbob1970 • 19 december 2015 01:25

Dit wetende moet je je als gebruiker van facebook / instagram dus heel sterk afvragen of jou dat daar echt niet voor andere toegankelijk is als me zulke zwakke wachtwoorden gebruikt.

Waarom dit wetende?

Vertrouw gewoon simpelweg geen enkele internet site en je bent al een stuk verder.
Digitale data is bijna per definitie openbaar toegankelijk, het is slechts een kwestie van wanneer...
Het kan zijn dat zwakke wachtwoorden het openbaar maken, maar het kan net zo goed een verbitterde ex zijn die zijn/haar ex-partners wachtwoorden weet.

Als je iets privé wilt houden zet het gewoon niet digitaal weg en zeker niet op een social media platform.

+1 geertdo
@mkools24 • 18 december 2015 16:41

Ik denk inderdaad dat hij er op de zwarte markt een veelvoud voor had kunnen krijgen.

Niet alleen zwarte markt. Hij kreeg een veelvoud van 10 ($24.000) van Microsoft voor het hacken van Hotmail.

+1 Tweade
@M-Opensource • 18 december 2015 16:08

Of het netjes is of niet, de beveiliging was in ieder geval een flinke puinbak. Dus goed dat hij dat aan de orde heeft willen stellen, ongeacht de voorwaarden van het bounty programma. Immers, figuren met minder goede bedoelingen houden zich ook niet aan die voorwaarden.

En Facebook snapt ook wel dat ze het niet netjes op orde hadden, dus ze proberen gewoon de aandacht af te leiden.

[Reactie gewijzigd door Tweade op 18 december 2015 16:22]

NotSoSteady
@M-Opensource • 18 december 2015 16:14

Lijkt mij ook, maar had hij ook niet beter eerst kunnen zeggen wat een juiste beloning in zijn ogen was in plaats van alles eerst vrij te geven.

RoffaboyS
@M-Opensource • 18 december 2015 16:26

Of een baan bij facebook als digitaal beveiliger lijkt mij op z'n minst redelijk.

Dograver
18 december 2015 15:54

Dus als ik de tijdlijn doorlees, dan zou hij NA het melden verder op onderzoek uit zijn gegaan.

Plat gezegd, omdat je tot de conclusie bent gekomen dat de deur van je buurman niet op slot zat heb je dat eerst gemeld. Omdat je daar toch mooie apparatuur binnen hebt zien staan ga je vervolgens nog wel even naar binnen om te gluren, simpelweg omdat de deur nog niet "gepatched" is

Nu kan ik mij voorstellen dat je tot aan het punt dat je het meldt "recht" hebt op die 2500 dollar.
Daar is het bug bounty program immers voor.
Maar omdat je daarna nogmaals zonder expliciete toestemming jezelf nogmaals toegang verleend buiten de reguliere paden om ben je volgens mij aan het hacken en strafbaar.
Je maakt immers gebruik van een inmiddels bekend lek.
Het lijkt me hierdoor niet eens raar als Wesley dit geld nu ook nog moet terugstorten.

Echter is de andere kant van het verhaal dat hij wel doorgaat tot de kern van het probleem zodat het lek nu wel in 1 keer goed opgelost kan gaan worden.

Moeilijke zaak. Snap het van beide kanten wel.

[Reactie gewijzigd door Dograver op 18 december 2015 16:01]

dfr0st
@Dograver • 18 december 2015 16:30

Of je kan het zo zien: buurman zegt als je mijn huis binnen kan komen dan geeft ik je 2500,-

Jij komt zijn huis binnen en stuurt je buurman een smsje. Maar ziet dan een kluis staan, je toetst de code 0000 (gelijk aan 'changeme', 'password' en 'instagram') in en de kluis gaat open. Daarin kom je een bos sleutels tegen die toegang geven aan alle deuren in het huis plus auto's etc.

Je meld aan je buurman dat naast de voordeur slot hij beter de code van de kluis ook moet veranderen of moet uitbreiden met een extra beveiliging.

+1 TheMak
@dfr0st • 18 december 2015 18:12

Ik zie het anders, je bent de huis van de buurman binnen gelopen. En je ziet dat de sleutel in het kastje onder de televisie nog nooit er uit gehaald is, en je gaat vervolgens zijn persoonlijke DVD's bekijken die je in het kastje vindt. Dit onder het mom van een lek van de beveiliging van het kastje.

+1 dnrb
@TheMak • 18 december 2015 19:26

Sorry, maar voor goede beveiliging is het juist belangrijk dat je niet veel verder kan komen als je door de voordeur bent. En toegang tot de broncode is echt in de kluis die in de kluis staat komen.
Goede beveiliging staat of valt ook als er geen "fail save" mentaliteit is. En dat was hier zeker niet het geval. Helaas zijn er meer organisaties die veel te veel op de buitenmuur vertrouwen.

0 Gomez12
@Dograver • 19 december 2015 01:39

Maar omdat je daarna nogmaals zonder expliciete toestemming jezelf nogmaals toegang verleend buiten de reguliere paden om ben je volgens mij aan het hacken en strafbaar.

Bounty bugs proberen te pakken is per definitie al hacken en strafbaar, de bounty bug is enkel een toezegging van het slachtoffer dat die geen actie gaat ondernemen mits. Bounty bugs maken niets uit voor of het hacken is of niet (en of het strafbaar is of niet)

doenietzodom
18 december 2015 16:14

Ik snap niet zo goed waarom mensen überhaupt zulke makkelijke wachtwoorden gebruiken, als bedrijf heb je hier toch wel een policy over?

eborn
@doenietzodom • 18 december 2015 16:40

Zonder het goed te praten, maar tegenwoordig hangen dit soort infrastructuren van zoveel losse applicaties aan elkaar die allemaal weer hun eigen wachtwoord regels en opslag hebben, met of zonder keys en 2-factor authentication. Policies handhaven is dan erg lastig en in de meeste gevallen geldt: zolang het goed gaat....

+1 robsky
18 december 2015 21:17

Alles wat hier gezegd wordt is een aanname. Een bug bounty program alswel pentests gaan vergezeld van een contract waarin de scope van de test en andere randvoorwaarden zijn opgenomen. Kennelijk bood dat contract ruimte voor interpretatie. Dat is in elk geval wat de onderzoeker beweert en facebook ontkent. De rechter dient uitsluitsel te geven. Tot dan toe is er sprake van enig speculatie immers wat er contractueel is overeengekomen wordt niet duidelijk uit dit artikel.

WhatsappHack

Facebook
Beheer en beveiliging

@robsky • 19 december 2015 03:14

Er is geen sprake van een contract, eerder van regels... FB heeft een Responsible Disclosure policy waar iedereen aan kan deelnemen en vergoedingen krijgt, mits je je maar aan de regels houdt.
Ik vind de regels niet bijster open voor interpretatie. Althans, niet zo ver als dit gegaan is.

https://www.facebook.com/whitehat/

0 robsky
@WhatsappHack • 19 december 2015 08:27

je hebt gelijk het gaat hier om een resp discl. policy. Alleen het ontvreemden van data van een systeem van derden is diefstal. Hoe die relatie ligt met disclosure policies en whitehat hacking en jurisprudentie weet ik zo gauw niet. Dat maakt de zaak iets anders aangezien het hier gaat om het melden van beveiligingsgaten en reserach die daarvoor nodig is en volgens de policy is toegestaan. Dus valt downloaden van credentials stores e.d. ook onder research? Het gebruiken van andermans accounts, hier voor privilege escalation, is op de manier waarop dit hier gebruikt is volgens de policy wel toegestaan.
FB heeft in principe een punt om te klagen over het downloaden van sensitive data (passwd databases) en misschien zelfs een rechtszaak aan te spannen.

WhatsappHack

Facebook
Beheer en beveiliging

@robsky • 19 december 2015 16:19

Tja... Hoe triest het ook is, hackers (ook die met de allerbeste bedoelingen) hebben totaal geen bescherming in dit geval. Elke vorm van hacking is in principe verboden, en daar kan je zwaar voor gestraft worden. Daarom worden veel beveiligingsproblemen ook lekker onder de pet gehouden (of verkocht op de zwarte markt) omdat mensen doodsbang zijn aangeklaagd te worden door de partij die ze proberen te helpen...

Dat is dan ook de reden dat bedrijven zo'n RD policy in het leven hebben geroepen, dat kan je dan nog deels als uitnodiging en goedkeuring zien voor het hacken en dat zou je enorm helpen in een rechtszaak; maar als het bedrijf vind dat je iets doet dat niet mag en je gaat te ver, ben je theoretisch alsnog de lul en kan je inderdaad zo voor de rechter verschijnen met minder kans op een happy ending...

Dat is erg jammer, maar ook lastig op te lossen. Straks krijg je situaties dat black hat hackers gaan claimen dat ze t allemaal deden om het bedrijf te helpen, en dan zou vrijspraak moeten volgen.

Al kan je dat lang niet altijd aannemelijk maken natuurlijk... Maar zo'n RD policy wil wel al enorm helpen en is al een grote stap verder dan waar we een paar jaar geleden waren... Helaas is het aantal bedrijven met een RD policy te verwaarlozen... En zo blijven veel grote bedrijven kwetsbaar. Blijkbaar hebben ze liever een hacking schandaal dan dat ze veilig worden gehouden. Mensen vergeten dat hackers, en veel van de "originele hackers", heel veel goeds doen in de wereld en mensen veilig houden; het is jammer dat mensen veelal negatief denken over hackers, ondanks dat ze er ook een bepaald stereotypisch ontzag voor hebben.

Het is mooi dat bedrijven als Google, FB, Microsoft, etc. allemaal zo'n policy hebben, maar we zijn er nog lang niet.

In principe kan FB deze man inderdaad aanklagen. Ik gok dat ze dat niet gaan doen, maar het kan wel en dan heeft ie, zeker in de "wij straffen absurd hard" VS, een behoorlijk probleem. Ik vind het wel goed dat FB dat recht heeft, immers is dit een lastige zaak daar je niet weet wat hij met de gedownloade data doet of heeft gedaan... En op dat vlak was het inderdaad een stapje te ver, en een groot risico dat hij nam door de policy te negeren en verder te hacken dan is toegestaan, zonder toestemming.

[Reactie gewijzigd door WhatsappHack op 19 december 2015 16:20]

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Onderzoeker ontdekt Instagram-lek en raakt in conflict met Facebook

Lees meer over

Nieuwste IT Banen

LOI ICT Opleidingen

Gerelateerde content

Sorteer op:

Weergave:

Reacties (114)