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.
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.
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."
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.
Not surprising, this device does everything wrong and provides neither of those things.
(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.)
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.
Though I don't think the FSF speaks on behalf of socket0, or vice versa.
"nomx Passes Security Tests After Blogger Claims to Have Penetrated nomx
- UK blogger makes false claims he can access nomx remotely
- UK blogger fails to access nomx remotely"
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.
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.
I guess, at least it isn't running it in conjunction with sendmail https://threatpost.com/no-fix-for-squirrelmail-remote-code-e...
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).
I guess there's some theoretical benefit possible there but if you're worried about your ISP reading your email, just use GPG.
Nomx may be terrible, but it's not their fault you can't send mail to hotmail.com
Edit: here is the price list for sending mail to hotmail.com https://returnpath.com/wp-content/uploads/2015/06/Return-Pat...
It's free. A bonus of this is that you get reports about emails from your IP that their users mark as spam.
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!
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.
You should not be able to originate any mail from EC2.
> 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 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?
Australian ISPs kill anything outbound on port 25 also.
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 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!?
With IPv6 some issues could be solved.
Are there other examples of similar systems?
That's so hilariously misguided I don't even know where to start!
"31 March 2017 16:52: Asked for confirmation of receipt of earlier email given apparent email issues.
4 April 2017 11:13: Asked for confirmation of receipt of earlier email given apparent email issues.
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.
That will be an easy win for whoever submits first.
>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...
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).
- The default credentials are "firstname.lastname@example.org" + "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!).
- 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.
- The device uses GoDaddy for dynamic DNS. I'm curious why this is so bad; is it because GoDaddy DNS doesn't update rapidly?
- This kind of reminds me of http://thedailywtf.com/articles/The-Expert-System
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 provides encryption, but no authentication nor authorisation. In short an ever so slight improvement over normal SMTP.
> 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.