fajfer.org

Serwowanie stron z gita i bezpieczeństwo

Damian Fajfer — Thu, 19 Feb 2026 02:03:00 +0000

Przeczytałem kiedyś na Niebezpieczniku artykuł o wycieku w sklepie influencerki Wersow. Artykuł zainspirował mnie przede wszystkim do zainstalowania wtyczki DotGit, ale do tej pory nie udało mi się znaleźc niczego spektakularnie ciekawego. Ot, proste strony statyczne czy kod, który i tak jest publiczny. Do dziś wątpiłem, że ktoś na serio wrzuciłby kredki do gita na prywatne repozytorium a potem rzucał git pull do synchronizacji w tym samym repozytorium.

Wyprzedzając pytania - administrator został powiadomiony i wpis został umieszczony już po naprawieniu problemu.

Od .git/config do haseł

Serfując po internecie z wyżej wymienioną wtyczką dostaniemy popup o znalezionym repozytorium .git, adresy zbierają się też w samym narzędziu więc można co jakiś czas spojrzeć co udało się przypadkowo zebrać. Spróbujmy wyciągnąć z tego coś sensownego.



Poręczna funkcjonalność

Pobieramy repozytorium przez wtyczkę, wypakowujemy, przechodzimy do katalogu i możemy zobaczyć, że jest pusty. Po wpisaniu polecenia git status widać jednak jakie pliki są usunięte:

On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    .gitignore
        deleted:    .htaccess
        deleted:    .htpasswd
(...)

no changes added to commit (use "git add" and/or "git commit -a")

Git służy do przechowywania historii zmian. Poprzednie commity są w formacie binarnym, w najprostszy sposób możemy dotrzeć do nich używając polecenia git restore .

$ ls -a
.     .gitignore  admin     assets      cron         index.php   mediacacheAdv            modules     static
..    .htaccess   admin321  class       css          js          mediacacheArticle        resource    templates
.git  .htpasswd   ajax.php  config.php  imagick.php  mediaCache  mediacachePhotorelation  robots.txt  tmp

Jak widać powyżej, pliki się odtworzyły. Pomijając hasła wpisane na sztywno w skryptach. Możemy nawet udać na potrzeby edukacyjne, że ich nie było. Najbardziej zaciekawił mnie plik .htpasswd^[1]

Byłem ciekaw, czy uda mi się odgadnąć hasło do znalezionego użytkownika. Przykład jest zmyślony, ale ciąg zdarzeń analogiczny. Dla poniższego wpisu w .htpasswd:

admin:6YPqJe88Wz5fQ

Napisałem snippet w Pythonie i dopisałem kilka propozycji dla powyższego użytkownika, (chciałem chwilę później spróbować metodą słownikową) wyglądało to mniej więcej tak:

import crypt

passwords = ['admin', 'password', '123456', 'admin123']
hash = "6YPqJe88Wz5fQ"

for password in passwords:
    if crypt.crypt(password, hash) == hash:
        print(f"Password found: {password}")
        break
else:
    print("Password not found in common list")

Po uruchomieniu dostałem potwierdzenie:

$ python3 htpasswd.py 
Password found: admin123

Co stało się dalej?

Po moim zgłoszeniu część rzeczy została ukryta w taki sposób:

Tu się będę już czepiał, ale chcę pokazać dlaczego jawna wersja oprogramowania w komunikacie błędu daje atakującemu nadmierną ilość informacji. Powyższa wersja Apache2 wskazuje prawdopodobnie na Ubuntu 22.04 LTS (jammy). Dlaczego? Bo ostatnia najnowsza wersja z Ubuntu 20.04 LTS (focal) to 2.4.41^[2], natomiast w jammy już 2.4.52^[3]. Najnowszy commit również wskazywałby, że strona nie jest juz jakiś czas aktualizowana

Wnioski

Ogromna prośba, żeby nie trzymać w gicie jawnie haseł. To nie jest odpowiednie miejsce. Jak widać, nawet w przypadku korzystania z prywatnego repozytorium coś po drodze może pójść nie tak i hasła mogą wyciec.

https://pl.wikipedia.org/wiki/.htpasswd Dostęp 19.02.2026 ↩︎
https://launchpad.net/ubuntu/focal/+source/apache2 Dostęp 19.02.2026 ↩︎
https://packages.ubuntu.com/jammy/apache2 Dostęp 19.02.2026 ↩︎

Uruchamianie aplikacji Green Cell UPS (GCUPS) na serwerze GNU/Linux

Damian Fajfer — Sat, 16 Sep 2023 14:00:00 +0000

PRZETŁUMACZONE MASZYNOWO - OGÓLNIE TODO

Jeśli jesteś jedną z tych osób, prawdopodobnie też chcesz/potrzebujesz UPS-a. Ponieważ instalowałem skrzynkę teleinformatyczną, szukałem UPS-a do obsługi reszty mojego racka 11" i nie mogłem znaleźć niczego atrakcyjnego na lokalnym rynku od APC. Po pewnych poszukiwaniach zdałem sobie sprawę, że chciałbym mieć wymienną baterię, więc w trakcie nabyłem UPS Green Cell. Reklamowali dedykowane oprogramowanie, które do niego dołączają, ale nie miało to dla mnie znaczenia, dopóki nie odkryłem, że obsługuje kilka dystrybucji GNU/Linux.



Podoba mi się jak UPS Green Cell wygląda podobnie do EON-a z gry Original War

Aplikacja GC UPS

Na ich stronie pobierania (edycja: lub mój GitHub) oferują gcups (tak się nazywa) dla wszystkich nowoczesnych systemów desktopowych - Windows, MacOS i, co zaskakujące, wsparcie dla Linuxa w postaci .deb, .rpm, .pacman i .tar.gz (z kilkoma skryptami shell). Jest to całkiem solidny wybór wieloplatformowy, ponieważ używają Electrona działającego na Chromium. Najgorszą rzeczą jest to, że to oprogramowanie nie jest open source.

Ogólnie rzecz biorąc, wsparcie dla Linuxa przekonało mnie do wypróbowania. Nie zamierzam robić większej recenzji tego oprogramowania. Gdy przeprowadziłem kilka udanych testów przez webGUI, pomyślałem, że mogłoby być przydatne do uruchomienia, tylko nie na moim desktopie. Próbowałem uruchomić gcups z jakimiś parametrami, żeby go zdemonizować, ale bez powodzenia. W czasie pisania tego artykułu używam wersji 1.1.7 wydanej 02.06.2023. Uruchomienie gcups na moim serwerze dało mi następujący output:

$ gcups 
[371031:0915/014627.729749:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
[371031:0915/014627.729793:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.
Segmentation fault (core dumped)



Support odpowiadający mi, że nie ma sposobu na uruchomienie gcups bez GUI, udowodnijmy, że się mylą

Uruchamianie gcups w środowisku CLI

Szukanie informacji na temat uruchamiania gcups nigdzie mnie nie zaprowadziło (wersja 1.0.0 została opublikowana w czerwcu 2022), więc zacząłem majstrować. Nawet gdybym poszedł tak daleko (lub tak blisko) jak uruchomienie tego bez X serwera, nadal musiałbym włączyć serwer HTTP w ustawieniach aplikacji. Robiłem standardowe rzeczy, ale nie zauważyłem żadnych nowych procesów uruchamiających się po włączeniu serwera web, strings nie dał mi żadnego wnikliwego outputu niespecyficznego dla Chromium, nie mogłem też niczego znaleźć w ~/.config/gcups. Jest też katalog /opt/gcups tworzony podczas instalacji, więc ostatecznie zacząłem szukać w folderze db i - hurra - to było to miejsce.

/opt/gcups/db$ ls
gcups-rxdb-0-                                                           gcups-rxdb-0-scheduler-mrview-c37be66b94b0bdae91ef3fcbeab58edf
gcups-rxdb-0-device_parameters                                          gcups-rxdb-0-settings-local
gcups-rxdb-0-device_parameters-local                                    gcups-rxdb-0-test
gcups-rxdb-0-device_parameters-mrview-99560a34de60f5074dcd2be42069d585  gcups-rxdb-0-test-local
gcups-rxdb-0-register                                                   gcups-rxdb-0-test-measurement
gcups-rxdb-0-register-local                                             gcups-rxdb-0-test-measurement-local
gcups-rxdb-0-register-mrview-692a6698c32319395128b449dfae271e           gcups-rxdb-0-test-measurement-mrview-99560a34de60f5074dcd2be42069d585
gcups-rxdb-0-_rxdb_internal                                             gcups-rxdb-0-test-mrview-8b2440dfbb354345cc5c69a011a2beb9
gcups-rxdb-0-scheduler                                                  gcups-rxdb-0-test-mrview-8b851648c605dcf349b861f65fdffef5
gcups-rxdb-0-scheduler-local                                            gcups-rxdb-1-settings  <--- ten jest interesujący
gcups-rxdb-0-scheduler-mrview-2f6b156c4b77dd00407dbed941ee1abf          pouch__all_dbs__

Uzyskałem dostęp do bazy danych gcups-rxdb-1-settings używając LevelDB przez pythona:

import plyvel
db = plyvel.DB('/opt/gcups/db/gcups-rxdb-1-settings')

for key, value in db:
    print(f"{key.decode()}: {value.decode()}")

Co daje nam interesujący output:

ÿby-sequenceÿ0000000000000001: {"api":{"port":8080,"password":"hash hasła tutaj","enable":true,"salt":"sól hasła tutaj"},"_attachments":{},"_id":"a733f0a7-4fe2-4120-8603-775370fd871a","_rev":"12-c2e2e2d475614a9aed42806e63a38338"}

Rozbijając najciekawsze części:

port jest dość oczywisty, to po prostu port HTTP dla naszego serwera web
enable mówi nam, czy serwer HTTP jest domyślnie włączony przy uruchomieniu gcups

Odkryłem, że można po prostu zastąpić pierwszą i jedyną sekwencję, żeby gcups działał. Jest klucz (4ty od końca) o nazwie document-store, który przechowuje wszystkie revy poprzednich sekwencji oraz winningRev, ale w tym przypadku liczy się tylko wartość seq, która w większości przypadków jest twoją ostatnią by-sequence.

Generowanie własnej by-sequence

Teraz gdy wiemy jak uzyskać dostęp do ustawień gcups bez uruchamiania samego gcups, musimy zastąpić port (opcjonalnie), enabled, password i salt. Nie wiem jak wygenerować salt i password ręcznie, więc zalecam zainstalowanie gcups lokalnie, skonfigurowanie go, a następnie wyeksportowanie tego ustawienia na swój serwer. Pamiętaj, że nie możesz zmienić hasła z webGUI. Aby to zrobić, po prostu zainstaluj gcups lokalnie, ustaw hasło i włącz serwer HTTP w ustawieniach. Następnie przejdź do /opt/gcups/db/gcups-rxdb-1-settings i wykonaj PUT na swoich danych:

import plyvel
db = plyvel.DB('/opt/gcups/db/gcups-rxdb-1-settings')

db.put(b'\xc3\xbfby-sequence\xc3\xbf0000000000000001', b'{"api":{"port":8080,"password":"hash hasła tutaj","enable":true,"salt":"sól hasła tutaj"},"_attachments":{},"_id":"a733f0a7-4fe2-4120-8603-775370fd871a","_rev":"12-c2e2e2d475614a9aed42806e63a38338"}')

Nie musisz robić nic więcej. Naśladowałem xserver używając xvfb i pozwala to na uruchomienie gcups na serwerze w ten sposób:

xvfb-run gcups

Następnie możesz uzyskać dostęp do webGUI gcups na host:port na swoim serwerze, który określiłeś w by-sequence

Podsumowanie

Skontaktowałem się z supportem dwa razy, aby potwierdzić, że oprogramowanie nie ma działać bez GUI. Będzie czysto CLI-owe rozwiązanie dla gcups i jest ono na roadmapie Green Cell, ale nie wiadomo kiedy zostanie wydane, co sprawiło, że spędziłem jeden wieczór próbując uruchomić to w niezamierzony sposób.

Myślę o konteneryzacji kompletnego rozwiązania jeszcze w tym roku, zaktualizuję wpis na blogu później i dostarczę gotowy docker-compose z przekazaniem USB do kontenera (UPS łączy się przez USB z maszyną, żeby gcups był funkcjonalny). Fajnie byłoby też, gdybym nauczył się jak generować kombinację pass/salt dla gcups, bo nie poświęciłem temu zbyt wiele uwagi.

I last but not least - nie ma sensu, żeby takie oprogramowanie NIE było wolnym oprogramowaniem. Jedyną znaczącą rzeczą, którą by to ujawniło, byłby schemat komunikacji między oprogramowaniem a UPS-em. I co z tego? Każdy producent UPS-ów komunikuje się ze swoim UPS-em w inny sposób, ponieważ nie ma ogólnego protokołu określającego jak to powinno być zrobione. Nie sądzę, żeby to był wielki sekret i że ostatecznie nie mógłby zostać ujawniony przy odrobinie pracy. Nawet gdyby gcups był wolny i ludzie zdecydowali się używać rozwiązań nieopracowanych przez Green Cell, nadal byłoby to korzystne dla Green Cell, ponieważ z powodu różnych schematów komunikacji, te rozwiązania firm trzecich nadal obsługiwałyby tylko ich produkt.

Teraz gdy jest to closed source, moja praca skupiła się na obejściu wymagania xservera zamiast ulepszaniu ich produktu, a ich produkt nie istniałby, gdyby nie open source.

AKTUALIZACJA 03.04.2024

Hej! Zmotywowany komentarzami od Roberta udało mi się zdockeryzować powyższe rozwiązanie. Jest jeszcze trochę pracy, ale jestem gotów się jej podjąć i utrzymywać projekt.

https://github.com/fajfer/gcups

docker pull ghcr.io/fajfer/gcups:1.1.7

AKTUALIZACJA 19.08.2024

Ze względu na popularne zapotrzebowanie utworzyłem pokój czatowy Matrix, żebym mógł pomagać wam na zawołanie (lub trochę później) - https://matrix.to/#/#gcups:fsfe.org

Cykl życia sygnatur Cosign w Artifactory

Damian Fajfer — Sun, 23 Jul 2023 14:00:00 +0000

PRZETŁUMACZONE MASZYNOWO - OGÓLNIE TODO

Dodatkowo zagłębimy się w proponowane rozwiązanie kopiowania sygnatury do docelowego repozytorium podczas fazy promocji lub kopiowania artefaktów, odnosząc się do potencjalnych wyzwań w tym procesie.

Szczegóły dotyczące podpisywania i weryfikacji kontenerów docker nie będą omawiane w tym wpisie. Zostało to bardzo dobrze wyjaśnione w innych wpisach blogowych^[1], jak również w oficjalnej dokumentacji^[2]^[3]. Można śmiało powiedzieć, że działa to co najmniej od 2021 roku.

Praca z Artifactory

Przed przystąpieniem do podpisywania musimy uwierzytelnić się w rejestrze docker. Jako przykład w tym scenariuszu używam rejestru docker Artifactory^[4].

cosign login -u {{ username }} -p '{{ password }}' x.artifactory.com

Cosign może zwrócić błąd, jeśli podasz URL ze schematem:

Error: registries must be valid RFC 3986 URI authorities: https://x.artifactory.com
main.go:74: error during command execution: registries must be valid RFC 3986 URI authorities: https://x.artifactory.com

Rozwiązaniem jest po prostu pominięcie schematu (https:// w powyższym przykładzie).

Gdy cosign pomyślnie się zaloguje, zbuduj i wypchnij obraz jak zwykle. Następnie powinieneś podpisać swój obraz docker używając cosign sign. Jeśli do tego momentu wszystko zrobiłeś poprawnie, wykonanie cosign verify jako testu na tej samej maszynie da następujący wynik:

$ cosign verify --key cosign.pub x.artifactory.com/fajfer/image:example
The following checks were performed on these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}

Możesz powtórzyć polecenie na innej maszynie, aby zweryfikować, że sygnatura została pomyślnie przesłana. Wynik powinien być taki sam, a sygnatura powinna być widoczna w interfejsie webowym:

Więc jaki jest problem?

Zgodnie z dokumentacją:

Dokumentacja Cosign @ af555d5

Sygnatury są przechowywane jako osobne obiekty w rejestrze OCI, z jedynie słabym odniesieniem do obiektu, który "podpisują". Oznacza to, że ta relacja jest nieprzezroczysta dla rejestru, a sygnatury nie zostaną usunięte ani odśmiecone po usunięciu obrazu. Podobnie można je łatwo skopiować z jednego środowiska do drugiego, ale nie dzieje się to automatycznie.

Jeśli cykl życia twojego artefaktu kończy się tutaj, a obrazy stąd są wdrażane na produkcję lub są dostępne publicznie, to wszystko, skończyłeś. W przeciwnym razie, jeśli chcesz promować swoje obrazy lub skopiować je gdzieś indziej, zauważysz, że podczas gdy twoje artefakty są promowane do docelowego repozytorium, ich sygnatury pozostają nienaruszone w repozytorium źródłowym. Co oznacza, że jeśli zbudujesz i podpiszesz artefakty w repozytorium x, to po promocji do repozytorium y cosign da ci tę smutną odpowiedź:

$ cosign verify --key cosign.pub y.artifactory.com/fajfer/image:example
Error: no matching signatures:

main.go:52: error during command execution: no matching signatures:

Co jest nie tak, prawda? Przecież właśnie działało idealnie w starym repozytorium.

Proponowane rozwiązanie

Musimy skopiować sygnaturę do docelowego repozytorium. Po żądaniu REST API Promote Docker Image musimy wykonać żądanie Copy Item, aby skopiować sygnaturę. Jest tu ważny szczegół - cosign nazywa sygnaturę po SHA256 manifest.json naszego obrazu. Na szczęście możemy łatwo uzyskać dostęp do tych informacji wykonując żądanie File Info. Możemy również obliczyć to sami, ale zakładam, że nie masz już obrazu lokalnie podczas fazy promocji/kopiowania.

Aby lepiej zrozumieć rozwiązanie i uzyskać pojęcie o tym, jak powinny wyglądać twoje żądania, oto przykład w kodzie Ansible, który mógłby zostać użyty do implementacji rozwiązania w twoim systemie CI:

- name: Promote Docker Image
  # https://jfrog.com/help/r/jfrog-rest-apis/promote-docker-image
  uri:
    url: "{{ artifactory_url }}/api/docker/{{ source_repo }}/v2/promote"
    method: POST
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true
    body_format: json
    body:
      targetRepo: "{{ target_repo }}"
      dockerRepository: "{{ docker_repository }}"
      copy: true

- name: Get manifest.json (File Info)
  # https://jfrog.com/help/r/jfrog-rest-apis/file-info
  uri:
    url: "{{ artifactory_url }}/api/storage/{{ source_repo }}/\
      {{ file_path }}/{{ tag }}/manifest.json"
    method: GET
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true
  register: manifest

- name: Copy cosign signature (Copy Item)
  # https://jfrog.com/help/r/jfrog-rest-apis/copy-item
  uri:
    url: "{{ artifactory_url }}/api/copy/{{ source_repo }}/\
      {{ source_file_path }}/sha256-{{ manifest.json.checksums.sha256 }}.sig\
      ?to=/{{ target_repo }}/{{ target_file_path }}"
    method: POST
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true

To podejście najlepiej wykorzystuje API Artifactory i nie wymaga wcale pobierania obrazu i sygnatury lokalnie.

Podsumowanie

Wsparcie Cosign dla Artifactory jest bardzo dobrze zrealizowane, a Artifactory wie, że serwuje podpisane obrazy, ponieważ wysyła sygnaturę wraz z kontenerem po wykonaniu docker pull. API tego jednak nie odzwierciedla, ale miejmy nadzieję, że zmieni się to w przyszłości. Podpisywanie kontenerów staje się coraz bardziej popularne i dostępne dzięki narzędziom takim jak cosign, notary i kyverno, żeby wymienić tylko kilka, więc wykonywanie obejść takich jak to nie powinno być wymagane w przyszłości.

Jabar Asadi, "Digital Signature With Cosign" 4 maja 2023. https://eng.d2iq.com/blog/digital-signature-with-cosign/ Dostęp 22.07.2023 ↩︎
Sigstore, "Signing Containers" https://docs.sigstore.dev/cosign/signing_with_containers/ GitHub: 18b11e2 ↩︎
Sigstore, "Verifying" https://docs.sigstore.dev/cosign/verify GitHub: 4186c93 ↩︎
JFrog Artifactory Documentation, "Docker Registry" https://jfrog.com/help/r/jfrog-artifactory-documentation/docker-registry Dostęp: 23.07.2023 ↩︎

MOC - Mobilna Ogólnodostępna Czytelnia

Damian Fajfer — Tue, 20 Jun 2023 14:00:00 +0000

Niestety, nie pamiętam dokładnie wszystkiego tak, żeby to jakoś zgrabnie opisać, natomiast nam, tj. mi, ekipie wolontariuszy z oddziału w Grajewie wraz z panią Beatą Strzałkowską i jej Szkolnym Kołem Wolontariatu udało nam się spełnić następujące cele:

Wygospodarowanie w ZS2 przestrzeni na „miejsce stacjonowania” mobilnej czytelni, czyli adaptacja części biblioteki na kącik czytelniczy
Zaprojektowanie, wycena i wykonanie muralu nawiązującego do edukacji czytelniczo-medialnej oraz idei wolontariatu
Organizacja społecznej kampanii reklamowej dotyczącej dostępności MOBILNEJ CZYTELNI w ZS2 i/lub użyczenia jej do innych szkół, ośrodków kulturalno-wychowawczych, czy też w akcjach regionalnych promujących powiat grajewski oraz ideę wolontariatu
Poszerzenie księgozbioru biblioteki szkolnej o brakujące książki informatyczne

Aktualizację posta piszę po trzech latach, ale zawsze cieszy, że pomysł się spodobał a kącik czytelniczy nadal jest rozwijany i wykorzystywany.

Warsztaty Bezpiecznie z Żubrem

Damian Fajfer — Sat, 16 Oct 2021 14:00:00 +0000

Poniżej tekst z broszury o wolontariacie Wolontariat 2021 Banku Pekao S.A. "Wartość w pomaganiu":

Uczniowski Klub Sportowy „Strzelec” w Grajewie postawił sobie za cel, by pomóc nastolatkom w budowaniu asertywnych postaw, wzmocnić ich poczucie własnej wartości i nauczyć reagowania w sytuacji napaści fizycznej. Potrzebny był pomysł na to jak to zrobić i środki finansowe na realizację. Nieoceniona okazała się pomoc wolontariuszy z banku, których liderem był Damian Fajfer z bankowego Centrum IT.

Pomysł na organizację treningów Krav Magi oraz szkoleń o stosowaniu bezpieczeństwa w sieci zdobył dofinasowanie fundacji bankowej. Z czasem do grupy dołączały nowe osoby. To był strzał w dziesiątkę. Uczestniczki zajęć nauczyły się lepiej analizować otoczenie, dostrzegać zagrożenia. Nie tylko w świecie rzeczywistym, ale i wirtualnym. Wzmocniły swoją pewność siebie i nauczyły się nowych umiejętności.