Quantencomputer können bestimmte komplexe Aufgaben in einer Geschwindigkeit lösen, die alle herkömmlichen Supercomputer um viele Größenordnungen übertrifft.
Die an Pentester und Sicherheitsexperten gerichtete Distribution Kali Linux frischt die Optik leicht auf, schraubt dezent an den Images für den Raspberry Pi und trägt ungewöhnlicherweise ein „a“…
Die an Pentester und Sicherheitsexperten gerichtete Distribution Kali Linux frischt die Optik leicht auf, schraubt dezent an den Images für den Raspberry Pi und trägt ungewöhnlicherweise ein „a“…
Das neueste Feature-Release Git v2.49.0 ist verfügbar. 460 Nicht-Merge-Commits seit v2.48.0 sind von 89 Personen beigesteuert worden.
Wer Quellcode mit dem Editor Zed bearbeitet, kann jetzt direkt aus der Benutzeroberfläche heraus die Versionsverwaltung Git steuern.
Wer Quellcode mit dem Editor Zed bearbeitet, kann jetzt direkt aus der Benutzeroberfläche heraus die Versionsverwaltung Git steuern.
Das altehrwürdige Startsystem SysVinit kommt immer noch zum Einsatz und wird stetig weiterentwickelt.
Das altehrwürdige Startsystem SysVinit kommt immer noch zum Einsatz und wird stetig weiterentwickelt.
Die Distribution ParrotOS richtet sich mit ihren vorinstallierten Werkzeugen primär an Sicherheitsexperten und Pentester. Die neue Ausgabe aktualisiert zahlreiche Pakete und korrigiert Fehler.
Die Distribution ParrotOS richtet sich mit ihren vorinstallierten Werkzeugen primär an Sicherheitsexperten und Pentester. Die neue Ausgabe aktualisiert zahlreiche Pakete und korrigiert Fehler.
Die EU-Kommission hat einen europäischen Aktionsplan zur Stärkung der Cybersicherheit von Krankenhäusern und Gesundheitsdienstleistern auf den Weg gebracht.
Eine Gruppe von Google-Forschern und Aleksei Gorban haben gravierende Sicherheitslücken im Dateisynchronisationswerkzeug Rsync entdeckt.
Eine Gruppe von Google-Forschern und Aleksei Gorban haben gravierende Sicherheitslücken im Dateisynchronisationswerkzeug Rsync entdeckt.
Das Open-Source-Projekt Git hat Git 2.48 mit Funktionen und Fehlerkorrekturen von über 93 Mitwirkenden veröffentlicht. Das Git-Projekt kann bei diesen Beitragenden 35 neue zählen.
In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.
Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.
Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.
Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.
Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.
Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.
Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.
Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.
Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.
Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.
Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.
Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.
Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.
Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.
Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.
Bekanntermaßen sind SSH-Verbindungen weitestgehend das Standardverfahren, um Serververbindungen sicher aufzubauen.
Normalerweise kommt in Bezug auf Authentifizierung eine Kombination aus Nutzernamen und Passwort zum Einsatz. Es gibt aber auch Varianten mit Zertifikat oder Schlüssel.
Letzteres sollte nicht nur Standard, sondern heute auch Thema sein. Üblicherweise erhältst du via SSH Vollzugriff (oke vielleicht kein root), es besteht allerdings die Möglichkeit diesen per authorized keys zu regulieren, so kannst du in einem SSH Schlüssel etwa eine IP-Beschränkung hinterlegen, um einen Zugriff weiter einzuschränken.
In einem Standardsetup findest du vorhandene Schlüssel unter ~/.ssh/authorized_keys und genau hier möchte ich heute einen genaueren Blick darauf werfen.
Dort liegen die öffentlichen SSH-Schlüssel, die einen bestimmten Aufbau haben, dazu gleich mehr. Auch wird zwischen Version 1 und Version 2 unterschieden, wobei zwei der Standard sein sollte.
Ältere Semester kennen eventuell noch ~/.ssh/authorized_keys2, was ursprünglich für den zweiten Protokolltyp vorgesehen war, allerdings seit 2001 deprecated ist und heute maximal noch von böswilligen Akteuren missbraucht wird.
Zurück zu den Schlüsseln, folgende Aufteilung besitzen diese laut Norm:
Im Detail ermöglichen sie, verschiedene Werte mitzugeben und anderen eine IP-Einschränkung.
Hier ein erstes Beispiel:
Anmelden
from="192.168.1.?,*.example.com" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com
Zur Erklärung: Du kannst in den Optionen Wildcards setzen. Das heißt, im Beispiel oben hätte 192.168.1.1-9 Zugriff, sowie Subdomains von example.com.
Eine weitere Möglichkeit wäre, die Option command zu verwenden, um direkte Befehle zu hinterlegen:
command="bash /opt/startworkflow" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com
command="/opt/mehrere_befehle.sh" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com
Der Nutzer hat hier nur das Recht, das vorgegebene Kommando auszuführen, nicht mehr und nicht weniger
Kontrollieren kannst du solche Kommandos mit der Variable $SSH_ORIGINAL_COMMAND. Diese enthält die ursprüngliche Befehlszeile
sobald ein erzwungener Befehl ausgeführt wird.
Wenn du mehrere Befehle erlauben willst, kommst du nicht drumherum, ein Script zu schreiben, was diese Beschränkungen mehr oder weniger aushebelt.
Ein weiteres Beispiel zeigt die Verwendungen der Kommandos für SSH Tunneling bzw. Port Forwarding:
restrict,port-forwarding,permitopen="localhost:8765" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com
Hier wird explizit erlaubt, eine Verbindung auf Port 8765 herzustellen und alles andere bitte bleiben zu lassen. Auch echter Shell-Zugang (no-pty ist in restrict enthalten) wird unterbunden.
restrict
Enable all restrictions, i.e. disable port, agent and X11 forwarding, as well as disabling PTY allocation and execution of ~/.ssh/rc. If any future restriction capabilities are added to authorized_keys files they will be included in this set.
Du hast nun einen kleinen Einblick in die vielfältigen Konfigurationsmöglichkeiten von SSH-Schlüsseln erhalten. Gerade IP-Beschränkungen oder Limitierung auf Befehle kommen im Alltag vor und sind in diesem Sinne keine neue Methode.
SSH Tunneling ist eigentlich schon wieder ein anderes Kapitel.
Einen Überblick der SSH Befehle findest du bei den Ubuntu Manpages. Viel Spaß.
Ein neues Malware-Rootkit namens Pumakit wurde kürzlich entdeckt und stellt eine Bedrohung für Linux-Systeme dar. Es nutzt fortschrittliche Verschleierungsmethoden, um sich unbemerkt auf betroffenen Systemen zu verstecken. Aktuell betrifft die Schadsoftware ausschließlich Linux Kernel Versionen älter als 5.7. Das Sicherheitsunternehmen Elastic identifizierte Pumakit im September, nachdem ein verdächtiges Binary von „cron“ auf VirusTotal hochgeladen wurde. […]
Der Beitrag Neuer Linux-Rootkit „Pumakit“ entdeckt: Das musst Du wissen erschien zuerst auf fosstopia.
Alarmierender Anstieg von Open-Source-Malware / Seit 2019 haben Sonatype-Analysen mehr als 778.500 bösartige Pakete aufgedeckt
Die Entscheidung, Forgejo als neuen Git-Forge zu verwenden, ist beim Fedora-Projekt wohl gefallen. Fedora Project Leiter Matthew Miller erläutert die Gründe für die Abkehr von Pagure.
Die Sicherheitslage im Cyberraum ist weiterhin angespannt. Zugleich stellen sich Staat, Wirtschaft und Gesellschaft stärker als bisher auf die Bedrohungen ein.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine Umfrage zum Thema KI-Sicherheit gestartet. Bis zum 15.
Die Distribution Parrot OS für Sicherheitsexperten und Penetration-Tester liegt in einer neuen Version 6.2 vor, die vor allem Produktpflege betreibt.
Die Distribution für Sicherheitsexperten und Penetration-Tester liegt in einer neuen Version vor, die vor allem Produktpflege betreibt.
Die Experten Georg Link und Luis Canas Diaz von Bitergia haben in ihrem Vortrag beim Ubuntu Summit vor zunehmenden Attacken auf die Software Supply Chain gewarnt.
Mark Shuttleworth, Ubuntu-Gründer und CEO von Canonical hat im World Forum in Den Haag den Ubuntu Summit 2024 eröffnet. Beim Summit wird auch das 20jährige Jubiläum von Ubuntu gefeiert.
