From dubious theories to ‘alternative truths’, disinformation is more present than ever. To be frank, I find that trend rather scary.

Paradoxically, I see very little work in using deception as a defense mechanism. That is, targeting cyber-criminals instead of citizens. So today, I would like to tell you about an empirical study we did a few weeks ago.

Every year, SAP organizes, as part of the ‘Security Month’, a hacking event called ‘Capture The Flag’. In a nutshell, security enthusiasts from SAP (including very talented ‘red teamers’) try to hack into systems searching for flags, essentially text messages such as “CTF{Deception_Rulez}” which can be redeemed for points.

For this year’s event, we built a hospital-themed web application. The goal was to find a confidential document (containing the flag) stored in the server. To do so, players had to identify and chain together two vulnerabilities, that would let them successfully hack into an account then obtain the required privileges to see the document.

Then we added decoys.

Usually, you develop an application as secure as possible. You threat model your design, you ensure compliance with security standards, you use code scanners to find security bugs, you monitor logs. But getting an application 100% secure is not possible – if it was, phishing would not work – and finding evidence of an attack is difficult. It depends on the quality of your logs, of your detection rules and on the intuition of your monitoring team.

So this time, we decided to see if we could deceive the players, and use this deception as an alert mechanism.

The idea is simple: we assume that the application has unknown vulnerabilities. We add elements that cannot be found except by people with bad intent (our players 🙂 ). And we check whether these elements are being interacted with.

The question we wanted to answer is: “how many players can we detect (before they find the flag), using only decoy alerts as a detection mechanism?”
Our hope was to find at least 20% of players this way. That would be very cool if we remember that in theory, the medic portal can be hacked without interacting with any decoy. Our hopes were more than fulfilled.

Adding decoys is about adding elements which have no relevance to the business process. It’s not something you want to ask developers to do inside the application itself, as if it’s done in an insecure way, you will be in a worst situation than before. So we did it by introducing a reverse-proxy in front of the application, able to monitor HTTP requests and to modify HTTP responses based on a set of rules.

We added six decoys to the application. Let me present to you two of these. If you decide to adopt them, let me know about your success stories once you start detecting attackers !

Decoy: hidden form field

The first one was placed on the ‘login’ page. On top of the ‘username’ and ‘password’ fields, we injected a third, hidden field, named ‘system’, with a value of ‘PROD’.
This field is not visible in the UI, one needs to look at the source code to find it. What this field does is that every time you press the login button, the string ‘system=PROD’ is automatically appended by your browser to your request. Again, this is completely invisible to a non-malicious user.
But for an attacker, such a field looks like a potential entry point. However, there is a trick: the only way to be sure whether this field can be used to exploit the application is to change the value ‘PROD’ to something else and see what happens. And of course, if our proxy receives a request with a ‘system’ value set to anything else than ‘PROD’, we raise an alert.

This decoy will detect attackers who are at the login page. If an alert triggers, you can retrieve the IP address of that attacker and decide what to do: you can opt for a temporary ban, or have a look at what else this IP address will do. If it then connects successfully, congratulations on identifying a compromised user account.

Decoy: extra cookie

A second decoy was injected only for authenticated users, in the form of a cookie named ‘state’. This cookie, again invisible to a user just trying to get work done (how often are you checking and modifying your cookies manually?) is very interesting to attackers as sometimes this can be used to gain extra privileges or to make the application behave in a non-standard way.

Of course, here again if our proxy sees a request with a ‘state’ cookie which value is not the expected one, an alert is raised. And what’s even more interesting here is that since only authenticated users get this cookie, then if you get an alert, you immediately know which user account was compromised and you can deal with it immediately, for example by forcing a password change.

So, how did we fare?

We collected logs and raised alerts from day 1 to day 7 of the Capture The Flag challenge. We could retrieve information about 120 players, over about 170.000 lines of logs.

The challenge required the players to follow a process, which could be broken down as:

start -> create an account -> impersonate a doctor -> further escalate privileges -> find the flag.

We silently collected alerts – players were not punished for being detected (meaning that some of them were detected at multiple stages). Of course in a real environment, we could have taken immediate action.

Now, knowing that not all 120 players found the flag:

– decoys already detected 10% of attackers even before they created an account
– decoys detected a whopping 62% of attackers with a valid account before they could impersonate a doctor
– decoys further detected 51% of attackers impersonating a doctor before they could further escalate privileges
– and among the few players who were not detected at all, none of them found the flag – meaning that they all eventually gave up. It shall remain a mystery whether they would have finally made it without being detected.

These numbers were well above our highest hopes. Of course, this was “just a game”, 120 players is not that many, and we cannot really judge how different cyber-adversaries are from hacker-minded colleagues. It’s safe to say though that these numbers are significant. And that what you can gain in real-time, high-accuracy detection is well worth the effort of devising and deploying decoys in the first place.

And the beauty of it is that once attackers will start suspecting that hidden form fields and cookies can be deceptive and refrain from interacting with them, they will miss some real opportunities to exploit actually vulnerable applications.

Or in five words: Disinformation for the Greater Good 🙂