it-gundan.com

Android 앱을 에뮬레이터에 설치할 수있는 경우의 보안 영향

회사 제품의 보안을 위해 노력하고 있습니다. 제품의 모바일 버전이 있습니다. 이 질문은 Android 버전입니다)

배경-우리 제품은 SaaS 기반 제품이며 앱은 테넌트 조직의 다른 영업 사원이 사용하도록되어 있습니다. 앱의 보안 (또는 더 안전한) 환경을 보장하기 위해 다양한 제어 계층을 구현했습니다.

  • 루트 감지를 확인합니다-(OS 레벨 확인)
  • SSL 피닝 구현-(전송 계층 수준 확인)
  • Android 키 체인에 비밀 저장
  • 최소한의 로컬 데이터 스토리지. 로컬 데이터 암호화 (저장해야 함)

그리고 목록은 계속됩니다. 요컨대, 장치에서 통신 계층, 서버 계층에 이르기까지 모든 구석을 다루는 과정에 있습니다.

문제는 보안 연구원 중 한 사람이 우리의 앱을 Android Play 스토어에서 다운로드 할 수 있으므로 에뮬레이터와 에뮬레이터에서 실행할 수 있음) 루트 탐지를 우회 할 수 있으므로 큰 위협이 추가되므로 즉시 수정해야합니다.

검색했지만 에뮬레이터에 앱을 설치할 수 있으면 보안에 영향을 줄 수 없습니다. 또한 수정해야 할 수도 있는지, 가능한 해결책은 무엇인지 확인했습니다. 실행 환경이 SDK인지 확인하고 카메라 또는 센서와 같은 기능이 작동하는지 확인하는 것과 같은 확인이 있지만 모든 확인은 에뮬레이터에서도 무시할 수 있습니다.

이 문제를 수락하면 고객이 보고서에서 문제를보고 문제를 해결해야하므로 매우 중요합니다. 경영진과 개발자에게 설명하고 (수락하는 경우) 수정해야한다는 의미에 대해 빈 틈이났습니다.

업데이트-

  1. 우리는 모든 클라이언트 측 보호가 한 지점에서 우회 할 수 있다고 생각하기 때문에 루트 감지 또는 다른 클라이언트 측 보안 제어를 앱의 플러스 포인트로 옹호하지 않는 것을 분명히하고 싶습니다.
  2. 우리는 서버 수준에서보다 안전한 아키텍처를 구축하려고 노력하고 있습니다. 그러나 클라이언트 쪽도 에코 시스템의 일부를 구성하기 때문에 우리는 그것을 보호 할 수 없습니다.
  3. TLS 이외의 통신 계층에서 컨트롤을 구현하여 모든 것을 얻을 수는 없습니다.

우리가 생각하는 것은 특정 것들을 통제 할 수 없다면 적어도 악의적 인 사람들에게는 어렵게 만들 수 있습니다. 우리의 주요 초점은 사용자 데이터와 컨트롤이 제자리에 있으며 진행중인 것을 보호하는 것입니다.

또한 Pentester에서 업데이트-토론 후 응용 프로그램 보안 요구 사항을 이해하지 못한다고 말했습니다. 그에 따라 모든 앱에는 루트 감지 기능이 있어야합니다. 우리는 그러한 것들이 우리에게 부차적 인 것을 의미한다고 설명하지만 클라이언트 특정 데이터가 명백히 보이지 않거나 앱 구성이 잘못되었거나 앱의 취약성 (하드 코딩 된 비밀과 같은)으로 인해 손상 될 수 있다면 기본 데이터라고 설명했습니다.

제공된 정보를 바탕 으로이 구별을 분명히하고 문제를 해결하는 데 도움을 줄 수있었습니다. 이전에는이 ​​문제로 인해 모든 소음이 발생했습니다. 모두에게 감사합니다

34
Lexi champ

처음에 어떤 종류의 보안 요구 사항이 있는지 확실하지 않으므로 보안 조치가 충분한 지 확실하지 않습니다.

사용자의 장치를 완전히 제어 할 수 없으면 응용 프로그램을 사용하는 악의적 인 사용자로부터 완전히 보호 할 수 없습니다. 이 위험에는 에뮬레이터에서 응용 프로그램을 실행하는 것이 포함되지만 루팅되었거나 변조 된 장치에서 응용 프로그램을 실행하는 것도 포함됩니다. 모든 루트 감지 방법으로이 모든 것이 감지되지는 않습니다.

대신 악의적 인 사용자가 본인이나 다른 사용자에게 해를 끼치 지 않고 자신에게만 피해를 줄 수 있도록 응용 프로그램을 설계해야합니다. 예를 들어, 애플리케이션에 사용자 고유의 비밀이 있고 전역 비밀을 사용하지 않는 것을 의미합니다. 또한 응용 프로그램에서보고하는 내용을 신뢰하지 말고 이것이 의미가 있는지 확인해야합니다 (예 : 게임 등에서 자체보고 된 높은 점수를 신뢰하지 않음).

94
Steffen Ullrich

클라이언트에 대한 정답과 정답은 NOTANISSUE 입니다.

클라이언트 측 소프트웨어는 * * ever는 질문이 요구하는 의미에서 안전한 것으로 간주되지 않아야합니다. 그들은 할 수 없습니다. 클라이언트 측 소프트웨어 (웹 또는 앱)는 소프트웨어를 다시 작성/수정하거나 감지 할 수없는 안전하지 않거나 수정 된 환경에서 실행할 수있는 전체 기능과 마찬가지로 환경과 마찬가지로 클라이언트 제어하에 있습니다. 그것은 버그가 아닙니다. 그것은 모델에 내재되어 있음 * *입니다.

다양한 검사의 목적은 보안과 마찬가지로 위험을 줄이고 막대를 높이는 것입니다. 클라이언트를 안전하게 만들거나 클라이언트 쪽 보안을 보장하기 위해 not이 수행되며 해당 목표를 가정하면 클라이언트가 올바르지 않습니다.

  • * * 전체 클라이언트 측 소프트웨어 및 해당 환경이 신뢰할 수있는 것과 같은 변조 방지 및 검증 가능한 환경을 작성하기 위해 설계되고 제어되는 클라이언트 측 소프트웨어의 독점 제외 유비 키의 실행 또는 펌웨어 (플래시 후에는 쉽게 다운로드하거나 수정할 수 없음) 또는 클라이언트가 서로 동기화 된 보안 장애 조치 서버와 같이 자체 보안 기능을 갖춘 원격 시스템 인 경우 SSH를 통해.

    그런데도 특정 모듈이 특정 위협 모델에 대해 안전한 것으로 간주 될 수 있지만 여전히 동글의 응답을 확인하는 로컬 앱과 같은 다른 방법으로 보안이 유지되는 것은 아닙니다.
14
Stilez

나는 여기의 선들 사이를 재조정하지만, 연구원이 어디에서 왔는지 알 것입니다.

앱에 다른 고객의 데이터를 노출시킬 수있는 비밀을 저장하거나 사용하는 비즈니스가 없습니다.

프론트 엔드에 부여 된 비밀 만 백엔드 서비스에 대한 분할 액세스를 제공하도록 백엔드를 설계하십시오. 사용자가 자신의 기기를 루팅하면 자신의 계정 만 해킹 할 수 있습니다.

9
Jasen

나는 가난한 악성 펜 테스터를 옹호해야한다고 생각합니다.

이 테스터는 무엇을하고 어떤 범위로 고용 했습니까?

앱 개발자가 루트 감지가 보안 전략의 일부라고 주장하는 백서 또는 보안 전략 등을 제공 한 경우 루트 감지가 공개적으로 사용 가능한 APK의 허구임을 지적하는 것이 절대적으로 적합합니다. 일반적으로 전체 아키텍처가 클라이언트 측에서 실제로 취약하고 제어 된 장치에서만 실행되어야하는지 또는 경영진이 가능한 가장 큰 "보안 기능"목록을 원했는지 여부를 확인하는 것은 일반적으로 테스터의 문제가 아닙니다. 그는 제공된 주장에 대해 실패했다고보고합니다 (루트 탐지가 보안을 향상시키고 있음).

"수정"은 더 많은 "보안 기능"목록을 가질 수 있도록 클라이언트 측 환경 검사에서 보안에 대한 모든 작업을 수행한다고 주장하는 것을 중지합니다.

이 사람이 암시하는 말은 "플레이 스토어에있는 것은 취약하다"는 말은 OP가 아닙니다. (내 자신의 경력에서 시간이 충분히 잘못되는 방식으로 내가 잘못 말한 것을 가지고있는 것은 ...!)

8
Affe

클라이언트 측 또는 웹 응용 프로그램을 충분히 안전한 독립형으로 생각하지 않습니다. 즉, OS에서 솔루션 서버 측을 독립적으로 보호하지 않습니다.

클라이언트 쪽 응용 프로그램 내부에 구현 된 모든 보안 계층, 유효성 검사 및 검사는 최소한 응용 프로그램 서버 쪽 구성 요소 내에서 해당하거나 더 강력한 유효성 검사로 반복해야합니다.

또한 에뮬레이터를 사용하여 응용 프로그램을 실행하면 에뮬레이터 자체 취약점으로 인해 사용자의 보안이 손상 될 수 있습니다. 예를 들어 공격자가 원격 코드 실행, 정보 유출, 백업 및 데이터 도용을 수행하고 에뮬레이터의 인터 프로세스 통신 기능 *.

* 출처 : https://www.bleepingcomputer.com/news/security/bluestacks-flaw-lets-attackers-remotely-control-Android-emulator/

7
Refineo

하드웨어 장치에서 실행되는 JVM 또는 에뮬레이터 간에는 거의 차이가 없습니다. 물론 OS 빌드 문자열에 "제네릭"(에뮬레이터 만 있음)이 있는지 확인한 다음 릴리스 빌드 일 때 응용 프로그램을 종료합니다. 그러나 전체 보안의 개선이 전혀 없습니다 (바이트 코드는 쉽게 디 컴파일-코드 서명만으로도 기능 변경이 어느 정도 방지됩니다. 또한 릴리스 빌드는 debuggable로 구성되지 않습니다.

요점은 루팅 된 장치에서 실행할 수 없을 때 (루트 된) 에뮬레이터에서 실행되지 않는다는 것입니다.

2
Martin Zeitler

확실한 논리적 펜 테스트 구멍으로 인해 신뢰할 수있는 루트 감지가 불가능합니다.

사용자가 APK에 액세스 할 수 있으면 APK를 분석 한 다음 서버 API를 직접 쉽게 호출 할 수 있습니다. 응용 프로그램을 완전히 우회 또는 응용 프로그램을 다른 시스템으로 이식하십시오. 루팅 된 기기에서 시스템이 실행되고 있는지 감지하기 위해 시스템을 보호하는 전략의 일부인 경우 보안에 대한 전반적인 접근 방식을 다시 생각해야합니다. 무엇이 실행되고 있는지 확실하게 알 수 없습니다.

사용자는 애플리케이션을 디 컴파일하고 애플리케이션에서 모든 탐지 부분을 먼저 제거 할 수 있습니다. 프로세스는 "크래킹"소프트웨어와 동일합니다.

루트 감지로 할 수있는 일은 사용자에게 보안상의주의 사항으로 자신의 전화기가 루팅되었다고 생각한다는 것을 사용자에게 알리는 것입니다. 사용자가 모르는 상태에서 전화기가 루팅되었을 수 있습니까? 그러나 그러한 경우에도 당신은 그것에 의존 할 수 없습니다. 실제 하드웨어인지 또는 실행 중인지 알 수 없습니다. knox와 같은 일부 시스템에서 실행 중인지 알 수 없습니다. 엔터프라이즈 기능을 통해 시스템에서 근본적으로 근본적인 힘을 얻도록 삼성을 지불 할 수 있습니다. 그렇습니다. 기본적으로 다른 응용 프로그램 및 다른 응용 프로그램 구성 요소를 망칠 수있는 거의 같은 힘을 부여 할 수 있습니다 -전화는 그때도 녹스 보안으로 표시되며 루팅되지 않은 상태입니다).

루트 탐지 및 이러한 탐지는 일반적으로 해킹을 방지하기위한 응용 프로그램에서 발생하지만 문제를 해결하는 데 100 % 잘못된 접근 방식입니다. 죄송하지만, 보안과 관련하여 조직의 문화적 사고 변화가 필요합니다. 다른 곳에서 실행되는 소프트웨어를 신뢰할 수 없다고 생각하는 것은 신뢰할 수 없습니다.

편집 : 당신이 상사에게 그것을 설명 할 수있는 방법이 필요하다면, 당신은 이것을 시도 할 수 있습니다 : "우리가 이것을 할 수 있다면 그 코드의 일부는 회사 전체가 가치가있는 것보다 더 가치가있을 것입니다." Google에서 일한 경우에도 회사에 계속 적용됩니다.

0
Lassi Kinnunen

보안 연구원 경고는 옳지 만이 경고를 응용 프로그램의 컨텍스트에 두어 관련성이 있는지 알아야합니다.

"루트 감지"를 앱의 중요한 보안 기능으로 나열했습니다.

보안 전문가이기 때문에 루트 탐지를 쉽게 우회 할 수 있다고 지적합니다. 가상 머신뿐만 아니라 물리적 디바이스에서도. 루트 감지를 주장하는 많은 프레임 워크는 많은 루팅 된 디바이스를 감지하지 않고 일부 루트 디바이스를 루팅 된 것으로 감지합니다. 경우에 관계없이 모든 응용 프로그램의 클라이언트 쪽을 쉽게 리버스 엔지니어링 할 수 있습니다. 동기를 부여한 공격자는 클라이언트 측 앱을 우회하여 백엔드 인터페이스에 액세스 할 수 있습니다. 즉, 클라이언트 측의 모든 검사를 무시하고 계산을 엉망으로 만들 수 있습니다. 클라이언트 측 확인 또는 계산을 신뢰할 수 없습니다.

신뢰할 수있는 클라이언트를 만들 수 있지만 독점 하드웨어, 독점 운영 체제 및 소프트웨어가 필요합니다. 게임 콘솔과 케이블 네트워크는 그렇게하지만 여전히 불법 복제로 많은 어려움을 겪고 있습니다. 이는 불법 복제 방지 장치가 얼마나 어려운지를 보여주는 좋은 예입니다. 이 전략은 이론적으로는 가능하지만 너무 비싸고 경쟁에서 약해지고 쓸모없는 제품 기능에 대한 투자를 도용하기 때문에 실제로 실패합니다.

얼마나 안전해야합니까?

안전하고 안전한 앱은 없습니다. 보안은 위험, 그것이 발생할 수있는 손실의 가능성 및 규모를 이해하고 우발적 인 이익 마진을 유지하기위한 우발 사태 및 완화 전략을 식별하는 것입니다. 당신이 묻는 질문은 :

  • "루트 감지"가 실패하면 어떻게됩니까?
  • "루트 탐지"는 어떤 종류의 공격을 막아야합니까?
  • 그럴 가능성은 무엇입니까?
  • "루트 감지"가 실패 할 수있는 손실은 무엇입니까?
  • 그것에 대해 다른 보호 책이 있습니까?
  • 이러한 종류의 위반을 빠르게 감지 할 수 있습니까?
  • 손실을 줄이거 나 없애는 비상 사태를 유발할 수 있습니까?
  • 그 손실로 회사는 여전히 수익성이 있습니까?

모든 중요한 논리는 서버 측이어야합니다

공격자가 가상 ​​환경에 앱을 설치할 수 있다는 우려가 있습니다. 많은 보안 검사와 중요한 계산이 클라이언트 측에 있다고 생각합니다. 이 경우 모든 컨트롤을 서버쪽으로 옮기려면 앱을 다시 디자인해야합니다.

  • 사용자 네트워크에 노출 된 백엔드 인터페이스 API에는 사용자 인증이 필요합니다.

  • 백엔드 인터페이스 API는 사용자가보고 수행 할 수있는 것을 제한해야합니다. 액세스 제한은 클라이언트 측이 아니라 서버 측에 의해 부과되어야합니다. 물론 민감한 정보와 명령을 포함하지 않는 서비스는 예외입니다.

  • 백엔드 인터페이스 API는 무차별 대입 공격 가능성을 고려해야합니다. 공격자는 데이터베이스의 많은 부분을 다운로드하고 취약한 암호 및 확인 코드를 모두 시도하여 추측 할 수 있습니다.

  • 백엔드에서 사용하고 사용자 네트워크에 노출되지 않는 내부 API는 서비스 사용자 또는 클라이언트 인증서를 사용하여 인증해야하는 내부 서비스 계층을 구성합니다. 실제 사용자 의 정보는 로깅 목적으로 해당 서비스에 전파되어야합니다.

이것이 매우 실망 스럽다는 것을 알고 있습니다. 이러한 제한으로 인해 백엔드 인터페이스 API는 앱 워크 플로에 매우 구체적이어야하고 재사용 성이 떨어집니다. 불행히도 내부 API 만 재사용 할 수 있습니다. 또한 백엔드 개발자는 사용자 경험, 설계된 워크 플로우를 잘 이해하고 대부분의 개발자가 싫어하거나 준비가되어있는 프론트 엔드 팀과 긴밀하게 작업해야합니다.

서버의 모든 중요한 논리가 있더라도 다른 위험을 처리하기 위해 워크 플로를 디자인해야합니다.

앱이 위에서 언급 한 지침을 따르는 경우 클라이언트 측 앱이 공격자의 장치에서 변조되었는지는 중요하지 않습니다. 사용자는 공식 클라이언트 측 앱을 통해 수행 할 수있는 사용자 자격 증명 이외의 다른 작업을 수행 할 수 없습니다.

그러나 실제 사용자 장치가 루팅되면 맬웨어가 다음을 수행 할 수 있습니다.

  • 루팅 된 기기 감지 우회;
  • 사용자 자격 증명을 캡처합니다.
  • 사용자를 잘못된 페이지로 리디렉션합니다.
  • 사용자를 잘못된 앱으로 리디렉션합니다.
  • 장치 원격 제어;

이러한 공격은 흔하지 않습니다. 일반적으로 사용자가 복잡한 절차를 수행해야하기 때문에 어렵습니다. 그러나 제품이 비싸거나 정보가 너무 민감한 경우 이러한 공격을 심각하게 고려해야합니다.

"영업 사원"이 손실이 크고 복구가 어려운 고가의 제품을 취급하기 때문에 우려가되는 경우 다음과 같은 2 차 장벽을 고려해야합니다.

  • 대규모 운영에 대한 감독자 검증;
  • 여러 외부 데이터베이스로 배달 주소를 확인합니다.
  • 배송 추적 향상;
  • 위험에 따라 배송에 시간 제약을가합니다.

여전히 충분하지 않은 경우 외부 앱 설치를 방지하고 충전 전용으로 USB를 잠그도록 회사 소유 장치를 제공하도록 선택할 수 있습니다. 나는 항상 다른 회사의 회사 전화 3 대를 가지고 다니는 소수의 사람들을 알고 있습니다.

좋은 로그를 개발하고 모니터링

모니터링은 많은 손실을 피하기위한 좋은 전략입니다. 로그의 손실을 역 추적하면 발생 방식과 실패한 사항을보다 잘 이해하고, 제품 변경을 제안하거나, 해당 상황을 모니터링하여 향후 유사한 상황에 대한 조기 경보를받을 수 있습니다.

로그가 충분히 상세하다면, 구현하기 쉽고 행동 손실을 방지하기에 충분히 많은 종류의 침입과 일부 운영 실수를 감지 할 수있는 행동 생체 인식 기법이 있습니다.

데스크탑 버전이 있습니까?

"모바일 버전의 제품이 있습니다"라고 말하면 다른 제품이있는 것 같습니다. 데스크탑 버전이 있습니까? 데스크톱 운영 체제는 기본적으로 루팅되어 있으며 앱 격리가 없습니다. 데스크톱 버전으로 살 수 있다면 처음부터 루트 감지가 필요하지 않을 수도 있습니다.

보안을 지속적으로 개선하는 것이 좋지만, 그렇게해야합니다. 그러나 새로운 개발에서 끔찍한 실수를하지 않는 한 모바일 버전이 데스크톱 버전보다 안전 할 것으로 예상 할 수 있습니다.

0
Lucas