heise meldet massen-sql-hacks

[4huf]

tja, wer weis. Zu Hause gings auch ohne Probleme.
Ev. lag es daran das sich das NoScript aktualisiert hatte.
Hat dann wohl einige Einstellungen vergessen oder war nur auf "temporär" gestellt.
Auf jeden Fall gehts auch bei mir und das NoScript möchte ich in Zeiten von
SQL-Massenhacks nicht mehr missen.

[tox]

tja, wer weis. Zu Hause gings auch ohne Probleme.
Ev. lag es daran das sich das NoScript aktualisiert hatte.
Hat dann wohl einige Einstellungen vergessen oder war nur auf "temporär" gestellt.
Auf jeden Fall gehts auch bei mir und das NoScript möchte ich in Zeiten von
SQL-Massenhacks nicht mehr missen.

den zusammenhang versteh ich nich was hat die clientseitige ausführung von java-scripten mit serverseitigen sql-abfragen zu tun

[4huf]

den zusammenhang versteh ich nich ,was hat die clientseitige ausführung von java-scripten mit serverseitigen sql-abfragen zu tun

siehe http://www.heise.de/newsticker/Nun-auch ... ung/108741

Wenn Tausende Webseiten mit Links zu schädlichen Javascripten infiziert sind, dann
ist es praktisch ein Muß sowas generell zu blocken.
Die beiden im Artikel genannten URLs sind zwar inzwischen abgeschaltet, aber das heißt ja
nicht das die den Angriff nicht mir anderen URLs wiederholen.
Und wenn man man Google frage welche Seiten alles infiziert sind kann einem
wirklich schlecht werden :

http://www.google.com/search?hl=de&q=sc ... =Suche&lr=

[tox]

siehe http://www.heise.de/newsticker/Nun-auch ... ung/108741

Wenn Tausende Webseiten mit Links zu schädlichen Javascripten infiziert sind, dann
ist es praktisch ein Muß sowas generell zu blocken.
Die beiden im Artikel genannten URLs sind zwar inzwischen abgeschaltet, aber das heißt ja
nicht das die den Angriff nicht mir anderen URLs wiederholen.
Und wenn man man Google frage welche Seiten alles infiziert sind kann einem
wirklich schlecht werden :

http://www.google.com/search?hl=de&q=sc ... =Suche&lr=

k, da mag was dran sein, aber für mich klingt die sache ziemlich weit hergeholt. ich halte das für eher schwierig, sowas erfolgreich durchzuführen. insbesondere müsste man das datenbankschema kennen, weil die betreffende db ja offenbar aus irgendeinem grund die links zu scripten von den webseiten enthält. noch dazu gibt es wohl eher sehr wenige seite, die ein CMS von Interlogics einsetzen. und obendrein musst du ja auch noch diese seite aufrufen. als dritte bedingung muss dein browser ja auch noch für die exploits anfällig sein, und wenn du derart auf sicherheit wert legst, wirst du doch so einen browser gar nicht verwenden. alles in allem halte ich dieses problem, dass über sql-hacks (von massen kann gar keine rede sein), du auf schädliche scripte geleitet wirst, für völlig überbewertet.

dein beispiel aber mit der google-suche ist blödsinn! du suchst ja nach allen seiten, die ein script namens "b.js" benutzen. das ist nun wirklich nicht unüblich. dass heise da jetzt "script src=http://www.banner82.com/b.js" geschrieben hat, war doch nur n beispiel. exakt diese zeile kann aber genauso gut auch zu einem vernünftigen script führen.

nun gut, jedem das seine

[4huf]

Ich weis nicht ob du die den Artikel, den Ursprungsartike und die Komentare richtig durchgelesen hast.
Das hier gehört auch noch dazu http://www.heise.de/security/Hunderttau ... ung/106959
Fakt ist, das alle Aufrufe der Art "script src=http://irgend.was/b.js" immer von Windowsservern
kommt. Meist an der .asp zu erkennen.
Bis gestern hatte ich auch nur vorrangig http://www.adw95.com und http://www.banner82.com als Quelle der b.js gesehen.
Heute tauchen (wie vermutet) auch noch weitere wie http://www.refer68.com, http://www.exec51.com oder http://www.libid53.com usw. auf.
Siehe auch Rechtes Frame von http://www.bedienungsanleitung-telefon. ... =1&Regel=1 .
ACHTUNG http://www.libid53.com ist noch aktiv und verweist auf sysid72.com/b.js, wobei allerdings
http://sysid72.com/b.js nicht geliefert wird (403 Forbidden).
Da kann aber auch daran liegen das es mit wget nicht geht weil die ev. den Browser filtern.
WARNUNG Auf alle hier geannten Links nur mit abgeschaltetem Javascript klicken.
Es sind offenbar wesentlich mehr Seiten die gefähliche Scripte liefern und nicht abgeschaltet sind.

ich halte das für eher schwierig, sowas erfolgreich durchzuführen. insbesondere müsste man das datenbankschema kennen, weil die betreffende db ja offenbar aus irgendeinem grund die links zu scripten von den webseiten enthält. noch dazu gibt es wohl eher sehr wenige seite, die ein CMS von Interlogics einsetzen

Ich hab es auch nicht für so einfach gehalten, aber offenbar kennt dieses automatisch Tool genügend Lücken in der
IIS/MSSQL -Paarung um erfolgreich zu sein.
Offensichtlich gibt es Möglichkeiten so etwas in die SQL-Datenbank zu injizieren.
In den Kommentaren ist ein Beispiel. Ich verstehe zu wenig von den SQL-Befehlen. Aber so wie es aussieht
wird willkührlich in viele Tabellen der Scriptaufruf eingefügt. Irgendwo passt es schon.

als dritte bedingung muss dein browser ja auch noch für die exploits anfällig sein

ICH verwende wie gesagt Firefox + NoScrip.
Aber wie viel surfen mit dem IE ? Und es ist Fakt das der IE nach wie vor genügend Lücken hat oder nicht immer aktualisieren. ( Ein Windowsupdate über Modem ist z.B. unmöglich)
Und auch der Firefox oder andere alternative Browser sind bestimmt nicht Lückenfrei.

dass über sql-hacks (von massen kann gar keine rede sein), du auf schädliche scripte geleitet wirst, für völlig überbewertet

Eine Trefferzahl mehreren Tausend zähle ich (wie Heise) als Massen-Hack.
Ok, ich hab eine Seite gefunden wo im Text ein b.js vor kommt. http://www.phpblogger.net/2007/05/13/ja ... erbessern/
Das ist aber wirklich die Außnahme (unser Forum wird da jetzt auch auftauchen )
Denn weder "http://www.citycardplus.de/" wird im Titel-Tag ein Script von http://www.exec51.com/b.js nachladen,
genau so wenig wie "http://www.jobagentur-en.de" auch im Titel-Tag von http://www.banner82.com/b.js, mehrfach.
Erfreulicherweise sind etliche Seiten schon gefixt, so das sie nur noch durch den Google-Cache in der Suche auftauchen.
Andere Seiten sind einfach kaputt.

Ich empfehle jedem diese Gefahr nicht zu unterschätzen.
Musst man früher auf der Hut sein wenn man auf "dubiosen" Seite gesurft hat, so muss man das heute auch bei
allgemein "sicheren" Seiten sein.
Beispiele
http://www.bedienungsanleitung-telefon. ... =1&Regel=1 (halb zerschossen)
http://www.die-bonn.de/publikationen/pr ... asp?ID=383 ( hier auch noch ein script src=http://www.killwow1.cn/g.js drin !!)
http://www.baierbrunn.de/bfree/dl1.asp? ... _typ=Liste (lange Ladezeit wegen vielen b.js-Links)

[tox]

so, jetzt hab ich die zweite heise-meldung auch gelesen.

ich versteh deine aussage nicht. "script src=http://irgend.was/b.js" ist kein aufruf, sondern ein html-tag. der kann so von jedem webserver geliefert werden. und das hat auch nichts primär mir asp zu tun. ich will mal ein missverständnis aus der welt schaffen: ein webserver ist nicht für die dahinterliegende web-anwendung verantwortlich. wenn diese fehlerhafte webanwendung (in diesem fall das CMS von Interlogics) eine datenbank benutzt, liegt das nicht in der verantwortung irgenwelcher webserver. und um es gleich klar zu stellen, die IIS können nichts an dem fehler verursachen oder ändern, das problem würde dir genauso mit dem Apache für windows auftreten. und das hat genauso wenig was mit dem datenbankserver SQL Server (woher weißt du das eigentlich, dass es der is, ich hab das nirgendwo gelesen ) direkt zu tun. sql-injection funktioniert mit jedem dbms, sei es oracle, sei es db2, sei es mysql, sei es postgres! das schwache glied ist die fehlerhaft programmierte web-anwendung, die eingaben offenbar direkt für sql-abfragen benutzt. das lernt man in der ersten vorlesung über datenbanken, dass man nie, nie, nie, eingaben von userseite direkt an die datenbank weiterleitet.

und dann möchte ich gern mal einen beleg für die zahl "hundertausende" haben. heise nennt die zahl zwar, aber ohne sich auch nur im geringsten auf irgendwelche quellen zu beziehen.

desweiteren stimme ich dir natürlich zu, dass man gefahren im allgemeinen nicht unterschätzen sollte. und auch dass sql-injections sehr oft möglich sind, ist durchaus bekannt.
ich denke, wir haben alle unsere persönlichen vorsichtsmaßnahmen. die einen vertrauen lieber auf nützliche tools, die anderen lieber auf ihre erfahrung. ich meine nur, dass man es nicht übertreiben sollte mit den sicherheitsmaßnahmen, denn wer die freiheit zugunsten der sicherheit aufgibt, wird letztendlich beides verlieren

*split*

[4huf]

ich versteh deine aussage nicht. "script src=http://irgend.was/b.js" ist kein aufruf, sondern ein html-tag

Richtig. Diesen html-tag bezeichne ich als "Aufruf" weil er dieses betreffende Javascript aufruft.
Und eben dieser html-tag ist in die SQL-Datenbanken injiziert worden, so das er später in der "harmlosen" Webseite steht.

die IIS können nichts an dem fehler verursachen oder ändern, das problem würde dir genauso mit dem Apache für windows auftreten. und das hat genauso wenig was mit dem datenbankserver SQL Server

Ok, da könnte ich mich ev. zu weit aus dem Fenster gelehnt haben
Außerdem soll das keine Wertung oder ähnliches für/gegen irgend eine Webserver/SQL-Server sein.
Aber die Warscheinlichkeit das es sich bei .asp-Seiten und IIS + MS-SQL handelt ist recht hoch.
Ev. ist noch Oracle bei großen Firmen wie eplus als SQL-Server dahinter.
Die vielen Städte und Vereine haben vermutlich ein Standartpaket von einem Webhoster.
Wie das bei den Chinesen oder anderen Server ist weis ich auch nicht.
Das Problem scheint in DE in der script.asp zu stecken. (http://www.heise.de/security/news/foren ... 9283/read/)
Es kann aber auch sein das es noch mehr solcher verwundbaren asp´s gibt.

und dann möchte ich gern mal einen beleg für die zahl "hundertausende" haben. heise nennt die zahl zwar, aber ohne sich auch nur im geringsten auf irgendwelche quellen zu beziehen.

Naja, die Anzahl der Treffer bei Google ist schon eine ordentliche Zahl.
Wenn man sich die Mühe macht und die Suchanfragen verfeinert und dann zusammenzählt werden es auch nicht viel weniger ...

Sinn meines Postings war ja nur auf das Problem aufmerksam zu machen.
Und es ist offensichtlich wirklich ein Problem ob das nun 10000 oder 100000 Seiten betrifft spielt eine geringere Rolle..

[PapaBaer]

Also, ich halte das Problem auch für durchaus enrom. Wenn man bedenkt, dass da irgendwelche exploits im Netz verwundbare Webseiten suchen, was ja dank google auch kein großes Ding mehr ist, kannst du halt prinzipiell keiner Website mehr vertrauen, weil halt in jeder Seite per SQL-Injection bösartiges JavaScript stecken könnte.

Ich gehe mal davon aus, dass, wenn die Angriffe google nutzen, durchaus von Massenhacks gesprochen werden kann. Sollte doch kein Problem sein, da draußen inerhalb kürzester Zeit 1000de ungepatchter PHP / ASP / MONO / ... Seiten zu finden.

Wenn man dann noch bedenkt, dass über 50% aller User mit dem IExplorer unterwegs sind und sich davon 90% nicht auf dem aktuellen Patch-Level befinden, ergibt sich da doch ein enormes Potential.

Und dieses Potential betrifft nicht zwangsläufig nur die Windows/IExplorer/Dau-Leute. Wenn das Bot-Netz erst mal steht, bekommst du auch mit dem besten Linux die nächste SPAM-Welle.

jedem das seine

is nicht immer anbracht, mit so nem belasteten Zitat zu kommen, lustig ist es nie ...

[tox]

[...]

jedem das seine

is nicht immer anbracht, mit so nem belasteten Zitat zu kommen, lustig ist es nie ...

es tut mir ja sehr leid, wenn ich damit jemandem zu nahe getreten sein sollte, aber eigentlich wollte ich damit nur ausdrücken, dass es jeder halten kann, wie er es möchte. die einen sehen es als große gefahr, die anderen eher weniger, die einen benutzen NoScript, die anderen andere methoden...

[se]

juti, dann wäre das ja geklärt.