꼰머의 보안공부

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) 보안 관점

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

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