[Solved] JD2 updates are sent over plain HTTP, easy to MITM and exploit

[mikebell]

Guys,

Are there any plans of switching to HTTP+TLS connections for updates anytime soon? Just looking at the wire, I see that JD2 still uses HTTP which is trivial to intercept and send malicious code to.

17:36:00	http://update.appwork.org/jcgi/pkg?rt=SO&jn=JDownloader.jar&pv=1&uid=[uid]&pkh=[pkh]&app=JD&os=MAC&arch=X86&os64=1&jvm64=1&urev=4731&ct=Normal&dst=-1&rev=4723&awfcxz=1&eid=translator%2Cscheduler%2Cchat%2Cfolderwatch&eir=&eip=&lng=en&chlg=0&jdiff=1&1420756559855	GET
17:36:07	http://update.appwork.org/jcgi/pkg?rt=SO&jn=JDownloader.jar	HEAD
17:36:08	http://update.appwork.org/jcgi/pkg?rt=SO&jn=JDownloader.jar	GET

Sending updates over TLS with a pinned certificate would go a long way in assuring JD2 is safe to use.

Unless you're running JD2 inside of a VM, I'd be careful about hitting that Update button or having updates turned on automatically.

[mikebell]

Another security issue with JD2 is that NONE of the jar files are signed.

I checked a bunch of them and not even the core.jar is signed.

Core.jar
jar is unsigned. (signatures missing or not parable)
JDownloader.jar
jar is unsigned. (signatures missing or not parsable)

Given that none of the jar files are signed and given that updates are served over plain HTTP, JD2 is potentially unsafe to use and a big security risk that cannot be easily mitigated.

Suggestions:

1) start signing JAR files. start signing updates and install them only when they've been verified.

2) serve updates over TLS and pin a cert within the app itself and only accept updates from servers that match signatures.

Right now, there is absolutely no way to tell whether the JD2 has been compromised or not.

[pspzockerscene]

Hi
Please send all of this to support@jdownloader.org.

GreeZ psp

[mikebell]

Originally Posted by pspzockerscene

Hi
Please send all of this to support@jdownloader.org.

GreeZ psp

Sent!

best, mike

[raztoki]

Jiaz did answer via email, but the gist is...
- protocol type has very little to do with been secure with this update system.
- updates are signed by the update system and checks are in place.

At worse when goes to install and the signs do not match, updates will not install. It can't be high jacked along the lines of OP posts.

Originally Posted by raztoki

Jiaz did answer via email, but the gist is...
- protocol type has very little to do with been secure with this update system.
- updates are signed by the update system and checks are in place.

At worse when goes to install and the signs do not match, updates will not install. It can't be high jacked along the lines of OP posts.

I can change anything in your data connection without secure connection like https. Example like other jdownloader.jar as website download. All other options are nice but not secure enough, maybe. More informations under ssllabs.com

FAIL1:
**External links are only visible to Support Staff**
**External links are only visible to Support Staff**
Result: No https connection (no secure connection)

FAIL2:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
Result: No https connection (no secure connection)

FAIL3:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
Result: No https connection (no secure connection)

Any question? No? Okay! I replace all jar files in the http connection with my evil jar files. Please use ALL ways to secure the updates and websites, THANKS!

[Lram32]

Please contact jiaz via EMail support@jdownloader.org
Then wait for his answer.

[raztoki]

How exactly are you going to replace jars without already having the client side compromised or the update server compromised?

or are you referring to installers themselves? Either way you would need to be control of transit (which could include your ISP) todo so such damage, unless I'm mistaken?.

@mikebell
Why the hell are you posting this in public ? Everybody can read in here. You don´t even have to be registered.

My opinion: Mike isn´t wrong. HTTP isn´t the way to go. Evil people will find a way.

[pspzockerscene]

@aeneon
As you can see until now he was not able to really tell us something we'd have to be afraid of - also our devs know about the "issue".

GreeZ psp

[mikebell]

Originally Posted by raztoki

Jiaz did answer via email, but the gist is...
- protocol type has very little to do with been secure with this update system.
- updates are signed by the update system and checks are in place.

At worse when goes to install and the signs do not match, updates will not install. It can't be high jacked along the lines of OP posts.

Hi,

Got a quick email from Jiaz. I won't go into too many details (to give bad guys even more clues but none of this is really advanced or intermediate... this stuff is basic as it comes) but your first assumption is wrong. Secure protocol is the #1 line of defense against an attack on any system.

I did not see any cryptographically signed updates. None of the updates served are recognized by Java6/7/8 verification checks.

Test it yourself:

jarsigner -verify /Applications/jDownloader.app/Contents/java/app/JDownloader.jar

Rolling out your own crypto signature system is a recipe for disaster and can always be bypassed since JVM is the only trusted part of the system and the only entity that can authenticate signature without being tricked into validating fake certs or other schemes.

Originally Posted by raztoki

How exactly are you going to replace jars without already having the client side compromised or the update server compromised?

or are you referring to installers themselves? Either way you would need to be control of transit (which could include your ISP) todo so such damage, unless I'm mistaken?.

You need to learn about MITM.
https://en.wikipedia.org/wiki/Man-in-the-middle_attack

Anyway, hope the changes in the future fix these two issues. Until then, I recommend people run JD/JD2 only within a VM since there are always java 0-days for privilege escalation available on black markets. You simply don't know if an update one day will include it as a payload. And JD2 update conveniently includes the OS, arch type, Java version etc so proper payload targeting is trivial.

Solution: HTTPS and let JD/JD 2 validate that the TLS web server is authentic. (Certificate)

Sadly it costs money and JD 2 is freeware. I don´t know if appwork earns enough money with JD to pay for a CA and more.

Maybe we (the JD community) could donate somehow. Fundme ? I would donate a few bucks.

[mikebell]

Originally Posted by aeneon

Solution: HTTPS and let JD/JD 2 validate that the TLS web server is authentic. (Certificate)

Sadly it costs money and JD 2 is freeware. I don´t know if appwork earns enough money with JD to pay for a CA and more.

Maybe we (the JD community) could donate somehow. Fundme ? I would donate a few bucks.

You can get a cert for as little as $8/year.

In JD2's case, they could use self-signed certs since they're not going to be exposed to browsers so whether the cert is recognized by browsers is irrelevant.

However, CA-recognized cert is better for code signing.

**External links are only visible to Support Staff****External links are only visible to Support Staff**

App can easily check if the cert is valid, expired and whether it has been revoked.

[pspzockerscene]

Are you serious?
So all of the sudden this is a major security issue?
I'll stay out of this conversation but please don't make our users paranoid.

GreeZ psp

Originally Posted by mikebell

You can get a cert for as little as $8/year.

However, CA-recognized cert is better for code signing.

App can easily check if the cert is valid, expired and whether it has been revoked.

That´s what i said. Regarding the 8 Dollars.... You`ll also need the hardware, bandwidth, administrator, coder to implement this stuff into JD 2. It´s not just 8 Dollars.

Originally Posted by pspzockerscene

Are you serious?
So all of the sudden this is a major security issue?
I'll stay out of this conversation but please don't make our users paranoid.

GreeZ psp

Ok But as a network administrator i have the rule: Better safe than sorry.
The CA and Cert-Solution would make it much harder to "compromise".

I´m also out of this conversation. That´s all i had to say.
Isch habe fertisch haha

[coalado]

Ok. Time to make this clear.

First of all: IF you find a security problem, contact the responsibles first in private, and give them a chance to fix it. If they don't do it, think about going public. If someone finds your door open, you'd probably prefer to get notified in private instead of reading about it in the newspaper. Anyway....there is no open door in the Update System, so we can continue to discuss this in public.

1) We do not use Jar signing, because this would not help us in any way. This would not improve security


2) How the Updates work.

The Update System uses a private/public key pair. The private Key is secret, the public key is known by the update server and all clients.
Here is the deploy process:

1. A Build/Deploy Server builds JD and does Tests on it. It's important to note, that the Build, Test and Sign Processes are not accessible from the www.
2. The Build/Deploy Server sends the new binaries to our Deploy Process
3. The Deploy Process uses the private key to create a signature of every file (all files and update instructions) This signature contains the version of the file.
4. The Deploy Process pushes files and signatures to our Update Server
5. The Update Server validates all signatures and accepts the new version
6. Done

When a Client requests an Update.. this happens:

1. JDownloader sends it's current version to the Update Server
2. The Update Server creates a package for him (incremental Updates)
3. This package contains all changed files and instructions AND their signatures
4. The Package gets encrypted with the public key, and spread to all update content distribution servers
5. The Update Server returns all references (urls) to the client.
6. The Client Downloads the package, and extracts it (public key)
7. The Client validates all signatures (public key) and continues only if the signatures match
8. If one or more signatures fail, The update will not get installed!

Think about this process, and you will see that this is MUCH stronger than any tls or ssl can ever be. Even of an attacker could control one of our update servers, he could - in the worst case - cut the users from getting updates. He could not distribute any data - the private key is missing.

A Man-In-The-Middle could modify packages - if he knows the public key, but during installation, the signature validation would fail, and the update will get rejected.

This is why, there is no reason for any additional man-in-the-middle protection.

Thanks for clearing this up. It sounds really secure. No offense coalado, but i don´t know if it´s a good idea to post the whole process in public.

[coalado]

Originally Posted by aeneon

Thanks for clearing this up. It sounds really secure. No offense coalado, but i don´t know if it´s a good idea to post the whole process in public.

This System has to be secure by design, and not by obscurity. A public discussion can help us to make it even better.

[raztoki]

As I said earlier, its secure! Which I did allude too. Hopefully this helps those in this thread that thread think they know better, without knowing the facts. I was hoping that Jiaz cleared that up in email, but maybe not.

Originally Posted by raztoki

As I said earlier, its secure! Which I did allude too. Hopefully this helps those in this thread that thread think they know better, without knowing the facts. I was hoping that Jiaz cleared that up in email, but maybe not.

We care and we wanna make it better. This is why Mikebell posted here. This is no competition about who is right or wrong. And if you really think,"it´s secure", you are wrong. Nothing in the IT-Field is 100% secure. There are always flaws and bugs and whatsoever.

There are always people that will game the system and use it for their advantage. Never underestimate people und their abilities. And never overestimate your own system.

Trust me. I know what i´m talking about. Especially in the IT-Field.

[pspzockerscene]

@aeneon
No one said it's 100% and anyone who'd have said this was wrong!
If you have the knowledge, go on and "hack" it - as long as you tell coalado first its all fine.

GreeZ psp

I´m not a hacker.

But..... your server seems pretty tight and secure. Nice work. Checked just a few small things in less than 2 minutes. Don´t worry.

I don´t know if my information is correct. If you are still using nginx 1.5.6, i would update. If i would try to hack your server, i would probably try to exploit svnserve on port 3690 first.

good discussion ... and thanks for this great app jdownloader .

[Jiaz]

@aeneon: you can contact me at support@jdownloader.org (in case you want to talk about this or find some security issue)
-nginx are all up2date (depends on used distro version)
-lighttpd are all up2date (depends on used distro version)
-svn is newest available version, so I hope not exploitable
-many services run in their own vm
-still working on server migration so many older distro will be gone soon

[raztoki]

@aeneon
My statement wasn't directed at anyone in particular, just those that didn't believe that the update system wasn't designed with security in mind. I also never stated it was 100% secure, other than it was secure (to the best of our knowledge). Without any proof of concept or disclosure to prove otherwise, we still believe its safe. Hopefully now the users (many with worry/uncertainty) in this thread, now have some understanding of how the update system was designed/works (in the real world) without the need to make assumptions. I also have IT based background and I comprehend that even with the best intent, hardware and software can be used outside architects/programmers parameters.

raztoki

Originally Posted by Jiaz

@aeneon: you can contact me at support@jdownloader.org (in case you want to talk about this or find some security issue)
-nginx are all up2date (depends on used distro version)
-lighttpd are all up2date (depends on used distro version)
-svn is newest available version, so I hope not exploitable
-many services run in their own vm
-still working on server migration so many older distro will be gone soon

I will Great work you are doing there!

Originally Posted by raztoki

@aeneon
My statement wasn't directed at anyone in particular, just those that didn't believe that the update system wasn't designed with security in mind. I also never stated it was 100% secure, other than it was secure (to the best of our knowledge). Without any proof of concept or disclosure to prove otherwise, we still believe its safe. Hopefully now the users (many with worry/uncertainty) in this thread, now have some understanding of how the update system was designed/works (in the real world) without the need to make assumptions. I also have IT based background and I comprehend that even with the best intent, hardware and software can be used outside architects/programmers parameters.

raztoki

Right now i think it´s safe too. It´s all good