Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

GitHub aktualisiert RSA SSH Host-Key

24. März 2023 um 10:55

Kurz notiert für alle, die GitHub nutzen, um ihre Git-Repositories zu speichern. Laut einem Artikel auf dem GitHub-Blog sah sich das Team durch einen Leak eines RSA-SSH-Private-Keys diese Woche gezwungen, heute am 24. März 2023 um 05:00 UTC (06:00 Uhr deutscher Zeit) die Keys zu tauschen.

Da nach TOFU-Prinzip vom SSH-Client der Key gespeichert wird, der bei der ersten Nutzung verwendet wurde, werden nachträgliche Änderungen auf Host-Seite als Man-in-the-Middle-Angriff (MitM-Angriff) vermutet. Deswegen sollte der alte, nun komprimittierte Key aus der known_hosts entfernt werden. Wie das geht, habe ich auf dem Blog hier schon einmal beschrieben.

Bei der erneuten, jetzt wieder "erstmaligen" Verbindung mit github.com sollte in jeden Fall der neue Key unbedingt mit der verlinkten GitHub-Dokumentationsseite abgeglichen werden, da man sonst erst recht MitM-Angriffen ausgesetzt ist. In der Regel wird spätestens jetzt ein auf einem neuen Verfahren wie ed25519 basierender Host-Key angeboten, was man auch nutzen sollte.

Docker irritiert Open-Source-Projekte mit Lösch-Ankündigung

17. März 2023 um 09:12

Docker will kostenfreie Team-Accounts für den Hub nicht mehr anbieten. Für Open-Source-Projekte bringt das Verwirrung und Probleme. Das Unternehmen gesteht Kommunikationsfehler ein.

Container-Spezialist Docker hat mit einer E-Mail an verbliebene Nutzer kostenfreier Team-Accounts in seinem Hub für Irritation bei zahlreichen Open-Source-Projekten gesorgt. Demnach sollten die kostenfreien Accounts und deren Inhalte wie Images gelöscht werden, falls nicht auf ein zahlungspflichtiges Abo-Modell gewechselt werde. Schon kurz nach der Ankündigung versuchte Docker jedoch, zumindest die Open-Source-Community zu beschwichtigen.

Die versendete E-Mail und zunächst dazu verfügbare FAQ sorgten für zahlreiche Diskussionen, etwa auf Hackernews oder Twitter, aber auch im Issue-Tracker der Projekte selbst – vermutlich, weil sie viel zu vage formuliert waren und noch viele Fragen zum Ablauf offen ließen. Viele Projekte sahen sich nicht nur mit dem Problem konfrontiert, ein Abo abschließen zu müssen, sondern auch damit, dass Images und Daten gelöscht werden sollten, falls das nicht erfolgt. Das wiederum könnte CI-Systeme oder Ähnliches von Dritten beeinträchtigen.

In den inzwischen überarbeiten FAQ findet sich nun ein neuer Absatz speziell für Open-Source-Projekte. Darin heißt es, dass das Ende der kostenfreien Team-Accounts nicht für jene Projekte gelte, die Teil von Dockers Open-Source-Sponsoring-Programm seien. Das Unternehmen forderte betroffene Projekte auf, sich um Aufnahme in das Programm zu bemühen. Man habe außerdem die Zahl der Angestellten erhöht, die die Bewerbungen überprüfen.

Auf Github beschweren sich jedoch zahlreiche Open-Source-Entwickler, dass sie nach einer Bewerbung für das Sponsoring-Programm in der Vergangenheit nie eine Rückmeldung von Docker erhielten, wie etwa bei Rocky Linux. Ebenso heißt es, dass die Fragen oder Bestimmungen zur Aufnahme auf einige Projekte schlicht nicht zuträfen und eine Bewerbung so überhaupt nicht möglich sei.

Das Docker-Unternehmen bittet inzwischen offiziell auf seinem Blog um Entschuldigung: “Wir entschuldigen uns für die Art und Weise, wie wir die Beendigung des kostenfreien Docker-Team-Abonnements kommuniziert und durchgeführt haben, was die Open-Source-Gemeinschaft alarmiert hat.” Das Unternehmen hat außerdem ausführliche FAQ zum weiteren Vorgehen veröffentlicht und bittet weiter um Feedback von Open-Source-Projekten.

Der Beitrag Docker irritiert Open-Source-Projekte mit Lösch-Ankündigung erschien zuerst auf Linux-Magazin.

Github führt verpflichtende 2FA ein

13. März 2023 um 12:37

Wer von Github ausgewählt wurde, muss die Zwei-Faktor-Authentifizierung (2FA) innerhalb von 45 Tagen einrichten.

Ab sofort verlangt Github von aktiven Entwicklern, eine Zwei-Faktor-Authentifizierung (2FA) für ihre Konten zu aktivieren. Die Maßnahme soll die Sicherheit für die Konten der über 100 Millionen Nutzer verbessern.

Den Schritt kündigte Github bereits vor einiger Zeit an. Zuerst berichtete das Onlinemagazin Bleepingcomputer über die anstehende Einführung.

Diese soll schrittweise stattfinden. Ab dem 13. März sollen kleinere Gruppen von Administratoren und Entwicklern per E-Mail angesprochen werden. Dabei soll sichergestellt werden, dass das Onboarding nahtlos verläuft und die Nutzer Zeit haben, eventuell auftretende Probleme zu lösen.

“Github hat einen Rollout-Prozess entwickelt, der sowohl unerwartete Unterbrechungen und Produktivitätsverluste für die Nutzer minimieren als auch Kontosperrungen verhindern soll”, erklärten Staff Product Manager Hirsch Singhal und Product Marketing Director Laura Paine.

“Gruppen von Nutzern werden im Laufe der Zeit aufgefordert, 2FA zu aktivieren. Dabei wird jede Gruppe auf der Grundlage der Aktionen und des Codes ausgewählt, den sie beigetragen haben.” Wenn das Konto für die Einführung einer Zwei-Faktor-Authentifizierung ausgewählt wurde, bleiben den jeweiligen Nutzern 45 Tage, sie zu aktivieren. In dieser Zeit soll das Github-Konto, abgesehen von gelegentlichen Erinnerungen, weiter normal nutzbar sein. Danach können einige Funktionen gesperrt werden, bis die 2FA eingerichtet wurde.

Als 2FA-Verfahren bietet Github Sicherheitsschlüssel (Fido-Sticks/Passkeys), TOTP, SMS sowie die Github-App an. Von der Verwendung von SMS als zweitem Faktor rät das Unternehmen aus Sicherheitsgründen jedoch explizit ab.

Der Beitrag Github führt verpflichtende 2FA ein erschien zuerst auf Linux-Magazin.

Atom-Editor eingestellt

31. Januar 2023 um 17:44

Wie GitHub bereits im Juni 2022 verlauten ließ, wurde der Editor Atom eingestellt. Dabei wurde am 15. Dezember 2022 das Repository archiviert und die Entwicklung somit vollständig beendet. Atom erschien im Jahr 2014 und wurde direkt durch GitHub entwickelt und stellte eine Alternative zu Editoren wie Sublime Text oder Notepad++ dar. Der Editor hat dabei nachhaltig die Welt der Desktop-Anwendungen verändert.

Der Grund hierfür liegt in der Basis, die anfangs noch Atom Shell hieß, aber später in Electron umbenannt wurde – ein Begriff, den viele sicherlich kennen werden. Electron wiederum nutzt Chromium als Basis, sodass die Entwicklung plattformunabhängiger Anwendungen ermöglicht wird, bei denen die eigentliche Anwendung lediglich innerhalb der Chromium-Browserinstanz ausgeführt wird.

Electron

Electron wird dabei kontrovers diskutiert. Es fällt auf der einen Seite der Ressourcenverbrauch auf, der entsteht, wenn mehrere Electron-Anwendungen mehrere Chromium-Browserinstanzen ausführen, die dann den RAM belagern. Auch sind Anwendungen nicht gerade klein – so ist eine Größe von über 100 MB selbst für kleinere Anwendungen nicht unüblich. Nicht allzuletzt wird der Kern der Anwendung auch in JavaScript und mit Paketen aus dem npm-Ökosystem ausgeführt. All das sind Faktoren, die zu einer hohen Komplexität und regelmäßigen Sicherheitsaktualisierungen führen, welche nicht außer Acht gelassen werden dürfen. Auf der anderen Seite stellt Electron aber eine Alternative zu verschiedensten Desktop-Frameworks wie Qt oder wxWidgets dar, steht unter der MIT-Lizenz und ermöglicht dank HTML, CSS und JavaScript eine mitunter einfachere Entwicklung von grafisch hochwertigen Anwendungen. Ob die Vorteile die Nachteile aufwiegen, bleibt dem Einzelfall überlassen.

Electron wird von Anwendungen wie Discord, Microsoft Teams oder auch Microsoft Visual Studio Code eingesetzt. Letztere Anwendung wird auch Atom beerben, da es nach dem Aufkauf von GitHub durch Microsoft nur eine Frage der Zeit war, bis einer der beiden Editoren weichen muss. GitHub selber möchte sich mit der Entscheidung vor allem auf die GitHub Codespaces konzentrieren, die Visual Studio Code in den Webbrowser bringen.

Mittlerweile gibt es im übrigen auch Alternativen zu Electron. Eine davon ist Tauri. Das Rust-Framework bietet dabei ähnliche Funktionen, baut intern aber nicht auf Chromium, sondern auf den jeweiligen WebView der OS-Plattform auf. Hier ist ein kurzer Einführungsartikel zu Tauri zu finden.

Aktueller Sicherheitshinweise zu Atom

Obgleich ich diesen Artikel deutlich früher schreiben wollte, gibt es heute einen wichtigen Anlass dazu: wer Atom noch einsetzt, sollte diesen Artikel beachten, da GitHub einige Zertifikate für Atom und GitHub Desktop zurückziehen musste und ggfs. ein Downgrade der Versionen erforderlich ist.

Intel beendet zahlreiche Open-Source-Projekte

11. Januar 2023 um 10:31

Intel hat aus seinen Github-Repositories rund 160 Open-Source-Projekte als beendet erklärt. Gründe für den Kahlschlag liefert Intel nicht.

Bei den rund 970 Repositories, die Intel unter dem Brand Open.Intel auf Github hostet, sind nun zahlreiche unter dem Flag „Public Archive“ zu finden. Intel schreibt in den Readme-Dateien meist gleichlautend: Dieses Projekt wird nicht mehr von Intel gewartet. Intel hat die Entwicklung und Beiträge zu diesem Projekt eingestellt, einschließlich, aber nicht beschränkt auf Wartung, Fehlerbehebung, neue Versionen oder Updates. Intel nimmt keine Patches für dieses Projekt mehr an.  Wenn Sie dieses Projekt weiterhin benötigen, an einer unabhängigen Entwicklung interessiert sind oder Patches für die Open-Source-Software-Community bereitstellen möchten, erstellen Sie bitte einen eigenen Fork dieses Projekts.

Zu den Projekten zählt der Hypervisor HAXM. Der Hardware Accelerated Execution Manager kam etwa beim Android Emulator zum Einsatz und funktionierte mit Windows, Linux, MacOS sowie Net-BSD. Dort heißt es in dem Github-Commit eines Intel-Entwicklers, dass bei diesem Projekt festgestellt wurde, dass es bekannte Sicherheitslücken aufweise.

Der Beitrag Intel beendet zahlreiche Open-Source-Projekte erschien zuerst auf Linux-Magazin.

Github macht minimale Zugeständnisse für Copilot

09. Dezember 2022 um 10:07

Das KI-Codingwerkzeug Copilot steht wegen möglicher Code-Kopien in der Kritik. Das Enterprise-Angebot von Github kann Kopien unterbinden.

Der zu Microsoft gehörende Code-Hoster Github startet sein Enterprise-Angebot für Nutzer des KI-Codingwerkzeugs Copilot. Bisher stand Copilot nur für den Gebrauch durch einzelne Nutzer bereit. Mit 19 US-Dollar pro Nutzer und Monat kostet dies etwa doppelt so viel wie das Angebot für Privatpersonen. Dafür soll es aber auch mehr Kontrollmöglichkeiten geben.

Die dabei wohl wichtigste Option dürfte sein, dass Copilot es im Unternehmenseinsatz ermöglicht, die Anzeige und Übernahme von Code-Vorschlägen für alle Nutzer zu unterbinden, sofern der Vorschlag Code aus öffentlich zugänglichen Repositorys auf Github entspricht.

Das dürfte eine direkte Reaktion auf die zahlreiche Kritik an Copilot sein, dass das Werkzeug einfach Code-Kopien vorschlägt und damit eventuell sogar Urheberrechte verletzt. Auch wenn die rechtlichen Fragen dazu noch nicht abschließend geklärt sind, sollte dies natürlich im Unternehmenseinsatz zwingend vermieden werden.

Eine Option von Copilot ermöglicht das Ausfiltern von Vorschlägen über 150 Zeichen, falls die Vorschläge identisch zu öffentlich verfügbarem Code sind. Die Erfahrung mit Machine-Learning-Modellen zeigt darüber hinaus, dass diese unter bestimmten Umständen und einer geschickten Wahl der Eingabe zur Ausgabe ihrer Trainingsdaten oder dazu sehr ähnlicher Daten bewegt werden können. Ob die nun verfügbare Option im Unternehmensangebot also reicht, muss sich zeigen.

Darüber hinaus verspricht Github den Kunden des Unternehmensangebot auch, den mit Copilot erstellten Code selbst nicht weiter zu verwenden. Dazu heißt es: “Wir behalten keine Codeausschnitte, speichern oder teilen Ihren Code nicht, unabhängig davon, ob die Daten aus öffentlichen Repositories, privaten Repositories, Nicht-GitHub-Repositories oder lokalen Dateien stammen.”

Der Beitrag Github macht minimale Zugeständnisse für Copilot erschien zuerst auf Linux-Magazin.

truffleHog3 – Passwörter und Zugangsdaten in Git, Github, Gitlab oder AWS finden und entfernen

27. November 2022 um 10:09

Bereits im April dieses Jahres wurde Version 3 des Repository-Security-Tools Trufflehog veröffentlicht. Zeit, einen eigenen Artikel über das bekannte Kali Tool zu verfassen.

Was ist Trufflehog

Leaked credentials oder secret keys sollten nicht in Github Repositorys zu finden sein, dennoch passiert dies öfters als gedacht. Genau hier setzt das Tool truffleHog3 an, es scannt Repositorys und mehr auf Geheimnisse wie Zugangsdaten, API Keys usw.

Das Security-Tool durchläuft dabei die gesamte Commit-Historie jedes Branches, prüft jedes diff von jedem commit und sucht nach Geheimnissen.

Möglich wird dies unter anderem durch die Verwendung von regulären Ausdrücken und Entropie.

Mit der Version 3 unterstützt truffleHog inzwischen mehr als 700 verschiedene Key Types von AWS, Azure, Confluent oder Facebook. Eine Übersicht der Detektoren ist hier zu finden.

Folgende Code Quellen werden momentan unterstützt:

  • git
  • github
  • gitlab
  • S3
  • filesystem
  • syslog

Installation

Die Trufflehog Installation erfordert eine funktionierende GO Installation. Alternativ kann auch auf Python Pip zurückgegriffen werden, allerdings wird via Pip momentan keine aktuelle Version angeboten. Für einen Test bietet sich die Docker Variante an.

#Aktuellste Version
git clone https://github.com/trufflesecurity/trufflehog.git
cd trufflehog
go install oder go build

#Via Python Pip (allerdings steht hier nur Version 3.0.x zur Verfügung)
pip3 install trufflehog3

#Die aktuellste Version via Docker Paket laufen lassen

docker run -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=trufflesecurity

Anwendungsbeispiele

#Hilfe
trufflehog --help

#github scan mit Optionen
trufflehog github --repo=https://github.com/trufflesecurity/trufflehog

trufflehog github --repo=https://github.com/trufflesecurity/trufflehog --json --only-verified

#AWS scan
trufflehog s3 --bucket=<bucket name> --only-verified

#Dateisystem
trufflehog filesystem --directory=/home/guenny/ansible/repository

Da die aktuellste Version momentan nur via Source/Docker zur Verfügung steht, können Gitlab, S3 und Co nur darüber gescannt werden

  git [<flags>] <uri>
    Find credentials in git repositories.

  github [<flags>]
    Find credentials in GitHub repositories.

  gitlab --token=TOKEN [<flags>]
    Find credentials in GitLab repositories.

  filesystem --directory=DIRECTORY
    Find credentials in a filesystem.

  s3 [<flags>]
    Find credentials in S3 buckets.

  syslog [<flags>]
    Scan syslog

trufflehog


Passwörter und andere Geheimnisse aus Git-Repositories entfernen

Was tun, wenn ein Passwort gefunden wurde?

Git Filter Branch bietet eine Möglichkeit, um dieses Problem zu beheben.

Beispielsweise:

git filter-branch --prune-empty --index-filter "git rm --cached -f --ignore-unmatch löschdatei" -- --all

Git Filter Branch ist ein sehr mächtiges Tool, daher verweist Github selbst auf den BFG Repo Cleaner und git filter-Repo

Mit ersterem lassen sich relativ einfach sensitive Dateien löschen oder ersetzen.

bfg --delete-files id_{dsa,rsa}  my-repo.git
bfg --replace-text passwords.txt  my-repo.git
git push --force

Wenn ein Passwort im letzten Commit vorhanden ist, würde übrigens auch amend ausreichen:

git commit --amend

Fazit

Vergessene Zugangsdaten in Repositorys schaffen unnötige Sicherheitslücken. Diese lassen sich mit TruffleHog einfach aufspüren. Das Tool unterstützt inzwischen weit mehr als nur Github. So lässt sich der gesamte Software Development Life Cycle/SDLC bei Bedarf überwachen.

Mit TruffleHog Enterprise bietet der Hersteller inzwischen eine GUI in der Cloud an, allerdings lässt er sich diese auch bezahlen. Für eine automatisierte Überwachung der eigenen Repositorys lassen sich alle Aufgaben via Kommandozeile erledigen.

Download



Ähnliche Artikel

Security Tools: Trivy – Docker Container auf Sicherheitslücken durchsuchen

Nuclei - schneller Schwachstellen Scanner mit praktischen Vorlagen

Security: GVM 21.04 - mit Docker in 15 Minuten zum OpenVAS Schwachstellen Scanner

❌
❌