Upcoming Webinar:
Key Steps to Improving Your Cyber Resilience
May 26, 1PM - 2PM EDT
Event Starts In: 0 DAY, 16 HRS, 27 MINS
Upcoming Webinar:
Guardium Tech Talk: Optimize DB2 for z/OS Data Collection
May 26, 8AM - 9AM EDT
Event Starts In: 0 DAY, 11 HRS, 27 MINS
Application security is serious business and requires constant improvement on behalf of security professionals and developers. All of the key players must be ready to play the application security game — otherwise, attackers will win by default.

iStock

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.

The vulnerable string of code in this Juniper example was readily available in the binary in plain text.

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.

Download the 2016 state of application security report from IBM Partner Arxan

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.

This image shows an example of how reverse engineering tools can give insight into the workings of a piece of software, putting your systems at risk.

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.

Beat Them at Their Own Game

To learn more about how IBM and Arxan can help your organization, watch the “Enhance Mobile Security Protection with Arxan Application Protection for IBM Solutions” video:

Topics: , ,

Related Content