CleanPress

Schlagwort: Security

  • OpenSSH 8.8 deaktiviert Support für RSA-SHA

    Photo by FLY:D on Unsplash

    OpenSSH ist eine auf dem SSH-Protokoll basierende Sammlung von abgesicherten Werkzeugen zum Netzwerken. Das gerade veröffentlichte OpenSSH 8.8 deaktiviert die Unterstützung für RSA-Signaturen mit dem SHA-1-Hash-Algorithmus. Für die meisten Benutzer sollte diese Änderung unmerkbar sein und es besteht keine Notwendigkeit, ssh-rsa-Schlüssel zu ersetzen, da die Funktion UpdateHostKeys die Clients auf einen verlässlicheren Algorithmus aktualisiert. Inkompatibilitäten können lediglich bei Verwendung älterer SSH- Implementierungen auftreten.

    Sicherheitsproblem bei sshd behoben

    Darüber hinaus kündigen die Entwickler an, in einer der nächsten Ausgaben von OpenSSH scp, das Protokoll zur verschlüsselten Übertragung von Daten von der Verwendung des scp/rcp-Protokolls auf die Verwendung von SFTP umzustellen. Die neue Version behebt zudem ein Sicherheitsproblem, das dadurch verursacht wurde, dass sshd seit OpenSSH 6.2 Benutzergruppen fälschlicherweise initialisierte, wenn Befehle aus den Sektionen Authorized Keys Command und Authorized Principals Command ausgeführt wurden, bei denen eine AuthorizedKeysCommandUser– oder AuthorizedPrincipalsCommandUser-Direktive gesetzt wurde, um den Befehl unter einem anderen Benutzer auszuführen. Dadurch konnten je nach Systemkonfiguration unbeabsichtigte Nutzerprivilegien vergeben werden.

  • Whonix 16 basiert auf Debian 11 »Bullseye«

    Whonix 16 basiert auf Debian 11 »Bullseye«

    Wer sich für anonymisierende Distributionen wie Tails oder Qubes interessiert, hat vermutlich auch schon mal von Whonix gehört, einer seit rund 10 Jahren entwickelten, auf Debian basierenden Desktop-Distribution aus deutschen Landen, die gesteigerten Wert auf Sicherheit, Anonymität und den Schutz der Privatsphäre legt. Das Rezept dazu sind zwei getrennte virtuelle Maschinen: einer Workstation und einem Gateway ins Internet. Dabei läuft jeglicher Netzverkehr durch das Tor-Netzwerk. Das System ist zusätzlich über AppArmor-Profile aus dem Paket apparmor-profile-everything abgesichert.

    Für Virtualisierung konzipiert

    Whonix ist für die virtualisierte Verwendung konzipiert, soll es auf echter Hardware laufen, so sind prinzipbedingt dafür zwei Rechner nötig. Beides auf einer Maschine auszuführen, führt das Konzept ad absurdum. Das Whonix Gateway besitzt zwei virtuelle Schnittstellen zur Verbindung über Tor, während die Workstation lediglich über eine private IPv4-Adresse zur Kommunikation nach außen verfügt. Dieses Konzept soll verhindern, dass im Falle einer Kompromittierung die öffentliche IP-Adresse des Anschlusses geleakt werden kann.

    Wechsel zu Debian 11

    Das kürzlich erschienene Whonix 16 wechselt von Debian 10 »Buster« zu Debian 11 »Bullseye« und bringt für die Workstation viele auf ihre Sicherheit hin überprüfte und teils vorkonfigurierte Anwendungen mit. Als Desktop kommt seit Whonix 15 Xfce zum Einsatz, das KDE Plasma ablöste. Das Gateway kommt mit Server-Anwendungen wie Apache HTTPd, Ngnix und einem IRC-Server.

    Neu in Whonix 16 ist auch das standardmäßig aktivierte Debian-FastTrack-Repository. Damit werden Apps wie Ruby, GitLab, VirtualBox oder Matrix, die nicht in Debian Testing gepflegt und auf dem üblichen Weg zurückportiert werden können, als Backports angeboten.

    Whonix kann unter Linux, macOS und Windows betrieben werden. Zudem gibt es ein Abbild zur Integration von Whonix in Qubes. Whonix 16 steht derzeit nur für KVM zur Verfügung. Tester für Virtualbox und Qubes werden gesucht.

  • Red Hat gibt Firewalld 1.0.0 frei

    Red Hat gibt Firewalld 1.0.0 frei

    Firewalld ist ein grafisches Frontend für die Befehlszeilenprogramme iptables und nftables des Netfilter-Frameworks im Kernel. Mit Firewalld lassen sich dauerhafte Regeln für den Netzwerkverkehr setzen, ohne dass man sich in die Gefilde von chains, jumps, accepts und denies begeben muss. Vielmehr regelt Firewalld den Netzverkehr mit einem Zonenmodell mit vordefinierten anpassbaren Regelsätzen. Zonen für bestimmte Szenarien lassen die dafür erlaubten Dienste herein und blockieren alles andere.

    10 Jahre bis zur 1.0.0

    Jetzt hat Red Hat nach 10 Jahren und vielen Minor-Versionen eine stabile Version 1.0.0 veröffentlicht, die auch einige nicht kompatible Neuerungen im Gepäck hat, aber auch Ballast abwirft. So wurde die Kompatibilität zu Python 2 über Bord geworfen und der tftp-client-Dienst entfernt. Das iptables-Backend geht in Rente. Bereits seit Firewalld 0.6 wird das modernere nftables unterstützt. Obwohl als veraltet markiert, wird iptables noch lange in Firewalld verfügbar bleiben.

    Intra Zone-Weiterleitung wird zum Standard

    Das mit Firewalld 0.8 eingeführte Intra Zone Forwarding wird mit 1.0.0 zum Standard. Das ermöglicht die freie Weiterleitung von Paketen zwischen Schnittstellen oder Quellen innerhalb einer Zone, wie es auch bei anderen auf Zonen basierten Firewalls der Fall ist. Für das nftables-Backend wurden die NAT-Regeln zur iNet-Familie zusammengefasst und damit die bisherige Regelduplizierung für ip- und ip6-sets überflüssig.

    Firewalld wird im Herbst mit Fedora 35 als Standard-Firewall ausgeliefert. Außerdem ist Firewalld bei openSUSE, SUSE, Red Hat und CentOS sowie dessen Nachfolgern AlmaLinux und Rocket Linux im Einsatz. Firewalld ist darüber hinaus in den meisten Distributionen aus den Archiven installierbar. Alle Änderungen können im Detail im Blog des Projekts nachgelesen werden. Das Konzept von Firewalld wird in einem Artikel im Sysadmin-Blog näher erläutert.

  • Report: Open-Source-Bibliotheken in Unternehmen kaum aktualisiert

    Bibliotheken selten aktualisiert
    Photo by Florian Olivo on Unsplash

    Ein 36-seitiger Report über die Sicherheit von Software von Sicherheitsanbieter Veracode mit dem Titel State of Software Security (SoSS) v11: Open Source Edition, der im Juni veröffentlicht wurde, stellt einem Großteil der Bibliotheken von Drittanbietern in Repositories ein schlechtes Zeugnis aus. Demnach werden fast 80 % dieser Bibliotheken von den Entwicklern, die sie in ihrer Software verwenden, nie aktualisiert. Als Resultat daraus enthielten fast alle diese Repositories Bibliotheken mit mindestens einer Sicherheitslücke, die sich in 92 % der Fälle mit einem einzigen Update beheben ließen.

    Solide Basis

    Der Report von Veracode (Download erst nach Anmeldung) scheint eine solide Basis zu haben, wie Günter Born in seinem Blog berichtet. Demnach wurden für den Report 13 Millionen Scans von mehr als 86.000 Repositories mit mehr als 301.000 Bibliotheken analysiert. Zudem wurden rund 2.000 Entwickler über ihre Verwendung von Software aus dritter Hand befragt.

    Angst vor Regressionen

    Dabei wird klar, dass es zwei Hauptgründe gibt, warum Entwickler keine Updates einspielen. Einerseits wird dies bei der Vielzahl der verwendeten Bibliotheken auch in proprietärer Software einfach vergessen, andererseits werden nach der Devise »never touch a running system« durch Updates eingeführte Regressionen befürchtet. Der Report stellt allerdings klar, dass 65 % solcher Updates nur minimale Änderungen mitbringen, die selbst bei komplexen Anwendungen kaum dazu in der Lage sind, Schaden anzurichten.

    Richtlinien notwendig

    Die beliebtesten Bibliotheken entstammen Tools und Frameworks wie .NET, Go, JavaScript, Ruby, PHP, Python Java und Swift, wobei die Beliebtheit von Jahr zu Jahr stark schwanken kann. Der Report geht auch darauf ein, ob Unternehmen Richtlinien haben, wenn es um die Auswahl von Bibliotheken geht und wie diese aussehen.

    Als Fazit kann man mitnehmen, dass die Sicherheit der Lieferkette bei Software einen steigenden Wert darstellt und die Einstellung vieler Entwickler von »Einbinden und Vergessen« nicht länger tragbar ist. Da sich Bibliotheken schnell ändern können, sei eine Bestandsaufnahme der verwendeten Bibliotheken im Unternehmen unabdingbar.

  • OpenSSL 3.0 mit neuer Lizenz

    OpenSSL 3.0

    OpenSSL, die freie Software-Bibliothek für Anwendungen, die die Kommunikation über Computernetzwerke unter anderem mittels SSL/TLS für die Mehrheit der HTTPS-Webseiten sichern, stellt die erste Beta-Version des neuen, ursprünglich für das 4. Quartal 2020 zur Veröffentlichung anstehenden Hauptzweigs 3.0 online. Das gab das OpenSSL Management Committee jetzt im Projektblog bekannt.

    Neu: Lizenz und Versionierung

    Drei Jahre haben die Entwickler an der neuen Hauptversion OpenSSL 3 gearbeitet und dabei mehr als 7.000 Commits von über 300 Entwicklern integriert. Mit der neuen Version wechselt das Projekt von der bisherigen Doppel-Lizenzierung aus SSLeay und seiner eigenen Lizenz hin zur Apache 2 Lizenz, um die Verwendung in anderen Open-Source-Projekten zu vereinfachen. Die Versionierung wird vereinfacht.

    Provider-basierte Architektur als Standard

    An die Stelle der bisherigen »Engine« API tritt eine Provider-basierte Architektur. Diese soll mehr Flexibilität bringen und es Drittautoren ermöglichen, neue Kryptoalgorithmen in OpenSSL hinzuzufügen. Dabei ist das Provider-Konzept eine der wichtigsten Änderungen, die bereits mit OpenSSL 1.1.1 eingeführt wurden. Provider sammeln Algorithmus-Implementierungen und stellen sie zur Verfügung. Mit OpenSSL 3.0 ist es nun möglich, entweder programmatisch oder über eine Konfigurationsdatei festzulegen, welche Provider der Anwender für eine bestimmte Anwendung verwenden möchte. OpenSSL 3.0 wird standardmäßig mit 5 verschiedenen Providern ausgeliefert. Im Laufe der Zeit werden möglicherweise weitere Provider von Drittanbietern zur Verfügung gestellt, die in OpenSSL eingebunden werden können.

    FIPS-Modul in Arbeit

    Einer der verfügbaren Standardanbieter ist FIPS. Dieser stellt FIPS-validierte kryptografische Algorithmen zur Verfügung. OpenSSL wurde 2006 erstmals die FIPS 140-2-Zertifizierung erteilt. Ein entsprechendes Modul ist für OpenSSL 3 in Arbeit, wird wegen des langen Review-Prozesses von mindestens sechs Monaten aber erst im nächsten Jahr erwartet. Zur Verwaltung von digitalen Zertifikaten in einer Public-Key-Infrastruktur (PKI) wurde das Certificate Management Protocol (CMP) vollständig implementiert.

    OpenSSL 3.0 ist ein Major-Release, was bedeutet, dass die ABI der Bibliothek geändert wurde, was eine Neukompilierung aller abhängigen Anwendungen erfordert. Ein Migrations-Leitfaden soll Entwicklern helfen, falls nötig ihre Anwendungen anzupassen. Der Quellcode steht auf der Projektseite bereit, das Projekt wird auf GitHub gepflegt.

  • Kritische Lücke in Polkit nach 7 Jahren geschlossen

    Photo by iMattSmart on Unsplash

    Polkit, das früher PoilcyKit hieß ist der mit Systemd verbandelte Berechtigungsdienst, der es unprivilegierten Prozessen ermöglicht mit ihren privilegierten Kollegen sprechen können. Wenn also eine Anwendung für eine Aufgabe Root-Rechte benötigt, fragt Polkit nach dem entsprechenden Passwort.

    CVE-2021-3560

    Wie auf GitHub aktuell zu lesen ist, wurde kürzlich eine Sicherheitslücke entdeckt, die seit sieben Jahren in Polkit vorhanden war und als CVE-2021-3560 (Common Vulnerabilities & Exposures) katalogisiert ist. Sie war mit 7.8 von 10 Punkten als kritisch eingestuft.

    Ausweitung der Rechte

    Bei der Lücke handelte es sich um eine mögliche Privilegien-Eskalation, die sehr einfach durchzuführen war. Sie war mit Commit bfa5036 in Version 0.113 eingeschleppt worden. Wie Kevin Backhouse, der Entdecker der Lücke schreibt, waren zur Ausnutzung lediglich einige Kommandozeilen-Werkzeuge und Befehle wie bash, kill und dbus-send notwendig. Die Schwachstelle wird durch das Starten eines dbus-send-Befehls ausgelöst, der jedoch sofort per kill beendet wird, während Polkit noch mitten in der Verarbeitung der Anfrage steckt.

    Polkit ging mit der Antwort auf die bereits beendete Anfrage falsch um. Anstatt den Vorgang abzubrechen, ging Polkit davon aus, dass die Anfrage von einem Prozess mit der UID 0 gekommen sei, also von einem Root-Prozess und genehmigte die Anfrage. Das gelang zwar nicht immer, aber oft genug, um den Aufwand gering zu halten.

    Bitte zeitnah aktualisieren

    Der Fehler betrifft Distributionen, die Polkit in Version 0.113 oder später verwenden. Welche Distributionen das sind, lässt sich mit Repology nachvollziehen. Debian hat mittlerweile mit Version 0.105-31 einen Patch für Unstable und Testing bereitgestellt, den Ubuntu für 21.04 übernommen hat. Unter anderem auch Arch Linux, Red Hat und SUSE haben ihre Pakete gepatched.

  • NSA gibt Hacker-Tool als Open Source frei

    Der US-amerikanische Geheimdienst NSA hat auf seiner derzeit abgehaltenen Jahreskonferenz RSA Conference 2019 die Freigabe des Hacker-Tools GHIDRA als Open Source bekannt gegeben

    Binärpakete analysieren

    GHIDRA ist ein Java-basiertes Reverse-Engineering-Framework mit einer grafischen Benutzeroberfläche (GUI), das für die Ausführung auf einer Vielzahl von Plattformen wie Linux, Windows und macOS entwickelt wurde. Das Framework enthält eine Reihe mächtiger High-End-Softwareanalyse-Tools, die es Anwendern ermöglichen, kompilierten Code zu analysieren.

    Gut oder böse?

    Offiziell setzt die NSA das selbst entwickelte Software-Reverse-Engineering-Tool bereits seit über einem Jahrzehnt intern ein, um Sicherheitsprobleme in Software zu beheben. Genausogut kann das Werkzeug aber auch dazu dienen, Backdoors in Binärsoftware zu platzieren.

    Keine Backdoor!

    Bei der Vorstellung des Werkzeugs auf der RSA betonte Rob Joyce, Referent für Cybersicherheit bei der NSA, GHIDRA habe keine Backdoor: »Dies ist die letzte Community, in die du etwas mit einer installierten Hintertür freigeben möchtest, für Leute, die nach diesem Zeug suchen, um es auseinanderzunehmen.«

    Keine Backdoor?

    Der britische Sicherheitsforscher Matthew Hickey vom Unternehmen Hacker House fand laut The Register einen zunächst verdächtigen Port, wenn das Tool im Debug-Modus läuft. Dann öffnet es den Port 18001 für das lokale Netzwerk und akzeptiert und führt Remote-Befehle von jeder Maschine aus, die sich verbinden dahin kann. Der Debug-Modus ist standardmäßig aber nicht aktiviert und kann auch auf Verbindungen des Host-Rechners beschränkt werden. Also eher keine Backdoor.

    Reverse-Enginiering-Tools

    Zu den Funktionen gehören Disassemblierung, Montage, Dekompilierung, und Skripting sowie Hunderte von weiteren Funktionen. GHIDRA unterstützt eine Vielzahl von Prozessanweisungen und ausführbaren Formaten und kann sowohl im interaktiven als auch im automatisierten Modus ausgeführt werden. Benutzer können auch ihre eigenen GHIDRA-Plugins oder Skripte mit Java oder Python entwickeln.

    InfoSec-Community hoch erfreut

    Die InfoSec-Community wartete bereits seit der ersten Ankündigung im Januar auf das mächtige Werkzeug zum Aufspüren von Viren und Malware, das nun in Version 9.0 auf der Webseite des Projekts zur Verfügung steht. Bisher standen in dieser Qualität lediglich teure kommerzielle Werkzeuge wie IDA-Pro, Radare, Capstone oder Hopper zur Verfügung.

    GHIDRA soll in nächster Zeit komplett auf GitHub zur Verfügung stehen, eine Installallationsanleitung steht auf der Projektseite bereit.

  • Ubuntu-Fehler: Sperrbildschirm kann umgangen werden

    Ubuntu-Fehler
    Bild: Security | Quelle GotCredit | Lizenz: CC BY-2.0

     

    Hacker können Zugriff auf laufende Anwendungen auf einem Ubuntu-Rechner erhalten, wenn Sie physischen Zugriff auf dessen Festplatte haben. Dieser bereits am 18. Juni gemeldete und erst  jetzt bekannt gewordene Ubuntu-Fehler betrifft alle Versionen seit Ubuntu 14.04 LTS »Trusty Tahr«.

    Vermutlich sind aber auch die Derivate der Ubuntu-Familie (bestätigt für 18.04 MATE) als auch Ableger wie Linux Mint und andere betroffen. Dabei besteht Zugriff auf offene Anwendungen des Anwenders, bevor dieser das Gerät in den Ruhemodus schickt.

    Kritischer Ubuntu-Fehler

    Wenn der Angreifer die Festplatte, auf der sich die Installation befindet, während des Ruhemodus (suspend) entfernt und dann das Gerät aufweckt, gibt es mehrere Möglichkeiten: Der Sperrbildschirm erscheint und die Eingabe eines beliebigen Passworts erlaubt den Zugriff. Wenn das beliebige Passwort nicht angenommen wird, kann der Ausschaltknopf der Hardware betätigt und dadurch der Zugriff erreicht werden. Bleibt der Bildschirm dunkel, kann der Vorgang, beginnend mit dem Ruhemodus des Rechners wiederholt werden.

    Die erste Stellungname eines Canonical-Security-Ingenieurs liest sich nicht gerade beruhigend:

    [su_quote style=“modern-light“ cite=“Marc Deslauriers“]Es ist unwahrscheinlich, dass wir dies beheben werden, da ein Angreifer mit einem physischen Zugriff einfach direkt auf die Festplatte zugreifen oder das Passwort auf der Festplatte ersetzen und den Computer entsperren kann.[/su_quote]

    Auch wenn dies so richtig ist, das Entfernen der Festplatte eines Rechners erfordert lediglich mechanisches Geschick und kein Wissen wie man das Passwort ersetzt. Es ist ein einfach klingender Hack und er funktioniert, indem er einen Fehler in der Art und Weise ausnutzt, wie das System Daten speichert, wenn Ubuntu im Ruhezustand ist.

    Ein weiterer in diesem Zusammenhang aufgetauchter Fehler erlaubt manchmal das Umgehen des Sperrbildschirms durch Anschließen eines HDMI-Monitors, sobald der Sperrbildschirm auftaucht.

    AMD-Microcode zurückgezogen

    Erst gestern wurde ein anderes Sicherheitsproblem bei Ubuntu 14.04 LTS »Trusty Tahr« beseitigt, indem der vorherige unsichere Zustand wieder hergestellt wurde. Der am 20. Juni ausgelieferte AMD-Microcode musste zurückgezogen werden, da er durch eine Regression vereinzelt den Bootvorgang von Rechnern unterbrach und diese somit nutzlos machte.

    Der AMD-Microcode sollte eigentlich den Auswirkungen der Anfang Januar bekannt gewordenen Spectre-Lücke (CVE-2017-5715) entgegenzuwirken. Nun zog Canonical den Microcode zurück, indem das Paket amd64-microcode 3.20180524.1~ubuntu0.14.04.2+really20130710.1 an seine Stelle rückte.

  • Wichtiges Debian-Security-Update

    Wichtiges Debian-Security-Update

    Debian-Security-Update
    Screenshot: ft

     

    Debians Kernel-Maintainer Ben Hutchings hat mit dem Debian Security Advisory DSA 4073-1 ein wichtiges Debian-Security-Update für Kernel 4.9 LTS in  Debian GNU/Linux 9 »Stretch« freigegeben. Das Update deckt insgesamt 18 kürzlich entdeckte Sicherheitslücken im Kernel ab, die von Data Leakage  über Rechteausweitung bis hin zu Denial of Service reichten.

    Alle 18 Lücken haben eine CVE-Nummer

    Nähere Einzelheiten können über die zugeordneten CVE-Nummern eingeholt werden. Diese lauten CVE-2017-8824, CVE-2017-16538, CVE-2017-16644, CVE-2017-16995, CVE-2017-17448, CVE-2017-17449, CVE-2017-17450, CVE-2017-17558, CVE-2017-17712, CVE-2017-17741, CVE-2017-17805, CVE-2017-17806, CVE-2017-17807, CVE-2017-17862, CVE-2017-17863, CVE-2017-17864, CVE-2017-1000407 und CVE-2017-1000410.

    Zeitnah aktualisieren!

    Hutchings erläutert zudem jede Verwundbarkeit einzeln kurz in seiner Ankündigung des Debian-Security-Update. Die Sicherheitslücken sind im aktuellen Debian-Kernel mit der Versionsnummer 4.9.65-3+deb9u1 geschlossen. Im kürzlich erschienenen Update auf Debian 9.3 sind diese Lücken noch vorhanden. Somit sind Anwender von Debian 9 »Stretch« angehalten, ihre Systeme zeitnah durch ein Update abzusichern. Weitere Informationen zu Debian Security Advisories bietet die Debian-Security-Webseite.