securitory

WINNIE

WINNIE는 국내 개발자 정진호 외 4명이 개발한 윈도우 기반 퍼저이다.

Harness 자동 제작은 물론 fork() 기술을 이용하여 빠른 퍼징을 수행한다.

개발 배경

• 퍼저는 대부분 리눅스 기반이다. 물론 윈도우 기반 퍼저 역시 존재하지만 당면한 과제가 있다.
• 윈도우의 특성, 즉 비공개 소스, GUI 과다사용, 프로세스 복제 능력 부족 등으로 인해 퍼징 개발에 어려움을 주고 있는 실정이다.
• 결과적으로 윈도우 바이너리에서 61개의 버그를 발견하는 데 성공하였다.

기존 Window 퍼저와 차이점

• 2.2배 더 많은 프로그램 수 지원
• 3.9배 더 많은 프로그램 상태 파악 지원
• 26.6배 더 빠른 실행 능력

  

Window 퍼징 당면 과제

• 사용자가 프로그램을 종료해도 그 프로세스는 종료되지 않음
• GUI 지원으로 인한 비교적 떨어지는 복제 성능
• 비공개 소스 기반으로 인해내부 맥락을 추측하기 어려움

기존 솔루션

• GUI 의도적인 미사용과 파싱 추출, 하지만 소스 코드를 모르기 때문에 효과가 크지 않음
• 입력 파서에서 Loop돌리기, 하지만 전역 프로그램 상태와 충돌할 수 있기에 불안정함

WINNIE만의 솔루션

• Harness generation 이용
• 리눅스의 fork() 메카니즘 차용
• 하이브리드 분석과 Fullspeed 이용

자세히 살펴보면 먼저,

1) Harness generation

Trace Collector

프로그램의 API 콜이나 리턴값을 수집함

• 메인 프로그램, 라이브러리 그리고 Window API를 대상으로 모니터링 수행
• 상호 간 호출 발생 시 해당 정보를 덤프 뜸

Target Extractor

어느 곳에 퍼징을 시도할 지, 대상을 식별함

• Run Trace 정보를 통해 컨트롤 흐름표를 재구성함
• 퍼징이 먹힐 만한 대상을 식별함
• 가령, 메인프로그램은 최초에 타겟이됨, 그리고 ReadFile을 수행하는 윈도우 API가 그 다음이 타겟으로 설정될 수 있음

Harness Builder

최종 입력 값을 만들어냄

• 이미지 뷰어에 이미지 파일과 텍스트 파일을 입력한 뒤,
  그에 대한 결과 값을 통해 로직 정보를 파악 할 수 있었음
  
• 호출된 API 이름을 식별하는 등의 분석 이후에 코드의 윤곽(Skeleton)을 생성함
  
• 지금까지의 과정을 토대로 만들어진 하네스 후보 중 하나를 선택함
  
  

2) Fork()

리눅스 프로세스 복제 기술을 윈도우에 가져옴

• 부모 프로세스에서 자식 프로세스를 파생시킨다
  
• 이후 csrss 서브 시스템을 통해 자식 프로세스를 관리한다
  
• 자식 프로세스에서는 할당된 변수를 해제하는 것을 반복한다
  
• csrss.exe : 윈도우 시스템에 기본으로 동작되는 프로세스로, 클라이언트 요청에 대한 작업자 스레드를 만들거나 삭제하는 MS 프로그램
  
  

3) Fullspeed Fuzzing

Code Coverage 수집을 목적으로 함

• 각 각 의 베이직 블락마다 브레이크 포인트를 걸어둠
• 브레이크 포인트 마다 충돌이 생기는 지 모니터링함
• 충돌이 생기지 않는 곳에는 브레이크 포인트를 해제하고 모니터링을 미수행함
• 점진적으로 충돌을 찾기 위해 위 행동을 반복함

WINAFL vs WININE

성과 및 오픈 소스 주소

오픈소스 : https://github.com/sslab-gatech/winnie

마무리

기존 윈도우 기반 퍼저인 AFL과 비교하여 월등한 성과를 보여준 WINNIE를 알게되었다.

여러므로 성능이 향상된 윈도우 퍼저이니, 앞으로 윈도우 퍼징을 할 기회가 온다면 WINNIE를 사용해보자!

참조

VPC란?

AWS내에서 영역을 2개로 나누어 하나는 외부에서 접속가능한반면 나머지 영역은 접근을 막는다.가령 웹서버는 public영역에 두고 DB서버는 private에 둠으로써 보안의 이점을 얻을 수 있다.

VPC에서..

VPC에서 다음 4개만 기억하자!

• 서브넷 : 하나의 VPC내에서 각 각 public과 private에게 할당할 네트워크 대역을 의미함
• 라우팅테이블 : public 영역 내 PC가 인터넷 게이트웨이와 연결할 수 있도록 해줌, 또는 private와 연결
• 인터넷 게이트웨이 : VPC와 외부간의 연결을 위한 게이트웨이를 의미함
• 네트워크 ACL : public, private 각 영역의 방화벽 개념이라고 이해하자

EC2에서..

각 각 public, private로 생성해주자

중요한 것은 public용 인스턴스는 반드시 public 서브넷 IP를 줄 것

결과

• public 인스턴스로의 접속 성공! private으로는 접속안됨~

• public 인스턴스에서만 접속 할 수 있음

$ sudo ssh -i ./fasoo.pem ubuntu@10.0.1.208

마무리

클라우드 보안에 핵심 기술인 VPC를 알아 보았다!

참조

ELK란?

"ELK"는 Elasticsearch, Logstash 및 Kibana, 이 오픈 소스 프로젝트 세 개의 머리글자입니다. 

Elasticsearch는 검색 및 분석 엔진입니다. Logstash는 여러 소스에서 동시에 데이터를 수집하여 변환한 후 Elasticsearch 같은 “stash”로 전송하는 서버 사이드 데이터 처리 파이프라인입니다. 

Kibana는 사용자가 Elasticsearch에서 차트와 그래프를 이용해 데이터를 시각화할 수 있게 해줍니다.

https://www.elastic.co/kr/what-is/elk-stack

설치 환경

◾ AWS EC2, Ubuntu Server 20.04 LTS (64비트 x86)

◾ ELK 5.4.3 버전

설치 과정

◾ 자바 설치

$sudo apt update && sudo apt install openjdk-8-jdk -y
$javac -version
javac 1.8.0_292

$which javac
/usr/bin/javac

◾ 환경변수 설정

$readlink -f /usr/bin/javac
/usr/lib/jvm/java-8-openjdk-amd64/bin/javac

$sudo vi /etc/profile
  unset i
fi
...
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH=$PATH:$HOME:$JAVA_HOME/bin
...

$source /etc/profile

◾ ELK 설치파일 다운로드

$cd ~
$wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.4.3.deb
$wget https://artifacts.elastic.co/downloads/logstash/logstash-5.4.3.deb
$wget https://artifacts.elastic.co/downloads/kibana/kibana-5.4.3-amd64.deb
$wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-5.4.3-amd64.deb

◾ 설치

$sudo dpkg -i elasticsearch-5.4.3.deb
$sudo dpkg -i logstash-5.4.3.deb
$sudo dpkg -i kibana-5.4.3-amd64.deb
$sudo dpkg -i filebeat-5.4.3-amd64.deb​

dpkg lock에러시

◾ elasticsearch 설정 파일 수정 

$sudo vi /etc/elasticsearch/elasticsearch.yml
...
network.host: 0.0.0.0 #원격 접속 허용
...

◾ kibana 설정 파일 수정

$sudo vi /etc/kibana/kibana.yml
...
server.host 0.0.0.0
...

◾ fileabeat 설정 파일 수정

$sudo vi /etc/filebeat/filebeat.yml
...
- input_type: log

  # Paths that should be crawled and fetched. Glob based paths.
  paths:
	- /var/log/syslog        #전반적인 시스템 로그   
	- /var/log/apache2/*.log #아파치 웹 로그를 elasticsearch에게 전달
...

◾ ELK 실행 및 확인

$sudo systemctl start elasticsearch
$sudo systemctl start logstash
$sudo systemctl start kibana
$sudo systemctl start filebeat

$sudo systemctl enable elasticsearch #재부팅시 자동 실행
$sudo systemctl enable logstash
$sudo systemctl enable kibana
$sudo systemctl enable filebeat

$sudo systemctl status elasticsearch
$sudo systemctl status logstash
$sudo systemctl status kibana
$sudo systemctl status filebeat

◾ 웹서버 로그 시각화를 위해 Apache2 설치 및 실행

$sudo apt-get install apache2 -y

$sudo systemctl start apache2
$sudo systemctl enable apache2
$sudo systemctl status apache2

결과

◾ filebeat가 elasticsearch에게 로그를 전달해주는 지 확인

http://[AWS IP]:9200/_cat/indices?v

◾ kibana에 접속해서 결과 확인

http://[AWS IP]:5601/

AWS 우분투에 ELK Stack 설치 끝!

마무리

리눅스 시스템 내에서 동작하는 서비스들의 로그 저장 폴더를 지정해주면 다음과 같이 json형식으로 로그를 받아 시각화 시킬수있다!

참조

취약점

공격자는 rootkit 설정 파일들을 서버 관리자가 쉽게 발견하지 못하도록 /dev 디렉터리에 device 파일인 것처럼 위장하는 수법을 많이 이용함

따라서 /dev 안에 일반 파일이 있는 지 확인한다.

보안조치

◾ 일반 파일 존재 유무를 확인

[root@localhost dev]# find /dev -type f -exec ls -l {} \;

결과는 일반 파일이 없다! 

◾ major, minor number을 가지지 않는 device일 경우 삭제

일반적으로 디바이스 파일은 권한앞에 c가 붙고 5번째 인자에 Major Number와 이어서 Minor Number가 붙는다.

만약 위 넘버가 설정되어있지 않다면 비정상적인 파일이라고 볼 수 있다.

마무리

공격자는 해킹툴을 PC내 특정 저장소에 숨겨두고자 한다. /dev는 해커들이 찾는 피난처라고 보인다.

취약점

1. world writable은 파일의 내용을 소유자나 그룹 외 모든 사용자에 대해 쓰기가 허용된 파일이다.

시스템 파일과 같은 중요 파일에 설정이 될 경우, 악의적인 사용자가 해당 파일을 마음대로 파일을 덧붙이거나 지울 수 있게 되어 시스템의 무단 접근 및 시스템 장애를 유발할 수 있음

따라서 "world writable"파일 존재 시 사용 목적을 확실히 알고 불필요 시 삭제한.

2. 리눅스에서 각 사용자는 환경 변수를 가진다. 이 파일을 통해 특정 명령어의 참조 우선순위를 지정할 수 있다.

비인가자가 이 파일을 변조하여 의도되지 않은 명령어 수행이 가능하다.

따라서 관리자 또는 사용자 이외 쓰기 권한이 부여되지 않도록 한다.

보안조치

◾ Other에게 2(쓰기권한)이 부여된 파일을 검색

[root@localhost ~]# find / -type f -perm -2 -exec ls -l {} \;

◾ ls -l "환경변수 파일"

쓰기권한이 사용자 이외에 부여되어있는 지 확인

[root@localhost ~]# ls -l .bashrc 
-rw-r--r--. 1 root root 176 12월 29  2013 .bashrc

취약점

◾ SUID, SGID 파일의 접근권한이 적절하지 않을 경우 roo권한 탈취가 발생할 수 있다.

◾ Sticky bit #

실습

◾ 일반 유저가 shadow파일을 열람할 수 없다. 하지만 파일의 소유자가 root이면서 SetUID설정이 되면

열람이 가능해진다. 이것은 일시적으로 root의 권한을 부여받기 때문이다.

[test@localhost /]$ cat /etc/shadow
cat: /etc/shadow: 허가 거부
[root@localhost /]# su root
[root@localhost /]# ls -l /usr/bin/cat
-rwxr-xr-x. 1 root root 54080  8월 20  2019 /usr/bin/cat

[root@localhost /]# chmod 4755 /usr/bin/cat
[root@localhost /]# ls -l /usr/bin/cat
-rwsr-xr-x. 1 root root 54080  8월 20  2019 /usr/bin/cat

[root@localhost /]# su test
[test@localhost /]$ cat /etc/shadow
root:$6$kZXbeAFq$bpGsWrBsetT5c5DYgmhQWV3bd3siNkf2dGd6wAd3G.HIthFTVBFoReYd.UUUE47eSi70D5qEuKnAgF81:18712:1:60:7:::

보안조치

◾ SetUID(4000)와 SetGID(2000)가 설정된 파일을 조회하는 명령어(-4000는 4000 이상을 의미)

[root@localhost ~]# find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -al {} \;

◾ SetUID, SetGID 제거 명령어

[root@localhost ~]# ls -l /usr/bin/vi
-rwsr-xr-x. 1 root root 928056 10월 14 01:13 /usr/bin/vi
[root@localhost ~]# chmod -s /usr/bin/vi
[root@localhost ~]# ls -l /usr/bin/vi
-rwxr-xr-x. 1 root root 928056 10월 14 01:13 /usr/bin/vi

마무리

SetUID는 권한을 다루기때문에 꼭 확인해주어야 하고 주기적인 검사를 위한 cron을 이용하는 것이 좋다.

취약점

1. 사용자가 없는 파일은 관리가 되지 않아 공격자의 도구로 사용될 수 있다. 따라서 NOUSER 파일은 삭제해주자!

2. 시스템의 중요 파일의 권한 관리가 미비할 경우 내부 자원의 유출 및 변조와 서비스 오작동을 초래할 수 있다.

보안조치

■ 사용자가 없는 파일은 지워준다.

#find / -nouser -exec rm {} \;
#find / -nogroup -exec rm {} \;

■ /etc/passwd파일의 소유자가 관리자인 것과 권한이 644로 설정되어있는지 확인한다.

"/etc/passwd" 파일의 변조가 가능할 경우 shell변조, 사용자 추가/삭제, root 권한 획득이 가능함

[root@localhost ~]# ls -la /etc/passwd 
-rw-r--r--. 1 root root 2456  1월  5 23:41 /etc/passwd

■ /etc/shadow 파일의 소유자가 관리자인 것과 오직 읽기 권한만 할당되어있는지 확인한다.

"/etc/shadow" 파일은 시스템 모든 계정의 암호화된 패스워드가 저장된 파일이다. 따라서 관리자만이 열람할 수 있도록 한다.

[root@localhost ~]# ls -la /etc/shadow
-r--------. 1 root root 1501  1월  5 23:41 /etc/shadow

■ "/etc/hosts" 파일의 소유자가 관리자인 것과 권한이 600인지 확인한다.

"/etc/hosts" 파일은 웹페이지의 IP주소를 찾을 때 사용되며 DNS 서버보다 우선한다. 이 파일이 변조되면 악성 사이트로 접속되는 파밍 공격 등에 악용될 수 있다.

[root@localhost ~]# ls -la /etc/hosts
-rw-------. 1 root root 158  6월  7  2013 /etc/hosts

■ "/etc/(x)inetd.conf" 파일의 소유자가 관리자인 것과 권한이 600인지 확인한다.

위 파일은 슈퍼데몬 설정 파일로써, 비인가자에게 쓰기 권한이 부여되어있을 경우 root권한으로 불법적인 서비스를 실행할 수 있다.

[root@localhost ~]# ls -la /etc/xinetd.conf 
-rw-------. 1 root root 1001  4월  1  2020 /etc/xinetd.conf

■ "/etc/syslog.conf" 파일의 소유자가 관리자인 것과 권한이 644인지 확인한다.

위 파일은 syslog데몬의 설정 파일로서, 공격자는 파일 변조를 통해 흔적 또는 시스템 오류 사항을 분석하기 어렵게 할 수 있다.

[root@localhost ~]# ls -la /etc/rsyslog.conf 
-rw-r--r--. 1 root root 3232  9월 30 22:19 /etc/rsyslog.conf

■ "/etc/services" 파일의 소유자가 관리자인 것과 권한이 644인지 확인한다.

위 파일은 시스템 내의 모든 서비스에 매칭 되는 포트번호를 정의하는 파일이다. 공격자는 운영 포트 번호를 변경하여 정상적인 서비스를 제한하거나 허용되지 않은 포트를 열어 악성 서비스를 의도적으로 실행할 수 있다.

[root@localhost ~]# ls -la /etc/services 
-rw-r--r--. 1 root root 670293  6월  7  2013 /etc/services

마무리

위 파일들이 보편적인 설정 파일인 만큼 공격의 노출도 또한 높다. 따라서 권한 관리를 잘해줘야 한다.

dreamhack.io/wargame/challenges/17/

참이면 "Correct"를 반대면 "Wrong"을 반환한다고 한다.

◾ 일단 실행부터 해보자

키값 인증 문제다, 여기서 알 수 있는 것은 비교문이 쓰일 것!

◾ 프로그램 정보 확인

컴파일러 종류가 어셈블러이고 코드가 직관적일 것으로 보임

◾ 문자열 검색을 통해 메인 함수를 찾아보자

◾ Correct로 가기 위해 점프 문(노란색)에서 wrong으로 분기되지 않게 한다.

그 말은 즉슨 바로 위의 함수의 반환 값이 1이 되어야 함을 뜻한다(0일 때, ZF=1 따라서 wrong으로 분기됨) 

함수로 들어가 보자!

◾ 네, 24번 반복하는데 조건이 있겠죠? 살펴보죠

◾ 저는 "pingu"라고 입력했고, 3000 주소(노란색)에는 I`gtcgBf..... 값이 들어있네요.

두 값을 비교할 텐데 한 바이트씩 가져와서 비교할 예정입니다. 자세히 보면 그냥 비교하지 않죠?

xor와 +연산을 수행한 결과를 비교합니다.

◾ 첫 번째 반복문에서 i=0, rsp에 저장됨

1) ecx = "p"

2) p xor 0

3) edx = 0

3) ecx = ("p"+0)

최종 ecx값을 기존 문자열에 첫 문자 I와 비교합니다

다른 문자다 그럼 for문을 빠져나가고 동일 문자이면 다음 반복문을 수행합니다~

◾ 두 번째 반복문에서 i=1

1) ecx = "i"

2) p xor 1

3) edx = 1

3) ecx = ("i"+2)

총 24번 반복합니다

◾ input을 I라고 입력해보니 동일한 문자라고 하네요 반복문 수행~

나머지 값들도 xor, +연산 조건을 충족하게 만들어봅시다.

#include "stdio.h"

int main(int argc, char* argv[])
{
	//I`gtcgBf.xii{.m.h...M¥.E의 아스키코드값
	int arry[24] = { 73, 96, 103, 116, 99, 103, 66, 102, 128, 120, 105, 105, 123, 153, 109, 136, 104, 148, 159, 141, 77, 165, 157, 69 };

	for (int i = 0; i < 24; i++) {	//24번 반복
		for (int n = 0; n < 128; n++) {	//아스키코드 0~127 중 조건에 맞는 값 찾기
			if ( (n xor i) + 2*i == arry[i]) {
				printf("Hex : %x\tDex : %d\tAski : %c\n", n, n, n);
				//printf("%c",n); //한줄로
				break;
			}
		}
	}
	return 0;
}

◾ 결괏값을 넣어보니 최초의 목적이었던 함수 반환 값이 1이 되었고 따라서 ZF에 0이 세팅되었습니다.

Correct로 진입 성공!

마무리

이번 예제를 통해 xor연산 방식과 for문에서 i가 어셈블리어에서 어떻게 구현되는지 알 수 있었습니다 :)

취약점

관리자가 명령어(예: ls, mv, cp등)를 수행했을 때 root 계정의 PATH 환경변수에 "." (현재 디렉터리 지칭)이 포함되어 있으면 현재 디렉터리에 명령어와 같은 이름의 악성파일이 실행되어 악의적인 행위가 일어날 수 있음

직접해보기

기존 환경변수 내용 확인

[root@localhost ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

실습을 위해 "." 추가!

[root@localhost ~]# vi /etc/profile
...
export PATH=.:$PATH
...
[root@localhost ~]# source /etc/profile

변경된 환경변수 확인

[root@localhost ~]# echo $PATH
.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

다음과 같이 c프로그램을 짜고 ls라는 이름으로 컴파일!

root는 ls를 입력하였으나 환경변수에 .이 선행하므로 공격자가 만들어 놓은 ls명령어를 수행

결과

hack파일이 setuid설정을 받아 실행시 root의 권한을 이용할수있게됨

보안조치

root 계정의 환경변수 설정파일("/.profile", "/.cshrc" 등)과 "/etc/profile" 등에서 PATH 환경변수에 포함되어 있는 현재 디렉터리를 나타내는 "."을 PATH 환경변수의 마지막으로 이동 "/etc/profile", root 계정의 환경변수 파일, 일반계정의 환경변수 파일을 순차적으로 검색하여 확인

Unix 서버 취약점 분석, 평가 항목

환경 :

VMware

CentOS Linux release 7.9.2009 (Core)

다음 항목을 나만의 리눅스 서버에 적용하자!

참조