'전체 글'에 해당되는 글 209건

1. 취약점 소개

사용자가 안드로이드 모바일을 이용할 시 입력했던 인증 정보(로그인, 비밀번호 등), 중요 정보(송금 여부, 액수 등), 민감한 정보들이 백업 파일에 저장된다. 만약 제3자가 획득한 단말기에서 백업 취약점이 발견하면 인증정보, 중요정보, 민감한 정보 등을 획득해 2차 피해가 우려될 수 있는 취약점이다.

기본적으로 전체 백업은 해당 애플리케이션의 Android Manifest.xml에 포함된 allowBackup 속성을 따른다. 값이 아예 설정 되어 있지 않거나 false로 설정될 경우 추출하려는 패키지의 데이터가 추출되지 않게 된다. 안드로이드 시스템 기본값은 백업값이 설정되어 있지 않으면 백업을 사용하지 않는 것으로 설정된다. 인시큐어뱅크 앱은 allowBackup이 설정되어 있고 전체 백업 수행이 가능하다.

2. 취약점 진단

[그림 2‑1] 인시큐어뱅크 Transfer

인시큐어뱅크에 로그인하고 Transfer을 실행한다. 실행이 되면 계좌번호와 보낼 금액을 입력한다. 현재는 가상에서 진행하기 때문에 랜덤한 숫자를 입력해도 된다. 만약 앱을 실행하지 않으면 백업 취약점에 대한 진단을 할 수 없기 때문에 반드시 실행 후 계좌번호, 보낼 금액을 입력해 실행해야 한다.

[그림 2‑2] Transfer 결과

계좌번호와 보낸 금액에 대한 실행 결과다. ViewStatement 탭을 실행하면 그림 2‑2와 같이 보낸 결과 값을 확인할 수 있다.

[그림 2‑3] adb backup 명령어

cmd 창을 열고 adb backup 명령어를 실행해 인시큐어뱅크 앱에서 실행한 정보를 백업한다.

[표 2‑1] adb backup 명령어 옵션

[그림 2‑4] adb backup 실행 결과

adb back 명령어를 실행하면 녹스플레이어 가상 환경에서 [그림 2‑4]와 같은 화면이 나온다. 비밀번호란은 비워놓고 전체 백업을 진행하면 암호화된 백업 파일이 로컬에 insecurebank.ad 파일명으로 저장된다.

[그림 2‑5] ad 파일 생성

전체 백업을 진행하고 로컬 컴퓨터에서 생성된 파일을 확인해보면 그림 2‑5와 같이 insecure.ad란 이름으로 AD 파일이 생성되었음을 볼 수 있다.

[그림 2‑6] 백업 추출 라이브러리

Insecurebank.ad 파일을 바로 열게 되면 글자가 전부 깨져서 어떤 내용인지 확인이 불가능하다. 파일 내용 복호화를 위해 백업 추출 라이브러리인 abe-all.jar을 활용해 insecurebank.ad 파일 내용을 복호화해서 알집 파일로 만든다.

[그림 2‑7] tar 파일

백업 추출이 성공적으로 완료되면 insecurebank.tar이라는 압축 파일이 생성된다. 이 압축 파일을 해제해서 추출된 정보들을 확인한다.

[그림 2‑8] 압축 해제 파일

압축을 해제해 추출된 정보들을 확인한다. apps 폴더에서 mySharedPreferences.xml 파일을 연다. mySharedPreferences.xml 파일은 인시큐어뱅크 앱에서 실행한 정보를 저장해놓은 파일이다.

[그림 2‑9] 계정 정보

mySharedPreferences.xml 파일을 열면 인시큐어뱅크 앱에 로그인하기 위해 입력한 아이디, 비밀번호 값이 Base64 방식으로 인코딩 되어 있다는 걸 볼 수 있다. 복잡한 암호화 알고리즘 방식을 적용하지 않아 간단한 인코딩 방식만 적용하면 쉽게 디코딩 되어 아이디, 비밀번호가 어떤 건지 평문으로 번역해 계정 정보를 획득할 수 있다.

3. 대응 방안

안드로이드 백업 취약점은 AndroidManifest.xml에 android:allowBackup 속성이 true로 설정되어 있기 때문에 발생하는 취약점이다. 민감한 정보, 중요한 정보 등이 노출되지 않도록 하기 위해서는 android:allowBackup 속성을 False로 설정해 변환된 백업 데이터에 대한 내용이 노출 되지 않도록 한다.

[그림 3‑1] AndroidManifest.xml

인시큐어뱅크 앱 소스 코드를 열어 AndroidManifest.xml 파일에 구현되어 있는 android:allowBackup 속성을 false로 변경한 후 앱을 다시 빌드한다.

[그림 3‑2] adb backup 명령어

앱이 녹스플레이어에 완전히 다시 빌드된 후 adb backup 명령어를 실행해 인시큐어뱅크 앱에서 실행한 정보를 백업한다. 실행된 정보를 백업하기 전에 인시큐어뱅크 앱에 다시 로그인 한 후 계좌정보 등을 다시 보내야 원활한 실습이 가능하다.

[그림 3‑3] 전체 백업

adb back 명령어가 정상적으로 실행되면 녹스 플레이어에 전체 백업 여부를 묻게 되는데 데이터백업을 실행해 전체 백업을 진행한다.

[그림 3‑4] 파일 생성

데이터 백업이 성공적으로 완료되면 insecurebank.ad 파일이 생성된다. Insecurebank.ad 파일이 생성된 후 백업 추출 라이브러리인 abe-all.jar을 활용해 insecurebank.ad 파일을 알집 파일로 만든다.

[그림 3‑5] 알집 파일 실행 결과

인시큐어뱅크 앱의 민감한 정보들을 탈취하기 위해 insecurebank.tar 파일의 압축을 풀려고 시도했지만 압축 파일이 아니라는 메시지가 출력되면서 압축이 풀리지 않는다. 이처럼 백업에 관련된 소스 코드를 변경하면 앱의 민감정보, 중요정보 등의 탈취를 막을 수 있다.

1. SQL 인젝션 공격 대응 방안

SQL 인젝션 공격과 같은 모든 파라미터 입력값 조작으로 이뤄지는 공격은 입력값 검증을 통해 대응이 가능하다. 대표적인 방어 방법은 화이트리스트 검증이다.

 $query = "Select first_name, last_name FROM users WHERE user_id='$id';";

위와 같은 쿼리 방식은 $id 방식이 입력값을 조작할 수 있을 가능성이 높기 때문에 매우 취약한 SQL 쿼리다.

[그림 1-1] SQL 방어 쿼리 - 1

SQL 인젝션 대응 방안이 되는 모범 코드다. 맨 윗쪽에는 CSRF 공격 방어까지 구현되어 있어 CSRF 공격도 하기 힘든 구조다. SQL 인젝션 공격을 방어하기 위해 사용하는 방법은 파라미터 쿼리로 변경하는 것이다. Check the database 주석을 보면 prepare, bindParam, execute를 호출해 쿼리문을 실행한다. Prepare 함수에선 미리 실행할 쿼리문의 형태를 작성하고 사용자 입력값이 들어가는 $id 부분은 bindParam 함수에서 실행할 수 있도록 하는 형태를 띠고 있다. 즉, 데이터베이스는 어떤 것이 코드고 어떤 것이 쿼리인지 구분을 할 수 있게 되기 때문에 공격자가 입력값을 조작하려고 해도 쿼리문에서 일부가 될 수가 없고 데이터로 처리되기 때문에 SQL 인젝션 공격을 효과적으로 방어 할 수 있다.

[그림 1-2] SQL 방어 쿼리 - 2

SQL 인젝션 High 단계의 소스 코드다. [그림 1-1] 소스 코드와 비교해 봤을 때 따로 처리하는 함수가 없고 온전히 쿼리 안에서만 처리하려고 하기 때문에 공격자가 입력값을 조작하는게 가능하다. LIMIT 1이라는 레코드 값 제한을 걸어도 #이나 --와 같은 주석으로 우회가 가능하기 때문에 안전한 소스 코드라곤 볼 수 없다.

1. SQL 인젝션 공격 High 단계 실습

[그림 1-1] SQL 인젝션 공격

DVWA 레벨을 high로 설정한 후 SQL Injection 탭을 클릭하면 기존과는 다르게 영어로 된 링크가 있다. 이 링크를 클릭한다.

[그림 1-2] 소스코드

SQL 인젝션 공격에 앞서 소스코드를 확인하면 '$id' 뒤에 LIMIT라는 쿼리가 추가 되어 있는데 이 쿼리는 레코드의 개수를 제한한다. 현재 쿼리는 1로 제한 되어 있지만 이 부분을 우회하기 위해 주석처리를 한다면 우회가 가능하다.

[그림 1-3] SQL 인젝션 공격

앞에 값이 참이든 거짓이든 뒷 부분을 참으로 만들어 쿼리가 동작하는 구문을 삽입한다. 1' or '1'='1'#을 입력한 후 전송한다. #은 주석으로 소스코드에서 본 Limit 1을 우회하기 위해 사용된다.

[그림 1-4] 공격 성공

1' or '1'='1'#을 입력한 후 전송된 결과 SQL 인젝션 공격이 성공했음을 확인할 수 있다. Limit 1이 우회되면서 전체 데이터베이스의 정보를 출력된다.

[그림 1-5]  테이블 정보

테이블 정보를 확인하기 위해 union SQL 공격 구문을 삽입한다. 1' union select user, password from users#을 삽입하고 전송한다. Users 테이블에서 user, password의 컬럼을 숫자 1과 조합해 참을 만들어 추출한다는 쿼리다.

[그림 1-6]  테이블 내용

1' union select user, password from users# 쿼리 전송 결과 아이디, 패스워드로 보이는 정보들이 노출되었음을 확인할 수 있다. 패스워드는 암호화 되어 있지만 MD5 형식이고 구글에서 쉽게 평문으로 변환이 가능하다.

1. Blind SQL 인젝션 공격 개요

Blind SQL 인젝션 공격은 임의의 SQL 구문을 삽입해 인가되지 않은 데이터를 열람할 수 있는 공격 기법이라는 것은 다른 SQL 인젝션 공격 기법과는 크게 다르진 않다. 차이점이 있다면 일반 SQL 인젝션 공격은 임의의 SQL 조작된 쿼리를 입력해 한번에 정보를 보여 줄 수 있지만 Blind SQL 인젝션 공격은 쿼리의 결과에 따른 서버의 참과 거짓의 반응을 통해 데이터베이스의 정보를 알아 낼 수 있다. 일반 SQL 인젝션 공격에 비해 시간이 상당히 오래 걸린다는게 단점이지만 시간을 투자하면 언제든지 데이터베이스 정보를 탈취할 수 있기 때문에 위험한 SQL 인젝션 공격 기법 중 하나라고 판단할 수 있다.

(1) Blind SQL 인젝션 공격 실습

[그림 1-1] User ID 입력

Blind SQL Injection 탭을 선택하고 User ID 값에 1을 요청한다. 1을 전송하면 User ID가 존재한다고 표시된다.

[그림 1-2] User ID 입력

이번엔 User ID 값에 6을 요청한다. 6을 전송하면 User ID가 존재하지 않는다고 표시된다. 이러한 응답값을 통해 데이터베이스는 총 5개가 된다는 것을 추측할 수 있다.

[그림 1-3] 정상값 처리

AND 뒤에 1=1#이라는 항상 참이 되는 조건을 추가해 삽입하고 실행한다. 1'이라는 값이 참이기 때문에 뒤에 1=1# 이라는 참이 되는 조건을 추가하면 데이터베이스는 존재한다는 것을 알 수 있다. 만약 SQL 인젝션 쿼리문이 실행되지 않는다면 ID가 1이 아니라 1' AND 1=1#의 전체 문자열을 하나의 ID로 처리하고 비정상적인 값은 실행하지 않아 User ID가 없다는 메시지가 나와야 한다.

[그림 1-4] 비정상값 처리

AND 뒤에 1=2#이라는 거짓이 되는 조건을 추가해 삽입하고 실행한다. User ID는 존재하지 않는다고 출력된다. AND 뒤에 1=2가 거짓이 되기 때문에 앞에 붙은 조건과 관계 없이 거짓이 된다. 즉, AND 이후 조건에 따라 결과가 바뀐다는 거고 입력하는 값이 SQL 쿼리문을 통해 처리되고 있다고 추측할 수 있다.

[그림 1-5] 소스 코드

소스 코드를 보면 빨간색 박스 안에 SQL 쿼리문을 구성하고 있다. User_id='1' AND 1=1과 같이 전제가 참인 조건문이 되서 사용자가 존재한다고 출력된거고 AND 1=2를 입력하면 where 구문이 전부 거짓이 되서 사용자가 없다고 출력한 것이다. 이와 같이 참, 거짓이 구분 되서 출력되는 것은 SQL 쿼리문이 뒤에서 사용되고 있는 것을 추측해 볼 수 있다.

(2) Time based SQL 인젝션 공격 실습

[그림 2-1] sleep 함수

User ID에 1' AND sleep(5)#을 입력한 후 요청한다. 개발자 도구를 활용해 응답시간을 확인하면 약 5초 동안 응답값이 지연 되는 현상을 볼 수 있다.

[그림 2-2] sleep 함수

이번에는 User ID에 6' AND sleep(5)#을 입력한 후 요청한다. 개발자 도구를 활용해 응답시간을 확인하면 응답값이 지연 되지 않고 응답 되는 현상을 볼 수 있다. 앞에 6'이 거짓이기 때문에 응답값이 지연 되지 않고 응답 되는 것이다. 즉, 6이라는 데이터베이스는 존재하지 않는 것이다. 조건이 참일 때만 응답값이 지연되고 거짓일 땐 응답값이 지연되지 않는 참, 거짓을 통해 구분할 수 있게 된다.

1. WHERE 구문

[그림 1-1] WHERE SQL 인젝션 공격 과정

[사진 출저: 화이트해커가 되기 위한 8가지 웹 해킹 기술]

정상적인 경로라면 사용자가 ID값 1을 요청하기 위해 ID값 1을 출력하는 SQL 쿼리 구문을 웹 애플리케이션에 요청하면 웹 애플리케이션은 SQL 구문을 DB에 전달한다. DB는 필요한 정보를 추출해 ID값 1인 사용자 정보를 웹 애플리케이션에 전달하고 웹 애플리케이션은 사용자에게 전달해주게 된다.

이에 반해 악의적인 의도를 가진 공격자는 SQL 쿼리문을 조작해 요청값 이외의 정보도 탈취한다. 공격자는 ID값 1 이외에도 다른 정보도 탈취하기 위해 or '1'='1이라는 쿼리를 추가해 웹 애플리케이션에 요청하고 웹 애플리케이션은 DB에 SQL 구문을 전달한다. DB에서 특별한 검증을 하지 않으면 요청 이외의 값들도 웹 어플리케이션에 전달되고 웹 어플리케이션에서 공격자에게 정보를 전달하게 된다.

(1) Where 구문 DB 정보 탈취 실습

[그림 1-2] 요청 ID 값

DVWA SQL Injection 항목을 실행하면 UserID 폼에 1을 입력해 전송하면 DB에 있는 정보들이 그대로 출력된다.

[그림 1-3] 소스코드

소스코드를 확인하면 별다른 검증값이 없고 '$id'라는 SQL 구문이 일치하면 DB가 동작한다. ''이라는 세미콜론 안에 SQL 구문이 정상적으로 일치하면 SQL 인젝션 공격이 가능하다는 의미다.

[그림 1-4] SQL 공격 구문

[그림 1-3]에서 확인했던 ''값의 조건을 맞춰 SQL 공격 구문을 삽입한다. 1' or '1'=1을 삽입하면 ''값 조건에도 맞게 되고 OR 연산자를 사용하게 되서 OR 앞, 뒤 중 한 부분만 맞게 되도 참으로 반환되기 때문에 SQL 인젝션 공격이 성사된다. 해당 구문의 SQL 인젝션 공격이 성공하면 모든 DB 정보를 탈취할 수 있다.

2. Union 구문

[그림 1-1] UNION SQL 인젝션 공격 과정

[사진 출저: 화이트해커가 되기 위한 8가지 웹 해킹 기술]

정상적인 경로라면 사용자가 ID값 1을 요청하기 위해 ID값 1을 출력하는 SQL 쿼리 구문을 웹 애플리케이션에 요청하면 웹 애플리케이션은 SQL 구문을 DB에 전달한다. DB는 필요한 정보를 추출해 ID값 1인 사용자 정보를 웹 애플리케이션에 전달하고 웹 애플리케이션은 사용자에게 전달해주게 된다.

이에 반해 악의적인 의도를 가진 공격자는 SQL 쿼리문을 조작해 요청값 이외의 정보도 탈취한다. 공격자는 ID값 1 이외에도 다른 DB 정보도 탈취하기 위해 1' union select name,pw from users#이라는 SQL 쿼리를 웹 애플리케이션에 전달한다. union 구문은 두개 이상의 select 구문을 합치는데 사용하게 된다. 여기서도 요청 값 이외에 union 구문을 삽입해 참을 만들어 추가 DB 정보를 탈취한다. DB에 SQL 공격 쿼리 구문이 전달되고 별다른 검증값을 거치지 않는다면 DB에 존재하는 모든 사용자의 이름, 비밀번호가 공격자에게 그대로 전달된다.

(1) Union 구문 칼럼 개수 추측 실습

[그림 1-2] Union SQL 공격 구문

Union SQL 공격 구문을 삽입해 실행하면 [그림 2-2]와 같이 DB 정보가 그대로 노출됨을 확인할 수 있다. #은 Mysql의 라인을 처리하는 주석으로 만약 ID, password 창이 있다면 ID에 #이 적용되면 password 창은 모두 주석 처리 되서 참인 결과를 반환한다.

[그림 1-3]  SQL 공격 구문

칼럼의 개수를 확인하기 위해 select에 1,1,1을 삽입해 실행한다.

[그림 1-4] 에러 메시지

Union select 구문 실행 결과 에러 메시지가 출력된다. 이는 컬럼의 개수가 3개는 아니라는 의미다. 따라서 공격자는 컬럼의 개수는 2개 임을 추측할 수 있다.

[그림 1-5] order by SQL 공격 구문

order by 구문은 SQL에서 지정된 컬럼순으로 오름차순, 내림차순으로 정렬을 해주는 역할을 한다. [그림 2-5]에서 컬럼의 개수를 알아보기 위해 order by SQL 공격 구문을 삽입하면 DB 정보가 그대로 노출 됨을 확인할 수 있다.

[그림 1-5] order by SQL 공격 구문

order by 뒤에 2를 붙여 컬럼 2개를 묶어 실행한 결과 DB 정보가 그대로 노출 됨을 알 수 있다.

[그림 1-6] order by SQL 공격 구문

order by 뒤에 3을 붙여 컬럼 3개를 묶어 실행한다.

[그림 1-7] 에러 페이지

order by SQL 공격 구문 실행 결과 에러 페이지가 출력 됨을 확인할 수 있다. 에러 페이지가 출력 됨으로써 컬럼의 개수는 2개임을 추측할 수 있다.

(2) Union 구문 계정 탈취

[그림 2-1] 데이터베이스 명

데이터베이스 명을 알아보기 위해 1' union select schema_name,1 from information_schema.schemata #을 입력해 데이터베이스 명을 확인한다. 입력한 SQL 공격 구문은 schemata 테이블의 information_schema 컬럼에서 schema_name, 1의 정보를 가져와 앞의 1'와 합쳐서 DB 정보를 출력한다는 의미다. Union SQL 공격 구문을 입력하면 데이터베이스 명을 알 수 있다.

[그림 2-2] dvwa 데이터베이스의 테이블 명

dvwa 데이터베이스의 테이블 명을 알아보기 위해 1' union select table_schema, table_name from information_schema.tables where table_schema = 'dvwa' #를 입력해 테이블 명을 확인한다. table_schema의 dvwa 데이터베이스에서 tables 테이블의information_schema 컬럼에서 table_schema, table_name의 정보를 가져와 앞의 1'와 합쳐서 DB 정보를 출력한다는 의미다. Union SQL 공격 구문을 입력하면 테이블 명을 알 수 있다.

[그림 2-3] users 테이블 칼럼

Users 테이블의 칼럼 정보를 알아보기 위해 1' union select table_name, column_name from information_schema.columns where table_schema = 'dvwa' and table_name = 'users'# 을 입력해 테이블 칼럼을 확인한다. 기존과 형식은 비슷하지만 where 조건 뒤에 and table_name = 'users'#가 추가되서 조회된다. DB 정보를 가져오면 users의 테이블의 칼럼을 확인할 수 있다.

[그림 2-4] users 테이블 정보

users 테이블 정보를 알아보기 위해 1' union select user, password from users#을 입력해 실행한다. 실행 결과 사용자 계정으로 추측되는 정보들이 있음을 확인할 수 있다. 아이디는 평문이지만 패스워드는 MD5 형식의 해쉬값으로 저장되어 있다. 하지만 MD5 형식의 해쉬값도 구글에 검색하면 바로 해독이 가능하다.

[그림 2-5] 해쉬값 해독

구글에 검색해 해쉬값 해독 결과 아이디가 admin으로 저장되어 있는 정보는 패스워드가 password 라는 것을 확인 할 수 있다.

요즘 케이쉴드주니어 모집 설명회 및 4기 모집이 한창입니다. 현재 저는 케이쉴드주니어 기술팀 팀장을 맡고 있습니다. 케이쉴드주니어 설명회 및 지인들에게 받았던 질문들에 대한 답변을 써봅니다.

1. 선발 기준, 우대요건이 있는지 궁금합니다.
-> 과정별로 다르지만 보안 동아리 경험, 관련학과, 자격증(정보처리기사, 정보보안기사), 관련 프로젝트 경험 등이 선발 우대 요건으로 들어갑니다.

2. BOB 수료생은 지원 가능한가요?
-> 지원 가능하며 BOB, 케이쉴드주니어 2개 동시 지원은 불가합니다.

3. 3학년은 지원이 가능한가요?
-> 시간이 허락된다면 지원이 가능하지만 당장 취업할 수 있는 인원을 좀 더 우선시 고려해서 선발합니다. 하지만 절대적인 것은 아니며 1기에서도 재학중인 3학년 학생들도 있었습니다.


4. 면접 때 어떤걸 질문하나요?
-> 이 질문은 기밀 사항이라 자세히 알려드리긴 어렵지만 기초 보안 지식부터 전산에 관련된 지식까지 질문 범위는 매우 다양합니다. 질문 난이도도 초급~고급까지 다양하며 학부때 해봤던 프로젝트, 개인 프로젝트 등에 대해서도 질문을 받을 수 있습니다.

5. 숙소는 지원되나요?
-> 아쉽지만 숙소는 지원되지 않지만 수업이 끝나고도 계속 공부하고 싶다면 강의실 제공은 합니다.

6. 필기 시험 난이도는 어느정도 되요?
-> 정보보안기사 정도의 난이도로 출제되고 있으며 1기 같은 경우는 이보다 좀 더 높은 수준 이었습니다. 이 부분도 케바케이며 학부 때 공부(3,4학년 전공 수준)을 열심히 하셨다면 무난하게 풀 수 있는 난이도입니다.

7. 비전공자도 따라 갈 수 있어요?
-> 가능합니다. 저도 전자과 출신 비전공자였고 기본기가 있다면 충분히 따라가실 수 있습니다. 다만 전공자 분들에 비해서 더 많은 노력을 하고 열정을 불태워야 살아남으실 수 있습니다.

8. 프로젝트는 어떤걸 해보면 좋나요?
-> 이 질문도 정확한 답변은 어려우나 보안에 관련된 프로젝트면 많은 가산점이 있습니다. 예를 들어 가상 웹 사이트를 진단한 프로젝트, 악성코드를 분석해본 프로젝트 등 이런 경험이 있다면 면접때도 유리할 뿐더러 교육 받을 때도 수월하게 따라가실 수 있을겁니다. 또한 보안에 대한 열정도 많이 보기 때문에 본인의 장점을 잘 어필하는게 중요합니다.

9. 교육 과정에서 이론/실기 비중은 어느정도 되요?
-> 이론 20%, 실습 80% 정도 됩니다. 케이쉴드주니어는 기업이 원하는 실무 교육을 하는 곳이기 때문에 실습 비중이 압도적으로 높습니다. 그렇기 때문에 실습을 잘하는 교육생이 유리합니다.

10. 수료하는 교육생은 얼마나 되요?
-> 선발인원은 120명이지만 출석 저조, 개인 사유 등을 이유로 중도 포기하는 경우도 있어 실제로 수료하는 교육생은 매 기수마다 100명 정도 됩니다.

11. 악성코드 분석으로 지원하고 싶은데 교육 수준이 어느정도 되나요?
-> 본인이 하기 나름입니다. 케이쉴드주니어는 악성코드 분석 교육을 시작하면 중급을 목표로 가르칩니다. 하지만 고급 분석가로 거듭나기 위해선 본인이 많이 노력해야 합니다. 여기에 좋은 멘토분들도 많기 때문에 본인이 하기 따라서 중급이 될 수 있고 고급이 될 수 있습니다.

12. 취업은 잘하는 편인가요?
-> 한국에서 가장 이슈되고 고민거리가 많은게 취업이죠. 케이쉴드주니어에선 정기적으로 연락오는 기업들이 많고 현재도 많은 회사에서 케이쉴드주니어 교육생을 채용해가기 위해 인력 요청이 계속 오고 있습니다. 이 외에도 본인이 지원해서 취업을 하는 경우도 있는데 케이쉴드주니어에서 교육 받은 것, 프로젝트 경험 등을 잘 어필해서 좋은 결과를 가져오는 교육생들도 많이 봤습니다. 모두가 알고 있는 보안에서 알아주는 회사들부터 컨설팅을 위주로 하는 회사, 분석, 개발을 하는 회사 등 많은 회사가 있습니다. 실제로 케이쉴드주니어 교육생들은 대체적으로 취업을 잘했고 원하는 회사, 포지션에 가서 열심히 일하고 있습니다. 현재도 동기들과 꾸준히 잘 만나고 많은 정보들을 주고 받고 있구요.

13. 보안사고분석대응 과정에서 프로그래밍 지식 수준은 어느정도 되야 하나요?
-> 많이 알고 잘할수록 유리합니다. html, javascript, python 언어 정도 구사하고 읽을 줄 알면 문제 없습니다.

14. 대회도 많이 나가나요?
-> 네. 많이 나갑니다. 실제로 나가서 수상한 교육생들도 있고 최근엔 K-사이버 시큐리티 챌린지에 나가서 최우수상을 차지했습니다. 이 외에도 해킹방어대회, 보안 개발 경진대회 등 많은 대회를 나가 좋은 성적을 거두고 있습니다.

15. 꼭 기술이 좋아야 선발 되나요?
-> 그렇진 않습니다. 기술은 여기 와서도 충분히 가르쳐주시는 멘토님들도 많고 잘하는 교육생 사이에서도 배우고 성장해나갈 수 있습니다. 다만 전산 기초, 보안 기초 지식 정도는 알고 오시는게 좋고, 요즘은 기술보다는 인성을 중요시하는 추세로 가고 있습니다.(이건 채용을 희망하는 회사들도 말했습니다) 나중에 과정 수료 후 기술팀 지원을 희망하실 수 있는데 저희팀도 기술보다는 인성을 중요시 봅니다.

요즘 오픈챗방, 카페 등 케이쉴드주니어에 많은 관심과 궁금증을 가지는 분도 많은 것 같아 적어봤습니다. 저도 케이쉴드주니어에서 공부한 후 취업한 경우며 교육 받는 동안 만큼은 모든 열정을 불태워서 공부했던 기억이 납니다. 케이쉴드주니어를 준비하시는 분들 모두 좋은 결과가 있길 바라겠습니다.

1. 브루트 포스 공격 대응 방안

[그림 1-1] 로그인 페이지

브루트 포스 방어가 되어 있는 로그인 페이지는 오류가 3회 이상 발생 시엔 15분 동안 로그인을 차단한다. 3회에 15분을 기다려야 하기 때문에 브루트 포스 공격은 사실상 불가능하다.

[그림 1-2] 소스 코드 - 1

소스코드를 보면 패스워드는 md5 형태로 해서 처리하고 있으며 username 변수에 대해선  mysql_real_escape_string() 함수를 처리한다. 또한 만약 로그인에 실패했을 때 sleep 함수를 사용해 응답 속도를 늦춘다. 만약 일정한 응답 속도로 설정하면 공격자 입장에선 패스워드가 틀린 것이라고 생각하고 다시 공격을 시도 할 수 있게 된다. 하지만 [그림 1-2] 소스코드에선 랜덤하게 응답 속도를 설정해서 공격자가 입력한 패스워드가 일치하는지 불일치하는지 판단하기 어려워져 브루트 포스 공격에 부담을 줄 수 있다.

[그림 1-3] 소스 코드 - 2

타임 아웃을 설정해놓는 소스코드다. 만약 3회 이상 로그인이 실패하면 자동으로 15분동안 로그인이 금지된다. 하지만 정상적인 사용자도 3회 이상 패스워드가 틀리면 15분 동안 접속이 차단된다. 사용자의 ID를 차단하기 보단 접속자 IP를 차단하는게 가용성을 높일 수 있지만 접속자 IP 주소를 서버에서 관리를 해야 하기 때문에 서버의 부담이 늘어날 수 있는 단점이 있다.

1. 브루트 포스 공격 개요

[그림 1-1] 브루트 포스 공격

[출저: 화이트헤커를 위한 웹 해킹의 기술]

브루트 포스 공격이란 특정 정보(사용자의 패스워드)를 알아내는 공격이다. 만약 패스워드가 일치하지 않아도 계속 바꿔가며 공격할 수 있고 시간이 오래 걸리지만 언젠가는 계정 정보가 일치해 로그인이 가능하게 된다. 패스워드가 너무 쉽거나 추측 가능하게 설정하면 브루트 포스 공격에 의해 너무 쉽게 노출될 수 있다. 하지만 특수문자를 섞어서 설정하면 공격에 시간이 상당히 많이 소요되기 때문에 패스워드가 쉽게 노출될 수 없게 된다. 브루트 포스 공격 방지를 위해 페이지 내에 방어도 중요하지만 사용자의 비밀번호 설정 방식도 브루트 포스 공격을 예방하는 방법 중 하나가 될 수 있다.

2. 브루트 포스 공격 실습

(1) 자동 브루트 포스 공격

[그림 2-1] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-2] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-2] payloads

페이로드 설정에서 Payload type을 Brute Forcer로 선택한다. Payload Options에서 Character set이 자동 지정되는데 영문자부터 숫자 9까지 지정된다. 이 부분에 특수문자들을 추가하면 Payload count는 늘어나고 Max length 숫자를 높이면 unknown이 표시된다. 그만큼 브루트 포스 공격을 하는데 있어서 많은 시간이 소요된다는 의미다.

[그림 2-3] 브루트 포스 공격

브루트 포스 공격 화면이다. 문자를 하나씩 넣어가며 자동화 공격을 시도하고 있다. 만약   응답 요청 길이가 다른 숫자 값으로 나온다면 그 문자열이 사용자 계정의 비밀번호다. 하지만 Brute forcer를 이용한 공격은 많은 시간이 걸리기 때문에 비효율적인 방법의 브루트포스 공격이 될 수 있다.

(2) Dictionary 브루트 포스 공격

[그림 2-4] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-5] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-6] payloads

Payload type을 Simple list로 선택한 후 Payload Options에서 사용자들이 가장 많이 사용하는 패스워드를 담은 txt 파일을 만든 후 업로드 한 후 Start Attack 버튼을 누른다.

[그림 2-7] 브루트 포스 공격

브루트 포스 공격 시도 결과 응답 요청 길이가 다른 것이 있다. 2번 응답 요청 길이는 5293이지만 1번 응답 요청 길이는 5358이다. 이 때 사용자 계정 비밀번호는 1234라는 것을 알 수 있다. 패스워드가 올바르지 않은 경우면 로그인 실패 페이지가 응답되지만 패스워드가 올바른 경우면 로그인 성공 페이지가 출력되게 된다. 즉, 1번 요청은 로그인에 성공한 페이지가 응답된 것이라고 생각할 수 있다.

[그림 2-8] 소스 코드

소스 코드를 보면 비밀번호는 md5로 해쉬화 해서 취약점은 발생하지 않는다. 하지만 username은 별다른 조치 없이 SQL 문에 그대로 입력 됨을 볼 수 있다. 하지만 쿼리 구문 아래 코드에서 SQL 결과 값이 1개일 때만 로그인 된다는 것을 알 수 있다. 이 경우에 사용자 비밀번호를 알지 못해도 SQL 인젝션 취약점이 발생할 수 있음을 추측할 수 있다.