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

Illustration: leowolfert/Bigstock
En sårbarhed i kommunikationen mellem Facebook og OpenID gav mulighed for at bruge Facebook til DDoS-angreb. Facebook udbetaler rekord-findeløn.

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.

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

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Søren Løvborg

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".

  • 1
  • 0
#2 Michael Aggerholm

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.

  • 0
  • 1
#3 Søren Løvborg

[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).

  • 1
  • 0
Log ind eller Opret konto for at kommentere