Google에서 9만 달러 포상금을 받은 원격 코드 실행 취약점을 발견한 과정
요약
본 기사는 Google에서 9만 달러의 포상금을 받은 원격 코드 실행(RCE) 취약점 발견 과정을 다루고 있습니다. 필자는 소프트웨어에 버그가 있다는 점을 강조하며, 취약점을 찾는 과정은 결국 '어디를 봐야 하는지 아는 안목'이 중요하다고 주장합니다. 또한 AI 도구의 발전에도 불구하고 인간 연구자의 고유한 통찰력과 능력이 여전히 핵심임을 역설합니다.
핵심 포인트
- 모든 소프트웨어에는 버그가 존재하며, 취약점 발견은 체계적인 과정으로 접근 가능함.
- 취약점을 찾는 능력은 단순히 도구 사용을 넘어선 깊은 안목과 경험이 요구됨.
- AI는 강력한 보조 도구일 뿐이며, 최종적인 연구 방향 설정과 통찰력은 인간의 영역임.
- 버그 바운티 분야에서는 발견 과정보다 취약점 자체의 가치와 신고가 중요함.
“네 가지가 바뀌어야 했고, 그 효과는 누적됨” 같은 Claude 특유의 문구가 나오면, 글 내용은 읽지 않고 그런 표현만 찾으며 훑게 됨.
소재가 흥미로워 보이면 일단 LLM으로 요약하고, 실제로 흥미롭거나 설득력이 있으면 더 깊이 읽는 편임.
나도 그렇게 읽게 되며, 관련 밈도 몇 개 봤음. ai;dr은 tl;dr의 진화형인 셈임.
이런 코드가 어떻게 코드·설계 검토를 통과하는지 모르겠음. 문제가 된 코드도 AI가 작성한 것인지 궁금함. 쿠키에 서명하는 키를 쿠키 자체에 넣었을 뿐 아니라, 모델 가중치 저장에서도 벗어나고 있는 pickle까지 사용함. 원인이 너무 초보적인 실수라 당황스러움.
pickle 사용은 황당하지만, 문제를 진단하다 객체 전체를 쿠키에 넣고 나중에 정리하는 걸 잊었을 가능성은 상상할 수 있음.
우리 회사라면 코드 검토는커녕 자동화 테스트부터 통과하지 못함.
직원의 태도가 “조직과 사명에 적극적으로 헌신하자”에서 “그냥 직장일 뿐이니 쉬면서 주식 보상이나 챙기자”로 바뀌면 그렇게 됨.
지나치게 가혹한 평가로 보임. 당신과 내가 쓴 코드, Google, iOS, 로켓 발사 소프트웨어까지 모든 소프트웨어에는 버그가 있음. 버그를 잡는 체계를 마련할 수 있고, 이번에는 그 체계가 작동한 것임.
미리 발견하지 못한 이유를 묻지만, 쉬웠다면 9만 달러의 가치가 없었을 것임. 어디를 봐야 하는지 알고 나면 모든 것이 명백해 보이기 마련임.
Google 도메인 7곳에서 코드 실행이 가능한 취약점인데, 정말 싸게 해결한 셈임.
버그 바운티를 시작하려는 사람에게 해줄 조언이 있나요? 이런 취약점을 찾는 방법론이 있는지, 아니면 오랜 경험이 핵심인지 궁금함.
이런 고액 포상금의 시대는 거의 끝나가는 듯함. AI 도구가 보상 시세를 대략 토큰 비용 수준까지 끌어내릴 것임. 포상금은 연구자가 익스플로잇을 되파는 것보다 신고하는 편이 조금이라도 경제적으로 유리하도록 존재함.
취약점 포상금을 지급하는 쪽은 어떻게 발견했는지에는 별로 관심이 없음.
Claude가 해낸 일을 “나”가 했다고 반복해서 쓰는 건 대담한 선택임. 취약점도 Claude가 찾았고, 블로그 글도 딱 봐도 Claude가 작성한 듯함. 어쩌면 Claude가 1인칭으로 글을 써서 자기 이름 대신 “나”를 쓴 것일 수도 있음.
Claude를 써도 Google에서 9만 달러 포상금을 받기는 어려우니 성과를 깎아내려서는 안 됨. 다만 글 전체가 LLM 말투라 읽기 꽤 거슬림.
그렇게 주장하려면 적어도 Claude 대신 GLM 5.3이라고 해야 함. 특별히 허용된 집단에 속하지 않는 한, Claude는 이런 일과 조금이라도 가까운 작업은 거부함.
이런 피상적인 폄하는 논의에 아무런 도움도 주지 못함.
LLM은 도구임. 나도 Claude를 쓸 수 있었지만 이 버그를 찾지는 못했고, 작성자는 찾아냈음. 연구 방향을 고르는 안목 같은 능력은 여전히 사람 사이의 차이를 만듦.
AI가 다른 제약을 없애면 이런 능력은 오히려 더 중요해질 것으로 봄. 외모가 덜 매력적인 헤지펀드 매니저의 성과가 더 좋은 것과 같은 원리임.
그러면 최상위 성과자 집단의 구성도 바뀔 것임. 예술가·연구자·작가처럼 뛰어난 성과자의 정체성은 자신을 보호하려고 만들어내는 경우가 많아, 이런 변화가 문제가 됨. 한때 자신을 지켜준 가면이 결국 변화를 막는 감옥이 될 수 있음.
이런 작업을 Claude와 함께 수행하는 데 필요한 노력과 사전 지식을 과소평가하고 있음.
발견은 훌륭하지만 분석 글의 품질은 끔찍함. LLM보다 설명을 못할 것 같더라도 시간을 들여 직접 써주면 좋겠음. 차라리 프롬프트나 정리 전 메모를 공유하는 편이 이 글보다 훨씬 읽기 좋을 것임.
댓글 상당수의 논의가 이해하기 어려움. “당신이 아니라 Claude가 했다”는 건 LLM을 쓰면 인간의 주도성이 사라진다는 뜻인가요?
“원격 코드 실행 취약점을 찾는 데 어떤 LLM과 실행 도구의 도움을 받았다”처럼 사용 도구를 명시하는 관행이 필요할 수도 있지만, 상황에 따라 공개하지 않을 이유도 있을 것임.
덧붙이면, 이 주제의 큰 댓글 묶음은 신고 처리되어 일부에게 보이지 않을 수 있음.
당신의 안내와 지식 없이도 Claude가 찾았을지가 기준임. 그렇다면 Claude가 찾은 것이고, 아니라면 당신이 LLM을 이용해 찾은 것임. 많은 작업은 후자에 해당할 텐데, 전자로 몰아가며 깎아내리는 일이 흔함.
그 기준을 적용하려면 모든 일에 적용해야 함. 코드도 웹사이트도 당신이 아니라 Claude가 만든 것이라고 해야 함. 솔직히 그러면 업계가 덜 피곤해질 수도 있음.
“그렇게 쉬우면 왜 직접 하지 않았나요? 손쉽게 9만 달러를 벌 수 있었을 텐데요?”라고 되묻는 게 가장 좋은 대응임.
머지않아 이런 비판은 결함을 찾을 때 어셈블리 대신 고급 언어를 썼다고 탓하는 것과 같아질 것임.
자기가 먼저 Claude에게 시켜보지 못한 걸 질투하는 듯한 태도도 보임. 다만 Claude 사용 여부는 공개해야 함. “쿠키가 내 눈길을 끌었다”고 썼는데 실제로 주목한 게 Claude라면, Simon은 자신에게 없는 안목을 내세운 셈임.
“Claude가 9만 달러짜리 원격 코드 실행 취약점을 찾았다”고 해도 똑같이, 어쩌면 더 흥미로웠을 것임.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기