15 Jun, 09
Seit geraumer Zeit geistern immer mal wieder Links zu Seiten herum, die die History der besuchten Webseiten auslesen. Mal mittels JavaScript, mal ohne. Momentan ist making-the-web recht frisch. Daher, damit nicht immer wieder selbe Panik aufkommt und ich immer wieder die selbe Argumentation führen muss:
- Ja, die History kann in gewissem Maße ausgelesen werden.
- JavaScript ist dafür nicht nötig.
- CSS schon.
- Es kann nur ausgelesen werden, was auch vorhanden ist. Wer seine History auf 7 Tage begrenzt, bei dem sind auch maximal 7 Tage ‘auslesbar’.
- Es können nur exakte Treffer ausgelesen werden.
Das Verfahren sieht so aus: Die Seite fragt den Browser, ‘wurde die URL bereits besucht?’ - volle URLs, wohlgemerkt! Wenn man also nur eine Unterseite von Slashdot, Heise, oder meinetwegen YouPorn aufgerufen hat, und die Ausleseseite nur nach ‘http://slashdot.org/’, ‘http://www.heise.de/’ oder eben ‘http://www.youporn.com/’ fragt, dann wird der Besuch nicht erkannt. Das bedeutet außerdem: Um das Surfverhalten breit genug zu erfassen, braucht man eine sehr, sehr lange Liste mit Adressen und ausreichend Zeit.
Also - seid euch bewusst, welche Daten gespeichert sind und wie sie genutzt (oder missbraucht) werden können. Panik jedoch ist unangebracht.
02 Mar, 07
Update: The announcement is out. The important part is:
[…] a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file […]
Nothing in the Subversion repository was touched, so if you upgrade and maintain your blog via SVN there is no chance you downloaded the corrupted release file.
This is the kind of thing you don’t want to happen to anyone.
Kudos to the WordPress guys for their quick reaction.
Original entry below.
The following mail was just posted to the WordPress mailing lists, as a reaction to this security advisory. There are multiple XSS vulnerabilities in WordPress <= 2.1.1 — inserted by a cracker — and an upgrade is urgently recommended.
Subject: Upgrade to 2.1.2
From: Matt Mullenweg m at mullenweg.com
Date: Fri Mar 2 19:41:35 GMT 2007
Hello everyone.
If anyone is running 2.1.1, or knows someone who is, I would recommend
upgrading to 2.1.2 as soon as possible. It is now available at
http://wordpress.org/download/
The md5 of the tar.gz is b1ae0c152e60300cba8c40c030baafd4.
No announcement quite yet, but coming soon. Thanks for your help.
Read the full announcement on wordpress.org.
22 Nov, 06
Mozilla today made bug #360493 public. It describes an attack using cross-site forms and a security flaw in the Firefox Password Manager to read stored passwords for a different site. There is a proof of concept that demonstrates that the bug can even be abused without any hint to the user - the form need not be visible for the auto-fill of the credentials to work, and Firefox does not even give a warning.
The type of attack has been coined a Reverse Cross-Site Request (RCSR).
As of the time of this post, there is no fix available. However, a possible workaround is to set a Master Password and use the Master Password Timeout extension with a very short timeout. One can also disable the password manager altogether.
The bug existed since at least Firefox 1.5. Also, similar bugs seem to exist in at least IE 6 and 7, but Microsoft say they’re working on a fix.
21 Nov, 06
Jaja, die Leute schreiben immer noch übers StudiVZ. Also schreib ich jetzt endlich mal die Sachen auf, die ich in den letzten Monaten (seit meiner Anmeldung beim StudiVZ, Mitte September) so bemerkt habe.
Das mit den Bilder-URLs ist ja schon stadtbekannt. Natürlich machen alle anderen Großen - wie Xing, flickr, etc. - auch so, und das macht es nicht viel besser, aber das ist ja kein Grund, nicht darüber zu schreiben. Man kann also auf Bilder immer zugreifen, wenn man eine direkte URL hat. Na gut.
Viel interessanter fand ich: Die User-IDs sind nicht unique. Man kann die ersten 8-24 Bits (je nach Länge der ID) recht frei ändern und landet immer noch auf dem selben Profil. Das selbe gilt für die Album-IDs und vermutlich auch für die Bild-IDs. Na, was das wohl für ein Algorithmus ist… *hust*
Jedenfalls kann man so sehr leicht alle Benutzer, Alben und Bilder enumerieren, indem man der showalbum.php beliebige IDs in relativ großen Schrittweiten gibt. Wenn man einen Treffer hat, steht die ‘wahre’, primäre Album-ID (sowie Titel und Besitzer) im Seitenquelltext. Damit kann man dann den Bildserver behämmern. Für nicht-öffentliche Alben muss man dann nur den Rest des Suchraums durchgehen, oder man knackt einfach die ID-Erzeugung. Der Bilderserver geht jetzt schon merklich in die Knie.
Listen aller Alben eines Benutzers gibt’s bei showpeoplealbums.php, wobei auch hier gilt: etwa die Hälfte der ID ist eh wurscht. Es gibt verschiedene Meldungen für “Album ist noch leer” und “hat keine Alben”.
Immerhin hat man durch die eigenen IDs (3-6 Zeichen) gegenüber UUIDs (16-36 Zeichen) Traffic gespart…
Auch interessant: Das StudiVZ benutzt offenbar Smarty und sajax. Smarty, klar, sinnvoll. Sajax, auch sinnvoll, aber hoffentlich haben sie nicht zu viele Funktionen exportiert, auf die Normalsterbliche eigentlich gar nicht zugreifen können sollten. Na, wer will’s testen?
Was haben wir noch … ach ja, das mit den nichtöffentlichen Profilen? Geht ja auch grade durch die Welt… sei es nun friends.php oder profile_guestbook_large.php oder showpeoplealbums.php, man kann sich so ziemlich alle Teile eines “privaten” Profils ansehen. Hübsch. Da fällt auch das “Diese Nachricht wurde von Foobar gelöscht und
wird anderen Mitgliedern nicht mehr angezeigt” nicht mehr ins Gewicht.
Hätte ich mich doch nur noch ein paar Wochen länger geweigert, da mitzumachen! Le seufz! Todo für morgen: Profile meiner Freunde scrapen, mein Profil löschen, Freunde per ICQ anhauen, done. Gute Nacht.
05 Dec, 05
Just got 26 requests from some bot or script looking for unprotected installations of phpMyAdmin. The requests, one per second, were made to the following URIs:
- /phpmyadmin/main.php
- /PMA/main.php
- /mysql/main.php
- /admin/main.php
- /db/main.php
- /dbadmin/main.php
- /web/phpMyAdmin/main.php
- /admin/pma/main.php
- /admin/phpmyadmin/main.php
- /admin/mysql/main.php
- /phpmyadmin2/main.php
- /mysqladmin/main.php
- /mysql-admin/main.php
- /main.php
- /phpMyAdmin-2.5.6/main.php
- /phpMyAdmin-2.5.4/main.php
- /phpMyAdmin-2.5.1/main.php
- /phpMyAdmin-2.2.3/main.php
- /phpMyAdmin-2.2.6/main.php
- /myadmin/main.php
- /phpMyAdmin-2.6.0/main.php
- /phpMyAdmin-2.6.0-pl1/main.php
- /phpMyAdmin-2.6.3-pl1/main.php
- /phpMyAdmin-2.6.3/main.php
- /phpMyAdmin-2.6.3-rc1/main.php
- /phpMyAdmin-2.6.2-rc1/main.php
The requests all originated from 66.235.201.231 (ds201-231.ipowerweb.com, which doesn’t forward resolve). A portscan shows ports 21 (ftp: ‘Microsoft FTP Service’), 25 (smtp: ‘Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830’), 54 (ftp: ‘Serv-U FTP Server v5.2 for WinSock’), 80 (http: ‘Microsoft-IIS/6.0’), 135, 139, 445, and 1433 open. Some ports just above 1024 are sporadically open. The host is probably a zombie.
I’ve mailed {abuse,hostmaster}@ipowerweb.com at 01:17 CET.
If you’re running any management software without proper protection (IP-based where possible, HTTP Authentication with a strong password at least), this is your last warning call.
Even for protected directories, you should change the default directory name, e.g. by appending a random string to make ‘phpMyAdmin_Irogah2A’ (pwgen is great for this), just to make it harder to find and thus (somewhat) protect from brute force attacks. (Yes, this is obscurity at work. Security by obscurity is only bad if it’s the only line of defense, but it’s great as an additional safety measure.)
PS: If you’re running phpMyAdmin <= 2.6.4, upgrade to the latest version.
Update 2005-05-12 22:09
Response (Angel P.) 12/05/2005 01:06 PM
Thank you for contacting the iPowerWeb Abuse Department.
We apologize for any inconvenience this may have caused you. We have taken action regarding the network scan originating from our network.
Thank you for your time and patience.
Security, Javascript, History, Browser and CSS