바이너리가 자신을 분석하는 AI에게 응답하는 방법을 배우게 되었고, 거의 아무도 알아차리지 못했습니다.
요약
만약 당신이 스트립된 바이너리를 AI 에이전트에게 넘겨주고 그가 제공한 요약을 신뢰했다면, 이 글을 읽어야 합니다. 연구원들은 C 프로그램에 포함된 문자열들이 Ghidra나 IDA Pro 같은 도구로 디컴파일되어도 살아남아, LLM 기반 리버스 엔지니어링 에이전트의 컨텍스트 창 내부에 온전하게 자리 잡을 수 있음을 보여주었습니다. 바이너리는 더 이상 단순한 데이터가 아닙니다. 그것은 프롬프트입니다.
배경
이는 새롭거나 완전히 새로운 취약점 범주는 아닙니다. 프롬프트 주입(Prompt injection)은 LLM 애플리케이션의 알려진 약점이었으며, 사람들이 LLM을 외부 입력이 있는 모든 것에 연결하기 시작한 지 약 5분 만부터 존재해 왔습니다. 우리는 웹 페이지를 읽는 채팅 에이전트, 받은 편지함을 요약하는 이메일 비서, 풀 리퀘스트(pull request)를 처리하는 코딩 에이전트 등에서 이를 목격했습니다. 여기서 새로운 점은 구체적인 파이프라인입니다: 보안 및 RE 커뮤니티가 수십 년 동안 기술적으로 적대적이지만 기능적으로 신뢰하는 아티팩트로 취급해 온 디컴파일된 코드 말입니다.
잠시 그 가정을 생각해 보세요. 악성코드 분석가들은 항상 자신이 보고 있는 바이너리가 적대적이라는 것을 알고 있습니다. 그것이 이 작업의 전체 목적입니다. 하지만 디컴파일러의 출력물 — 의사 C 코드(pseudo-C), 복구된 문자열, 제어 흐름 그래프(control flow graph) — 은 전통적으로 해당 바이너리가 수행하는 바에 대한 충실하고 비활성적인 표현으로 간주되어 왔습니다. 당신은 그것을 읽고, 그것에 대해 추론하며, 디컴파일러 출력물 자체가 당신에게 무언가를 할까 봐 걱정하지 않습니다. 이제 그 출력이 LLM 에이전트(여기서는 Cline, GhidraMCP와 Qwen3-8B를 사용)로 직접 파이프되는데, 이 에이전트는 그것을 자신의 추론 컨텍스트의 일부로 취급합니다. 예전에
솔직히 말해서 이것이 무엇이고 무엇이 아닌지 알아야 합니다. 이것은 Ghidra 자체에 대한 새로운 익스플로잇(exploitation) 프리미티브도 아니며, 분석가(analyst)의 머신을 대상으로 하는 원격 코드 실행(remote code execution)도 아닙니다 (적어도 여기서 설명된 내용에 근거로는). 이것은 로직 하이재킹(logic hijack)입니다. AI 에이전트가 자신이 '분석해야 할 데이터'와 '따라야 할 지침'을 구별하지 못하기 때문에, 자신의 분석 결과를 잘못 보고하거나, 오도하거나, 리디렉션하도록 만드는 것입니다. 이 구분은 미묘하게 들리지만, 지금 모든 LLM 통합 도구에 영향을 미치고 있는 정확히 같은 해결되지 않은 문제라는 것을 기억하면 다릅니다.
과소평가되고 있는 것은 현재 출시되는 모든 AI-RE(AI-Reversing Engineering) 도구에 내재된 '신뢰할 수 있는 입력(trusted input)' 가정의 폭발 반경입니다. 악성코드 분류(malware triage), 펌웨어 분석, 취약점 탐색을 위한 AI 코파일럿을 구축하는 공급업체들 — 이들은 모두 디컴파일러 출력을 필터링 없이 모델에 전달해도 안전하다는 동일한 암묵적 베팅을 하고 있습니다. 그 베팅은 한 번도 검토된 적이 없었으며, 단지 인간이 추론을 수행하던 LLM 이전 도구 시대에서 물려받은 것입니다. 그리고 인간은 디스어셈블리 목록에 있는 문자열에 의해 '프롬프트 주입(prompt injected)'되지 않습니다 (음, 대부분의 경우).
과대평가되고 있는 것은 새로움입니다. HN에서 두 개의 포인트와 댓글이 없다는 것은 담론이 아직 그 함의를 따라잡지 못했다는 것을 의미할 뿐이지, 그 함의 자체가 작다는 것을 의미하지 않습니다. 이것은 우리가 2023년부터 계속 이야기해 온 프롬프트 주입 스토리일 뿐이며, 단지 다른 옷을 입고 있을 뿐입니다. 이 '옷'이 중요한 이유는 방에 누가 있느냐 때문입니다. 아이러니하게도 보안 연구원들은 바로 이런 종류의 에이전트를 정확히 이런 종류의 적대적 입력(hostile input)에 대해, 의도적으로, 매일 실행할 가능성이 가장 높은 사람들입니다.
함의(Implications)
만약 AI 기반 리버스 엔지니어링 도구를 구축하거나 구매한다면, 디컴파일된 출력은 다른 어떤 신뢰할 수 없는(untrusted), 공격자 통제 입력(attacker-controlled input)을 LLM에 처리하는 방식과 동일하게 취급해야 합니다. 이는 모델에 도달하기 전에 정제(sanitization)가 필요하며, '분석 대상 콘텐츠'와 '따라야 할 지침' 사이의 엄격한 분리(이것은 아무도 완전히 해결하지 못했습니다)가 필요하고, 자신이 직접 컴파일하지 않은 바이너리에 대한 AI 생성 분석 요약에 대해서는 건강한 수준의 회의론을 가져야 함을 의미합니다. 악성코드 작성자들은 이미 인간 분석가를 무력화하기 위해 문자열을 난독화(obfuscate)하고 바이너리를 패킹(pack)합니다. 여기에 AI 분석가를 겨냥한 프롬프트 인젝션 페이로드(prompt injection payload)를 추가하는 것은 논리적이고 저렴한 다음 단계이며, 악성코드가 실제로 실행되는 방식에 어떠한 변경도 요구하지 않습니다. 이는 대상(target)을 공격하는 것이 아니라 도구(tooling) 자체를 공격하는 무료적인 방법입니다.
더 광범위한 산업 차원에서 볼 때, 이것은 패턴 속의 또 다른 데이터 포인트입니다. 우리가 기존의 신뢰 경계(trust boundary)에 LLM을 부착할 때마다, 그 경계는 이전 도구로부터 상속받는 것이 아니라 처음부터 다시 검토되어야 합니다.
열린 질문 (Open question)
AI 리버스 엔지니어링 에이전트가 자신에게 거짓말하도록 특별히 제작된 바이너리를 읽을 때, 그 에이전트가 제공하는 요약 정보가 악성코드의 최종 페이로드(final payload)가 아님을 어떻게 알 수 있을까요?
— Cor, Skyblue Soft
출처 (Sources)
AI 지원 초안 또는 이미징, 인간 큐레이션, 검토 및 편집.