it-swarm-korea.com

코드 분석 : 이진 대 소스

소프트웨어 보안 평가를 수행하는 동안 컴파일 된 응용 프로그램 (예 : C++)의 소스 코드에 액세스 할 수있는 경우 자동화 된 기술을 사용하거나 수동으로 컴파일 된 버전을 분석 한 적이 있습니까? 퍼징이이 상황에서 적용 할 수있는 유일한 기술입니까 아니면 바이너리를 보는 데 다른 잠재적 이점이 있습니까?

14
TobyS

상황 (응용 프로그램 유형, 배포 모델, 특히 위협 모델 등)에 따라 다릅니다.

예를 들어, 특정 컴파일러는 코드에 표시되지만 (코드 검토 만족) 바이너리에는 표시되지 않는 (실제 테스트 실패) 미묘한 결함 (예 : 특정 검사 우회)을 도입하여 섬세한 코드를 크게 변경할 수 있습니다.
또한 특정 코드 수준 루트킷이 있습니다. C++을 언급했지만 예를 들어 관리 코드 루트킷 도 있습니다. .NET 및 Java-코드 검토를 완전히 회피하지만 배포 된 바이너리에는 표시됩니다.
또한 컴파일러 자체에는 특정 루트킷이있어 앱에 백도어를 삽입 할 수 있습니다. (- original rootkit 의 일부 기록을 참조하십시오. 컴파일러는 로그인 스크립트에 백도어 비밀번호를 삽입했습니다. 또한 "clean"코드에서 다시 컴파일 할 때이 백도어를 컴파일러 자체에 삽입했습니다. 다시, 소스 코드에서 누락되었지만 바이너리에 존재합니다.


물론 바이너리를 리버스 엔지니어링하는 것은 더 어렵고 시간이 많이 걸리며 이미 소스 코드가 있다면 most 시나리오에서는 의미가 없습니다.
이 점을 강조하고 싶습니다. 소스 코드가있는 경우 정리할 때까지 걱정하지 마십시오 RE로 정리하십시오 all 코드 검토, Pentesting, Fuzzing, Threat Modeling 등을 통해 발견 한 다른 취약점은 매우 민감한 앱이거나 매우 눈에 띄는 경우에만 귀찮게합니다.
Edge 사례는 찾기가 어렵고 다른 곳에서 노력을 더 잘 보낼 수있을 정도로 드물습니다.


다른 한편으로, 바이너리를 특별히 스캔하는 정적 분석 제품 (예 : Veracode)이 있으므로 그 중 하나를 사용하는 경우 실제로 중요하지 않습니다 ...

12
AviD

@AviD 솔리드 포인트는 바이너리/컴파일러 컴포넌트의 루트 키트에 전적으로 동의합니다.

지식이 풍부한 초급 전문가라면 AviD의 유효한 포인트를 따로 설정하면 대부분의 취약점이 소스 코드에있을 수 있습니다. 프로그래밍에 대한 강력한 지식과 리버스 엔지니어링이 수행되는 방법을 알고 있으면 소스 코드에서 대부분의 구멍을 수정/예방할 수있는 최상의 방법을 얻을 수 있습니다. 또한, 컴파일러/바이너리를 이용한 익스플로잇이있는 경우, 다른 컴파일러/언어 (보통 실행 가능한 옵션은 아님)를 사용하는 것 외에는 개발자가이를 막기 위해 할 수있는 일은 없습니다.

7
mrnap

보안 관련 사항 외에 최종 바이너리를 조사하는 데는 여러 가지 이유가 있습니다. 디버거, 디스어셈블러 또는 Valgrind와 같은 프로파일 러 및 에뮬레이터를 사용하여 컴파일 된 프로그램의 다양한 측면을 확인할 수 있습니다.

프로그램의 보안과 정확성은 대개 서로 밀접한 관련이 있습니다.

나를 위해 먼저 코드를 보풀 (예 : PCLINT 사용) 한 다음 이진 파일을 작성하고 (Falgrind의) fuzzer와 memcheck로 확인하고 견고성과 신뢰성에 관해서는 매우 좋은 결과를 얻었습니다. 이 경우 PCLINT만이 소스 코드에 액세스 할 수 있습니다.

4
0xC0000022L

이진 및 소스 코드 분석은 약간 다른 관점을 제공하므로 두 가지를 모두 적용해야합니다. 그러나 이진 분석은 인간에게 위협이 될 수 있습니다. 소스 코드 수준에서 분석하는 것이 어려울 수는 없지만 어셈블리 수준에서 응용 프로그램의 논리를 분석하는 것이 최선의 선택은 아닙니다. 이진 분석에서는 실제로 일어나는 일을 처리하고 그렇지 않으면 할 수 없습니다. 소스 코드에서 몇 가지 가정을 할 수 있다면 여기에 명확한 상태가 있습니다.

그러나 퍼징과 같은 테스트는 컴파일 된 애플리케이션에 대해 실행하여 최소한 어느 정도의 애플리케이션 견고성을 보장해야합니다. 코드 범위는 퍼징 방법론, 응용 프로그램 특정 사항 및 기타 요인에 따라 다릅니다. 여기에서는 설명하기가 너무 어렵습니다. 퍼지 기술입니다. 마이크로 소프트조차도 퍼징을위한 도구를 개발하고 SDL에 적용 . 다음은 프로세스에 대한 통찰력을 제공하는 Codenomicon의 논문입니다. http://www.codenomicon.com/resources/whitepapers/codenomicon-wp-sdl-20100202.pdf

2
anonymous

AviD가 암시했지만 강조해야 할 점이 있는데, 이는 코드 검토가 이진 검토보다 훨씬 많은 시간과 노력의 효과적인 프로세스 인 경향이 있다는 것입니다. 특히 C++의 경우 바이너리는 일반 개발자는 물론 일반 보안 전문가도 이해하기가 매우 어렵습니다.

해석되는 언어의 경우에는 그렇지 않습니다. 명확하지 않은 Java 및 .NET 바이트 코드는 사람이 읽을 수있는 것으로 다시 변환 될 수 있습니다.

0
Aaron

호환되는 바이너리에 대한 분석이 수행 될 때만 많은 보안 기능을 평가할 수 있으므로 바이너리를 보는 것이 항상 필요합니다. 예를 들어, 코드는 응용 프로그램의 논리에서 취약점을 암시하여 ASLR과 같은 특정 컴파일 기능 및 스택 실행 파일이 활성화 또는 비활성화되었는지 여부를 컴파일 된 바이너리가 알려줍니다. 이 정보는 단지 소스 코드를 보면 얻을 수 없습니다. 퍼징은 일반적으로 강제 취약점을 무력화하는 데 유용한 기술이지만 시간이 많이 걸리고 리소스가 많이 소요될 수 있지만 문제를 식별하는 데 의존하면 때로는 잘못된 결과를 얻거나 누락 될 수 있습니다. 따라서 이진을 분석하려면 radare2 또는 hopper와 같은 리버스 엔지니어링 도구가 필요합니다.

이진 대 소스 코드 분석을 비교하는이 리소스를 찾았습니다. 이것은 도움이되어야합니다 Binray vs source code analysis

면책 조항-나는 Appknox에서 일합니다

0
Chaitanya Gatreddi