AppArmor
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor는 프로그램별 프로필을 통해 프로그램에 사용할 수 있는 리소스를 제한하도록 설계된 커널 향상 기능으로, 접근 제어 속성을 사용자 대신 프로그램에 직접 연결하여 강제 접근 제어(MAC)를 효과적으로 구현합니다. 이 시스템은 부팅 중에 프로필을 커널에 로드하여 작동하며, 이러한 프로필은 프로그램이 접근할 수 있는 리소스(예: 네트워크 연결, 원시 소켓 접근 및 파일 권한)를 규정합니다.
AppArmor 프로필에는 두 가지 운영 모드가 있습니다:
강제 모드: 이 모드는 프로필 내에서 정의된 정책을 적극적으로 시행하며, 이러한 정책을 위반하는 행동을 차단하고 syslog 또는 auditd와 같은 시스템을 통해 위반 시도를 기록합니다.
불만 모드: 강제 모드와 달리 불만 모드는 프로필의 정책에 반하는 행동을 차단하지 않습니다. 대신, 이러한 시도를 정책 위반으로 기록하지만 제한을 시행하지 않습니다.
커널 모듈: 정책 시행을 담당합니다.
정책: 프로그램 동작 및 리소스 접근에 대한 규칙과 제한을 지정합니다.
파서: 정책을 커널에 로드하여 시행 또는 보고합니다.
유틸리티: AppArmor와 상호작용하고 관리하기 위한 인터페이스를 제공하는 사용자 모드 프로그램입니다.
Apparmor 프로필은 일반적으로 _/etc/apparmor.d/_에 저장됩니다.
sudo aa-status
를 사용하면 일부 프로필에 의해 제한된 바이너리를 나열할 수 있습니다. 나열된 각 바이너리의 경로에서 문자 "/"를 점으로 변경하면 언급된 폴더 내의 apparmor 프로필 이름을 얻을 수 있습니다.
예를 들어, _/usr/bin/man_에 대한 apparmor 프로필은 _/etc/apparmor.d/usr.bin.man_에 위치합니다.
영향을 받는 실행 파일을 나타내기 위해 절대 경로와 와일드카드가 파일을 지정하는 데 허용됩니다.
바이너리가 파일에 대해 가질 접근을 나타내기 위해 다음 접근 제어를 사용할 수 있습니다:
r (읽기)
w (쓰기)
m (실행 가능한 메모리 맵)
k (파일 잠금)
l (하드 링크 생성)
ix (새 프로그램이 정책을 상속받아 다른 프로그램을 실행)
Px (환경을 정리한 후 다른 프로필에서 실행)
Cx (환경을 정리한 후 자식 프로필에서 실행)
Ux (환경을 정리한 후 제한 없이 실행)
변수는 프로필에서 정의할 수 있으며 프로필 외부에서 조작할 수 있습니다. 예: @{PROC} 및 @{HOME} (프로필 파일에 #include <tunables/global> 추가)
허용 규칙을 무시하기 위해 거부 규칙이 지원됩니다.
프로필 생성을 쉽게 시작하려면 apparmor가 도움이 될 수 있습니다. apparmor가 바이너리에 의해 수행된 작업을 검사하고 어떤 작업을 허용하거나 거부할지 결정할 수 있게 해줍니다. 단순히 다음을 실행하면 됩니다:
그런 다음, 다른 콘솔에서 바이너리가 일반적으로 수행할 모든 작업을 수행합니다:
그런 다음 첫 번째 콘솔에서 "s"를 누르고 기록된 작업에서 무시할지, 허용할지 또는 다른 작업을 선택합니다. 완료되면 "f"를 눌러 새 프로필이 _/etc/apparmor.d/path.to.binary_에 생성됩니다.
화살표 키를 사용하여 허용/거부/기타를 선택할 수 있습니다.
이진 파일의 apparmor 프로필 템플릿을 다음과 같이 생성할 수 있습니다:
기본적으로 생성된 프로필에서는 아무것도 허용되지 않으므로 모든 것이 거부됩니다. 예를 들어, 이진 파일이 /etc/passwd
를 읽을 수 있도록 /etc/passwd r,
와 같은 줄을 추가해야 합니다.
그런 다음 강제 적용할 수 있습니다.
다음 도구는 로그를 읽고 사용자가 감지된 금지된 작업 중 일부를 허용할 것인지 물어봅니다:
화살표 키를 사용하여 허용/거부/기타 원하는 항목을 선택할 수 있습니다.
예시 AUDIT 및 DENIED 로그는 실행 파일 **service_bin
**의 _/var/log/audit/audit.log_에서 가져온 것입니다:
이 정보를 다음을 사용하여 얻을 수도 있습니다:
docker의 프로필 docker-profile이 기본적으로 로드되는 방식을 주목하세요:
기본적으로 Apparmor docker-default 프로필은 https://github.com/moby/moby/tree/master/profiles/apparmor에서 생성됩니다.
docker-default 프로필 요약:
모든 네트워킹에 대한 접근
능력이 정의되어 있지 않음 (그러나 일부 능력은 기본 기본 규칙을 포함하여 올 수 있음, 즉 #include <abstractions/base>)
모든 /proc 파일에 대한 쓰기는 허용되지 않음
다른 하위 디렉토리/파일인 /proc 및 /sys에 대한 읽기/쓰기/잠금/링크/실행 접근이 거부됨
마운트는 허용되지 않음
Ptrace는 같은 apparmor 프로필에 의해 제한된 프로세스에서만 실행할 수 있음
docker 컨테이너를 실행하면 다음 출력을 볼 수 있어야 합니다:
Note that apparmor will even block capabilities privileges granted to the container by default. For example, it will be able to block permission to write inside /proc even if the SYS_ADMIN capability is granted because by default docker apparmor profile denies this access: apparmor는 기본적으로 컨테이너에 부여된 권한을 차단합니다. 예를 들어, SYS_ADMIN 권한이 부여되더라도 /proc 내부에 쓰기 권한을 차단할 수 있습니다. 이는 기본적으로 docker apparmor 프로파일이 이 접근을 거부하기 때문입니다:
You need to disable apparmor to bypass its restrictions: 당신은 그 제한을 우회하기 위해 apparmor를 비활성화해야 합니다:
기본적으로 AppArmor는 SYS_ADMIN 권한이 있어도 컨테이너가 내부에서 폴더를 마운트하는 것을 금지합니다.
컨테이너에 capabilities를 추가/제거할 수 있지만(여전히 AppArmor 및 Seccomp와 같은 보호 방법에 의해 제한됩니다):
--cap-add=SYS_ADMIN
SYS_ADMIN
권한 부여
--cap-add=ALL
모든 권한 부여
--cap-drop=ALL --cap-add=SYS_PTRACE
모든 권한 제거 후 SYS_PTRACE
만 부여
보통, docker 컨테이너 내부에서 privileged capability가 사용 가능하다는 것을 발견했지만 exploit의 일부가 작동하지 않는 경우, 이는 docker apparmor가 이를 방지하고 있기 때문입니다.
(예시는 여기에서 가져옴)
AppArmor 기능을 설명하기 위해, 다음 줄을 추가하여 새로운 Docker 프로필 “mydocker”를 생성했습니다:
프로필을 활성화하려면 다음을 수행해야 합니다:
프로필을 나열하려면 다음 명령을 실행할 수 있습니다. 아래 명령은 내 새로운 AppArmor 프로필을 나열하고 있습니다.
아래와 같이, AppArmor 프로필이 “/etc”에 대한 쓰기 접근을 방지하고 있기 때문에 “/etc/”를 변경하려고 할 때 오류가 발생합니다.
어떤 apparmor 프로파일이 컨테이너를 실행하고 있는지 확인하려면:
그런 다음, 다음 명령어를 실행하여 사용 중인 정확한 프로필을 찾을 수 있습니다:
In the weird case you can modify the apparmor docker profile and reload it. 당신은 제한을 제거하고 "우회"할 수 있습니다.
AppArmor는 경로 기반입니다. 이는 **/proc
**와 같은 디렉토리 내의 파일을 보호하고 있을지라도, 컨테이너가 어떻게 실행될지를 구성할 수 있다면, 호스트의 proc 디렉토리를 **/host/proc
**에 마운트할 수 있으며, 그러면 더 이상 AppArmor에 의해 보호되지 않습니다.
이 버그에서 특정 리소스와 함께 perl의 실행을 방지하고 있다 하더라도, 첫 번째 줄에 **#!/usr/bin/perl
**을 지정한 셸 스크립트를 생성하고 파일을 직접 실행하면, 원하는 것을 실행할 수 있는 예를 볼 수 있습니다. 예:
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)