'분류 전체보기'에 해당되는 글 194건

개인정보 유출 점검에 적발 되어서 사건 하나가 이관되었다. 현장 점검을 나가게되었다. 대상은 실제 개발중인 홈페이지 였는데 모바일 홈페이지를 추가하는 과정에 실수를 범한 모양 있다. 유출된 시스템 IDC에서 다 개발을 진행중인데 실수로 홈페이지에 robots.txt도 없는 상황이고, C Class 대역대 IP를 외부에 오픈한 상황이였다.

만약 서버가 내부에 위치하고 와이파이로 접속을 하고 테스트를 하였다면 이런 문제가 발생되지 않았을 수도 있다.

과거 몇년 전에 ISMS인증 대상을 받은곳이기도 하였으나 그 후 관리가 되지 않았고, 담당자가 바뀌는 등 전문 지식이 좀 많이 미흡한 상태였다. 최초 디렉토리 나열이 발생되어 개인정보가 유출 사고가 발생 되었어도 제거해야될 indexs의 위치를 찾지를 못해 서비스를 중지 시켰다고 한다.

1시간 정도 통화와 설득 끝에 우리가 현장 점검을 나가기 전 취약점 점검을 해야되니 오픈을 해달라고 요청하였고, 디렉토리 나열이 조치가 아직 안된거를 알고 환경을 물어보니 윈도우 서버에 Apache를 구동중이라고 한다 그래서 VirtureHost쪽 계정별에서도 설정이 가능하니 찾아 보라고 했다. 그래서 조치를 완료 했는데 구글 캐쉬는 삭제 신청을 해놓았다고 한다. 본인들 담당하는 입장에서는 굉장히 억울할수도 있겠고, 어설프게 알고 진행한것이 가장 큰 문제점이다.

robots.txt도 충분히 디렉토리별 관리가 가능하고, 외부 유출된 첨부 파일을 모아둔 디렉토리도 필터기능이나 아니면 세션관리를 통해 개별적인 세션이 없으면 접근을 못하게 하였어야 한다.

그리고 또 하나 놀라웠던 사실이 대표홈페이지에 sql injection이 있었는데 ISMS인증 심사시에도 발견 되었는데 발견된 부분만 조치하고, 특수문자만 필터링 하였다고 한다. 근본적인 해결법인 PreparedStatement를 사용하지 않고 땜빵적으로 조치한것도 가장 크다.

그리고 신규 오픈한 홈페이지에 대해서 워드프레스를 사용중인것에 대해 플러그인들에 대한 취약점 점검을 실사 하라고 하였다. 그리고 얼마 후 이행점검을 위해 둘러 보는중 robots.txt는 홍보를 위해서 계속 사용해야 된다고 한다. 디렉토리 별로 권한 설정이 가능하다고 하여도 별로 고칠 생각이 없나 보다.

linux kernal.pptx

bandicam 2015-04-28 14-33-08-040.zip

학교 과제로 한것 인데 쓸대 없는 부분이 너무 많이 추가 된거 같다.

몇달 전 전산담당자로 부터 자문을 구해온적이 있었다. 메일 서버가 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억치 실력있는 보안담당자가 낫고 그것 보다 실제 임직원의 보안 마인드를 개선하는것이 더욱 더 보안사고를 줄일수 있는 부분이다.