안녕하세요. 마지막. 포스팅을 이후로 1년 6개월가량 지난 시점에 다시 회고록을 작성하려 방문했습니다.

이전의 회고록과 마찬가지로 제 글을 읽어보시는 분들이 긍정적으로 영향을 받고, 방황하지 않고 많은 시간을 허비하지 않는 데에

도움이 될 수 있었으면 하는 바람입니다. ㅎㅎ :)

 

저는 지금 대학교를 졸업한 뒤 1년하고도 약간의 시간이 흐른 시점입니다.

취업을 목표로 공부하다 보니 아무래도 필요한 역량이 무엇인지 점검해 보는 시간이 필요했는데요.

이를 위해서는 다른 사람들의 지표나 포트폴리오를 확인해 보며 알고리즘 역량이 키워야 한다고 생각하게 되었습니다.

우리가 직면하는 문제를 식별하고 이를 프로그래밍을 통해 코드로 녹여낼 수 있는 능력은 연차를 쌓아갈수록 더욱 필요한 역량이라는

생각이 드는데요. 이를 알고리즘이라고 분류하며 여기에 많은 시간을 투자하기도 합니다.

 

메타인지 향상을 위한 노력!

우리가 알고리즘을 통해 문제를 해결한다는 것은 크게 세 가지로 분류할 수 있습니다. 

먼저, 문제를 인식하고 우리가 생각할 수 있는 컴퓨터적 사고에 맞춰 문제 내용을 바꿀 수 있는 직관과 사고력이 필요합니다.

다음으로 필요한 데이터가 무엇인지? 어떤 자료구조를 이용해 데이터를 어떻게 전처리해 둘 필요가 있는지 고민해 보아야 하고요

마지막으로 문제를 해결해 내기 위해 시간 / 공간 복잡도를 계산하며 최적화 방법을 고민해야 합니다.

 

일련의 과정을 거쳐 우리는 소스코드로 작성해 낼 수 있습니다. 그러나 알고리즘을 공부하는 우리는 이 외에도 더욱 많은 부분을

고민하게 됩니다. 특히 구글링, 알고리즘 서적을 찾아보며 꼼꼼하게 검토해 본 뒤 코드를 작성하는 것은 많은 시간과 인내가 필요한 만큼

개인적인 내적 성장이나 가치관에도 영향을 끼치게 되는데요. 무엇보다도 자신에게 필요한 정보가 무엇인지 고민해 보고

정확하게 이해하려는 노력이 필요하다는 점이죠. 이렇듯 알고리즘은 시간을 내어 공부해야 하는 필수적인 관문이라 생각이 듭니다.

 

목표를 세워보자.

이제 오랜 시간을 투자해 알고리즘을 공부해야 하는데, 제 목표는 무엇이었을까요?

사실 저는 코딩테스트를 위해 알고리즘에 시간을 할애하며 공부를 시작해서 막연한 목표가 없었습니다. 단순히 기업의 코딩테스트를 통과하

기 위해 코딩테스트에 포함되는 알고리즘의 전반적인 내용을 공부하고 응시하는 것을 목표로 세웠죠. 

이는 ‘딩 테스트를 위한 알고리즘 공부법’ 이라는 서적 제목이 나타내듯이 빠르게 취업한 뒤 역량을 더 쌓아나가는 게 옳은 방법이라는

사회적인 인식이 제 견해에 영향을 끼쳤을지 모르겠습니다.  (해당 서적을 비판하려는 것은 아닙니다..)

 

우리는 검색을 통해 코딩테스트에 대비하기 위해서 어떤 목표를 세워야 하는지 검색해 보면

실버, 골드 정도의 문제를 해결할 수 있으면 된다.

라는  게시글을 심심찮게 확인할 수 있습니다. 그러나 상당히 오랜 시간을 공부에 할애해야 한다는 점과 문제를 풀이하기 위한

사고력이나 프로그래밍 코드로 녹여낼 수 있는 구현력 등의 역량을 쌓으며 알고리즘을 공부하는 것은 단순히 문제를 푸는 것만으로는

달성하기 어렵다고 생각합니다. 그래서 공부 과정에서 개인적인 상태를 점검하고 목표를 다시 잡으며 지금까지 공부할 수 있었는데요.

  • 프로그래머스 2, 3레벨을 모두 풀어보기 - 코딩 테스트 대비하기 - 벡준 다이아 달성해보기

라는 과정으로 목표를 점점 키워왔던 것이져! 헤헤~

 

이 과정에서 코딩 테스트에 포함되는 알고리즘을 검토하고 모두가 입을 모아 칭찬하는 종만북 서적도 읽어보며 고급 알고리즘 기법과 응용

을 공부했습니다. 벡준과 프로그래머스, SWEA 플랫폼을 이용해 대략 700 문제가량 풀이해 보며 목표에 도달할 수 있었네요.

 

조급하지 않은 마음으로 꾸준하고 성실하게..

이제 목표를 세운 시점에서 이러한 성취에 도달하는 과정에서는 역경이 존재하는데요.

알고리즘을 공부하기 위해 컴퓨터 앞에 앉는 것만으로도 소름이 끼치지만 외에도 다양한 부분을 인내하며 공부해야 합니다.

모든 사람이 그렇듯 과정에서 조바심이 생기게 된다거나 이해가 어려워 중도 포기를 끊임없이 고민하게 될 텐데요? ㅎㅎ

특히 알고리즘을 공부하는 점에서는 이러한 역경들이 더욱이 크게 다가오는 것 같습니다. 이는 몇 세기에 걸쳐 학자들이 고민하고 연구한 내

용을 단시간에 흡수하는 것은 그 자체로도 어렵고 굉장한 일이지만 알고리즘을 이용해 문제를 정확하게 해결할 수 있어야 한다는 점에서 더

욱 이러한 특징이 두드러집니다. 우리가 이해하기 어려운 지식을 습득하기 위해서는 다양한 자료를 참고하며 정확한 이해가 선행되지 않고

서는 이를 구현하기란 불가능에 가까운데요. 그러나 회고록의 전반부에서 언급했듯이 알고리즘 공부는 단순히 이해력만을 요구하는 것은 아

니기에 더욱더 많은 시간을 할애하며 고민해야 하죠!

 

이전의 저는 빠른 취업을 목표로 조급한 마음에 필요한 역량을 빠르게 채우려 노력해 왔는데요. (떳떳).. ! 

만약 그 시점으로 돌아가 벡준 다이아를 목표로 알고리즘 공부를 시작한다면 저는 중도 포기를 선언했을지 모릅니다. 알고리즘을 공부하며

메타인지를 키워가는 과정에서 자신의 현재 상태를 점검하고 성장을 위해 끊임없이 고민하며 목표를 수정해 왔기에 다이아를 달성할 수 있

었던 것 같습니다. 목표를 달성한 지금까지도 알고리즘은 막연하게 공부하기 어렵고 자신의 한계도 많이 느끼는 상황이지만, 그럼에도

지금까지 꾸준하게 공부하고 있다는 점과 이전과는 직면하는 상황에 대해 개인적인 견해가 달라졌다는 점에서 의미가 있을지도 모르겠네요.

확실히 꾸준하고 성실하게 공부하는 만큼, 또 많이 고민하는 만큼 이전과는 달라져 있는 제 모습을 볼 수 있는 것 또한 알고리즘의 매력이라

고 생각합니다. 물론 알고리즘에 무조건 시간을 투자해야 한다는 이야기는 아닙니다. 여러분이 생각하기에 필요성과 타당성이 충분하다면

고민해봐도 되겠지요? ( 저도 그렇다고 알고리즘으로 밥 먹고 살겠다는 이야기는 아닙니다.. 너무 괴로어 )

 

이 글을 읽고 계시는 여러분은 어떤 상황에서 알고리즘을 다시 보게 될까요? 공부하는 상황이라면 후에 어떤 내적 성장을 이뤄낼 수 있을지

회고록이 여러분의 견해에 긍정적인 방향으로 영향을 끼칠 있었으면 좋겠습니다. 감사합니다.

대학교 학부생으로써 올해 정보보안학과를 졸업하고 지금까지 정보보안과 관련된 공부를 해왔습니다.

자연스레 자격증을 준비하거나 BoB 활동을 통해 CS 지식을 넓히고 다양한 경험을 해보면서 공격자 관점에서 insight를

넓힐 수 있었던 것 같습니다. 해수로는 4년 정도 공부를 해왔는데, 확실히 보안과 관련해서 연구직 혹은 시니어 연구원

으로 성정하기에는 개개인의 성향과 적성이 맞아야 한다는 것을 매번 느낍니다.

그래서 최근 연구 동향을 파악하며 개인적으로 느낀 바를 정리해보며 진로를 고민하는 후배들이 참고할만한 조언을

제공해보고 싶어 회고록을 작성해보게 되었습니다.

뛰어나진 않지만 먼저 공부를 시작한 선배로써 진로 결정에 도움이 되었으면 좋겠습니다. 다른 사람에게 참견할 상황은

아니지만요 ㅎㅎ.. 제 코가 석자랍니다.

 

꾸준하게 공부하기!

학부생으로써 보안 공부를 할 때, 우선 흥미 위주의 공부를 진행했던 것 같습니다. 노력한 대비 산출물이 보이는

프로젝트나 활동들은 더욱 성장하고 싶다는 동기부여 역할도 하니까요. 그러나, 학부생 수준에서 연구원으로

거듭나기 위해서는 다양한 능력과 기술스택이 뒷받침되어야 합니다. 이런 부분에서 탄탄한 CS 지식과 개발 능력은

성장에 부스트 역할을 할 수 있는 좋은 재료라는 생각이 듭니다.

 

보안과 개발은 별개인듯 보이지만 엄연히 보안에서도 개발이 필요한 부분이 있고, 개발을 못한다는 것은 성장하기

위한 발판을 없애버리는 것과 같습니다. 그러므로 공부를 하며 개발을 소홀히 해서는 성장할 수 없습니다. 틈틈히

제작된 오픈 소스를 분석해보며 개발에 대한 감을 기를 수 있도록 노력해야 합니다.

모든 사람들이 그렇듯이 프로그래밍과 관련해 특출난 재능이나 적성이 아닌 한, 프로그래밍 언어를 공부할 때는

지루함을 느끼며 포기와 도전을 반복한다고 합니다. 자료구조, 알고리즘 등 이론적으로 지루한 내용들.. 

막연히 공부할 때는 어디에 사용되는지도 모르지만 다른 사람들이 세워놓은 로드맵을 따라하며 어거지로 공부하는

방법들에는 한계가 있고, 꾸준히 지속할 동기부여도 되지 않습니다. 이러한 부분에서 저는 산출물이 가시적으로

나타나는 활동을 통해 흥미를 유지하며, 흥미가 떨어지는 공부를 병행해 왔습니다. 이러한 공부법이 좋은

접근이라고 장담할 수 없지만 꾸준하게 연구할 수 있는 원동력을 마련한다는 점에서 괜찮은 접근 방법이라고 생각합니다.

짧게 정리하면 탑 다운 방식의 공부법으로 흥미를 유지하되, 바텀 탑 방식으로 CS 지식을 넓혀가는 느낌이라고 보면

될 것 같습니다.

 

 

다양한 관점에서 바라보기!

이전에는 단순히 오디팅, 소프트웨어 테스팅 기술을 통해 분석하고 취약점을 찾았다면 program analysis 학문을 접하고

최근 연구 동향을 파악하며 현업에서 어떻게 활용할 수 있을지 고민해보는 시간을 가졌습니다.

이전과는 다르게 취약점 분석 시에도 자동화 도구 및 새로운 트랜드 기술이 연구되며 개개인의 분석 노하우로도

쓰이는 만큼 단순히 어플리케이션 분석에 그치는 것이 아닌 다양한 접근법을 생각할 수 있도록 관점을 바꾸어야 하지

않을까요? 과연 취약점을 찾을 때 매번 오디팅, 소프트웨어 테스팅으로만 접근해야 할까요?

 

취약점 분석 업무의 예로 오펜시브 시큐리티가 존재합니다. 취약점을 발굴해 찾으면 성공 아니면 실패라는 점에서

오펜시브 시큐리티는 제대로 된 비즈니스 모델이 아닐 수 있습니다. 그래서 오펜시브에 종사하는 사람이라면

비즈니스 모델을 보완할 수 있도록 기술스택을 마련해 다른 비즈니스와 차별화 둘 수 있는 방안을 생각해보아야 합니다.

예를 들어, 단순히 바이너리를 분석하는 사람은 퍼징, static analysis 등 기술 스택을 가진 사람에 비해 소외될

수 밖에 없습니다. 수동으로 취약점에 일일히 접근한다는 것은 기계와 다름이 없으니까요.

그렇다고 정적, 동적 분석 접근법이 만능이라는 소리는 아니랍니다. 단지 해커의 관점에서

attack surface를 식별하고 접근하기 위한 개개인의 노하우와 경험과 더불어 방법론을 이용해 실무에 적용할 수 있다면

차별화된 경쟁력을 마련할 수 있을거란 이야기입니다. 또 그렇게 할 수 있도록 노력해야 합니다.

 

시스템 해킹의 미래?

개인적으로 시스템 해킹에 관심이 많은 만큼 시스템 해킹의 미래에 대해 생각해 봅시다. memory safety 언어인 rust를 예로

들어보면, 많은 제약사항이 존재하지만 C계열 언어에서 발생하는 취약점을 어느정도 방지하잖아요? 외에도 프로그램

컴파일 시 sanitizer와 같은 최적화를 이용한 보안 유틸리티들이 발전해 왔습니다.

브라우저, 커널에서는 다양한 mitigation이 존재하며 연구원들이 익스를 하는데에 어려움을 겪고 있습니다. 컴파일러

기준으로 봤을 때도 보안 기법이 적용되어 사실 상 입문자가 시스템 해킹을 공부하기에는 많은 어려움과 진입장벽이

있을거라 생각이 듭니다. 이런 점에서 '시스템 해킹의 미래가 없다'라고 봐도 과장이 아닐 수 있습니다.

그렇기에 시스템 해킹을 좋아해서 하는 경우가 대다수지만요. 이런 점에서 오펜시브나 모의해킹과 관련해서는

부업과 같은 느낌으로 버그 바운티 제도에 참여하는 것이 좋은 방법일 수 있습니다. 아니면 시스템 해킹과 관련된

연구 주제를 선정해 진행해보는 것도 좋은 방법일 수 있습니다. 오펜시브를 업으로 하는 분들의 경우,

꾸준하게 연구하며 그 분야의 탑이라고 봐도 무방할 정도의 실력을 가지고 있으므로, 어중간한 마음가짐으로 모의해킹

분야에 임하는 것은 좋은 방향이 아닐 수 있다는 생각이 듭니다.

 

생각해보기..

LLVM 프로젝트의 경우 다양한 아키텍처를 컴파일하고 디스어셈블하며 프로그램을 정적으로 분석할 수 있도록

중간 언어(IR) 역할을 합니다. 모바일의 프레임워크에서도 다양한 아키텍처를 호완하기 위해 깊게 들어가면 IR 레벨의

언어가 존재하구요. 브라우저 역시 IR 개념이 존재합니다. V8이 동작하며 Turban을 사용할 때, 최적화 없이 사용 시에도

IR이 필요하구요. 이를 이용하면 어플리케이션을 다른 아키텍처로의 포팅 과정을 거쳐 시너지를 낸다거나 하는 방식으로

접근이 이뤄지고 있습니다. 그러나 이 역시 코드 패턴에 대한 예외가 존재해 인터프리터 혹은

최적화 관점에서 취약점이 존재하기도 합니다. (그래서 브라우저의 JIT 기술에 취약점이 발견되는 것 아닐까요?)

이처럼 연구 동향을 파악하면 다양한 연구 주제를 확인해볼 수 있고, 다른 사람들이 연구한 legacy를 바탕으로 좀 더

나은 결과를 도출하는 데에 성취감을 느낄 수 있습니다. 이처럼 취약점 분석을 목표로 하는 사람이라면 단순히

서비스의 취약점 발굴만이 목표가 아닌 틀을 넓혀 여러 관점에서 보안을 바라볼 수 있도록 노력해야 합니다.

그렇다고 컴퓨터를 붙잡고 IT속에 박혀 살라는 이야기는 아닙니당. ㅎㅎ

 

결론

지금까지 공부해오며 느낀바를 두서없이 정리해보았는데, 읽는 분에게 어떻게 다가올지 잘 모르겠습니다.

그래도 취약점 분석과 관련한 커리어에도 다양한 길이 존재하며 CS 지식을 탄탄히 하고, insight를 넓혀야 한다는 것이

결론입니다. 이상으로 글을 마무리하며 후배들이 보안과 관련해 커리어를 생각할 때 도움이 되었으면 좋겠습니다.

추가적으로 앞으로 개인적인 연구 포스팅은 https://judangs.github.com/ 블로그를 이용해보려 합니다.

해당 블로그가 독학으로 연구하는 분들에게 시야를 넓힐 수 있는 insight를 제공할 수 있었으면 좋겠습니다. 감사합니다.

오늘 23년 2회차 실기 결과가 나왔습니다.

다행히 합격했네요.

2023 알기사 서적으로 공부했고, 문제의 50% 정도는 기출문제집에서 나온 것 같습니다.

다른 자격증과는 다르게 기출 문제집의 문제만 모두 맞춘다면 합격 커트라인인 60점 언저리인 것 같습니다.

그래서 기출문제집 외의 문제 중 자기가 아는 문제로 나와야 합격 가능성이 높아지는 시험입니다.

다른 자격증의 경우, 다른 사람들에게 도전해보라는 말을 가볍게 던질 수 있겠으나 보안기사는 공부를 잘못하면

시간 낭비가 될 수도 있는 만큼 쉽게 권하지는 못하겠어요. 성실히 공부 + 운적인 요소가 갖춰져야 합격할 수 있는

시험이니까요.

 

실기 공부는 아이패드를 활용해 최대한 적어가며 공부했습니다. 적어도 기출문제집에서 나오는 문제는 다 맞춘다는

방향으로 공부해야 합격 가능성이 높아지는 것 같습니다. 달리 합격을 위한 꼼수같은게 없네요 ㅜ.ㅜ

해당 자격증 시험을 준비하는 수험생이라면 이 자격증이 꼭 나한테 필요한지 판단해보고 충분히 고민해본 뒤 시험에

임했으면 좋겠습니다. ㅎㅎ

다들 화이팅~

23년 2회차 필기시험을 보고 왔습니다. 

문제 출제가 KISA에서 KCA로 변경되고 좀 더 쉬워졌다는 소리를 듣고 많이 안심했네요.

결과는 합격했습니다! CBT 시험이라 처리기사와 동일하게 문제은행방식이라고 생각했는데

기출문제에서 약간 변형해 문제가 출제되었던 것 같아요.

만약 기출문제집을 푼 이후 오답을 확실히 했다면 쉽게 풀 수 있는 난이도라 생각됩니다 ㅎㅎ..

외에도 알기사 서적에서는 나오지 않는 개념이 문제로 몇 문제 출제되는데,

배웠던 부분에서 점수를 많이 얻으셨다면 부담스럽지 않은 정도입니다. 

보안기사가 어려운 이유는 필기보다 실기라고 하는 만큼, 필기를 공부할 때

실기를 같이 준비하는 느낌으로 공부해야 할 것 같습니다 ㅎㅎ..

정보보안기사를 준비하는 수험생분들 화이팅이에요!

 

공부법

2023 알기사 정보보안기사 필기 서적으로 공부했습니다.

기출 문제의 오답을 꼼꼼하게!

오늘 23년 1회차 실기 결과가 나왔습니다.

 

 

합격했네요.

2023 시나공 실기 서적으로 공부했고, 이론을 노트에 써내려가며 공부했습니다. 산업기사와는 다르게 범위가 너무 많아

공부하는데에 어려움이 있지만 시나공 서적의 파트 별 중요도 표시를 적절하게 활용했습니다.

이전과는 다르게 실기의 답을 써내는데 단답식, 서술형으로 적는 방식에서 보기가 주어지는 방식으로 바뀐 듯 합니다.

㉠  선택지1  ㉡ 선택지2

이런 방식에서 ㉠ , ㉡ 을 고르는 것처럼요. 아무래도 정보처리기사 실기를 준비하는 수험생분들이 좀 더 편한 마음으로

준비할 수 있어 보입니다. 또 문제 유형의 절반 이상이 보기에서 고르는 선택지 유형인만큼 모든 것을 암기한다는 부담은

덜었으면 좋겠습니다 ㅎㅎ.

 

다들 화이팅~

 

23년 1회차 필기시험을 보고 왔습니다. 합격 ㅎ,ㅎ 

이번에도 CBT 시험으로 응시를 했는데, 확실히 문제 은행 방식이라 PBT방식보다 부담이 덜해서 좋습니다. 

산업기사와 마찬가지로 23년도 시나공 서적으로 공부를 했는데 서적 범위에서 많이 나왔습니다.

덕분에 문제 풀기가 수월했는데, 정보처리기사는 문제는 갈수록 쉬워지는 것 같은데 범위가 엄청 많더라고요..

정보처리산업기사와 비교하면 문제 난이도는 비슷하나 범위가 2배 이상? 이 부분에서 마음의 준비를 하셔야.. ㅜ.ㅜ

정보처리기사를 준비하는 수험생분들 화이팅이에요! 

 

공부법

시나공 기준 중요도 A, B에 해당하는 내용을 중심으로 꼼곰하게 공부하면서 기출문제를 많이 풀어보는

방향으로 공부했습니다. 중요도 C, D의 경우 1 ~ 2번씩 훑어보는 느낌으로 넘어갔네요. 이런거보면

다른 자격증은 몰라도 정보처리 자격증은 시나공이 가장 좋은 것 같습니다. ( 홍보 X )

 

요약) 시나공 중요도 A, B 자세히 보기.

 

 

policyKit은 시스템 전체의 권한을 제어하기 위한 툴킷입니다. policyKit 내부에 존재하는 pkexec의 경우,

특정 명령어를 사용자 정책에 따라 상위 권한으로 실행할 수 있도록 도와주는 도구입니다. 최근 이런 툴킷에서 취약점이 발견되고 있습니다.

이번에 분석하는 CVE-2021-4034은 pkexec에서 취약점이 발견되었으며, root 권한의 setuid가 설정되어 있어 LPE가 가능한 취약점입니다.

바로 문제가 되는 main의 소스코드를 살펴보겠습니다.

반복문을 통해 n = argc - 1임을 생각해볼 수 있습니다.

path에 argv[n]에 해당하는 값을 넣게 되는데, 만약 argv가 null로 설정되어 있다면 argv[1]을 참조하게 되면서 Out-of-bounds가 일어나게 됩니다. 바이너리 상에서 argv 다음으로 오는 인자는 env이므로, env에 명령어를 넣고 pkexec를 실행한다면 상위 권한의 패스워드 검증없이 원하는 명령어 실행이 가능합니다.

pkexec의 다음 구문에서 실행되는 명령어의 default 권한을 알 수 있습니다.

default 값으로 opt_user=root 입니다. 때문에, main의 정책 검증 로직이 의미가 없어지게 되고

쉘 명령어가 root 권한으로 일어나면서 로컬 권한 상승을 일으킬 수 있게 됩니다.

 

 

22년 1회차 실기 결과가 나왔습니다.

 

다행히 합격했네요.

교재는 시나공 문제서적으로 공부를 했고, 시나공 서적 범위에서 많이 나왔습니다.

네트워크나 프로그래밍 언어, DB 관련은 편하게 공부할 수 있어서 취득하기 쉬웠던 자격증이 아닌가 싶습니다.

개인적으로 2022 실기보다  2022 필기 CBT 시험이 더 어려웠던 것 같습니다.

참 희한하네요. 프로그래밍에 자신있는 분은 취득하기 쉬운 자격증이니 한번 도전해보는 것도 좋을 것 같습니다.

 

오늘 22년 1회차 실기 결과가 나왔습니다..

바로 조회를 해보니

합격했습니다 ...

이것 저것 신경쓴다고 제대로 시간을 투자하지 못했는데

다행히, 문제가 생각보다 평이하게 나와서 크게 어렵진 않았습니다.

교재는 알기사 문제서적으로 공부를 했고, 거의 서적 범위 내에서 나왔네요.

80점 정도 나올 것 같았는데.. 채점 기준이 엄격한 건지, 제가 잘못적은 건진 몰라도 62.5로  턱걸이 합격했습니다.

이런 거보면, 실기는 배운 이론을 글로 잘 적어내는 것이 중요한 것 같습니다.

자격증을 준비하는 분들이라면 이론을 꼼꼼하게 서술형으로 써내는 방식으로

공부하면 좋은 결과가 있을 거라 생각해요!

 

 

libc leak없이 libc 메모리 주소에 aaw를 해야하는 상황에서 많은 삽질을 하다가 해당 기법을 알게되었는데요..

Stack Pivot은 특정한 쓰기 가능한 공간에 Fake Stack을 구성해 놓고 rsp로

스택의 위치를 바꿔 Chanining을 이어갈 수 있는 기법입니다.

해당 기법은 SFP와 leave Gadget을 사용하므로 최소한 RET 주소까지는 오버플로우가 일어나야 합니다.

보통 오버플로우 기법을 이용할 때 입력 공간이 부족한 경우 이용하게 됩니다.

 

조건

  • 최소한 RET까지 오버플로우가 일어나야 한다
  • leave ; ret ; 가젯이 있어야 함
    leave 의 경우 mov rsp , rbp ; pop rbp ; 와 같이 Gadget 조각을 모아 조건을 성립시켜줘도 됨
  • Fake Stack의 위치는 Stack처럼 사용하므로 RW 권한이 있어야 함

 

SFP에 Fake Stack의 주소를 넣고

RET에 leave Gaget을 넣게 되면 rsp를 원하는 위치로 지정할 수 있습니다.

 

 

이후 Fake Stack의 스택프레임에 맞춰 Chain을 이어나갈 수 있게 됩니다.

기본적인 개념은 이렇습니다. 하지만 이를 응용하면 생각지도 못한 위치로 aaw가 가능하게 됩니다.

 

AAW 응용


libc leak을 하지 않은 상황에서 라이브러리 주소에 특정 바이트를 적는 것은 어렵습니다. 그런데 

Stack pivot을 사용하여 라이브러리 주소를 담고있는 특정 주소의 -0x8의 위치에 pop rsi 가젯을 위치시키면

주소값이 read함수의 인자로 넘어가면서 자연스레 해당 라이브러리 주소에 원하는 byte를 적을 수 있게 됩니다.

Fake Stack의 구성은 다음과 같습니다.

영역의 크기를 잘 고려해서 페이로드를 짜야하지만, 이런 창의적인 방법으로 libc leak 없이 aaw가 가능합니다!

 

정교한 익스를 위한 추가사항

Fake Stack의 Chain별 길이를 조절하는게 중요합니다. 예를 들어, FULL RELRO가 걸려있는 ELF에서

특정 영역에 Fake Stack을 생성했다면 길이가 너무 길어 .got영역와 같은 영역을 페이로드가 침범할 수 있습니다.

이런 경우 바이너리가 바로 죽어버리게 되는데 이는 익스플로잇에 민감한 사항이 될 수 있습니다.

이럴 경우, RW가 가능한 메모리를 우선 확인하고 사이즈를 조절한 뒤 Chain을 연결하여 ROP를 터트리는 방향을

고려해봐야 합니다.

'System' 카테고리의 다른 글

Linux] Seccomp  (0) 2022.04.28
DLL Load(IAT, EAT)  (0) 2022.03.27

+ Recent posts