소개

모바일 애플리케이션의 급속한 개발과 광범위한 적용으로 인해 타사 SDK가 모바일 개발의 중요한 부분이 되었습니다. 풍부한 기능과 편리한 통합 방법을 갖춘 타사 SDK는 개발자에게 애플리케이션 기능을 신속하게 개발하고 향상시킬 수 있는 방법을 제공합니다. 그러나 블랙박스 특성과 타사 SDK의 광범위한 사용으로 인해 보안이 많은 관심을 끌었습니다. 본 글에서는 모바일 APP에서 타사 SDK의 보안 문제를 중점적으로 살펴보고, 실제 취약점 마이닝 사례를 통해 잠재적인 보안 위험과 공격 방법을 설명합니다.

타사 SDK 보안 상태:

모바일 앱에서 널리 사용되는 타사 SDK에는 일부 보안 위험이 있습니다. 첫째, 타사 SDK는 jar 패키지 또는 라이브러리 형태로 애플리케이션에 통합되어 블랙박스로 존재하므로 개발자가 보안을 감사할 수 없습니다. 둘째, 널리 사용되기 때문에 SDK에 취약점이 존재하면 많은 애플리케이션에 영향을 미칩니다. 또한 SDK를 통합하면 애플리케이션의 공격 표면이 증가하여 애플리케이션의 보안 위험이 높아질 수 있습니다.

Umeng SDK 재정의 취약점:

Umeng SDK 무단 접근 취약점은 2017년 9월에 발견되었습니다. 이 취약점은 Umeng의 메시지 푸시 SDK에 존재하며, 공격자는 이 취약점을 이용해 허가 없이 내보내지 않은 구성 요소를 호출하여 영향을 받는 APP의 구성 요소에 대한 악의적인 호출, 임의의 허위 메시지 알림, 원격 코드 실행 및 기타 공격을 수행할 수 있습니다. 약 30,000개 이상의 앱이 이 취약점의 영향을 받으며, 다양한 유형의 애플리케이션과 관련된 7,000개 이상의 앱 제품이 이 취약점의 영향을 받습니다.

 

Baidu SDK 백도어 노출

2015년 11월 Trend Micro가 발견한 Baidu Moplus SDK 백도어 취약점. 이 취약점은 Baidu Moplus SDK에 존재하며, 공격자는 이 취약점을 이용하여 루팅된 Android 기기에 자동으로 애플리케이션을 설치하여 민감한 사용자 정보를 훔치거나 기기를 제어할 수 있습니다. 이 취약점은 약 1억 대의 Android 기기에 영향을 미치며 수천 개의 Android 앱과 관련됩니다.

금융공급망 리스크가 심각하다

그 중에서도 안드로이드 애플리케이션 공급망에 있는 타사 SDK의 보안 위험은 금융 앱에서 특히 심각합니다.

취약점 마이닝 및 분석

기본 사상

 애플리케이션 샌드박스

Linux 기반 권한 제어 메커니즘: 애플리케이션 설치 후 UID와 GID를 할당하고 UID를 사용하여 파일에 대한 액세스를 제한합니다. 이론적으로 애플리케이션은 다른 애플리케이션의 비공개 파일에 액세스할 수 없습니다. GID는 리소스에 대한 액세스를 제한하는 데 사용됩니다. 애플리케이션이 권한을 적용한 후 권한에 해당하는 사용자 그룹에 다른 UID가 추가됩니다. 권한과 GID 간의 매핑 관계는 /data/etc/platform.xml입니다. 필요한 권한은 설치/런타임 중에 적용됩니다. 시스템/사용자 등에 의해 제어됩니다.

 의지

Android의 일반적인 IPC 형식: 동일한 프로세스/교차 프로세스인 APP 구성 요소 간의 통신에 사용되는 IPC 메시지 개체입니다.

, startActivity()/startService()/bindService()/sendBroadcast(), Action 또는 ComponentName을 사용하여 대상 구성 요소를 지정하고 추가 데이터를 전달할 수 있습니다(추가)

구성 요소 보안

Android 앱의 기본 구성 요소: 활동, 방송 수신기, 콘텐츠 제공자 및 서비스. 예: xml 파일에 선언됨: 구성 요소는 외부 내보내기/애플리케이션 비공개로 선언될 수 있으며 권한을 사용하여 보호될 수 있습니다.

부품 수출 보안

구성요소 내보내기: 내보낸 구성요소는 android:exported=true, RegisterReceiver()와 같은 모든 애플리케이션에서 액세스할 수 있습니다. android:export=false가 설정되지 않은 경우 기본적으로 레이블 구성 요소를 내보냅니다. 예:

<receiver 안드로이드:이름=”com.xxx.android.pushservice.PushServiceReceiver” android:process=”:xxservice_v1″ >

<intent-filter>

<action android:name=”android.intent.action.BOOT_COMPLETED” />

<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />

<!– … –>

</intent-filter>

</receiver>

프라이빗 구성 요소: 프라이빗 구성 요소는 애플리케이션에 민감한 기능을 포함하는 경우가 많으며 입력 데이터에 대한 확인이 적고 다른 애플리케이션 프라이빗 구성 요소에 대한 무단 액세스(애플리케이션 샌드박스 이스케이프) 및 심각한 보안 위험이 있습니다.

악용 방법

SDK의 취약점을 악용하여 악성 애플리케이션은 어떠한 권한도 요구하지 않고, 샌드박스 제한을 우회하고, 애플리케이션의 비공개 구성요소에 접근하고, 악성 알림 메시지를 푸시하고, 피싱 웹사이트에 대한 접근을 유도하고, SMS 인증 코드를 획득하고, 사용자 개인 데이터에 접근하고, 임의 코드를 실행합니다. , 등.

이 기사에서는 타사 SDK의 가능한 보안 위험과 공격 방법을 보여주기 위해 몇 가지 실제 취약점 마이닝 사례를 제공합니다.

푸시SDK 취약점 마이닝

SDK 푸시는 모바일 애플리케이션의 일반적인 기능 중 하나이지만 여기에는 몇 가지 보안 허점이 있습니다. 푸시 SDK의 취약점을 마이닝함으로써 공격자는 애플리케이션 샌드박스 제한을 우회하고, 애플리케이션의 비공개 구성 요소에 접근하고, 악성 알림 메시지를 푸시하고, 사용자가 피싱 웹사이트를 방문하도록 유도하는 등의 작업을 수행할 수 있습니다. 구체적인 사례로는 도시의 공식 지하철 앱에 통합된 푸시 SDK-A의 취약점이 있으며, 공격자가 악성 푸시 메시지와 내보낸 수신기를 구성하여 피싱 알림 팝업에 성공했습니다.

푸시 SDK

푸시 SDK – A

• 공식 문서는 개발자가 내보낸 수신기를 추가하도록 안내합니다.
• 내보낸 수신기의 특정 기능은 개발자가 구현합니다.
• 개발자가 공격 입구를 떠나도록 '안내'

<receiver android:name=”您自己定义的Receiver” android:enabled=”true”>

<intent-filter>

<action android:name=”cn.xxxxx.android.intent.REGISTRATION” />

.

.

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />

<action android:name=”cn.xxxxx.android.intent.CONNECTION” />

.

</intent-filter>

</receiver>

이 경우 해당 도시의 공식 지하철 APP 통합 푸시 SDK입니다.

• 내보내기수신자xxxxx고객수신자
• xxxxxCustomerReceiver에서 인텐트 수신 데이터를 구문 분석하고 앱에서 지정된 URL을 엽니다.
• POC

시 공식 지하철 앱이 악성 피싱 페이지에 접속하다

푸시 SDK – B

• 사용자에게 내보낸 수신기를 추가하도록 안내
• 내보낸 수신기는 com.xxx.android.xxxxx에서 상속됩니다..xxx베이스수신기

<receiver android:name=”com.xxxx.xxdemo.receiver.MessageReceiver”

안드로이드:내보냈습니다=”진실” >

<intent-filter>

.

<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />

</intent-filter>

</receiver>

푸시 SDK – B

xxxxxx.android.xxxxx. 푸시 메시지는 xxxBaseReceiver에서 처리됩니다. 전달된 메시지는 RSA로 암호화되고 앱에 의해 로컬로 복호화됩니다. 복호화에 성공한 후 사용자에게 표시됩니다. 그러나... 암호화가 있습니다. SDK의 메서드를 사용하며 공격자는 이 암호화 메서드를 호출하여 위조된 메시지를 암호화할 수 있습니다.

XX Credit Card Manager는 push SDK-B를 통합하고 내보낸 Receiver를 추가하며, 공격자는 SDK의 암호화 방식을 호출하여 악성 푸시 메시지를 구성하고 내보낸 Receiver를 사용하여 피싱 알림을 팝업합니다. POC:

영향권

공유 카테고리SDK 취약점파기

공유 SDK는 모바일 애플리케이션에서 소셜 공유 기능을 구현하는 데 자주 사용되지만 일부 공유 SDK에는 보안 취약점이 있습니다. 예를 들어 특정 공유 SDK-A에 내보낸 활동이 있는 경우 공격자는 애플리케이션 샌드박스 제한을 우회하고 모든 비공개 활동에 대한 무단 액세스를 얻을 수 있습니다. 공격자는 악의적인 입력 문자열을 구성하여 일반적인 서비스 거부 취약점을 유발하여 응용 프로그램이 중단되도록 할 수 있습니다. 또한 일부 공유 SDK로 인해 애플리케이션 비밀번호 잠금이 우회되어 사용자의 개인 데이터에 액세스할 수도 있습니다.

SDK 공유 – A

SDK에는 입력 문자열을 구성 요소 이름으로 사용하고 확인 없이 지정된 구성 요소를 직접 시작하는 XxShareXxXxxxxActivity라는 내보낸 활동이 있습니다. 악성 애플리케이션은 애플리케이션 샌드박스 제한을 우회하고 비공개 활동에 대한 무단 액세스를 얻을 수 있습니다.

XxShareXxXxxxxActivity는 Intent로부터 들어오는 문자열을 수신하며, 검증 없이 들어오는 문자열은 ActivityName으로 저장되고, 현재 애플리케이션 컨텍스트에서 startActivity를 호출하여 ActivityName 등으로 지정된 Activity를 시작합니다.

취약점 악용 – 일반적인 서비스 거부: 활동이 시작되면 매개변수를 전달하고 일부 초기화 작업을 수행해야 하며... SDK 취약점을 악용하여 내보내지 않은 활동을 강제로 호출하고 부적절한 예외 처리를 수행하여 애플리케이션 충돌을 유발해야 합니다.

많은 수의 응용 프로그램에 대해 테스트 도구를 작성하고 일괄 테스트를 수행합니다. SDK를 통합하는 응용 프로그램 중 90%+에 이 문제가 있습니다. 통계에 따르면 SDK를 통합하는 응용 프로그램 중 90%+에 이 문제가 있습니다. 많은 수의 우물- 알려진 국내 제조업체의 애플리케이션이 이 취약점의 영향을 받습니다.

취약점 악용 – 애플리케이션 비밀번호 잠금 우회: 사용자의 개인정보 데이터가 애플리케이션에 저장되어 애플리케이션 진입 시 정확한 비밀번호를 입력해야 하는 현상 금융 및 IM 애플리케이션에서 흔히 발생하는 현상으로, 이 SDK 취약점을 이용한 무단 접근에는 비밀번호 재설정, 비밀번호 설정 등 애플리케이션의 민감한 기능 구성 요소와 높은 권한 구성 요소는 엄격하게 인증되지 않아 비밀번호 잠금이 우회/재설정되는 등의 결과를 낳습니다. 테스트 결과 다음과 같은 많은 유명 제조업체의 앱에 이러한 문제가 있는 것으로 나타났습니다. .

취약점 악용 - 허가 없이 디버깅 모드 켜기: 온라인에서 버그 찾기를 용이하게 하기 위해 많은 애플리케이션 릴리스 버전에는 디버깅 코드, 로그 스위치 적용, 온라인 서버 주소 사용자 정의, 사용자 데이터 내보내기 및 기타 민감한 기능이 포함되어 있습니다. 디버깅 기능은 일반적으로 다음과 같습니다. UI에서는 사용할 수 없음 일반 사용자가 쉽게 접근할 수 없는 직관적인 진입 예를 들어 디버깅 모듈은 민감한 작업을 포함하고 본질적으로 백도어와 유사함 SDK 취약점을 악용하여 애플리케이션의 내보내지 않은 모든 구성 요소를 탐색하고 숨겨진 디버깅 기능을 발견합니다. 예를 들어, 기업 수준의 IM 애플리케이션에서 디버깅 기능이 포함된 내보내지 않은 구성 요소가 여러 개 발견되었으며, 역분석을 통해 UI에 디버깅에 들어갈 수 있는 숨겨진 입구가 있는 것으로 확인되었습니다. 그러나 UI를 통해 디버깅 구성 요소를 시작하려면, 비밀번호를 입력해야 하며 인증이 엄격하지 않습니다. 이 SDK 취약점은 비밀번호 보호를 우회하는 데 악용됩니다. , 허가 없이 디버깅 기능을 활성화합니다.

일반 사용자 ID 로그인: SDK 취약점을 이용하여 관리자 권한 기능을 공개하고, 서버는 사용자 ID 확인을 엄격하게 하지 않으며, 일부 관리자 기능은 권한 없이 호출될 수 있습니다.

영향권

요약 및 생각:

모바일 앱에서 타사 SDK의 보안 문제를 심각하게 받아들이고 해결해야 합니다. 개발자는 통합된 타사 SDK를 감사하여 보안과 안정성을 보장해야 합니다. 동시에 개발자는 모바일 앱에서 타사 SDK의 보안을 향상하기 위해 다음 조치를 취하는 것이 좋습니다.

1. 신뢰할 수 있는 제3자 SDK 공급업체 선택: 제3자 SDK를 선택하고 통합하기 전에 개발자는 공급업체를 철저히 조사 및 평가하고 평판이 좋고 보안 기록이 좋은 공급업체를 선택해야 합니다.

2. 정기적으로 SDK 버전 업데이트 및 업그레이드: 타사 SDK 공급업체는 일반적으로 알려진 보안 취약성을 해결하기 위해 업데이트 및 수정 버전을 출시합니다. 개발자는 애플리케이션 보안을 보장하기 위해 통합 SDK를 즉시 업데이트하고 업그레이드해야 합니다.

3. 보안 감사 및 취약성 마이닝 수행: 개발자는 보안 감사 및 취약성 마이닝을 통해 타사 SDK의 잠재적인 보안 취약성을 감지할 수 있습니다. 이를 통해 이러한 취약점을 조기에 감지하고 복구할 수 있어 애플리케이션 보안이 향상됩니다.

4. SDK 권한 및 액세스 범위 제한: 타사 SDK를 통합할 때 개발자는 권한을 검토하고 필요한 권한만 부여해야 합니다. 또한 잠재적인 보안 위험을 줄이려면 앱의 비공개 구성 요소에 대한 SDK의 액세스를 제한하세요.

5. 사용자의 민감한 데이터 보호 강화: 타사 SDK를 사용할 때 개발자는 사용자의 민감한 데이터 보호에 주의를 기울여야 합니다. 사용자 데이터의 보안을 보장하기 위해 암호화, 인증 및 기타 조치가 취해질 수 있습니다.

마지막으로 모바일 앱에서 타사 SDK의 보안 문제가 중요한 문제입니다. 개발자와 보안 연구원은 타사 SDK의 보안 감사 및 취약성 마이닝에 세심한 주의를 기울이고 강화해야 합니다. 공동의 노력을 통해서만 모바일 앱의 전반적인 보안이 향상되고 사용자의 개인 정보 보호 및데이터 보안.