Facebook betaler rekordstor findeløn til hacker for fund af sikkerhedshul

24. januar 2014 kl. 10:113
Facebook betaler rekordstor findeløn til hacker for fund af sikkerhedshul
Illustration: iStockphoto.com.
En sårbarhed i kommunikationen mellem Facebook og OpenID gav mulighed for at bruge Facebook til DDoS-angreb. Facebook udbetaler rekord-findeløn.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Facebook har betalt en sikkerhedsekspert 184.000 kroner i findeløn, for at have opdaget og indberettet en seriøs sårbarhed i det sociale netværk. Det skriver Zdnet.

Sårbarheden, der udløste Facebooks største udbetaling af findeløn nogensinde, lå i den kode, der bruges til implementering af autentificeringsstandarden OpenID. OpenID giver mulighed for at oprette et login hos en godkendt identitetsudbyder og derpå bruge den til at logge på alle sider, der accepterer brug af OpenID.

Men i november sidste år opdagede it-ingeniøren Reginaldo Silva, at kommunikationen mellem Facebook og OpenID var usikker, hvilket blandt andet gav mulighed for at bruge Facebooks båndbredde til DDoS-angreb.
Sårbarheden gav også adgang til lokale filsystemer og mapper, der indeholdt en liste med alle brugerkonti.

Da Reginaldo Silva opdagede dette indberettede han fejlen til Facebook, der lukkede hullet på tre timer og altså udbetalte 184.000kr som tak for hjælpen.

Artiklen fortsætter efter annoncen

Silvas opdagelse har fået både Google, Drupal og Stackoverflow til at stramme op på sikkerheden ved brug af OpenID.

3 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
25. januar 2014 kl. 20:08

Artiklen ovenfor indeholder ingen detaljer om sårbarheden, og snakker om kommunikation "mellem Facebook og OpenID", hvilket må basere sig på en misforståelse, da OpenID er en protokol, og ikke en part, der kan kommunikere. Men i den linkede Zdnet-artikel finder man dog flg. bid, der forklarer problemet:

The mere act of parsing the XML response from a fake provider opens it up to attack due to a known XML external entity processing vulnerability. This vulnerability allows an attacker to specify a URI to be stored in a system identifier, and then call upon that identifier to retrieve data.

Vi er med andre ord endnu en gang vidne til resultatet af XML-parsere, der automatisk følger indlejrede URL'er i XML-dokumenter (såsom DTD-reference), en feature som er fuldstændig sindsyg taget i betragtning at XML-input som hovedregel er untrusted.

Det er ikke første gang at det fører til et DoS-angreb; i 2008 modtog W3C i perioder op til 350 Mb/s trafik fra XML-parsere, der insisterede på at loade DTD'en, hver gang de parsede et XHTML-dokument. Hvilket må siges at være selvforskyldt, siden det nu er W3C selv, der har standardiseret den tåbelige feature i XML...

På trods af at problemet således har været kendt i 6+ år, er det stadig normen at man eksplicit skal slå henting af eksterne resourcer fra. I .NET blev det først rettet med .NET 4.0 fra 2010. I libxml2 blev det først rettet i 2012. I Java er det implementationsspecifikt, både hvorvidt eksterne entitieter hentes som standard, og hvordan det i så fald slås fra. Det er derfor ikke overraskende at Facebook heller ikke har styr på denne "feature".

2
26. januar 2014 kl. 21:30

Du har ret i at der er forskellige tekniske muligheder for at gemme eksterne DTD referencer lokalt så de ikke nødvendigvis skal hentes hver gang. Det bør man selvfølgelig gøre. Jeg synes omvendt ikke det er et specielt godt forslag at man helt holder op med at validere, for så flytter man denne opgave op i applikationslaget hvor det ikke hører hjemme.

Jeg forstår ikke din påstand om at XML input er "untrusted". XML er blot en formaliseret måde at udtrykke sig på, og er på denne måde hverken mere eller mindre trusted end JSON, CORBA, SMTP, Protocol Buffers eller tilsvarende. Trust ligger i infrastrukturen og transportlaget.

3
27. januar 2014 kl. 01:31

[Der] er forskellige tekniske muligheder for at gemme eksterne DTD referencer lokalt så de ikke nødvendigvis skal hentes hver gang.

En DTD kan i praksis sjældent indkapsle al protokolsemantik, så man er tvunget til at lave i hvertfald noget af sin validering i applikationslaget. Men hvis man bruger DTD-validering, skal det selvfølgelig være mod en lokal cache. Hvad skulle pointen være i at automatisk hente en ekstern DTD? Din applikation får jo ikke på magisk vis support for fx MathML, bare fordi den automatisk kan hente DTD'en http://www.w3.org/Math/DTD/mathml3/mathml3.dtd og validere en XML-stump mod den.

Jeg vil derudover sige at en parser af et filformat aldrig skal lave eksterne HTTP requests uden eksplicit tilladelse. Jeg tager mig faktisk til hovedet over at have skrevet den sætning, så absurd er idéen.

Jeg forstår ikke din påstand om at XML input er "untrusted".

Jeg sagde "som hovedregel". Her mener jeg at XML, i højere grad end fx JSON og Protocol Buffers, ofte bruges til dataudveksling med tredjepart i form af standardiserede protokoller/formater. JSON derimod anvendes langt oftere som en intern ad-hoc kommunikationsprotokol (typisk fra server-side til client-side i webapps), og kunne derfor ofte parses med et kald til den ellers pivusikre "eval" funktion, da man kunne stole på indholdet (grundet fx same-origin policy).