[SK shieldus Rookies 16기] 클라우드 기반 스마트 융합 보안 과정 교육 정리(36일차)

오늘 학습 주제

1. 소스코드 취약점 진단

2. 소스코드 취약점 진단 실습

3. 클라우드 진단

 

 

 

 

소스코드 취약점 진단

---

 

- 동적 진단 vs 정적 진단(소스코드 진단) -

동적진단

• 장점 상대적으로 진단 소요기간이 적다 (1 URL = 2~3 Day or 1 ~ 2 week)
• 단점 상대적으로 누락의 가능성이 높음

정적 진단

• 장점 보다 Depth 있고 상세한 진단이 가능(정답지인 소스코드를 보고 진단하기 때문)
• 단점 진단 소요기간이 오래 걸린다(최소 2주~수개월)
  • 진단자 역량에 따라 결과 산출물의 품질이 달라진다(코드가 사용하는 언어의 이해도에 따라 달라진다)
  • 그렇기에 소스코드 방법론(data tracing)을 사용

 

 

- 소스코드 진단 -

소스코드 진단
정의	소스코드를 활용하여 애플리케이션 내 모든 입/출력 값에 대해 DATA Tracing 을 통해 취약점 누락 최소화 및 상세 취약점 점검을 수행하여 보안 수준을 향상하는데 목적
특징	기존 동적 진단 대비 Depth 있는 진단 수행 및 다양한 케이스 도출이 가능함 소스코드 자동화 도구(AppScan, Fortify 등) 대비 과/오탐 비율이 적다 개발 언어에 구애 받지 않고 모든 분석이 가능함 (입/출력 DATA Tracing) 취약점 다포인트 리스트 업 방식을 통한 누락률 최소화 입/출력 분석을 통한 상세 서비스 분석이 가능함 진단자 역량에 따라 산출물 품질이 결정됨
방식	자동화 솔루션(App Scan / Fortify 등) 결과 보고서가 자동으로 출력 반자동화 장점 간편하고 시간이 적게 소모 단점 과/오탐 비율이 크다 그렇기에 솔루션을 잘 이해하고 있는 엔지니어(진단자)가 필요 수동진단 편차가 큰 결과물이 나온다 장점 도출한 취약점에 대한 결과가 명확하다(사람이 직접 하기 때문) 단점 시간 소모가 크고 진단자에 대한 결과물의 편차가 크다

 

취약점 포인트

 

동적진단에서의 환경분석보다

소스코드에서의 환경분석이 더 자세하다

 

 

- 소스코드 진단 프로세스 -

 

개발자마다 변수명를 선언하는 규칙이 다르기 때문에

분석을 하면서  유형을 파악

 

 

- 소스코드 진단 환경 분석 -

 

각각의 회사마다 고유의 정책이 있기 때문에

 

IP - ELB로 IP가 가려지는 경우가 있으니 사전에 내가 공격하는 IP를 확인하여 실제 대상 서비스인지 확인

 

OS - 올바른 공격을 하기 위해 OS의 정보를 확실하게 확인

 

개발언어 - 언어에 특화된 취약점을 찾을 수 있음

 

open source - 사용하는 라이프러리에 따라 구조를 확인하고 취약점 진단

 

 

- 소스코드 진단 RAWDATA 작성 -

소스코드 진단 RAWDATA
정의	전달받은 모든 소스를 확인하고 분석하는 것은 시간이 오래 걸리기 때문에  입/출력 DATA와 환경 구성을 빠르게 파악하기 위해 고안된 방법
키워드	기존 동적 진단 대비 Depth 있는 진단 수행 및 다양한 케이스 도출이 가능함 소스코드 자동화 도구(AppScan, Fortify 등) 대비 과/오탐 비율이 적다 개발 언어에 구애 받지 않고 모든 분석이 가능함 (입/출력 DATA Tracing) 취약점 다포인트 리스트 업 방식을 통한 누락률 최소화 입/출력 분석을 통한 상세 서비스 분석이 가능함 진단자 역량에 따라 산출물 품질이 결정됨
방식	자동화 솔루션(App Scan / Fortify 등) 결과 보고서가 자동으로 출력 반자동화 장점 간편하고 시간이 적게 소모 단점 과/오탐 비율이 크다 그렇기에 솔루션을 잘 이해하고 있는 엔지니어(진단자)가 필요 수동진단 편차가 큰 결과물이 나온다 장점 도출한 취약점에 대한 결과가 명확하다(사람이 직접 하기 때문) 단점 시간 소모가 크고 진단자에 대한 결과물의 편차가 크다

 

여기서 data는

개발자의 코딩 유형(변수 함수의 선언명)

입출력 등에 사용되는 파일들을 집중적으로 확인

 

 

- 소스코드 진단 분석 방법 -

소스코드 분석 방법
방법	개발자 별 각기 다른 스타일로 개발이 구현되어 있기 때문에 진단자가 서비스 기능에 목적을 두고 분석을 할 경우 SourceCode를 파악하기가 어렵기 때문에 애플리케이션에서의 DATA Tracing(흐름)을 추적하여 서비스를 분석해야함 입출력 RAW_DATA 작성을 통해 파악된 유형을 추적 해야하며, 소스코드만 가지고 분석이 어려울 경우에는 실제 서비스에 접근하여 동적(PROXY)으로 추가 정보를 수집해야함 (동적 + 정적 분석을 통해 상호보완 필요) 입/출력 Tracing 및 개발자 유형 파악이 완료된 이후에는 좁은 범위의 키워드 검색이 필요함

 

 

소스코드 취약점 진단 실습

---

- 소스코드 진단 XSS -

최선 특수문자 필터링 

최대한 모든것을 어우르는 표현을 적어준다 (모든 입출력에 대한 필터링)

필터링 - 공격구문을 공격구문으로 동작되지 않게 바꾸는 것

 

차선 하위단계의 보안조치

 

 

- 소스코드 진단 SQL Injection -

자바에서는 Statement을 지양(보안과정이 복잡하기 때문에)

prepared를 사용하면 데이터를 바인딩하여 쿼리로서 동작이 불가능해짐

mybatis sql map

# 동적쿼리 불가능

$ 동적 쿼리 가능

 

 

- 소스코드 진단 파일 업로드-

자바스크립트 안에서 자바스크립트를 정의할 수 있기 때문에 필터링이 의미가 없다

서버에서 필터링을 해야 한다

 

 

- 소스코드 진단 경로 탐색 -

파일명에 대한 경로 검증이 부재

 

 

 

 

클라우드 진단

---

 

- 클라우드 진단 -

현재 클라우드 진단을 명확하게 하고 있는 기업은 X

클라우드 진단의 개념이 다양하다

운영적인 관점, 관리 컨설팅 관점, 취약점 진단/모의해킹 관점

고도화 진행 중

 

- 클라우드 진단 Process -

 

담당자의 인터뷰가 필요

정형화되지 않았으며 기준이 필요

 

 

 

- 클라우드 진단 특징 -

 

 

 

- Security Group와 Network ACL -

공통점 

IP/Port 기반 접근 제어

 

SG = 인스턴스 기반 IP/Port ACL

Network ACL = 네트워크 기반 IP/Port ACL

 

둘 다 사용하는 것이 보안에 좋지만 현실적으로는 ACL을 Control로 사용하지는 않는다

 

 

 

 

 

 

 

 

취약점 진단 Wrap up

---

 

- XSS -

Stored XSS

Reflected XSS

DOM Based XSS

CSRF

 

 

- SQL Injection(RDBMS) -

Blooean Based SQL Injection(Blind SQL Injection)

Error Based SQL Injection(찾는것도 실행시키도 어렵다)

Time Based SQL Injection(DB 시간 함수 활용)

 

 

- File Upload -

확장 검증 X

확장 검증 O but 미흡

 

 

- Directory Traversal -

파일명 검증 X

파일명 검증 미흡(URL Decoding)

 

 

- 인증 -

비인증권한 상승