Phew! It's been 3 long years since my last article... and I've deliberated over posting this for way too long.  But, I feel it's important enough to warrant at least some debate.

2 months ago, I came across a tweet by Lancashire Police Fraud & Cyber advertising CyberAlarm; a govt-funded tool to help protect companies from cyber attacks.

Interest piqued, I signed up and awaited my "access code" which is necessary to gain access to the downloads page. Or so I thought.

A few days later, I was contacted by a Cyber Protect officer from Leicestershire Police who explained there was no download link for the "live" product on the grounds of "data confidentiality".  I'm not sure I understand that premise, given it's a product intended for public use... but I digress.  Instead, he provided an "installation guide" PDF which outlined how the product worked & how to install it.  If I still wanted to proceed, he could provide the access code.

Here's a segment of the installation guide...

--

Their installation guide suggests running it inside a DMZ (de-militarized zone, an isolated segment from other network assets) or "on your internal network".

For many firms, especially SME, the concept of running a DMZ is alien; with many network assets all joined together with no logical/physical segmentation whatsoever.  This is crucial, as isolating potentially dangerous assets (IoT, BYOD devices etc) from your core infrastructure is vital to help prevent attacks travelling across your network.

Unfortunately, it's likely to be those smaller SMEs without a DMZ who deploy CyberAlarm; in the mistaken belief it's a safe & secure way to mitigate cyber threats.

If you're going to run anything on your internal network, you must be able to ensure the product is reasonably secure.  Faith-based security rarely ends well, so let's dive in.

Installation:

In the installation guide, they advise you to deploy this on a dedicated machine... which seems reasonable, until they explain why...

Disable SELinux?!

SELinux or "Security-Enhanced Linux" is a mandatory access control (MAC), a vital security tool built into CentOS (based on RedHat Linux).  It's designed to protect system administrators from themselves; enforcing strict security policies and ensuring isolation between processes.  If it's disabled, poorly-configured or malicious apps/services have root access (aka - total control) over the device.

NCSC quite rightly state "rooted/jailbroken devices are a threat to sensitive data" (https://www.ncsc.gov.uk/guidance/application-development-guidance-introduction), but NPCC are actively pushing a product which requires you to effectively root your device!

If you take NCSC's advice (and you really should!), this alone is a deal-breaker.  The only reason you'd disable a vital security control is because you're too idle/inept to overcome the issue which prompted you to disable it in the first place.  If you need further proof of this ridiculous decision, here's an article on the CentOS blog called No! Don't turn off SELinux! in which Thomas Cameron, Chief Architect for Red Hat says "Linux is a gun and you know where your foot is".

Anyway...

I noticed a screenshot with the download link and without an access code or authentication, I proceeded to download the 2GB virtual machine image and launched it with VMWare Workstation.

Opening Pandora's box...

There's a lot to get through, so I'll summarise as much as possible.

PHP 5.4

PHP 5.4 was end of life in September 2015.  No more security patches or updates, it's dead and should never be used in a production app.  I'll also mention, I put this "phpinfo" file here remotely; it's not part of CyberAlarm.

Remote Network Access via RCE

This one beggars belief.  The app has a file called "getmon.php" which literally serves as an RCE (remote command execution) endpoint.

The above image shows me grabbing /etc/passwd from the virtual machine.

That's bad enough, but what if the attacker is slightly more creative?

Here, we use the SMB protocol to connect to another PC inside the network and grab sensitive data from it.

If you have sensitive data, trade secrets or anything else important on your network, it's now remotely accessible to anyone, anywhere when you view a web page.  We haven't placed anything on the network/virtual machine to achieve this either... the attacker is just carrying out commands as if they're sat inside your network.

Let me be really clear about this.  This vulnerability allows a remote attacker to entirely bypass your firewall and exfiltrate any data accessible over your network; you only need to visit a vulnerable web page once.

Cross Site Scripting

Looking through the code, there's no attempt to sanitize (or make safe) any user inputs, so an attacker can remotely inject malicious code into any page on the box.  Here, we hijack the "registration" page.

TLS certificate expiry

It should go without saying, but if your security certificate expires, it's no longer secure.

Broken Encryption

The strongest of door locks is rendered insecure if you leave the key somewhere vulnerable.  The same applies in cryptography.  It's absolutely vital to generate a cryptographically random key and handle it securely.

Sadly, CyberAlarm does neither.

The "key" is static and hard-coded: "P3rv4d3S0ftw4r3"

Reading between the character substitution, you'll see "Pervade Software" - the developers behind CyberAlarm.

To make matters worse, they use AES-CBC, which can be implemented securely by a competent developer.  Alas here, the weak key and complete lack of MAC (message authentication code) means they cannot trust any of the data they collect.

A MAC is vital; it allows the recipient to ensure the data hasn't been manipulated during transit.  Without it, they're actioning harvested data collected from "data collectors" with absolutely no guarantee of its integrity.  Far from improving security, I'd argue this makes matters worse.  Your reports could be entirely fake or largely contain data you can't act upon; diverting your attention from real risks.

Broken Encryption  - Part Deux

One sure-fire way to ensure your product is entirely insecure is to disable all security checks on your certificate, which of course, CyberAlarm does.

This means all updates are insecure - allowing an attacker to put anything on the device remotely.  Note: I've added the comments in this screenshot to clarify what each line does.

Embedding server passwords in code!

Seriously.

When the app needs to grab a list of "jobs" or tasks to carry out locally, it logs in with a password of "3jscove".

If you're wondering, the "phash" function is a wrapper for SHA-256; another insecure & unsuitable choice for password hashing.

<insert record scratch sound here>

In light of all these failings, I notified Leicestershire Police and awaited their response.

When it came, I was stunned.

The link I'd "found" (from their installation guide) was a 2yr old "test" version never intended for public use!  Great, it's 2 years old... now your dependencies are only 3 years out of date instead </sarcasm>

I'm not about to disclose the entire conversation or the meetings which followed, but when the phrase "no deal breakers" was uttered, I realised this has to go public.  In fairness, they have put me in touch with the CTO at Pervade with a view to "making the product better" but after a couple of brief conversations (none of which technical) and despite his candid response, my position now hasn't changed from day one.

This pilot should be pulled immediately. I'd actually go one step further and question how a product with so many simple but critical security flaws could ever be promoted by the Police.

The "actual" live version...

Following my criticisms over the "old" version, I was given an access code to allow me to download the "live" one.

Suffice to say, little has changed.

The code is still woefully insecure, as is the implementation of several core features and in all honesty, I just haven't the time nor motivation to explain why disabling security controls is a bad idea. Sorry Jon.

Obscurity hides a thousand sins...

What I haven't yet mentioned, is the fact that every single line of code in CyberAlarm is encoded/obfuscated using IonCube.  By obscuring the code, it prevents any casual observer from uncovering the mess contained within.

Thankfully, IonCube is easily reversed (as is any encoding) and offers very little real-world protection.  However, CyberAlarm has apparently "passed" a penetration test which, assuming it wasn't carried out by Stevie Wonder, beggars belief.

Summary

CyberAlarm is sadly nothing more than an insecure, poor-designed/engineered wrapper around OpenVAS - an open-source vulnerability assessment scanner.

I appreciate the forces may disagree with my findings and/or conclusions, however whilst they don't consider any of the above to be "deal breakers", the public are now able to decide if they're willing to entrust their firms security to a product like CyberAlarm.

If you're in #infosec (even if you're not), I welcome your comments below.

Update(s)

25/11/20 3PM: Thanks to Dave Walker on Twitter for pointing out a mistake regarding CentOS.  My screenshots show a later build with CentOS 7 / PHP 5.4 so to avoid confusion, I've removed that section. Apologies folks.

27/11/20 17:30PM: The NPCC have published a response, claiming this is "completely untrue".  Needless to say, they're entirely wrong... but I've been hearing that story for 2 months.  I'll reply here shortly, however for more immediate updates, keep your eyes peeled on @paul_reviews - where I've already disproven their first claim (they never provided a link to the vulnerable version)

02/12/20 5PM: My response to NPCC and a review of the production build is here: https://paul.reviews/cyberalarm-testing-the-production-version-and-why-you-should-avoid-it/