Zero Day Defence 2014 is one of the few components in Singapore's National Infocomm Security Competition (NISEC). The task is to create a Web Application with the intention to secure it from malicious web attackers. Attendees started off with a day of training on Software Developmental Life Cycles (SDLC), followed by the development of the Web Application and finally finishing off with the Web Application Penetration Challenge.
From this point on, I would be sharing what my team and I went through, together with my personal comments, within the 3-day boot camp.
Day 1
The first day was supposedly secure code training and ethical hacking advisory. Instead, what we went through was an entire day how a proper software development cycle should be like. Competitors were taught on the different SDLC models, as well as how a developer should sieve out bugs in their software.
Quite frankly, I felt that this was not very important for the competition as you'll only have a day of coding to do. Most of us would be scrambling to get things up and running and have no time to get organised in an orderly manner.
With that being said, it is still a relevant framework that developers should follow while handling projects in the real world. Sticking by these rules and practices will make your work appear more systematic and controlled. Again, I would feel that this is probably not the best time to practice a new framework if time is against you.
Towards the end of the day after all the training were completed, we were finally given our task for the competition. Competitors were required to build an online e-commerce site, and certain requirements have to be met in order to be eligible to participate in the Web Application Penetration Challenge (Day 3).
The Web Application has to be able to do the following:
List the products available for purchase;
Implement client registration and login;
Implement a search function;
Implement batch registration by uploading a CSV file;
Implement a shopping cart; and many more...
Participants were allowed to install and configure any of the Web servers available/familiar to them. The operating system (OS) used in the server, however, was controlled and limited to the pre-installed Windows Server 2012.
Right after going through the requirements, my team (of 3 members) has set 2 persons to create the Web Application and one to set up the Host system itself (that's me!).
We decided that this was the best allocation as my forte was not in developing Web applications, while the other 2 has had experience in dealing with securing them. However, this should not mean that we do not communicate along the way. Communication is key while working on your objective because it is common to overlook certain aspects of the application/configuration. Thus, a timely reminder from your team members would help to restore your chain of thoughts.
Day 2
Continued from Day 1, we came back during the 2nd day to complete the Web Application in full speed. Configuring the server was not as easy as we had to work via Remote Desktop. The server itself has no internet connection. Therefore, the only way to install your own software was to download them onto your own laptop and transfer them via Shared folders (after you have set it up and have connected your laptop into the local network).
I've met with a lot of installation bugs and had to redo the entire installation twice due to many of the dependencies that some of the software had. (For example, when the software required a specific version of .NET framework and there is no Internet connection to the server)
We had the following software running for our setup:
MySQL Community Edition
Apache HTTPD Server
OpenSSL
PHP
Going back to the Web application, you may notice that a lot of the requirements were screaming possibilities of SQL Injection, Cross-Site Scripting (XSS), and Privilege of Escalation via other means such as using unsafe codes for the Batch Registration feature.
SQL Injection and XSS are easy to prevent but is often overlooked at certain elements of the page. While the other 2 were coding the various components of the Web Application, I went ahead to test what was done to ensure that we do not put up unsafe codes in the Web server.
To prevent SQL Injection and/or XSS attacks, you should always remember to sanitise the code. MySQL has a function for you to sanitise input and it is easy to implement it in your code.
Another important point that was not stated for the Web application we noted was that we could restrict certain features to different views of the Web App. For example, we have made it a point such that only registered users will be able to view the search bar to try to obscure the attack surface. It is unwise to leave every implemented feature in the main page right away for attackers to test them all out. However, obscurity is not security! It might deter them from trying certain attacks, but if your Web application is broken internally, it would not stop the possibility of an attack.
To ensure that our Web application was secure, I ran multiple vulnerability scanners on our server. Sure enough, there were a couple of places where we missed out sanitising on. It was promptly fixed and a rescan was performed.
In the end, we were quite satisfied with the level of security in the Web Application and we went ahead to submit the app.
Day 3
In the final day of the competition, only those teams that fulfilled the requirements will be able to participate in the final activity. Up until now, we have been developing the Web application with no specific attack range given to us. There is no way to edit your website at this point as our rights have been revoked. It all came down to how prepared our Web application was, and how insecure the other teams' Web application were.
Easiest: Defacement of Website
Normal: Obtaining the shop's customer information (Specifically the credit card details)
Hardest: Removal of the server's log files
The attacks above are subjected to whether the other teams' websites were secured enough. If everyone has covered their attack surfaces it is difficult to perform any of the attacks.
Out of the 3 main tasks, removal of the server's log files was the most difficult task and each team has a specific target host to conquer over. The team leaders had to randomly pick from a balloting box a piece of paper which contains the opponent team to target.
Removing a server's log files via the website itself was difficult, but one team managed to have such a vulnerability. (Unfortunately, it was not our target) The vulnerability came about in the Batch Registration feature, where I described it as reading values off a .CSV file to register a batch of users at one go.
What Went Wrong with the Team's Batch Registration Feature
To start off, this team's server was running Apache Tomcat and the page was JSP based. I knew that by meeting with a few error pages while probing the site.
Next, I went to the Batch Registration field and tried to send in my own crafted CSV file. I was greeted with an error which says that the file I submitted was not a valid CSV file. Not giving up here, I looked into the source and found that error was checked on the client-side.
Upon removing the little code that was supposed to validate my file, the site was quick to accept it and that was when another error came about. This time it revealed the relative directory of the site and from there it is easy to figure out where the logs were located.
Also, when you upload a file for this particular server, the file was saved in the webroot directory with the file named "uploaded<FILENAME>.<EXT>". This calls for trouble as now I can upload a .jsp file which could execute commands from the server side when I visit my uploaded JSP file.
What Vulnerability Most of the Other Teams' Web Application Had
The bulk of our score came from defacing the other teams' website with our flag through various XSS vulnerabilities in their website. Indeed, many teams kept up based on this vulnerability alone. Many of the sites were bound by this vulnerability in various of their text fields. Some of them might not be text fields but we still tried to inject our XSS code by editing our values directly in the HTTP GET/POST.
One other vulnerability exploited was SQL Injection, which was only available in very few servers. Using this vulnerability, one could eventually retrieve customers' information stored in the database.
The competition then came to an end and I have not stopped thinking about how one could take advantage of the vulnerabilities to do potentially more harmful stuff. The awareness of such threats should be spread to more Web users. End users should also be aware of potentially compromised websites and be able to make a decisive judgement on whether it is safe to continue browsing on the pages they are on.
Today, it has come to my mind on how further attacks could have been deployed for this challenge alone and I'm open for discussion of any other defence/attack in the following scenario described above.
Shared by Ang Ming Yi.
Comments