Fiicen - A lesson on how not to secure your webapp

A few days ago, a Twitter account (no elon i wont be calling it that) touting a new social network targeted to the Japanese market claiming “no censorship” and “freedom from foreign media giants” called Fiicen was launched. I observed one of its posts gain quite some notoriety amongst the Japanese twitter community.

The founder, a supposed Japanese Grade 11 high school student claimed that he had originally created this network for a friend group, but wanted to open it up to the world. This piqued the interest of me and some of my friends interest, and we decided to check it out for ourselves.

A not-so-great start

From a brief look at the website, it became more and more apparent that the developer of Fiicen was not very experienced in basic app security practices. For starters, the API endpoint for creating a new account had absolutely no protection, not even basic measures such as reCaptcha, which meant that botting the creation of accounts was extremely easy. In fact, there were already quite a few spambots on the website by the time we got to it. This further got our interest, and we decided to see what other weakpoints the website had.

Part 1: The stack

A quick look at some of the pages of the website showed more developer incompetence. All of the JS used in the page was not minified or obfuscated at all, and the error pages showed things like “set DEBUG to True”, which raised the question of what framework this site was running on. A quick look at Wappalyzer showed that Fiicen was powered by none other than; Django.

Wappalyzer

While this Python based web framework surely would have made for an easy developer experience, the longevity of running a social media network on Python was what I would consider highly questionable.

Part 2: The vulnerabilities

Just like the signup process, the whole platform was very much completely unprotected and was wide open for manipulation. To our absolute amazement, Fiicen allowed its users to not only post images to the site, but also post videos as well. This, along with the completely unprotected nature of the site was what we considered a huge vulnerability, as this meant that spamming uploads and possibly spiking the bill of whatever cloud storage service Fiicen used was rendered trivial. In fact, the only thing that was protecting Fiicen from total bombardment was Cloudflare’s 100MB upload limit on the Free plan. (Of course, Fiicen had not implemented chunked uploads)

Part 3: The hunt begins

Now knowing exactly how incompetent the development of Fiicen seemed to be, I started to think that this site definitely had a critical security vulnerability hidden somewhere. So, I decided to put my amateur pentesting skills to the test and see what weaknesses I could find. Firstly, out of my own curiosity more than anything else, I wanted to know exactly what kind of server Fiicen was using to host itself. However the website, like most websites today was protected behind Cloudflare, which obfuscated the origin IP address of the server. This was going to be a difficult nut to crack… or so I thought.

Part 3.5: Cloudflare isn’t as secure as I thought it was.

Before this, I thought that any website that was hosted behind Cloudflare and did not have any exposed subdomains would be rendered impossible to find the origin IP of the actual server. However, after a quick Google search 🔍 find real ip behind Cloudflare I was led to https://shodan.io/ , a supposed “search engine of the internet of everything”. After simply putting in the domain I wanted to crack, in this case https://fiicen.jp/ , Shodan immediately gave me the actual IP address of the server hosting Fiicen; A server located in Chiba prefecture, with the ASN of BIGLOBE, a prolific Japanese ISP.

Turns out that while Cloudflare is good at securing a website and you should definetly consider using it, it isn’t the end-all-be-all of security, and you shouldn’t rely solely on that to protect your projects from cybercrime.

Part 4: Bingo

Now since I was sure that this IP was of the server hosting Fiicen, and not some network node as this was such a small-scale operation, I decided to try one of the most simple attack vectors; Attempt to SSH into the server and see what happened. So I opened my terminal, inputted ssh root@ip and pressed enter. What followed shocked me.

Not only was the SSH daemon wide open for anyone to pole around at, but the root account for some reason allowed password authentication, which is a monumentally bad idea for a public facing IP as anyone with a password cracker could easily brute force the authentication and gain full access to Fiicen’s systems.

While I did not attempt to bruteforce the password myself, I did attempt to login multiple times to see if the server had a security layer behind the SSH daemon, such as fail2ban. After multiple failed login attempts and my IP not being banned, I concluded that there was no such protection.

I had hit the jackpot. This was an extremely dangerous security vulnerability that I had come accross. What should I do?

Part 5: Resolution

While this was quite an interesting thing I had come across, I decided that I should not try to venture any further into this. I had to tell the developer.

I decided to shoot him a DM on twitter telling him about my discoveries. I also added some advice about ways to improve; specifically disabling SSH password authentication and implementing reCaptcha. To his credit, He did respond very quickly saying he would fix the issues and thanked me for my service. As of May 22, Fiicen is not accepting new sign-ups citing they want to “make the platform more spam-proof”

Conclusion

So what did we learn today?

Always protect public-facing UI from spam. It will always happen.
While services such as Cloudflare provide excellent security features, they shouldn’t be a replacement for basic security practices.
NEVER enable SSH password authentication on public facing IPs.

Keep these at heart when developing your new webapp. If in doubt, ask around and let others check what you may have missed.

I would like to add at the end; while I did say multiple times that the developer was “incompetent”, I think it would be nicer to say that he lacked the experience and knowledge. I don’t despise him because of this, not at all. I always find these kinds of personal pet projects to be interesting, and I hope he can make something good out of Fiicen in the future.

End

Thank you for reading until the end :) If you found this article interesting consider sharing it around, and spread the word!