Over the weekend, I improved my l33t h4ck3r sk1llz considerably, by attending the Cyber Defence Exercise (CDX) 2018, at the University of Glasgow, organised by members of the Glasgow University Tech Society (GUTS).
CDX is essentially a cyber warfare simulation in the style of a hackathon. There are three groups of hackers that take part:
- Red (bad hackers): malicious hackers from the industry and/or skilled committee members in cyber security that attempt to hack into and bring down your servers.
- Grey (neutral hackers): committee members that run the IT helpdesk and are there to answer any questions you may have (without helping you too much).
- Blue (good hackers): participants that try and patch any vulnerabilities across the servers to make them secure as possible, before coding ends, so that the red team have a really tricky time getting past the security. Participants within the blues split up into different teams, with a maximum of 5 members.
There was a brilliant and fleshed-out story to this year’s CDX, which entailed every team within the blue hackers being an individual country within a fictional world, which was about to be attacked by a black-hat hacker group.
The blues all had the responsibility of defending 3 of their own country’s servers which were: the nuclear power reactor control interface, the stock exchange, and the president’s server. All of these servers had major security vulnerabilities from the get go, that had to be patched as effectively as possible.
There were plenty other easter-eggs and little blips to the plot, like social engineering happening on Twitter, there being a major cyber security conference happening during the hackathon, cryptography and hardware challenges, and many other things.
Process for Defence
Since this was my first CDX, along with the majority of my team members, we didn’t have a particular plan in process for securing the servers to the best of our ability. We started with server 1, then moved to the other servers as we got the hang of what we were doing.
The servers increased in difficulty as they moved along in terms of vulnerabilities, therefore starting with server 1 took a long time. We didn’t end up moving to start work on the other servers until well over half of our time was up.
To find vulnerabilities, we enlisted in several different strategies. For one, we manually looked through all the directories and files that looked off or were important i.e. system config files. There were various lines commented out in these files that were required to protect against spoofing attacks, port forwarding, and other vulnerabilities. There were also root kits present and other generally dodgy things in some of the files.
Nmap was a very effective tool in helping us to identify and fix network vulnerabilities. There were backdoors to the servers that were found using this tool, and we also identified version numbers of processes running on certain ports. Some processes had majorly outdated versions of software backing them and therefore needed a lot of patches/updates to protect effectively, for example, Samba.
There were a lot of easy to guess passwords that gave access to pretty serious things, such as ‘password’ being the password for admin access to the nuclear power control interface. This goes back to the root cause, of having passwords that aren’t easy to guess or crack. The best way to do this is using a random password generator.
Apart from that, when we were SSH-ing, we were told that we should be using keys instead of passwords as a whole to access the servers, so that there would be no need for passwords. We didn’t follow this advice, and this probably generally lead to our ultimate defeat.
There was also a way on some of the servers to access confidential data through the website interface, via backing through directories, SQL injections, looking at debug reports, etc. These should all be things that are protected against to the best of your ability.
Vim also was the default or “selected editor” on the majority on the servers. This is most likely because it is possible to drop into a shell from Vim, relatively easily. Make sure you protect against this sufficiently, as we did.
There were a lot of confidential information such as employee records and nuclear launch codes stored in some of the servers that were not sufficiently secured. If if it absolutely necessary for you to have files like this on a server, it would be a good idea to encrypt them to the best of your ability.
After all was said and done, we sat and wait, constantly checking IPs that were accessing each of the 3 servers that were allocated to us to protect, and kicking unrecognised IPs off the system as they were coming in. We actually ended up getting an honorable mention at the end of the event for doing this, as we were the only team that did!
At the end of the day, even though we got brutally destroyed along with our servers, the event was one of the best hackathons that I have ever attended, if not the best. It made for a fun packed and intense learning experience, surrounded by some of the leading people in the industry, and students that could possibly be defending the country one day after all!
Hackathons are a fantastic environment to meet skilled people within the industry, make friends and learn new things. Quite frankly, I’ve learned far more from this weekend than any cyber security book or course that I’ve put myself through so far.
I’ve put up highlights of my (slightly ridiculous) stories on Instagram up over the weekend following the link here, and GUTS have now also released their photos from the event, available via this link. There is also usually a CDX after-video, which I can imagine will take some time to be released, but it will definitely best sum up the experience as a whole for anybody that wasn’t there, so is worth the watch.
If you have a strong interest in security, make sure to not miss out on CDX 2019, as I’ve heard that the events get better and better each year!