Command Injection – Wstrzykiwanie poleceń systemowych
🧨 Command Injection – Wstrzykiwanie poleceń systemowych
Command Injection to jedna z najbardziej krytycznych podatności aplikacji internetowych lub serwisów API, która pozwala atakującemu na wykonywanie poleceń powłoki (bash, cmd) bezpośrednio na serwerze. Błąd wynika zazwyczaj z niewłaściwego przetwarzania danych użytkownika w funkcjach wywołujących polecenia systemowe.
📌 Czym różni się Command Injection od Remote Code Execution (RCE)?
- Command Injection wykorzystuje istniejące procesy i polecenia systemowe.
- RCE może polegać na przesłaniu własnego kodu do wykonania (np. poprzez luki w parserach, interpreterach).
Mimo to, skutki obu ataków są równie poważne – pełne przejęcie serwera.
🔧 Przykład podatnego kodu (PHP)
$user = $_GET['user'];
system("ping -c 4 " . $user);
Żądanie atakującego:
http://example.com/ping.php?user=127.0.0.1; whoami
Efekty:
- Aplikacja wykona
ping 127.0.0.1 - Następnie wykona
whoami, co zwróci nazwę użytkownika serwera
💥 Typowe znaki wykorzystywane w ataku
;– oddzielenie poleceń&&– wykonaj następne polecenie tylko, jeśli poprzednie się powiedzie|– przekierowanie wyniku jednego polecenia do drugiego`– wykonanie polecenia i podstawienie jego wyniku$()– podobnie jak powyżej (w bash)
🛠️ Co można zrobić po udanym ataku?
- 📂 Przeglądanie i modyfikacja plików systemowych
- 📤 Eksfiltracja danych (np.
curl,wget) - 🔓 Tworzenie backdoora (np. reverse shell)
- 🛠️ Instalacja złośliwego oprogramowania
- 📡 Użycie serwera do kolejnych ataków (pivoting)
🔬 Narzędzia wykorzystywane do wykrywania i ataku
- Commix – automatyczne narzędzie do ataków Command Injection
- Burp Suite – do ręcznego testowania aplikacji i modyfikacji parametrów
- WFuzz / DirBuster – do wykrywania ukrytych endpointów, które mogą być podatne
- Metasploit – eksploitacja znanych podatności, np. reverse shell
🧪 Wariacje ataku
| Rodzaj | Opis |
|---|---|
| Blind Injection | Serwer nie zwraca wyniku polecenia, ale można go „wyczuć” (np. przez czas odpowiedzi). |
| Out-of-band (OOB) | Atakujący wysyła dane na własny serwer (np. DNS, HTTP), by uzyskać informacje zwrotne. |
| Argument Injection | Podatność na nieprawidłowe przekazywanie argumentów do polecenia (np. scp, rsync). |
🔐 Jak zabezpieczyć aplikację?
👨💻 Dla programistów:
- ❌ Nigdy nie łącz wejścia użytkownika bezpośrednio z poleceniami systemowymi
- ✅ Używaj bibliotek wysokiego poziomu zamiast
system(),exec(),shell_exec() - ✅ Stosuj whitelisting – tylko dozwolone wartości (np. IP, domeny)
- ✅ Escapuj dane (np. z
escapeshellarg()w PHP) - ✅ Używaj funkcji
subprocess.run()z parametrami jako listy w Pythonie
🧱 Na poziomie systemu:
- 🛡️ Ogranicz uprawnienia użytkownika serwera (np.
www-databez sudo) - 🔒 Używaj mechanizmów AppArmor/SELinux
- 🚧 Segmentuj sieć i nie dawaj serwerowi dostępu do wewnętrznych zasobów
- 📈 Monitoruj logi – nietypowe polecenia mogą świadczyć o ataku
🔎 Detekcja i forensics
- Sprawdzanie logów (syslog, apache/nginx, bash history)
- Monitorowanie nieautoryzowanych połączeń wychodzących
- Użycie EDR/SIEM do wykrywania nietypowego działania procesów (np.
ping,curl,nc,python)
🧠 Podsumowanie
Command Injection to jeden z najbardziej krytycznych i groźnych wektorów ataku, który niestety nadal występuje w praktyce. Nawet prosty formularz kontaktowy lub endpoint API może prowadzić do całkowitego przejęcia serwera. Edukacja programistów, testy bezpieczeństwa i ograniczenie powierzchni ataku są kluczowe w zapobieganiu.
🚨 Potencjalne zagrożenia związane z nowymi technologiami w kernelu Linuxa (np. io_uring, eBPF) 🔍 Wprowadzenie Kernel Linuxa nieustannie ewoluuje, dostarczając Czytaj dalej
Bezpieczeństwo aplikacji webowych — SQL Injection, XSS, CSRF, testy penetracyjne i DevSecOps Poniżej masz praktyczny i uporządkowany przewodnik po najważniejszych Czytaj dalej
