Bitter war of words erupts between UK cops and web security expert over alleged flaws in Cyberalarm monitoring tool • The Register
A war of words has erupted between the National Police Chiefs' Council (NPCC) and a British web security pro after a senior cop declared it would be "a waste of public money" to keep discussing security flaws in the body's Cyberalarm product.
Paul Moore says he uncovered what he described as a number of serious flaws in Cyberalarm, a distributed logging and monitoring tool intended to be deployed by small public-sector organisations.
While the NPCC and the tool's developer, Pervade Software, initially insisted that Moore was mistaken because he had stumbled upon an early test build rather than the production version of Cyberalarm, The Register has done some digging and all is not as police and Pervade claimed.
In its current state the tool itself is probably not an unintentional backdoor for criminals, though the war of words between Moore, police and Pervade perhaps serves as a reminder of how not to handle independent security research.
What is this thing, then?
Cyberalarm was launched earlier this year. A free tool, it is intended to give police direct visibility of online threats faced by SMEs and small public-sector organisations.
In essence it's a distributed firewall log monitoring system: end users deploy Cyberalarm's "data collectors" on their networks in a demilitarised zone and those then send alerts to the local police force's cybercrime team. The types of data it collects are described in more detail on the Cyberalarm FAQ page.
Moore told The Register he had downloaded a copy of Cyberalarm out of curiosity to see what it did and how it was done after following a link in a PDF about the tool sent to him by his local police force.
Surprised to find a number of security problems, he contacted Cyberalarm, he told The Register, to raise his concerns with its creators. The tool Moore examined included a remote code execution vuln, expired TLS certificates, advice to disable SELinux prior to deployment (normally a big no-no), potential for cross-site scripting attacks and more, he said.
Disabling SELinux? Out-of-date distros? Just a sec...
Both police and Pervade stopped engaging with him after a while as he pointed out the tool's flaws. Out of what he described as concern for the public, Moore published an article about his findings.
Andrew Gould, a detective chief superintendent with the NPCC and the police national cybercrime lead, told The Register: "What he found was a debugging tool," repeating that Moore had found an early development build known to contain flaws and that it was not in live use.
"So he knows that [the security vulnerabilities were] not the case but he's published anyway," said Gould. "Normally in policing we're very thick skinned... but this has got the potential to have an impact on business confidence. In our view what he's done is misleading and deliberately so."
Moore had made some mistakes, said Sean Wright, application security researcher at Immersive Labs, who had a read of Moore's article and told The Register there was a flaw in his condemnation of Cybersafe's advice to disable SELinux prior to installing Cyberalarm:
Simply disabling SELinux does not necessarily make the system vulnerable. SELinux is certainly an important security control, however the act of disabling it does not necessarily mean that any attacker has access to the devices. An attacker would still need to find a way to gain local access to the box.
Wright continued: "PHP 5.4 [referred to by Moore as 'dead and should never be used in a production app'] is indeed end-of-life'd but Red Hat-based Linux distributions do not perform feature patching, meaning that the version is never updated. All security updates are however applied. So in this case in order to determine if a vulnerable version is used, you would need to identify the package installed and determine if it's on the latest patch version."
So what about the production version of Cyberalarm?
It emerged during The Register's investigation that the link Moore followed to download Cyberalarm had been incorrectly edited when a PDF user download guide had been updated: the anchor text in the link to the downloadable package pointed to one location while the link itself pointed elsewhere. (Neither Pervade nor the NPCC fully accepted this version of events, though it is the most plausible way that Moore was able to access what we were told was an outdated file saved to a directory that was supposedly no longer in use.)
Given the correct link by his local police force, who thanked him for telling them of the wrong link, Moore told us he examined the production build of Cyberalarm.
As the NPCC and Pervade dug their heels in, insisting that he was still mistaken, Moore told The Register: "They weren't listening. I told them again and again that there were serious problems with this and they didn't want to know."
Moore said that by comparing hashes of Cyberalarm downloads from different dates, as well as the "last modified" date of the compressed packages, he found that the files differed. He attributed this difference to silent fixes for issues he had raised – issues police had said they were not interested in.
We asked Pervade's director Jon Davies to comment on this suggestion. Davies said he would consider publishing changelogs and version feature lists, things that are currently not available to users of Cyberalarm. Neither is there an at-a-glance way in which users can check that they're running the latest version.
After reading Moore's first article, the NPCC's Gould sent him an eight-page cease-and-desist letter [PDF], which said: "...it is not conducive to the delivery of the programme's objectives to spend further time and public money engaging with these issues or with you."
'There's no point engaging with him'
While Gould and Davies – initially – jointly insisted to The Register that Moore was mistaken and he had only reviewed the test tool, the man himself was certain he now had the production version. In the middle of last week, amid what he described as continued stubbornness from the NPCC and Pervade, Moore published a second review of Cyberalarm.
He alleged that there were still security deficiencies in the product, including hardcoded passwords and disabled TLS security checks.
Pervade's Davies told The Register that prior to publication of this second review, Moore had "reported in to us 20-something issues, all of which were to do with the live version. Some of which we were able to take some helpful things from. The disabling of TLS certificate validation, it's not a vulnerability but a risk, a very sensible one and one we should be doing to protect member organisations, and we went back to Paul to thank him for the suggestion."
Davies also accepted that Pervade had been updating Cyberalarm since Moore first downloaded it, though he stopped short of saying this was as a direct result of Moore's feedback.
Nonetheless, an unrepentant Gould told The Register, when we asked if he stood by his cease-and-desist in light of Moore's feedback about the production version:
Yeah absolutely. What he said is false and misleading in the way he's approached this. The letter, the fact that it is in our original letter you've seen, he undertook to comeback to Jon and Pervade with a detailed list of his concerns so we could consider them potentially in more detail... It's not really the standard that the reputable information security community would support, it's irresponsible. It's potentially undermining a free tool that's there to protect businesses... Yeah, that's right, there's no point engaging with him.
Gould and Davies both maintain that Moore found the link to the dev build of Cyberalarm and has continued to review that instead of the live product, despite Davies also having told The Reg in a phonecall that Moore had identified "20-something issues... to do with the live version."
However, Davies did concede that there is no public changelog or version list for Cyberalarm, while Gould said that any customer who installed the superseded dev build would have phoned Cyberalarm's operators asking why it didn't work. No such call has ever been received, he told your correspondent.
He said, she said… meanwhile, where's the security?
In The Register's view, Cyberalarm is a data-gathering exercise by police. That in itself is not evil: there is a difference between GCHQ-style snooping on network traffic and deploying a logging tool that sends alerts back to Cyberalarm Towers when it detects suspicious inbound connections and does some basic vulnerability scanning. Remember, this tool is targeted at the bottom of the market: organisations with very small IT departments and no in-house security expertise. While it's not ideal, one would hope you could trust the police with a partial, one-step-removed view of your network's comings and goings.
Intelligence that lets police cybercrime teams better equip themselves to tackle threats to small businesses and public-sector organisations is, again, no bad thing. Even if the resulting advice is "find a SOC-as-a-service contractor who knows how to mitigate these threat types", it's better than nothing at all – and it's better than police simply not understanding what's going on in the real world.
What doesn't help the general anti-cybercrime effort, however, is police declaring that independent security researchers are wrong while their contractors accept that the feedback is useful. Neither is it helpful that those contractors appear to be silently updating their products as a result of that feedback while infosec professionals with findings that deserve a second look are publicly lambasted by police.
It is sad that Moore has felt driven to contact his lawyers over the cease-and-desist letters he received from the NPCC. The Register hopes that he, the police and Pervade are able to resolve their differences amicably. After all, none are on the side of the crims that Cyberalarm is supposed to help defend against.
As for Cyberalarm itself: if you trust the police, it probably won't hurt to install it. If you've got the budget, however, your organisation would also benefit from signing a contract with an IT security firm.
Paul Moore says he uncovered what he described as a number of serious flaws in Cyberalarm, a distributed logging and monitoring tool intended to be deployed by small public-sector organisations.
While the NPCC and the tool's developer, Pervade Software, initially insisted that Moore was mistaken because he had stumbled upon an early test build rather than the production version of Cyberalarm, The Register has done some digging and all is not as police and Pervade claimed.
In its current state the tool itself is probably not an unintentional backdoor for criminals, though the war of words between Moore, police and Pervade perhaps serves as a reminder of how not to handle independent security research.
What is this thing, then?
Cyberalarm was launched earlier this year. A free tool, it is intended to give police direct visibility of online threats faced by SMEs and small public-sector organisations.
In essence it's a distributed firewall log monitoring system: end users deploy Cyberalarm's "data collectors" on their networks in a demilitarised zone and those then send alerts to the local police force's cybercrime team. The types of data it collects are described in more detail on the Cyberalarm FAQ page.
Moore told The Register he had downloaded a copy of Cyberalarm out of curiosity to see what it did and how it was done after following a link in a PDF about the tool sent to him by his local police force.
Surprised to find a number of security problems, he contacted Cyberalarm, he told The Register, to raise his concerns with its creators. The tool Moore examined included a remote code execution vuln, expired TLS certificates, advice to disable SELinux prior to deployment (normally a big no-no), potential for cross-site scripting attacks and more, he said.
Disabling SELinux? Out-of-date distros? Just a sec...
Both police and Pervade stopped engaging with him after a while as he pointed out the tool's flaws. Out of what he described as concern for the public, Moore published an article about his findings.
Andrew Gould, a detective chief superintendent with the NPCC and the police national cybercrime lead, told The Register: "What he found was a debugging tool," repeating that Moore had found an early development build known to contain flaws and that it was not in live use.
"So he knows that [the security vulnerabilities were] not the case but he's published anyway," said Gould. "Normally in policing we're very thick skinned... but this has got the potential to have an impact on business confidence. In our view what he's done is misleading and deliberately so."
Moore had made some mistakes, said Sean Wright, application security researcher at Immersive Labs, who had a read of Moore's article and told The Register there was a flaw in his condemnation of Cybersafe's advice to disable SELinux prior to installing Cyberalarm:
Simply disabling SELinux does not necessarily make the system vulnerable. SELinux is certainly an important security control, however the act of disabling it does not necessarily mean that any attacker has access to the devices. An attacker would still need to find a way to gain local access to the box.
Wright continued: "PHP 5.4 [referred to by Moore as 'dead and should never be used in a production app'] is indeed end-of-life'd but Red Hat-based Linux distributions do not perform feature patching, meaning that the version is never updated. All security updates are however applied. So in this case in order to determine if a vulnerable version is used, you would need to identify the package installed and determine if it's on the latest patch version."
So what about the production version of Cyberalarm?
It emerged during The Register's investigation that the link Moore followed to download Cyberalarm had been incorrectly edited when a PDF user download guide had been updated: the anchor text in the link to the downloadable package pointed to one location while the link itself pointed elsewhere. (Neither Pervade nor the NPCC fully accepted this version of events, though it is the most plausible way that Moore was able to access what we were told was an outdated file saved to a directory that was supposedly no longer in use.)
Given the correct link by his local police force, who thanked him for telling them of the wrong link, Moore told us he examined the production build of Cyberalarm.
As the NPCC and Pervade dug their heels in, insisting that he was still mistaken, Moore told The Register: "They weren't listening. I told them again and again that there were serious problems with this and they didn't want to know."
Moore said that by comparing hashes of Cyberalarm downloads from different dates, as well as the "last modified" date of the compressed packages, he found that the files differed. He attributed this difference to silent fixes for issues he had raised – issues police had said they were not interested in.
We asked Pervade's director Jon Davies to comment on this suggestion. Davies said he would consider publishing changelogs and version feature lists, things that are currently not available to users of Cyberalarm. Neither is there an at-a-glance way in which users can check that they're running the latest version.
After reading Moore's first article, the NPCC's Gould sent him an eight-page cease-and-desist letter [PDF], which said: "...it is not conducive to the delivery of the programme's objectives to spend further time and public money engaging with these issues or with you."
'There's no point engaging with him'
While Gould and Davies – initially – jointly insisted to The Register that Moore was mistaken and he had only reviewed the test tool, the man himself was certain he now had the production version. In the middle of last week, amid what he described as continued stubbornness from the NPCC and Pervade, Moore published a second review of Cyberalarm.
He alleged that there were still security deficiencies in the product, including hardcoded passwords and disabled TLS security checks.
Pervade's Davies told The Register that prior to publication of this second review, Moore had "reported in to us 20-something issues, all of which were to do with the live version. Some of which we were able to take some helpful things from. The disabling of TLS certificate validation, it's not a vulnerability but a risk, a very sensible one and one we should be doing to protect member organisations, and we went back to Paul to thank him for the suggestion."
Davies also accepted that Pervade had been updating Cyberalarm since Moore first downloaded it, though he stopped short of saying this was as a direct result of Moore's feedback.
Nonetheless, an unrepentant Gould told The Register, when we asked if he stood by his cease-and-desist in light of Moore's feedback about the production version:
Yeah absolutely. What he said is false and misleading in the way he's approached this. The letter, the fact that it is in our original letter you've seen, he undertook to comeback to Jon and Pervade with a detailed list of his concerns so we could consider them potentially in more detail... It's not really the standard that the reputable information security community would support, it's irresponsible. It's potentially undermining a free tool that's there to protect businesses... Yeah, that's right, there's no point engaging with him.
Gould and Davies both maintain that Moore found the link to the dev build of Cyberalarm and has continued to review that instead of the live product, despite Davies also having told The Reg in a phonecall that Moore had identified "20-something issues... to do with the live version."
However, Davies did concede that there is no public changelog or version list for Cyberalarm, while Gould said that any customer who installed the superseded dev build would have phoned Cyberalarm's operators asking why it didn't work. No such call has ever been received, he told your correspondent.
He said, she said… meanwhile, where's the security?
In The Register's view, Cyberalarm is a data-gathering exercise by police. That in itself is not evil: there is a difference between GCHQ-style snooping on network traffic and deploying a logging tool that sends alerts back to Cyberalarm Towers when it detects suspicious inbound connections and does some basic vulnerability scanning. Remember, this tool is targeted at the bottom of the market: organisations with very small IT departments and no in-house security expertise. While it's not ideal, one would hope you could trust the police with a partial, one-step-removed view of your network's comings and goings.
Intelligence that lets police cybercrime teams better equip themselves to tackle threats to small businesses and public-sector organisations is, again, no bad thing. Even if the resulting advice is "find a SOC-as-a-service contractor who knows how to mitigate these threat types", it's better than nothing at all – and it's better than police simply not understanding what's going on in the real world.
What doesn't help the general anti-cybercrime effort, however, is police declaring that independent security researchers are wrong while their contractors accept that the feedback is useful. Neither is it helpful that those contractors appear to be silently updating their products as a result of that feedback while infosec professionals with findings that deserve a second look are publicly lambasted by police.
It is sad that Moore has felt driven to contact his lawyers over the cease-and-desist letters he received from the NPCC. The Register hopes that he, the police and Pervade are able to resolve their differences amicably. After all, none are on the side of the crims that Cyberalarm is supposed to help defend against.
As for Cyberalarm itself: if you trust the police, it probably won't hurt to install it. If you've got the budget, however, your organisation would also benefit from signing a contract with an IT security firm.
