이제... 글립코드 소스 코드를 보는 게 좀 더 편해졌으니
새로운 기술을 시험해 보죠 검색하세요 네 취약한 바이너리와 함께 pwntools 템플릿
스크립트를 찾을 수 있어요 안 돼요!
네 패스트빈_둡-3 이진법은 1부에서 만난 패스트빈_둡 이진법과 거의 동일합니다
같은 이름으로 기술을 익히면서요
신속히 실사를 통해 차이점을 찾아보죠
체스크는 렐로의 일부만 나타납니다 우리가 알던 렐로가 아니죠
렐로 일부라면 이건 쌍성이에요 곳 plt 섹션은 프로그램이 진행되는
동안 계속 쓰일 테니 명심하세요
잘 모르신다면 곳 plt 섹션은 외부 라이브러리 기능에 대한
포인터의 시리즈일 뿐이죠
네 착취 개발의 주된 요소지만 개발과 크게 관련은 없어요
더 자세히 알고 싶다면 룹 상점 입문자 안내서의 부록 a를 참고하세요 제가 원리를
자세히 적어 뒀어요 ?
이 바이너는 비좌지 독립적이기 때문에 주소를 알 수 있습니다 곳 런타임에 plt
섹션이요 글리벡 버전 2와 연결되어 있어요 30편은 편집 안 했어요 2부에서 봤듯이 tcache는 이진법
데이터를 훨씬 쉽게 이용할 수 있어요 그래서 패스트빈을 계속 활용하고 있죠
글리벡 2에서 악영향을 완화하면... 302
네
30 챌린지 이진법을 GDB에 불러
실행하면 libc 리그가 나오고 말로크가 6번 호출한 걸 알 수 있죠
기존 패스트빈_덥 바이너리보다 하나 적네요
그것 말고는 기본적으로 똑같아요 빠른 결정만 요청할 수 있어요 할당 후 작성해서 풀어주는
거죠
화물칸을 분해해서 검사하면 예상한 결과가 나오죠
.도 볼 수 있습니다 곳 pwndbg의 plt 섹션은 명령이 있죠
여기서부터 패스트빈_dup_3 이진법을 도전으로 취급할 겁니다 네 이번에 배울 것은 말록의 내부를
새로 익히거나 보안이 철저한 프로그램을 뚫는 게 아니라 글록의 소스 코드를
찾아 퍼즐을 푸는 겁니다
여러분 시작하기 전에 몇몇은 이 어려운 쌍성을 아무 힌트 없이 이용하려
하죠
네 잠시 후 화면을 정지할 테니 템플릿 스크립트로 개발을 시작하세요
여기서 중요한 건 글리벡 소스 코드 검색이란 걸 기억하세요
내 말이 모호하면 좀 있다가 봐요
여러분 네 우리가 더블 무 버그를 이용해 패스트빈 포인터를
덮어쓰고 말록 훅을 겹치는 가짜 덩어리를 할당했다는 걸 봤을 거예요 ,
명심하세요 네 기존 글립코 데이터를 가짜 크기로 만들어서
패스트빈의 크기 확인을 충족할 겁니다 좋아요,
이걸 기억 못 한다면 1부의 패스트빈 둡 강의를 다시 듣고 이 기술을
익히길 권합니다
네 말록 갈고리 위에 줄을 던진 후 한 가지 장치에 조준하고 일곱 번째이자 마지막
신호로 그 장치를 작동시켜 탄피를 떨어뜨립니다
네 패스트빈 둠3 쌍성에 무균 버그가 아직 있지만 한 마리만 더 잡으면 터질
거예요
네 말록 갈고리를 다시 쓸 순 있지만 그 후에 말록을 작동시킬 방법이 없어요
,
네 네 프리 훅 근처에 쓸 만한 가짜 크기의 필드가 없고 주 경기장에서
쓸 수 있는 것보다 더 많은 공간이 필요해요
중요한 건 프로그램이에요 곳 plt 구역 거기에 패스트빈덥을 넣으면 시스템
주소나 가젯 등등이 나올 거예요 함수 포인터를 이용해
해당 함수에 대한 호출을 트리거합니다
예를 들어 exit 함수의 입구를 하나의 장치 주소로 바꾸면 프로그램을 그만두고 그렇게
함으로써
exit을 곳 plt는 그 장치로 이어집니다
이 콘셉트가 낯설지 않았으면 좋겠네요
네 인트로에서 말씀드렸듯이 이 과정의 마지막 부분은 고급으로 간주됩니다
그러니 착취 개발자 지식에 좀 더 가깝겠죠 ? 네
네 맨페이지를 확인하거나 함수가 뭔지 배워야 할 수도 있어요 호출
시 바이너리의 동적 분석도 필요하고요 너무
힘들진 않아요
각 함수의 중단점을 설정하고 다양한 메뉴 옵션을 선택하면 알아야 할 게 나옵니다
Fwndbg의 Fake_fake_ast 커맨드를 이용했습니다
힙을 초기화하기 위해 덩어리를 요청합니다 그렇지 않으면 pwndbg의 힙 명령이 작동하지 않습니다
말록이 바늘을 물기 직전의 크기 판입니다
같은 명령을 이용해 가짜 크기 필드를 찾아보죠 그래야 우리가 이길 테니까요 곳 plt 항목입니다
exit 포인터를 예로 들게요
후보자를 찾았는데 너무 느려요
가짜 크기 부분은 작성할 수 없는 부분이에요
네 늘 이런 건 아니에요 말록이 작성을 시도하지 않으면 그럴 일은 없겠지만
우리가 작성한 사용자 데이터가 작성을 허가하는 한 괜찮을 거예요 ,
하지만 이 가짜 데이터의 첫 세 바이트는 쓰기가 불가능한 메모리에 있습니다
네 이 경로를 이미 써 봤다면 이미 깨달았을 거예요 이 덩어리를 분배하고 세그폴트
없이 쓰려 해도 글립벡의 읽기 기능이 워낙 강해서 데이터를 쓸 수 없다는 걸요 하지만 글리지벡은
하지만 희망이 없는 건 아닙니다 패스트빈의 크기는 보기와는 다릅니다
네 글리벡의 새로운 소스로 서핑하는 능력을 발휘해 봐요 패스트빈 사이즈
업계를 뒤져서 뭐가 문제인지 알아내요
글리벡 버전을 제대로 보세요 네 워보크 코드 브라우저를 사용할
경우 글립코드 버전에 문제가 있는지 확인하면 됩니다
네 네 모험을 해서 마무리하세요 네,
좋아요
힌트를 원하시면 다시 재생하세요 제가 무슨 말을 하려는지 알려드리죠
네 워보크 코드 브라우저로 패스트빈 사이즈 확인을 찾을게요 팔로우하시면
선호하는 소스 브라우저로 따라오세요
좋아요, 홈페이지에서 이 검색 바를 사용하라고 추천하네요 하지만 위에 있는 모든 프로젝트를 검색하고 있어요
그러니 쓸모없죠
소스 트리를 찾으려면 글리벡을 클릭하세요
여기서부터는 트리를 직접 검색하거나 왼쪽 상단 바에서 검색할 수 있습니다
글리벡이 어떻게 작동하는지 알아내는 고통을 맛보게 될 테니
각오하세요
네 말록을 검색하면 말록 디렉터리의 모든 파일을 볼 수 있어요 도움이 안 되지만 기호로
스크롤을 내리거나 반환을 누르면 말록 기호가 정의되는 곳으로 가요
그렇게 간단하지 않아요
말록은 6개의 파일로 정의됩니다
일부는 테스트용이지만 dl-minimal에 있는 것도 있어요 c는 완전히 다른
말로리예요 그건 libc 바이너리가 로드되기 전에 동적 로더가 사용합니다
맞아요 저도 예전에 엉뚱한 놈을 디버깅해서 안 건데
같은 일이 생겨도 걱정 마세요
우리가 찾는 기호는 리브코말록이에요 가명은 말록이죠
예전 계획보다 훨씬 나아요
말로크에선 한 가지 특징만 보입니다 c를 클릭해
코드를 보죠
네 포장 기능이에요 말록의 갈고리를 확인하고 공연장을 찾아주는
거죠
또한 Tcache로부터 신속한 할당으로 사용됩니다
말록은 더프 메모리에 포인터를 반환하니까 '피해자' 변수는 그 포인터일 거예요
그 위를 맴돌면 _int_멀록이라는 다른 기능이 있다는 걸 알 수 있죠
클릭하면 코드를 볼 수 있어요
_int_malloc에서 무거운 걸 들어요
네 최선을 다해 pdf 플로차트에 _libc_intmalloc을 정리했지만
특정 코드를 추적해야 한다면 시간을 들여 읽고 이해하는 수밖에 없어요
이 부분을 보기 전에 그렇게 하셨길 바라요
네 다행히도 말록이 가장 먼저 찾는 곳이 패스트빈입니다 그래서 멀리
가지 않아도 패스트빈 크기 검색을 할 수 있죠
네 특정 완화를 원한다면 오류 메시지를 찾는 게 편리해요 말록은
이런 걸 남겨요
확인은 두 변수를 비교하는 것을 포함합니다 피해자_인덱스와 idx죠 일치하지 않으면 오류 메시지를
출력하고 전송을 중단해요
이 두 변수는 fastbin_index macro가 채웁니다
매크로 영역에 침범하면 더 확장돼요
nb, 우리가 나중에 익숙해질 변수인데요 정규화된 요청 사이즈입니다 네 여기서 정규화는 가장 가까운
덩어리로 모였다는 뜻입니다 그래서 5 바이트 요청은 nb 값이
0x20으로 올라갑니다
우리가 찾는 덩어리예요
네 구조상 SIZE_SZ는
8이고 패스트빈_인덱스는 nb를 4비트로 바꾸고 2를 빼요
매크로의 핵심은 덩어리 크기를 기준으로 경기장의 패스트빈 배열에 색인을 넣는 거예요
말로크를 통해 힙 메모리를 요청한다고 가정해 보죠
그러면 최소 구조의 nb인 0x20이
제공됩니다
네 네 패스트빈_인덱스는 크기를 4비스씩 바꿉니다
??? 그럼 최소의 나비는 놓치고 두 명만 남네요
여기서 2를 빼면 0이 남죠
0x20은 여기서 가장 작은 덩어리라서
패스트빈 0에 저장합니다
가로세로 30cm인 덩어리를 찾는다면 패스트빈 지수가 1이 되겠죠
네 여기요 idx는 우리가 검색하는 패스트빈드 인덱스고 피해자_인덱스는 저 통의
패스트빈 인덱스예요 사용자에게
돌아가 크기 필드를 이용해
계산합니다
당연히 두 개의 값이 일치해야죠 0x20 패스트빈은 0x20 크기로만 구성해야 합니다
전에도 이런 경화를 촉발한 적이 있어서 알죠
이 수표는 뭐가 문제죠?
idx와 피해자_인덱스 사이의 데이터 너비 불일치를 보셨을 겁니다
어떤 아키텍처에서 int는 롱과 너비가 같지만 x64에서는
그렇지 않습니다 int는 32bit 너비가 되고 롱은 64..
네 이건 문제가 안 돼요 문제가 생길 테니까요 이전에는 없었던 높은
패스트빈 지수를
그래도 데이터 너비가 핵심이에요 아직 도청 장치를 못 찾았다면
마지막으로 말할 기회를 줄게요
이미 이해하셨다면 다음 질문은 건너뛰고 바로 시작하죠
패스트빈 크기 검사 버그가 패스트빈_인덱스에 나타났습니다
네 sz는 전달된 덩어리예요 이제 제대로 이동한 걸 알죠 2를 빼기 전에 2를 빼는
거예요
아키텍처의 기본 조건에 따르면 청크 크기는 8바이트 너비입니다
INTERNAL_SIZE_T로부터
온 것인데, 기본 값은 size_t이죠
자세히 보시면 너비 불균형에 대한 경고도 있습니다
패스트빈_인덱스로 돌아가서 가장 먼저 하는 일은 덩어리 크기를 int로 보내는 겁니다
x64 아키텍처에서
가장 중요한 32개의 가짜 덩어리를 잃게 됩니다 이동과 뺄셈이 일어나기 전에요 ? 네
네 패스트빈스 측정기로 가장 중요한 4바이트 크기의 덩어리를 무시합니다
네 원래는 가짜 사이즈를 나타낼 4글자를 생각했어요 0x7f 그리고 7개의 null
바이트 예를 들면
하지만 이 지식만 있으면 계산은 네 바이트면 돼요
이 약점을 찾을 다른 방법은 버그 보고서를 찾는 거죠
네 이 잡지는 2016년에 에인절 보이가 처음 보도했지만 오해와 무시를
받았죠
4년 후 그 기사는 독자적으로 재발견됐고 학생에 의해 다시 보도됐습니다 ? 네, 그렇습니다
특히 이 벌레를 알게 해 준 허시에게 감사드려요
연락받기 전까진 있는지도 몰랐어요
맞아요 하지만 안타깝게도 이 두 가지 보고가 녹음 당시에도 불구하고 도청은 여전히 글립코 최신판에 남아
있습니다
네 이제 패스트빈 크기 검사의 결함을 알았으니 패스트빈_dup-3
이진법으로 껍질을 떨어뜨려 봐요 끝나면 돌아와서 다시 작동시켜요 그때 최종
개발을 검토하죠
화면에 패스트빈_dup_3 바이너리 정보가 떴습니다
네 시작은 다른 패스트빈 둡과 비슷합니다 패스트빈에 덩어리를 두 번 분리하죠 특히 0x70
패스트빈입니다
복사된 덩어리는 패스트빈 포인터를 덮어쓰는 데 사용됩니다
겹치는 주소는 이진법 읽기 항목이에요 곳 plt 구역, 3 마이너스 3의 중요성이
잠시 후에 나옵니다
나머지 공격은 프로그램 중복되는 가짜 덩어리를 요청하는 거예요 곳 plt 항목에 글리벡
시스템 주소를 덧씌우는 데 사용했어요
마지막 줄은 시스템에 전달할 명령을 보내고 그 결과 셸이 만들어지죠
네 마지막 줄에 주석을 달아서 빈칸을 채워보죠 셸이 떨어지지 않도록요 GDB와 NOASLR
옵션을 이용해 취약점을 취약점 취득하세요
GDB에 침입해 프로그램을 검사합니다 곳 pwndbg의 plt 섹션은 명령이 있죠
네 내 취약점 공격으로 이 지역에 가짜 돈을 성공적으로 할당했고 스트툴 엔트리를
말록을 타락시키고 설비프프리를
설정하는 시스템 주소로 바꿨어
가짜 덩어리를 어떻게 여기 배치했을까요?
그렇군요 그런데 말록의 주소가 여전히 적은데 널바이트로 끝나네요
그건... 네 멀록의 주소에서 가장
덜 중요한 12개는 계속 반복될 거예요 이 프로그램을 아무리 돌려도요
그러니 용량이 가장 중요한 바이트가 될 거예요
읽기 항목에 메모리를 버리면 좀 더 명확하죠 마이너스 3 제 취약점
스크립트가 가짜 청크의 주소로 사용한 값입니다
가짜 0x7f 크기 필드예요
중요한 4 바이트는 중요하지 않다는 걸 알죠
말로크가 확실히 받아들였죠
가끔씩은 Pwndbg의 덤프 바이트 명령을 사용해서 순서를 가늠하는 게
더 쉽습니다
이 바이트로 판독을 합니다 곳 plt 기록이에요 이건 말록 기록이고요
여길 보면 가장 중요한 3개의 바이트의 읽기 항목과 가장 중요하지 않은 바이트인 말로크
항목을 비교하면 가짜 크기 항목은 무엇일까요?
네 스트툴 곡에 손을 대야 하는데 잘 모르시는 분들을 위해 스트링으로 조작해서
서명되지 않은 장편 곡으로 바꾸려 하죠
HeapLAB 프로그램은 모두 이 기능을 이용해 사용자가 선택한 메뉴를 해석합니다
네 네 그럼 시스템에 명령을 보낼
수 있죠 네, 맞아요
내 취약점이 바로 그거죠
네 메뉴에 숫자를 입력하는 대신 문자열/bin/sh를 보내죠 스트툴 대신 시스템으로 보내져요 스트툴
, 맞아요
솔루션 스크립트로 돌아가서 추가한 주석을 지우고 제품 조건에서 공격
실행을 해서 우리가 의존하는 멀록의 바이트가 그대로인지 확인합니다
,
믿을 만한 정보를 찾았어요
지금까지 배운 걸 정리해 보죠
가장 명백한 사실은 글립코드 소스 코드를 검색하고 이해하는 게 생각보다 어렵다는
거예요
하지만 개발자든 FOSS 기여자든 여전히 중요한 기술입니다
글립코드에도 네 , 하지만 중요한
건
한 명뿐이라고 생각하지 마세요
나중에 글리벡의 다른 버그를 살펴볼 겁니다
그렇군요 네 안 그러면 패스트빈의 실드 체크를 못 해요
네 이걸 이용해서 취약한 바이너리에 이중 무첨가 버그를 심어서 프로그램의 가짜 덩어리를
겹치게 했어요 곳 plt 구역 네 우리가 사용한 가짜 사이즈 필드는 ASLR
엔트로피를 가장 중요한 네 바이트로 포함하고 있었죠 앞서 말한 약점을 알기 전까진 용납할 수 없다고 생각했어요 하지만 그 약점을 알게 됐죠
가짜 고환으로 a를 수정할 수 있었죠 곳 plt 항목 스트툴 항목을 시스템으로
재전송하고 포탄을 투하하는 명령줄을 전달합니다
이 도전 바이너리를 아무 도움 없이 이용했다면 축하합니다 프로그램에서 가짜 청크를 둘 다른 장소를
고를 수도 있었어요 곳 가장 중요한 바이트인
사이즈를 가진 plt 섹션은 미해결 스택_chk_fail 주소입니다
이 접근법의 유일한 단점은 printf를 수리하고 그 과정에서 항목을 읽어야 한다는
거죠
어떤 주소 비트가 ASLR에 영향을 받는지 더 알고 싶다면 잠시 후 알아보죠
그동안 강의실 리소스에서 내 솔루션 스크립트를 다운로드해요
늘 그렇듯 말록 시험대가 있으니 배운 걸 연습하세요
다음 영상에서는 부식의 집이라는 새롭고 물이 안 새는 기술을 알아보겠습니다
거기서 봐요