[보안] 웹 해킹 팀 프로젝트(Writeup)

웹 해킹 프로젝트는 팀별로 웹페이지를 만들고 서로의 웹페이지의 정보를 빼오는 모의해킹을 실습한 프로젝트입니다.

이 프로젝트는 2주 동안 웹페이지를 만들고 1주일에 한 번씩 2회의 실습에 걸쳐 진행되었습니다.

 

사실상 보안 프로젝트이지만 웹 개발도 같이 공부한 것 같습니다.

 

본 게시글은 아래 글의 후속 편입니다.
https://perconsi.tistory.com/38

[프로젝트] 웹 해킹 팀 프로젝트(모의 해킹 시나리오)

 

1. 팀별 웹페이지 소개

1.1 Team3: 로그인/게시판 구현

메인 페이지

 

 

웹 구현 방식 확인 user_id와 user_pw변수로 id/pw를 받아서 post방식으로 다음 페이지에 전달 / 회원가입 / 게시판

게시판

 

 

 

 

1.2 Team4: 로그인/게임 구현

 

 

 

 

 

 

 

 

 

 

1.3 Team5: 로그인/게시판 구현 (우리 팀)

웹 개발은 처음이었지만 처음 로그인/회원가입 구현하고 게시판 틀을 만든 뒤로는 삭제/확인/글쓰기 등은 메커니즘이 비슷해서 수월하게 할 수 있었다.

 

 

 

 

 

 

 

 

 

 

 

조금 신경 쓴 부분은 게시글을 삭제할 때 비밀번호를 확인하는 과정에서 JS alert로 입력받아서 다음 페이지로 넘기고(php) DB에서 불러와서 확인하고 삭제 alert를 띄운 것이다. 

 

 

 

2. 모의해킹 실습

2.1 1회 차

✓ 3조에 id = admin, pw = 'or'1=1으로 admin으로 로그인(by 다른 팀원분)

로그인

✓ 3조에 sql injection으로 테이블명 알아냄(me)

sql injection시도

✓ 3조 21,80,443 열린 포트 확인(me)

포트스캔

느낀 점/총평

• 시나리오를 준비하지 않고 무계획으로 실습하다 보니 비효율적이었음
• 기본기(코딩)에 더욱 충실해야겠다 생각함
• 워게임에서의 실습은 일부러 취약하게 만들어짐 그래서 실제 해킹과는 괴리감이 있어서 워게임의 한계를 느낌(feat. 화이트해커를 위한 웹 해킹의 기술)

Ex) 1 or 1’만 해도 너무 친절하게 답이 나옴..
->그럼에도 불구하고 응용을 위한 기본 틀로는 도움 됨

• 너무 어려워서 내가 갈 길이 보안이 맞는가 다시 한번 생각하게 됨

 

피드백

• 이 실습(1회 차)에서 너무 준비가 부족했다 느낌
• 계획(시나리오)을 준비해야겠다
• 우리 웹에 실습해 보며 계획 세우자
• 다음 실습(2회 차) 때 목적: 다른 팀 DB 정보를 빼오는 것

(∵) 다른 팀 DB정보 ≒ 실제 웹사이트에서 회원들의 정보 유출


위 피드백의 결과로 나온 게 앞선 게시글인 시나리오입니다.

---

2회 차

✓ 4조 공격

1. 취약점 분석
sqlmap으로 시나리오를 작성하며 배운 건데 웹에 $_GET으로 받는 페이지가 하나라도 있으면
전체 DB와 테이블을 탈취할 수 있다.

그래서 $_GET으로 받는 페이지를 먼저 찾아봤다.
id라는 변수를 get으로 받는 것으로 추정되는 페이지 발견했다.

취약한 페이지 포착

2. GET으로 Injection 시도
위에서 발견한 페이지를 대상으로 아래와 같이 데이터베이스를 조회하는 명령을 입력했다.

Sqlmap -u https://colony-webnetwork-dieqj.run.goorm.io/register.php --dbs

그런데 에러가 나서 다시 페이지로 돌아가 소스코드를 살펴보앗다.에 get의 형식을 띄고 있어서 당연히 get인 줄 알았는 데 알고 보니 get이 아니라 그냥 하이퍼링크로 값을 고정한 거였다.

소스 코드

3. POST로 Injection 시도
따라서 get으로 받는 url을 찾지 않고 바로 로그인 화면을 대상으로 sqlmap을 아래와 같이 post로 명령을 작성했다.

Sqlmap -u https://colony-webnetwork-dieqj.run.goorm.io/register.php
--method=”post”—data=”username=1&password=3” -p ”username” -v 3 -D colony –tables

--method로 post로 받는다고 알려주고 –data로 값이 어떻게 전 달 되는지 알려준다. 참고로 data에 지정된 id, pw의 1,3이라는 값 은 아무거나 찍어 넣은 것이다. Username과 password 변수는
소스코드의 name변 수명이다.

다음으로 –p로 변수가 무엇인지 알려준다.
처음 시도가 usernameusername이었고 안 되면 -p “password”도 해보려고 했는데 다행히 잘 되었다.

post에 맞게 공격

DB확인

(colony가 우리 동아리명)
위 사진과 같이 현재 로그인 화면의 DB는 colony임을 알아냈다.

4. 테이블, 칼럼 조회
위 명령문에 옵션을 추가하는 형식으로
차례로 -tables,-columns를 추가해서 테이블과 칼럼을 조회했다.

테이블 확인

5. 전체 DB 덤프는 실패
왜인지 모르겠지만 전체 DB는 덤프에 실패했다.

 

Sqlmap이 자동화 프로그램으로 Injection을 시도하고 있는 화면이다.

결론적으로 4조는 DB 명 colony와 테이블명 user만 알아낸 상태로 종료되었다.

✓ 3조 공격

1. 취약점 분석
3조는 대놓고 form 태그에 method=”get”으로 명시되어 있어서 해당 페이지를 상대로 Injection을 시도했다.

2. 데이터베이스 조회
get으로 받는 페이지의 URL에 –dbs 옵션을 주어 데이터베이스 목록을 먼저 확인했다.

위 사진과 같이 여러 DB 목록을 확인할 수 있다. Information/performance_schema, sys 등등은 보통 디폴트 데이터베이스여서 Testbook이 로그인 테이블이 있는 DB라고 추정했지만 확인을 위해 현재 DB를 조회해 준다.


3. 현재 데이터베이스 확인
현재 데이터베이스는 예상과 같이 testbook 임을 확인할 수 있다.

db확인

4. 테이블 조회
확인한 db testbook을 -D “testbook”으로 지정해주고
--tables로 테이블을 조회하면 blogin과 board 테이블을 확인할 수 있다.

참고로 blogin 테이블은 실습 1차시에 sql injection을 시도했을 때 힌트로 나온 테이블명과 일치한다.

5. 전체 덤프
Board 테이블은 게시판 DB이고 blogin은 로그인 DB라고 추정할 수 있다. 이를 확인하기 위해 blogin과 board 테이블을 데이터베이스를 지정해 준 상태에서 차례로 덤프 해준다.

위 사진을 보면 예상과 같이 blogin이 로그인 테이블이고
board가 게시판 테이블임을 확인할 수 있다. 그리고 두 테이블 모두 덤프에 성공했다.

Blogin 테이블에서는 회원들의 정보가 탈취되었고 board테이블에서도
게시판에 작성된 글이 DB에 저장된 화면을 확인할 수 있다. 이상으로 3조 Writeup도 마무리된다.

✓ 대응 방안

만약 이것이 실제 웹페이지였다면 위 정보는 회원들의 실제 정보였을 것이다.

대응 방안으로는 Mysqli_real_escape_string() 등을 이용하여 입력 값에 대한 검증이 필요하다.
Mysqli_real_escape_string()은 php에서 제공하는 함수로 웹과 DB를 연동할 때 String을 escape 한 상태로 만들어준다.

그리고 비밀번호를 암호화해서 저장하는 것도 중요하다.
위에 덤프 된 blogin 테이블을 보면 암호화되지 않고 저장되어 그대로 패스워드가 노출되는 것을 확인할 수 있다.
따라서 md5 혹은 외부 파일을 include 하는 방법 등으로 암호화가 필요하다.