Wow. The title kind of gave away that this was going to be a fun read, but I did not expect it to be that bad.
Even if the vendor did not make those bold claims and simply sold it as a hassle-free email appliance for home users and small businesses, it would be borderline fraudulent. With the bold claims attached it almost looks like performance art to ridicule all the snake oil-peddlers out there.
It's unlikely to be performance art, and if this isn't fraud it's gross negligence. Does anyone know of any British legislation that refers to the sale of these types of products?
I read through the patent application cited in the article [1] so I can explain what the device is supposed to be doing.
The "secret sauce" is it can send email between two Nomx devices without using DNS or other third party servers, avoiding DNS attacks. The handshake between two devices sets up DNS records on each device so they can locally resolve each other. There's a mechanism so if a device changes IP address, it informs the other paired devices, with some sort of authentication.
So, it's not just a standard email server running on a RasPi, but does have something new. (To be clear, I'm not defending this device, just explaining what I learned from the patent.)
It's suspicious that the article's author didn't see any network traffic between devices when the handshake was set up, which makes me wonder how much of this is implemented. A couple followup experiments the author could do: a) verify that the device doesn't do an external DNS after the handshake. b) see if changing one device's IP address causes the other to get updated.
> There's a mechanism so if a device changes IP address, it informs the other paired devices, with some sort of authentication.
Except there appears to be no evidence that there is such a mechanism.
and as i336_ here stressed:
"The device is designed to send TLS-encrypted mail from nomx device to nomx device on port 26, BUT IT IS ENCRYPTING USING THE DEFAULT Postfix "snakeoil" TLS CERTIFICATE."
From what the author found, it seems pretty clear to me that that patent is nothing more than an idea on paper right now. If the device doesn't send anything over the network for a "handshake" then it isn't a handshake at all. Also, I'm not sure if the author added detail or not but it makes it quite clear that the web interface simply adds a row to the handshake table with the fields entered and nothing else. He also found that the only other place in the GUI that references this table at all is to display the existing "handshakes".
As far as how it actually works on the device the author also showed the relevant portion of the postfix config where it checks if the domain is in the handshake table and if it is then connect to that IP on port 26 with the hardcoded default cert.
Maybe they plan on creating something based on that patent someday but right now what they're selling as based on that patent has nothing to do with it.
Calling your product 'the most secure' and 'ensuring absolute privacy' should already set off alarm bells for anyone interested in either security or privacy. It's the kind of marketing that no one in their right mind would use if they knew much about either.
Not surprising, this device does everything wrong and provides neither of those things.
I find these kinds of stories infuriating (and just a bit frustrating). Charlatans repackage, rebrand, and repurpose FOSS, then sell them at an unrealistic markup to unsuspecting dupes. Anything from PABX or VoIP systems based on Asterisk, through overly complex CMS's based on Wordpress. I'm not sure what riles me more: consumers being ripped off by these products, or the fact that my strengths lie in tech rather than sales.
The FSF has always made clear that they don't have any problem with people selling Free Software; it's about freedom, not low low price.
(What infuriates me about this story is that it reminds me of how far companies like Google have destroyed Mail as a protocol usable without their intermediation. Use Googlemail or get your mails spam-binned.)
Of course not! A decentralized, federated solution where everyone running a service takes responsibility for their service and ensures high standards are adhered to is preferable, desirable, and possible.
So preferable, in fact, that professionals have tried! Extensively, exhaustively, and at great length. New standards have been devised. New protocols designed. Newer, more clever ideas pioneered and deployed.
Several decades of trying that approach with results being somewhat below what could be hoped for led users and administrators alike to look for alternatives.
The nature of the problem at hand is that in a highly decentralized system where the cost of use is borne by the receiver and breaking backwards compatibility isn't acceptable, it is extremely difficult to stem abuse. Measures that could stop or diminish abuse will not be taken by abusers, and the need to preserve backwards compatibility prevents cutting off both them and legitimate users on less modern services.
It's a shit scenario. It didn't have to be this way! Yet, there don't seem to be other options on offer that deliver equivalent or better benefits for equivalent or better costs in time and treasure.
If you are distributing a product using GPL code aren't you supposed to explicitly display the license in the product manual or somewhere else ? The end user is not supposed to have to open a product case to find out... I have not seen it mentioned in the original post. So this is a license infringement as well.
Definitely. The problem is that consumers (especially small business) so often end up buying an overpriced and badly configured black box, when a decent expert would have been able to set up the same software properly.
Three sentences into "Security testing" section and you have to wonder if they have ever heard of an evil maid attack. Along with outdated kernels that have remote execution bugs, CSRF / XSS bugs, outdated versions of PHP, etc. You really have to wonder if they have any real world security knowledge or skills.
> You really have to wonder if they have any real world security knowledge or skills.
I wouldn't even be the least surprised if they turned out to be genuinely honest and convinced about their own skill.
I've talked to a guy that could tell you right in the eye that a HTTP redirection never hits the UA and goes straight to the second server so it's safe to pass plain credentials in there.
Another one goes out of its way to (please follow through) derive an AES256-CBC key from a user's password using PBKDF2, said key that ends up being sent over HTTP(not S) right along with the encrypted payload that turns out to include said password, but we're safe because that goldberguesque non-encryption is base64-encoded as a second layer. In a flash of foresight, as additional defense in depth, within that encryption the password is actually hashed by the client using plain SHA256, sent on the wire and compared as is with the db record. Please note the irony of using PBKDF2 nearby for the noop key. Well, when viewed as a whole the thing is ironic on so many levels and whatever the angle you look at it that at some point you have to convince yourself this is just an elaborate joke to keep any manner and composure.
Some people just don't get security. Or logic. Or computers. Yet they're being trusted into writing software and building systems, sometimes critical ones, sometimes medical ones. That, defies the mind.
> Addressing the issue of old software, he said Nomx planned to let users choose which updates should be applied to their device.
> "We will selectively allow users to pick and choose when that becomes available but today we're not forcing any types of updates," he said, adding that updates can introduce vulnerabilities.
> "Updates actually cause a cascading effect and now you're patching patches and that is not a good place to be in," he told Click.
I don't understand the point of this, even if it worked correctly.
If I understand correctly what it does is create some kind of secure tunnel between two nomx devices if you tell it to. But doesn't starttls do that already if you configure your mail server that way? And it already just works with any compliant email server?
So unless I'm missing something there's absolutely no doubt in my mind that this is a scam. Kudos to the author for bothering to find flaws in the admin interface but honestly at this point I'd just have reflashed the raspberry pi and used it as a media center.
Even the first picture with the case open is already a huge red flag, not because of the raspberry pi but because of the botched glue gun job.
The thing I think it is trying to do is enforce that TLS is used for the known domains. Starttls as implemented in most SMTP servers normally allows fallback to non-encrypted delivery (it's opportunistic).
This kind of agreed upon enforcement has been possible in many email products for years though (I worked on one which could do it about 10 years ago).
The real story here, is that if you try to set up your mail server so that you can send mail to a microsoft email server such as live or hotmail, you eventually end up here where they ask for a bribe: https://returnpath.com/solutions/email-deliverability-optimi...
Nomx may be terrible, but it's not their fault you can't send mail to hotmail.com
I know you work on a lot of email tools. What is your go-to resource when someone asks about deliverability? If you're written something up yourself I'd appreciate a link!
Just wanted to say that building a site around this info would draw a lot of traffic - perhaps much of it coming from the spammers! A solid amount of legit info in one place would probably lead the big webmail providers to have to change their tactics, so it owuld be a commitment to keep it updated.
That's strange: I have my own hosted mail server (on a static home IP) and I haven't had a problem with hotmail (but I've got DKIM, reverse DNS, and SPF configured)
That's exactly what make this kind of home mail server box impossible on dynamic IP and even on most of ISP providing static IP. As long as you can't set the reverse DNS for your IP, mails will be rejected.
Can you prove this? I've also set up DKIM, reverse DNS, and SPF, but Microsoft places mail sent from my AWS box straight into the spam folder. Every other email provider that I've tried has been able to receive my email correctly. Microsoft is the only one asking for a bribe to do so.
I've even tried to contact them by phone and their support forum. On the phone they told me that this is a "feature": all mail goes to spam folder until the client whitelists the sending address. This is false, and on their support forums I was told that my static IP from Amazon "is not eligible for appeasement" or something like that.
When you look at what Microsoft has done with Skype and Windows, it's fairly obvious that they don't care about security. Even so, I find it especially egregious that they are offering a "pay to spam" service while at the same time knowingly blocking legitimate email.
I have it all configured and I still cannot send mail to my parents. Though maybe having a Czech domain name doesn't help. The strange thing, is that the bounce emails directly link to the website asking for the bribe.
It is a bribe, given that you are allowed to send SPAM if you pay up. This isn't an attempt to prevent SPAM, it is actually a policy that allows you to do so if you pay.
> Contrary to the blogger's claim that this was an easy, simply hack, in fact, the blogger couldn't make the code work and requested other participants to support his attempts and publicly stated so on his blog. The "payload" he developed was from a third party named Paul.
That's embarassingly bad logic. The fact that this particular guy wasn't an expert at XSS doesn't make the hack hard, and the fact that it exists at all is the issue. What a bunch of fuckin' jokers.
If i understand this correctly, the device is (apart from being the least secure thing ever) basically useless at it's function, since it doesn't support SPF/DKIM/DMARC and you can't get it to use HTTPS and as such will bounce off every single correctly configured email server in the world?
If i remember correctly, when i tried to setup my own email server with my domain on a VPS box, i had to go through the whole nine yards of getting a letsencrypt cert and setting up lots of voodoo stuff before i could send mails to anyone but myself.
Also, how are you supposed to use this at home at all, if most residential ISPs (at least here in germany) block any Port 25 traffic?
I really can't tell whether this is an outright scam, or an earnest attempt by someone completely unqualified (and completely unaware that they're unqualified, per Dunning and Kruger).
At the very least there was bad faith from trying to stall and making false claims about updates and disclosure to costumers in the e-mail chain between Scott and them.
I'd also doubt they "had two of the largest security firms provide remote and "in hand" vulnerability assessments on nomx", or else they just completely ignored their advice.
I'm feeling it's an earnest attempt by someone to set up a p2p email system (that will also send email normally), that wasn't quite finished (like: how will we handle certs, what about dynamic IPs) but was picked up by someone good at marketing who convinced then it was awesome and has created a tidy looking package, etc..
I actually like the idea: a plug-and-play email device that will do p2p with your known contacts.
Just needs more development to make it work, and then some more to make it work securely!?
They ripped that straight out of the OWASP CSRF cheat sheet, under "Personal Safety CSRF Tips for Users". Yep, clearly nomx's issues are all just user education issues.
While I have a summary post elsewhere in here, at the risk of being a bit spammy I'm double-commenting the following bit:
The device is designed to send TLS-encrypted mail from nomx device to nomx device on port 26, BUT IT IS ENCRYPTING USING THE DEFAULT Postfix "snakeoil" TLS CERTIFICATE.
The rampant goalpost-moving in their response suggests that they'll never actually pay out. I mean, their response to the author pointing out that it can be infected by drive-by malware sites is "don't visit those sites".
Many years ago, I've been working on similar (but better ?) SMTP security device [1], that was doing on-the-fly email encryption by catching outgoing SMTP connections and encrypting their content. One only had to setup some keys and stick in in the outgoing network and it worked - like PGP, but without the need to setup it on every device. But, they are already out of business now...
This (statistics on the nomx rebuttal pages) must be coming from some kind of alternate universe:
>For Media - Some statistics:
Number of nomx accounts that have been compromised since inception: 0
Number of Gmail accounts that have been compromised in the United States (from 2014): About 5 million to 24 million depending on source
How about the TOTAL number of (respectively) nomx accounts and gmail accounts (from 2014)?
I mean, 0/(something) is undoubtedly a smaller number than 5-24*10^6/(a very HUGE number), but maybe the (something) is so little that the target in itself is irrelevant...
Interesting findings. Though I didn't get why the author concentrated so much on the security issues of the UI while the real issue is that the whole thing is snake oil. I mean - what if the UI was great, had https and there were no CSRF vulnerabilities? Would this be considered a secure product?
I STRONGLY recommend reading just the first bullet point below.
I'm wondering whether this is someone running a scam or whether they don't fully understand technology and some evil tech has taken them for a ride. It's that bad.
Some paraphrased/elided highlights from the article:
--
Practicality as a secure mail device:
- The TL;DR of the "unbreakable security" is that the device sends TLS-encrypted email on another nomx device listening on port 26... USING THE DEFAULT "snakeoil" Postfix TLS CERTIFICATES.
- The device sends from port 25. Or rather, it tries to - it worked for the post author, but I can personally say this would not work for me; my ISP blocks port everything outgoing on port 25.
- The device tries to relay mail from a residential IP. Predictably, all commercial email systems shut this down the moment they see it. Hotmail has the decency to actually kick the email back; other providers seem to just silently drop it.
- The device will immediately put your IP on DNS blacklists because you are sending mail that looks 100% like spam. These blacklists are used by a variety of online services so this is likely to catch up with you in a big way eventually (one thing I just wondered is whether Google checks your IP this way when deciding how complicated to make the captchas it sends you).
- When you set up a link to another nomx device (it calls this a "handshake"), you have to do it by IP address. There is no mechanism to autoupdate the remote IP (I do acknowledge such a system would be mildly nontrivial to put together, but I think this is already at the "doing it wrong" stage and this type of solution is not what is needed here).
--
Security considerations:
- The default credentials are "admin@example.com" + "password" and there is no requirement to change this upon login.
- The device is so full of vulnerabilities it's possible to pwn it by simply visiting an arbitrary malicious Web page (from any web site on the Internet) that scans your network to find the device - once that's done the malicious page can fire off a series of form submissions (probably also doable via XHR) to gain a login cookie, create a new admin user that will not be visible because the device is only capable of listing one admin, and then...
- With the device pwned, it's possible to take it over completely, create arbitrary incoming email addresses, and attempt to send mail from the device, from your IP. Your computer doesn't even need to be on for this to work, obviously. I say attempt to send mail because most of it will be blocked, but you could easily take someone down by sending highly offensive mail to a provider that let the email through - bam, your IP is on file as having sent the email.
- Thunderbird required repeated manual verification of the device's TLS certificate (something the device purports not to require!).
--
Software versions:
- Raspbian GNU/Linux 7 (wheezy) - last updated 7th May 2015
- nginx version: nginx/1.2.1 - released 5th June 2012
- PHP 5.4.45-0+deb7u5 - released 3rd September 2015
- OpenSSL 1.0.1t - released 3rd May 2016
- Dovecot 2.1.7 - released 29th May 2012
- Postfix 2.9.6 - released 4th February 2013
- MySQL Ver 14.14 Distrib 5.5.52 - released 6th September 2016
The author received no response to his requests for updated versions of the software.
The device also has no autoupdate mechanism, and there is also no mention of such a mechanism being in development.
--
Other thoughts:
- The device uses GoDaddy for dynamic DNS. I'm curious why this is so bad; is it because GoDaddy DNS doesn't update rapidly?
It's $199 to $399 for a plastic case literally just containing a Raspberry Pi 3 Model B, running an outdated Raspian, and the software stack is extremely poorly developed. eg: their "secure handshake between devices" is basically two devices serving SMTP on port 26 instead of port 25.
It's actively ten thousand times worse than that. From the article:
> The device uses self-signed certs throughout and they aren't even device specific. It's using the default ssl-cert-snakeoil.pem and ssl-cert-snakeoil.key in the Postfix config.
Even if the vendor did not make those bold claims and simply sold it as a hassle-free email appliance for home users and small businesses, it would be borderline fraudulent. With the bold claims attached it almost looks like performance art to ridicule all the snake oil-peddlers out there.