해커의 목적
먼저, 해킹 의뢰를 받은 해커의 최종 목적은 ‘여기 어때’ 데이터베이스에 저장된 회원정보, 숙박예약정보, 제휴점 정보 등을 획득하는 것이었습니다. 해커는 데이터베이스 서버에 접근하기 위해서 ‘서비스 관리 웹서버’ 즉, 여기어때 서비스 관리 시스템에 접속하는 것을 목표로 하였습니다.
‘서비스 관리 시스템’에서는 회원 정보, 예약 정보를 확인하고 관리하는 기능이 있을 것으로 쉽게 예측할 수 있습니다. 서비스 관리 시스템에서 해당 정보에 접근할 수 있는 계정은 DB서버에 있는 회원 정보나 예약 정보 테이블에 접근할 수 있는 ‘권한 있는 사용자’라고 유추할 수 있습니다. 따라서 해커는 ‘서비스 관리 웹서버’의 ‘관리자 계정’으로 로그인을 하고자 계획합니다.
해커는 여기 어때 운영사에서 관리중인 웹사이트들 중에서, SQL 인젝션 공격에 취약한 홈페이지를 찾았습니다. 여기 어때의 ‘마케팅 센터 웹서버’는 비정상적인 SQL문에 대한 검증 절차가 없었기 때문에 SQL 인젝션 공격에 취약한 상태였습니다.
세션ID 획득 (SQL Injection)
만약 ‘마케팅 센터 웹서버’에서 SQL 인젝션에 대한 대응 방안이 전무했다면, 사진과 같이 텍스트 필드에 [’ OR 1=1] 값을 입력하는 정도만으로도 데이터베이스의 데이터를 얻을 수 있습니다.
위의 예시는 ' 로 id 파라미터의 입력을 끝내고, OR 1=1로 WHERE절을 모두 참으로 만들었습니다. --으로 뒤의 문장을 주석으로 만들었습니다. 즉 모든 Users의 데이터를 가져오는
SELECT * FROM Users구문과 같은 의미가 됩니다.
보통 웹페이지의 관리자 계정의 아이디로 ‘admin’을 사용하므로, ID는 [admin], 패스워드는 [’ OR 1=1]값을 입력하여 손쉽게 관리자 계정에 로그인할 수 있습니다.
‘관리자 페이지’에서는 sql 인젝션을 사용하지 않고 세션 하이재킹을 실행한 것으로 보아, sql 인젝션에 대한 방어 수단이 ‘웹서버’ 앞단에 존재했을 것으로 추측할 수 있습니다. 마케팅 서버 웹서버에서 DB에 접근할 때 sql 인젝션이 가능했으므로 방어 수단이 웹서버와 DB 사이(DB 앞단)에 있다고 보긴 어려울 것 같습니다. (IDPS의 위치)
해커는 마케팅 서버 웹페이지에서 DB 서버에 접근 가능한 계정으로 로그인한 후, DB서버에서 ‘서비스 관리자 시스템’의 ‘관리자 계정’의 ‘세션값’을 얻었습니다. 이때 해커가 로그인한 계정은 데이터베이스의 ‘회원 정보 테이블’에 접근할 권리가 없었기 때문에 세션 정보만을 얻었을 것입니다.
세션값을 데이터베이스에 저장한다는 것은 다중 서버를 사용하기 때문에 세션id를 저장할 필요가 있다고 해석할 수 있습니다. 다중 서버를 사용한다는 것은 보통 세션 클러스터링의 경우를 말하며, 여러개의 물리적 서버를 하나의 서버처럼 운용하는 것을 말합니다.
하지만 마케팅 서버 웹서버는 일명 사장님 서비스로, 고객이 사용하는 서비스입니다. 고객이 사용하는 마케팅 서버 웹서버와 사내에서 사용할 것으로 예상하는 서비스 관리 시스템이 서로 세션id 를 공유 필요가 없음에도 불구하고, 마케팅 서버 웹서버에서 서비스 관리 시스템의 세션id 데이터를 조회할 수 있도록 허용한 것은 큰 보안적 허점으로 볼 수 있습니다.
서비스 관리 웹서버 접속 (HTTP Session Hijacking)
해커는 이미 관리자 계정의 세션 ID를 알고 있었으므로, 사진의 4번부터 진행하면 세션 하이재킹을 성공할 수 있습니다.
헤더에 세션 ID를 포함한 http 패킷을 서버에 request 합니다. 서비스 관리자 웹서버는 탈취된 세션값을 통한 우회 접속, 즉 세션 변조 공격을 탐지,차단하는 체계가 없었기 때문에 요청된 패킷의 세션ID값만 확인한 후, 정상적인 response 패킷을 보냅니다.
따라서 해커는 획득한 세션값을 사용하여 서비스 관리 시스템에 손쉽게 우회 접속 할 수 있었습니다. 서비스 관리 시스템에 관리자 계정으로 접속한 이후, 해커는 해당 시스템에서 회원 정보와 예약 내역을 읽고 수정할 수 있는 페이지로 이동하였고, 관련 정보를 조회, 저장하여 성공적으로 목적을 달성하였습니다.
SQL Injection 대응 방안
SQL 인젝션 공격을 예방하기 위해서 다음과 같은 조치를 할 수 있습니다.
웹 서버 내에서의 조치
‘웹서버’ 내의 정보를 사용자가 쉽게 읽지 못하도록 조치하거나, 웹 어플리케이션과 연동되는 데이터베이스의 접근 권한을 최소화하는 방법, 사용자 입력 폼에서 특정 문자열을 필터링 하는 방법이 있습니다.
홈페이지 개발 보안 조치
홈페이지의 소스코드에서 사용자의 입력값을 필터링하는 코드를 추가할 수 있습니다.
보안 코드 사용
데이터베이스 파라미터 값을 미리 단순 문자열로 치환하는 prepared statement 문을 사용하여 예방하는 방법이 있습니다.
Error Message 노출 금지
오류 페이지를 만들고 리디렉션 하여, 데이터 베이스에서 발생한 오류를 사용자에게 직접 노출하는 것을 피해야 합니다.
HTTP Session Hijacking 대응 방안
http 세션 하이재킹 공격을 예방하기 위해 다음과 같은 조치를 취할 수 있습니다.
Secure, HttpsOnly 설정
http는 암호화 되지 않은 데이터를 전송하므로, 웹 어플리케이션이 쿠키 값을 브라우저에 전달할 땐 https가 적용된 상태에서만 가능하도록 설정하여 제 3자가 쿠키를 탈취하지 못하도록 예방합니다.
Session ID 설정
세션 ID의 생성 범위값을 충분히 크케 설정하고, 추측 불가능 하도록 random하게 설정하여 세션 ID를 획득하기 어렵도록 할 수 있습니다. 세션 TimeOut과 세션ID 재생성 기능을 사용하여 같은 세션을 오래 사용하지 않도록 할 수도 있습니다.
웹페이지 점검
웹서비스상에 html 공격 코드 삽입이 가능한 페이지가 있는지 점검하여 세션ID를 보호할 수 있습니다.
