Security specialists. Arghhh! They’re all sitting in their ‘ivory tower’ without anything better to do than to take a baseball bat to your hard work and tell you how you’ve not considered some obscure vulnerability CVE-142341231/4234 in a library that you didn’t even know existed. Not only that, there is definitely no way that you can deploy now, even when the product owner is breathing down your neck saying that nobody is going home until we’ve fixed this!

No, I didn’t think so either.

It is reasonable to assume that they all have been inducted into a secret 5-year training programme covered by government reporting restrictions. Either this, or at least spent a long time in Ops sitting in front of at least 7 monitors sipping cold strong coffee, learning the intricacies of the Linux firewall whilst also working to actively block the l33t h4x0rz attacking our website; while signed into all the servers simultaneously as root.

No, I didn’t think so either! – but come to think of it, this would make for a good cheesy film script!

So, exactly what does it take to get involved in security? The other day, I was sat around a table with a number of security specialists (more on that later, but of that is a secret, 😉) and I was surprised when they all started their introductions with “I’ve not had any formal security training…” - it seems like they all sort of ‘fell into it’ so to speak, but come to think of it, so did I.

Debugging Puzzles

My journey started as a developer and liking puzzles, in particular the ones that involved finding and fixing production issues that could not be reproduced locally and made no sense whatsoever. For example, why would the database think that there is a working day between Friday and Sunday?

This is the code:

1
2
3

--Check if it is a Weekend - 6=Saturday , 7=Sunday._  
SELECT to_char(pInputDate,'D') INTO vWeekend  
FROM DUAL;

To determine the answer, you have to know that Oracle uses the Locale of the JDBC client to determine which “Locale” to use in a DB session. In this case, the container default of “en_US” meant that the first day of the week was Sunday.

But I digress… What does this have to do with security? Well, security holes are based on the similar puzzles. Exploits are just bugs with unintended consequences. SQL injection, XML injection, XXE, XSRF are all down to someone using a behaviour of code in a way that wasn’t originally envisaged.

Working Backwards – What’s the worst that could happen?

Quite a few months ago I realised that something wasn’t quite right when looking at some of our teams inherited code. Someone had commented out a Spring bean that did some encryption. Most likely, it was commented out when debugging locally and as it was too convoluted to set up encryption keys and keystores on the developer’s laptop the change was accidentally committed.

I know, we’ve all made these kinds of mistakes.

However, rather than simply fixing, committing and then forgetting the issue, I thought, what is the worst that could happen? Is there any way I could exploit this?

To cut a long story short – the keys were used to encrypt a Java Serialised Object which was POSTed between two services via the user’s browser. By not encrypting the object, it was possible to inject your own Java Serialised Object and then have the server execute any command you like.

That’s not good… It was exciting! I had just found my first proper ‘in-the-wild’ real-life vulnerability!

Fortunately, I had already worked out what the fix was! All I did was find the root cause and worked backwards to figure out what caused the problematic symptoms. In my view, this isn’t really that different to debugging.
The same tools help (a debugger, a good network proxy) and a good bit of thinking outside the box, but of course, that’s all part and parcel of development, right?

Break the Bank

My next steps into security were a stroke of good timing. As a member of the Equal Experts network, I found out that they were running a 9-day event to let interested EE associates try to Break the Bank!
Armed with a version of the Xinja app (Australian aspiring neobank), Charles Proxy and a good dose of “malicious” intent I managed to poke some dents into the backend.

It all got rather exciting when I thought I had caused the backend to stop responding!

Security as a Team Sport

Wind the clock forward a couple of months, and my interest in security meant that I took on testing a newly migrated reauthentication service for security holes. I had a laugh and found XML can be dangerous. I also learned that finding and fixing security holes is only the part of the story.

My first step was to raise the issue with the security team. They then swung into action:

• Do the affected services need to be taken online?
• How do we communicate with the business?
• What else is affected?
• How can we investigate whether the vulnerability has already been exploited?
• How could the vulnerability be exploited?
• How do we contact the service owners and/or people who can check for the same vulnerability?
• How can we fix it?
• How can we prevent it from happening again?

Rather than the 7-monitored fast-typing caffeine freaks from the movie script above, the security team wielded spreadsheets and Slack channels to: find the best people to investigate the issue across the estate, provide templates on how to test, report any vulnerabilities and generally help out. The three Cs of Communication, coordination and context would be the key words to describe the flurry of activity taking place.

True enough, I ended up working long into Friday night and partway through Saturday morning to fix the issue but no amount of frenzied hacking into my laptop would have been able to achieve anything without the 3 Cs and a lot of valuable teamwork.

Now this was not only impressive and but exhilarating!

Postscript

I now find myself closely liaising with other Equal Experts security professionals which provides a great opportunity to expand my skill set in a different and exciting direction.
It doesn’t mean that I’m going to give up the day job though. Without being a developer and debugging, I would not have had the background knowledge to know what I could find when I start poking the system.

If you'd like to find more of my writing, why not follow me on Bluesky or Mastodon?