{"id":499,"date":"2013-09-16T19:29:36","date_gmt":"2013-09-16T17:29:36","guid":{"rendered":"http:\/\/sseblog.ec-spride.de\/?p=499"},"modified":"2013-09-16T19:29:36","modified_gmt":"2013-09-16T17:29:36","slug":"java-script-attack-vector","status":"publish","type":"post","link":"https:\/\/blogs.uni-paderborn.de\/sse\/2013\/09\/16\/java-script-attack-vector\/","title":{"rendered":"JavaScript in Android Apps &#8211; An Attack Vector"},"content":{"rendered":"<div class=\"twoclick_social_bookmarks_post_499 social_share_privacy clearfix 1.6.4 locale-en_US sprite-en_US\"><\/div><div class=\"twoclick-js\"><script type=\"text\/javascript\">\/* <![CDATA[ *\/\njQuery(document).ready(function($){if($('.twoclick_social_bookmarks_post_499')){$('.twoclick_social_bookmarks_post_499').socialSharePrivacy({\"txt_help\":\"Wenn Sie diese Felder durch einen Klick aktivieren, werden Informationen an Facebook, Twitter, Flattr, Xing, t3n, LinkedIn, Pinterest oder Google eventuell ins Ausland \\u00fcbertragen und unter Umst\\u00e4nden auch dort gespeichert. N\\u00e4heres erfahren Sie durch einen Klick auf das <em>i<\\\/em>.\",\"settings_perma\":\"Dauerhaft aktivieren und Daten\\u00fcber-tragung zustimmen:\",\"info_link\":\"http:\\\/\\\/www.heise.de\\\/ct\\\/artikel\\\/2-Klicks-fuer-mehr-Datenschutz-1333879.html\",\"uri\":\"https:\\\/\\\/blogs.uni-paderborn.de\\\/sse\\\/2013\\\/09\\\/16\\\/java-script-attack-vector\\\/\",\"post_id\":499,\"post_title_referrer_track\":\"JavaScript+in+Android+Apps+%26%238211%3B+An+Attack+Vector\",\"display_infobox\":\"on\"});}});\n\/* ]]> *\/<\/script><\/div><p>One week ago, Trustlook\u00a0publised a <a href=\"http:\/\/blog.trustlook.com\/index.php\/alert-android-webview-addjavascriptinterface-code-execution-vulnerability\/\">blog post<\/a>\u00a0about the\u00a0<em>addJavascriptInterface<\/em> Code execution Vulnerability in Android&#8217;s WebView. Accordingly to that post, we describe the attack in detail and also show Android&#8217;s changes in the OS in order to mitigate this JavaScript attack.<\/p>\n<p><!--more--><\/p>\n<p>The usage of WebViews in Android apps is a widely-used approach because of its OS independent development of apps. If an app is developed in form of a web-GUI, it can be easily integrated in any OS-specific app, such as <a href=\"http:\/\/developer.android.com\/guide\/webapps\/webview.html\">Android<\/a>, <a href=\"https:\/\/developer.apple.com\/library\/ios\/documentation\/uikit\/reference\/UIWebView_Class\/Reference\/Reference.html\">iOS<\/a> or <a href=\"http:\/\/developer.blackberry.com\/native\/documentation\/cascades\/ui\/webview\/\">Blackberry<\/a>. For instance, Chin et al. [1] analyzed 864 different Android apps in their research, where 608 \u00a0(70%) of those contained WebViews. This shows that the integration of WebViews is common in Android apps.<\/p>\n<p>Last week, <a href=\"http:\/\/blog.trustlook.com\/index.php\/alert-android-webview-addjavascriptinterface-code-execution-vulnerability\/\">Trustlook<\/a> published a blog post about a WebView vulnerability in Android that allows an attacker to execute arbitrary\u00a0code in an application (e.g., install new application on the device) just via a drive-by attack. In this post we want to describe the attack in detail and explain Google&#8217;s mitigation against it.<\/p>\n<p>The general idea of this attack is described with the following picture:<\/p>\n<p><a href=\"http:\/\/blogs.uni-paderborn.de\/sse\/files\/2013\/09\/attackOverview.png\"><img decoding=\"async\" class=\"size-medium wp-image-515 aligncenter\" alt=\"attackOverview\" src=\"http:\/\/blogs.uni-paderborn.de\/sse\/files\/2013\/09\/attackOverview.png\" width=\"600\" srcset=\"https:\/\/blogs.uni-paderborn.de\/sse\/files\/2013\/09\/attackOverview.png 720w, https:\/\/blogs.uni-paderborn.de\/sse\/files\/2013\/09\/attackOverview-274x300.png 274w\" sizes=\"(max-width: 720px) 100vw, 720px\" \/><\/a><\/p>\n<ol>\n<li>A benign application creates a <a href=\"http:\/\/developer.android.com\/reference\/android\/webkit\/WebView.html\">WebView<\/a>\u00a0for displaying web pages.<\/li>\n<li>These web pages are also allowed to contain JavaScript in it. Therefore the WebView enables the execution of JavaScript.<\/li>\n<li>\n<h4>addJavascriptInterface(): By calling this Android API method, an object (in this case: JsInvokeClass) gets injected into the JavaScript context.\u00a0This allows the Java object&#8217;s methods to be accessed from JavaScript. The second argument of that method (&#8220;Attack&#8221;) is used to expose the object in JavaScript.<\/h4>\n<\/li>\n<li>In our example, we directly call an html code via the <em>loadUrl()<\/em> method. The URL is hard-coded here, but there are other use cases (e.g., browser) where the string is inserted by the user.\u00a0The html code contains some JavaScript, which is shown in the &#8220;JavaScript&#8221;-box.<\/li>\n<li>After 4. the user accesses the web page and the JavaScript gets executed. The JavaScript method <em>execute()<\/em>\u00a0accesses the <em>getClass()<\/em> method of the <em>JsInvokeClass <\/em>(Attack.getClass()). Since JsInvokeClass is extended from Object, we can call getClass via the\u00a0supplied name &#8220;Attack&#8221;. After that we are using reflections to call any Java method. In this case the <em>getRuntime()<\/em> method in order to\u00a0execute any command (args). The command in the example is responsible for writing the text &#8220;THIS_IS_JUST_A_TEXT&#8221; into output.txt (sdcard).\u00a0<a href=\"http:\/\/blog.trustlook.com\/index.php\/alert-android-webview-addjavascriptinterface-code-execution-vulnerability\/\">Trustlook<\/a> described a different attack where an app gets built via string concatenation of the app&#8217;s binary code \u00a0that is written into a new file (apk) and gets installed afterwards. If the mobile device is in debug mode, the installation of that new app happens in the background without any user recognition. Quite sexy!<\/li>\n<\/ol>\n<p>What are the countermeasures and how can a developer mitigate this attack ? Google is aware of this Problem (see <a title=\"API-description\" href=\"http:\/\/developer.android.com\/reference\/android\/webkit\/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29All)\">API-description<\/a>) that&#8217;s why they introduced the Java Annotation <em>@JavaScriptInterface<\/em> in Android 4.2. All applications declaring <span style=\"font-family: courier new,courier\">targetsdk<\/span> &gt;= 17 in the AndroidManifest.xml file that need the interaction between JavaScript and Java have to explicitly annotate those methods that are accessed by the JavaScript. In our case this would cause the annotation of the returnHelloWorld() method in order to call it via JavaScript:<br \/>\n<span style=\"font-family: courier new,courier\"><br \/>\n@JavaScriptInterface<br \/>\npublic String returnHelloWorld()<br \/>\n<\/span><\/p>\n<p>All other methods are not able to be access. This is also the reason why our example is no longer working, since the\u00a0<span style=\"font-family: courier new,courier\">getClass()<\/span> method is not annotated.<\/p>\n<p>We recommend to declare the <span style=\"font-family: courier new,courier\">targetsdk<\/span> of their application to version 17 or higher if the interaction between JavaScript an Java is necessary in an app. For older version try to avoid remote injection possibilities by loading JavaScript from remote. Store the JavaScript local in the application or simple try to avoid declaring such interfaces JS calling android API code.<\/p>\n<p>&nbsp;<\/p>\n<p>Stephan Huber and <a href=\"http:\/\/www.ec-spride.tu-darmstadt.de\/csf\/sse\/staff_sse\/siegfried_rasthofer\/siegfried_rasthofer.en.jsp\">Siegfried Rasthofer<\/a><\/p>\n<p>[1]\u00a0Chin, Erika, and David Wagner. &#8220;Bifocals: Analyzing WebView Vulnerabilities in Android apps.&#8221;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>One week ago, Trustlook\u00a0publised a blog post\u00a0about the\u00a0addJavascriptInterface Code execution Vulnerability in Android&#8217;s WebView. Accordingly to that post, we describe the attack in detail and also show Android&#8217;s changes in the OS in order to mitigate this JavaScript attack.<\/p>\n","protected":false},"author":6581,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,61],"tags":[],"class_list":["post-499","post","type-post","status-publish","format-standard","hentry","category-android","category-security-vulnerability"],"_links":{"self":[{"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/posts\/499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/users\/6581"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/comments?post=499"}],"version-history":[{"count":0,"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/posts\/499\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/media?parent=499"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/categories?post=499"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.uni-paderborn.de\/sse\/wp-json\/wp\/v2\/tags?post=499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}