2017-02-03 8 views
-1

명명 된 파이프를 사용하여 두 응용 프로그램 간의 통신을 만들었습니다. 첫 번째 응용 프로그램은 CreateNamedPipe이라는 이름의 파이프를 만들고 두 번째 응용 프로그램에서 보낸 ReadFile으로받은 메시지를 읽습니다. 두 응용 프로그램 모두 의도 한대로 통신 할 수 있습니다.명명 된 파이프에서 메시지의 보낸 사람을 식별하거나 권한을 부여하는 방법은 무엇입니까? (CreateNamedPipe)

수신 메시지의 발신자를 식별 할 수 있습니까? 신원 확인 (보낸 사람의 exe 경로 가져 오는 것과 같은)이 없거나 다른 모든 응용 프로그램에서 해당 파이프를 사용하여 응용 프로그램에 메시지를 보낼 수 있습니다.

(편집) 더 자세한 사항은, 보인다 있기 때문에이 경우 중요 :
이 파이프를 작성하는 응용 프로그램이 Windows 서비스로 실행됩니다. 두 응용 프로그램은 모두 같은 시스템에서 로컬로 실행됩니다.

+0

직접 구현해야합니다. 파이프는 보안 개체이지만 Windows 용 보안 모델은 응용 프로그램 지향이 아니므로 사용자 지향적입니다. –

+0

적어도 메시지가 어디에서 왔는지 알아내는 방법이 없습니까? 명명 된 파이프를 통해 메시지를 보낸 파일의 핸들/이름/경로 같은 것이 있습니까? – CodeX

+0

@ CodeX는 직접적으로 사용할 수 없습니다. 발신자는 메시지 데이터 자체 내에서 자신을 식별해야합니다. 서버가 독자적으로 결정할 수있는 유일한 방법은 메시지를 보낸 앱을 실행하는 사용자 계정입니다. 그리고 그렇게하기 위해서는 서버가 [연결 클라이언트를 가장해야합니다 (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365573 (v = vs.85) .aspx)해야합니다. 사용자 정보를 검색하십시오.서버에 충분한 권한이있는 경우 ** 해당 로컬 시스템에서 열린 핸들을 열거하고 해당 사용자가 열고 핸들을 찾고 서버 파이프 이름을 가리킬 수도 있습니다 ... –

답변

1

GetNamedPipeClientProcessId()은 클라이언트 프로세스의 프로세스 ID를 제공합니다. 그런 다음 OpenProcess()을 사용하여 프로세스 핸들을 열고 GetModuleFileNameEx()으로 전화하여 해당 프로세스에서 실행중인 응용 프로그램을 확인할 수 있습니다. 그런 다음 가장 잘 생각하는 방식으로 애플리케이션을 확인할 수 있습니다. 예를 들어 digital certificate의 신원을 확인하거나 원하는대로 경로 이름을 확인하는 것이 좋습니다.

특정 사용자가 아닌 특정 응용 프로그램에 대한 액세스를 제한하려고 시도하면 결코 튼튼해질 수는 없습니다. 공격자는 승인 된 애플리케이션을 항상 제어하고 자체 코드를 자신의 코드로 교체 할 수 있습니다. 기본적으로 스피드 범프 이상이 될 수는 없지만, 할 가치가 있다고 느낀다면 할 수 있습니다. 당신이 정말 알고 싶은 것은 사용자가 연결된 어떤 경우


대신 OpenThreadToken()에 의해 등등 다음, 이미 코멘트에 제안 ImpersonateNamedPipeClient()를 사용한다. 또는 명명 된 파이프를 만들 때 권한을 설정하여 권한이 부여 된 사용자 만 연결할 수 있도록하십시오. 클라이언트가 상승 된 권한으로 실행되는 것이 분명했습니다 이제


, 나는 좀 더 구체적인 추천을 할 수 있습니다 : 위의 두 가지를 모두 수행. Administrators 그룹의 구성원 만 액세스 할 수 있도록 명명 된 파이프에 대한 사용 권한을 구성합니다. 높은 권한으로 실행되는 응용 프로그램 만 액세스 할 수 있습니다. 실행 파일을 검사해도 해가되지는 않지만 공격자가 응용 프로그램 복사본을 시작하고 요청 된 상승을 억제하고 자신의 코드를 프로세스에 삽입 할 수 있기 때문에 충분하지 않습니다. (또는 conio가 가리키는 것처럼 자신의 프로세스를 수정하여 실행 파일을 실행하는 것처럼 보이게하고 GetModuleFileNameEx()는 보안 방법으로 사용하지 않으므로 스푸핑을 피하려고 아무런 노력을하지 않습니다.

+0

GetNamedPipeClientProcessId가 정확히 내가 원하는 것 같습니다! 내일 테스트 할 코드를 작성하려고합니다. 보안 측면 : 응용 프로그램을 발견 한 후 WinVerifyTrust()를 사용하여 서명을 검사 할 것입니다. 그렇게하면 내 신청서가 수정되지 않은 것을 알 수 있습니다. 침입자가 메모리에있는 코드를 덮어 쓸 수 있다면 시스템에 이미 더 큰 문제가있는 것입니다 ... – CodeX

+0

여기에 어떤 위협 모델이 있습니까? * 사용자 *가 연결되어있는 것보다 * 응용 프로그램 *이 연결되어있는 것에 신경을 쓰는 유일한 이유는 사용자 *가 자신을 보호하려고 시도하는 경우입니다. * 사용자가 항상 코드를 수정할 수 있기 때문에 작동하지 않습니다. 자신의 프로세스에서 실행됩니다. –

+0

... 물론 사용자 컨텍스트에서 실행되는 악성 소프트웨어에도 동일하게 적용됩니다. –