Neues Link-Tool zeigte Daten von fremden Domains an

Veröffentlicht am 7. Februar 2007 von Jens

Durch eine Lücke im neuen Link-Tool der Webmaster Tools war es bis vor wenigen Stunden auch möglich die Statistiken von fremden Webseiten einzusehen. Zwar handelt es sich dabei nicht wirklich um eine Sicherheitslücke und stellt keine Gefahr da, aber trotzdem hat Google diese Lücke schnell geschlossen - schade eigentlich. Durch eine kleine Änderung in der URL konnte man die Daten von jeder beliebigen Seite ansehen:

https://www.google.com/webmasters/tools/ externallinks?siteUrl= http%3A%2F%2Fblog.outer-court.com%2F&hl=en& bplink=http%3A%2F%2Fblog.outer-court.com

ersetzen durch:

https://www.google.com/webmasters/tools/ externallinks?siteUrl= http%3A%2F%2Fblog.outer-court.com%2F&hl=en& bplink=http%3A%2F%2Fwww.google.com

Ich fände es sehr interessant wenn Google diese Daten weiterhin zugänglich machen würde - nur nicht an dieser Stelle. Es wäre doch eine nette Erweiterung für alle Webmaster, wenn man seine eigenen Daten mit denen der Konkurrenz vergleichen kann. Für alle interessierten hat Philipp Lenssen die Verlinkungsanzahl von einigen großen Webseiten in seinem Blog veröffentlicht. » Verlinkungszahlen bei Philipp Lenssen

Neue Sicherheitslücke erlaubt Zugriff auf Google-Cookie

Veröffentlicht am 16. Januar 2007 von Jens

Kaum zu glauben aber wahr: Innerhalb von 2 Wochen wurde jetzt eine dritte große Sicherheitslücke bei Google entdeckt. Nach dem ausspähen der Google Mail-Kontakte und dem Cookie-Klau via Blogger hat Haochi jetzt eine weitere Möglichkeit zum Cookie-Klau entdeckt. In Googles Sicherheitsabteilung dürften wohl bald einige Köpfe rollen... Angespornt von der ersten vor 2 Tagen bekannt gewordenen Sicherheitslücke hat sich Haochi von Googlified auf die Suche nach weiteren Möglichkeiten zum Cookie-Klau gemacht - natürlich im Dienste der Sicherheit, nicht um böswilliges damit anzustellen. Laut eigenen Aussagen hat er eine Möglichkeit gefunden das Google.com-Cookie mit nur 3 Zeilen PHP-Code zu klauen. Wie dieser Cookie-Klau genau funktioniert und welcher Dienst diesmal betroffen ist hat er natürlich noch nicht preisgegeben, dies folgt erst wenn das Google-Team den Fehler behoben hat. Ich denke aber dass es sich um AdSense oder Analytics handeln dürfte - eben ein Angebot mit dem man Google in die eigene Webseite integrieren kann. Ich könnte mir vorstellen dass es noch viele weitere offene Lücken im Google-Netzwerk gibt, die bisher nur noch nicht entdeckt worden sind und demnächst alle ans Tageslicht kommen. In der Sicherheitsabteilung sollte man sich in den nächsten Wochen also auf Überstunden einstellen und vielleicht ein wenig besser arbeiten... Was bei all diesen Sicherheitslücken so beunruhigend ist, ist die Tatsache dass sie alle sehr leicht reproduzierbar und sehr einfach gehalten sind - wer weiß wie viele schwerwiegende Lücken dann noch im System vorhanden sind. Ich bin mal gespannt wo die Lücke diesmal steckt - in einigen Tagen werden wir es erfahren. [Google Blogoscoped]

Details zur Cookie-Sicherheitslücke

Veröffentlicht am 15. Januar 2007 von Jens

Nachdem Google die Sicherheitslücke zum ausspähen des Cookies komplett geschlossen hat und nicht mehr reproduzierbar ist, hat Tony Ruscoe beschlossen die Lücke zu veröffentlichen. Die Angriffsstelle war das neue Custom Domain-Feature von Blogger, mit dessen Hilfe Tony eine Google-Subdomain praktisch entführt hat. Im Hilfeeintrag von Blogger wird die Subdomain ghs.google.com als Beispiel für die Einrichtung einer eigenen Domain genannt. Leider hat Google vergessen genau diesen Eintrag zu sperren, und dies hat ein User sich aus versehen zu Nutze gemacht. Um eine Domain komplett auf Blogger umzuleiten, muss ein Eintrag in der DNS-Tabelle vorgenommen werden, und genau dies wurde für ghs.google.com schon getan. Die Adresse ist jetzt also komplett eingerichtet, jetzt muss sie nur noch an Blogger gebunden und mit Content gefüllt werden. Ganz offiziell über das Custom-Domain-Interface hat Tony nun seinen Blog quasi auf ghs.google.com umgezogen, der Content kam zwar weiterhin von Blogger - aber für den Server lag der ganze Inhalt auf ghs.google.com, damit hatte Tony nun vollen Zugriff auf eine Blogger-Subdomain. Mit dem Besitz dieser Subdomain hatte Tony nun die Möglichkeit auf den Google-Cookie zuzugreifen und diese Informationen problemlos auszulesen. Blogger hat das Problem jetzt, eher unelegant, damit gelöst dass keine URLs mehr angenommen werden die auf "google.com" liegen. Das mag jetzt ganz gut dafür sein dass Googles Daten wieder sicher sind, aber das Hauptproblem ist noch lange nicht gelöst. Es gibt bisher keinen guten Weg herauszufinden ob der Blogger wirklich im Besitz der Domain ist. Hier muss noch eine Möglichkeit gefunden werden, evt. per Datei-Validierung wie es z.B. bei Sitemaps funktioniert. Hoffen wir dass es nicht noch weitere große Sicherheitslücken gibt die ein solches Ausspähen ermöglichen... » Sehr ausführliche Erklärung von Tony

Sicherheitslücke erlaubte Zugriff auf fremde Google-Accounts

Veröffentlicht am 13. Januar 2007 von Jens

Google-Experte Tony Ruscoe hat über eine Sicherheitslücke im System eine Möglichkeit gefunden auf jeden beliebigen fremden Google-Account zuzugreifen und viele enthaltenen Informationen einzusehen oder gar zu verändern. Die Lücke ist mittlerweile behoben, aber wie Tony das genau angestellt hat verrät er nicht - nur soviel: Er musste nur seine Cookies austauschen. Die Zeit in der man einfach den Loginnamen in den eigenen Cookies durch den Loginnamen des Opfers ersetzen musste ist zwar schon lange vorbei, aber im Grunde hat Tony es auf eine ähnliche Art und Weise geschafft an den Account von Philipp Lenssen (als Beispiel, er war eingeweiht) heranzukommen. Anscheinend hat Tony also eine Möglichkeit gefunden auf den Google.com-Cookie zuzugreifen. Eine ähnliche Sicherheitslücke gab es vor einigen Monaten schon einmal. Damals wurden frei anpassbare Suchseiten auf Google.com gespeichert und abgerufen, so hatte die Webseite freien Zugriff auf die Cookies. Mit der Verlagerung auf eine andere Domain wurde dieses Problem aus der Welt geschafft, aber anscheinend gibt es immer noch eine Möglichkeit auf einer Google.com-Subdomain eigenen Content unterzubringen - aber Tony verrät nicht wo. Alles was er jetzt tun musste, ist ein kleines Skript zu basteln dass den Cookie des Besuchers ausliest und diese Daten an Tony sendet. Das muss der User im besten Fall garnicht merken - denn wenn Tony das Skript eine nett gestaltete Seite einbaut wird der User den Link im besten Falle sogar weitergeben und Tony kommt an Haufenweise Google-Accounts heran. Jetzt musste der Cookie von Tony nur noch durch den von Philipp ausgetauscht werden, und schon hatte er Zugriff auf folgende Dinge: » Voller Zugriff und alle Bearbeitungsrecht für Google Docs & Spreadsheets » Teilweise auslesen der eMails, durch das Google Mail-Modul für die Personal Homepage - auf Google Mail selbst war kein Zugriff möglich » Einblick in die Google Accounts-Seite » Voller Zugriff auf den Google Reader » Voller Zugriff auf das Google Notebook » Voller Zugriff auf den Suchverlauf Man kann Google jetzt zwar zugute halten dass die richtig sensiblen Daten wie eMails oder der Zugriff auf AdSense und AdWords nicht funktioniert hat, aber das ist auch nur ein schwacher Trost. Anscheinend verwendet Google kein einheitliches Loginsystem bei seinen Angeboten - sonst hätte der Cookie-Trick überall oder nirgendwo funktionieren dürfen. Und wieder einmal müssen wir uns die Frage stellen ob Google wirklich genügend dafür tut all unsere Daten zu schützen. Zwar wurde die Sicherheitslücke die für das auslesen des Cookies verantwortlich ist nach etwas weniger als 4 Stunden behoben - Rekordzeit - aber von selbst kam kein Googler darauf, oder hat sich zumindest nicht darum gekümmert. Ich denke Google wird einen ganzen Stab an Sicherheitsexperten beschäftigen - fragt sich nur was die den ganzen Tag lang machen... Aber so lange solche Bugs in windeseile behoben werden und nicht all zu häufig auftauchen wird die Einstellung "Eine Google.com-Seite, die ist sicher" vom Großteil der User beibehalten. » Google-Sicherheitslücken [Google Blogoscoped] Nachtrag: » Details zur Cookie-Sicherheitslücke

Sicherheitslücke späht alle Google Mail-Kontakte aus

Veröffentlicht am 2. Januar 2007 von Jens

Das neue Jahr hat für die Googler gleich mit einer riesigen Sicherheitslücke begonnen die alle eure Google Mail-Kontakte ausspähen konnte und immer noch kann. Den Ursprung hat das ganze mit der Entdeckung einer in der Entwicklung befindlichen API genommen, der Contacts API, welche zwar eine sehr gute Idee ist, aber derzeit noch ohne jede Sicherheitsbestimmung mit eMail-Adressen um sich wirft. Der erste Schritt, die Entdeckung der API, kam natürlich wieder einmal von Garett Rogers. Er hat eine Zeile im Google Video-Quellcode entdeckt, die auf einen neuen "Contact-Picker" hinweist. Schon länger ist es möglich, Videos an verschiedene eMail-Adressen weiterzuleiten, aber bisher musste man diese Adressen noch im Kopf haben oder von Google Mail abtippen. Mit dem neuen Feature wird man direkt aus den Google Mail-Kontakten auswählen können. Die Funktion selbst ist immer noch aktiv, nur liefert sie derzeit verständlicherweise keine Daten mehr zurück. Schaut euch dazu einfach irgendein Video bei Google Video an und tippt dann folgende Zeile in die Adressleiste:

javascript:handlePickerClick(0);void(0);

voila! Der Haken an der ganzen Sache ist ja nun, dass dieses Fenster die Daten irgendwo her bekommen muss - und genau da liegt das Problem. Bei fast jeder Subdomain eines Google-Dienstes hat vor einigen Tagen die URL subdomain.google.com/data/contacts eine vollständige XML-formatierte Liste der Google Mail-Kontakte zurückgeliefert. Bei einigen Angeboten, wie z.B. die Docs & Spreadsheets-Datei funktoniert dies immer noch und wird wohl von den Diensten dazu benutzt die Kontakt-Liste aufzubauen. Richtig los ging es jetzt aber erst, als Haochi von Googlified sich diese XML-Dateien vorgenommen, mit einem Skript geparst und dieses Skript online gestellt hat. Digg und Slashdot haben ihr übriges getan und den Googlern das Wochenende und die Neujahresfete vermiest. Da sie sich so schnell nicht zu helfen wussten, haben sie die Ausgabe der Kontakte jetzt bei den meisten Angeboten erst einmal abgestellt. Haochi hat das Security-Team von Google zwar vor der Veröffentlichung des Skripts informiert, aber leider nur 2 Stunden davor und in der Nacht des 31.12 - auch nicht die feine englische Art... Das Problem ist nun, dass einige Angebote die eMail-Adressen dringend brauchen und sich diese wohl immer auf diesem Wege geholt haben. Diese Sicherheitslücke muss jetzt schleunigst bei allen Angeboten geschlossen werden, sonst kann das noch böse Folgen haben und die Sicherheit von Google Mail noch weiter in Verruf geraten. Die Frage ist nur, wieso die Googler nicht selbst auf die Idee gekommen sind die Daten auf einem anderen Wege in die Anwendungen zu importieren wo sie benötigt werden. Haben sie einfach auf Gut Glück die Daten auf diesem Wege ausgelesen und gehofft dass es schon keiner rausfinden wird? Leicht fahrlässig... Hoffentlich baut die neue API nicht auf diesem Prinzip auf, sondern hat eine sicherere Möglichkeit der Übertragung - ansonsten können sie das ganze wegschmeißen und von vorne beginnen. Warum um diese ganze Sache nun so ein Wirbel gemacht wird ist natürlich verständlich. Zwar werden nur die Adressedaten der Kontakte angezeigt die zu dem dazugehörigen Google Mail-Account gehören mit dem man gerade eingeloggt ist, aber dies kann ganz leicht von Webmastern ausgelesen werden. Eine Webseite müsste nur im Hintergrund eben diese Seite öffnen, Google Mail liefert brav die Daten zurück, und der Webmaster kann diese Liste auslesen - ein Paradies für jeden Spammer, Millionen von existierenden eMail-Adressen. Hoffentlich bekommt Google die Probleme schnell in den Griff... Quellen, Links & weiterführende Artikel: » Docs & Spreadsheets-XML-Kontakte » Video-XML-Kontakte » Skript von Haochi » Entdeckung der API » Aufruf des Contact Picker » Google Mail-Kontaktliste » Veröffentlichung des Skripts » Problem teilweise gelöst » Zusammenfassung von Haochi » Bericht bei anty.at » Bericht bei heise Update: » Google Mail ContactPicker jetzt bei Google Video und Spreadsheets

Sicherheitslücke in Googles Search Appliance

Veröffentlicht am 29. November 2006 von Jens

Googles Suche für Webseiten oder die Search Appliance kann mit einer kleinen Parameterändeung eine Sicherheitslücke für die eigene Seite darstellen. Wenn man Google anweist den Suchstring mit dem Zeichensatz UTF-7 statt UTF-8 zu interpretieren, funktionieren die Filter nicht richtig und führen beliebigen JavaScript-Code aus. Normalerweise fangen Googles Filter alles ab dass der Webseite gefährlich werden könnte, dazu gehört neben HTML-Code natürlich auch jegliche Art von Scripten. Dies klappt aber nur wenn der korrekte Zeichensatz eingestellt ist, via dem Parameter oe=UTF-7 lässt sich der Zeichensatz aber dahingehend verändern dass eben diese Filter nicht mehr richtig funktionieren. Damit kann z.B. der Code

< script >alert("Es funktioniert!")< /script >

ausgeführt werden in dem er einfach als Suchstring eingegeben wird. Eine ernste Sicherheitslücke. Im schlimmsten Fall kann die gesamte Webseite mit JS zerstört werden oder Daten der User herausgefiltert werden. Anfällig dafür ist jede extern verfügbare Google-Suche, inklusive der teuren Search Appliance. Brisant an der ganzen Sache ist, dass die Sache schon seit über einem Jahr bekannt ist und damals auch noch in der Websuche funktioniert hat. In der eigenen Suche hat Google den Fehler innerhalb weniger Stunden ausgebessert, hat dies aber für die Angebote seiner Partner schlicht und einfach vergessen... Aber ich denke dass die Googler mittlerweile mit Hochdruck dran arbeiten. P.S. Besteht eigentlich Hoffnung dass es eines Tages nur einen einzigen Zeichensatz geben wird? Ich hasse die Inkompatibilität der beiden, wie oft mir dadurch schon Zeichen verloren gegangen oder verkrüppelt worden sind... [heise security]

Gefälschte Login-Seite auf dem google.com-Server

Veröffentlicht am 16. September 2006 von Jens

Eine ebenso interessante wie erschreckende Sicherheitslücke ist jetzt auf dem Google-Server aufgetaucht. Unter der Adresse google.com/u/gplus befand sich bis vor wenigen Stunden eine Login-Page für das neue Google Mail Plus - vermeintlicherweise. Google Mail Plus existiert nicht, die Login Page leitet auf eine externe Webseite weiter die die Login-Daten anzeigt und zeigt so sehr eindrucksvoll wie einfach man an User-Daten kommen kann. Tja, aber wie funktioniert das ganze nun?

Zu aller erst: Die Login-Seite liegt tatsächlich auf dem Google-Server, es wird keine Weiterleitung oder ähnliches vorgenommen. Die Seite wurde mit Google Public Service Search erstellt, welche es erlaubt das Aussehen der Suchergebnisse ganz individuell an die eigene Webseite anzupassen. Dies war ursprünglich für Universitäten und Organisationen gedacht, hat aber auch alle anderen User aufgenommen. Dieses Angebot stammt noch aus der Zeit als Google eine reine Suchmaschine war und der Google Account nicht existierte. Das Problem liegt jetzt an der Anpassbarkeit dieser Suchergebnisse. Es können Header- und Footer-Code komplett frei geändert werden. Dies hat sich diese Seite zu Nutze gemacht und via JavaScript nach und nach die komplette Google-Suche entfernt und durch den eigenen Inhalt - eben jene Loginseite - ersetzt. Das gefährliche ist nun, dass diese Seite - da sie auf google.com liegt - auch Zugriff auf die Cookies hat, und somit, selbst ohne die Login-Daten des Users, den Google Account entführen und sich zu nutze machen könnte. Google hat das Problem mittlerweile erkannt, die Seite deaktiviert und das gesamte Public Service Search gleich mit heruntergefahren. Neue Registrierungen werden derzeit nicht angenommen und auch bestehen User können sich derzeit wieder einloggen noch Templates verändern. Die Suchfunktionalität ist aber weiterhin komplett gegeben. -- Tja, da muss Google aber wirklich aufpassen. Zum Glück wurden die Login-Daten von dem User der die Seite erstellt hat nicht gespeichert. Ein böswilliger Hacker hätte diese Adresse im Web verteilen, als neuen Google-Service ankündigen und so jede Menge Daten sammeln können. Der Reiz ein neues Google-Produkt als erster zu testen ist zu groß, als dass man auf die URL achten würde... » Stellungnahme im Google Webmaster Blog » Google Public Service Search » Diskussion bei Google Blogoscoped [Googlified] Nachtrag: » Lösung für das Public Service Search-Problem

Writely speichert Passwörter im Quelltext

Veröffentlicht am 15. Juli 2006 von Jens

Ohoh, da haben die Writely-Entwickler aber nicht aufgepasst. Die Zugangsdaten zum eigenen Blog, sofern man sie denn angegeben hat, stehen offensichtlich und unverschlüsselt im Quelltext von Writely. Zwar sind sie nur in der Bearbeitungsansicht zu sehen, aber trotzdem haben sie im Quelltext nichts zu suchen und stellen eine Gefahr da. Der Fehler tritt auf wenn man Writely dazu benutzt Blog-Postings aus der Ferne zu schreiben. Dieses Feature bietet fast jede Blog-Software mittlerweile an und ist schon üblich. Es wird also der Text in Writely geschrieben und formatiert und dann an den Blog gesendet welcher es in der Form automatisch veröffentlicht. Dafür braucht Writely natürlich die Zugangsdaten des Blogs, die man der Software vertrauensvoll gibt. Solche Variablen sollten eigentlich auf dem Server zwischengespeichert werden und nicht im Quelltext und damit für jeden zugänglich der Zugriff auf den Writely-Account hat. Und selbst wenn die Daten aus irgendwelchen technischen Gründen an dieser Stelle gespeichert werden müssten, was aber mehr als unwahrscheinlich ist, könnten sie wenigstens verschlüsselt werden. Ich hoffe dass Writely diesen Fehler schnellstens behebt und nicht noch andere Lecks dieser Art in den Untiefen der Software versteckt hat. » Entdeckung bei Googlified » Screenshot des Quelltextes Nachtrag: » Writely entfernt Passwort aus dem Quelltext

Schwachstelle in Analytics

Veröffentlicht am 12. April 2006 von Jens

Terrill hat in seinem Blog eine Schwachstelle von Google Analytics aufgedeckt. Es ist ohne Probleme möglich, die eigene Website mit einem fremden Analytics-Code zu bestücken und so die Analysen der ursprünglichen Website zu beeinflussen. Erstmal sieht es so aus, als wenn das eine echte Schwachstelle wäre und Google dies einfach nicht bedacht hat. Doch es ist möglich, das Tracking nur auf bestimmte URLs einzuschränken. Dies ist nur standardmäßig deaktiviert, da die meisten Personen mehrere Webseiten betreiben und Google diesen Webmastern nicht das Leben erschweren wollte. Zwar ist diese Erklärung - die Google in diesem Blog sogar offiziell abgegeben hat - eher blödsinnig, aber immerhin ist es doch keine Lücke in Analytics. Blödsinnig deswegen, weil nur sehr erfahrene Webmaster etwas mit Analytics anfangen können - und es für diese wohl kein Problem wäre die URL-Sperre von Hand zu deaktivieren. » Blog-Eintrag » Google Analytics Hilfe: Include and exclude filters