서술형

1. NTP 서버 취약성 존재 여부 확인하는 방법 3가지

운영 조직내, 취약한 NTP 서버가 있는지 확인하기 위한 3가지 방안

모든 영역에 트렌드가 있듯이 DDoS 공격에도 유행하는 트렌드가 있는데, 가장 최신의 트렌드라면 전통적인 좀비PC를 활용하지 않고 프로토콜의 특성을 악용해, IDC내 서버를 활용하는 amplification(증폭) 공격이라고 할 수 있다.

가장 전통적인 증폭 공격이라면 공격자가 소스IP를 victim의 IP로 위조하여 증폭하려는 네트워크의 broadcast 주소에 icmp request를 요청하면, 이에 대해 broadcast 내 모든 디바이스들이 해당 IP로 icmp echo reply로 응답하는 그러나 지금은 역사속에 사라진 smurf 공격으로 거슬러 올라갈 수 있다.

이후, UDP 기반의 공격으로는 2013년 spamhaus에 대한 300Gbps의 공격으로 이슈화가 된 DNS(53/udp) 증폭 공격을 시작으로default community string인 public을 사용하는 snmp(161/udp)에 대량의 응답을 요청하는 snmp 증폭 공격이 잠시 유행한 적이 있었고, 최근에는 ntp(123/udp) 증폭 공격이 큰 이슈가 되고 있다.

물론 증폭 공격의 특징은 소스IP를 Victim인 것처럼 위조해야 하므로 소스IP 위조가 가능한 ICMP나 UDP가 활용될 수 밖에 없을 것이다. 여기에서는 최근 이슈가 되고 있는 NTP 증폭 공격에 대해 좀 더 살펴보도록 하자.

데일리시큐 기사 및 여러 기술 문서에서 언급된 바와 같이 문제가 된 ntp의 취약성은 해당 ntp 서버에 최근 ntp질의에 응답을 했던 목록을 보여주는 monlist 기능때문이다.

 

먼저, ntp.conf 에 아래와 같이 간단한 설정만 한 후 ntp를 가동해 보도록 하자.

--------- ntp.conf ---------

server pool.ntp.org

driftfile /etc/ntp/drift

-----------------------------

 

이후 아래와 같이 원격에서 ntpdc 명령어를 이용하여 해당 서버에 질의를 해 보도록 하자.

# ntpdc -n -c monlist 192.168.34.85

remote address port local address count m ver code avgint lstint

===============================================================================

10.1.198.173 45579 192.168.34.85 1 7 2 0 0 0

107.22.163.51 123 192.168.34.85 692692147 7 2 0 0 0

59.46.172.253 123 192.168.34.85 34988639 7 2 0 0 0

222.146.205.218 123 192.168.34.85 26669143 7 2 0 0 0

210.173.160.87 123 192.168.34.85 48709 4 4 0 1464 6

173.217.36.243 80 192.168.34.85 274 7 2 0 0 393

173.25.188.13 80 192.168.34.85 9110 7 2 0 0 580

69.138.111.24 3074 192.168.34.85 281 7 2 0 0 580

107.2.112.102 80 192.168.34.85 552 7 2 0 0 806

70.209.7.172 50557 192.168.34.85 136 7 2 0 0 879

68.13.254.149 50557 192.168.34.85 14 7 2 0 1 880

98.110.44.46 80 192.168.34.85 109 7 2 0 0 896

173.35.167.91 80 192.168.34.85 4892 7 2 0 0 1158

50.172.46.211 80 192.168.34.85 65 7 2 0 0 1349

177.106.157.89 80 192.168.34.85 1852 7 2 0 0 1416

151.224.225.219 50557 192.168.34.85 709 7 2 0 1 1486

72.229.135.22 80 192.168.34.85 263 7 2 0 0 1630

37.187.52.240 80 192.168.34.85 3616 7 2 0 0 1728

.............. 중략 ..............

 

참고] 소스 포트가 123/udp인 것도 있지만 80/udp인 것도 적지 않음을 알 수 있다.

 

이때의 패킷을 tcpdump로 캡처해 보면 아래와 같다.

 

12:30:04.830324 IP 10.1.198.173.44948 > 192.168.34.85.123: NTPv2, Reserved, length 192

12:30:04.830337 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830344 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830351 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830367 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830371 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830379 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830387 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830395 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830406 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

12:30:04.830412 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440

... 이하 중략

 

여기에서 문제는, ntp의 monlist가 기본적으로 600개의 최근 질의/응답 목록을 보여 주기 때문에 단 몇십~몇백 바이트의 한 질의 패킷에 440byte씩 쪼개어져 결국 약 x20배의 증폭이 되어 4,000 byte 이상의 응답 패킷을 생성하게 된다는 것이다. 그리고, 짧은 시간에 많은 질의를 하게 되면 결국 다음과 같이 한 서버에 수백 Mbps 이상의 공격 트래픽이 유발될 수 있음을 확인할 수 있다.

 

사실 이 monlist 기능은 일반적인 ntp 운영시 굳이 필요한 기능이 아니기 때문에 해제하면 되는데, 이 기능을 뺀 최신 버전으로 ntp를 업그레이드 하거나 또는 ntp.conf 에서 아래와 같이 noquery 옵션만 추가해 주면 간단히 해결이 된다.

 

----------- ntp.conf ----------

restrict default noquery

server pool.ntp.org

driftfile /etc/ntp/drift

---------------------------------

 

혹자는 ntpd 를 운영시 굳이 서버가 아닌 클라이언트로 사용한다면 123/udp를 listen하지 않아도 되지 않을까 생각할 수 있지만 ntpd의 구조상 서버의 역할이든 클라이언트의 역할이든 반드시 123/udp를 listen하여야 한다. 따라서, ntp 패키지 업데이트도 불가능하고, 이 설정을 추가하는 것도 어렵다면, iptables등의 방화벽등을 통해 123/udp 대한 ACL 설정을 하여 꼭 필요한 소스IP에 대해서만 응답하도록 설정할 수도 있을 것이다. 또는 123/udp를 리슨하는 ntpd 대신 ntpdate 명령어를 cron 을 통해 동기화할 경우 특정 포트를 리슨하지 않기 때문에 ntpd의 대안으로 생각해 볼 수도 있다.

자신이 운영하는 조직 또는 네트워크 대역에서 이에 취약한 ntp 서버가 있는지를 확인하려면 다음의 3가지 방법으로 확인할 수 있다.

1) ntpdc 명령어로 확인해 보는 방법

아래와 같이 질의시 timeout이 나면 정상적인 것이다.

 

# ntpdc -n -c monlist pool.ntp.org

maths.kaist.ac.kr: timed out, nothing received

***Request timed out

 

2) nmap 명령어로 확인해 보는 방법

최신 버전의 nmap에서는 nse script를 제공하고 있는데, 이를 활용하여 아래와 같이 질의해 볼 수 있다.

아래 서버의 경우 monlist에 대해 응답하고 있는 것을 알 수 있다.

 

# nmap -sU -pU:123 -Pn -n --script=ntp-monlist 192.168.34.85

 

Starting Nmap 6.40 ( http://nmap.org ) at 2014-01-29 12:05 KST

Nmap scan report for 192.168.34.85

Host is up (0.32s latency).

PORT STATE SERVICE

123/udp open ntp

| ntp-monlist:

| Target is synchronised with 210.173.160.87

| Public Servers (1)

| 210.173.160.87

| Other Associations (185)

| 10.1.198.173 (You?) seen 6 times. last tx was unicast v2 mode 7

| 222.146.205.218 seen 26721423 times. last tx was unicast v2 mode 7

| 107.22.163.51 seen 692940790 times. last tx was unicast v2 mode 7

| 59.46.172.253 seen 35057211 times. last tx was unicast v2 mode 7

| 127.0.0.1 seen 2 times. last tx was unicast v2 mode 6

| 173.217.36.243 seen 274 times. last tx was unicast v2 mode 7

| 173.25.188.13 seen 9110 times. last tx was unicast v2 mode 7

| 69.138.111.24 seen 281 times. last tx was unicast v2 mode 7

| 107.2.112.102 seen 552 times. last tx was unicast v2 mode 7

 

중략...

 

3) http://openntpproject.org/ 로 확인하는 방법

http://openntpproject.org/ 에서는 특정 IP 를 입력하면 해당 IP 대역(/22이하)에서 오픈되어 있는 ntp 서버 목록을 보여주고 있다. 따라서, 자신이 운영하고 있는 대역에 취약한 ntp서버가 없는지 확인해 보는 것이 좋다.

2. SQL 인젝션 취약점 방법을 3가지 이상 기술

1) 웹어플리케이션과 연동되는 데이터베이스의 접근 권한을 최소화.

- 연동되는 DB계정을 sa, root 같은 관리자 계정으로 설정 금지

- 웹서비스 전용 권한이 축소된 계정을 생성하여 사용

2) internal Error(500) Page에 대한 오류정보를 노출 금지

3) 데이터베이스 쿼리에 사용되는 문자열을 검사하여 모두 삭제하도록 처리

- EXEC XP_, EXEC SP_, UNION, SELECT, INSERT, UPDATE, 쭈석처리를 의미하는 - -, # 등

4) 사용자의 입력 값 및 서버로 전송되는 모든 파라미터에 대해 필터링 처리를 수행

- single quote( '), Double quote( ") 문자 발견시 삭제 또는 replace 처리

- 파라미터의 데이터 타입을 구분하여 동일한 데이터 타입만 허용하도록 처리

- 파라미터 별 데이터 길이 값을 제한

5) Database 운영 레벨에서 SQL Injection 방어

- DB 계정에 최소 권한 부여

- 웹사이트에서 사용되는 DB 계정에 최소한의 권한만 부여

- DB 계정에 system 권한 (sysdba, sa, root 등)을 미부여

- 에러 발생 시 웹서버 또는 WAS에서 정형화된 에러 페이지를 출력하도록 설정하여 에러에 의한 DB 정보 노출을 방지

- SQL Server의 경우 xp_cmdshell 확장 프로시저를 제거

3. 리눅스 종류와 그 버전을 알아 볼 수 있는 방법에 대하여 간단하게 서술

리눅스 종류 확인

# Cat /etc/issue 

# Cat /proc/version

# Cat /etc/*-release

커널 버전 확인

# uname -a

4. 운영체제 버전별로 제공되는 보안서비스, 보안정책, 보안 취약점을 파악할 수 있는 방법

1) Windows

- Update 확인

- 방화벽 활성 유무 확인

- MBSA 도구 등을 이용하여 취약점 점검

2) Linux

- 패키지 업데이트(yum update, apt-get update 등)

- iptables, TCP Wrapper 등의 정책 확인

- nessus 등의 도구를 이용한 취약점 점검

5. 윈도우즈 파일시스템이 대하여 각각 비교 설명

윈도우즈 파일시스템은 대표적으로 FAT, FAT1

1. FAT

- 

2. FAT32

3. NTFS