Given HOW broken the setup was (it wasn't even a remotely decent mail server setup in the first place, let alone 'the only secure solution' of course), what did we expect?
The marketing material was already screaming snake oil. Now they're trying to put out the fire with .. more snake oil, avoiding any specifics related to the original criticism.
I once worked for a HIPAA controlled healthcare company and complained about their security when I found out all the production database and server passwords were stored in a text file available to most of the company. Their defense was "we passed our security audits so it's ok."
"Security" through obscurity vs. the spotlight of the BBC! Both sides are pretty much true: the simplistic proof-of-concept XSS requires the target device's internal IP address. This product winds up accomplishing its intended purpose simply because of how few active users it has.
It is unfortunate the takeaway from the initial post was a "works on my machine" XSS attack rather than emphasizing that there is only one widely shared public/private key pair "securing" all communication all of the devices. There is plenty of precedent demonstrating that not-private private keys is a serious issue eg. https://isc.sans.edu/diary/22076
Speculatively, all that old software is a juicy target as well (obscured by ARM vs. x86). However, since the security researcher appears to specialize most in XSS that wound up in the spotlight. I'm most curious about how this person was selected by the BBC to review the device. Imagine if Matthew Garrett had done it!
Where are you getting that the takeaway was an XSS attack? There's a whole host of things wrong that the researcher finds — it almost reads like a how-to of bad security.
When you say:
> However, since the security researcher appears to specialize most in XSS that wound up in the spotlight.
I agree a number of things wrong were listed. The one concrete attack demonstrated in the post (the one author put the effort into demonstrating), and thus directly addressed in the response (the takeway chosen by the vendor), was an example XSS [edit:CSRF] attack.
Scott Helme has released a pair of tools focused on making sure websites anti-XSS/security headers are correct. (https://securityheaders.io/https://report-uri.io/ ) The bulk of his public messaging prior to this gigantic luck surface area boost could be categorised as XSS-related (website security headers). I was suprised that he needed help but good on him for being honest.
I am sure this entire process has been a learning experience for Scott and will be a tremendous positive for him in his future endeavors. I remain curious how the BBC chose him; I'd guess he is one of the most polished/presentable security guys in the UK when it comes to network protocols.
Edit: I need to clarify my terminology; when I say XSS above I basically mean everything under the "Web app testing" portion of the original article. (So basically s/XSS/web app testing/ please. In fact it is CSRF that is demonstrated, in my mind they've wound up classified as similar enough to get the idea across.) The security researcher chose to dive deepest into the vulnerabilities that most benefitted his side projects - which makes perfect sense! Is remote root possible with all that old software on an RPi? Feels possible to me.
Nice, I missed that in the big list at the end! That should have allowed the security researcher to make significant progress in the bogus security test with ease.
I'm guessing they've already selected the least suspicious customers. This is basically the best response they can create. They have no real product and no defense, so just reiterating the product is fantastic is all they need to do.
This seems like a bad PR move. Now there's serious questions about the validity of the claims.
I've never heard of Nomx but this really should not be how you should introduce your product by claiming it's safe and you should just believe the website.
They (and a few here) are missing the key point. I'll refer everyone to the passage "One Good Thing" in Helme's article, just above the disclosure timeline. The product does not create an MX record for the email server, hence it is a write-only system. You can't receive email without an MX record because no sender can locate your MTA. I don't care how secure it may or may not be, it's still useless to me.
Technically, MX are not mandatory. As per RFC2821, if no MX is found the A record will be used.
In the past I used this fact regularly when obtaining SSL certificates for subdomains that were pointed at my server. Customer "foo.com" would point app.foo.com at my server for me to host my service for them on their subdomain. To obtain an SSL certificate, I would select email validation to admin@app.foo.com and not need an MX record in the customer's DNS system in order to receive the email, it would be delivered purely based on the A record pointing to my server.
Also, for context, here is the original article from the security researcher: https://scotthelme.co.uk/nomx-the-worlds-most-secure-communi...