Code1018

* 이 글은 SK Infosec의 오픈소스 소프트웨어 보안가이드를 참조하여 작성하였습니다.

Node.js Security

1. 데몬 관리

1.1 root 권한 실행 금지

  Node.js로 서버를 구동시켰을 때, root 권한으로 실행하면 안된다. root 권한으로 구동된 서버의 경우 취약점으로 인해 Exploit 당해 실행 권한을 넘겨주었을 때 그 권한이 root일 경우 상황이 심각해지기 때문이다.

1.2 요청을 전달할 HTTP 서버/proxy 형태로 구성

  Apache, nginx 등과 같은 HTTP 서버를 통해 요청을 받아 전달하도록 구성해야한다.

1.3 NODE_ENV 설정을 production으로 설정

  개발 당시 develpoment로 설정하여 개발 할 수 있는데, 서비스를 시작할 때 이를 깜빡하여 그대로 서비스를 구동하는 경우가 있다. 이럴 경우 에러에 관해 상세한 정보가 출력되기 때문에 이를 이용해 공격자들이 활용할 수 있다.

* 진단 방법

2. 로그 디렉토리/파일 권한 설정

  로그 파일에 공격자에게 유용한 정보가 들어있다. 그래서 권한관리가 필요하며 일반 사용자들이 접근하지 못하도록 권한을 설정한다.

2.1 권한 설정

  권한은 WAS 서버 계정 소유여야하며, 디렉토리는 750(drwxr-x---) 파일은 640(-rw-r-----) 권한으로 설정해야한다.

* 진단 방법

3. 로그 포맷 설정

  로그 포맷을 설정하지 않으면 침해사고 발생 시 공격 여부 파악, 공격자 사용 툴 파악, 공격자 위치 파악이 불가능하다. 그러므로 필요한 정보들로 로그 포맷을 설정해두어야한다.

* Node의 기본 console.log 또는 Express 4.x 이전 버전으로 지원 가능한 로그 출력 기능 외 morgan 등의 추가 로거 모듈을 사용하는 경우 해당되며, 파일의 형태가 아닌 콘솔 출력을 의미함. 어플리케이션 코드 내에서 제어하는 형태로 사용.

3.1 모든 요청에 대해 combined 포맷의 로그를 출력하도록 설정

combined : 표준 Apache combined 로그 출력 

common : 표준 Apache common 로그 출력

dev : 개발을 위해 response에 따라 색상이 입혀진 축약 로그 출력 

short : 기본 설정보다 짧은 로그 출력, 응답 시간 포함 

tiny : 최소화된 로그 출력 

* 사전에 morgan 모듈을 설치했다고 가정했다.

* 진단 방법

  소스 코드 내 log 내용 확인 또는 개발자 인터뷰

  로그포맷 설정 값이 combined가 아니거나 그에 준하지 않는 포맷 토큰 조함으로 설정되어 있는 경우 취약함.

4. 로그 저장 주기

  ‘정보통신망이용촉진및정보보호등에관한법률’, ‘개인정보보호법’, ‘회사사규’ 등에 따라 로그 파일은 최소 6개월 이상의 기간은 보관해야한다. 또한 담당자는 로그 기록을 정기적으로 백업 및 확인 감독!

 4.1 정보 보호 관련 법 및 개인정보보호법 등에 따라 최소 아래 기간 이상은 보관해야한다.

1) 사용자접속 기록

사용자 로그인/로그아웃/정보변경 등 -> 6개월 이상

2) 개인정보취급자의개인정보처리시스템접속기록

정보주체 식별정보/개인정보취급자 식별정보/ 접속일시/접속지 정보/ 부여된 권한 유형에 따른 수행업무 등 -> 2년 이상

3) 개인정보취급자권한변경기록 

개인정보취급자 권한 생성/변경/삭제 등 -> 5년 이상

4.2 담당자는 접속 기록을 월 1회 이상 정기적으로 확인·감독하여, 접속과 관련 된 오류 및  부정행위가 발생하거나 예상 되는 경우 즉각적인 보고 조치가 되도록 해야 한다.

4.3 접속 기록이 위·변조 되지 않도록 별도의 물리적인 저장 장치에 보관하여야 하며  정기적인 백업을 수행 해야 한다.

* 진단 방법

  서버 운영 또는 담장자 인터뷰

5. 헤더 노출 정보 방지

  HTTP 요청에 대한 응답 시 헤더에 서버 이름, 버전 등의 정보가 포함되어 공격자가 해당 정보를 공격에 이용할 수 있다.

* Node의 헤더 관련 개별 설정 방법 외 helmet과 보안 관련 HTTP 헤더 모듈을 사용한 경우엥 해당된다.

5.1 Node 어플리케이션 코드 내에 모듈 사용 설정 

  위 설정은 Apache, nginx 등의 웹 서버 환경 설정을 통해서도 같은 설정이 가능하다.

* 진단 방법

  소스 코드 내 헤더 설정 관련 확인 또는 개발자 인터뷰

* 보안 패치

  최신의 보안 패치 필요. Node.js 뿐 아니라 추가한 Express 모듈 또한 패치에 신경 써야한다. 주기적으로 보안 패치를 적용하지 않으면 exploit 공격, 제로데이 공격 등의 서버 침해가 발생할 수 있다.

* Node.js 0.10.42 이전 0.10.x, 0.12.10 이전 0.12.x, 4.3.0 이전 4.x, 5.6.0 이전 5.x 버전들에서 원격 공격자의 조작된 Content-Length HTTP 헤더를 통한 HTTP request smuggling 공격을 허용할 수 있다.

(* HTTP Request Smuggling 공격은 Web Hacking 카테고리에 글을 포스팅 하였다. ) 

HTTP Request Smuggling

Normaltic 작성

HTTP Request Smuggling (HRS) 란?

HTTP의 Content-Length 헤더 변수를 조작하여 원하는 데이터 혹은 패킷을 Smuggling(밀수) 몰래 들여보내는 것이다. 이 공격을 통해 웹 서버 앞의 방화벽(F/W)을 우회하거나, 웹 캐시 서버의 Cache-Poisoning 등을 할 수 있다.

* 본 자료는 http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf 을 참조하여 작성하였다.

(1) Web Cache Poisoning

  이 공격을 가능하게 하는 취약점은 바로 HTTP의 Post 패킷에 Content-Length 헤더가 2개가 들어있을 때 받아들이는 방식이 웹 캐시 서버(Proxy)와 웹 서버(W/S)가 다르다는 점이다.

-> 그렇다면 HTTP Post 패킷에 Content-Length 헤더가 다른 값으로 2개 들어가있으면 서버는 어떻게 처리할까?

이는 서버마다 다 다르다. 예를 들면, SunONE W/S 6.1 (SP1)의 경우 첫 번째의 Content-Length 헤더를 사용한다. 반대로 SunONE Proxy 3.6 (SP4)의 경우 두 번째의 Content-Length 헤더를 사용한다.

위와 같은 차이로 인해 악의적인 Web Cache Poisoning이 가능하다. SunONE W/S 6.1 (SP1)의 서버 앞에 SunONE Proxy 3.6 (SP4)가 Proxy 서버로 있으며 SITE라는 DNS 주소를 가진 서버라고 가정하고 공격해보겠다.

< 공격 모습 >

  위와 같은 패킷들이 서버에 전달 되었을 때, Proxy 서버의 경우 1-7 번 라인을 POST Request라고 먼저 인식하게 된다. 그리고 Content-Length 헤더가 두 개 있다는 것을 알게 되는데 여기서 Proxy서버의 경우 첫 번째 Content-Length 헤더를 무시하고 두 번째의 Content-Length 헤더를 사용하여 Body의 길이가 44라고 인식하게 된다. 여기서 8-10 번 라인이 정확하게 44 바이트이다. 그러므로 8-10 번 라인을 첫 번째 POST 패킷의 Body라고 인식하게 되는 것이다. 그 다음으로 Proxy 서버는 11-14 번 라인을 GET Request로 인식한다.

  이제 웹서버의 경우를 보자. 웹 서버의 경우 Proxy 서버와 달리 첫 번째 Content-Length 헤더를 사용한다. 그래서 Body 길이가 0이라고 인식한다. 그렇게 되면 8번부터 새로운 GET 요청으로 인식하게 되는 것이다. 여기서 주목할 점은 10번 라인 다음에 CRLF 이 없다는 것이다. 그렇기 때문에 11번 라인이 새로운 GET Request로 인식되지 않고 8번 라인의 GET Request 패킷의 Bla 헤더의 값으로 인식 되는 것이다.

  정리해보면 다음 표와 같다.

< 정리 >

  Proxy와 Web 서버에서 둘 모두 2개의 Request가 왔다고 인식한다. 하지만 그 2개의 내용이 다르다. 어떤 2개의 Request인지는 위의 표로 정리하였고 내용은 다음과 같다.

  Proxy에서 2번 째 Request는 “http://SITE/page to poison.html”을 요청한다고 인식하였고, Web 서버에서 2번째 Request는 “/poison.html”을 요청한다고 인식하였다. Web 서버는 “/poison.html” 요청의 결과를 돌려주는데 이 때 Proxy 서버가 이를 캐싱해 둔다면 Proxy 서버는 “http://SITE/page to poison.html” 요청과 “/poison.html”의 결과를 매칭시켜 저장하게 된다.

* 더 강력하게 효과 보는 경우

  만약 서버가 가상 호스팅하고 있는 경우라면, 효과가 더 강력할 수 있다. IP는 같으므로 HTTP 패킷 안에 host 헤더만 다시 설정하므로써 다른 많은 사이트들에 대해 공격을 할 수 있다.

  이를 통해 악의적으로 Web Cache를 조작할 수 있게 된다. 이 것이 Web Cache Poisoning의 공격에 활용 될 수 있는 방법이다.

(2) Firewall/IPS/IDS 우회

방화벽이나 IPS, IDS의 경우 특징 기반으로 악성 패킷을 검출한다. 예를 들어 “cmd.exe”라는 문자열이 URL에 들어가 있다거나 하는 특징들이 있다. 혹은 SQL Injection에서 사용하는 특징들을 생각해 볼 수 있다.

이 자료에서 보여주는 공격은 IIS/5.0 기반 서버에서 이루어진다. ISS/5.0는 큰 Body를 가진 POST Request를 처리할 때 버그가 일어난다. 바로, Request에 Content-Type헤더에 정해진 타입이 아닌 경우 49,152 Bytes(48K) 만큼 잘라서 읽는다. 그래서 48K + X 의 크기로 보내게 되면 X 만큼의 데이터를 Smuggling할 수 있게 된다.

아래 공격 예시는 ISS/5.0 서버이고 앞 단에 Firewall이 설치 되어있는 경우이다. 공격 목적은 Firewall을 우회하여 서버에 “cmd.exe” 문자열이 도착하게 하는 것이다.

< 공격 패킷 >

  위와 같은 모습으로 패킷을 전달하게 되면, Firewall 입장에서는 첫 번째 Request를 49223 Byte 크기의 Body를 가지고 있다고 인식하게 된다. 위에서 보면 10번 라인 까지를 첫 번째 Request로 인식한다. 그 다음 Firewall은 두 번째 Request를 11번 라인부터 인식하게 되는데 주목할 점은 12번 라인이다. 12번 라인 뒤에 CRLF가 없다. 그렇기 때문에 13번라인부터가 두 번째 Request의 Bla헤더의 값에 포함되어 인식되는 것이다. 그렇게 되면 Firewall은 이 2가지 패킷을 막지 않는다. 이유는 URL에 공격 패턴이 없었기 때문이다.

  하지만 Firewall을 지나서 서버에 도착하면 상황이 달라진다. IIS/5.0 서버에서 첫 번째 Request를 보면 Content-Type이 없다. 그렇기 때문에 서버는 49152 크기로 Body를 잘라버린다. 그러면 1-6번 라인이 첫 번째 Request로 인식 되는 것이다. 그리고 두 번째 Request로 7번 라인부터 인식이 되는데, Content-Length가 30으로 되어있다. 그래서 Body로 11-12번 라인이 포함된다. 그렇게 되면 서버 입장에서는 다음 Request가 13번부터 받아들이게 되는데 13-15번 라인의 Request를 보면 URL에 “cmd.exe” 문자열이 있는 것을 확인 할 수 있다. 그렇게 되면 서버 입장에서는 “cmd.exe”를 실행되어 공격이 이루어 질 수 있다. 인식하는 Request를 정리해보면 아래 표와 같다.

< 정리 >

(3) Forward VS Backward HRS

일반적으로 HRS 공격은 3개의 Request를 보내는데, Content-Length를 조작하여 각각 다른 2개의 Request로 보이게 하는 원리로 공격이 일어난다. 첫 번째 예에서는 req1, req2를 웹 서버가 인식하고, req1, req3을 Proxy가 인식하므로써 공격이 일어났는데, 이러한 경우를 Forward Smuggling이라고 한다.

< Forward Smuggling >

  이와 반대로 Backward Smuggling이 있다.

< Backward Smuggling >

  Forward Smuggling보다 Backward Smuggling 공격이 훨씬 어렵다. 그 이유는 Proxy가 Request를 받고 웹 서버에 전달하는데 그에 대한 응답을 받을 때 까지 다음 Request를 보내지 않기 때문이다. 이럴 경우 Proxy는 첫 번째 Request라고 인식하여 보내고 그에 대한 응답을 기다리는데 웹 서버의 경우 Request가 다 도착하지 않았으므로 기다리게 된다. 그러면 Deadlock에 빠지게 된다. 이렇게 보면 이론적으로 Backward Smuggling이 불가능한 것처럼 보인다. 하지만 예외의 경우가 있다.

  이번 예시는 DeleGate/8.9.2 캐시 서버를 사용한다. 그리고 웹 서버로는 IIS/6.0, Tomcat, SunONE 서버 등을 사용할 수 있다. 이번 트릭은 바로 이 것이다. 우리는 GET Request를 사용할 것이다. 그런데 이 GET Request에 Content-Length 헤더와 값을 넣어서 보낼 것이다. DeleGate는 GET Request의 Content-Length를 0이라고 생각한다. 즉, Body가 없다고 생각하는 것이다. (실제로 GET에는 Body가 없다.) 반대로 웹 서버는 Content-Length 값 만큼의 Body가 있는 Request라고 생각한다. 그렇지만 웹 서버는 Body를 받기 전에 응답을 보내준다. 바로 이 점에서 Backward Smuggling이 가능한 것이다. 웹 서버는 Body가 있는 Request라고 생각하지만, GET 요청이므로 Body부분이 도착하기 전에 응답을 보내는 것이다.

  공격 예시는 다음과 같다.

< Backward Smuggling >

  위의 패킷을 보내게 되면, DeleGate는 Content-Length 헤더를 무시한다. 이유는 GET 요청이기 때문이다. 첫 번째 요청을 1-6 번 라인이라고 인식한다. 그 후 7-10번 라인 까지를 두 번째 요청이라고 생각한다. 이유는 8번 라인 다음에 CRLF가 나오지 않았기에 9-10번 라인이 Bla 헤더의 값이라고 생각하기 때문이다. 이와 반대로 웹 서버에서는 첫 번째 요청이 40 바이트 크기의 Body를 가진 요청이라고 생각한다. 그렇기에 1-6번 라인까지 받았을 때 GET이기 때문에 응답은 하되, 나머지 40 바이트 크기의 Body를 기다린다. 그 후 7-8번 라인까지 40 바이트가 들어오면 첫 번째 요청의 Body라고 인식한다. 그 후 9-10번 라인의 요청을 두 번째 요청이라고 생각하는 것이다. 이렇게 악의적으로 인식되는 요청은 3번째(후자) 이므로 Backward Smuggling이 가능하게 되는 것이다. 

(4) Request Hijacking ( HTTP Request Smuggling Through a Proxy Server )

  HTTP Request Smuggling 공격을 통해 XXS 공격과 비슷한 결과를 만들 수 있다. XXS 공격이란 간단히 설명하면 클라이언트(피해자) 컴퓨터에서 악성 스크립트가 실행되도록 하는 공격이다. 비슷한 결과를 만들지만 XXS 공격보다 훨씬 더 성능이 좋다. 그 이유는 HttpOnly Cookie 정보나 HTTP 인증 정보들을 직접 가져갈 수 있기 때문이다. ( Cross Site Tracing이 필요없다. )

(* 참고 : Cross Site Tracing : HTTP의 TRACE 방식을 지원 할 때 가능. )

  Request Hijacking의 선행 조건

    1. 서버 앞단에 Proxy 서버가 존재해야한다. ( Web Cache Poisoning과 달리 캐싱기능은 없어도 된다. )

    2. 해당 웹 서버에 XXS 취약점이 존재해야한다.

< Request Hijacking 원리 >

  공격 예시는 위와 같다. 위 데이터를 보내게 되면, Proxy 서버에서는 두 번째 Content-Length로 인식하고 위 전체 내용이 하나의 요청으로 전달된다. 하지만 서버에 도착해서 서버가 해석하기를 첫 번째 Content-Length로 인식하여 1-7번 라인(this=that까지) 의 요청으로 인식하고 응답한다. 그 뒤 데이터를 POST 요청으로 인식한다. 여기서 Content-Length를 95로 잡아주었는데 여기서 94 바이트만 제공되어있다. 그러면 나머지 한 바이트를 서버는 기다리게 된다. 이 때 피해자가 GET 방식으로 요청을 했다고 가정하자. 그렇게 되면 한 바이트를 기다리면 요청이 있는데 여기에 데이터의 맨 앞 ‘G’라는 문자가 소모된다. 

< 완성되는 요청 >

  그렇게 되면 위와 같은 요청이 완성된다. 이 요청에 대한 응답으로 cookie를 출력하는 스크립트가 피해자에게 전송되는 것이고 그렇게 피해자의 컴퓨터에서 임의의 스크립트가 실행되는 것이다.

  그런데, 이는 HTTP Request Smuggling을 통해 어떻게 악성 스크립트가 실행되는지를 확인한 것이다. 이를 이용해 세션정보가 있는 cookie와 인증 정보를 탈취하기 위해서는 약간의 트릭이 필요하다.

< 자바 스크립트 >

  위 자바 스크립트는 document의 텍스트 정보들을 단일 문자열로 concat한 후, 앞에서부터 300바이트를 잘라내는 동작을 한다. 이를 이용해 다음과 같은 공격 패킷들을 구성했다고 해보자.

< 스크립트를 추가한 패킷모습 >

  param1 변수부터 시작되는 body의 길이는 277바이트만 제공하였다. 이렇게 되면 나머지 300바이트를 웹 서버는 기다리게 된다. 피해자가 보낸 요청으로부터의 300바이트를 사용하게 된다. 이 상태의 응답이 클라이언트(피해자)에게 전송되고 피해자의 브라우저에서 해당 응답이 로딩될 때, 삽입한 스크립트가 실행된다. document의 텍스트 부분 앞에서 300바이트를 잘라내는데 이 안에 보통 Cookie와 인증 정보 헤더가 담겨있다. 또한 이와 함께 URL도 담겨있는데 이를 활용해 해당 사이트의 인증 정보와 쿠키를 Hijacking 할 수 있다.

(5) Request Credential Hijacking ( HTTP Request Smuggling Through a Proxy Server )

  클라이언트의 크리덴셜을 가지고 특정 스크립트를 실행시키는 또 다른 방법이 있다. 이 방법은 클라이언트의 크리덴셜을 가지고 악성 스크립트를 실행한다는 것으로 CSRF(Cross-Site Request Forgery) 공격과 비슷하다. 그러나 CSRF보다 훨씬더 효과가 좋다. 그 이유는 클라이언트(피해자)와 상호작용할 필요가 없기 때문이다.

< 공격 패킷 >

  이 때 피해자가 아래와 같은 요청을 했다고 가정하자.

< 피해자의 요청 >

  그렇게 되면 위 공격 패킷의 빨간 부분(GET 요청)에 최종적으로 아래와 같은 패킷이 만들어지게 된다. 

< 만들어진 위조된 요청 >

이 요청은 ‘/some_page.jsp’의 페이지에서 피해자의 크리덴셜을 가지고 요청이 되는 것이다. 그렇게 되면 CSRF와 비슷한 효과를 낼 수 있다. 만약 이 ‘/some_page.jsp’ 페이지가 비밀번호 변경 페이지라던가, 큰 돈을 전송하는 페이지였다면 피해가 컸을 것이다.

github에서 계정을 만들고 새 저장소를 만든다.

(저장소 생성)

생성된 저장소는 아래와 같다.

(생성된 저장소)

이제 remote 저장소와 현재 저장소를 연결해야한다.

(사용자 정보 입력)

그리고 remote 저장소와 연결

(remote 저장소와 연결)

이제 현재 내 VM-kali 호스트와 계정을 연결해 둘 것이다.

(SSH 연결)

그래서 할 수 없이 새로 다른 폴더를 만들고, 거기서 git clone을 해준 뒤, 작업했다.

(add 전)

그리고 git status를 치니 아직 추적되지 않은 파일들이 나온다.

(add)

commit을 해준다.

(commit)

이제 이 정보들을 remote 저장소에 push 해주면 된다.

(push)

작업했던 내용들이 업로드 된다.

(원격 저장소)

이제 CoffeeNet 프로젝트를 소개할 README.md 를 작성해야한다.

(README.md)

방금 작성한 README파일을 내 로컬에도 옮겼다.

(pull)

그렇기에 이와 관련되어 필요한 파일들을 설치해주는 setup.sh 쉘스크립트를 작성했다.

(setup.sh)

그리고 파이썬의 필요한 모듈들을 파일로 이름들을 저장해두었다.

(필요한 모듈)

custom 옵션같은 경우, 스캐너 클래스에 custom_option이라는 문자열 변수를 놓고 여기에 옵션을 사용자로부터 입력받아 저장하고, 스캔할 때 이 옵션을 뒤에 추가한다.

(추가한 옵션 변수)

여기에 옵션을 사용자로부터 입력받아 저장한다.

(실행 코드)

실행시 이 변수를 옵션 뒤에 붙여서 실행해준다.

(실행 모습)

왜냐하면 부정확한 옵션을 입력으로 넣게 되면 스캔 작업때 에러가 나기 때문이다.

(입력된 옵션)

입력을 받게 되면 스캔 메뉴에서 직접 어떤 옵션이 들어가있는지 확인 할 수 있다.

(실행 모습)

아무리 경고를 해놨다 해도, 이에 대해 잘 처리를 안해두면 훌륭한 프로그래머가 아니다.

(에러 모습)

이를 막기 위해 예외 처리를 하였다.

(예외 처리)

예외처리를 하였다. 총 스캔하는 코드가 3부분 있었는데 그 곳에 이렇게 예외처리를 하였다.

(예외처리 모습)

에러를 출력한다. 그리고 현재 입력된 옵션을 지워주게 만들었다.

(옵션 삭제)

깃헙에 올려서 배포를 한 후, 깃헙을 이용해 업데이트 작업을 진행할 계획이어서 여기서는 구현하지 않았다.

(update 미 구현)

그리고 추가적으로 메뉴를 조금씩 바꾸고 있다. 아래는 스캐너 모듈의 스캔 메뉴를 조금 바꾸었다.

(스캔 메뉴)

이럴 경우 기존 host 데이터가 없으므로 detail 스캔을 진행하지 못하므로, ip 주소를 입력받아 해당 ip 주소를 detail 스캔 하는 방식으로 작성하였다.

(detail 스캔 예외모드)

실행하면 다음과 같이 잘 동작하는 것을 확인하였다.

(동작 확인)

코드에서는 두번째 인자를 ip 형식이 맞는지 체크하는 루틴을 위에서 만든것과 같이 똑같이 만들었다.

(동작 확인)

그래서 찾아본 결과 -T 옵션이 아래와 같은 기준으로 세부 옵션을 설정해주는 거였다.

(-T 옵션)

그런데 카페 같은 소규모 네트워크에서 사용할 프레임워크로써 그러한 소음에는 덜 민감해도 된다고 판단하였고, 카페같은 무선랜을 주로 사용하는 곳에서는 호스트가 유동적으로 연결 되었다 해제된다. 그러기에 빠르게 스캔할 줄 아는게 굉장히 중요하다고 판단하여 -T5 옵션을 사용하기로 결정했다.

(-T 옵션 장착)

그 외로 이제 정상적인 스캐너의 기능을 할 줄 알게 되는 스캐너를 구현하였다.

(스캐너 구현)

db 메뉴에서 지금까지 스캔한 정보에 대한 정보를 선택해서 볼 수 있는 메뉴를 만드는게 좋을 것 같았다.

(추가한 db메뉴)

db 메뉴에 들어가면 아래와 같다.

(db 메뉴)

host 리스트 정보 출력

(호스트 리스트)

입력된 ip에 열려있는 포트 정보를 출력해준다.

(open 된 port 정보)

예외적으로 호스트된 정보가 없다면 데이터가 없다고 출력해준다.

(호스트 정보 없음)

service 메뉴에 관한 코드는 아래와 같다.

(service 메뉴)

4. nmap의 속도 개선 고민.

특수 코드인 1018을 입력으로 넣으면 root 권한을 넘겨주는 rootkit을 만들것이다.

(Prototype)

여기서 write함수를 채워준다.

(write 함수)

Makefile을 만든다.

(Makefile)

그 이유는 루트 권한이 아닌 일반계정에서 실행할 수 있도록 하기 위해서이다.

(권한 설정)

실행하기 전 권한을 확인한 모습이다.

(권한)

이 디바이스에 1018이라고 입력을 넣는다.

(매직값 입력)

위에서 작성한 write에 의해서 사용자 권한을 0으로 만들어준다.

(root 권한 획득)

https://0x00sec.org/t/kernel-rootkits-getting-your-hands-dirty/1485

(detail 명령)

추가한 코드 시작부분이다.

(코드)

default 방식인 host 스캔을 했다는 가정을 한 디테일 스캔을 완성하였다.

(스캔 옵션)

운영체제, 오픈 포트 및 서비스를 분석하여 사전으로 저장한다.

(스캔 정보 저장)

이렇게 저장된 스캔 결과를 확인'해보았다.

(호스트에 저장된 정보)

이번에 구현한 기능은 detailscan의 결과를 출력하는 함수를 만들었다.

(detailscan 출력)

아이피, 맥, 벤더, 운영체제  이렇게 4가지의 정보를 나열해서 보여주게 만들었다.

(구현 결과)

3. Framework의 update 기능 구현

그러기 위해 필요한 것이 있다. 바로 linux 헤더이다.

(linux-headers)

알맞은 운영체제 버전을 선택해서 설치하면 된다.

(설치)

hello.c 파일을 작성하였다.

(hello.c)

이 파일을 컴파일 하기 위하여 Makefile을 만든다.

(Makefile)

make 를 입력하여 컴파일한다.

(컴파일 완료)

그러면 hello.ko 가 생기게 된다. 이 커널 오브젝트 파일은 모듈인데 이 모듈을 올려보도록 할 것이다.

(커널 모듈 올리기)

올라간 모듈은 lsmod를 통하여 확인 할 수 있다.

(올라간 모듈 확인)

올라간 모듈을 해제하는 법은 rmmod 이다.

(모듈 해제)

아까 우리가 init과 exit 에 printk를 넣었으니, 모듈이 올라갈 때 내려갈 때 로그가 찍혔을 것이다.

(로그 확인)

이번에는 아까 만든 변수에 값을 넘겨주며 올려보겠다.

(인자 넘기기)

(모듈 확인)

올라간 모듈 hello에 들어가본다.

(모듈 정보)

여기서 우리는 parameters를 확인해 볼 것이다.

(변수 확인)

이 값을 수정할 수 있을까 했더니

(파일 권한)

마지막으로 인자를 넘긴 모듈을 해제해보겠다.

(모듈 해제)

그렇다면 kern.log는?

(커널 로그)

소스코드의 select_menu() 함수가 문제였다.

(문제 코드)

(문제코드)

2번의 과정은 없어도 되었다. 스택영역의 주소를 얻기위해 반복하는 과정에서 자연스레 엄청 낮아졌다.

(스택 영역 주소 구하기)

그렇게 되면 ret,leave 하면서 쭉 내려갈 테니까!

(clear 함수)

쉘코드 올리기

(쉘코드 올리기)

쉘코드를 올리는 부분이다.

(스택 영역 주소 덮기)

exploit!

(스택 주소 받기)

옆에 Stacking 옆의 값은 현재 ebp 값이다.

(clear 중)

clear 도 몇번 실행되었다.

(exploit)

여기서 5를 눌러 exit를 실행하면 최종적으로 shell을 획득할 수 있다.

(쉘 획득)

문제 풀이 끝!