제어 흐름은 그대로 두고 데이터만 바꿔 RCE를 내는 공격, 도구 Einstein이 자동 생성한다

퍼징이 원래 데이터 전용 공격 찾는 방법 아니었어? 저 첫 문장이 좀 이상하게 들리는데

퍼징으로 터지는 건 코드 실행 공격이랑 다름. 데이터 전용은 코드와 로직을 안 건드리고 플래그나 파일 경로 같은 데이터만 바꿔서 원래 로직을 재사용하는 건데, W^X나 stack canary, CFI가 여기선 아예 안 먹힘. 컴파일러 mitigation 발표마다 데이터-only가 한번씩 나오고 바로 학술적 호기심으로 치부되더라.

execve 인자만 바꾸는 거라서 GTFOBins 목록이 떠올랐음. setuid 환경에서 인자 하나로 우회되는 쉘 도구들이 꽤 있거든.

taint analysis가 저평가당한 기술이라는 생각이 듦. 역공학할 때 taint 흐름을 보기 쉽게 만든 UI만 나와도 상황이 달라질 텐데, over-tainting는 감수해야 하고.

그런데 taint analysis는 메모리 안전 버그가 이미 오염 안 된 데이터를 통째로 덮어쓰는 경우를 못 막음. 그건 secure enclave급 보호가 필요해.

이 도구가 또 LLM 래퍼가 아니라서 반갑더라. LLM이 어느 정도 쓸만해진 뒤로 HN 제출 품질이 확 떨어졌거든.

제목에 (2024) 붙은 것만 봐도 ChatGPT 이전 시절 연구임을 알 수 있음. 그런 도구에 LLM이 끼어들 자리가 없었지.

데이터 전용 공격은 사실 저과일이야. 고전적 정적 분석으로도 찾을 수 있고 LLM이 식별을 더 쉽게 만들었지. 진짜 무서운 건 환불 남용처럼 정상 비즈니스 로직을 악용하는 건데, 버그 헌터들은 그걸 리스크로도 안 침.

AFL 같은 비AI 퍼저도 아직 셈. Kimi한테 리눅스 커널 파일시스템 코드를 퍼징하라고 시키고 잤더니 재현자와 픽스가 딸린 크래시 26개가 나왔고, 지금 업스트림 올리는 중임.

예전에 클럽 라이브에서 게임 점수를 그냥 제출만 해도 Xbox 선물을 받았던 거 기억남. 나중에 찾아보니 직원들이 스스로 악용하려고 만든 구조였고, 거기서 msft가 수백만 달러를 잃었음.

근데 버퍼 오버플로우로 cgi_bin_path를 덮어쓰는 게 왜 데이터 전용 공격이지? 여전히 전통적인 방식으로 오버플로우를 써야 하잖아.

경계가 좀 모호하긴 해. 전통 공격은 ROP나 executable stack으로 공격자가 다음 명령어를 고르는 데까지 가는데, 데이터 흐름 공격은 끝까지 명령어 선택권이 없이 데이터만 바꿈. 그래도 버퍼 오버플로우는 여전히 필요해.

한마디로 DEP를 지키는 경로로 버퍼 오버플로우를 RCE까지 자동 연결해주는 거임. 전용 용어가 헷갈리게 만들 뿐이지.

복잡한 파일 포맷 다루는 코드의 상태 관리 쪽도 이런 도구로 털기 쉬울 듯. 상태 머신을 최대한 작게 만들고 정의를 수학자처럼 빡빡하게 잡는 수밖에 없음.

데이터로 악성 행동을 유도하는 건 interpreter eval injection이랑 똑같은 건데 50년도 더 된 기법 아니야? php, js, perl, 셸 호출, SQL 전부 다. 뭘 놓치고 있는 거지?

대부분 언어는 직접 eval을 안 주니까 그건 별개임. 나는 데이터 전용을 앱 특화 익스플로잇 프리미티브의 다른 말로 봐. 오버플로우로 instruction pointer를 못 건드릴 때 남는 게 그건데, 이 글 예시는 사실 커맨드 인젝션이고 앱 상태를 취약한 상태로 만드는 과정이 필요함.

그러면 저 도구가 nginx에서 미패치 익스플로잇 944개를 새로 찾아낸 거임? 표2에 confirmed exploits for nginx 944이라고 나오던데.