Home AI로 취약점 찾기 후기
Post
Cancel

AI로 취약점 찾기 후기

AI로 버그바운티를 해보면서 느낀 후기입니다.

LLM은 취약점을 얼마나 잘 찾을까?

취약점을 찾는 과정에서 느낀 지극히 개인적인 후기이며, 부정확한 내용이 포함되어 있을 수 있습니다.

최근 LLM의 성능이 비약적으로 향상되었다고 느껴져 해외 버그바운티를 진행했습니다.
오픈AI의 GPT 5.6 soldaybreak blue를 사용하여 취약점 2건을 제보를 했는데 실제 취약점으로 인정될지는 모르겠습니다.

두 모델을 사용하면서 가장 크게 체감한 부분은 자율성을 상당히 높혀줘야 원하는 결과를 얻을 수 있다는 점입니다.

GPT-5.4를 사용할 때는 Skill과 Agent에 다양하고 세부적으로 하네스를 구성하였습니다.

이번 모델들을 사용하면서 오히려 이런 제약을 많이 설정할수록 취약점을 잘 찾지 못한다는 느낌을 많이 받았습니다.

물론 솔루션 처럼 일관된 결과를 얻는 것이 목적이라면 충분한 하네스를 구성해야하겠지만, 유효한 취약점을 찾으면 되는 상황에서는 오히려 자유롭게 두는 편이 조금 더 나은 결과를 얻을 수 있을 듯 합니다.

처음 하네스를 구성했을 때는 취약점 분석에 참고할 수 있는 여러 링크를 많이 제공하여, 해당 자료를 기반으로 분석하도록 유도했을때 보다, LLM이 직접 오픈소스를 다운받고 Docs를 읽고 필요한 정보를 알아서 찾을 때 더 정확하고 다양한 Finding의 후보군을 보여주었습니다.

물론 이 Finding 들을 그대로 제출하면 쓰레기 보고서가 되기에 검증을 하고 진짜 유효한지를 확인해야 합니다.

LLM으로 검증 하기

버그바운티뿐만 아니라 일반적인 취약점 분석에서도 가장 중요한 부분은 발견한 취약점이 실제로 유효한지 검증하는 것이라고 생각합니다.

"내가 찾은 취약점도 아닌데, 어떻게 빠르고, 정확하게 검증할 수 있을까?" 라는 고민이 있었습니다.

그래서 Finding을 검증할 때 3 가지의 원칙을 적용했습니다.

  1. 취약점 유형과 영향도 파악
  2. 취약점이 발현되기 위한 전제 조건 확인
  3. PoC를 통한 실제 재현 가능 여부 확인

가장 먼저 취약점의 유형과 예상 영향도를 확인했습니다.

영향이 클수록 분석할 가치가 높기 떄문에 이를 기준으로 LLM이 제시한 여러 Finding 중 우선적으로 검증할 대상을 선별했습니다.

다음으로 취약점이 실제로 발현되기 위한 전제 조건을 확인했습니다.

현재 주어진 환경에서 해당 조건을 만족할 수 있는지 확인하고, 직접 만족할 수 없다면 전제 조건을 우회하거나, 충족 시킬 방법이 있는지를 추가 검토를 했습니다.

마지막으로 PoC를 작성하여 실제 재현 가능성을 확인했습니다.

개인적으로는 요즘처럼 AI를 활용해 많은 Finding을 빠르게 만들어낼 수 있는 환경에서는 단순히 “취약해 보인다”는 설명만으로 유효한 취약점임을 증명하기 어렵다고 생각합니다.

따라서 PoC와 실행 결과, 스크린샷 등의 증적을 함께 제공하여 제3자가 동일한 환경에서 쉽게 재현하고 검증할 수 있도록 만드는 것을 중요하게 생각했습니다.

보고서 작성하기

마지막은 취약점 보고서 작성입니다.

보고서 역시 AI에게 별도의 기준 없이 작성을 맡기면 필요 이상으로 길고 장황해지고, 정작 취약점의 핵심을 직관적으로 파악하기 어려운 결과 물이 만들어집니다.

이를 해결하기 위해서 6가지의 항목을 중심으로 최대한 간결하게 작성하도록 했습니다.

마지막으로 보고서를 작성해야하는데 보고서 또한 AI에게 무작정 맡기면 쓸데없이 길고 장황하고 직관적으로 이해하기 어려운 보고서가 완성됩니다.

이를 해결하기 위해 6가지를 소제목과 최소한으로 작성되도록 하였습니다.

  1. 현재 상태 및 환경 정보
    • 제품 및 버전 정보 등
  2. 취약점 설명 및 영향도
    • 핵심 내용을 3줄 이내 작성
  3. 단계별 재현 방법 `
    • Step-by-Step 형태로 작성
  4. PoC 및 증적
    • PoC 코드 및 실행결과, 스크린샷
  5. 취약점 발생 원인
    • Root Cause 및 데이터 흐름 설명
  6. 대응 방안
    • 취약점의 근본적인 해결 방법 제시

이 중 특히 신경 쓴 부분은 5. 취약점 발생 원인 입니다.
취약점이 발생하는 과정을 DFD(Data Flow Diagram)를 활용하여 공격자의 입력이 어디에서 시작되고, 어떤 소스들을 거쳐 최종적으로 취약점 지점에 도달하는지 최대한 직관적으로 표현했습니다.

또한 가능하면 어떤 파일의 몇 번쨰 라인에서 부터 어떤 함수와 파일을 거치는지 함께 표시했습니다.

이렇게 작성할 경우 보고서를 처음 보는 사람도 전체 코드를 분석하지 않더라도 취약점의 발생 원인과 흐름을 비교적 빠르게 이해할 수 있도록 했습니다.

Conclusion

AI를 쓰면 쓸수록 하루빨리 금융권에도…. 망분리 완화가 시급하다고 느껴집니다.