Securing Odoo After Terminating a Developer: A Post-Incident Security Checklist

Współpracujemy z różnymi osobami oraz firmami. Nadajemy im dostępy do systemów, na których muszą pracować, między innymi do Odoo. Współpraca układa się dobrze, freelancer rozwiązuje taski, tworzy konta nowym użytkownikom, wprowadza nowe funkcjonalności. Ale któregoś dnia, z jakiegoś powodu chcesz zmienić osobę, z którą współpracujesz. Jako że współpraca układała się dobrze, wymieniacie podziękowania. Archiwizujesz konto tego użytkownika, a po jakimś czasie w Twoim Odoo zaczynają się dziać dziwne rzeczy...

Uwaga na takie sytuacje, bo zdarzają się częściej niż się wydaje. A kiedy dojdzie do takiego ataku, którego źródłem jest osoba, z którą współpracowałeś, jest to podwójnie niebezpieczne i... cóż, odbiera dużą porcję zaufania do ludzi. Bo przecież dobrze się współpracowało, developer był zawsze miły, "dzień dobry mówił na spotkaniu".

Ale co dalej? W jaki sposób zareagować na taki incydent? Co sprawdzić w Odoo? Przecież Odoo to jest oprogramowanie, w którym możemy zdefiniować sobie funkcje automatyczne wraz z wywoływalnym kodem. Potencjalne pułapki, które zostawił po sobie nasz dawny kolega, mogą być wszędzie.

W moim przypadku, sytuacja działa się w Odoo, które hostowane było na odoo.sh — bardzo popularnym systemie PaaS. Sytuacja, z którą się spotkałem, nie miała związku z zaawansowanymi metodami ataku. To był po prostu zwykły developer, który (prawdopodobnie) poczuł się urażony tym, że ktoś zdecydował się nie kontynuować współpracy. I ukrył w systemie różne metody autoryzacji, za pomocą których sprawiał, że normalna praca w Odoo stała się niemożliwa.

Odkrycie takiego ataku to duże zaskoczenie. Liczy się czas. Pytanie więc jak skutecznie odebrać wszystkie uprawnienia? Na moje zaskoczenie, na stronie Odoo nie było jednej listy, która wskazywałaby co zrobić w tym przypadku. Wsparcie techniczne również okazało się dość "spokojne". Postanowiłem się więc podzielić tą listą tutaj, na blogu. Mam nadzieję, że nie czytasz tego po tym jak odkryłeś, że ktoś zaatakował Cię w ten sposób.

Odoo.sh

Usuń użytkowników GitHub, którzy nie powinni mieć dostępu

• Remove any GitHub users who should no longer have access to your repository.

Usuń klucze SSH (skonfigurowane w projekcie)

• Jeśli złośliwy użytkownik miał dostęp do konta GH — wejdź na stronę główną Odoo.sh, kliknij profil (prawy górny róg) → Profil i usuń wszystkie klucze SSH

Usuń Deploy Keys

Odoo

Parametry systemowe

• database.secret — utwórz nową wartość parametru (wylogowuje wszystkie aktywne sesje)
• Przejrzyj całą listę parametrów i zdecyduj, które wymagają rotacji

Klucze API

• Usuń klucze API (Ustawienia → Klucze API)

Użytkownicy

• Zarchiwizuj złośliwych użytkowników oraz tych, których nie rozpoznajesz
• Zresetuj hasła
• Włącz 2FA (zresetuj, jeśli były konfigurowane przez atakującego)
• Sprawdź listę użytkowników pod kątem nieznanych kont
• Sprawdź dostawców OAuth — jeśli istnieje jakiś samodzielnie utworzony, usuń go

Dostawcy Logowania

• Sprawdź pod kątem nieautoryzowanych dostawców OAuth oraz LDAP

Zaplanowane akcje (Scheduled Actions)

• Przejrzyj każdą z nich, sprawdź konfigurację — szczególnie co dokładnie robi. Przeczytaj i zrozum kod. (u mnie tutaj była "bomba z opóźnionym zapłonem", która miała dużo rzeczy usunąć, a potem po sobie posprzątać)

Akcje automatyczne (Automated Actions)

• Przejrzyj każdą z nich, sprawdź konfigurację — szczególnie akcje typu „Execute Code"
• Usuń każdą, która wygląda podejrzanie

Akcje serwerowe (Server Actions)

• Przejrzyj każdą z nich — sprawdź, czy nie zawiera podejrzanych elementów

Widoki

• Sprawdź niestandardowe widoki pod kątem podejrzanego kodu

Płatności

• Rotacja wszystkich kluczy

Metody wysyłki

• Zaktualizuj wszystkie dane logowania (również dla nieaktywnych kont — są używane w backendzie)

Serwery e-mail

• Przejrzyj konfiguracje serwerów pocztowych (przychodząca i wychodząca)

Jeżeli potrzebujesz pomocy — skontaktuj się ze mną!