SSL인증서 적용하여 HTTPS 구현하기 (그누보드 로그인에 https 적용하기)

Posted by taeho Tae-Ho
2016.06.26 22:34 서버보안

웹서버는 기본적으로 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 파일을 위와같이 수정하면 완성됩니다.


신고
이 댓글을 비밀 댓글로

웹서버까지 공격하는 랜섬웨어 - RedCastle로 방어한다.

Posted by taeho Tae-Ho
2016.01.14 19:00 서버보안

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

신고
이 댓글을 비밀 댓글로
  1. 리멤버에 명함이 업데이트 되셨던데 혹시 이직 하신건지요?
    이전에 회사명이랑 달라진것 같아서 ^^
    • 아닙니다. 회사명만 바뀌었습니다. 레드비씨에서 "SGA솔루션즈"로요.. 원래 레드비씨는 SGA의 자회사였습니다. 이제 회사명이 바뀔일은 없을 듯 합니다.

RedCastle의 서버방화벽을 이용해 중국 IP접속 차단하기

Posted by taeho Tae-Ho
2015.11.05 10:02 서버보안

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 방화벽이기 때문에 서버의 성능과 네트워크 트래픽 등을 감안하여야 한다는 점을 꼭 유념해야 합니다. (그래도 다른 서버 방화벽 보다는 가볍습니다. 그 이유는 나중에.... ^^)



신고
이 댓글을 비밀 댓글로

운영체제 쉘(shell)의 취약성과 쉘의 실행 통제 방안

Posted by taeho Tae-Ho
2015.08.21 11:24 서버보안

정보보안 업계에서 일을 하면서 정보보안업계는 다른 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분야 종사자의 최초의 직업이 아니라 최후의 직업이 되어야 제대로 일할 수 있다.

신고
이 댓글을 비밀 댓글로
  1. 올해는 보안때문에 너무 고생을 해서 ^^ 그래도 보안은 미래에 점점 더 중요한 IT기술의 하나가 될건 분명해 보입니다 ^^
    • ㅎㅎ 기기 인증은 잘 끝나셨겠죠...??
      고생 많으셨습니다~~
  2. 좋은 글 잘 읽었습니다~ 정보보안전문가가 되기위해 갈 길이 멀군요.. 끊임없이 정진하겠습니다ㅎㅎ

Reverse Telnet 실습과 RedCastle을 통한 방어 방법

Posted by taeho Tae-Ho
2015.06.18 15:08 서버보안

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

신고
이 댓글을 비밀 댓글로

2차 인증 및 워크플로 기반 명령어 통제 시스템

Posted by taeho Tae-Ho
2015.05.15 15:23 서버보안

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

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


바로 "정보"다.


그리고 해커들이 원하는 정보는 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차 인증과 연동한 실사용자 기반의 명령어 통제 및 파일 접근통제를 지원하며 워크플로(결재 절차) 지원을 통해 서버에서의 작업관리와 작업 승인에 기반한 명령어 실행 권한 자동 부여 및 권한 회수를 지원하는 서버보안 솔루션을 제공하는 국내 유일의 보안 솔루션 기업이다.


신고
이 댓글을 비밀 댓글로

클리앙 홈페이지 해킹에 의한 랜섬웨어 유포 사고 (2015.04)

Posted by taeho Tae-Ho
2015.04.24 17:25 서버보안

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

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의 보안 패치 업데이트 타령만 하는 것은 너무 무책임한 것은 아닌지 생각해 봐야하지 않을까 싶습니다.

신고
이 댓글을 비밀 댓글로
  1. 잘못하면 문서 다 날아가겠네요. 조심해야겠어요. 백업도 잘 해야겠고요.
    • IE보다는 크롬을 사용하시고...
      가능하시면..광고를 막아주는 플러그인을 쓰시는 것도
      광고서버를 통한 악성코드 감염을 차단하는 방법 중 하나입니다.

이중 인증 기반 명령어 실행 통제 기술의 핵심 (참조모니터 : Reference Monitor)

Posted by taeho Tae-Ho
2015.02.05 09:39 서버보안

보안 운영체제라 부르는 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) 입니다.


신고
이 댓글을 비밀 댓글로
  1. 대형보안사고의 실제 피해자이기도 했기에~
    서버 내부 개발자와 관리자에 대한 행위 통제가
    가능하다는 사실을 알게되어 기쁩니다.^^
    좋은 하루 보내세요!
    • 가능하지만...
      통제를 안하려고 한다는 건 함정..!!
      개발과 관리업무가 불편해진다고 생각하기 때문이죠~ ^^
  2. 제가 일하는 업계에서 secure os에 대해서 아직은 요구사항이 크진 않지만 점점 커지고 강화되는 보안 요구에 언젠가는 필수 제품이 되리라 생각이듭니다
    • 지후대디님 회사의 서버에는 이미 상당수 서버에 시큐어os가 설치되어 있습니다. ^^ 지금도 저희가 기술지원을 하구 있구요... 다만 실제 통제가 아니라 행위에 대한 감사만 하고 있을 뿐이죠.. 언젠간 이중인증과 명령어 통제, 파일 보호 정책까지 정책을 실제로 적용할 수도 있습니다.. ^^

웹서버 해킹 방어 사례 - 남다른 끈기를 보여준 해커

Posted by taeho Tae-Ho
2014.12.21 22:22 서버보안

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


얼마 전 지속적인 웹 소스파일 변조 공격을 받고 있어 몇 주 째 사투(?)를 벌이고 있던 한 웹사이트 운영 업체의 요청으로 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을 도입했고 현재 스스로 운용 중이다. 이따금씩 정책 관련 문의가 오고는 있으나 현재는 공격이 들어오지는 않고 있는 듯 하다. 


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





신고
이 댓글을 비밀 댓글로
  1. 해커의 끈기가 놀랍군요 꼭 뚫고 싶은 동기라도 있었나 봅니다 흥미진진하게 보고 갑니다 ^^
    • 저도 뭔가 이해관계가 있는 사람과 연관이 있는게 아닐까 하는 생각을 안할래야 안 할 수가 없었습니다.
  2. 휴지통에서 악성코드를 실행하다니~
    놀랍습니다.
    • 선구자적 해커들은 상식을 깨는 사고를 많이 합니다. 당연히 다른 해커들은 그것을 따라하고요.. ^^
  3. 좋은 포스팅 너무나도 잘 보고 갑니다!
    포스팅 잘 봤네요. 즐거운 하루 되시길!!
  4. 잘보고 갑니다!
  5. 엄청나군요... 이것도 능력이겠죠ㅎㅎ

SETHC.EXE 의 취약성을 이용한 백도어 공격 기법

Posted by taeho Tae-Ho
2014.12.05 10:56 서버보안

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


유닉스나 리눅스가 갖고 있는 쉘카피백도어와 비슷한 백도어 생성기법 중 하나입니다. 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 운영체제는 보안에 취약합니다. 위 화면에 표시된 대로 접근성 센터에 가서 이 기능을 꼭 꺼주시기 바랍니다. 



신고
이 댓글을 비밀 댓글로
  1. 윈도우 운영체제가 이렇게 보안에
    취약하다니~ 충격입니다....ㅠㅠ
  2. 보안 문제다 보니 불안하군요;;
    • 윈도가...태생적으로..보안에 취약한 구조로 설계되어 있습니다. 게다가 보안에 더욱 취약한 HTTP(웹)을 함께 쓰니 더 보안에 취약한 상태가 되지요.
      부실과 부실이 만나...더 큰 부실을 초래한 결과지요.

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

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