RPC 관련 보안 취약점 및 대책
1. 개요
최근들어 국내뿐만 아니라 국외에서도 RPC 서비스의 취약점을 이용한 공격 빈도가 급격히 증가하고 있으며 대부분의 경우 관리자의 권한을 획득하게 된다. 특히 국외 모 대학의 경우 하루동안 50여 호스트(Solaris)가 침해당하는 사례가 발생하였다. 국내에서도 많은 수의 관련사고가 발생하고 있다. 여기서는 RPC 서비스에 대한 기본지식과 최근 사용되고 있는 공격 수법, 그리고 그 대처방안을 설명한다.
2. 관련 취약점
○ rpc.statd
statd는 시스템 장애시 NFS에서 파일 복구를 위해 제공하는 lockd 프로그램을 지원하는 도구로 클라이언트와 서버의 상태를 모니터링 하는 rpc프로그램이다. 이 프로그램은 원격 클라이언트의 매개변수 크기를 체크하지 않아 버퍼오버플로우(Buffer Overflow)를 통해 루트 권한에서만 수행 가능한 임의의 명령어를 수행시킬 수 있다. 다음은 실제 rpc.statd 공격 프로그램 소스의 일부분이다.
#include <sys/types.h>
#include <sys/time.h>
#include <stdio.h>
#include <string.h>
...
/* up to ~ 150 characters, there must be three strings */
/* 실행시킬 명령어 스크립트 */
char *cmd[3]={"/bin/sh", "-c", "touch /tmp/blahblah"};
/* 버퍼오버플로우 일으켜 임의의 번지로 점프, 위의 특정 스크립트를 실행하게 하는 어셈블리코드 */
char asmcode[]="\xeb\x3c\x5e\x31\xc0\x88\x46\xfa\x89\x46\xf5\x89\xf7\x83\xc7\x10\x89\x3e\x4f
...
char nop[]="\x90";
char code[4096];
...
위의 코드를 실행시키면 공격 대상 시스템에 /tmp/blahblah 라는 파일이 생성된다.
○ SUN automountd
SUN 솔라리스 시스템의 automountd는 일반적으로 UDP나 TCP프로토콜을 통해서 패킷을 받아들일 수 없지만 rpc.statd가 포워딩 해주는 TLI프로토콜을 통해서는 패킷을 받아들일 수 있다. 공격자는 이를 이용해 자신이 실행시키고자 하는 명령어를 rpc.statd에 패킷형태로 보내 실행시킬 수 있다.
공격자는 간단한 명령으로 공격 대상 원격 시스템의 rpc서비스 정보를 얻을 수 있고, rstatd데몬의 샐행 여부를 확인할 수 있다.
[han]# rpcinfo -p abc.victim.com
100000 4 tcp 111 rpcbind
100024 1 udp 32772 status
. . .
100001 3 udp 48686 rstatd
100001 4 udp 48686 rstatd
100017 1 tcp 34168 rexd
100233 1 tcp 34169 ufsd
. . .
다음은 rstatd 데몬이 실행되고 있을 경우, automountd 취약점 공격 프로그램을 이용하여 특정 명령어를 실행시킨후 루트로 접속하는 예이다.
[han]:/Hacker/amountdexp> amountdexp abc.victim.com victim "echo + + > /.rhosts" 0
SM_MON: 0
SM_NOTIFY: 0
[han]:/Hacker/amountdexp> rsh abc.victim.com -l root csh
id
uid=0(root) gid=1(other)
○ rpc.ttdbserver
ttdbserver는 RPC기반의 ToolTalk 데이터베이스 서버 프로그램인데, 이 프로그램 구현상의 오류로 인해 원격의 침입자가 루트 권한으로 특정 명령어를 실행시킬 수 있다. 이 취약점은 SUN 솔라리스뿐만 아니라 HP, IRIX, AIX등 대부분의 시스템에서도 나타난다.
○ SUN rpc.cmsd
rpc.cmsd프로그램은 데이터베이스 관리 프로그램으로 Open Windows의 Calendar Manager와 CDE의 Calendar 프로그램에서 사용한다. 침입자는 이 프로그램의 취약점을 이용 원격에서 임의의 파일을 쓰거나 루트 권한을 얻을 수 있다.
○ AIX automountd
IBM AIX의 automound 프로그램은 로컬 AutoFS파일 시스템 커널의 요청을 처리하는데 수신된 요청이 실제 커널로부터 온 것인지를 검증하지 않아 로컬시스템의 일반 사용자 혹은 원격시스템의 사용자가 automountd 서비스를 요청할 수 있다. 이를 통해 침입자는 원격에서 루트권한으로 임의의 명령어를 실행시킬 수 있다.
○ IRIX autofsd
IRIX의 autofsd 프로그램은 RPC서버로 autofs파일 시스템의 mount, unmount요청을 처리하며, 지역 파일 또는 네임 서비스 맵을 이용하여 마운트 할 파일 시스템의 위치를 찾아낸다. 하지만 로컬의 일반 사용자가 autofsd에 조작된 요청을 보내어 루트 권한으로 임의의 명령을 실행시킬 수 있다.
3. RPC관련 공격 탐지 방법
최근 접수된 많은 RPC 관련 침해사고를 분석해 보면 상당수가 유사한 공격방법으로 피해를 입고 있음을 알 수 있다. 다음은 관련 피해 호스트에서 수집한 자료로서 공격 흔적을 발견하는데 도움이 될 것이다.
○ rpc.ttdbserverd 취약점을 공격한 경우 루트 디렉토리에 Core 파일이 생긴다.
○ rpc.cmsd 취약점을 공격한 경우 "/var/spool/calendar" 디렉토리에 callog.* 파일이 생성된다.
○ 공격자는 /tmp/bob 이라는 이름의 inetd.conf 파일을 생성하여 또 다른 inetd 데몬을 실행시킨다(ps 명령을 이용하여 확인 가능).
※ 대부분의 경우 ingreslock(1524)포트와 pcserver(600)포트가 사용된다. 따라서 네트워크 관리자는 자신 도메인내의 모든 시스템을 포트스캔 하여 1524와 600번 포트가 열려있는지 조사함으로서 피해여부를 빨리 파악할 수 있다. 다음은 nmap이라는 프로그램을 이용하여 Class B 네트워크에서 1524 포트만을 점검하는 방법이다.
# nmap -Pl -sT -p 1524 -m logfile A.B * *
○ 로그파일 흔적
- /var/adm/messages 파일
Jun 10 09:13:47 victim statd[13036]: attempt to create "/var/statmon/sm/echo + + > /.rhosts"
Jun 10 09:14:05 victim statd[13036]: attempt to create "/var/statmon/sm/echo + + > /.rhosts"
Jun 10 09:15:01 victim statd[120]: attempt to create "/var/statmon/sm/;echo + + > /.rhosts;?/FONT>
Jun 10 09:14:45 victim inetd[18416]: fs/tcp: bind: Address already in use
Jun 10 09:13:45 victim inetd[18416]: fs/tcp: bind: Address already in use
Aug 7 07:46:19 boa inetd[198]: /usr/openwin/bin/rpc.cmsd: Child Status Changed- core dumped
등 등
○ 공격자는 rpc 취약점을 이용하여 공격한 다음 자신의 자취를 감추고 또 다른 공격을 위하여 다양한 공격 도구들을 자동으로 설치하고 실행하도록 하는 다음과 같은 스크립트를 사용한다.
- neet.tar : update(sniffer), doc(inetd 백도어), ps(가짜 ps 프로그램)을 포함
- leaf.tar : in.fingerd(백도어), eggdrop
- 기타 다수의 스캐닝 도구(crackerm mns-v.75 등)
※ /dev/sda69 디렉토리에 파일을 숨겨놓는 경우가 많이 발견됨
4. 보안 대책
사용하지 않는 서비스는 중지하고 알려진 버그는 패치 해 줌으로써 rpc취약점 관련 공격을 막을 수 있다.
○ statd
패치를 설치하거나 statd프로그램이 동작하지 않게 한다. statd 프로그램을 정지하려면 lockd 프로그램을 off하고 재부팅하면 된다.
# chkconfig lockd off
# reboot
# ps -ef | grep rpc.statd
패치는 OS별로 다음과 같다.
IRIX 5.3 1391
IBM Corporation
AIX 3.2 APAR - IX56056 (PTF - U441411)
AIX 4.1 APAR -IX55931
※ PTF를 확인하기 위하여 다음과 같이 한다.
instfix -ik IX55931 혹은, ls|pp -h bos.net.nfs.client
Sun Microsystems
5.5.1 104166-02
5.5.1_x86 104167-02
5.5 103468-03
5.5_x86 103469-03
5.4 102769-03
5.4_x86 102770-04
4.1.4 102516-06
4.1.3_U1 101592-09
○ SUN automountd
rpc.statd과 automountd을 다음과 같이 OS별로 각각 패치를 한다.
rpc.statd:
SunOS 5.6 106592-02
SunOS 5.6_x86 106593-02
SunOS 5.5.1 104166-04
SunOS 5.5.1_x86 104167-04
SunOS 5.5 103468-04
SunOS 5.5_x86 103469-05
SunOS 5.4 102769-07
SunOS 5.4_x86 102770-07
SunOS 5.3 102932-05
※ Solaris 7은 패치되어 있다.
automountd:
104654-05 SunOS 5.5.1
104655-05 SunOS 5.5.1_x86
103187-43 SunOS 5.5
103188-43 SunOS 5.5_x86
101945-61 SunOS 5.4
101946-54 SunOS 5.4_x86
101318-92 SunOS 5.3
※ Solaris 2.6과 7은 패치되어 있다.
○ rpc.ttdserver
/etc/inetd.conf 파일에서 해당 서비스를 코멘트 처리하여 서버를 실행시키지 않도록 한다.
# Sun ToolTalk Database Server
#
#100083/1 stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd
그리고 OS별로 패치를 설치한다.
HP
HP-UX release 10.10 HP9000 Series 7/800 PHSS_16150
HP-UX release 10.20 HP9000 Series 7/800 PHSS_16147
HP-UX release 10.24 HP9000 Series 7/800 PHSS_16197
HP-UX release 10.30 HP9000 Series 7/800 PHSS_16151
HP-UX release 11.00 HP9000 Series 7/800 PHSS_16148
IBM AIX
APAR 4.1.x: IX81440
APAR 4.2.x: IX81441
APAR 4.3.x: IX81442
○ rpc.cmsd
다음과 같이 OpenWindows와 CDE 패치를 설치한다.
OpenWindows:
SunOS 5.5.1 104976-03
SunOS 5.5.1_x86 105124-02
SunOS 5.5 103251-07
SunOS 5.5_x86 103273-04
SunOS 5.4 102030-09
SunOS 5.4_x86 102031-07
SunOS 5.3 101513-12
SunOS 4.1.4 100523-24
SunOS 4.1.3_U1 100523-24
CDE:
CDE version Patch ID
___________ ________
1.02 103670-04
1.02_x86 103717-04
1.01 103671-04
1.01_x86 103718-04
○ AIX automountd
automountd사용을 중지하고 패치를 설치한다.
AIX 4.3.x : IX83752
5. 참고 자료
http://www.certcc.or.kr/advisory/ka99/ka99-51.txt
http://www.certcc.or.kr/advisory/ka98/ka98-150.txt
http://www.certcc.or.kr/advisory/ka98/ka98-60.txt
http://www.cert.org/incident_notes/IN-99-04.html
http://www.securityfocus.com/
http://www.certcc.or.kr/
첨부: RPC(Remote Procedure Call)란 ?
분산처리 환경은 서버 응용프로그램과 각 서버에 접근하여 작업을 요구하는 클라이언트 프로그램을 필요로 하는데, 이러한 프로그램 개발을 위한 기본 툴로써 제공되는 것이 바로 RPC이다. RPC를 이용하지 않고 서버-클라이언트 모델을 기준으로 하여 분산 응용 프로그램을 개발할 수도 있지만 이때 개발자는 통신기능, 프로토콜, 그리고 그 밖의 작업들을 직접 작성해야 하는 부담이 있으며 이식성에도 한계점이 있다. 따라서 RPC를 사용하게 되면 분산 시스템 개발이 더욱 용이해진다.
RPC 호출 절차를 도식화하면 다음과 같다.
클라이언트에서 호출에 필요한 인자를 메시지화하여 서버에게 넘겨주면 서버는 이 메시지를 해독하여 인자를 확인하고 이 인자로 프로시져를 호출하게 된다. RPC 서버는 프로시져 수행 결과를 다시 메시지화하여 클라이언트에 돌려주면 클라이언트는 이 메시지를 해독하여 결과를 얻는다.
이 과정에서 두 개의 시스템은 서로 다른 자료 표현 방식을 가질 수 있는데 이를 위해 공통된 자료 표현 변환이 이루어진다.
실제 RPC 구현을 위해서는 클라이언트와 서버쪽에 각각 스텁이 존재한다. 클라이언트 스텁은 클라이언트의 프로그램에서 서버쪽에 있는 원격 프로시져를 마치 클라이언트 로컬에 있는 프로시져인 것처럼 보여주며, 대신 클라이언트내의 프로그램에서 호출한 인자들을 메시지화하여 서버쪽으로 넘겨주는 역할을 한다. 서버 스텁은 클라이언트의 호출 메시지에서 인자를 분리해서 서버에 있는 프로시져를 호출하고 그 결과를 다시 메시지화하여 클라이언트 스텁에 보내준다.
