Select Page

NETWAYS Blog

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die “Reporting” Funktion deaktiviert habt.

Der Link zur Veröffentlichung: Kibana 8.12.1, 7.17.18 Security Update (ESA-2024-04)

Schweregrad: Severity: CVSSv3: 9.9(Critical)

Beschreibung

Die Verwundbarkeit ist ist auf eine Schwachstelle von Google Chrome aus Dezember 2023 zurückzuführen. Da Kibana für die Reporting Funktion eine eingebettete “Chromium headless Verison” mit sich bringt, ist Kibana von dieser “Heap buffer overflow in WebRTC” ebenfalls betroffen. Diese Schwachstelle ermöglicht es einem entfernten Angreifer, über eine manipulierte HTML-Seite einen “Heap-Velrust” auszunutzen.

Dieser Effekt betrifft “on-premises” Kibana installation auf Betriebsystemen die “Chromium Sandbox” abgeschaltet haben. Diese sind CentOS, Debian, RHEL.

Es betrifft auch Instanzen welche mit dem Kibana Docker betrieben werden, wenn “Chromium Sandbox” wie explizit empfohlen abgeschaltet ist. Jedoch gilt hier, dass eine “Container Escape” nicht möglich ist, da es durch “seccomp-bpf” unterbunden wird. Das gilt auch für Kibana Instanzen auf “Elastic Cloud“, für “Elastic Cloud Enterprise (ECE)“, wobei hier das weitere Vordringen zusätzlich zum “seccomp-bf ” mit “AppArmor profiles” verhindert wird.

Für Kibana Instanzen welche auf “Elastic Cloud on Kubernetes” laufen, ist um das weitere Vordingen (Container Escape) durch “seccomp-bf” zu verhindern, dieses entsprechend in Kubernetes zu konfigurieren (wird seit V1.19 unterstützt).

Betroffene Versionen

  • Kibana bis 7.17.17
  • Kibana bis 8.12.0

Handlungsablauf zur Abhilfe

  • Dringend Update auf Version 8.12.1 oder Version 7.17.18
    • Dabei ist aber auch an die Elasticsearch Version zu denken
  • Sollte Kein UPDATE möglich sein, dann sollte die “Reporting” Funktion dringend abgeschalten werden
    vi /etc/kibana/kibana.yml
    ...
    xpack.reporting.enabled: false

     

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

CVSS:Medium: Elastic Sicherheits-Updates gleich für drei Produkte

Gleich drei Sicherheits-Updates für drei verschiedene Produkte wurden von Elastic veröffentlicht. Alle drei haben den Schweregrad  Medium. Jedoch ist es Ratsam die Updates durchzuführen. Folgend eine kurze Zusammenfassung je Produkt.

Link: APM Server 8.12.1 Security Update (ESA-2024-03)

Solltet Ihr in Elasticsearch aktiv das Application performance Feature nutzen und einen eigenen lokalen APM Server betreiben, dann ist ein Update ratsam. Dies Betrift nur die selbst betriebene APM binary Server Varianten nicht die Elastic APM Integration des Agent.

Beschreibung

Der APM-Server schreibt bei Fehlermeldungen welche einen Indizierungsfehler (das schreiben von Dokumenten in den Index) betreffen, Teile des dazugehörigen Dokumentes mit in die lokale Log-Datei. Dies kann dazu führen das Schützens werte Informationen (z.B Entitäten z.B von Applikations-Nutzern) lokal lesbar in der Datei geschrieben sind.

Betroffene Versionen

  • APM Server <8.12.1

Abhilfe

  • Aktualisierung des lokal betriebenen APM-Server auf Version 8.12.1
  • Aufspüren von sensiblen Informationen in den Logs:
    • Beispiel unter Linux mit Standard Log-Einstellungen:
      grep -Hrn "Preview of field's value:" /var/log/apm
    • sollte es Treffer geben ist die Log-Datei am besten zu rotieren und danach zu löschen.

Link: Kibana 8.12.1 Security Update (ESA-2024-01)

Beschreibung

Solltet hier die Detection Search Engine nutzen und verfügt über eine Subskription die es euch ermöglicht die Document-level (DLS) oder Field-Level (FLS)= basierten Berechtigungen zu nutzen, dann solltet Ihr hier handeln. Denn Benutzer welche Berechtigt sind die Indices für Alarmierungen über die Kibana-Api zu nutzen (Webfrontentd) könnten bei der Abfrage der entsprechenden Indices “.alerts-security.alerts-{space_id} mehr angezeigt bekommen als diese sehen dürften. Grund ist das die Engine diese einfach ignoriert. Bedeutet wenn ein Benutzer mit Berechtigungen auf Basis von DLS und FLS diese API abfragt, bekommt er Zugriff auf Informationen die er nicht sehen sollte.

Betroffene Versionen

  • Kibana 8.x bis zu <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1
    • Vorsicht es empfiehlt sich immer Elasticsearch und Kibana auf gleicher Version zu halten. Somit kann hier auch ein Update von Elasticsearch anstehen, was mit einem Rolling Restart verbunden ist.

Link: Elastic Network Drive Connector 8.12.1 Security Update (ESA-2024-02)

Beschreibung

Der Elastic Network Drive Connector ist ein Werkzeug welches bei Verwendung der Enterprise Search zum Einsatz kommt (Subskription Funktion). Hier kann der Benutzer auf Dokumenten Ebene trotzdem Dokumente sehen, welche Ihm explizit zum lesen und schreiben nicht zugeordnet sind. Somit kann der Benutzer Dokumente, auf die er nicht zugreifen kann und sollte, trotzdem sehen.

Betroffene Versionen

  • Elastic Network Drive Connector  <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Achtung Handlungsbedarf: Kibana schreibt sensitive Benutzerinformationen im Log mit

Kibana Insertion of Sensitive Information into Log File (ESA-2023-25)

Und erneut wurden in den Kibana-Logs in bestimmten Fehlerfällen sensible Informationen gefunden. Wir empfehlen dringend ein Update auf Kibana 8.11.1. In diesen Fällen werden Anmeldeinformationen des Benutzers “kibana_system”, API-Schlüssel und Anmeldedaten von Kibana-Endnutzern in das Log geschrieben.

Hier der Post zum CVE ESA-2023-25

Betroffene Versionen

Kibana nach 8.0.0 und vor 8.11.1

Nicht betroffene Versionen

Kibana Versionen 7.x.x

Schweregrad : 9,0 (Critical)

Handlungsablauf

Es besteht also bereits Handlungsbedarf. Im Folgenden wird ein möglicher Handlungsablauf beschrieben:

  • Aktualisierung von Kibana auf  8.11.11
  • Identifizieren ob ihr betroffen seit. Genau beschrieben hier
    • Beispiel für eigene Elastic Stack Instanz mit Stack Monitoring:
      message: ("headers" AND "x-elastic-product-origin" AND "authorization")

      gesucht mit Verwendung des Agents in “logs-kibana.*-default” oder bei Verwendung des Filebeats “filebeat-{version}”

  • Beheben der Schwachstelle (Remediation Actions) . Beispiel eigene Instanz:
    • Rotation des Passwords für den User “kibana_system” mittels API oder Passwort-Reset Tool
      bin/elasticsearch-reset-password -u kibana_systems
      curl -X POST "localhost:9200/_security/user/kibana_system/_password?pretty" -H 'Content-Type: application/json' -d'
      {
        "password" : "new_password"
      }
      '
      
    • Für alle Kibana-Endanwender  welche in den Logs gefunden wurden, könnt ihr die Kibana UI oder die Change passwords API wie oben beschrieben verwenden.

Für alle weiteren Varianten wie ECE, ECK und Elastic Cloud findet ihr alles genauer beschrieben unter den Punkten Identification and Remediation of credentials in logs und Remediation Actions

Hinweis

Es gilt auch hier ist eine Aktualisierung von Elasticsearch auf die Version 8.11.1 empfohlen. Bei jeder Aktualisierung gilt wie immer Release Notes lesen und “Breaking Changes” beachten.

Anmerkung der Redaktion

Wo gehobelt wird , da fallen auch Spähne

Deshalb ist Handeln erforderlich. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Graylog Release Version 5.2 ist da! HURRA!

Diese Woche wurde Graylog 5.2 veröffentlicht. Natürlich gibt es auch in diesem Release wieder Abstufungen für Open, Operations und Security.

Da wir nicht auf alles eingehen können, möchte ich hier auf die hervorzuhebenden Neuerungen und Änderungen eingehen. Ein vollständiges Changelog zum Release findet sich hier. Im Folgenden wollen wir auf zwei bemerkenswerte neue Features bzw. Änderungen im Detail eingehen.

HOT New Feature in Graylog OPEN/OPERATIONS/SECURITY: Pipeline Rule Builder UI

Der neue Pipeline Rule Builder UI ist wohl die auffälligste Neuerung und daher möchte ich darauf näher eingehen.

Das neue Pipeline Rule UI ist für all diejenigen hilfreich, die sich mit dem Schreiben von Pipeline Rule Code nicht auskennen oder sich noch nicht mit Pipeline Processing beschäftigt haben und daher Extraktoren am Input verwendet haben. Das neue UI (UserInterface) bringt hier eine ähnliche Handhabung wie bei den Extractoren. Die Extraktoren sind schon lange auf dem Weg aus dem Graylog heraus und sind und waren nie ein Weg für dynamische Verarbeitung.

Da dieses Menü bisher noch keine Erklärung gefunden hat, habe ich ein kurzes Video dazu gemacht. Vielleicht hilft das ja dem ein oder anderen von euch dies als Dokumentation zum verstehen.

Ausgangslage für das Video:

  • TCP RAW Input auf Port 5114 mit statischem Feld “demo” und dem Wert true
  • rsyslog Daemon der im JSON Format sendet
  • Pipeline und Stream für die Daten vorkonfiguriert.

 

Breaking Change in Graylog Security: lluminate Bundle

Dies sollte beachtet werden:

Die Verarbeitung von IP-Adressen zu Geo-IP-Informationen wurde aus dem Illuminate Bundle entfernt und benötigt nun den globalen “Geoip Resolver Processor”. Daher muss dieser aktiviert werden und dem “Illuminate Processor” folgen. Dabei braucht ihr keine Angst haben, dass jetzt mehr Ressourcen verbraucht werden. Mittlerweile kann der Processor unterscheiden zwischen reserved und public IP. Zu dem könnt ihr ein “Enforce default Graylog schema” aktivieren, dies sorgt dafür das nur Felder aufgelöst werden welche dem GIM entsprechen. Das sind folgende Felder:

  • destination_ip
  • destination_nat_ip
  • event_observer_ip
  • host_ip
  • network_forwarded_ip
  • source_ip
  • source_nat_ip

Bedeutet aber auch das ihr diese Felder selbst auch bei anderen Applikation welche nicht im ILLUMINATE vorhanden sind entsprechend erzeugen müsst.

Wenn “Enforce default Graylog schema” nicht aktiviert ist wird jedes Feld mit einer nicht reservierten IP-Addresse übersetzt.

Hierzu folgend die Einstellung für die Processor-Plugins welche notwendig sind:

Processor Configuration

Graylog Processor configuration order and activation

Dazu muss dann entsprechend auch der Geo-IP Processor konfiguriert sein und die entsprechenden Informationsdatenbanken zum Beispiel von Maxmind auf allen Servern abgelegt sein.

Geo-Location Processor Configuration in graylog

Alle weiteren Neuerungen und Änderungen in Graylog ILLUMINATE findet ihr hier.

 

Wir wünschen euch viel Spaß beim aktualisieren und Arbeiten mit den Neuerungen. Wenn ihr nicht weiter weißt oder Hilfe beim aktualisieren benötigt wir von NETWAYS Professional Services helfen euch gerne dabei. Meldet euch einfach bei unseren Sales TEAM!

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Do Servers Dream of Electric Sadness?

Als Systemadministrator ist man oft mit einer Vielzahl von Fehlermeldungen konfrontiert, die manchmal klar verständlich, manchmal mehrdeutig und manchmal völlig nichtssagend sein können. Wichtig ist hierbei, sich nicht von der Meldung in der Herangehensweise an den Fehler beeinflussen zu lassen und somit von vornherein auf dem Holzweg unterwegs zu sein.

icingadbweb

Zwei Hosts down, oder nur redis und mysql?

In diesem Blogbeitrag werden wir die Bedeutung eines methodischen Denkens und eines gut ausgestatteten Werkzeugkastens für Systemadministratoren erkunden.

 

Kenne Deine Umgebung:

Für die korrekte Interpretation ist es nicht nur wichtig, seine Umgebung zu kennen, sondern auch zu wissen, welche Werkzeuge in dem persönlichen Werkzeugkasten vorhanden sind. Sieht der Fehler nach Schraube aus, ich halte allerdings einen Hammer in der Hand, wird der Fehler gerne als Nagel interpretiert.Beides hält ja irgendwie Dinge zusammen und mit ausreichend Ausdauer, bekommt auch ein Hammer mit einer Schraube eine Verbindung zustande. Die Schraubverbindung mit einem Hammer zu lösen ist hier allerdings schon wieder eine andere Geschichte.

Aufbau Deines Werkzeugkastens:

Der Werkzeugkasten eines Systemadministrators baut sich über viele Jahre Erfahrung zusammen, kann aber auch durch realitätsnahe Übungen erweitert werden, was dann auch eine gewaltige Zeitersparnis beim Lösungsweg mit sich bringt. Ein sehr sympathischer Ansatz ist der Advent of Code mit dem Fokus auf programmatischen Lösungen, um so auch eventuell eine neue Sprache näher zu beleuchten.

Realitätsnahe Herausforderungen:

Mit realitätsnahen Herausforderungen auf AWS-Root Servern locken dagegen die traurigen Server auf https://sadservers.com. In derzeit 20 unterschiedlichen Szenarien darf man, falls nötig auch mit Tipps, eine definierte Aufgabe via bash lösen. Während der Beginn und die Zeitvorgaben entspannt anfangen, wird es je nach Kenntnisstand ziemlich schnell ziemlich fordernd. Einen ersten Einblick bietet auch das zugehörige GitHub Repository

Austausch und Schulungen:

Wer danach oder währenddessen Interesse daran hat, den Werkzeugkasten über einen Monat hin weiter zu befüllen, sollte einen Blick auf https://linuxupskillchallenge.com/ riskieren. Auch Personen, die schon Jahrzehnte im Geschäft sind, erfahren bei solchen Challenges nicht nur neues, sondern auch der Austausch mit Gleichgesinnten hilft hierbei enorm. Wem das alles zu digital ist, findet vielleicht in unseren Schulungen und Events nicht nur sich selbst eher wieder, sondern auch mehr Gleichgesinnte.

 

Ein gut ausgestatteter Werkzeugkasten und ein methodischer Ansatz sind entscheidend für den Erfolg eines Systemadministrators. Indem Du Deine Umgebung kennst, Deine Werkzeuge verstehst und durch praktische Übungen und Herausforderungen Dein Wissen erweiterst, wirst Du in der Lage sein, Fehler effektiv zu lösen und die Herausforderungen Deines Berufs zu meistern!

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...