For Information Security

모의해킹01-대상 선정 및 취약점 탐색

Hackerrior — Mon, 27 May 2019 18:37:17 +0900

※모의해킹 진행은 직접 구현한 환경에서 진행했으며, 교육 이외의 목적으로 사용하실 경우 발생하는 책임은 본인에게 있습니다.

대상 선정

대상 : http://192.168.0.163/wordpress/

환경 분석

↑ nmap을 이용한 정보 수집

# Apache 정보와 운영체제 정보(Ubuntu) 확인

↑ kali linux의 whatweb을 이용한 정보 수집

# -v 옵셥 : 상세 출력

# Apache 정보, wordpress 버전 등 정보 확인 가능

기능 분석

웹 서비스에 존재하는 기능에 대해 수동 점검 진행

↑ 웹 서비스 기능 수동 확인

# 게시글에대한 좋아요 기능 확인

# 관리자의 게시글 확인 가능

# 게시글 작성, 댓글 작성 기능 미구현

해당 웹 서비스가 워드프레스 기반인 점을 이용하여 wpscan을 이용해 좀 더 상세한 정보 확인 시도

-wpscan은 wordpress 취약점 스캐너로 무료로 이용할 수 있다.

↑ kali linux의 wpsacn이용한 대상 웹 서비스 스캔

↑ 대상 웹 서비스가 운용중인 다양한 플러그인 정보를 확인할 수 있다.

# 해당 플러그인 버전 정보를 통해 취약점을 확인할 수 있다.

↑ 설치된 플러그인에 존재하는 취약점으로 발생할 수 있는 위협

SQL 인젝션

Hackerrior — Sat, 11 May 2019 17:45:04 +0900

SQL 인젝션

Injection이란?

애플리케이션에서 서버로 전달되는 명령, 쿼리, 스크립트등의 값을 변도하여 비정상적인 방법으로 시스템에 접근하는 공격기법이다.
웹 어플리케이션에만 국한되지 않고 데이터 베이스와 연결된 모든 어플리케이션에서 고려해볼 수 있는 공격 기법이다.

데이터 베이스와 연동된 웹 어플리케이션에서 SQL 질의문에 대한 필터링이 제대로 이루어지지 않을 경우 공격자가

입력이 가능한 폼( 웹 브라우저 주소 입력창 또는 로그인 폼 등)에 조작된 질의문을 삽입하여 웹 서버의 데이터 베이스

정보를 열람 또는 조작할 수 있는 취약점

injection의 특징

파라미터, 쿠리, 내부외부 웹 서비스 등 거의 모든 데이터가 인젝션 공격 대상이 된다.

파급효과

데이터 베이스 정보노출, 데이터 삽입, 삭제 및 변경, 데이터 베이스 서비스 중지, 사용자 인증 우회

공격 예상도

데이터 베이스(DB)와 연동된 응용 프로그램에서 입력된 데이터에 대한 유효선 검증을 하지 않을 경우, 공격자가 입력

데이터에 SQL 쿼리문을 삽입하여 DB로 부터 정보를 열람하거나 조작할 수 있는 보안 취약점을 말한다.

위 그림과 같이 공격자는 쿼리를 조작할 수 있는 문자열을 입력하여 조작된 요청을 보낸다. 서버가 입력값을 검증하지

않고 DB쿼리 실행에 사용하는 경우 인가 되지 않는 사용자가 DB 데이터를 무단으로 조회 또는 삭제할 수 있다.

SQL 인젝션 원인과 결과

임의의 SQL쿼리 입력에 대해 검증이 적절히 이루어지지 않아 발생
민감한 정보 유출등의 위험이 존재
웹 서비스 상 회원 정보 유출 사고의 상당수가 인젝션 공격에 의해 발생된다.

SQL 인젝션 취약점에 대한 대응방안

점검시 고려사항

SQL 인젝션 로그 유형

공격 패턴 삽입 과정 중에 Internal Server Error인 500번 종류의 에러 발생 ( 스크립트 에러 )
동일한 IP에서 동일한 페이지에 대한 반복된 접속 시도
업무와 관련이 없는 페이지 및 패턴이 존재

SQL 인젝션 공격 대응방안

사용자 입력 값 검증 / 비 정상적 입력값( ' , ", #, --, = 등 ) 필터링
데이터 길이 제한
적절한 오류 처리 /웹 서버 오류 페이지 구성
IDS/웹 방화벽 구축

설계시 고려사항

1. 어플리케이션에서 DB연결을 통해 데이터를 처리하는 경우 최소 권한이 설정된 계정을 사용해야 한다.

→ 취약한 어플리케이션으로 인해 침해 사고가 발생하더라도 나머지 부분에 대해 공격자가 액세스 권한을 가지지

않도록 어플리케이션에서 사용하는 DB연결 계정은 해당 어플리케이현이 사용하는 데이터에 대한 읽기,쓰기,삭제,

업데이트 권한만 설정한다.

2.외부입력값이 삽입되는 SQL 쿼리문을 동적으로 생성해서 실행하지 않도록 해야 한다.

→ 쿼리문의 구조가 외부입력값에 의해 변경되지 않는 API를 사용하도록 시큐어 코딩 규칙을 지정한다.

3.외부 입력값을 이용해 동적으로 SQL쿼리문을 생성해야 하는 경우, 입력값에 대한 검증을 수행한 뒤 사용한다.

→ 클라이언트와 서버 양층에서 입력값에 대해 안전한 값만 사용할 수 있도록 검증 작업을 수행한다.

3-1. 필터를 이용한 입력값 검증

→ 외부입력값에서 SQL 삽입이 가능한 문자열들을 필터링하여 안전한 값으로 치환하도록 하는 필터링을

생성하고 , DB에서 관리하는 데이터를 처리하는 모든 애플리케이션에 일괄 적용한다.

3-2. 인터셉트를 이용한 입력값 검증

→ MVC프레임워크를 사용하는 경우 인터셈터 컴포넌트를 사용하여 입력값에 대한 검증 작업을 수행 한 뒤

요청을 차단하거나 허용하는 정책을 어플리케이션에 일관 적용한다.

3-3. 라이브러리 또는 Validator컴포넌트를 이용한 입력값 검증

→ 입력값을 검증하는 Validator 컴포넌트를 공통 코드로 생성하고, 모든 개발자가 SQL문에 삽입되는

입력값에 대해 검증작업을 해당 컴포넌트에서 수행하도록 시큐어 코딩 규칙을 정의한다.

SQL 인젝션 취약점 실습

웹 어플리케이션의 일반적인 인증 절차

계정정보(ID/PW) 입력
SQL 쿼리(Query) 생성
DB로 쿼리(Query) 전송
DB에서 쿼리(Query) 실행
반환되는 return 값에 따라 인증 여부 판단

데이터 베이스 정보가 노출되는지 시도하는것을 목표로 두는것이 모의해킹의 목표이고, SQL injection 취약점

존재 유무를 파악하는것이 취약점 진단이라고 할 수 있다.

SQL injection은 크게 Error-based SQL injection, Blind injection 등으로 나눠생각해 볼 수 있다.

Error-based 취약점

공격자가 쿼리(Query) 를 이용해서 의도적으로 에러를 발생시키고 에러를 발생 시켰을 떄 웹 서버에는 디폴트

에러 페이지를 만들어서 사용자에게 반환해준다. 디폴트 에러 페이지는 소스코드 오류나 디버깅, 에러를

해결하기 위한 형태로 구성된 페이지이며 이러한 형태는 공격자에게 매우 큰 도움이되기 때문에 공격자는 에러

페이지를 유발 시켜 웹서버의 기본정보나, DB정보를 얻을 수 있다.

실습환경 MS-SQL

1). Database 이름 알아내기

1-1). MS-SQL의 Database 이름을 반환하는 함수를 이용한다. → DB_NAME()

1-2). SQL injection 취약점이 있는 로그인 페이지

→ 'and DB NAME() >1 --

↑ 문자열과 정수를 비교할 수 없기 때문에 오류가 발생 했다.

# 해당 오류를 통해서 oyesmall이라는 DB명을 알아낼 수 있다.

2). Table 및 Column 이름 알아내기

2-1). Having

→ Group by절을 이용하여 지정한 컬럼의 필드값을 집계(묶음)후 조건 비교할 떄 사용한다.

Group by user id 를 사용하면 user id 컬럼안에 값을 같은 필드값들을 묶어 준다. Having은 묶어진

필드값들을 한번 더 조건 검사를 수해한다.

Having을 group by뒤에 쓴다. having은 group by와 함께 쓰이기 때문에 having을 써서 오류를 만들어

낸다면 group by와 함께 쓰라는 오류를 표시하면서 컬럼값을 알아낼 수 있다.

having 1=1 --

↑ SELECT * FROM Members WHERE user_id = "having 1=1 --

# having 오류 특정상 모든 컬럼을 알려주지만 에러 페이지 특성으로 인해 첫번째 컬럼 값만 알려준다.

# Table : Members, Column : num

'group by(num) --

↑ 동일한 데이터를 묶어서 무엇을 할건지 나와있지 않기 때문에 에러가 발생했다.

# 해당 에러를 통해서 다음 컬럼값을 유추해 낼 수 있다.

3)Field값(Record) 값 알아내기

SELECT user_id FROM members WHERE num > 0 → members 테이블의 user_id 컬럼의 모든 필드값을 가져온다.

↑WHERE 조건의 in과 not in을 이용한 field값 조회

'or 1 in (select user_id from members where num > 0) --

=>oyes

'or 1 in (select user_id from members where num > 1) --

=>bisang2da

=>kisec

'or 1in(select user_id from members where user_id not in('oyes','bisang2da') ) --

=>kisec

'or 1in(select user_id from members where user_id not in('oyes','bisang2da','kisec') ) --

=> kisectest

고객사의 특성에따라 모의해킹 시나오도 달라진다. 현재는 위험성을 확인하는 수준의 모의해킹 시도라고

볼 수 있다 권한이 있는 사용자가 SQL문을 이용해서 특정 테이블의 컬럼값을 알아야 하는데

이때 테이블,필드값을 알아야한다. 때문에 공격자도 테이블과 컬럼값을 알아야 한다.

members table의 필드값을 획득할 수 있다면 다른 사용자의 권한으로 로그인할 수 있다. 이는 SQL injection의

가장 기본적인 목표이다. 이를 위해 Error-based, UNION등 다양한 유형의 injection을 시도해 볼 수 있다.

참고

- K-shield.jr 2기 정보보호 관리진단 과정

- KISA : 웹 취약점 분석 및 기술지원

- KISA : SW개발 보안 가이드

파일 업로드 취약점 (webshell upload)

Hackerrior — Wed, 8 May 2019 20:07:17 +0900

파일 업로드 취약점

파일업로드 기능을 이용하여 시스템 명령어를 실행할 수 있는 웹 프로그램(웹셀)을 업로드할 수 있는 취약점이다.

DBD(Drive-By-Download)공격을 이용해 (웹이 가지고있는 취약한 보안상태를 이용해 악성코드를 심어 놓는방법)

공격이 이루어지면 일반 클라이언트는 어떠한 액션을 취하지 않아도 취약한 사이트를 방문하는것 만으로도 감염시킬 수 있다.

파급 효과

시스템 장악, 웹 페이지 변조

공격 예상도

서버측에서 실행될 수 있는 스크립트 파일(asp,jsp,php파일 등)을 업로드가능하고, 이 파일을 공격자가 웹을 통해

직접 실행할 수 있는 경우 시스템 내부 명령어를 실행하거나 외부와 연결하여 시스템을 제어할 수 있다.

파일 업로드 취약점 원인 및 결과

→ 파일 업로드 취약점

- 파일 업로드 기능을 이용하여 시스템 명령어를 실행할 수 있는 웹 프로그램(웹셀)을 업로드할 수 있는 취약점

→ 파일업로드 취약점 원인과 결과

- 웹 사이트상에서 파일 업로드 시 파일의 확장자 검증을 하지 않아서 발생

- 서버의 모든 제어권, 정보탈취, 변조, 악성스크립트 삽입 등의 위험 존재

파일 업로드 취약점에 대한 대응방안

점검시 고려사항

검증된 웹셀 올리기
웹셀 취약점 점검 이후 후속 조치를 통해 업로드 했던 웹셀은 반드시 삭제 해야한다.
업로드 기능이 불필요할 경우 개발단계에서 완전 제거해야하며 소스코드단에서 편의를 위해 주석처리하는등의 처리는 지양한다.
파일 업로드 기능이 필요한 경우 서버측에서 파일명 검

4-1. 파일 이름은 전체 검사를 원칙으로 한다.

4-2. 확장자를 분리할 경우(.) 조건문자 마지막 확장자를 검사한다.

4-3. 시스템에서는 대소문자를 구분함으로 소문자 치환 후 검사를 진행한다.

※ 허용하는 확장자를 먼저 규정한 후 이외의 확장자는 모두 차단한다.

4-4. 업로드 가능한 파일명, 확장자인 경우 업로드 전용 폴더에 저장한다. 저장시 파일명, 확장자명 변경

=> 정상 파일 다운로드시 데이터베이스 연동을 통해 원본 파일명으로 바꿔준다.

4-5. 업로드 전용 폴더의 실행권한 제거 ( 주기적으로 체크 요망 )

설계시 고려사항

1. 업로드되어 저장되는 파일의 타입, 크기, 개수, 실행권한을 제한해야 한다.

1-1. 업로드 파일의 크기제한

1-2. 파일 타입의 제한

1-3. 업로드 되어 정되는 파일의 실행권한 제거

2. 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 한다.

2-1. 업로드되는 파일의 저장경로는 외부에서 직접 접근이 불가능한 경로 사용

2-2. 업로드되어 저장되는 파일의 파일명은 랜덤하게 생성하여 사용

↑ 파일 업로드 기능 구현시 위와같은 프레임워크의 사용을 고려하여 기능의 목적에 부합하는

형식의 파일만 업로드 하도록 허용한다.

파일 업로드 취약점 실습 : 웹페이지 소스코드 변조

1. 파일업로드 기능 탐색

2. 파일 업로드 기능을 이용해서 악성파일 업로드 시도

2-1. 웹 어플리케이션에서 실행 가능한 언어로 작성된 악성 스크립트 업로드 시도

=> 이는 웹 개발 언어가 JSP언어로 개발된 환경이라면 먼저 1차원적으로 JSP로 작성된 악성 스크립트의

업로드를 시도한다. → .jsp 해당 환경에 맞춰 같은 언어로 제작된 악성 스크립트 업로드 시도

2-2. 업로드된 파일 확장ㅈ가 개발 운영 환경에서 실행 가능한 확장자이어야 실행이 가능하다.

3. 우회기법

3-1. webshell.txt.asp

→조건 문자를 만나는것에서 처음 만나는 부분으로 기준을 잡는다면해당 파일이 업로드될 가능성이 있다.

#파일 이름은 전체검사를 원칙으로 한다.

3-2. 종단 문자 우회

A. urlencode 이용 : %00 = null code

→ %00가 포함된 뒷 문자열은 웹 서버에서 파일을 저장할 때 null 인식되는 것을 악용하는 방식

허용하는 확장자를 알고 있다면 해당 방식을 사용할 때 허용하는 확장자와 원하는 확장자 사이에

%00를 이용해 업로드를 시도한다.

↑ 현재 파일업로드 기능에대해서 파일의 확장자를 필터링하고 있다.

↑ 현재 게시판은 웹 서버측에서 확장자 필터링을 하는것이 아닌, 해당 웹 페이지단에서 확장자를 필터링하고 있다.

# 확장자 필터링은 항상 웹 서버측에서 진행되어야 한다. 이는 프록시를 이용한 소스코드 조작으로 악의적인

스크립트 파일을 업로드할 수 있기 때문이다.

↑프록시도구를 이용해 해당 웹페이지의 소스코드중 필터링 코드를 수정하였다.

↑웹셀 업로드 시도

↑ 웹셀이 성공적으로 업로드 되었다.

%00를 이용한 파일 업로드

↑업로드 가능한 파일 확장자명을 알 수 있다.

# 이를 이용한 우회기법으로 웹셀 업로드를 시도할 수 있다.

↑%00가 포함된 물자열은 웹 서버에서 파일을 저장할 때 null로 인식한다

# 웹 서버에 저장되는 파일은 webshell(seung_hoon).asp이다.

↑웹셀이 성공적으로 업로드 되었다.

↑업로드한 웹셀을 다운로드하고, 프록시 도구를 이용해 다운로드 경로를 찾는다.

↑다운로드 경로 확인하기

↑ 파일 다운로드 URL을 통해 다운로드 경로를 확이할 수 있다.

# 이를 이용해 웹셀에 접근한다.

↑찾아낸 다운로드 경로를 이용해 업로드한 웹셀에 접근한다.

↑접근한 웹셀을 이용해 시스템 명령어를 사용한 모습

참고

- K-shield.jr 2기 정보보호 관리진단 과정

- KISA : 웹 취약점 분석 및 기술지원

- KISA : SW개발 보안 가이드

크로스 사이트 리퀘스트 변조(CSRF)

Hackerrior — Wed, 8 May 2019 18:23:26 +0900

CSRF:Cross-Site Request Forgery

크로스 사이트 리퀘스트 변조는 사이트간 요청위조 불리기도 한다. 피해자의 권한으로 피해자 모르게 공격자가

의도한 요청을 수행 하도록 만드는것이다. 이는 그 피해자의 권한에 따라서 위험성이 달라진다는 특징이 있다.

- 피해자가 자신의 의도와는 무관하게 공격자가 의도한 행위를 웹사이트에 요청하도록 만드는 공격이다.

- 조작된 요청값을 이용해 웹 애플리케이션을 공격한다.

CSRF 공격 예상도

CSRF는 로그온된 피해자의 브라우저를 통해 , 세션쿠키 및 기타 다른 인증 정보가 포함된 변조된

HTTP 요청을 전송하여 정상적인 요청 처럼 보이게하는 기법이다.

CSRF 공격의 원인 및 결과

→ 크로스 사이트 리퀘스트 변조

- 피해자는 자신의 의지와는 무관하게 공격자가 의도한 행위를 웹 사이트에 요청하도록 만드는 공격

- 조작된 Request를 웹 어플리케이션에 전송하는 공격

- CSRF가 적용되려면 수정/삭제하는 액션에서 사용자를 구분하는 파라미터 값이 존재하지 않아야 한다.

→ 크로스 사이트 리퀘스트 변조 원인과 결과

- 사용자 입력 값에 대한 적절한 필터링 및 인증에 대한 유효성 검증이 미흡하기 때문에 발생한다.

- 서버 내의 파일 변경 및 서버 다운로드 등의 위험존재

CSRF 공격에대한 대응방안

이 방법은 모의 해킹 및 소스코드 분석을 통해 확인가능하다. 추측 불가한 토큰등을 포함한 링크

및 폼을 검사하고 HTTP 요청시 함께 입력하여 재인증 절차를 가지도록 하는것이 필요하다.

→ 설계시 고려사항

시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유요한 요청인지, 아닌지 여부를 판별할 수 있도록

해야한다.

A. CSRF 토큰 사용 : 웹은 URL 기반으로 요청을 처리하는 구조이다. 이는 해당 요청이 특정 사용자의 정상적인

요청인지를 구분하기 위한 정책이 적용되지 않는 경우, 스크립트나 자동화된 도구에 의해 보내지는 요청이 검증

절차 없이 처리될 수 있다.

그래서 해당 요청이 정상인지 사용자의 정산적인 절차에 의한 요청인지를 구분하기 위해 세션별로 CSRF토큰을

생성하여 세션에 저장하고, 사용자가 작업페이지를 요청할 떄마다 hidden값으로 클라이언트에게 토큰을 전달한

뒤, 해당 클라이언트의 데이터 처리 요청시 전달되는 CSRF 토큰값을 체크하여 요청의 유효성을 검사하게

설계 해야 한다.

↑사용자의 요청을 검증하여 CSRF를 방어할 수 있도록 위와같은 프레임워크나 라이브러리의 사용을 고려할 수 있다

B. 사용자와 상호 처리 기능 적용 : CSRF토큰 방식도 XSS취약점이 있는 사이트를 통해 공격하게되면 무력화

될 수 있으므로 CAPTCHA(사용자가 실제 사람인지 컴퓨터 프로그램인지를 구별하는 기술)와 같은 사용자와 상호

처리 가능한 기법을 적용하여 위조된 요청이 차단될 수 있도록 설계한다.

C. 재인증 요구 : 중요기능의 경우 재인증을 통해 안전하게 실제 요청여부를 확인하도록 설계 한다.

GET method를 이용한 CSRF 공격

- 실습환경 : 모의 쇼핑몰 사이트

↑ 웹 스캐닝 도구인 httpwatchpro 설치

↑ httpwatchpro를 이용해 상품을 장바구니에 담았을 시 파라미터 값을 스캔한다.

# 현재 POST method를 이용해 전달되는 보이지 않는 값을 해당 도구를 이용해 파라미터값 확인

httpwatchpro 결과

Parameter	Value
ea	1
g_code	200811415950
top	2

↑httpwatchpro를 이용해 얻은 파라미터값을 조작하여 GET method로 값을 넘겨 주었다.

↑ 파라미터값을 조작해 공격자가 원하는 만큼의 수량으로 수정

SCRIPT를 이용한 CSRF 공격

↑ 현재 비어있는 피해자의 장바구니 확인

↑ 공격자는 javascript의 iframe 태그를 이용해 보이지 않는 게시글을 남긴다.

# 이때 해당 게시들을 클릭할 시 iframe의 src 페이지가 동작한다.

↑ 해당 게시글을 클릭 시 아무런 변화가 없어 보인다.

↑ 해당 게시글의 iframe 태그의 영향으로 비어있던 장바구니가 공격자가 원하는 수량의 값으로 채워져있다.

악성 사이트 유도를 이용한 CSRF 공격

↑ 현재 비어있는 피해자의 장바구니 확인

↑공격자 PC의 웹 서버 가동

↑ 공격자의 웹서버 홈 디렉터리에 조작된 리퀘스트 요청

# 공격 요청 수량 87개

↑ 공격자 웹 서버로 유도하는 공격 코드

↑ 피해자는 공격코드가 담긴 게시글을 클릭하는 순간 공격자의 웹 서버로 연결된 공격코드 실행

↑ 공격자의 의도대로 공격 성공!

참고

- K-shield.jr 2기 정보보호 관리진단 과정

- KISA : 웹 취약점 분석 및 기술지원

- KISA : SW개발 보안 가이드

Linux에서 현재 실행중인 데몬 확인 (feat.Ubuntu)

Hackerrior — Sat, 4 May 2019 18:17:42 +0900

Ubuntu - 현재 실행중인 모든 데몬 확인하기

user@user:~$ service --status-all

↑현재 실행중인 모든 서비스 확인

현재 실행중인 데몬만 조회

user@user:~$ service --status-all | grep +

↑현재 실행중인 서비스만 확인

조회를 원하는 데몬만 확인

user@user:~$ service --status-all | grep ssh

↑ 내가 원하는 서비스 조회 가능

02.모의해킹 범위

Hackerrior — Mon, 29 Apr 2019 13:43:14 +0900

모의해킹 범위

모의해킹 범위는 크게 2가지로 생각해 볼 수 있다.

A.외부 모의해킹 : 물리적으로 외부에서 진행하며, 외부 IP를 사용한다.

B.내부 모의해킹 : 고객사 내부에서 진행하며, 내부에서 사용하는 IP를 사용한다.

외부에서 모의해킹을 수행할 때는 외부 수행IP를 고객사에게 전달해야하고 반드시 전달한 IP만을 사용해서 외부 모의해킹을

수행 해야 한다. 수행 IP대역을 벗어난 IP대역에서 업무를 수행해서는 안되며 DHCP 가 아닌 고정된 IP를 사용해야 한다.

내부 모의해킹은 내부에서 발생할 수 있는 사고에대해서 검사하는것으로 내부 IP를 사용해 수행 해야하며, 담당자가

지정해준 고정IP를 이용한다.

외부 비인가자	- 외부 IP 대역 - 공개된 서비스 위주로 진행 - 회원가입 없이 진행
외부 인가자	- 외부 IP대역 - 공개된 서비스 위주로 진행 - 회원가입 가능 - 상황에 따라 관리자 계정 부여 가능
내부 비인가자	- 내부 IP 대역 - 비공개 서비스 진행 - 임직원 권한 없이 진행
내부 인가자	- 내부 IP 대역 - 비공개 서비스 진행 - 임직원 권한을 가지고 진행

01.모의해킹 업무속 자동화도구

Hackerrior — Mon, 29 Apr 2019 13:33:31 +0900

1. 모의해킹 도구

모의해킹 도구는 모의해킹 업무를 수행할 때 필수불가결한 존재이다. 모의해킹 업무를 수행할 때 인력외의 범위를

할당 받았다면 자동화 도구를 이용해 업무의 효율을 늘릴 수 있다. 하지만 무차별적인 도구 사용은 좋지 않다.

특히 자동화된 도구를 이용해 공격 코드를 삽입해 취약점을 찾는 행위는 네트워크에 과부하를 줄 수 도 있는 행위기

때문에 여러면에서 지양해야 한다.

또한 점검자가 직접 짠게 아니기 때문에 그 도구의 코드들이 어떻게 구성되어 있는지 100%확인 할 수 없다.

고객 협의하에 진행할 때는 자동화 도구로 인한 영향을 고려해서 반드시 백업 요청을 하고 업무를 수행해야한다.

이 과정에서 이메일을 보내 협의내용 대한 부인방지를 해놓는것도 유용하다.

실제 현업에서는 도구를 설치하는것이 매우 제한적이다. 때문에 고객과 협의를 통해서 업무를 진행 해야하고

제한된 환경에서 실제 사용할 수 있는 유용한 스크립트 코드들을 직접 짜낼 수 있는 역량을 길러야 한다.

정보보호 시스템 취약점 진단과 모의해킹의 차이

Hackerrior — Tue, 9 Apr 2019 19:27:27 +0900

취약점 진단

1. 체크리스트 기준으로 항목별 취약점 점검

2. 위협이 있을 수 있는 취약점을 식별하고 위험의 가능성을 확인하는 수준

SQL injection → SQL injection에 영향을 받을 수 있는 취약점 구조 확인 → '(싱글쿼터) 를 이용한 에러 페이지 유발

모의해킹

1. 대상 시스템의 취약점 정보를 수집 ( 이 단계가 전제 되어야 한다. )

2. 취약점 정보를 바탕으로 위협 모델링 ( 시나리오 기반 )

3. 방법론을 구상하고 정보탈취, 정보 변경, 시스템 파괴 등을 목적으로 해당 목적이 달성 까지 진행

중요 시스템의 정보를 탈취,조작, 파괴 등이 가능한지를 알아내는 과정이 취약점 진단이라면,

모의해킹은 정보 탈취, 조작, 파괴 등이 실제로 일어날 수 있다는것을 확인하고 수행하는 과정이라고 생각하면 된다.

SQL injection → SQL injection에 영향을 받을 수 있는 취약점 구조 확인 → '(싱글쿼터) 를 이용한 에러 페이지 유발

→SQL 구분 작성 → DB 정보 유출, 조작, 삭제 등 수행

정리

특정 행위로 DB에러 페이지를 발견해 취약점 유무를 판단 했다면 취약점 진단까지 수행한것,

취약점 유무를 판단해 이를 이용해 DB정보 유출, 변조, 삭제 등을 수행 했다면 모의해킹을 수행 했다고 볼 수 있다.

실무 적응을 위한 정보시스템 진단

Hackerrior — Tue, 9 Apr 2019 19:11:20 +0900

실무 적응을 위한 정보시스템 진단

기술적인 지식들을 가지고 있어야 위협평가를 잘 할 수 있고 위협평가를 잘해야 대상 기업과 기관에

맞게 대응방안 및 가이드를 제시해 줄 수 있다.

정식 명칭은 정보 시스템 취약점 진단이라고 한다.

이는 주요 정보통신 기반시절로 지정된다면 정보 통신 보호법에 의해 해당하는 기관이나 기업은 지정된

첫 회의 6개월 이내에 취약점 진단을 받아야 한다.

정보 시스템 취약점 진단은 지정된 사업들이 자체 전담반을 편성해 수행할 수 있지만 대부분의 경우

컨설팅 업체에 요청해서 처리한다. 요청 프로세스는 다음과 같다.

제안서 - 프로필 - 투입 인력 - 투입 기간 - 방법론 - 제안서 발표 - 입찰 - 수행

정보 시스템 취약점 진단 시 명확히 알아야할 5가지 개념

1. 체크리스트

2. 위협

3. 취약성과 취약점의 차이

4. 위험성

위 개념들은 보고서에 포함되는 경우가 많은데 위 내용들이 명확하게 제시되어야 보고서의 질이 좋아진다.

취약점은 명확하게 들어난것을 말하고 위협과 결함될 수 있는 부분이다.

예를 들어 SQL injection은 위협, SQL injection이 발생할 수 있는 구조적인 문제를 취약점이라고 할 수 있다.

안티 바이러스가 설치 되어있지 않은 PC는 취약점이고 이러한 취약점의 위협이 될만한것이 악성코드가

되는것이다. 악성코드가 유입되었을때 주요정보가 탈취될 수 있다는것이 위험성이다.

기업과 기관이 보안을 하는데 있어서 제일 중요한 것이 위험성이다. 이는 돈을 투자하는 이유기도 하다.

이 위험성을 어떻게 관리하느냐가 보안의 핵심으로 볼 수 있다.

위험에 대해서 지켜야할 대상이 자산이고 자산이 가지고 있는문제점이 취약점이다. 어떠한 위협이 취약점을

이용해 자산을 노리는가를 위험성으로 볼 수 있다.

위험성 = 자산 x 취약점 x 위협

정보보호 진단은 취약점이 발생할 수 있다는것을 알려주는것 이에 차선책과 명확하게 가이드를 전수 해줘야 한다.

관련된 참고 자료는 KISA자료나 공공기관에서 제시된 검증된 자료를 참고하는것이 좋다.

정보보호 감사,점검,진단의 차이

Hackerrior — Tue, 9 Apr 2019 18:43:28 +0900

정보보호 감사,점검,진단의 차이점

정보보호 감사, 정보보호 점검, 정보보호 진단을 수행하는 방법은 같다. 감사는 징계나 특정 행위를 적발하기

위해서 하는것이고 정보보호 점검은 문제에 대한 체크를 하는것, 정보보호 진단은 문제를 찾아내서

대응책 까지 만들어 내는것까지 수행한다.

정보보호 컨설팅 업무는 정보보호 진단 업무가 주된 업무이다. 정보보호 점검을 수행하는 이는 기업의

보안 담장자가 일일 보안점검, 주간 보안 점검등 체크리스트에 따라 수행하는것으로 볼 수 있다.

감사 기록은 행위 기반의 기록 문제가 터졌을 때 누군가를 색출하기 위함이다. 이는 목적성에

따라서 의미와 단어가 달라진다.