Wydaje się, że exploit Cash-2014-6271 w shellshock Bash może być wykorzystywany przez sieć za pośrednictwem SSH. Mogę sobie wyobrazić, jak exploit działałby za pośrednictwem Apache / CGI, ale nie wyobrażam sobie, jak działałoby to w przypadku SSH?
Czy ktoś może podać przykład wykorzystania SSH i jaką szkodę może wyrządzić system?
WYJAŚNIENIE
AFAIU, tylko uwierzytelniony użytkownik może wykorzystać tę lukę poprzez SSH. Jakie zastosowanie ma ten exploit dla kogoś, kto i tak ma legalny dostęp do systemu? To znaczy, ten exploit nie ma eskalacji uprawnień (nie może stać się rootem), więc nie może zrobić nic więcej niż mógł po prostu zalogować się legalnie przez SSH.
bash
ssh
shellshock
Martin Vegter
źródło
źródło
Odpowiedzi:
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 nabash
, 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:
Tutaj konfigurujemy użytkownika
testuser
, który wymusza uruchomienie wszystkich połączeń ssh za pomocą twojego klucza sshecho starting sleep; sleep 1
.Możemy to przetestować za pomocą:
Zauważ, że nasz
echo something else
nie uruchamia się, alestarting sleep
pokazuje, że uruchomiono polecenie wymuszone.Teraz pokażmy, jak można wykorzystać ten exploit:
Działa to, ponieważ
sshd
ustawiaSSH_ORIGINAL_COMMAND
zmienną środowiskową na przekazane polecenie. Tak więc pomimosshd
uruchomieniasleep
, a nie polecenia, które mu powiedziałem, z powodu exploita mój kod wciąż działa.źródło
ssh testuser@localhost echo something else '`whoami`'
aby udowodnić, gdzie polecenie jest wykonywaneRozszerzając przykład z Ramesh - jeśli używasz uwierzytelniania dwuskładnikowego, możliwe jest ominięcie drugiego czynnika za pomocą tego exploita, w zależności od tego, jak jest on implementowany.
- Normalne logowanie -
- Uruchomiony kod bez 2FA -
Zauważysz, że uruchomił kod bez pytania o 2FA.
- Po załataniu basha -
źródło
read
funkcji. W przeciwnym razie - użytkownik jest bezpieczny.Shellshock to podatność na bash, a nie na SSH. Aby go wykorzystać, osoba atakująca musi spowodować uruchomienie przez podatny na atak systemu bash oraz kontrolę wartości zmiennej środowiskowej, która zostanie przekazana do bash.
Aby osiągnąć proces bash przez SSH, osoba atakująca musi przejść kroki uwierzytelnienia. (Wektory ataku mogą występować za pośrednictwem innych usług sieciowych, ale wykraczają one poza zakres tego wątku.) Jeśli mimo to konto może uruchamiać dowolne polecenia powłoki, atak nie jest wykonywany. Luka wchodzi w grę, jeśli konto jest ograniczone do uruchamiania określonych poleceń: na przykład konto tylko SFTP lub konto tylko git itp.
Istnieje kilka sposobów ograniczenia konta do uruchamiania określonej komendy za pomocą SSH: z
ForceCommand
opcją wsshd_config
lub zcommand=
. ograniczenie wauthorized_keys
pliku. Jeśli powłoka użytkownika jest bash, wówczas luka Shellshock pozwala użytkownikowi, który normalnie miałby dostęp tylko do konta z ograniczeniami, ominąć ograniczenie i wykonać dowolne polecenia.źródło
zsh
.