CLOUD12

해킹의 이해를 돕기 위한 유닉스 상의 기초상식

이제부터 나오는 내용들은 해킹을 이해하기 위한 유닉스상의 기초 지식이다.

패스워드는 어떻게 관리되는가?

보통 도용한 ID를 이용해 다른 시스템이나 ID의 소유주가 사용하고 있는 시스템의 관리자(root, Super user)의 자격을 얻어내기 위한 발판으로 삼는 경우가 있다. 그러므로 자신의 도용 당한 ID 때문에 피해를 본 쪽에서 조사 를 한다면 자신이 하지도 않은 일에 의심을 사게 될 수도 있게 되는 것이다.
또한 ID를 도용 당하면 자신만의 피해로 끝나는 일이 아닌 시스템의 피해까지도 야기할 수 있기 때문에 패스워드를 검증하는 절차를 두어 패스워드를 모르는 외부인은 사용하지 못하도록 막고 있는 것이다.
하지만 이 패스워드를 사용하고 있다 하더라도 문제는 있다. 만일 다른 사람도 충분히 추측해낼 수 있는 것으로 패스워드를 정했다면 다른 사람이 마음만 먹으면 자신의 ID를 사용할 수 있으므 로 무용지물이 되는 것이다. 그래서 자신의 패스워드를 관리하는 것에 대해 말해볼까 한다.
유닉스 시스템은 각 유저들의 패스워드 및 기타 정보를 /etc/passwd에 보관하고있다. vi나 cat을 이 용해 이 파일을 살펴보자.( 단, 보는 방법이 어떤 시스템을 쓰느냐에 따라 다르다. 위의 것은 일반적인 경우이고 위에 나온 NIS 시스템은 NFS 시스템과 함께 같이 뒤에서 설명하고자 한다.)

예시로 몇 줄만 들어보자.

    root:##root:0:0:Supervisor:/:/bin/csh
    daemon:##daemon:1:1::/:
    uucp:##uucp:4:8::/var/spool/uucppublic:
    kwlee:##kwlee:104:30:KyeongWon Lee:/circ/kus/kwlee:/usr/local/bin/tcsh
    sakai:##sakai:129:30:Kim Huy kang:/circ/kus/sakai:/usr/local/bin/tcsh
    hohle:##hohle:11529:410:Hoh eun ha:/under/under/hohle:/bin/csh
    sungho:##sungho:13189:410:Park sung ho :/under/under/sungho:/bin/csh

위와 같이 : 으로 구분된 두 번째 부분이 위와 같이 돼있는 경우도 있을 것이고 또는

    root:VRLoJ2QnLhRA2:0:0:Supervisor:/:/bin/csh
    daemon:*1:1::/::
    uucp:*:4:8::/var/spool/uucppublic:
    kwlee:ntim9ljaUGI.A:104:30:KyeongWon Lee:/circ/kus/kwlee:/usr/local/bin/tcsh
    sakai:tdtwKgRa3ZZoI:129:30:Kim Huy kang:/circ/kus/sakai:/usr/local/bin/tcsh
    hohle:u2WKlqINaIP8w:11529:410:Hoh eun ha:/under/under/hohle:/bin/csh
    sungho:eATMm4J0Zb4Dw:13189:410:Park sung ho :/under/under/sungho:/bin/csh

위와 같은 경우도 있을 것이다. 두 파일을 한번 살펴보자. 첫 세 줄은 root,daemon,uucp라는 시스 템 계정(account)에 관한 정보 이고 그 다음에 나오는 줄들은 kwlee나 sakai 같은 시스템의 일반 유저들에 관한 정보이다. 각각 의 줄은 : 을 기준으로 다음과 같은 7개의 필드(field)로 나뉜다.

그 예를 들어보자. 위에서 sakai란 사람을 살펴보면

    sakai:##sakai:129:30:Kim Huy kang:/circ/kus/sakai:/usr/local/bin/tcsh
    sakai:tdtwKgRa3ZZoI:129:30:Kim Huy kang:/circ/kus/sakai:/usr/local/bin/tcsh

  1. 유저이름: sakai
  2. password: ##sakai(의도적으로 패스워드 부분을 숨긴 경우->Shadowing passwd라고도 말한 다.)
    tdtwKgRa3ZZoI(변형시켜서 알지 못하게 한 경우. 보통 encrypt(암호화)시켰다고 말한다.)
  3. UID : 129
  4. GID : 30
  5. 실제 유저의 이름: Kim Huy kang
  6. 유저의 홈디렉토리:/circ/kus/sakai
  7. 유저가 사용하는 쉘: tcsh
위와 같은 정보를 얻을 수가 있다.

패스워드는 어떻게 만들어지는가?

그럼 위의 변형된 부분은 어떻게 생성되는 것일까? 다음을 수행시켜보자.

    % /usr/lib/makekey iakasbells
    lsDy0cB/5/zho>

    % /usr/lib/makekey sakaixvaaa
    aaxuEmMgYNZz2>

두 번의 실행결과를 비교해 보자. 공통점은 입력한 글쇠 중에서 끝에서 두번째부터의 글씨는 다 음 줄의 암호화된 부분에 그대로 찍혀 나오고 나머지 부분은 알아보지 못하게 변형되어 나온 것을 알 수 있다. 위의 예에서 입력한 단어 iakasbells의 마지막 두글자 ls와 다음에 변형된 단어 lsDy0cB/5/zho>의 첫 ls 다.

이 마지막 두 글자들을 key character(혹은 salt)라고 한다. 이런 방식으로 로그인 네임을 입력한 후 패스워드를 입력하면 맨 마지막의 두번째 글자들을 가지고 입력한 패스워드를 암호화하게 되고 이 암호화한 자료를 가지고 /etc/passwd와 내용을 비교하여 옳다면 로그인에 성공하게 되는 것이다.

보통 패스워드는 8자를 기준으로 하기 때문에 패스워드로 입력한 글자 수와 마지막 두 글자가 중 요한 의미를 갖게 된다. 앞 절에서도 말했지만 충분히 추측할 수 있는 패스워드를 사용하면 곤란하다. 또 /etc/passwd 파일로부터 패스워드를 추측해 주는 툴들(Crack 이라든지 Cops)을 사용해 알아낼 수도 있다.

이 툴들은 자신들의 독특한 알고리즘을 사용하는데, 이를테면 사전에 나오는 단어들이나, ID를 뒤 집어 대입해본다든지, 패스워드 파일에서 알아낸 자료들을 대입해본다든지 하는 방법이다. 물론 대입을 할 때에는 crypt() 함수를 이용해 encrypt(암호화)한 다음 이 결과를 /etc/passwd 파일에 있는 두번째 field인 변형된 부분과 계속 비교해 맞는지를 확인해내게 된다.

이런 이유로 인해 흔히 일상에서 쓰는 단어들은 적발될 우려가 높은데, 좋지 않은 패스워드로서 다음과 같은 사례를 들 수 있다 .

좋지 않은 패스워드의 예

setuid란 무엇인가?

/etc/passwd의 소유주는 분명히 호스트 관리자(root)이다. 또한 우리는 패스워드를 바꾼 다음 변경 된 내용을 /etc/passwd 파일에 저장을 하고 있다. 이상하지 않은가? 보통의 예라면 permission denied 라는 눈에 익은 메시지가 떠야 할 텐데 말이다. 여기 에 아주 중요한 내용이 담겨 있다. 바로 setuid라는 것이다. 다음을 수행시켜 보자.

    % ls -al /bin/passwd
    rwsr-xr-x 2 root 512 Jan 11 12:31 passwd
앞에서 설명이 잘 됐겠지만 setuid bit로서 s가 표시돼 있음을 알 수 있다. 이는 이 프로그램이 실 행되는 동안은 루트의 권한을가질 수 있게 되며 프로그램이 끝남과 동시에 이 권한은 사라지게 된다. 그런 이유로 패스워드를 이용해 /etc/passwd 파일을 우리가 바꿀 수 있는 것이다.

우리는 이런 setuid를 많이 이용하고 있다. 로그인 프롬프트가 나왔을 때 우리는 생각 없이 로그 인을 하지만 내부에서는 상당히 복잡한 구동이 이뤄지고 있다. 우선 login 이라는 메시지 다음에 들어오는 사용자의 ID를 읽어 들인다.

그리고 패스워드를 읽어 들이는데 읽어들인 패스워드를 crypt() 함수를 이용해 암호화시킨다. 이 암호화된 패스워드를 /etc/password(Shadowing passwd 인 경우는 다른 파일 이를테면 passwd.adjunct 같은 다른 파일을 참조한다.)의 두번째 field와 비교해 같으면 올바른 패스워드를 입력했으므로 login을 허가해준다. 다시 ls /bin/login을 해보면 알겠지만 이 login도 root 소유의 setuid bit가 붙은 파일이다.

여기서 알아둬야 할 점은 패스워드를 확인할 때 /etc/passwd 파일의 두 번째 field를 풀어서 입력된 패스워드와 맞춰 보는 게 아니라는 점이다. 이런 decrypt 함수는 없으며 알고리즘도 존재치 않는다. 이로 인해 불완전하지만 유닉스의 보안이 이뤄지고 있는 것이다.

또한 앞에서 이야기했지만 루트 소유이고 setuid가 실행되는 동안은 시스템관리자의 권한을 갖는 다고 했다. 우리는 이것을 보고effective uid라고 한다. 해커들은 이런 루트 소유의 setuid bit 파일들을 실행시키는 동안 인터럽트를 걸 수 있는 쉘 스크립트라든가 툴을 이용해 이 파일들의 실행을 중지시킨 상태로 있게 한 다. 즉 root의 권한을 가진 채로 있도록 하는 것이다. 이런 식으로 해 root의 권한을 불법적으로 획득하는 것이 대부분의 해킹방법이다.

과거의 해킹 유형들

예전에는 주로 네트워크 상이나 로컬 호스트 상에 서 configuration이 잘못된 것을 이용해 관리자의 권한을 얻는 초보적인 해킹이 많았다. 즉, OS를 인스톨하면 프로그램들의 퍼미션이 적절히 조정 안돼 있는 경우가 많은데, 이를 악용해 호스트 관리자만이 보고 쓸 수 있는 파일도 마음대로 조작하는 경우가 예전의 해 킹 유형이었다. 또한 웃지 못할 얘기로 해킹시도를 해도 계속 실패하게 되자, 기계를 들고 훔쳐 달아난 도둑해커(?) 도 있다.


sqCLOUD2 sqCLOUD19