CTF Challenges

Introduction

This page is a collection of different challenges broken down into different categories. A lot of these are pretty simple, but hopefully at least a little bit interesting! My primary goals in putting these together were:

  • Be non-destructive - I wanted stuff that I could just leave up without needing to dynamically spin up and down infrastructure. As such I want to avoid situations where people get shells and can break the flow for others. This also helps with keeping the costs low enough to just keep running.
  • Be instructive - There is an amazing amount of really, really good technical content out there if your primary goal is to learn how to exploit specific vulnerabilities. My main thing in teaching people about how to do good assessments is that they need to worry less about specific vulnerabilities and more about how the application they are testing works and how they can break that. A lot of these are more geared towards needing to understand how to do something, more than out to break something.
  • Be accessible - I work with a lot of really junior people in security - a lot of people who are extremely smart and eager to learn but are often intimidated by the scope of work that is out there. In almost all cases once people get a bit of confidence in them that they can actually do things they tend to blossom into amazing information security professionals. A lot of times doing public CTFs can be a tad demoralizing so nothing here is really that complicated. If you are really experienced you might find this too easy but hopefully they are at least fun!

Challenges

💡
You do not need to do extensive fuzzing - in some cases you might need to do some automated requests and it will be mentioned in the description of the challenge.

Regex

URL: http://c.pratikamin.com/regex/

This one starts off pretty easy, the focus of this challenge is figuring out how to read regular expressions. The entire endpoint is running FastAPI - so you can probably figure out how to get documentation. Your goal is to figure how how to call the API with the correct inputs.

With modern applications you really should be identifying cases where an application is not using some sort of regular expression to validate input. In cases where a service just accepts anything from a user it opens the door to a lot of problems. On the other hand if you have an app that forces all input to be alphanumeric strings it really limits what an attacker can do

Data Formats

URL: http://c.pratikamin.com/input1/

The focus of this challenge is going through the inputs provided and passing in input in the correct format. There is a some nested inputs that need to be in specific formats - but the service should give you information for what each of these should be.

When testing modern applications there are going to be situations where you are passing in different types of data formats - which require you to take steps to properly massage your inputs. Its not unusual for a client to provide you with some very opaque instructions for how to make a request and you need to figure out how to get it to work. Since applications are written by real people with real problems there is no shortage of extremely weird types of input you will need to be able to perform.

Iteration(Sandwhich Maker)

URLs to find my favorite sandwhich items:

  • http://c.pratikamin.com/sandwich/bread
  • http://c.pratikamin.com/sandwich/filling
  • http://c.pratikamin.com/sandwich/topping

URLs to tell me what my favorite topping is: http://c.pratikamin.com/sandwich/{bread}/{filling}/{topping}

The goal here is to take the values the first three APIs and use them to make a request to the last endpoint . There is a correct combination but what is it? You will probably need to break out a tool that will let you iterate through a bunch of values

Codec

This challenge has two URLs:

  • http://c.pratikamin.com/jwt/generate
  • http://c.pratikamin.com/jwt/return (POST)

The first API will return a value back to you as well as some information you will need to massage the data back into a format that you can send to the second API. You will likely need to put together a small script to do the steps. Don't be afraid to do so!

AWS Lex - ChatBot

URL:https://lex-web-ui-codebuilddeploy-u3ei8b8o5-webappbucket-1f8f21fwd1upu.s3.us-east-1.amazonaws.com/index.html

The link above will take you to a new page where you can talk to an AWS Lex (v1) bot that has a secret.

There is a flag that is accessible through talking to this chat bot - you gotta just figure out what it wants to know. There are no malicious payloads or anything like that you need to send the bot. The last step of this puzzle requires you to be able to see the request that was sent by the service - you can do this via tools such as Burp Collaborator or CanaryTokens

AWS Cognito - Register

Cognito is one of the most interesting services at AWS for me, mostly because it was extremely confusing for no good reason. I often see people testing services that use Cognito without really understanding what is going on. This challenge is pretty straight forward - using the following information make an authenticated call to the API!"

Make an authenticated call to http://c.pratikamin.com/cognito/secure using a user from the following user pool:

  • User Pool ID: us-east-1_ENc5QHg0A
  • Client ID: 34mb9hkpi736ucv9259g03s8f