Of all the conferences I’ve been to, Securi-Tay has always been a favourite. I don’t know whether it’s the mix of security professionals and students, the relaxed atmosphere, or the balance between technical and non-technical talks, but it’s always a great time. For those of you that aren’t familiar with it, Securi-Tay is a student organised and lead conference, held annually by the Abertay Ethical Hacking Society at the University of Abertay, Dundee. This year’s event, held on January 15th (last week, at time of writing), marked the third instance of the conference.
I spoke at Securi-Tay last year (video), before I joined Portcullis, on the security threats posed by common office and datacenter devices such as photocopiers, printers, and UPSs. This year I decided to tackle a much more foreboding and monolithic topic: cryptography. I feel that one of the major obstacles to learning about cryptography is the stigma around it – it is often seen as obscenely complex, studied only by mathematicians with foot-long beards and a slew of three-letter acronyms trailing their surnames, detailing their accomplishments. Another obstacle is the lack of reputable, high quality, entry-level education in the subject outside of university courses and paid workshops. This aspect has improved somewhat, especially with the introduction of free online courses like Stanford’s, but free materials are certainly nowhere near the breadth and ubiquity we come to expect in other areas of security education. As such, I felt that I should do my part in rectifying this.
My talk, entitled “Breaking crypto without breaking your brain”, aimed to give people a basic understanding of the common types of cryptography that I see in practical use as part of my day job, without needing an advanced degree in mathematics. In contrast to many introductions to the topic, I skipped the classic ciphers such as the Caesar cipher, simple alphabetic transposition and substitution ciphers, and other algorithms of that ilk, as I rarely find knowledge of them useful in the context of real security assessments. Instead, I focused upon one-time pads, modern stream and block ciphers, padding, block cipher modes, and demonstrated how seemingly strong encryption can often be broken trivially.
The talk was recorded and should be available on YouTube within the next few weeks, via the AbertayHackers YouTube account. In the meantime, you can download the slides and both demo applications:
- Slides - Breaking crypto without breaking your brain
- Demo 1 - OTP key re-use
- Demo 2 - ECB block-cipher mode weakness
Aside from my own, there were a number of very good quality talks from both industry professionals and students. I thought it would be nice to write a short description of each that I saw, with some take-away points for each talk.
Olly Whitehouse – “Real world threat modelling”
This talk covered a range of topics around the concept of assessing a black-box appliance, with a view to building a threat model. Olly proposed that by building a threat model, pentesters can obtain greater coverage of targets during tests, primarily by answering simple questions that help us understand the system. He highlighted the need to understand underlying technologies, especially the operating system, in order to minimise the risk of missing key issues. Finally, he went on to discuss ways of building threat models, visualising them, and utilising feedback from security tests to improve upon existing models.
Three take-away points:
- Go for the simplest attacks to reach your goal – elabourate and sexy tricks aren’t important
- Threat modelling can help both pentesters and the organisations that hire them
- Threat model discussions with security engineers, developers, and other technical staff can lead to real improvements in security posture
Panagiotis Gkatziroulis – “Physical attacks: Walking past the egg shell perimeter”
This talk gave a broad overview of the technological, structural, procedural, and human challenges that are involved in physical security. First, a range of security measures were discussed that fall into the building design and security technology category, including entry choke points, placement of receptionists and guards, use of CCTV cameras and electronic doors, as well as the training of the personnel involved. Panagiotis noted that reception staff are often not trained to act as security guards, despite the fact that fooling them may get you the “keys to the kingdom”. He went on to discuss four avenues of exploitation when dealing with human opponents: misrepresentation, obligation, authority, and emergency. Five key reasons why humans fail to act were proposed: a sense of obligation to business goals (not wanting to hinder productivity), employees feeling that they aren’t targets, anxiety of punishment if they mistakenly report something, a lack of confidence in challenging people, and a belief that security is someone else’s problem.
Three take-away points:
- Physical security is meaningless if humans can be subverted into giving you access
- Often a lack of proactive security – changes are reactive, after the damage is done
- Once you get a pass from reception, you win. These people should be trained in security procedures
Oren Benshabat – “DNS distress”
Oren’s talk focused on the problems of DNS cache poisoning and DNS amplification attacks from the ground up, explaining the subject in detail. He began with cache poisoning – an attack that tricks a system into accepting a spoofed DNS response. He described bailiwick checking, a series of checks designed to enforce correct responses, and how this process can be subverted by flooding the target with reply packets containing different query IDs until one is accepted. He went on to cover Dan Kaminsky’s BIND attack, which spoofs an entire domain rather than just one hostname, by spoofing the nameserver of a domain to point at an authoritative DNS server under the attacker’s control. He proposed several fixes, including BIND patches, randomised source ports, DNSSEC, and pinning of nameserver IP addresses. He went on to discuss DNS amplification DoS attacks, which involve tricking open DNS servers into sending large reply packets to a target system. A range of DNS features that increase response packet size were discussed, including EDNS0, DNSSEC, as well as proprietary and custom DNS extensions. Finally, countermeasures such as IP source validation (mainly at the ISP level) and restriction of open recursion were suggested, with the caveat that there is no bullet-proof solution against DNS amplification attacks at the current time.
Three take-away points:
- There are multiple ways in which DNS can be abused, even when properly configured
- Some DNS security features (e.g. DNSSEC) help to fix one problem but also contribute to other problems
- There is no current practical solution to DNS amplification attacks
Dom Cashley – “Security in SCADA”
SCADA is a topic that I am personally interested in, but have very little knowledge of. As such, I was very happy to see someone approaching the subject at an entry level. Dom started the talk by explaining the traditional SCADA network design, including Human-Machine Interface, Master Terminal Unit, and Remote Terminal Unit devices, and how they are usually deployed in production facilities. Whilst the original design was focused on an air-gapped network, Dom noted that many modern SCADA devices are in fact no longer air-gapped, and are commonly available from the internet for remote access purposes. He went on to explain how off-the-shelf hardware was often used to network these devices and link them to IP networks, making an attacker’s job easier. Additional security issues were also noted, such as a lack of security training for engineers that are deploying equipment, general purpose computing platforms being used in field devices (including BYOD-style policies), and “SCADA in the cloud” management systems. Dom noted several problems with patching and updates, including long-standing hardware life spans, a reluctance to take down critical devices for patching, and use of old insecure protocols. A demo was also shown, using a special demo board and an exploit that causes the MTU to alter pump motor parameters without alerting the HMI user.
Three take-away points:
- SCADA is usually controlled by software on regular PCs, often running Windows
- Patching bugs is paradoxically problematic due to the critical nature of systems
- Systems are often not air-gapped and regularly appear on the internet, and may be found on SHODAN
Paco Hope & Ritesh Sinha – “The Colour of your box: The art and science of security testing”
Along with Paco, Ritesh, and the usual exuberance we’ve come to expect, the stage was occupied with two rollercoasters built from k’nex, wrapped almost entirely in large cardboard boxes, exposing only the starting and finishing sections of track. These contraptions formed a metaphor for the core concept of their talk: black-box vs. white-box testing. A toy car was placed into each, which could be heard traversing the track, but the car did not appear at the other side. Two teams were invited from the audience to diagnose the fault, each given access to one rollercoaster each. This was described as the black-box test, where only inputs and outputs could be seen, functionality could be deduced, and some vision of the internal technologies was available. Each team reported that the system utilised k’nex, was meant to take a car in one side and send it through to the other, but did not work.
The teams were then allowed to open flaps on the sides of the boxes to see inside, and propose one single fix that would solve the problem – essentially a white-box test. The “one issue” restriction was designed to emulate a true penetration test, where the customer receives a report and cannot be guaranteed to fix anything but the highlighted issues. Paco noted that reports needed to be clear, concise, and free of unnecessary technical jargon, stating that far too many reports end up reading somewhere along the lines of “bla bla bla owned you bla bla bla root shell bla bla bla Cross-site Scripting bla bla bla disaster!”. Now that the Teams had access to the internals, both began identifying potential problems with the design, and tried to come to a conclusion on what should be fixed. After some pointers from the presenters, the solution was eventually found: a piece was blocking the passage of the car and needed to be moved.
The conclusion given was that both black-box and white-box approaches are necessary, as they both promote different types of thinking and analysis. Black-box tests tend to focus on the external attack surface that most attackers would see, whereas white-box tests tend to focus more on implementation details that may lead to potential issues. By combining the two methods, the presenters propose that a strong coverage of the target can be obtained.
Three take-away points:
- Black-box makes you focus on external attack surface, white-box makes you focus on implementation details
- Reports need to be clear, concise, and explain the full spectrum of problems in order to facilitate improvements
- Combining both types of testing helps increase coverage during assessments
The conclusion of Paco and Ritesh’s talk marked the end of the conference day, after which we all congregated in the student union bar for after-party drinks. I’d like to issue personal thanks to all involved with organising and running the conference, including all the speakers and sponsors.
As I noted above, all talks were recorded and should hopefully be available on YouTube within the next few weeks.