mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/android-applic
This commit is contained in:
Translator
parent
98e66a98bd
commit
2fd0ab4d90
@ -26,7 +26,7 @@ A partir do Android 5.0(L), o **SELinux** é aplicado. Basicamente, o SELinux ne
|
||||
### Permissões
|
||||
|
||||
Quando você instala um **app e ele pede permissões**, o app está solicitando as permissões configuradas nos elementos **`uses-permission`** no arquivo **AndroidManifest.xml**. O elemento **uses-permission** indica o nome da permissão solicitada dentro do **atributo name**. Ele também possui o atributo **maxSdkVersion** que impede a solicitação de permissões em versões superiores à especificada.\
|
||||
Note que as aplicações android não precisam pedir todas as permissões no início, elas também podem **pedir permissões dinamicamente**, mas todas as permissões devem ser **declaradas** no **manifesto**.
|
||||
Observe que as aplicações android não precisam solicitar todas as permissões no início, elas também podem **pedir permissões dinamicamente**, mas todas as permissões devem ser **declaradas** no **manifesto**.
|
||||
|
||||
Quando um app expõe funcionalidade, ele pode limitar o **acesso apenas a apps que tenham uma permissão especificada**.\
|
||||
Um elemento de permissão tem três atributos:
|
||||
@ -36,8 +36,8 @@ Um elemento de permissão tem três atributos:
|
||||
- O **protection-level**, que indica como as permissões são concedidas. Existem quatro tipos:
|
||||
- **Normal**: Usado quando não há **ameaças conhecidas** ao app. O usuário **não é obrigado a aprová-lo**.
|
||||
- **Dangerous**: Indica que a permissão concede à aplicação solicitante algum **acesso elevado**. **Os usuários são solicitados a aprová-las**.
|
||||
- **Signature**: Apenas **apps assinados pelo mesmo certificado que o que** exporta o componente podem receber permissão. Este é o tipo mais forte de proteção.
|
||||
- **SignatureOrSystem**: Apenas **apps assinados pelo mesmo certificado que o que** exporta o componente ou **apps executando com acesso a nível de sistema** podem receber permissões.
|
||||
- **Signature**: Apenas **apps assinados pelo mesmo certificado que o que exporta o componente** podem receber permissão. Este é o tipo mais forte de proteção.
|
||||
- **SignatureOrSystem**: Apenas **apps assinados pelo mesmo certificado que o que exporta o componente** ou **apps executando com acesso a nível de sistema** podem receber permissões.
|
||||
|
||||
## Aplicações Pré-Instaladas
|
||||
|
||||
@ -45,7 +45,7 @@ Esses apps geralmente são encontrados nos diretórios **`/system/app`** ou **`/
|
||||
|
||||
- As que vêm com o **AOSP** (Android OpenSource Project) **ROM**
|
||||
- Adicionadas pelo **fabricante** do dispositivo
|
||||
- Adicionadas pelo **provedor de celular** (se compradas deles)
|
||||
- Adicionadas pelo **provedor de telefonia** (se compradas deles)
|
||||
|
||||
## Rooting
|
||||
|
||||
@ -55,14 +55,14 @@ Uma vez que a exploração tenha funcionado, geralmente o binário Linux `su` é
|
||||
Uma vez que o binário su está configurado, outro app Android é usado para interagir com o binário `su` e **processar solicitações de acesso root** como **Superuser** e **SuperSU** (disponível na Google Play store).
|
||||
|
||||
> [!CAUTION]
|
||||
> Note que o processo de rooting é muito perigoso e pode danificar severamente o dispositivo.
|
||||
> Observe que o processo de rooting é muito perigoso e pode danificar severamente o dispositivo.
|
||||
|
||||
### ROMs
|
||||
|
||||
É possível **substituir o SO instalando um firmware personalizado**. Fazendo isso, é possível estender a utilidade de um dispositivo antigo, contornar restrições de software ou obter acesso ao código Android mais recente.\
|
||||
É possível **substituir o SO instalando um firmware personalizado**. Fazendo isso, é possível estender a utilidade de um dispositivo antigo, contornar restrições de software ou ganhar acesso ao código Android mais recente.\
|
||||
**OmniROM** e **LineageOS** são dois dos firmwares mais populares para usar.
|
||||
|
||||
Note que **nem sempre é necessário fazer root no dispositivo** para instalar um firmware personalizado. **Alguns fabricantes permitem** o desbloqueio de seus bootloaders de maneira bem documentada e segura.
|
||||
Observe que **nem sempre é necessário fazer root no dispositivo** para instalar um firmware personalizado. **Alguns fabricantes permitem** o desbloqueio de seus bootloaders de maneira bem documentada e segura.
|
||||
|
||||
### Implicações
|
||||
|
||||
@ -99,12 +99,12 @@ Para engenharia reversa, **Smali** se torna crucial. É a versão legível por h
|
||||
|
||||
## Intents
|
||||
|
||||
Intents são o principal meio pelo qual os apps Android se comunicam entre seus componentes ou com outros apps. Esses objetos de mensagem também podem transportar dados entre apps ou componentes, semelhante a como as solicitações GET/POST são usadas em comunicações HTTP.
|
||||
Intents são o principal meio pelo qual os apps Android se comunicam entre seus componentes ou com outros apps. Esses objetos de mensagem também podem transportar dados entre apps ou componentes, semelhante a como solicitações GET/POST são usadas em comunicações HTTP.
|
||||
|
||||
Assim, um Intent é basicamente uma **mensagem que é passada entre componentes**. Intents **podem ser direcionados** a componentes ou apps específicos, **ou podem ser enviados sem um destinatário específico**.\
|
||||
Para ser simples, o Intent pode ser usado:
|
||||
Para simplificar, o Intent pode ser usado:
|
||||
|
||||
- Para iniciar uma Activity, tipicamente abrindo uma interface de usuário para um app
|
||||
- Para iniciar uma Activity, normalmente abrindo uma interface de usuário para um app
|
||||
- Como transmissões para informar o sistema e os apps sobre mudanças
|
||||
- Para iniciar, parar e comunicar-se com um serviço em segundo plano
|
||||
- Para acessar dados via ContentProviders
|
||||
@ -126,13 +126,13 @@ Além disso, os desenvolvedores têm a opção de proteger ainda mais o acesso a
|
||||
<!-- Intent filters go here -->
|
||||
</activity>
|
||||
```
|
||||
### Intents Implícitos
|
||||
### Intenções Implícitas
|
||||
|
||||
Intents são criados programaticamente usando um construtor de Intent:
|
||||
Intenções são criadas programaticamente usando um construtor de Intenção:
|
||||
```java
|
||||
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
|
||||
```
|
||||
A **Ação** da intenção declarada anteriormente é **ACTION_SEND** e o **Extra** é um mailto **Uri** (o Extra é a informação adicional que a intenção está esperando).
|
||||
A **Ação** da intenção declarada anteriormente é **ACTION_SEND** e o **Extra** é um **Uri** mailto (o Extra é a informação adicional que a intenção está esperando).
|
||||
|
||||
Esta intenção deve ser declarada dentro do manifesto como no seguinte exemplo:
|
||||
```xml
|
||||
@ -145,7 +145,7 @@ Esta intenção deve ser declarada dentro do manifesto como no seguinte exemplo:
|
||||
```
|
||||
Um intent-filter precisa corresponder à **ação**, **dados** e **categoria** para receber uma mensagem.
|
||||
|
||||
O processo de "resolução de Intent" determina qual aplicativo deve receber cada mensagem. Este processo considera o **atributo de prioridade**, que pode ser definido na **declaração do intent-filter**, e **aquele com a maior prioridade será selecionado**. Essa prioridade pode ser definida entre -1000 e 1000 e os aplicativos podem usar o valor `SYSTEM_HIGH_PRIORITY`. Se um **conflito** surgir, uma janela "chooser" aparece para que o **usuário possa decidir**.
|
||||
O processo de "resolução de Intent" determina qual aplicativo deve receber cada mensagem. Este processo considera o **atributo de prioridade**, que pode ser definido na **declaração do intent-filter**, e **aquele com a prioridade mais alta será selecionado**. Essa prioridade pode ser definida entre -1000 e 1000 e os aplicativos podem usar o valor `SYSTEM_HIGH_PRIORITY`. Se um **conflito** surgir, uma janela "chooser" aparece para que o **usuário possa decidir**.
|
||||
|
||||
### Intents Explícitos
|
||||
|
||||
@ -161,18 +161,17 @@ context.startService(intent);
|
||||
```
|
||||
### Pending Intents
|
||||
|
||||
Esses permitem que outros aplicativos **realizem ações em nome do seu aplicativo**, usando a identidade e permissões do seu app. Para construir um Pending Intent, deve-se **especificar um intent e a ação a ser realizada**. Se o **intent declarado não for Explícito** (não declarar qual intent pode chamá-lo), um **aplicativo malicioso pode realizar a ação declarada** em nome do aplicativo vítima. Além disso, **se uma ação não for especificada**, o aplicativo malicioso poderá fazer **qualquer ação em nome da vítima**.
|
||||
Esses permitem que outros aplicativos **realizem ações em nome do seu aplicativo**, usando a identidade e permissões do seu app. Para construir um Pending Intent, deve-se **especificar um intent e a ação a ser realizada**. Se o **intent declarado não for Explícito** (não declarar qual intent pode chamá-lo), um **aplicativo malicioso pode realizar a ação declarada** em nome do aplicativo vítima. Além disso, **se uma ação não for especificada**, o aplicativo malicioso poderá realizar **qualquer ação em nome da vítima**.
|
||||
|
||||
### Broadcast Intents
|
||||
|
||||
Diferentemente dos intents anteriores, que são recebidos apenas por um app, os intents de broadcast **podem ser recebidos por múltiplos apps**. No entanto, a partir da versão da API 14, é **possível especificar o app que deve receber** a mensagem usando Intent.setPackage.
|
||||
Diferente dos intents anteriores, que são recebidos apenas por um app, os broadcast intents **podem ser recebidos por múltiplos apps**. No entanto, a partir da versão da API 14, é **possível especificar o app que deve receber** a mensagem usando Intent.setPackage.
|
||||
|
||||
Alternativamente, também é possível **especificar uma permissão ao enviar o broadcast**. O app receptor precisará ter essa permissão.
|
||||
|
||||
Existem **dois tipos** de Broadcasts: **Normal** (assíncrono) e **Ordenado** (síncrono). A **ordem** é baseada na **prioridade configurada dentro do elemento receptor**. **Cada app pode processar, retransmitir ou descartar o Broadcast.**
|
||||
|
||||
É possível **enviar** um **broadcast** usando a função `sendBroadcast(intent, receiverPermission)` da classe `Context`.\
|
||||
Você também pode usar a função **`sendBroadcast`** do **`LocalBroadCastManager`**, que garante que a **mensagem nunca saia do app**. Usando isso, você não precisará nem exportar um componente receptor.
|
||||
É possível **enviar** um **broadcast** usando a função `sendBroadcast(intent, receiverPermission)` da classe `Context`.\ Você também pode usar a função **`sendBroadcast`** do **`LocalBroadCastManager`** que garante que a **mensagem nunca saia do app**. Usando isso, você não precisará nem exportar um componente receptor.
|
||||
|
||||
### Sticky Broadcasts
|
||||
|
||||
@ -180,11 +179,11 @@ Esse tipo de Broadcasts **pode ser acessado muito tempo depois de serem enviados
|
||||
Esses foram descontinuados no nível da API 21 e é recomendado **não usá-los**.\
|
||||
**Eles permitem que qualquer aplicativo capture os dados, mas também os modifique.**
|
||||
|
||||
Se você encontrar funções contendo a palavra "sticky", como **`sendStickyBroadcast`** ou **`sendStickyBroadcastAsUser`**, **verifique o impacto e tente removê-las**.
|
||||
Se você encontrar funções contendo a palavra "sticky" como **`sendStickyBroadcast`** ou **`sendStickyBroadcastAsUser`**, **verifique o impacto e tente removê-las**.
|
||||
|
||||
## Deep links / URL schemes
|
||||
|
||||
Em aplicativos Android, **deep links** são usados para iniciar uma ação (Intent) diretamente através de uma URL. Isso é feito declarando um **URL scheme** específico dentro de uma atividade. Quando um dispositivo Android tenta **acessar uma URL com esse esquema**, a atividade especificada dentro do aplicativo é iniciada.
|
||||
Em aplicativos Android, **deep links** são usados para iniciar uma ação (Intent) diretamente através de uma URL. Isso é feito declarando um **esquema de URL** específico dentro de uma atividade. Quando um dispositivo Android tenta **acessar uma URL com esse esquema**, a atividade especificada dentro do aplicativo é iniciada.
|
||||
|
||||
O esquema deve ser declarado no arquivo **`AndroidManifest.xml`**:
|
||||
```xml
|
||||
@ -215,9 +214,9 @@ Para encontrar o **código que será executado no App**, vá para a atividade ch
|
||||
|
||||
Aprenda a [chamar deep links sem usar páginas HTML](#exploiting-schemes-deep-links).
|
||||
|
||||
## AIDL - Android Interface Definition Language
|
||||
## AIDL - Linguagem de Definição de Interface Android
|
||||
|
||||
A **Android Interface Definition Language (AIDL)** é projetada para facilitar a comunicação entre cliente e serviço em aplicativos Android por meio de **comunicação entre processos** (IPC). Como o acesso à memória de outro processo não é permitido no Android, o AIDL simplifica o processo ao marshalling de objetos em um formato compreendido pelo sistema operacional, facilitando assim a comunicação entre diferentes processos.
|
||||
A **Linguagem de Definição de Interface Android (AIDL)** é projetada para facilitar a comunicação entre cliente e serviço em aplicativos Android por meio de **comunicação entre processos** (IPC). Como o acesso à memória de outro processo não é permitido no Android, o AIDL simplifica o processo ao marshalling de objetos em um formato compreendido pelo sistema operacional, facilitando assim a comunicação entre diferentes processos.
|
||||
|
||||
### Conceitos Chave
|
||||
|
||||
@ -229,7 +228,7 @@ A **Android Interface Definition Language (AIDL)** é projetada para facilitar a
|
||||
|
||||
## Componentes
|
||||
|
||||
Estes incluem: **Atividades, Serviços, Broadcast Receivers e Providers.**
|
||||
Estes incluem: **Atividades, Serviços, Receptores de Broadcast e Provedores.**
|
||||
|
||||
### Atividade de Lançamento e outras atividades
|
||||
|
||||
@ -256,7 +255,7 @@ O ciclo de vida de uma atividade **começa com o método onCreate**, configurand
|
||||
|
||||
### Subclasse de Aplicativo
|
||||
|
||||
No desenvolvimento Android, um aplicativo tem a opção de criar uma **subclasse** da classe [Application](https://developer.android.com/reference/android/app/Application), embora não seja obrigatório. Quando tal subclasse é definida, ela se torna a primeira classe a ser instanciada dentro do aplicativo. O método **`attachBaseContext`**, se implementado nesta subclasse, é executado antes do método **`onCreate`**. Essa configuração permite uma inicialização antecipada antes que o restante da aplicação comece.
|
||||
No desenvolvimento Android, um aplicativo tem a opção de criar uma **subclasse** da [Application](https://developer.android.com/reference/android/app/Application) classe, embora não seja obrigatório. Quando tal subclasse é definida, ela se torna a primeira classe a ser instanciada dentro do aplicativo. O método **`attachBaseContext`**, se implementado nesta subclasse, é executado antes do método **`onCreate`**. Essa configuração permite uma inicialização antecipada antes que o restante da aplicação comece.
|
||||
```java
|
||||
public class MyApp extends Application {
|
||||
@Override
|
||||
@ -288,9 +287,9 @@ Uma aplicação interessante dos serviços inclui a reprodução de música em s
|
||||
|
||||
**Filtros de Intent** são cruciais em ambos os métodos de registro, determinando quais transmissões acionam o receptor. Uma vez que uma transmissão correspondente é enviada, o método **`onReceive`** do receptor é invocado, permitindo que o aplicativo reaja de acordo, como ajustando o comportamento em resposta a um alerta de bateria baixa.
|
||||
|
||||
As transmissões podem ser **assíncronas**, alcançando todos os receptores sem ordem, ou **síncronas**, onde os receptores recebem a transmissão com base em prioridades definidas. No entanto, é importante notar o potencial risco de segurança, já que qualquer aplicativo pode priorizar a si mesmo para interceptar uma transmissão.
|
||||
As transmissões podem ser **assíncronas**, alcançando todos os receptores sem ordem, ou **síncronas**, onde os receptores recebem a transmissão com base em prioridades definidas. No entanto, é importante notar o risco de segurança potencial, já que qualquer aplicativo pode priorizar a si mesmo para interceptar uma transmissão.
|
||||
|
||||
Para entender a funcionalidade de um receptor, procure o método **`onReceive`** dentro de sua classe. O código deste método pode manipular o Intent recebido, destacando a necessidade de validação de dados pelos receptores, especialmente em **Transmissões Ordenadas**, que podem modificar ou descartar o Intent.
|
||||
Para entender a funcionalidade de um receptor, procure o método **`onReceive`** dentro de sua classe. O código desse método pode manipular o Intent recebido, destacando a necessidade de validação de dados pelos receptores, especialmente em **Transmissões Ordenadas**, que podem modificar ou descartar o Intent.
|
||||
|
||||
### Content Provider
|
||||
|
||||
@ -323,7 +322,7 @@ Para mais informações, consulte:
|
||||
|
||||
## WebViews
|
||||
|
||||
WebViews são como **mini navegadores da web** dentro de aplicativos Android, puxando conteúdo da web ou de arquivos locais. Eles enfrentam riscos semelhantes aos navegadores regulares, mas existem maneiras de **reduzir esses riscos** por meio de **configurações** específicas.
|
||||
WebViews são como **mini navegadores web** dentro de aplicativos Android, puxando conteúdo da web ou de arquivos locais. Eles enfrentam riscos semelhantes aos navegadores regulares, mas existem maneiras de **reduzir esses riscos** por meio de **configurações** específicas.
|
||||
|
||||
O Android oferece dois tipos principais de WebView:
|
||||
|
||||
@ -332,7 +331,7 @@ O Android oferece dois tipos principais de WebView:
|
||||
|
||||
Um ponto chave é que os navegadores WebView **não compartilham cookies** com o navegador principal do dispositivo.
|
||||
|
||||
Para carregar conteúdo, métodos como `loadUrl`, `loadData` e `loadDataWithBaseURL` estão disponíveis. É crucial garantir que essas URLs ou arquivos sejam **seguros para uso**. As configurações de segurança podem ser gerenciadas por meio da classe `WebSettings`. Por exemplo, desabilitar o JavaScript com `setJavaScriptEnabled(false)` pode prevenir ataques XSS.
|
||||
Para carregar conteúdo, métodos como `loadUrl`, `loadData` e `loadDataWithBaseURL` estão disponíveis. É crucial garantir que essas URLs ou arquivos sejam **seguros para uso**. As configurações de segurança podem ser gerenciadas através da classe `WebSettings`. Por exemplo, desabilitar JavaScript com `setJavaScriptEnabled(false)` pode prevenir ataques XSS.
|
||||
|
||||
O "Bridge" JavaScript permite que objetos Java interajam com JavaScript, exigindo que os métodos sejam marcados com `@JavascriptInterface` para segurança a partir do Android 4.2.
|
||||
|
||||
@ -350,11 +349,11 @@ Para controlar o acesso a arquivos:
|
||||
|
||||
### **Verificação de Aplicativos para Segurança Aprimorada**
|
||||
|
||||
- A partir do **Android 4.2**, um recurso chamado **Verificar Aplicativos** permite que os usuários verifiquem a segurança dos aplicativos antes da instalação. Este **processo de verificação** pode alertar os usuários sobre aplicativos potencialmente prejudiciais ou até mesmo impedir a instalação de aplicativos particularmente maliciosos, aprimorando a segurança do usuário.
|
||||
- A partir do **Android 4.2**, um recurso chamado **Verificar Aplicativos** permite que os usuários tenham aplicativos verificados quanto à segurança antes da instalação. Este **processo de verificação** pode alertar os usuários sobre aplicativos potencialmente prejudiciais ou até mesmo impedir a instalação de aplicativos particularmente maliciosos, aprimorando a segurança do usuário.
|
||||
|
||||
### **Gerenciamento de Dispositivos Móveis (MDM)**
|
||||
|
||||
- **Soluções MDM** fornecem **supervisão e segurança** para dispositivos móveis por meio da **API de Administração de Dispositivos**. Elas exigem a instalação de um aplicativo Android para gerenciar e proteger dispositivos móveis de forma eficaz. As funções principais incluem **imposição de políticas de senha**, **obrigação de criptografia de armazenamento** e **permissão para limpeza remota de dados**, garantindo controle e segurança abrangentes sobre dispositivos móveis.
|
||||
- **Soluções MDM** fornecem **supervisão e segurança** para dispositivos móveis através da **API de Administração de Dispositivos**. Elas exigem a instalação de um aplicativo Android para gerenciar e proteger dispositivos móveis de forma eficaz. As funções principais incluem **imposição de políticas de senha**, **exigência de criptografia de armazenamento** e **permissão para limpeza remota de dados**, garantindo controle e segurança abrangentes sobre dispositivos móveis.
|
||||
```java
|
||||
// Example of enforcing a password policy with MDM
|
||||
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
|
||||
@ -365,4 +364,105 @@ if (dpm.isAdminActive(adminComponent)) {
|
||||
dpm.setPasswordMinimumLength(adminComponent, 8);
|
||||
}
|
||||
```
|
||||
## Enumerando e Explorando Serviços AIDL / Binder
|
||||
|
||||
O IPC *Binder* do Android expõe muitos **serviços do sistema e fornecidos pelo fornecedor**. Esses serviços se tornam uma **superfície de ataque** quando são exportados sem uma verificação de permissão adequada (a camada AIDL em si não realiza *nenhum* controle de acesso).
|
||||
|
||||
### 1. Descobrir serviços em execução
|
||||
```bash
|
||||
# from an adb shell (USB or wireless)
|
||||
service list # simple one-liner
|
||||
am list services # identical output, ActivityManager wrapper
|
||||
```
|
||||
1. Tradução do conteúdo relevante para o português.
|
||||
2. Manter a sintaxe markdown e html exatamente como está.
|
||||
3. Não traduzir código, nomes de técnicas de hacking, palavras comuns de hacking, nomes de plataformas cloud/SaaS, a palavra 'leak', pentesting, links e tags markdown.
|
||||
4. Não traduzir links ou caminhos.
|
||||
5. Não traduzir ou modificar tags, links, refs e caminhos específicos.
|
||||
6. Não adicionar nada extra na resposta que não faça parte da tradução e da sintaxe markdown.
|
||||
```
|
||||
145 mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
|
||||
146 wifi : [android.net.wifi.IWifiManager]
|
||||
```
|
||||
* O **índice** (primeira coluna) é atribuído em tempo de execução – ***não*** confie nele entre reinicializações.
|
||||
* O **nome do Binder** (por exemplo, `mtkconnmetrics`) é o que será passado para `service call`.
|
||||
* O valor dentro dos colchetes é a **interface AIDL** totalmente qualificada da qual o stub foi gerado.
|
||||
|
||||
### 2. Obter o descritor da interface (PING)
|
||||
Todo stub do Binder implementa automaticamente o **código de transação `0x5f4e5446`** (`1598968902` decimal, ASCII "_NTF").
|
||||
```bash
|
||||
# "ping" the service
|
||||
service call mtkconnmetrics 1 # 1 == decimal 1598968902 mod 2^32
|
||||
```
|
||||
Uma resposta válida retorna o nome da interface codificado como uma string UTF-16 dentro de um `Parcel`.
|
||||
|
||||
### 3. Chamando uma transação
|
||||
Sintaxe: `service call <name> <code> [type value ...]`
|
||||
|
||||
Especificadores de argumento comuns:
|
||||
* `i32 <int>` – valor assinado de 32 bits
|
||||
* `i64 <long>` – valor assinado de 64 bits
|
||||
* `s16 <string>` – string UTF-16 (Android 13+ usa `utf16`)
|
||||
|
||||
Exemplo – iniciar monitoramento de rede com uid **1** em um dispositivo MediaTek:
|
||||
```bash
|
||||
service call mtkconnmetrics 8 i32 1
|
||||
```
|
||||
### 4. Força bruta em métodos desconhecidos
|
||||
Quando os arquivos de cabeçalho não estão disponíveis, você pode **iterar o código** até que o erro mude de:
|
||||
```
|
||||
Result: Parcel(00000000 00000000) # "Not a data message"
|
||||
```
|
||||
para uma resposta `Parcel` normal ou `SecurityException`.
|
||||
```bash
|
||||
for i in $(seq 1 50); do
|
||||
printf "[+] %2d -> " $i
|
||||
service call mtkconnmetrics $i 2>/dev/null | head -1
|
||||
done
|
||||
```
|
||||
Se o serviço foi compilado **com proguard**, o mapeamento deve ser adivinhado – veja o próximo passo.
|
||||
|
||||
### 5. Mapeando códigos ↔ métodos via onTransact()
|
||||
Descompile o jar/odex que implementa a interface (para stubs AOSP, verifique `/system/framework`; OEMs costumam usar `/system_ext` ou `/vendor`).
|
||||
Procure por `Stub.onTransact()` – ele contém um grande `switch(transactionCode)`:
|
||||
```java
|
||||
case TRANSACTION_updateCtaAppStatus: // 5
|
||||
data.enforceInterface(DESCRIPTOR);
|
||||
int appId = data.readInt();
|
||||
boolean ok = data.readInt() != 0;
|
||||
updateCtaAppStatus(appId, ok);
|
||||
reply.writeNoException();
|
||||
return true;
|
||||
```
|
||||
Agora o protótipo e os **tipos de parâmetro** estão cristalinos.
|
||||
|
||||
### 6. Identificando verificações de permissão ausentes
|
||||
A implementação (geralmente uma classe interna `Impl`) é responsável pela autorização:
|
||||
```java
|
||||
private void updateCtaAppStatus(int uid, boolean status) {
|
||||
if (!isPermissionAllowed()) {
|
||||
throw new SecurityException("uid " + uid + " rejected");
|
||||
}
|
||||
/* privileged code */
|
||||
}
|
||||
```
|
||||
A ausência de tal lógica ou uma lista de UIDs privilegiados (por exemplo, `uid == 1000 /*system*/`) é um **indicador de vulnerabilidade**.
|
||||
|
||||
Estudo de caso – *MediaTek* `startMonitorProcessWithUid()` (transação **8**) executa completamente uma mensagem Netlink **sem** qualquer controle de permissão, permitindo que um aplicativo não privilegiado interaja com o módulo Netfilter do kernel e sobrecarregue o log do sistema.
|
||||
|
||||
### 7. Automatizando a avaliação
|
||||
Ferramentas / scripts que aceleram a reconhecimento do Binder:
|
||||
* [binderfs](https://android.googlesource.com/platform/frameworks/native/+/master/cmds/binderfs/) – expõe `/dev/binderfs` com nós por serviço
|
||||
* [`binder-scanner.py`](https://github.com/adenflare/binder-scanner) – percorre a tabela do binder e imprime ACLs
|
||||
* Atalho Frida: `Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))`
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- [Android Services 101 – Pentest Partners](https://www.pentestpartners.com/security-blog/android-services-101/)
|
||||
- [Android Developer Docs – AIDL](https://developer.android.com/guide/components/aidl)
|
||||
- [Android Developer Docs – IBinder](https://developer.android.com/reference/android/os/IBinder)
|
||||
- [Understanding Binder, Talk @ Google](https://www.youtube.com/watch?v=O-UHvFjxwZ8)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user