Without giving too much away (ooh), I have a desktop application that connects to a server and downloads a data file. The data file contains URLs, some point to web pages and some point to installer packages. The data file also contains a HASH of the contents along with various salting.
I’m worried that a hacker could potentially break through and then use this data file to install malware on customer machines. Currently there are two hurdles in place.
#1 Need to break into the file server. #2 Need to figure out at the very least how to simulate or recreate the hash.
So it boils down a hacker breaking the first two steps and then changing the URLs to point to MacKeeper, or whatever the current malware is. I thought about hardcoding my app so it won’t open any urls that are not on my server, but then I realized for them to get this far, they have access to my server and so they could place files on my server to redirect to other locations.
While most people I’ve discussed this with, think two steps is enough, I’m not convinced. And would like to see what you guys think.
Does your app use https to communicate with your server? Then yes, this security should be enough. If someone breaks into your file server you will have different problems.
Are the URL’s fixed but different users see different ones? You could obfuscate all the URL’s into the app and then just hash which files the user has access too. That way there is no way the data file can “drive” the application.
Yes it will, so no man in the middle attacks. Which would also be nullified due to the hashing/signing of the data but what I’m worried about is if someone compromises the server, and then cracks the hashing/signing they could replace the URLs with anything they wanted. Maybe I’m worrying too much?
Hmm… No the URLs are not fixed and it’s part of the process to be able to supply a data file that contains URLs.
My initial thoughts on hardcoding domains, were say to reject URLs that are not on “ohanaware.com”, but then I realized that in order for them to change the data file, they need access to “ohanaware.com” and therefore it’s irrelevant.
The URL’s that get built are clearly not secret right? I mean the user becomes aware of the URL when you presumably open a browser or web view. SO perhaps your data file should be transparent. IE: You can “sign” the datafile to verify its authenticity but you show the URL’s in the clear. This way if a users computer does become compromised you can clearly point out that it was security on their system because you provided X.
I would use the Crypto module to generate signatures instead of just hashing. Keep the private key off your server, public hard coded into the app. This stays secure, even if the attackers knows everything about your system. Per Kerckhoff’s Principle, assume the salt can be found. Yes, the public key can be changed in your app easily, but at that point the computer is already compromised.
This guarantees that even if a malicious URL list makes it to your app, it can’t infect your users. They won’t be able to generate the correct signatures. At that point, HTTPS isn’t even required anymore, but I’d still use it as long as you’re using Xojo.Net.HTTPSocket and not HTTPSecureSocket.
This was a vector for the hack of Puush a while back, someone compromised their update server with an infected update, even to the extent of excluding Australia from the change (thats where the devs were).
As Phillip said, sign your data and check the signature before using it. Also check signatures on patches before installing/using.
Yeah, that’s a good idea. I’m using a HTML viewer to display generated HTML content, so I can make sure that when a user mouses over a link the URL is show.
Thanks for the advice, I’ve just started experimenting with the RSAsigning that’s built into Xojo. Hopefully it will take a long time for a hacker to break. I saw today that back in 2010 it took two years to crack a 768Bit key, so 1024 or higher should make it not worth their time to crack.
If the user is running a version with a modified public key, they’re already compromised and most likely (he says) not via our system.
My concern is if the hackers figure out a way to simulate or fake a file signature that’s accepted. I think after reading how long it could take, perhaps I am being overly paranoid.
Thankfully updates are taken care of, but this was something that I’d worried about also. My update system works only with code signed Apple installers (at the moment) and the code signature is compared with the one on the application.
But I realized that if the data file (not the update) were cracked, then other URLs could be used to trick the user into downloading nasty things.
Thanks guys for all your input, sometimes this stuff floats on top my head and I’m not sure if I’m worrying too much, not enough, but I really don’t be used as a route for distributing nasty stuff.
https does not guarantee a safe connection alone. In manipulating DNS a wrong server could be presented to your app. A lot of apps failed in validating the certs. Another approach: Downgrading encryption from a strong cipher to a weak one e.g. 3DES, SSLv1, SSLv2. This could be done with a proxy server making your https communication transparent. This is why you shouldn’t use Microsoft Outlook 2007 or Microsoft System Center Configuration Manager 2012 in networks today cause they’re still accepting downgraded 3DES, SSLv1, SSLv2 ciphers which should be considered as unsafe.
Despite your client app you should keep an eye on your https server: observatory.mozilla.org and ssllabs.com tests could provide a good starting point. As you mentioned in your title how much security is enough you should consider to which degree you extent your security.
In the past I used an updater like you. I stopped this last year only showing user “there is a new version” forcing him to download it from my servers by himself. So I am out and no one could make me responsible for bringing the malware in.
Yes, you’re being paranoid. If RSA encryption falls, trust me, the internet will truly have broken. Use a 2048 bit key, performance is barely different but the effect is exponentially better. Current SSL vendors require a 2048 bit key, and this is literally the same encryption type.
you don’t understand me. It’s not about breaking RSA.It’s more about misconfigured webservers offering broken ciphers to clients and/or not enforcing ssafe ciphers.
CLIENT: Hey Server here I am! Lets speak encrypted.
SERVER: Fine! I have ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDHE-ECDSA-RC4-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:SRP-RSA-AES-128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-AES-128-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-SHA;DES;RC4;MD5;PSK
CLIENT: Mmm howdy thats a long list… lets see… I’ll pick DES… yes DES sounds fine to me…
SERVER: Fine DES…
… and from now on your “secure” connection is anything but not secure anymore.
[quote=320746:@Tomas Jakobs]you don’t understand me. It’s not about breaking RSA.It’s more about misconfigured webservers offering broken ciphers to clients and/or not enforcing ssafe ciphers.
CLIENT: Hey Server here I am! Lets speak encrypted.
SERVER: Fine! I have ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDHE-ECDSA-RC4-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:SRP-RSA-AES-128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-AES-128-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-SHA;DES;RC4;MD5;PSK
CLIENT: Mmm howdy thats a long list… lets see… I’ll pick DES… yes DES sounds fine to me…
SERVER: Fine DES…
… and from now your “secure” connection is anything but not secure anymore.[/quote]
No, I didn’t misunderstand you. I wasn’t replying to you, sorry. My reply was specifically referenceing this comment:
The other thing I came up with last night was secondary authentication.
When I “publish” the data file, I submit the file signature to a encrypted secondary server on a secondary system.
Once the end user app has verified the signature against the data, it then checks the secondary server to see if the signature exists.
I don’t think I’ll integrate this just yet; but maybe down the road in the future. This way, if they crack the private key for the RSA signing, there’s a whole different server they have to crack.
[quote=320808:@Sam Rowlands]The other thing I came up with last night was secondary authentication.
When I “publish” the data file, I submit the file signature to a encrypted secondary server on a secondary system.
Once the end user app has verified the signature against the data, it then checks the secondary server to see if the signature exists.
I don’t think I’ll integrate this just yet; but maybe down the road in the future. This way, if they crack the private key for the RSA signing, there’s a whole different server they have to crack.[/quote]
You’re overthinking it. Your private key will not be cracked. At 2048 bits, it’s well beyond the realm of possibility by today’s standards. The only way to compromise the system would be to steal the private key. They’d need access to your personal computer. At which point, they could just get the source code. And worse.
Understood… Security is an area where I have enough experience to be dangerous, but not enough to be truly knowledgable. I just can’t get past the fact that no matter how long it takes today (or 7 years ago), everything I do can be undone by someone else.
To me security is just an illusion, be it computer security, home security, car security or airport security.
This isn’t like physical security. The windows in your home can be smashed. Security guards can be paid off or worse. Safes can be broken. This is all true. But this isn’t physical, this is math. It won’t fail you.
This encryption/signing will stand up even when all variables, except the private key, are known. It is well documented and studied, there is no obfuscation here.
So implement it, keep your private key safe, and it won’t fail you.
in theory yes and I totally agree with you but in practise implementation is the key. if an app or server fails here, the strongest encryption rendered obsolete.
Not really. There’s only two possibilities for failure that I can see:
The private key is stolen. This really needs to be protected at all costs.
A vulnerability in RSA is discovered. This would likely cause a meltdown of the global economy, as all of ecommerce relies on it.
It’s otherwise infallible. A compromised server is exactly what the signing defends against. A compromised app is already a lost cause and something that we have no defense against anyway.
ah ok np…