Share this
The Evolving Arms Race of IT Security Countermeasures
by Reflare Research Team on Mar 3, 2023 5:25:00 PM
The attack technique appears to circumvent so-called ASLR protection mechanisms by triaging the exact memory location of a running process from differences in function response times.
First Published 16th February 2017 | Latest Refresh 3rd March 2023
Ask yourself - who really benefits from the arms race?
4 min read | Reflare Research Team
Dutch security research team VUSec released information on an attack technique which appears capable of circumventing so-called ASLR protection mechanisms by triaging the exact memory location of a running process from differences in function response times. This makes for a good example to explore the constant arms race between offensive and defensive technologies.
Defining hack and countermeasures
The term hack has countless definitions, and many of our previous briefings have looked closely at some of them. For the purposes of this briefing, a hack will be anything allowing the attacker to do things with a system that the systems designer did not intend them to do.
There are many ways to do unintended things on a system. Probably the best-known approach is to steal or guess passwords for users with more permissions and abuse them. Other approaches include installing malware, calling undocumented APIs, triggering unintended behaviour in programs, and last but not least, using a crash to rewrite the code of an application completely.
The last class of vulnerabilities - so-called memory corruption vulnerabilities - are extremely common in binary software. The battle to prevent attackers from abusing them has likewise been going on for a long time and makes for a good example of how attacks and countermeasures evolve.
A brief history of memory corruption in common terms
In 1996, a hacker by the handle Aleph One popularised the idea that certain programming mistakes could be abused to trick the vulnerable application into running arbitrary code. His attacks depended on two things: Knowing where exactly in memory the application was located and being able to run data as code.
As the technique became more widely abused, two countermeasures were developed.
The first approach was to change the memory location of an application each time it was started so attackers wouldn’t be able to guess it (ASLR). Attackers quickly realised that while most memory locations can be randomised, those of some critical features can not. Also in applications that restarted automatically, the correct address could simply be guessed with enough tries. Thus new attacks such as Return-To-Library and NOP-Sledding were deployed.
Another approach was to make sure that data and code were strictly separated and that data could thus not be executed (NX). This requires hardware and software support and breaks some legacy applications. At the same time, some of the techniques developed to combat ASLR were able to circumvent NX as well.
The next step for the defence was the use of so-called Canary values to detect if an attack had occurred. Attackers countered by either guessing the Canary value through data leaks or circumventing the mechanism altogether (SEH).
The introduction of 64-bit processors made guessing attacks virtually impossible and thus significantly strengthened ASLR and Canary protection mechanisms. Newer CPU generations introduced more and more sophisticated NX mechanisms at the same time. Attacks circumventing the need to provide code in the first place (ROP) were developed to counter them.
The new attack mentioned at the beginning of this briefing is yet another technique to counter current generation ASLR protections. If it finds widespread adaptation, it will undoubtedly lead to another defence mechanism being deployed against it.
The cycle of offensive and defensive technologies continues.
Summary
IT security is an ongoing and never-ending arms race between attacks and preventive measures. While the technical details of these measures lie in the realm of research, it is essential for every organisation to understand that there is no final word in security.
Any existing safeguard will eventually be circumvented, and every attack will be countered in one way or another. Maintaining security standards means constantly updating and improving infrastructure, training, and policy.
If someone offers you a “one-shot solution” that will “make your network secure for good”, you can always safely conclude that you are dealing with snake oil.
Share this
- December 2024 (1)
- November 2024 (1)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- April 2024 (2)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)
- November 2023 (1)
- October 2023 (1)
- September 2023 (1)
- August 2023 (1)
- July 2023 (1)
- June 2023 (2)
- May 2023 (2)
- April 2023 (3)
- March 2023 (4)
- February 2023 (3)
- January 2023 (5)
- December 2022 (1)
- November 2022 (2)
- October 2022 (1)
- September 2022 (11)
- August 2022 (5)
- July 2022 (1)
- May 2022 (3)
- April 2022 (1)
- February 2022 (4)
- January 2022 (3)
- December 2021 (2)
- November 2021 (3)
- October 2021 (2)
- September 2021 (1)
- August 2021 (1)
- June 2021 (1)
- May 2021 (14)
- February 2021 (1)
- October 2020 (1)
- September 2020 (1)
- July 2020 (1)
- June 2020 (1)
- May 2020 (1)
- April 2020 (2)
- March 2020 (1)
- February 2020 (1)
- January 2020 (3)
- December 2019 (1)
- November 2019 (2)
- October 2019 (3)
- September 2019 (5)
- August 2019 (2)
- July 2019 (3)
- June 2019 (3)
- May 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (3)
- January 2019 (1)
- December 2018 (3)
- November 2018 (5)
- October 2018 (4)
- September 2018 (3)
- August 2018 (3)
- July 2018 (4)
- June 2018 (4)
- May 2018 (2)
- April 2018 (4)
- March 2018 (5)
- February 2018 (3)
- January 2018 (3)
- December 2017 (2)
- November 2017 (4)
- October 2017 (3)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (4)
- May 2017 (4)
- April 2017 (2)
- March 2017 (4)
- February 2017 (2)
- January 2017 (1)
- December 2016 (1)
- November 2016 (4)
- October 2016 (2)
- September 2016 (4)
- August 2016 (5)
- July 2016 (3)
- June 2016 (5)
- May 2016 (3)
- April 2016 (4)
- March 2016 (5)
- February 2016 (4)