July 27, 2023
Open Source software is in the security spotlight again as a campaign which seems to target banks specifically has been uncovered by researchers, as reported by darkreading.com1:
The Simple Mechanics of Typosquatting
To be more precise, it’s the source repository and delivery mechanism, in this case, NPM, which is causing concern. Just when we thought typosquatting had become unfashionable, it’s re-invented itself for a modern audience and looks like pulling off that tricky second album.
It’s laughably simple, it seems, to change a couple of letters in the name of a popular package, upload it to an NPM repo and await victims who aren’t paying attention.
The most likely route in for the miscreants is via dev platforms, stood up in a hurry and not necessarily subject to the same level of scrutiny as production environments.
As usual, however, once attackers gain a foothold, who knows where their snooping will get them? Often pretty far actually, if the stats on shared credentials between environments together with the reliance on common elements of infrastructure are to be believed.
The Role of FOSS in the Security Debate
Presenting this as a strictly FOSS problem is not very fair – it’s not the fault of the author or maintainer if the repo which handles distribution of their code can be so easily compromised, or if admins don’t do the basics to check the integrity of the software they download, after all, there are some pretty simple steps we can take to protect ourselves.
– First, and most basic – check the name! Typosquatting is called that for a reason. It relies on you not noticing, well, a typo…
– Check for the download history – is it recent, is it popular?
– Does an associated GitHub repo check out? Same devs? Matching dates? Sane comments and issues?
– Lastly – there are tools to help spot these things, such as NPQ, which has a free tier.
This has all added more fuel to the fire which is the pro / anti-FOSS debate in the security community, which gathered momentum during the Log4j debacle and hasn’t abated since. Full disclosure – I’m fully in the pro camp, but I do understand the points made by the wrong other side.
Navigating the Pro and Anti-FOSS Debate
The traditional argument for actively selecting FOSS to carry out functions in secure environments is that the source is available for your inspection, and it has been rigorously peer-reviewed. This is, of course, problematic if you don’t have the skills available to inspect source code, as those supporting proprietary code would argue – and that’s probably most organisations, and then, even if you did have a bench of developers just waiting to give all your open-source code the all clear, think of how long it would take and the project delays it would introduce.
So that leaves peer review, which is, of course, just fine if you trust the peers to not make mistakes, and not to be bad guys. And still exist.
The Reality of Open Source in Our Infrastructure
The deciding argument, though, isn’t an argument at all – you don’t have a choice. As Log4j dragged into the light for many previously unaware execs, all of us have dozens, if not hundreds, of dependencies in our environments on elements of FOSS whether we’re happy about it or not – show me a network or firewall appliance which doesn’t have a boot-up attribution for some open-source code (probably BSD), or a server farm with no Linux. Or an Android phone without Android. You get the idea.
The most important software in the world, powering all our daily lives both at work and at home originates from, or still resolutely is, FOSS, and as a member of the security community I know we certainly couldn’t do our jobs without it.
So, given that we’re all stuck with each other, what to do?
Protecting Your Environment Against Cyber Attacks
As usual, be careful. Check and double check anything you introduce to your environment, look for the obvious, use the tools and talk to the community.
Maintain complete separation of dev and prod systems and don’t take shortcuts to save hours when it could cost you months of lost time recovering from a breach. Test in a safe place and trace interactions – should that piece of code be talking to a Chinese IP address associated with North Korean hacking teams? Probably not. Unless you’re a North Korean hacker, in which case, all good.
Use logs from everywhere, they’re the window to your world. Be vigilant – use layers of defence so you can at least contain an attack if the worst happens. Finally, maintain a picture of what “normal” looks like for you, and use it to detect anomalous activity, be it human or code related.
The Emerging Risks of AI and Large Language Models
Food for thought – there’s a lot of debate now of the reliability of emerging AI and in particular LLMs (Large Language Models) like that used by ChatGPT (have a look at AI hallucination if you want an internet rabbit hole afternoon) and its dependency on the quality of the massive chunks of data it ingests. Imagine if you could poison the data lake to bend it to your will, or to start a chain of unintended consequences.
Could the singularity begin with a typo?
A Tribute to Kevin Mitnick: Father of Modern Social Engineering
I couldn’t possibly sign off without a tribute to Kevin Mitnick, who died this week. For anyone who hasn’t heard of Kevin, he was the father of social engineering in its modern form and latterly a hugely entertaining public speaker. If your job is to help your users avoid being caught out by phishing, tailgating, confidence scams, impersonation, or inherited trust techniques – you need to know about Kevin.
Arguably without Kevin we wouldn’t have voicemail hacking, but we also wouldn’t have his wonderful book Ghost in the Wires (https://www.mitnicksecurity.com/ghost-in-the-wires) which, for anyone of a certain age and a love of the movie Wargames, is indispensable reading, so, swings and roundabouts. Anyone who hacks a phone system to join a conference call with the FBI, Secret Service and AT&T engineers whilst they’re trying to work out how to catch him, I can’t help but have a grudging respect for. For once, a call participant who really did need to stay on mute.