Deutsch | English

Netzhygiene

CERT.at sammelt Informationen zu konkreten Sicherheitsproblemen im österreichischen Teil des Internets, wie etwa infizierte Computer, manipulierte Webseiten oder fehlkonfigurierte Server. Dazu stützten sich CERT.at und GovCERT neben der eigens entwickelten Sensorik auf Quellen innerhalb der internationalen Gemeinschaft der IT-Sicherheitsbranche. Ziel ist es, das Niveau der Netzwerksicherheit in Österreich durch Informationen über Sicherheitsprobleme an betroffene Betreiber von IKT laufend zu heben.

IntelMQ - Open Source Software zur Verarbeitung von Informationen über Infektionen und Fehlkonfigurationen

Seit 2016 wird die Verarbeitung von automatisierten Berichten zu Sicherheitsvorfällen bei CERT.at von einer halbautomatischen Verarbeitung durch eine vollautomatische Verarbeitung mit IntelMQ ersetzt. IntelMQ wird als gemeinsames Projekt von mehreren europäischen CERTs als Open Source Software entwickelt, und wird von CERT.at im Rahmen der Förderung der EU für CERTs (Connecting Europe Facility Telecom, Cyber Security Call 2+3) maßgeblich betreut und weiterentwickelt.

Im Zuge dieser Umstellung wurde auch die Zuordnung von Einzelereignissen zu Tickets geändert. Einzelereignisse sind eine Sicherheitslücke, Fehlkonfiguration oder Malwareinfektion eines einzelnen Geräts (PC, Server). Diese Umstellung ist in den Statistiken des Ticketsystems zu erkennen, da sie aber schrittweise erfolgte, ist kein klarer Umstellungszeitpunkt mit entsprechenden Änderungen in den Grafiken sichtbar.

Früher wurden alle Datenquellen (etwa Ergebnisse der Scans von ShadowServer, oder Daten von Microsofts Digital Crime Unit) unabhängig voneinander verarbeitet. Da diese typischerweise einmal pro Tag einen Datensatz liefern, ergab sich so pro Quelle ein Report, ein Incident und dann pro vorkommendem Netzbetreiber eine Investigation. Nach der Umstellung gibt es zwar weiterhin tägliche Reports dieser Quellen, aber die Inhalte werden erst zusammengefasst und dann aufbereitet an die Netzbetreiber weitergesendet, anstatt umgekehrt, wie dies früher geschah. Weiters können nun auch Stream-basierte Datenquellen, bei denen ein ständiger Datenfluss besteht, anstatt eines täglichen Berichtes, direkt und einfacher verarbeitet werden. Das neue System basiert auf Einzelereignissen, genannt "Events", die jeweils eine einzelne Beobachtung bzw. Messung darstellen. Diese werden täglich pro Kategorie ("Taxonomie") als ein Incident zusammengefasst und verarbeitet. Die dahinterstehende Taxonomie geht ebenfalls aus einer europäischen Zusammenarbeit hervor ("eCSIRT II Taxonomy"). Damit soll erreicht werden, dass sowohl der Datenaustausch zwischen den CERTs, als auch ein länderübergreifender Vergleich der Statistiken, einfacher wird. Zu diesem Zweck nimmt CERT.at auch am europäischen Projekt "Reference Security Incident Taxonomy Task Force" zur Weiterentwicklung der Taxonomie für CSIRTs teil.

Der Effekt dieser Umstellung ist in den Graphen der Investigations gut erkennbar: So wurden die getrennten Investigations zu DDoS-Reflektoren per SNMP, NTP oder SSDP in E-Mails zu verwundbaren Systemen ("Vulnerable") zusammengefasst. Da es zwischen den Infektionsdaten-Quellen immer wieder Überschneidungen gibt, ermöglicht diese Vorgehensweise eine Vermeidung mehrfacher Einträge in Investigations und somit eine einfachere Verarbeitung durch die Netzbetreiber.

Da IntelMQ nicht mehr auf tägliche Reports per E-Mail angewiesen ist, ist es möglich die Infektionsdaten direkt ohne Verzögerung den Netzbetreibern weiterzuleiten. Es ist geplant, den Netzbetreibern ein Webportal zur Verfügung zu stellen, mit welchem diese die den Umfang, das Intervall sowie die Beschaffenheit der bezüglich ihres Bereiches gesendeten CERT-Meldungen selbst konfigurieren können.

Diese Umstellung beeinflusst die Vergleichbarkeit der Report/Incident/Investigation Zahlen mit den historischen Daten natürlich negativ. Dem ist jedoch entgegenzuhalten, dass die Zahl der E-Mails von CERT.at allein seit Beginn dieser Auswertungen nur bedingt etwas über den Sicherheitsstatus in Österreich ausgesagt hat. Grund dafür ist der Umstand, dass eine E-Mail, welche lediglich eine Infektion enthält, in dieser Betrachtungsweise einer E-Mail, welche tausende IP-Adressen enthält, rechnerisch gleichgestellt wurde. Aufgrund dieser Unschärfe ist die schlichte Anzahl gesendeter E-Mails zu Infektionen daher in ihrer Aussagekraft als Gradmesser für einen Status der Cybersicherheit in Österreich ungeeignet und sollte dafür nicht herangezogen werden.

Die Umstellung auf IntelMQ betrifft nicht die Meldungen über gehackte Webseiten und Phishings (in den Graphen sind dies die Kategorien Exploit Pack, Fake Pharmacy Hack, Phishing und Searcheengine Ranking Hack), diese wurden auch in der Vergangenheit schon als Einzelereignisse verarbeitet. Aussagekräftigere Lageinformationen bekommt man aus den Daten zu Events, die den folgenden Statistiken zugrunde liegen.

Botnetze in Österreich

Die vorhandene Datenbasis hinsichtlich der in Österreich verbreiteten Botnetze hängt sehr stark von der Möglichkeit ab, diese Daten auch erheben zu können. Bessere Daten sind daher vor allem für ältere Botnetze vorhanden, da diese bereits gut analysiert sind und entsprechende Sensoren ("Sinkholes") betrieben werden. Da verschiedene Quellen unterschiedliche Bezeichnungen für die gleiche Malware verwenden, harmonisiert CERT.at diese mit einer auch öffentlich verfügbaren Zuordnungstabelle. In der folgenden Grafik werden die Meldungen nach Malwarefamilie in Österreich dargestellt.

Abbildung 5: Klassifizierung der Meldungen nach Botnetzen im Zeitverlauf (Wochen) des Jahres 2017 bis Ende 2017, Quelle: CERT.at

Denial of Service-Attacken – DoS und DDoS

DoS (Denial of Service) und DDoS (Distributed Denial of Service) Attacken zählen derzeit zu den häufigsten und wirksamsten Cyber Attacken. Vor allem in der Industrie und dem Finanzwesen werden diese Angriffe eingesetzt, um Unternehmen unter Druck zu setzen und hohe Summen an Schutzgeld einzufordern.

DDoS-Attacken legen Webserver oder ganze Netzwerke lahm. Im Gegensatz zu einer einfachen DoS-Attacke haben DDoS-Angriffe eine wesentlich höhere Schlagkraft. Mehrere Computer greifen dabei gleichzeitig und im Verbund (beispielsweise über ein Botnetz) eine Webseite oder eine ganze Netzinfrastruktur an. Das angegriffene System wird mit (teils sinnlosen) Anfragen überflutet, die mit den dort zur Verfügung stehenden Ressourcen nicht mehr schnell genug abgearbeitet werden können. Typische DDoS-Angriffe zielen dabei regelmäßig auf die Überlastung der Internetanbindung, der Ressourcen der Netzwerkkomponenten sowie der Web- und Datenbankserver ab.

DDoS-Angriffe lassen sich im Wesentlichen in drei Gruppen kategorisieren:

  • Quantitative Angriffe: Diese versuchen, das Zielsystem durch den Angriff zu überlasten. Dabei kommen in der Regel keine hochspezialisierten Angriffsvektoren zum Einsatz, sondern der gewünschte Effekt wird allein durch die Menge des Datenverkehrs erzielt.
  • Qualitative Angriffe: Diese versuchen primär, Schwachstellen in Systemen gezielt auszunutzen, um so die Erbringung dieses Dienstes für die dafür vorgesehenen BenutzerInnen einzuschränken oder gänzlich zu unterbinden. Solche Angriffe setzen zumeist ein höheres technisches Niveau der Angreifer voraus.
  • Eine Kombination daraus: Durch Verschränkung von quantitativen und qualitativen Angriffen können Systeme noch effizienter gestört werden.

DDoS-as-a-Service

Gegenwärtig ist in immer stärkerem Ausmaß die Entwicklung zu beobachten, dass DDoS-Angriffe im Internet unkompliziert als "Dienstleistung" "eingekauft" werden können. So bieten im "Darknet" zahlreiche Anbieter gegen vergleichsweise geringes Entgelt die Möglichkeit, Angriffe nach Dauer und Volumen preislich gestaffelt zu ordern. In den letzten Jahren konnten einige dieser Anbieter enttarnt und verhaftet werden.

So funktioniert ein DoS/DDoS-Angriff im Detail

Bei DoS-Angriffen werden häufig Schwächen in Anwendungen, Betriebssystemen oder Webprotokollen ausgenutzt. Die Attacken können in verschiedenen Varianten durchgeführt werden:

  • Syn Flooding
    Soll eine TCP-Verbindung - etwa zum Abruf einer Webseite - aufgebaut werden, so führt dies zu einem Austausch von SYN- und ACK-Datenpaketen zwischen Client und Server (dies wird auch "TCP-Handshake" genannt). Im Falle eines Syn Flooding-Angriffs werden von den Angreifern viele SYN-Pakete losgeschickt, die jeweils eine gefälschte Absender-IP-Adresse enthalten. Das Zielsystem antwortet auf diese Pakete, so wie dies gemäß TCP-Handshake vorgesehen ist, mit entsprechenden SYN-ACK-Paketen, schickt diese aber an die gefälschten IP-Adressen zurück und erwartet von dort (gemäß eines regulären TCP-Handshakes) Antworten in Form eines ACK-Pakets. Für diese Abhandlung und insbesondere das Warten auf eine Antwort wird vom Zielsystem jeweils etwas Rechenleistung und für eine gewisse Zeit Speicherkapazität in Anspruch genommen. Wenn diese ACK-Pakete jedoch ausbleiben (was bei einer Syn Flooding Attacke der Fall ist), so werden umso mehr Ressourcen gebunden je höher die Rate der empfangenen SYN-Pakete ist. Sind die vorhandenen Verbindungskapazitäten (TCP State Table) des Zielsystems ausgeschöpft, dann kann dieses keine weiteren Verbindungen mehr annehmen und ist damit auch für legitime Anfragen nicht mehr erreichbar – das Ziel einer DDOS Attacke wurde damit erreicht. Für effektive SYN Flooding Angriffe reichen oft schon Bandbreiten im Bereich von wenigen Mbit/s. Mittels SYN Cookies, welche die Bindung von Ressourcen auf einen späteren Zeitpunkt im Handshake verschieben, lassen sich diese Angriffe allerdings gut abwehren.
  • Reflected-DoS-Angriff
    Diese Angriffsvariante zielt auf die Überlastung von Leitungskapazitäten und nutzt legitime, aber schlecht konfigurierte UDP-basierte Server im Internet als Reflektoren/Verstärker von Paketen. Der Angreifer schickt dabei viele (kleine) Anfragen an diese Server, wobei er aber die IP-Adresse des Opfers als Absenderadresse einträgt (IP-Spoofing). Die Server halten diese Anfragen für legitim und beantworten sie mit großen oder mehreren Antwortpaketen. Diese werden aufgrund des IP-Spoofing jedoch an das Opfer anstelle des eigentlichen Senders zugestellt.

Dadurch hat der Angreifer folgende Vorteile:

  • Seine Angriffsbandbreite wird durch die Reflektoren verstärkt.
  • Nutzt er viele verschiedene Server als Reflektoren, so sieht das Opfer breit verteilte Angreifer, die sich nicht einfach über eine Filterliste ausblenden lassen.
  • Der Standort des Angreifers, bzw. die Quelle der gefälschten Pakete ist schwer auszuforschen.

Für eine solche DoS-Reflection lassen sich mehrere Protokolle zweckentfremden: Primär betroffen sind UDP-basierte Protokolle, da hier nicht auf Transportebene mittels eines Handshakes die IP-Adresse des Clients validiert wird. Aktuell sind DNS (Domain Name Service), NTP (Network Time Protocol), SSDP (Simple Service Discovery Protocol) die am häufigsten missbraucht werden. Es wurden aber auch schon Angriffe, welche SNMP (Simple Network Management Protocol), portmapper, chargen und sogar LDAP (Active Directory Pings über UDP) verwendeten, beobachtet.

CERT.at informiert die heimischen Netzbetreiber laufend über Server in deren Netzen, die sich für solche Angriffe ausnutzen lassen. Wie Abbildung 6 zeigt, ist es ein langwieriger Prozess, das Netz bezüglich dieser Gefahr zu säubern. Um Reflected-DoS zu unterbinden, ist eine globale Anstrengung nötig, denn das Problem ist mit dem Umweltschutz oder der globalen Erwärmung vergleichbar: Nur wenn alle an einem Strang ziehen, kann sich die Lage nachhaltig verbessern.

  • Angriffe auf den Applikationslayer
    Sowohl gegen Webserver, als auch gegen Nameserver wurden in der letzten Zeit spezifische Angriffsmuster beobachtet. Ähnlich wie bei Reflection-Attacks funktionieren etwa Angriffe auf Basis der Pingback Funktion der weit verbreiteten Blogsoftware "Wordpress". Das grundliegende Prinzip dabei ist der Umstand, dass solche Blogs auf Artikel anderer Blogger verweisen, was gerne mit einem Retour-Link ("Folgende Blogs zitieren diesen Artikel") beantwortet wird. Im Hintergrund notifiziert der zitierende Blog die Quelle eines Verweises, das dortige Wordpress verifiziert das und setzt erst dann den Pingback Link. Dieses Verifizieren ist jedoch ein Problem: Wenn ein Angreifer tausenden Wordpress-Installationen mitteilt, dass die Webseite eines Opfers gerade einen Link gesetzt hat, dann versuchen die, dies auf die beschriebene Weise zu verifizieren und lösen so eine Überlast beim Opfer aus.
    Angriffe auf das Domain Name System werden ebenfalls regelmäßig registriert. Aktuell beobachtet man "Random Subdomain Requests" als größte Bedrohung: Hierbei werden aus einem Botnet heraus sehr viele Anfragen zu zufällig gewählten Subdomains des Opfers an beliebige Nameserver gestellt. Diese Randomisierung hebt den Effekt von Caches auf, wodurch eine Flut von Anfragen die Nameserver des Opfers erreicht und diese potentiell überlastet.

CERT.at informiert die Netzbetreiber in Österreich laufend darüber, welche IP-Adressen in den jeweiligen Netzen für eine DDoS-Angriffsverstärkung verwendet werden können. Die Entwicklung dafür verwendeter Systeme in Österreich wird in Abbildung 6 dargestellt.

Abbildung 6: Entwicklung der DDoS Reflektoren in Österreich, Quelle: CERT.at 2018

Die Quellen der Daten zu Botnetzen

Die den Statistiken zu Botnetzen zugrundeliegenden Daten stammen aus unterschiedlichen Quellen. Durch die diversen Mess- und Erhebungsmöglichkeiten dieser Daten, die von Aktionen von Strafverfolgungsbehörden bis zu Spuren, die Täter selbst hinterlassen, reichen, wird ein umfassender Blick auf die IT-Sicherheitslage in Österreich ermöglicht. Zu diesen Quellen gehören:

Aktionen von Strafverfolgungsbehörden: Diese Daten stammen aus der Beschlagnahmung von Domains oder Servern von Botnetzen. Dabei werden die ursprünglich von den Angreifern eingesetzten Steuerserver der Botnetze (sog. "Command and Control Server") durch Sensoren (diese werden "Sinkholes" genannt) ersetzt, die für die Strafverfolgungsbehörden mitprotokollieren, von welchen IP-Adressen infizierte Geräte neue Befehle abholen wollen.

Analyse von Malware und Registrierung der verwendeten Domains: In vielen Fällen wird der "Command and Control Server" nicht über eine konstante Domain angesprochen, sondern über nur kurzfristig gültige Domains, die aus dem aktuellen Datum abgeleitet werden. Wenn eine Analyse der Malware diesen Algorithmus extrahiert, so besteht die Möglichkeit, die künftig verwendeten Domains im Voraus zu berechnen und sie rechtzeitig zu registrieren. Dort lassen sich dann Sinkholes betreiben.

Verwendet Malware einen Peer-to-Peer (P2P) Mechanismus für die Kommunikation, so kann man durch eine Teilnahme am P2P Protokoll die Mitglieder des P2P-Netzes bestimmen.

In manchen Fällen gelingt es der Polizei, SicherheitsforscherInnen oder CERTs Zugang zu Servern der Angreifer zu erlangen. Die dort vorgefundenen Daten können sehr aufschlussreich sein.

Aktive Suche nach Sicherheitsproblemen: Manche Sicherheitsprobleme können "von außen" überprüft werden. Beispielsweise, ob eine IP-Adresse auf gewisse Protokoll-Anfragen antwortet und sich daher als DDoS-Verstärker missbrauchen lässt.

Operation Avalanche

Am 30. November 2016 wurden durch eine breit angelegte Kooperation von Polizei (Europol, Eurojust, FBI...), Staatsanwälten und IT-Sicherheitsorganisationen (BSI, Shadowserver, CERTs) die Server und Domains der Avalanche Botnetzinfrastruktur übernommen. Ausschlaggebender Grund dafür war Avalanches Beteiligung an mehreren großen Botnetzen. Dies war ein wichtiger Schritt in Richtung eines sichereren Cyber Raumes durch internationale Zusammenarbeit.

Am 1. Dezember 2017 wurden im Rahmen einer Nachfolgeoperation auch die Kontrollserver der Schadsoftwarefamilie Andromeda (auch bekannt unter den Namen Gamarue) übernommen. Im Graphen zur Operation Avalanche ist dieser "Takedown" sehr gut durch einen Anstieg der infizierten Geräte am Ende des Jahres 2017 in den Berichten zu erkennen.

Dies war ein gutes Beispiel für "Aktionen von Strafverfolgungsbehörden", denn statt der echten Command and Control Server nehmen die infizierten PCs mit Sensoren ("Sinkholes") Kontakt auf, die von Sicherheitsforschern im Auftrag der Polizei betrieben werden. Die so erhaltenen Daten werden an CERT.at übermittelt, welches sie wiederum an die Netzbetreiber weiterreicht. Anfänglich wurden mehr als tausend Infektionen in Österreich gemessen:

Abbildung 7: Daten aus dem Avalanche Takedown in Österreich, 2016 bis Ende 2017, Quelle: CERT.at

TLS Probleme in .at

Die Verschlüsselungsprotokollfamilie SSL/TLS wird verwendet um HTTP- (Web) und SMTP- (Mail) Datenverkehr zu verschlüsseln. In der Vergangenheit wurden bereits mehrmals protokollarische Schwächen bzw. Sicherheitslücken gefunden, die durch Aktualisierungen der verwendeten Software bzw. durch neuere Versionen von SSL/TLS behoben wurden. CERT.at überprüft täglich alle unter .at-Domains erreichbaren Webseiten und Mailserver auf zwei besonders schwerwiegende Sicherheitslücken, "Heartbleed" und "DROWN".

Die Sicherheitslücke Heartbleed – bekannt geworden im April 2014 – bestand in bestimmten Versionen der Softwarebibliothek openssl, welche von sehr vielen Serverdiensten genutzt wird Entsprechend groß war auch ihre Auswirkung. Durch die Lücke ist es möglich, den geheimen Schlüssel von einem betroffenen Server auszulesen, womit ein Angreifer die Möglichkeit bekommt, den eigentlich verschlüsselten Datenverkehr zu entschlüsseln. Es kann davon ausgegangen werden, dass alle mit Ende 2017 immer noch verwundbaren Systeme nicht aktualisiert und damit nicht betreut werden.

Unter DROWN wird eine Schwäche in der SSL-Version 2.0 verstanden. Diese wurde im März 2016 bekannt. Betroffen sind alle Serverdienste welche diese SSL-Version anbieten bzw. nicht explizit verbieten. Die Folge ist auch hier wieder, dass ein Angreifer verschlüsselten Datenverkehr entschlüsseln kann. Es ist dringend zu empfehlen die SSL-Version 2.0 sowie auch das Nachfolgeprotokoll SSL 3.0 zu deaktivieren. Empfehlungen zur sicheren Konfiguration von kryptografischer Software finden sich zum Beispiel im Dokument Applied Crypto Hardening auf bettercrypto.org.

Die folgenden Abbildungen zeigen einen Überblick über von beiden Sicherheitslücken betroffene Server in Österreich. Die kleinen Sprünge in den Zahlen sind auf Änderungen an den Suchprogrammen und in der zugrundeliegenden Datenbasis zurückzuführen.

Abbildung 8: Anzahl der IP-Adressen der von Heartbleed unter .at betroffenen Server. Quelle: CERT.at 2018

Abbildung 9: Anzahl der IP-Adressen der von DROWN unter .at betroffenen Server. Quelle: CERT.at 2018

Gehackte Webseiten in .at

CERT.at informiert Webseitenbetreiber wenn von außen erkennbar ist, dass deren Webseite gehackt wurde. Es werden dabei mehrere Fälle unterschieden:

Bei Hacks, die nur des Hacks wegen ausgeführt werden, prahlen die Angreifer auf diesen Seiten über ihre Leistung mit expliziten Texten und Bildern (zum Beispiel "Hacked by ..."). Diese Vorfälle werden in den Statistiken unter der Bezeichnung Defacement geführt.

Weniger auffällig sind Exploit-Packs. Dabei handelt es sich um Manipulationen an der Webseite, welche gezielt die Brower der Besucher angreifen. Ist dieser verwundbar, etwa weil dieser selbst oder eines der installierten Browser-Plugins (Java, Flash, Silverlight, …) nicht aktualisiert wurden, dann wird damit der PC (oder das Handy/Tablet) des Besuchers mit Malware infiziert.

Bei Fake-Pharmacy-Hacks liefern gehackte Webseiten andere Inhalte, wenn die Besucher über eine Suchmaschine auf die Webseite gelangen (abzuleiten aus den sogenannten Referer-Informationen). Dadurch erscheinen in den Ergebnissen einer Suchmaschine andere Inhalte auf, die im Großteil der Fälle für Potenzmittel aus dubiosen Quellen werben. Beim direkten Aufruf der Webseiten über das Adressfeld scheinen diese Inhalte nicht auf. Diese Vorfälle werden auch Google Conditional Hacks genannt.

Phishing-Seiten ahmen die Webseiten von Banken, Portale von Firmen, Webmail-Zugänge von Behörden und andere lohnenswerten Zielen nach und verleiten Opfer mit Spam-Kampagnen dazu, diese täuschend echt aussehenden Seiten zu besuchen, um sich dort anzumelden. Die Login-Daten werden dabei vom Angreifer gestohlen.

Unter Search Engine Ranking Hacks werden Verlinkungen verstanden, die darauf abzielen, die verlinkte Seite dadurch in den Suchergebnissen höher gelistet aufscheinen zu lassen.

CERT.at stehen mehrere Quellen für Informationen zu gehackten Webseiten zur Verfügung:

Suche mittels Suchmaschinen: Will man nach aktuellen Problemen verwundbarer Webseiten suchen, so kann man dazu auch gängige Suchmaschinen wie Google, Bing usw. benutzen. Dabei wird im Quellcode von Webseiten gezielt nach Auswirkungen von eingeschleustem, schadhaftem Code oder anderen Erkennungsmerkmalen gesucht (etwa bekannte Muster von Exploit-Packs), was ein Indikator dafür ist, dass eine Webseite für böswillige Zwecke missbraucht wird.

Blacklists: Von mehreren Internet Service Betreibern werden "Listen" von als (potentiell) bösartig oder gefährlich eingestuften IP-Adressen, Domains und URLs geführt. Internetnutzer sehen den Effekt dieser Blacklists vor allem dann, wenn ihr Browser vor dem Besuch einer Phishing-Seite warnt.

Die Täter selbst: So melden etwa einige der Einbrecher in Webseiten ihre "Defacements" bei zone-h.org. Gestohlene Daten aus Datenbankeinbrüchen landen auch oft auf "pastebin".

Wenn mehrere Webseiten eines Dienstleisters (Hosters) oder Webseiten, die mit der gleichen Software (Content-Management-System, kurz "CMS") erstellt wurden, über die gleiche Schwachstelle fast gleichzeitig infiziert werden, sprechen wir von Massendefacements. Das führt diese nicht selten zu eindeutig erkennbaren Ausreißern in den Statistiken. Im Besonderen sind dabei die Defacements ab Ende Jänner 2017 zu erwähnen. So etwa wurde in den Versionen 4.7 und 4.7.1 des Content-Management-Systems Wordpress mehrere Sicherheitslücken gefunden, die eine Übernahme von darauf aufsetzenden Webseiten stark vereinfachten. Die Version 4.7.2 behob darauf diese Probleme und wurde am 26. Jänner 2017 veröffentlicht. Viele der Installationen wurden nicht oder nicht rechtzeitig aktualisiert, wodurch eine Welle an gehackten Webseiten folgte, die in den Statistiken klar erkennbar ist.

Abbildung 10: Probleme mit Webseiten. Quelle: CERT.at 2018





<< Vorige Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
Kritische Schwachstelle in bzip2 - je nach Setup für RCE ausnutzbar
24. Juni 2019 | Beschreibung In ...
Kritische RCE Schwachstelle in Oracle WebLogic Server
19. Juni 2019 | Beschreibung | Mehrere ...
mehr ...
Zoom, Zoom, Zoom
9. Juli 2019 | In der ...
In eigener Sache: CERT.at sucht Verstärkung
2. Juli 2019 | Für unsere ...
mehr ...
Jahresbericht 2017
Ein Resumee zur digitalen Sicherheitslage in Österreich

(HTML, PDF).
Letzte Änderung: 2018/12/10 - 17:37:54
Haftungsausschluss / Datenschutzerklärung