충돌을 찾는 퍼징

퍼징은 예상치 못한 동작, 특히 충돌을 일으키기 위해 잘못되었거나 지나치게 큰 입력을 프로그램에 보내는 기법입니다. 충돌은 메모리 손상 버그의 신호인 경우가 많습니다.

버퍼 오버플로에서는 먼저 대상 프로그램을 충돌시켜 오버플로가 존재한다는 사실을 확인하는 것이 목표입니다.

고전적인 익스플로잇 작업 흐름은 다음과 같습니다.

• 프로그램을 충돌시키도록 퍼징합니다.
• 반환 주소까지의 정확한 오프셋을 찾습니다.
• EIP를 제어합니다.
• 셸코드로 리디렉션합니다.

이 단원에서는 처음 두 단계를 다룹니다.

충돌을 관찰하려면 대상 프로그램에 디버거(Windows에서는 Immunity 디버거 또는 x64dbg, Linux에서는 GDB 등)를 연결합니다.

프로그램이 충돌하면 디버거는 레지스터의 상태를 보여 줍니다. 특히 EIP를 확인하면 반환 주소를 덮어썼는지 알 수 있습니다.

간단한 퍼저는 프로그램이 충돌할 때까지 점점 더 긴 문자열을 보냅니다. 흔히 'A' 문자(0x41)를 많이 보내는 것부터 시작합니다.

충돌 후 EIP에 41414141이 표시되면 반환 주소를 제어할 수 있음이 확인된 것입니다.

애플리케이션이 충돌하고 EIP가 41414141과 같다면 오버플로가 저장된 반환 주소까지 도달한 것입니다.

하지만 아직 EIP 앞에 정확히 몇 바이트가 있는지는 알 수 없습니다. 같은 바이트만 보내면 EIP를 제어할 수 있다는 사실은 알 수 있지만, EIP가 어디에 있는지는 알 수 없습니다.

정확한 오프셋을 찾으려면 'A'만 보내는 대신 반복되지 않는 고유 패턴을 보냅니다. 4바이트로 이루어진 각 구간이 서로 다르므로 EIP에 들어간 값으로 오프셋을 식별할 수 있습니다.

Metasploit은 이를 위한 pattern_create.rb를 제공합니다.

패턴으로 충돌시킨 후 EIP의 값을 기록합니다. 이 값을 pattern_offset.rb에 입력하면 EIP 앞에 있는 정확한 바이트 수를 반환합니다.

이 오프셋은 반환 주소 바이트 앞에 넣을 패딩의 크기입니다.

항상 검증해야 합니다. offset 바이트만큼 'A'를 넣고 그 뒤에 'B' 네 바이트(0x42)를 붙인 입력을 만드세요. EIP가 42424242가 되면 오프셋이 정확한 것입니다.

이 확인을 거치면 나중에 몇 바이트 차이로 발생한 오류를 디버깅하느라 시간을 낭비하는 일을 막을 수 있습니다.

EIP를 제어한 후에는 충돌 순간에 ESP가 가리키는 위치도 기록합니다. ESP는 보통 덮어쓴 반환 주소 바로 뒤, 즉 남아 있는 버퍼 내부를 가리킵니다.

나중에 셸코드를 배치할 공간이 바로 그곳입니다.

유용한 퍼징 및 패턴 도구는 다음과 같습니다.

• Spike와 boofuzz: 네트워크 프로토콜 퍼저입니다.
• pattern_create / pattern_offset: EIP 오프셋을 찾습니다.
• Immunity의 mona.py: 패턴, 오프셋, 잘못된 문자 관련 작업을 자동화합니다.

유용한 충돌은 재현 가능해야 합니다. 충돌을 일으키는 정확한 입력을 저장하고, 깨끗한 상태에서 다시 실행하여 오프셋이 안정적인지 확인하세요.

충돌이 일관되지 않다면 버그가 깔끔한 스택 오버플로가 아니거나, 실행할 때마다 어떤 조건(타이밍, 길이, 내용)이 달라진다는 뜻일 수 있습니다.

순환 패턴이 동일한 바이트로 이루어진 문자열보다 나은 이유를 떠올려 보세요.

이제 충돌 오프셋을 찾는 방법을 알고 있습니다.

• 입력을 점점 늘려 가며 퍼징하여 충돌을 일으키고, EIP에 41414141이 표시되는지 확인합니다.
• 순환 패턴과 pattern_create / pattern_offset을 사용하여 정확한 오프셋을 찾습니다.
• 패딩과 'B' 네 바이트(42424242)를 사용해 검증합니다.
• 나중에 셸코드를 배치할 수 있도록 ESP가 가리키는 위치를 기록합니다.

다음에는 EIP를 완전히 제어하고 실행을 리디렉션합니다.