Sql Injection 침해 흔적을 통한 보안점검

여러 보안 기관 및 언론등에서 자주 오르내리는 해킹사건의 상당 부분이 웹사이트를 통해서 이루어지고 있다.

왜냐면, 요즘에는 거의 대부분 방화벽등의 장비등을 통해서 막아 놓기 때문에 역시 공개되어 있는 루트를 이용해야 하는데 그것이 바로 웹사이트 이기 때문이다.

예전에는 주로 서버자체 OS나 응용프로그램의 취약점을 노리고 있으나, 최근에는 웹사이트 프로그램 코드의 취약점을 이용하고 있으며, 국내 웹사이트의 상당수가 (일부 포털의 CP 사이트 포함) 노출되어 있는 형국이고,. 데이터가 탈취 당했음에도 여전히 모르고 있는체 웹사이트가 운영되고 있다.

웹사이트 해킹은, 해당 웹사이트 파괴나 데이터 위변조에서 멈추는게 아니라 곧바로 시스템까지 해킹할수 있게 된다.

요즘에 극성을 부리는 중국(일명 짱께) 에서 하루가 멀다하고 해킹시도가 이루어 지고 있고 그 대부분이 Sql Injection, FTP 스캔, RPC, SMB 등이다.

위 통계는, http://www.krcert.or.kr/index.jsp 에서 해킹 트랜드를 확인할수가 있다.

자, 그럼 그중에 가장 위험한 DB 연동 웹사이트에 의한 데이터 위변조 및 시스템해킹 인데 그들이 어떤 흔적을 남기는지 결과를 통해서 현재 운영하는 본인의 시스템을 점검해 보는것이 좋다.

(* 샘플 일부의 내용중 서버명의 경우 SERVERINFO,serverinfo.pe.kr 로 변경함)


1. 웹사이트 연동 데이터베이스 DB 의 테이블 목록 확인.

Sql Injection 을 통해서 해킹이 된 경우, 데이터 유출을 하는 경우도 일부 있으나 대부분 시스템을 조회한 테이블을 남긴다. 일부 해커의 경우는 조회후 테이블을 삭제하기도 한다.

DB의 테이블 목록을 정기적으로 점검을 해보는 것이 좋은데, 해킹된 DB의 경우 주로 다음과 같은 이름의 테이블이 생성되어 있다.

테이블 스키마나, 레코드를 보면 테이블 이름과 비슷한 내용이 들어 있는데 주로 시스템디렉토리 목록이나 웹사이트 디렉토리 목록, 레지스트리 값 조회가 대부분 이다.



2. xpcmdshell 을 통한 시스템 해킹

일부 몰지각한 개발자들의 경우, 웹사이트 DB 연동계정을 sa 계정이나, 시스템권한이 있는 DB 계정을 이용하는 경우가 있는데 그때는 xp_cmdshell 확장프로시져를 통해서 서버내 어떠한 작업도 가능해져 완전 장악당하는 경우가 있다.

다음은, 보안이벤트 로그 일부 이다.  sa 같은 계정으로 연동된 웹사이트가 침해되는 경우, 대부분 SQL Server는 SYSTEM 계정으로 서비스가 실행되는데 xpcmdshell 명령을 실행하게 되면 SYSTEM 권한으로 실행을 하게 된다. 

일부는, SQL 을 Administrator 같은 어드민권한이 있는 계정으로 서비스를 실행하는데 어차피 실행 계정이 서버내에서 모든 작업이 가능한 권한을 가지고 있으므로 계정을 지정한다고 해서 취약점을 피해갈수 없다. (*예)

다음과 같이 해킹용 새로운 계정을 등록하거나, 패스워드 변경 시도 및 삭제등이 가능해 진다. 아래와 같은 작업을 했다는 것은 서버내 어떠한 작업도 가능하다는 것이며 이는 완전히 장악 당했다는 증거이다.




3. 웹사이트를 통해서 데이터베이스 탈취 시도

다음은, DB서버에서 백업을 하여 웹사이트를 통해서 데이터를 다운로드 하는 것이다. SQL 서버에서 해당 데이터베이스의 백업을 할때 백업미디어를 다음과 같은 웹사이트 디렉토리에 파일로 저장하여 백업파일로 지정한다.


또는, 해당 asp 파일을 생성후 해당 asp 파일 코드내에 여러가지 작업이 가능한 시스템 명령어 및 DB 쿼리 명령어를 넣어 두기도 한다.



4. Sql Injection 시도 웹사이트 로그

위와 같은 작업은 웹사이트를 통해서 하는데, 자동화된 툴을 이용하는 경우에는 웹사이트 주소줄의 레퍼러 위/변조 방법을 이용하고 직접적인 시도는 레퍼러 위조 뿐만 아니라 폼값 POST 전송을 통해서도 시도를 한다.

(* 다음은, 필자의 웹사이트인 Serverinfo.pe.kr 을 거의 매일 다음과 같이 스캔을 당하고 있다.)



물론, 레퍼러 버퍼를 작게(제한) 해놓은 웹서버도 있기는 하지만 그렇다고 그것이 방어의 대안이 되지는 못한다.


5. 방어

방어의 최상의 방법은, 기본적인 방화벽에 의해서 공개 서비스외는 차단이 되어 있다는 가정하에,.