Nun stecke ich in einem Dilemma, welches wohl viele White-Hat-Hacker kennen. Ich habe von Schwachstellen in verschiedenen Softwareprodukten Kenntnis und die Hersteller meinen nur:

Diese Schwachstellen sollte es in [...] nicht geben. Mail an unsere QA weitergeleitet.

Wenn denn überhaupt eine Rückmeldung kommt…

Bei einer Lücke ist ein Script betroffen über das man alle (!) Dateien runterladen kann, anstatt nur die vorgesehenen PDFs – und dies hoch bis zum ROOT. Da in dem CMS (wie üblich) die Zugangsdaten zur Datenbank in einer Datei im Klartext stehen, hat man dadurch auch Zugriff auf diese und somit auf alle Userdaten.

Wenn aufgrund meiner Hinweise nichts unternommen wird um die Betroffenen zu informieren und entsprechende Updates anzubieten, so wäre dies nicht wirklich ungewöhnlich, wie man an dem (angeblichen) China-Google-Hack sieht. Microsoft hatte im September Hinweise zu der Lücke im Internet Explorer erhalten, aber erst vor ein paar Tagen ein Update angeboten. Hat man in Redmond geglaubt dass nur der der ihnen den Hinweis geliefert hat die Lücke kannte?

Die Lücken die ich noch auf Lager habe und für die sich die Hersteller bisher nicht interessieren, sind nicht so schwer zu finden, dass ich annehmen kann nur ich wäre im Besitz des Wissens darum.

Was mach ich nun? Warten bis die Hersteller sich bequemen zu handeln oder selber die betroffenen Seitenbetreiber kontaktieren oder einfach die Schwachstellen veröffentlichen?

Ich könnte mir auch einfach nur die bekanntesten/größten Seitenbetreiber raussuchen, sie über die Lücken informieren, mit dem Hinweis, der Hersteller hat auf meine Meldung nicht entsprechend reagiert. Wenn ein Betroffener dann mit einer Pressemitteilung droht – nach dem Motto: “Wir wechseln den Anbieter unseres Systems weil der bisherige Anbieter gemeldete Schwachstellen nicht behebt.” – dann ergibt sich ein gewisser Handlungsdruck, dem sich nur wenige entziehen können.


Noch ein paar Worte zu meinem “angeblich”: Woher weiß Google, und natürlich auch die US-Regierung, dass die chinesische Regierung hinter den Angriffen steckte?

War die Identifizierung der Angreifer so effektiv wie das Aussperren deutscher Youtube-Besucher?

Dieses Video enthält Content von [...] Es ist in deinem Land nicht mehr verfügbar.

(Stichwort: Proxy-Server)

Wenn mal wieder jemand versucht eine PHP-Shell in meinen Blog zu injizieren, so kommt der (angeblich) auch aus China. Hat die chinesische Regierung auch ein Interesse an meinem Geschreibsel und dem was sonst so auf dem Server liegt? Ganz bestimmt nicht!

Halb- und Unwissenheit für politische Zwecke zu missbrauchen, steckt wohl eher hinter dem China-Bashing.

Und – natürlich betreibt die chinesische Regierung Informationsbeschaffung auf diesem Wege, genauso wie alle anderen Regierungen dieser Welt auch.

Was so selbsternannten Programmierer für Zeuch koten:
<?php
$_GET['file'] = urldecode($_GET['file']);
if(is_file('./uploads/media/'.$_GET['file'])) {
    header("Content-type: application/pdf");
    header("Content-Disposition: attachment;
      filename=downloaded.pdf");
    readfile('./uploads/media/'.$_GET['file']);
}
?>

Das Script steckt in einer Website die TYPO3 benutzt. Da könnte man mit
http://domain/dau.php?file=../../typo3conf/localconf.php
schnell zum Ziel kommen. ;O)


Wer ein Download-Script selber coden möchte, der kann sich dies mal anschauen:
“Dateidownload realisieren” (selfphp.de)

Es wird auch erklärt worauf man achten muss, damit eben nicht das obige Malheur passiert.

Unternehmen setzen offenbar beim Schließen von Sicherheitslücken in Client-PCs die Schwerpunkte falsch. Obwohl Kriminelle fast nur noch Lücken im Adobe Reader, QuickTime, Adobe Flash und Microsoft Office ausnutzen, um Windows-PCs zu infizieren, verstreicht bis zum Installieren von Sicherheits-Updates doppelt so viel Zeit wie für das Schließen von Lücken in den Betriebssystemen

Dies liegt wohl primär daran, dass das Betriebsystem automatisch, sofern man es nicht deaktiviert hat, nach Updates schaut und, wenn vorhanden, selbstständig installiert. Bei anderer Software gibt es nicht immer diesen Automatismus. Der Adobe Reader z.B. melden sich wenn es ein Update gibt, aber der Flashplayer tut keinen Mucks.

Untersuchungen zufolge erhöhen stille Updates ohne Nachfrage beim Anwender die Patchrate.

Dies mag wohl stimmen, beinhaltet aber immer die Gefahr, dass andere Software plötzlich nicht mehr funktioniert. In einem Unternehmen wäre es natürlich tödlich, wenn plötzlich die Buchhaltungssoftware nicht mehr funktioniert und es für diese keine Updates zu dem gepatchten Betriebssystem gibt.

Schnell Updates einzuspielen ist zwar wichtig, aber wenn man nicht 100% sicher ist, dass auch die andere Software weiterhin reibungslos funktioniert, so ist dies schon ein Problem. Wenn man eine gut funktionierende IT-Abteilung hat, dann prüfen die, ob ein Update zum Totalausfall führen kann. Aber was macht der Privatnutzer oder der Kleinunternehmer der keine IT-Abteilung hat? Das ist gar nicht so leicht zu beantworten. Auf jeden Fall ist es immer gut, wenn man sich vor einem Update noch einmal ein Backup zieht, da es i.d.R. keine Möglichkeit gibt ein Update rückgängig zu machen.

Manchmal ahnt man auch gar nicht welche Software voneinander abhängig ist. Es ist noch immer Software in Unternehmen im Einsatz, die den Explorer 6 voraussetzt. Wer nun das automatische Update auf den 8er Explorer durchführt, könnte plötzlich ohne seine funktionierende Asbachuralt-Software dastehen.


Dies kennt wohl jeder Benutzer des Firefox: Man will ein Update auf die gepatchte Version machen und dann mault er, dass nach dem Update verschiedene Plugins nicht mehr funktionieren werden. Ja und nun? Den Firefox updaten oder warten bis auch die geliebten Plugins ein Update erfahren haben?

Für den Firefox gibt es da einen kleinen Kunstgriff: “Nightly Tester Tools” (addons.mozilla.org)

Mit diesem Plugin kann man den Firefox dazu zwingen, auch Plugins die angeblich nicht mehr funktionieren werden, trotzdem zu nutzen. I.d.R. steckt die Inkompatibilität nur in der im Plugincode enthaltenen FF-Versionsnummer, für die das Plugin entwickelt wurde. Bisher haben noch alle Plugins, die ich mit diesem Tool nachbehandelt habe, ohne Probleme funktioniert.


Und noch etwas aus dem Artikel:

60 Prozent aller Attacken im Internet richten sich mittlerweile gegen Webserver, um etwa SQL-Injection zu finden und auszunutzen. Mehr als 80 Prozent aller Lücken in Servern entfallen auf SQL-Injection- und Cross-Site-Scripting-Lücken.

“Shopping.De: Amazon-Klon Oder Mehr?” (alles2null.de)
Dort hinterließ ich am vergangenen Sonntag einen Kommentar:

Shopping.de mag zwar wie Amazon aussehen, aber was sie Sicherheit angeht ist es unvergleichlich…

In dem Shopsystem kann man reflektives und persistentes Cross-Site Scripting ausnutzen. Mit XSS kann man dann den Session-Cookie auslesen und mit dem ist es möglich sich in den Account des Opfers einzuloggen.

Einkaufen würde ich dort nicht, solange diese eklatanten Sicherheitslücken nicht geschlossen wurden.

Unister kam dann am Montag auch über den Kommentar auf mein Blog, hätte sich also evtl. auch etwas über XSS informieren können, sofern sie es nicht kennen. Bisher wurde nur eine Lücke geschlossen, aber auch nur weil dort schon jemand etwas für jeden Shopbesucher sichtbares hinterlassen hatte. Warum wurden die anderen Lücken noch nicht gefixt?

Sorry Unister, aber ich kann es einfach nicht verstehen, wie man Millionen für eine Domain ausgibt, aber dann bei der Sicherheit des Shops so versagen kann.

Es geht um die wp-login.php und die Zeile 188:
$key = preg_replace('/[^a-z0-9]/i', '', $key);

Was macht denn nun diese eine Zeile PHP? Eigentlich nicht viel, sie wandelt nur alle Zeichen die nicht Buchstaben (a-z) oder Ziffern (0-9) sind in das Zeichen zwischen den Hochkommas '' um, löscht sie also. Ja, das war schon alles. Diese eine Zeile Code macht nun WordPress nicht unsicher, zeigt aber, wie Herr Ruef es nennt, eine “Art der defensiven Programmierung”.

Da $key (laut Ruef) nur ein MD5-Hash sein darf,

• Buchstaben von a bis f
• Ziffern von 0 bis 9
• Länge: 32 Zeichen

ist ganz klar festgelegt, was vom Script verarbeitet werden darf und was sofort als Fehlfunktion bzw. Angriff eines Hackers gewertet und abgebrochen werden muss.

Hätten sich die WP-Entwickler ähnliche Gedanken über die Sicherheit gemacht wie Herr Ruef, so würden alle Prüfungen die nach der Zeile 188 vorgenommen werden, auch wenn es kein MD5-Hash ist, nicht ausgeführt – die weitere Verarbeitung würde mit einer Fehlermeldung abgebrochen werden – aber dem ist leider nicht so.

Genau solche vermeintlichen Kleinigkeiten, führen in der Summe eines Projektes (WP hat 276 PHP-Dateien), im Zusammenspiel unzähliger Scripte, sehr schnell zu Fehlern, die dann eben doch kritisch sein können.


Ich habe es ja auch immer wieder mit Entwicklern zutun, die eher darauf schauen das ihr Code schnell ausgeführt wird und möglichst wenig Zeilen verbraucht (sic!). Sie wollen oft nicht einsehen, dass es immer besser ist, sich den Code auch von der Seite des Hackers her anzuschauen und zum Beispiel alle Benutzereingaben abzufangen und auszuschließen, die nicht benötigt werden.


Warum muss z.B. ein Feld für deutsche Postleitzahlen mehr als 5 Ziffern aufnehmen, Buchstaben und Sonderzeichen erlauben und in der Datenbank 255 Zeichen speichern können? Damit sich der Entwickler keine Arbeit machen muss, wenn ein nicht-Deutscher sich verlaufen hat. ;O)

Bisschen ergoogelt (ext:sql dump blz|plz):

`plz` varchar(64)
…
`PLZ` int(11)
…
`plz` decimal(10,0)
…
`plz` varchar(255)
…
`blz` text
…
`blz` varchar(64)

Passend zu mehr Sicherheit in WP dies:
“Mehr Sicherheit für WordPress 2.8.5” (entwickler.de)

Da soll der Admin in Zukunft nur noch bestimmte Datei-Typen in die Mediathek hochladen können und ein gehackter Admin-Account von WordPress wird damit sicherer?!

entwickler.de bezieht die Info von Robert Wetzlmayr:
“Neu in WordPress 2.8.5: Sichere Mediathek” (talkpress.de)

Und auch der offizielle deutsche WordPress-Blog schreibt:
“Neue Sicherheitsbestimmung für die Mediathek in 2.8.5” (blog.wordpress-deutschland.org)

Was hindert den Hacker daran, der nun Admin ist, ein Plugin zu installieren, mit dem er die MIME-Typen der Whitelist wieder aufbohrt? Und was hindert ihn daran, einfach im Theme eine Datei zu editieren, um dort eine R57-Shell einzufügen?

Ich kann nur hoffen das die WP-Entwickler diese Änderung nicht wirklich als Beitrag zu mehr Sicherheit in WordPress einstufen.

Für die Gestaltung (HTML, CSS etc.) der web sites unserer Kunden sind wir nicht direkt verantwortlich. Dies geschieht im Projekt durch den Kunden selbst oder einen ausgewählten Systemintegrator.

Wir liefern den Kunden das unterliegende CMS mit dem prinzipiell beliebige Ausgabeformate (HTML, WML, PDF etc.) erzeugt werden können.

Nach 90 Tagen Bedenkzeit, ist die Antwort bisschen dürr und sehr Falsch!

Der Webdesigner der einen Designentwurf in ein fertiges Template für ein CMS umsetzt, hat mit HTML und CSS keinen Einfluss auf die Validierung, sprich – was das CMS mit den übergebenen Daten aus Formularfeldern anstellt oder wie Steuerungsparameter in der URL verarbeitet werden.

Nur mit JavaScript könnte im Template eine Vorabprüfung stattfinden, die aber leicht umgangen werden kann und eigentlich nur zur Verbesserung der Usability Sinn macht, in der Form, dass z.B. in einem PLZ-Feld nur Ziffern eingegeben werden können. Wenn nun aber direkt in einem Link (GET) oder per selbstgebasteltem Script (POST) andere Zeichen als Ziffern übergeben werden, so greift das JavaScript nicht, da muß dann das CMS entsprechend reagieren.

Es besteht auch die Möglichkeit das die von mir gefundenen Lücken nicht direkt dem CMS anzulasten sind. Ein Kunde möchte etwas in seiner Website nutzen, was das CMS nicht anbietet, also muß eine Erweiterung dafür entwickelt werden. Der Entwickler der Erweiterung ist dann für die Prüfung der übergebene Daten verantwortlich. Wenn der Entwickler diese Prüfung nicht sorgfältig genug integriert, so ist das CMS zwar anfällig für Angriffe, aber dies liegt dann nicht im Einflussbereich des Herstellers des CMS.

Allerdings waren auch Lücken in der Suchfunktion des CMS. Ich gehe mal davon aus, dass jedes CMS heutzutage eine Suchfunktion mitbringt. ;O)


Wer hat mir denn da geantwortet?
Kein Geringerer als der “Executive Director”.
Von der Putzkolonne?
Nein, von der Abteilung “Technical Services”.


Ok, nur weil er der Verantwortliche für die Abteilung ist, muß er nicht wirklich tiefgreifendes Fachwissen besitzen, vielleicht ist er sehr gut in der Führung des Personals – aber eine so falsche Antwort…

Titel können mich nicht beeindrucken – nur Fachwissen ist dazu in der Lage.

Sobald ein Link per CSS (float: right) nach rechts ausgerichtet wird, funktioniert er mal oder mal nicht, grad so wie der Safari es mag – i.d.R. funktioniert er nicht.

Und hier der Quellcode dazu:
<a href="#">Testlink Nr. 1</a>
<a href="#" style="float: right;">Testlink Nr. 2</a>

Ob und wie man diesen Bug mit einem CSS-Hack austricksen kann weiß ich nicht, auf jeden Fall habe ich es nicht geschafft und auch noch keine Hinweise dazu gefunden.


Zum Teil wird auch behauptet, der Safari 4 würde den Acid3-Test (acid3.acidtests.org) komplett bestehen…

…auf meinem Äpfelchen aber nicht.


Und das Schließen von Tabs per Äpfelchen-W führt oft dazu, dass das ganze Fenster, inkl. aller Tabs, geschlossen wird. Auch ein sehr ärgerlicher Bug.


Auf Windows gibt es den CSS-Bug nicht, dort besteht er auch den Acid3-Test komplett und das Schließen von einzelnen Tabs per CTLR-W bereitet auch keine Probleme.

Wollen die Apfelmännchen mich dazu bringen wieder auf Windows umzusteigen?

Seit der Firefox in der 3ten Version mit den Schriftgrößen irgendwie nicht mehr das anzeigt wie der 2er und ich auf vielen Seiten, den Text größer oder kleiner schalten muß – trotz meiner Voreinstellung im FF, bin ich auf den Safari umgestiegen. Auch wenn ich schon seit knapp drei Jahren nur noch mit OS-X arbeite, habe ich den Safari vorher nie wirklich benutzt, da ich von Windows noch den Firefox gewöhnt war.

Vor ein paar Monaten habe ich schon einmal über einen Bug im Safari geschrieben. Ab der Version 3.2 mußte ich immer nach dem Start, das aktuelle Fenster schließen und ein neues öffnen, damit die Adresszeile auch richtig funktioniert.

Seit ein paar Tagen… (oder sind es schon Wochen… Altenheimer…) habe ich ein sehr sonderbares Verhalten des Safaris festgestellt. Ich bin ja ein paranoider Mensch und klicke immer artig auf “Abmelden” oder “Ausloggen”, nachdem ich eine WebSite verlasse, in der Hoffnung das niemand an Daten von mir kommt, die er nicht haben soll – nur der Safari hat da irgendwie seinen eigenen Kopp.

Wenn ich mich z.B. in meinen Google-Account einlogge, dann auslogge, etwas surfe und nach ein paar Minuten die Google-Suche aufrufe, dann sehe ich oben rechts meine E-Mail-Adresse und “Abmelden”, also bin ich wieder eingeloggt?! Erst dachte ich, naja, alde Leude, hab’ nur vergessen “Abmelden” zu klicken – Altenheimer! Aber nein, das läßt sich reproduzieren!

Dann habe ich mal alle Cookies gelöscht… und wieder! Dann schau ich mir die Cookies an… ALLE Cookies sind wieder vorhanden, obwohl die Meldung kommt, dass das Löschen aller Cookies nicht rückgängig gemacht werden kann – der Bugfari hat einen Weg gefunden.

Gestern habe ich die Beta4 vom Safari installiert, obwohl die 3er auch noch Beta war – zumindest auf meinem Mac. Der alte Bug, der mit der nicht richtig funktionierenden Adresszeile ist jetzt weg, aber der neue Bug ist noch vorhanden. Nur wenn ich den Safari beende, werde ich nicht mehr automatisch Eingeloggt und auch die automatische Cookiewiederherstellung wird nicht mehr ausgeführt.

Diesen neuen Bug konnte ich im 4er für Windows nicht feststellen, aber da haben die Apfelmännchen bestimmt noch andere Bugs versteckt. ;O)

Ich habe TeamViewer sofort ausprobiert, auf meinem Mac und den alten Windows-Rechnern – es läuft und das ganz einfach.


TeamViewer kann man hier runterladen: http://teamviewer.com/de/

Unter OS-X installiert man die Software wie üblich per Drag&Drop nach dem Entpacken der DMG. Unter Windows wird man nach dem Start der runtergeladenen EXE gefragt ob man die Software starten oder installieren möchte.

Die Software sieht auf Windows und OS-X sehr ähnlich aus:

Was noch fehlt ist eine Version für Linux.


Zwei Computer miteinander zu verbinden ist sehr einfach. Die ID des anderen Computers eingeben, auf “Mit Partner verbinden” klicken, dann das fremde Kennwort eingeben und… das war’s schon. :O)



Es gibt vier Modi: Fernwartung, Präsentation, Dateiübertragung und VPN. (VPN habe ich mir nicht angesehen.)

“Apple schließt acht kritische Lücken in Safari für Windows” (heise.de)

Bislang steht dort aber nur Version 3.1.2 zum Herunterladen bereit.

Man muß auch Apple nicht alles glauben… nach dem Klick zum Download folgt:

Der Download lädt dann die Safari3.2Leo.dmg runter und über die Softwareaktualisierung bekommt man ebenfalls die neue Version. Unter Windows heißt sie zwar einfach nur SafariSetup.exe aber es ist ebenfalls die 3.2er.


Nur leider ist der neue Safari für den Mac nicht ganz fehlerfrei.

Nach dem Klick auf Links aus der Lesezeichenleiste wird die Adresszeile nicht aktualisiert, beim weiteren Surfen auf den WebSites wird sie ebenfalls nicht aktualisiert und manche Links auf den WebSites selber funktionieren leider nicht.

Benutzt man Links aus den Lesezeichen (nicht der Lesezeichenleiste) so öffnet sich ein neues Fenster?! Aha! und dort funktioniert dann die Aktualisierung der Adresszeile wieder und auch alle Links auf den WebSites. Also Fehler gefunden und bis zum nächsten Update: Safari starten, erstes Fenster schließen und neues Fenster öffnen.

Sehr lästig dieser Bug, er tritt nicht unter Windows auf, nur unter OS-X.

Erst hatte ich nur das Update über die Softwareaktualisierung gemacht und danach noch einmal das komplette Pack installiert. Leider hat die Komplettinstallation den Fehler auch nicht behoben, da muß ich wohl bis zum nächsten Update mit diesem lästigen Bug leben…

Nicht nur Bananen reifen beim Anwender, auch manche Äpfel. ;O)

Auf milw0rm.com las ich grad das der 3.0.3 nun auch schon wieder ein Problem hat:
“Mozilla Firefox 3.0.3 User Interface Null Pointer Dereference Crash” (milw0rm.com)

Mit etwas JavaScript kann man den Firefox zum Absturz bringen. Ob dieser Absturz dann noch weiter benutzt werden kann, um z.B. Schadcode in das System zu schleusen, weiß ich noch nicht.

In dem Beispiel von secniche.org werden 6 Schleifen benutzt.

Ich habe mal ein kleines Script gebastelt mit dem man jede einzelne Schleife ausprobieren kann, ob sie zu einem Absturz des Firefox 3.0.3 führt.
Firefox 3.0.3 Crash – Script.

Bei mir konnte ich feststellen das nur die erste Schleife zu einem Absturz führt und dies jeweils unter OS-X und XP:

var moz303 = document.createEvent("UIEvents");

moz303.initUIEvent("keypress", true, true, this, 1);
for (var moz303_loop = 1 ; moz303_loop < 10 ; moz303_loop++)
{ document.documentElement.dispatchEvent(moz303); }