By Hadar Blutrich, CEO of Source Defense
In the recent massive ransomware attack, which threatened institutions, businesses, and organizations in 99 countries, unless victims paid the required ransom, hackers didn’t discriminate; they successfully targeted hospitals, Telco’s, government offices, and thousands of businesses with WannaCry, the breed of malware that they used to propagate the attack. Largely exempt from the attacks, however, were banks. Normally a prime target for hack attacks, banks weathered the ransomware storm successfully, for the most part, with a few exceptions.
It’s a testimony to the efforts banks have put into cybersecurity in recent years. As a famous bank robber once said, banks are where the money is, so clearly, they would be a prime target in any cyber-attack – as they no doubt were in the WannaCry ransomware attack. The hackers were unable to penetrate the veil of cyber-protection banks have wrapped themselves with. No doubt, members of IT teams in the world’s major banks are slapping each other on the back for a job well done.
They might want to hold off on the slapping, though. That banks were able to survive a massive cyber-attack from the outside doesn’t mean that they could survive an attack from the inside – via the web sites that they present to the public, where hackers have an opportunity to rip off customers using the third party scripts that most banks already have on their websites and of which they have no control over. Those scripts, issued by third-party service companies, provide essential services that are indispensable for banks and other organizations with an on-line presence – but are out of reach of the IT teams that need to ensure their security.
The security issues surrounding third-party scripts don’t get as much play as massive ransomware attacks, but they are no less of a threat. Last fall, for example, millions of visitors to top content sites were exposed to malware hidden in an ad banner that hackers had compromised. The Stegano exploit hid its malicious code in the parameters of banner ads’ alpha channels, redirecting website visitors to another site that hosts Adobe Flash exploits – with no clicking or scrolling required. All that was needed for the exploit to work was for a visitor to show up at the infected site.
That exploit was made possible by the compromising of the third-party script that controls the placement of ads on a site. In today’s super-connected web, sites use third-party scripts to provide many of the services they rely on – like chat, social media, comments, content, and much more – which are administered by the remote companies that support those services. Banks, like many others, rely on the integrity of these scripts to ensure smooth operation of the services visitor’s demand.
But the IT teams responsible for security at these sites don’t have access to these scripts – and these could be compromised by hackers, who are able to hack into sites and subtly change code that is propagated to thousands of sites. Using that code, hackers can run all sorts of exploits – like installing a keylogger that records users’ credentials and uploading them to a database, stealing account or credit card information, using phishing scams to record data and more.
Unlike with “direct” hacks into a bank’s networks, the IT teams responsible for bank system security have no control over these scripts; the best they can do is inventory and review the code script (which they usually do on a regular basis). But they cannot review the code all day, every day – and all it takes is one moment of inattention for a hacker to do their damage.
With that, banks still need to defend themselves. How? One way is via a dynamic protective security layer for websites, where code is evaluated in real time while executing on each browser and tested for security; if anything is found to be amiss, it is dismissed, without endangering the user. Currently, this is the only strategy that is viable to protect sites from rogue scripts.
How does it work? When a script (in response to a user query) calls a listing of stock prices, for example – the security system executes that code in a protected layer evaluating its activities. If the script acts as expected – if the policies for this specific script allow the load of information to this area– the results will be displayed on the institution’s page. If the script tries to perform an action that is not permitted, the protective layer prevents that execution from taking place, allowing the rest of the action- the “clean” part – to continue on with its work.
Thus, a dynamic protective layer for web sites could “arrest” malware or rogue code that attempts to install a keylogger, click diverter, or any other exploit a hacker would use a compromised script to run. Using such a system, banks can protect themselves from the unknown threats presented by third-party scripts just as well as they can protect themselves from the “standard” cyber-threats they have become so successful at fighting and beating.