In July 2020, I ordered a takeaway from Napolis Pizza.

Like many firms across the UK, they use ZPos for their websites and electronic point of sale.  A snazzy website, simple & easy to use ordering and minimal processing fees (compared to others in this space), it seems like a great deal for businesses and consumers alike.

However, it quickly became clear that far from the "super secure" service they promote, it's an absolute mess which only places their client - and subsequently you & I - at considerable risk.

Let's dive in.

Pay what you like!

In an act of sheer lunacy, ZPos sites allow the user to choose their own prices!

Simply edit the HTML, alter the price to whatever you like and place your order.

Here's the video showing how it's done.

But, being able to modify the price doesn't necessarily mean it'll go through...

Well, it worked.  Order processed... now to collect it.  Will they notice?

Napolis is a busy place with great food, so I didn't expect anyone to spot the dodgy order.

Sure enough, the food was ready & waiting with not a hint of a problem.

If I were dishonest, I could have easily walked out having paid half the actual price - but after 5 years and numerous attempts to raise it with ZPos, I'd had enough and decided to tell their client directly.  After all, Napolis is a small local business and every penny matters.

They were clearly stunned to realise what had happened and despite offering full payment, they simply thanked me & escalated it with ZPos.  ZPos promised to call me back the following day. More on that later.

5 years, many thousands of orders and any of them could have been altered without the shop's knowledge.  It stands to reason ZPos didn't know either... just how lax is their quality assurance process?

I can excuse the idiotic design - bad developers are a blight on the industry.  I can even excuse the odd security flaw.

What I can't excuse however, is virtually every flaw in the book whilst purportedly being a "super secure", security-conscious service.

The ToFu Attack

I wrote about this back in 2021.

In short, a ToFu - or "trust on first use" attack is possible when a website accepts registrations from unverified email addresses.

The risk isn't obvious, at first.  Think of it like the web-based equivalent of a supply chain attack; the ability to embed malicious payloads into an account and leverage any existing (or future!) vulnerabilities.

This works because:
a) Most sites don't send confirmation emails after registration
b) Even if they do, the victim hasn't registered and assumes it's spam - ignoring it.

The attacker simply registers with the victim's email address, a random password and buries the malicious payload.  If/when the victim comes to order, the site will report an existing account and offer to reset the password.  Once they do, the payload is executed and the damage is done.

It might seem far fetched - but I carried out this attack on Dropbox Passwords... copying the victim's "recovery phrase" which doesn't (or rather didn't) change when the password reset.  Every password, payment card, website URL - everything fell into my lap moments later.

Don't trust, verify.

Reflected & stored XSS

It appears ZPos has never heard of output encoding - as virtually every field is susceptible to an XSS attacks.

XSS or Cross-Site Scripting attacks allow an attacker to execute code in your browser; effectively taking control of the entire session and altering how the site works/looks.

During checkout, ZPos cheekily suggests your details are safe.

In reality, they've gone to greater lengths to place a meaningless trust mark than actually secure the service.

Here, I embed code which alters that trust mark to make it more accurate.

If this were a real attack, nothing would change visually... the attacker would slurp your data (including full payment card/CVV) and allow the order to proceed as normal.

I must remind you, it's been this way for 5 years.

If you've seen strange activity on your card after purchasing from any ZPos powered website, there's a chance you've been the victim of identity theft due to ZPos' poor security posture.

CSRF - Cross Site Request Forgery

A CSRF attack allows an attacker to remotely execute commands, completely without your knowledge.

Here, I change the user's password from a completely different website.

First, I changed the password field type to text - so you can see the information I've entered.  As you know, passwords are normally hidden with ***** to preserve privacy.

Then, I login with my actual password, which works as expected.  Then, visiting another website, the attacker changes the user's password.

Note: In this demo, the exploit is intentionally obvious to explain how it works.  In reality, this would happen silently & invisibly to the user.  No user action required - just browsing the web as usual.  This is identical to the ASDA/Walmart attack from 2014.

When the user next tries to login, the password has been changed.

Like the ToFu attack earlier, the attacker is now able to login as the user - grabbing personal information, order history, telephone numbers, addresses and crucially, embedding a malicious payload to later grab the customer's payment info.

Again, all of this is transparent to the victim.  You won't know the site has been manipulated - neither will ZPos - but I can guarantee, your payment details will either be used or sold shortly thereafter.

If it's days/weeks later, would you put two and two together? Probably not.

Set your own discounts!

In many ways, this is similar to setting your own pricing - but instead, setting your own "points" limit.  This way, the price remains the same to the affected company and it simply appears the customer has valid points to use.

They're unlikely to spot the order anyway, as I mentioned earlier - but now with accurate prices, it's almost certain to fly under the radar.

No security headers, literally none.

This is one of the most basic (but most useful) security steps they could take, but don't.

No security policies, no reporting, no frame limitations... basically, anything goes.

Outdated Dependencies

Fixing bugs & applying security fixes should be an integral part of any business.

Sadly, ZPos is so antiquated, their entire ecosystem looks to be hanging by a thread.  Their caller ID uses Visual Basic 6 - which went "end of life" in 2008!  Not inherently insecure, but certainly legacy and decidedly crusty.

Passwords are reset to 6 "random" numbers

Even if you picked a reasonably safe & secure password, an attacker can reset it to 6 random numbers.

So, if our attacker (or rather their PC) can count to 1 million, every account is accessible in just a few minutes.

Another idiotic design choice.

Passwords emailed to the user

If the user subsequently changes their "reset" password (the above 6 digit number), ZPos used to email the entire password in plain text.  Thankfully, they now redact all but the first & last character.

This is not only unnecessary, but significantly weakens the password.

If we compare this email with another password reset, can you spot the problem?

Not only is the length of the password leaked, but an attacker knows the first & last character.

Responsible disclosure

I contacted ZPos the day it started, way back in 2020.

After 5 days, I sent an email too... which they clearly received.

Again, no reply whatsoever.

4 years later, I tried again.

Still no response.  2 emails, 1 contact form submission (and auto reply) and several tweets, they clearly weren't interested.

Another year goes by, so I tried again.

At this point, it's clearly not a priority... which prompted my disclosure to their client, Napolis Pizza.

As you heard earlier, they promised to call back the following day.  Willing to give them another chance to come good, I waited...

24hrs later, having had no phone call, I notified Napolis of my intention to publish and report to the ICO - my patience had finally expired.

Napolis then contacted ZPos again.  At which point, I received an email...

Research projects take considerable time & effort - extending well beyond the initial findings.  The ultimate goal is (and always is) to protect the end user - people like you and me - that use these sites daily and assume they're safe.  The fastest route to resolution is nearly always contacting the firm directly.

If a company has shown willing to engage, I'll invest whatever time is necessary to assist.  If they appear apathetic, the next logical step is to notify the public directly.

I replied...

By this point, I've already written this article and proofed it (cue someone spotting a typo I've missed), so the thought of spending yet more time to explain the situation is demoralizing... especially when they've only got in touch after their customer complained - twice.

To add insult to injury, they gave the typical "we take it seriously" nonsense... and say they want to address these issues "quickly and thoroughly".  I'm not sure 5 years constitutes "quickly", but disclosure is rarely a quick & simple process... so against my better judgement, I agreed to a call.

That was last night.  It's now 4PM the following day - no reply, no call and the sites are still live.

Final thoughts:

ZPos is remarkably similar to TiffinTom - another EPOS firm which had little regard for the user's security/privacy.  Unlike ZPos, they at least replied - but disputed everything despite quietly trying to fix it.  They closed shortly after.

I hope the same isn't true for ZPos - they have staff, families, mortgages etc.  But, so do we.  Having your identity stolen is a brutal & humbling experience; the impact from which is often felt for many years.  Ask any TalkTalk victim.

Some may place blame with Napolis here - and whilst they could have paid to have it audited, how many small firms are in a position to do that?  Instead, they understandably outsource & trust a supposed leader in this industry... and I can't find fault in that.  Napolis were not only quick to respond, but actively chased ZPos when their concerns weren't actioned.

As I mentioned to Napolis' Director, these things happen.  What matters is how you respond.  Some go quiet, others go legal (ignoring the Streisand Effect entirely) and if they ignore valid concerns for long enough, some go under.  That said, it's entirely possible to recover by putting policies and procedures in place to not only prevent future vulnerabilities, but engage with people trying improve your platform.

If you're affected, as a client of ZPos or customer of one of their clients, get in touch.

Fish & chips?

Such an innocuous phrase which should have led to an evening in front of the TV with the better half.  Instead, a nightmare ensued; endlessly contacting several local eateries to alert them to a very serious problem.

Tiffin Tom is a "Just Eat" style, online food ordering service with hundreds of local businesses.  Just enter your postcode and a world of artery-clogging yet convenient food awaits.

Unfortunately, it's also a sure-fire way to have your identity & payment information stolen - very, very quickly indeed.

After Googling my local Parkhill Fish Bar, https://parkhillfishbar.co.uk/ appears as the first result.  I began adding items to my basket before the site asks me to register.

Note: As Parkhill Fish Bar took immediate action and requested the site be taken down on the day I notified them, the images used throughout this article will show another company, Major Curry Affair, who I also notified.  Their site remains live.

Pandora's Box

Before you order, the site makes a database lookup to get the takeaway's details; opening hours, minimum order values, service area etc.

It returns data like this:

Nothing wrong so far... until you scroll down.

Let me make sense of that for you...

I asked to register.  Instead, Tiffin Tom gave me full, unfettered access to their Google, Firebase, Facebook, Twitter, MailChimp, Text Magic, Click Send, Pusher, Email, PayPal & Stripe payment accounts!

You'd be forgiven for thinking, they're obviously fake, outdated or canaries, right?

A quick call to Stripe's API confirms... I'm their latest customer.

Sure enough, every single credential is live, working and leaking every single piece of customer information.

Full names, addresses, email addresses, phone numbers, order history, payment information including card data... literally everything you hand over is visible to the public.

Ignorance is bliss.

It's been a while since I've seen an application do something so blatantly stupid & dangerous - not since Police CyberAlarm in fact, when they returned user passwords in plain text.

At this point, I obviously didn't place an order and immediately visited Parkhill.  Parkhill's our local and whilst we don't visit often, it's always our go-to place for fish & chips, so I already knew Baljinder, the owner.

Once I'd outlined the issue to Bal, he promptly called Jamal Ahmed, the "Director" of Tiffin Tom Ltd.

Note: I've put Director in quotes, for reasons I'll explain shortly.

Bal explained & relayed the information to Jamal, but we eventually ended up on speakerphone, during which I explained the entire system was exposed, Stripe keys were breached and everything should be taken offline immediately.  His immediate response was "we've not been breached", a line he continues to repeat to every business I've notified.

However, he promised to take Parkhill offline and remove their data.  I also agreed to email & call the following day with more concrete information.

The "fix"

The following day, I started pulling the rest of the service apart.  However, during a mandatory due diligence period, I noticed something odd at Companies House.

What?! No Directors whatsoever?

Jamal resigned in July 2022 - meaning the company has been "trading" illegally ever since.  It's probably why Companies House have tried to strike off the company - that and a lack of accounts/confirmation statement, but someone's lodged an objection, so the company remains active with no leadership.

Curve ball

This is a situation I've never faced before.

Normally, I'd hand over all the supporting evidence to the company and let them resolve it.  Now however, I can't - legally at least - because Jamal is no longer the Director he purports to be.

A quick call to the ICO and they too are equally stumped; asking me to forward a complaint but with no guarantee of any action because of the unique circumstances.

One thing was for sure however... the businesses using Tiffin Tom were still liable for sizeable fines, something I'm trying to avoid.

Anyway, I digress... let's move on to the "fix".

Despite claiming (and continuing to claim) there has been no breach, Jamal did admit he'd "found a few things" which his developers were fixing.

A few days later, the database call which prompted this mess changed significantly.

They've clearly found and discussed the problem (keep in mind, I didn't tell them where it was) - but their "solution" is equally as pathetic as the site itself.

Instead of returning the critically-sensitive details in plain text, they've encrypted it.  However, the astute amongst you will have already surmised... if the site is decrypting the results to populate forms/javascript, the encryption key must be accessible in the DOM.

Sure enough...

Decrypting the data is as simple as Googling "aes decrypt"

Sigh.

OK, they tried... but not particularly hard.  They didn't even change the exposed secret keys!  They've just encrypted the existing, leaked keys - then told customers there's been no breach!

I rarely get angry, but this piss-poor effort continues to place 21,000 customers at immediate, demonstrable risk and instead of holding their hands up, apologizing and making a reasonably-competent effort to fix it... they've lied & covered it up.

Now, Jamal told Parkhill that his site was offline (confirmed) and his data had been removed.  That however, is a lie too.

Instead of doing what was legally required, Tiffin Tom have simply hidden Parkhill from search results.

All the PII & payment data - which places Parkhill and countless other businesses at risk of huge fines - still remains in the database.

Tip of the iceberg

Believe me when I tell you, this is merely the tip of the iceberg.

The site is festooned with the most rudimentary of security flaws; stored XSS, CSRF, iDOR, broken authentication, session hijacking - it's a perfect little CTF competition masquerading as a business.

Did I mention, they offer debit cards & payment machines too?

More denials...

After finishing my research, I notified Bal @ Parkhill of the further findings, prompting him to contact Jamal again.

His response, as of the 28th June 2023.

Summary

I've researched some pretty egregious sites in the past but this one... it takes some beating.

If you value your business, your customer's data or simply want to avoid a colossal fine from the Information Commissioner's Office, avoid Tiffin Tom/Ubsidi/Nibs Solutions at all costs.

Ya know the worst part? After explaining all this, my chips were cold. Oh, the humanity.

FAQs

1)  I run a business and have a Tiffin Tom account. What should I do?
a)  Notify Tiffin Tom Ltd immediately and request the full & immediate deletion of every record associated with your business, but not before requesting a copy of all logs - as you'll likely need them for any ICO investigation.  Technically, there's nobody steering the ship - even legal action won't help, but you may get results.

2) What if Tiffin Tom doesn't respond, or refute this?
a)  Legally, there's nobody to respond.  Jamal had been very receptive, but clearly doesn't understand the risk of running a Ltd company in breach of CA 2006.

3)  I've placed an order with a takeaway, am I affected?
a)  If they use Tiffin Tom, almost certainly.  Look for "copyrights tiffintom" in the footer.  If you're concerned your details may have been exposed, please contact me privately.  In any event, your payment details should be considered compromised and you should cancel your cards.

18 months ago, I reviewed two versions of Police CyberAlarm; their pre-release "development tool" and a production variant.

After many hours of reviewing some of the worst code I'd seen in quite a while, I reached two conclusions.

1) cyberAlarm is woefully insecure
2) Pervade, the developer responsible, were incompetent

If you've followed this saga, you may recall I responsibly disclosed everything to the NPCC and Pervade.  However, their responses were both defensive & dismissive; to the extent of telling the public I'd reviewed the wrong product entirely and my claims were "completely untrue"

Until recently, that was the official line to anyone who raised my initial review during webinars/support calls.

Thankfully, that ends today.

Over the last 18 months, I've received a steady stream of emails/DMs from users/EDUs/firms, many of whom were rightly concerned about what they'd read.

In February, a network admin from a local School reached out, asking me to audit cyberAlarm again.  Unfortunately, time & COVID had other ideas... forcing us to wait until March 16th before we could exchange files/details.

March 16th 3.15PM

I received the files and fired up the virtual machine.

Once again, the files are Ioncube encoded to "hide" the contents - which took all of an hour to reverse.  I began looking through the decoded files, instantly spotting several critical flaws.

Over the next couple of hours, I created a list of serious issues which Pervade, Prism Infosec & Arcanum Cyber Security have supposedly missed.

Let's dive in.

Insecure Passwords

You may recall that I notified NPCC/Pervade back in 2020 that SHA256 wasn't secure or appropriate for password storage.

So, 18 months later... is it any better?

Well, locally stored passwords are still hashed with unsalted SHA256... but incredibly, Pervade have actually made it worse.

A logic flaw in "index.php" means passwords are actually sent to AND RETURNED FROM the central API in plain text!  This isn't an API running on the data collector either - it's centrally operated at https://collectors.cyberalarm.police.uk/OPVIEW/API

Above is a response from an API call to fetch a user's details.  You're not obliged to set a password on the data collector, but even if you do, an attacker can simply request it from the API.

Insecure Session Tokens

Before a cyberAlarm data collector carries out any request, it checks to see if a session variable exists... called "token".

If it doesn't exist, it creates one and attaches it to the user's session.  Here's the snippet of code responsible...

The token is created using two PHP functions.

1)  "time" returns the number of seconds since the Unix Epoch (Jan 1 1970)
2) "rand" returns a random number between & including 1000 and 9999

Spotted the problem yet?

Any attacker can remotely control the box if they know the current time and can count to 9,000! Must. Not. Insert. Meme.

https://datacollectorIP/?token=16478839932011
https://datacollectorIP/?token=16478839932012
https://datacollectorIP/?token=16478839932013
https://datacollectorIP/?token=16478839932014

… and so on.  As with password brute force attacks, we rarely need to search the entire space for the correct token.  In reality, we often see a successful response after just 50% or 4,500 requests.  To a local endpoint, this takes around 2.5 seconds to complete.

The logic which checks the token's validity looks like so...

So if the token doesn't exist or doesn't match, "exit" the PHP application immediately.  Don't worry about writing it to a log or limiting further requests... just abort and let the attacker try again. Sigh.

In short, cyberAlarm can withstand an attack for a maximum of 5 seconds.

But who's got 5 seconds to XSRF a data collector, I hear you cry?  Ain't nobody got time for that.

Let's just ask the API to do it instead!

Unauthenticated API

You read that right.

The central API has no authentication whatsoever!

Want a customer's records? Sure.

Make a GET request with the data collector's ID and it just hands it over.

Names, email addresses, the aforementioned plain-text password, telephone numbers, timestamps, which IPs they scan, how often they're scanned... basically everything you've entered into the data collector.

But that's a GET request... what if we POST with the same JSON?  Surely we can't update a record without authentication?!

Of course we can!  Give it the data collector's ID (it's the primary key, for those who understand databases) and the central API updates the record.

To make matters worse, these changes are then sent to the data collector (including the password!).

So, what can we do with such limitless access?

1) Redirect monthly vulnerability reports to the attacker
An attacker can now set the "reportingEmail" address, so if cyberAlarm does detect a 0 day, the attacker is the first to know.

2) Set someone else's scan IP!
An attacker can also manipulate which IPs are scanned for vulns.  That'll make for an awkward discussion when an NPCC/Pervade server starts scanning another gov't agency ;)

What's stopping an attacker from entering your competitors IP instead?  NPCC/Pervade will almost certainly breach the Computer Misuse Act by actively testing for 0 days without consent of the owner... and the data collector's admin isn't the owner.

3) Download any/all reports
Somewhat unsurprisingly at this point, it's also possible to download any PDF report for any data collector, without authentication.

What better way to increase your risk significantly than to hand your attackers a list of vulnerabilities!

No XSRF protection

Echoing my 2020 article, cyberAlarm still has no adequate XSRF protection... allowing an attacker to remotely breach/control any CA installation.

Of course, nobody is likely to bother with this slightly more difficult attack while the API is so willing to comply... but after 18 months, I hoped it'd be safer now.

Passwords aren't timing safe

At this point, any hopes of a safe & secure authentication scheme are long gone.

However, if you're going to compare two password hashes, it's vital to compare them using a timing-sensitive comparison.

Rookie mistake #3,251,901.

As Pervade use a direct string comparison, it's possible to leverage the metadata of a failure (here, the time it takes to fail) to work your way closer to the real credential.  PHP created "hash_equals" for a reason.

Broken crypto, AGAIN!

Here's a code snippet showing how Pervade "encrypt" your data.

If you understand cryptography, you're likely shaking your head in disbelief right now.

You see, Pervade's limited grasp of security/cryptography throughout the entire app leads us to an inevitable issue here.  The use of AES-256-CBC isn't an issue in itself; it's entirely possible to deploy CBC safely & effectively.

Unfortunately, Pervade has made a complete hash of it.

After you've encrypted your super sensitive message, it's absolutely imperative to add an HMAC or Hash-based Message Authentication Code.  The HMAC allows the recipient (the central collector, in this context) to verify the authenticity of the message, as it's possible to manipulate ciphertext whilst in transit.  This is a well-known/understood attack called CBC bit flipping.  Without it, you can't rely on the authenticity of the data and as such, it should be discarded.

It's 2022.  It's reasonable to expect Pervade to have use a modern AEAD cipher; something which supports authenticity checks natively... but for whatever reason (lack of knowledge, perhaps?), they've tried to roll their own crypto; breaking the cardinal rule of cryptography.

There are only two possible outcomes here. Broken... and very broken.  Guess which category Pervade's code falls into? ;)

Rolled their own? They've used PHP functions!

At first glance, you might think that's a reasonable counter-argument... but let me explain why it's not.

There are countless crypto libraries out there... many peer-reviewed & trusted.  Pervade may have used the same underlying functions, but they've done so in a way which falls right into the hands of an attacker.

The devil is in the detail.

This line sets the initialisation vector - a crucial step in the encryption process.

There are two functions, one nested.

1) openssl_cipher_iv_length
2) openssl_random_pseudo_bytes

#1 returns the length (in bytes) for the given cipher, or false
#2 returns random bytes of the given length, or false

I emphasise "or false" because it's equally vital to ensure the data is as you expect.  Whilst #1 can fatally fail (resulting in a crash here), #2 can fail with a warning (which are turned off) but PHP still encrypts the value... with the $iv as false.

What happens when the $iv is false?  Every single record is encrypted using a static key and no IV! Great!

Introducing OWASP - The Open Web Application Security Project

Web developers often build applications mindful of the OWASP Top 10 - a list of common vulnerabilities collected from multiple sources.

For 2021, the top 10 looked like this...

Keep in mind the scale of the cyberAlarm's data collector.

It's a single HTML form "protected" by a login page, with a spec-driven data collector bolted on.  It's about as simple as it gets.  Almost incredibly, Pervade has managed a solid 9/10 categories - and a straight 10 if we include flaws from 18 months ago.

In my view, there are only two ways to describe such an app.  Woefully insecure... or a CTF competition.  Seriously, this would make a great capture the flag application for rookies looking to cut their teeth.  I make that distinction for a reason; these really are rookie-level issues made by a firm I can demonstrate are devoid of a clue.

Speaking of CTFs

It's all well & good endlessly parroting that Pervade are clueless, but that's an opinion based on their code.  So, I set out to prove myself wrong.  I joined their Cyber Wales CTF Cluster webinar, hosted by John & Jason of Pervade.

This webinar from April 2021 is intended to teach viewers how to defeat XSS attacks.  Unfortunately, it's one of the most tortuous & mind-numbingly misinformed webinars I've ever witnessed.

It's an hour and 15 minutes long but it really is hand-bitingly awful to watch; demonstrating a total lack of understanding of XSS and various other bits.

Don't have an hour?  Let me break it down for you.

12:59 - John (Director at Pervade, "joking" that he'd alter a pen test report so basic flaws like this wouldn't appear - many a true word....)
14:10 - Lacks basic understanding of IFRAMEs.  Tries to load sites on the wrong protocol & sites which expressly prohibit framing with CSP (bbc, google etc).
30:00 - Literally clueless.  Seems to think javascript won't execute after a page has loaded, so "no dynamic stuff".
31:00 - Seems to think this XSS attack is happening "server side" and because it is, we can now "insert code which does something"
31:24 - This isn't being "executed" by the server, what is he talking about?
32:03 - Genuinely believes a client-side language is being executed on the server.  Is PHP node now?
33:25 - Just throw "htmlspecialchars" at everything - job done.  Forget quotes, forget context - but at least he's doing it on output.
34:07 - Immediately renders the fix useless by running it against the inputs, not the output.  This demonstrates a fundamental lack of understanding.
34:33 - Oh good lord, they're using the same technique for SQL injection mitigation!

ADVANCED (BUT EQUALLY STUPID/INEFFECTIVE) BITS

35:15 - Using regex (preg_match) to find "the bad characters".  Bad characters in what context?  Again, missing the point entirely.
38:10 - "Sanitize our inputs so it can't do anything dangerous to us" - Sigh
38:32 - "We can also replace the bad characters" - This guy is the Director of Pervade, a "professional" company which provides apps for the Police, NHS etc.  Think about that for a moment.
40:15 - Demonstrating a "stored XSS" attack - with fails aplenty.
47:00 - "You can do that on any page on the planet.  There's actually no way for me to stop you doing that" (referring to inline XSS).  Again, fundamental lack of understanding of basic security controls.  A CSP (Content Security Policy) header is literally designed to protect against attacks like this, but it's the same CSP he couldn't figure out whilst trying to embed an IFRAME earlier.
48:55 - Genuinely seems to think he has to alter his code syntax to allow different inputs.
53:28 - Me asking him to demonstrate how to protect against XSS in his own code - he REMOVES THE BAD CHARACTERS! Writes software for Police/NHS remember!
56:13 - "To secure it, once again, it's one word - same as SQL injection" - Christ above.  I give up.
1:05:30 - I ask him to explain how an application which requires characters which allow XSS, can protect against it.  He goes on to explain nested ifs, database calls etc.  An IF statement for every possible input - seems scalable!
1:09:50 - A glimmer of hope - "You can actually do this on the other side" - Referencing output encoding, which is actually how it should have been done an hour ago.

This video (along with several others) is definitive proof, straight from the horses mouth, that Pervade fundamentally do not understand secure coding practices.  The issues I've identified here aren't mistakes - they're the result of a gov't funded team completely out of their depth.

Remember, these guys run the Cyber Essentials platform... oh, the irony.

Responsible Disclosure

After the 2020 debacle, I'd hopefully be forgiven for simply publishing these issues without speaking with NPCC.  After all, my disclosures were discarded as a "waste of public money" and I was accused of operating in bad faith.

However, the goal of disclosures like these is to protect the public - not to put them at direct, demonstrable & increased risk.  That, combined with the severity of the vulnerabilities, left me with little choice but to notify the NPCC again.

However, here's how the story takes an interesting & positive turn.

March 18th 1:40PM

After briefly speaking with Ian Hickling on his mobile earlier in the day, he escalated the matter to Phillip Donnelly, Cyber and Darkweb Technical and Capabilities Lead @ NPCC.

I'd spoken to Ian & Phil back in 2020 and both were polite & helpful, but communications quickly turned sour when Pervade pushed back with lies & misleading statements... leading NPCC to believe my claims were untrue.

I requested a video call with Phil that day and to my surprise, he agreed.

Later that day, Phil and I spent a good hour on a Teams call - during which I explained every issue and demonstrated each attack, live, via screen sharing.  No room for movement or disagreement this time; every attack worked exactly as described.  By the end of the call, it was clear I could control any data collector and the API.  I advised that CA be taken offline immediately, as the risk to the public was/is very high.  Whilst Phil didn't agree/disagree on the call, he later emailed to advise that parts of the API were taken offline and members were notified as such.  In reality, NPCC mitigated several risks within 1hr of our initial call - simply by taking parts of the API offline.  Say what you will, that's impressive.

Let me clarify a few things, before I go any further.

Phil's approach both initially and during conversations even now is absolutely spot on.  His candid & measured response makes disclosure much easier.

It has always been my belief that NPCC have been & continue to be misled - even hoodwinked.  Whilst their response to my 2020 review wasn't great, I can somewhat understand & justify it given the information coming from the other side.

Mindful of our previous discussions and how several vulns disappeared despite "never existing in the first place", I took a different approach this time.

Before contacting NPCC, I'd already been in touch with various media outlets & several other security testers, all of which have independently verified these findings.  They may be running the story shortly too.

What next?

Over the coming days, Phil/NPCC realised these issues needed further investigation and clearly weren't willing to trust Pervade or the existing security firms.  Instead, they sought the assistance of another independent security auditing firm.

I won't name them just yet (possibly not at all), but I have absolutely no doubt in their abilities to highlight not only the above, but far more.  Their report is a paid engagement however, so I'd certainly expect better results when compared to my freebie to an EDU.

An email from Phil later requested another video call, this time with the external testing company.

March 25th 10AM

I join a call with Phil & <redacted> from the external security company.

Once again, we go through each & every issue - demonstrating them with proof-of-concept files and providing screenshots showing payloads which were working, prior to the API going partially offline.

I have something of a reputation for telling it like it is; some appreciate it, others (perhaps rightly) see it as slightly unprofessional.  The external company on the other hand... took notes, asked questions and remained professional throughout, refraining from comment until their own research was over.  So far as I'm aware, their investigation is still ongoing and cyberAlarm remains live.

That however, is where we disagree and is the reason this article exists.

My advice, both now and 18 months ago, was to pull cyberAlarm immediately, believing it to be a dangerous application which only increased the risk to anyone who installed it.  Understandably, NPCC's position differs and every effort is being made to patch these issues and keep cyberAlarm going.

During conversations back & forth, NPCC cited a common 90 day period before any disclosure.  They didn't request it, to be clear... but merely referenced it - perhaps hoping I'd refrain from publishing until they'd had time to investigate.  Normally, that's perfectly reasonable.  However, I've been barking about cyberAlarm's vulnerabilities/risks for 18 months... to no avail.  NPCC had the chance, 18 months ago, to do the right thing and pull cyberAlarm from service.  Now, the number of customers has increased and so have the quantity of vulnerabilities.

Now, my position couldn't be clearer.

CyberAlarm is profoundly dangerous.  It's woefully insecure, ill-conceived, poorly written & provides questionable value.

Whilst I welcome the news that NPCC have engaged another security firm, I sincerely hope they take this opportunity to see cyberAlarm/Pervade for what it is; a one-way ticket to a serious breach.

April 14th 11:24AM

I received a reply email from Phil Donnelly at NPCC requesting 90 days before disclosure, citing the need to wait for a report and mitigative action.

I refused on the basis that nearly all of these vulnerabilities existed 18 months ago but were ignored, "never existed" or "weren't a security issue".  Even so, I've given 30 days which I believe is perfectly sufficient given the risk/circumstances and likely far more than any other researcher would provide, given the initial response in 2020.

Phil again cites "I've been assured that several points are not possible due to other checks" but still will not disclose which ones, or why.  I have left no room for argument this time; he's seen every exploit on a Teams call with screen share.

Summary

Pervade has had 3 attempts and well over 18 months to develop cyberAlarm into something resembling a decent, secure & deployable application and judging by this latest iteration, it has utterly failed to do so.

Whilst NPCC's response on this occasion has been entirely commendable, their latest communication outlines their need/desire to "get it right", but go on to discuss "mitigation" following the independent report.

In my opinion, the NPCC needs to shutter cyberAlarm at the earliest opportunity and turn their attention to other projects outsourced to Pervade, including the Cyber Essential platform.

I sincerely hope this signals the end of this utterly shambolic debacle.  If pride precedes privacy again, expect another article in a few years.  If NPCC decides to revert to type and tries to refute this article, there's a growing number of media outlets & security researchers ready & waiting to fully disclose; that really won't be pretty.

This article and all findings within are the result of one anonymous network admin who remained open-minded & professional enough to push back against the "official line" and wanted an independent audit before putting his staff/students or network at risk.  If this has helped you, please pass on your thanks in the comments below.

If you're in a similar position, please get in touch.

I can't honestly recall the last time I was left seething with rage; I'm not an angry person.  That said, I've never been called a liar or been accused of acting in bad faith by the NPCC before... but hey, the increased heart-rate should burn a few much-needed calories.

Following my review of the infamous "development/test build", NPCC published an article stating it's "completely untrue", how it was "a completely different piece of software", how it "has never formed part of the Police CyberAlarm system in ANY live version" and I "stumbled upon" the development link.

Their rebuttal pivots on two issues:
1) I "stumbled upon" the development link, therefore would have known it wasn't CyberAlarm.
2) The production version isn't based on the development "tool" (which doesn't make sense), thus it would "be impossible to find the issues raised".

I've made every effort to protect the force's reputation and the public, even extending the metaphorical olive branch after the first (of two) insulting cease & desist letters, but I'm left with no choice but to publish the entire debacle in an effort to salvage my reputation.

This is likely to be an enormous post, but I will try to keep it to a minimum; it's not intended to be a sedative.

I don't want to spend too long discussing the "development/test build" as I've pretty much covered everything I could responsibly mention in my previous post, but in order to explain exactly what's happened, I need to go back to the beginning.

30th September 2020:

12.41PM

I filled in the "registration" form on the official CyberAlarm website and received an auto-response.

2nd October 2020:

9.48AM

I received an email from Leicestershire Police, apologising for the delay and attaching 4 PDFs which include sample reports, threat summaries etc.

11.22AM

I replied, asking for an installation guide.

6.41PM

I received a reply with the installation guide attached.

7.22PM

I downloaded the installation guide.

... then replied to <redacted>

Here's a snippet of the installation guide, or you can view the offending article yourself from my backup.

Keep in mind the filename of the PDF... ending "310720" which obviously refers to date it was updated.  Assuming they've sent me the most recent installation guide, that's the last time it was updated.  For 2 months, this has been the document members receive.

You might be wondering why I think it was updated, rather than created on that date, but I'll come back to that.

If you take a look at the "downloadable" URL - it clearly shows "https://www.cyberalarm.police.uk/CyberAlarm.ova" which is the production build.

So, how did I end up with the test version?

The astute amongst you may have already surmised; in some applications, updating a hyperlink merely changes the visible text but leaves the original URL in the background.  When you hover over the link, the truth is revealed.

Although the text says "cyberalarm.police.uk", the actual hyperlink takes you to "cyberalarm.org.uk" - housing the dangerous internal build!

Of course, they refute the existence of screenshots too & claim I've never pointed it out, despite two members of staff actually thanking me for raising it! (proof of that later, so as not to confuse the timeline of events).

This is absolutely irrefutable proof that, contrary to NPCC's claim that I stumbled upon it, I simply used the link they provided by email.  They go on to claim it would have been obvious that it wasn't a "real" CyberAlarm data collector, having later seen the "production" one.

Spinning up the "test build" VM:

There's the one & only UI.  The PDF said "CyberAlarm", the website said "CyberAlarm", the filename is "CyberAlarm.ova" and the UI says it's..... CyberAlarm.  But, I'm expected to know it's a demonstrably dangerous, internal build of an "OpView Collector".

8.50PM

The last hour and a half were spent dissecting the image, uncovering an astonishing array of mind-blowingly awful code, disabled security controls, outdated dependencies, insecure endpoints... just about every rookie mistake a developer could make, all lovingly packaged into something they expect the public to run on their internal network.  I'll bet Huawei's code isn't as bad as this... but I digress.

Needless to say, I emailed back to say I couldn't recommend this to customers.

Let me be the first to say that without context, that was an unreasonable comment and I wouldn't have expected them to action it without investigating themselves.  However, it hopefully does show that whilst the main aim was to protect the public, I was also mindful of the huge reputational damage this would do to member forces and the NPCC.

However, as the scale of their incompetence began to sink in, I realised I couldn't just leave it there and needed to report it formally.

3rd October 2020:

2.57PM

I called <redacted> (from Leicestershire Police) on the mobile number (also redacted) from his email above.

Despite being a rest day, he thankfully took my call and listened as I outlined everything I'd seen thus far.  As expected, he asked me to put my findings in an email which I did shortly after.

I won't post the entire screenshot, as it's identical to the previous article.

3.12PM

He replies to say he's discussing the issues with the developers.

5.15PM

An update! That was quick!

So quite apart from being "a completely different piece of software", it is indeed the proof-of-concept/development version which formed the basis of the current CyberAlarm platform.

Pay careful attention to the statement "none of the below codes/passwords/URLs you have mentioned have anything to do with the CyberAlarm system", referring to "P3rv3d3" and "P3rv4d3S0ftw4r3" from my disclosure email.

But, my concerns have apparently prompted a full penetration test... so that's job done, right?

5.32PM

6.52PM

At this point, they appear to be taking it seriously.

I'll snip out the dialog of us finding a suitable time/date for the teams meeting, but it ended up being 5th October 2020 @ 4PM, lasting well over an hour.

5th October 2020:

3.54PM

I dialled in to the meeting with <redacted> ready & waiting.  Over the next hour or so, we discuss the outcome of their investigations, why none of it applies to the production version (in their view), how I "found" the URL to the test build and TL;DR - <redacted> uttered the phrase which will likely lead to the cancellation of this platform.

"We don't consider these to be deal breakers..."

I'm not paraphrasing either.  That's verbatim.

What?! I was absolutely dumbstruck.

I've no idea if it was an attempt to placate me (not that I was hostile in any way), but <redacted> also asks me to join CDSV (Cyber Digital Specials & Volunteers); the replacement for the CSCV programme which was pulled a while back.

During the meeting, <redacted> generated an "access code" to allow me to download the "production" build and asked me to review it.

To protect myself, I asked him to put his request to review it in writing... which he emailed shortly after.  It always pays to be careful... as disclosures can very quickly go sour.

Hang on, rewind!  Look at that download URL...
"cyberalarm.police.uk/download/cyberalarm.ova"

The "installation guide" PDF earlier didn't mention "/download", so if you clicked their address, you get a one-way ticket to network compromise (or the "test build") and if you copy/paste, it 404s.

Download Link Broken: Check.

Intermission

Are you still here? Wow.  Let's take a breather for a moment and discuss where we are so far.

I've proven NPCC literally gave me the offending URL, so let's not go over that again.  I've also demonstrated that I followed a fairly typical responsible disclosure process & they acknowledge my attempts to report the issues.

But, I'd like to take a step back to posit a question...

If this is a "2 year old test build" which "is not used anymore", why was it last updated in May 2019?  Are we to believe they stopped using the product immediately after development? Of course not.  I'd hope it'd be passed to beta testers, a QA team, pen testers etc.  Realistically, mindful of how long it takes to launch a product like this in a Police force, it's likely to have remained in use for many months after.  I can't prove that, but I think it's a reasonable assumption.  Strange too they'd buy a TLS certificate to protect an endpoint they don't use, but perhaps that's to prevent redirect errors. Who knows.

Another question too... who ioncubes their own internal development builds?!

OK. Deep breath... let's dive back in.

Testing the "production build"

It's still October 5th, keep in mind.

I downloaded the installer and immediately opened the bash script, revealing this...

The installer is plain text - easily visible to anyone, as opposed to the actual code which is still encoded.

There's two vulnerabilities, right there! 1024 bit RSA and TLS security checks disabled... on the damn installer!  I pointed both of these out in my email about the "test build" but they claim it doesn't apply to production.  If an attacker can trick your box into downloading any ol' .tar.gz, you're vulnerable to all manner of exploits, including the aforementioned RCE.

After decoding "index.php" from the file which the installer grabs (insecurely), a similar trend begins to emerge.

TLS security checks, disabled.
Server "secret": "P3rv4d3S0ftw4r3".

You'll note, that's the same insecure "secret" which Pervade claimed didn't exist in the production version.

Okay, okay... that's just the registration script. Is server communication safe?

Yet again, TLS certificate checks are disabled everywhere.  This is beyond debate.

Wait a minute...

The CURLOPT_URL parameter is calling an IP.  Hmm... do they really have IPs in their certificate CN (common name)?

Not that I could find, or you wouldn't see an error like this.

Note, this is the IP address of the "cyberalarm" public site and this particular image is used as an example only.  The system actually calls a "system API" URL on a URL I'm not prepared to release, but that too has no IP addresses in the CN.

Regardless, I try registering on the Police collection endpoint (previously located at <force_area>.cyberalarm.police.uk>.  Do not confuse this with the local data collector software above... this is now the admin UI which the forces have access to; looks a little something like this.

Ahem... good luck making sense of that mess.  You could cogently make the argument that if the system delivers "actionable data" like this, forget security... it's probably worthless.

5.27PM

Before you get there however, you need to click the "validate email" button they send.

Note the double protocol, making this a dead link.  I later reported this one too.

Registration Link Broken: Check.

6.11PM

The first "thank you" for reporting the dangerous URL.

6.12PM

The next few days are spent relaying issues to <redacted> until finally, I'm told an independent penetration tester could not confirm any of the issues I'd raised.

I'll leave out the back & forth which followed, but TL;DR (huh - too late for that) they flat refuse to accept any of the issues I've raised affect the production version.

By now, I suspect <redacted> was growing tired of me parroting the same line, only to hear the same response.

8th October 2020:

3.29PM

I'm starting to smell a rat... so I download the installer again.

Hmm.  They updated the installer the day after I reported the production build was insecure.

You can probably guess what's coming, but don't get ahead of me.  Will they continue to claim I'm wrong?

9th October 2020:

3.47PM

I receive an email, out of the blue, from another NPCC Cybercrime Programme member.

By now, I'm losing my patience.

6.37PM

Note: I've redacted a paragraph, as it relates to an on-going investigation which isn't suitable for wider release.

Let me explain the above... because I reference the issues in the "test build" and I don't want any confusion.

Mindful of the them putting the wrong URL in the PDF, it's entirely logical to expect anyone in receipt of it would install it, as I did, believing it to be "CyberAlarm".  With no formal update process and no notification from NPCC, that would remain the case.  I explained the other issues directly related to the "production build" in prior emails to <redacted> and the other <redacted> from October 2nd.

Remember, this "test build" can't talk to a server for updates... it's been decommissioned "2 years" before I installed it.  If it IS running anywhere, it'll stay that way until it's either removed or worse, an attacker leverages it.

They claim this version was "never released or promoted by anyone, least of all the Police" - and we now know that to be inaccurate... so I disagree with the suggestion there's no risk to the public.

13th October 2020:

5.19PM

The admission, in black and white, that the Police accidentally made available a massively-insecure "test build" to the public and said nothing.  No article, no email, no "oops, we screwed up, don't install that"... just silence.

Worse still, they don't seem to understand the risk it presents... so you can understand why I'm finding it impossible to outline why the "production" build is equally insecure.

Intermission #2

If you're still here, thank you.

I know there's a huge amount to take in and believe me, I've cut this down to make it somewhat readable.

Let's recap...

Two members of the same force acknowledge I raised the dodgy URL and both thank me for alerting them - a world apart from NPCC's claim that I merely "stumbled upon" it.

The same force admits they released a insecure build and to date, I'm not aware of a single publication to alert the public.

The force/NPCC remain confident that PCA is secure.

Grab yourself a brew and let's dive in one last time.

24th November 2020:

I publish my findings, primarily focusing on the "test build" but referencing the same vulnerabilities (but different method of execution, in some cases) in the production build.

There's a much greater chance the production version is more widely deployed, so I redacted key elements to ensure I don't become the purveyor of zero-days.

25th November 2020:

6.42PM

NPCC send the first cease & desist letter.

TL;DR - "You're wrong, you knew you were wrong - pull the article by Friday 5PM, and stop using our image, you're breaching copyright"

9.08PM

I reply.

26th November 2020:

4.30PM

Even after the ugly & unnecessary cease & desist, I tried one last time.

8.33PM

NPCC respond again, with another cease & desist... which you've all now seen, as it forms the majority of the official response they published.

In the second C&D, <redacted> questions why I didn't post the first C&D letter, which is a reasonable question.

I didn't post it because it's highly embarrassing for both NPCC and <redacted> and, as I said from the very beginning, I was trying to protect NPCC's reputation whilst following a normal disclosure process.  I had assumed that the "olive branch" email I sent in return would make them step back, reconsider and perhaps question why someone would willingly commit career-suicide in the public view, by releasing demonstrably false information.

Alas, no such luck... just more threats and a libellous retort.

27th November 2020:

6.46PM

I pull the installer again, just to see if any of the other issues which don't exist... don't exist anymore.  It was modified on the 14th of October.

29th November 2020: Lies, deception and defamation...

Something just doesn't add up.

We have the NPCC Cybercrime team filled with respected professionals, actively pushing a product which I can repeatedly demonstrate is woefully insecure.

Let's open that update from the 6th...

Sigh.

The 1024 bit RSA key is still there, but they've fixed the vulnerable "wget" call... so the installer is now safe(r).  The app however, still has TLS verification disabled.

Swing and a miss.

I'd already caught them out once when Pervade stated the laughable "secret" key from the "test build" didn't exist in production.  Now, they're at it again.

Someone at Pervade (it really doesn't matter who) is actively patching the very issues I raised the previous day... but claiming they were never there.  Utterly abhorrent behaviour.

They say trust is a fickle thing.  Whilst I might be able to overcome the hideous code, if they're willing to lie, repeatedly - and put the NPCC's reputation at risk, it's game over.

Confirming my suspicions...

Let's open the installer from the 27th... (which is the latest, as of this article)

They're using 2048 bit keys! Colour me shocked.

What about index.php?

They validate TLS too!  It's a mess elsewhere, but let's brush over that for now.

I can't see the infamous "P3rv4d3" server secret either.  Things are looking up!  I still wouldn't trust it, but at least they are patching bugs, even if they didn't exist to begin with.

I really should try to cut down on sarcasm, it's not a good look.

Though, if someone more talented than I could explain this laughable bit of obfuscation, that'd be great.

What about the CREST STAR / NCSC-approved "pen test"?

Your guess is as good as mine.

Whilst it fits with the theme to simply bury the testing company, it's not beyond the realms of possibility that Pervade provided an entirely different or scaled-back application, limited the scope or even lied about the results.  It's also possible the testing companies (there are apparently more than 1) are useless.

Keep this in mind...

There's a world of difference between "we found no issues" and "there are no issues".

It's also possible the testers found all of it (and more - there's plenty) and Pervade/NPCC simply ignored the experts and carried on.

Take this gem from their official response, for example...

I assumed (how stupid of me, by now) that a direct quote from a Red Hat expert would make them reconsider their ludicrous decision.  If someone describes Linux as a footgun, it's probably not a good idea to play around with security controls that you clearly don't understand.

I could try again but let's face it, I'm a nobody.

So, I'll hand over to Mr Karanbir Singh.

Karanbir is widely credited with shaping the CentOS project as we know it today.  He's not just a contributor, he's the project lead.  I can't think of anyone better placed to convince the NPCC team that they're not only wrong, they're dangerously wrong.  Keep in mind, SELinux is disabled in the production builds!

So do I, but I don't expect them to be forthcoming.

I offered to sign an NDA but even then, the source & pen test reports were "not for public record"

I could continue posting each & every vulnerability, but I think I've made my point.

One last thing though... breach of copyright for using the CyberAlarm logo?! If this isn't the definition of a criticism/review, I'm not sure what is.

A couple of things I really should have mentioned...

A few people have (correctly) pointed out that my claim that PHP 5.4 was insecure isn't always true.  This is a nuanced topic & one I actively wanted to avoid, but I'll try to explain as quickly as possible.

Official vendor support for PHP 5.4 ended 5 years ago.  Official support for PHP 7.2 ended.... on the 30th November 2020 (seriously!).  The vendor's (The PHP Group) official advice mirrors mine; upgrade as soon as possible because there may be unpatched security vulnerabilities.

However, it's not quite as clear cut and although I don't condone relying on backports, I should have explained it more clearly.  Just as you may opt for an "extended, 3rd party warranty" with your latest iPhone, platforms like RedHat/CentOS provide something called back-porting; the process of actively monitoring for new vulnerabilities and retrospectively rolling patches in to previous versions.

This is often misunderstood and causes no end of confusion, largely because whilst the official version stays the same (5.4.16 for example), the subversion (-xx) is often hidden from a standard "phpinfo" or "php -v" command.  As a result, patches are often missed and vulnerabilities (even if you're responsible enough to update) remain unpatched.

Of course, that's the case here too.

The "test build" from October 2nd 2020 is vulnerable to the following...
CVE-2018-10547 (CVSS 6.1 Medium)
CVE-2018-5712 (CVSS 6.1 Medium)
CVE-2019-9024 (CVSS 7.5 High)
CVE-2018-7584 (CVSS 9.8 Critical)
CVE-2019-11043 (CVSS 9.8 Critical)

2 "critical" issues - never to receive a patch.

Where's the MIT license guys?

CyberAlarm, both old & new, uses the "phpseclib" library... distributed under the MIT license.  I can't, for the life of me, find any reference to the required copyright... and if it doesn't exist, they're not providing the necessary credit and have effectively stolen the developer's work product.

Keep diggin'

Upon request of the media, I withheld this article to give them time to question NPCC & Pervade.  Unsurprisingly, they doubled-down and refused to accept there are serious issues with CyberAlarm.  Following a call between NPCC and the media, they offered to send a link "to have a good look at", presumably to prove it's safe.

As the final nail in the coffin, they sent the media a link to the current public "live" version with a modification date of 29/11/20.

Are there any issues?  Of course.

Step 1: Upgrade PEAR - we wouldn't want to be left insecure, would we?
Step 2: Install 10 year old, outdated & vulnerable dependencies.

Net_SMTP-1.4.2
https://pear.php.net/package/Net_SMTP/download/1.4.2
A 10 year old, outdated build.

Net_URL2-0.3.1
https://pear.php.net/package/Net_URL2/download/0.3.1
A 10 year old beta test build!

HTTP_Request2-0.5.2
https://pear.php.net/package/HTTP_Request2/download/0.5.2
A 10 year old ALPHA build! (Using an alpha in production - what could go wrong)

Mail-1.2.0
https://pear.php.net/package/Mail/download/1.2.0/
A 4 year old, outdated build.

Mail_Mime-1.8.2
https://pear.php.net/package/Mail_Mime/download/1.8.2
A 9 year old, outdated build.

Do I really have to explain the risks of deploying an alpha build of anything to the NPCC?  Again, this is in the installer, visible in plain text.  Jeez...

What now?

For CyberAlarm - I hope it's pulled with immediate effect.  It should never have reached the public in this state and those responsible for both developing it & presiding over its deployment should probably reconsider their positions.

For me - I hope NPCC do the right thing, apologise & retract their defamatory post... quickly.

Summary

Of all the vulnerabilities I raised in the "test" build, only 2 are fixed - CentOS & PHP.  I say "fixed", PHP 7.2 went end-of-life on the 30th November 2020, but backporting... yada yada.

If we ignore those, let's briefly bullet everything else.

SELinux disabled:
They don't deny this - but don't understand the risk.  I've told them, a RedHat article explains why it's dangerous and now, thanks to Karanbir, CentOS have stepped in to prove beyond doubt, this is dangerous; unless nobody cares about exploits like ShellShock etc.

RCE:
Still possible, though not through "getmon.php".  Keep in mind this product is live in Schools, Councils, Mental Health Clinics, SMEs with valuable intellectual property and a Formula 1 team - I obviously can't drop a zero-day which puts them all at risk.  However, untrusted input combined with "exec" - the outcome is self evident.

Mindful of the risk, here's a demo proving it's possible, with steps removed to protect the public...

Cross Site Scripting:
Still possible - part of the wider product rather than the data collector itself.  Hint - Validate on input, sanitize/encode on output; anything else leaves you vulnerable to XSS attacks.

TLS Certificate Expired:
The production version points to a different endpoint which does have a valid certificate.  Not that it matters however... as TLS security checks are disabled everywhere.

Attacker: "Hey, I'm a Police server with an important update for you..."
Collector: "You don't look like a Police server and your certificate has expired... so, what can I do for you?"
Attacker: "Extract this .tar.gz and execute the contents..."
Collector: "Sure thing"

Broken Encryption:

... sure looks like an encryption key to me.

They don't deny using AES-CBC without a MAC either - but again, demonstrate they don't understand why that's not only important, but crucial.

Broken Encryption - Part Deux:

Exactly the same as the "test" build - all SSL/TLS security checks disabled.

Embedding server passwords in code:

Exactly the same as the "test" build.

The similarities between these two "completely different pieces of software" is staggering.

That's it folks.  Thank you for listening and for heaven's sake, be careful what you install on your network.

Notes / Files

If you've downloaded CyberAlarm previously, you'll be able to hash the files to prove I've not modified anything other than filenames.  If even a single character in any file changes, the entire hash would be different - thus proving we have different versions.

While watching reruns of Dragon's Den last week, one particular pitch caught my attention.

After Googling the company, I arrived at a page containing SQL errors. Having read the error log, it became clear the site had a critical security vulnerability. After a few tweets, emails & a brief call, the company patched it within 24hrs. Result!

However, something else caught my eye...

... a SafeBuy trustmark.

Clicking the trustmark reveals the following popup...

Interest piqued, I decided to see just how trustworthy this SafeBuy scheme really is.

Registration

SafeBuy offer a 60 day free trial, after which, it's £180 a year.

That's it! That's the entire registration process. The observant amongst you will note the lack of a "I agree to abide by our code of conduct" checkbox and, if you're especially observant, you'll also note the price has gone up to £238.80 too.

The majority of sites ask for a password during registration, but surprisingly, SafeBuy do not.

24 hours later, I receive an email:

Hmm, the password is prefixed with "safe" and what looks to be a random number, 1709121. Remember that for later...

After logging in, you're greeted with your account profile page.

Wait, what?! Toronto, Canada, Freshbooks?! Where did that come from?

In actual fact, the URL I entered (urity.co.uk) redirects to our billing control panel; run by Freshbooks. SafeBuy have wrongly assumed I own Freshbooks... but surely they wouldn't issue a trustmark in their name?

Sigh. The independent vetting process can't be particularly thorough if this slipped through!

As if that wasn't bad enough, I've been automatically featured in their members' directory.

https://www.safebuy.org.uk/directory/computers.html

Hang on, that "accreditation number" looks familiar...

Oh for christ sake! The reputation of "my" business, or rather that of Freshbooks, is now in the hands of anyone blessed with the gift of sight. Thanks "Safe" Buy!

By this point, I've already written this off as insecure, ill-conceived snake oil. But, how deep does this rabbit hole go?

"Credible reviews"

Having all the hallmarks of a "one man band", I doubt SafeBuy has the resources to audit each & every review they receive. What they can do however, is implement the most basic of automated checks to verify a review is genuine. Unfortunately, that doesn't appear to be the case.

Here's my first review:

Trouble is, you get slightly less of a warm, fuzzy feeling when you review... yourself. Yes, I submitted that review... and I was logged in at the time! What's the point of a "trusted" reviews site which allows companies to review themselves?

Security, or lack thereof

Before we get into the shocking state of security at SafeBuy, here's my reviews page:
https://ratings.safebuy.org.uk/freshbooks.com/stats.html

If you're wondering why the images are going crazy and you're hearing some pretty awful music, that's the harlem shake.

You see, the site is so unspeakably insecure, it's possible to embed & execute arbitrary code as if I'm the developer. OK, the harlem shake is a bit of harmless fun... but I could just as easily embed malware or indeed alter anything you see; quantity of reviews, star ratings, each review, their responses... literally anything!

Talking of responses:

On this screen, we can see all our customer reviews and if necessary, respond to them. One of the best ways to judge a company is not from the quantity of reviews (especially as they're so easy to fake) but how they respond to reviews/complaints.

Hmm, there's an ID in the URL. What happens if we change it?

Sigh! It's the review screen for oakhillflooringltd.co.uk.

At first glance, you'd be forgiven for thinking this isn't a major security concern. After all, we can view their reviews publicly anyway. Trouble is, the "reply" button works!

Yes, we can reply to OakHill's customers as if we're logged in as OakHill. It's a good job I'm not in competition with them, or it'd be very easy to destroy their reputation.

Let's recap

In summary, we've visited an insecure website, been assured it's secure & private by a trustmark, registered and been accredited for a brand I neither own nor control, been given an insecure default password (also stored in plain text!), reviewed our own company, hijacked our own review page to deliver fake/inflated reviews and/or malware & had the opportunity to hijack any other SafeBuy member simply by changing a number in the address bar.

It's hard to believe this was designed in collaboration with the Office of Fair Trading!

It's worth mentioning at this point, the OFT closed in 2014... but it adds credibility, so why remove it? </sarcasm>

Responsible disclosure; redefined?

As regular readers will know, I always follow (what we call) responsible disclosure; typically by reporting these issues to the company in an attempt to have them addressed. However, there are those who will undoubtedly claim this isn't responsible disclosure, so let me explain my actions...

The industry is plagued by snake oil, meaningless trustmarks which continue to mislead users around the world. I've no doubt Troy Hunt would agree, given his comments in this excellent article from 2013. By reporting & effectively donating my time to companies which provide them, I am complicit in their questionable practices. On this occasion, the only way to "responsibly disclose" this... is to inform you, the general public, of just how pointless they really are.

Serving malware!

If you visit the site with a VPN and/or antivirus app running, you'll receive an error similar to this:

Why? The site has been infected with malware for months! Thankfully, the site which the malware redirects to has since been fixed... but quite how "SafeBuy" were hacked is still unknown. Keep in mind, their trustmark ensures "total security & privacy" yet their own site falls short.

Summary

I have thinly veiled contempt for companies which claim to be "secure" simply by displaying a misleading image; even more so for those who advocate & facilitate this type of behaviour.

To put it bluntly, SafeBuy is a complete & utter shambles. If you're considering entrusting your firm's reputation to them, I'd strongly urge you to think again.

Notice: This article is a work-in-progress and serves only to address questions from media outlets & Kerv customers.

On the morning of June 21st 2017, I received an email from an "anonymous" Kerv user... coincidentally the same day I received my Kerv ring.

Nothing unusual there, apart from the fact it contained my name, home address, phone number and memorable information. Oh dear...

As regular readers will know, I use 1Password to generate both passwords & memorable information; meaning a breach of such information doesn't adversely affect other accounts I hold elsewhere. As each entry is entirely unique, it's trivially easy to determine the author of this email really does have access to my Kerv account. It quickly became clear that this wasn't a breach in the typical sense... this "anonymous" person had inside information which wouldn't otherwise be available. In an act of either lunacy or clarity, he subsequently forwarded admin credentials to me from a Tor address; obviously unaware of my work deanonymizing Tor users. Not a smart move!

After logging in to my Kerv account, I was greeted with the usual user interface. This time however, I clearly had access to features which were only intended for Kerv employees. After a brief investigation, it became obvious I had full admin access to the site, shop & customer database.

Time to contact Kerv!

I initially tried the Kerv "lost & stolen" number from the site, but there was nobody immediately available for comment. Cue Twitter...

Hi @KervLife
I need to speak with your security team urgently. Please advise.
cc @FD_Phil

— Paul Moore (@Paul_Reviews) June 21, 2017

After a matter of minutes, Mr Phil Campbell (Director @ Kerv Wearables) emailed to request further information. After a lengthy telephone conversation, I advised Phil to immediately take the site offline until a review could be performed. Almost immediately, my access was revoked and at 2:15PM, the site was taken offline completely.

In the hours which followed, Phil and his team worked to identify the root cause and restore service to their customers.

More information to follow...

FAQ

Q) What can I do to protect myself?
A) Change your passwords and memorable information, immediately. Use a password manager to generate them both. Register with Noddle for free credit alerts/reports.

Q) How did Kerv handle the disclosure?
A) Phil/Kerv's response is a perfect example of how companies should handle data/security breaches.

Q) Do you have any other concerns, should I still use my Kerv?
A) I haven't spent much time with Kerv, having only received it yesterday and it being offline ever since. However, I have a number of concerns which I've raised with Phil. It wouldn't be appropriate to list them here, however I've every confidence that Kerv will resolve any outstanding issues. Nonetheless, I see no reason to abandon Kerv. Insider threats affect everyone; Kerv have taken (what I'd consider to be) reasonable & appropriate steps to mitigate the risks involved and have been open & honest in their responses.

Q) What information did you have access to?
A) I was added to the "customer services admin" group, allowing access to virtually every piece of customer data, excluding financial info.

Q) Do you have any further comments?
A) If & when I do, I'll update the article. If you're a news/media outlet looking for comment, please use the comments form below.

After months of tweets, emails & articles from eminent figures like Troy Hunt & the NCSC, it's about time I weighed in on the debate surrounding sites which disable a user's ability to paste passwords.

The general consensus amongst many experts, including those mentioned above, is that disabling paste on password fields reduces security; the NCSC went one step further, calling it "completely pointless" and "damaging".

So without further ado, allow me to explain why I believe disabling paste can actually increase security.

Premise

Disabling paste facilitates barrier-less 2FA.

Confused? OK, let me explain...

Traditional e-authentication systems monitor what you type (your password, for example). This, by definition, provides 1FA or single-factor authentication; you've demonstrated to the site (or verifier, for those of a NISTy disposition) that you "know" the password.

As we know, passwords can be and are frequently stolen, guessed, intercepted, cracked or bypassed... thus requiring a drive towards 2FA or multi-factor authentication.

For many years, companies have focused on introducing a "possession" factor, allowing you to present something you have (along with something you know) to further prove you are who you're purporting to be. That's great, in theory... but the adoption rate of this type of 2FA is pretty abysmal; with some firms (Google et al) seeing figures of < 5%.

Other firms have opted to use a little-known technique called behavioural biometrics/keystroke dynamics. These systems monitor how you type; the periodicity of your keystrokes, how long you dwell between each key, how often you make mistakes, how long each key is pressed and so on. These metrics can be used, with astonishing & near 100% accuracy, to determine who's typing. This is known as an inherence factor. Here's a more detailed explanation of behavioural profiling.

You could, in theory, give someone your password and they'll be unable to login... simply because their typing pattern differs enormously from your own. Think of it as a signature; something unique to you.

Just how reliable is it?

Back in 2015, myself & Per Thorsheim (@thorsheim) presented our research into behavioural biometrics (and how to defeat it) at Cambridge University.

During this research, we demonstrated the ability to shatter a user's anonymity, even when using proxy servers & Tor.

Just let that sink in for a moment...

Even when a user is actively trying to hide their identity using sophisticated & layered defences, the site is able to identify who they are by how they type. No passwords, no perma-cookies... just typing into a webpage.

Many financial institutions, including 2 UK banks actively use this technology in the fight against fraud. Also, HSBC recently announced the introduction of behavioural biometrics via telephone banking; using just your voice to identify you.

How does disabling paste break behavioural biometrics?

When you paste data into a form, the value reaches the DOM almost immediately (a caveat being the use of scripts which monitor for bubble events and delay/block them).

As you haven't typed anything, the script is unable to verify it's really you... leaving you with just single-factor authentication again. Depending on how the site is designed, it may prevent you from logging in, or increase a fraud indicator which prevents access to certain functions (transferring funds etc)

Myths

It's true, there are dozens of increasingly-comical reasons why some developers believe disabling paste increases security.

We'll lose our security certificate if we allow paste

Nonsense.

We'll be vulnerable to brute-force attacks

True, but attacks are rarely (if ever) carried out this way.

Bizarre eh! But equally bizarre, are the myths which circulate as to why you should be allowed to paste passwords.

It breaks password managers!

Not one for going with the status quo, I decided to test this widely agreed-upon theory.

Disabling paste doesn't break password managers...

1Password, LastPass, Roboform & Dashlane all work perfectly with paste disabled.

How's that possible if paste is disabled?

They don't use paste, at all.

If you're using a password manager which generates & populates password fields automatically, it won't be using the "paste" event to achieve the desired result, thus disabling it has no effect whatsoever. I admit, testing 4 password managers is hardly comprehensive... but they all face the same constraints (set by the browser) in terms of how they interact with DOM elements and nearly all adopt a similar, tried & tested method of populating the field.

Now it's true, some password managers don't auto-populate fields and have little/no integration with your browser; KeePass is a prime example. In that scenario, you would be unable to copy/paste from KeePass to the password field. You still haven't "broken" the password manager or measurably decreased security... only the user-experience (UX) is affected.

"That's a good enough reason to allow paste then, surely?"

Not really, no.

If we make conscious design decisions affecting only people who use password managers, we're already talking a tiny fraction of your potential user-base. To further limit those decisions to people who only use comparably-antiquated and potentially more risky solutions like KeePass, you're probably in the realms of < 0.1%.

Summary

Barrier-less 2FA is exactly that... a zero-barrier, frictionless method of increasing security for all your customers, including those who use password managers.

There are many "completely pointless" reasons to disable paste, but that doesn't mean disabling paste is completely pointless, nor damaging.

That's it folks.

Use a password manager.

Ever since publishing a "two factor authentication vs two step verification" article in 2014, I've been waiting for an opportunity to irrefutably demonstrate the difference.

Note:
This article is very much a "work in progress" as until both exploits are patched, I can't provide any technical information.

A quick recap...

If you haven't yet read the above article, let's quickly recap on the differences between two-factor authentication & two-step verification.

A "factor" falls into one of the following categories.

1. Knowledge
2. Possession
3. Inherence

The lines between them however, become blurry when companies refer to SMS one-time passwords (OTPs) or calls as "two-factor" authentication.

Although you technically "possess" the phone, the OTP isn't generated by, nor dependent on the phone itself... but rather the code sent to it via the mobile network. I've long argued that despite NIST's statement to the contrary, SMS OTPs do not constitute 2FA.

So, let's dive right in.

Who are FreedomPop?

FreedomPop are the UK's first completely free mobile network provider; launching in September 2015.

Unsurprisingly, FreedomPop has grown rapidly to in excess of a million users, many of whom opt for the free 200 minutes, 200 texts & 200MB data plan.

FreedomPop's security... or lack thereof

At this point, I'd usually explain the exploit in detail but, mindful of not wanting to exacerbate the problem, stop short of providing a step-by-step guide. On this occasion however, the risk is such that any further information is likely to immediately place 1+ million users at considerable risk.

It is currently possible to remotely hijack any FreedomPop account, allowing both calls & messages to be made/intercepted by an attacker. No usernames, no passwords and no SIM swapping... just unfettered access to a user's communications.

Monetizing the exploit...

OK. We now have access to every call & SMS message to a user's device... how can we convert that into actual money?

Well, the user's contact list is probably a good place to start; a few quick texts to friends & family is likely to yield a few quid. Keep in mind, the messages are coming from the victim's own number.

That's all well & good, but what if we're not interested in a few hundred quid?

Hitting the bank

At first glance, this seems like a particularly crazy idea.

To successfully gain access to a Halifax account, an attacker would need the username, password & security pass phrase. Even armed with all this, they're unable to add a new payee without triggering further anti-fraud checks... in the form of an automated call to your registered mobile number.

The UK banking sector isn't particularly hot on security either, but that's still a tall order without tripping sophisticated anti-fraud systems.

Can we bypass the username, password & security pass phrase entirely?

As of the date of this article, it's possible to do just that.

Halifax don't offer a "Premier +" account, but would you have spotted the fake/malicious section of the page?

No security warnings, no outward signs at all that we're looking at a page controlled entirely by an attacker.

A serious (yet remarkably simple) vulnerability in the Halifax site allows an attacker to execute arbitrary & external scripts. This gives the attacker complete control over the victim's environment; changing links, buttons, text and crucially... perform actions as if they're the genuine user.

Thankfully, Halifax/Lloyds Banking Group have since verified this exploit, even bringing in external consultants to re-test & confirm their results.

Whilst we agree there's an issue, Halifax/Lloyds have (unsurprisingly) played down the risk, suggesting that other safeguards prevent unauthorised access to a user's bank account. One of those safeguards, of course, is the requirement to verify a new payee by contacting the victim's mobile number.

I've demonstrated one method of payload delivery and although it works, it's by no means quick or easily scaled. There's at least one other route too, but proving this theory means breaching the Computer Misuse Act and, given their propensity for threatening legal action, it's a step too far for an exploit I've proven by other means.

Let's not forget though, even a single, well-executed attack can yield a sizeable return. Remember Vivian Gabb?

Killing two birds with one stone.

Let's recap...

We control the user's mobile number.
We control the user's banking environment.

But, we still need to deliver & execute the payload in a manner which doesn't alert the user.

How?!

The fix for this exploit is due in 3/4 weeks, so until then, I obviously can't give any further details.

However, their failure to adopt even the most basic of safeguards means it's possible to fire both exploits simultaneously and directly on Halifax's own site. To make matters worse, the exploit takes place on the user's device; effectively shielding the attacker from the vast majority of anti-fraud checks.

Wider issues...

Let's be clear. An attacker is unlikely to hit your bank account first... the risk is just too high.

There are other low/no risk targets which could yield an equally high return. Your email address, as an example, provides access to virtually every account you own.

If you're sensible, you've enabled 2FA or 2SV on your email account; effectively preventing unauthorized access to anyone armed with just your password. It's also sensible to add a fallback number, if you ever lose access to your second factor... or is it?

Every fallback/revocation option provides a wider threat surface, each attracting their own set of security concerns. An immensely strong password is rendered useless by anyone with access to my email account. A Yubikey/Google Authenticator is rendered useless by the ability to bypass it via SMS. Instead, the crypto seeds which form the basis of my OTPs are backed up locally; encrypted and isolated from the outside world.

Thankfully, I've never lost my keys... but it'll happen one day. If you must use backups/fallback options, just bear in mind they're another door into your digital life.

If the attacker now has knowledge of your OTP, he has access to your supposedly "2FA" protected accounts. Keep in mind, 2 knowledge factors does not constitute 2FA either... but 2SV or two-step verification.

The attacker hasn't stolen something you "possess", thus it couldn't possibly be 2FA. It's undoubtedly stronger than just a password, but it's by no means comparable to true 2FA.

Summary

These exploits really are the lowest of the low-hanging fruit; detected by even the most rudimentary of security scans... but overlooking even the simplest of exploits can lead to much bigger problems.

In isolation, the issues at the Halifax do not appear to be particularly serious... though I'd question how such a basic flaw went unnoticed. When combined with other, equally simple exploits elsewhere, an attacker has a much wider window of opportunity to gain access to your communications & bank account.

Timeline

Halifax/Lloyds Banking Group responded immediately, escalating the issue to the appropriate team for review. They later called to confirm the exploit, the steps they're taking to resolve it and their assessment of the risk. As our assessments differ, a partial publication seems appropriate.

FreedomPop however, are yet to reply.

24/03/16 - Tweeted FreedomPop. They replied asking for details to be emailed to feedback@freedompop.com - Email sent.
24/04/16 - Identical email to feedback@freedompop.com requesting a response.
25/04/16 - Email to CTO. No response.
27/04/16 - DM to FreedomPop asking for an update.
28/04/16 - Response to DM. "We've relayed your message, have a wonderful day"
01/05/16 - Publication. Further information to follow if they fail to respond.

Update 27/04/16:
Here are some screenshots of the EveryKey Windows app.

It's not digitally signed, so there's no way to ensure it's genuine and hasn't been modified, it crashes if you click the toolbar & if you click "forgot password", it opens Google. To be frank, it looks pretty thrown together at the moment.

Thank you for the anonymous tip folks.

Update 12/04/16:
EveryKey have replied to this post. Read it here.

In May 2015, I questioned if EveryKey, one of Kickstarter's most successful campaigns, was vaporware.

Over the last 11 months, I've received near-monthly emails/tweets from backers; angry over delays and poor communication. Other than a few updates to the original article, I didn't intend revisiting EveryKey as, quite honestly, I didn't see the point.

This week however, has seen an influx of complaints as EveryKey have, once again, failed to deliver the product as promised. By my count, they've missed no less than 6 deadlines... although "March 2015" was never realistic.

Before we dive in, let me answer my own question.

No, EveryKey isn't vaporware.

It may not be in the hands of backers just yet, but I've no doubt EveryKey exists and will ship at some point in the future.

Whether you'll want to use it however, is another matter entirely.

Accepting payments over HTTP.

When the Kickstarter campaign finished, EveryKey began collecting pre-orders, customer PII & payment info over HTTP, which is both insecure and in breach of PCI compliance. I tweeted EveryKey (@_EveryKey) and despite the lack of a response, it was fixed a few days later. Leaking your customer's payment data isn't a great way to begin a working relationship, especially given the context.

"We won't be hacked"

Famous last words.

No responsible company, especially not one in the security space, would ever claim to be impervious to hacking. It does however, reaffirm my decision to back out of their campaign.

OK. Enough of the trivialities...

Vulnerable API

For several months, EveryKey has provided an API on http://api.everykey.com which presumably acts as the service entry point for their devices/partners.

Hmm. That's clearly not finished... or even started.

But, what happens if you land on the registration page first?

That's better... apart from the distinct lack of SSL/TLS! If you try to load the site over HTTPS, the connection fails, so it's impossible to register your details over a secure connection.

Let's register.

That's a good start! It can't connect to the database! But hang on, what's this?

Database name: ev[erykey]
Database username: hytech
Database password peeyushisthebest

We now have Everykey's database credentials.

That's already game over, for a number of reasons.

1. There's no SSL/TLS, an absolute necessity when dealing with personal data & passwords.
2. They're leaking database credentials in error messages.
3. The password being used to "protect" the database is weak & amateurish, thus crackable even without being disclosed.

Again, I emailed Everykey to alert them to this and despite not receiving a reply, the domain was taken offline yesterday and replaced with this.

Perhaps I'm being too harsh. It's clearly a work-in-progress and perhaps doesn't reflect the true quality of the final product.

But...

Is a barely-working, insecure prototype acceptable after nearly 4 years & $1.25 million dollars of investment? The registration page gives absolutely no indication that it's a proof-of-concept page and not intended for public use, so how many others have blindly "registered" and inadvertently leaked their details?

The observant amongst you may have spotted the addition of SSL/TLS in the last screenshot, so now it's secure, right?

Really? POODLE in a brand new TLS deployment? This is a joke, surely?

... and the certificates are in the wrong order! I've no idea how they've managed to make a mess of a "Let's Encrypt" deployment... it's about as "hands off" & simple as it gets.

It's shipped for Windows & Android. Or has it?

A week ago today, EveryKey announced the product had finally shipped.

Well, sort of.

At the last minute, they opted to hold back on support for Mac/iOS, citing the logistics of handling 4,000+ orders and the appreciable load on their support desk.

Forgive me, but that's thinly-veiled nonsense.

It's true; shipping 4,000+ products is a logistics nightmare and will undoubtedly increase the number of support requests... but that's something you scope into your business plan before you begin collecting millions of dollars from backers. Phased roll-outs are nothing new, but keeping backers in the dark until the day of shipping is misleading to say the least.

It's also very unusual for a company to send out surveys to "confirm shipping details" on the day they're due to ship the product. A bit of forward planning goes a long way.

Despite all this, the comments on both Kickstarter & Indiegogo suggest not a single person has received their survey... even a week later. BackerKit, which EveryKey uses to manage their campaign, makes the process of sending surveys painless. They're quick, simple and hassle-free. They certainly don't take a week to send.

The Play Store

Let's assume at least 1 has been shipped... the app isn't in the Play Store.

It's not available to download via their website either, nor is the Windows binary or Chrome/Firefox extension.

Alas, EveryKey later admitted the Mac & iOS versions weren't ready for release but they estimate it'll be ready over the next few years/decades months.

Summary

Well, that's enough for amateur hour this week folks.

I really do appreciate your efforts in updating me on the situation, but this is likely to be the last I'll write about EveryKey.

Invest in a password manager and leave cryptography & security to the experts.

A few weeks ago, I was asked to observe an installation of several wireless access points & VoIP phones, with a view to making recommendations on how best to improve security while maintaining ease of deployment.

It didn't take long for several trends to appear; chief amongst which was the use of

We'll just use defaults, for now. That password will do, for now.

Of course, as soon as the device burst into life, it's on to the next one. At which point, "now" becomes a distant memory, along with any thoughts of hardening the device for use in a commercial setting.

This was not a fly-by-night company either, nor do they install cheap & cheerful hardware; we're fitting enterprise-grade Cisco, Snom & Ubiquiti UniFi equipment. With a tight schedule & reputable brand names, I completely understand why many installers trust the default configurations so vehemently.

A default config is rarely a secure config.

A default configuration is only intended to restore a device to a "default" state, such that a competent installer can configure it to meet the client's needs.

Note: This is neither aimed at nor unique to Snom devices. I'm aware of similar exploits against current Cisco devices too.

In the following example, I've reset a Snom 320 VoIP phone (running 8.7.5.13 firmware) back to factory "default" settings.

Even before we begin, there's a serious problem... there's no authentication whatsoever!

To their credit, some manufacturers provide a default set of credentials... even if they're usually "admin/admin", thus equally insecure.

Snom however, opted to place a tiny "HTTP password not set" warning at the top of the configuration screen. That'd be fine if it forced you to set a password during the setup process, but it doesn't.

To make matters worse, it's only too happy to accept a single character/number password too.

They're sat behind a strong firewall, so what's the big deal?

A reasonable argument, you might think. So, let's put it to the test.

Hijacking the Snom 320

Step 1: Visit a site which contains the exploit payload.

That's it.

Simply by opening a malicious site (or a genuine site containing the malicious payload), the attacker has complete control over our VoIP phone.

To demonstrate this vulnerability, I enlisted the help of two colleagues... Per Thorsheim & Scott Helme. Per will play the part of our attacker, embedding the exploit on a site which he controls. Meanwhile, I'm reading Per's site while having a private conversation with Scott, via Skype.

Unbeknownst to me, Per has forced my VoIP phone to call his premium rate number and disabled the speaker, so unless I'm looking at the phone, I wouldn't know it's dialling.

Note: We've left the activity LED on during this demo, as it's difficult to read the screen. When the light illuminates, the phone is dialling out.

What can the attacker do?

Virtually anything.

Make calls, receive calls, transfer calls (even before it rings), play recordings, upload new firmware and crucially... use the device for covert surveillance.

Our self-defeating approach...

If we look beyond the IP telephony sector to the industry as a whole, many companies ship devices which have no "default" security... or permit the use of weak credentials which provide nothing more than a false sense of security.

It has to stop.

Vendors - If you must supply devices with "default" credentials, disable all other functionality until a suitably-secure password is set to replace it.

Summary

The term "covert surveillance" is usually only associated with nation states, certain 3-letter agencies and those closed-minded individuals pushing the Investigatory Powers Bill (IPBill / Snoopers Charter).

In this demonstration, the attacker has not only compromised your phone & privacy with just a browser, but you've paid him for the privilege!

If you install, use or just find yourself sat next to one of these devices, just remember... it's basically a PC, with all the security vulnerabilities associated with them. Don't assume it's safe because it's running as the manufacturer intended; seek professional advice.

1. Use strong passwords, derived from a password manager.
2. VLAN / network segregate your phones, if possible.
3. Restrict access to APIs, even if they're only visible internally.
4. Check & upgrade your firmware regularly, ensuring it doesn't revert to "defaults" afterwards.

Just today, Professor Alan Woodward of Surrey University published an article entitled "Are you the only one using your VOIP phone?" which discusses the various attack vectors & implications associated with VoIP devices. If you haven't yet subscribed to Alan's RSS feed, I'd strongly suggest doing so.

Thanks to Per Thorsheim & Scott Helme for their help with this demonstration.

That's it folks... for now.

Back in March 2014, I contacted ASDA to report several security vulnerabilities and despite a fix promised "in the next few weeks", little appears to have changed.

@Stuho1mez All of our sites are secure, I would advise using Chrome. Thanks, Beth

— Asda Service Team (@AsdaServiceTeam) January 14, 2016

After 677 days and several tweets along a similar vein, my patience has finally run out.

What's the problem?

Two of the simplest and most prevalent exploits allow an attacker to quickly & effectively collect personal information & full payment details.

Rather than outline the finer points of CSRF (Cross Site Request Forgery) & XSS (Cross Site Scripting) for the umpteenth time, it's probably easier to show you.

Have I been affected?

As of Q2 2014, ASDA processed upwards of 200,000 online orders each week. Given the length of time this has been exploitable, that equates to over 19 million transactions.

I'm not aware of any evidence suggesting these exploits are being used in the wild, but just a few months after my initial report, this tweet appeared.

@asda some one hacked my acc tomake fraud on line purchases the bank caught it tank god but warn ur customers and i need a number to ring

— cathy creighton (@Ruby6918) June 10, 2014

Unfortunately, it's difficult to know if your details have been stolen unless the attacker uses the information very shortly after the breach occurs, such that it's reasonable to assume a link between the two. However, ASDA may be able to shed further light on anyone affected by this, or any other exploit.

How can I protect myself?

The safest way is simply to shop elsewhere.

ASDA/Walmart have had ample opportunity to fix these issues and have failed to do so. If you must continue shopping with ASDA, open a "private" / "incognito" window and do not open any other tabs/windows until you've logged out.

Other issues...

Well, they don't enforce SSL/TLS during login and the entire session is maintained over an insecure protocol.

Another user spotted this too... and tweeted ASDA.

Hey @ASDA why do you serve your login form over plain (unencrypted) HTTP? pic.twitter.com/1LsuP8YuLF

— Chris (@cmrowles) February 9, 2015

Did they acknowledge the issue & deploy a fix? Not quite.

@cmrowles Morning! We've had it confirmed that the page is secure 😊 Thanks, Beth

— Asda Service Team (@AsdaServiceTeam) February 10, 2015

--

When Sarah tried to apply for a job, she was greeted with this error.

@asda get a new security certificate for your jobs site, risk of having personal data stolen. #asda #websecurity pic.twitter.com/mVpueZs5Qy

— Sarah Rose (@NyowcatS) May 26, 2015

Did they spot their mistake, generate and deploy a new certificate?

@NyowcatS Hi Sarah, I can confirm that all our Asda web pages are secure, Thanks Steph

— Asda Service Team (@AsdaServiceTeam) May 26, 2015

No. They go on to recommend Sarah delete her cookies!

Scott tried to apply for a job too.

@asda I'm trying to apply for a job on your site. But anytime I try to access the application part. It tells me the websites in danger

— scott paterson (@whosinthebox94) June 15, 2015

Surely now they'll fix it, right?

@whosinthebox94 Hi Scott, I can confirm to you that the http://t.co/I7R0i6VbzC website is a fully secure site, Thanks Steph

— Asda Service Team (@AsdaServiceTeam) June 15, 2015

Nope. Now, it's fully secure.

Summary

Despite a speedy response to my first email and a privacy policy which suggests otherwise, ASDA do not appear to be overly concerned about the security of their customers.

I invited ASDA to comment on the situation; requesting more detailed information on who customers should contact if they believe they're affected by any security flaws. I received an "out of office" from their "data protection" email address and haven't heard anything since.