Skip to main content
Jan 14, 2016

Would You Like to Play an Application Security Game?

Why Are We Still Playing the Game?

It happened again. The recent disclosure of devastating security vulnerabilities associated with certain Juniper devices has renewed discussions about best practices to prevent hacking of critical applications and the importance of effective application security protection.

In this case, researchers found unauthorized code in the ScreenOS router operating system (CVE-2015-7755 and CVE-2015-7756). This rogue code permitted an attacker to perform nefarious operations that could potentially compromise data within the application.

War Games: Application Security Style

You may recall professor Stephen Falken, a fictional character in the popular 1983 film “War Games.” As Falken famously said in the movie, “This is your classic scenario.”

When presented with the impossible situation of finding a secret password to log in to the War Operation Plan Response (WOPR) supercomputer in the film, Matthew Broderick’s character, David Lightman, went to the library to perform deep research on the professor. After learning everything he could about his target, the login credentials became obvious.

That type of research may have worked in the movies, and social engineering still takes place today. However, today’s cybercriminals and attackers often need only look as far as your application’s binary code to locate vulnerabilities and critical information that your apps contain — and that’s exactly what happened in the Juniper device example above. The vulnerable string was readily available in the binary in plaintext. 

Hiding Application Credentials in Plain Sight

The clever move by the coder who implemented this backdoor involved hiding a password in plain sight, disguised among other debugging strings. The less clever move was to facilitate a direct call to a string comparison function that short-circuited logic of the login function. The disassembly of that function made the intention of the original code clear — a full backdoor password that enabled an SSH or telnet connection to a vulnerable device. This credential empowered superuser-level access to the ScreenOS interface, permitting a potential attacker to run arbitrary commands. Such an approach could eventually lead to hostile remote control and remote introspection of the data that these devices were installed to protect.

Enhancing Your Organization’s Application Security Game

Remember the facts: Any information on a device that isn’t protected can represent easy pickings for potential attackers. For example, any of the following can give an attacker a foothold to compromising your assets:

  • Usernames and other constants;
  • Debugging strings;
  • Class and function names;
  • Error messages;
  • Command line arguments and output format strings;
  • Cryptographic library calls; and
  • Standard library calls.

These assets are guideposts that enable reverse engineering and analysis of underlying code. From that point on, it becomes relatively simple for an attacker to exfiltrate data and comb your binary code for other vulnerabilities.

In the figure below, see how a small sequence of code can tell an attacker exactly how a password is validated in your code. This is the output of a disassembler, a tool that takes the machine code in an application and translates it to the instructions that it represents. In the ARM code below, the input password is being compared with a string comparison function to another value in the application binary. This is a simplified version of how an attacker may have found the backdoor password to ScreenOS.

What’s the Next Move?

Protection and information-hiding need to be taken to the next level in order to address persistent threats that are being developed against your software. Application hardening and cryptography are critical application security techniques to help mitigate attacks. Application hardening and runtime application self-protection are vital for defense against, detection of and reaction to attempted application compromises.

In fact, key security analysts like Gartner recommended the following: “Make application self-protection a new investment priority, ahead of perimeter and infrastructure protection,” because “modern security fails to test and protect all apps. …Apps must be capable of security self-testing, self-diagnostics and self-protection. It should be a CISO top priority.”

Organizations that harden their applications and leverage runtime protection divert attackers who are generally looking for lower-hanging fruit and more vulnerable targets. Your goal should be to force cybercriminals to understand that attacking your applications is likely to be a losing proposition for them so that they won’t want to play the game.

This blog was authored by: Aaron Lint, Director of Research, Arxan


Arxan Author

More from the Blog
May 27, 2020

Application Security: Testing is NOT Enough

In the software development world, developers are faced with a breakneck release schedule and tasked to produce applications ...
Read more
Apr 16, 2020

The Next Step in the Arxan Journey

As many of you may have seen, we just announced that w
Read more
Feb 24, 2020

Android Cracks and App Hacks – What Is StrandHogg?

StrandHogg is a critical v
Read more