바나나맛 페이로드

차세대 보안리더 양성 프로그램 BoB(Best of the Best)

멘토의 변이 아닌 변(?)

안녕하세요 차세대 보안리더 양성프로그램의 심준보라고 합니다.

차세대보안리더 양성프로그램 Best of the Best(이하 BoB)는 미래창조과학부의 

지원에 힘입어 한국정보기술연구원(KITRI)가 주관하는 인력양성 프로그램입니다.

현재 4기 모집 평가가 한창인 가운데

작년 BoB 프로그램 모집시에 BoB 정구홍 멘토님의 글처럼 멋있는 글은

(http://hackerschool.org/Sub_Html/HS_Posting/?uid=44)  

쓰기 어려운 것 같아서 다른 형태로 잠시나마 시간을 내어 남겨봅니다.

이 글은 BoB 프로그램을 처음부터 같이한 멘토의 입장에서 쓰는 글이지

어디까지나 미래부나 KITRI의 공식적인 답변이 아님을 미리 밝혀둡니다.

이 글은 SNS를 통한 한 지인분의 궁금증으로 부터 시작했습니다.

BoB 프로그램이 국민들의 세금으로 운영되는 것이기에,

많은 분들이 격려도 해주시지만, 많은 궁금증을 유발하고 

비판도 많이 해주시고 있습니다.

걱정하시는 마음 너무도 잘 알기에

이에 대해 비공식적(?)으로 잠시나마 답변을 해 봅니다.

많은 분들이 궁금해 하시는 내용을 간단히 정리해 보았습니다.

1. 국민들의 세금으로 운영되는데 성과가 뭐냐?

- BoB는 2015년 현재 4기 모집중에 있습니다. BoB는 1, 2, 3기를 통틀어 

300여명의 수료생을 배출하였습니다. 평균적으로 BoB는 모든 교육에 따른 

제반사항이 모두 세금으로 지급되기에 각 학생들은 천만원에서 3천만원정도의 

혜택을 보는 셈입니다.

BoB는 한 기수에 8개월정도의 교육, 프로젝트 등을 진행하게 되고, 이를 통해 

수료생을 배출하고 있습니다. 

그러나 이미 수료한 1, 2, 3기들이 어떤 성과를 내고 어떤 일을 하고 있는지 

보이지 않아 많은 분들이 걱정하고 있는 것으로 알고 있습니다.

-  BoB 1기는 2012년 시작하였습니다. 이 때 교육생들의

평균 나이는 21 ~ 23세 정도였습니다. 고등학생도 다수 있었으며, 2015년 현재 

이 학생들은 거의 대부분 대학교에 다니고 있거나 대학원, 유학 등의 길을 선택하였습니다.

가시적인 성과에 취업률을 빼놓고 이야기 할 수 없다는 의견이 많은 것으로 알고 

있습니다만, BoB는 취업에 대한 연계 프로그램도 아니거니와 그 특성상 교육생들이

자신의 부족함을 깨닫고 학업을 더 하려는 의견이 매우 많은 것으로 나타납니다.

- 그러나 국민들의 세금으로 운영되기에 정량적 결과 역시 매우 중요합니다. 

과연 올바르게 세금이 잘 사용되고 있는지를 단지 정성적 결과를 그럴싸하게 포장한

모습이 되지 않도록 지금도 여러모로 노력하고 있습니다.

다만, 이러한 행동들이 BoB학생들에게 실적위주의 교육이 되지 않고, 스스로 자신의

길을 선택할 수 있도록 하는 대전제를 해치면 안된다는 생각이 기본인 것은 변하지 

않아야 한다고 생각하고 있습니다.

- 우리는 8개월의 교육으로 그들이 전문가가 될 것이라는 생각도 하지 않으며,

모두가 만족하는 교육이 될 것이라고도 생각하지 않습니다. 

단지 그들이 보안이라는 큰 항해를 하는 동안 어디로 가야하는지를 알려줄 수 있는

등대를 만나고 같이 항해를 할 수 있는 친구들을 만나는 것이 이 사업의 가장 큰

핵심이자 우리가 해줄 수 있는 가장 큰 역할이라고 생각하고 있습니다.

- BoB는 3년동안의 수료생들을 통해 140여건의 국내외 취약점을 무료로 조치하는데

큰 공을 세웠으며, 국내 주요 기반망의 취약점을 컨설팅하고, 영세한 기업들에게

컨설팅을 제공하여 보안 의식을 고취시키고, 수많은 국내외 학술대회 및 

해킹/방어대회에서 우수한 성적으로 입상하고 있습니다. 다만 앞에서 설명한 많은

이유로 인해 취업을 하는 학생은 현저히 적은 상황입니다.

- 이 학생들이 자라서 자신이 이룬 가장 큰 성과는 BoB를 할 때 이룬 것이다 라는

말을 듣고자 하는 것이 아니라 자신이 이룬 가장 큰 성과는 BoB의 토대가 있었기

때문이다 라는 말을 듣고자 함입니다.

2. 선발 기준이 모호하고 이해할 수가 없다

- BoB는 3기를 기준으로 한 기수에 약 천여명의 지원자들이 있습니다. 평균적으로

합격에 대한 경쟁률은 5:1 에서 7:1정도가 됩니다. 모든 학생들을 평가하는데 매우

어려움이 따릅니다. 4기 모집이 한창인 어제도 멘토들과 오피스 직원분들은 각자

생업의 업무를 마치고 피곤한 몸을 이끌고서라도 넥타이를 풀어헤치고 한명의 서류라도

더 보려고 노력했습니다. 각자의 평가가 불균형하게 이뤄질까봐 평가기준을 명확히

세우고 이를 공유하며 서류 평가를 무사히 마쳤습니다.

개인적으로 저만해도 약 150여명의 서류를 읽었으며 평가를 마쳤습니다. 

우리가 평가를 할때 가장 많이 이야기 했던 것은 서로의 기준이 다를까봐 이야기한

"난 이정도면 이 점수를 줄 수 있다고 생각한다. 여러분은 어떠십니까?"에 대한 

이야기 였습니다. 

물론 더욱 좋은 평가 방안을 생각하기 위해 매 기수마다 수많은 회의를 거치고,

밤새 멘토들끼리 워크샵을 진행하기도 합니다. 

- 다만 우리나라는 토익시험에도 유형을 만들고 영어 한마디 못해도 만점을 받는 

나라입니다. 공개한 평가 기준이 싸구려 입시경쟁을 유도할 우려에 의해 기준은

공개하지 않는 것을 아직까지는 원칙으로 하고 있습니다. 다만 평가 점수에 대한 것은

지원자가 요청할 시에는 자신의 점수만을 공개하는 것을 원칙으로 하고 있습니다.

- 또한, BoB는 선발에 있어서 필기시험 및 기술면접도 진행하고 있습니다.

최대한 많은 학생을 만나고 공정하게 평가하기 위해 생업도 포기하고 주말도 포기하고

가족도 포기하고 불철주야 노력하고 있습니다. 더 좋은 선발이 될 수 있도록 많은

노력을 기울이겠습니다.

3. 정보보호 교육 시장에 악영향을 미친다.

- 정보보호 교육 시장은 보안전문가가 유망직종으로 떠오르면서 많은 관심을 갖기 

시작했습니다. 그런데 사실 정보보호시장은 산업구조를 살펴보면 필요한 인력은 많은데

그만큼의 이윤을 내지 못하고 있는 실정입니다. 

이는 산업구조가 약한 국내 소프트웨어 및 기술력 기반 산업의 구조적 문제를 해결하기

위해 정부가 뛰어들어 시장을 저해하고 있다는 우려에서 시작한 내용입니다.

- 대한민국은 자유경제의 나라이고 시장에서의 자율경쟁이 경제의 근간을 이뤄야하는

나라입니다. 그런데 정보보호의 우수한 인력을 국가가 나서서 교육을 하고 이에 대한

시장성을 말살한다는 우려는 충분히 공감이 가는 내용입니다.

- 다만, 정직한 정보보호 교육 시장을 형성하려는 움직임 대신에 최근에 일부 몰지각한

행태를 보이는 정보보호 교육기관들의 아우성에 BoB는 대답할 의무가 없다고 생각합니다.

- BoB는 이러한 교육시장 형성에 불씨를 당기기 위한 프로그램입니다. 영원히 시장을

저해하고자 하는 목적이 아닌 단기간 시장에 악영향을 미치더라도 이 영향이 훗날 시장의

큰 향상을 위해 반드시 필요하다고 생각하는 부분입니다. 이는 보안의 중요성을 단지

취업이나 학업의 연장선으로 생각하지 않고 새로운 ICT세상을 살아갈 학생들의

더 큰 물을 위함입니다. 정보보호에 대한 산업구조를 강하게 만드는 것은 우리가 해야할

몫이 아니라 자라나는 이 친구들이 만들어갈 세상이라고 생각합니다. 

방아쇠가 없으면 포탄은 날아가지 않습니다.

끝으로 흔히들 어린아이를 키우는 것을 교육이라고 일컫습니다.

우리는 아이가 자라날 때 말을 하는 법을 알려주거나, 걷는 법을 알려주지 않습니다.

그저 아이가 스스로 자라날 수 있도록 옆에서 보살필 뿐입니다.

네트워크가 국가간의 경계를 허물고 SNS를 통해 퍼진 의견이 

여론을 넘어 누군가의 사상으로 자리 잡는 새로운 세상을

우리 세대는 겪어본적도 없고 어떤 세상이 될지 알 수도 없습니다.

BoB는 새로운 세대들에게 무엇을 해야한다고 이야기할 수 없습니다.

우리는 그런 세상을 살아본적이 없기 때문입니다.

BoB 멘토로서 이렇게 변명아닌 변명을 하는 것은

프랙 매거진의 말을 인용하면, (http://phrack.org/issues/7/3.html)

"기껏해야 공무원들의 미친 실적싸움이나, 정신병자들의 헛짓거리, 

그것도 아니라면 관심에 목마른 불쌍한 정치인들의 싸구려 쇼가 되지 않도록 하는 것"

아직까지는 그렇게 변명하고자 합니다.

감사합니다.

2014년 2월 14일 발렌타인 데이이자 불타는 금요일이었던 날

오후 4시경에 수많은 금융 정보보호 담당자들과 우리나라 정보보호 담당자들은 매우 황당한 소리를 들었다.

그리고 야근이 결정되었다.

당연히 화가 났다. 

그렇지만 일단 마음을 추스리고 진상 확인에 나섰다.

이유는 이렇다

http://dailysecu.com/news_view.php?article_id=6211

대한민국 주식거래 시스템 해킹시연

당연히 예상한 결과였지만, 시연을 마치고 내려온 나는 많은 기자분들이 하시는

"잠시만, 얘기좀" 을 들을 수 있었다.

일단은 모두 거절했다.

왜냐하면 이제 정부 관계자 분의 "잠시만, 애기좀"을 들어야 하기 때문이다.

이럴경우 내 경험상 정부 관계자 분은 항상 똑같은 특징이 있었다.

1. 반드시 사람을 시켜서 나를 부른다. 직접 찾아오는 경우를 못 봤다.

2. 일단 나를 눈으로 위, 아래를 쭉 훑는다.

3. 절대 명함은 주지 않는다.

이때 상황은 위의 기사를 쓰신 기자분이 정확히 기억하고 계신다.

당연히 많은 언론보도가 나갔다.

http://news.mk.co.kr/newsRead.php?sc=30000001&year=2014&no=242706&sID=

http://www.boannews.com/media/view.asp?idx=39810&kind=1

http://www.ajunews.com/view/20140214162506899

사실상 언론보도의 기사를 내가 써주지 않는한, 아니 내가 쓴다고 해도 정확하게 보도되는 경우는 없다.

반드시 잘못 전달되는 부분이 있다.

사실, 이 취약점을 알게된 계기는 내가 프리랜서를 하기전 업체에서 근무할 때 였다.

엄청 큰 취약점이 있길래 업무중 하나이기도 하고 말해줬다.

취약점이 없도록 해결해 달라길래 해결 방법을 이야기 해주었다.

그리고 몇년 뒤, 다시 확인해보니 그대로 였다.

다시 이야기를 해보니 내 이야기를 잘못 이해하고 전혀 상관없는 부분의 취약점이 제거되었다.

따라서, 다시 말해줬다. 이 때 나는 돈을 벌기 위해 아르바이트를 수도 없이 하고 있을 때다.

물론, 한푼도 받지 않았다. 한 증권사는 고맙다고 명절 선물세트를 주었다.

BoB 프로그램을 진행하면서 강의를 하던 도중 예전에 있었던 이 사건이 생각났다.

당연히 다시 조사해봤다. 여러부분이 막혀있었는데 그 중에 황당하게도 아직 해결 안된 부분이 있었다.

특이하게도 이 증권사는 프로그램이 두개 존재했는데, 그 중에 예전에 쓰던 프로그램을 좋아하는 고객을 위해

예전 버전의 프로그램을 다운로드해서 사용할 수 있게 해 주었다.

왠지 모르게 화가 났다.

그 때 우리 회사 사무실에는 2명의 다른 기관 사람들이 업무상 파견 나와 있을 때였다.

사정을 이야기 하고 하루 동안 14개 증권사의 프로그램을 받아서 기법이 통하는지 안통하면 어떻게 막았는지

가장 중요한 "올바른 인증"을 사용하고 있는지를 검사했다. 계좌도 없이 말이다.

예상했지만, 결과는 역시나 였다.

순간, 잘 알고있는 평소에 친하게 지내고 있는 우리나라 보안을 책임지고 있는 친구들의 얼굴이 

주마등 처럼 지나간다. 

죄없이 보고서 쓰고 있는 친구들.

한번의 실수로 가족들의 얼굴을 떠올리고 있을 보안 담당자들.

곧 결혼할 여자친구와 데이트를 즐길 계획이었던 책임자들.

언제 다시 올지 모르는 휴가를 즐기고 있었던 담당자.

그런데 이상하게 억울했다.

"나"는 없었다.

사실 나는 얼마전 결혼했다.

이제 "나"를 생각할 시점인 것 같았다.

미안하다. 친구들.

시연이 있고나서 나는

이제는 두번째이자 가장 어려운 난이도를 가지고 있는 파도를 기다리고 있다.

바로 진짜 전문가라 칭하는 사람들의 의견.

보통 이런 전문가 집단은 자신의 고집이 있다.

당연히 전문가는 자신의 고집이 있어야만 한다.

사실 이번 사태에서 가장 고생하는 사람들이다. 나는 별로 한게 없다.

이 친구는 엄청난 기간동안 "여자친구 없이" 대한민국 보안을 위해 한국인터넷진흥원에서 일했다.

휴가갔다가 불려나오신 연구원님

너무나 감사하게도 실제 금융권 담당자 분들의 매너있는 대응

실제로 시연에서 사용한 해당 증권사의 담당자 분의 전화를 받았다.

엄청 화가나고 당황스러우실텐데 매우 매너있게 대응해주셨다.

"어려우시더라도 재시연을 부탁드리고 정보를 부탁드립니다. 그에 상응하는 대가도 지불할 계획이 있습니다."

너무 목소리가 안좋으셔서, 그냥 말씀드렸다.

학계에서도 많이 응원해주셨다.

고려대학교 김휘강 교수님

성균관대 김형식 교수님

KAIST 김용대 교수님

시연이 끝나고 날아든 충남대 류재철 교수님으로부터 문자

"오늘 시연 굿!!"

물론 다른 반응도 많았다.

1. 대전제가 생략되어 있는 해킹이다 : 동영상을 자세히 보시길 바랍니다.

2. 그럴리가 없다. 사기다 : 동영상을 자세히 보시길 바랍니다.

3. 메모리 해킹으로 해킹 가능한 것은 이미 알고 있는 사실이다 : 동영상을 자세히 보시길 바랍니다.

4. 의견을 내세우려면 책임감이 있어야 한다. : 동영상을 자세히 보시길 바랍니다.

5. 왜 쓸데없이 위험을 내세워서 국민들의 불안심리를 조장하는가 ? : 동영상을 자세히 보시길 바랍니다.

나는 해커이다.

그것도 잔뼈가 굵은

취약점이 무엇인지 알고 있는 해커이다.

얼토당토하지도 않은 이야기를 하는 것이 아니다.

그래서 예전에 그런 이야기를 했다.

항상 그렇게 이야기를 한다.

그런데 정말 중요한 것은 100%의 보안은 없다는 것이다.

취약점은 반드시 존재한다. 다만 내가 모를 뿐이다.

시스템을 만든사람이 그 시스템의 취약점을 모두 안다면

해킹사고가 왜 발생하겠는가

취약점은 다른 사람이 더 잘 찾게된다.

자신이 묶어놓은 매듭을 다른 사람은 다른 방식으로 풀지도 모른다.

10번 취약점 점검을 위해 모의해킹을 하면

10번 모두다 다른 취약점이 나온다.

심지어 100번을 해도 그럴 가능성이 매우 높다.

그래도 아직 우리는 안일하다.

그래도 자리에 앉아 웃기는 소리 하지 말라고 하면서

대한민국 사이버 안보 불감증이 웃기는 소리라고 헛소리를 해댈텐가

사실 이 모든 것이 먹고 살기 위해 해킹으로 사기를 치며

영업을 해온 일부 몰지각한 보안회사들 탓이라고 해도

이제는 바꿔야겠다고 생각했다.

그야말로 해킹을 "시연"했을 뿐이니까 오히려 다행이라고 생각해주길 바랄 뿐이다.

정말 용기가 있었던 것은 무슨 일을 할지 뻔히 알고도

자신들의 계좌를 빌려준 정현일군과 박찬규군이다.

또, 이 행사를 준비하고 계획해준 강승현 과장님, 센터장님, 두 원장님들 

그리고  best of the best 센터 직원 분들과 학생들

시연을 같이 준비해준 성원이

모두 "나"를 위해 희생해 주었다.

나는 오늘도 취약점을 찾는다.

취약점을 찾는건 나에게 숨을 쉬는 것이랑 별반 다를것이 없다.

돈을 벌기위해, 재미를 위해, 시간이 남아서, 자기 만족 때문에 하는 것이 아니라

이제 그 이유도 불분명할 정도로 그냥 하고 있다.

이제 이 글을

해킹 시연시에는 아무도 신경쓰지 않았던

시연 발표자료의 처음 제목과 함께 끝내려고 한다.

더이상 이와 관련한 일은 말을 아끼도록 하겠다.

 " Beyond Security"

우리는 시큐리티를 넘어 다른 곳을 향하고 있다.

많이 어플리케이션이 보안을 위해 SSL통신을 수행하고있으며, 연구나 다른 목적을 위해 SSL패킷을 스트립해야하는 경우가 생깁니다. (저는 제일 처음 모바일 게임쪽을 분석하기위해 이를 수행하였습니다.)

이를 위해 일반적으로 PC 환경에서는 SSL 스트립을 위해 MITM(Man In The Middle)을 수행합니다.

하지만 모바일 환경에서는 MITM이 쉽게 수행되지 않습니다.

가장 큰 이유는 윈도우에서도 CA체크가 되지않은 인증서의 경우 경고창이 뜨고 클릭해야 실행할 수 있듯이, 모바일에서도 CA체크를 합니다. 그리고 대부분에 SSL을 사용하는 어플리케이션에서는 CA체크에 대해서 호락호락하게 넘어가주지 않습니다. (하지만 다 할수있는 방법은 있습니다. Mitm을 수행할 필요가 있으신분은 Kandroid에서 GMS 를 분석한 자료를 보면 참고하면 됩니다. )

하지만 특정 어플에서 발생하는 SSL 트래픽을 구분하기도 힘들뿐더러, 환경을 구성하기도 번거럽습니다..

그래서 본 포스팅에서는 좀 더 쉽게(?) SSL 스트립을 할 수 있는 방법을 제시합니다. 모두가 아는방식일거고 이미 쓰는사람도 많을겁니다.

안드로이드는 SSL 통신을 위해 내부적으로 openssl 을 사용합니다.

그리고 SSL_read, SSL_write 함수를 통해 데이터 송수신을 수행합니다.

즉, SSL_read 함수와 SSL_write 함수를 후킹해서 송수신 전, 후의 데이터를 가져온다면, 인증서 생성 환경구성등의 번거러운거 없이 SSL 스트립을 수행할 수 있습니다. (이게 더 번거러울지도 모름....)

SSL_read, SSL_write 의 데이터를 가져오기 위해서는 후킹을 통해 두 함수의 기능에 로깅을 추가하면 되며, 쉽게 2가지 방법을 선택할 수 있습니다.

1) 프레임워크 소스코드를 받아 로깅기능을 추가한 libssl.so 를 재 컴파일해서 교체하면 손쉽게 로깅을 수행 할 수 있습니다. 하지만 이경우 어플에 대한 예외처리를 하지 않을경우 시스템에서 SSL 을 사용할 경우 모두 로깅이 되기 때문에 엄청난 데이터가 축적됩나다.

2) 두번째 방법으로는 고전적으로 많이 사용되던 lnline 후킹을 통해 함수에 전달되는 데이터를 추출할 수 있습니다. 특정 프로세스 메모리에 존재하는 SSL_read 함수와 SSL_write 함수를 패치하여 인자 및 수행결과를 추출할 수 있습니다. (비슷한 연구로는 collin님이 발표한 Dynamic Binary Instrumentation on Android 이 있었고, 물론 발표에 사용된 도구 모두 제공됩니다. 하지만 코어 라이브러리에 대한 후킹이 재대로 수행되지 않습니다. 이유는 따로 설명하지 않겠습니다. 그래서 저는 안드로이드 환경에서 동작하는 lnline 후킹 도구를 재 설계해 개발하였습니다.)

위 방법을 통하면 그림과 같이 손쉽게 SSL 스트립이 가능해집니다. 

아래 사진은 2번에 제시한 방법으로 inline 후킹도구를 개발하여 페이스북 어플의 SSL 통신을 스트립한 결과로 Logcat으로 로깅을 수행하였습니다.

키사측 요청으로 상세 내용은 생략합니다.

바나나팀의 막내(?) EXSO 입니다.

KISA 에선 10월부터 KISA에서 신규 취약점 포상제를 운영하고 있습니다.

포상은 분기별로 이루어지며, 취약점에 대해서 포상 단위는 개별 신고건입니다.

하지만 많은 주변 사람들이 KISA의 취약점 보상제도에 대해 아직 신뢰하지 못한 분들이 많은데 참고하시라고, 신고한 내용에 대한 결과에 대해 그대로 올리겠습니다. 긍정적인지와 부정적인지의 평가는 개인이 내려주시면 되겠습니다.

일단 제 의견은 매우 만족스러운 제도라고 생각합니다. 국내 취약점 연구에 대한 보상 자체를 국가해서 해준다는 자체가 긍정적이며, 꽤 전문적인 평가를 한다는 점과, 크게 인정받지 못하던 국내 소프트웨어 취약점에 대해 상당히 높은 보상을 해준다는 점입니다.

저같은 경우 한컴오피스 2010 파일 포멧을 이용한 code execution 취약점에 대해 신고를 했었으며 평가는 다음과 같은 식으로 이루어 집니다.

금액은 키사측에서 공지한대로 최고 500만원까지의 포상이 이루어진다고 합니다. 

또한, 보안 신고자의 credit 을 다음과 같이 게시해 줍니다. 
http://www.krcert.or.kr/kor/data/secNoticeView.jsp?p_bulletin_writing_sequence=1683
버그헌팅 분야는 공부를 시작한지 얼마 되지않아 이런거 올려주면 기분좋습니다.ㅋㅋㅋㅋ

국내 소프트웨어 취약점 연구하시는 분들은 썩혀두지 마시고 신고하셔서 국내 보안에 기여하시고, 또한 재정에 보탬이 되시기 바라면서 포스팅합니다.

일반적으로 프로그램의 버그를 찾는데 있어서 많은 사람들이 사용하는 것이

막 찾아주는(?) 더미 퍼징( dummy fuzzing ) 이다.

간단하게 인터넷에서 구할 수 있는 자료들만으로도 생각보다 괜찮은 효율로

버그들을 찾아낼 수 있으며, 그로 인한 공격가능한 상황을 만들 수도 있다.

이러한 퍼징을 통한 버그 찾는 방법들은 보통 디버거나 모니터링해주는 프로세스가

대상 프로그램의 익셉션 상황을 잡아내서 로그를 남겨주는 것이 보통의 구조인데,

이러한 더미퍼징으로 찾는 대부분의 크래쉬는 보통 메모리 커럽션을 발생시키게 된다.

이 때 이런 익셉션의 상황을 종합해서 이것이 어떤 버그인지를 분류한다.

이는 보통 크게 6가지로 나뉜다.

1) Read Access Violation Near NULL

2) Read Access Violation Not Near NULL

3) Write Access Violation Near NULL

4) Write Acesss Violation Not Near NULL

5) Invalid Instruction Pointer

6) Unknown

이런 분류는 크게 Access Violation이 어떤 상황에서 일어났는지가 중요한 기준으로

사용되는데, 그때 사용되는 또 다른 중요한 기준이  NULL 근처인가 아닌가하는 기준이다.

NULL 포인터 근처에서 Access Violation이 일어난 경우와 그렇지 않은 경우를

구분하는 이유는 NULL포인터가 아닌경우에 일어나는 Access Violation의 경우

보통 익셉션이 일어나는 주소를 변경할 수 있는 경우가 많기 때문이다.

또한, NULL 포인터 근처가 아닌곳에서 일어나는 Access Violation이 할당할 수 있는 

메모리인 경우에도 역시 공격할 수 있는 형태의 버그가 되어 

일반적으로 NULL 근처가 아닌경우의 Access Violation을 선호하는 경향이 크다.

(라고 일반적으로 생각하지만, 결국 그렇지는 않다 -_-)

그렇지만, Access Violation이 일어나는 곳이 NULL 근처이거나 아니거나 이와는 상관없이

이러한 크래쉬들은 모두 공격시에 도움이 많이 된다.

NULL 포인터 근처에서의 Access Violation의 경우는 일반적으로 원격에서 공격을 하여

로컬권한의 쉘을 얻거나, 원하는 악성코드를 설치하는 경우보다는 

로컬에서의 권한상승을 위해 사용되는 경우가 매우 많다.

대표적으로 알고있는 유명한 Exploit이 Linux의 sendpage() exploit이다.

sendpage() exploit은 Linux system call 인 sendpage() 함수내에서 발생되는

NULL 포인터 익셉션에 기반하고 있다. 

sendpage() 함수안에 예외처리를 하지 않음으로서 함수포인터의 값이 NULL일때 

호출시킴으로서 커널 권한상승을 꾀하는 것이다.

이러한 NULL 포인터 예외는 커널에서 일어날 경우 그 위험성이 대단히 크게 작용한다.

따라서 대부분의 운영체제에서 NULL 포인터 근처에 메모리 할당을 강제적으로 막고 있다.

그동안 윈도우즈 운영체제 역시 NULL 포인터에 메모리를 할당하기 어려운 것으로 알려져 

왔는데, 우연히 들린 jz님의 블로그에서 다음과 같이 윈도우즈 NULL page를 할당하는 

방법을 확인할 수 있었다.

http://jz.pe.kr/63

요약하자면, 32비트 운영체제의 경우 0xFFFFFFFF 부터 메모리를 할당시켜 0x1000 

바이트를 할당하게 되면, 순환구조로 0x00000000의 메모리의 값이 할당된다는 것이다. 

일반적으로 Windows 운영체제의 .sys 파일은 매우 퍼징하기 쉽다.

이는 IOCTL계열의 함수를 통해 각 인터페이스 함수들을 퍼징해주면 되는데, 

vmware와 같은 가상화 프로그램과 이를 windbg에 물려서 사용한다면,

초보자라도 대단히 쉽게 Windows 커널 퍼저를 구성할 수 있다.

이를 통해 백신이라던가, driver를 사용하는 디바이스 프로그램들을 퍼징한다면

NULL 포인터 근처의 Access Violation을 얻어낼 수 있을 것이다.

그렇다면 우리는 보통 다음과 같은 형태의 공격코드를 작성할 수 있다.

1. NULL page를 할당한다

2. 필요한 값들을 NULL page에 넣어준다.

3. NULL 포인터 근처의 Access Violation을 얻을 수 있는 sys파일의 인터페이스 함수를 호출한다.

4. 커널에서 호출된 sys파일의 인터페이스 함수는 커널권한으로 NULL page에 접근하게 된다.

5. 커널 권한을 얻어낼 수 있다.

최근 국내에도 제로데이를 찾고자 하는 노력들이 많이 보이고 있다.

대부분의 연구하는 해커들이 잘 찾고 있지만, 

혹여나 안일한 마음으로 아 이런 크래쉬는 공격할 수 없을것 같아 라고 생각한다면,

그동안 알고 있던 NULL page 할당을 생각해 봤으면 좋겠다.

안전한 크래쉬는 없다.

물론 모든 프로그램의 버그가 크래쉬로 연결되는 것은 아니고,

모든 크래쉬가 공격가능한 것은 아니다.

그렇지만 언제나 생각지 못한 공격방법은 있는 것이다.

그리고 취약점을 찾는 과정도 매우 중요하지만,

공격방법을 찾아내는 과정 역시 매우 중요하다.

다른 해커들이 만들어내지 못하는 공격방식을 찾아내는 즐거움

NULL page를 할당하는 저런 기발한 생각들이

우리 해커들을 움직이게 하는것이 아닐까