Linux Privilege Escalation
시스템 정보
OS 정보
운영 중인 OS에 대한 지식을 얻기 시작합시다.
경로
만약 PATH
변수 내의 어떤 폴더에 쓰기 권한이 있다면, 일부 라이브러리 또는 이진 파일을 탈취할 수 있습니다:
환경 정보
환경 변수에 흥미로운 정보, 비밀번호 또는 API 키가 있나요?
커널 exploits
커널 버전을 확인하고 권한 상승에 사용할 수 있는 exploit이 있는지 확인합니다.
좋은 취약한 커널 목록과 이미 컴파일된 exploits을 다음에서 찾을 수 있습니다: https://github.com/lucyoa/kernel-exploits 및 exploitdb sploits. 일부 컴파일된 exploits을 찾을 수 있는 다른 사이트: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
해당 웹에서 모든 취약한 커널 버전을 추출하려면:
다음은 커널 exploits을 검색하는 데 도움이 될 수 있는 도구들입니다:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (피해자에서 실행, 커널 2.x용 exploits만 확인)
항상 Google에서 커널 버전을 검색하십시오. 아마도 커널 버전이 커널 exploit에 기재되어 있을 수 있으며, 이를 통해 해당 exploit이 유효한지 확인할 수 있습니다.
CVE-2016-5195 (DirtyCow)
Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8
Sudo 버전
취약한 sudo 버전을 기반으로 합니다:
다음 grep을 사용하여 sudo 버전이 취약한지 확인할 수 있습니다.
sudo < v1.28
@sickrov로부터
Dmesg 서명 확인 실패
이 취약점이 어떻게 악용될 수 있는지에 대한 예제로 HTB의 smasher2 상자를 확인하십시오
더 많은 시스템 열거
가능한 방어책 열거
AppArmor
Grsecurity
Grsecurity는 Linux 커널 보안 패치로, 특히 특권 상승 공격을 방지하는 데 도움이 됩니다.
PaX
Execshield
Execshield
SElinux
ASLR
ASLR(주소 공간 렌덤화)는 공격자가 악의적인 코드를 실행하기 위해 사용하는 메모리 주소를 예측하기 어렵게 만드는 보안 기술입니다.
Docker Breakout
만약 도커 컨테이너 안에 있다면 탈출을 시도할 수 있습니다:
드라이브
마운트된 것과 마운트되지 않은 것을 확인하고, 어디에 마운트되었는지 그리고 왜 마운트되었는지 확인하세요. 무언가가 마운트되지 않았다면 마운트를 시도하고 개인 정보를 확인할 수 있습니다.
유용한 소프트웨어
유용한 이진 파일을 나열합니다.
또한 설치된 컴파일러가 있는지 확인하십시오. 이는 커널 익스플로잇을 사용해야 할 때 유용합니다. 해당 머신에서 컴파일하는 것이 권장되므로 (또는 유사한 머신에서) 사용할 곳에서 컴파일하는 것이 좋습니다.
취약한 소프트웨어 설치 확인
설치된 패키지 및 서비스의 버전을 확인합니다. 혹시 권한 상승을 위해 악용될 수 있는 오래된 Nagios 버전과 같은 것이 있을 수도 있습니다... 의심스러운 소프트웨어의 버전은 수동으로 확인하는 것이 권장됩니다.
만약 머신에 SSH 액세스 권한이 있다면 openVAS를 사용하여 머신 내에 설치된 오래되고 취약한 소프트웨어를 확인할 수도 있습니다.
이 명령어들은 대부분 쓸모없는 많은 정보를 보여줄 수 있으므로, 알려진 취약점에 대해 설치된 소프트웨어 버전이 취약한지 확인할 수 있는 OpenVAS나 유사한 응용 프로그램을 권장합니다.
프로세스
어떤 프로세스가 실행되고 있는지 살펴보고, 어떤 프로세스가 그것이 가져야 할 이상한 권한을 가지고 있는지 확인해보세요 (어쩌면 root로 실행되는 톰캣이 있을 수도 있습니다).
항상 가능한 electron/cef/chromium 디버거가 실행 중인지 확인하십시오. 권한 상승을 위해 악용할 수 있습니다. Linpeas는 해당 프로세스의 명령줄 내부에 있는 --inspect
매개변수를 확인하여 이를 감지합니다.
또한 프로세스 이진 파일에 대한 권한을 확인하십시오. 다른 사용자의 것을 덮어쓸 수도 있습니다.
프로세스 모니터링
pspy와 같은 도구를 사용하여 프로세스를 모니터링할 수 있습니다. 이는 취약한 프로세스가 자주 실행되거나 일련의 요구 사항이 충족될 때 식별하는 데 매우 유용할 수 있습니다.
프로세스 메모리
일부 서버의 서비스는 메모리 내부에 평문으로 자격 증명을 저장합니다. 일반적으로 다른 사용자에 속한 프로세스의 메모리를 읽으려면 루트 권한이 필요합니다. 따라서 이미 루트 권한을 가지고 있고 더 많은 자격 증명을 발견하려는 경우에 더 유용합니다. 그러나 일반 사용자로서 소유한 프로세스의 메모리를 읽을 수 있다는 것을 기억하십시오.
요즘 대부분의 기계는 기본적으로 ptrace를 허용하지 않는다는 것을 유의하십시오. 이는 권한이 없는 사용자에 속한 다른 프로세스를 덤프할 수 없다는 것을 의미합니다.
파일 _/proc/sys/kernel/yama/ptrace_scope_는 ptrace의 접근성을 제어합니다:
kernel.yama.ptrace_scope = 0: 동일한 uid를 가진 모든 프로세스를 디버깅할 수 있습니다. 이것은 ptracing이 작동하는 고전적인 방법입니다.
kernel.yama.ptrace_scope = 1: 부모 프로세스만 디버깅할 수 있습니다.
kernel.yama.ptrace_scope = 2: 관리자만 ptrace를 사용할 수 있습니다. CAP_SYS_PTRACE 능력이 필요합니다.
kernel.yama.ptrace_scope = 3: ptrace로 추적할 수 있는 프로세스가 없습니다. 한 번 설정하면 다시 ptracing을 활성화하려면 재부팅이 필요합니다.
GDB
FTP 서비스의 메모리에 액세스할 수 있다면 (예:), 힙을 얻고 그 자격 증명을 검색할 수 있습니다.
GDB 스크립트
/proc/$pid/maps & /proc/$pid/mem
특정 프로세스 ID에 대해 맵은 해당 프로세스의 가상 주소 공간 내에서 메모리가 매핑되는 방식을 보여주며, 각 매핑된 영역의 권한을 보여줍니다. mem 가상 파일은 프로세스 메모리 자체를 노출합니다. maps 파일에서는 어떤 메모리 영역이 읽기 가능한지와 그 오프셋을 알 수 있습니다. 이 정보를 사용하여 mem 파일로 이동하고 모든 읽기 가능한 영역을 덤프하여 파일에 저장합니다.
/dev/mem
/dev/mem
은 시스템의 물리적 메모리에 액세스할 수 있으며 가상 메모리가 아닙니다. 커널의 가상 주소 공간은 /dev/kmem을 사용하여 액세스할 수 있습니다.
일반적으로 /dev/mem
은 오직 root와 kmem 그룹에게 읽기 권한만 허용됩니다.
ProcDump for linux
ProcDump은 Windows의 Sysinternals 도구 모음에서 영감을 받은 Linux 버전의 ProcDump 도구입니다. https://github.com/Sysinternals/ProcDump-for-Linux
도구
프로세스 메모리를 덤프하려면 다음을 사용할 수 있습니다:
https://github.com/hajzer/bash-memory-dump (루트) - _루트 요구 사항을 수동으로 제거하고 소유한 프로세스를 덤프할 수 있습니다
https://www.delaat.net/rp/2016-2017/p97/report.pdf의 스크립트 A.5 (루트 권한 필요)
프로세스 메모리에서 자격 증명
수동 예제
인증 프로세스가 실행 중인 것을 발견하면:
당신은 프로세스를 덤프할 수 있으며(다른 방법을 찾아 프로세스 메모리를 덤프하는 방법은 이전 섹션을 참조하세요) 메모리 내에서 자격 증명을 검색할 수 있습니다:
미미펭귄
도구 https://github.com/huntergregal/mimipenguin는 메모리에서 평문 자격 증명을 탈취하고 일부 잘 알려진 파일에서 가져옵니다. 올바르게 작동하려면 루트 권한이 필요합니다.
검색 정규식/truffleproc
예약/Cron 작업
예약된 작업 중 취약한 작업이 있는지 확인하십시오. 루트가 실행하는 스크립트를 악용할 수 있습니다 (와일드카드 취약성? 루트가 사용하는 파일을 수정할 수 있습니까? 심볼릭 링크를 사용할 수 있습니까? 루트가 사용하는 디렉토리에 특정 파일을 생성할 수 있습니까?).
크론 경로
예를 들어, /etc/crontab 내부에서 다음과 같은 경로를 찾을 수 있습니다: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
("user" 사용자가 /home/user에 대한 쓰기 권한을 가지고 있는지 주목하세요)
만약 이 crontab 내에서 root 사용자가 경로를 설정하지 않고 명령어나 스크립트를 실행하려고 한다면. 예를 들어: * * * * root overwrite.sh 그럼, 다음을 사용하여 root 쉘을 얻을 수 있습니다:
크론을 사용하여 와일드카드가 포함된 스크립트 실행 (와일드카드 인젝션)
루트에 의해 실행되는 스크립트에 명령어 내부에 "*"가 포함되어 있다면, 이를 악용하여 예상치 못한 일들(예를 들어 권한 상승)을 할 수 있습니다. 예시:
만약 와일드카드가 경로 앞에 오는 경우 /some/path/* 와 같이, 취약하지 않습니다 (심지어 ./* 도 아닙니다).
더 많은 와일드카드 악용 기법을 보려면 다음 페이지를 읽어보세요:
Cron 스크립트 덮어쓰기 및 심볼릭 링크
만약 루트가 실행하는 cron 스크립트를 수정할 수 있다면, 매우 쉽게 셸을 획들할 수 있습니다:
만약 root가 실행한 스크립트가 전체 액세스 권한이 있는 디렉토리를 사용한다면, 해당 폴더를 삭제하고 대신 다른 스크립트가 제어하는 심볼릭 링크 폴더를 생성하는 것이 유용할 수 있습니다.
빈번한 cron 작업
프로세스를 모니터링하여 1, 2 또는 5분마다 실행되는 프로세스를 검색할 수 있습니다. 이를 이용하여 권한 상승을 할 수도 있습니다.
예를 들어, 1분 동안 매 0.1초마다 모니터링하고, 덜 실행된 명령어순으로 정렬하여 가장 많이 실행된 명령어를 삭제하려면 다음을 수행할 수 있습니다:
또한 pspy 를 사용할 수 있습니다 (이것은 시작되는 모든 프로세스를 모니터링하고 나열할 것입니다).
보이지 않는 cron 작업
주석 뒤에 개행 문자를 넣는 cron 작업을 만들 수 있습니다 (개행 문자 없이). 예시 (개행 문자를 주목하세요):
서비스
쓰기 가능한 .service 파일
.service
파일을 쓸 수 있는지 확인하십시오. 가능하다면 서비스가 시작될 때, 다시 시작될 때 또는 중지될 때 백도어를 실행하도록 수정할 수 있습니다 (아마도 기기가 다시 부팅될 때까지 기다려야 할 수도 있습니다).
예를 들어 .service 파일 내에 백도어를 만들고 **ExecStart=/tmp/script.sh
**를 사용합니다.
쓰기 가능한 서비스 이진 파일
서비스에 의해 실행되는 이진 파일에 쓰기 권한이 있다면, 백도어로 변경하여 서비스가 다시 실행될 때 백도어가 실행될 수 있습니다.
systemd PATH - 상대 경로
systemd에서 사용되는 PATH를 확인할 수 있습니다:
만약 해당 경로의 어떤 폴더에 쓰기 권한이 있다면 권한 상승이 가능할 수 있습니다. 다음과 같은 상대 경로가 서비스 구성 파일에서 사용되는지 검색해야 합니다:
그럼, 실행 가능한 백도어가 실행될 시스템 PATH 폴더 내에 상대 경로 이진 파일과 동일한 이름을 가진 실행 파일을 생성하고, 서비스가 취약한 동작(시작, 중지, 다시로드)을 실행하도록 요청받으면(일반 사용자는 일반적으로 서비스를 시작/중지할 수 없지만 sudo -l
을 사용할 수 있는지 확인), 백도어가 실행될 것입니다.
**man systemd.service
**를 사용하여 서비스에 대해 더 자세히 알아보세요.
타이머
타이머는 이름이 **.timer**
로 끝나는 systemd 유닛 파일로, **.service**
파일이나 이벤트를 제어합니다. 타이머는 달력 시간 이벤트와 단조 시간 이벤트에 대한 내장 지원이 있어 cron 대신 사용할 수 있으며 비동기적으로 실행할 수 있습니다.
다음 명령을 사용하여 모든 타이머를 나열할 수 있습니다:
쓰기 가능한 타이머
타이머를 수정할 수 있다면 .service
또는 .target
와 같은 systemd.unit의 일부를 실행하도록 만들 수 있습니다.
문서에서 단위가 무엇인지 읽을 수 있습니다:
이 타이머가 경과할 때 활성화할 단위입니다. 인수는 ".timer"가 아닌 단위 이름입니다. 지정되지 않은 경우 이 값은 타이머 단위와 동일한 이름을 가진 서비스로 기본 설정됩니다. (위 참조) 활성화되는 단위 이름과 타이머 단위의 단위 이름이 접미사를 제외하고 동일하게 지정하는 것이 좋습니다.
따라서 이 권한을 남용하려면 다음을 수행해야 합니다:
쓰기 가능한 이진 파일을 실행하는 시스템디 단위(예:
.service
)를 찾습니다.상대 경로를 실행하는 시스템디 단위를 찾고 시스템디 경로에 대한 쓰기 권한이 있어야 합니다(해당 실행 파일을 흉내 내기 위해).
man systemd.timer
로 타이머에 대해 자세히 알아보세요.
타이머 활성화
타이머를 활성화하려면 루트 권한이 필요하며 다음을 실행해야 합니다:
타이머는 /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
에 심볼릭 링크를 생성하여 활성화됩니다.
소켓
유닉스 도메인 소켓(UDS)은 클라이언트-서버 모델 내에서 동일한 또는 다른 기기에서 프로세스 통신을 가능하게 합니다. 이들은 유닉스 기본 파일 기술자를 사용하여 컴퓨터 간 통신을 설정하며 .socket
파일을 통해 설정됩니다.
소켓은 .socket
파일을 사용하여 구성할 수 있습니다.
**man systemd.socket
**을 사용하여 소켓에 대해 자세히 알아보세요. 이 파일 안에는 여러 흥미로운 매개변수를 구성할 수 있습니다:
ListenStream
,ListenDatagram
,ListenSequentialPacket
,ListenFIFO
,ListenSpecial
,ListenNetlink
,ListenMessageQueue
,ListenUSBFunction
: 이러한 옵션들은 다르지만 어디에서 소켓을 듣을지를 나타내는 요약이 사용됩니다 (AF_UNIX 소켓 파일의 경로, 듣기 위한 IPv4/6 및/또는 포트 번호 등).Accept
: 부울 인수를 취합니다. true인 경우, 각 들어오는 연결에 대해 서비스 인스턴스가 생성되고 연결 소켓만 전달됩니다. false인 경우, 모든 듣기 소켓 자체가 시작된 서비스 유닠에 전달되며 모든 연결에 대해 하나의 서비스 유닛이 생성됩니다. 이 값은 데이터그램 소켓 및 FIFO에서는 무조건적으로 모든 들어오는 트래픽을 처리하는 단일 서비스 유닛이 생성됩니다. 기본값은 false입니다. 성능상의 이유로 새로운 데몬은Accept=no
에 적합한 방식으로만 작성하는 것이 권장됩니다.ExecStartPre
,ExecStartPost
: 각각 들어오는 소켓/FIFO가 생성되기 전 또는 후에 실행되는 하나 이상의 명령줄을 취합니다. 명령줄의 첫 번째 토큰은 절대 파일 이름이어야 하며, 그 다음에는 프로세스의 인수가 따라야 합니다.ExecStopPre
,ExecStopPost
: 추가로 들어오는 소켓/FIFO가 닫히고 제거된 후에 실행되는 명령어입니다.Service
: 들어오는 트래픽에 대해 활성화할 서비스 유닛 이름을 지정합니다. 이 설정은 Accept=no인 소켓에 대해서만 허용됩니다. 이 설정은 소켓과 동일한 이름을 가진 서비스를 기본값으로 사용합니다. 대부분의 경우 이 옵션을 사용할 필요가 없습니다.
쓰기 가능한 .socket 파일
쓰기 가능한 .socket
파일을 찾으면 [Socket]
섹션의 시작 부분에 다음과 같은 내용을 추가할 수 있습니다: ExecStartPre=/home/kali/sys/backdoor
그러면 소켓이 생성되기 전에 백도어가 실행됩니다. 따라서 아마도 기기가 다시 부팅될 때까지 기다려야 할 것입니다.
시스템이 해당 소켓 파일 구성을 사용하고 있어야만 백도어가 실행됨에 유의하십시오
쓰기 가능한 소켓
쓰기 가능한 소켓을 식별하면 (이제 우리는 구성 .socket
파일이 아닌 유닉스 소켓에 대해 이야기하고 있습니다), 해당 소켓과 통신하고 취약점을 이용할 수 있습니다.
유닉스 소켓 열거
원시 연결
악용 예시:
HTTP 소켓
주의할 점은 HTTP 요청을 수신 대기하는 소켓이 있을 수 있다는 것입니다 (저는 .socket 파일이 아닌 유닉스 소켓으로 작동하는 파일을 말하고 있습니다). 다음 명령어로 확인할 수 있습니다:
쓰기 가능한 도커 소켓
도커 소켓은 일반적으로 /var/run/docker.sock
경로에서 찾을 수 있으며 보안되어야 하는 중요한 파일입니다. 기본적으로 root
사용자와 docker
그룹의 구성원이 쓰기 권한을 갖습니다. 이 소켓에 쓰기 액세스 권한이 있으면 권한 상승이 발생할 수 있습니다. 이를 수행하는 방법과 도커 CLI를 사용할 수 없는 경우의 대체 방법에 대해 설명합니다.
도커 API 직접 사용
도커 CLI를 사용할 수 없는 경우에도 도커 소켓을 curl
명령어를 사용하여 조작할 수 있습니다.
도커 이미지 목록 보기: 사용 가능한 이미지 목록을 가져옵니다.
컨테이너 생성: 호스트 시스템의 루트 디렉토리를 마운트하는 컨테이너를 생성하는 요청을 보냅니다.
새로 생성된 컨테이너를 시작합니다:
컨테이너에 연결:
socat
을 사용하여 컨테이너에 연결을 설정하여 해당 컨테이너 내에서 명령을 실행할 수 있도록 합니다.
socat
연결을 설정한 후에는 호스트 파일 시스템에 대한 루트 수준 액세스로 컨테이너 내에서 명령을 직접 실행할 수 있습니다.
기타
도커 소켓에 대한 쓰기 권한이 있기 때문에 **docker
그룹 내부에 있을 경우 권한 상승을 위한 추가 방법이 있습니다. 도커 API가 포트에서 수신 대기 중인 경우 해당 API를 침해할 수도 있습니다.
도커를 탈출하거나 권한 상승을 위해 도커를 남용할 수 있는 더 많은 방법을 확인하려면:
Containerd (ctr) 권한 상승
ctr
명령어를 사용할 수 있다면 권한 상승을 위해 남용할 수도 있습니다. 다음 페이지를 읽어보세요:
RunC 권한 상승
runc
명령어를 사용할 수 있다면 권한 상승을 위해 남용할 수도 있습니다. 다음 페이지를 읽어보세요:
D-Bus
D-Bus는 응용 프로그램이 효율적으로 상호 작용하고 데이터를 공유할 수 있는 정교한 프로세스 간 통신 (IPC) 시스템입니다. 현대적인 리눅스 시스템을 고려하여 설계되었으며, 다양한 형태의 응용 프로그램 통신을 위한 견고한 프레임워크를 제공합니다.
이 시스템은 기본 IPC를 지원하여 프로세스 간 데이터 교환을 촉진하며, 향상된 UNIX 도메인 소켓과 유사한 방식으로 작동합니다. 또한 이벤트나 신호를 브로드캐스트하고 시스템 구성 요소 간의 원활한 통합을 촉진하여 사용자 경험을 향상시킵니다. 예를 들어, 블루투스 데몬에서 오는 전화 수신에 대한 신호는 음악 플레이어를 음소거하도록 유도하여 사용자 경험을 향상시킵니다. 또한 D-Bus는 원격 객체 시스템을 지원하여 응용 프로그램 간의 서비스 요청 및 메소드 호출을 간소화하여 기존에 복잡했던 프로세스를 간소화합니다.
D-Bus는 허용/거부 모델로 작동하여 일치하는 정책 규칙의 누적 효과에 따라 메시지 권한 (메소드 호출, 신호 발생 등)을 관리합니다. 이러한 권한의 악용을 통해 권한 상승이 가능할 수 있습니다.
/etc/dbus-1/system.d/wpa_supplicant.conf
에 있는 정책의 예시는 루트 사용자가 fi.w1.wpa_supplicant1
에게 소유권을 갖고 메시지를 보내고 받을 수 있는 권한을 상세히 설명합니다.
특정 사용자나 그룹이 지정되지 않은 정책은 보편적으로 적용되며, "default" 컨텍스트 정책은 다른 특정 정책에 포함되지 않은 모든 대상에 적용됩니다.
여기서 D-Bus 통신을 열거하고 악용하는 방법을 배우세요:
네트워크
기계의 위치를 파악하고 네트워크를 열거하는 것은 항상 흥미로운 작업입니다.
일반적인 열거
오픈 포트
접근하기 전에 상호 작용할 수 없었던 머신에서 실행 중인 네트워크 서비스를 항상 확인하십시오:
스니핑
트래픽을 스니핑할 수 있는지 확인하십시오. 그렇다면 일부 자격 증명을 획득할 수 있습니다.
사용자
일반적인 열거
누구인지, 어떤 권한을 가지고 있는지, 시스템에 어떤 사용자가 있는지, 누가 로그인할 수 있는지, 그리고 누가 루트 권한을 가지고 있는지 확인하세요:
큰 UID
일부 Linux 버전은 UID > INT_MAX를 가진 사용자가 권한 상승을 할 수 있는 버그에 영향을 받았습니다. 자세한 정보: 여기, 여기 및 여기.
**systemd-run -t /bin/bash
**를 사용하여 이를 악용하십시오.
그룹
루트 권한을 부여할 수 있는 어떤 그룹의 구성원인지 확인하십시오:
클립보드
클립보드 내에 흥미로운 내용이 있는지 확인하십시오 (가능한 경우)