트윗 보다가 kitploit에 눈길가는 툴하나 올라와서 간략하게 정리해봅니다. ClusterFuzz라는 도구로 Google에서 사용하고 있는 퍼징 인프라(?) 라고 합니다.
CusterFuzz 자체는 퍼징 도구인데, 이를 다른 시스템들과 연결하여 마치 하나의 인프라 처럼 동작한다는 의미인 것 같습니다.
구조
도구 자체의 기능이나 그런 것 보다는 구조가 조금 더 중요하단 생각이 들어 조금 찾아봤습니다. 우선 구글의 oss-fuzz와 연결되어 오픈소스 코드(예를들면 크로미움)에 대해 퍼징하고 자동으로 리포팅하는 형태로 구성되어 있습니다.
이런 과정에서 ClusterFuzz는 실제 퍼징을 담당하게 되는거죠. 발견 사항은 자동으로 BTS로 리포팅하고(대상은 모노레일) 개발자에게 노티되는 형태로 동작합니다.
What is ClusterFuzz?
그럼 ClusterFuzz가 일반적인 Fuzzer, Fuzzing framework와 다른점이 뭐가 있을까요? 구글 공식 내용으론 이렇습니다.
- Highly scalable : 스케일업/다운이 쉽게 가능한 퍼저?
- Accurate deduplication of crashes.: 완전한 중복제거
- Fully automatic bug filing and closing for issue trackers : 이슈둥록(BTS)까지 전자동화
- Testcase minimization. : 테스트 케이스 최소화
- Regression finding through bisection. : 직역으론 이분법을 통한 회기 분석이라는데 정말 저 의미인지는 모르겠네요..
- Statistics for analyzing fuzzer performance, and crash rates. : 성능, 통계 제공
- Easy to use web interface for management and viewing crashes. : 웹 잘 만들어놓음
- Support for coverage guided fuzzing (e.g. libFuzzer and AFL) and blackbox fuzzing. : blackbox 테스트 가능하고 퍼징에 대해 가이드?
제가 제일 관심있게 생각되는걸로 보면 이슈 등록 전자동화, 테스트 케이스 최소화 정도가 되겠네요.
Fully Automatic bug managing
BTS, 즉 이슈 관리 도구의 API 사용 등으로 솔직히 쉽게 구축할 수 있는 부분이라고 생각합니다만, 이에따른 리스크를 얼마나 적절히 해결했는가가 중요한 것 같습니다.
일반적인 취약점 분석에서도 이슈 등록/처리에 대해 어느정돈 자동화할 수 있지만 문제가 되는게 이슈의 타당성, 중복여부, 환경에 따른 다른 처리? 정도가 발목을 잡을텐데요. 여기서 중복의 경우는 위에 완전하게 제거 했다고 하니..없다고 치고 나머지 2개에 대해 생각해봐야 할 것 같네요.
이슈의 타당성의 경우 자동으로 등록된 이슈가 진짜 이슈인지, 처리할 수준의 가치가 있는 이슈인지 구별할 수 있냐가 성능적인 관건이 될거라 생각합니다. 저도 예전에 이슈 자동화에 대해 고민을 좀 했었는데, 결국 다가온 문제가 이 문제였습니다.
두번째도 방금 이야기한거긴한데, 환경에 따라서 이슈에 대해 어떻게 구별할까입니다. 예를들어 A에서 XSS 취약점이 발견되었는데, 이게 B에서는 이슈가 아닐수도 있는 경우입니다. 이유가 단순하다면 상관없겠지만, 여러 취약점/버그, 이에따른 여러가지 상황이 접목되면 코드단에서 판단하기 까다로워집니다. 결국은 사람의 개입이 어느정도 들어갈질 수 밖에 없고, 그런 경우 전체 자동화라곤 이야기하기 어려워집니다.
구글이 얼마나 잘 구현했는가가 중요하겠지만, 외부에 오픈할 수 있을 정도의 프로젝트라면 머리를 많이 굴렸을거라 생각되네요! 갓구글
Testcase Minimization
테스트 케이스 최소화란 의미가 아마 이런걸로 쓰인게 아닐까 싶습니다.
사용자가 테스트해야할 케이스에 대한 최소화 ** **기본적으로 여러가지 필터+검색 조합으로 의미있는 결과 위주로 보는게 베스트이고, 별도의 테스트 케이스 업로드로 특정 대상/특정 버그에 대해 쉽게 테스트할 수 있도록 지원해주는 것 같습니다. 이런 방식은 외부에서 수집한 테스트 케이스, 공격코드에 대해 좀 더 체계적으로 테스트할 수 있고, 여러 타겟에 대해서도 체크해보기 좋을 것 같네요(아무래도 발견된 부분이 다른 시스테멩서 영향을 줄 수 있기 때문이죠)
How to use?
ClusterFuzz는 GCP(Google Cloud Platform)에서 동작하도록 구성되었지만, 별도로 로컬 환경에서도 구동될 수 있습니다. (다만 구글 클라우드 서비스쪽 의존성이 있어서 잘될지는 모르겠네요)
git clone https://github.com/google/clusterfuzz cd clusterfuzz
프로덕션에 적용하려면..
gcloud auth application-default login gcloud auth login
or
local /install_deps.bash
$source ENV/bin/activate
$python butler.py --help
** **아 확인해보니 테스트 목적으로 로컬에서 쓰는건 의존성 괜찮다고 하네요! ** **서버 실행하려면. butler.py 돌려줍니다.
python butler.py run_server --bootstrap
봇 구동은..
python butler.py run_bot --name my-bot /path/to/my-bot
Conclusion
본질적으로 클라우드 서비스를 위한 툴이지만 구성이나 방식, 문제 해결에 대한 부분은 참고할게 많을 것 같습니다. 혹시나 비슷한 프로젝트를 구상하고 계신다면 충분히 참고해볼만할 것 같네요 :)
References
https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html https://google.github.io/clusterfuzz/ https://github.com/google/oss-fuzz https://github.com/google/clusterfuzz