U-44) root 이외의 UID가 '0' 금지

 

 

오늘 말씀드릴 리눅스 서버 취약점 점검 항목은 "root 이외의 UID가 '0' 금지"라는 항목입니다. 아무래도 리눅스 시스템의 권한 체계나 파일의 소유자에 대해 자세하게 공부하시 않으셨다면, 해당 제목만 보고 어떤 것을 점검하는 것인지 잘 와닿지 않으실 수 있는데요. 좀 더 명확한 점검 항목 제목은 "root 계정 이외의 User ID가 0이 아닌 계정 존재 유무 점검"이라고 해야지 조금 더 정확할 것 같습니다. 저번 글에서 말씀드린 /etc/passwd 파일 점검에 이어진 내용으로 보시면 될 것 같은데 먼저 취약점 개요에 대해 정리를 해보죠.

 

 

저번 점검 항목이었던 "U-04) 패스워드 파일 보호"에서 /etc/passwd의 구조를 설명드리면서, UID와 GID에 대해 짧게나마 말씀드린적이 있었죠. 다시 설명하면, UID(User Identification)는 사용자를 식별하는 번호, GID(Group Identification)는 사용자 계정이 포함된 그룹을 식별하는 번호입니다. cat 명령어를 통해 /etc/passwd 파일의 내용에서 세번째와 네번째 필드가 각각 UID와 GID라는 것을 볼 수 있는데요. GID는 추후 자세히 다루도록 하고, 일단 파일의 내용 맨 첫 라인에는 슈퍼 유저이자 관리자 계정인 root의 UID가 0으로 되어있는 것을 확인할 수 있습니다. 즉, UID가 0이면 모든 파일 시스템에 접근할 수 있고 파일의 내용을 수정할 수 있다는 말이 됩니다.

그러면 한 번 위와 같은 점검 항목의 결과가 취약으로 나왔을 때의 시나리오를 들어보도록 하죠. 어느 기업의 개발자가 집에서 서버에 접근할 수 있도록 개발 서버의 22번 포트를 열어두고, root 계정 접속을 차단하지 않았다고 가정합시다. 한 해커가 포트 스캐닝을 돌리다가 해당 서버의 22번 포트가 열린 것을 확인하고 SSH로 접속해서 Brute Force(무작위 대입) 공격을 통해 root 계정의 패스워드를 알아냈고, 이후 root 계정 접속이 막힐 것을 생각해서 별도의 계정을 만들고 UID를 0으로 수정하죠. 그럼 이후에는 해당 계정을 통해 자유롭게 개발 서버의 소스코드나 중요 정보들을 확인하거나 유출할 수 있게 됩니다.

물론 위에 든 예시는 어느 정도의 규모가 되는 기업이라면 현실적으로 존재할 수 없는, 구멍이 많은 가상의 시나리오 입니다. 외부에서 개발 서버를 접속할 때  VPN 연결 없이 다이렉트로 SSH를 통해 연결되었다는 점과 이전 "U-03) 계정 잠금 임계값 설정" 글에서 설명했던 것처럼 패스워드가 일정 횟수 이상 틀렸을 때 계정이 잠기지 않았다는 것도 말이죠. 또한 보안 솔루션이 설치되어 있었다면 무작위 대입 공격 시 이상 행위로 탐지되어 해당 IP 접속 자체가 차단되었을 겁니다. 하지만 항상 말씀드렸던 것처럼 의외로 당연히 되어 있어야할 보안이 잘 안된 경우가 많기 때문에 보안을 신경쓰지 않는 기업이라면 충분히 있을 법한 시나리오이기도 합니다.

일반 사용자 계정의 UID가 0이라면, 관리자 계정인 root와 동일한 접근 권한을 가지게 되기 때문에, 모든 파일을 볼 수 있고 수정할 수도 있습니다. 일반적으로 다른 사용자 계정이 생성되었을 때는 UID가 1000, 1001 이렇게 차례대로 부여가 되고, A라는 UID가 1000인 계정이 생성한 파일을 B라는 UID가 1001이라는 계정이 접근할 때는 파일의 권한과 UID를 확인해서 접근 통제를 하죠.

 

아직 리눅스의 퍼미션에 대해 자세히 설명드리진 않았지만 대강 이런 흐름으로 흘러간다는 것만 아시면, 해당 항목을 왜 점검하는지 이해하시는데는 큰 무리가 없을 것으로 생각됩니다. 그러면 마지막으로 해당 항목을 점검하는 방법과 취약으로 나왔을 때 어떻게 조치해야 하는지 말씀드리고 마치도록 하겠습니다.

 

root@kali:~# cat /etc/passwd | awk -F : '$3==0' | wc -l
1

 

지난번 글에서 awk에 대해 말씀드린 바 있기에 자세한 명령어 설명은 생략하도록 하고, /etc/passwd 파일을 읽어서 각 라인의 세번째 필드가 0인지 확인해서, root 계정 이외에 UID가 0인 계정이 존재한다면 결과가 2이상이 나오게 됩니다. 결과가 1이라면 root 계정만 UID가 0일 것이기에 점검 결과가 양호하고 2이상이라면 취약하다고 보는 겁니다.

 

만약 root 계정이 아닌 일반 계정의 UID가 0이면 해당 계정은 다른 UID로 변경하거나 계정 자체를 삭제해야하고, 사실 이러한 결과가 나왔다면 침해사고가 발생했다고 생각하셔도 되겠죠. 또한 UID를 변경할 때 usermod(User Modification) 명령어를 사용하셔도 되지만, 직접 /etc/passwd의 파일 내용을 수정하실 수 있는데요. 위에서 말씀드렸던 시나리오에서도 해커가 특정 계정의 UID를 0으로 변경할 때, /etc/passwd를 vim과 같은 에디터를 통해 0으로 수정했다고 보시면 됩니다.

그리고 여담으로 주통기 가이드가 2021년 버전으로 개정되면서 해당 항목의 순서가 5번째였던 것이 44번째로 바뀌었는데, 동일한 계정관리 항목으로 분류했으면서 해당 항목의 순서를 왜 뒤로 보냈는지는 의문입니다. 그래서 처음에는 점검 번호 순으로 글을 올릴까 했지만, 앞에서 부터 읽으시는 분들이 일관성을 가지고 볼 수 있도록 주통기 가이드에 나와있는 목차 순으로 쓰도록 하겠습니다. 그럼 오늘은 여기까지 설명하도록 하고 다음 글에서는 "root 계정 su 제한" 점검 항목에 대해 말씀드리도록 하죠. 읽어주셔서 감사합니다.