Avast WEBforum
Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: Lisandro on November 03, 2011, 10:46:06 PM
-
I was manually updating avast when I saw an Excel file of mine, totally private, was being uploaded to avast.
The file does NOT contain any macros.
Why was it uploaded?
Where is this logged? Which file?
-
I don't know much about the OLE (e.g. Excel) stuff, but I'd say macros are quite a history... with the malware using various exploits in these format nowadays.
So, it might have been some heuristics on the file format that triggered the submit (just guessing).
Also, the file may actually not have been transferred - some completely unrelated event may have occurred during its scanning, and a submission package has been created for that (currently scanned) file - so its name is shown, but with a completely different content.
I believe there's some logging in setup.log.
-
I don't know much about the OLE (e.g. Excel) stuff, but I'd say macros are quite a history... with the malware using various exploits in these format nowadays.
So, it might have been some heuristics on the file format that triggered the submit (just guessing).
Also, the file may actually not have been transferred - some completely unrelated event may have occurred during its scanning, and a submission package has been created for that (currently scanned) file - so its name is shown, but with a completely different content.
Hope it's true.
I believe there's some logging in setup.log.
Well, I believe on that too, but it's not there and I'm absolutely sure about the name of the file when I was updating...
-
That excel must have had your bank passwords and paypal account details.
-
What exactly did you see which led you to believe an Excel file was being uploaded? Was it a popup message, dialog with a prompt, were you snooping network traffic at the time... what?
Somewhere I read that Avast will upload some things if and only if the Settings->Community->Participate in the avast!community checkbox is checked. Assuming that is true (if it isn't I would greatly appreciate someone pointing that out), do you have that checkbox checked?
-
What exactly did you see which led you to believe an Excel file was being uploaded? Was it a popup message, dialog with a prompt, were you snooping network traffic at the time... what?
Open avast > Maintenance > Update > Looking the messages/info displayed there...
Somewhere I read that Avast will upload some things if and only if the Settings->Community->Participate in the avast!community checkbox is checked. Assuming that is true (if it isn't I would greatly appreciate someone pointing that out), do you have that checkbox checked?
Sure.
I have no private .exe or .dll files...
-
I have the participate option unchecked in an attempt to eliminate any possibility of private information being uploaded. I have not seen a message like you describe. I take it you mean the message was (very?) briefly displayed along with other progress messages during the update(?). Had you not been in manual update mode, I wonder what if anything you would have seen(?).
There is a Privacy policy link under that Participate in the avast! community check box. It takes me to a privacy policy page which is too vague to allow one to assess the potential behavior and potential consequences of the feature. To anyone: Is there a more detailed description of this reporting feature to be found somewhere else?
Especially in light of your having seen evidence that a frequently sensitive filetype was or may have been uploaded in part or full, I would suggest you disable the feature until such a time that you are confident that it won't [inadvertently] upload something sensitive. This isn't an Avast! specific recommendation. It goes for similar features in the OS and other software too.
Which reminds me, did you look into what is logged and did that shed any light on the details of that Excel file upload?
-
Non-participant here too.......No thanks.
-
There's no "detailed" description in the sense you mean it, because no such thing can even be defined. There are some heuristic methods in the scanning engine that may be too weak to trigger regular detections (or maybe not - but it's hard to say before the effect in the real world is seen, that's why they are there in the submitting mode) that do the submits, and even that possibly in random mode - meaning that the submit is often avoided simply to lower the load on the target servers. It is not possible to say what they will actually submit (if we knew what they're going to send, we wouldn't have to do it, right?)
So yes, sometimes a sensitive file might be submitted - but even if that happened, the information in these files is not used in any way (I mean the real content), because the important information for an AV is the "structure" of the file, abnormalities in the file format etc., certainly not the data. Most of the processing is done automatically, so most likely nobody is going to ever see the file at all - and even if somebody does, he/she is hardly going to open the file (if we're talking about documents). But sure, even though I can assure you that nobody is going to abuse your data in any way (should the unlikely even of their submit happen), it's about whether you trust the company or not.
[And yes, the same can be said e.g. about crash dumps submitted to Microsoft etc. - anything can be in the memory, including passwords, opened documents, ... but nobody is going to extract those.]
Anyway, I think it's quite likely that no Excel file has actually been submitted, the filename may have been used as a "carrier" for something else.
Tech, if you upload your setup.log on the FTP, somebody will take a look at it.
-
It is not possible to say what they will actually submit... So yes, sometimes a sensitive file might be submitted...
That in and of itself is some detail IMO, and it is also what I considered to be the appropriate assumption. Even IF the feature were hard-coded to prevent submission of data filetypes, malware could use an exe, dll, etc filetype to store the sensitive information it is attempting to steal. If it went that far it might also encrypt the data so that at least the typical user wouldn't recognize it contained their sensitive data. Ruling out that sensitive information will be uploaded would seem rather difficult to do.
... the filename may have been used as a "carrier" for something else.
I'm not sure that was meant to imply that the filename itself was uploaded, but just in case I'll remind people that filenames can contain sensitive information too. For example: "John Doe Wugga Bank Acct 49583985 Transactions.xls".
-
I'm not sure that was meant to imply that the filename itself was uploaded, but just in case I'll remind people that filenames can contain sensitive information too.
Well, it's a a bit technical and I'm not sure if I'll be able to explain in a simple way. The scanning engine can create a submission package during a file scan (when the file is suspicious in some way). But, a file might look just fine in the beginning - and the "suspiciousness" grows later when it's already running, long after the scan has taken place (e.g. according to the data supplied by the Behavior Shield); so the application performs some actions that are strange, so that we should probably take a look at the file and possibly add a real detection. But - the file has already been scanned (and wasn't submitted during that scanning) - and scanning a file is the moment ("event") when the submission can be created - it can't happen without it (I'm not saying that cannot be improved somehow, but that's the case now).
So, the engine creates a submission package during the next file scan - which can be basically a random file being scanned, completely unrelated to the suspicious event, and the submitted data have nothing to do with that particular file (its content is not sent), but rather with the suspicious one - just the filename is taken from the currently scanned (unrelated file), because that's the event where we can create the submission.
Now, I'm really not sure if I made it any clearer :)
-
That was a clearer description :) It is one thing to create a submission for a suspicious file during the scanning of an innocent file. It is another to use the name of the innocent file when you know the name of the suspicious file and could use that. That sounds like a simple "used wrong filename" bug that would be quickly fixed. Is that the case or are you leaving something out (like a two-step submission creation process where the later stage no longer has easy access to the name of the suspicious file)?
-
It's more related to the internal (inter-modular) interface which simply uses the currently scanned file for submit; while it's possible to change the size to submit (e.g. to "nothing"), and also add some "metadata" (e.g. the real suspicious data), it's not prepared to change the name, it's kinda hardcoded and would require not completely simple changes.
The mechanism will most likely be redesigned a bit sooner or later, but it's not really a top priority right now (it's also not very likely that something really important would get transferred this way).
Btw, that "knowing of the suspicious file name" is actually the key question sometimes, and not always easy/possible to answer. If a piece of code somehow appears in the memory of your browser and starts doing strange things (such as injecting code into other running processes), it might be hard to find the real cause (and if it's a result of an exploit, there may actually not be any real file associated with that).
-
Which reminds me, did you look into what is logged and did that shed any light on the details of that Excel file upload?
No, I did not find anything in the logs. But I'm absolutely sure about the file.
CRC32: 57D724C0
MD5: CD8A03A1FEEA2367030452939D545679
SHA-1: C627748F6BA3D15601BB5D518330B2FEA176BDFA
Did you receive a file like that? By the way, it's a xls and not a xlsx.
-
It's about whether you trust the company or not.
Sure. Why do you think I won't even think on disabling the participation on the Community? ;)
Tech, if you upload your setup.log on the FTP, somebody will take a look at it.
No problems. I'll do it right now.
-
Tech, if you upload your setup.log on the FTP, somebody will take a look at it.
No problems. I'll do it right now.
[/quote]
Tech.Setup.Log.File.log
-
Igor, any news?
-
No file has been submitted - it was just a "statistical" package related to the version of the installed PDF reader; that's where e.g. the data for the following talk come from:
http://www.virusbtn.com/conference/vb2011/abstracts/KubecSejtko.xml
(I gives us an overview of the used versions and makes it possible to give more priority to specific vulnerabilities to detect.)
As I was trying to explain, the submitting system has currently some limitations and needs a "file scan" event to submit something. The data here, however, have nothing to do with the particular Excel file, and its content wasn't sent - it's only the filename that you see during the submission process.
-
Ok, much better.
But, improvements on that submission process will be welcome, like not showing the file name then :)
-
@ Tech
Can you please tell me how you found out about the excel file been uploaded? I have never seen avast upload anything and i have participate in community enabled so it must submit some file but i never found out what it submitted.
-
Gautam, add the file to Chest (right click Chest, add, choose a file).
Then right click it and send it to avast team for analysis. You need to choose if it is a clean file or a false positive.
Go to the Update tab and manually invoke the virus definitions update.
The file being uploaded will be shown there.
-
Igor,
Thanks for the discussion. With respect to this reporting feature, it appears avast supports "deny all" and "allow all" options. Is there some means of configuring things to be "selective", whereby users have the opportunity to review prepared submissions and approve/disapprove them? Is there some means of configuring things so that submissions are created and logged (can be later reviewed) but not actually sent to avast?
-
Igor,
Thanks for the discussion. With respect to this reporting feature, it appears avast supports "deny all" and "allow all" options. Is there some means of configuring things to be "selective", whereby users have the opportunity to review prepared submissions and approve/disapprove them? Is there some means of configuring things so that submissions are created and logged (can be later reviewed) but not actually sent to avast?
Although I agree with this, this should be an option on demand, i.e., chosen by the users who want to tweak avast installation and not by default. It breaks completely the idea of the Community and the improvement of avast by its 175+ million users.
-
Although I agree with this, this should be an option on demand, i.e., chosen by the users who want to tweak avast installation and not by default. It breaks completely the idea of the Community and the improvement of avast by its 175+ million users.
There are three basic approaches:
1) Have the participate option enabled by default such that those who don't want to participate would have to go into settings and disable it. This would be called an opt-out approach.
2) Have the participate option disabled by default such that those who want to participate would have to go into settings and enable it. This would be called an opt-in approach.
3) Require the user to choose whether to enable or disable it (during installation). This would be called the ask approach.
Tech: Which do you advocate? Edit: Or if something else, what is that approach?
-
Opt-out.
-
Thank you for answering. The ask approach is sometimes overlooked (by some) during such discussions and I just wanted to make sure that would not happen (was not happening) here.
-
By the way, I fully trust on avast or I won't be using it since almost ten years. More than an user, a fell a coworker :)
-
Opt-out.
I agree with the opt-out concept in general. Unfortunately with avsast! every time you use the installer file it resets all your settings to default. So until that problem is fixed I vote for the ask approach the first time with the ability to change it to opt-in or opt-out options.
-
Although I agree with this, this should be an option on demand, i.e., chosen by the users who want to tweak avast installation and not by default. It breaks completely the idea of the Community and the improvement of avast by its 175+ million users.
There are three basic approaches:
1) Have the participate option enabled by default such that those who don't want to participate would have to go into settings and disable it. This would be called an opt-out approach.
2) Have the participate option disabled by default such that those who want to participate would have to go into settings and enable it. This would be called an opt-in approach.
3) Require the user to choose whether to enable or disable it (during installation). This would be called the ask approach.
Tech: Which do you advocate? Edit: Or if something else, what is that approach?
I would favor the ask approach with a clear explanation of why it would be advantageous to accept it.