C

zasami użytkownicy systemów stacjonarnych wychodzą z błędnego założenia, że jeśli dla kluczowych plików (typu: .bashrc, .bash_profile, .profile) w swoim katalogu domowym zmienią właściciela na administratora (root) – będzie to znaczne utrudnienie dla atakującego, aby zmusić użytkownika do uruchomienia szkodliwego skryptu lub pliku, a tym samym osiągnąć eskalację uprawnień na systemie. Nic bardziej mylnego. Należy pamiętać, że jeśli nasz użytkownik posiada prawa zapisu do katalogu, w którym znajdują się pliki nie z jego prawami to nadal może je usunąć:

agresor@darkstar:~$ ls -la
total 36
drwxr-xr-x 5 agresor agresor 4096 Jun 14 21:09 .
drwxr-xr-x 3 root    root    4096 Dec  1  2019 ..
-rw------- 1 agresor agresor 2214 Jun 14 20:59 .bash_history
-rw-r--r-- 1 root    root     220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 root    root    3771 Apr  4  2018 .bashrc
drwx------ 2 agresor agresor 4096 Dec  1  2019 .cache
drwx------ 3 agresor agresor 4096 Dec  1  2019 .gnupg
drwxrwxr-x 3 agresor agresor 4096 Dec  6  2019 .local
-rw-r--r-- 1 agresor agresor  807 Apr  4  2018 .profile
-rw-r--r-- 1 agresor agresor    0 Dec  1  2019 .sudo_as_admin_successful
agresor@darkstar:~$ chmod 777 .bashrc
chmod: changing permissions of '.bashrc': Operation not permitted
agresor@darkstar:~$ echo "# Malware code" >> .bashrc
-bash: .bashrc: Permission denied
agresor@darkstar:~$ cat .bashrc > /tmp/foo && rm -f .bashrc && cat /tmp/foo > .bashrc
agresor@darkstar:~$ echo "# Malware code" >> .bashrc
agresor@darkstar:~$ tail -1 .bashrc
# Malware code

Dlatego jeśli dojdzie do sytuacji, w której dana aplikacja pozwoli na wykonanie polecenia na systemie – ochrona plików poprzez zmianę ich właściciela będzie nieskuteczna – ze względu na możliwość ich usunięcia i odtworzenia pierwotnego właścicielstwa. W celu umożliwienia takiego “zabezpieczenia” należy zmienić właściciela katalogu $HOME na konto administratora oraz nadanie bezpiecznego atrybutu tekstu (ang. save-text attribute / sticky bit) na ten katalog – ale taki ruch może mieć jeszcze gorsze konsekwencje niż pozostawienie standardowych uprawnień. Bardziej rozsądnym rozwiązaniem, które nie bazuje na prawach dostępu – jest nałożenie (chattr +i .bashrc) atrybutu niezmienności (ang. immutable) na w/w pliki z poziomu administratora.

J

akiś czas temu na Hacker News pojawił się artykuł próbujący udowodnić, że uruchamianie daemona SSH na innym porcie niż 22 (Opcja: Port w /etc/ssh/sshd_config) to zły pomysł. Czy na pewno? Autor głównie skupił się w swoich wywodach na argumencie security by obscurity, co jest ulubionym ryżym śledziem ludzi, którzy prawie rozumieją to zagadnienie.
[ czytaj całość… ]