OverTheWire - Natas

Cameron Blankenbuehler — Tue, 31 Dec 2024 00:00:00 +0000

Introduction</a></h2>
The Natas wargame</a> is another 1</a> wargame hosted by OverTheWire. This one focuses on web security.
In this walkthrough I’m going to show the process for solving each challenge and try to provide some insight into what each challenge is trying to teach and why it’s useful, so keep an eye out for callouts like those below.

Each Natas level is accessible via browser at the specified URL for the level. For example, the level 0 url is: http://natas0.natas.labs.overthewire.org</a>. </blockquote>

If you’re looking for the solution of a particular level, you are highly encouraged to attempt it on your own before following this walkthrough. You will learn some useful things regardless, but attempting each level on your own first will help the knowledge stick better. I promise. </blockquote>
Prerequisites</a></h2>
The solutions for each level will be illustrated with numerous screenshots, so you won’t need any other tools to just read along. However, if you’d like to have a better understanding of what’s going on, you may want to familiarize yourself with a few things.

The basics of HTML and PHP will be quite important. If you’re familiar with another programming language you can probably follow along with any challenges that require PHP without too much trouble though.</li>
The browser dev tools. Specifically for Chrome/chromium browsers, though everything we do in this walkthrough should also be possible via the dev tools for other browsers like Firefox, Opera, etc. If you’d like an introduction check out this overview of the Chrome devtools</a></li>
Knowledge of HTTP will be essential for several levels and is somewhat of a prerequisite to effectively use the web proxies mentioned next.</li>
A web proxy. Zed Attack Proxy (ZAP)</a> and PortSwigger’s Burp Suite</a> are the most popular ones. Either will suffice, but I’ll be demonstrating the solutions in this walkthrough with ZAP wherever a proxy is needed.</li> </ol>
That’s it. Enjoy the walkthrough!
Walkthrough</a></h2>
Level 0</a></h3>
Most of the levels of Natas begin with some kind of hint, links to other pages, or an interactive form.
For example, the level 0 home page shows a hint.

The first step in examining any web application should always include viewing the source code. Use the keyboard shortcut `Ctrl-U</code> or right click the page and select “View page source” to view the source code of the page. This will give you insight into what content is on the page, what other resources are used by the page like Javascript and CSS files and links to other resources available on the website.`
`<body> <h1>natas0</h1> <div id="content"> You can find the password for the next level on this page.  </div> </body></code></pre>`
The source code for the level 0 home page clearly shows the password for level 1</a> as an HTML comment.
While direct data disclosure on a web page like this isn’t overly abundant, it can still be found in the wild 2</a> and should always be considered when examining a web application for vulnerabilities.
Level 1</a></h3>
This challenge is similar to the last one. The hint provided even mentions that “rightclicking” is blocked now.

To bypass this, the keyboard shortcut `Ctrl-U</code> mentioned earlier can be used to view the source. Once again, the password is clearly shown in an HTML comment.`
<body oncontextmenu="javascript:alert('right clicking has been blocked!');return false;"> <h1>natas1</h1> <div id="content"> You can find the password for the next level on this page, but rightclicking has been blocked!  </div> </body></code></pre>
Level 2</a></h3>
Level 2 doesn’t provide much information, but examining the page’s source will give some insight into solving this level.

12<h1>natas2</h1> 13<div id="content"> 14There is nothing on this page 15<img src="files/pixel.png"> 16</div></code></pre> In addition to the message stating there’s nothing on this page, there is an <img></code> tag linking to an image file at /files/pixel.png</code>. Most importantly, this link indicates some files are being served by the web server under the /files</code> directory. Navigating to this endpoint at http://natas2.natas.labs.overthewire.org/files/</code> shows some interesting files. Besides the image file, there is also a text file users.txt</code>. This file reveals the password for the next level. 
`This kind of vulnerability would most likely be classified as a` `security misconfiguration</a>. Clearly the users.txt</code> should not be accessible. Access should be blocked by the web server or at least restricted to particular users.`
Level 3</a></h3> Once again, the home page doesn’t reveal much at first glance. Let’s look at the source. <body> <h1>natas3</h1> <div id="content"> There is nothing on this page  </div> </body></code></pre> This time, the HTML comment provides a subtle clue. It mentions that “[n]ot even Google will find it” which is hinting at something called a robots.txt</code></a> file which contains a list of directories and files that should be ignored by web crawlers. Search engines like Google and Bing use the robots.txt</code> file to determine which files and directories they shouldn’t be indexing. robots.txt In this case, there is only a single directory /s3cr3t</code> being disallowed. Navigating to that directory reveals a single file, users.txt</code>. View the users.txt</code> file for the password to the next level. Looking at the robots.txt</code> is a common step taken by attackers when performing reconnaissance on a web application since it can sometimes reveal locations that the developers have deemed sensitive enough to exclude from search indexing. </blockquote> Level 4</a></h3> Level 4 is the first challenge we’ve seen that can’t simply be solved by examining the page source or navigating to some specific endpoint. If you aren’t familiar with HTTP, there are some excellent guides on HTTP</a> available in the MDN Web Docs</a>. Essentially every3</a> request by the browser uses HTTP. Fortunately the dev tools have a convenient interface for examining the HTTP requests made by the browser. These requests can be viewed in the Network tab of the browser dev tools. There’s a bunch of cool stuff you can do with the network tab, but for this challenge we’re only interested in that highlighted request to index.php</code>, which is the home page for level 4. Here’s the network tab after loading the level 4 home page. Click on that index.php</code> to view more information about the request like the request’s headers. The message on the home page hints that authorized users “come from” the URL http://natas5.natas.labs.overthewire.org/</code>. The key is recognizing that there is an HTTP header that’s used to convey this information from the client to the web server. Unfortunately, at the time of this writing, the request headers can’t be easily edited in the browser. Instead we’ll need to use another tool to craft an HTTP request with the appropriate header to convince the web server that we’re a user from http://natas5.natas.labs.overthewire.org</code>. This is where knowledge of HTTP is essential, because you have to recognize that we’re looking for the Referer4</a> HTTP header which is used to indicate the source of a request. As I mentioned before, the browser doesn’t allow for modifying request headers, so we’ll need to use a different tool. The simplest will be to use a command line tool like curl</a>, though a web proxy like ZAP or Burp Suite will work just as well. curl</code> is a program for transferring data to or from a server using URLs. We’ll just be using it with HTTP, but it supports other protocols too. If you’d like to dig into the capabilities of curl, I’d recommend reading through the Everything curl</a> guide, but, if you’re in a hurry, the browser dev tools have a convenient feature to construct a web request in the curl format from the Network tab. Just right-click on the request and click “Copy as cURL” under the “Copy” menu. Paste the command into the terminal or a text editor and it should look something like this. curl 'http://natas4.natas.labs.overthewire.org/index.php' \ -H 'Accept-Language: en-US,en;q=0.9' \ -H 'Authorization: Basic [REDACTED]' \ -H 'Cache-Control: no-cache' \ -H 'Connection: keep-alive' \ -H 'Pragma: no-cache' \ -H 'Upgrade-Insecure-Requests: 1' \ --insecure</code></pre> Each argument to the -H</code> flag is an HTTP header. Now, just add an argument for the Referer header with the correct value as mentioned in the message on the home page. curl 'http://natas4.natas.labs.overthewire.org/index.php' \ -H 'Accept-Language: en-US,en;q=0.9' \ -H 'Authorization: Basic [REDACTED]' \ -H 'Cache-Control: no-cache' \ -H 'Connection: keep-alive' \ -H 'Pragma: no-cache' \ -H 'Upgrade-Insecure-Requests: 1' \ -H 'Referer: http://natas5.natas.labs.overthewire.org/' \ --insecure</code></pre> Be sure to keep the original Authorization</code> header from your own HTTP request. It’s required to handle the Basic authentication</a> that was previously handled by the browser. Alternatively you can provide the credentials with the -u</code> flag like so. Replacing REDACTED</code> with the level 4 password you used to access this level. curl -H 'Referer: http://natas5.natas.labs.overthewire.org/' \ -u natas4:REDACTED \ http://natas4.natas.labs.overthewire.org</code></pre> The curl</code> response should contain the following body with the password to the next level. <body> <h1>natas4</h1> <div id="content"> Access granted. The password for natas5 is [REDACTED] <br/> <div id="viewsource"><a href="index.php">Refresh page</a></div> </div> </body></code></pre> HTTP headers are useful for a lot of things, but be cautious. Using them incorrectly for authentication as the Referer</code> header is used in this challenge can lead to all kinds</a> of security vulnerabilities. </blockquote> Level 5</a></h3> The level 5 message is a bit more cryptic than the previous levels, but it does give us a place to start. First identify what mechanisms may be used for tracking the login state of a user. Stateless protocols</a> like HTTP cannot retain session state between requests and must instead work around that limitation with some kind of session management mechanism. In the case of HTTP this is most often handled with HTTP cookies</a>. Under the Application tab of the browser dev tools you should find a list of storage options available to the browser, including any HTTP cookies. In this case there’s a single cookie labeled loggedin</code> from the natas5</code> domain. It’s set to 0</code>. Try changing the value to 1</code>. Reloading the page should yield a message of “Access granted” with the password to the next level. Cookies can, in fact, be used for secure session management. But not like this. </blockquote> Level 6</a></h3> This level doesn’t give any message. Just an input form and a link to “View sourcecode” The “View sourcecode” link doesn’t show the client-side source. It actually shows the code as it exists on the server. The critical section below shows how PHP will render the page based on secret</code> POST parameter which is set by the form and checked against the $secret</code> variable. 1<? 2include "includes/secret.inc"; 3 4 if(array_key_exists("submit", $_POST)) { 5 if($secret == $_POST['secret']) { 6 print "Access granted. The password for natas7 is <censored>"; 7 } else { 8 print "Wrong secret"; 9 } 10 } 11?> 12 13<form method=post> 14Input secret: <input name=secret><br> 15<input type=submit name=submit> 16</form></code></pre> Also note the include</code> statement which references a file at includes/secret.inc</code>. Navigating to that location shows the following PHP file where the $secret</code> variable is defined. <? $secret = "FOEIUWGHFEEUHOFUOIU"; ?></code></pre> Entering the secret defined in includes/secret.inc</code> into the form will return the password for level 7. Level 7</a></h3> This level actually has multiple pages. Home page About page The page source contains a useful hint. <body> <h1>natas7</h1> <div id="content"> <a href="index.php?page=home">Home</a> <a href="index.php?page=about">About</a> <br> <br>  </div> </body></code></pre> The most important thing to notice in this source code is that the “Home” and “About” links are specifying their target pages via query parameters. As always, when performing a web application test, it’s important to examine any entry point for user input. The combination of the mentioned links and the hint provided should lead you to investigate for any local file inclusion (LFI)</a> vulnerabilities. Modify the page</code> query parameter to reference the level 8 password file like so. http://natas7.natas.labs.overthewire.org/index.php?page=../../../../etc/natas_webpass/natas8`</code></pre> Note the several doubled dots ../</code> chained together to backtrack the current directory to the root of the file system before continuing to the password directory at /etc/natas_webpass/</code> as mentioned by the hint. Level 8</a></h3> Similar to level 6</a>, the main page of level 8 contains an input text field and a link to the server-side source code. However, this time the encoding of the secret is a bit more complicated. 1<? 2 3$encodedSecret = "3d3d516343746d4d6d6c315669563362"; 4 5function encodeSecret($secret) { 6 return bin2hex(strrev(base64_encode($secret))); 7} 8 9if(array_key_exists("submit", $_POST)) { 10 if(encodeSecret($_POST['secret']) == $encodedSecret) { 11 print "Access granted. The password for natas9 is <censored>"; 12 } else { 13 print "Wrong secret"; 14 } 15} 16?> 17 18<form method=post> 19Input secret: <input name=secret><br> 20<input type=submit name=submit> 21</form></code></pre> The php script has an $encodedSecret</code> variable which is checked before granting access to the next password. The encodeSecret</code> function encodes the $secret</code> variable into base64, reverses the string, and converts the ASCII string to hex. The encoding algorithm could be reversed with any programming language, but PHP has functions available to easily reverse them all. PHP function</th> Description</th></tr></thead> hex2bin</a></td> decodes a hexadecimally encoded binary string</td></tr> strrev</a></td> reverse a string</td></tr> base64_decode</a></td> decodes data encoded with MIME base64</td></tr> </tbody></table> The encoding can be reversed with the following PHP script. 1<?php 2 $res = hex2bin("3d3d516343746d4d6d6c315669563362"); 3 echo "$res\n"; 4 $res = strrev($res); 5 echo "$res\n"; 6 $res = base64_decode($res); 7 echo "$res\n"; 8?> </code></pre> If you don’t have PHP installed on your system, the script can be executed on an online platform like repl.it</a>. Otherwise, save the script locally and execute it with php -f script.php</code>. </blockquote> Enter the decoded secret into the form to get the password to the next level. Level 9</a></h3> Level 9 is a bit different than anything we’ve seen so far. It contains a form that accepts an input to search a dictionary for words that match. Empty search input Search for the string ‘hack’ Similar to the previous challenges though, we have a link to the PHP source code. <? $key = ""; if(array_key_exists("needle", $_REQUEST)) { $key = $_REQUEST["needle"]; } if($key != "") { passthru("grep -i $key dictionary.txt"); } ?></code></pre> One thing we should take note of is the passthru</a> function which executes an external program as if it was run from the command line. We can see passthru</code> is being used to execute the grep</code> command on a file called dictionary.txt</code>. Download that file and see what it contains. As you might have suspected, it’s a list of words, and it’s sorted alphabetically. A quick scan of the file doesn’t reveal any unusual entries. There are a few words with diacritics, but that is it. Instead let’s focus on $key</code>. It’s being passed directly into the passthru</code> function without any sanitization, essentially giving us complete control over the command being executed by the server. Here are a few possible payloads. Note the leading ;</code> which is used by Bash to indicate the end of a line allowing us to insert a new command like cat</code>. # this payload outputs the entire dictionary.txt instead of just the grepped lines ;cat # this payload outputs the /etc/passwd file in addition to dictionary.txt ;cat /etc/passwd # this payload outputs the natas 10 password in addition to dictionary.txt ;cat /etc/natas_webpass/natas10 # this outputs ONLY the natas 10 password # The trailing '#' marks the remainder of the line as a comment # which prevents the dictionary.txt from being output ;cat /etc/natas_webpass/natas10 #</code></pre> Using ;cat /etc/natas_webpass/natas10 #</code> as a payload returns the contents of the natas10</code> password file. This type of attack falls under the Injection</a> category of the OWASP Top 10 (2021)</a>. Specifically it’s a command injection vulnerability and is a concern whenever user input is passed to an execution environment such as Bash as it’s done in this level. </blockquote> Level 10</a></h3> The front page for level 10 is the same as level 9</a> with some slight changes in the source code. <? $key = ""; if(array_key_exists("needle", $_REQUEST)) { $key = $_REQUEST["needle"]; } if($key != "") { if(preg_match('/[;|&]/',$key)) { print "Input contains an illegal character!"; } else { passthru("grep -i $key dictionary.txt"); } } ?></code></pre> In this iteration of the word search form, a call to preg_match</code></a> is used to catch the ;</code>, |</code>, and &</code> symbols, so it won’t be possible to simply prefix the command with ;</code> like we did before. Fortunately for us, this was a naive approach to sanitize inputs. The search input is still passed into the grep</code> command which can take multiple arguments. So files can still be searched even if they can’t be directly output with the cat</code> command. This payload should do the trick: "." /etc/natas_webpass/natas11 #</code>. It makes the grep</code> command return every line in the natas11</code> password file and comments out the dictionary.txt</code> argument with #</code> just like in level 9</a>. To be continued</a></h2> I hope you enjoyed the walkthrough. When time permits, I intend to expand this post to include every level of OverTheWire Natas. Happy hacking! </blockquote> See my writeups for the OverTheWire Bandit</a> and Leviathan</a> wargames. ↩</a> </li> A relatively high-profile example of this sort of data disclosure occurred in 2021 where over 100,000 teachers’ Social Security numbers were accessible by simply viewing the page source of a site hosted by the Missouri Department of Elementary and Secondary Education</a>. See this TechCrunch article</a> for more details. ↩</a> </li> Not every request made by a browser is strictly over HTTP or HTTPS, but it is the most common and is the only protocol that’s essential to understand for the Natas wargame. ↩</a> </li> Yes, the correct spelling should be “Referrer”, however the header was misspelled in the original HTTP specification RFC 1945</a>, so it continues to be misspelled for backwards compatibility. ↩</a> </li> </ol> </section> OverTheWire - Leviathan Cameron Blankenbuehler — Sun, 24 Nov 2024 00:00:00 +0000 Introduction</a></h2> Leviathan</a> is another wargame</a> available at overthewire.org</a>. In this walkthrough I’m going to show the process for solving each challenge while also providing some insight into what each challenge is trying to teach and why it’s useful. Keep an eye out for callouts like those below. Access to each level is made over SSH. The username will correspond to the index of the level starting at 0. Always make sure you’re logging into the correct level! If you’re new to CTFs and wargames you may want to check out the Bandit wargame walkthrough</a> first. </blockquote> None of the Leviathan levels have any additional descriptions. Presumably, since they’re relatively simple, any hints would probably give away the solution. Instead you’re dropped into a regular user session after login with the task of identifying any important files available to that user and using them to find the password to the next level. Walkthrough</a></h2> Level 0</a></h3> To start, there only appears to be a few hidden dotfiles in the home directory. The only atypical thing here is the ~/.backup</code> directory which contains a bookmarks.html</code> file. Solution</a></h4> It’s certainly possible to manually read through the bookmarks for anything interesting, but grep</code> can be utilized to search for some keywords which might be useful. For example, “password” or “flag”. This example is a bit contrived for the sake of the wargame, but this is a common tactic used by attackers. Searching a user’s files with grep</code> for things like usernames, passwords, bank or credit card details, and any other kind of sensitive information is one of the first things an attacker might do once they’ve compromised a user’s account. It should go without saying that you should never store any passwords or other sensitive information in plain text files if it can be avoided. Ideally use a password manager with secure encryption to store any digital account details. </blockquote> Level 1</a></h3> This level presents us with a setuid</a> binary. On some systems this is evident by the red background color, but to verify, you just need to check the file permissions with ls -l</code>. There will be an s</code> in place of the typical x</code> for the user level execution permissions. After running it with an input of abc</code>, it’s clear from the output that the input is being checked against some password string for correctness. We can do some preliminary analysis of the binary’s execution with the ltrace</code></a> program which will record the C level dynamic library function calls made by check</code>. This includes common standard library functions like strcmp</code></a>. Solution</a></h4> From the output of the above ltrace</code>, we can see the parameters passed to the strcmp</code> function call. The first is our test password, and the second is the target password that check</code> is using to verify the input. The ltrace</code> program can be quite useful to perform some initial analysis of a binary’s execution before transitioning to more advanced tools like the gdb</code> debugger. </blockquote> Level 2</a></h3> Here’s another setuid</code> binary. Executing prints from usage information to the console. Following the usage description, a file path may be passed as an argument and be printed to the console. Unfortunately, printing the level3</code> password file isn’t allowed. To investigate, let’s use the ltrace</code> command again. The ltrace</code> output shows calls to access</code></a>, snprintf</code></a>, and system</code></a>. Attempting to read another file for which we have read permissions, e.g. .bashrc</code>, shows that printfile</code> executes the shell command /bin/cat <FILEPATH></code> when the access</code> function call succeeds where <FILEPATH></code> is whatever you pass as the first argument to printfile</code>. The above output was truncated since the .bashrc</code> file is actually quite long. In fact, you might want to redirect stdout to /dev/null</code> to only display the results from ltrace</code>. Just to make it a bit more readable. </blockquote> The setuid bit</a></h4> We saw this in the previous level as well, but I wanted to call attention to the fact that printfile</code> has the setuid</code> bit</a> set. We can even see the function call to setreuid</code> which will set the real and effective user ID for the process. This level and the last are showcasing the dangers of giving any file setuid permissions. Without it printfile</code> wouldn’t be able to access the password file for level 3. Our goal is to craft some input to printfile</code> such that the system</code> call will execute for the password file (/etc/leviathan_pass/leviathan3</code>). But, to reach that point, the path passed in must also be readable by the leviathan2</code> user. With that in mind, one method we can use to trick printfile</code> is by providing a path with a variable. This way the variable will be expanded when the path is passed to the system</code> function, but will be interpreted literally by the call to access</code>. When attacking the input of a program, always try to identify different points of entry. In this case there are two points at which the input path is passed into the program. The first is to the call to access</code> and the second to system</code>. Both of these functions process input differently. When you have multiple points like this without some sort of input validation or normalization, there’s always an opportunity to disrupt the expected behavior of the program. On the flip-side of this, as a developer this showcases why input validation is such an important concept. Never implicitly trust user input. More specifically for this level, system</code> should never be used in a setuid program and user input should never be passed directly to a call to system</code> without sanitization. The system</code> manual page</a> explicitly warns against this practice due to the potential for compromising system security. </blockquote> Solution</a></h4> Level 3</a></h3> This challenge is almost identical to level 1</a>, except that you are dropped into a shell where you can easily cat</code> the password file for level 4. The intended solution for level 1 probably differs slightly from the one provided here since having near duplicate solutions usually isn’t done by wargame and CTF authors. Either way, this one is left as a challenge to the reader. Have fun! Level 4</a></h3> In this level, we have some more hidden files. In the .trash</code> directory is another setuid binary. Solution</a></h4> All the leviathan challenges are possible without any programming, but in this case, you could also solve it with a short python script. print( "".join( [chr(int(x, 2)) for x in "00110000 01100100 01111001 01111000 01010100 00110111 01000110 00110100 01010001 01000100 00001010".split()] ) )</code></pre> This script splits the text into a list of binary numbers and converts each binary number into decimal with int(x, 2)</code>. Each integer is then translated into the corresponding ASCII letter with the chr</code> function before joining each letter back into a single string. Of course it’s also possible to translate it by hand with an ASCII table</a> though you’ll need to convert the binary numbers into either hexadecimal or decimal. Another option is to use one of the many online translators, for example Binary to Text Translator</a>. Level 5</a></h3> It looks like the binary expects a file at /tmp/file.log</code>. Let’s make that file with some dummy content and ltrace</code> the binary to see what’s going on. We have two important things going on in this binary. The contents of the /tmp/file.log</code> are being printed.</li> /tmp/file.log</code> is deleted. See the unlink</code> manual page</a> for details.</li> </ol> The deletion of the file is less of a concern since we can remake the file as needed. More importantly, we have control of the file being printed. Solution</a></h4> Obviously we don’t care too much about the content of /tmp/file.log</code>. But, what if, we could link /tmp/file.log</code> to a more interesting file. Like /etc/leviathan_pass/leviathan6</code> for example. Here we’ve simply made a symbolic link to /etc/leviathan_pass/leviathan6</code> and placed the link file at /tmp/file.log</code>. When leviathan5</code> is executed, the link is followed to the password file for the next level which is printed to stdout. Level 6</a></h3> Hopefully you’ve gotten the hang of the first few steps now. Check for interesting files in the home directory</li> Execute the binary and provide any required input</li> Run the binary via ltrace</code> to see what function calls it’s making</li> </ol> Blast it, this time they’ve managed to foil our use of ltrace</code>. There’s clearly some sort of check going on to verify the input code. We can probably assume the check is happening in a simple if</code> statement comparing the input code to some hardcoded number. Which would explain why it doesn’t show up in ltrace</code> since no library function call is being made. At this point we’re reaching beyond the capabilities of most basic Linux commands. Instead you may have to reach for something like gdb</code></a>, the GNU Debugger. The debugger will allow you to step through the program one instruction at a time. Unfortunately it does require you understand a bit about C and Assembly language</a>. In the disassembly of leviathan6</code> above there are a few important lines. At line main+76</code> we can see the function call to atoi</code> which you should recognize from the preliminary analysis with ltrace</code>. Another important concept to understand is that for x86 binaries like this one, the return results of functions are usually assigned to the eax</code> register.</li> A cmp</code> instruction which is comparing the returned value of the atoi</code> function call in eax</code> to another value on the stack at [ebp-0xc]</code>.</li> </ol> Use the run</code> command to start the program. The program will begin executing and stop at the first breakpoint it finds. After the program stops, we can examine the arguments of the cmp</code> instruction. The command info registers</code> will display the values for all the registers, or the target register can be passed as an argument as shown below. The format for the register listing is register name | hexadecimal | decimal</code>. You can see the decimal representation matches the PIN provided to the program 1234</code>. The other argument to cmp</code> is a bit trickier. It’s actually using a pointer. Meaning the value at ebp - 0xc</code> is actually a memory address and it must be dereferenced to examine the value. The x</code> command can be used to examine memory like this. You can read more in the Examining Memory section</a> of the GDB documentation</a>, but, in summary, the command used here (x/1d $ebp-0xc</code>) examines the memory at the address computed by subtracting 0xc</code> from the value in the ebp</code> register. One integer value at the resolved memory address is then printed to the console thanks to the display format of 1d</code>. Conclusion</a></h2> You can do quite a lot with just some basic terminal commands. Supposedly all the Leviathan levels are possible without any programming knowledge, so I suspect level 6</a> has a simpler intended solution. Either way, know your tools. I think ltrace</code> in particular is useful for understanding the actions of a binary without needing to resort to tools for debugging and reverse engineering like gdb or Ghidra. Don’t forget to clean up any files you’ve created. rm -rf /tmp/MY_TEMP_DIRECTORY</code> </blockquote> Language Transfer and The Thinking Method Cameron Blankenbuehler — Thu, 07 Nov 2024 00:00:00 +0000 Language Transfer</a> is an incredible project by Mihalis Eleftheriou to teach not only languages but a method of learning. First off, the free courses</a> are excellent. The recordings are available on the web, but the content is also available through Apple</a> and Android</a> apps. I’ve personally only completed the German course, but I intend to complete the Spanish and French courses as well. I think these courses exhibit a few important aspects of learning that make them so effective. Student interaction and a call / response methodology to engage students.</li> Pausing for reflection and forming connections. In fact it’s emphasized to facilitate active recall of the material.</li> Repetition. Returning to previous content at appropriate intervals to improve recall.</li> </ul> Miahlis’s method makes it clear that’s okay to slow down and simply think deeply about what you’re learning and not be in such a hurry to get everything right away. I’ve found that when I pause and reflect more often just like Mihalis recommends, my knowledge sticks around longer, it’s richer, and learning a language starts to feel less like a race and more like a walk in the park. OverTheWire - Bandit Cameron Blankenbuehler — Sun, 20 Oct 2024 00:00:00 +0000 Introduction</a></h2> Bandit</a> is just one of several wargames</a> available at overthewire.org</a>. It’s aimed at beginners to Linux and CTFs and provides an excellent introduction to the basics of the Linux command line. In this walkthrough I’m going to show the process for solving each challenge while also providing some insight into what each challenge is trying to teach and why it’s useful, so keep an eye out for callouts like those below. Access to each Bandit level is made over SSH. The username will correspond to the index of the level starting at 0. Always make sure you’re logging into the correct Bandit level! </blockquote> If you’re looking for the solution of a particular level, you are highly encouraged to attempt it on your own before following this walkthrough. You will learn some useful things regardless, but attempting it on your own first will help the knowledge stick better. I promise. </blockquote> I have a few recommendations before getting started. Most of the OverTheWire Bandit levels provide links to potentially useful manual pages. Unfortunately the man</code> pages can be somewhat cryptic, especially for beginners. For that reason I recommend the following steps to try to get unstuck when slogging through the man</code> pages for any particular command. Search for examples. Many man</code> pages contain examples of their usage. These may be marked by all-caps EXAMPLES</code> in some cases, but sometimes not.</li> If skimming through the man pages doesn’t surface any apparent examples, then you may want to refer to cheat.sh</a>. Cheat.sh is a database of usage examples for thousands of command line programs. It can be searched from the main page or by simply adding a /</code> followed by the command. For example https://cheat.sh/ssh</a> will return examples of ssh</code> usage. This one can be helpful when trying to understand how a command is commonly used and which command flags are most useful.</li> If you’re struggling to understand some of the examples then paste them into https://explainshell.com</a>. Explainshell provides a more readable breakdown of each command line flag and argument. This tool can save you a lot of time flipping back and forth through the man</code> pages.</li> </ol> Please also note that for any terminal output, the command prompt will be truncated to a single $</code> for brevity. Just remember that you’ll need to be logged in to the appropriate level before executing any of the commands. For example: $ cat hello.txt Hello there!</code></pre>Logging in</a></h2> The goal of this level is for you to log into the game using SSH. The host to which you need to connect is bandit.labs.overthewire.org, on port 2220. The username is bandit0 and the password is bandit0. Once logged in, go to the Level 1 page to find out how to beat Level 1. </blockquote> Bandit 0</a> provides an introduction to SSH and provides a couple useful links for further research. ssh manual</a></li> SSH - Wikipedia</a></li> </ul> Firstly, let’s discuss what SSH is and how it’s used day-to-day. SSH is a networking protocol that allows secure communication between networked computer systems. This is distinct from the ssh</code> command line program linked above. The program implements the protocol and allows regular users to utilize the SSH protocol for secure communication. The security of SSH is based on public-key cryptography</a> which you’re welcome to read more about, but many of the details are out of scope for this walkthrough. The most important thing you need to know about SSH is that it can be used to login to a computer system with a username</code> and password</code> just as if you were physically present. Except in this case it’s another system accessible over the network. This is how it will be used over the course of the Bandit wargame as well as some of the other wargames by OverTheWire. It’s worth mentioning that SSH is usually (and preferably) used with an SSH key. More specifically a key-pair. A public key and a private key which are both needed to take advantage of the aforementioned public-key cryptography. I won’t go into detail here, but don’t worry there are a couple later levels that do utilize SSH keys, so I’ll discuss them in more detail when we reach them. </blockquote> The prompt tells us that both the username</code> and password</code> are bandit0</code>. Just as important though, is the network location we’ve been provided, bandit.labs.overthewire.org</code>, which we’ll use to connect to level 0. Actually, bandit.labs.overthewire.org</code> is what’s known as a hostname</a> or domain name</a>. More specifically, it’s a fully qualified domain name (FQDN)</a>. You can recognize an FQDN because it will include a top-level domain (TLD)</a> such as .com</code>, .net</code>, or .org</code>. This naming system for computers is called the Domain Name System (DNS)</a>. Luckily we don’t need to dig into the details here. Just know that one of these FQDNs will resolve to an IP address</a> which can (usually) be used to uniquely identify a computer system on the internet. This unique name will tell the ssh</code> program what system to connect to. The ssh</code> program expects the user credentials and hostname in the following format ssh://[user@]hostname[:port]</code>. This is explained in the first couple paragraphs of the ssh man page</a>. ssh connects and logs into the specified destination, which may be specified as either [user@]hostname</code> or a URI of the form ssh://[user@]hostname[:port]</code>. </blockquote> The elements wrapped in brackets [</code> and ]</code> are actually optional. Linux man</code> pages will commonly express the available flags and arguments for a command in this way. With that knowledge we can now connect to the first level with this command. ssh ssh://bandit0@bandit.labs.overthewire.org:2220</code></pre> You should be greeted by a banner for the Bandit wargame and a prompt requesting entry of the bandit0</code> password. Enter bandit0</code> and you’re ready to get started. It isn’t necessary to solve any of the Bandit levels, but I highly recommend researching DNS. It’s intrinsic to how the internet operates and you’ll likely encounter it again and again if you pursue any area of IT, software, or cybersecurity. </blockquote> Resources: What is DNS?</a>: an excellent intro to the basics of DNS by freeCodeCamp</li> Implement DNS in a weekend</a>: if you have some programming experience, I highly recommend following this walkthrough by Julia Evans</li> </ul> Walkthrough</a></h2> Level 0</a></h3> Now that we’re logged in, it’s time to solve the first level. The password for the next level is stored in a file called readme located in the home directory. Use this password to login to bandit1</code> using SSH. Whenever you find a password for a level, use SSH (on port 2220) to log into that level and continue the game. </blockquote> Useful commands 1</a></h4> The prompt also provides links to the man pages for several commands. With perhaps the exception of du</code>. Each of these commands is fundamental for any Linux user who wants to effectively use the command line. Command</th> Description</th></tr></thead> ls</a></td> list the files in a directory</td></tr> cd</a></td> change your current directory</td></tr> cat</a></td> display the contents of a file</td></tr> file</a></td> display information about the content of a file</td></tr> du</a></td> display the disk space used by files</td></tr> find</a></td> search the file system for files with various parameters such as filename, file type, file size, etc.</td></tr> </tbody></table> You are highly encouraged to review each of the commands. At the very least check out the cheat.sh</code> page for each. Regardless these are all pretty common, so you’ll get plenty of experience with these commands in later levels. For now, it should be apparent that one of the above commands should serve to show us the contents of the readme</code> file mentioned in the prompt. The humble cat</code> command. It takes a filename as a parameter. So providing it with the filename readme</code> should print it’s contents. $ cat readme Congratulations on your first steps into the bandit game!! Please make sure you have read the rules at https://overthewire.org/rules/ If you are following a course, workshop, walkthrough or other educational activity, please inform the instructor about the rules as well and encourage them to contribute to the OverTheWire community so we can keep these games free! The password you are looking for is: [REDACTED PASSWORD]</code></pre> I won’t be providing any of the passwords throughout this walkthrough per the OverTheWire rules</a>. So get out your notepad and copy those passwords. You’ll need them to return to the last level you’ve completed without completing each level again. Once you’ve done that, you’re ready to continue to Level 1. Level 1</a></h3> The password for the next level is stored in a file called -</code> located in the home directory </blockquote> The prompt also provides links to the man pages for the same commands as level 0. Naturally, you might think to try the cat</code> command again. Afterall, we’re told the password in in the file called -</code>. Let’s try it and see what happens. $ cat - █</code></pre> Strange, you’re left with a blank line on the terminal now. And, if you type some text and press the Enter</code> key, the text is repeated back to the terminal like so. $ cat - hello there hello there</code></pre> The reason for this will become clear if you read the description from the cat</code> man page. NAME cat - concatenate files and print on the standard output SYNOPSIS cat [OPTION]... [FILE]... DESCRIPTION Concatenate FILE(s) to standard output. With no FILE, or when FILE is -, read standard input.</code></pre> So, according to the description, the parameter -</code>, makes cat</code> read from standard input. You may have guessed this already, but standard input or STDIN is usually what’s entered by the user in the terminal; however, STDIN doesn’t explicitly refer to input from a user. Rather, it refers to a stream of data that is being sent to a program, so it may also refer to files or even the output of other programs that is being passed to other programs. You’ll most likely hear of this concept of input and output referred to as STDIO or standard input and output. If you’d like to read more, there is an excellent article by freeCodeCamp</a> explaining more about it and many other useful concepts. There will be opportunities to demonstrate STDIO and IO redirection later, but for this level, all you need to recognize is that -</code> is a special character that tells cat to read input from STDIN instead of a file as we saw before. So to properly refer to the -</code> file, it must be referenced by some other means than the simple filename. There are several ways to accomplish that. Use ./<filename></code> where <filename></code> would be -</code> for this example. The .</code> is a special character that is interpreted as the current directory. This is usually implied when we just enter a file by it’s name. However, stating it explicitly allows us to circumvent the special case of using -</code> as an argument to cat</code>. $ cat ./- [REDACTED PASSWORD]</code></pre></li> Use the full path. On Linux and other Unix-based systems the root of the file system</a> can be specified with a /</code>. To use this method though we’ll need to know the full path of the -</code> file. To get that we can use the pwd</code> command, which is short for “print working directory”. $ pwd /home/bandit1</code></pre> To complete the full path for -</code> we just need to append /<filename></code>. $ cat /home/bandit1/- [REDACTED PASSWORD]</code></pre></li> We can also use what is called a glob (</code>). The glob can be used to execute commands over multiple files at once. For example using the following command will print all files in the current working directory. $ cat ./ [REDACTED PASSWORD]</code></pre> In this example the only file in our current directory is the password file -</code>. But just like the other examples it circumvents the special -</code> argument to cat</code>. The glob is actually a part of a larger set of filename expansion</a> features available in Bash. They’re quite useful and we may see more of them in future levels. </li> </ol> The main takeway from this level is that there are special characters that may change how commands are interpreted on the command line. Some of them will be built-in to whatever shell you’re using, but some may just be conventions like the -</code> character for STDIN and won’t apply to every program. Here is a breakdown of the special characters used in the Bash shell that you might want to watch out for. https://mywiki.wooledge.org/BashGuide/SpecialCharacters</a> </blockquote> Level 2</a></h3> The password for the next level is stored in a file called spaces in this filename</code> located in the home</code> directory </blockquote> This level is similar to Level 1, except that the file is not a special character. Instead it contains special characters, the space █. The space character is essential for the shell to interpret the input text. $ cat spaces in this filename cat: spaces: No such file or directory cat: in: No such file or directory cat: this: No such file or directory cat: filename: No such file or directory</code></pre> As you can see from above, entering the name as it’s written will cause the cat</code> command to interpret each word in the file as a separate filename. Just as before, there are a few ways to get around this. Escape the space characters. In Bash, the backslash \</code> is used as an escape character</a>. When the \</code> is used, the following character is interpreted literally. This allows the space characters of the filename to be “escaped”. $ cat spaces\ in\ this\ filename [REDACTED PASSWORD]</code></pre></li> Instead of escaping the spaces individually, the filename can also be surrounded by single quotes</a>. Every character between two single quotes is interpreted literally. $ cat 'spaces in this filename' [REDACTED PASSWORD]</code></pre></li> Similarly, double quotes</a> can also be used to interpret the surrounded characters literally. However, there are some exceptions, and double quotes allow some special characters to be interpreted. But the space character is not one those, so it is functionally the same as the above example in this case. $ cat "spaces in this filename" [REDACTED PASSWORD]</code></pre></li> </ol> Recognize that it’s sometimes necessary to escape characters within filenames and other arguments. Most Linux users will avoid naming files with any special characters, but sometimes you’ll still run into them. This is especially true with files created on Windows where spaces inside file and directory names are much more common. </blockquote> Level 3</a></h3> The password for the next level is stored in a hidden file in the inhere</code> directory. </blockquote> $ ls ./inhere</code></pre> According to the ls</code> command, there don’t appear to be any files in the inhere</code> directory. That’s because ls</code> doesn’t display hidden files by default. To show hidden files with ls</code>, it’s necessary to use the --all</code> or -a</code> flag. $ ls -a ./inhere . .. ...Hiding-From-You</code></pre> With the --all</code> flag enabled, ls</code> now shows all the files in the inhere</code> directory. Including the hidden files. In Linux and other Unix-based systems, a leading dot .</code> in a filename is used to indicate a hidden file. As such, you may here them referred to as dotfiles. Now that we know the name of the hidden file, cat</code> can be used to print the contents just as we’ve seen before. $ cat inhere/...Hiding-From-You [REDACTED PASSWORD]</code></pre> The term “dotfile” is also frequently used to refer to a user’s personal configuration files. This is because many configuration files follow the leading dot .</code> convention, so they don’t clutter up directory listings. </blockquote> Some systems will have aliases for the ls</code> command as well, with various flags enabled. Here a few common ones. ll</code> for ls -AlhF</code> to list all files in a human-readable, long format</li> la</code> for ls -A</code> to list all files excluding .</code> and ..</code></li> l</code> for ls -CF</code> to list files in a column format</li> lsd</code> for ls --group-directories-first</code></li> </ul> See this DigitalOcean article</a> to learn more about common aliases and how to configure your own. </blockquote> Level 4</a></h3> The password for the next level is stored in the only human-readable file in the inhere</code> directory. Tip: if your terminal is messed up, try the reset</code> command. </blockquote> If you haven’t done so already, now would be a good time to read through the manual for each of the commands that were already mentioned in Level 0</a>. If you’ve read through the description for each, you should have a pretty good idea of which command you’ll need to solve this one. This level is asking us to identify which files in inhere</code> are human readable. The file</code> command can get the information we need. From the file</code> manual page we know that we can expect a response of text</code> for any files that only contain typical ASCII characters</a>. The type printed will usually contain one of the words `text` (the file contains only printing characters and a few common control characters and is probably safe to read on an ASCII terminal), `executable` (the file contains the result of compiling a program in a form understandable to some UNIX kernel or another), or `data` meaning anything else (data is usually “binary” or non-printable).</code></pre> One option is to execute file</code> on each file in inhere</code> one-by-one like so. $ file inhere/-file00 inhere/-file00: data</code></pre> A better way is to use the glob </code> that we’ve seen previously. This allows us to run the file command on all the files at once. $ file ./inhere/ ./inhere/-file00: data ./inhere/-file01: data ./inhere/-file02: data ./inhere/-file03: data ./inhere/-file04: data ./inhere/-file05: data ./inhere/-file06: data ./inhere/-file07: ASCII text ./inhere/-file08: data ./inhere/-file09: data</code></pre> From here it’s obvious that we want the file with the text data at ./inhere/-file07</code>. $ cat ./inhere/-file07 [REDACTED PASSWORD]</code></pre> Always keep an eye out for opportunities to use globbing. Especially if you’re running commands over a bunch of files. </blockquote> Level 5</a></h3> The password for the next level is stored in a file somewhere under the inhere</code> directory and has all of the following properties: human-readable</li> 1033 bytes in size</li> not executable</li> </ul> </blockquote> This level requires a precise approach to locate the correct file. While it’s technically possible to solve with just the ls</code> and file</code> commands. It would require some tedious manual searching to find the files that match each of the criteria. Luckily the find</code> command is capable of locating files with all the above criteria. You just need to know the right flags. The find</code> command is essential to efficiently locating files on Linux systems. It has several flags that can be used to refine its search. Most importantly for this level are -readable</code>, -size</code> and -executable</code>. $ find -readable -size 1033c -not -executable ./inhere/maybehere07/.file2</code></pre> Note -size</code> and -not</code> flags. The c</code> suffix for the -size</code> argument is used to indicate a size in bytes. The other available suffixes are all available in the find man page</a>. Additionally, the -not</code> flag negates the next expression, thus locating any files that aren’t executable in this example. In this case the content and size of the file are sufficient to uniquely identify the file and the -not -executable</code> isn’t strictly necessary. $ find -readable -size 1033c ./inhere/maybehere07/.file2</code></pre></blockquote> Once again, cat</code> the file to get the password. $ cat ./inhere/maybehere07/.file2 [REDACTED PASSWORD]</code></pre>Level 6</a></h3> The password for the next level is stored somewhere on the server and has all of the following properties: owned by user bandit7</li> owned by group bandit6</li> 33 bytes in size</li> </ul> </blockquote> This level is very similar to Level 5</a> with a couple minor differences. First, the file is “stored somewhere on the server” instead of in the inhere</code> directory. That just means we’ll need to run the find</code> command from the root of the file system to ensure the file isn’t missed. Secondly, the file is specified by two new parameters. The user and group</a> that own the file. Searching the find</code> manpage you can find the two flags -user</code> and -group</code> to filter for files owned by the bandit7</code> user and the bandit6</code> group as specified by the prompt. The final parameter is for a -size</code> of 33 bytes which we already saw in level 5. Here’s an example of the output from find</code> with all the required arguments. $ find / -user bandit7 -group bandit6 -size 33c find: ‘/drifter/drifter14_src/axTLS’: Permission denied find: ‘/root’: Permission denied find: ‘/snap’: Permission denied find: ‘/tmp’: Permission denied find: ‘/proc/tty/driver’: Permission denied find: ‘/proc/250118/task/250118/fd/6’: No such file or directory find: ‘/proc/250118/task/250118/fdinfo/6’: No such file or directory find: ‘/proc/250118/fd/5’: No such file or directory ... [TRUNCATED OUTPUT]</code></pre> Unfortunately searching with find</code> from /</code> has a side effect. Any files or directories that the current user is not allowed to read will print an error to the terminal. This makes it pretty difficult to parse the output for any resulting files that match our search. To avoid this flood of errors, a common solution is to redirect the standard error stream to /dev/null</code></a> This is actually just a file that discards anything written to it. To redirect a data stream in Bash we must specify its file descriptor</a>, which is an integer. The file descriptor is followed by a greater than sign ></code> which indacates that the stream should be redirected to a target file. Here is the same command as above with all errors redirect to /dev/null</code>. $ find / -user bandit7 -group bandit6 -size 33c 2>/dev/null /var/lib/dpkg/info/bandit7.password</code></pre> As you can see, the output is considerably easier to understand. Read the file at /var/lib/dpkg/info/bandit7.password</code> to get the next password. Level 7</a></h3> The password for the next level is stored in the file data.txt</code> next to the word “millionth”. </blockquote> Useful commands 2</a></h4> This is the first level that OverTheWire introduces some new recommended commands since level 0</a>. Command</th> Description</th></tr></thead> man</a></td> access the system reference manuals</td></tr> grep</a></td> print lines that match patterns</td></tr> sort</a></td> sort lines in text files</td></tr> uniq</a></td> remove duplicate lines from a file</td></tr> strings</a></td> print readable strings from arbitrary files (even binary)</td></tr> base64</a></td> encode data into Base64</a></td></tr> tr</a></td> translate and replace characters</td></tr> tar</a></td> a utility for archive files</td></tr> gzip</a></td> a utility for compressing files</td></tr> bzip2</a></td> a utility for compressing files</td></tr> xxd</a></td> a tool for creating a hex dump of a file</td></tr> </tbody></table> Once again, I highly recommend at least reading through the introduction for each of these commands and checking out the examples at cheat.sh</a>. If you’ve followed the above advice, there should really only be one contender to solve this level. The grep</code> command. NAME grep - print lines that match patterns SYNOPSIS grep [OPTION...] PATTERNS [FILE...] grep [OPTION...] -e PATTERNS ... [FILE...] grep [OPTION...] -f PATTERN_FILE ... [FILE...] DESCRIPTION grep searches for PATTERNS in each FILE. PATTERNS is one or more patterns separated by newline characters, and grep prints each line that matches a pattern. Typically PATTERNS should be quoted when grep is used in a shell command. </code></pre> According to the syntax description we should be able to search for patterns in a file with the following syntax. grep <PATTERN> <FILE></code></pre> Swapping in the values mentioned in the prompt will return the line we’re looking for. $ grep "millionth" data.txt millionth [REDACTED PASSWORD]</code></pre>Regex</a></h4> Grep and more generally regular expressions</a> (regex) are extremely useful. You’ll find many applications have integrated support for text search via regex. In particular text editors, word processors, and programming IDEs. To explore regex more I highly recommend reading through the Regex Quick Start Guide</a> from regular-expression.info</a> to get a feel for what’s possible with regex and then follow that up with some experimentation on regex101.com</a>. This is a tool that visualizes regex matches. Drop any text you want into it and try out all kinds of search patterns. Try to match words, letters, various combinations of upper and lowercase letters, punctuation, etc. Seeing regex in action and observing precisely what matches with different patterns will give you a much better intuition for what’s possible than anything I could write here. Regex can get very complicated very quickly, so regex101 is also a great tool for debugging your regex. Definitely give it a bookmark, it’ll be a life saver. Trust me. </blockquote> Level 8</a></h3> The password for the next level is stored in the file data.txt</code> and is the only line of text that occurs only once </blockquote> This level is the first that seriously benefits from chaining two commands together. In Bash this is done with the pipe |</code> character. The pipe, when placed after a command will pass all of the output (stdout) into the input (stdin) of the command that follows it. For example, we can combine the ls</code> and grep</code> commands to list only those files that contain “bash” in the name. $ ls -a | grep bash .bash_logout .bashrc</code></pre> Remember that the -a</code> flag is necessary to list hidden or dot files. Read through the Piping and Redirection</a> article provided under the helpful reading material section to learn more about piping. Reviewing the recommended commands, one should stick out. NAME uniq - report or omit repeated lines SYNOPSIS uniq [OPTION]... [INPUT [OUTPUT]] DESCRIPTION Filter adjacent matching lines from INPUT (or standard input), writing to OUTPUT (or standard output). With no options, matching lines are merged to the first occurrence.</code></pre> The uniq</code> command is able to filter matching or repeated lines. Since we’re looking for a unique line in a file, this will be helpful. However, there is one caveat when using uniq</code> that you must be aware of. The uniq</code> command filters adjacent matching lines. This means that any matching lines that aren’t directly adjacent, won’t be filtered. So the first step must be to organize the file such that matching lines are adjacent. In other words the file should be sorted. The sort</code> program is designed precisely for this use case. For example, here’s the first 20 lines of data.txt</code> when sorted. $ sort data.txt | head -n20 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz</code></pre> As mentioned before, the pipe |</code> is useful here to send the output of the sort</code> command to uniq</code>. $ sort data.txt | uniq | head -n20 0BKVRLEJQcpNx8wnSPxDLFnFKlQafKK6 0eJPctF8gK96ykGBBaKydhJgxSpTlJtz 0kJ7XHD4gVtNSZIpqyP1V45sfz9OBLFo 0lPOvKhpHZebxji0gdjtGCd5GWiZnNBj 0REUhKk0yMqQOwei6NK9ZqIpE5dVlWWM 1jfUH1m4XCjr7eWAeleGdaNSxFXRtX0l 1VKPEkd0bCtIRwMFVQfY7InulwOFyDsn 2u8fvAzvnaFlvQG3iPt4Wc1TFhPcGxhH 35l6mr3f6TvlJyDwU6aUgJX07cLhr6t9 3FIgajXBiaQAiTMVGo1gxRDSiACNyvvJ 3mNA2le0gfURQKNHVIhGkMNLqLwjyyLN 4CKMh1JI91bUIZZPXDqGanal4xvAg0JM 4P8FsHcdr7d5WKnPtAaXY5SslKICd2gL 5EmwMKZHwF6Lwq5jHUaDlfFJBeHbcX0b 5hYz0028e1Q2TrtPVz5GZbpMzZNjebhh 5I2jWpqjtVp576xXI2TLh1UCyXJtGQ78 6Boy6esAjnIxCYn8uI6KZ7VD7zysDM8i 7cP8ssLElERHXqOJc9T84bxsmJBjNXk2 7qHmEo1FEbzthgyNpKc38YofXjYKZv18 8FCtUQlFXsJnNeyiDY5KfE3vRy6sZFEJ</code></pre> Well that’s strange. Why has uniq</code> returned all those lines? If you read the description for uniq</code> carefully, then one line explains this. With no options, matching lines are merged to the first occurrence.</code></pre> So essentially what we have here is a file with each unique line of the file where adjacent duplicates have been compressed into a single line. However, we want to list only the unique lines from the input. For that, the -u</code> flag will meet our needs. The -u</code> flag tells sort to only print unique lines. In other words, only lines without any duplicates in the input. So finally, we have a solution. $ sort data.txt | uniq -u [REDACTED PASSWORD]</code></pre>Level 9</a></h3> The password for the next level is stored in the file data.txt</code> in one of the few human-readable strings, preceded by several ‘=’ characters. </blockquote> Once again we’re searching a file, so exploring our options with grep</code> may be a good idea. Trying a basic grep</code> for several =</code> characters doesn’t seem to work. $ grep '=== \w' data.txt grep: data.txt: binary file matches</code></pre> The \w</code> is a shortcut for any word characters which equivalent to [a-zA-Z0-9_]</code>. We can see here, that grep found some matches, but data.txt</code> was interpreted as a binary file. We can force grep to process the file as if it were text with the -a</code> flag. $ grep -a '=== \w' data.txt D] h#!QJsVzl7POl%Y]Ha^UvToD|@T^N8g}b}? Q#gm1x}========== theѦ+idW^)F1>)٘SK3PZt&xs肉WB/2ÜB Ź/Bjɢ<7<u/d| -n #iu= 7֣n)Uջش5bBKK}x>}:4Rl_7gHD:274CFy 6!&zB$l_GphqI.02H$Twm⧫o3mt0p~L3JprD========== passwordi L ~ˏ<@Ȅh$%Q5Dk |3 ~Tf;o9sP#t+Pe΢쵟 OqDf.8Czmnf&vl:FXKbM CIBi>Y Еk $nXT=~}4a2?TO"'&J~fDV3========== isd5z(#&s!10&poq nR F z|!(if+A64+'FTb5A} éT:kAU2Qcɐ%#g+;YA_ekrX53|f8+e~&Oiu?VhM}^Qp^G==6!sT: "uVa-t\fg ]󈍅(.ۍg:7nnp CD`voSQ-<]`@#H UumBiAj堵!O&D9========== [REDACTED PASSWORD] </code></pre> On the last line of the above output, you’ll find the password to the next level. It’s possible for grep</code> to output the precise matching text instead of each entire line. The -o</code> flag is needed to do this. It tells grep to only output the matched pattern. $ grep -a -o '=== \w' data.txt === the === passwordi === is === [REDACTED PASSWORD]</code></pre> This gives a much clearer picture of the password without all the surrounding binary data. </blockquote> Level 10</a></h3> The password for the next level is stored in the file data.txt</code>, which contains base64 encoded data </blockquote> This one is pretty straight forward. The prompt gives it away by mentioning that the data is Base64 encoded. Check the manual for the base64</code> command and you’ll find one of the first flags is -d</code> for --decode</code>. $ base64 -d data.txt The password is [REDACTED PASSWORD]</code></pre> Be sure you understand what encoding is in this context. Base64</a> is just one scheme of many to convert binary data into printable characters i.e. alphanumeric characters with the addition of the equal sign =</code>. In fact, that equal sign =</code> is used for padding the end of encoded text, so it’s often a dead giveaway that some text was Base64 encoded. For example, the word “password” when Base64 encoded is cGFzc3dvcmQ=</code>. Base64 encoded text is extremely common on the web and you’re likely to come across it at some point, so it may behoove you to read up on it. FreeCodeCamp has an excellent article</a> that gives a good overview of how Base64 works and what it’s used for. You’re less likely see other forms of binary to text encoding, but feel free to read more</a>. </blockquote> Level 11</a></h3> The password for the next level is stored in the file data.txt, where all lowercase (a-z) and uppercase (A-Z) letters have been rotated by 13 positions </blockquote> This challenge is describing what’s commonly known as a shift cipher or Caesar cipher</a>. It’s not actually used in modern times for any meaningful attempts at securing messages, but it’s somewhat popular in CTFs and wargames. To keep within the spirit of the wargame, let’s first go over how you might solve this challenge in the terminal. One of the recommended commands is tr</code> which can “[t]ranslate, squeeze, and/or delete characters” according to the description. Here’s a few different ways to go about it. # Rotate the alphabet by 13 letters where both input and output are explicit cat data.txt | tr "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" "nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM" # Similar to above except the input is defined by a regular expression cat data.txt | tr "a-zA-Z" "nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM" # Similar to above except both the input and output are defined by a regular expression # Note: the odd arrangement for the output is the necessary since Regex doesn't allow # the letter ranges to wrap around cat data.txt | tr "a-zA-Z" "n-za-mN-ZA-M"</code></pre> While the tr</code> command is cool and all, there’s an even cooler tool you should be using when investigating any challenge related to cryptography. And that’s CyberChef</a>. CyberChef has a huge number of useful features for transforming data and supports hundreds of data formats and encoding schemes. Check out the CyberChef ROT13 cipher solver</a>. </blockquote> Level 12</a></h3> The password for the next level is stored in the file data.txt</code>, which is a hexdump of a file that has been repeatedly compressed. For this level it may be useful to create a directory under /tmp</code> in which you can work. Use mkdir</code> with a hard to guess directory name. Or better, use the command mktemp -d</code>. Then copy the datafile using cp</code>, and rename it using mv</code> (read the manpages!) </blockquote> This challenge is quite tedious. As the prompt mentions, it’s a good idea to create a temp directory to work with all the files. For example mkdir /tmp/my-super-secret-directory</code> followed by mv ~/data.txt /tmp/my-super-secret-directory</code>. Now we’re ready to begin. The first step is to recognize the format of the data.txt</code>. Taking a look at the first few lines shows that this file isn’t just a text file. It’s a hexdump. Read the first few lines with head -n5 data.txt</code>. 00000000: 1f8b 0808 dfcd eb66 0203 6461 7461 322e .......f..data2. 00000010: 6269 6e00 013e 02c1 fd42 5a68 3931 4159 bin..>...BZh91AY 00000020: 2653 59ca 83b2 c100 0017 7fff dff3 f4a7 &SY............. 00000030: fc9f fefe f2f3 cffe f5ff ffdd bf7e 5bfe .............~[. 00000040: faff dfbe 97aa 6fff f0de edf7 b001 3b56 ......o.......;V</code></pre> Don’t panic! You don’t need to be able to read this stuff right away. Just recognizing it as a hexdump is enough. Fortunately, one of the recommended commands is made specifically to handle hexdumps. The xxd</a> command. Using xxd</code> with the -r</code> flag can reverse the hexdump into a binary file. xxd -r data.txt > data</code></pre> This output data</code> file is now in it’s original format and can be examined with file data</code> to determine it’s type. data: gzip compressed data, was "data2.bin", last modified: Thu Sep 19 07:08:15 2024, max compression, from Unix, original size modulo 2^32 574</code></pre> The result from file</code> identifies it as “gzip compressed data”. To decompress the archive, use the gunzip</code> command. Be aware, that the archive utilities like gunzip</code> may require particular file extensions when decompressing files. For example, .gzip</code> or .gz</code>. Otherwise you may get an error like this. gzip: data: unknown suffix -- ignored</code> </blockquote> To complete this challenge, you must repeat this process of decompressing or extracting data into a new format, then verifying the new format with file</code> eight times to reach the original flag file content. Below is a script describing each step of the decompression. You could run the script directly on the Bandit host to get the flag, but I encourage you to walk through each decompression step manually and observe the different flags being used for each command. #!/bin/sh # extract.sh xxd -r data.txt > f1.gz; # extract first gzip archive from hexdump gunzip -c f1.gz > f2.bz2; # extract bzip2 archive from f1.gz bunzip2 -c f2.bz2 > f3.gz; # extract gzip archive from f2.bz2 gunzip -c f3.gz > f4.tar; # extract tar archive from f3.gz tar -xOf f4.tar > f5.tar; # extract tar archive from f4.tar tar -xOf f5.tar > f6.bz2; # extract bzip2 archive from f5.tar bunzip2 -c f6.bz2 > f7.tar; # extract tar archive from f6.bz2 tar -xOf f7.tar > f8.gz; # extract gzip archive from f7.tar gunzip -c f8.gz > flag; # extract plaintext flag file from f8.gz cat flag;</code></pre>Level 13</a></h3> The password for the next level is stored in /etc/bandit_pass/bandit14</code> and can only be read by user bandit14</code>. For this level, you don’t get the next password, but you get a private SSH key that can be used to log into the next level. Note: localhost</code> is a hostname that refers to the machine you are working on </blockquote> Useful commands 3</a></h4> Once again, OverTheWire has provided some new recommended commands to investigate. Command</th> Description</th></tr></thead> ssh</a></td> a program for logging into or executing commands on remote machines</td></tr> telnet</a></td> communicate with another host using the TELNET protocol</td></tr> nc</a></td> the swiss army knife for communicating over the network using TCP, UDP, or Unix-domain sockets</td></tr> openssl</a></td> a program for using various cryptography functions of the OpenSSL crypto library from the shell</td></tr> s_client</a></td> a program implementing a generic SSL/TLS client</td></tr> nmap</a></td> a network scanner for network exploration and security auditing</td></tr> </tbody></table> Each program is worth exploring, but for this challenge we’ll only need ssh</code>. However, it won’t be used quite the same as before. This time an SSH private key is required to login to the next level. After logging in to bandit13</code>, you should find the private SSH key mentioned in the prompt at /home/bandit13/sshkey.private</code>. Copy that file to your primary host. You can simply copy paste the text if you wish, or use something like scp</a>. Watch out! The ssh</code> command requires private key files to have appropriate permissions. If they aren’t correct you may receive an error message like this. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'sshkey.private' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "sshkey.private": bad permissions</code></pre> A brief reminder of the octal permissions. Octal Number</th> Permission Type</th> Symbols</th></tr></thead> 0</td> No permissions</td> —</td></tr> 1</td> Execute</td> –x</td></tr> 2</td> Write</td> -w-</td></tr> 3</td> Write + Execute</td> -wx</td></tr> 4</td> Read</td> r–</td></tr> 5</td> Read + Execute</td> r-x</td></tr> 6</td> Read + Write</td> rw-</td></tr> 7</td> Read + Write + Execute</td> rwx</td></tr> </tbody></table> As the error mentions, the permissions 0644</code> are too open. That’s because private key files should only be readable and/or writeable by the user they belong to. Usually that means either 600</code> or 400</code>, though 400</code> is a bit strict and won’t allow the file to be edited. Setting the permissions to 600</code> gives the key file read and write access for the user, and no permissions for either the group or others. chmod 600 sshkey.private</code></pre> Now we’re ready to connect to bandit14</code>. </blockquote> To use a key file with ssh</code>, the -i</code> flag can be used. E.g. ssh user@host -i private_key</code></pre> To connect to bandi14</code> use the following command. ssh bandit14@bandit.labs.overthewire.org -p 2220 -i sshkey.private</code></pre> SSH is the most common protocol used for remotely administrating Linux and Unix-like systems, and using a key file as we’ve done here is by far the most common way it’s used. It’s not strictly necessary, but I highly recommend reading up on the fundamentals of public-key cryptography</a>. It’s how SSH guarantees1</a> it’s security. In the solution above, we just used the -i</code> flag to specify the private key file. However, anyone using ssh</code> on a regular basis will rightly tell you to consider configuring ssh on your system for a much simpler workflow. If you’re connecting to many hosts via ssh, it is much more convenient to configure the ssh-agent</a> to handle your ssh keys automatically so you don’t need to specifiy the key file with the -i</code> flag each time. You may also want to combine this with host-specific configurations. This can be done with a config</code> file usually at ~/.ssh/config</code>. Check out the ssh_config manual</a> for more details. </blockquote> Level 14</a></h3> The password for the next level can be retrieved by submitting the password of the current level to port 30000 on localhost. </blockquote> If you aren’t familiar with IP addresses or ports, I highly encourage you to read the recommended reading material on the Bandit 14 page</a>. This time we need to connect to a particular port, but we won’t be using the SSH protocol. Instead we need to send the current password as unencrypted text to port 30000 on localhost. The nc</code> (netcat) utility can do just that. Netcat establishes a connection with the following syntax: nc <destination> <port></code></pre> The destination</code> can be any domain as long as it resolves to an IP address, or it can take an IP address directly.</li> The port</code> corresponds to the TCP/UDP port.</li> </ul> Now, connect with the parameters given in the prompt. netcat localhost 30000</code></pre> This will establish the connection, but won’t provide a new terminal prompt. That’s because the program you’ve connected to is now awaiting input. Provide the level 14 password and press Enter</code>, and the level 15 password will be returned. Level 15</a></h3> The password for the next level can be retrieved by submitting the password of the current level to port 30001 on localhost using SSL/TLS encryption. Helpful note: Getting “DONE”, “RENEGOTIATING” or “KEYUPDATE”? Read the “CONNECTED COMMANDS” section in the manpage. </blockquote> Now, we’ve got another challenge asking us to connect to a port on localhost and submit the password, but this time, the password must be encrypted using SSL/TLS. One of the recommended commands is s_client</code> which is a generic SSL/TLS2</a> client. We’ll need to use a couple flags, -host</code>, and -port</code>. openssl s_client -host localhost -port 30001</code></pre> It’s actually possible to elide the -host</code> flag since s_client</code> connects to localhost</code> by default. openssl s_client -port 30001</code></pre> By default there, will be a fair amount of output describing the security parameters for the connection such as the certificate and handshake details. Once the connection is established there should be a line at the bottom read R BLOCK</code>. At this point the terminal is awaiting input. Provide the current password to receive the password for the next level. --- read R BLOCK [REDACTED BANDIT 15 PASSWORD] Correct! [REDACTED BANDIT 16 PASSWORD] closed</code></pre>Level 16</a></h3> The credentials for the next level can be retrieved by submitting the password of the current level to a port on localhost in the range 31000 to 32000. First find out which of these ports have a server listening on them. Then find out which of those speak SSL/TLS and which don’t. There is only 1 server that will give the next credentials, the others will simply send back to you whatever you send to it. Helpful note: Getting “DONE”, “RENEGOTIATING” or “KEYUPDATE”? Read the “CONNECTED COMMANDS” section in the manpage. </blockquote> This challenge is almost identical to Level 15</a>. However, this time we are not given the appropriate port. Instead, we’re only given a range of suspect ports. To identify the services running on these TCP/UDP ports, we can use the nmap</code> program. Nmap</a> is a network scanning tool which is often used to automatically enumerate devices and ports in a network. In our case, we’re only interested in ports on the Bandit host, or in other words the localhost</a>. To scan all the ports in the given range on localhost</code> we’ll run an nmap command</a>. nmap localhost -p31000-32000</code></pre> This should return the following: Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-05-29 20:28 UTC Nmap scan report for localhost (127.0.0.1) Host is up (0.00017s latency). Not shown: 996 closed tcp ports (conn-refused) PORT STATE SERVICE 31046/tcp open unknown 31518/tcp open unknown 31691/tcp open unknown 31790/tcp open unknown 31960/tcp open unknown Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds</code></pre> This scan results in just a few open ports. Given such a short list, one option is to attempt communication on each port to see which one speaks SSL/TLS. However, if there were many more open ports, it would make more sense to automate that detection with nmap</code>. Luckily this is possible with just one flag -sV</code> which can be found under the SERVICE/VERSION DETECTION</code> section in the manpage</a>. nmap localhost -p31000-32000</code></pre> This version of the command will take a bit longer since nmap</code> must analyze the traffic on each open port to determine what service may be running. The output should look something like this. Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-05-29 21:11 UTC Nmap scan report for localhost (127.0.0.1) Host is up (0.00018s latency). Not shown: 996 closed tcp ports (conn-refused) PORT STATE SERVICE VERSION 31046/tcp open echo 31518/tcp open ssl/echo 31691/tcp open echo 31790/tcp open ssl/unknown 31960/tcp open echo 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port31790-TCP:V=7.94SVN%T=SSL%I=7%D=5/29%Time=6838CD8E%P=x86_64-pc-linu SF:x-gnu%r(GenericLines,32,"Wrong!\x20Please\x20enter\x20the\x20correct\x2 SF:0current\x20password\.\n")%r(GetRequest,32,"Wrong!\x20Please\x20enter\x SF:20the\x20correct\x20current\x20password\.\n")%r(HTTPOptions,32,"Wrong!\ SF:x20Please\x20enter\x20the\x20correct\x20current\x20password\.\n")%r(RTS SF:PRequest,32,"Wrong!\x20Please\x20enter\x20the\x20correct\x20current\x20 SF:password\.\n")%r(Help,32,"Wrong!\x20Please\x20enter\x20the\x20correct\x SF:20current\x20password\.\n")%r(FourOhFourRequest,32,"Wrong!\x20Please\x2 SF:0enter\x20the\x20correct\x20current\x20password\.\n")%r(LPDString,32,"W SF:rong!\x20Please\x20enter\x20the\x20correct\x20current\x20password\.\n") SF:%r(SIPOptions,32,"Wrong!\x20Please\x20enter\x20the\x20correct\x20curren SF:t\x20password\.\n"); Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 155.35 seconds</code></pre> Here we have the same open ports as before, but this time, with some additional version information. You’ll notice that SSL/TLS responses were only detected on ports 31518</code> with ssl/echo</code> and 31790</code> with ssl/unknown</code>. The ssl/echo</code> is just a simple echo service like the others, except that it is served via SSL/TLS, which only leaves the remaining ssl/unknown</code> service. You can actually see the initial text sent and received by nmap</code> when analyzing port 31790</code>. It seems to include several failed password attempts. Just as in Level 15</a>, we can use the following OpenSSL command to start an SSL/TLS connection with our target port. After the initial connection is established, the program awaits some user input which requires the password to the current level. Once the password is entered, it’s possible that the service does not immediately reply with the credentials for the next level. As mentioned in the prompt, if there is a response including “DONE”, “RENEGOTIATING”, or “KEYUPDATE” then you may need to check the “CONNECTED COMMANDS” section of the openssl-s_client</a> manpage. CONNECTED COMMANDS (BASIC) If a connection is established with an SSL/TLS server then any data received from the server is displayed and any key presses will be sent to the server. If end of file is reached then the connection will be closed down. When used interactively (which means neither -quiet nor -ign_eof have been given), and neither of -adv or -nocommands are given then "Basic" command mode is entered. In this mode certain commands are recognized which perform special operations. These commands are a letter which must appear at the start of a line. All further data after the initial letter on the line is ignored. The commands are listed below. Q End the current SSL connection and exit. R Renegotiate the SSL session (TLSv1.2 and below only). C Attempt to reconnect to the server using a resumption handshake. k Send a key update message to the server (TLSv1.3 only) K Send a key update message to the server and request one back (TLSv1.3 only)</code></pre> In my case, I received a “KEYUPDATE” response because the password I used begins with a “k”. --- snip --- read R BLOCK [REDACTED LEVEL 15 PASSWORD] KEYUPDATE</code></pre> Since I didn’t provide any of the -quiet</code>, -ign_eof</code>, -adv</code>, or -nocommands</code> flags, the connection entered the “Basic” command mode which uses the first character in the next line of input to determine which command to execute. To prevent this “Basic” mode from clobbering our input we need use one of these flags. For example. openssl s_client -connect localhost:31790 -nocommands</code></pre> Which should return the following. --- snip --- read R BLOCK [REDACTED LEVEL 16 PASSWORD] Correct! -----BEGIN RSA PRIVATE KEY----- [REDACTED RSA KEY] -----END RSA PRIVATE KEY----- closed</code></pre> This time, the service accepts the password and replies with an RSA key to access the next level and closes the connection. Level 17</a></h3> There are 2 files in the homedirectory: passwords.old</code> and passwords.new</code>. The password for the next level is in passwords.new</code> and is the only line that has been changed between passwords.old</code> and passwords.new</code> NOTE: if you have solved this level and see ‘Byebye!’ when trying to log into bandit18, this is related to the next level, bandit19 </blockquote> This level wants us to find any differences between the passwords.old</code> and passwords.new</code> files. One of the recommended commands is diff</a> which has the sole purpose of comparing files line by line and displaying the differences. Let’s get a diff of our two password files. $ diff passwords.old passwords.new</code></pre>42c42 < C6XNBdYOkgt5ARXESMKWWOUwBeaIQZ0Y --- > [REDACTED LEVEL 18 PASSWORD]</code></pre> The first line indicates which lines were changed. In this case a change has been identified in line 42 of both files. The lines above the ---</code> separator are the changes made in the file that was input as the first argument (passwords.old</code>), while the lines under the ---</code> correspond to the second argument (password.new</code>). We can see the password for level 18 highlighted in green. Level 18</a></h3> The password for the next level is stored in a file readme</code> in the homedirectory. Unfortunately, someone has modified .bashrc</code> to log you out when you log in with SSH. </blockquote> While ssh</code> is primarily used for starting a user shell on a remote host, commands can actually be executed directly without starting a new shell. The SYNOPSIS of the ssh manpage</a> shows the necessary syntax. SYNOPSIS ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]] ssh [-Q query_option]</code></pre> After the required destination</code> parameter you can see the optional [command [argument ...]]</code> parameter. Any commands provided here will be executed on the remote host. So the command to output the password in the remote host’s readme</code> file should look like this. $ ssh bandit18@bandit.labs.overthewire.org cat readme _ _ _ _ | | _ _ | (_) |_ | '_ \ / _` | '_ \ / _` | | __| | |_) | (_| | | | | (_| | | |_ |_./ \,_|_| |_|\__,_|_|\__| This is an OverTheWire game server. More information on http://www.overthewire.org/wargames bandit18@bandit.labs.overthewire.org's password: [REDACTED LEVEL 18 PASSWORD]</code></pre> This command should be executed from your own system, not from the system hosting Bandit i.e. while logged into one of the previous levels. I’ve configured my SSH client to automatically use port 2220</code> as required for the Bandit wargame which is why I haven’t explicitly provided the port in this example. To do the same, add the following line to your ~/.ssh/config</code> file or provide the port number via the -p</code> flag. Host bandit.labs.overthewire.org</code></pre></blockquote> > port 2220</code></pre> </code></pre></blockquote> Level 19</a></h3> To gain access to the next level, you should use the setuid</code> binary in the homedirectory. Execute it without arguments to find out how to use it. The password for this level can be found in the usual place (/etc/bandit_pass</code>), after you have used the setuid</code> binary. </blockquote> First let’s define a few terms. Term</th> Descriptions</th></tr></thead> Real User ID (RUID)</td> The ID of the user which started a process</td></tr> Effective User ID (EUID)</td> The ID of the user which defines the privileges of a running process.</td></tr> suid permission bit</a></td> A special file permission bit besides the standard read (r), write (w), and execute (x) that allows a file to be executed as the owner of that file</td></tr> </tbody></table> For the bandit20-do</code> permissions the suid</code> bit can be seen as the s</code> in the execute position of the user permissions. $ ls -l total 16 -rwsr-x--- 1 bandit20 bandit19 14884 Apr 10 14:23 bandit20-do</code></pre> The special (suid) permission is set and the owner of the file is bandit20</code>, thus allowing the binary access to resources available to the user bandit20</code>. By default, the effective user ID matches the real user ID. However, If you execute the provided binary without any arguments some usage information will be returned. $ ./bandit20-do Run a command as another user. Example: ./bandit20-do id</code></pre> Note that the id</a> command will show the real and effective user and group IDs for the current user’s shell unless provided with an argument. Now, let’s run that example. $ ./bandit20-do id uid=11019(bandit19) gid=11019(bandit19) euid=11020(bandit20) groups=11019(bandit19)</code></pre> See how it differs from running the plain id</code> command run as the bandit19</code> user. $ id uid=11019(bandit19) gid=11019(bandit19) groups=11019(bandit19)</code></pre> An additional item is returned from the bandit20-do</code> invocation, the effective user ID euid=11020(bandit20)</code>. This indicates that the commands run via bandit20-d0</code> should be able to access files available to the bandit20</code> user. Which includes the password file. As long as we know its location which was provided as /etc/bandit_pass/bandit20</code> we can simply output the file. So, solving this challenge is actually quite simple. Execute a cat</code> command with the password file as an argument via the bandit20-do</code> binary like so: $ ./bandit20-do cat /etc/bandit_pass/bandit20 [REDACTED BANDIT 20 PASSWORD]</code></pre>Level 20</a></h3> There is a setuid binary in the homedirectory that does the following: it makes a connection to localhost on the port you specify as a commandline argument. It then reads a line of text from the connection and compares it to the password in the previous level (bandit20). If the password is correct, it will transmit the password for the next level (bandit21). NOTE: Try connecting to your own network daemon to see if it works as you think </blockquote> Useful commands 4</a></h4> This challenge recommends some new commands that we haven’t seen so far. Command</th> Description</th></tr></thead> screen</a></td> a terminal multiplexer</td></tr> tmux</a></td> a terminal multiplexer</td></tr> jobs</a></td> display the status of all jobs in the current session</td></tr> bg</a></td> send a running job to the background</td></tr> fg</a></td> bring a backgrounded job to the foreground</td></tr> </tbody></table> These programs introduce some new concepts that are pretty important for anyone working on Linux system whether as a user or an administrator. Let’s briefly go over them. Job control</a></h4> You can read more about it in the Job Control section</a> of the Bash Reference Manual</a>. But, to summarize, job control, is a system for suspending and resuming processes and allowing them to run in the background such that the user can continue executing other commands without waiting for previous commands to complete. To interact with the job control system, we have a few tools including: the jobs</code>, bg</code>, and fg</code> commands as well as the &</code> character, and the Ctrl+Z</kbd> keyboard shortcut which you may see referred to as the suspend character or ^Z</code>. We generally use two methods to run a program in the background. The first is to execute a command with an &</code> at the end of the line. For example $ cat - & [1] 1809443</code></pre> The cat</code> process has been added to the jobs list and is now in the background. $ jobs [1]+ Stopped cat -</code></pre> As you can see when listing the available jobs, the command has been Stopped which indicates that is has been suspended and is no longer running. However, we can bring this process back to the foreground so that we can interact with it again using the fg</code> command. $ fg cat - hello hello</code></pre> Besides starting a command with the &</code>, we can also use the Ctrl+Z</kbd> keyboard shortcut to send an already running process to the background. Let’s send the cat</code> process to the background once again. ^Z [1]+ Stopped cat - $ jobs [1]+ Stopped cat -</code></pre> You can see here we’ve once again stopped the process running cat</code> and returned it to the background. The ^Z</code> indicates the pressing of Ctrl+Z</kbd>. Be aware though, that backgrounding a process in this manner will also stop the process. To let it continue running in that background you must use the bg</code> command. $ bg %1 [1]+ cat - & [1]+ Stopped cat -</code></pre> Here we used what’s known as a job specification or job spec to identify the job with a %</code> followed by the ID of 1 which you may need to do if you have several backgrounded jobs. In this little example, since the cat</code> process is awaiting user input, it’s immediately stopped again after telling it to run in the background. However, a longer running process would continue until the program exits or is awaiting more user input. Terminal multiplexing</a></h4> Both tmux</code> and screen</code> are terminal multiplexers. Which just means they can display multiple terminals within a single window. They allow you to split these windows as needed and can allow grouping terminals, copying and pasting etc. This can all be done from the command line with these tool, which is why they’re useful when working over a remote SSH session. There are also GUI-based alternatives. Terminal emulators like Terminator</a>, Konsole</a>, and even Windows Terminal</a> ship with multiplexing features, but I won’t go into too much detail here. I recommend you try out whichever ones work for your system and see what you like best. Just know that only the terminal-based multiplexers like tmux</code> and screen</code> will enable you to use multiple terminals on a remote system without initiating an additional SSH session. Solution</a></h4> This challenge provides another setuid</code> binary, just how Level 19</a> did. Checking the permissions shows that this binary also has the suid</code> bit set with an owner of bandit21</code>, so it should be able to read the bandit21</code> password file for us in some way. $ ls -l total 16 -rwsr-x--- 1 bandit21 bandit20 15608 Apr 10 14:23 suconnect</code></pre> First off, let’s check the usage information for suconnect</code>. $ ./suconnect Usage: ./suconnect <portnumber> This program will connect to the given port on localhost using TCP. If it receives the correct password from the other side, the next password is transmitted back.</code></pre> For this walkthrough we’ll use the job control method. First, we need to setup a TCP listener on a high port3</a> for the suconnect</code> binary to connect to. The simplest way to do this is with the netcat</code> utility which we’ve used before</a>. Here we run netcat in listening mode and specify port 9898</code>, but importantly we’ve provided the &</code> at the end of the line to send the process to the background. $ nc -l -p 9898 & [1] 744373</code></pre> Running the jobs</code> command will list the active jobs which now includes the netcat</code> command we just launched. As you can see it’s still running since it’s awaiting a connection. $ jobs [1]+ Running nc -l -p 9898 &</code></pre> Next we need to run the suconnect</code> binary and connect to the same port, 9898</code>. We also execute this command as a background job. $ ./suconnect 9898 & [2] 913657</code></pre> The jobs list now contains both of our programs running in the background. $ jobs [1]+ Stopped nc -l -p 9898 [2]- Running ./suconnect 9898 &</code></pre> You can see that the netcat</code> command has been stopped, but we can start it again by bringing it into the foreground with the fg</code> command to interact with it. Note that since the netcat</code> job has the +</code> indicator it will be selected by default, but we can also specify the specific job to bring to the foreground with it’s job number. Once you bring the netcat</code> job to the foreground, the terminal will once again be awaiting input. Provide the level 20 password as the prompt informed us. $ fg %1 nc -l -p 9898 [REDACTED LEVEL 20 PASSWORD] Read: [REDACTED LEVEL 20 PASSWORD] Password matches, sending next password [REDACTED LEVEL 21 Password] [2]+ Done ./suconnect 9898</code></pre> As you can see, suconnect</code> accepted the level 20 password and replied with the password for level 21. We can also see that the job for suconnect</code> completed and exited normally by the Done</code> response in the final line. Level 21</a></h3> A program is running automatically at regular intervals from cron</code>, the time-based job scheduler. Look in /etc/cron.d/</code> for the configuration and see what command is being executed. The prompt also recommends some useful manpages. Cron</a></h4> Manpage</th> Description</th></tr></thead> cron(8)</a></kbd></td> system for scheduling commands</td></tr> crontab(1)</a></kbd></td> manage crontab files for a user</td></tr> crontab(5)</a></kbd></td> crontab file format and syntax</td></tr> </tbody></table> Cron is a system for executing commands at regular intervals. This is a very common task for system administrators. Whether a task involves performing regular backups of data or generate reports automatically. Contab guru</a> is a convenient tool to parse crontabs if you’re unfamiliar with the syntax or want to verify the correctness of your own crontabs. Solution</a></h4> The prompt points us to the configuration files in /etc/cron.d</code>. $ ls -l total 28 -rw-r--r-- 1 root root 123 Apr 10 14:16 clean_tmp -rw-r--r-- 1 root root 120 Apr 10 14:23 cronjob_bandit22 -rw-r--r-- 1 root root 122 Apr 10 14:23 cronjob_bandit23 -rw-r--r-- 1 root root 120 Apr 10 14:23 cronjob_bandit24 -rw-r--r-- 1 root root 201 Apr 8 2024 e2scrub_all -rwx------ 1 root root 52 Apr 10 14:24 otw-tmp-dir -rw-r--r-- 1 root root 396 Jan 9 2024 sysstat</code></pre> Checking the contents of the cronjob_bandit22</code> file reveals a specification for two cron jobs. @reboot bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null</code></pre> The first line runs the cronjob_bandit22.sh</code> script at boot time, and the second line runs the same script every minute. Let’s see what that script does. #!/bin/bash chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv</code></pre> According to this script, the password for bandit22</code> seems to be written to the file /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv</code>. Reading that file will reveal the password. $ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv [REDACTED LEVEL 22 PASSWORD]</code></pre>Level 22</a></h3> A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/</code> for the configuration and see what command is being executed. NOTE: Looking at shell scripts written by other people is a very useful skill. The script for this level is intentionally made easy to read. If you are having problems understanding what it does, try executing it to see the debug information it prints. </blockquote> This level once again involves Cron. You may remember, from Level 21</a> that there were a few other cron files in /etc/cron.d</code>. This time we’re interested in the /etc/cron.d/cronjob_bandit22</code> file. @reboot bandit23 /usr/bin/cronjob_bandit23.sh &> /dev/null * * * * * bandit23 /usr/bin/cronjob_bandit23.sh &> /dev/null</code></pre> Once again this crontab points to a script in /usr/bin</code>. 1#!/bin/bash 2myname=$(whoami) 3mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1) 4 5echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget" 6 7cat /etc/bandit_pass/$myname > /tmp/$mytarget</code></pre> This script is quite similar to the script in Level 21</a> except it’s now using a variable, mytarget</code> to store the target directory. And, instead of using a hardcoded location, the mytarget</code> is built with a series of commands. However, be aware that the $myname</code> variable is being populated when the script runs as the bandit23</code> user. So you can’t use the results of whoami</code> in the current shell for the $myname</code> variable since that resolves to bandit22</code>. Instead, the $myname</code> variable should be bandit23</code>. Replace it in the command line, like so, to calculate the correct location for the password. echo I am user bandit23 | md5sum | cut -d ' ' -f 1</code></pre> Running this series of commands will give us the value stored in $mytarget</code> which is 8ca319486bfbbc3663ea0fbe81326349</code>. Therefore, the final location for the password is /tmp/8ca319486bfbbc3663ea0fbe81326349</code>. Output the file to get the password. $ cat /tmp/8ca319486bfbbc3663ea0fbe81326349 [REDACTED BANDIT 23 PASSWORD]</code></pre>Level 23</a></h3> A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/</code> for the configuration and see what command is being executed. NOTE: This level requires you to create your own first shell-script. This is a very big step and you should be proud of yourself when you beat this level! NOTE 2: Keep in mind that your shell script is removed once executed, so you may want to keep a copy around… </blockquote> This challenge is similar to the last one, but this time we won’t just be reading a shell script. We’ll be writing out own. Shell scripting</a></h4> We mostly breezed by all the scripts in the previous levels, but now that we’re writing our own. Let’s break them down a bit. First we’ll look at the anatomy of a shell script. Shell scripts are just text files. On Linux, file extensions in Linux usually4</a> aren’t necessary, but it’s common to end shell scripts with a .sh</code> e.g. shell.sh</code>. The first line of any script should include a shebang</a> to specify what kind of script it is. When a file starting with a shebang is executed, the filepath provided after the shebang points the interpreter that will be used for the script. For example, a shell script might begin like so. #!/bin/bash echo Hello there!</code></pre> But it’s also possible to indicate other types of scripts, like Python for example. #!/usr/bin/python print("Hi!")</code></pre> We’ll only be writing shell scripts in this walkthrough though. After the shebang, you can write any command as you’d normally write directly in the terminal. For example, here’s a script making a directory and writing some text to a file in that directory. #!/bin/sh mkdir -p test_dir echo "TESTING" > test_dir/test.txt cat test_dir/test.txt</code></pre> There’s a lot more to Bash and shell scripting, but this should be enough to get started. If you’d like to learn more, the Bash Reference Manual</a> is an excellent reference. If you’re planning to do any real work with Bash scripts, definitely read through the Bash scripting quirks & safety tips</a> article by Julia Evans. It’ll walk you through some of the common gotchas. Don’t forget to make any script you write executable. On most systems files aren’t created with the execute (x) permission. So you’ll need to modify the permissions with a command like chmod +x</code>. This will enable any user to execute the script. </blockquote> Solution</a></h4> Now let’s write our script. We know that bandit24</code> has a cronjob running. You’ll find it at /etc/cron.d/cronjob_bandit24</code>. @reboot bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null * * * * * bandit24 /usr/bin/cronjob_bandit24.sh &> /dev/null</code></pre> Just like the last level, the cronjob is executing a script in /usr/bin</code>. Let’s examine it. 1#!/bin/bash 2 3myname=$(whoami) 4 5cd /var/spool/$myname/foo 6echo "Executing and deleting all scripts in /var/spool/$myname/foo:" 7for i in .; 8do 9 if [ "$i" != "." -a "$i" != ".." ]; 10 then 11 echo "Handling $i" 12 owner="$(stat --format "%U" ./$i)" 13 if [ "${owner}" = "bandit23" ]; then 14 timeout -s 9 60 ./$i 15 fi 16 rm -f ./$i 17 fi 18done</code></pre> According to the echo</code> message, this script should be executing and deleting all the scripts in /var/spool/bandit24/foo</code>. So, presumably, if that foo</code> directory is writable by bandit23</code> then we could write a script. Copy it into that directory, and then simply wait for the cronjob to activate and run our script. Let’s check. $ ls -l /var/spool/bandit24/ total 4 drwxrwx-wx 62 root bandit24 4096 Jun 17 13:51 foo</code></pre> Note the atypical w</code> in the “other” portion of the directory permissions. That means we’ll be able to copy in any scripts we’d like. There are plenty of different ways you could solve this, but the simplest is to send the contents of the bandit24 password file to a new file which we can read. Here’s an example solution. 1#!/bin/sh 2mkdir -p /tmp/cblanken_L24 3cat /etc/bandit_pass/bandit24 > /tmp/cblanken_L24/pass.txt</code></pre> Don’t forget to swap in your own temporary directory name and make your script file executable with chmod</code>. $ chmod +x solve.sh</code></pre> Then copy your script into /var/spool/bandit24/foo</code> and wait for it to be executed. $ cp solve.sh /var/spool/bandit24/foo/</code></pre> The cronjob is triggered every minute, so you shouldn’t have to wait long. $ cat /tmp/cblanken_L24/pass.txt [REDACTED LEVEL 24 PASSWSORD]</code></pre>Level 24</a></h3> A daemon is listening on port 30002 and will give you the password for bandit25 if given the password for bandit24 and a secret numeric 4-digit pincode. There is no way to retrieve the pincode except by going through all of the 10000 combinations, called brute-forcing. You do not need to create new connections each time </blockquote> There are a lot of possible ways to solve this, but I recommend splitting it into two parts. First we need to generate these 4 digit PINs</li> Then we’ll send them to port 30002.</li> </ol> Generating PINs</a></h4> One convenient way to do this is with the seq</a> command which can generate sequences of numbers. For example $ seq 0 10 0 1 2 3 4 5 6 7 8 9 10</code></pre> You might notice though that all these single digits aren’t exactly valid PINs. They should have leading zeroes up to 4 digits. Fortunately, seq</code> has a flag that will pad our numbers with leading zeroes just how we need using the -w</code> flag. Here’s an excerpt from the manual. -w, --equal-width equalize width by padding with leading zeroes</code></pre> Now we have our leading zeroes, and we just need to update the maximum argument from 10 to 9999 to get every possible 4-digit pin. $ seq -w 0 9999 0000 0001 0002 0003 0004 --- snip --- 9995 9996 9997 9998 9999</code></pre> Next let’s see what we need to be sending to port 30002. If you start a connection to the port with netcat, the service will reply with a simple explanation. $ nc localhost 30002 I am the pincode checker for user bandit25. Please enter the password for user bandit24 and the secret pincode on a single line, separated by a space.</code></pre> It says here that the bandit24</code> password and our PIN should be sent in a single line with a space separating the two. To write this all out, it would be a bit unwieldy to do it all directly from the shell, so let’s write ourselves a Bash script. We’ve already gone over some of the basics</a>, but here we’ll need to introduce some new syntax. The for</code> loop. #!/bin/bash # Generate PINs for i in $(seq -w 0 9999); do echo "[REDACTED LEVEL 24 PASSWORD] $i" done</code></pre> Now, I want to return to something mentioned in the prompt. It reads. You do not need to create new connections each time. </blockquote> This is actually quite an important concept when writing scripts or doing any programming really. Understanding the requirements for the script you’re writing and making it perform well without doing extra work or using resources that aren’t strictly necessary. In this case the prompt has hinted to us that we really only need one connection to port 30002 to do all this work. Now I want you to think about what this script will do with the addition of one line. Consider why this might be problematic. for i in $(seq -w 0 9999); do echo "[REDACTED LEVEL 24 PASSWORD] $i" | nc localhost 30002 done</code></pre> The problem here is that we’ve placed our call to netcat</code> within our for</code> loop. That means netcat</code> will be creating and tearing down the connection to port 30002 for every iteration of this loop. If you try this script you’ll also notice an even more glaring problem. The program actually hangs after sending only the first code. That’s because netcat will await user input as long as the connection hasn’t been closed and since the correct PIN wasn’t sent, the service is still awaiting more input. So we can already see this approach may cause some problems. Instead, let’s generate all our numbers with our first script and then pass the output to netcat with a pipe. In this way, only one connection is required, and we can guarantee that all the PINs will be sent to the service on port 30002. $ ./gen_pincodes.sh | nc localhost 30002</code></pre> Running the script will yield the password once the correct PIN is reached. --- snip --- Wrong! Please enter the correct current password and pincode. Try again. Wrong! Please enter the correct current password and pincode. Try again. Wrong! Please enter the correct current password and pincode. Try again. Wrong! Please enter the correct current password and pincode. Try again. Correct! The password of user bandit25 is [REDACTED LEVEL 25 PASSWORD]</code></pre>Level 25</a></h3> Logging in to bandit26 from bandit25 should be fairly easy… The shell for user bandit26 is not /bin/bash</code>, but something else. Find out what it is, how it works and how to break out of it. NOTE: if you’re a Windows user and typically use Powershell to ssh into bandit: Powershell is known to cause issues with the intended solution to this level. You should use command prompt instead. </blockquote> We’re told bandit 26 runs some other shell than bash. There are a couple ways to discover a user’s default shell in Linux. One is the /etc/passwd</code> file. It lists all the users of the system, whether they can login, and what default shell they have. We can cat /etc/passwd</code> and search for bandit26 to discover its shell. Here’s the relevant excerpt. $ cat /etc/passwd --- snip --- bandit24:x:11024:11024:bandit level 24:/home/bandit24:/bin/bash bandit25:x:11025:11025:bandit level 25:/home/bandit25:/bin/bash bandit26:x:11026:11026:bandit level 26:/home/bandit26:/usr/bin/showtext bandit27:x:11027:11027:bandit level 27:/home/bandit27:/bin/bash bandit28:x:11028:11028:bandit level 28:/home/bandit28:/bin/bash --- snip ---</code></pre> To display this information in a more readable format, we can use the lslogins</a> command as well. $ lslogins bandit26 Username: bandit26 UID: 11026 Gecos field: bandit level 26 Home directory: /home/bandit26 Shell: /usr/bin/showtext No login: no Primary group: bandit26 GID: 11026 Last login: 14:03 Last terminal: pts/171 Last hostname: 183.171.69.129 Hushed: no Running processes: 0 Last logs:</code></pre> Note how the Shell field for bandit26</code> is /usr/bin/showtext</code> as opposed to the other levels which use /usr/bin/bash</code> as the default shell. Running file</code> on /usr/bin/showtext</code> shows that it’s a regular ASCII file. $ file /usr/bin/showtext /usr/bin/showtext: POSIX shell script, ASCII text executable</code></pre> It’s identified as a shell script, so let’s read through it to see what it’s doing. 1#!/bin/sh 2 3export TERM=linux 4 5exec more ~/text.txt 6exit 0</code></pre> Pretty short, it seems to be setting the $TERM</code> shell variable to “linux” and then replaces the current shell with a more</code> command with the file /home/bandit26/text.txt</code> (remember the ~</code> will expand to the home directory of the user). We can’t directly read the contents of the text.txt</code> file from bandit25 but since the more</code> pager is being used it should print the contents to the screen when we try to login as the bandit26 user. Pagers</a></h4> Before we continue though, we need to discuss a bit about pagers. You might have already used one before, but this is our first look at a challenge that strictly requires the use of one. The pager used here is more</code></a>, but it’s more likely you’ll have used less</code></a> which is the default in many Linux distributions. Essentially pagers allow us to view text in the terminal such that it’s paginated. As opposed to printing an entire file with the cat</code> command all in one shot. A pager like more</code> will stop writing text once the screen is filled and then allow you to continue page by page until you’ve reached the end of the text. The less</code> command has some more advanced text search features and allows moving forward and backwards through a file unlike more</code>. In any case, I’d recommend looking through the help menu of less</code> (just press h</code> after opening a file to see a summary of less</code> commands). 1 SUMMARY OF LESS COMMANDS 2 3 Commands marked with * may be preceded by a number, N. 4 Notes in parentheses indicate the behavior if N is given. 5 A key preceded by a caret indicates the Ctrl key; thus ^K is ctrl-K. 6 7 h H Display this help. 8 q :q Q :Q ZZ Exit. 9 --------------------------------------------------------------------------- 10 11 MOVING 12 13 e ^E j ^N CR * Forward one line (or N lines). 14 y ^Y k ^K ^P * Backward one line (or N lines). 15 f ^F ^V SPACE * Forward one window (or N lines). 16 b ^B ESC-v * Backward one window (or N lines). 17 z * Forward one window (and set window to N). 18 w * Backward one window (and set window to N). 19 ESC-SPACE * Forward one window, but don't stop at end-of-file. 20 d ^D * Forward one half-window (and set half-window to N). 21 u ^U * Backward one half-window (and set half-window to N). 22 ESC-) RightArrow * Right one half screen width (or N positions). 23 ESC-( LeftArrow * Left one half screen width (or N positions). 24 ESC-} ^RightArrow Right to last column displayed. 25 ESC-{ ^LeftArrow Left to first column. 26 F Forward forever; like "tail -f". 27HELP -- Press RETURN for more, or q when done</code></pre> Now back to the challenge at hand. Solution</a></h4> Bandit 25 has an ssh key for bandit 26 in the home directory. We’ll retrieve that first so we can ssh directly into bandit 26. But, if you try to login with this key we’re greeted with the usual message followed by a closed connection. $ ssh bandit26@bandit.labs.overthewire.org -i bandit26.key --- snip --- --[ More information ]-- For more information regarding individual wargames, visit http://www.overthewire.org/wargames/ For support, questions or comments, contact us on discord or IRC. Enjoy your stay! _ _ _ _ _ | | | (_) | | \ / / | | __ _ _ | |_| |_ ) / /_ | '_ \ / _` | '_ \ / _` | | __| / / '_ \ | |_) | (_| | | | | (_| | | |_ / /| (_) | |_./ \,_|_| |_|\__,_|_|\|\_/ Connection to bandit.labs.overthewire.org closed.</code></pre> The crux of this challenge relies on that fact that the paging of more</code> is dependent upon the size of the text input. If the number of lines of text exceed the available lines on-screen then more</code> will paginate the output, otherwise it behaves like the cat</code> command. So, in the case above, my terminal was able to print the entire text.txt</code> file which we can probably assume contains the ASCII art of bandit26 since that’s the last thing we see and the only thing that deviates from the normal welcome message from previous levels. So, that means it should be possible to trigger the pager by shrinking the height of our terminal to less than 6 lines high. Since the output is paginated, the connection doesn’t immediately end because the more</code> program is waiting for us to page through the remaining content. However, more</code> has some other features that can help us escape this prompt. If you press either the h</code> or ?</code> key while on this prompt, more</code> will list out a summary of commands. One of which includes the option to execute commands in a subshell. This is promising and there may be a way to execute commands directly via more</code> to retrieve the bandit26 password and to solve for the next one. However, it’s quite laborious since more</code> won’t yield any output for any commands we run, so we would have to write to various temporary files to manage it. Instead, I’m going to show you a neat trick with Vi. If you look carefully there’s an option just below the !<cmd></code> option. The v</code> command which will open vi</code>. Vi and Vim</a></h4> Vi is a powerful text editor that is a common default on Linux systems. You may have also heard of its descendant Vim which has even more capabilities. I won’t be going into much detail on the features of Vim here. Just enough to demonstrate the solution, but I highly recommend working through the beginner section of the Vim Guide</a> by The Valuable Dev</a> if you’re interested in discovering its power. From here on out I’ll refer to Vi and Vim collectively as Vim for simplicity. Just be aware they are in fact distinct. Even if we don’t run into any distinguishing features in this walkthrough. Firstly, Vim is not a typical text editor like most folks are familiar with like Windows’ Notepad and Apple’s TextEdit. Vim exists entirely in the terminal and was designed to function entirely without a pointing device like a mouse. Vim is what’s known as a modal editor. Instead of always interpreting input from the keyboard as text to be written, Vim has several different modes: normal mode (this is the default mode usually used for navigating your files)</li> insert mode (this is like your typical text editors)</li> visual mode (kind of like when you select text with your mouse in other editors)</li> command mode</li> </ul> The main thing you need to know for this challenge is that the colon :</code> is used to enter command mode. The first command we’ll use is :edit</code>. This command will open a file so let’s use it to grab the bandit26 password. :edit /etc/bandit_pass/bandit26</code></pre>[REDACTED BANDIT 26 PASSWORD] ~ ~ ~ ~ ~ "/etc/bandit_pass/bandit26" [readonly] 1L, 33B 1,1 All</code></pre> While this is a good first step, we still need some way access a shell to complete the next level. Fortunately Vim can also open a shell with the :shell</code> command. You can read more about it with the :help</code> command. The full command is :help :shell</code>. Unfortunately, by default, it uses the same shell that spawned the process. Use the set command to change the mentioned shell</code> variable like so. :set shell=/bin/bash</code></pre> At last, we can open a bash shell with the :shell</code> command. Level 26</a></h3> Good job getting a shell! Now hurry and grab the password for bandit27! </blockquote> If we look in the home directory of bandit27 we’ll find a setuid script called bandit27-do</code>. When we run it we get the following output.</li> </ul> This level is essentially a duplicate of Level 19</a> since the real difficulty is in gaining a shell via more</code> as shown in Level 25</a>. The suid binary bandit27-do</code> is available in the home directory. $ ./bandit27-do Run a command as another user. Example: ./bandit27-do id</code></pre> Print the bandit27 password like so. $ ./bandit27-do cat /etc/bandit_pass/bandit27 [REDACTED BANDIT 27 PASSWORD]</code></pre>Level 27</a></h3> There is a git repository at ssh://bandit27-git@localhost/home/bandit27-git/</code> repo via the port 2220. The password for the user bandit27-git is the same as for the user bandit27</code>. Clone the repository and find the password for the next level. </blockquote> Git</a></h4> Git is a software version control system. As of this writing Git is probably the most popular version control system for software and has been for a while. At any rate, you’ll likely come across it while doing any kind of IT administration or security work. The best resource to learn about Git is probably the reference documentation</a> and the Pro Git book</a> which is freely available online, but it isn’t necessary to know a lot of details for these challenges. To start you really only need to know a few commands. Git Command</th> Description</th></tr></thead> git-clone(1)</kbd></a></td> download a repository from a remote system</td></tr> git-checkout(1)</kbd></a></td> interact with the repository at a certain commit</td></tr> git-log(1)</kbd></a></td> list commits</td></tr> git-branch(1)</kbd></a></td> list branches</td></tr> </tbody></table> The repository mentioned in the prompt can be cloned with the following command. $ git clone ssh://bandit27-git@localhost:2220/home/bandit27-git/repo</code></pre> After entering the level password, the git clone should complete with some progress indicators. remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Compressing objects: 100% (2/2), done. Receiving objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0</code></pre> And, there should now be a directory named repo</code> in the current directory. The repository contains a single README file which contains the password. $ cat README The password to the next level is: [REDACTED LEVEL 28 PASSWORD]</code></pre>Level 28</a></h3> There is a git repository at ssh://bandit28-git@localhost/home/bandit28-git/</code> repo via the port 2220. The password for the user bandit28-git is the same as for the user bandit28</code>. Clone the repository and find the password for the next level. </blockquote> Just as before, clone the repository. $ git clone ssh://bandit28-git@localhost:2220/home/bandit28-git/repo</code></pre> This time, the README</code> file contains a password that has been redacted. # Bandit Notes Some notes for level29 of bandit. ## credentials - username: bandit29 - password: xxxxxxxxxx</code></pre> Examine the change history with the git log</code> command. commit 674690a00a0056ab96048f7317b9ec20c057c06b (HEAD -> master, origin/master, origin/HEAD) Author: Morla Porla <morla@overthewire.org> Date: Thu Apr 10 14:23:19 2025 +0000 fix info leak commit fb0df1358b1ff146f581651a84bae622353a71c0 Author: Morla Porla <morla@overthewire.org> Date: Thu Apr 10 14:23:19 2025 +0000 add missing data commit a5fdc97aae2c6f0e6c1e722877a100f24bcaaa46 Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:19 2025 +0000 initial commit of README.md</code></pre> There’s a reference to an “info leak” from the previous commit. Check out the previous commit with the git checkout</code> command. $ git checkout fb0df1358b1ff146f581651a84bae622353a71c0</code></pre> This will change the repository to its original state at the specified commit hash. At this point in the repositories history, the bnadit29 password had not yet been redacted in the README</code> file. # Bandit Notes Some notes for level29 of bandit. ## credentials - username: bandit29 - password: [REDACTED LEVEL 29 PASSWORD]</code></pre>Level 29</a></h3> There is a git repository at ssh://bandit29-git@localhost/home/bandit29-git/</code> repo via the port 2220. The password for the user bandit29-git is the same as for the user bandit29</code>. Clone the repository and find the password for the next level. </blockquote> Clone the repository. $ git clone ssh://bandit29-git@localhost:2220/home/bandit29-git/repo</code></pre> Similar to Level 28</a> there is a README</code> file. # Bandit Notes Some notes for bandit30 of bandit. ## credentials - username: bandit30 - password: <no passwords in production!></code></pre> Looking at the log again doesn’t turn up anything interesting. commit 3910630172946c9ffb75842922e394b772c672bd (HEAD) Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 add gif2ascii commit 3b8b91fc3c48f1a19d05670fd45d3e3f2621fcfa (origin/master, origin/HEAD, master) Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 fix username commit 8d2ffeb5e45f87d0abb028aa796e3ebb63c5579c Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 initial commit of README.md</code></pre> This is where some knowledge of Git’s branching is useful. By default, the git log</code> command will only display commits from current branch. In this case the master</code> branch. Use the git branch</code> command to show the active branch. $ git branch * master</code></pre> Additionally using the --all</code> flag will list all the local and remote branches. $ git branch --all * master remotes/origin/HEAD -> origin/master remotes/origin/dev remotes/origin/master remotes/origin/sploits-dev</code></pre> You can see here that there are two additional branches mentioned. The dev</code> and sploits-dev</code> branches. Let’s check them out. $ git checkout dev Switched to branch 'dev' Your branch is up to date with 'origin/dev'.</code></pre>commit a97d0dbf8fd910ead6fcf648829ff55c1a629c8e (HEAD -> dev, origin/dev) Author: Morla Porla <morla@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 add data needed for development commit 3910630172946c9ffb75842922e394b772c672bd Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 add gif2ascii commit 3b8b91fc3c48f1a19d05670fd45d3e3f2621fcfa (origin/master, origin/HEAD, master) Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 fix username commit 8d2ffeb5e45f87d0abb028aa796e3ebb63c5579c Author: Ben Dover <noone@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 initial commit of README.md</code></pre> The git show</code> command will print the changes made by the last commit, but you can alternatively, just read the README</code> file while on the dev</code> branch since the last commit contains the password. commit a97d0dbf8fd910ead6fcf648829ff55c1a629c8e (HEAD -> dev, origin/dev) Author: Morla Porla <morla@overthewire.org> Date: Thu Apr 10 14:23:21 2025 +0000 add data needed for development diff --git a/README.md b/README.md index 1af21d3..bc6ad3d 100644 --- a/README.md +++ b/README.md @@ -4,5 +4,5 @@ Some notes for bandit30 of bandit. ## credentials - username: bandit30 -- password: <no passwords in production!> +- password: [REDACTED BANDIT 30 PASSWORD]</code></pre> The password only appears in the dev</code> branch because it was only added in the dev</code> branch, but never actually merged into master</code>. Level 30</a></h3> There is a git repository at ssh://bandit30-git@localhost/home/bandit30-git/</code> repo via the port 2220. The password for the user bandit30-git is the same as for the user bandit30</code>. Clone the repository and find the password for the next level. </blockquote> Clone the repository. $ git clone ssh://bandit30-git@localhost:2220/home/bandit30-git/repo</code></pre> If we run git log --all</code> there doesn’t appear to be anything unusual. This time we’ll need to look at something called Tags</a> and a couple new commands. Git Command</th> Description</th></tr></thead> git-tag(1)</kbd></a></td> create, list, delete or verify tags</td></tr> git-show(1)</kbd></a></td> show various git object i.e. blobs, commits, tags, and trees</td></tr> </tbody></table> Here we’ll list the existing tags for the repo. $ git tag secret</code></pre> Usually tags are used to mark specific commits, but if you try to git checkout</code> this secret</code> tag you’ll get an error saying the reference is not a tree. This means the tag is just a BLOB (Binary Large OBject). You can read more about trees and blobs here</a>. To show the contents of a blob we can use the git show</code> command which reveals the next password. $ git show secret [REDACTED LEVEL 31 PASSWORD]</code></pre>Level 31</a></h3> There is a git repository at ssh://bandit31-git@localhost/home/bandit31-git/repo via the port 2220. The password for the user bandit31-git is the same as for the user bandit31. Clone the repository and find the password for the next level. </blockquote> Clone the repo. The README.md</code> tells us to push a file to the remote with some file details. This time your task is to push a file to the remote repository. Details: File name: key.txt Content: 'May I come in?' Branch: master</code></pre> We’ll need a couple new commands to do that. Git Command</th> Description</th></tr></thead> git-status(1)</kbd></a></td> display the status of the working tree</td></tr> git-add(1)</kbd></a></td> add files to the staging area</td></tr> git-push(1)</kbd></a></td> create a new commit based on the current changes and add a commit message</td></tr> </tbody></table> Next we need to create the key.txt</code> file. $ echo "May I come in?" > key.txt</code></pre> Then add the key.txt</code> to our index. $ git add key.txt The following paths are ignored by one of your .gitignore files: key.txt hint: Use -f if you really want to add them. hint: Turn this message off by running hint: "git config advice.addIgnoredFile false"</code></pre> You can read more about the mentioned .gitignore</code> files here</a>, but in this case we can just use the recommended -f</code> flag to add the file and try again. $ git add -f key.txt</code></pre> We can verify that the key.txt</code> file has been added to the index with git status</code>. $ git status On branch master Your branch is up to date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: key.txt</code></pre> Now we need to commit this change with the git commit</code> command. This applies our changes to the master</code> branch. $ git commit -m "Add key.txt" [master a1f8c06] Add key.txt 1 file changed, 1 insertion(+) create mode 100644 key.txt</code></pre> And finally, we can use the git push</code> command to push our new commit to the remote repository. $ git push origin master</code></pre> Watch out! If the content of key.txt</code> does not match the prescribed text exactly you may receive an error like this. Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 2 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 323 bytes | 323.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: ### Attempting to validate files... #### remote: remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo. remote: remote: Wrong! remote: remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo. remote: To ssh://localhost:2220/home/bandit31-git/repo ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh://localhost:2220/home/bandit31-git/repo'</code></pre></blockquote> If everything is in order, you’ll get some feedback from the git server which will include the next password. remote: ### Attempting to validate files... #### remote: remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo. remote: remote: Well done! Here is the password for the next level: remote: [REDACTED LEVEL32 PASSWORD] remote: remote: .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo. remote: To ssh://localhost:2220/home/bandit31-git/repo ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'ssh://localhost:2220/home/bandit31-git/repo'</code></pre>Level 32</a></h3> After all this git stuff, it’s time for another escape. Good luck! </blockquote> After logging in to bandit32 you’ll find yourself in an “UPPERCASE” shell, all entered text appears to be converted to uppercase. WELCOME TO THE UPPERCASE SHELL >> cat /etc/passwd sh: 1: CAT: Permission denied >></code></pre> It’s possible to reference some environment variables such as $PATH</code>, $PWD</code>, $SHELL</code>, and $USER</code>. >> $PATH sh: 1: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: not found >> $PWD sh: 1: /home/bandit32: Permission denied >> $USER sh: 1: bandit32: Permission denied</code></pre> You see, just accessing the variable, the Uppercase Shell tries to execute the contents seemingly with the sh</code> shell. This is great, but not enough. You have to know about a special shell variable, $0</code>. The $0</code> shell variable expands to the name of the shell or shell script being executed which in this case is sh</code>. Therefore, providing the $0</code> variable will execute the sh</code> command dropping us into a normal shell. >> $0 $</code></pre> From here’s it’s just a matter of printing the next password from the file as we’ve done many times before. $ cat /etc/bandit_pass/bandit33 [REDACTED LEVEL33 PASSWORD]</code></pre>The End</a></h2> Congratulations! You made it! I hope you had fun working through all these challenges. There were a couple tricky ones that I didn’t get them all myself on the first time around. If this wargame has piqued your interest I’ve also written a couple other walkthroughs. OverTheWire Natas</a></li> OverTheWire Leviathan</a></li> </ul> If the OverTheWire wargames aren’t quite your cup of tea though, then I highly recommend the picoCTF</a> platform run by Carnegie Mellon University. They host an annual CTF event, but challenges from previous years are all available to practice. The picoCTF challenges cover a wide range of topics and levels of difficulty so that anyone can find something interesting. Finally, a big thanks to the folks at OverTheWire</a> for maintaining the infrastructure for the OverTheWire wargames. They’re such a great resource for folks first dipping their toes into cybersecurity and CTFs. Happy hacking! Just like almost every cryptographic system, it’s possible for SSH to be used incorrectly, thus compromising it’s security</a>. ↩</a> </li> SSL and TLS both commonly refer to Transport Layer Security</a> which is a protocol designed for secure communications over computer networks. SSL (Secure Sockets Layer) is a legacy term referring to the precursor to TLS, but the terms are often used interchangeably. However, modern applications should not be communicating via SSL since its final version (SSL 3.0) was deprecated in 2015. ↩</a> </li> Ports 1-1024 are privileged ports and can’t be used without root permissions. That’s because commonly known services are hosted on these ports and should ideally only be accessible by a system administrator. Anything from 1025 to 65535 should be fine though. If by chance you receive an error message of nc: Address already in use</code>, then try another. ↩</a> </li> Some programs, in particular archiving and compression utilities like tar</code>, gzip</code>, and bzip2</code> will refuse to operate on files without an appropriate file extension, but most programs will instead read the first few bytes of a file to determine it’s type. Commonly known as magic numbers</a> ↩</a> </li> </ol> </section> HTB Apocalypse 2023 - Janken Cameron Blankenbuehler — Sat, 25 Mar 2023 00:00:00 +0000 Problem description</a></h2> Janken is an easy rated Misc challenge. As you approach an ancient tomb, you’re met with a wise guru who guards its entrance. In order to proceed, he challenges you to a game of Janken, a variation of rock paper scissors with a unique twist. But there’s a catch: you must win 100 rounds in a row to pass. Fail to do so, and you’ll be denied entry. </blockquote> Analysis</a></h2> Analyzing the decompilation of the binary (janken</code>), we find a loop for the 100 rounds mentioned in the prompt running the following game</code> function. Solution</a></h2> Here’s an excerpt of the pwntools script used to solve the challenge. 1io = start() 2info(io.recvuntil(b'>> ')) # prompt 3io.sendline(b'1') 4 5rps = ['rock', 'scissors', 'paper'] 6 7rps_win = { 8 'rock': 'paper', 9 'paper': 'scissors', 10 'scissors': 'rock', 11} 12 13def wait_for_next_second(epoch_time): 14 while int(time.time()) <= epoch_time: 15 time.sleep(0.05) 16 17for _i in range(0, 99): 18 epoch_time = epoch_time = time.time() # time before asking for prompt 19 if epoch_time - int(epoch_time) > 0.8: 20 wait_for_next_second(epoch_time) 21 info(io.recvuntil(b'>> ')) # wait for prompt 22 time2 = time.time() 23 rand_io = process(['./rand', f"{epoch_time}"]) 24 r = int(rand_io.readline().strip()) 25 enemy_answer = rps[r % 3] 26 answer = rps_win[enemy_answer] 27 28 info(f"Sending result: {answer}") 29 time3 = time.time() # time before sending response 30 io.sendline(bytes(answer, encoding="utf-8")) 31 time4 = time.time() # time after sending response 32 33 print(f"{_i}: Time delta: {epoch_time:.3f}, {time2:.3f}, {(time2 - epoch_time):.3f}, {(time4-time3):3f}") 34 35io.interactive()</code></pre>Flag</a></h1> We have our flag! HTB{r0ck_p4p3R_5tr5tr_l0g1c_buG}</code> KitCTF 2022 - ein-pfund-mails Cameron Blankenbuehler — Wed, 26 Oct 2022 00:00:00 +0000 Problem description</a></h2> The ein-pfund-mails</code> challenge is a baby rated challenge in the Misc category for KitCTFCTF 2022. The title ein pfund mails is actually German for “A pound of mail”. Which makes sense since we are given an archive (mails.tar.gz</code>) containing 3993 .eml</code> files. We’re told one of these leaked email files contains our flag, but we’re unable to determine which file contains the correct flag. Analysis</a></h2> First off, let’s take a look at one of the email files. Return-Path: <mawalu98@gmail.com> Delivered-To: martin@mawalabs.de Received: from mail.mawalabs.de ([fd4d:6169:6c63:6f77::e]) by a0818493a1af with LMTP id Oa/3IrxGq2JiaTIAoqc0QA (envelope-from <mawalu98@gmail.com>) for <martin@mawalabs.de>; Thu, 16 Jun 2022 17:05:32 +0200 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.mawalabs.de (Postcow) with ESMTPS id 5BA84A2171 for <martin@mawalabs.de>; Thu, 16 Jun 2022 17:05:27 +0200 (CEST) Received: by mail-pj1-f42.google.com with SMTP id k12-20020a17090a404c00b001eaabc1fe5dso2079659pjg.1 for <martin@mawalabs.de>; Thu, 16 Jun 2022 08:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=; b=R1TrM58fPxWGqqUpauME4wQbljhoUlMEpPpf2NWBP1Hy8WrZH0MMkrqurXHAMNNx/H I3QHbOEeHm8GjQ9GbUWHWTYt8oFutzcBiCN8+5xFbuuDoYgxyAQWpbuKcWM3h3LpkFbC IN4ps9rF3ANb/DOTxYFf0TUGvTOSqXuwe1UBFnOwckfUFVwvh/FYPDzOvGiXE683jxXq 4GrAKzDDdbyyeKzUSyeV4ndqkTGGODLWULrUbBT/ihyNq5Nomc5QCiw61UIflwVndFdE h1ufkxX2FEUJ2fpS9KbV8mfEqN+roncsHzXvVdo+ersxg4jQXA/aYOf9XoaPz48Sb9qf MsMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=; b=AwM4jiAdlpSKBy7IZ3nfQsHnYeQp1gvVpI/Bpnoer/mkdv75drjydquL+ZXUmOaySW k9jKtb/haWXRx6TCvoAFrO/ZN2tmDknI7r9yoKWdLP37Er4thOhniv0mKAPBeL47i/95 GG3Kfu4eMuNx/NzhqxKPIPb6Mc+tGAfe2VisvxOk/l5vbR8U4bWNiBwmF9Q4kLyFYMnb gPx1ZhsxQWqFIn+hr6D9vUFxiz5cAe0m2Bq6V4e24akQrLjMrBjwY94vXzZJlb4VW6cG 2pffywU5CDks4qLPYnI1bkImrQJrOR3KEZSYppSm3vkBSvgJ06aTzvGRrLE18Hwmtxmv 5Vnw== X-Gm-Message-State: AJIora9DCvU5UatGInjShXcoDXp0abItZgRUoXxhwA+0+fDgg4Jv+3l8 jr6KvtgQZpxKkN+zFS/vejX8L1MA57H5+1ZjOis2QxR6//w= X-Google-Smtp-Source: AGRyM1tXZeDE5/ppkeaIx2YE297NIvPpikDXV+2nwHlgPl646MSCkIdSwtEBFkznNZNqV1uMfJsEq98wjv3m/KYd3Vc= X-Received: by 2002:a17:903:244a:b0:164:2880:4df1 with SMTP id l10-20020a170903244a00b0016428804df1mr5108675pls.120.1655391924792; Thu, 16 Jun 2022 08:05:24 -0700 (PDT) MIME-Version: 1.0 From: Martin Wagner <mawalu98@gmail.com> Date: Thu, 16 Jun 2022 17:05:13 +0200 Message-ID: <CAA2ev=GHMZn2+6vgHv9kEQV5h4ZWcOapubMOJtg2BTM7VsgOAw@mail.gmail.com> Subject: Flag To: martin@mawalabs.de Content-Type: multipart/alternative; boundary="000000000000a433c905e191f775" ARC-Seal: i=1; s=dkim; d=mawalabs.de; t=1655391927; a=rsa-sha256; cv=none; b=qiV2rtXrZGucJcxohmzBoIzrGijMaDnXMKViSQCoub6PgUBRu9dXIo2JbqjIvVG3RiAsB5 x2y79l2rnSzipM62UfVfdnv7/bHXC0oxlHtIqYVDK/NqOBasDYzkgkmkAmUFIeyh7qcJ8A i50585Fm1I58zMYi88Nnlq4Ou+whuc8= ARC-Authentication-Results: i=1; mail.mawalabs.de; dkim=pass header.d=gmail.com header.s=20210112 header.b=R1TrM58f; spf=pass (mail.mawalabs.de: domain of mawalu98@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=mawalu98@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mawalabs.de; s=dkim; t=1655391927; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: dkim-signature; bh=Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=; b=oiuiewyUJBkwDRfqclseGFj1hYEfF0kN+UD7pdWf/wun/Sccb1T9bP6a9DGS/liipuXPhS DayxqKgsuRqvB5c1WSxQXIc2iXdKkTttQt1LgaXE1d+wSo6Hap502RMji4aZVcMM6owh/T 1fhY0QCzzNrw2JCYoeMCtcZ0LNWvtTY= X-Last-TLS-Session-Version: TLSv1.3 Authentication-Results: mail.mawalabs.de; dkim=pass header.d=gmail.com header.s=20210112 header.b=R1TrM58f; spf=pass (mail.mawalabs.de: domain of mawalu98@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=mawalu98@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Spamd-Result: default: False [1.79 / 15.00]; RBL_SORBS_RECENT(2.00)[209.85.216.42:from]; BAD_REP_POLICIES(2.00)[]; NEURAL_HAM_SHORT(-2.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.216.42:from]; MX_GOOD(-0.01)[]; IP_REPUTATION_HAM(-0.00)[asn: 15169(0.00), country: US(-0.00), ip: 209.85.216.42(0.00)]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[gmail.com:s=20210112]; BCC(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; CLAM_VIRUS_FAIL(0.00)[failed to scan and retransmits exceed]; PREVIOUSLY_DELIVERED(0.00)[martin@mawalabs.de]; RCPT_MAILCOW_DOMAIN(0.00)[mawalabs.de]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.216.42:from]; ARC_SIGNED(0.00)[mawalabs.de:s=dkim:i=1]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 5BA84A2171 --000000000000a433c905e191f775 Content-Type: text/plain; charset="UTF-8" Hi, die Flag ist KCTF{1d2fa1ed91a0310dad83242abc3f8a92} LG Martin --000000000000a433c905e191f775 Content-Type: text/html; charset="UTF-8" <div dir="ltr">Hi,<div> </div><div>die Flag ist KCTF{1d2fa1ed91a0310dad83242abc3f8a92}</div><div> </div><div>LG</div><div>Martin</div></div> --000000000000a433c905e191f775--</code></pre> Of note, are several signatures and a possible flag (KCTF{1d2fa1ed91a0310dad83242abc3f8a92}</code>). If we take a diff</code> of the two different emails (e.g. diff fffc5.eml ffdef.eml</code>), only the flag is changed. 110c110 < die Flag ist KCTF{1d2fa1ed91a0310dad83242abc3f8a92} --- > die Flag ist KCTF{a3afe0043bf7736216bc7ace6efac886} 118c118 < <div dir="ltr">Hi,<div> </div><div>die Flag ist KCTF{1d2fa1ed91a0310dad83242abc3f8a92}</div><div> </div><div>LG</div><div>Martin</div></div> --- > <div dir="ltr">Hi,<div> </div><div>die Flag ist KCTF{a3afe0043bf7736216bc7ace6efac886}</div><div> </div><div>LG</div><div>Martin</div></div></code></pre> This confirms what the prompt told us, so we can’t identify the correct flag by any differences between the files. Instead we’ll have to utilize the signatures provided in the emails to verify a valid .eml</code>. Solution</a></h2> The first signature we see in the file is a DKIM-Signature</code>. There is a useful explainer</a> over on mailtrap[.]com, if you want to get into the nitty gritty, but the short of it is that DKIM is a common signature type that’s used to verify the sender and content of an email have not been altered. That should be perfect to find the original, unaltered email in our ein pfund mails. Luckily, there are several DKIM verification libraries available on PyPI</a>. I chose check-dkim</a> since it was at the top of the list for my search. In the case of check-dkim</code>, it’s actually a CLI script. So, after installing (pip install check-dkim</code>), we can verify that it works for one of our .eml</code> files. $ check-dkim mail/fffc5.eml Error verifying DKIM body hash mismatch (got b'SHy1AAdR/+J5fTOT5HqeEr23p+JmXnlXWdr1QxcFqcU=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=')</code></pre> Now let’s write a simple bash script to verify every email file. 1#!/bin/bash 2# dkim_verify.sh 3find "$1" -iname .eml -type f -exec echo -ne "FILE: {} --- " \; -exec check-dkim {} \;</code></pre> Execute the script to start checking. ./dkim_verify.sh ./mail/</code></pre> Here is the output from our first few files. FILE: mail/c9f01.eml --- Error verifying DKIM body hash mismatch (got b'KSjh/SWf9CoOfANlP1JwziULd7TJwo2jAXdS6WxxiXk=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/483c0.eml --- Error verifying DKIM body hash mismatch (got b'NPfXTjlgeHmYX3XL505Y9ZlDsWR/nKofQRnlX2Eg+Vk=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/e1262.eml --- Error verifying DKIM body hash mismatch (got b'IwEUYGwkRHvyIUocHDTn1mq653UyllFukFAsC7/bewY=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/a9331.eml --- Error verifying DKIM body hash mismatch (got b'2kwfDpgExCVsPaquMn2PMAqKf/UEuOQneY6YpVutQ+U=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/c65c1.eml --- Error verifying DKIM body hash mismatch (got b'GGvQpfeY8Vzvfms3TWn1TsYW2Ws4CKhenm26CVZ7kCs=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=')</code></pre> After a few minutes we get a hit. Here is the output leading up to the valid .eml</code>. FILE: mail/3c586.eml --- Error verifying DKIM body hash mismatch (got b'DopvYFdcPVYCj2nGEr3Jdll+EK7xiVVk33K/6xRJp90=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/06570.eml --- Error verifying DKIM body hash mismatch (got b'uJ/mmb0346p2GMzAqGnz/6hn5G0cL/jiotY2dl2tBJk=', expected b'Hc1fzmKy9aocJCtYl88l4HEWgiYgp/nBHaexg4xOWtk=') FILE: mail/438b5.eml --- DKIM verified successfully</code></pre> Now we can check which flag is in 438b5.eml</code>. grep -oP "(KCTF{.})" mail/438b5.eml KCTF{1f8e659e892f2b2a05a54b8448ccbff9} KCTF{1f8e659e892f2b2a05a54b8448ccbff9}</code></pre>Flag</a></h1> Here we have our flag! KCTF{1f8e659e892f2b2a05a54b8448ccbff9}</code> Cryptoverse 2022 - Super Guesser Cameron Blankenbuehler — Wed, 26 Oct 2022 00:00:00 +0000 Problem description</a></h2> Super Guesser is an easy rated reversing challenge for the Crytoverse 2022 CTF. We are given a short challenge description: Only the true guessing king can solve this challenge. </blockquote> Analysis</a></h2> We are provided a link to download guesser.pyc</code>, a compiled python binary. Just to confirm there aren’t any shenangins with the file extension, let’s check the file type. $ file guesser.pyc guesser.pyc: Byte-compiled Python module for CPython 3.8, timestamp-based, .py timestamp: Sun Sep 11 18:00:05 2022 UTC, .py size: 682 bytes</code></pre> The file</code> utility tells us that we are, in fact, dealing with a compiled python binary. In this case CPython 3.8 is the version. Note: it’s important that we use the correct version of python when running the compiled .pyc</code> file otherwise we might get a magic number error as shown below and be unable to execute the program. $ python guesser.pyc RuntimeError: Bad magic number in .pyc file</code></pre> If your system has an incompatible version of Python, I’d recommend installing a tool like pyenv</code></a> to install and manage other python versions side by side on your system. Now let’s try running this program to see what we get as output. $ python guesser.pyc Guess: test Invalid $ python guesser.pyc Guess: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Invalid</code></pre> Okay it look’s like the program is checking our input. Perhaps it is checking against the challenge’s flag. Referring to the challenge title we know that this is a reversing challenge, so the next logical step is to try decompiling the python binary. One popular python decompiler is decompyle3</a>, which we can see from the PyPI page supports python versions 3.7+ which should work fine for the bytecode we have. We can decompile guesser.pyc</code> with the command: $ decompyle3 guesser.pyc</code></pre> This gets us the source code guesser.py</code> 1# decompyle3 version 3.9.0 2# Python bytecode version base 3.8.0 (3413) 3# Decompiled from: Python 3.8.0 (default, Oct 29 2022, 20:02:52) 4# [GCC 12.2.0] 5# Embedded file name: /home/guesser.py 6# Compiled at: 2022-09-11 14:00:05 7# Size of source mod 2**32: 682 bytes 8import hashlib, re 9hashes = [ 10 'd.0.....f5...5.6.7.1.30.6c.d9..0', 11 '1b.8.1.c........09.30.....64aa9.', 12 'c.d.1.53..66.4.43bd.......59...8', 13 '.d.d.076........eae.3.6.85.a2...'] 14 15def main(): 16 guesses = [] 17 for i in range(len(hashes)): 18 guess = input('Guess: ') 19 if len(guess) <= 4 or len(guess) >= 6 or re.match('^[a-z]+$', guess): 20 exit('Invalid') 21 if not re.match('^' + hashes[i].replace('.', '[0-9a-f]') + '$', hashlib.md5(guess.encode()).hexdigest()): 22 exit('Invalid') 23 else: 24 guesses.append(guess) 25 else: 26 print(f"Flag: {guesses[0]}" + '{' + ''.join(guesses[1:]) + '}') 27 28 29if name == 'main': 30 main() 31# okay decompiling guesser.pyc</code></pre> At first glance, this seems to be a fairly simple python script, but let’s break it down line by line. First we have the declaration of a list of hashes</code> 1hashes = [ 2 'd.0.....f5...5.6.7.1.30.6c.d9..0', 3 '1b.8.1.c........09.30.....64aa9.', 4 'c.d.1.53..66.4.43bd.......59...8', 5 '.d.d.076........eae.3.6.85.a2...']</code></pre> These will be important in a moment, but for now let’s follow the logic to see what the guesser is checking for. We can see in the main function, we’re iterating over the list of hashes, and for each hash, we take a string as user input and check if it’s length is equal to 5 AND if it matches the regex string ^[a-z]+$</code> which would be interpreted as a string of exclusively lowercase alphabetic letters with a length greater than or equal to one. If this condition is met, the program exits and outputs ‘Invalid’ just as we saw in initial test. 18guess = input('Guess: ') 19if len(guess) <= 4 or len(guess) >= 6 or re.match('^[a-z]+$', guess): 20 exit('Invalid')</code></pre> The second if</code> statement is taking an md5 hash of our guess string and checking that it matches the hash from our hashes list. The hash converts each .</code> (dot) character to [0-9a-f]</code>. This is necessary to only match on valid md5 hashes, otherwise we exit just as before. 21if not re.match('^' + hashes[i].replace('.', '[0-9a-f]') + '$', hashlib.md5(guess.encode()).hexdigest()): 22 exit('Invalid')</code></pre> And finally, if our guess passes both of those checks it is appended to the guesses</code> list. 23else: 24 guesses.append(guess)</code></pre> This guesses</code> list is joined and printed as the flag output provided the program doesn’t exit prematurely by receiving an incorrect guess. 25else: 26 print(f"Flag: {guesses[0]}" + '{' + ''.join(guesses[1:]) + '}')</code></pre> One important part of the last line, is that the first element of guesses</code> is used as the beginning of our flag which, according to the flag format should correspond to cvctf</code>. With that in mind we should be able to confirm our understanding of the program by finding the md5 hash of cvctf</code> which should match the first hash in hashes</code>. We can get the md5 hash by running echo -n cvctf | md5sum</code> in our terminal. This gives us an md5 hash of d70146aef5a8e5364791d3006ccd9c00</code> Placing the hashes side by side we can see that they match. d.0.....f5...5.6.7.1.30.6c.d9..0 d70146aef5a8e5364791d3006ccd9c00</code></pre> We should be able to test this by entering cvctf</code> as our first guess when running the challenge binary. $ python guesser.pyc Guess: cvctf Guess: again Invalid</code></pre> We can see that the program only exited after the guess of “again”, meaning the guess of “cvctf” was correct. That’s great but you may have noticed this seems to contradict a bit of our analysis. Recall that the first if</code> check appeared to exclude any guesses that were 5 characters in length or all lowercase and alphabetic. This exactly matches our guess of “cvctf”! Bad Decompilation?</a></h3> As we can see, the behavior of the program when running the decompiled code does not match the behavior of the original guesser.pyc</code>. Now I tried several decompilers, and as far as I can tell this is an error in the decompilation process. That line in particular should actually have decompiled to this: if not(len(guess) <= 4 or len(guess) >= 6 or re.match('^[a-z]+$', guess)): exit('Invalid')</code></pre> Instead of this if len(guess) <= 4 or len(guess) >= 6 or re.match('^[a-z]+$', guess): exit('Invalid')</code></pre> In this case, the program would exit if the guess is NOT 5 alphabetic characters. This matches the behavior we’ve seen when running the compiled binary and leads us to different assumptions about the possible problem space. Restricting our guess to all lowercase alphabetic characters means we only have $ 26^5 $ possibilities. That comes out to a measly 11,881,376 possible guesses. We should be able to write a program to do that for us. Enter brute.py</code>. Solution</a></h2> 1# brute.py 2import hashlib 3import re 4from pwnlib.util.iters import bruteforce, mbruteforce 5 6hash_patterns = [ 7 '^d.0.....f5...5.6.7.1.30.6c.d9..0$', 8 '^1b.8.1.c........09.30.....64aa9.$', 9 '^c.d.1.53..66.4.43bd.......59...8$', 10 '^.d.d.076........eae.3.6.85.a2...$'] 11 12hash_regexes = [re.compile(x) for x in hash_patterns] 13 14guess_len = 5 15charset = "abcdefghijklmnopqrstuvwxyz" 16 17for regex in hash_regexes: 18 print(f"Searching for match for {regex}...") 19 found = mbruteforce(lambda guess: 20 regex.match(hashlib.md5(guess.encode()).hexdigest()), 21 alphabet=charset, 22 length=guess_len 23 ) 24 if found is None: 25 print("No matches found") 26 else: 27 print(f"FOUND: {found}, MD5: {hashlib.md5(found.encode()).hexdigest()}")</code></pre> The program uses pwntools</a> to generate all the possible combinations given our set of lowercase alphabetic characters. It then generates the md5 hash using the hashlib</code></a> library and compares it against the hash from the hashes</code> list. $ python brute.py Searching for match for re.compile('^d.0.....f5...5.6.7.1.30.6c.d9..0$')... FOUND: cvctf, MD5: d70146aef5a8e5364791d3006ccd9c00 Searching for match for re.compile('^1b.8.1.c........09.30.....64aa9.$')... FOUND: hashi, MD5: 1bd8d1fc2b9ad2bb0943056ecf64aa97 Searching for match for re.compile('^c.d.1.53..66.4.43bd.......59...8$')... FOUND: snotg, MD5: cdd01c536d66a4943bd8bf6f5d59c0c8 Searching for match for re.compile('^.d.d.076........eae.3.6.85.a2...$')... FOUND: uessy, MD5: 8d1d70762f431cd9eaec3967859a2b4b</code></pre>Flag</a></h1> Et voilà, we have our flag! cvctf{hashisnotguessy}</code> PicoCTF 2022 - Operation Orchid Cameron Blankenbuehler — Sun, 29 May 2022 00:00:00 +0000 The challenge description goes as follows: Download this disk image and find the flag. </blockquote> We’re then given an option to download the mentioned compressed disk image (disk.flag.img.gz). Decompress the archive with gunzip disk.flag.img.gz</code>. Let’s check what kind of disk image this is: $ file disk.flag.img disk.flag.img: DOS/MBR boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-CHS (0xc,223,19), startsector 2048, 204800 sectors; partition 2 : ID=0x82, start-CHS (0xc,223,20), end-CHS (0x19,159,6), startsector 206848, 204800 sectors; partition 3 : ID=0x83, start-CHS (0x19,159,7), end-CHS (0x32,253,11), startsector 411648, 407552 sectors</code></pre> Okay at the very least the system recognizes disk.flag.img</code> as a valid image. Let’s try to mount the image to see if we can access the files. $ mkdir ./mnt $ sudo mount disk.flag.img ./mnt/ mount: /home/cameron/notes/ctf/picoCTF_2022/Forensics/OperationOrchid/mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.</code></pre> Well that didn’t work. It’s important to know that, while the mount</code> command can often automatically detect the filesystem of a device or disk image, it doesn’t automatically detect the offset. We can get some more information about the image, by viewing the partition table with the mmls</code> command. $ mmls disk.flag.img DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 000: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 001: ------- 0000000000 0000002047 0000002048 Unallocated 002: 000:000 0000002048 0000206847 0000204800 Linux (0x83) 003: 000:001 0000206848 0000411647 0000204800 Linux Swap / Solaris x86 (0x82) 004: 000:002 0000411648 0000819199 0000407552 Linux (0x83)</code></pre> Here we have all the information we need to calculate the offset in bytes. The mmls</code> output lists each section by a count of sectors. So in this case, we can see the first Linux partition starts at sector 2048</code>. To calculate the offset we just need to multiply the number of sectors by the bytes per sector listed above as Units are in 512-byte sectors </blockquote> So, our offset = 512 x 2048 = 1048576 bytes. Let’s try to mount the image again with the appropriate offset. $ sudo mount -o offset=1048576 disk.flag.img ./mnt/</code></pre> Nice, we didn’t get any errors this time. Let’s check the ./mnt/</code> directory $ tree ./mnt/ ./mnt/ ├── boot -> . ├── config-virt ├── extlinux.conf ├── initramfs-virt ├── ldlinux.c32 ├── ldlinux.sys ├── libcom32.c32 ├── libutil.c32 ├── lost+found [error opening dir] ├── mboot.c32 ├── menu.c32 ├── System.map-virt ├── vesamenu.c32 └── vmlinuz-virt 2 directories, 12 files</code></pre> Okay, doesn’t look like there is much here. This just seems to be the boot partition. We can check out the extlinux.conf</code> $ cat extlinux.conf # Generated by update-extlinux 6.04_pre1-r9 DEFAULT menu.c32 PROMPT 0 MENU TITLE Alpine/Linux Boot Menu MENU HIDDEN MENU AUTOBOOT Alpine will be booted automatically in # seconds. TIMEOUT 30 LABEL virt MENU LABEL Linux virt LINUX vmlinuz-virt INITRD initramfs-virt APPEND root=UUID=7b688671-b1b5-4e64-830d-36ebc2d4259e modules=sd-mod,usb-storage,ext4 quiet rootfstype=ext4 MENU SEPARATOR</code></pre> It looks like this is an Alpine Linux image which is neat but isn’t particularly helpful here. Let’s look at the next partition we saw in the partition table. The 2nd partition started at sector 206848, but it says it’s a swap partition which is essentially a file that acts as extra memory to keep your system from crashing if it is using too much RAM. We’ll skip this partition for now and look at the last partition which should contain the files for the system this image was pulled from. The last partition starts at sector 411648, so 512 x 411648 = 210763776 bytes is our new offset. Let’s unmount the first partition and remount with the new offset. $ sudo umount ./mnt $ sudo mount -o offset=210763776 disk.flag.img ./mnt/ $ tree -L 1 ./mnt/ ./mnt/ ├── bin ├── boot ├── dev ├── etc ├── home ├── lib ├── lost+found ├── media ├── mnt ├── opt ├── proc ├── root ├── run ├── sbin ├── srv ├── swap ├── sys ├── tmp ├── usr └── var</code></pre> Nice, that looks like a standard Linux system to me. Let’s see if we can find that flag. A good first step is to search for any files with “flag” in the name since this is a CTF after all. We can do that with the find</code> command. $ sudo find ./mnt/ -iname "flag" ./mnt/root/flag.txt.enc</code></pre> Well that looks promising. Let’s check what kind of file that is. $ sudo file ./mnt/root/flag.txt.enc ./mnt/root/flag.txt.enc: openssl enc'd data with salted password</code></pre> Let’s also check if flag.txt.enc</code> shows up in any logs, scripts or other files on the image. $ sudo grep -r flag.txt.enc ./mnt ./mnt/root/.ash_history:openssl aes256 -salt -in flag.txt -out flag.txt.enc -k unbreakablepassword1234567</code></pre> It looks like the openssl</code> command was used to encrypt the flag.txt</code> with a password of unbreakablepassword1234567</code>. The command we saw in /mnt/root/.ash_history</code> uses the openssl-enc</code></a> function of openssl</code> to encrypt the data. If we look through the man page, we’ll notice that openssl-enc</code> has an option for decryption. -e Encrypt the input data: this is the default. -d Decrypt the input data.</code></pre> Let’s try decrypting flag.txt.enc</code> with the password we found. $ openssl aes256 -d -salt -in flag.txt.enc -out flag.txt -k unbreakablepassword1234567 *** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better. bad decrypt 140027284948288:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:610:</code></pre> We got some warnings, but it looks like the command still output a decrypted file flag.txt</code>. Let’s see what it says. $ cat flag.txt picoCTF{h4un71ng_p457_5113beab}</code></pre> And there’s our flag. Don’t forget to unmount the image once you’re done! </blockquote> $ sudo umount ./mnt/</code></pre> PicoCTF 2022 - SideChannel Cameron Blankenbuehler — Sun, 29 May 2022 00:00:00 +0000 The name itself “SideChannel” seems to indicate a side-channel attack</a>, so we should keep that in mind going forward. To start, we’re given a short description. There’s something fishy about this PIN-code checker, can you figure out the PIN and get the flag? </blockquote> We’re then offered a download for a program called pin_checker</code>. Running the pin_checker</code> binary will give us the following output: $ ./pin_checker Please enter your 8-digit PIN code:</code></pre> Let’s try entering a PIN $ ./pin_checker Please enter your 8-digit PIN code: 00000000 8 Checking PIN... Access denied.</code></pre> Okay, so it looks like a classic PIN entry. The program will tell us if we’ve found the correct PIN. It also requires an 8-digit PIN as you might expect. Anything longer or shorter will give an error. For example: Short PIN $ ./pin_checker Please enter your 8-digit PIN code: 12345 5 Incorrect length.</code></pre> Long PIN $ ./pin_checker Please enter your 8-digit PIN code: 123456789 9 Incorrect length.</code></pre>Brute-force</a></h3> At this point, I decided to try a simple brute-force attack on the PIN, just to see if it was feasible, so I wrote a python script to do just that. 1# pins.py 2import sys 3from subprocess import Popen, PIPE 4 5pins = ("{:08}".format(x) for x in range(0, 99999999)) 6try: 7 for pin in pins: 8 proc = Popen(["./pin_checker"], stdout=PIPE, stdin=PIPE, stderr=PIPE) 9 stdout_data = proc.communicate(input=bytes(pin, 'utf-8'))[0] 10 stdout_string = str(stdout_data) 11 if 'granted' in stdout_string: 12 print("FOUND PIN! PIN: {}", pin) 13 break 14 print(f"PIN: {pin}, {str(stdout_data).strip()}") 15except KeyboardInterrupt: 16 print("Program interrupted.") 17 sys.exit(0)</code></pre> pin.py</code> output $ time python pins.py PIN: 00000000, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000001, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000002, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000003, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000004, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000005, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' ... PIN: 00000095, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000096, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000097, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000098, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' PIN: 00000099, b'Please enter your 8-digit PIN code:\n8\nChecking PIN...\nAccess denied.\n' real 0m12.780s user 0m12.311s sys 0m0.435s</code></pre> Unfortunately timing just the first 100 PINs, my system took over 12 seconds. Now let’s see how long we could expect a complete brute force attempt to take if we let the script run to completion for all 99,999,999 possible PINs. $ total time = \frac{99999999} {100} \times 12s = 11,999,999s = 199,999min = 3,333hrs $ This is, of course, assuming the time to check each PIN is consistent (we’ll find out shortly that’s not the case). Regardless, it’s safe to say brute forcing the PIN doesn’t look like a good path forward. Timing attack</a></h3> Okay, now that we’ve ruled out a brute-force attempt, let’s go back to the title of the challenge, SideChannel. Side-channel attacks are essentially observing a process and gleaning information from it based on timing, power consumption, or even sound. They can get very complicated, but in our case the only path that really makes sense for our program is a timing-based attack. So, let’s start by fuzzing pin_checker</code> with a few different PINs and monitoring the execution time to see where that gets us. Just to highlight a few things I’ll be using the following pipeline to clean up the output and just focus on the real elapsed time by the process. You can see an in depth breakdown of the pipeline</a> on explainshell.com</a>. Just know that we’re sending a PIN code (00000000</code> in this case) to ./pin_checker</code> and getting back the elapsed time in hours:minutes:seconds</code>. $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 00000000 | tail -n1 0:00.13</code></pre> Following are all the permutations of the first digit of the PIN while leaving the remaining digits as zero. $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 00000000 | tail -n1 0:00.12 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 10000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 20000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 30000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 40000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 50000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 60000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 70000000 | tail -n1 0:00.14 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 80000000 | tail -n1 0:00.13 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 90000000 | tail -n1 0:00.13</code></pre> If you look carefully, you’ll see that when we sent the PIN 40000000</code>, the elapsed time seemed to double. That’s certainly interesting. We know that pin_checker</code> must be checking the PIN code for a valid entry. Maybe it takes longer to verify the PIN when some of the digits are correct? Let’s keep going. Keeping the first digit as 4, lets check the second digit. $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 40000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 41000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 42000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 43000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 44000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 45000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 46000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 47000000 | tail -n1 0:00.25 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 48000000 | tail -n1 0:00.37 $ /usr/bin/time -f 2>&1 "\n%E" ./pin_checker <<< 49000000 | tail -n1 0:00.25</code></pre> We notice that the elapsed time has increased again when sending the PIN 48000000</code>. It hasn’t doubled this time, but it has markedly increased while the elapsed time for the others remained the same. I won’t go through each step here, but each digit can be deduced from the above process. After checking each digit for an increased elapsed time we can find the correct PIN. I’ll leave that up to the reader though =) Once you determine the correct PIN you can check it against pin_checker</code>. $ ./pin_checker <<< XXXXXXXX Please enter your 8-digit PIN code: 8 Checking PIN... Access granted. You may use your PIN to log into the master server.</code></pre>

OverTheWire - Leviathan

Language Transfer and The Thinking Method

OverTheWire - Bandit

HTB Apocalypse 2023 - Janken

Flag</a></h1>

We have our flag! `HTB{r0ck_p4p3R_5tr5tr_l0g1c_buG}</code></p>`

KitCTF 2022 - ein-pfund-mails

Flag</a></h1>
Here we have our flag! `KCTF{1f8e659e892f2b2a05a54b8448ccbff9}</code></p>`

Cryptoverse 2022 - Super Guesser

Flag</a></h1>
Et voilà, we have our flag! `cvctf{hashisnotguessy}</code></p>`

PicoCTF 2022 - Operation Orchid

PicoCTF 2022 - SideChannel

cblanken.dev - Blog

OverTheWire - Natas

cblanken.dev - Blog

OverTheWire - Natas

OverTheWire - Leviathan

Language Transfer and The Thinking Method

OverTheWire - Bandit

HTB Apocalypse 2023 - Janken

KitCTF 2022 - ein-pfund-mails

Cryptoverse 2022 - Super Guesser

PicoCTF 2022 - Operation Orchid

PicoCTF 2022 - SideChannel