본문으로 바로가기

간혹 홈페이지의 소스파일 중 하나인 Javascript 파일이 변조되는 해킹공격을 당해 긴급하게 서버보안SW적용을 요청하는 기업들이 있다. 대부분 보안에 신경을 쓰지 않은 채 웹서버를 구축하거나 홈페이지를 개발하는 경우가 대부분이지만 간혹 이름만 대면 다 아는 그런 기업도 종종 있는 편이다. 


얼마 전 긴급하게 요청이 온 기업도 이름만 대면 다 아는 기업이었다. 공교롭게도 방화벽, IPS(웹방화벽), 웹소스변조방지 등 여러 제품을 도입하여 프로젝트를 진행하는 도중에 지속적으로 소스파일이 변조하여 자바스크립트를 삽입하는 공격이 발생하고 있었지만 도입된 솔루션들이 무용지물인 상황인 듯 했다. 급하게 엔지니어를 보내 RedCastle을 설치하고 홈페이지 소스파일들이 위치한 경로에 다음과 같은 정책을 적용했다.


정책은 아주 간단하다. 소스파일 경로 아래의 모든 파일에 대해 아래 화면처럼 IIS 웹서버 (w3wp.exe)가 읽기만 가능하고 수정을 하지 못하도록 하는 정책이다. (물론 운영체제를 보호하는 baseline policy는 적용하였음)



정책을 적용하고 얼마 지나지 않아 javascript 파일에 대해 변조 공격이 들어왔고 정책에 의해 차단되었다.

변조가 시도되는 파일은 감사로그에 정확하게 기록되었다.



해커는 몇차례 반복하여 Javascript 파일를 변조하려 시도하였고 그 시도는 번번히 RedCastle에 의해 차단되었다. 


인터넷을 통해 온라인 주문을 실시간으로 처리하거나 대 고객 서비스 업무를 수행하는 웹서버는 언제는 위와같은 홈페이지 소스 위변조 공격을 당할 수 있다. 하지만 공격당했다는 사실 조차 모르는 경우가 비일비재하다.  


왜냐하면 해커가 변조한 그 웹서버가 "공격 대상"이 아니라 그 웹서버에 웹브라우저를 통해 접속한 일반 사용자의 PC가 공격대상이기 때문에 서버에 쉽게 알아챌만큼 큰 피해를 단시간내에 주지는 않기 때문이다. 즉 일반 사용자의 PC에 악성코드를 다룬로드 받도록 java script 파일에 악성코드를 심어 놓는 것이 해커가 웹서버의 소스를 변조하는 목적이기 때문인 경우가 많다. 만약 더 이상 서버의 활용도가 없다면 그땐 큰 피해를 주고 유유히 빠져나갈 가능성도 배제할 수는 없다.


이렇게 외부에서 웹소스나 웹서버의 취약점을 공격하여 소스파일을 직접 변조하려는 시도는 오히려 다른 공격보다 위험도 측면에서 나은 경우일 수 있다. 만약 실제로 소스파일이 변경되지 않았는데 웹브라우저로 접속해보았을 때 변조된 Javascript가 소스보기로 보면 소스가 변경되어 보인다면 상황은 더욱 심각할 수 있다.


이런 경우는 정말 심각한 경우다. 이미 웹서버가 있는 네트워크에 해커가 침투하여 거점을 마련하고 스니핑과 스푸핑 공격에 성공한 경우이거나 SQL인젝션 등을 통해 다른 서버나 PC에 이미 침투하였을 가능성이 높기 때문이다. 만약 그렇다면 피해는 서버 한두대에 그치지 않을지도 모르는 심각한 상황이라고 봐야한다.


IIS웹서버의 소스에 악성코드가 삽입되어 있다면 최대한 빨리 취약성을 제거해야 한다. 하지만 취약성 하나를 제거한다고해서 소스위변조가 다시는 일어나지 않는다는 보장은 없다. 취약성이라는 것은 언제든 새로운 것이 발견되거나 새로 추가한 페이지에 존재할 수 있기 때문이다. 


그렇기 때문에 가장 최선의 방법은 공격패턴이나 취약성 공격에 대응하는 패턴기반의 웹방화벽이나 IPS가 아닌 정책기반의 서버보안SW인 RedCastle을 설치하여 소스 파일의 위변조를 커널 수준에서 통제하는 것이 최선의 해결책이다. 


결국 그 고객사는 경쟁사 제품을 걷어내고 RedCastle을 도입하였다.


신고

댓글을 달아 주세요