Red Team Chronicles — No Hidden Information

In this episode, you’ll discover a perfect illustration of the security knowledge gap existing between organizations. Offensive security expert Philippe Caturegli comes across a way too common belief: “nobody will find my scripts or my data because they are very carefully hidden”.

And here is how Philippe reacts to this:

There is no such thing as well-hidden information. Security can’t be established by hiding things or considering they are not understandable, cybercriminals have the time, intelligence and tools to find anything. A common error is to leave sensitive data in a development folder. Everything that is available in a website for example, even in sub-folders should be considered public.

Multiple techniques enable attackers to find hidden or forgotten information: Open Source Intelligence, DNS enumeration (active or passive), attacks through folders and files dictionaries, website archives are some of them.

You need to protect the information in a way that even with complete knowledge of how things work, you can’t exploit it.

In one case we got access to the source code of a Java application. In this application, they used a function called Math.random to generate a one-time password. This function is in fact a formula :

X n+1 = (a.Xn+c) mod m

where a is a multiplier, c an increment and m a modulo

This formula generates pseudo-random numbers. These numbers constitute a sequence for which each new number depends on the previous one. The initial term X0 is called the seed. Each seed generates a new sequence. The modulo defines the randomization space.

The sequence seems random but it is, in fact, predictable. We just needed a sequence of 3 numbers , which we got by enrolling 3 times. From the 3 numbers, we could reverse engineer the formula using brute-force techniques. Current processing power makes it easy and quick. In this case, the function elements were static numbers in the java code, the only unknown element was the seed.

You need to protect the Intellectual Property that is present in your code because if it leaks it can give hackers a lot of useful information to exploit.

But you also discover hardcoded secrets, like credentials?

Oh yes… and cookies and tokens which have a longer lifespan, as passwords are often expired, but not always… also we can deduct things from accounts, password structure, the way they are used, internal machine names, internal IP addresses, even proxies. We often use multiple items together to succeed, one leading to another. So never consider something as not important.

In fact, I really believe that there is always a way to get in. Social engineering being one, even if people are trained. There is always a weak link. Some profiles are also easier to bypass because it is their vested interest to comply. I am thinking for example about sales reps or support teams. IT needs to make sure access rights are correctly managed. Do sales need to access Jira tickets? Because in Jira tickets you often find security issues.

But don’t get me wrong, developers are also potential targets , even if it is a bit more difficult. We can use personal accounts and credentials leaked to embody a developer and create trust with their colleagues.

In the end, security should really focus on detection. Being compromised is not a major issue if you react early, because the initial intrusion is limited to a very narrow scope. This is a shift we’d like security teams to take, adding a discriminating alert layer to their protection. They should not only focus on preventing but also on alerting.

As you can see, Philippe has some interesting stories to share as well as some useful recommendations to make. If you are interested, keep following the Red Team Chronicle by subscribing to our newsletter or following us on Twitter or LinkedIn.

Stay tuned for Episode 5!

Originally published at https://blog.gitguardian.com on September 15, 2021.