Bug in Twitter maakt plaatsen javascript mogelijk - update

De webversie van Twitter kampt met een lek waardoor gebruikers misbruik kunnen maken van het onMouseOver-event. Speciaal geprepareerde tweets kunnen ervoor zorgen dat javascript automatisch wordt uitgevoerd bij een mouse-over.

Het is op het moment van schrijven nog niet bekend hoe groot het probleem is en in hoeverre er misbruik van wordt gemaakt. Er zijn wel gevallen bekend van Twitter-gebruikers die ongewild automatisch berichten plaatsten nadat ze met hun muis over een andere Twitter-bericht gingen, dankzij javascript-code die zou zijn uitgevoerd. Ook zou Sarah Brown, de vrouw van de voormalige Britse premier Gordon Brown, haar volgers per abuis hebben doorgestuurd naar een Japanse pornosite.

Het lek doet zich voor zover bekend alleen voor in de webversie; wie een applicatie zoals TweetDeck of DestroyTwitter gebruikt valt buiten schot. Wel zijn browser-add-ons mogelijk ook vatbaar: in ieder geval PowerTwitter voor Firefox heeft hier last van. Beveiligingsbedrijf Sophos heeft al gewaarschuwd voor het lek. Het is niet bekend of de nieuwe Twitter-interface, die vorige week werd aangekondigd, ook kampt met de problemen. Twitter heeft nog niet gereageerd op het lek.

De oorzaak van het probleem ligt waarschijnlijk in het feit dat Twitter html-code niet weet te herkennen en te verwijderen wanneer deze direct na een internetadres, gevolgd door het @-symbool, wordt geplaatst. Daardoor kan het href-attribuut, waarin zich de locatie van een hyperlink bevindt, worden gesloten en kunnen gebruikers hun eigen attributen toevoegen. Zo is het mogelijk om de achtergrondkleur of het lettertype van een tweet te veranderen, maar ook om een onMouseOver-event toe te voegen. Door dit laatste kan javascript-code automatisch worden uitgevoerd wanneer een gebruiker met zijn muis over de tweet beweegt.

Update, 15:02: Gebruikers van Twitter melden dat ze automatisch berichten retweeten van een bepaalde gebruiker, zodra ze de webversie bezoeken. Met de muis over een bepaalde tweet gaan is niet meer vereist. Dit komt ogenschijnlijk doordat de 'auteur' van de tweet zijn link een specifieke css-class heeft toegewezen, waardoor de tweet de hele pagina in beslag neemt.

Update, 15:32: De nieuwe versie van Twitter lijkt geen last te hebben van het probleem.

Update, 15:39: Twitter zegt van de problemen op de hoogte te zijn en aan een oplossing te werken.

Update, 16:02: Del Harvey, leider van het beveiligingsteam van Twitter, meldt dat het lek gedicht zou moeten zijn.

Reacties (130)

[kowapanga]

Wow dat ding gaat echt snel
http://twitter.com/search#search?q=onMouseOver

Heb hem 5seconden geleden refreshed en er zijn nu al 13k nieuwe tweets bij.

[edit]
En 10minuten later:
127,134 more tweets since you started searching

EDIT2: Uurtje later
556,085 more tweets since you started searching.

[Reactie gewijzigd door kowapanga op 22 juli 2024 19:29]

[OddesE]

En nu we het over bugs hebben... Het ziet er naar uit dat de Tweakers.net post engine niet om kan gaan met URL's die een parameter hebben NA het hash symbool (#) dat een referentie aangeeft.... Te zien aan de link van kowapanga, die niet goed is doorgekomen.

Dit is normaal gesproken ook een vrij zeldzame combinatie hoewel Google dit geloof ik ook zo doet. Te weinig getest door Tweakers.net? Ik denk gewoon een nieuw bewijs dat dit allemaal best lastig is om goed te krijgen en dat het dus niet zo raar is dat ook bij twitter dit soort foutjes er in sluipen. Belangrijker is of/hoe snel ze het fixen.

[crisp]

Dat is geen bug maar een afweging wanneer een bepaald teken als leesteken gezien wordt of als onderdeel van de URL, en dat bijt elkaar wel eens

Zoals hierboven al gezegd kan je in dat geval beter gebruik maken van de [url]-tag

[OddesE]

Toch zou je zeggen dat normaal gesproken zowel een vraagteken als een komma gevolgd worden door whitespace en niet direct door andere tekens.

Normaal gesproken schrijf je zo, en niet,zo.

En zo toch? En niet zo?toch?

Dus lijkt het me vrij eenvoudig om de normale leestekens van de URL tekens te onderscheiden...

[crisp]

Waar, maar dat maakt het matchen minder rechtlijnig en daarmee minder performant en slechter onderhoudbaar. Ik ben persoonlijk van mening dat je beter dergelijke ambiguiteiten kan uitsluiten door dit soort tekens niet te gebruiken in URI's... Verder is het goed gebruik van interpunctie velen vreemd op het internet tegenwoordig

[Reactie gewijzigd door crisp op 22 juli 2024 19:29]

[Dreamvoid]

Ook met URL's met een komma erin, overigens.

[.oisyn]

Wat natuurlijk bewust is. Als je gewoon schrijft: "hey, ga eens naar http://tweakers.net/bla, en plaats daar een reactie", wil je niet dat die komma ook mee wordt genomen. Wil je dat wel, dan moet je dat maar even expliciet in een url tag doen (wat in het geval van kowapanga ook gewoon werkt: http://twitter.com/search#search?q=onMouseOver)

[Dreamvoid]

In een URL tag werkt het ook niet, of tenminste, toen ik t probeerde 2 weken terug.

[.oisyn]

Jawel, je moet alleen quotes gebruiken, omdat de komma een speciale betekenis heeft in de [tag=a,b,c] syntax. Dus [url="a,b,c"]je tekst hier[/url] in dit geval. Of gewoon [url]a,b,c[/url]

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:29]

[TheMatrixHasYou]

Opletten. Er wordt nu ook gebruik gemaakt van de Jquery GetScript, op deze manier kan een kwaadwillende gebruiker duizende regels code executen op je pagina. Er worden op dit moment ook worms geinstalleerd via deze methode...

[OddesE]

Dat laatste van die Worms vind ik interessant, want dat kan volgens mij niet ,of is een vette browser (niet twitter) bug als dat kan.

Een javascript worm? Of bedoel je een echte, ouderwetse, binary-code, worm??

[Farscape2]

SecureList houdt een live blog bij over de exploits

http://www.securelist.com/en/blog/2297/Live_Twitter_XSS

bedrijf waar ik werk is ook al slachtoffer, nu snappen ze hier eindelijk dat ze een third-party client moeten gebruiken... ach het enige waar het je naar verwijst is een pr0n-site... daar is nog nooit iemand aan dood gegaan

hoop dat ze het snel kunnen aanpakken daar bij Twitter, niet zo netjes natuurlijk deze gang van zaken, maar wel grappig om te zien dat iedereen hier even in paniek rondloop ("twitter kapot! twitter? kapot!")

[YopY]

Update 5 (14:59 CEST): It appears Twitter now properly escapes links, that specific vulnerability seems closed.

...Crisis voorbij? .

[boombes]

Nou dat aan Pr0n nog nooit iemand is dood gegaan direct is een feit echter er zijn genoeg mensen die tijdens het hoogtepunt omkiepen.

Maar over twitter kapot Gelukkig hebben we het mooie medium tweakers nog;)
_{Al was het gister andersom}

[Malarky]

Ene Judofyr (deze dus) schijnt het lek ontdekt te hebben.

[Reactie gewijzigd door Malarky op 22 juli 2024 19:29]

[appel437]

iemadn hier op de studie heeft het ook zelf ontdekt... maar dan alleen CSS

[DNA_Saint]

Ze hebben het gefixed.

Update 5 (14:59 CEST): It appears Twitter now properly escapes links, that specific vulnerability seems closed.

[cyboria]

Dat is toch wel een vrij serieuze bug ... Is het zo niet mogelijk om iemand die een mouseover-event uitvoert, ongewenst door te sturen naar een link waar een virus/malware geprepareerd staat om zo de pc te infecteren?

[.Gertjan.]

Dat zoiets mogelijk is maakt het juist gevaarlijk (en zorg er voor dat Sophos waarschuwt). Een alert is niet indrukwekkend. Maar goed, javascript wordt toegestaan dus javascript die de browser naar een andere pagina laat schieten (location = "") zal er vanzelf komen (als dat er nog niet is).

Aan de andere kant zal Javascript crosssite dingen niet toelaten (is een beveiliging in de JS engine), je kunt dus alleen redirecten (uiteraard kan daar wel weer rommel staan), maar zaken als je account hacken/hijacken zal dus niet zo snel lukken.

Daarnaast is door de beperkte ruimte in de tweets ook maar beperkte ruimte voor scripts

[Britney65]

Aan de andere kant zal Javascript crosssite dingen niet toelaten

Tenzij er nog een bug in je brouwser zit:
nieuws: Onderzoeker publiceert 'ernstig' lek in IE8

Daarnaast is door de beperkte ruimte in de tweets ook maar beperkte ruimte voor scripts

Tenzij het script een ander script van een andere site kan laden.

Ondanks dat het een klein bugje is, hadden de gevolgen groot kunnen zijn. Gelukkig schijnt het verholpen te zijn:
http://www.securelist.com/en/blog/2297/Live_Twitter_XSS

[bluppfisk]

met JQuery's $.getScript() dus precies wel

[OddesE]

Maar een script element in de HEAD plaatsen die weer een extern script inlaadt en uitvoert zal waarschijnlijk wel passen in een tweet, dus dan heb je effectief weer onbeperkt de ruimte. Zelfde techniek die Bookmarklets gebruiken, maar dan ongevraagd, vanuit een onmouseover.

[.oisyn]

Aan de andere kant zal Javascript crosssite dingen niet toelaten (is een beveiliging in de JS engine), je kunt dus alleen redirecten (uiteraard kan daar wel weer rommel staan), maar zaken als je account hacken/hijacken zal dus niet zo snel lukken.

Javascript kan de cookie opvragen en een form posten naar een andere website. Account hijacking is dus vrij gemakkelijk.

[DJMaze]

Mooie beginners bug.
Een controle op email adressen d.m.v. een @ zijn echt groot.
Je moet rekening houden met IPv4, IPv6 en verschillende RFC's voor local email parts en domein namen.
Een dubbel aanhalings teken (waar nu de bug in zit) mag in de "local part", zelfs meerdere @'s zijn mogelijk!
bijvoorbeeld: "me@home"@example.org

Edit: een foutje in je controle dat een " mag na een @ is dus snel gemaakt!

[Reactie gewijzigd door DJMaze op 22 juli 2024 19:29]

[OddesE]

Je kunt email adressen niet controleren eigenlijk, zelfs een adres als 'localhost' is gewoon valide.

Hier maakt men van e-mail adressen automatisch een mailto link... en in die code zit gewoon een fout. Lijkt me toch niet zo moeilijk om gewoon alle enkele/dubbele quotes te escapen en er mailto: voor te zetten. Inderdaad een echte beginnersfout.

[raptorix]

Volgens mij gaat het niet om emailadressen maar om twitternaam (gestart met een @)

Dus normaal word @gebruiker, door twitter iets van http://www.twitter.com/gebruiker gelinked. Kortom de bug zal wel iets zijn van: http://www.twitter.com/ge...e-teken/kwaadaardigscript.

Kortom stop je dit: gebruiker-escape-teken/kwaadaardigscript in een tweet, dan gaat het fout, weet niet of dit hier precies het geval is, maar het zal er niet ver vanaf zitten.

De bug is denk ik ontstaan omdat de reguliere expressie die de twitternaam moet herkennen te "greedy" is.

Edit, de injectie word dus Voor de twitternaam gezet.

[Reactie gewijzigd door raptorix op 22 juli 2024 19:29]

[Dimiz]

Mensen, pas op voor de gebruiker Matsa, wordt nu erg veel geretweet en verspreid een worm via Twitter, deze heeft de javascript exploit nog erger misbruikt dan dat er nu al mogelijk was waardoor er naar een website gelinkt wordt.

[Firesphere]

Enig idee welke worm? Heb'm even wat uitgeplozen, maar niet direct iets gevonden nog door Clam/F-Prot en Kaspersky, so far.

Heb meer het idee dat hij consequent zijn laatste tweet automatisch laat retweeten door anderen.

[Reactie gewijzigd door Firesphere op 22 juli 2024 19:29]

[eXisTa]

Deze heb ik dus ook al perongeluk binnengehengeld, deze retweet automatisch.
Nasty nasty nasty

[Chimera]

Matsa's account is al leeg

[Reactie gewijzigd door Chimera op 22 juli 2024 19:29]

[Frank Reiber]

Het is user maTSTa en niet Matsa

[LX_Emergency]

Zegt toch wel iets over het niveau waarop ze hun spul testen.

[YopY]

Zou jij als tester zijnde een testcase maken "Ik ga even een @ achter een URL plaatsen om te kijken of ik daarmee een onmouseover kan plaatsen"?

[LX_Emergency]

Waarschijnlijk wel ja. Zeker in een zo wijd gebruikte applicatie als deze. Jij niet dan?

Ook bekend als risico zijn bijvoorbeeld SQL statements. En gezien het feit dat java op het internet gebruikt word. Waarom dan niet Java of javascript statements?

[Reactie gewijzigd door LX_Emergency op 22 juli 2024 19:29]

[OddesE]

De subtiele bugs die allemaal kunnen voorkomen in (gebrek aan) escaping en encoding zijn lastig vooraf te voorspellen. Het is nu makkelijk te roepen dat dit getest had moeten worden maar zelfs 140 tekens (of wat is het max. van zo'n tweet) is teveel om alle mogelijke permutaties te testen. En dus zal men een selectie van test berichten moeten maken.

Als deze bug er al vanaf het begin in zat en nu pas bekend wordt geeft dat ook wel aan hoe weinig dit voorkomt. Nu men de hack kent gaat men bewust dergelijke tweets maken, maar spontaan, in 'het wild' komt deze combinatie van tekens nauwelijks voor.

Dus ja, tuurlijk wil iedereen alle cases afdichten, maar dat is veel moeilijker gezegd dan gedaan.

[MSalters]

Ja.

Beter gezegd, als security tester kijk je naar mogelijke risicofactoren. Emailadressen en URLs zijn beiden ruim bekend als risicofactor. Alleen al daarom zou je een groot aantal test-tweets maken waarin die twee op verschillende manieren worden gecombineerd, inclusief overlappende URL en email.

[Verwijderd]

Makkelijk gezegd nu een ander er tegenaan loopt

[.oisyn]

Sorry hoor maar een beetje fatsoenlijk software developer of tester doet precies wat MSalters zegt. Ik ben destijds voor mijn forumsoftware ook een hele tijd bezig geweest om ervoor te zorgen dat dingen als XSS niet mogelijk zijn, door goed na te denken waar user input in terecht kan komen en hoe je ervoor kan zorgen dat dat nooit fout kan gaan. En dat was dan slechts een hobbyprojectje wat door niemand daadwerkelijk wordt gebruikt

[Reactie gewijzigd door .oisyn op 22 juli 2024 19:29]

[Kecin]

De mouseover van jullie plaatje is in ieder geval briljant.
Snap niet dat niemand hier eerder achter is gekomen bij zo'n grote website.

Overigens is het vrij makkelijk om dit te verhelpen dus ik verwacht niet té grote problemen...

[Reactie gewijzigd door Kecin op 22 juli 2024 19:29]

[TvdW]

Mensen bij Twitter.com slapen nog Daarnaast gebruikt iedereen van het Twitter HQ de #newtwitter dus merken ze er niks van.