Skip to main content

How I enumerated flags of all the problems in CTFLearn | Part 1

What is CTFLearn?

CTFLearn is a jeopardy-style CTF where points are received after solving the problems and gaining the flag. The player with highest number of points is on top of the leader-board. However, unlike other CTFs where a party makes the question and players solve it, CTFLearn allows you to post your own questions too.

 

What was the vulnerability?

The edit functionality in the application allows the problem creator to edit the problem. If an user tries to edit a problem that he doesn't own then he will be redirected to the view problem functionality. However, in the redirection HTTP response, the body of edit problem functionality is thrown. Hence, the edit problem functionality discloses the flag when accessed by user who didn't create the problem. I will go into details of this on the upcoming parts. This was an information disclosure vulnerability caused due to broken access control.

 

What was the impact?

 The flag was being disclosed which means that the players could get flags without solving problems. This impacted highly in platform confidentiality.

 

How to exploit the vulnerability by yourself?

 1. Login to CTFLearn



 2. Note the problem id of a problem



 

4.  Replace the problem_id parameter in the following URL to the problem_id you noted in Step 2: https://CTFLEARN_V1_URL/view/index.php?action=show_edit&problem_id=1

5. Open the URL you created at Step 4 in a web browser, intercept the request in Burp Suite and send it to repeater

 



 

 6. Find the request in repeater tab and send it. Do not follow redirection.

7. Find the flag in HTTP Response:



 

Conclusion

I reported this vulnerability and it has already been patched. However, you can clone the old version by visiting LukeLaScala's Github repository on this link and try to exploit this vulnerability by yourself.

 

 


 

 

 
 

 

Comments

Popular posts from this blog

Mysterious Javascript Code Found Infecting Hundreds of Websites

  After installing Wappalyzer in my browser, I decided to test its functionality by visiting a familiar website. To my surprise, I was unexpectedly redirected to a spear phishing campaign. Knowing the website's usual practices, it seemed highly unlikely that they would intentionally redirect their visitors in such a manner. Intrigued by this anomaly, I took it upon myself to investigate the underlying cause of this redirection.   I have not yet known how threat actors implanted the Javascript Code in the victim's application but this is what it looked like.         What does the code do?   The code is simply importing script from biggerfun[.]org domain. In other words, it's simply doing <script src="biggerfun[.]org"></script> Further investigation I wanted to check if others think the website is bad, so I looked into it more. I observed they do things similar to another group called TA569. You can learn more about TA569 here: ...

Getting unlimited money by abusing the 'Send Money' feature

      It has been a while since I published a post. So, I am writing this one to share one of my interesting finding while testing an e-wallet application.     I glanced at my Total Balance and I was wondering if there was a way for me to increase it arbitrarily. So, I thought Race Condition would help me here.  What is a Race Condition vulnerability? "A race condition vulnerability typically occurs when your application has access to the same shared data and attempts to change variables within it simultaneously ." - automox.com So, I loaded up Turbo Intruder in Burp Suite and attempted testing it. I failed. I couldn't exploit it.  I didn't want to give up this soon. I kept that fire bottled up and changed my approach. I realized that the 'Send Money' feature uses basic maths to reduce balance from the sender's account and add it to the receiver's account. So, the feature did the following operations:   function sendMoney(sender, receiver, amoun...

Prevent account takeover with proper cookie configuration

    In this blog, I am writing about how improperly configured cookie may lead to account takeover. The type of account takeover I'm writing about is only possible when you're in the same local network as victim. Before explaining the issue, I want to thank Veshraj Ghimire for reviewing this.   Misconfiguration #1:  Not using 'secure' flag while setting cookies What is 'secure' flag? The secure flag is a setting that can be specified when a cookie is created and sent from a web server to a client browser. When a cookie is marked with the secure flag, the client browser will only transmit the cookie back to the server over a secure HTTPS connection. If the secure flag is not set, the cookie will be sent over both secure and insecure connections, making it vulnerable to eavesdropping and tampering by malicious actors.   Misconfiguration #2:  Cookie scoped to all the subdomains     What do I mean by "cookie scoped to all the subdomains"? If yo...