취약점 분석 - 웹해킹 원리

*화이트햇 스쿨 2기에서 이수한 이론교육 내용을 바탕으로 작성되었습니다.

 

1. 해킹/웹해킹 개요

 

해킹이란?

개발자가 의도하지 않은 동작을 입력 혹은 행위를 통해 악의적인 결과를 만들어내는 것

 

웹해킹이란?

웹 서비스에 접속하는 클라이언트와 웹 서비스를 구동하는 서버가 요청과 응답을 주고받으며 진행되는 코드 흐름 중 발생하는 취약점을 찾는 것

- 클라이언트단

  → 브라우저(크롬, 사파리, 파이어폭스 등)

  → HTML/JS/CSS

  → DOM 엔진, JS 엔진

  → Vue/React/Angular

- 서버단

  → 웹서버/웹애플리케이션서버: apache, nginx ... / tomcat, jeus ...

  → PHP, JSP, ASP, python, nodejs, ruby ...

  → Laravel, Spring, flask, Django, express, rubyonrails ...

  → 데이터베이스: mysql, oracle, mssql, sqlite ...

 

2. 웹 요청과 응답

 

Method

- GET: URL 쿼리를 통해 파라미터를 담아 요청

- POST: HTTP Body를 통해 파라미터를 담아 요청

- PUT: 서버에 리소스를 생성(업로드) 하거나 수정

- DELETE: 서버의 리소스를 삭제

- PATCH: 서버의 리소스를 일부 수정

- HEAD: Response에 Content 없이 헤더 부분만 요청

- OPTIONS: 서버에서 지원하는 메서드 종류를 열거

 

REST API

- GET: 리소스 조회

- POST: 리소스 생성 요청

- PUT/PATCH: 리소스 업데이트

- DELETE: 리소스 삭제

 

URI

https://id:pw@www.arang.kr:port/somereq.html?someparam1=value1&someparam2=value2#hash 

- Protocol: 서버 리소스에 접근하기 위해 사용되는 프로토콜

- Host: 서버의 도메인 이름이나 IP 주소, 접속하기 위한 id:pw, 도메인명/IP와 포트로 구성되어 있음, http에서는 id:pw는 거의 사용하지 않지만, 지원하고 있기 때문에 여러 우회 기법에 사용됨

- Path: 서버 내의 리소스의 위치를 지정하는 경로

- Query String: 파라미터를 전달하는데 사용

 

HTTP Version

- HTTP/1.0: 1996년에 출시된 첫번째 버전, 하나의 연결에 하나의 요청과 응답만 처리가 가능

- HTTP/1.1: 여러 개의 요청과 응답을 하나의 TCP 연결에서 처리 가능, Keep-Alive 연결을 통해 연결 재사용, 캐시 등 기능 또한 도입됨

- HTTP/2: 2015년에 출시된 버전, 요청과 응답을 작은 프레임 단위로 분할하여 전송

- HTTP/3: 2020년에 출시됨, QUIC 프로토콜을 기반으로 TCP가 아닌 UDP를 사용하여 지연 시간을 낮춤

 

주요 Request Header

- Host: 요청하는 호스트(도메인/IP)의 이름

- Content-Type: 요청하는 POST Body 데이터의 형식을 지정

- Content-Length: 요청하는 POST Body 데이터의 길이

- User-Agent: 요청하는 클라이언트의 정보, 브라우저 버전 등이 적힘

- Referer: 요청 패킷이 어디서부터 흘러왔는지 알려주는 정보

- Cookie: 사용자 세션 정보 등과 같이 유지하고자 하는 정보 등이 적혀있음, 어떠한 정보를 저장할 때 브라우저에 저장하고 매 요청시마다 전송

- Session: 어떠한 정보를 저장할 때 서버에 저장(메모리, 파일, 데이터베이스 등), 서버에서 관리

 

Status Code: 요청에 대한 응답 상태 코드

- 200 OK: 정상응답

- 301 Moved Permanently: 리소스가 다른 곳으로 영구적으로 이동됨

- 302 Found: 리소스가 일시적으로 다른 위치로 이동됨, 보통 Location 헤더를 통해 이동할 위치를 지정

- 400 Bad Request: 요청이 잘못되었거나 서버가 이해할 수 없는 요청

- 401 Unauthorized: 자격 증명이 없어 인가되지 않은 요청

- 03 Forbidden: 권한이 없어 인가되지 않은 요청

- 404 Not Found: 없는 페이지

- 500 Internal Server Error: 서버 내부 오류, 서버가 요청을 해석하여 서버단 언어로 해석 도중 에러가 생겼을 때

 

주요  Response Header

- Server: 서버의 정보를 나타냄, 서버 정보, 버전 등의 정보를 제공

- Content-Type: 응답 데이터의 content-type을 정의, Character set(인코딩)에 대한 정보도 전달 가능

- Set-Cookie: 쿠키(세션 값 등) 정보를 세팅 가능, 만료와 적용 대상 path, domain 지정 가능

- Content-Length: 응답 데이터의 길이

 

3. 프록시 실습

 

BurpSuite 혹은 Telerik Fiddler 사용

 

4. Client Mitigation

 

클라이언트단 취약점

- XSS(Cross-Site Scripting)

- CSRF(Cross-Site Request Forgery)

- Open Redirection

 

SOP(Same Origin Policy)

: 웹 브라우저에서 동작하는 스크립트나 요청이 특정 출처(Origin)에서 온 것인지 확인하는 규칙

 

CORS(Cross Origin Resource Sharing)

: 웹 브라우저의 요청이 안전한 출처로의 요청인지 검증하는 방어 기법으로, SOP에 의하면 모두 차단해야하지만 외부 스크립트, 이미지 등을 사용하기 위해 허용해주는 정책

 

CSP(Content Security Policy)

- 서버에서 허용한 동작만 브라우저에서 수행되도록 설정하는 정책

 

5. XSS(Cross-Site Scripting)

 

개념

: 브라우저가 해석하는 JS에 임의의 스크립트를 삽입하여 본래 개발자의 의도 외의 동작 등이 실행되는 취약점

 

위협

- XSS가 발생하는 링크를 피해자가 클릭하거나, 임의의 JS 구문이 담긴 페이지에 접근함으로써 임의의 JS 구문이 실행됨

- XSS를 통해 JS로 접근 가능한 정보(쿠키, 다른 페이지 소스코드, DOM 영역 내 코드 등)를 공격자 PC로 전송하거나, CSRF 취약점과 연계햐여 의도하지 않은 동작을 피해자 명의의 세션으로 수행하도록 할 수 있음

 

대응방안

- 주요 특수 문자나 onfocus onerror와 같은 event attribute 등을 WAF 혹은 소스코드단에서 필터링 혹은 치환하도록 함

 

공격실습 진행

 

6. Open Redirection / CSRF

 

Open Redirectoin

개념

: HTML이나 JS에서 사용자의 입력을 통해 페이지를 이동시킬 경우, 임의의 페이지로 이동시킬 수 있는 취약점

 

위협

- Open Redirect 취약점이 존재하는 URL을 클릭하였을 시, 대상 사이트와 비슷하게 만들어진 피싱사이트로 이동시킴으로써, 분명 처음에는 정상사이트였으므로 의심을 덜하고 ID/PW 등 정보 입력 가능

- XSS와 연계될 시 Open Redirection을 통하여 Internet Explorer의 XSS Auditor를 우회할 수 있음

- Referer Check 우회 가능

 

대응방안

- 입력받은 파라미터를 페이지 이동에 사용할 시, domain/host 검사를 수행 후 맞지 않다면 drop

 

공격실습 진행

 

CSRF(Cross-Site Request Forgery)

- URL에 접근하는것만으로 검증 없이 정상적으로 요청이 처리되는 취약점

 

위협

- Ex. 비밀번호 변경 기능에 CSRF 취약점 존재 시 공격자가 원하는 임의의 비밀번호로 변경 가능

- Ex. 송금 기능에 CSRF 취약점 존재 시 공격자 계좌로 송금 가능

- XSS와 연계될 시 보다 복잡한 CSRF 체이닝이 가능해짐

- Ex. 개인정보/금융정보 등을 조회 페이지로 정보 획득 후 정보들을 공격자 페이지로 전송

 

대응방안

- CSRF Token, Referer Check 등을 통해 실제 사용자가 해당 기능을 사용하는게 맞는지 확인

 

공격실습 진행

 

7. 웹의 주요 취약점

 

OWASP Top 10

- 웹 애플리케이션 보안에 가장 위협적인 취약점 중 상위 10개에 대한 명세를 담은 지침

- 광범위한 조직에게 발생할 수 있는 가장 심각한 웹 애플리케이션 보안

- 3~4년 주기로 순위가 업데이트 됨

취약점	설명
A1 - 인젝션	SQL, OS, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생함, 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있음
A2 - 취약한 인증	인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용함
A3 - 민감한 데이터 노출	다수의 웹 애플리케이션과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않음, 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있음, 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저에서 주고 받을 때 각별한 주의가 필요함
A4 - XXE	오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가함, 외부 개체는 파일 URL 처리기, 내부 파일 공유, 내부 포토 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있음
A5 - 취약한 접근 통제	인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않음, 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 증 권한 없는 기능과 데이터에 접근할 수 있음
A6 - 잘못된 보안 구성	잘못된 보안 구성은 가장 흔하게 보이는 이슈임, 취약한 기본 설정, 미완성, 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과임, 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/업그레이드를 진행해야

 

주요 정보 통신 기반 시설 취약점 분석/평가 가이드

- 2017년 KISA 주관 하에 제작된 취약점 진단 지침

- 28개의 웹 취약점 항목에 대한 진단 방법을 다룸

- IT 시스템 관리자를 위한 기술 안내 가이드

 

8. OS 커맨드 인젝션

 

개요

- 적절한 검증절차를 거치지 않은 사용자 입력 값에 의도하지 않은 시스템 명령어를 실행 가능한 취약점

- 발견 빈도는 낮으나, 시스템 명령어를 직접 실행할 수 있어 파급력이 큼

- shell_exec, system 등의 함수를 통해 트리거

 

진단

- 쉘에서 특수한 역할을 하는 | & ; ` 문자를 입력 값에 추가해 반응 관찰

- ; 앞의 명령어를 실행한 후 뒤의 명령어를 실행

- & 앞의 명령이 성공했을 경우에만 뒤의 명령어를 실행

- | 앞의 명령어 성공 여부에 관계없이 뒤의 명령어를 실행

- ` 기존 명령어를 실행하기 전에 `로 둘러싸인 명령어를 먼저 실행

 

시나리오

- 공격이 방화벽에 막힐 수 있으나 안에서 밖으로 나가는 패킷은 잘 검사하지 않기에 리버스 쉘을 사용해 우회 가능

- Bash, PERL, Python, Netcat 등 다양한 프로그램을 사용 가능하며 서버에 어떤 프로그램이 설치되어 있는지에 따라 유동적으로 공격

 

9. SQL 인젝션

 

개요

- 애플리케이션이 가진 보안상의 허점을 의도적으로 이용하여 개발자가 생각하지 못한 SQL문을 DBMS가 실행하게 하는

취약점

- 취약점으로 인한 피해 시나리오: 데이터베이스 스키마 노출, 애플리케이션 인증 절차 우회, 명령어 임의 실행, 데이터베이스 조작 및 파괴

 

진단

- 데이터베이스의 테이블을 구성하는 각 컬럼들은 이름과 데이터 유형을 가져야하며 대표적으로 사용되는 데이터 유형으로 "VARCHAR", "INTEGER"가 존재

- "VARCHAR"같은 문자열 유형의 컬럼을 SQL 질의를 통해 조회, 수정하려면 싱글 쿼테이션을 사용

- "INTEGER"같은 정수 유형의 컬럼을 SQL 질의를 통해 조회, 수정할 때는 싱글 쿼테이션을 사용하지 않아도 가능

- 로그인 창에 참이 되는 SQL 쿼리를 전달하여 로그인이 되는지 확

- substr(): 문자열의 일부분을 추출하는 함수

- ascii(): 문자열의 아스키 값을 반환하는 함수

- sleep(): 주어진 시간만큼 응답을 지연하는 함수

- if(): 1번째 인자가 참이면 2번째 인자를, 거짓이면 3번째 인자를 반환

 

시나리오

- 데이터베이스 정보 탈취: 데이터베이스 이름, 테이블 이름, 컬럼 이름, 컬럼의 타입과 같은 정보를 얻을 수 있는 DBMS의 함수 혹은 메타 테이블을 악용한 공격 기법

- MySQL 대상 버전정보 추출: mysql> select version()

- information_schema: 데이터베이스의 모든 테이블, 뷰, 컬럼, 프로시저에 대한 정보를 제공, 대부분의 DBMS에 존재하나 Oracle은 system view를 대신 사용

- information_schema.tables: 데이터베이스에 있는 테이블 정보에 관한 내용을 담고 있음

 

10. 불충분한 세션 관리

 

개요

- 클라이언트를 구분하기 위해 사용하는 세션 토큰을 탈취하거나 재사용하여 사용자에게 악의적인 영향을 줄 수 있는 취약점

- 세션 토큰이 웹 애플리케이션의 주요 기능에 따라 개별적으로 할당 되어있지 않거나 만료 기간을 지정하지 않았기 때문에 발생하는 취약점

 

시나리오

- XSS 혹은 DNS Spoofing을 통한 세션 하이재킹으로 사용자 개인 정보 열람/수정

  → 로그인한 IP 주소와 접속 IP 주소를 비교해서 검증하는 경우가 있으나, IP 주소가 자주 바뀌는 모바일 기기에서 접속하면 대부분 해당 로직을 비활성화함

- 세션 재사용을 통한 사용자 개인정보 열람/수정

  → 세션 타임아웃은 10분으로 설정하는 것이 권고됨

  → 서비스마다 다르나 보통 24시간 이상 유지되면 진단

- 세션 토큰을 발급하는 과정에서 복잡도가 충분하지 않거나 규칙성이 있을 경우 공격자가 타인의 세션 아이디를 추측할 수 있음

 

JWT?

Json Web Token의 줄임말로,

- 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준

- 인증 기능을 위해 세션 대신 많이 쓰임

 

- 세션: 인증 정보를 서버에 저장 (클라이언트에는 세션의 키만 보관)

- JWT: 인증 정보를 클라이언트에 저장 (변조되지 않았는지 검증하기 위한 Verify Signature를 포함)

 

클라이언트가 자신의 토큰 정보를 Decode(base64) 할 수 있기에 민감한 정보를 저장하면 안됨

 

Verify Signature

- 서버에서 None 알고리즘을 허용할 경우 JWT 토큰을 임의로 수정해도 valid한 토큰으로 취급됨

- 혹은 개발자가 잊고 Verify Signature 검증 자체를 안 할수도 있음

 

공개키 → 대칭키

개발자 의도

1. RSA 암호화(공개키, 인증정보)

: JWT 토큰을 클라이언트에 내려준다

2. 클라이언트가 보낸 JWT 토큰을 복호화 한다

: RSA복호화(개인키, JWT 토큰)

 

공격자는 암호 알고리즘을 바꿀 수 있다

헤더를 변조해 SHA로 암호화했다고 주장한다

SHA암호화(공개키 + 인증정보) 값과 클라이언트가 보낸 JWT 토큰이 같은지 확인한다

공개키는 공개된 값이기에 임의로 서명이 가능하다

 

11. 민감한 데이터 노출

 

개요

: 웹 애플리케이션과 브라우저 간 주고 받는 민감한 데이터가 평문으로 전송되어 다른 사용자에게 노출될 수 있는 취약점

 

진단

- wireshark, tcpdump 등의 패킷 수집 도구 혹은 프록시 피들러를 사용해 민감한 정보가 평문으로 전송되는지 확인

- https 프로토콜을 사용하더라도 http 프로토콜로 접속 후 민감정보 전송이 가능한지 확인

 

시나리오

- 로컬 네트워크 환경에서 클라이언트와 애플리케이션 서버가 평문으로 데이터를 주고받을 경우 공격자는 MITM 공격을 통해 사용자의 로그인 정보를 탈취 가능

- HTTPS를 사용하지 않더라도 브라우저에서 자바스크립트로 공개키 암호를 사용해 데이터를 암호화할 경우 공격이 불가능

- 개발 과정에서 생기는 테스트, 백업 파일이 삭제되지 않고 남아있을 시 공격의 단서가 될 수 있음 (db.sql, Desktop.zip, README, composer.json 등)

- Vi 에디터를 비정상적으로 종료 시 .FILENAME.swp 파일이 생성됨 (index.html → .index.html.swp)

- Blowfish는 FILENAME~, 다른 에디터는 FILENAME.bak 등 생성 됨 (index.html → index.html~ / index.html → index.html.bak)

 

12. XXE

 

개요

- XML 업로드가 가능하거나, XML 문서에 악의적인 내용을 포함할 수 있다면 취약한 XML 프로세스를 공격 가능한 취약점

- XML 파싱 과정에서 외부 개체를 참조하게 해 공격 수행

- 데이터를 가져오거나 원격 코드 실행, 내부망 스캔, DoS 공격을 수행 가능

- DTD: 문서 타입을 정의, 정의하는 과정에서 entity의 사용이 가능

- entity: XML 문서를 구조화하기 위해 사용, 상수와 같은 역할

- internal entity: entity 대상이 DTD 내부에 있을 경우

 

진단

- external entity의 사용 가능 여부를 확인

 

시나리오

- 내부망에서만 접근 가능한 도메인 접근

- 파싱된 결과값을 화면에 응답하지 않을 때 공격자의 서버로 응답을 반환하도록 유도할 수 있음

- 파싱 과정에서 에러가 발생했을 때 에러 메시지를 출력해주면 에러 메시지를 통해 파일을 읽을 수 있음

- 하나의 entity가 다른 entity를 참조하는 행위를 반복시켜 DoS 공격이 가능

- 파싱하지 않는 문자 데이터라는 의미의 <![CDATA[]]> 문법을 사용해 XSS 공격 가능

- <, &, > 등의 특수 문자는 XML에서 문법적인 의미를 가지기 때문에 해당 특수문자를 데이터로 넣기 위해서는 CDATA가 필요

 

13. 취약한 접근 통제

 

개요

- 접근이 제한되어 있는 자원에 대해 인증 및 인가받지 않은 사용자가 임의로 접근하는 취약점

- 자원에 대한 접근 요청 시 사용자가 조작할 수 있는 값을 이요하여 신원을 확인하거나 권한을 검사할 때 발생

 

- 열람 권한이 없는 게시물의 첨부파일 탈취

- 다른 사용자의 개인 정보 수정 페이지 열람

- 권한이 없는 게시판의 게시글 등록

- 다른 사용자의 게시글 열람

 

진단

- 애플리케이션에게 서비스 및 자원 접근에 대한 요청을 할 때 사용자를 구분하거나 권한을 구분하는데 사용되는 파라미터 값을 조작

 

시나리오

- 이체, 선물 기능에서 음수 전달

- 비밀글에 대한 검색 기능

  → 비밀글에 직접 접속은 불가능하지만 검색 과정에서 비밀글의 내용이 검색 결과에 포함되는 경우가 있음

  → 한 글자 씩 추출해내는 방법으로 비밀글의 내용을 알아낼 수 있음

- 결제 과정에서 물건 가격 변조

- 보유 마일리지보다 많은 마일리지를 사용

- 일반 게시물에서 얻을 수 있는 경로를 권한이 없는 게시물에 적용시켜봄

 

14. 잘못된 보안 구성

 

개요

- 인가되지 않은 영역으로 접근할 수 있는 권한이나 시스템 정보를 얻기 위해 패치되지 않은 취약점을 공격

- 디폴트 계정, 미사용 페이지, 보호받지 못하는 파일이나 디렉토리에 접근

 

시나리오

- 디렉토리 리스팅

  → 디렉토리 목록 접근 권한을 부여했을 때 발생

  → 민감한 파일이 공격자에게 노출되거나 다른 공격의 단서가 될 수 있음

- 에러 메시지로부터 정보 획득

- 디폴트 계정 사용

  → 사용 중인 제품의 사용자 설명서, 메뉴얼에 나오는 디폴트 계정을 그대로 사용할 때 쉽게 공격 당할 수 있음

 

요즘 패스워드 Brute Force 될리가 없다

8글자 이상의 대/소문자, 숫자, 특수문자 섞고, 연속된 문자열, 같은 문자 몇 번 반복...

패스워드는 충분히 복잡하여 Brute Force가 안됨

 

하지만 PIN code는 복잡하지 않다

이메일 인증, 비밀번호 초기화 등에 주로 사용되는 PIN Code는 6~8자리 숫자를 사용함

 

15. 안전하지 않은 역 직렬화

 

개요

- 직렬화: 언어 문맥에서 구조나 상태를 다른 컴퓨터 환경에 저장하고 나중에 다시 사용할 수 있는 포맷으로 변환하는 과정

- 직렬화 된 데이터를 역 직렬화 하는 과정에서 악의적이거나 변조된 객체를 삽입해 애플리케이션 로직을 수정하거나 임의의 코드를 실행 가능 

 

진단

- PHP 객체 직렬화 등 사람이 확인할 수 있는 데이터에 대하여 변조 시도

 

16. 알려진 취약점이 있는 구성요소 사용

 

개요

- 이미 알려진 취약점이 존재하는 버전의 운영체제, 서버, DBMS, 애플리케이션, API, 라이브러리를 사용하거나, 사용하던 버전이 취약해지는 경우, 공격자는 적은 노력으로 쉽게 취약점을 찾을 수 있음

- 정기적으로 취약점을 스캔하지 않거나, 사용 중인 컴포넌트와 관련된 보안 취약점 공지 서비스에 등록하지 않은 경우, 취약할 가능성 존재

 

시나리오

- Bash 쉘에서 환경변수를 악용해 발생하는 보안 취약점

- 취약점이 발표된 지 1시간 뒤 실제 악용 사례가 보고됨

- 1일 뒤 해당 취약점을 사용해 만든 봇넷을 기반으로 한 DDoS 공격 발생

- 2일 뒤 1,800개 도메인에서 17,400건의 공격이 보고됨

- 6일 뒤 CloudFare사에서 일 150만 건의 공격 탐지

 

17.불충분한 로깅&모니터링

 

개요

- 로그인, 로그인 실패, 높은 가치를 지닌 트랜잭션 등의 이벤트를 감시

- 의심스러운 활동에 대한 애플리케이션의 로그 감시

- 로그는 로컬 뿐만 아니라 다른 서버에 함께 저장하지 않으면 공격자가 권한을 획득 후 로그를 삭제할 수 있음

- 사용자나 공격자에게 로깅, 경고 이벤트가 보여질 시 정보 유출에 취약할 수 있음

- 일반적인 기업에서 보안 위협을 식별하는 데에 평균 191일이 소요됨

 

18. 임의 파일 접근 원격 파일 삽입

 

개요

- 파라미터를 통해 경로를 입력받아 사전에 의도한 파일이나 외부 모듈을 참조하는 웹 애플리케이션이 잘못된 경로 입력을 받아 권한이 허가되지 않은 파일의 내용을 노출시키거나 외부의 악성 스크립트를 실행하게 되는 취약점

- 애플리케이션이 파라미터를 통해 입력 받는 동적 경로 정보에 대한 유효성 검증을 실패했을 때 발생

 

진단

- 파일 이름 혹은 경로 정보를 파라미터로 사용하는 지점을 찾은 후 해당 정보들을 다양한 형태로 조작하여 서버의 반응을 분석

- 파일의 참조는 상대 경로와 절대 경로 모두 가능

- 파일 업로드 기능과 연계해서 악의적인 코드가 담긴 파일을 서버에 업로드 후 해당 파일을 참조하는 방식으로 임의 코드 실행 가능

 

19. 악성 파일 업로드 및 실행

 

개요

- 파일 첨부가 가능한 웹 애플리케이션의 기능을 이용하여 실행 가능한 파일을 업로드 한 후 원격에서 실행시키는 취약점

- 애플리케이션이 업로드 되는 파일(웹쉘)에 대한 확장자 검사를 실패하는 경우 발생

- 웹 서버 환경 별 업로드 가능 확장자

웹 서버 환경	실행 가능한 확장자
IIS	html, htm, asp, aspx, cgi, cer 등
PHP	html, htm, php, php5, cgi, cer 등
JAVA	html, htm, jsp, cer 등

 

진단

- 업로드 되는 파일이 허용 가능한 확장자를 가지는지, 공격에 사용되는 위험한 확장자를 가지는지 검사 여부

- "php", "asp", "jsp", "html"과 같은 공격에 사용될 수 있는 확장자를 가진 파일을 업로드하여 차단 하는지 여부

- ".htaccess", "php.ini"와 같은 설정 파일의 업로드를 차단하는지 여부

 

시나리오

- "aSP", "AsP", "pHp"와 같은 대소문자 조합을 사용한 파일을 업로드 시도

- "php5", "shtml", "asa", "cert"와 같은 서버가 실행할만한 확장자를 사용한 파일을 업로드 시도

- ".htaccess" 파일에 대한 업로드를 시도하여 확장자에 대한 인터프리팅 방식을 조작할 수 있는지 점검

- IIS6.0 일부 버전의 경우 ";"을 파일 이름의 끝으로 인식하는 경우가 있으므로 "file.asp;.jpg" 형태의 업로드 시도

- 파일 이름 끝에 "file.asp%00"와 같은 특수문자를 포함하여 업로드 시도

- "file.php.jpg", "file.jpg.php"와 같은 확장자를 두 개 연속으로 사용하여 업로드 시도

- 업로드 되는 경로를 알 수 없을 떄 에러 메시지를 유발해 경로 유

 

20. 서버사이드 템플릿 인젝션

 

개요

- 템플릿 엔진은 웹사이트 개발 과정에서 반복적인 작업을 효율적으로 수행하기 위해 만들어짐

- 사용자의 입력이 템플릿 문법의 일부분으로 해석되면 공격의 도구로 악용될 수 있음

- 템플릿 엔진마다 문법이 다른데 공격자는 웹사이트가 어느 템플릿을 사용하는지 알 수 없으므로 다양한 문법의 페이로드를 시도해야 함

 

시나리오

- Java FreeMarker 템플릿

- PHP Twig

- Flask Jinja

 

21. 서버측 요청 변조

 

SSRF?

Server Side Request Forgery의 줄임말

방화벽 우회, 인트라넷 접근 등 활용

이전부터 알려져 있었으나, BlackHat USA 2017에서 URL 파서를 공격하는 기법 발표 이후 핫해짐

 

내부망 보안은 보통 허술하다

- 내부망은 외부에서 접근이 안되어서 보통 보안이 허술함

- 외부 공개된 서비스가 내부망과도 연결되어 있을 경우 내부망 공격의 출발지가 될 수 있음

 

DNS Rebinding

- DNS는 유효시간을 의미하는 TTL 속성을 설정 가능

 

RFC는 특이케이스는 다루지 않는다

RFC에서 정의하지 않는 상황, 명확한 정의가 없어 언어마다, 함수마다 제각각으로 해석함