Embark on a thrilling journey with us as we delve into the captivating realm of PicoCTF challenges. Whether you're taking your first steps or already a seasoned pro, our blog is your go-to guide for unraveling the mysteries of these puzzles.
Level 1
Digital Camouflage
Problem Statement: Our objective is crystal clear: breach into some routers. The path to victory? It lies within the enigmatic realm of captured network data - specifically, data.pcap
Solution
Upon initiating Wireshark and accessing the PCAP file, my first move was to systematically export all HTTP objects, aiming to dissect the ongoing requests within the captured network data.
Within the hex payload of the main.html file, a critical revelation surfaced in the form of a D.userid field, catching my attention and hinting at a potential breakthrough.
Subsequently, navigating through the HTTP stream associated with main.html, a pivotal POST request came into focus:
POST /pages/main.html HTTP/1.1
Referer: 10.0.0.1:8080/index.html
User-Agent: User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9*/*;q=0.8
Host: 10.0.0.1:8080
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
Accept-Language: en-US,en;q=0.5
userid=randled&pswrd=OFBGRW8wdHRIUQ%3D%3DHTTP/1.0 200 OK
Server: BaseHTTP/0.3 Python/2.7.9
Date: Sat, 19 Mar 2016 01:45:28 GMT
Content-type: text/html
The comprehensive details of this HTTP transaction included relevant headers, such as User-Agent and Accept, providing insights into the client-server communication.
The encoded password, pswrd=OFBGRW8wdHRIUQ%3D%3D, spotted in the payload, raised suspicion and hinted at a layer of Base64 encoding.
Further investigation confirmed that %3D decodes to \=, affirming the use of Base64 encoding. Armed with this knowledge, I proceeded to decode the password.
Flag: 8PFEo0ttHQ
Lazy Dev
Problem Statement: I really need to login to this website, but the developer hasn't implemented login yet. Can you help?
Solution
The website's login mechanism has a peculiar JavaScript file, client.js, where the password validation logic seems to be a work in progress:
//Validate the password. TBD!
function validate(pword){
//TODO: Implement me
return false;
}
//Make an ajax request to the server
function make_ajax_req(input){
var text_response;
var http_req = new XMLHttpRequest();
var params = "pword_valid=" + input.toString();
http_req.open("POST", "login", true);
http_req.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http_req.onreadystatechange = function() {//Call a function when the state changes.
if(http_req.readyState == 4 && http_req.status == 200) {
document.getElementById("res").innerHTML = http_req.responseText;
}
}
http_req.send(params);
}
//Called when the user submits the password
function process_password(){
var pword = document.getElementById("password").value;
var res = validate(pword);
var server_res = make_ajax_req(res);
}
The crucial line of interest is: var params = "pword_valid=" + input.toString();. This indicates that the website is sending a POST request to /login with the parameter pword_valid, and it seems to be based on the validation result.
By using Chrome devtools, the user discovered an XHR request being made on clicking the Submit button. They further inspected the cURL data and found the following:
curl 'http://shell2017.picoctf.com:35895/login' -H 'Pragma: no-cache' ... --data 'pword_valid=false' --compressed
Manipulating the request by changing pword_valid=false to pword_valid=true, the desired outcome was achieved, resulting in the obtained flag: client_side_is_the_dark_sidebde1f567656f8c9b654a1ec24e1ff889