몇달 전 전산담당자로 부터 자문을 구해온적이 있었다. 메일 서버가 2년 동안 무작위로 1%정도 계정이 스펨메일로 활용 된다는 정황이 있다는 것이다. 보유한 메일 계정은 2~3만개 정도라고 한다. 그 계정이 실제 메일서버에서 발송된 것이고, 패스워드 길이도 9자리 이상에 특수문자를 포함하여 길다고 하는것이다. 그 메일이 외부에도 아웃룩이 오픈되어 있는 상황이였다. 메일 서버에 루트킷이 설치되어있을 가능성이 있어서 서버를 포멧하고 재설치 하라고 권고를 하였다.

몇달 뒤 포멧을 하고, 재설치를 해도 동일한 현상이 발생 된다고 문의가 온것이다. 웹메일 엔지니어가 와도 원인도 못찾고, 릴레이 정책도 다 적용이 되어 있다고 한다. 아는형에게 자문을 구하니 Cain & Abel같은 Arp스푸핑이 아닌가 한다. 부서에서는 악성코드일지 모른다고 한다.
Arp 스푸핑이면 smime일텐데 허가되지 않는 인증서라고 계속 뜰것이다. 해킹 당한 사람 이야기로는 그런것이 전혀 없었다고 한다. 공유기나 게이트웨이에서 AP라도 잘 찾아 보라고 이야기는 했다.

그리고 해킹 당한 사람들 중 한두명만 악성코드가 발견되었고, PC포멧해도 그런 증상이 발생 되었다고 한다. 해당 악성코드나 루트킷이 2년동안 활동 할러면 백신에 탐지가 안되는 제로데이 악성코드가 내부 인트라넷 같은 곳에서 배포 된다는 것인데 2년동안? 그정도로 정교한 악성코드라면 APT형태의 공격이라면 자료유출이 목적일텐데 왜 스펨메일 유포지로? 이건 말도 안되는거 같다.
스펨메일 유포지로 쓴다는 것은  "나를 찾아주세요~" 밖에 안되는것이다. 나도 기억에 잊혀진 뒤 얼마전에 통화를 하다 갑자기 생각나서 그때 그 부분 해결한지 물어보니 SMTP AUTH Brute Force Attacks이였다고 한다. SMTP로그에 엄청나게 쌓여 있었다고, 그리고 해당 정책을 강하게 적용한 뒤에는 발생을 하지 않는다고 한다.
담당자의 문제인가? 웹메일 엔지니어의 문제인가? 아님 잘못 찍은 나의 문제인가? OWASP에서는 세션 예측이 언제나 상위 항목인데 웹에서만 발생되는게 아닌가 하는 생각도 들었고, 해당 방법으로 사고접수 된것도 본적도 없다. 실제로는 아는동생이 시현하는거 말고는 본적도 없으니 실제로 격어 보니 당황 스럽긴하다. 유저가 많으면 접속중인 세션도 많고 Brute Force Attacks도 잘 맞아 떨어지나 보다.

또 다른 하나의 사례는 여러가지 시스템 중 SSO를 잘못 구축한 경우다. SSO를 구축할려면 첫째 DB가 통합 되어야 된다. 다른 방법도 있지만 통합 DB로 구축하는게 편하다. 둘째 로그인을 하는 모든 시스템을 대상으로 해야된다. 셋째 통합 로그인으로 로그인을 하게 되어야 된다. 넷째 기존 로그인의 로직을 과감히 버러야 된다.

SSO솔루션을 구버전, 신버전으로 두개를 사용 한다던지, 통합이 어려워 얄팍한 기술을 사용하다가는 큰 사고로 발생되는 경우가 많다.

문제는 기존로그인을 과감히 버리지 못하는 점 A사이트에 개인정보가 10만이고 B사이트에 5만이라면 다수의 정보로 가야되고 B사이트 사용자중 A사이트에 없는분들은 재가입을 권고 해야 된다. 물론 그전에 중복 가입된 사람도 개인정보 동의를 받아서 기록을 남겨야 된다.

SSO를 구축해도 컨트롤이 안되면 정말 큰 사고가 발생될수도 있다. 관리자의 실수로 정말 통합하기 어려운 곳을 통합해 달라고 요청이 와서 업체에서 대충 Get Parameter로 ID값을 암호화하여 넘기던지 하면 정말 큰 사고가 발생된다.

구지 저렇게 한다면 SSO을 하는게 가장 좋게 그게 힘들다면 공용 DB를 만들어서 DB세션을 쓰는게 바람직하다.

실제로 침해사고로 발생되어 언론에 나온 사례도 있다. 데이타 조작이 되었고, 관련자들의 처벌을 원하지 않아서 처벌이 되지 않은 경우다.

침해사고를 분석하고 대응 할때 마다 느끼지만 사회 공학적인 해커의 심리적 유형도 파학해야 될 필요성도 느낀다. 발생 원인을 찾지 못한다고, 웹해킹의 경우 제로데이 공격이라고 생각 하지마라 리모트 제로데이 공격으로 침해사고가 발생된 경우는 난 한번도 본적이 없다.언제나 가장 기본적인 실수로 인해 뚫리는게 대부분이다. 이번 경우는 공격자가 해당 취약점으로 웹쉘을 업로드 한 뒤 탐지되어 대응 되었다. 탐지 패턴 기준으로 하면 총 3번의 기준이 있다.

[Apache Struts 공격 ->웹쉘 -> 유닉스 명령어] 으로 탐지가 가능하다. 사고가 발생 되는것 보다 어떻게 조치하고, 어떻게 대응 하는 것이 더욱 더 중요한부분이다. 가장 잘못 생각 하는것들 중 하나가 웹서버 만 해킹 당한거면 DB는 안전하다는 생각이다.Apache만 권한이 획득당한 경우만 그럴것이다. 하지만 그런 경우는 거의 없고 파일 업로드나 sqli도 그렇고 웹쉘은 WAS단에서 올라가고 처리된다. 서블릿 컨테이너라서 실제로 웹서버에 업로드가 된다고 해도

WAS단에서 그 명령어를 처리 한다. jdbc connection이나 was db pool을 이용해서 충분히 DB에 접근이 가능하다. 그래서 웹쉘이 업로드 되고 탐지를 못하고 시간이 지났다면 개인정보는 다 털렸다고 보는게 맞다.   

[그림 1-1]

공격 받은 대상은 앞단에 Apache를 두고, WAS는 Weblogic을 쓰는 환경이 였는데 해당 IPS에서 Apache Struts 관련 공격이 있었는것이 탐지 되었다.

[그림 1-2]

위 사진은 해당 공격에 대한 실제 탐지 코드다. 'action:', 'redirect:'같은 매개변수에서 특정 구문을

전달 하는 과정에서 입력값 검증을 하지 않아 발생 된다.

침해사고는 언제든지 발생될수 있다. 하지만 대응에 대한 부분이다. 원인을 빨리 분석해서 업로드 중인 웹쉘을 제거하고 해당 공격에 대한 패치를 해야되는 부분이고, 웹방화벽이나 IPS에 공격 패턴을 등록해서 탐지 및 차단을 하도록 해야된다. 시스템 상의 백도어나 커널 루트킷에 대한 부분도 점검을 하는것도 좋다. 인간은 완벽할수는 없다. 엄청나고 복잡한 시스템들을 어떻게 효율적으로 관리 해야될지에 대한 프로세스와 담당자의 역량이 가장 중요한 부분이다. 대형 포탈이나 사고가 발생한곳들도 보안담당자들이 못해서 그런것이 아니다.

언제나 100억치 솔루션보다는 1억치 실력있는 보안담당자가 낫고 그것 보다 실제 임직원의 보안 마인드를 개선하는것이 더욱 더 보안사고를 줄일수 있는 부분이다.