PaulReviews

It's sadly quite common. A further insult to scroll to the bottom of the email to see "Our values: trust" Thanks for raising it Andy.

This is a blatant lie. To confirm, I've just spoken with Willis Towers Watson (0117 9769 361) one of the two companies providing RPA support for the DfE. https://www.gov.uk/government/publications/risk-protection-arrangement-rpa-for-academies/academies-risk-protection-arrangement-rpa An email has been sent by an IT provider claiming RPA will not pay out unless you register AND install/use Police CyberAlarm. Is that correct? "That's absolutely not true; a complete lie - they're probably trying to sell you something. Can you please forward that to us, we'll have someone investigate" 21/07/25 2.25PM [Edit] The other company has just confirmed they've heard about it, called it spam and said it's wrong. Topmark Claims Management: "Yeah, we'd heard there's a company trying to sell something. You don't need to use it, only register. It's just spam." 21/01/25 2.45PM I won't name her as it's not appropriate, but you're welcome to call and check yourself.

No problem at all

Thanks Ditto, much appreciated. Under the circumstances, I'd hope admins realised the importance of patching these systems and with a lack of information on it, turn a blind eye to it. We'll see.

I'm not sure why an admin has redacted the password in my previous post?! Doing so prevents people updating their own devices! The password can be found in your installation guide. Also, yum check-update ... will list outdated deps only on your device, rather than the repo as a whole.

I've been doing some digging since last night. I'm yet to find anyone that's receiving an email explaining how to update the appliance... or that it's necessary. As a result, every CA deployment has been sat with outdated, vulnerable dependencies since installation. Ironic.

I'm curious. Has *anyone* ever received an email explaining how to install updates... and that it's required?

Use an app like Putty (update it, there's been a serious security issue lately), hit the IP on port 22. Login with Username: root Password: [Password] (unless you've changed it) [Password redacted] Run: yum list updates There's shouldn't be any (many) if it's patched regularly.

Hang on... that's worrying. If they don't have privileged access to install updates, they can't be installing updates. Login to your instance via SSH and check the deps... If they're out of date, please let me (everyone) know.

I wouldn't recommend it (security issues aside), as you'll likely break the auto-update facility. They'll be trying to execute commands on a CentOS environment which likely won't work as expected on Ubuntu. Also, it's not your responsibility to update it... leave that to Pervade to screw up.

That seems unnecessarily disrespectful @robjduk and makes me wonder why... NPCC has never addressed any concerns; they've refuted them from day one and continue to do so.

NCSC have taken the (understandable) stance of saying nothing & not tried to step on anyone's toes; presumably hoping it'll fail and go away quietly before proverbial hits the fan. Behind the scenes, it's a different matter. Many a giggle has been had

It's EOL June 30th 2024

Hi AAC There are only two locations in CyberAlarm where "Malicious activity detected" is thrown. Rebuilding the server isn't a solution... but without the code, they won't know why it's happening. and... If it's being thrown at 165, it's because the token (a CSRF token they added after one of my disclosures) isn't valid or present. If it's thrown at 665, it's the same reason... but related to the creation of logs. For both situations, it's a sessions issue. Either the session cookie is expiring/being removed before the session has ended or it's not being created properly. You could check your session.save_path INI setting to make sure it's able to write the session data to storage. If it can't, $_SESSION['token'] won't exist and it'll crash with that error. It could also be an FQDN issue... are you loading the console via IP or have you mapped a domain/subdomain to it? The session cookie will be tied to the FQDN and won't be valid if (when) CA tries to load over a different IP/FQDN. In any event, as others have said, it's not worth running anyway. It's of no appreciable benefit; it's poorly written/insecure and only adds risk where it's not necessary.