Introduction
In this 50-point web challenge, we are given this simple statement and a link:
Space System for Research and Fun! Come and visit your favorite planet ;)
Upon visiting the link provided, we encounter a straightforward form with an input field, a Visit! button, and an image of our beloved Rick and Morty.
Solution
By conducting some small tests, it's possible to figure out how the website operates. If we input a valid URL (e.g., example.com), we observe that the website reloads with a somewhat peculiar text.
The resulting text is nothing more than the source code of the entered page encoded in base64 and with a font named 'wubbalubba'.
<html>
<head>
<title>RickyMuertin</title>
<style>
@font-face {
font-family:'wubbalubba';
src: url('ANGERTH.ttf') format('truetype');
}
input[type="text"] {
width:70%;
}
#container {
width:80%;
padding:20px;
margin:40px;
background-color:#fff;
}
body {
background-color:#BF6BFF;
}
</style>
</head>
<body>
<center>
<div id='container'>
<h1>RickyMuertin</h1><br><br>
<div style="font-family:'wubbalubba';width:60%;border:1px solid black;padding:10px 10px;word-wrap:break-word;">
<!-- CÓDIGO FUENTE DE LA PÁGINA DEL FORMULARIO CODIFICADO EN BASE64 -->
</div>
</div>
</center>
</body>
</html>
To view the clear result, you simply need to open the page's source code and decode the content of the div:
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
div {
width: 600px;
margin: 5em auto;
padding: 50px;
background-color: #fff;
border-radius: 1em;
}
a:link, a:visited {
color: #38488f;
text-decoration: none;
}
@media (max-width: 700px) {
body {
background-color: #fff;
}
div {
width: auto;
margin: 0 auto;
border-radius: 0;
padding: 1em;
}
}
a:link, a:visited {
color: #38488f;
text-decoration: none;
}
@media (max-width: 700px) {
body {
background-color: #fff;
}
div {
width: auto;
margin: 0 auto;
border-radius: 0;
padding: 1em;
}
}
</style>
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is established to be used for illustrative examples in documents. You may use this
domain in examples without prior coordination or asking for permission.</p>
<p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
Looking More further and deep dive
Understanding how the web works, let's find out more information that can guide us on how to solve this challenge.
The first step is to check if a robots.txt file exists. In this case, its content is:
Disallow: /.bash_history
This indicates that there may be a file named .bash_history, which, as we know, contains the user's recent commands.
ls
ls -la
clear
lftp -e 'put /home/morty/flag_1.txt;put /home/morty/muertin.php.bckp; bye' -u rick,8===D localhost
curl localhost:8080/muertin.php
rm -rf /
exit
In the content, we can identify several relevant lines:
The fourth line, lftp -e 'put /home/morty/flag_1.txt;put /home/morty/muertin.php.bckp; bye' -u rick,8===D localhost, indicates the possible existence of two files, flag_1.txt and muertin.php.bckp, on a local ftp server.
The fifth line, curl localhost:8080/muertin.php, suggests the possible existence of another file, muertin.php, on a local web server.
Knowing all that we have discovered, the next step is to check if these files can be accessed normally. As it turns out, the server's port 8080 is closed, so we cannot access muertin.php. Additionally, the ftp server is also not open, at least not on the port typically used for it.
Therefore, we can assume that these two servers (web and ftp) are configured to be accessed only from within the server and not from outside.
Finally, it seems quite suspicious that one of these files is named flag_1.txt. I don't know about you, but at this point, it raises a lot of red flags for me
First Attempt
Summing up, we know that we can retrieve the content of an address by entering it into the web form. Additionally, there is a highly suspicious file on an internal web server.
Therefore, it seems likely that if we input the address of the file (file:///home/morty/flag_1.txt) into the web form, it will return its content:
Well, Ricky, it seems we've ended up on the wrong portal!
Clearly, this is not the result we were expecting. It looks like the website is preventing us from attempting to access a file.
After conducting a series of tests, we can see that the service blocks any address with the file:// scheme. So, we need to think of another way to access this file because, remember, our instincts are tingling.
Give it a Second try
Second and perhaps definitive attempt
What other way do we have to access the file? Remember, there is a web server and an FTP server.
Since we have the username and password for the local FTP server, let's give that a shot; it seems more promising.
So, we try the FTP address for the file: ftp://rick:8===D@localhost/flag_1.txt
Morty, if you mess up again, we're done for!
It seems that this time won't be the charm either. Testing as before, we can observe that the ftp:// scheme is not the issue.
If we keep experimenting, we notice that the filter is applied when the entered address contains localhost.
The question now is, how can we input a local address without using localhost? This is where IPv6 comes to the rescue. As we know, in IPv4, the internal address of a system is localhost. In IPv6, fortunately, there is also an internal address, but it looks different: [::].
With this in mind, let's try the following address: ftp://rick:8===D@[::]/flag_1.txt
This looks promising...
Let's go back to the source code of the website, decode the base64, and voilà, there's the flag:
nn7ed{g00d_j0b_but_pr1nc3ss_1s_1n_an0th3r_c4stl3!}
Conclusion
What we've encountered here is a type of vulnerability called SSRF (Server-Side Request Forgery), where we trick the server hosting the statement's webpage into returning the base64-encoded content of a file from a local ftp server on the same machine.