This is a follow-up post about the web application from ISU NCDC 2014. My code for the application is located on my Github account here.
Below I’ve included a report I submitted during the competition about the vulnerabilities and mitigations in the application.
In addition, I have a response time chart for our web server. I just thought it was kind of interesting to see.
These were the average response times for an HTTP GET request over time. The Y-axis is in milliseconds. The graph starts at 8:00 AM (when the competition started) and goes to around 3:00 PM.
I tested this vulnerability on my development server and can confirm that our login form is SQL injectable. Using the proof of concept (POC), I was able to drop the users table. One way we could prevent this would be to escape the input parameter so that special characters are not interpreted as part of the SQL syntax. In addition, we could have prevented the webapp database user from being able to DROP the tables in the database, though this would be less effective and still would allow for data deletion by deleting rows in the tables.
Since the login form is not the only form that is injectable, we would have to audit each individual database query in order to fix all accounts. I would estimate this fix to take two full-time engineers a few days to fix.
Since no parameters were checked in the timesheet functions, it safe to assume that our app is vulnerable to this attack. However, I was unable to reproduce the issues using provided POCs. We did set the X-XSS-Protection: 1; mode=block id header setting in our Apache configuration, which may have helped to prevent some XSS vulnerabilities.
It seems there is some information about escaping the output of user input here.
There are less unchecked params than unescaped SQL queries, so I would estimate the mitigation for this would take one or two days for one full-time engineer.
We noticed this issue in the application early on and were able to mitigate by hashing (w/ salt) our passwords before inputting them into the database. We did this by using the SHA() MySQL command. We also noticed that sensitive information such as the social security numbers of our employees was in the database. We were not able to mitigate this due to time, however MySQL has data encrypt and decrypt functions that could potentially facilitate this task.
To implement the MySQL functions and encrypt data in storage, it would not take very long to do. I would estimate that one full-time engineer could implement this functionality in one day.
We were not able to mitigate this issue. The debug code seemed fairly complex and obfuscated. To mitigate this one would need to trace the debug code and check it for “malware”.
In order to fix this issue, it would require removing the offending code. It would take a day to unravel the code, a day to patch/remove the code, and potentially another day to replace the code with its proper functionality.
We did not mitigate this code. We did notice these lines, however, we forgot to fix it. We did make sure that the the app runs as the web-data user (Apache) and that sticky bits were not set during the deploy scripts.
It could potentially take a full-time engineer less than one day to fix this and implement it properly.
We fixed this issue by implementing session management in our application. For reference we used this cheat sheet: Session Management Cheat Sheet
The session gets properly set in the user’s browser and has the HttpOnly and Secure options added to prevent tampering and hijack attempts.
We were unaware of this vulnerability and were unable to mitigate.
The POC would not work because we migrated our app to an entirely new OS.
To mitigate this issue it would require removing the offending code and two full-time engineers one or two days to patch it.
Some of the functions the app are vulnerable to would be most of the string functions. Since many times string functions use the \0 (null) character to terminate, it can be easy to miss this character or accidentally truncate it. This could potentially end up with a string of undefined length. The functions reach into memory until it finds a null character. Some of the string functions could be: sprintf, strcmp, strdup, etc. There are a class of ‘n’ string functions allow for specification of length which could prevent these issues.
We were unable to mitigate these issues, however, in almost all Linux OSs, memory not allocated to the application can not be read.
There were many string functions in this app and would require a few engineers multiple days to fix and verify the issues.
Since my team placed 3rd in the Fall, we qualified for ISU’s National Cyber Defense Competition this Spring. This was a slightly different competition than the ones I have competed in before, mainly because the scenario was slightly different this time around. It was unique for a few reasons: unusual applications and services were required, plentiful competition-day anomalies, and an additional service that was added to the scenario less than a day before the competition started. There were a lot of flags to protect, and to be captured.The scenario essentially stated that we were a SaaS company that provided hosting and application programming services. We were required to implement the following services: DNS for our domain, a highly-vulnerable custom web application that contained sensitive company data, a chat service of our choosing, remote desktop, method for backups, a Nagios monitoring service, and a “beta” Python application that was given to us just before the competition. For added benefit, we also introduced a gateway firewall, Active Directory server, and Splunk monitoring. This was a challenging, but also exciting and rewarding, scenario. My two main responsibilities were securing the web application and implementing the Splunk system.
The web application was very insecure mainly because it was written in ANSI C, had numerous OWASP Top 10 vulnerabilities, and multiple malicious backdoors. I will most likely have a separate write up just for that application because I would like my main focus here to be on the overview of the competition and what we could have done better. In addition to securing the web application, I was tasked with monitoring our network using Splunk, which is an operational intelligence platform. I used this software to gain insight into our network and to make sense of the data our systems were generating. It was very useful because the whole team could log in and use Splunk’s web interface to search and parse log files and look at metrics relating to their assigned services. It was really neat to see visualizations of what was happening to our services and network. Below I’ve included some graphs and results we received from Splunk throughout the day.
I participated in the Fall 2013 ISU Cyber Defense Competition. This event was an invaluable experience that greatly added to my professional career. This report outlines my experience as it goes through what I learned and what I could have done better for the competition. This report will help me to reflect on the competition and improve my techniques for next time.
As a computer engineering major, the CDC greatly benefited me. I developed on a technical level and a professional level. The CDC always offers a great challenge and allows me to solve real world problems. I think the CDC really is a unique experience. It let me gain skills that will increase my employability and open many career opportunities. The CDC taught me many security principles that, as a computer engineer, will be very useful in the increasingly internet-connected world that we live in.
The CDC complements my career path very well. When designing computer systems and software systems in the modern world, it is imperative that the designs take into account the security of the system. Since I will be designing computer networks and software systems, my real world experience will greatly assist with these tasks.
I have learned many things in my internships and on my own that helped me succeed at the CDC. At my internships I have learned secure coding practices and system design practices that allowed me to create a secure and reliable network. I learned to securely write web applications at one of my internships. This helped me audit the code from the web server that we were given for the competition. I have learned several things from my previous CDCs that also helped me prepare for this CDC. This assisted in my ability to predict how the red team would attempt attacks on our network. I taught myself how to use Linux, which was very helpful in using our network.
The CDC had as real as a scenario that you could possibly have. It demonstrated real world situations that a security professional would encounter. Networks aren’t always designed properly, attackers target your networks regularly, and anomalies are thrown at you at a moment’s notice. The time constraints are realistic because you could have to come in and secure a network in a very short amount of time, all while attacks are impending.
One of the vulnerabilities we encountered was that we had repeated failed logins possible on our web application. This allowed red team to attempt brute force attacks against our login forms. If I had more time to fix the application, I would have added a feature that prevented repeated login failures. We could have blocked the user after several failed logins. This would prevent them from automatically attempting passwords. This vulnerability would be a software design flaw.
One of the green team anomalies we encountered was to take certain users and give them administrative access rights. This posed an issue for our team: either give the users administrative rights or forfeit the points for the anomaly. We ended up not doing the anomaly because we assumed red team already compromised the users and the ramifications would have been detrimental. If an end user had made the request, more discussion would be typically be had to consider the request. Another anomaly we received was to add an FTP service to one of our servers. Users had to be able to FTP to our shell server and upload and download files to it. This was a fairly simple task so we decided to implement it. If a single end user requested this service, it would most likely be denied in the real world. Since it is not a secure protocol, it poses a security risk to the company.
The CDC was an overall fun and excellent learning experience. I always enjoy the atmosphere. I had a chance to talk to some of the sponsoring companies and they were very impressed by my technical and leadership abilities. I think my team performed very well. We worked very hard and the work paid off: we placed third, so we will be able to compete in the National ISU CDC in the spring.
I took a screenshot of a graph of our log data sent to Splunk over time after the competition was over:
I have also attached one of my team’s intrusion reports that received full credit during the competition. ISU CDC 2013 – Team 14 Intrusion Report 4:00PM
Ethics are a very important part of engineering. The reason it is so important is because engineers make technology that has never existed before. They push technology to a point that has never been reached in history. Because of these constant unprecedented situations, engineers need to have a solid sense of ethics. They need to have a code of ethics that can guide them through their careers where they may have to make difficult decisions about the technology that they encounter.
In our small group ethics discussion, we studied the Space Shuttle Columbia. We analyzed the ethical dilemma that NASA faced in its development of the Columbia. The reason the Space Shuttle Columbia tragedy occurred was because of something called “safety waivers”. Safety waivers are essentially a known safety problem or specification deviation. Some members of our group argued that these risks are just a part of the job. They argued that the astronauts knew what they were getting themselves into. I agreed that there is always some risk involved with something like space travel. However, I didn’t agree that the issue was as simple as that. The study we read discussed a concept about determining the risk of the safety waivers. I think that the threshold for acceptable risk was too low for the Columbia. The article didn’t discuss what NASA could have been done better, but my group decided that there should be more accountability and inspection of the waivers. We thought that multiple people should have to sign off on these exceptions to the rules.
The three Virtues of Ethics that relate most to the Space Shuttle Columbia incident are integrity, charity, and responsibility. Integrity is essentially a moral compass. NASA engineers needed to have integrity because they had to make tough ethical decisions for the safety waivers. Charity played a major part too. The NASA engineers gave their lives for the betterment of mankind. NASA as a whole gives a lot to the world. Finally, the responsibility that the engineers at NASA have is very large. Each and every engineer that worked on the shuttle had the responsibility of making sure their components were well tested and safe. If something was wrong then they were responsible for communicating their concerns up the chain. The other virtues aren’t necessarily irrelevant; these virtues were just the most relevant. As far as I could tell, there weren’t issues pertaining to fidelity or self-discipline in the case study. Realistically, though, all of the virtues probably came in to play in the events that we discussed. One additional virtue that might have been relevant to this case study may have been prudence. It’s defined as being thoughtful of the future. This would be important because NASA does things every day that will affect the future.
In situations where I have to make an ethical decision, there are a few different things I take in to account. To start, I try to consider any and all factors that might affect the outcome of the situation. This is important because one small thing can affect the outcome in a very large. This was the case in the study we discussed at our small group meeting. One small defect in the shuttle caused a devastating tragedy. I also consider who the decision affects, specifically who it benefits as well as affects negatively. This point of view is helpful because I’m no longer taking into account just the performance or cost benefits, but also the affects it might have on others. Another thing I do when making ethical decisions is identify whether it is an issue purely of good versus evil or rather a more difficult issue of the lesser of two evils. The latter could be a much more difficult decision to make and therefore could require more research and thought.