Category Archives: Encryption – Decryption

iDrive backup use SSL 2.0

Encryption - Decryption, Vulnerabilities, What have I discovered?Eitan Caspi

Recently I begun using iDrive cloud backup service, using their Windows client.

Being who I am I sniffed around and found that during the backup the Windows app is backing up files to the service server using SSL 2.0, which is considered as not secure.
See a Wireshark screenshot below.

Log of events trying to get iDrive response for this issue:

2-Dec-2019 – I sent an email to their support asking about this problem. I received immediately an auto-reply email with support case ID number

7-Dec-2019 – Since I didn’t get any human reply, I sent another email asking for reply, using the relevant case ID.

9-Dec-2019 – I got a reply that my case was filed under a case ID for all the past enhancements requests I sent before
Right after accepting this email I replied that this is not an enhancement request but a vulner to take care of and that I wish a security employee will contact me

That’s it. Nothing since then. It’s time to go public.

To their credit I must note that they claim their app encrypts the data before it is sent over the network (I didn’t check this part. Yet…).
Still, I believe every layer should be secured correctly.

iDrive backup user SSL 2.0 during backup
TCPView session showing process connections to the same IP address
TCPView process properties for the relevant process, showing it is related to iDrive

Not OK, Google

Encryption - Decryption, Speechless, Web Application Security, What have I discovered?Eitan Caspi

Last weekend I logged into my credit card company web site and accessed the page of my transactions.
Suddenly something strange caught my attention, my Google Chrome browser presented the icon of “unsafe site”…

In my credit card’s web site?!
Not on my watch… 😉, so I looked into the page’s source code and Chrome’s warnings, were one main finding stood out – a red colored error stating:
“Mixed Content: The page at ‘https://<site-domain-name>/Card-Holders/Screens/Transactions/Transactions.aspx’ was loaded over HTTPS, but requested an insecure script ‘http://www.gstatic.com/charts/loader.js‘. This request has been blocked; the content must be served over HTTPS.”
(You can test it yourself using this site, which will show you the server’s response)

Hmmm… who owns gstatic.com? well, Google! The same one who develops the browser that I am using, Chrome… ahhh, the irony….

And as far as I know, Google really works hard to apply strong security and SSL/TLS everywhere, at its sites and services, and pushes the whole Internet towards security. Even the Google’s “unsafe sites” help page states that missing SSL (“secure”) is one of the reasons to present the “unsafe site” icon:
“This page is trying to load scripts from unauthenticated sources: The site that you are trying to visit isn’t secure.”

First thing first – I informed this issue to the relevant person at the credit card company, to simply change the URL to use HTTPS.

Then, being the good digital citizen I am, I turned to Google’s security team and filed an issue about the above.

At the same day they replied:
“
Status: Won’t Fix (Infeasible)
Hey,

Thanks for the bug report. We analyzed it, but there are still some areas we don’t understand fully.

How could this be used in the attack against other users? Please write a more detailed attack scenario – we have prepared some tips on how to create one at https://sites.google.com/site/bughunteruniversity/improve/writing-the-perfect-attack-scenario.

Thanks a lot in advance!

Regards,
<name>, Google Security Team
“

I didn’t even bother to write such a report. SSL/TLS is so basic, that we shouldn’t even drill into reasoning it these days.

In addition, while writing this post I also noticed that http://www.googleadservices.com is also allowing plain text access and does not automatically redirect to HTTPS.
It is also owned by Google and you can also see its server’s response.

Since I know Google is VERY security oriented, this looks strange to me as something that was possibly overlooked. Is it possible that it is so on purpose? To allow access by weaker/older clients? other reason(s)?

 

Update, 13-Nov-19:

Google team just updated their response with the following text:

“
Migrating all the domains to HTTPS, and deprecating all clients that can only talk HTTP takes time. We’re constantly trying to add HSTS support to various services, but we know there’s still much to do in this area. As we already know about our HSTS posture and are actively working on this, we don’t treat the lack of HSTS for a given domain as a bug that needs a separate response, and tracking (see https://sites.google.com/site/bughunteruniversity/nonvuln/lack-of-hsts). Thanks for your research and better luck next time!
“

It didn’t really changed my mind. I am sure they know they can at least auto-redirect the clients, using the server’s response, to the HTTPS version of their sites. My guess is that this is done to try and reach more clients for their services, probably mostly their ads service.

gstatic.com was registered on 2008. googleadservices.com was registered on 2003. We’re towards the end of 2019. They didn’t have the time till now to add SSL to these sites? The mighty Google?
The one which gives better search engine rank to sites with SSL (from 2014)? The company which runs “Project Zero” (also from 2014), which aims to find vulnerabilities at non-Google services and products?

Before you educate the world – clean up your own stuff. Be the example to follow.

“VirusTotal​ Windows Uploader” poor design of privacy

Encryption - Decryption, What have I discovered?Eitan Caspi

Something to share with you, which I am not sure is known enough:

Recently, while I was tweaking a network monitoring systems, I noticed an upload of a file that its name included a full local Windows file path, ending with a name of a file I uploaded to VirusTotal, using their Windows application – “VirusTotal Windows Uploader“, version 2.2, which is the most recent version.

Looking deeper into this I found that uploading a file using this app is performed in a way that:
1. The upload is performed via plain text HTTP. No SSL/TLS based HTTPS is used. Just for comparison – the web site of VT, and its API, forces the use of HTTPS to upload files
2. The uploaded file name is not merely the file’s name and extension – but rather the full path of the file, from the drive letter up to the extension, like “c:\users\dan\Downloads\file-name.exe”

Neither of these issue can be change by the user of the app. The app’s interface doesn’t have any options to change these issues.

Attached at the bottom of this post – a screen shot of a network packet capture that I made – demonstrating these issues.

I realize this app is rather old, possibly from 2013 by its attributes, but I was not expecting that either VirusTotal or its parent company, Google​, who both care about information security – to have such a weak privacy design, running around for so many year, without even informing the users of this app about this way of work, in the app’s page (in the link from above).

I approached VT about these issues, by email, and I got this response:
”
We haven’t updated the uploader in some time, so there are certain issues like that, and we can take them into account. In the meantime, you are welcome to use the Public API to build an uploader setup that you are more comfortable with.
”

I hope that VT will, ASAP:
1. Use the app’s page on their site to inform users about these issues
2. Create a new version of this app – one that use HTTPS, possibly using their own API, and of course – upload only the core name of the file, not including its full path as part of the file’s name

FYI.

Eitan Caspi