In this challenge we faced up a login form that we bypass in order to get the flag. It use a NoSQL database so no SQL injection this time. If we try to login we get always the same message that inform us the user doesn't exists. But if we input a username with spaces in it an error is provided:
BSD licensed, advanced key-value store returned an error: -ERR wrong number of arguments for 'get' command
What this mean? Googling the error we discovered the query we submit is processed by Redis (http://redis.io/). With Redis for submit more than a query you havte to use the CRLF chars. W tryed this: http://22.214.171.124:5000/?action=login&username=asd%0d%0ainfo&password=asd
and a message popped out saying the SHA-1 of the database don't match the SHA-1 of the password we supplied. So now we know that the script match the output of the query with our password hashed with SHA-1. Now a problem: how do we return a custom SHA-1 hash? The function SCRIPT LOAD help us. Infact the ECHO, PUBLISH, etc where denied so we cannot use them. As the documentation said SCRIPT LOAD return the SHA-1 of the code it loads, so just put a LUA code like this: 'print (11)' in username field with SCRIPT LOAD and in password field put the code so 'print (11)'. Final query is:
http://126.96.36.199:5000/?action=login&username=j%0d%0a%0d%0a script load print(11)&password=print(11)
P.S: since the output didn't showed up submitting a second query we must to submit a 3rd one.
This task was really easy, 100 points gifted I would say. Basically it was a pcap file where inside there are multiple request from HTTP to SSH and DNS requests. Filtering all HTTP requests a file "rootkit.zip" file showed up. We tryed to extract it but a password was required. So analyzing further the requests applying a filter like : "ip.addr eq 10.142.0.1 and ip.addr eq 10.142.0.3) and (udp.port eq 31337 and udp.port eq 4242" one interesting stream came up:
If you look after the "6unzip" string it follow a word: "a" , then in the line after another one "l" and so on. Late you'll find out that is the password to extract the zip. The password is "alongpassword1234" just open the archive with this to cat the flag.
The challenge is a site with SSL support for both mobile version and the computer one. There is a registration form where once you logged in you can set a device to attach and put on your "secret". Obviously the target was to log in as admin or in somehow get his secret. The challenge provide an Andriod application (SecureSpaceAuth.apk). After installing it and testing a bit I managed to see what HTTP request it was doing by pointing the DNS of the site's challenge site to my webserver. With a logger a saw two insteresting one:
The first one attache a new device given the username and the password and the second one complete the auth process. After testing a bit I got that device parameter where vulnerable by SQL injection and also the error report that its running within an update query. So basically with this SQL we can set us as admin:
But first we have to create the new device:
and then authenticate us
The important thing to keep in mind is that we have to do all this stesp using a crafted UuserAgent simulating an Android system because this request will be accepted only from mobile device because this queries is coded by running under this circumstances.
Now just log in with your account and get the admin secret.
The challenge was made by 3 auth levels where the aim is bypass them through SQLi and the annonying thing of this challenge is that no feedback is provided about your query so you have to guess the most common mistake till you find the right one..
The first one is as easy as tricky beacuse it was a OR injection but the strings are included within double-quotes and not with singles quotes so a classic ' OR '1'='1 won't work. Use instead " OR "1"="1. Now that you have bypassed auth1 you have also to pickup the right password of "admin1" user blindly. In this case a regular BSQLi with substr() + ascii() will work.
Now that you have the password for auth1 we can move on auth2. This time the things getting a little bit harder but still remain an easy chall. The hardest part was to understand that we are playing with a LIKE query with almost everything filterd but with LIKE statemant we can make it true by using wildcards as %, this will match every char. So the POST query would be like this:
But same as in auth1 we have to find the password of auth2. How? I coded a script to do this: http://pastebin.com/UPDwMFDw.
Last auth, finally! In this auth some feedback has been provided so it was very easy to solve infact you have two password to input (apart those about auth1,auth2) and must be equal else an error will pop up. If we input a random password we'll see error like ..query failed : password3.1 password3.2 means both have failed but if we input: ' or '1'='1 we'll see error like ..query failed : password3.2 means password3.1 has been executed correctly. So basically our true/false condition on BSQLi is based on the presence of "password3.1" error. An equal code for get the password as the previous one is this: http://pastebin.com/gQvQy1c0
Now just log in and get the flag.
The challenge gave us this link:
Inside this you find the download link of the requested file and the chiper used to encrypt it and other fields. At first glance the vulnerability could be a LFI or a SQLi but looking further through the download link:
you can see the path where the file is. So now as you may guessed the vulnerability was HTTP indexing basically. Infact you can browse the directories easly and after that I found and interesting file uploader.earth.tasks.ufoctf.ru/secret_uploads/f6140944d4fa3976ef04f81792d2c88562872a2d/Mr.LOL_earth.documents.zip
Now there is another problem: the aes-cbc-256 encryption of the text. Inside every directory there is a file called ._secret where inside this you can find the key to decrypt the content of the file. So now its a cake:
openssl enc -d -aes-256-cbc -in Mr.LOL_earth.documents.zip -out a.zip
Now just unzip and open the image to see flag...
When I went to the challenge page the script complained about missing parameters (user and password missing xml parameter). So we tryed adding ?xml=<login><user>YmxhaA==</user><password>YmxhaA==</password><login> (user and password must be base64 encoded) and an authetication error came out. After some testing a Xpath injection has been revealed in password parameter(may be also in user, didn't test it). No chance to get the password with concatenating the queries so we must go blind. This is the script I used to extract flag:
The //User/ReportURL field was taken in /users.xml~ file (when you logged in successfully an HTML comment inform you about its existance).
This trivia wanted that our input hashed with an "unkown" method must starts this string:"1000000". Also the first chars of our hashed input is provided, for example the hash of 123 is "4f68465". Detecting the hash algorithm was extremely easy, infact we can check all the hasing methods supported with hash_algos() and see who with input "123" return "4f68465":
The returned "salsa20". Knowing this we can now just set up a bruteforce script to catch wich string starts with "1000000":
The number was 460825513.
The site give us an image uploader where you can add your photos (only JPG images is accepted) in a gallery(one per team). The vulnerability was very easy to exploit: when you upload the image the script take its comment (if doesnt exist it dies with a error) and insert it into a SQL Lite database.
So just download exiv2 and run:
$exiv2 -c "' union select password from pictures-- -" index4
Then upload it and get flag.
In this challenge we have to connect to the server but instead using TCP as transport protocol the server used SCTP. So after connecting to it a wierd output has been provided. You could easly understand that was the flag but every chars has changed his position getting the flag shuffled. Analyzing the traffic with tshark I saw that the chars' original position was taken by the SID of their data chunk, for example:
-- DATA CHUNK --
This means that char N was at 5th place in the original string. Filtering the SID with tshark is easy:
tshark -R "sctp" -Tfields -e "sctp.data_sid"
Running this while you ar connecting to the server will give you the SID that tshark has obtained. Now we have the SIDs and their corrisponding value (server's output) now just reconstruct the string with this little perl script:
Another challenge from SIGINT CTF. The organizers give to us the sourecode of this little CMS where, after a registration, you can create a message that only you and the admin can see. The aim of this one was to login as admin and read his secret (flag). After login with mine account I see that 3 cookies has been created: login_time, login_token and login_name. Well, login_time is as self-explanatory as login_name but login_token isn't. This is a piece of code that may help you to understand how it is generated:
So login_token take the the time has seed. In login_token function we see another variable initialized that is password_data. As you may understand its a file (source/data/users/<user>/password_hash) containing a string: $2a$13$ntsVS46ekclCQRIO45a1oOgpZy6asmxAfP0ko3d8G4H1LsGVcEQ0O
This one is from admin user that concatenated with the salt(login_time) and SHA256'd gives the login_token. So generating one that fit to admin is extremely easy. Just took the good login_time from your cookies after logged in with your account and put it in this piece of code:
login_token = Digest::SHA256.hexdigest(password_data+salt)
and it will give you the login_token. Now replace it with the older one setting login_name as admin and you'll be him.