퍼징5: 퍼징의 정의 / 역사 / 목적 / 기타 등등

검색 키워드: History of Fuzzing, Fuzzing History

 

퍼징의 정의

https://fuzzinginfo.wordpress.com/history/

퍼징은 컴퓨터 프로그램의 입력에 유효하지 않거나, 예상하지 못한 랜덤한(무작위) 데이터를 생성하고

생성한 데이터의 입력으로 발생할 수 있는 어플리케이션의 충돌(crash)나 예외적인 조건(?)에 대한 모니터링을 포함하는 소프트웨어 테스팅 기법

 

https://www.wired.com/2016/06/hacker-lexicon-fuzzing/

 

퍼징은 해킹할 수 있는 소프트웨어 버그를 찾아내는 자동화된 프로세스

취약점이 드러날 때까지 변형된 데이터를 타겟 프로그램으로 무작위적인 입력하는 것

 

오래된 기법이지만 요즘 해커들이 exploit할 취약점을 찾는 데도, 방어자가 먼저 찾아내어 고치는 데도일반적인 프로세스가 되고 있음

 

"Fuzzing: Brute Force Vulnerability Discovery"의 저자이자 사이버 보안 회사 InQuest의 최고 기술 책임자(chief technology officer)인 Pedram Amini는 리버스 엔지니어링과 비교하여 퍼징은 dumb한 과학의 일종이라 말한다

 

퍼징은 그저 프로그램의 엄청나게 많은 데이터를 던지고 그것을 빠르게 변형하며 소프트웨어의 모니터링에 의존하여
뭔가 나쁜 일이 일어나는 것을 찾아내길 기다린다.데이터 흐름을 세심하게 매핑하여 버그를 찾아내는 대신에... 많은 버그를 빠르게 찾아낼 수 있다

 

소프트웨어 시장에서 퍼징을 활용하는 것은 개발 사이클에서 standard part가 되었고이는 훌륭한 투자이고, 세계의 보안 향상을 돕고 있다.

 

https://labs.f-secure.com/blog/what-the-fuzz/ 

https://www.notion.so/What-the-Fuzz-40f7ffaa94814d2d8fbf52a9a2407551
fuzzing이란 자동화된 소프트웨어 테스팅 기술로써 프로그램내부에 존재할 수 있는 취약점을 찾아내는 것이다.

 

단순화된 fuzzing은 브루트포스와 마찬가지로 무작위로 입력값을 보내는 방식으로 진행할 수 있다. 그러나 발전된 fuzzing techniques은 소스코드나 바이너리를 분석하여 입력값을 생성한다

 

https://cpuu.postype.com/post/3419500 Fuzzing: Art, Science, and Engineering

직관적으로, 퍼징은 "PUT(테스트 대상 프로그램)에 Fuzz 된 입력값을 넣고 실행하는 행위"를 지칭

Miller 교수의 연구를 계승하여, 'Fuzz 된 입력값'이란 대상 프로그램이 예측하지 못한 입력, 즉 PUT이 해당 값을 잘못된 방식으로 처리하게 만듦으로써 PUT 프로그램의 원개발자가 전혀 의도하지 않은 행동을 유발할 수 있게 된다.

 

정의하자면,

Fuzzing is the execution of PUT using input(s) sampled from an input space (the “fuzz input space”) that protrudes the expected input space of the PUT.

퍼징(Fuzzing)은 PUT(테스트 대상 프로그램)의 예상 입력 공간을 벗어나는 입력 공간(이를 "퍼즈 입력 공간"이라 한다)에서 추출한 입력을 사용하여 PUT에 대해 실행하는 것이다. 

 

이때, 다음과 같은 3가지 사항을 염두해야 한다.

1. 일반적으로 퍼즈 입력이 예상된 입력 범위 안에 포함되어야 하는 것처럼 보이지만, 이것은 꼭 필수적인 사항은 아니다. 후자에 없는 입력이 전자에 포함될 수 있다.
2. 실무적으로 퍼징을 수행할 때에는 거의 필연적으로 많은 작업을 반복 실행하게 된다. 때문에 "반복된 실행"이라고 지칭하는 것이 적절하다.
3. 샘플링을 수행하는 과정이 반드시 무작위적이어야 할 필요는 없다.

퍼즈 테스팅이 다른 테스팅 분야와 차별화되는 가장 큰 목적은 프로그램의 충돌 현상을 비롯한

보안 관련 취약점을 찾아내는 데에 중대한 관심이 있다는 것

 

이하 Fuzz testing, Fuzzer, Fuzz Campaign에 대한 설명.

Fuzzing과 Fuzz Testing을 구분하고 Fuzz Testing과 Fuzz Campaign을 구분한 것이 특징.

 

목적

https://cpuu.postype.com/post/3419500

PUT에 퍼즈 캠페인을 수행하는 목적은, 요구되는 특정 보안 정책을 위반하는 버그를 찾아내기 위함이다.

 

+버그 오라클(Bug Oracle)의 개념이 나옴

+퍼즈 알고리즘(Fuzz Algorithm)의 개념이 나옴

PUT으로 전달되는 매개 변수에 따라 좌우되는데, 이에 대한 구체적인 설정을 "퍼즈 환경서렂ㅇ"이라고 부름

보통 튜플로 전달, {(PUT)}, {(PUT, s1, r1), (PUT, s2, r2),...}등 수식...

 

이하 퍼즈 알고리즘...

 

 

 

 

 

[인터넷 브라우저를 퍼징하려면?]

컴퓨터의 메모리에서 프로그램이 실행하는 모든 커맨드를 추적하기 위해 디버거툴로 브라우저를 열고,
퍼징 프로그램을 통해 동작하도록 디자인된 자신의 웹 서버에 접속하도록 한다.

퍼저는 HTML과 자바스크립트를 변형하며 몇 천에서 심지어 몇 백만개의 다른 웹 페이지를 생성하고
타겟 브라우저에 로드하여 어떻게 반응하는지 확인한다.

며칠에서 몇 주, 몇 달이 소요될 수도 있으며 해커는 입력 중 하나에 대한 응답으로 브라우저가 수천 번 충돌한 로그를 갖게 된다.

 

https://www.notion.so/d2d23293c4214a2a85c93f43fd0ca85a

퍼징이란 프로그램에서 취약점을 찾아내는 소프트웨어 테스팅 기술.

소프트웨어에서는 버그를 찾는게 목표였으나 보안쪽에서는 버그에서 익스플로잇터블한 버그를 발견하는게 차이점임.

 

자동으로 찾게하면 준비를 하는데에 시간이 오래걸린다. 따라서 결국 사람의 노력이 들어가는 것,

따라서 비용과 시간은 적게드는것 같지만 의외로 투자해야하는 시간이 길다.

 

이론적으로는 퍼저가 모든 버그를 찾을 수 있으나, 현실적으로는 모든 버그를 찾는건 불가능, 따라서 퍼저가 버그를 못찾는다고 안전한게 아님.

 

 

퍼징은 전혀 새로운 기법이 아니다.

https://fuzzinginfo.wordpress.com/history/

장점1

SSTIC09-article-A-Takanen-Fuzzing-the_Past-the_Present_and_the_Future

퍼징은 심각한 보안 취약점을 찾아내기 위함이다 고도화된 취약점은 못찾아낸다고 하던데?

보안 취약점을 찾아내는 테스트의 타이밍 또한 소프트웨어의 총 비용에 큰 영향을 미침

 

퍼징의 일반적인 이점: 보안 관련 버그 발생 및 수정과 관련된 비용

 

소프트웨어 제품 보안은 특별한 추가 속성이 있다.

소프트웨어 유지 관리, 패치 배포 및 인시던트로 인한 손상으로 인해 발생하는 비용은 

소프트웨어의 최종 사용자에게 실제로 발생한다는 것이다.

다시 말해 보안에 대한 손상과 DoS는 소프트웨어 개발자가 아닌 사용자에게 영향을 미친다는 것이다.

또한 이것은 소프트웨어 취약점의 가치와 관련된 비용 지표(cost metrics)에 개발자의 수리 비용과
최종 사용자(end-user)의 손상 비용이 모두 포함되는 이유이다

 

These are often the very same metrics that you might have developed

for analyzing "the needs for static analysis tools"

이것은 정적 분석 도구가 필요한 분석을 할 때도 동일하게 적용된다(X)
이것은 정적 분석 도구의 필요성을 분석할 때도 동일하게 적용된다.

 

소프트웨어 생명 주기의 어느 시기(phase)에 테스트 노력을 집중하느냐에 따라

버그 당 비용은 바뀔 것이다.

(빨리 발견할 수록 출시 이후 발견하는 것보다 비용이 적다)

 

This type of analysis is not easy for static analysis tools due to the rate of false positives, indicated flaws that do not have any significance from security perspective. 

A metric collected early in the process might not give any indication of the real cost saving. 

(뭔소린지)

 

Whereas static analysis tools create poor success rate based on analyzing the real security impact of the found flaws

정적 분석 도구는 발견된 결함의 실제 보안 영향을 분석하여 낮은 성공률을 가진다. (?)

장점2

다른 관점의 장점...

 

수동테스트는 분석자의 기술력에 굉장히 의존적이다. 그러나 fuzzing을 사용하면 서로 다른 종류의 버그를 찾을 수 있다. 또한 분석자의 손을 벗어나도 계속해서 분석이 가능하기 때문에 효율적이다.

이슈

fuzzing은 훌륭하고 값싼 기술이지만 최적의 방안은 아님.
왜냐하면 fuzzing을 하기위한 토대를 만드는데 많은 시간이 걸린다.

fuzzing을 통해 많은 취약점을 발견하면 취약한 프로그램이라고 할 수 있으나,
취약점이 나오지 않는다고 해서 취약점이 없는 프로그램은 아니다. 즉, fuzzing만으로 보안성을 평가하기 어렵다.

fuzzer는 무의미하고 익스플로잇터블하지 않은 많은 버그들을 만들 수 있다.
따라서 검토프로세스가 항상 필요하고, 수동으로 해야만 가장 정확한 검토가 가능하다.

 

 

입력을 받는 타겟 프로그램이 필요하다.(프로그램이 복잡할 수록 더 많은 버그를 찾을 가능성이 높다.)

 

어떤 프로그램인지 어떤 버그를 찾을 것인지에 따라 어떤퍼저를 사용할지 고민해야한다.(그렇지 않으면 처음부터 작성해야함.)

 

찾아낼 수 있는 버그의 종류

이론적으로 fuzzing통해서는 모든 종류의 버그를 찾을 수 있다

fuzzing을 할때 프로그램의 행동이 의도된것인지 잘못된 것인지 구별할 메카니즘이 필요하다

메모리 corruption같은경우 fuzzing을 통해 찾아내기 쉽지만, 논리 취약점의 경우에는 탐지하기가 어렵다

(논리 취약점에는 어떤 것들이 있는지)

---

Testcase Generator

새로운 테스트케이스 작성을 담당한다. 즉, 입력값을 만들어 내는 곳.
입력값의 구조를 알고 test case를 만드는 것은 smart fuzzer.
입력값의 구조를 모르고 무작위로 test case를 만드는 것은 dumb fuzzer.
test case는 처음부터 생성되거나, 이미 존재하던 test case를 변조하여 생성된다.

---

Guided Fuzzing

테스트케이스 생성기를 이용하여 test case를 만드는 것은 품질의 차이가 따른다.
따라서 어떤 test case에서 어떤 부분을 조작하여 입력값을 만들지에대한 고민이 필요하다.

이에 대한 일반적인 지침은 code coverage이다.

이론적으로 code coverage가 클수록 더 많은 버그를 찾을 수 있다.

---

Dumb Fuzzing

입력구조 모델이 필요없는 방식을 Dumb fuzzer라고 한다.

장점으로는 입력구조의 정보 없이 가능하기 때문에 많은 다른 프로그램들에 적용이 가능하다.

가장 큰 단점은 입력에 미리 정의된 구조가 필요하거나,

체크섬이 존재하는 경우 fuzzer가 유효한 입력값을 만들어 내기까지 상당한 어려움이 존재한다.

 

https://www.notion.so/d2d23293c4214a2a85c93f43fd0ca85a

C로는 /dev/random값을 활용하여 랜덤값을 뽑아낼 수 있다.

혹은 Radmasa를 이용하여 값을 mutation하는 방법도 존재한다.

테스트 케이스 생성기가 만들어 내는 값은 품질적인 차이가 크다.

 

그래서 어떤 값을 변경할지에 대한 지침이 필요하다.

이러한 경우 코드의 실행범위가 넓을 수록 더 많은 버그를 만날 수 있다.

 

고로 Coverage guided fuzzing이 효율이 좋다고 할 수 있다.

만약 Dumb fuzzing을 한다면 타겟 프로그램에 대한 이해도가 없어도 된다. 그냥 입력값을 때려 박는것이다.

Smart Fuzzing

Dumb fuzzer와는 반대로 입력구조 모델이 필요한 방식을 Smart fuzzer라고 한다.
필요한 입력구조 파일을 input model이라고 한다.

Smart fuzzing의 장점으로는 입력값이 주로 유효한 값이며 실제 프로그램에서 높은 code coverage를 갖는다. 그러나 단점으로는 입력값이 정형화되어 있기 때문에 특정버그를 찾는데 한하여 효과적이고, 상당히 우수한 입력모델이 필요하다.

 

---

Mutation based Fuzzing

존재하는 test case를 변형하여 test case를 생성한다.

주로 bit flipping을 사용하며, 랜덤으로 bit flipping을 하고, 움직이거나, 지우거나 반복하는 형태로 진행된다.

장점으로는 설정작업이 많이 필요하지 않다는것이다

 

Generation based fuzzing

처음부터 test case를 생성한다. 또한 입력파일의 구조를 알고 있어야한다.

그러나 한번 실행하게 되면 Mutation based fuzzer보다 높은 coverage를 생성하는 경향이 있어서 고유한 버그를 발견할 가능성이 높다.

 

---

블랙박스 테스트(black box test)

소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식.

올바른 입력과 올바르지 않은 입력을 입력하여 올바른 출력이 나오는지 검사한다.

화이트 박스 테스트(white box testing)

응용 프로그램의 내부 구조와 동작을 검사하는 테스트 방식. 소프트웨어 내부 소스 코드를 테스트 하는 기법. 개발자 관점의 단위 테스트 방법. 구현 기반 테스트. 소스코드 동작을 추적 할 수 있다.

⇒ 이때 커버리지를 측정하여 완성도를 확인한다.

---

어원

탄생 배경 1980년대~

[fuzz!]

바튼 밀러 교수, 폭풍우가 치는 동안 원격으로 전화 링크를 통해서 유닉스 시스템에 원격으로 로그인

이는 전화 링크에서 많은 interference noise를 발생시켰고

회선 밖에서 데이터를 사용하고 있는 응용 프로그램들에서 crash가 발생하게 됨

 

또 다른...https://www.wired.com/2016/06/hacker-lexicon-fuzzing/

1987 위스콘신 대학교 Barton Miller 집에 있는 터미널을 통해 사무실에 있는 데스크톱 VAX 를 사용하려 함

그러나 오류 수정 기능이 없는 구식 모뎀을 사용하여 전화 라인을 통해 UNIX 시스템에 연결하고 있었고

천둥번개가 치면서 입력하는 명령어에 계속 noise가 발생하고 프로그램이 계속 충돌함

 

 

[최초의 fuzzer]

이 현상을 바탕으로 밀러 교수는 계속해서  “Operating System Utility Program Reliability – The Fuzz Generator”라는 프로젝트를 진행하였다.

학생들은 유닉스 프로그램의 안정성을 테스트하기 위해 무작위 데이터로 폭격을 가하고 충돌 여부를 감시하는

basic command line fuzzer를 개발하였다.

 

[fuzzing]

스티브는 Mac 컴퓨터가 이전에 기록된 동작을 재생함으로써 스스로 demo할 수 있는 "Jornaling Hook"을 활용한 도구를 쓰고 있었음 이 소프트웨어는 스티브에 의해 아래와 같이 용도 변경

Steve Capps가 임의의 마우스 클릭과 키보드 입력을 만들어 MacWrite와 MacPaint를 테스트하기 위한 프로그램을 제작,

보이지 않는 원숭이가 컴퓨터를 불규칙하게 사용하는 것처럼 보여 원숭이(The Monkey)라고 명명

---

https://fuzzinginfo.files.wordpress.com/2012/05/fuzzing-1.pdf

1999년 Oulu 대학에서 PROTOS가 제작됨

          PROTOcol에 특화되어 분석하기 위해 시작됨

          여러 제조사의 제품에서 사용될 수 있도록 설계됨

 

2002년 최초의 상업 퍼저, Microsoft에서 PROTOS에 투자,

           PROTOS의 일부 멤버가 나와서 Codenomicon이라는 회사를 설립

 

          SPIKE fuzzer 공개됨 (Dave Aitel이 씀)

          - 밀러의 fuzzer가 dumb이라면, SPIKE는 genius이다

          - 데이터를 describe할 수 있는 능력

          - 잘 알려진 프로토콜에 대한 Built-in 라이브러리(ex. RPC)

          - 소프트웨어가 결함을 일으키도록 designed 고안된 fuzz strings

 

2004년 브라우저 퍼징, HTML을 Fuzz하여...

          MangleMe, (Michal Zalewski 제작)

 

          파일 포맷 퍼징, Microsoft Security Bulletin MS04-028을 발견

          Buffer Overun in JPEG Processing, RCE 가능

          https://scienceon.kisti.re.kr/srch/selectPORSrchReport.do?cn=TRKO201100004909&SITE=CLICK 에 자세한 내용..

          https://www.ibric.org/search/?category=EXTS&subcategory=NDSLR&kwd=cve 여기 KISA R&D 산업보고서

 

2005년 파일 포맷 퍼저 Release

          FileFuzz, SPIKEfile, notSPIKEfile 등

 

          더 많은 브라우저 퍼저 Release

          Hamachi, CSSDIE

 

2006년 브라우저 버그의 달(Month of Browser Bugs)

 

          ActiveX 퍼징

          COMRaider, AxMan

 

2007년 더 많은 브라우저 퍼징

 

 

년도 설명하면서 원형 이어지는...그런 디자인 적용하면 좋을듯함

 

[퍼징의 과정]

---

[오늘날의 퍼징]

 

 

 

연도별 주요 논문

https://fuzzinginfo.wordpress.com/papers/ 

https://wcventure.github.io/FuzzingPaper/

 

 

 

 

 

주요 사이트

https://fuzzinginfo.wordpress.com/resources/

ㄴ https://fuzztest.wordpress.com/

    ㄴhttps://pages.cs.wisc.edu/~bart/fuzz/fuzz.html 1988년엔 뭐 했고 2000년엔 Windows에서 2006년엔 Mac에서...