엄마보고싶다(1) - 전초전(feat.linux_permission)

Intr0

어느 더운 여름날이었다…

내가 까만 돛을 단 원양어선에 승선을 제의 받은 것은…

날씨가 너무너무 핵! 더우니까…

배를 타고 바다를 항해하며 시원한 바람을 만끽하는 것도 괜찮겠다 싶었고…

그때는………………………

그리고 나는 덜컥 그 배에 올라타고 말았다………..!

으아…

역시 인생은 뜻대로 되지 않는 것…ㅋㅋㅋㅋㅋㅋㅋ

배에 탄 뒤로 시원한 바람은커녕 따스한 햇빛조차 만날 수 없었다.

매일매일이 폭풍우 몰아치는 고난의 연속이여따…. OTL…..

뭐지.. 이제 어떻게 되는 거지…?

띠로리띠로리로리로리로리로리뢰로

.

.

.

그렇게 며칠째 갑판 위를 방황하고 있는데, 등 뒤로 검은 그림자가 드리워졌다.

나 : (화들짝 뒤돌아본다)

? : 자네가 새로 들어온 선원인가

나 : 예 그렇사옵니다만

? : 나는 이 배의 선장일세

나 : !!!!!!!!!!!

선장님 : 자네가 무척 심심해 보이는 것 같아 얘기나 나눠볼까 왔네 허허허

자네 Command Injection이라고 아나?

.

.

.

그렇게 선장님은 Command Injection에 대해 한참 동안 신나게 썰을 풀어놓으셨당..

그리고 말씀하셨다………….

선장님 : 이게 바로 자네가 앞으로 해야 할 일이야.(흐흐흐)

쉽지 않은 여정이겠지만 어디엔가는 끝이 있을 걸세.(과연) 행운을 비네.(껄껄껄)

나 : 어버버버버버어어어어…어어어어어….선장님…??!!

띠로리이이이이이…….이이?

우르르르르르콰과과과과가강(청천벽력)

내가 간신히 정신줄을 잡고 일어났을 때 선장님은 또 홀연히 사라지고 없으셨다….

….? 어떡하지

나 어떡???

그냥 선장님이 먼나라 얘기하시는 줄 알고 고개만 끄덕끄덕 열심히 하면서 맞장구 쳐드린 건데…

너무 열심히 리액셔어어어어언해서 옳다구나 나한테 맡기신 건 아니겠지 으앙

하나도 기억 안나는데에에에에에에에!!…..털썩…………

큰일났다…

이렇게 된 거 뭐라도 해야지 어째…. 또륵……하…..

Command Injection 탐험기, <엄마보고싶다> 지금 시작합니다하하핳!!

※ 주의 : 위 내용은 재미(과연 재미있…?)를 위해 일부 각색되었음을 알려드립니다(524님이 라노벨이냐며 극!혐! 하셨지만 꿋꿋함ㅋㅋ)

Command Injection이 뭘까요?

먼저 Command Injection??! 이 뭔지 알아야 되겠죠??!

저는 제일 처음으로 Owasp 페이지를 참고 해 보았습니다! ㅎㅎㅎ

Command Injection(커맨드 인젝션)을 단어 그대로 해석하면 “명령어를 삽입한다” 입니다.

간단히 말하면! 원래는 command1만 실행해야되는데 command2도 실행되게끔!

command2를 요래조래 삽입!해주는 것이죠! ㅎㅎㅎ (요래조래!?가 어떤 건지는 이제 부터 차근차근 알아갈 거니까 성급 노노해 ㅎㅎ)

◎ 그럼 우리가 어디에 command2를 끼워넣을 수 있을까요??

자 그걸 이제부터 우리가 함께 고민해보는 겁니다 ㅎㅎㅎㅎ

우선! 내가 무언가 입력할 수 있는 부분이 있나 봐야돼요.

그리고 내 명령을 어~떻~게~ 끼워넣을 수 있~을~까~ 막 고민하는 거죠 ㅎㅎ….

하지만 프로그램이 사용자로부터 입력값을 받는다고 무조건 내 명령을 막 전달할 수 있는 건 아닙니다!!

우리가 공략할 수 있는 취!약!점!이 존재해야겠죠!?!!!

◎ 어떤 취약점을 말하는 건가요??

Command Injection을 가능하게 하는 대표적인 요인은 프로그램이 사용자의 입력값을 제대로 검사! 판단! 차단! 하지 않는 것입니다.

프로그램이 사용자의 데이터(예를 들면 시스템 명령어에 전달하는 인자값! 혹은 서버에 전달하는 HTTP 헤더 등…)를 받아가서

시스템 쉘에 넘기는 동작을 할 때 그 데이터가 유효한지, 정상적인지 제대로 검사하지 않고!!

시스템 쉘에 전달하게 되면 취약점이 발생합니다!!

◎ 유효하지 않은, 정상적이지 않은 입력값에는 어떤 것들이 있나요?

기본적으로 해당 프로그램이 의도하는 것과는 다른 내용의 데이터를 입력하면 유효하지 않다, 정상적이지 않다라고 할 수 있겠죠!

예를 들면 내가 입력값으로 파일이름을 입력하면 그 파일을 읽어주는

(cat 명령어를 실행) 프로그램인데…….. 파일 이름과 함께 새로운 명령(root 권한의 쉘을 열어라! [/bin/sh] 등)을 덧붙여서

명령을 추가적으로 내린다면 그게 바로 정상적이지 않은 입력인 것입니다.

아 그리고 /bin/sh이 권한을 획득하는 명령이 아니더라도….

rm -rf / 명령을 추가적으로 실행하도록 입력값을 조작한다고 칩시다…. ㄷㄷ

그 프로그램을 제공하는 시스템 자체를 모두 날려버리는 어마어마한 행동이 되는거에요.

그러니까! 미리당부하면! 이렇게 의도치 않은, 시스템에 피해를 끼칠 수 있는 명령이 실행되지 않도록!

입력값을 잘 검사하고 필터링해야!! 악의적인 Command Injection 공격을 막을 수 있다는 겁니다!

즉, 정리하면 Command Injection이란 시스템에 입력값이 정상적인지 제대로 검사하지 않는 취약점이 존재할 때!

사용자가 의도하는 명령을 삽입하여 실행시키는 공격입니다!

하지만…. 말로만 들으니까 제가 아무리 친절히 설명하려고 해도 딱! 와 닿지가 않으시죠?

그래서 Command Injection의 간단한 예를 하나 보여 드릴게요! 직접 해봅시다!!

맛보기니까 가볍게 봐주시길!

Command Injection에 취약한 핵 간단한 프로그램을 만들었습니다. (테스트 환경 - Ubuntu 14.04.3)

> $ vi command_injection.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void main( char* argc, char** argv ){
   char cmd[60] = "/bin/ls ";
   strcat(cmd, argv[1]);
   system(cmd);
}

사용자로부터 입력값을 받은 후, 해당 입력값을 /bin/ls 명령어의 인자로 넘겨주는 프로그램입니다! system( ) 함수 뙇 보이구요~

> $ ls -al 

이 파일에 SetUID 설정된 것을 확인할 수 있습니다!

SetUID 가 뭔지, 왜 SetUID가 설정돼있어야 하는지는 차차 알아보도록 해요! ㅎㅎ

그리고 ";/bin/sh" 을 인자값으로 command_injection 파일을 실행하면???!

> $ ./command_injection “;/bin/sh”

마지막 줄에 영롱한 # 보이시죠?? root 권한의 쉘을 땄네요!

id 명령어로 확인해보면!?

> # id

euid가 root!!가 된 것을 알 수 있습니다! 즉 root 권한이 유지된 상태로 다른 행동도 할 수 있게 된 것이죠.

EUID는 Effective User ID로, 쉘 상에서 사용자를 변경하면 적용되는 UID입니다.

EGID(Group’s)도 마찬가지!! 처음 로그인을 했을 때는 UID와 EUID가 동일합니다.

SetUID 설정 등을 통해 사용자 권한이 임시로 바뀌었을 때 EUID가 재설정되는 것이죠!

뭐가 뭔지 아직은 잘 모르겠지만 그래도 마지막에 #!! root!!의 쉘을 딴 걸 보니 설렙니다

왜 저렇게 하는 건지, 어째서 저런 일이 일어나는지 궁금한 것이 천지지만… 잠시 접어둡시다

하나씩 하나씩 찬찬히 가다 보면 어느새 저기에 도달하게 될테니까요! ㅎㅎ

※ Command Injection은 리눅스의 터미널 환경에서 뿐만 아니라
웹 상에서 오고가는 입력값을 조작하는 등,여러가지 환경에서 이루어질 수 있습니다.
하지만 본 글은 우선 리눅스 터미널 환경에서 이루어지는 Command Injection을 중심으로 설명함을 알려드립니다 :)

[기초 탄탄] File Permission이 뭔가요?

본격 Command Injection을 파헤치기 전에 아주아주 기초부터 짚어볼까요.

리눅스에서의 ‘File Permission(파일 권한) 알기’ 부터 시작 해 볼까 합니다!

자, 먼저 리눅스의 특징인 멀티유저 시스템에 대해서 말해볼까요?

전반적인 내용은 여기를 참고했습니다 :)

멀티유저 시스템이라는 건 여러 사용자가 동시에 하나의 컴퓨터 시스템을 이용하는 것을 말합니다.

예를 들어 어떤 컴퓨터가 네트워크나 인터넷에 연결 되어 있으면,

여러 사용자들이 ssh(secure shell)접속을 통해 원격으로 컴퓨터를 함께 이용할 수 있다는 것이죠!

리눅스의 이러한 멀티유저 기능은 운영체제 설계에서부터 깊이 뿌리 박혀있습니다.

컴퓨터가 개인적인 용도로 상용화되기 이전, 리눅스가 만들어질 때 즈음에는

비싸고 큰 본체 컴퓨터 하나를 중심에 두고 여러 개의 터미널을 여기에 연결해서 쓰는 방식이 주를 이루었습니다.

그래서 여러 사용자가 하나의 컴퓨터를 동시에 사용하는 ‘멀티유저’ 시스템을 기본적으로 운영체제 설계에 반영했던 것이죠!! 아항!!

그리고 이 때 멀티유저 시스템을 실용적이고 안전하게 쓰려면

그 여러 사용자들이 서로 침범하지 못하게 보호해야 하는 게 필수!!!

즉 어느 사용자가 컴퓨터 시스템을 망가뜨려서도 안되고, 다른 사용자의 작업 환경을 들쑤셔도 안되게 막아야 하는 거당!!

…… 이 길고 긴 이야기를 왜 했냐….하면!!?

이게 바로 리눅스 시스템이 파일마다 Permission을 두는 이유이기 때문입니다 ㅎㅎㅎ

. . .

그럼 ls -l 명령어를 통해file_permission 이라는 이름을 가진 파일의 권한 정보를 확인해봅시다.

> $ ls -al file_permission1 

여기서 첫 번째 열에 나타나는 정보가 바로 File Permission입니다!!

그럼 첫 번째 열의 각각의 글자가 어떤 의미를 갖는지 깊이 파봅시다 삽삽!

(1) File Permission 표현법

File Permission을 나타내는 주요 부분인 파란 박스를 먼저 봅니다.

딱 봐도 세 부분으로 이루어져 있죠? 각 부분을 구성하는 요소는 같기 때문에 한 부분만 알면 셋 다 아는 거에요 어예~

File Permission은 클래스 별로 각기 부여되고, 클래스는 총 3개-User / Group / Others-가 있습니다.

User는 Owner! 파일의 소유주입니다.

Group은 Group! 그룹 멤버들을 말합니다.

Others는 Other users on system! 그 외 다른 모든 사용자들입니다.

그럼 각 클래스의 권한을 구성하는 요소를 알아봅시다!!!

클래스 별로 각각 Permission 정보가 따로 정해지는데, 이를 세 개의 문자로 표현합니다.

r이 표시돼있어야 read할 수 있고 w이 있어야 write할 수 있는 건데

r/w/x 대신에 -이 적혀있으면 해당 권한은 ‘없다’는 뜻!!입니다.

예를 들어 --x 면 read /write는 못하고 execute만 할 수 있다는 거니까!

여기서 User는 r/w/x 모두 할 수 있고, Group과 Others는 x(execute)만 할 수 있다는 뜻입니다! 호옹이~

그런데… 파일이냐 디렉터리냐에 따라서 r/w/x 로 할 수 있는 일의 의미가 약간 다릅니다!

직관적으로 그냥 본능적으로 난 알겠어!! 하는 사람은 안 봐도 됩니다….

그치만 저는 오 신기! 이렇게 다른 거구나 깨달을 수 있어서… 재밌었어영 ㅋㅋ 그냥 한 번 읽고 지나가 보세요 ㅎㅎ

‘File’에서는 이렇게 해석합니다

• r : 열어서 내용을 읽을 수 있다.
• w : 열어서 내용을 읽고 수정할 수 있다.
• x : 파일을 실행시킬 수 있다.

반면! ‘Directory’에서는 이렇게 해석합니다

(기본적으로 x(execute) 권한이 있어야 디렉터리에 들어가서 r이나 w를 할 수 있는 듯!!)

• r : 디렉터리에 무엇이 담겼는지(파일이나 디렉터리 등) 볼 수 있다.
• w : 디렉터리 내에서 파일을 추가/제거 하거나 혹은 디렉터리 간에 파일을 이동할 수 있다.
• x : 디렉터리에 들어가서 작업을 수행할 수 있다.

자 이제 파란 박스를 다 구경했으니 노란 박스를 구경해봅니다.

노란 박스 부분은 파일의 종류를 나타냅니다.

• - : 는 가장 흔히 볼 수 있는 파일 종류로 ‘일반 파일’!! 을 말합니다.

• d :는 디렉터리!! 우리가 윈도우 시스템에서 흔히 ‘폴더’라고 말하는 것입니다.

• l : 은 symbolic link로 연결된 파일을 말합니다.

우리가 작업을 하면서 자주 볼 수 있는 파일 종류는 이 세가지 정도라고 말할 수 있어요.

p, s, c, b 등의 더 많은 파일 종류가 있는데 여기서는 그런게 있구나~ 정도 알고, 그때그때 나올 때마다 알아보기로 해요 ㅎㅎㅎ

그래도 나는 더 상세한 설명을 읽어보고 싶다~하면 여기 위키를 참고하시길 바라영!! 다만 영어라는 거….ㅎㅎㅎㅎㅎ 화이팅!

(2) File Permission 수정하기 - chmod

이제!!! File Permission에 대해 어느 정도 알게 된 거 같은데….!

Permission을 수정할 수는 없나??? 하는 생각이 듭니다.

others는 못 보게 꼭 싸매고 있던 파일을.. 이제는 자비를 베풀어 같이 볼 수 있게 권한 설정을 바꾸고 싶을 수 도 있쟈나!!

그래서 우리에게 필요한 건….!!!??

바로바로 드디어 인사합니다.

안녕 chmod??? ㅋㅋㅋㅋㅋ (볼드모트 사촌같당 ;;; 아… 저는 저걸 크모드라고 읽어서 그런가봐요 ㅋㅋ)

chmod 명령어를 이용하면 우리가 방금 배운 Permission(r/w/x)을 수정할 수 있게 되는 거에용!!! 신난다!

이름부터 느껴집니다. 나는 ch(ange)할 거야아아아아앙!! mod(e)르으으으으을!!!!

그렇습니다. chmod 명령어는 -rwx--x--x 요렇게 생긴 permission 부분을 바꿔주는 중요한 아이에요.

chmod --help 라는 명령어로 기본적인 정보를 얻어봅시다.

> $ chmod –help

< chmod 명령어 Option >

옵션을 먼저 볼까요?

여기서 자주 사용하게 된다는 R / f / v 옵션을 한번 볼게요 ㅎㅎ

• R (recursive) : change files and directories recursively

chmod를 하는 대상이 디렉터리일 경우 그 안에 있는 파일이나 디렉터리까지 모두 권한을 바꿉니다!! 와우!

• f (force) : suppress most error messages

에러가 일어나더라도 강제로 밀고 나갑니다!! ㄷㄷ

• v (verbose) : output a diagnostic for every file processed

권한 설정을 수행한 내용을 다 알려줍니다! 친절한 것~ 근데 또 장황한(verbose) 것이지…ㅎㅎ

그 밖의 원하는 옵션을 적절히 사용해주면 됩니다!

R 옵션은 뭔가 잘 쓰면 진짜 편리하겠네요 ㅎㅎ

v 옵션은 어떤 식으로 결과를 알려주는지 궁금해서 직접 한번 테스트를 해봤어요.

> $ ls -l file_permission3

이러했던 파일에… v 옵션을 추가해 chmod를 써보면??!

> $ chmod -v 777 file_permission3

요로코롬 되네요 ㅎㅎㅎㅎ 친절한 것~

<chmod 명령어 Usage >

chmod의 옵션을 살펴봤으니 이제 Usage를 볼까요? 어머 세 개나 돼요!!

이 중 세 번째를 먼저보면…

chmod [OPTION]… –reference=RFILE FILE…

FILE의 권한을 RFILE의 권한과 똑같게 바꿔주는 방법입니다!

필요한 옵션은 앞에다 추가해주면 되고~ 오옹 이것도 새로 알게 됐는데 재밌네요 ㅎㅎㅎ

그럼 우리가 실제로 많이많이 써먹을 두 가지 Usage를 알아봅시다!

chmod [OPTION]… [OCTAL-MODE] [FILE]… (Octal modes)

chmod [OPTION]… [MODE]… [FILE]… (Symbolic modes)

이건 chmod만의 표현법을 알아둬야 써먹을 수 있으니 집중!! ㅎㅎㅎ

하지만 이것만 봐서는 뭐가 뭔지 잘 모르겠으니 쉽게 예시를 들어볼게요~

chmod 664 somefile (Octal modes)

chmod g+w somefile (Symbolic modes)

같은 명령어에 이렇게나 다른 표현 방식이 있다니! 쫌 싄기…ㅎㅎㅎㅎ

< Octal Modes >

Octal modes 부터 차근차근 알아보아욥!

Let’s Learn OctalOctal…….옥털이당… 옥의 털?? ㅋㅋㅋㅋㅋㅋ (나만 재밋옹 ㅋㅋㅋ)

이름에서부터 8진법 느낌이 폴폴 ㅎㅎㅎ

위에서도 봤듯이

> $ chmod 664 somefile

요로코롬 중간에 숫자가 세 개(네 개 들어갈 수도 있는데 이건 좀 이따가 ㅋㅋ 우선은 기본부터 알기로 해요 ㅎㅎ) 들어가는데 왜 세 개일까요???

그야~ 우리가 아까 잘~ 배운 대로! File Permission는 세 개의 클래스(user/group/others)별로 부여되기 때문입니다!!

즉 클래스 당 숫자 하나!! 즉 숫자 각각이 user/group/ohters의 permission을 나타냅니다.

이제 그 숫자의 의미가 뭔지 알러 ㄱㄱㄱㄱ

(Octal modes니까 8진법이라서 0부터 7까지 8개의 숫자만 쓰일 거라는 게 예상 가능합니다 ㅎㅎㅎ)

우선 제가 보기 쉬우라고 표를 만들었어요 후후후후후후훟 이것도 다 설명 드릴게요 ㅎㅎ

여기서 포인트는 첫 번째 열의 rwx형태를 세 번째 열의 Octal number로 변환하는 것입니다.

그 변환 과정을 논리적으로 이해하기 위해서 둔 게 바로 두 번째 열이에요!

세 자리의 이진수가 있다고 하면

첫 번째(가장 왼쪽) 자리는 r, 두 번째 자리는 w, 세 번째 자리는 x의 자리인 거죠!!!

그래서 r이 있으면 1이고, r이 없으면(-) 0으로 표시합니다 호호ㅎㅎ

w랑 x도 마찬가지!

어렵지 않은 거니까 차근차근 이해하면서 따라오세요 ㅎㅎㅎ

그럼 rwx를 세자리 이진수로 나타낼 수 있게 되었습니다.

이제 끝난거졍 ㅎㅎㅎㅎㅎㅎㅎㅎ

세 번째 열처럼 이 이진수를 Octal number로 바꿔주면 땡이니까요 ㅎㅎㅎㅎ

자 이렇게 우리는 rwx를 Octal number로 바꿀 수 있게 되었습니다. 하하하하하핳

네 번째 열은 rwx에 따른 권한을 설명해뒀어요 ㅎㅎ

아까 말로만 설명했는데 눈으로 하나씩 보니까 훨씬 더 이해가 잘 되죠? :)

자 이제 그럼 chmod 명령어의 Octal modes를 이용해서 권한을 설정하는 연습을 해봅시다.

somefile에 rwxr-x--x의 권한을 주고 싶다면 어떻게 명령을 내려야 할까요??

우선 해석하면, user(owner)에게 rwx, group에게 r-x, others에게 --x의 권한을 주는 거네요~

그럼 user에게 줘야 할 Octal number는 뭐다?? 7(111=4+2+1=7)!!!!! 굳굳입니다

group에게는?? 5(101=4+0+1)!!!! others에게는?? 1(x뿐이니까)!!!

합치면?? 751~ 합칠 땐 이렇게 user-group-others순으로 샤샤샥 빠르게 합쳐주면 돼요 ㅎㅎㅎ

$ chmod 751 somefile

완성이네요~ ㅎㅎㅎㅎㅎ

chmod octal modes 마스터!!! ㅎㅎㅎ 익숙해지려면 좀 더 연습해야겠지만 알 건 다 안 것 같습니당 ㅎㅎ

< Symbolic Modes >

Octal 마스터했으니깐 이제 Symbolic 정복하러 가볼까용

저는 처음 chmod 배울 때 Octal만 배워가지고… Symbolic 있는 줄 나중에야 알았다는… ㅋㅋ

흠 Symbolic 알게 된 제가 정리해 본다면…

Octal은 한번에 싹 설정하기에 좋은 거 같고 Symbolic 은 하나하나 수정할 때, 조금씩 바꿀 때 유용할 것 같습니돵 (안써본 자의 그저 예측)

낯설지만 이제 친해질 거에요 ㅎㅎ

chmod g+w somefile (Symbolic modes)

아까 보여드렸던 Symbolic modes의 예시입니다!!

정규 표현으로 보여드리면 이런 형태입니다.

chmod [class][operator][modes] FILE…

여기서 [class], [operator], [modes] 부분에 어떤 값이 들어갈 수 있는지 살펴봐용!

먼저 [class]입니다.

user / group / others 에서 첫 글자를 따서 u / g / o 로 사용합니다.

a는 셋 다에게 적용하고 싶을 때 쓰면 되겠죠? 즉 a는 ugo라고 쓰는 것과 같은 거죠 헿!

u / g / o 를 꼭 하나씩 쓸 필요는 없어요!! 필요한 만큼 가져다 쓰세요 훅훅 ㅎㅎ

요러코롬?!!! ㅎㅎ

> $ chmod ug+rx somefile

다음은 [operator]입니다.

operator는 + / - / = 세 종류가 있습니다.

우리가 정한 [class]에게 우리가 정한 [modes]를 추가할 건지(+) 제거할 건지(-) 결정합니다!

=는 우리가 정한 권한대로 딱 설정해주는 거에요! 뭐가 다른지 모르겠죠? ㅎㅎ

+는 기존에 없던 권한을 ‘추가’할 때 쓰는 거고, -는 기존에 있던 권한을 ‘제거’할 때 쓰는데

=는 그냥 딱 내가 지금 정해주는 대로 싹 바꿔! 라는 겁니다 우오오 칼이쓰마 ㅎㅎㅎ Octal modes가 하는 방식이랑 느낌이 비슷하네요!

예를 들어서,  r--r--r-- 라는 권한을 가진 chmod_operator라는 파일이 있습니다!

여기에 chmod ug=rw chmod_operator 라는 명령을 내리면???! rw-rw-r-- 로 권한이 바뀌는 거에요!

u(ser)와 g(roup)의 권한은 r과 w이다!!라고 딱!!! 정해준 거니까 r--이 rw-로 바뀐 것이죠 이히힣 좋네요 재미있다 ㅎㅎㅎㅎ

[class]와 [operator]를 배웠으니 마지막!!! [modes]입니다.

modes는 어떠한 권한모드를 수정할 것인지 정합니다.

r / w / x 는 자꾸자꾸 보던 거라 이제 익숙하시죵

chmod a+rwx somefile

이런 명령을 내리면 u / g / o 모두에게 r / w / x 모든 권한을 다 추가하라는 뜻이 되는 겁니다 하하핳

그으러언데에에에에! r / w / x 말고 다른 신기한 녀석들이 있습니다.

바로 s!!와 t!! 사실 이건 파일의 ‘속성’이라고 할 수 있는데,

많은 사람들이 ‘권한’, ‘모드’라는 표현을 혼용해서 사용합니다. 이 아이들은 좀 스페샬해요!

그래서 얘들은 chmod 끝나고 (와 언제 끝나나 chmod만 한 시간째; 거의 끝나가요 좀만 참아요 후흡후흡),

chown, chgrp 설명까지 끝내고 나서!! 단독으로 파헤쳐보기로 해요!

으아으아으아 이로써 chmod 명령어의 Symbolic Modes까지 모두 끝마쳤어요…

이제 좀 알 것 같죠? :)

< chmod 실습하기 >

그럼 실제로 chmod 명령어를 사용하는 연습을 한 다음, chmod를 마무리 짓도록 해요 으어 빨리! ㅎㅎ

우선 실습 대상은 rw-rw-r--의 권한을 가진 chmod_example 파일입니다.

먼저 Octal modes를 이용해보아요

1. User : r / Group : w / Others : x 으로 권한을 바꿔보자!

r=4 / w=2 / x=1 !! 그럼 421 !! chmod 421 chmod_example 이라고 명령을 내리면 되겠습니다!

> $ chmod 421 chmod_example

2. User : rwx / Group : rw / Others : r 으로 권한을 바꿔보자!

rwx=4+2+1 / rw=4+2 / r=4 !! 그럼 764 !! chmod 764 chmod_example 이라고 명령을 내리면 되겠습니다!

> $ chmod 764 chmod_example

다음은 Symbolic modes를 이용해보아요 하핳

현재 chmod_example의 권한은 rwx rw- r– 상태입니다.

1. User와 Group에서 w(write)와 x(execute) 권한을 제거해 보자!

즉 u와 g에서 w와 x를 제거(-)하면 되겠습니다!

> $ chmod ug-wx chmod_example

2. Group과 Others에 w(write) 권한을 추가해 보자!

즉 g와 o에 w를 추가(+)하면 되겠습니다!

> $ chmod go+w chmod_example

우와우와 이제 좀 실감이??! 잘 따라오셨죠? ㅎㅎ

으어… 이제야 chmod가 끝났어요…. 명령어 하난데 핵길고길었다…. ㅎ

자아 힘들긴 하지만 쉬지 말고 빠르게 달려서 끝내볼까요? ㅎㅎㅎ

(3) File Permission에서 User와 Group 수정하기 - chown / chgrp

chmod 정복했으니 이제 chown & chgrp !!

chown : change ownership !!

chgrp : change group ownership!!

chmod가 파일의 권한을 설정해주는 녀석이었다면 chown, chgrp 얘들은 파일의 소유자, 소유그룹을 설정해줍니다 ㅎㅎ

그런데.. 잠시 짚고 넘어가야 할 것이 있었으니…!

ownership과 group ownership을 수정할 수 있는 건 Root!! Superuser!! 뿐이라는 겁니다.

아하!! chmod처럼 읽고 쓰고 실행하는 권한을 바꾸는 거보다

소유자 자체를 바꾸는 게 훨씬 통큰 일이라 그런가봐요 호호홓

(보안의 특성상 chown이랑 chgrp은 Superuser만 쓸 수 있는 걸로!! ㅎㅎㅎ )

< su / sudo 가 필요해!!>

그래애서! chown과 chgrp 을 쓰기 전 root 권한을 얻기 위해서 su / sudo 명령어를 이용합니다.

su : substitute user

sudo : substitute user do

su와 sudo를 이용하면 일시적으로 root의 권한을 얻을 수 있습니다.

root가 아닌 다른 사용자로 전환하는 것도 가능하고 다시 본래 사용자로 돌아오는 것도 당연 가능!!

두 명령어의 가장 큰 차이는 su를 쓸 때는 root의 비밀번호를 입력해야 하고,

sudo를 쓸 때는 현재 사용자의 비밀번호를 입력하면 된다는 것입니다.

그래서 보안의 측면에서 볼 때, su는 root 계정의 비밀번호를 공유해야 하므로 sudo에 없는 보안상의 약점을 가지고 있다고 할 수 있습니다.

(sudo에서도 경우에 따라서는 root의 비밀번호를 입력해야 할 수 있다고 합니다! 하지만 우리가 흔히 사용할 때는 필요 ㄴㄴ해! )

그런데 sudo는 왜 사용자의 비밀번호만 입력해도 root 권한을 주지? 더 위험한 거 아닌가? 생각할 수 도 있습니다.

댓츠 논노~ 그리 허술하게 해뒀을 리가 있겠습니까 ㅎㅎ

sudo 명령어는 ‘누가 어떤 일을 할 때’에 한해서 root 권한을 하사하겠다! 하고 /etc/sudoers 파일에 기록된 유저만 사용할 수 있습니다!

sudoers 파일은 root가 소유한 파일이고 우리가 함부로 건들 수 없지요 ㅎㅎ

그래서 sudo [some_command] 형식으로 명령을 전달한 후 사용자 비밀번호를 입력하면 sudoers 파일을 검색해서

‘이 사용자가 some_command를 실행하게 해줘라’는 말이 있을 때만 권한을 주는 것이다! 아항! 이해가 가시죠? ㅎㅎㅎㅎㅎ

흔히 sudo [some_command] 형식으로 사용하기 때문에 이걸 알려드린 거구…

sudo에 command를 입력하지 않고 사용하는 방법도 있어요…

그래서 sudo를 난 더 깊이깊이 알고 싶어!! 하시는 분은 위키와 sudo –help 명령을 참고하시길 바랍니다~하핳

보안 얘기하다가 sudo 설명을 거의 다 했네요 ㅎㅎㅎ

직접 써볼까요?

여기에 sudo_test라는 root소유의 파일이 있습니다.

root소유니까 함부로 삭제할 수 없어요! 그래서 우리는 sudo 명령어를 이용해 파일을 삭제해봅시다! (rm : 삭제 명령어)

$ sudo rm sudo_test

root 비밀번호가 아닌, 현재 사용자인 ‘nyoung’의 비밀번호를 요구합니다

비밀번호가 맞다면? 지워지겠죠!  ls -l 로 보려고 하니까 없는 파일이라고 하네요! ㅎㅎㅎ

(제가 작업한 환경에서는 sudo 를 통해 사용할 수 있는 명령에 거의 제한이 없기 때문에!!

sudo rm 이 가능했던 것이고… 만약 Superuser가 sudoers 파일을 수정해서 권한을 막아뒀다면 rm도 쓸 수 없을 겁니다!)

정리하면!! sudo 명령어는 흔히 sudo [some_command] 형태로 쓸 수 있고,

sudo로 실행할 수 있는 명령어에는 제한이 있어서 내 마음대로 할 수 있는 게 아니다~ 하는 겁니다 ㅎㅎ

자 그럼 root의 비밀번호를 내가 알고 있는 경우엔?! su 명령어를 사용해봅시다!

su를 입력하면 root 비밀번호를 내놓으라고 합니당. 비밀번호 모르면… 이렇게 fail! root 권한 안 줘요 ㅠㅠ

내놓으면 이렇게 root의 쉘을 저에게 척! 투척해줍니다 굳굳

현재 작업 디렉터리에서 그대로 root의 권한으로만 바뀌었습니다.

만약 root의 쉘을 땄을 때 현재 작업 디렉터리가 아닌 root의 기본 작업 디렉터리에서 열고 싶으면 su - 라고 입력할 수 있습니다.

> $ su -

이렇게 su 명령어를 사용하면 아예 root권한의 쉘을 얻는 거기 때문에 sudo 처럼 [some_command]를 같이 입력하지 않아도 돼요 ㅎㅎ

root 쉘 얻고 나서 뭐든 다 하면 되는 걸~ ㅎㅎㅎ

su 명령어에도 command를 같이 넘겨주는 방법이 있습니다.

저는 지금 chown/chgrp 을 위한 su/sudo 의 기본적인 사용법을 알려드리고 넘어갈 거라서 모~두 설명해드릴 수 가 없으니!!

궁금하신 분은 su --help 명령어를 이용해 주세요~ ㅎㅎㅎㅎㅎ :D

< chown / chgrp 실습하기 >

요래요래~ Superuser 되는 법도 배웠겠다~ chown / chgrp 드뎌 들어갑니다 진짜진짜!

chown과 chgrp 명령은 파일의 소유자와 소유그룹을 바꾸는 역할을 합니다!

chown : change ownership !!

chgrp : change group ownership!!

파일의 소유자와 소유그룹은 ls -l 명령으로 확인할 수 있습니다.

주황색 칸이 소유자!! 파란색 칸이 소유그룹!! 입니다.

그럼 chown/chgrp 명령으로 file_permission 파일의 소유자와 소유그룹을 root로 바꿔봅시다.

chown!!! 실패!!

chgrp!!! 실패!!

오잉? 뭐가 문제??? 후훟 제가 chown / chgrp 배우기 전에 강조한 그거! Superuser 권한을 잊었네요~

아무리 본래 소유자이더라도 일반 사용자인 nyoung의 권한으로는 할 수 없는 일입니다.

그럼 sudo 써서 chown 해봅니다!

성공~ 소유자가 root로 바뀐 게 보이죠?

chgrp은 su를 써서 해봅니다ㅎㅎ

거뜬히 성공~ 우와 소유자와 소유그룹이 모두 root로 바뀌었네요 ㅎㅎㅎ 뿌듯!!

그리고 하나 더! 꿀팁!!

소유주와 소유그룹을 다시 둘 다 nyoung으로 바꾸고 싶은데… chown과 chgrp을 한번에 하고 싶다!! 하면??!

요로코롬 chown [소유자이름].[소유그룹이름] [대상파일] 형태로 입력하시면 됩니다! 우왕 간단한 것!

으아으아으아 드디어 ch형제들을 끝냈습니다! 반가웠어 잠시 안녕! 다음에 또만나요! ㅎㅎ

그럼 이제 우리 뭐해야 할까요?? ㅎㅎㅎ 다 끝난 건가? 아 그랬으면 좋겠다 ㅎㅎㅎ

하나가 딱 남았어요! 우리 아까 하나 또 이따 배우기로 하고 뚱쳐놓은거 있잖아요 ㅎㅎ

Symbolic modes 배울 때 mode 종류에 있었던 s!! t!!! 스페샬!! ㅎㅎㅎㅎㅎㅎㅎ 기억나죠?

(4) Special!! Permission - SetUID / SetGID / Sticky bit

바로 SetUID /SetGID / Sticky bit 입니다!!

이거는 음… 좀 특별한 Permission modes라고 생각하시면 돼요 ㅎㅎ

chmod의 Octal modes를 배울 때 “숫자옵션에 네 개를 줄 수도 있는데 좀 이따가 배워요”라고 했던 거 기억나시나요? ㅎㅎㅎ

기본 숫자옵션 세 개에 추가되는 맨 앞의 한자리가!! 바로 SetUID/ SetGID/ Sticky bit를 설정하는 bit에요! ㅎㅎㅎ

네 자리 숫자 옵션부터 먼저 소개하고 하나하나 설명 드릴게요 ㅎㅎ

우리가 rwx를 r(4) / w(2) / x(1) 로 정하고 부여된 권한의 숫자를 더해서 표시한 것처럼

SetUID(4) / SetGID(2) / Sticky bit(1) 로 정해서 Special mode로 권한을 부여합니다!!

스페샬~모드니까 딱히 설정해 줄 필요가 없을 때는

가장 처음에 Octal modes 설명했을 때처럼 그냥 세 자리 숫자 옵션을 쓰면 돼요! ㅎㅎㅎ 아시겠죵? ㅎㅎ

자 그럼 세부설명 들어갑니다 ㅎㅎㅎ 우선 SetUID / SetGID 형제부터 알아볼게요.

SetUID : set user id upon execution

SetGID : set group id upon execution

SetUID와 SetGID는 유닉스의 접근 권한에 관련된 flag로 특정한 업무를 위해

일시적으로 권한을 상승하여 프로그램을 실행하는 데 주로 사용합니다.

SetUID가 설정된 경우엔 Permission에서 User section의 실행권한(x) 자리에 `x` 대신 `s`!! 가 기록되고,

SetGID가 설정된 경우엔 Permission에서 Group section의 실행권한(x) 자리에 `x` 대신 `s`!! 가 기록되는 거죠!

그럼 SetUID와 SetUID를 직접 설정하면서 배워봅시다 ㅎㅎ

< SetUID / SetGID 설정하기 >

먼저 chmod Symbolic modes를 이용합니다

대상 파일은 make_setuidgid_symbolic !!

1. SetUID 설정 : User에게 SetUID를!! 이라는 뜻으로 “u+s”를 사용합니다.

> $ chmod u+s make_setuidgid_symbolic

2. SetGID 설정 : Group에게 SetGID를!! 이라는 뜻으로 “g+s”를 사용합니다.

> $ chmod g+s make_setuidgid_symbolicc

User와 Group 권한에 각각 s가 쏙쏙 들어간 게 보이시죠? ㅎㅎ

다음은 chmod Octal modes로!

대상 파일은 make_setuidgid_octal !!

1. SetUID 설정 : SetUID bit는 4!!로 나타내니까!! 세자리 권한 앞에 4를 하나 더 얹어서

> $ chmod 4755 make_setuidgid_octal

2. SetGID 설정 : SetGID bit는 2!!로 나타내니까!! 세자리 권한 앞에 2를 하나 더 얹어서

> $ chmod 2755 make_setuidgid_octal

각각 User와 Group 권한에 s가 쏙! 들어갑니다 ㅎㅎ

이렇게 설정하는 걸 다 배웠고~ 설정하면 실제로 어떤 기능을 하는지!!! 알아봅시다 ㅎㅎ

실행 파일에 적용될 때와 디렉터리에 적용될 때 그 기능이 약간 다르기 때문에 이를 구분해서 보도록 해요.

< 파일에 적용된 SetUID / SetGID >

먼저 실행파일에 SetUID가 적용되면,

(해당 파일에 실행 권한이 있는) 일반 사용자가 해당 파일을 실행하면 파일이 실행되는 동안 소유자의 권한을 가지게 됩니다.

권한은 실행한 프로세스가 살아있는 동안 뿐이지만요… 이러한 실행권한이 필요한 파일이 뭐가 있을까 궁금한데,

가장 대표적인 게 /usr/bin/passwd 파일입니다.

passwd 파일의 경로는 /etc/passwd 이지만,

root만 이걸 수정(write 권한 필요!!)할 수 있다… 즉 일반 사용자가 패스워드를 바꾸고 싶을 때 사용하는 명령이??! /usr/bin/passwd 입니다 ㅎㅎㅎ

근데…. 이 명령어도… 일반 사용자에게는 수정할 권한이 없습니다. 뭔일?? ㅠㅠㅠ 수정권한은 없지만… 다른 게 있습니다.

바로 s bit!! 이게 우리가 말하고 있던 SetUID bit입니다!! 소유자 권한에 rws가 뙇 있습니다.

그래서 우리가 수정 권한은 없지만,

/usr/bin/passwd를 실행하는 동안 root의 권한을 얻기 때문에 패스워드를 수정할 수 있게 되는 것이죠 굳굳

조금 와닿으시나요, SetUID의 위력이?? ㅎㅎㅎ

이렇게 SetUID가 설정되어 있으면 무려 root의 권한을 받을 수 있으니까…

실행하는 동안 가지게 되는 root권한을 이용해 딴짓(!!)을 하려고… Command Injection같은 방법들을 이용하는 것입니다.

어마어마하죠? 이래서 SetUID가 중요한 거고… 이런 이야기로 넘어가려고… File Permission 설명하고 주절주절 했어요 ㅎㅎ

이렇게 살짝 흥미돋게 한 다음 저는 사라질 예정이에요 (소곤소곤) ㅎㅎㅎ

그런 다음 흥미가 좀 커졌을 때 다시 돌아와야 더 재미있게 배울 수 있거든요 하하핳

Buttt 사라지기 전에 SetUID / SetGID / Sticky bit 마저 설명하고 갈게요… ㅎㅎㅎㅎ

실행파일에 SetUID가 적용되는 경우를 설명했는데 실행파일에 SetGID가 적용되는 경우도 유사합니다!

SetGID가 설정되어있으면 소유그룹의 권한으로 실행할 수 있는 것이죠 ㅎㅎ 거의 비슷하니까 상세 설명은 생략!

< 디렉터리에 적용된 SetUID / SetGID >

자 그럼 SetGID와 SetUID가 파일말고 디렉터리에 적용될 수도 있겠죠?? 이 경우 파일과는 또 다른 특별한 일이 발생합니다. 주목! ㅎㅎ

우선 SetGID를 디렉터리에 적용할 경우

그 디렉터리 내에 새롭게 생성되는 모든 파일과 디렉터리에게 SetGID가 적용된 디렉터리의 group ID를 모두 물려주게 됩니다.

그래서 어떠한 디렉터리를 작업환경으로 두고 거기에서 생성되는 모든 것에 같은 그룹소유주를 설정하고 싶다!할 때 사용합니다.

즉 그 디렉터리에 무언가를 생성하는 사용자들의 그룹을 일일이 똑같게 설정하지 않아도 된다는 거죠!!

그럼 SetUID를 디렉터리에 적용하는 경우는요??

# 출처 : 위키피디아(wikipedia)

음 사실 유닉스와 리눅스 시스템에서 디렉터리에 SetUID bit를 설정하는 건 별 의미가 없대요… 그냥 무시된달까…

그리고 FreeBSD(또다른 Unix-like 시스템) 시스템에선 SetGID를 건 효과랑 같게 해석한다고 해요…

그러니까 SetUID를 디렉터리에 적용하는 건 특별한 의미가 없는 것 같습니다.

결국 뭔가 SetUID는 파일에 적용할 때 큰 힘을 발휘하고, SetGID는 디렉터리에 적용할 때 큰 힘을 내는 느낌이네요…. ㅎㅎㅎㅎ???!

< Sticky bit 알기 >

자아아아아 이제 대망의 마지막 스페샬 Permission mode!! Sticky bit 입니다 ㅎㅎㅎ

먼저 Sticky bit가 설정되면 Permission에서 Others의 실행권한(x) 자리에 x 대신 t!! 가 기록됩니다.

그럼 Sticky bit를 직접 설정해봅시다 ㅎㅎ

make_sticky1과 make_sticky2 파일에 chmod Symbolic modes와 Octal modes를 각각 적용할게요!

( make_sticky? 를 보고 뭐지? 하셨나요? 이 때 ‘?‘은 하나의 문자열을 대체하는 역할을 해서…

sticky 뒤에 하나의 문자열이 붙는 모든 파일을 보여준 것이죠! 우리는 1,2 볼 거니까 ?로 한 번에 요청하면 핵편!! ㅎㅎ )

1. Symbolic modes : Others에게 sTicky를!! “o+t”를 사용합니다.

> $ chmod o+t make_sticky1

2. Octal modes : Sticky bit는 1!!로 나타내니까!! 세자리 권한 앞에 1을 하나 더 얹어서

> $ chmod 1555 make_sticky2

요로코롬 해주면?!

두 파일 모두 각각 Others 권한에 t가 쏙! 들어간 게 보이시죠? ㅎㅎㅎㅎㅎㅎㅎㅎ

이렇게 Sticky bit가 부여 되어 있는지 아닌지 확인할 수 있습니다.

Sticky bit는 파일에 적용되기 보다는 디렉터리에 적용되는 권한으로, 주로 공용 디렉터리를 만들 때 설정한다고 하죠!

이 때 공용 디렉터리라 함은 흔히 여러 사용자가 함께 사용하면서 누구나 그 안의 파일과 디렉터리를 ‘생성’하거나 ‘열람’할 수는 있는데,

‘삭제’하거나 ‘수정’하는 작업은 소유자 혹은 Superuser(root)만 할 수 있는 환경을 말합니다.

즉 일반적으로 우리가 어떤 온라인 게시판에 글을 쓸 때

게시글을 작성한 당사자 혹은 관리자만 그 글을 수정하거나 삭제할 수 있는 것과 유사합니다! 이해되시죠? ㅎㅎㅎ

마무으리

우와 이제 진짜 다 배웠다~~~

진짜……. 저의 장황한 설명…. 친절이라는 핑계로 주저리주저리 맥락 휘젓는 얘기…. 다 들어주시느라 수고하셨습니다ㅋㅋ

사실 헛소리 한다 싶으면 빠르게 패스패스하면서 필요한 것만 쏙쏙 읽으시라고… 미리 말씀드렸어야 했는데…

그래도… 감격스러운 첫 탐험기 한 글자 한 글자 읽어주십사 미리 말안했어요 후훟 (죄송)

간단히 뭘 배웠는지 정리하면

1. Command Injection 맛보기 소개

2. File Permission !!!

3. File Permission을 바꿔보자!! - chmod / chown / chgrp ( 더하기 su / sudo )

4. Special Permission !!! - SetUID / SetGID / Sticky bit

사실 2,3은 기본적인 건데 4를 하려고 우선 윗 단계로 끌고 왔습니다… ㅎㅎ

그래도 2,3도 가장 기본! 중요!!한 거잖아요? ㅎㅎ 슥슥 다시 봐도 괜찮습니다 ㅎㅎㅎㅎㅎㅎ

자 그래서 오늘 4번 개념을 설명하면서 끝났는데, 다음 시간에 SetUID!!!!! 의 아주 중요한 역할과 쓰임새에 대해서 알아볼게요.

그러고나면 그걸 이용해서 Command Injection 살살 들어가보는 겁니다! ㅎㅎㅎ 기대…..해주시면 부담스럽겠지만… 열심히 해서 탐험기2로 돌아오겠습니다!

20000…

항해 열흘 째…. 슬슬 엄마 얼굴이 그리워지기 시작했다….

아… 엄마아….

ㅠㅠ

ㅠㅠ…

ㅠㅠ…?

엄마아아ㅏ아아아!!!!!!!!!!

aㅏ… 엄마보고싶다아아…

(이제서야 밝혀진 제목의 진실… ㅋㅋㅋㅋㅋ 하지만 아직도 무슨 얘길 할 건지 다 알진 못할 거라능! ㅋㅋ)

곧 엄마가 더 격하게 보고싶어지는 이야기로 다시 찾아뵙겠숩니다 호호홓

씨유쑨!