A2:2021 | Crypto Basics (8) | Cycubix Docs
A big problem in all kinds of systems is the use of default configurations. E.g. default username/passwords in routers, default passwords for keystores, default unencrypted mode, etc.
Java cacerts
Did you ever changeit? Putting a password on the cacerts file has some implications. It is important when the trusted certificate authorities need to be protected and an unknown self signed certificate authority cannot be added too easily.
Protecting your id_rsa private key
Are you using an ssh key for GitHub and or other sites and are you leaving it unencrypted on your disk? Or even on your cloud drive? By default, the generation of an ssh key pair leaves the private key unencrypted. Which makes it easy to use and if stored in a place where only you can go, it offers sufficient protection. However, it is better to encrypt the key. When you want to use the key, you would have to provide the password again.
SSH username/password to your server
When you are getting a virtual server from some hosting provider, there are usually a lot of not so secure defaults. One of which is that ssh to the server runs on the default port 22 and allows username/password attempts. One of the first things you should do, is to change the configuration that you cannot ssh as user root, and you cannot ssh using username/password, but only with a valid and strong ssh key. If not, then you will notice continuous brute force attempts to login to your server.
Assignment
In this exercise you need to retrieve a secret that has accidentally been left inside a docker container image.
With this secret, you can decrypt the following message: U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=.
You can decrypt the message by logging in to the running container (docker exec …) and getting access to the password file located in /root. Then use the openssl command inside the container (for portability issues in openssl on Windows/Mac/Linux) You can find the secret in the following docker image, which you can start as:
With this secret, you can decrypt the following message: U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=.
You can decrypt the message by logging in to the running container (docker exec …) and getting access to the password file located in /root. Then use the openssl command inside the container (for portability issues in openssl on Windows/Mac/Linux) You can find the secret in the following docker image, which you can start as:
Solution
Hints: After starting the docker container enter the container using docker exec -ti dockerid /bin/bash. Try to gain access to /root. Try to become user root by su -. Try to change the /etc/shadow file using docker cp.
Find your container ID.
The output will tell you docker container ID.
Once you have the ID access your to WebGoat Shell.
Try to find a path to the password located in root.
You can see that the permission was denied.
Try to find which files are in the Root Directory instead.
And explore the files, looking for the file password. Output is detailed in image below.
Exit webgoat shell and copy the file passwd into your own system. The output should be" successfully copied into your windows.
Explore the file with passwords.
Check in the image above that root has the following password: 0:0, whilw WebGoat has 1000:1000 as password.
In order to change the password of WebGoat into the Root password, open the PowerShell and copy the following script:
Once you execute it, you will see the change in Webgoat's password.
To confirm that the execution is correct, execute the following commands on PowerShell:
Send the modified file to the original directory in Docker.
Access docker container again. You will see that we have access to the root directory.
Now we try to find the password and the name of the file that stores the password.
Also, if we copy the encrypted message into our Shell, and add at the end the file default_secret we will be able to decrypt the message.
Now go ahead and submit your answer to WebGoat.
Troubleshooting
Despite changing the
webgoat
user's UID and GID to0
in the/etc/passwd
file, you are still seeing the user aswebgoat
and not asroot
. This might indicate that the change was not applied correctly or there is some other issue.Your will need to Verify Changes in
/etc/passwd
.Open the Docker container shell and type:
If you receive the following output then the changes are made:
If you are still seeing webgoat under passwords 1000:1000, it is recommended to exit the shell, and restart the docker container shell:
Last updated