Database Management Tools Log pattern compare: PMA & Adminer

1. 개요

다형의 침해사고의 유형 중 데이터베이스에 대한 침해사고는 데이터의 유출과 파괴 등의 행위로 이어진다.
안랩에서 발표한 자료 [그림 1]에 따르면 2019년 사이버 공격의 전체 중 39%가 웹 기반의 공격으로 진행 되었다고 한다.

[그림 1] 2019년 사이버 공격 동향 통계

웹 서비스는 데이터베이스와의 연결이 거의 필수적이고 대다수 기업의 서비스가 웹 기반으로 서비스가 이뤄지고있다.
서비스 담당자 혹은 전산 담당자는 데이터베이스를 좀 더 편하고 효율적으로 관리하기 위해 데이터베이스 관리 툴을 이용하는데, WordPress 같은 CMS의 관리 플러그인이나 phpMyAdmin, Adminer 같은 웹 기반의 관리 툴을 흔히들 사용하곤 한다.
관리자의 입장에서 데이터베이스 관리 툴은 매우 유용한데, 이는 공격자의 입장에서 또한 효율적인 공격 도구로 사용할 수 있기에 주된 공격 포인트가 되어왔다.
본 포스트에서 두가지의 웹 기반 데이터베이스 관리 툴을 이용하여 데이터베이스에 접근하였을 때 웹 로그에 남는 흔적을 분석, 정리하여 해당 툴이 사용된 침해사고 분석에 도움이 되고자 한다.

2. 분석 환경 구성

phpMyAdmin과 Adminer에 대해 분석이 진행 되었다.

먼저 phpMyAdmin은웹 개발자 혹은 관리자라면 한번쯤은 들어봤을 관리 툴일 것이다.
PHP로 작성된 오픈 소스 도구로서 직관적인 웹 인터페이스를 통해 자주 사용되는 작업을 수행 할 수 있으며 SQL문을 직접 실행할 수 있다.

[그림 2] phpMyAdmin

Adminer는 패키지 형태인 phpMyAdmin과는 다르게 단일 페이지로 구성된 데이터베이스 관리 도구이다. 단일 페이지이기 때문에 크기가 작고, 따로 설치가 크게 필요 없다는 점에서 관리자나 공격자 두 입장 모두에게 매혹적인 도구일 수 밖에 없다.

[그림 3] Adminer

매혹적인 이 두 도구들을 각각 두 가지 버전(최신 메이저 버전과 바로 이전 메이저 버전)에 대해 분석을 진행 했으며, 각 버전들과 구성 환경은 [그림 4]와 같이 구성한 후 진행하였다.

[그림 4] 분석 환경

3. 분석 방법

최대한 동일한 환경에서 진행을 하였지만, Adminer3는 php5 버전 까지 지원을하여 해당 버전은 php5 버전에서 분석이 진행되었다.
또한 MySQL 5.7버전 이후 부턴 터미널이 아닌 환경에서의 root 계정의 로그인이 제한되어있어 원할한 분석을 위해 “plainbit” 계정을 생성하여 다음과 같은 구문을 사용하여 권한을 부여하였다.

INI
mysql > GRANT ALL ON *.* to 'plainbit'@'localhost' identified PASSWORD
1
mysql > GRANT ALL ON *.* to 'plainbit'@'localhost' identified PASSWORD

Apache 환경에서의 데이터베이스 관리 도구를 이용한 동작이 access.log에 어떻게 남는지를 중점으로 분석하였으며, 여러 행위(DB 질의, 쿼리 실행 등)를 수행한 후 해당 로그를 추출하는 방식으로 분석을 진행하였다.

[그림 5] 분석 순서도

4. 분석 결과

가독성을 위해 분석 결과의 일부 리소스에 대한 로그(css, image 파일 등)는 제외하고 작성하였다.


# 로그인(Login)

a. phpMyAdmin

  • 로그인 여부
[그림 6] PMA Login 로그

b. Adminer

  • 로그인여부
  • 로그인한 계정명(username 파라미터)
[그림 7] Adminer Login 로그
# 데이터베이스 생성(DB Create)

a. phpMyAdmin

  • 데이터베이스 생성 여부
  • 생성된 데이터베이스명(db 파라미터)
[그림 8] phpMyAdmin 생성 로그

b. Adminer

  • 데이터베이스 생성 여부
  • 생성된 데이터베이스명(db 파라미터)
[그림 9] Adminer DataBase 생성 로그
# 데이터베이스 삭제(DB Drop)

a. phpMyAdmin

  • 알 수 없음
[그림 11] Adminer DataBase 삭제 로그 – 1
  • 데이터베이스명(db 파라미터)
    *[그림 12] : [데이터베이스 목록] – [데이터베이스 상세페이지] – [삭제] 순으로 접근시
[그림 12] Adminer DataBase 삭제 로그 – 2
# 테이블 생성(Table Create)

a. phpMyAdmin

  • 테이블 생성 여부
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 13] PMA Table 생성 로그

b. Adminer

  • 테이블 생성 여부
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 14] Adminer Table 생성 로그
# 테이블 초기화(Table Truncate)

a. phpMyAdmin

  • 초기화(Truncate) 여부
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 15] PMA Table Truncate 로그

b. Adminer

  • 알 수 없음
[그림 16] Adminer Table Truncate 로그
# 테이블 삭제(Table Drop)

a. phpMyAdmin

  • 알 수 없음
[그림 17] PMA Table Drop 로그

b. Adminer

  • 알 수 없음
    * [그림 18] : [테이블 목록] – [삭제] 순으로 접근시
[그림 18] Adminer Table Drop 로그 – 1
  • 테이블 삭제 패턴(db & create 파라미터 -> POST요청 -> db 파라미터)
  • 데이터베이스명(db 파라미터)
  • 테이블명(table, create 파라미터)*[그림 19] : [테이블 목록] – [테이블 상세 페이지] – [테이블 변경] 순으로 접근시
[그림 19] Adminer Table Drop 로그 – 2
# 레코드 삽입(Record Insert)

a. phpMyAdmin

  • 레코드 삽입(Insert) 패턴
    * tbl_replace.php POST 요청
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 20] PMA Record Insert 로그

b. Adminer

  • 레코드 삽입(Insert) 패턴
    * edit 파라미터 -> POST 요청 -> select 파라미터
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 21] Adminer Record Insert 로그
# 레코드 수정(Record update)

a. phpMyAdmin

  • 레코드 수정(Update) 패턴
  • [PMA4.9.4] : tbl_change.php -> POST 요청 -> index.php -> tbl_replace.php -> POST 요청
    [PMA5.0.1] : tbl_row_action.php -> POST 요청 -> index.php -> tbl_replace.php -> POST 요청
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 22] PMA Record Update 로그

b. Adminer

  • 레코드 수정 여부
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
  • 첫번째 칼럼 및 해당 값
    * [그림 23] 참고
[그림 23] Adminer Record Update 로그
# 레코드 삭제(Record delete)

a. phpMyAdmin

  • 알 수 없음
[그림 24] PMA Record Delete 로그

b. Adminer

  • 알 수 없음
[그림 25] Adminer Record Delete 로그
# SQL 직접 실행(SQL execute)

a. phpMyAdmin

  • SQL문 실행 여부
  • SQL문 실행 페이지
    * server_sql.php(서버 정보 페이지), db_sql.php(DB 정보 페이지) , tbl_sql.php (테이블 정보 페이지)
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 26] PMA SQL문 실행 로그

b. Adminer

  • SQL문 실행여부(sql 파라미터)
  • adminer 4.7.6 버전은 쿼리문이 sql 파라미터에 남음([그림 27] 참고)
[그림 27] Adminer SQL문 실행 로그
# 내보내기(Export)

a. phpMyAdmin

  • Export 실행 여부
  • Export 실행 페이지
    *server_export.php(서버 정보 페이지), db_export.php(DB 정보 페이지), tbl_export.php(테이블 정보 페이지)
  • 데이터베이스명(db 파라미터)
  • 테이블명(table 파라미터)
[그림 28] PMA Export 로그

b. Adminer

  • Export 실행 여부(dump 파라미터)
[그림 29] Adminer Export 로그
# 가져오기(Import)

a. phpMyAdmin

  • Import 실행 여부
  • Import 실행 페이지
    * server_import.php(서버 정보 페이지), db_import.php(DB 정보 페이지), tbl_import.php(테이블 정보 페이지)
[그림 30] PMA Import 로그

b. Adminer

  • [Adminer 3.7.1] : Import 여부 알수 없음
  • [Adminer 4.7.6] : Import 여부(import 파라미터)
[그림 31] Adminer Import 로그

# 결론

각각의 도구간 메이저 버전들의 행위 흔적에 대한 패턴은 일부 파라미터나 페이지를 제외하곤 비슷한 로그를 남긴걸 알 수 있었다.
물론 단순히 웹 로그만을 가지고 데이터베이스 관리 툴을 이용해 발생한 침해사고 분석에는 무리가 있지만, 본 분석 결과를 통해 주로 일어나는 행위(테이블 삭제, SQL문 직접 실행, 내보내기 등)들의 특정한 패턴을 파악할 순 있다.
의심되는 행위에 대한 패턴이 웹 로그 상에서 확인이 될 경우, 해당 웹 로그와 전후 로그를 연결지어 분석하게 된다면 좀 더 명확한 행위 파악이 가능할 것으로 보인다.
이를 참고하여 분석에 도움이 되었으면 한다.

You've successfully subscribed to PLAINBIT
Great! Next, complete checkout to get full access to all premium content.
Error! Could not sign up. invalid link.
Welcome back! You've successfully signed in.
Error! Could not sign in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Error! Billing info update failed.