전 글에서 설명하였듯이 스택의 적당한 곳에 우리가 직접 작성한 쉘코드를 집어넣어주면 된다. 하지만 이는 말처럼 쉽지만은 않다. 쉘코드를 C언어로 작성한다면 쉽지만 스택에 삽입해야 하기 때문에 기계어 수준의 코드를 필요로 한다는 점이다. 아울러 우리가 삽입한 코드의 어드레스를 알기가 그리 쉽지 않다는 것이다. 하지만 이런 어려움들을 이번 글에서 극복해본다.

쉘코드를 만드는 문제는 이미 인터넷에 현재 널리 사용되는 OS들의 쉘코드가 해커들 사이에 돌아다니고 있기 때문에, 그것을 얻음으로써 어느 정도는 쉽게 해결할 수 있다.

우리가 삽입한 코드의 정확한 위치를 아는 방법은 수많은 시행착오를 통해서 해결할 수 있는데, 여러번 시도해 보면 스택의 어디쯤에 삽입된 코드가 저장되어 있는지를 대략 짐작할 수 있다. 하지만 그 코드를 실행하기 위해서는 정확한 어드레스를 알아야 된다. 이것은 그 코드 앞에 충분히 많은 NOP(null operation) 코드를 삽입한 후 리턴 어드레스가 그 NOP를 가리키게끔 하는 방법으로 극복할 수 있다.

C로 짠 쉘코드

이 어셈코드를 스택에 넣은 다음 실행시키면 /bin/sh를 실행시키게 된다. 그렇게 하기 위해서는 위의 코드를 명령인자에 넣어주기 위해선 문자배열로 만들어야 되는데 다음과 같은 문자배열을 만들 수 있다.

이전글 [UNIX 보안 기초 -3-] 대표적인 해킹유형

벌써 한주가 지나갔습니다. 시간 참 빠르네요. 다들 중간고사도 끝났겠구..이제 새로운 시작을 해봅시다. 저는 매번 시작인것 같네요..ㅠ

이번부터는 몇가지 해킹 기법에 대해 약간 깊숙히 소개하려 합니다. 오늘은 BOF(Buffer Over Flow 공격) 인데요. 얼마전 구글폰 G1 과 구글 웹브라우저 크롬에서 버퍼 오버플로우 공격에 대한 취약성이 발견되었죠..
아무튼,, 이제 시작합니다.

void function(int a,int b) {         char buffer1[5];         char buffer2[5]; } void main() {         function(1,2); }

요점 - SUID 걸린 프로그램에 BOF로 공격하여 return address를 shell 띄우는 곳으로 이동하게끔 하면 root 권한을 얻을 수 있다.

이전글 [UNIX 보안 기초 -2-] UNIX 파일시스템 초간략

• DoS, DDoS - local DoS, remote DoS  (서비스를 불가능하게 하는 공격)
• 시스템 오류 - 환경변수의 취약성, ptrace, race condition, 잘못된 퍼미션
• 프로그램의 오류 - setuid, daemon 의 오류 이용, BOF(Buffer Overflow), FSB(Format String Bug)
• Network의 취약성 - Spoofing, Sniffing
• 기타 - passwd cracking

다음은 간단한 해킹시도의 원리들이다.

1. DoS, DDoS

DoS (Denial of Service) 공격이란 다중작업을 지원하는 운영체제에서 발생할 수 있는 공격 방법. 구체적으로 한 프로세스가 시스템의 리소스를 독점하거나, 모두 사용해 버리거나 또는 파괴하여서 올바른 서비스를 제공하지 못하도록 하는 공격. 공격 장소에 따라 나누면 local DoS, remote DoS 가 있다.

local DoS - 공격자가 시스템에 들어와서 시행하는 방법. 실제 이를 위해서는 간단한 C코드나 쉘 스크립트를 이용하면 된다. 하지만 이러한 공격법의 문제점은 반드시 시스템에 계정이 있어야 한다는 점.
ex) 디스크 채우기, 메모리 고갈, 프로세스 만들기. Explorer 4.0 자기참조프레임

remote DoS - 일반적으로 이들은 특정 포트를 listen하고 있는 프로세스를 마비시키거나 운영체제의 네트워크 기능 자체를 오동작하게 하거나 LAN 자체를 마비시키는 것으로 분류할 수가 있다. 
ex) ping attack, ICMP(Internet Control Message Protocol)공격, 메일폭탄 등.

2. 환경변수 이용

다중 사용자를 지원하는 서버용 시스템은 각 사용자에 맞는 환경변수를 지정하여서 지정한 환경 하에서 사용자가 좀더 편리하게 작업을 할 수 있도록 도와주고 있다.

PATH - PATH 환경변수는 실행파일이 위치한 디렉토리들을 값으로 가지고 있다. 프로그램 내부에서 절대 경로를 주지 않고 외부 프로그램을 호출한다면 PATH 변수에 포함된 디렉토리들을 순서대로 찾아가면서 호출한다. 프로그래머가 만약 다음과 같은 코드를 사용한다면

set | less 명령어로 확인하여 보자.

IFS 가 "/"로 바뀐 것을 확인할 수 있다.

동적 라이브러리 이용 - 유닉스 시스템에서 사용하는 동적 라이브러리(Dynamic Library)를 이용하기 위한 환경변수를 이용해도 프로그램의 오동작을 유도할 수도 있다. 동적라이브러리를 이용하기 위한 환경변수에는 LD_LIBRARY_PATH와 LD_PRELOAD가 있다.

- LD_LIBRARY_PATH : 동적 라이브러리가 들어있는 디렉토리들을 값으로 갖는다.
- LD_PRELOAD : 먼저 loading 해야 하는 동적 라이브러리가 들어있는 디렉토리를 값으로 갖는다.

3. Race Condition(경쟁조건) #1. 임시파일을 생성하는 SETUID가 걸린 프로그램

만약 수퍼유저 소유의 SETUID 프로그램이 임시파일을 만든다면 수퍼유저의 권한으로 파일이 생성될 것이고 이 임시 파일을 프로세스가 접근하기 전에 다른 시스템 파일로 바꿔버린다면 어떤 시스템 파일이든 덮어쓰기가 가능해진다.


root권한의 setuid가 걸린 "good"이라는 프로그램이 있다고 하자.
그런데 이 프로그램은 실행한 후에 /tmp 디렉토리안에 byebye라는 임시파일을 만든다. 이러한 경우, 즉 프로그램이 실행 과정에 임시파일을 생성하는 경우에도 심볼릭링크를 이용하여 해킹을 할 수 있다.
일단 good이라는 프로그램을 실행하면 /tmp/byebye라는 임시파일이 생길 것이다. 일반 사용자가 이 임시파일(/tmp/byebye)을 삭제하고, /etc/passwd의 심볼릭 링크를 만드는데 이름을 /tmp/byebye라고 하여 만들었다.

그럼 이제 다시 good을 실행시키면 어떻게 되겠는가?

good이라는 프로그램엔 root권한의 setuid가 걸려있으므로 실행되는 동안에는 root의 권한이 유지된다. 프로그램이 byebye라는 임시파일을 만드는데 byebye는 /etc/passwd의 심볼릭링크 파일이다. /etc/passwd는 root만이 쓰기가 가능한데, 프로그램 실행 중에는 root권한이기 때문에 결국 /etc/passwd파일에 쓰기가 가능해진다. 따라서 심볼릭링크 파일을 수정하면 원본파일(/etc/passwd)도 수정이 되는 것이다.

이러한 사실을 기초로 하면, 결국 /tmp/byebye의 내용이 /etc/passwd로 들어갈 것이고 /etc/passwd파일은 손상을 입게된다고 예상할 수 있을 것이다.

ex)
-> 문제가 되었던 SunOS의 /bin/mail은 편지를 저장할 때 먼저 그 사용자의 계정을 파일 이름으로 하는 파일의 상태를 검사한다. (lstat()을 이용). 그리고 나서 편지를 저장하기 위해 open()을 수행한다. 즉, 두 시스템 콜 사이에 아무런 변화가 없었다고 가정하고 프로그램이 작성되어 있다. 하지만 lstat()를 사용한 바로 다음에 다른 프로세스가 그 파일을 /.rhosts로 바꿔버리면 편지의 내용은 /.rhosts에 저장하게 된다. 만약 편지의 내용 중에 "+ +"가 들어 있다면 모든 시스템에서 수퍼유저의 권한으로 아무런 제약 없이 로긴할 수 있게 되는 것이다.

4. Race Condition(경쟁조건) #2.

만약 위와 같다면 왜 race condition이 등장하게 되었을까? 그냥 링크 시켜서 하면 되는 것인데, 왜 프로세스 간의 resource 경쟁이 나타나는가? 그것은 일종의 방어자와 공격자의 싸움에서 등장한 결과라고도 볼 수 있다.

프로그래머는 이런 문제점을 인식하고 lstat()을 이용한 방법을 택하였다. lstat()을 이용하여 먼저 modify 하고자 하는 파일이 Symbolic Link인지를 먼저 파악, 그 후 그 파일을 open() 시켜서 처리하도록 한 것이다. 아무런 문제가 없는 듯이 보였다. 그러나, 여기에서 진정한 race condition이 등장한다.

lstat()과 open()사이에는 분명히 갭이 존재한다. 그 갭을 적절히 이용한 것이 바로 race condition인데, 먼저 race 프로그램을 background로 돌린다. race 프로그램은 돌면서, 공격하고자 하는 프로그램이 modify하는 파일을 연속해서 지우고, 링크를 만들고 하는 작업을 반복한다. 그런 후에 공격하고자 하는 프로그램을 돌린다. 그러면 어떻게 될까?

race condition example.

5. PTRACE

ptrace는 생성된 프로세스가 어떻게 움직이며, 어떤 식으로 데이터를 읽고 쓰는지, 어떤 에러를 내는지 추적을 하기 위해 마련된 시스템 콜이다. 이것은 주로 디버그를 위해 사용되며, 따라서 디버거는 일종의 ptrace 명령어 묶음 유틸리티라고 보면 옳겠다. 프로그래머는 디버거를 통해 ptrace를 손쉽게 사용할 수 있으며, 자신이 만든 프로그램이 어떻게 수행되는지 총괄적으로 관제할 수 있다.

부모프로세스가 invoke된 자식 프로세스를 통제할 수 있다는 사실. 조작의 대상이 되는 것은 그 프로세스가 가진 variables등의 메모리 core와 registers 들이다. ptrace 명령어들은, 이러한 것들을 읽고 쓰고 할 수 있음으로 해서 그 프로세스에 대한 전체적인 control flow도 조작해낼 수 있다는 것이다.

이전글 [UNIX 보안 기초 -1-] 개요.

대표적인 공격유형에 들어가기에 앞서 유닉스 파일시스템의 간단한 구조를 재짚어 보겠습니다.

UNIX 파일시스템 아주 간략하게~

d rwx r-x r-x

이전글 [UNIX 보안 기초 -0-] Prologue.

* 보안에 관한 간략한 개요

1. 정보보호란?

The Protection of information against unauthorized disclosure, transfer, modification, or destruction, whether accidential or intentional [ Information Warfare, July 1996 ]
(우연 또는 의도적으로 허가받지 않은 정보의 누출, 전송,수정,파괴 등으로부터 보호)


2. 정보보호의 원칙

• OECD 의 개인정보보호 8대 원칙 (1980)
  더보기
  접기

  원문보기[새창] 1) 수집제한의 원칙 개인데이터의 수집에 제한을 두어야하며 개인데이터 수집 방법은 적법하며 공정한 수단에 의해 행하도록 하여야 한다. 경우에 따라서는 정보주체에 알리거나 동의를 구하여야 한다.   2) 정보내용의 원칙 개인데이터는 그 이용목적에 따라야 하며 이용목적에 필요한 범위 내에서 정확, 안전 그리고 최신의 것을 가져야만 한다.    3) 목적명확화의 원칙 개인데이터의 수집 목적은 수집시 보다 늦지 않은 시점에서 명확하게 되어야 하며 그후의 데이터 이용은 해당 수집 목적의 달성 또는 수집 목적에 모순되지 않도록 하며 목적의 변경 시에 명확한 다른 목적의 달성에 한정되어야만 한다.   4) 이용제한의 원칙 개인데이터는 명확한 목적이외의 목적을 위해서는 데이터 주체의 동의가 있는 경우나 법률의 규정에 의한 경우를 제외하고는 공개나 이용, 그 외의 사용에 대해서는 금지되어야 한다. 5) 안전보호의 원칙 데이터는 분실 또는 부당한 접근, 파괴, 사용, 수정, 공개의 위험에 대해서 합리적인 안전보장 조치에 의해 보호되어야 한다. 6) 공개의 원칙 개인데이터에 관한 개발, 운용 및 정책에 관해서는 일반적인 공개 정책이 취해져야 한다. 개인데이터의 존재, 성질 및 주요목적과 함께 데이터 관리자의 식별, 통상의 주소를 분명히 하기 위한 수단이 쉽게 이용될 수 있도록 하여야 한다. 7) 개인참가의 원칙 개인은 다음 4가지의 권리를 가진다. ① 데이터 관리자는 자기 데이터 유무를 확인할 수 있다. ② 자기 데이터를 알 수 있다. ③ ① 또는 ②가 거부되었을 경우는 사유를 들을 수 있다. ④ 자기 데이터에 관한 이의신청이 인정될 경우는 데이터를 소거, 수정, 완전한, 교정할 수 있다. 8) 책임의 원칙 전기통신분야에 있어서 고용문제에 대한 데이터 관리자는 상기의 원칙을 실시하기 위한 조치에 책임을 가진다.

  접기
• NIST 컴퓨터 보안 원칙
  더보기
  접기

  원문보기[새창] 1). 컴퓨터 보안은 조직의 임무를 지원해야 한다. 컴퓨터 보안의 목적은 조직의 가치 있는 자원(정보, 하드웨어, 소프트웨어 등)을 보호하기 위한 것이며 적절한 보호 수단의 선택 및 적용을 통하여, 조직의 물리적 재정적 자원, 평판, 법적인 위상, 혹은 다른 유 무형 자산의 보호하는데 그 의미가 있다. 또한 보안은 목적을 달성하기 위한 수단으로서 존재하며, 그 자체가 목적은 아니다. 예를 들면, 개인적인 사업 영역에서의 보안은 이익을 창출하기 위한 부가적인 수단이 될 수 있으며, 공공기관에서의 보안은 대중에게 제공하는 서비스의 수준을 향상시키기 위하여 필요한 부가적인 수단이 되는 것이다. 2). 컴퓨터 보안은 견고한 관리를 위한 필수 요소이다. 정보와 컴퓨터 시스템은 조직의 임무를 지원하는 결정적인 자산이다. 그 자산을 보호하는 것은 조직 경영관리를 위한 필수요소이다. 그러나, 정보와 컴퓨터 관리에 있어서 보안에 대한 문제를 포함하는 것 만으로는 이러한 자산에 대한 위험 가능성을 완벽하게 배제할 수는 없다. 결과적으로 조직의 관리자는 보안 통제에 따르는 비용을 반영하여 허용 가능한 위험의 수준을 결정하여야 한다. 3). 컴퓨터 보안은 비용대 효과가 고려되어야 한다. 보안에 대한 비용과 이익은 보안의 실현에 따르는 비용이 효과를 넘지않도록 금전적인 면과 비 금전적인 면에 대하여 주의 깊게 검토되어야 한다.. 보안은 컴퓨터 시스템에 대한 의존도, 가치, 잠재적인 위협의 심각성 및 발생가능성 등을 고려하여 적절하고, 균형있게 이루어져야 한다. 만약 위험을 방치했을 때 발생되는 손실보다 직·간접적으로 더 많은 비용이 든다면 보안대책은 비용대 효과면에서 고려되어야 한다. 4). 컴퓨터 보안에 대한 책임과 책임추적성이 분명해야 한다. 컴퓨터 시스템의 소유자, 공급자, 사용자 및 보안에 관련된 사람들의 책임과 책임추적성이 분명해야 한다 .만일 시스템이 외부 사용자를 가지고 있다면, 그 소유자는 다른 사람들로 하여금 그 시스템이 적절하게 안전하다는 확신을 가질 수 있도록 보안 대책의 일반적인 범위와 현황에 대하여 정보를 제공하고 이에 대한 책임을 가지고 있어야 한다. 5). 시스템 소유자들은 그들의 조직 외부에 대해서도 보안 책임을 갖는다. IT 시스템 및 관련된 다른 분야의 소유자, 공급자 그리고 사용자는 그에 대한 책임 및 의무가 명백하게 정의되어야 하며, 책임의 할당은 조직 내부 혹은 조직의 경계 밖에까지 확대되어 질 수 있다. 6). 컴퓨터 보안은 포괄적이고 통합된 접근방법을 필요로 한다. 효율적인 컴퓨터 보안은 모든영역을 고려하는 포괄적인 접근법을 필요로 한다. 즉 관리자들은 컴퓨터 보안이 다른 시스템의 영역 및 전체적인 조직의 관리 구조에 대하여 어떻게 연관이 있는지 이해하여야 한다. 7). 컴퓨터 보안은 정기적으로 재평가되어야 한다. 컴퓨터와 그 운영 환경은 동적이다. 그래서 시스템 기술과 사용자, 시스템내의 데이터와 정보, 시스템과 관련된 위험과 보안 요구는 항상 변화한다 그러므로 시스템이 한번 잘 구현되었다 할지라도 그것이 동적으로 변화를 반영하지 못하면 그 시스템의 보안은 결코 완벽할 수가 없는 것이다. 또한 시스템 사용자들과 운영자들은 보안 설정을 우회하거나 파괴하는 방법을 의도적 혹은 비의도적으로 새로이 발견하게 되며. 시스템 및 환경의 변화는 새로운 보안 취약성들을 생성하기도 한다. 따라서 IT 시스템 보안은 주기적으로 재 평가되어야 한다. 8). 컴퓨터 보안은 사회적인 요인에 의해 제약된다. 조직의 임무를 지원하는 보안 능력은 사회적 쟁점과 같은 다양한 요인에 의해 제한될 수 있다. 예를들면 보안정책과 사업장에서의 프라이버시는 서로 대립될 수 있다. 그러므로 보안의 통제 수단은 다른 사람들의 법적인 권리를 이해하는 바탕에서 선택되고 구현되어야 한다. 다시 말해서, 정보의 소유자가 요구하는 보안과 사용자의 사회적인 목표가 조화를 이루어야 한다.

  접기
• GASSP의 정보보호원칙
  더보기
  접기

  원문보기[새창] 1) 보편적 원칙(Pervasive Principles) 기본적인 원칙으로써 거의 불변하며 원칙의 수가 적다. 1. 책임추적성의 원칙(Accountability Principle) 2. 인식의 원칙(Awareness Principle) 3. 윤리원칙(Ethics Principle) 4. 다중협력의 원칙(Multidisciplinary Principle) 5. 균형성의 원칙(Proportionality Principle) 6. 통합성의 원칙(Integrated Principle) 7. 적시성의 원칙(Timeliness Principle) 8. 재평가의 원칙(Reassessment Principle) 9. 공정성의 원칙(Equity Principle) 2) 광범위한 기능적 원칙(Broad Functional Principles) 보편적 원칙에 종속되며 다음의 상세원칙의 개발지침을 제공한다. 이 원칙은 기술이나 기타 영향 요소의 중요한 개발에 반영될 때에만 변경되며 다소 원칙의 수도 많고 특수성을 갖는다. 1. 정보보호 정책(Policy) 2. 보안 인식(Awareness) 3. 책임추적성(Accountability) 4. 정보관리(Information Management) 5. 환경관리(Environment Management) 6. 인력의 자격(Qualifications) 7. 무결성(Integrity) 8. 정보시스템 생명주기(Life cycle) 9. 접근통제(Access Control) 10. 업무연속성 계획(Contingency Planning) 11. 위험관리(Risk Management) 12. 네트워크와 기반구조 보호)Infrastructure Security) 13. 정보보호의 법률, 규제 및 계약상 요구사항(Legal, Regulatory, Contractual) 14. 윤리실행(Ethical Practices) 3) 상세원칙(Detailed Security Principle) 광범위한 기능적 원칙에 종속되며 기술이나 기타 영향요소의 혁신에 따른 잦은 변경이 이루어진다. 원칙의 수도 많고 특수성과 갑자기 부각되는 특성을 갖는다. 1. Need to know 원칙 2. Need to go 원칙 3. Need to do 원칙 4. 최소권한의 원칙(Least Privilege Principle) 5. 임무분리의 원칙(Separation of Duty) 6. 임무 순환 원칙(Rotation of Duty) 7. 2인조 근무의 원칙(Two-man Principle)

  접기

3. 관리자의 역할과 책임
 
시스템 관리자는 시스템을 정상적으로 유지하는 데 있어서 가장 중요한 위치에 있는 사람이다. 관리자가 시스템을 어떻게 관리하느냐에 따라 사용자들이 얼마나 유용하고 편리하게 사용할 수 있는가 하는 것이 결정되어지며 그 시스템의 안정성과 보안에 대한 신뢰도도 결정되어진다.

다음 아래는  '이상용 삼성전자 총무보안그룹 차장'의 글

• Policy
  • Security Policy
  • Marking
• Accountability
  • Identification
  • Accountability
• Assurance
  • Assurance
  • Continuous Protection

이 항목들에 의하여 보안등급이 나뉘어진다. 보안등급은 D, C, B, A 등으로 나뉘며 세부적으로는 다시 C1, C2, B1, B2, B3 등으로 나뉘어진다. 보안은 등급이 A로 갈수록 강력하며 같은 등급 내에서는 뒤에 붙는 숫자가 클수록 강력하다. 보안등급에 대하여 간단히 설명하면 다음과 같다.  
더보기

 관리자는 시스템을 어느 정도의 보안등급으로 구축할 것인지를 결정하여야 한다. 이때 주의하여야 할 것은 보안등급이 높다고 해서 꼭 좋다고 볼 수만은 없다는 것이다. 너무 엄격하게 보안을 유지한다면 사용자들의 불편이 그만큼 커지기 때문이다. 그러므로 관리자는 이 점을 충분히 고려하여야 한다.

5. 일반적인 침입수법

A. 정상적인 데이터 전송 .