By Benjamin Donnelly

Let me be clear.  The types of hackers that we’ve been seeing have rapidly changed in the past five or so years.  There is a clear trend that only a few highly informed individuals have been following.  If you’re not aware, you are going to get left behind.

Cracking into a network used to be an easy and routine task.  The same types of attacks worked almost everywhere.  You could use a few well known “tricks” to gain access to any network of your choosing.  Hackers would collect not just zero-days, but 100-days, or even 1,000-days (vulnerabilities that are well known to the public).  Times have been changing, though.  Companies like Microsoft have done an increasingly great job of building security into their products.  Whereas MS08-067 was still being found on computer networks even five years after its first discovery, nowadays you will be hard-pressed to find MS17-010 even two years later.

And it’s not just vulnerability patching.  It’s getting harder to find new functional exploits.  In the earlier days of the internet, you could easily find a stack-based buffer overflow in nearly any program of your choosing. Modern tools like EMET – as well as increasingly effective secure coding standards, have made this style of research very difficult.  And it’s not just that the internet has seen less per-software-component buffer overflows.  Similar attack styles in various other subdomains have also been steadily cleaned up by the ever-advancing push for better cybersecurity controls.

Do you remember how easy it was to find SQLi (SQL injection) even a few years ago?  Have you noticed how much harder it’s gotten now?  There was a time when many web applications were built on PHP, requiring developers to implement security controls manually. Modern web applications are built from a selection of various web frameworks like Django, Flask, Node.js, Spring, etc.  These frameworks often include baked in protections against various web application vulnerabilities.

For example, where CSRF (Cross-Site-Request-Forgery) used to be an attack style that required mitigating developers to build out a special submission routine for all returned form POSTs — Flask’s WTF Forms handles mitigation automatically.  If a developer writes an application in Flask, using built-in modules, CSRF will be mitigated from the start.  In another example, with PHP it was very common for a developer to “echo” untrusted user input unsanitized back to the page — thereby generating an XSS (cross-site-scripting) vulnerability; Flask’s Jinja2 templating engine automatically escapes such content.

Note: Jinja2 still creates the possibility of XSS in a few rare circumstances, such as when a variable is echoed into an HTML tag’s attribute section, where it may be interpreted as Javascript.  But that’s a huge improvement from what we had before!

Combine all these new technologies and techniques – with increasingly effective workstation and network protections against malware and malicious traffic, and we are looking at an ever increasingly secure world.  At least that is, against traditional threats.

If you haven’t been watching, you might think that things have been slowly getting better for computer network defenders.  It’s far easier today to identify, track, and remove threats from your network than it has ever been before.  But not all vulnerabilities are gone.  Networks are not perfectly secure.  If anything, the partial mitigation of entire vulnerability classes has left many networks and security teams worse off than before.

A true hacker’s story

Let me tell you the story of a web application that I myself personally destroyed as part of a pen test.  This application had no SQLi vulnerabilities that I could find.  It was perfectly protected from XSS.  The security team assured me that it was well built.  And I’m sure that from their perspective it was.  In reality, it was anything but that.  Their overreliance on various web frameworks meant that when the time came to deal with a next-generation threat model, they had nothing to counter what was coming.

Instead of focusing on OWASP top ten style vulnerabilities, I slowly unwrapped their website by pulling hidden token values from a glob of Javascript they presented to the client upon each request.  Over time I was able to find hidden but unsecured endpoints that generated authentication tokens to enable me to delve further into the site.  Finally, I was able to uncover an endpoint which gave me the ability to add my user to the Administrators group on the site – without authentication other than the tokens I had already generated.

From there, it was game over.  I had access to all the personal information owned by the site.  No known attack styles required.  All it took was to slowly unpack the logic of their site – and making it play against itself.

This is what more and more attacks in the future will look like.  Let me warn you – so that you can go back to your organizations and push for a solution.  Because if you don’t, you’ll be left standing when the music stops.

The new attackers are coming!

Here’s the big prediction: Tech isn’t getting more secure. It’s getting more complex. You know it’s true too.  You’ve likely been watching it happen, thinking that it was entirely a good thing.  And in many ways, it is.  But let’s be clear.  Your networks aren’t getting objectively more secure.  The complexity of the products and pipelines that you’re using are raising the bar.  Requiring more and advanced attackers.

It’s no longer enough that an attacker simply has custom malware unknown to anti-virus and basic knowledge of Metasploit.  There is a new class of attacker coming.  I want you to be ready for them.

To be clear, when I say that they’re coming, I only mean that they’re becoming more common.  In reality, members of this class of attacker are already here.  They leverage vast infrastructure, advanced computing, and complex attack styles to tear your security paradigm wide open.

Want a sampling of what these new attackers can do? Take a quick peek at what happened in February of 2017.  If you weren’t paying attention to scholarly research, you probably missed it.  There was no big breach or scary announcement.  In what became known as “SHAttered” a teaming of Google security researchers and the Dutch research institute CWI, announced that they had generated the first known collision of SHA-1 hashes for two different PDF files.

Note: Though a full explanation of this attack is beyond the scope of this article, a quick explanation is that the SHAttered team created two PDF files that might be mistaken for the same PDF file by various software systems.  This means that it would be possible for them to replace a “secure” message with one of their choosing.  Making it look like a person or system had said something they had not.  For instance, modifying the secure message “ATTACK AT DAWN” to “ATTACK AT DUSK”.  For more information check out: https://shattered.io

It had been known for a long time that SHA-1 was out in the open.  But many organizations had thought of such attacks as simply “theoretical” or otherwise impractical.  Against the previous generation of attackers, this assessment was almost certainly right.  But against attackers from the next-generation model – with complex attack styles, advanced computing power, and vast infrastructure, not only would such an attack be possible, it might even be trivial.

SQLi, XSS, CSRF, and generic RCE attacks slowly wane. But you’ll observe that increasingly insidious supply chain and custom logic attacks grow over time – remember the following: tech isn’t getting more secure; it’s getting more complex.

So, what can you do about it?

Be prepared

As a leader in an organization, here is the best advice I can give you.  If you want to increase your security against previous-generation threats, keep doing what you’ve been doing.  Hire security analysts, invest in network security devices, build strong patching policies and processes.

If you want to be one of the few organizations prepared to handle the next wave, you have one solution.  You need to hire engineers.  Not front-end developers; not “programmers”; not “tech wizards”.  Your infrastructure is getting more complex.  Your software is getting more complex.  Without people who can actively operate in that environment you are literally blind.  Hoping that some attacker will not come along who is able to see — and open a door you forgot to lock.

Benjamin (Ben) Donnelly is an omni-domain engineer, and the founder of Promethean Information Security LLC.  Ben has worked as part of teams hacking such things as prisons, powerplants, multi-nationals, and even entire states.  He is well-known for his research projects, including his work on the DARPA funded Active Defense Harbinger Distribution.  Ben has produced a number of field-leading advancements, including the Ball and Chain cryptosystem.  He has spoken at Derbycon and BSides Boise; and has contributed content to multiple SANS courses.  Outside of cybersecurity, he can often be found skydiving, producing underground electronic music, or starring in indie films. 

The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same. All views stated in the article are personal.