본문으로 이동

루트킷

위키백과, 우리 모두의 백과사전.

시리즈 일부
정보 보안
관련 보안 분류
위협
방어

루트킷(rootkit)은 컴퓨터 소프트웨어 중에서 악의적인 것들의 모음으로써, 자신의 또는 다른 소프트웨어의 존재를 가림과 동시에 허가되지 않은 컴퓨터나 소프트웨어의 영역에 접근할 수 있게 하는 용도로 설계되었다.[1] 루트킷이라는 용어는 "루트"(유닉스 계열 시스템에서 권한을 가진 계정의 전통적인 이름)와 "kit"(툴을 구현하는 소프트웨어 구성 요소를 가리킨다.)의 합성어이다. "루트킷"이라는 용어는 악성 소프트웨어와의 연관으로 인해 부정적인 의미를 함축하고 있다.[1]

루트킷의 설치는 자동으로 이루어지거나 공격자가 루트 권한이나 관리자 접근을 획득하였을 때 설치될 수 있다. 이 접근을 획득하는 것은 알려진 취약점(권한 확대 같은)을 공격하는 것이나 암호(크래킹 또는 사회공학을 통해 획득한)를 통한 직접적인 권한의 결과이다. 한 번 설치되면, 권한을 가진 접근을 유지할 뿐만 아니라 침입을 숨길 수도 있다. 중요한 점은 루트 또는 관리자 접근이다. 시스템에 대한 완전한 제어는 존재하는 소프트웨어가 수정되었을 수 있다는 것을 의미한다.

루트킷 탐지는 이것이 자신을 찾으려 하는 소프트웨어를 뒤집어 엎을 수 있기 때문에 어려운 일이다. 탐지 방법은 대체적이고 신뢰성 있는 운영 체제나 행동 기반 방식, 특징(signature) 스캐닝 그리고 메모리 덤프 분석 등이 있다. 제거는 복잡하거나 심지어 실질적으로 불가능할 수 있는데 특히 루트킷이 커널에 거주할 때 더 그렇다; 운영 체제의 재설치가 문제 해결의 유일한 해결법이 될 수 있다.[2] 펌웨어 루트킷의 경우, 제거하기 위해서 하드웨어 교체나 특별한 장비가 필요할 수 있다.

용도

[편집]

현대 루트킷들은 접근을 상승시키지 않고,[3] 대신 숨겨진 기능을 추가함으로써 다른 소프트웨어 페이로드를 탐지하지 못하게 하는 용도로 사용된다.[3] 대부분의 루트킷들은 악성 소프트웨어로 분류되는데, 그들과 함께 번들된 페이로드가 악의적이기 때문이다. 예를 들면 페이로드는 은밀하게 사용자 계정, 신용 카드 정보, 컴퓨팅 자원을 훔치거나 다른 비인가된 행동을 수행할 수 있다. 소수의 루트킷들은 자신의 사용자에 의해서 유틸리티 애플리케이션으로 여겨질 수 있다.

루트킷과 그것의 페이로드는 많은 용도를 갖는다.

  • 공인되지 않은 접근을 허용함으로써 공격자가 백도어를 통해 완전한 접근을 할 수 있게 한다. 이것을 이행하는 방법 중 하나로 유닉스 계열 시스템의 경우에는 /bin/login 프로그램, 윈도우의 경우에는 GINA 같은 로그인 메커니즘을 뒤집어 엎는 것이 있다. 이 대체는 정상적으로 동작하는 것처럼 보이지만 비밀 로그인 조합을 받아들여서 공격자가 시스템에 관리자 권한으로 직접 접근하게 한다. 이것은 표준 인증 그리고 인가 메커니즘을 우회함으로써 가능해 진다.
  • 비밀번호를 훔치는 키로거와 컴퓨터 바이러스 같은 악성 소프트웨어를 숨긴다.[4]
  • 다른 컴퓨터를 공격하기 위해 특정 머신을 좀비 컴퓨터로 도용한다. (공격은 공격자의 시스템이 아니라 좀비 컴퓨터에 의해서 수행된다.) "좀비" 컴퓨터들은 일반적으로 서비스 거부 공격을 수행할 수 있는 다수의 봇넷들이 멤버이다.
  • 디지털 권리 관리의 강화.

어떤 경우에 루트킷들은 요구되는 기능을 제공하며, 사용자에 의해 의도적으로 설치될 수 있다.

  • 안티 치팅 소프트웨어로부터 온라인 게임 치팅을 숨긴다.[5]
  • 허니팟에서 공격들을 탐지한다.[6]
  • 에뮬레이션 소프트웨어와 보안 소프트웨어를 강화한다.[7] 데몬 툴즈가 시큐롬 같이 복사 방지 메커니즘을 무산시키는데 사용되는 악의적이지 않은 루트킷의 상업용 예시이다. 카스퍼스키 안티바이러스도 또한 악의적인 행동으로부터 자신을 보호하기 위한 루트킷과 비슷한 기법을 사용한다. 이것은 시스템 활동을 가로채기 위해서 자신의 드라이버를 로드하며, 다른 프로세스들이 자신에게 해로운 행동을 하는 것을 예방한다. 이 과정들은 감추어져 있지는 않지만 표준적인 방식으로 종료할 수는 없다.
  • 도난 방지 보호: 노트북은 BIOS 기반 루트킷을 가짐으로써 주기적으로 감시하고 도난된 후에도 정보가 사라지지 않게 해준다.[8]
  • 마이크로소프트 정품 인증[9]


종류

[편집]

루트킷에는 적어도 5가지의 종류가 존재하며, 가장 낮은 레벨인 펌웨어부터(가장 높은 권한을 가진) 가장 높은 권한을 갖는 링 3의 사용자 기반까지의 범위를 갖는다. 이것들의 하이브리드 형태는 사용자 모드에서 커널 모드까지에 걸친 것이다.[10]

사용자 모드

[편집]
컴퓨터 보안 링 (링 -1이 보이지 않는다는 점에 주의하라)

사용자 모드 루트킷은 저수준 시스템 프로세스가 아니라 링 3에서 돌아간다.[11]이들은 API의 표준 행동을 가로채고 수정하기 위한 가능한 수많은 설치 매개들을 갖는다. 몇몇은 DLL을 다른 프로세스에 삽입함으로써 어느 대상 프로세스에서도 실행될 수 있게 한다; 다른 충분한 권한을 가진 것들은 간단하게 대상 애플리케이션의 메모리를 덮어쓴다. 삽입 메커니즘은 다음을 포함한다.[11]

  • 벤더에서 제공된 애플리케이션 확장 사용. 예를 들면 윈도우 익스플로러는 써드파티가 기능을 확장하게 해주는 공용 인터페이스를 갖는다.
  • 메시지 가로채기.
  • 디버거.
  • 보안 취약점 공격.
  • 실행되는 프로세스나 파일 시스템에 존재하는 파일을 숨기기 위한 함수 후킹 또는 주로 이용되는 API의 패치.[12]

커널 모드

[편집]

커널 모드 루트킷은 커널과 디바이스 드라이버 같은 코어 운영 체제의 한 부분에 코드를 추가하거나 대체함으로써 높은 운영 체제 권한(링 0)과 함께 실행된다. 대부분의 운영체제들은 운영체제 자신과 같은 권한에서 실행되는 커널 모드 디바이스 드라이버를 지원한다. 이러한 많은 커널 모드 루트킷들은 리눅스에서 적재 가능 커널 모듈, 그리고 윈도우에서 디바이스 드라이버 형태로 개발된다.[13] 이 복잡함은 버그가 흔한 상태로 만들며, 동작하는 코드의 어느 버그도 시스템 안정성에 심각한 영향을 미쳐서 루트킷이 발견되게 한다.[13]

커널 루트킷들은 운영체제 자신과 같은 보안 수준에서 동작하기 때문에 특히 탐지하고 제거하기가 어려우며, 그로인해 가장 신뢰되는 운영 체제 동작을 가로채고 전복시킬 수 있다. 바이러스 검사 소프트웨어 같은 시스템과 같이 돌아가는 어떤 소프트웨어도 똑같이 취약하다.[14] 이 경우에 시스템의 어떤 부분도 신뢰할 수 없게 된다.

루트킷은 DKOM(Direct Kernel Object Manipulation)으로 알려진 기법을 사용하는 윈도우 커널에서 데이터 구조를 수정할 수 있다.[15] 이 방식은 프로세스들을 숨기는데 사용될 수 있다. 커널 모드 루트킷은 또한 시스템 서비스 서술자 테이블 (SSDT)을 후킹하거나, 자신을 가리기 위해 사용자 모드와 커널 모드 사이의 게이트를 수정할 수 있다.[16] 비슷하게 리눅스 운영 체제에서도, 루트킷은 커널 기능을 전복시키기 위해 시스템 호출 테이블을 수정할 수 있다.[17] 루트킷이 다른 악성코드나 감염된 파일의 원본을 숨기긴 곳에서 감춰진 암호화된 파일 시스템을 생성한다는 것은 흔한 일이다.[18]

운영 체제들은 커널 모드 루트킷의 위협에 대응하도록 진화하고 있다. 예를 들면 마이크로소프트 윈도우의 64비트 버전은 신뢰하지 않은 코드를 높은 권한으로 실행하는 것을 어렵게 하기 위해 현재 모든 커널 수준 드라이버들의 의무적인 표시를 구현하고 있다.[19]

부트킷

[편집]

부트킷이라고 불리는 커널 모드 루트킷의 변형은 마스터 부트 레코드(MBR), 볼륨 부트 레코드(VBR) 또는 부트 섹터 같은 시작 코드를 감염시켜서 전체 디스크 암호화를 공격하는데 사용될 수 있다. 일반적으로 악성코드 로더는 커널이 로드될 때 보호 모드로 이행하려고 하며, 그로 인해 커널을 전복시킬 수 있다.[20][21][22][23]

부트킷 공격에 대한 유일한 알려진 방어는 시스템에 대한 비인가된 물리적 접근의 예방 또는 부트 경로를 보호하기 위한 신뢰 플랫폼 모듈의 사용이다.[24]

하이퍼바이저 레벨

[편집]

학문적으로 타입2 하이퍼바이저 형태로 생성된 루트킷은 기술 검증용으로서 만들어져 왔다. 인텔 VT 또는 AMD-V 같은 하드웨어 가상화 특징을 익스플로잇함으로써 이 타입의 루트킷은 링 -1에서 실행되고 가상 머신으로서 대상 운영 체제를 호스트하며, 이로써 루트킷이 원래 운영 체제에 의해 만들어진 하드웨어 호출을 가로챌 수 있게 한다.[25] 일반적인 하이퍼바이저와는 달리, 이들은 운영 체제 전에 로드될 필요가 없고, 가상 머신에 프로모트하기 전에 운영 체제에 로드될 수 있다.[25] 하이퍼바이저 루트킷은 전복시키기 위해 대상의 커널을 수정할 필요가 없다; 하지만 이것이 게스트 운영 체제에 의해서 탐지될 수 없다는 것을 의미하지는 않는다. 예를 들면 CPU 명령어에서 시간 차이가 탐지될 수 있다.[25]

2009년에 마이크로소프트와 노스캐롤라이나 주립 대학교의 연구원들은 Hooksafe라고 불리는 하이퍼바이저 계층 안티 루트킷을 입증하였으며, 이것은 커널 모드 루트킷에 대한 일반적인 보호를 제공한다.[26]

윈도우 10은 "디바이스 가드"라고 불리는 새로운 특징을 도입하였으며, 이것은 루트킷 형식의 악성코드에 대한 운영 체제의 독립적인 외부 보호를 제공하기 위해 가상화의 장점을 이용한다.[27]

펌웨어와 하드웨어

[편집]

펌웨어 루트킷은 하드웨어에서 일관적인 악성코드 이미지를 생성하기 위해 라우터, 네트워크 카드,[28] 하드 디스크 드라이브 또는 시스템 바이오스[11] 같이 디바이스나 플랫폼 펌웨어를 사용한다. 펌웨어가 일반적으로 코드 무결성 검사가 이루어지지 않기 때문에 루트킷은 펌웨어에 숨는다.

설치와 은폐

[편집]

루트킷들은 시스템의 제어를 얻기 위해 다양한 기법들을 사용한다. 가장 일반적인 기법은 은밀한 권한 확대를 달성하기 위해 보안 취약점을 사용하는 것이다. 다른 접근법으로 컴퓨터 사용자가 루트킷의 설치 프로그램을 믿게하기 위해 트로이 목마를 사용하는 것이 있다.[13] 설치 작업은 만약 최소 권한 원칙이 적용되지 않았다면 더 쉬운데, 이것은 루트킷이 명시적으로 권한 확대를 요청할 필요가 없기 때문이다. 다른 종류의 루트킷은 오직 대상 시스템에 물리적으로 접근함으로써 설치될 수 있다. 어떤 루트킷은 사용자에 의해 직원 감시용으로 설치될 수도 있다.[29]

루트킷은 한번 설치되면 호스트 시스템 내에서 자신의 존재를 알리지 않기위한 수단으로 표준 운영 체제 보안 툴과 진단, 스캐닝, 감시를 위한 API들을 전복시키거나 회피하는 등의 동작을 수행한다. 루트킷들은 다른 프로세스들에 코드를 로딩하고 드라이버나 커널 모듈들을 설치하거나 수정하는 방식을 통해서 운영 체제의 중요한 부분의 행동을 수정함으로써 이것을 달성한다. 난독화 기법은 시스템 감시 메커니즘으로부터 실행 중인 프로세스들을 숨기고 시스템 파일들과 다른 설정 데이터를 숨기는 것을 포함한다.[30] 공격의 증거를 숨기기 위해 루트킷이 운영 체제의 이벤트 로깅 능력을 비활성화시키는 것은 흔하지는 않은 일이다. 이론적으로 루트킷들은 어떠한 운영 체제 활동도 전복시킬 수 있다.[31] "완벽한 루트킷"은 "완전범죄"로 여겨질 수 있다.

루트킷들은 또한 안티 바이러스 소프트웨어로부터 탐지되거 제거되는 것에 대한 생존을 위해 여러 방식을 사용하는데, 일반적으로 링 0(커널 모드)에 설치되는 것이 그것이다. 이곳은 시스템에 대한 완전한 접근이 가능하다. 이것들은 다형성, 은폐 기법, 재생, 안티 바이러스 소프트웨어 비활성화 같은 것들을 포함한다.[32] 그리고 연구자들에 의해서 쉽게 발견되고 분석될 수 있는 가상 머신에 설치되는 것을 거부하는 방식도 있다.

탐지

[편집]

루트킷을 발견하는데 근본적인 문제는 만약 운영 체제가 전복되었다면, 특히 커널 수준 루트킷에 의해서, 자신 또는 자신의 구성 요소들에게 비인가된 수정이 신뢰된다는 것이다.[31] 실행 중인 프로세스들의 목록이나 디렉토리의 파일을 요청하는 것 같은 행동은 예상과 같이 행동한다고 신뢰될 수 없다. 즉 감염된 시스템에서 동작 중인 루트킷 탐지기들은 단지 커널에서 루트킷보다 낮은 수준에서 실행될 때 탐지할 수 있다.[13] 컴퓨터 바이러스 같이 루트킷의 탐지와 제거는 이 때문에 더욱 힘들어지고 있다.[31]

탐지는 여러 가지 접근법을 가질 수 있는데 시그니처(안티 바이러스 소프트웨어), 무결성 검사(디지털 서명), 차이 기반 탐지(예상 결과와 실제 결과와의 비교) 그리고 행위 기반 탐지(CPU 사용이나 네트워크 트래픽 감시)가 있다. 커널 모드 루트킷들에서 탐지는 상당히 복잡한데, 악성코드가 시스템 행위를 전복시키는 곳에서 후킹된 함수들을 찾기 위한 시스템 호출 테이블과 숨겨진 프로세스들을 가리키는 패턴에 대한 메모리의 포렌식 스캐닝의 철저한 검토를 요구한다.

유닉스 루트킷 탐지는 Zeppoo[33], chkrootkit, rkhunter 그리고 OSSEC를 제공한다. 윈도우에서, 탐지 툴들로는 마이크로소프트 시스인터널스 RootkitRevealer,[34] 어베스트! 안티바이러스, Sophos 안티-루트킷,[35] F-시큐어,[36] Radix,[37] GMER,[38] 그리고 WindowsSCOPE가 있다.

의심되는 운영 체제가 가동중이지 않을 때 저장소를 검사함으로써 탐지하는 것은 루트킷이 활성화되지 않아서 루트킷을 인식하는 것을 실패할 수 있다. 가동중인 루트킷과 함께 돌아가는 일반적인 안티 바이러스 소프트웨어는 루트킷이 자신을 효과적으로 숨기면 실패할 수 있다.

대안이 되는 신뢰되는 매체

[편집]

운영 체제 수준 루트킷을 탐지하는 가장 신뢰되는 방법은 의심되는 컴퓨터를 끄고 대안이 되는 신뢰되는 매체(CD-ROM, USB 플래스 드라이브)에서 부팅함으로써 이것의 저장소를 검사하는 것이다.[39] 이 기법은 루트킷이 자신이 실행 중이지 않을 때에는 자신의 존재를 숨길 수 없기 때문에 효과적이다.

행위 기반

[편집]

루트킷을 탐지하기 위한 행위 기반 접근법은 루트킷이라고 여겨질만한 행동을 찾음으로써 루트킷의 존재를 추론할 수 있다. 예를 들면 시스템을 프로파일링하고 전체 CPU 활용에서 API 호출의 빈도와 타이밍이 다를 때 루트킷으로 여겨질 수 있다. 이 방식은 복잡하고 긍정 오류의 높은 발생으로 방해받는다. 루트킷을 처리하는 것은 종종 시스템에 매우 명백한 변화를 줄 수 있다. Alureon 루트킷은 코드에 설계 결함을 가진 보안 업데이트 이후 윈도우 시스템을 충돌시켰다.[40][41]

패킷 분석기, 방화벽, 침입 차단 시스템에서의 로그는 네트워크 환경에서 루트킷 행위의 증거를 보여줄 수 있다.[10]

시그니처 기반

[편집]

비록 보안 소프트웨어 벤더들이 루트킷 탐지를 위해 제품에 추가하여도 안티바이러스 제품들은 공개 테스트에서 모든 바이러스들을 잡아내지는 못한다. 루트킷은 안티바이러스 스캔 시에 숨겨지려 하며 은폐 탐지기는 알아챌 수 있다. 만약 루트킷이 임시적으로 자신을 시스템에서 언로드시킨다면 시그니처 탐지는 찾아낼 수 있을 것이다. 이 결합된 접근법은 공격자가 대응 메커니즘을 구현하게 했는데 이것은 안티바이러스 프로그램을 종료시키는 것이다. 시그니처 기반 탐지 방식들은 공개된 루트킷에는 효과적이지만, 특별히 커스톰화된 루트킷들에는 약한 경향이 있다.[31]

차이 기반

[편집]

루트킷을 탐지하는 다른 방식으로는 "신뢰된" raw 데이터와 API가 반환하는 "오염된" 내용을 비교하는 것이다. 예를 들면 디스크에 존재하는 바이너리들은 메모리의 복사본과 비교될 수 있거나 파일 시스템 또는 윈도우 레지스트리 API에서 나온 결과들은 물리 디스크에서의 raw 구조와 함께 검사될 수 있다[31]—그러나, 전자의 경우 몇몇 유효한 차이점들은 메모리 재배치 같은 운영 체제 메커니즘에 의해서 도입될 수도 있다. 루트킷은 이러한 차이 기반 스캐너나 가상 머신의 존재를 탐지하고, 자신의 행동을 차이없게 해서 탐지되지 않게 할 수도 있다. 차이 기반 탐지는 소니 DRM 루트킷을 탐지하기 위한 마크 러시노비치의 RootkitRevealer 툴에서 사용되었다.[1]

무결성 검사

[편집]
rkhunter 유틸리티는 SHA-1 해시들을 사용해서 시스템 파일들의 무결성을 검증한다.

코드 사이닝은 파일이 배포자에 의해 디지털 서명화된 이후로 수정되었는지를 검증하기 위해서 공개 키 기반 구조를 사용한다. 대체적으로, 시스템 소유자나 관리자는 디스크의 코드 라이브러리들에 대한 비인가된 변화를 탐지하기 위해 암호화 해시 함수를 사용할 수도 있다.[42] 그러나 정교하지 않은 방식들은 단지 코드가 설치 이후로 변경되었는지만 검사한다. 핑거프린트는 반드시 각 시간의 변화를 설정해야 한다. 해쉬 함수는 메시지 다이제스트를 생성하는데, 이것은 파일의 각 비트에서 계산된 상대적으로 짧은 코드이다. 설치된 파일의 메시지 다이제스트를 재계산하고 비교하는 것은 탐지되고 감시될 수 있다. 더 정교한 루트킷들은 디스크가 아니라 메모리에서 코드를 수정함으로써 이 검증 과정을 전복시킬 수 있다. 이 기법은 그러므로 단지 정교하지 않은 루트킷에 효과적이다.

비슷하게 펌웨어에서의 탐지는 펌웨어의 암호화 해시를 계산하고 이것을 예상되는 값들의 화이트리스트와 비교하거나, 해시 값을 TPM(신뢰 플랫폼 모듈) 설정 레지스터(이후에 기대 값의 화이트리스트와 비교되는)로 확장함으로써 달성될 수 있다.[43] 해시, 비교 또는 확장 연산을 수행하는 코드는 반드시 보호되어야 한다. 이 문맥에서 immutable root-of-trust 의 개념은 가장 처음 코드를 가지고 자신의 가장 기초 수준에서 루트킷 또는 부트킷이 시스템과 타협하지 않게 하는 것을 보장하게 하기 위한 시스템의 보안 속성을 측정한다.[44]

메모리 덤프

[편집]

가상 메모리의 완전한 덤프를 가능하게 하는 것은 활성화된 루트킷(또는 커널 모드 루트킷의 경우 커널 덤프)을 잡게하고, 결과 덤프 파일에 대해 오프라인 포렌식 분석을 디버거로 수행할 수 있게 한다. 여기서 루트킷은 자신을 은폐할 수 없다. 이 기법은 고도로 전문적이며 공개되지 않은 소스 코드나 디버그 심볼에 대한 접근을 요구한다. 운영 체제에 의해 초기화된 메모리 덤프들은 항상 메모리를 읽기 위한 가장 낮은 수준의 시도를 가로채고 전복시키는 하이퍼바이저 기반 루트킷을 탐지하는데 사용될 수 없다.[25] 마스크할 수 없는 인터럽트를 구현하는 것 같은 하드웨어 장치는 이 시나리오에서 덤프 메모리를 요구할 수 있다.[45][46] 하이퍼바이저 아래의 가상 머신들 또한 위태로운 머신의 메모리를 분석하는 것을 쉽게할 수 있어서, 몇몇 루트킷들은 이 이유로 가상 머신을 감염시키는 것을 피한다.

제거

[편집]

루트킷을 직접 제거하는 것은 일반 컴퓨터 사용자들에게 매우 어렵지만,[11] 많은 보안 소프트웨어 벤더들이 자동으로 루트킷을 탐지하고 제거하는 툴들을 제공한다. 2005년, 마이크로소프트의 월간 윈도우 악성 소프트웨어 제거 툴이 몇몇 종류의 루트킷들을 탐지하고 제거할 수 있게 되었다.[47][48] 몇몇 안티바이러스 스캐너들은 루트킷에 의해 조작될 수 있는 취약점을 가진 파일 시스템 API들을 우회할 수 있다. 대신 이것들은 raw 파일시스템 구조에 직접적으로 접근하고, 루트킷에 의해 유발되는 어떤 차이점도 식별하기 위해 이 정보를 시스템 API의 결과를 유효화하는데 사용한다.[49][50][51][52]

루트킷을 제거하는 신뢰성있는 유일한 방법은 운영 체제를 신뢰되는 매체에서 재설치하는 것이라고 믿는 전문가들이 있다.[53] 이것은 감염된 시스템에서 실행 중인 안티바이러스와 악성코드 제거 툴들이 잘 쓰여진 커널 모드 루트킷들에는 효과적이지 않기 때문이다. 신뢰되는 매체에서 대체 운영 체제를 부팅하는 것은 감염된 시스템 볼륨이 마운트되고 잠재적으로 안전하게 제거되었으며 중요한 데이터가 복사되었다는 것이다. 또는 대안으로 포렌식 검사가 수행되었거나.[10] 윈도우 사전 설치 환경 같은 경량 운영 체제들은 이 목적으로 사용될 수 있으며 시스템을 깨끗하게 해준다.

비록 루트킷의 본성과 종류가 알려졌지만, 직접 이것을 복구하는 것은 비현실적이며, 운영 체제를 재설치하는 것이 훨씬 쉽고 빠르다.[53]

대중적 이용 가능성

[편집]

공격자에게 사용되는 악성코드들처럼, 많은 루트킷 구현들은 인터넷에서 공유되고 쉽게 사용 가능하다.[10]

대부분의 루트킷들은 인터넷에서 기반한 컴퓨터 시스템에서 숨기고, 비인가된 제어를 하는 것을 입증하기 위한 익스플로잇 또는 학문적으로 "개념 증명"으로서 사용 가능하다.[54] 종종 은폐를 위해 완벽하게 최적화되지 않은 루트킷들은 자신의 존재에 대한 의도치 않은 증거를 남겨놓는다. 그렇더라도, 이러한 루트킷들이 공격에 사용될 때는 매우 효과적일 수 있다.

방어

[편집]

루트킷이 설치되는 것을 막는 시스템 하드닝은 루트킷을 방어하는 첫번째 계층 중 하나이다.[55] 보안 패치, 최소 권한 원리 등은 모든 종류의 악성코드를 막는데 효과적인 방식이다.[56]

통일 확장 펌웨어 인터페이스 같은 새로운 보안 부트 명세는 부트킷의 위협 때문에 설계되었지만, 자신이 제공하는 특징이 사용되지 않는다면 더 취약하다.[57]

서버 시스템에서 원격 서버 증명은 서버를 좋은 상태로 유지시키는 효과적인 방법이다.

같이 보기

[편집]
위키미디어 공용에 관련된
미디어 분류가 있습니다.

각주

[편집]
  1. ↑ 가 나 다 “Rootkits, Part 1 of 3: The Growing Threat” (PDF). 맥아피. 2006년 4월 17일. 2006년 8월 23일에 원본 문서 (PDF)에서 보존된 문서. 2016년 2월 8일에 확인함. 
  2. ↑ http://www.technibble.com/how-to-remove-a-rootkit-from-a-windows-system/
  3. ↑ 가 나 Greg Hoglund, James Butler (2006). 《Rootkits: Subverting the Windows kernel》. Addison-Wesley. 4쪽. ISBN 0-321-29431-9. 
  4. ↑ Russinovich, Mark (June 2005). “Unearthing Root Kits”. 《Windows IT Pro》. 2012년 9월 18일에 원본 문서에서 보존된 문서. 2010년 12월 16일에 확인함. 
  5. ↑ “World of Warcraft Hackers Using Sony BMG Rootkit”. The Register. 2005년 11월 4일. 2012년 9월 17일에 원본 문서에서 보존된 문서. 2010년 8월 23일에 확인함. 
  6. ↑ Steve Hanna (September 2007). “Using Rootkit Technology for Honeypot-Based Malware Detection” (PDF). CCEID Meeting. 
  7. ↑ Russinovich, Mark (2006년 2월 6일). “Using Rootkits to Defeat Digital Rights Management”. 《Winternals》. SysInternals. 2006년 8월 14일에 원본 문서에서 보존된 문서. 2006년 8월 13일에 확인함. 
  8. ↑ Ortega, Alfredo; Sacco, Anibal (2009년 7월 24일). 《Deactivate the Rootkit: Attacks on BIOS anti-theft technologies》 (PDF). Black Hat USA 2009 (PDF). Boston, MA: Core Security Technologies. 2014년 6월 12일에 확인함. 
  9. ↑ Kleissner, Peter (2009년 9월 2일). “Stoned Bootkit: The Rise of MBR Rootkits & Bootkits in the Wild” (PDF). 2011년 7월 16일에 원본 문서 (PDF)에서 보존된 문서. 2010년 11월 23일에 확인함. 
  10. ↑ 가 나 다 라 Anson, Steve; Bunting, Steve (2007). 《Mastering Windows Network Forensics and Investigation》. John Wiley and Sons. 73–74쪽. ISBN 0-470-09762-0. 
  11. ↑ 가 나 다 라 “Rootkits Part 2: A Technical Primer” (PDF). 맥아피. 2007년 4월 3일. 2008년 12월 5일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 17일에 확인함. 
  12. ↑ Kdm. “NTIllusion: A portable Win32 userland rootkit”. 《프랙》 62 (12). 2012년 9월 12일에 원본 문서에서 보존된 문서. 2016년 6월 8일에 확인함. 
  13. ↑ 가 나 다 라 “Understanding Anti-Malware Technologies” (PDF). 마이크로소프트. 2007년 2월 21일. 2010년 9월 11일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 17일에 확인함. 
  14. ↑ Butler, James; Sparks, Sherri (2005년 11월 16일). “Windows Rootkits of 2005, Part Two”. 《Symantec Connect》. 시만텍. 2012년 9월 11일에 원본 문서에서 보존된 문서. 2010년 11월 13일에 확인함. 
  15. ↑ Butler, James; Sparks, Sherri (2005년 11월 3일). “Windows Rootkits of 2005, Part One”. 《Symantec Connect》. 시만텍. 2012년 9월 12일에 원본 문서에서 보존된 문서. 2010년 11월 12일에 확인함. 
  16. ↑ “Windows Rootkit Overview” (PDF). 시만텍. 2006년 3월 26일. 2010년 12월 14일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 17일에 확인함. 
  17. ↑ Burdach, Mariusz (2004년 11월 17일). “Detecting Rootkits And Kernel-level Compromises In Linux”. 시만텍. 2012년 9월 13일에 원본 문서에서 보존된 문서. 2010년 11월 23일에 확인함. 
  18. ↑ Marco Giuliani (2011년 4월 11일). “ZeroAccess – An Advanced Kernel Mode Rootkit” (PDF). Webroot Software. 2011년 8월 10일에 확인함. 
  19. ↑ “Driver Signing Requirements for Windows”. 마이크로소프트. 2012년 5월 30일에 원본 문서에서 보존된 문서. 2008년 7월 6일에 확인함. 
  20. ↑ Soeder, Derek; Permeh, Ryan (2007년 5월 9일). “Bootroot”. eEye Digital Security. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2010년 11월 23일에 확인함. 
  21. ↑ Schneier, Bruce (2009년 10월 23일). “'Evil Maid' Attacks on Encrypted Hard Drives”. 2012년 9월 11일에 원본 문서에서 보존된 문서. 2009년 11월 7일에 확인함. 
  22. ↑ Kumar, Nitin; Kumar, Vipin (2007). 《Vbootkit: Compromising Windows Vista Security》 (PDF). Black Hat Europe 2007. 
  23. ↑ “BOOT KIT: Custom boot sector based Windows 2000/XP/2003 Subversion”. 《NVlabs》. 2007년 2월 4일. 2010년 6월 10일에 원본 문서에서 보존된 문서. 2010년 11월 21일에 확인함. 
  24. ↑ Scambray, Joel; McClure, Stuart (2007). 《Hacking Exposed Windows: Windows Security Secrets & Solutions》. McGraw-Hill Professional. 371–372쪽. ISBN 0-07-149426-X. 
  25. ↑ 가 나 다 라 Myers, Michael; Youndt, Stephen (2007년 8월 7일). “An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits”. Crucial Security. CiteSeerX: 10.1.1.90.8832. 
  26. ↑ Wang, Zhi; Jiang, Xuxian; Cui, Weidong; Ning, Peng (2009년 8월 11일). 〈Countering Kernel Rootkits with Lightweight Hook Protection〉 (PDF). Al-Shaer, Ehab (General Chair). 《Proceedings of the 16th ACM Conference on Computer and Communications Security》. CCS 2009: 16th ACM Conference on Computer and Communications Security. Jha, Somesh; Keromytis, Angelos D. (Program Chairs). New York: ACM New York. doi:10.1145/1653662.1653728. ISBN 978-1-60558-894-0. 2009년 11월 11일에 확인함. 
  27. ↑ https://msdn.microsoft.com/en-us/library/dn986865(v=vs.85).aspx
  28. ↑ Delugré, Guillaume (2010-11-21)
  29. ↑ Ric Vieler (2007). 《Professional Rootkits》. John Wiley & Sons. 244쪽. ISBN 9780470149546. 
  30. ↑ Brumley, David (1999년 11월 16일). “Invisible Intruders: rootkits in practice”. 《USENIX》. USENIX. 2012년 5월 27일에 원본 문서에서 보존된 문서. 2008년 2월 25일에 확인함. 
  31. ↑ 가 나 다 라 마 Davis, Michael A.; Bodmer, Sean; LeMasters, Aaron (2009년 9월 3일). 〈Chapter 10: Rootkit Detection〉 (PDF). 《Hacking Exposed Malware & Rootkits: Malware & rootkits security secrets & solutions》 (PDF). New York: McGraw Hill Professional. ISBN 978-0-07-159118-8. 2012년 3월 8일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 14일에 확인함. 
  32. ↑ Trlokom (2006년 7월 5일). “Defeating Rootkits and Keyloggers” (PDF). Trlokom. 2011년 7월 17일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 17일에 확인함. 
  33. ↑ “Zeppoo”. 소스포지. 2009년 7월 18일. 2012년 7월 19일에 원본 문서에서 보존된 문서. 2011년 8월 8일에 확인함. 
  34. ↑ Cogswell, Bryce; Russinovich, Mark (2006년 11월 1일). “RootkitRevealer v1.71”. 마이크로소프트. 2012년 6월 4일에 원본 문서에서 보존된 문서. 2010년 11월 13일에 확인함. 
  35. ↑ “Sophos Anti-Rootkit”. Sophos. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2011년 8월 8일에 확인함. 
  36. ↑ “BlackLight”. F-Secure. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2011년 8월 8일에 확인함. 
  37. ↑ “Radix Anti-Rootkit”. usec.at. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2011년 8월 8일에 확인함. 
  38. ↑ “GMER”. 2012년 8월 2일에 원본 문서에서 보존된 문서. 2011년 8월 8일에 확인함. 
  39. ↑ Harriman, Josh (2007년 10월 19일). “A Testing Methodology for Rootkit Removal Effectiveness” (PDF). Dublin, Ireland: Symantec Security Response. 2009년 10월 7일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 17일에 확인함. 
  40. ↑ Cuibotariu, Mircea (2010년 2월 12일). “Tidserv and MS10-015”. 시만텍. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2010년 8월 19일에 확인함. 
  41. ↑ “Restart Issues After Installing MS10-015”. 마이크로소프트. 2010년 2월 11일. 2012년 7월 7일에 원본 문서에서 보존된 문서. 2010년 10월 5일에 확인함. 
  42. ↑ “Signing and Checking Code with Authenticode”. 마이크로소프트. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2008년 9월 15일에 확인함. 
  43. ↑ “Stopping Rootkits at the Network Edge” (PDF). Beaverton, Oregon: Trusted Computing Group. January 2007. 2008년 7월 11일에 확인함. 
  44. ↑ “TCG PC Specific Implementation Specification, Version 1.1” (PDF). Trusted Computing Group. 2003년 8월 18일. 2010년 11월 22일에 확인함. 
  45. ↑ “How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system”. 마이크로소프트. 2012년 7월 20일에 원본 문서에서 보존된 문서. 2010년 11월 13일에 확인함. 
  46. ↑ Seshadri, Arvind; 외. (2005). “Pioneer: Verifying Code Integrity and Enforcing Untampered Code Execution on Legacy Systems”. 카네기 멜런 대학교. 
  47. ↑ Dillard, Kurt (2005년 8월 3일). “Rootkit battle: Rootkit Revealer vs. Hacker Defender”. 2012년 7월 13일에 원본 문서에서 보존된 문서. 2016년 6월 8일에 확인함. 
  48. ↑ “The Microsoft Windows Malicious Software Removal Tool helps remove specific, prevalent malicious software from computers that are running Windows 7, Windows Vista, Windows Server 2003, Windows Server 2008, or Windows XP”. 마이크로소프트. 2010년 9월 14일. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2010년 10월 17일에 확인함. 
  49. ↑ Hultquist, Steve (2007년 4월 30일). “Rootkits: The next big enterprise threat?”. 《InfoWorld》 (IDG). 2012년 9월 21일에 원본 문서에서 보존된 문서. 2010년 11월 21일에 확인함. 
  50. ↑ “Security Watch: Rootkits for fun and profit”. CNET Reviews. 2007년 1월 19일. 2012년 7월 18일에 원본 문서에서 보존된 문서. 2009년 4월 7일에 확인함. 
  51. ↑ Bort, Julie (2007년 9월 29일). “Six ways to fight back against botnets”. 《PC 월드》. San Francisco: PCWorld Communications. 2012년 9월 7일에 원본 문서에서 보존된 문서. 2009년 4월 7일에 확인함. 
  52. ↑ Hoang, Mimi (2006년 11월 2일). “Handling Today's Tough Security Threats: Rootkits”. 《Symantec Connect》. 시만텍. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2010년 11월 21일에 확인함. 
  53. ↑ 가 나 Danseglio, Mike; Bailey, Tony (2005년 10월 6일). “Rootkits: The Obscure Hacker Attack”. Microsoft. 2012년 9월 21일에 원본 문서에서 보존된 문서. 2016년 2월 10일에 확인함. 
  54. ↑ Stevenson, Larry; Altholz, Nancy (200). 《Rootkits for Dummies》. John Wiley and Sons Ltd. 175쪽. ISBN 0-471-91710-9. 
  55. ↑ Skoudis, Ed; Zeltser, Lenny (2004). 《Malware: Fighting Malicious Code》. Prentice Hall PTR. 335쪽. ISBN 0-13-101405-6. 
  56. ↑ Hannel, Jeromey (2003년 1월 23일). “Linux RootKits For Beginners - From Prevention to Removal”. SANS Institute. 2010년 10월 24일에 원본 문서 (PDF)에서 보존된 문서. 2010년 11월 22일에 확인함. 
  57. ↑ http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/

더 읽어보기

[편집]
  • Blunden, Bill (2009). 《The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System》. Wordware. ISBN 978-1-59822-061-2. 
  • Hoglund, Greg; Butler, James (2005). 《Rootkits: Subverting the Windows Kernel》. Addison-Wesley Professional. ISBN 0-321-29431-9. 
  • Grampp, F. T.; Morris, Robert H., Sr. (October 1984). “The UNIX System: UNIX Operating System Security”. 《AT&T Bell Laboratories Technical Journal》 (AT&T) 62 (8): 1649–1672. 
  • Kong, Joseph (2007). 《Designing BSD Rootkits》. No Starch Press. ISBN 1-59327-142-5. 
  • Veiler, Ric (2007). 《Professional Rootkits》. Wrox. ISBN 978-0-470-10154-4. 

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=루트킷&oldid=37480508"