RootBabyKalmarCTF
Based on the docker-compose.yaml file, it is confirmed that the challenge is running 3 different containers called ctfd, db and scraper
The database container is rather simple, its credentials are stored inside the environment.
The scraper container is read-only but can write into the /tmp folder
The ctfd container is the only thing that we can directly interact with through localhost:8000, in its environment store the database credentials.
Nothing notable inside the db/Dockerfile
The flag is stored inside /flag.txt file inside the scaper container, the scraper user inside the container download something from the URL http://ctfd:8000/challenges and store it inside the /app/functf folder every 30 seconds, and it does not change session, the session is harcoded inside the command!
The ctfd container’s Dockerfile contains some interesting information. First is that the user running the container at the end is user 1001, the user has full privilege to the directories:
- /var/log/CTFd
- /var/CTFd
- /opt/CTFd
- /opt/venv
And another flag is stored inside the /flag-${random_suffix}.txt file, at the end of the Dockerfile, the container run the mysterious docker-entrypoint.sh file as the user 1001. We can access the container through localhost:8000
Register, login, create a new team and go to search team, we can see that there is a search bar, I tried inputting % and the name of my team was returned, this is an SQL injection vuln
Further testing show no results, even if I manage to get inside the db, it is not possible to get a flag inside another container.
My user_id is 2
So there must be another admin user, I look at the challenge description again and there is a pair of credentials for admin, I tried it and got into the admin account
BKICS - Secure Notes
The bot’s config allows the public website to make request to local untrusted server, big hint for OOB via XSS or such.
The application used EJS which is a template engine, in EJS, <%- %> means unescaped raw content, by grepping it in the codebase, we can see what appears to be a sink for our exploit:
The flag is served through an endpoint called /api/admin/data
The there is a HTML escape function inside the codebase but was not used on our sink, this confirm the vulnerability.
Very easy XSS pattern right here:
