[2020.9.26] DreamHack개념 정리 - Sever-side Basic

Server-side Basic (서버 사이드 취약점)

 개념: 서버에서 사용자가 요청한 데이터에 의해 발생하는 취약점

  목적: 서버를 이용한 서비스 공격

    ex) 서버 내에 존재하는 사용자들의 정보 탈취, 서버의 권한 장악 등등

 

 

Injection

사용자의 입력 데이터가 어플리케이션의 처리 과정에서 구조나 문법적인 데이터로

해석되어 발생하는 취약점을 의미

-> 변조된 입력을 주입해 의도한 행위를 변질시켜 의도하지 않은 행위를 발생시킴

 

 

1. SQL Injection

       : SQL 요청을 사용할 때 공격자의 입력 값이 정상적인 요청에 영향을 주는 취약점

 

                               -> 웹 애플리케이션 사용자 입력 값에 필터링이 제대로 적용돼 있지 않을 때 발생

                               -> 웹사이트 취약점을 찾아, DB를 관리하는 SQL 명령어에 악성코드를 삽입해

                                  해커가 원하는 방식으로 조작

 

    2. Command Injection

     : OS Command를 사용 시 사용자의 입력 데이터에 의해 실행되는 Command를 변조할 수 있는 취약점

         -> 웹 애플리케이션 시스템 명령을 사용할 때, ‘;’,’&’,’&&’ 등의 META문자를 사용하여 

              하나의 command를 주입하여 두개의 명령어가 실행되게 하는 공격

   

     3. Server Side Template injection (SSTI)

       : 템플릿 변환 도중 사용자의 입력 데이터가 템플릿으로 사용돼 발생하는 취약점

          -> html을 사용하여 동적 페이지를 만드는 것보다 템플릿을 이용하면 간단한 문법을 사용하여

               더 쉽고 짧은 코드로 사용 가능하며 미리 만들어 놓은 템플릿을 사용 가능하기 때문에 유지보수가 쉬움

                 -> RCE(Remote Code Execute)가 템플릿의 문자열이나 파일 위치에 들어가면공격자가 원하는 대로

공격 가능

    4. Path Traversal

       : URL/ Fire Path를 사용 시 사용자의 입력 데이터에 의해 임의의 경로로 접근하는 취약점

          -> 파일 경로를 조작하여 주어진 권한 외 파일에 접근할 수 있음

          -> 서버 파일을 다운로드 받을 수 있는 URL에 경로 표현 문자를 조합하여 서버에 요청

    5. Server Side Request Forgery (SSRF)

       : 공격자가 서버에서 변조된 요청을 보낼 수 있는 취약점

          -> 공격자가 서버 측 응용 프로그램이 공격자가 선택한 임의의 도메인에 HTTP 요청을 할 수 있도록 하는 취약점

          -> 웹 어플리케이션에서 요청을 보내기 때문에 웹 어플리케이션이 작동하고 있는 서버 내부의 포트,

               서버와 연결된 내부망에 요청을 보낼 수 있음

          -> server-side에서 변조된 요청/ 의도하지 않은 서버로 요청 가능

 

 

File Vulnerability

   1. 파일 업로드 취약점

      - 이해해야 할 개념: CGI(Common Gateway Interface)

 

➤ 사용자의 요청을 받은 서버가 동적인 페이지를 구성하기 위해 엔진에 요청을 보내고 엔진이 처리한 결과를 서버에게 반환하는 기능

 

• 서버의 파일 시스템에 사용자가 원하는 경로 또는 파일명 등으로 업로드 가능하게 하여 악영향을 미칠 수 있는 파일이 업로드 되는 취약점
• 파일 업로드 기능은 사용자의 파일이 서버의 파일 시스템에 저장되어 처리되므로 취약점 발생할 수 있음
• 사용자가 파일 업로드 시 내용과 함께 이름도 서버로 전송되는데, 이때 서버가 아무런 검증도 하지 않는다면 서버의 파일 시스템에 원하는 파일을 저장할 수 있게 됨
• 웹 서버가 파일을 실행하는 시기는 사용자의 요청이 들어오면 파일 시스템에서 해당 파일을 찾아 실행하는 것이기 때문에 웹 서버가 서비스하는 경로에 파일을 업로드할 수 있어야 함

 

 

Content-Disposition: form-data; name="file"; filename="../hack.py"

filename에 상위 디렉토리로 이동하는 ../ 문자를 삽입함

• 웹 어플리케이션이 실행하는 코드를 악의적인 사용자가 조작할 수 있다면 웹 어플리케이션 언어에 내장된 OS 명령어 등을 사용할 수 있음

       -> 웹쉘이라는 악성코드 등장

 

 

2. 파일 다운로드 취약점

 

• 파일 다운로드 기능에서 취약점이 발생하는 가장 흔한 형태는 사용자가 입력한 파일 이름을 검증하지 않고 그대로 다운로드 시켜주는 행위
• 파일 다운로드 취약점은 웹 어플리케이션의 소스코드, 관리자 패스워드, 서비스 키, 설정 파일 등을 유출 할 수 있어 이차적인 공격을 위한 발판이 될 수 있음
• Path Traversal을 이용하면 시스템 파일, 설정 파일 같은 중요한 정보를 다운로드할 수 있음

➤ ex

정상적인 파일 다운로드 요청: http://____?filename=docs.pdf

공격자의 파일 다운로드 요청: http://____?filename=../../../../etc/passwd

-> 시스템 계정 파일 다운로드 가능

 

 

3. 파일 다운로드 취약점 방어

• 인자에 다운로드 받으려는 파일의 경로나 이름을 넘기지 않는 것이 좋음. 반드시 이름을 넘기는 방식이어야 한다면 상대경로로 올라가는데 사용될 수 있는 .. / \\ 을 적절히 필터링 해야함.
• 데이터베이스에 다운로드 될 파일의 경로와 그에 해당하는 랜덤 키를 생성해 1대 1로 매칭해 저장해두고 해당 랜덤 값이 인자로 넘어왔을 때 데이터베이스에 존재하는 파일인지를 먼저 식별하고 다운로드 하는 것이 안전함

*다운받으려는 파일 경로에서 단순히 ../ 만을 필터링하려고 filename = filename.replace("../", "")처럼

 상위 경로로 올라가는 키워드를 없애면 안전할 것이라고 생각하지만

 공격자는 ..././file 같은 형식으로 요청해 ../가 삭제되어 다시 새로운 ../ 를 만드는 형식으로 우회 가능함.

*웹 서버가 동작하는 운영 체제가 윈도우일 경우 ../ 외에 ..\\로도 상위 경로에 접근 가능하므로 둘 다 필터링해야함

 

Business Logic Vulnerability

 

Business Logic: 규칙에 따라 데이터를 생성/표시/저장/변경하는 로직, 알고리즘

Business Logic Vulnerability(비즈니스 로직 취약점)

 : 정상적인 비즈니스 로직을 악용하는 것을 의미

   서비스의 기능에서 적용되어야 할 로직이 없거나 잘못 설계된 경우에 발생

    -> 어플리케이션의 검증 부재 또는 미흡의 이유로 발생

 

 

IDOR(Insecure Direct Object Reference)

 = 불안전 직접 객체 참조/안전하지 않은 직접 객체 참조

  : 공격자가 요청 메시지의 URL이나 파라미터를 변경하여 정상적으로 허용되지 않은 기능을 실행하거나

    다른 사용자의 리소스에 접근할 수 있는 공격

(안전하지 않은 객체 참조라는 의미와 같이 객체 참조 시 사용하는 객체 참조 키가 사용자에 의해 조작됐을 때

조작된 객체 참조 키를 통해 참조하고, 해당 객체 정보를 기반으로 로직이 수행되는 것)

->  웹 어플리케이션 사용자가 항상 웹을 통해 제공되는 메뉴대로만 웹 어플리케이션을 사용할 것이라 생각하고,

서버 쪽에서 입력값 검증을 소홀히 한다면 IDOR 취약해지는 경우가 많다.

 

[ 주된 원인 ]

 사용자의 입력 데이터에 의해 참조하는 객체가 변하는 기능에서 사용자가 참조하고자 하는

객체에 대한 권한 검증이 올바르지 않아 발생

 

다음은 각 사용자의 금액을 저장하는 데이터베이스이다. 

서버에서 검증하지 않을 경우 자신의 Account Number가 아닌 다른 사용자의 Account Number로 변경하여

다른 사용자의 금액도 조회할 수 있다. 자세한 내용은 다음과 같다.

 

자신의 Number를 1001으로 가정했을 때 위와 같이 Number를 1000으로 변경하여

다른 사용자의 userId와 금액을 알 수 있다. 

다른 사용자의 Number을 이용해서 자신의 Number 1001계좌로 금액을 전송할 수 있고

 Number 1000의 계좌에는 총 500 금액에서 전송한 금액 23을 제외하고 477 금액이 남은 것을 확인할 수 있다. 

 이와 같이 IDOR의 취약점은 비즈니스 로직에 따라 조회/삭제/수정/추가 등의 다양한 형태를

다른 사용자의 객체로 수행할 수 있다. 

 

 

IDOR 취약점 방어:

 

- 객체 참조 시 사용자의 권한을 검증, 즉, 사용자가 의도한 권한을 벗어나서 행동할 수 없도록 권한 등을 분리해서 관리

- 사용자가 요청 시 전달하는 세션을 통해 서버 내에서 처리하는 것이 안전

- 객체를 참조하기 위해 사용하는 객체 참조 키를 단순한 숫자가 아닌 무작위 문자 생성 등을 통해

악의적인 공격자가 객체에 참조하기 위한 객체 참조 키를 추측하기 어렵게 만드는 방법.

- 굳이 클라이언트로부터 전달받을 필요가 없는 정보는 웹 어플리케이션 내부에서 직접 설정하여

불필요한 파라미터 조작 가능성을 원천 차단

- 입력값 검증, 사용자 입력값이 원래 의도대로 전달된 정상적인 값인지 입력값 검증을 거쳐야 한다. 

 

 

Race Condition(레이스 컨디션)

: 공유 자원 처리 과정에서 해당 자원에 대한 동시 다발적인 접근으로 인해 발생하는 취약점

• 검증 과정에서의 데이터와 수정 과정의 데이터의 차이로 인해 웹 어플리케이션에서 의도하지 않은 흐름으로 진행하게 된다.
• 비즈니스 로직의 잘못된 순서로 인해 취약점 발생

 

레이스 컨디션 방지:

• 레이스 컨디션 취약점으로부터 안전하게 보호되어야 하는 로직들은 하나의 접근이 끝난 후 다음 접근을 처리하도록 쓰레드 락을 통해 동시 다발적인 접근을 방지
• 레이스 컨디션 취약점을 발생시키기 위해 다량의 접근이 필요하다는 점을 이용하여 특정한 행위에 요청을 할 시에 CSRF 토큰, 캡차 등을 통해 다량의 접근을 방지하는 방법을 통해 웹 어플리케이션을 보호

     CSRF 토큰: 랜덤 한 수를 사용자의 세션에 저장하여 사용자의 모든 요청(Request)에 대하여 서버단에서 검증하는 방법

Language specific Vulnerability

  : 컴퓨터언어에서 발생할 수 있는 취약점(php, 파이썬, 자바스크립트 등)

- file system: 파일 시스템에서 사용하는 변수들이 변조될 가능성이 있을 때, 파일시스템 공격 가능성이 생김.

 

1. file read: 어플 코드나 정보 노출

2. file write: 기존의 설정파일을 덮는 공격

3. 파일 삭제

4. 어플리케이션 서비스 무력화

 

 

- 직렬화와 역직렬화

직렬화(serialize): object나 data의 현재 상태를 특정한 형태의 데이터로 변환하는 것

역직렬화(deserialize): 직렬화된 데이터를 원래의 상태로 변환하는 것

- PHP

   1. include함수: 동적으로 다른 php페이지를 로드할 때 주로 사용

      - 파일의 내용에 php태그가 포함될 경우 바로 php코드 실행 -> 이점을 이용해 공격 가능

   

   2. wrapper: URL style 프로토콜을 위해 존재

       - wrapper를 사용해 사용자의 의도와 다른 행위를 함으로서 공격 가능

   3. extract함수: 배열에서 변수를 가져오는 함수

       - 기존에 사용되고 있는변수의 데이터를 덮고 변조함으로서 공격 가능

   

   4. type-juggling(타입 저글링): 자동형변환이 일어나 의도치 않은 결과가 일어날 수 있음  

       - 보통 서로 다른 타입이 비교연산자에서 사용될 경우 발생

  

   5. session관리

    5-1) session_start() : http에서 쿠키를 가져와 아이디값을 가져옴

    5-2) $_SESSION 변수에 접근해 값 변경

    5-3) 페이지가 종료될 때 자동으로 세션변수 직렬화

      -> 이렇게 사용자의 입력데이터를 가져와 다른 공격과 연계하여 사용

    ex) include함수 인자 조작

 

   6. upload 로직 

      - 코드

<?php $uploadDIR = './uploads/'; $error = $_FILES['file']['error']; $name = $_FILES['file']['name']; if( $error != UPLOAD_ERR_OK ) { // error occurs } if( move_uploaded_file( $_FILES['file']['tmp_name'], "$uploadDIR/$name") ){ // upload success }else{ // upload fail }

 

     6-1) move_uploaded_file : php에서 파일을 업로드 할 때 임시 디렉토리 생성

     6-2) 임시 파일로 생성

         - 이때 임시파일명 생성 규칙:  php[a-zA-Z0-9]{6}

     6-3) 정상적인 로직 처리 후 임시파일 삭제

         - 문제점1: 사용자가 임시 디렉토리에 임의대로 업로드 가능

         - 문제점2: 임시파일 생성규칙이 예측 가능해 무작위로 공격 가능

자바스크립트

: 프로토타입을 사용하는 언어

 

> 프로토타입을 지정해주지 않을 시 동일한 프로토타입을 상속받음

: valueOf, toString : 두 변수의 값을 비교

 

> 이때 임의의 값을 반환하는 함수로 수정 시:

첫번째 요소가 secretValue인 배열을 넣어주면 그 요소를 찾지 못해 익셉션 발생

 

 

 

Misconfiguration

:  잘못된 설정(misconfiguration) 취약점은 모든 웹 어플리케이션 계층에서 발생

   -> 잘못된 설정으로 인해 공격자는 허가되지 않은 동작을 수행할 수 있음 (간단한 설정 오류)

  1. 부주의로 인해 발생하는 문제점

      -> 권한 설정 문제 : 

              + 잘못된 권한 설정

              + 기본 계정

      -> 기본 서비스

      -> 임시/백업 파일, 개발 관련 파일

 

  2. 편의성을 위한 설정에 의해 발생하는 문제점 

      -> 개발자를 위한 설정이 서비스 환경에서도 커져있어 공격자가 이를 통해 시스템 내부의 정보를 알아내 추가적인 공격에 사용될 수 있음

     - DEBUG / Error Message Disclosur

     - 0.0.0.0으로 바인딩된 네트워크 설정

 

3. 메뉴얼과 실제 구현체이 차이로 인해 발생한는 문제점

        -> 메뉴얼에 설명되어있는 대로 사용했지만 중의적 표현이 존재하거나 잘못 설명되어있을 때 발생

       - NGINX ALIAS Path Traversal  취약점

   

4. 해당 코드나 설정에 대한 이해 없이 사용해 발생하는 문제점

        -> 취약점이 존재하는 예제 코드, StackOverflow 답변등을 이해 없이 복사 붙여넣기 해 사용하거나

            메뉴얼에 존재하는 권고 설정을 무시한 채 사용해 발생

https://stackoverflow.com/questions/47404893/reverse-image-proxy-without-specifying-host

Reverse image proxy without specifying host

- 모든 도메인을 허용한 CORS 설정