CMD + CTRL - InstaFriends
The CMD+CTRL Cyber Range suite features intentionally vulnerable applications and web sites that tempt players to steal money, find out their boss’s salary, purchase costly items for free, and conduct other nefarious acts.
March 20 - March 24 2019
CMD + CTRL & March Hackness 2019 CTFs
This was my first on-site CTF, hosted by the Toronto chapter of OWASP. It was two sites from the Security Innovation cyber range: Instafriends – a social networking site, and Shadowbank, a banking website.
On the night of the OWASP Toronto meeting I focussed on the Instafriends site and only took a poke at the Shadowbank in the last 5 minutes or so, although I wish I’d spent more time there. It looked fun!
As it happened, Security Innovation’s March Hackness happened to be running over the following weekend, so I had more time to play with the Instafriends site (sadly, the Shadowbank wasn’t part of this event).
These vulnerable sites are part of an active commercial cyber-range, and they request that participants not post public write-ups. I don’t see any other write-ups out there, so until they retire this scenario, I’ll keep the walk-through write-up to myself. It is, however, worth noting some lessons I learned in the process of working on the challenges.
I spent most of the first half of Saturday (and probably too much of the Wednesday evening event) just looking around at the website and gathering as much information as possible about the site layout and how information for the social network functionality was being stored. Thorough recon lets you ask important questions like: What is the intended purpose of this area, feature, or data? If there’s a “public” feature, does that imply that there’s a “private” one? What’s the difference between an error saying something that is “not found” and something that’s “forbidden”?
Although, I didn’t gain much from InstaFriends by checking each page’s source HTML, it is always a good starting place. Programmer comments, even when they are not commenting out a bit of bad code or a vulnerable feature (or a CTF flag or hint), can give you an idea of how the page and site are laid out. This also gave me a good sense of where else I could exploit each vulnerability as I found them. Again and again, I found myself asking…hey, if I can do that here, can I do the same thing over there?
For all that I had success with intercepting and manipulating HTTP requests using Burp, I realise that I need to delve deeper into HTTP request headers and the behaviours and vulnerabilities of different request types and header parameters. I think there was a lot more that I could have taken advantage of there, and some additional manipulation could have made the difference between success and failure in exploiting possible vulnerabilities. The HTTP request data was certainly useful, but don’t underestimate the importance of just keeping an eye on the URL in the address bar as you move from page to page and take different actions.
I also thought I had a decent handle on the basics of SQL injection, but I think that all but the most rudimentary injections were being filtered in a way that prevented me from getting the information or effects that I expected. I need to learn more about alternate formatting and encoding of SQL queries to circumvent this.
One area that I didn’t have any real experience with, and therefore failed to get really interested results from, was XSS. I can get an alert popup, which was fine, but nothing more. I think there was more that could have been done with XSS, and perhaps that’s how I could have gotten around the SQLi filtering.
And the other area that I got nowhere near to exploiting was looking for vulnerabilities in the services that showed up in my reconnaissance and initial testing. It’s all well and good to identify a service and to find a CVE for it, but exploiting the vulnerability in that CVE is a whole other story. I’m not sure, yet, if I’m just going about searching for more details wrongly, or if this is all there is and one is expected to start writing their own exploit. If so, that is still a bit ahead of my curve right now. I did start to poke around with Metsaploit, to very little effect, and I definitely need more experience with that before I can use it reliably or effectively. Indeed, I had much more success with simpler tools that I know better.
With all of the user-uploaded images in a social networking site, I don’t think I’m letting the cat out of the bag by saying that I attempted to exploit a file upload vulnerability. That said, I didn’t have any luck getting my crafted or modified files accepted. Maybe they were looking for the magic bytes that identify my asserted file type, or maybe I just didn’t try all of the possible upload opportunities…and on that note, don’t assume that just because one form field or upload opportunity doesn’t work that all of the fields and uploads across the whole site won’t work. It only takes one typo or forgotten precaution to cause the site’s safety nets to fail in that one case.
I’ve been getting a better appreciation for what goes into more complex cookies, and I need to learn more about common formats and encryption types for cookies. In plenty of places I saw no ID references to indicate which user was doing what with the fields I was trying to change, and I can only assume that the session cookie is the source of that information. Reverse engineering a cookie might have been key to successfully exploiting more vulnerabilities.
FINAL RESULTS
Wednesday evening (3 hours):
Instafriends – 13/55 challenges solved for 975 points
Shadowbank – 1/48 challenges solved for 150 points
Rank 36/80
Weekend:
Instafriends – 38/55 challenges solved for 3590 points
Rank 10/139 - My first top 10 finish!