{"id":22,"date":"2012-07-19T12:22:20","date_gmt":"2012-07-19T19:22:20","guid":{"rendered":"http:\/\/seanmurphree.com\/blog\/?p=22"},"modified":"2012-08-02T00:13:49","modified_gmt":"2012-08-02T07:13:49","slug":"blackbox-level1","status":"publish","type":"post","link":"https:\/\/seanmurphree.com\/blog\/?p=22","title":{"rendered":"BlackBox Level1 &#8211; Welcome to the GDB"},"content":{"rendered":"<p>Welcome. \u00a0This blog will be about the <a title=\"BlackBox\" href=\"http:\/\/blackbox.smashthestack.org:85\/\" target=\"_blank\">BlackBox<\/a> wargame on the <a title=\"SmashTheStack Network\" href=\"http:\/\/www.smashthestack.org\" target=\"_blank\">SmashTheStack Network<\/a>. Today we will be starting off the wargame with Level1. \u00a0Since BlackBox is a more advanced wargame, basic ssh and linux experience will be assumed. \u00a0Also, the actual password for the next level will be replaced on this page with a string Y&#8217;s. \u00a0If you want to do the level, do it.<\/p>\n<p>According to the BlackBox webpage, level1 can be accessed via username\/password level1\/level1 on blackbox.smashthestack.org port 2225. \u00a0Upon logging in a quick directory listing shows a SUID program for user level2 group level1, named login2. \u00a0This must be the program we&#8217;re going to exploit. \u00a0A quick run of the program gives the following<\/p>\n<blockquote><p>level1@blackbox:~$ .\/login2<br \/>\nUsername: level1<br \/>\nPassword: level1<br \/>\nInvalid username or password<br \/>\nlevel1@blackbox:~$ .\/login2<br \/>\nUsername: level2<br \/>\nPassword: level2<br \/>\nInvalid username or password<\/p><\/blockquote>\n<p>Now we know the program probably isn&#8217;t linked directly to \/etc\/passwd or \/etc\/shadow since level1\/level1 wasn&#8217;t valid. \u00a0Additionally the simple attempt of level2\/level2 didn&#8217;t work, so more digging is needed. \u00a0First to notice, no source code is available. \u00a0Thus, we&#8217;ll have to resort to other attempts to reverse engineer the program. \u00a0First we&#8217;ll start with determining the file type of the program with the file command:<\/p>\n<blockquote><p>level1@blackbox:~$ file login2<br \/>\nlogin2: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU\/Linux 2.4.1, statically linked, for GNU\/Linux 2.4.1, not stripped<\/p><\/blockquote>\n<p>Now we know we have an executable. \u00a0Quick attack for static strings would be to run strings on the program and testing each result as a username\/password. \u00a0This will result in n^2 attempts where n is the number of strings returned from the strings command. \u00a0Unfortunately, running strings and taking the number of lines (strings login2 | wc -l), we see that there are 2279 lines and with the n^2 algorithm that would be aprox 2*10^7652, or a number far to large to check. \u00a0IF we could test 1 million (1*10^6) login\/pass combo&#8217;s per second, it would still take [(2*10^7652)\/(1*10^6) ] seconds to test all of those combos (which is still 2.3*10^7641 DAYS, I don&#8217;t know if we have a term for how large that number is). \u00a0So, we need a better approach.<\/p>\n<p>The approach we will take has to do with reverse engineering. \u00a0We will try to figure out specifically which string the program tests as the username and password. \u00a0To do this we will use the command line debugging tool gdb. \u00a0To load the program use the command &#8220;gdb &lt;program to debug&gt;&#8221;. \u00a0In our case, from the home directory, &#8220;gdb login2&#8221;. \u00a0From here the first two commands we need to know are the &#8220;run&#8221; command, which starts the loaded program, and the &#8220;disass&#8221; command which disassembles and shows the assembly code of a function or memory address. \u00a0Type &#8220;run&#8221; to test that the program runs correctly in gdb, then disassemble the main function to attempt to understand the program with the &#8220;disass main&#8221; command. \u00a0(For a gdb cheat sheet head on over to <a title=\"darkdust.net\" href=\"http:\/\/darkdust.net\/files\/GDB%20Cheat%20Sheet.pdf\" target=\"_blank\">darkdust.net<\/a>\u00a0or google.) \u00a0Since main is a little long, I will assume you can follow along on your own screen.<\/p>\n<p>One easy way to get an idea of what is happening in the assembly is to look at the call instructions. \u00a0These are where functions were called in the original program. \u00a0Our asm code has the following calls:<\/p>\n<blockquote><p>0x08048292 &lt;main+24&gt;: call 0x8072ec0 &lt;_ZNSsC1Ev&gt;<br \/>\n0x0804829d &lt;main+35&gt;: call 0x8072ec0 &lt;_ZNSsC1Ev&gt;<br \/>\n0x080482b1 &lt;main+55&gt;: call 0x806d8f0 &lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;<br \/>\n0x080482c4 &lt;main+74&gt;: call 0x806b2e0 &lt;_ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E&gt;<br \/>\n0x080482d8 &lt;main+94&gt;: call 0x806d8f0 &lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;<br \/>\n0x080482eb &lt;main+113&gt;: call 0x806b2e0 &lt;_ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E&gt;<br \/>\n0x080482fe &lt;main+132&gt;: call 0x80483ee &lt;_ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_&gt;<br \/>\n0x08048317 &lt;main+157&gt;: call 0x80483ee &lt;_ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_&gt;<br \/>\n0x08048343 &lt;main+201&gt;: call 0x806d8f0 &lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;<br \/>\n0x08048353 &lt;main+217&gt;: call 0x806bf10 &lt;_ZNSolsEPFRSoS_E&gt;<br \/>\n0x0804835f &lt;main+229&gt;: call 0x80b5ab0 &lt;system&gt;<br \/>\n0x08048375 &lt;main+251&gt;: call 0x806d8f0 &lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;<br \/>\n0x08048385 &lt;main+267&gt;: call 0x806bf10 &lt;_ZNSolsEPFRSoS_E&gt;<br \/>\n0x08048390 &lt;main+278&gt;: call 0x8074e40 &lt;_ZNSsD1Ev&gt;<br \/>\n0x080483a3 &lt;main+297&gt;: call 0x8074e40 &lt;_ZNSsD1Ev&gt;<br \/>\n0x080483b3 &lt;main+313&gt;: call 0x8074e40 &lt;_ZNSsD1Ev&gt;<br \/>\n0x080483ce &lt;main+340&gt;: call 0x8074e40 &lt;_ZNSsD1Ev&gt;<br \/>\n0x080483dc &lt;main+354&gt;: call 0x80a5180 &lt;_Unwind_Resume&gt;<\/p><\/blockquote>\n<p>At this point we can google the mangled function names, such as\u00a0&lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;, and figure out which function it was in c, in this case it&#8217;s the printf function. \u00a0Additionally, &lt;_ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E&gt; is get line from user and\u00a0&lt;_ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_&gt; is string compare!<\/p>\n<p>Great! \u00a0Now, knowing what we do we can assume the first set of print\/getline get&#8217;s the username and the second set of print\/getline get&#8217;s the password. \u00a0We also then see two string compares, one at main+132 and one at main+157. \u00a0First we&#8217;ll look at the username, then we&#8217;ll do the password.<\/p>\n<blockquote><p>0x080482a2 &lt;main+40&gt;: movl $0x80ffe48,0x4(%esp)<br \/>\n0x080482aa &lt;main+48&gt;: movl $0x8130f60,(%esp)<br \/>\n0x080482b1 &lt;main+55&gt;: call 0x806d8f0 &lt;_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc&gt;<\/p><\/blockquote>\n<p>So what is happening here? \u00a0Well, when a function is called, it&#8217;s parameters are often put on the stack. \u00a0So in the first case of the printf function, two parameters are moved in, both are memory addresses, the first of a string and the second of an int. \u00a0We see the use of printf(string, stringlen);. \u00a0If we want to examine memory in gdb we use the &#8220;x&#8221; command. \u00a0The usage we will use is &#8220;x\/1s 0x080ffe48&#8221;. \u00a0This means examine one string at memory 0x080ffe48 (the memory address passed as a string to printf). \u00a0We get the following:<\/p>\n<blockquote><p>(gdb) x\/1s 0x080ffe48<br \/>\n0x80ffe48 &lt;_IO_stdin_used+4&gt;: &#8220;Username: &#8220;<\/p><\/blockquote>\n<p>Just what we expected! \u00a0The first string printed by the program was &#8220;Username: &#8220;, and that is what we have found through reverse engineering the assembly. \u00a0Now for the input.<\/p>\n<blockquote><p>0x080482b6 &lt;main+60&gt;: lea 0xfffffff4(%ebp),%eax<br \/>\n0x080482b9 &lt;main+63&gt;: mov %eax,0x4(%esp)<br \/>\n0x080482bd &lt;main+67&gt;: movl $0x8130ec0,(%esp)<br \/>\n0x080482c4 &lt;main+74&gt;: call 0x806b2e0 &lt;_ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E&gt;<\/p><\/blockquote>\n<p>Now what is happening here is only slightly more involved due to the lea command. \u00a0But what is happening is lea is loading the address of a variable declared in the program (such as char inputUserName[128];) and putting it on the stack as the first parameter. \u00a0The second movl command is just supplying another memory address, in this case a number, the length of the array. \u00a0This is fine and dandy, but let&#8217;s move on to the string compare for username:<\/p>\n<blockquote><p>0x080482f0 &lt;main+118&gt;: movl $0x80ffe5e,0x4(%esp)<br \/>\n0x080482f8 &lt;main+126&gt;: lea 0xfffffff4(%ebp),%eax<br \/>\n0x080482fb &lt;main+129&gt;: mov %eax,(%esp)<br \/>\n0x080482fe &lt;main+132&gt;: call 0x80483ee &lt;_ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_&gt;<\/p><\/blockquote>\n<p>We know string comparing needs two strings strcmp(s1, s2) and returns a value. \u00a0We see the setup here,\u00a0movl $0x80ffe5e,0x4(%esp) loads in one of the strings. \u00a0So let&#8217;s examine that memory value, looking for 1 string<\/p>\n<blockquote><p>(gdb) x\/1s 0x080ffe5e<br \/>\n0x80ffe5e &lt;_IO_stdin_used+26&gt;: &#8220;level2&#8221;<\/p><\/blockquote>\n<p>Well what do you know, a string. \u00a0Looks like this is the user name. \u00a0Can double check by examining the other value loaded in but you can see the way it is referenced (lea from ebp) that it&#8217;s a variable from within the C program, the same one getline used for getting user input. \u00a0Alright! \u00a0We have the username, now onto the password! \u00a0It&#8217;s all the same for the password:<\/p>\n<blockquote><p>0x08048309 &lt;main+143&gt;: movl $0x80ffe65,0x4(%esp)<br \/>\n0x08048311 &lt;main+151&gt;: lea 0xfffffff0(%ebp),%eax<br \/>\n0x08048314 &lt;main+154&gt;: mov %eax,(%esp)<br \/>\n0x08048317 &lt;main+157&gt;: call 0x80483ee &lt;_ZSteqIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_&gt;<\/p>\n<p>&#8230;<\/p>\n<p>(gdb) x\/1s 0x080ffe65<br \/>\n0x80ffe65 &lt;_IO_stdin_used+33&gt;: &#8220;YYYYYYYY&#8221;<\/p><\/blockquote>\n<p>And there we have it. \u00a0Run the program (from the shell, not gdb, otherwise your privileges won&#8217;t be escalated) and use the username\/password we found above.<\/p>\n<blockquote><p>level1@blackbox:~$ .\/login2<br \/>\nUsername: level2<br \/>\nPassword: YYYYYYYY<br \/>\nWelcome, level 2!<br \/>\nsh-3.1$ whoami<br \/>\nlevel2<\/p><\/blockquote>\n<p>So that long assembly primer was BlackBox Level1 from SmashTheStack.org. \u00a0Assembly is extremely important to know if you want to truly understand how computers are working, and understand security. \u00a0For security, strcmp is not a secure function. \u00a0You cannot use string compare without providing two strings and when your strings are in plain text, not only can your program see them, but so can the person controlling your program, and users are always in control of their system. \u00a0Remember, nothing to do with computers is magic, it&#8217;s all very well defined.\u00a0\u00a0Every bit on a computer means nothing without context, but in the correct context all is understood.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Welcome. \u00a0This blog will be about the BlackBox wargame on the SmashTheStack Network. Today we will be starting off the wargame with Level1. \u00a0Since BlackBox is a more advanced wargame, basic ssh and linux experience will be assumed. \u00a0Also, the &hellip; <a href=\"https:\/\/seanmurphree.com\/blog\/?p=22\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7,6,4],"tags":[48,12,10,9,11,47],"_links":{"self":[{"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/22"}],"collection":[{"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22"}],"version-history":[{"count":6,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions"}],"predecessor-version":[{"id":171,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions\/171"}],"wp:attachment":[{"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/seanmurphree.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}