Apache Struts 취약점

침해사고를 분석하고 대응 할때 마다 느끼지만 사회 공학적인 해커의 심리적 유형도 파학해야 될 필요성도 느낀다. 발생 원인을 찾지 못한다고, 웹해킹의 경우 제로데이 공격이라고 생각 하지마라 리모트 제로데이 공격으로 침해사고가 발생된 경우는 난 한번도 본적이 없다.언제나 가장 기본적인 실수로 인해 뚫리는게 대부분이다. 이번 경우는 공격자가 해당 취약점으로 웹쉘을 업로드 한 뒤 탐지되어 대응 되었다. 탐지 패턴 기준으로 하면 총 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억치 실력있는 보안담당자가 낫고 그것 보다 실제 임직원의 보안 마인드를 개선하는것이 더욱 더 보안사고를 줄일수 있는 부분이다.