Michael W. Norris

Michael W. Norris

An archetypal computer nerd with an added pinch of personality.

HackerOne CTF Write-up: Micro-CMS v1

5 minute read

The challenge titled “Micro-CMS v1” is rated as easy difficulty and contains four flags. The challenge provides an introduction to an insecure indexing vulnerability, an (extremely) basic example of SQL injection, and a demonstration of two cross-site scripting vulnerabilities. This challenge helps to drive the point home that submitted forms are not the only user-modifiable fields that can pass data to a server.

h1

Home Page

At the start of the challenge, the home page contains three clicable links. The “Testing” link and the “Markdown Test” link direct the user to /page/1 and /page/2, respectively. The “Create a new page” link directs the user to /page/create. The home page is shown in the image below.

home_page

Flag 0

Flag 0 is obtained through an insecure indexing vulnerability that can be discovered through the “Create a new page” functionality of the challenge home page. After following the “Create a new page” link, a new page can be created that shows up alongside the “Testing” page (located at /page/1) and the “Markdown Test” page (located at /page/2) on the home page.

After the first new page has been created, the newly created page is located at /page/7 instead of the more logical location of /page/3.

new_page

Because of this, it can be inferred that pages 3 through 6 may already exist on the webserver, but that they are not accessible in the same manner (e.g. by following a link) as pages 1 and 2.

Manually browsing to page indices 3, 4, and 6 return “Not Found” errors while index 5 (/page/5) returns a “Forbidden” error. This “Forbidden” error suggests that page 5 exists, but that the user does not have permission to access the file via /page/5.

Using the newly created page 7 as an example, following the “Edit this page” link directs the user to /page/edit/7. This suggests an alternative method of viewing the contents of any indexed page.

edit_page

Manually browsing to /page/edit/5 reveals Flag 0.

^FLAG^e853fb6a<redacted>$FLAG$

Flag 1

Flag 1 is obtained after attempting SQL injection via a URL. The importance of this flag is the idea that data can be sent to a server in a variety of (sometimes unintended/unexpected) ways.

Using the “Edit this page” functionality present in the web application as an example, an application developer expects (and hopefully has prepared for) a wide variety of user input being passed to the web server through this form. Since the web developer knows that a user can place any text/characters here that they want, the developer has (once again, hopefully) implemented input sanitization on the contents passed to the web server through this form.

In this case, Flag 1 cannot be triggered through the “Edit this page” form. Perhaps, however, the web application developer has failed to consider that the “Edit this page” form is not the only place that needs its input sanitized.

Browsing to /page/edit/1' (or /page/edit/anything_else', for that matter) triggers Flag 1. The ' character used to trigger the flag could cause a SQL error under normal circumstances.

^FLAG^b0538bc7<redacted>$FLAG$

Flag 2

Flag 2 is obtained after triggering a cross-site scripting vulnerability. The concepts described earlier regarding input sanitization remain true for Flag 2 as the developer of the web application failed to consider all attack vectors.

After following the “Create a new page” link from the web application’s home page or after following the “Edit this page” link after browsing to any created and viewable page, it can be seen that the developer of the website boldly states:

Markdown is supported, but scripts are not

Simply put, script tags can be used in cross-site scripting attacks to execute arbitrary commands and display arbitrary content in a victim’s browser.

The devloper’s assertion is true when it comes to script tags that are included in the main input field of the “Create Page” or the “Edit Page” web pages. Entering <script>alert('XSS')</script> into the main input field of the “Create Page” web page or any “Edit Page” web page results in the <script> and </script> tags being filtered out.

scrub

If the script tags were not filtered out and a victim were to visit the newly created page, the JavaScript alert function would execute causing an alert window with the characters “XSS” to be displayed in the victim’s browser.

Another place where user input is dispalyed on the website is on the home page. Text that is included in the “Title” field located on the “Create Page” and the “Edit Page” web pages is displayed on the home page of the website. This means that if the contents of the “Title” field are not sanitized, then cross-site scripting can be achieved.

xss_1

Flag 2 is displayed in the alert pop up upon visiting the home page.

^FLAG^2068a9d8<redacted>$FLAG$

I know you can see the full flag in the GIF, but whatever…

Flag 3

Flag 3 is obtained through another cross-site scripting vulnerability. This time, the vulnerability is a bit more difficult to find. Flag 3 once again exemplifies the importance of considering the wide variety of ways in which information (and code) can be sent from a browser (client) to a server.

For the previous flag, cross-site scripting was achieved through the classic script tag method which executes JavaScript in the victim’s browser. For Flag 3, the onclick event can be used to achieve this same goal.

Similar to the the way that script tags were used to execute the alert JavaScript function for Flag 2, the onclick event can be used to execute JavaScript when a button (or an image) on a web page is clicked.

The “Markdown Test” page located at /page/2 contains the “Some button” button. Clicking the button does nothing.

some_button

From this page, following the “Edit this page” link directs to the page with the Markdown and HTML contents shown in the image below:

edit_button

Changing <button>Some button</button> to <button onclick=alert('XSS')>Some button</button>, saving the changes, and clicking the “Some button” button will result in a popup with the characters “XSS” being displayed within the browser.

onclick

Viewing the page source reveals Flag 3 in the HTML button tag.

html_flag

^FLAG^58de1483<redacted>$FLAG$

This flag can be achieved in the same manner by including <img src='whatever' onclick=alert('XSS')> in the main input field while creating or editing a page, saving the changes, and clicking on the image.

You may also enjoy

Exploiting CVE-2020-9047 (ICSA-20-170-01)

  21 minute read

On April 9, 2020, I discovered and reported the vulnerability in the exacqVision Web Service that has since been designated CVE-2020-9047 (ICSA-20-170-01) to the Johnson Controls Product Security team. The vulnerability was publicly disclosed by Johnson Controls on June 18, 2020. This vulnerability also affects exac...

HackerOne CTF Write-up: A little something to get you started

  less than 1 minute read

The HackerOne CTF challenge “A little something to get you started” could not get much easier. Given its difficulty rating of “Trivial” I suppose this should come as no surprise. Nonetheless, the challenge introduces the importance of the powerful “View Page Source” option built into browsers.

HTB Write-up: Craft

  15 minute read

Craft is a medium-difficulty Linux system. To reach the user.txt flag, a variety of small hurdles must be overcome. The majority of this process involves getting to the bottom of what’s up with the beer-themed Craft API. It seems that one of the developers had a few too many craft IPAs before pushing some sloppy cha...

SLAE32 0x07: Custom Crypter

  6 minute read

In this post, a crypter program will be created and demonstrated that uses the Advanced Encryption Standard encryption specification, also known as AES. The AES standard is part of the block cipher family. It is also important to note that AES is a symmetric-key algorithm which means that the same key is used for en...