클라이언트 측 보안 취약점은 일반적으로 어떻게 발견됩니까?

Question

운영체제 또는 해당 응용 프로그램을 의미합니다. 내가 생각할 수있는 유일한 방법은 strcpy()와 같은 위험한 함수의 사용법에 대한 바이너리를 검사 한 다음이를 악용하려고 시도하는 것이다. Visual Studio의/GS 스위치와 같은 컴파일러 기능이 향상되었지만이 가능성은 대부분 과거의 문제 일 것입니다. 또는 나는 틀린가?

사람들은 취약점을 찾기 위해 다른 어떤 방법을 사용합니까? 디버거에 타겟을로드 한 다음 예기치 않은 입력을 보내고 무슨 일이 일어나는지 확인하십시오. 이것은 길고 지루한 과정처럼 보입니다.

누구든지이 주제에 대해 좋은 책이나 웹 사이트를 추천 할 수 있습니까?

미리 감사드립니다.

Answer 1

"클라이언트 측 보안"과 관련된 두 가지 주요 문제가 있습니다.

오늘날 가장 많이 사용되는 클라이언트는 "Drive By Downloads"형태의 브라우저입니다. 대부분의 경우 메모리 손상 취약점이 발생합니다. ActiveX com 객체는 Windows 시스템에서 일반적인 경로였으며 AxMan은 훌륭한 ActiveX fuzzer입니다.

메모리 보호 시스템 측면에서/GS는 카나리아이며 버퍼 오버플로를 중지하는 데있어 모두 끝나지는 않습니다. 이는 리턴 주소를 겹쳐 쓰려고 시도하는 스택 기반 오버 플로우를 보호하고 EIP를 제어하는 ​​것을 목표로합니다. NX 영역과 카나리아는 좋은 일이지만 ASLR은 메모리 손상 공격을 막는 데 훨씬 뛰어날 수 있으며 모든 ASLR 구현이 똑같이 안전하지는 않습니다. 이 세 가지 시스템을 모두 사용하더라도 여전히 해킹 당할 수 있습니다. Windows 7에서 실행되는 IE 8은이 모든 것을 가지고 있으며 pwn2own에서 해킹당한 첫 번째 사람 중 하나였습니다. 여기에 how they did it입니다. Heap Overflow와 Dangling Pointer 취약점을 연쇄 적으로 연계시키는 것이 었습니다.

서버 측에서 비밀 리소스 (예 : 암호)를 사용하여 클라이언트를 신뢰하거나 플래시 게임에서 Players Score과 같은 중요한 정보를보고 할 때 "클라이언트 측 보안"문제는 CWE-602: Client-Side Enforcement of Server-Side Security입니다.

클라이언트 측 문제를 찾는 가장 좋은 방법은 트래픽을 살펴 보는 것입니다. WireShark는 브라우저가 아닌 클라이언트/서버 프로토콜에 가장 적합합니다. 그러나 TamperData은 플래시 및 JavaScript와 같은 브라우저 기반 플랫폼에 사용할 수있는 최고의 도구입니다. 각각의 경우는 프로세스 충돌을 쉽게 볼 수있는 버퍼 오버 플로우와 달리 클라이언트 측 신뢰 문제는 모두 컨텍스트에 관한 것이며 문제를 파악하기 위해 네트워크 트래픽을 살펴 보려면 숙련 된 인력이 필요합니다.

때때로 어리석은 프로그래머는 암호를 응용 프로그램에 하드 코드합니다. 그것의 사소한 데이터를 얻기 위해 응용 프로그램을 디 컴파일합니다. 플래시 디 컴파일은 매우 깨끗하며 완전한 변수 이름과 코드 주석을 얻을 수 있습니다. 또 다른 옵션은 OllyDBG와 같은 디버거를 사용하여 메모리의 데이터를 찾으려고 시도하는 것입니다. IDA-Pro는 C/C++ 응용 프로그램에 가장 적합한 디 컴파일러입니다.

Answer 2

Writing Secure Code, 2nd edition에는 위협 모델링 및 테스트에 관한 내용이 포함되어 있습니다.