Auch unter Windows kann man die gewohnten Linux-Befehle nutzen, um entfernte Rechner zu verbinden und darauf zu arbeiten. Dafür sorgen Werkzeugkästen wie MobaXterm.

Quelle

Dies ist der Folgeartikel, den ich in der Einführung in das Advanced Intrusion Detection Environment (AIDE) versprochen hatte. Es handelt sich hierbei um einen Proof of Concept (PoC), der zeigt, wie AIDE mithilfe einer Ansible-Rolle ferngesteuert werden kann. Die Einführung wird als bekannt vorausgesetzt.

Grundlegende Ansible-Kenntnisse, wie die Verwendung von Ansible-Rollen und das Ausführen von Playbooks werden ebenfalls als bekannt vorausgesetzt. Wer Ansible nicht kennt, sei an die offizielle Dokumentation verwiesen.

Welche Aufgaben sind mit Ansible zu lösen?

• Das Paket aide ist auf den Zielsystemen installiert
• Die optionale Generierung und Verteilung der Konfigurationsdatei aide.conf
• Die Initialisierung der AIDE-Datenbank
• Zentrale Speicherung der AIDE-Datenbanken aller verwalteter Hosts auf dem Ansible Control Node (ACN)
• Durchführung von Integritäts-Checks
• Aktualisierung der AIDE-Datenbanken und erneute Speicherung auf dem ACN

Durch die Speicherung der AIDE-Datenbanken und -Konfigurationsdateien auf dem ACN sind diese gegen Veränderung auf einem kompromittierten Host geschützt. Gegen Veränderungen auf dem ACN selbst sind die Dateien nur mit Unix-Dateiberechtigungen geschützt. Doch wenn der ACN kompromittiert ist, hat man eh ein ganz anderes Problem, als sich um AIDE Sorgen zu machen.

Labor-Umgebung

Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:

• ansible-ctrl (RHEL 8 mit installiertem ansible-core)
• rhel7
• rhel8
• rhel9

Der ACN kann sich via SSH zu den Zielsystemen (rhel{7,8,9}) verbinden und dort Programmcode mit erhöhten Rechten ausführen.

Die von mir für diesen PoC entwickelte Ansible-Rolle gibt es unter der URL: https://github.com/Tronde/aide

Beschreibung der Ansible-Rolle aide

Die Rolle ist nicht idempotent. Sie ruft das Programm aide auf den Zielsystemen mit verschiedenen Optionen auf und verarbeitet deren Ausgabe. Dazu macht die Rolle Gebrauch des Moduls ansible.builtin.command.

Gesteuert wird die Rolle über Ansible-Tags. Wird die Rolle in einem Playbook ohne Angabe von Tags ausgeführt, werden keinerlei Veränderungen an den Zielsystemen vorgenommen.

Der folgende Code-Block zeigt ein Beispiel-Playbook zum Aufruf der Rolle. Die Tags und die Variable aide_db_fetch_dir werden im Anschluss erläutert.

# SPDX-License-Identifier: MIT
---
- name: Example aide role invocation
  hosts: targets
  tasks:
    - name: Include role aide
      tags:
        - install
        - generate_config
        - init
        - check
        - update
      vars:
        aide_db_fetch_dir: files
      ansible.builtin.include_role:
        name: aide

• install – Bei Angabe dieses Tags stellt die Rolle sicher, dass das Paket aide auf den Zielsystemen installiert ist
• generate_config – Generiert die Datei /etc/aide.conf unter Nutzung von templates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster Abschnitt
• init – Hiermit wird die AIDE-Datenbank initialisiert, welche als Referenzdatenbank für zukünftige Checks dient
• check – Führt einen Integritäts-Check unter Verwendung der Referenzdatenbank durch
• update – Führt einen Integritäts-Check durch und erzeugt eine neue AIDE-Datenbank, welche zukünftig als Referenz dient

Die Variable aide_db_fetch_dir erwartet im Auslieferungszustand das Verzeichnis files parallel zum Playbook. In diesem Verzeichnis werden Unterverzeichnisse für jeden Host erstellt, in denen die AIDE-Datenbank der verwalteten Systeme gespeichert wird. Soll ein anderer Speicherort verwendet werden, ist der Wert dieser Variablen entsprechend anzupassen. Die AIDE-Datenbanken werden mit dem Ansible-Module ansible.builtin.fetch von den verwalteten Systemen geholt.

Nutzung für die verschiedenen Anwendungsfälle

In diesem Abschnitt beschreibe ich die fünf Anwendungsfälle für den PoC. Alle Anwendungsfälle wurden gegen RHEL 7, RHEL 8 und RHEL 9 getestet. Für diesen Blog beschränke ich mich jedoch auf Tests gegen RHEL 9, um die Übersichtlichkeit der Ausgaben zu verbessern.

Es wird stets das Playbook aus dem Abschnitt Beschreibung der Ansible-Rolle aide verwendet und mit unterschiedlichen Tags ausgeführt.

Anwendungsfall 1: Installation von AIDE

Um AIDE nutzen zu können, muss es zuerst installiert sein. Dies wird mit folgendem Playbook-Aufruf festgestellt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Für diesen Anwendungsfall arbeitet die Rolle idempotent. Bei einer zweiten Ausführung werden keine weiteren Änderungen am System vorgenommen:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Anwendungsfall 2: Generierung der Datei /etc/aide.conf

Zusammen mit der Rolle wird die Datei templates/aide.conf.j2 ausgeliefert. Dabei handelt es sich um die Standardkonfigurationsdatei aus einer RHEL9-Installation, in welcher zusätzlich der Pfad /root/.ansible* von der Überwachung ausgenommen wurde, um falsch positive Ergebnisse zu vermeiden.

Diese Datei ist an die individuellen Bedürfnisse anzupassen. Wer Hilfe zum Templating mit Jinja2 benötigt, findet in der Ansible-Dokumentation einen Einstieg.

Ausgerollt wird die Konfigurationsdatei dann wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags generate_config

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Generate /etc/aide.conf] ******************************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Auch mit diesem Tag arbeitet die Rolle idempotent.

Wird dieser Schritt ausgelassen, wird in allen folgenden Anwendungsfällen die Standardkonfigurationsdatei verwendet, welche bei der Installation des Pakets aide mitinstalliert wurde.

Anwendungsfall 3: Initialisierung der AIDE-Datenbank

Um Integritäts-Checks durchführen zu können, muss zuerst die AIDE-Datenbank initialisiert werden. Dies geschieht mit dem folgenden Aufruf:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags init

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Initialize AIDE database] *****************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nach der Initialisierung der AIDE-Datenbank wird diese auf den ACN kopiert und von den verwalteten Systemen entfernt. Dies hat den Hintergrund, dass es sich beim ACN um ein sehr gut gesichertes System handelt und die Datenbanken hier am besten vor einer Kompromittierung geschützt sind.

Wird der Standardwert der Variable aide_db_fetch_dir verwendet, findet sich die AIDE-Datenbank jetzt im Pfad files/rhel9/var/lib/aide/aide.db.new.gz. Dabei entspricht rhel9 in der Pfadangabe dem inventory_hostname des jeweiligen Zielsystems.

Dieser Teil der Rolle ist nicht idempotent. Wird das Playbook erneut ausgeführt, wird eine neue AIDE-Datenbank erstellt, auf den ACN heruntergeladen und vom Zielsystem gelöscht.

Anwendungsfall 4: Ausführung einer Integritätsprüfung

Der nun folgende Code-Block zeigt den Playbook-Aufruf zur Integritätsprüfung. Hier wird zuerst die AIDE-Datenbank auf das Zielsystem kopiert, anschließend ein AIDE-Check ausgeführt. Da im folgenden Beispiel keine Änderungen detektiert wurden, besitzt der Task „[aide : Check against AIDE reference database]“ den Status „ok“.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Dieser Teil der Rolle ist nicht idempotent. Bei jedem Aufruf wird ein neuer Integritäts-Check ausgeführt.

Ich habe die Datei /etc/hosts auf dem Zielsystem manipuliert, um auch den Fall zu zeigen, wenn eine Änderung erkannt wurde.

Zu Beginn der folgenden Ausgabe ist zu erkennen, dass der Task „[aide : Copy AIDE reference database to remote]“ den Status „ok“ besitzt. Ansible hat erkannt, dass die AIDE-Datenbank bereits in unverändertem Zustand auf dem Zielsystem existiert, und hat sie deshalb nicht erneut übertragen. Der Task „[aide : Check against AIDE reference database]“ schlägt nun allerdings fehl (Status: „fatal“), da Veränderungen erkannt wurden. Die zugegeben etwas unübersichtliche Ausgabe enthält die Nachricht, dass die Datei /etc/hosts verändert wurde.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
ok: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
fatal: [rhel9]: FAILED! => {"changed": true, "cmd": ["aide", "--check"], "delta": "0:00:27.177397", "end": "2024-03-29 05:16:50.682795", "msg": "non-zero return code", "rc": 4, "start": "2024-03-29 05:16:23.505398", "stderr": "", "stderr_lines": [], "stdout": "Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)\nAIDE found differences between database and filesystem!!\n\nSummary:\n  Total number of entries:\t45541\n  Added entries:\t\t0\n  Removed entries:\t\t0\n  Changed entries:\t\t1\n\n---------------------------------------------------\nChanged entries:\n---------------------------------------------------\n\nf   ...    .C... : /etc/hosts\n\n---------------------------------------------------\nDetailed information about changes:\n---------------------------------------------------\n\nFile: /etc/hosts\n  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n\n             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS\n             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==\n\n\n---------------------------------------------------\nThe attributes of the (uncompressed) database(s):\n---------------------------------------------------\n\n/var/lib/aide/aide.db.gz\n  MD5      : gMgRyMOExVAdOAvdgt4QDA==\n  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=\n  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=\n  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O\n  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6\n             GNZlwySPKcY=\n  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ\n             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj\n             MWQpsGf7v12iACc4SP9ANA==\n\n\nEnd timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)", "stdout_lines": ["Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)", "AIDE found differences between database and filesystem!!", "", "Summary:", "  Total number of entries:\t45541", "  Added entries:\t\t0", "  Removed entries:\t\t0", "  Changed entries:\t\t1", "", "---------------------------------------------------", "Changed entries:", "---------------------------------------------------", "", "f   ...    .C... : /etc/hosts", "", "---------------------------------------------------", "Detailed information about changes:", "---------------------------------------------------", "", "File: /etc/hosts", "  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n", "             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS", "             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==", "", "", "---------------------------------------------------", "The attributes of the (uncompressed) database(s):", "---------------------------------------------------", "", "/var/lib/aide/aide.db.gz", "  MD5      : gMgRyMOExVAdOAvdgt4QDA==", "  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=", "  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=", "  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O", "  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6", "             GNZlwySPKcY=", "  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ", "             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj", "             MWQpsGf7v12iACc4SP9ANA==", "", "", "End timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)"]}

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

An dieser Stelle wurde gezeigt, dass sowohl unveränderte Systeme als auch Systeme mit Veränderungen erkannt und gemeldet werden. Dabei muss natürlich niemand die Standardausgabe beobachten. Stattdessen kann Logging für Ansible Ausgaben konfiguriert werden.

Anwendungsfall 5: Update der AIDE-Datenbank

Dieser Anwendungsfall nimmt an, dass erfolgte Änderungen legitim sind und in die AIDE-Referenzdatenbank aufgenommen werden sollen. Dies geschieht wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags update

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Update AIDE database] *********************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nachdem die Referenzdatenbank aktualisiert wurde, wird diese wieder auf den ACN kopiert und vom Zielsystem entfernt.

Das folgende Beispiel zeigt, dass auf dem Zielsystem der AIDE-Check nun ohne Fehler absolviert wird:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Ansible hat erkannt, dass die AIDE-Datenbank auf dem Zielhost nicht mit der aktuellen Referenzdatenbank übereinstimmt und hat letztere daher auf das Zielsystem übertragen. Die Überprüfung endet mit dem Status „ok“. Das System entspricht dem Soll-Zustand.

Zusammenfassung

Der Proof of Concept hat gezeigt, dass AIDE mit der verwendeten Ansible-Rolle ferngesteuert genutzt werden kann. AIDE-Datenbank und Konfigurationsdatei werden dabei getrennt von den verwalteten Systemen gespeichert und sind daher gegen Veränderung bei Kompromittierung der Zielsysteme geschützt. Bei Bedarf, wenn Ansible Abweichungen des Ist- zum Soll-Zustand erkennt, werden diese Dateien auf die Zielsysteme übertragen.

Der größte Arbeitsaufwand steckt in der Erstellung einer oder mehrerer AIDE-Konfigurationsdateien, die optimal zur eigenen Umgebung passen und möglichst keine falsch positiven Ergebnisse erzeugen. Dieser Aufwand besteht jedoch auch, wenn man AIDE ohne Ansible einsetzt.

Einen Punkt hat dieser PoC unberücksichtigt gelassen. Es nützt natürlich nichts, wenn man die Ausgaben der Playbooks nur protokolliert, die Protokolle jedoch nicht analysiert, um entsprechende Alarme in Monitoring- oder Ticket-Systemen zu erzeugen. Dies sei den Anwendern zur selbstständigen Übung überlassen. ;-)

Kodi 21 »Omega« wurde jetzt nach 15 Monaten Entwicklung freigegeben. Die wichtigsten Neuerungen sind die Einführung von FFmpeg 6.0 und die Bereitstellung als Flatpak.

Quelle

Das Entwickler-Team hat Kodi 21 Omega zur Verfügung gestellt. Seit der Veröffentlichung von Version 20.0 Nexus am 15. Januar 2023 wurden mehr als 3.750 Änderungen vorgenommen. Erwartungsgemäß gibt es natürlich einige wichtige und nennenswerte Änderungen. FFmpeg 6 in Kodi 21 Kodi setzt stark auf FFmpeg. Laut eigenen Angaben haben in den vergangenen 15 Monaten viele Personen dazu beigetragen, das Projekt an die neueren FFmpeg-Versionen anzupassen. Zunächst war das FFmpeg 5 und später dann FFmpeg 6. DolbyVision On-the-Fly-Profilkonvertierung Androis User dürfen […]

Der Beitrag Kodi 21 Omega ist veröffentlicht ist von bitblokes.de.

Malwarebytes hat eine sogenannte Malwertising-Kampagne auf Bing entdeckt, die einen Trojaner auf den Geräten der User einschmuggeln sollte. Dabei tarnt sich die bösartige Kampagne als die VPN-Software NordVPN. Laut den Security-Experten ist Bing neben Google wohl auch ein lukratives Ziel, da die Microsoft-Suchmaschine mit Windows und dem Browser Edge verknüpft ist. Fällt ein User auf die bösartige Werbung herein, landet er auf einer Website, die dem Original täuschen ähnlich sieht. Laut Malwarebytes gingen die Cyberkriminellen aber noch einen Schritt weiter. […]

Der Beitrag Bing-Anzeige für NordVPN führt zu SecTopRAT (Trojaner) ist von bitblokes.de.

Die beiden unter dem Dach von Linux Containers entwickelten Projekte LXC und Incus, ehemals LXD, erhielten eine Aktualisierung auf Version 6.0 LTS mit je fünf Jahren Unterstützung.

Quelle

Vor wenigen Tagen ist wieder eine neue Ausgabe des kostenlosen Magazins FCM erschienen. Das Full Circle Magazine 203 kommt nun genau richtig zum Wochenende und Du kannst es gratis herunterladen. Im Magazin werden folgende Themen behandelt: Wobei der Test von Cubuntu eher ein Blick in die Vergangenheit ist. Das Projekt wurde von 2012 bis 2017 entwickelt und ist damit seit einigen Jahren tot. Allerdings kannst Du die letzte Version, Cubuntu 16.04.3 LTS weiterhin von der SourceForge-Seite herunterladen. Mit dem erweiterten […]

Der Beitrag Full Circle Magaine 203 veröffentlicht – Cubuntu-Test ist von bitblokes.de.

Deutschlands nördlichstes Bundesland Schleswig-Holstein geht konsequent den 2020 eingeschlagenen Kurs weg von proprietärer Software.

Quelle

Opera stellt in Opera One Developer 150 lokale KI-Sprachmodelle zum Test bereit. Damit können Anwender verhindern, dass Daten ihrer Anfragen an externe Server abfließen.

Quelle

Die am Karfreitag entdeckte Hintertür im Paket xz-utils löst in vielen Projekten Betriebsamkeit aus. Canonical verschiebt die Beta zu Ubuntu 24.04 um eine Woche.

Quelle

Das Team von Nextcloud hat ein großes Update für den Nextcloud KI-Assistenten zur Verfügung gestellt. Ab sofort gibt es Context Chat und Context Write. Zudem ist GPU-Beschleunigung möglich und der Nextcloud-Server lässt sich vom KI-Server abspalten. Ferner arbeitet das Nextcloud-Team mit mehreren bekannten europäischen Hosting-Unternehmen zusammen, darunter IONOS und OVHcloud, um KI-as-a-Service-Lösungen anzubieten, die Privatsphäre und digitale Souveränität respektieren. In diesem Fall benötigst Du selbst keine teuren GPUs, um KI und Nextcloud zu vereinen. Nextcloud Assistant 2.0 Die Oberfläche wurde […]

Der Beitrag Nextcloud veröffentlicht großes Update für KI-Assistant – 2.0 ist von bitblokes.de.

Canonical hat angekündigt, dass die Beta-Version von Ubuntu 24.04 LTS Noble Numbat wegen CVE-2024-3094 (Sicherheitsproblem / Backdoor in den xz-utils) auf 11. April verschoben wird. Das Entwickler-Team hat sich entschieden, alle Binärpakete zu entfernen und neu zu erstellen. Mit dieser Aktion will Canonical sicherstellen, dass keine Binärdatei von der Sicherheitslücke betroffen ist. Bisher war der Plan, Ubuntu 24.04 LTS Beta am 4. April zu veröffentlichen. Am 25. April soll laut Zeitplan die finale Version erscheinen. Ob dieser Termin ebenfalls betroffen […]

Der Beitrag Ubuntu 24.04 LTS Beta auf 11. April verschoben (xz-Backdoor) ist von bitblokes.de.

Nitrux ist eine unabhängige Distribution, die dem KDE-Projekt nahesteht. Trotzdem soll noch in diesem Jahr der Umstieg von Plasma zu Maui-Shell vollzogen werden.

Quelle

Fedora mit KDE Plasma als Standard? Ein Aprilscherz? Mitnichten, der jetzt eingereichte Vorschlag ist ernst gemeint und überzeugend ausgearbeitet.

Quelle

Das für den Sommer zu erwartende Linux Mint wartet mit sinnvollen Neuerungen auf. So werden Kernel künftig in aktuelleren Versionen angeboten.

Quelle

Nach einem kleinen Rücksetzer im Februar ist Steam auf Linux im März 2024 wieder knapp an die 2 % herangerückt. Nun muss man dazu sagen, dass diese Umfragen mit Vorsicht zu genießen sind, da nicht alle Steam-User gefragt werden und nicht alle, die gefragt werden, teilnehmen müssen. Dennoch sind die Steam-Statistiken ein guter Indikator, wie es um Linux und Spiele steht. Die Umfrage im März hat einen Marktanteil von 1,94 % ergeben (Februar 2024 1,76 %). Damit ist Steam unter […]

Der Beitrag Steam unter Linux kratzt wieder an den 2 % ist von bitblokes.de.

openSUSE baut Tumbleweed komplett neu, Debian verschiebt ein Point-Release. Auswirkungen eines gerade noch rechtzeitig entdeckten Angriffsszenarios.

Quelle

Der Monatsbericht von Linux Mint ist da und es gibt einige Neuigkeiten bezüglich Linux Mint 22, das bekanntlich auf Ubuntu 24.04 LTS Noble Numbat basieren wird. Zunächst einmal gibt es Verbesserungen, dass sich Installationen von Linux Mint 22 besser lokalisieren lassen und weniger Speicherplatz als bisher benötigen. Vorinstallierte Pakete für andere Sprachen als Englisch und die von Dir gewählte Sprache werden am Ende der Installation entfernt. Laut eigenen Angaben wird durch das Entfernen dieser Pakete in Linux Mint 22 nach […]

Der Beitrag Linux Mint 22 wird Thunderbird als .deb-Paket bieten ist von bitblokes.de.

Die Hölle friert zu: Microsoft kündigt Office 2024 für Linux an. Details und weitere Informationen erfahrt ihr nach dem Klick auf Weiterlesen!

Quelle

Debian verschiebt die Aktualisierung auf v12.6 wegen der teils noch ungeklärten Hintergründe von CVE-2024-3094. Zunächst wird das Archiv einer gründlichen Analyse unterzogen.

Quelle

Bei Technik-affinen Leuten wie die Leser dieses Blogs dürfte sich bereits wie ein Lauffeuer verbreitet habe, dass das weit verbreitete Paket xz-utils (Datenkompressions-Tools), beginnend mit den Versionen 5.6.0 bis 5.6.1, eine Backdoor hat (CVE-2024-3094). Diese Hintertür könnte es einem böswilligen Akteur ermöglichen, die sshd-Authentifizierung zu kompromittieren. Damit könnte sie oder er unbefugten Fernzugriff auf das gesamte System erhalten. Die gute Nachricht ist, dass aktuelle LTS-Versionen von Ubuntu nicht betroffen sind. Das gilt auch für Linux Mint und die stabile Version […]

Der Beitrag Kali von xz-utils Backdoor betroffen, Debian / Ubuntu nicht ist von bitblokes.de.

Durch jahrelange Vorarbeit ist es Angreifern gelungen, den Quellcode der Kompressions­software xz zu kompromittieren. Gezielt eingereichte Patches schufen Sicherheitslücken und diese wurden proaktiv in aktuelle Linux-Distributionen eingepflegt. Zum Update auf ein bereinigtes Paket wird dringend geraten.

Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.

Es handelt sich um Wartungsversionen und die laufen normalerweise schnell und problemlos durch. Die Updates bringen verschiedene Korrekturen und Leistungsverbesserungen in allen unterstützten Versionen von Nextcloud Hub. In Versionsnummern gibt es ab sofort Nextcloud 26.0.13, 27.1.8 sowie 28.0.4. Ich habe es schon mehrmals erwähnt, finde den Mix aus Hub und Versionsnummern echt verwirrend, zumal eine große Versionsnummer nicht zwingend eine große Hub-Nummer repräsentiert. Klar, es ist ein kosmetisches Problem, aber weniger Verwirrung wäre dennoch besser. Nextcloud 26 hat ihr Lebensende […]

Der Beitrag Nextcloud – Updates für Hub 6 und 7 – EOL für Hub 4 ist von bitblokes.de.

Aktuelle Linux-Distributionen sind durch eine Backdoor in der Kompressionssoftware XZ betroffen. Noch sind die genauen Auswirkungen des anspruchsvollen Schadcodes nicht gänzlich bekannt.

Quelle