TweetDeck kampt met xss-bug - update

TweetDeck, de officiële client van Twitter voor powerusers, bevat een xss-bug. Daardoor is het in potentie mogelijk voor kwaadwillenden om bijvoorbeeld automatisch tweets te plaatsen. De normale Twitter-site is niet getroffen.

De bug is arbitrair te gebruiken: tweets blijken in TweetDeck als normale html te worden geparsed, waardoor het toevoegen van een javascript aan een tweet voldoende is om de javascript-code uit te laten voeren. Daarmee kan een kwaadwillende in theorie automatisch een tweet plaatsen door javascript-code naar iemand te twitteren. Ook zouden volgers kunnen worden verwijderd.

Een Duitse twitteraar heeft als proof-of-concept een tweet gemaakt die automatisch wordt geretweet wanneer een TweetDeck-gebruiker hem voorbij ziet komen; op het moment van schrijven is dat bericht al 39.000 keer geretweet.

Het is niet duidelijk welke versies kwetsbaar zijn. In ieder geval de webversie van TweetDeck is kwetsbaar; de OS X-app is dat niet. Het is onduidelijk of de Windows-versie kwetsbaar is. Beveiligingsonderzoeker Frederik Jacobs stelt dat het in dit geval niet mogelijk is om cookies te stelen, iets dat bij sommige xss-bugs wel het geval is. Desondanks adviseren beveiligingsonderzoekers om TweetDeck voorlopig niet te gebruiken.

In 2010 kampte de Twitter-website met een soortgelijk probleem. Daarbij konden kwaadwillenden gebruikmaken van een onMouseOver-event. Een twitteraar maakte daarbij een tweet die automatisch werd geretweet bij het bezoeken van twitter.com. Twitter nam TweetDeck in 2011 over.

Update, 18:43: Volgens onderzoeker Jacobs is de bug inmiddels gepatcht. Gebruikers zullen echter wel opnieuw moeten in- en uitloggen en de cache van de browser legen om te voorkomen dat de oude, kwetsbare javascript-code van TweetDeck nog ingeladen is.

Reacties (35)

[Verwijderd]

XSS is lang niet altijd zo makkelijk te voorkomen als sommigen hier beweren. Het is triviaal om te voorkomen wanneer de invoertekst geen enkele HTML of javascript mag bevatten, in dat geval kun je makkelijk alles strippen/escapen. Echter, vaak wordt er plain text ondersteund met daarin enkele mogelijkheden voor speciale markup, een soort tussenweg dus. In dergelijke gevallen ontstaan er ineens vele manieren om langs de parser te komen, en is het erg lastig om waterdicht te krijgen.

[Patriot]

Dat is imo gewoon een grote denkfout, en inderdaad de reden dat xss soms ook bij programmeurs waar je het eigenlijk niet van verwacht voorkomt. Het lijkt namelijk logisch om specifiek te filteren op wat je niet wilt, als je sommige gevallen toch wilt toestaan.

In de praktijk is het echter veiliger om gewoon bepaalde tekens om te zetten naar hun html entities en vervolgens een simpele parser te schrijven die de html entities voor < en > gebruikt als delimiters voor die paar tags die je wel wilt ondersteunen.

Toegegeven, die parser kan behoorlijk complex worden als je bijvoorbeeld ook (bepaalde) attributen wilt toestaan. Het blijft echter veiliger om expliciet toe te staan wat je wilt toestaan, dan het is om te proberen om alles wat je niet wilt te filteren.

[JohnAxae]

Probleem blijkt verholpen: https://twitter.com/TweetDeck/status/476763638695743489

[Reanimator909]

Tweetdeck is zojuist helemaal offline gehaald :

"We've temporarily taken TweetDeck services down to assess today's earlier security issue. We'll update when services are back up."

https://twitter.com/TweetDeck/status/476770732987252736

[Bassievdb]

Eerlijk gezegd een regelrechte schande. Ikzelf ben student Computer en CyberCrime in Brugge, en xss wordt praktisch gezien in de eerste 3 maand van de opleiding helemaal onder de loep genomen. Ook de richtingen Software ontwikkeling en webdesign zien dergelijke en goede technieken om zoiets op een heel makkelijke manier te voorkomen. Het baart me toch zorgen dat TweetDeck niet nauw kijkt op security. Desondanks las ik dat de applicatie binnenkort verdwijnt.
http://www.queromedia.be/...dwijnen-binnenkort-25396/

[seba]

Als je volledige kennis hebt over een systeem, is het een schande moest XSS mogelijk zijn. In de praktijk werkt het anders bij complexe systemen, dan moet je meerdere systemen die onvoldoende, of in het geheel niet, gedocumenteerd zijn met elkaar laten praten. Vaak worden hier verkeerde assumpties gemaakt en bijna telkens gaat het verkeerd in dergelijke 'glue code'.

Het feit dat XSS nog steeds regelmatig voorkomt bij de grote tech bedrijven, waar de meeste programmeurs wel getalenteerd zijn, maakt dat je nogal arrogant overkomt met je statement als beginnende student.

[Twixie]

Binnenkort ? Het artikel waar je naar linkt is van maart 2013. Volgens mij zijn de Tweetdeck apps al lang (officieel) verdwenen.

[bn326160]

XSS is iets dat nog vaak voorkomt, vooral bij Yahoo, ook regelmatig bij Google en af toe ook bij Facebook. Natuurlijk kan dit op verschillende websites voorkomen, ook Sony of een andere onderneming. Bounty hunters ruimen de stront van de developers op. Ik ken iemand van 18 die al 3 jaar bounty's ontvangt van die 3 partijen en op hun whitehat list staat. Het is vaak niet zo moeilijk als je zou denken of dat willen dat je denkt. Blogs van dergelijke internetbedrijven in de gaten houden, XSS of SQL-injecties proberen uitvoeren op nieuwe diensten en rapporteren.

[Reactie gewijzigd door bn326160 op 22 juli 2024 16:44]

[mad_max234]

Eerlijk gezegd een regelrechte schande. Ikzelf ben student Computer en CyberCrime in Brugge, en xss wordt praktisch gezien in de eerste 3 maand van de opleiding helemaal onder de loep genomen.

Droom verder, dit soort dingen kunnen altijd gebeuren. Je hebt schijnbaar nog niet voldoende geleerd en al helemaal geen praktijk ervaring. maar ach wie ben ik, wellicht ban jij de nieuwe Einstein en hadden wij(de rest van de wereld) het allemaal al decennia verkeerd.

Edit/
Hoop dat die drie maanden opstapje is voor je om verder te leren, want je kan niet uitgeleerd raken op dit gebied, drie maanden hebben ze hoogsten basisbeginselen besproken.

[Reactie gewijzigd door mad_max234 op 22 juli 2024 16:44]

[Bv202]

Wat ik opmaak uit het artikel is dat de user input gewoon als html wordt geparsed en er dus helemaal geen enkele vorm van beveiliging (op dit gebied) is.

Zoiets is wel degelijk een grote fout en zou niet mogen voorkomen.

[Bassievdb]

@mad_max234
Ik zeg ook helemaal niet dat ik praktijkervaring heb, meer nog, studenten studeren af met een minimum aan ervaring. Wat ik wil zeggen is dat het zo simpel te voorkomen is, dat ik ervan verschiet hoe vaak het toch nog voorkomt. Oke, dat complexe vormen inderdaad moeilijker zijn tegen te gaan, maar gewoon zaken tussen <script></script> tags zetten is eerlijk gezegd het eerste wat wij zien.

Verder ben ik ook zeker niet de nieuwe einstein, en was al de rest al evenmin verkeerd, maar van een applicatie die relatief jong is (>2005) verbaasd het me toch...

En een reactie op je edit.
Moest je geininteresseerd zijn in het lessenprogramma, het is echt specifiek beveiliging en het voorkomen ervan. 24/7 niets dan beveiliging. Het eerste jaar echter, daarover gaat mijn punt, zien we al het voorkomen van simpele xss..
/Edit, het is een 3 jarige opleiding, dus tijd zat om beveiligin onder de loep te nemen.

[Reactie gewijzigd door Bassievdb op 22 juli 2024 16:44]

[Aionicus]

Het probleem is dat het wel leuk is een opleiding te volgen in "beveiliging" maar dat je er 9 van de 10x weinig tot niets aan hebt.

Juist doordat mensen zo gedrilled worden kunnen studenten die een opleiding hebben afgerond alleen nog maar wat ze hebben geleerd op de opleiding. Wij hadden hier een hele groep HBO/WO studenten allemaal in IT-security branche , en wat ze op school hadden geleerd konden ze allemaal dromen , maar de out of the box maniertjes om binnen te komen of iets te kraken kenden ze allemaal niet of maar amper. Terwijl iemand zoals een collega met puur praktijkervaring ze allemaal tandenknarsend achter laat .... Doet toch wel heel veel pijn hoor voor die jongens , een mavo medewerker die hun gewoon op elk vlak alle kanten van de kamer laat zien. Puur doordat het echt zijn intresse is en hij weet waar hij het over heeft.

Daarbij moet je ook rekening houden dat een "security" eens word opgezet , gechecked word en dan beetje bijgehouden word terwijl een echte hacker alle tijd heeft van de wereld. Al koste het mij soms een maand om ergens in binnen te dringen , het lukte mij wel (als pentester). Ik heb ooit is een half jaar erover gedaan om een hele grote bekende paid streamingsite te kraken , puur omdat ik de films wou downloaden en kijken of het me lukte , Na heel wat uitzoekwerk , tooltjes , stukken uitpluizen had ik toch een manier gevonden om zonder account elke film (van de 10.000 online) op de beste qualiteit te downloaden. Hoe ? Ik kwam er achter na het "decoden" van ssl verkeer dat de bestandsnaam van het plaatje icm een url en verwijzing in XML/javascript te gebruiken was om verbinding te leggen met de streamingserver van dat bedrijf . hierna was het een questie van de juiste javascript commands decoden en de juiste var's meesturen die de Adobe flash server verwachte.

Na nog meer speurwerk uiteindelijk een scriptje gebouwd wat van elke film een downloadable url maakte en dan kon je die gewoon in 1x binnenslurpen , geen enkele login werd gevraagd.

Ik heb ook wel eens een kassasysteem in de winkel gekraakt. Alles dichtgetimmerd tot aan het bot , helaas hadden ze een help menu en door alt in te drukken werd de werkbalk zichtbaar en kon je dus naar bestand -> openen -> en dan is het as simpel als %windir% intypen en boem hello cmd.exe / command.com . Toen stond er nog een typical IT fout in de c:\ (sysprep folder ^^) met daarin leuk de username's en passwords voor elk finiaal van een hele bekende speelgoedwinkel. Ik kon alles , van net send * naar heel landelijk netwerk een popupje sturen hehe tot aan het openen van kassa's en het aanpassen van prijzen (omdat je de verbinding naar de database kon overnemen omdat hij altijd actief stond als kassa systeem ingelogd was) . Dit na het net send berichtje meteen aan leidinggevende gemeld.

dag later werd ik gebeld , bijna aangeklaagd omdat ik zogenaamd een usb stick had gebruikt enz enz . Kreeg een conference call met hun top 12 IT boys , en toen ik het uitlegde werd het ineens heeeeeeel erg stil aan de andere kant van de lijn. Ik ben bedankt , zou een krat bier krijgen (na 5 jaar is het kratje er nog niet) en heb hun aardig gered eigenlijk. Iemand die iets kwaads in zin had zou heel veel dingen kunnen aanpassen in winkelvoorraad en gewoon deur uit kunnen lopen.

Daarbij wil ik ook aankaarten dat die heren van hbo/wo zich vaak compleet aanpassen aan de bedrijfscultuur en dus maar 1x roepen van HEY je flash player is niet up2date of jullie gebruiken geen adblock . daar word niets mee gedaan en dan doen ze er zelf ook verder niets meer mee tot het te laat is.

[Reactie gewijzigd door Aionicus op 22 juli 2024 16:44]

[WeAreLegion]

Beetje jammer dat je dan door zo'n bug gerickrolled word.

[xFeverr]

Dat is inderdaad wel het ergste wat je kan overkomen, sterkte voor alle slachtoffers

[CyBeR]

Die JPEG screenshot maakt 't niet veel beter.

[Verwijderd]

beetje jammer dat ze Rick ook nog eens verkeerd quoten
Never going to gonna give you up, never going to gonna let you down.

[Trancicted]

Er zijn dan wel leukere dingen die je kan gaan doen als je een XSS gevonden hebt dan een Alert te gaan geven

[sfranken]

Dit is (IMO) een nette manier van waarschuwen. Dit zou ik white-hat willen noemen. Shit uithalen is black/gray hat, en daar krijg je waarschijnlijk problemen mee.

Een onschuldige alert is precies dat: onschuldig. Maar het legt wel de vinger op de zere plek

[J0HAN]

Niet helemaal mee eens...

De nette manier zou zijn dat je de bug rapporteert bij Twitter zonder deze openbaar te maken.
Hier wordt in principe gewoon door iemand misbruik gemaakt van het lek door eindgebruikers op een vervelende manier lastig te vallen met berichten.

Er wordt inderdaad geen schade aangericht dus de impact valt mee, maar helemaal netjes vind ik het niet.

Maar oke, het is stiekem natuurlijk wel leuk om het lek op deze manier te "misbruiken"

[mad_max234]

Dat is ook de enige manier die legaal is zover ik weet, welke hoed je ophebt is niet van belang, je mag gewoon niet iemand systeem binnendringen zonder toestemming. Hij is nu dus strafbaar bezig geweest, als ze kwaad willen dan kunnen ze gewoon aangiften doen.

[RGAT]

Dat betwijfel ik, hoewel ik het er mee eens ben dat dit verre van ethisch hacken is.
Hij heeft namelijk niks gekraakt, is nergens ingebroken en heeft niets veranderd en alleen een (groot?) aantal twitteraars laten schrikken...

Nogmaals, niet mee eens met zijn manier van handelen, absoluut niet, maar of het illegaal was betwijfel ik...

[Patriot]

Nouja, het zal wel weer afhangen van of zoiets als het versturen van een beetje html en Javascript als kunstgreep oid gezien kan worden.

In ieder geval is het sturen van zo'n bericht relatief onschuldig, een eigenaar zal je er waarschijnlijk niet om aanklagen en zelfs als ze dat proberen geloof ik niet dat er een rechter is die je zal veroordelen.

Misschien wel in de VS, maar daar is het rechtssysteem tamelijk debiel.

[Amanoo]

Een leuk filmpje van Tom Scott over het onderwerp: https://www.youtube.com/watch?v=zv0kZKC6GAM
Het was erg jammer, wat er is gebeurde. In Toms eigen woorden, men faalde hier in webdesign 101. Een eigenlijk vrij basale fout.

[Verwijderd]

Dat is dus helaas niet helemaal waar. TweetDeck filterde wel degelijk de content van tweets op deze tags. Zeker nadat in 2011 deze bug aan het licht kwam: https://mobile.twitter.com/mikko/status/73849855562350592. Het toevoegen van het hartje liet echter dit filter falen.

[Zidane007nl]

En dat staat dus ook in zijn tech note aantekening tijdens het filmpje.

[Orama]

Hier is het script "script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script"

[J0HAN]

RT Hier is het script "script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script"

Hé, wat gebeurt er nou weer...

[Caladai]

XSS is een probleem dat nog jaren zal blijven bestaan.

Grote bedrijven hebben heel veel mensen in huis zitten maar hoeveel ervaring hebben die? Vaak zijn de seniors van ontwikkelteams verantwoordelijk voor de grote lijnen en de juniors verantwoordelijk voor het standaard-werk. Laat web-forms bouwen en valideren nou typisch een standaard klus zijn en komt dus vaak terecht bij de minst ervaren. XSS achteraf klinkt misschien als een "hoe kon je dat nou missen" item maar tijdens het maken van een formulier ben je vaak zo gefocused op de werkende case (wordt de data goed verwerkt, krijgt de user de juiste meldingen te zien, etc.) dat de xss check vaak niet eens meer in je opkomt. Uitgebreide/geautomatiseerde testprocedures zijn duur/complex om op te zetten.

Kleine bedrijven hebben vaak het probleem van mankracht.

Ik vergelijk software ontwikkeling graag met de bouwsector. Ook bij software hebben we namelijk te maken veiligheid en architectuur. In de bouw zijn er echter wettelijke inspecties waar regels voor zijn opgesteld waar gebouwen aan moeten voldoen. De software branche is echter nog relatief jong en heeft deze procedures nog niet of in ieder geval niet op wettelijk niveau. De enige garantie voor software veiligheid is momenteel nog de garantie van de ontwikkelaar.

Ontwikkeling van applicaties als tweetdeck kan nooit stilstaan (concurrentie is killing). De requirements veranderen constant. Het kan zo maar zijn dat de initiële afhandeling XSS proof was (gemaakt door team A en afgevinkt als zijnde XSS proof) maar er nog even snel die extra feature bij moet (taak voor team en dan de "tussenweg" gecreëerd wordt. Bij het bepalen van de nieuwe feature is de relatie met eventueele XSS problemen niet altijd voor de hand liggend en wordt niet de security-test suite gedraaid voordat de nieuwe feature live gaat.

Hackers zijn digitale monniken. Developers hebben vaak geen tijd voor monniken werk die worden beoordeeld op de features die ze opleveren.
XSS is bekend en had allang verholpen moeten zijn? true maar hackers hebben blijkbaar 6 jaar nodig gehad om de exploit te vinden dus zo voor de hand liggend is het blijkbaar ook niet.

[Verwijderd]

Ik vergelijk software ontwikkeling graag met de bouwsector. Ook bij software hebben we namelijk te maken veiligheid en architectuur. In de bouw zijn er echter wettelijke inspecties waar regels voor zijn opgesteld waar gebouwen aan moeten voldoen. De software branche is echter nog relatief jong en heeft deze procedures nog niet of in ieder geval niet op wettelijk niveau. De enige garantie voor software veiligheid is momenteel nog de garantie van de ontwikkelaar.

Ik vraag me af of je dit op wettelijk niveau wilt gaan regelen. Dat wordt dan de doodsteek voor de softwarebranche qua innovaties. Softwarebouwers zullen hun producten moeten laten certificeren door een door de overheid ingestelde instantie, vergelijkbaar met bijvoorbeeld KEMA. Op kosten van de softwareleverancier. Dat is slechts weggelegd voor een paar grote softwarebedrijven. En hoe ga je dat regelen met open source software? Wie is verantwoordelijk?

[Caladai]

Dat de haalbaarheid van certificering en de invulling daarvan heel moeilijk is ben ik zeker met je eens. Software is echter de backbone van de informatie economie. De schade die foutieve software aanricht schat ik (bij gebrek aan exacte cijfers) aanzienlijk. Dit zal steeds hoger oplopen naar mate meer bedrijven menselijke handelingen weg automatiseren. Dus ja hoe is mij ook de vraag ik stel echter wel dat er een noodzaak voor is.

[Reactie gewijzigd door Caladai op 22 juli 2024 16:44]

[redburn]

Ik kan (helaas) bevestigen dat het ook de Windows client treft (nieuwste versie). Zodra ik TweetDeck start, retweet ik automatisch een bericht.

[Reactie gewijzigd door redburn op 22 juli 2024 16:44]