Avast WEBforum

Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: Indoctor on February 24, 2012, 03:31:21 PM

Title: ARA Security Considerations
Post by: Indoctor on February 24, 2012, 03:31:21 PM
Hello Avast community. It's a while I've been using the Avast 6 version. Now it updated to version 7. Great great, until I notice that there's a new "Feature" called Remote Assistance.  >:(

The problem with this "feature" is that ANYONE who can open the avast interface can allow ANYONE to completely control the computer. It also proudly says it "bypasses firewalls" and "routes through avast servers".   :-[

Say a library has avast installed, they nicely put in admin passwords etc, but forgot AVAST PASSWORD! Then a user clicks on REMOTE ASSISTANCE code, calls his criminal friends, and BAM!! Post-exploitation fase. Or if a employee with industrial secrets with all his files encrypted has AVAST, but in all his troubles didn't password protect it, a criminal could activate REMOTE ASSISTANCE, install a bootkit/rootkit, and VOILA! :'(

Avast, a company protecting "150 000 000" users, must be VERY proud how it uses malware techniques for "convenience" of its user. ???

How many of those "150 000 000" users have a password for avast, hm? Even if they all would have a 7 word diceware phrase, this "feature" is another added complexity which can be exploited.

SO, Avast, if you actually CARE about the security of your users, and not how GOOD you LOOK for CONVENIENCE, REMOVE this "Feature" from avast. If you want, you can make it available as a separate package for users who, despite the above, want this "Feature".


THANKS!

Indoctor

EDIT: Finally, after 5 pages of senseless arguing, avast developers show some transparency.

http://forum.avast.com/index.php?topic=93989.msg749530#msg749530 (http://forum.avast.com/index.php?topic=93989.msg749530#msg749530)

Topic subject edited.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: RSD on February 24, 2012, 03:42:02 PM
I think you miss that the real problem is that someone you don't trust is using the PC physically.
There's nothing a remote user can do that couldn't be done by a local intruder.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: AdrianH on February 24, 2012, 03:46:05 PM
If you thought for 5 seconds prior to posting it just might have occurred to you that this "Remote Access" feature is a CHOICE just like all the other features available in avast!

Don't want it ? Then simply don't install it, end of problem!  ::)

Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 24, 2012, 03:50:45 PM
I did some further testing, and as it seems, the remote assist code is NOT PROTECTED.

Even LUA accounts could easily intercept it by making a screenschot. I tried it w/ paint as a limited user, and guess what ! plainly visible. So malware could easily use it for privilige escalation.

Quote
I think you miss that the real problem is that someone you don't trust is using the PC physically.
There's nothing a remote user can do that couldn't be done by a local intruder.

Oh really? So if you go 20 seconds from otherwise well locked down, strongly passworded, LUA etc. computer, a criminal can install a bootkit? Without you noticing ANYTHING? Every malware under limited accounts etc. can install bootkits you think? I think YOU miss the point here.

Quote
Don't want it ? Then simply don't install it, end of problem
Plus, I could not see the option to NOT install this "Feature". It automatically installed with my update. Read before you " ::)" Howmany of the "150 000 000" users have "auto-update" on avast?
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 03:59:26 PM
I don't see an issue here. As it is you need two people working together to do this. If a person has physical access to a machine there are more effective and efficient ways to cause a problem.

Avast will still be protecting from malicious code attempting to run on the local machine.

Like you said the avast program can be password protected.

Also a library or business should be using the Business Protection/ Business Protection Plus software for ease of management and security purposes.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: AdrianH on February 24, 2012, 04:00:56 PM
Look at the installer for avast.............. as always the feature set is selectable via a custom install.  All users can change the features they have loaded at any time.

Let's face it you haven't thought this through, you are complaining about security here and yet you tell us that you blindly allow an auto install?    You have not read the Help Files and found out that you can select which features you wish to use?  This is hardly new, avast has given you the choice in all the versions I have seen.


>>> https://support.avast.com/index.php?languageid=1&group=eng&_m=knowledgebase&_a=viewarticle&kbarticleid=1139
 

Quote
9. Besides 'Typical' and 'Minimum' installation with predefined Configuration, you can also select 'Custom' on the next screen, where it is possible to add or remove individual program components and features in a checkbox tree. Then click 'Next' to continue.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Charyb-0 on February 24, 2012, 04:03:04 PM
For years, there has been a remote assistance feature installed with every copy of Windows that I have seen. And there are many more Windows users than there are Avast users. Are you going to protest Windows too?  Just turn it off/uninstall it if you don't like it.

A bad guy would have to physically be sitting at the computer to enter the code. Why would he need a remote assistance connection if he is already physically at the computer?

I will tell you what. You use the remote assistance feature in avast! to hack into my computer. I would like to see how far you get. According to you, it's easy to do, right?
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 04:25:04 PM
Even LUA accounts could easily intercept it by making a screenschot. I tried it w/ paint as a limited user, and guess what ! plainly visible. So malware could easily use it for privilige escalation.

Where exactly is the privilege escalation?
The remotely connected user can only do the same as the local user can - the remote assistance is not running under any privileged account.

Quote
I think you miss that the real problem is that someone you don't trust is using the PC physically.
There's nothing a remote user can do that couldn't be done by a local intruder.

Oh really? So if you go 20 seconds from otherwise well locked down, strongly passworded, LUA etc. computer, a criminal can install a bootkit?

How can he install a bootkit? He's running under the very same account as the user that invoked the remote assistance - so if this powerful criminal can do that, it means that the original user can do it as well, so your machine is obviously not that strongly protected after all.
I mean, you are making overcomplicated scenarios with remote control where the same can be achieved locally (and if it can't, then it can't be achieved remotely either).
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: EmoHobo on February 24, 2012, 04:42:12 PM
At first when I saw the remote thing I panicked also, I thought for sure it could be exploited but then I figured, Avast knows what they are doing, there was probably a lot of work that went into making sure this feature was safe, it may sound naive to have this kind of blind faith, but security is kind of their thing.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Alievitan on February 24, 2012, 05:00:38 PM
hxxp://www.pcmag.com/article2/0,2817,2400609,00.asp

Don't know much about the remote security, but any word from Avast about how to prevent a similar scenario like the ongoing fiasco of Symantec pcAnywhere which is also remote tool?  Hope it is me being oversensitive, I was hoping to use it, it remote my families computers b/c they will sooner or later they will be upgraded to Avast 7. 
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 24, 2012, 05:12:15 PM
Quote
as always the feature set is selectable via a custom install.  All users can change the features they have loaded at any time.

Nonsense. Only ADMINs can change the install, all users can only install program updates (which include the full package).

Quote
you are complaining about security here and yet you tell us that you blindly allow an auto install?

Barely. I used to the "update" button in the interface, as most users I would think do. There is no "custom" install on the update.

Quote
Where exactly is the privilege escalation?
The remotely connected user can only do the same as the local user can - the remote assistance is not running under any privileged account.

We'll see how long that will remain so ... after an exploit's been found  ;)

Quote
Don't know much about the remote security, but any word from Avast about how to prevent a similar scenario like the ongoing fiasco of Symantec pcAnywhere which is also remote tool?  Hope it is me being oversensitive, I was hoping to use it, it remote my families computers b/c they will sooner or later they will be upgraded to Avast 7.

A good point.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 05:29:13 PM
hxxp://www.pcmag.com/article2/0,2817,2400609,00.asp

Don't know much about the remote security, but any word from Avast about how to prevent a similar scenario like the ongoing fiasco of Symantec pcAnywhere which is also remote tool?  Hope it is me being oversensitive, I was hoping to use it, it remote my families computers b/c they will sooner or later they will be upgraded to Avast 7.

I'm not familiar with pcAnywhere and I don't know what exact vulnerabilities there were in the Symantec code, so I'm just speculating.
If the software (when installed) is listening for network connections, and if the handling of those network connections is vulnerable (so it's possible to bypass the authentication somehow), then anybody with the knowledge of the exploit can connect to your machine and control it (unless blocked by a firewall somewhere on the way, of course).

avast! is not listening for any connections, the communication is outbound - and it starts only when you click the "Allow remote control" button. So, noone can connect to your machine without you allowing that first (before you click the big button, avast! behaves just like it did when there was no remote assistance).
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 05:37:49 PM
hxxp://www.pcmag.com/article2/0,2817,2400609,00.asp

Don't know much about the remote security, but any word from Avast about how to prevent a similar scenario like the ongoing fiasco of Symantec pcAnywhere which is also remote tool?  Hope it is me being oversensitive, I was hoping to use it, it remote my families computers b/c they will sooner or later they will be upgraded to Avast 7.

I'm not familiar with pcAnywhere and I don't know what exact vulnerabilities there were in the Symantec code, so I'm just speculating.
If the software (when installed) is listening for network connections, and if the handling of those network connections is vulnerable (so it's possible to bypass the authentication somehow), then anybody with the knowledge of the exploit can connect to your machine and control it (unless blocked by a firewall somewhere on the way, of course).

avast! is not listening for any connections, the communication is outbound - and it starts only when you click the "Allow remote control" button. So, noone can connect to your machine without you allowing that first (before you click the big button, avast! behaves just like it did when there was no remote assistance).

Symantec had a network breach and had their source code stolen. If this happened to avast I would jump ship because by that point they couldn't be trusted with security.

This system seems like any remote assistance programs available except it is integrated into the antivirus program itself. In my opinion this is a good idea.

To the op - no system is 100% secure. A system on the internet can be compromised and a system that is not connected to the internet can be compromised. Your best bet for 100% computer security is to not buy the computer in the first place. With that said you can't ensure protection of information not stored in electronic form either.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: RSD on February 24, 2012, 05:39:23 PM
I've been testing the Remote Assistance and I find it pretty safe.
There's a always on top window at the bottom right corner telling you the computer is being controlled remotely. That window can't be closed or moved.
The controlling computer can not send files to the controlled computer, and it can not use its keyboard (you can still use an on-screen keyboard).

So it can't be used as a hidden spy and it can't be used to send a virus to the controlled computer.

If you try to stop Avast shields, the warning window asking you for permission only appears in the local computer.
However, you can disable the advanced settings without any warning. That could be improved, although it can also be done by a local intruder anyway.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 06:08:10 PM
There is not a security breach and the poll is evidently biased.
The remote access has the same rights and privileges of the local user.

But I would like to have another way to exchange the password besides phone, email and chat.
I think this could be improved like it is on TeamViewer (unattended session that requires registration of the computer being controlled remotely and also can manage UAC-like messages).
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 06:11:36 PM
Quote
Where exactly is the privilege escalation?
The remotely connected user can only do the same as the local user can - the remote assistance is not running under any privileged account.

We'll see how long that will remain so ... after an exploit's been found  ;)

Exploit for what? To get out of the ordinary user's account avast! UI is running in?
You are basically saying you need an exploit in Windows - to use it via avast! to exploit Windows. OK, but since it's already there, you don't need avast!, you can use it directly.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Coolmario88 on February 24, 2012, 06:13:15 PM
Remote assistance feature is there but that doesn't mean you have to use it. ;D
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 06:19:05 PM
Symantec had a network breach and had their source code stolen. If this happened to avast I would jump ship because by that point they couldn't be trusted with security.

I believe it wasn't their network, but rather one of their partners?
I would probably argue about the idea that something like that can fully be prevented if you just try hard enough (I mean, if one of the developers packs the code and gives/sells it someone... you can only prevent it by not having any developers or no source code ;)), and I also don't think that when it comes to antivirus applications, the bad guys can learn from the source code anything new they don't already know... but I'd be getting off topic here, so I won't :)
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: AdrianH on February 24, 2012, 06:32:50 PM
The poll was posted by someone that simply has not even learned how to use Avast correctly.

If anyone feels there is a security issue or does not want to use the feature they can remove it.  It is already a "separate" download as it is a user choice within the installer.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 24, 2012, 07:09:22 PM
Nice Poll,  :-[
No mater how you vote, you're voting his way. Typical pole to prove your own point.
I personally am extremely happy this feature is available.
I no longer have to rely on a third party application to help someone who has a problem and can't fix it on their own.
Since the person needing the help has to start this feature, I don't see where there is a security breach ???
If they don't trust me, they simply don't ask for the help and don't allow access.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: MikeN92 on February 24, 2012, 07:19:43 PM
The guy who made this poll doesn't even know how to do a custom install for God's sake! I know the forum is supposed to help and inform people but this is just ridiculous.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Gargamel360 on February 24, 2012, 07:33:09 PM
Yeah, nice FUD poll.  ::)

Honestly, what doesn't compromise security?  Hiding in a box.  Unplugging the cord.

Most of us here on the forum don't need it, but I can think of plenty of people who do......sick of this general idea that remote assistance is "evil".
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 24, 2012, 07:33:34 PM
Quote
The guy who made this poll doesn't even know how to do a custom install for God's sake! I know the forum is supposed to help and inform people but this is just ridiculous.

Christ, what an offense. I'm not from a competing anti-virus firm guys!

Anyway, you're missing the point. It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Gargamel360 on February 24, 2012, 07:39:39 PM
Anyway, you're missing the point. It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!
If you are not ADMIN, its not your PC, so you have nothing to complain about.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 07:48:11 PM
Well, if you simply say that you automatically get a feature you don't want, OK. I'm not saying the thing gets changed for you, but I can see your point.
But I don't see the announced security problem here.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: AdrianH on February 24, 2012, 07:48:37 PM
Quote
The guy who made this poll doesn't even know how to do a custom install for God's sake! I know the forum is supposed to help and inform people but this is just ridiculous.

Christ, what an offense. I'm not from a competing anti-virus firm guys!

Anyway, you're missing the point. It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!

And IF the user is ona LUA and not the admin Windows doesn't allow them to install an update or new software, it requires an admins authorisation.

The admin/license holder/registered user is responsible for his/her own actions and security.  Before allowing a new version of anything on your system you need to check exactly what you are getting and what it will do.

The information on all the coming features was there for all to read and act on.  IF a user on an LUA feels they don't want the feature that worries you so much they simply need to ask the admin account holder to remove it.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Dch48 on February 24, 2012, 07:49:25 PM
If you thought for 5 seconds prior to posting it just might have occurred to you that this "Remote Access" feature is a CHOICE just like all the other features available in avast!

Don't want it ? Then simply don't install it, end of problem!  ::)
+10

I couldn't vote in your paranoid poll because none of the options apply.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 07:53:39 PM
Symantec had a network breach and had their source code stolen. If this happened to avast I would jump ship because by that point they couldn't be trusted with security.
Symantec and other security companies were compelled to release the source code to military authorities if they sell the product in India.
It was not a breach in the search code. Even less in the remote assistance technology. It's completely unrelated.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 07:55:35 PM
It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!
And so? What's wrong with that? You don't need to alter anything or change the installation. The breach just does not exist.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: BTIsaac on February 24, 2012, 07:56:08 PM
Is it just me or is that poll a little like "DurrHurr me stupid" vs "OMFG Avast is h4xx0rin' mah computerz"?

Christ, what an offense. I'm not from a competing anti-virus firm guys!

Wait a second. Who said anything about you being from a competing firm?
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 24, 2012, 07:58:17 PM
Quote
The guy who made this poll doesn't even know how to do a custom install for God's sake! I know the forum is supposed to help and inform people but this is just ridiculous.

Christ, what an offense. I'm not from a competing anti-virus firm guys!

Anyway, you're missing the point. It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!
Did you read the title of this post ??? or, did someone else writ it for you ???


Change the title of this thread to what your actual problem is and get rid of this one sided poll and we wouldn't all be an the defensive.  :)
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Arsh de Grand on February 24, 2012, 08:00:24 PM
For years, there has been a remote assistance feature installed with every copy of Windows that I have seen. And there are many more Windows users than there are Avast users. Are you going to protest Windows too?  Just turn it off/uninstall it if you don't like it.

A bad guy would have to physically be sitting at the computer to enter the code. Why would he need a remote assistance connection if he is already physically at the computer?

I will tell you what. You use the remote assistance feature in avast! to hack into my computer. I would like to see how far you get. According to you, it's easy to do, right?
100% agree with you. if anyone don't like this feature just simply switch off it !
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: RejZoR on February 24, 2012, 08:01:28 PM
Sorry but you're complaining for nothing. If you have an untrusted person behind your computer, i think you have a bigger problem than the remote assistance that so called "anyone" can activate. So i really don't understand why are you complaining about this feature.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Charyb-0 on February 24, 2012, 08:03:18 PM
It is speculation. The OP is just making accusations that he cannot prove. The subject line reads like there was an actual breach which is untrue. You can't answer the poll because each answer is leading. Another thing, your subject line reads "Unite against REMOTE AVAST SECURITY BREACH" with remote avast security breach in all caps. How misleading and untrue is this subject line? I don't care for misleading and untrue. A different approach at this may have yielded different, less hostile, responses.

Either prove it or leave it alone! Stop the speculation.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: WhiteZero on February 24, 2012, 08:07:48 PM
Love the loaded question for the poll.

Get over it man.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Gopher John on February 24, 2012, 08:25:43 PM
This poll makes a strong argument for an mandatory "Irrelevant" to be added as a vote option to any poll by the forum software. ;D
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 24, 2012, 08:29:40 PM
Quote
And IF the user is ona LUA and not the admin Windows doesn't allow them to install an update or new software, it requires an admins authorisation.

Wrong. Avast has SYSTEM priviliges so can update itself (program) under LUA.

Quote
Wait a second. Who said anything about you being from a competing firm?

This one's funny. You're suggesting I'm ADMITTING to BE from a competing firm? Hilarious. It was a METAPHOR.

http://en.wikipedia.org/wiki/Metaphor (http://en.wikipedia.org/wiki/Metaphor)
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 08:30:38 PM
Symantec had a network breach and had their source code stolen. If this happened to avast I would jump ship because by that point they couldn't be trusted with security.
Symantec and other security companies were compelled to release the source code to military authorities if they sell the product in India.
It was not a breach in the search code. Even less in the remote assistance technology. It's completely unrelated.

I stand corrected. In many instances I would say that a security system is only as strong as its weakest link, but that does not apply to this.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 08:33:57 PM
Wrong. Avast has SYSTEM priviliges so can update itself (program) under LUA.
Wrong. Your messing avastUI.exe and avastSvc.exe.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 08:35:25 PM
I stand corrected. In many instances I would say that a security system is only as strong as its weakest link, but that does not apply to this.
No, you're wrong. You've wrote: "Symantec had a network breach" and it is not a network from Symantec.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 08:44:05 PM
I stand corrected. In many instances I would say that a security system is only as strong as its weakest link, but that does not apply to this.
No, you're wrong. You've wrote: "Symantec had a network breach" and it is not a network from Symantec.

That is what I stand corrected means. I was admitting that I was wrong and that Symantec was not to blame.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: FlyingRobot on February 24, 2012, 09:01:04 PM
There are a couple of distinct issues involved here.  IIRC (I started testing 7 but aborted that effort early on), the typical and default custom installs included Remote Assistance.  Arguably, such a feature should not be bundled with an anti-malware tool let alone installed by default.  The ability to opt-out is something but arguably opt-out is insufficient.  IIRC, the appearance was that by unchecking the installation of Remote Assistance, that component would literally not be copied to an Avast directory and thus all related functionality would simply not exist on the target machine.  Theoretically speaking, that may or may not be the case because some functionality could be built into other components.  Only those intimately familiar with the code would know.  Routing Remote Assistance traffic through avast Servers is on one hand (potentially) convenient for (less sophisticated) users but doing it that way also creates additional security/privacy issues.  So yes, there does seem to be some must consider issues with respect to the Remote Assistance feature.

PS: I don't recall seeing an option to prevent the installation of avast remote management portal functionality.  It would be good if that functionality could be completely eliminated, included as is, or included in private remote management only form (where management via avast servers is impossible but management via private server is possible).
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 24, 2012, 09:02:50 PM
That is what I stand corrected means. I was admitting that I was wrong and that Symantec was not to blame.
Ok, sorry. Misunderstand you.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: BTIsaac on February 24, 2012, 09:30:51 PM
This one's funny. You're suggesting I'm ADMITTING to BE from a competing firm? Hilarious. It was a METAPHOR.

Don't link wikipedia for me pal, I know more about metaphors than whoever wrote that article and I can tell you weren't making one.

And I'm not suggesting that you're admitting anything, I'm asking who accused you of working for a competing firm. You don't have to act all defensive over a legitimate question
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 24, 2012, 09:56:16 PM
Quote
Wrong. Your messing avastUI.exe and avastSvc.exe.

I know about the two, but it is irrelevant. Your the developer guy, you should know that updating Avast program under LUA does work.

@FlyingRobot: Good argument. So removing Remote Assistance afterwards with the installer might not be a guarantee to get rid of its dangers. Great.

Quote
Don't link wikipedia for me pal, I know more about metaphors than whoever wrote that article and I can tell you weren't making one.

I was. Sorry to disappoint you. OT please.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 10:00:14 PM
That is what I stand corrected means. I was admitting that I was wrong and that Symantec was not to blame.
Ok, sorry. Misunderstand you.

No problem. I just wanted to clear things up.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: lordsoth1 on February 24, 2012, 10:32:07 PM
As stated earlier you do not have the posibility to op out when upgrading from GUI which is kinda annoying.
And having to opt out of a feature that has no relevance security wise in an antivirus seems odd to me. In my humble oppinion the feature should have been an opt in instead, especially as a lot of people who use avast probably wont ever use it. I know heaps of not so tech savvy avast users who just install and forget, they never even know its there or what its for.

Cheers
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: igor on February 24, 2012, 10:47:02 PM
Yes, and those less tech savvy people are exactly the ones that might need help some day, and this feature can be a convenient way of getting that - while trying to add it into the installation later might be a too big problem for them. The particular component is a separate module so when you uninstall it, the functionality is gone.

The online portal is something completely unrelated. As far as I know, there's no "management" functionality there at the moment - and again, you have to connect there first for anything to happen.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 24, 2012, 10:51:42 PM
Yes, and those less tech savvy people are exactly the ones that might need help some day, and this feature can be a convenient way of getting that - while trying to add it into the installation later might be a too big problem for them. The particular component is a separate module so when you uninstall it, the functionality is gone.

The online portal is something completely unrelated. As far as I know, there's no "management" functionality there at the moment - and again, you have to connect there first for anything to happen.

As a computer tech and an avast reseller I agree with this. This is an incredibly useful feature and trying to instruct someone that isn't tech savvy on how to download and install it will cause too many headaches.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: MikeN92 on February 24, 2012, 10:55:24 PM
I have used TeamViewer many times for security related problems for people that were too far or if I was just too lazy to go to their place. I think it's a great option in a security program. If you are new to security things, use it. If you don't need to use it, then don't. If you are paranoid, don't install the damn thing!
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: lordsoth1 on February 24, 2012, 11:38:55 PM
I did uninstall it just as i killed every remote services in windows. Allways do.

If your af reseller it really shouldnt be a problem to instruct customers to opt in to the feature. The opt in could even be made possible through the avast GUI auto updater. Pretty easy.
But everyones got their own opinion, i just personally dont think features like this should be standard installation in security software.

But yea im a paranoid security freak and proud of it, you're right about that   ;)

Cheers
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 24, 2012, 11:51:04 PM
Quote
Wrong. Your messing avastUI.exe and avastSvc.exe.

I know about the two, but it is irrelevant. Your the developer guy, you should know that updating Avast program under LUA does work.

@FlyingRobot: Good argument. So removing Remote Assistance afterwards with the installer might not be a guarantee to get rid of its dangers. Great.

Quote
Don't link wikipedia for me pal, I know more about metaphors than whoever wrote that article and I can tell you weren't making one.

I was. Sorry to disappoint you. OT please.


Please get off your soap box. This is one of the best additions to avast7.
I have about 20 Seniors who depend on my help whenever they have a problem.
All of them use avast! and now that they will all be able to get help remotely,
I'll even be able to help them even when I'm out of town.
They'll only get help, when they actually need it and ask for it.


If you don't like the service, don't use it and disable it.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 25, 2012, 12:00:03 AM
Quote
If you don't like the service, don't use it and disable it.

I did, but the developers haven't cleared one thing yet.

There are a couple of distinct issues involved here.  IIRC (I started testing 7 but aborted that effort early on), the typical and default custom installs included Remote Assistance.  Arguably, such a feature should not be bundled with an anti-malware tool let alone installed by default.  The ability to opt-out is something but arguably opt-out is insufficient.  IIRC, the appearance was that by unchecking the installation of Remote Assistance, that component would literally not be copied to an Avast directory and thus all related functionality would simply not exist on the target machine.  Theoretically speaking, that may or may not be the case because some functionality could be built into other components.  Only those intimately familiar with the code would know.  Routing Remote Assistance traffic through avast Servers is on one hand (potentially) convenient for (less sophisticated) users but doing it that way also creates additional security/privacy issues.  So yes, there does seem to be some must consider issues with respect to the Remote Assistance feature.

PS: I don't recall seeing an option to prevent the installation of avast remote management portal functionality.  It would be good if that functionality could be completely eliminated, included as is, or included in private remote management only form (where management via avast servers is impossible but management via private server is possible).

Also, it is somewhat depressing that anti-malware makers go hand in hand with corporations like google and facebook by standardly setting privacy-invading options. Even more depressing is that their customers, with a few exceptions, seem to actually like it.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: FlyingRobot on February 25, 2012, 12:11:08 AM
The particular component is a separate module so when you uninstall it, the functionality is gone.
Thanks for commenting on that

The online portal is something completely unrelated. As far as I know, there's no "management" functionality there at the moment - and again, you have to connect there first for anything to happen.
Do you mean connect it with your avast account?  It look(ed|s) to me that once configured avast would automatically report statistics (to avast servers), report existing configuration (to avast servers), and accept configuration changes (from avast servers).  Which would be semi or pseudo related to Remote Assistance as it is also a type of remote control feature. 

--
506172616e6f696420667265616b73206f662074686520776f726c643a20756e69746521203a29
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Paul Rodgers on February 25, 2012, 12:16:29 AM
Also, it is somewhat depressing that anti-malware makers go hand in hand with corporations like google and facebook by standardly setting privacy-invading options. Even more depressing is that their customers, with a few exceptions, seem to actually like it.

Including remote assistance capabilities != an invasion of privacy

Including the option to set up an account to manage devices != an invasion of privacy

A company that has based its advertising around word of mouth is not going to invade the privacy of their users.

For avast the product is the software where with Google and Facebook the product is your information.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Gargamel360 on February 25, 2012, 12:17:05 AM
The only suggestion that I can really agree with is it would be nice to make it an opt-in, via update, not just installer.    In this, I also keep in mind that it might not even be possible to make it opt-in through a normal update.  As long as I can choose to remove it selectively, I could care less about a RAT.  It will help innumerably more people than it will ever hurt (if any).

Also, it is somewhat depressing that anti-malware makers go hand in hand with corporations like google and facebook by standardly setting privacy-invading options.
now you are the one on an OT drift
 
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Hermite15 on February 25, 2012, 12:25:15 AM
change the title of this poll to something more neutral may be ???

... remote assistance has been available in Windows for years, both parties have to agree for it happen, I have no problem with that at all ::) ... this remains perfectly ethical ...

ps: and on a side note ...anyway more ethical from Avast if compared to some obscure Comodo feature allowing Comodo personnel only to collaborate remotely ;D
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 25, 2012, 12:56:51 AM
change the title of this poll to something more neutral may be ???

... remote assistance has been available in Windows for years, both parties have to agree for it happen, I have no problem with that at all ::) ... this remains perfectly ethical ...

ps: and on a side note ...anyway more ethical from Avast if compared to some obscure Comodo feature allowing Comodo personnel only to collaborate remotely ;D

Changeing the title of this poll to something more neutral was mentioned some pages back but (accidentally) overlooked.  :) 
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bagrat on February 25, 2012, 08:20:53 AM
I believe Remote Assistance does a lot of good! Yesterday, thanks to this option, I could save one remote PC from a crash. I couldn't use my usual TeamViewer and only Avast Remote Assistance helped me.


Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: RejZoR on February 25, 2012, 08:42:56 AM
I love the Remote Assistance idea. The last time avast! expired on my uncle's PC i had to help him re-register it through phone. Now he'll just tell me the code, i'll connect to his system and do the magic on my own. I'll be done in 1 minute instead of explaining through phone for 10 minutes.
Not that it's so complicated, it's just that such stuff is difficult for non tech savy users.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 25, 2012, 01:08:45 PM
An "unkown" force has deleted my poll. Well, you can't expect "evangelists" to respect criticism from their users.

Let's bring up another issue. Is the connection encrypted? Can Avast see the traffic in clear text? Would the remote assistance be safe from intercepting?

You needn't answer, as the answer is likely: No - Yes - No

Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 25, 2012, 01:14:52 PM
An "unkown" force has deleted my poll. Well, you can't expect "evangelists" to respect criticism from their users.

Let's bring up another issue. Is the connection encrypted? Can Avast see the traffic in clear text? Would the remote assistance be safe from intercepting?

You needn't answer, as the answer is likely: No - Yes - No
Amazing, first you post a question with a headline unrelated to your actual question.
Now, you answer your own questions in fear of not getting the answers you'd like to hear.  ;D


We are waiting for you to change the title of this thread.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 25, 2012, 01:17:55 PM
Including remote assistance capabilities != an invasion of privacy
For sure not. If you do not trust avast! company and its seriousness about security and privacy, maybe it would be better think in another antivirus...

Including the option to set up an account to manage devices != an invasion of privacy
Absolutely not. It's a service that would help users with more than one installation, business, mobile users (that could use Anti-Theft options by internet and not only by SMS).
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 25, 2012, 01:19:56 PM
I couldn't use my usual TeamViewer
Why not?
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Lisandro on February 25, 2012, 01:26:42 PM
Is the connection encrypted?
Yes.

Can Avast see the traffic in clear text?
No. It depends on the assistance ticket both parts exchanged.

Would the remote assistance be safe from intercepting?
Yes. Like any other break on the HTTPS connection.

Indoctor, you're making FUD.
You're making wrong assumptions.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 25, 2012, 01:32:29 PM
Quote
Amazing, first you post a question with a headline unrelated to your actual question.
Now, you answer your own questions in fear of not getting the answers you'd like to hear.  ;D

This just keeps getting better and better.

Quote
We are waiting for you to change the title of this thread.

What would YOU suggest? Make my day.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: AntiVirusASeT on February 25, 2012, 01:44:57 PM
An "unkown" force has deleted my poll. Well, you can't expect "evangelists" to respect criticism from their users.

Let's bring up another issue. Is the connection encrypted? Can Avast see the traffic in clear text? Would the remote assistance be safe from intercepting?

You needn't answer, as the answer is likely: No - Yes - No

Well i am one of those who reported about ur 'poll'
I shall be direct. it is spreading misinformation to the less technical ppl, creating unnecessary alarm.
if u do not like Avast!, please use another antivirus as u wish  ::)
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: akama1 on February 25, 2012, 01:51:09 PM
dude remote assistance in avast... the code can only be used on one computer and not several.. furthermore you must have permission to allow remote access... and if you dont like the remote assistance feature.... just exclude it from install :) or dont use it
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: bob3160 on February 25, 2012, 02:09:37 PM
Quote
Amazing, first you post a question with a headline unrelated to your actual question.
Now, you answer your own questions in fear of not getting the answers you'd like to hear.  ;D

This just keeps getting better and better.

Quote
We are waiting for you to change the title of this thread.

What would YOU suggest? Make my day.


Your own words:
"Anyway, you're missing the point. It's not about the INSTALL, it's about when doing the update WITH THE AVAST UI, it installs the full package. There's NO WAY AFTERWARDS to alter it except if you're ADMIN, and NOT ALL users administer their computers themselves/have access to that account!!!"
So the title should reflect your complaint about not being able to do a selective install when using the UI update feature.
And the so called poll that's listed is total garbage and totally unrelated with out any real choices.
Hope that makes it clear.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: RejZoR on February 25, 2012, 02:21:12 PM
Remote Assistance in avast! is a P2P (Peer to peer) feature. The authentication code is only used to make the handshake. After that, encrypted connection is established directly between two computers. avast! servers will allow activation of 1 code just once. After it has been connected, no one can reuse it again (at least not in the very close future). And when it possible might be reused, both clients will be very different so it doesn't matter anymore.

As for the poll removal, who cares? It was stupid anyway. If avast! team wanted to cover up anything, this thread would be gone altogether. But it's still here. There is no conspiracy behind this feature. It's very fool proof, secure and useful.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Zdenek on February 25, 2012, 02:57:11 PM
Hallo All!

I'm a developer responsible for the Avast Remote Assistance (ARA) component, then I'll try to reply some of your questions about the ARA security.

The security of the ARA component has been one of the major requirements during the component development process.

We are using strong cryptography methods (SSL to establish a session and verify the ARA server identity and AES 256 to protect the Remote desktop data transfers) to keep users secure.

At first, when the request for the ARA session is created, the Avast! workstation initiate the SSL connection to the ARA server and verify the server certificate, if it belongs to the ARA subsystem. It protect users against fake servers, which can be used by attacker to hijack the  ARA session (Man in the Middle).

Server generates the ARA ticket, which is delivered by the SSL connection to the user (Assistance Requester).The SSL connection keeps alive during this time.

Now, the ticket is delivered to the Assistance Requester and ARA server is waiting for second connection from Assistance Provider.

The Assistance Requester have to deliver the Assistance ticket to other side (Assistance Provider) to allow second user to connect to his computer and establish full remote assistance session.

Here is on user responsibility to deliver the ticket securely to other side. Avast! cannot take any responsibility if the ticket will be stolen  during the transfer. We recommend to use cellular phone, or encrypted e-mail (PGP for example) or SKYPE message or call (Skype is using strong encryption to protect session communication) to do this. Use ICQ or normal e-mail message for example is not recommended, because any e-mail can be sniffed by attacker on any part of the e-mail path.


The ARA component is as secure as secure is the Assistance ticket! Choose the communication channel which you really TRUST!

When the ticket is delivered to the Assistance Provider, then he uses the ticket to establish the full ARA session. Mechanism is same -> use SSL connection to verify the ARA server and protect the communication, then send the ticket by this secure connection to the ARA server

When ticket is verified and both SSL connections from both user are paired on the server, then both sides goes to establish new data connections which carry the Remote desktop data. These data are shifted from one connection to other by the ARA server, but in encrypted (AES 256)form. The encryption keys are randomly generated and delivered to both sides of connection by established SSL connections, and then is granted that those keys cannot be stolen by a third party.

Due this, the Remote desktop data can be only decrypted by Assistance Requestor / Provider workstations and by ARA server proxy, but no one else.

I have to notice that encryption keys are visible for ARA server, because it works as proxy between both sides of the ARA session. Avast! will never decrypt any kind of communication belongs to any ARA session!

As somebody mentioned here, if you do not trust to AVAST!, do not use this piece of software.

If a data connection will be "stolen" or redirected by an atacker, then is not possible to use this connection for access to the Requester workstation, because the connection will deliver only binary noise to attacker -> the encryption keys are never transmitted in unencrypted form.

Additionally, the Remote Desktop server on the Assistance Requester side is started only when the Provider will initiate the session, and it  listen only on localhost interface and on random port , then is not possible to connect on this server from outside.

All ARA connections are initiated from AVAST! workstations, then security of those connections is same as for example your web browser SSL secured connections or SSH sessions to your servers...

ARA doesn't use any server listening on Avast! workstations. It is provided on ARA servers, which are hardened and monitored by AVAST! IT profesionals.

I believe that this post help to understand the ARA principles of work and explain how the ARA security is implemented.

Of course, if you have any additional questions, let us to know, ad we will try to answer it ASAP.

Zdenek
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Indoctor on February 25, 2012, 03:04:51 PM
Well FINALLY. Couldn't you be this transparent from the beginning? Provide this information together with the new feature? Would have saved a lot of trouble.

Remaining questions:

Quote
Do you mean connect it with your avast account?  It look(ed|s) to me that once configured avast would automatically report statistics (to avast servers), report existing configuration (to avast servers), and accept configuration changes (from avast servers).  Which would be semi or pseudo related to Remote Assistance as it is also a type of remote control feature.
Title: Re: ARA Security Considerations
Post by: Zdenek on February 25, 2012, 03:20:51 PM
ARA is not using AVAST! account. Connections are anonymous, the ticket is generated randomly (to prevent possibility to guess the ticket value by attacker).

ARA doesn't collect any data about user.
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 03:35:31 PM
"Well FINALLY. "
Are you now ready to change the title of this thread ???  :)
Title: Re: ARA Security Considerations
Post by: Gopher John on February 25, 2012, 03:36:35 PM
@Zdenek

Thank you very much for the concise information.  It should dispel the paranoia surrounding this feature. 8)

Will the requester be able to copy/paste the Assistance ticket from the interface to enter into an encrypted message?  Will it be reasonably small enough that it may be quoted verbally over a phone to the remote assistant?

I do wonder why anyone would run a security program that they don't trust. :o
Title: Re: ARA Security Considerations
Post by: Indoctor on February 25, 2012, 03:37:37 PM
It is already changed. I'm not unreasonable.

BTW, I never said I don't trust AVAST, I only said I have doubts w/ Remote Assistance. Although I may have given another impression sometimes, I'll admit that.
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 03:40:43 PM
It is already changed. I'm not unreasonable.

BTW, I never said I don't trust AVAST, I only said I have doubts w/ Remote Assistance.


Hopefully those doubts have now been laid to rest.  :)
Title: Re: ARA Security Considerations
Post by: Zdenek on February 25, 2012, 03:47:29 PM
I think that copy/paste feature is not problem to implement in the future...

Best regards

Zdenek
Title: Re: ARA Security Considerations
Post by: Indoctor on February 25, 2012, 03:49:12 PM
Quote
Hopefully those doubts have now been laid to rest.

Mostly. Although I still insist developers don't wait on that doubt to show this willingness for transparency. And make new features opt-in by default, and not opt-out, even with the avast updater.

Kind Regards,

Indoctor
Title: Re: ARA Security Considerations
Post by: Gopher John on February 25, 2012, 04:20:03 PM
I think that copy/paste feature is not problem to implement in the future...

Best regards

Zdenek

Thanks for your reply.  I'd like that ability.

To add to my other question, will the Assistance ticket not be so long and/or complicated so as not to confuse the elderly when trying to exchange it verbally over a voice connection?  I can just imagine trying to transfer that information to some of the people I know (maybe even me :-[ ;)) if it is too much.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Asyn on February 25, 2012, 04:26:28 PM
I believe that this post help to understand the ARA principles of work and explain how the ARA security is implemented.

Thanks Zdenek..! :)
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: FlyingRobot on February 25, 2012, 05:00:00 PM
When ticket is verified and both SSL connections from both user are paired on the server, then both sides goes to establish new data connections which carry the Remote desktop data. These data are shifted from one connection to other by the ARA server, but in encrypted (AES 256)form. The encryption keys are randomly generated and delivered to both sides of connection by established SSL connections, and then is granted that those keys cannot be stolen by a third party.

This makes it sound as though the Assistance Requester and Assistance Provider establish SSL connections with the avast server (over which could be transmitted the remote desktop data), but instead secondary connections to the same or another avast server are brought up to relay the remote desktop data.  Why?  Is this, for example, to lighten the load on the server by eliminating SSL on the secondary connections which utilize the AES256 encryption?

Due this, the Remote desktop data can be only decrypted by Assistance Requestor / Provider workstations, but no one else.

I have to notice that encryption keys are visible for ARA server, because it works as proxy between both sides of the ARA session. Avast! will never decrypt any kind of communication belongs to any ARA session!

If I followed your description correctly (forgive me if I did not), the above two comments seem contradictory.  If encrypted remote desktop data is relayed through an avast server and the avast server generated or otherwise has the keys, it would seem that the avast server could decrypt the remote desktop traffic.  I don't understand why that approach would be used.  The requester must establish a direct and hopefully very private communications channel with the provider in order to pass ticket information.  Lets say the requester calls the provider.  That phone call provides an opportunity for the requester to give the provider a pass phrase that could be used to derive or modify the keys privately on requester and provider sides (thus preventing the avast server from knowing them and being able to decrypt the traffic).   
Title: Re: ARA Security Considerations
Post by: Lisandro on February 25, 2012, 05:24:55 PM
And make new features opt-in by default, and not opt-out, even with the avast updater.
No. I defend the opt-in policy if I could vote. 200 million users, the majority just the default installation, when we need, it won't be there. avast! should keep userfriendly and let it there. There is no security or lack of transparency for common users imho.
Title: Re: ARA Security Considerations
Post by: Hermite15 on February 25, 2012, 05:34:14 PM
agreed ... there's already enough freedom with the custom options ...  having that said your PC won't be connecting remotely anytime soon without your consent... so opt-in for the feature in that case is useless.

 Another thing, I haven't tried the remote feature yet so I can't tell for sure, but forbidding "remote desktop" connections at Windows level (in system properties) should prevent ARA from operating at all ... right?
 
Title: Re: ARA Security Considerations
Post by: UserA789 on February 25, 2012, 05:47:45 PM
Hello Avast community. It's a while I've been using the Avast 6 version. Now it updated to version 7. Great great, until I notice that there's a new "Feature" called Remote Assistance.  >:(

The problem with this "feature" is that ANYONE who can open the avast interface can allow ANYONE to completely control the computer. It also proudly says it "bypasses firewalls" and "routes through avast servers".   :-[

Say a library has avast installed, they nicely put in admin passwords etc, but forgot AVAST PASSWORD! Then a user clicks on REMOTE ASSISTANCE code, calls his criminal friends, and BAM!! Post-exploitation fase. Or if a employee with industrial secrets with all his files encrypted has AVAST, but in all his troubles didn't password protect it, a criminal could activate REMOTE ASSISTANCE, install a bootkit/rootkit, and VOILA! :'(

Avast, a company protecting "150 000 000" users, must be VERY proud how it uses malware techniques for "convenience" of its user. ???

How many of those "150 000 000" users have a password for avast, hm? Even if they all would have a 7 word diceware phrase, this "feature" is another added complexity which can be exploited.

SO, Avast, if you actually CARE about the security of your users, and not how GOOD you LOOK for CONVENIENCE, REMOVE this "Feature" from avast. If you want, you can make it available as a separate package for users who, despite the above, want this "Feature".


THANKS!

Indoctor

EDIT: Finally, after 5 pages of senseless arguing, avast developers show some transparency.

http://forum.avast.com/index.php?topic=93989.msg749530#msg749530 (http://forum.avast.com/index.php?topic=93989.msg749530#msg749530)

Topic subject edited.

I understand your concerns over this.  I, myself, was quite leary of it until I read the HELP topic provided in the on screen manual.  My biggest concerns, however, are not with the Avast Remote Tool.  I trust Avast as much as any other AV vendor but choose them due to all the others seem to make a PC run slower and slower every time it re-boots.  Avast seems to have dealt with what ever causes this in other AV resident scanners.

My concern, although right now there isnt much other choise as of yet, is illicit users being able to fake the initial SSL cert.  Last year, a group using a PS3 linux cluster broke the SSL cert process wide open and have used it to 'HiJak' everything from email login pages to Google.  It would be nice to see my favorite security solution provider come up with a better, more secure method to this.  Another thing Im curious about, although Im sure the Alwil team stays up on this; would be the following article from the FBI concerning DNS hijacking:

http://www.fbi.gov/news/stories/2011/november/malware_110911 (http://www.fbi.gov/news/stories/2011/november/malware_110911)

This exploit is strraight outta James Bond scenarios and most dev's thought there was no way to do something like this.  Proof that we as developers dont always 'kno-it-all'.
Title: Re: ARA Security Considerations
Post by: Lisandro on February 25, 2012, 05:48:08 PM
But forbidding "remote desktop" connections at Windows level (in system properties) should prevent ARA from operating at all ... right?
Not so sure it works also for P2P (like avast ARA).
Title: Re: ARA Security Considerations
Post by: Hermite15 on February 25, 2012, 06:01:02 PM
But forbidding "remote desktop" connections at Windows level (in system properties) should prevent ARA from operating at all ... right?
Not so sure it works also for P2P (like avast ARA).

thought Windows native remote desktop was p2p too  ;D >>> it is.
Title: Re: ARA Security Considerations
Post by: Lisandro on February 25, 2012, 06:06:26 PM
Thought Windows native remote desktop was p2p too  ;D >>> it is.
Really? Living and learning...
What about TeamViewer? Which technology does it use?
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 06:13:04 PM
" This exploit is strraight outta James Bond scenarios and most dev's thought there was no way to do something like this.  Proof that we as developers dont always 'kno-it-all'."

By now, we should all know that for every security measure that's implemented, there are 100's of hackers busy at work finding a way to break the protection.


There is no solid guarantee that today's most secure product will not turn into tomorrows least secure application.
It's a fact of the times.
Title: Re: ARA Security Considerations
Post by: FlyingRobot on February 25, 2012, 07:03:43 PM
I think the Microsoft/Windows parallel to Avast Remote Assistance would be Windows Remote Assistance (not Remote Desktop per se).  Avast Remote Assistance appears (to me at at this point at least) to require the use of a central server/service for both a) rendezvous/setup and b) relaying the remote assistance/desktop session data itself.  IIRC, the Windows Remote Assistance does not require a or b.  IIRC, the rondezvous/setup can be achieved through purely private channels and the remote assistance/desktop session data itself can be communicated directly between the requester and the provider machines.  There is the newer Easy Connect *option* though, which I haven't investigated.  I think the latter utilizes peer-to-peer name resolution and routing to facility rendezvous/setup.  I'm not sure if, when using Easy Connect, the remote assistance/desktop session data itself is passed directly between the requester and provider machines though.  TLDR: I don't think Avast Remote Assistance and Windows Remote Assistance fall into the same categories. 
Title: Re: ARA Security Considerations
Post by: Hermite15 on February 25, 2012, 07:14:34 PM
I think the Microsoft/Windows parallel to Avast Remote Assistance would be Windows Remote Assistance (not Remote Desktop per se).

true ;) ... I made a mistake, hesitated a second about that before posting, god knows why I thought a second that remote assistance was MS related and it's not, it's p2p help between computer users.
Title: Re: ARA Security Considerations
Post by: UserA789 on February 25, 2012, 07:22:54 PM
" This exploit is strraight outta James Bond scenarios and most dev's thought there was no way to do something like this.  Proof that we as developers dont always 'kno-it-all'."

By now, we should all know that for every security measure that's implemented, there are 100's of hackers busy at work finding a way to break the protection.


There is no solid guarantee that today's most secure product will not turn into tomorrows least secure application.
It's a fact of the times.
My main point with the statement goes along with what you've said, unfortunately more developers are to hard headed to hear anything than what they believe.  I'm more old school than that.  If I have a script, or piece of code, I develop, I do my best to stay open to every possibility of its uses and/or mis-uses.  Although there is a rule, more like guidelines (to steal a quote from a favorite Disney flick).

Kinda like how most dev's will swear by *nux builds but last year there were more serious exploits of *nux based systems (Sony, the US federal government minus the USMC -they use their own CLOSED/PRIVATE SOURCE code, etc) than Windows servers.  to that, we can attribute the fact that criminal organizations are NOT as stupid as we tend to believe and with how much of our lives exist in our machines, why wouldn't they be involved in all sorts of 'open-source' projects to insure their own criminal survivability?  We would be more stupid than we attribute them to be if we thought anything else.  I used to be a dedicated open-source user.  From FF to Filezilla to Linux itself.  The past year, Iv had my *nux builds crash more than my windows, or show stray transmission(s).

Either way, this went a bit off topic and for that I apologies, but at the same time remains on topic to suggest when users like InDoctor bring things like this to attention, we should explore EVERY possibility of it being true instead of the only possibilities of it not being true.  And if it does run on a P2P basis, this is a mistake. P2P is very easily interceptible (even with SSL; as reason described above) for MiM attacks.  We must believe that illicit users are already reverse engineering Avast, as its one of the best... if not the best.  end of story.
Title: Re: ARA Security Considerations
Post by: Dch48 on February 25, 2012, 08:54:30 PM
I just have one question and it's about this part of Zdenek's explanation.
Quote
Here is on user responsibility to deliver the ticket securely to other side. Avast! cannot take any responsibility if the ticket will be stolen  during the transfer. We recommend to use cellular phone, or encrypted e-mail (PGP for example) or SKYPE message or call (Skype is using strong encryption to protect session communication) to do this.
What if you're like me and you don't have any of those options? I do not and have never had a cell phone, and I have never used Skype. I also have no idea what PGP for email is.
Title: Re: ARA Security Considerations
Post by: Asyn on February 25, 2012, 08:57:15 PM
What if you're like me and you don't have any of those options? I do not and have never had a cell phone, and I have never used Skype.

You can use any phone, not just a cell phone..!! ;)
Guess you have one at home, don't you..?
Title: Re: ARA Security Considerations
Post by: Dch48 on February 25, 2012, 09:02:14 PM
What if you're like me and you don't have any of those options? I do not and have never had a cell phone, and I have never used Skype.

You can use any phone, not just a cell phone..!! ;)
Guess you have one at home, don't you..?
Okay, well he didn't say that. Of course I have a phone but I only use it less than once a week. I hate talking on the phone. Oh and just to stave off the inevitable comments, no, the phone does not have a dial or a crank but it does have those little buttons that make a sound when you push them.  :P
Title: Re: ARA Security Considerations
Post by: Asyn on February 25, 2012, 09:04:27 PM
Oh and just to stave off the inevitable comments, no, the phone does not have a dial or a crank but it does have those little buttons that make a sound when you push them.  :P

Great. ;D
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 09:24:29 PM
What if you're like me and you don't have any of those options? I do not and have never had a cell phone, and I have never used Skype.

You can use any phone, not just a cell phone..!! ;)
Guess you have one at home, don't you..?
Okay, well he didn't say that. Of course I have a phone but I only use it less than once a week. I hate talking on the phone. Oh and just to stave off the inevitable comments, no, the phone does not have a dial or a crank but it does have those little buttons that make a sound when you push them.  :P
(http://bloggingblue.com/wp-content/uploads/2012/01/Ostrich-man-head-in-sand-300x201.gif)
Remove the option you don't need it. ;D
Title: Re: ARA Security Considerations
Post by: FlyingRobot on February 25, 2012, 09:31:15 PM
On a somewhat related note, if the design is such that everything that is necessary to establish a remote assistance session is in the ticket, then secure transmission of that ticket information to the provider becomes a critical issue.  As I touched upon in an earlier post today, there would seem to be a perfectly viable option to utilize a separate, privately communicated only piece of information such as a pass phrase.  It has been ages since I've helped someone via Windows Remote Assistance (everyone I now help is very local), but IIRC I either used a pre-shared passphrase (exchanged before hand, can be very strong) or created one on the spot by referencing something we both knew without actually saying it (example: make the pass phrase the name of your first dog, assuming said name was significantly obscure and unique of course).  I think by exploiting such tactics the ticket/setup info exchange via private communications channel can become a less critical issue.
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 09:40:47 PM
IMHO,
None of this is a critical issue it's just being turned into one.
Title: Re: ARA Security Considerations
Post by: Dch48 on February 25, 2012, 09:47:21 PM
What if you're like me and you don't have any of those options? I do not and have never had a cell phone, and I have never used Skype.

You can use any phone, not just a cell phone..!! ;)
Guess you have one at home, don't you..?
Okay, well he didn't say that. Of course I have a phone but I only use it less than once a week. I hate talking on the phone. Oh and just to stave off the inevitable comments, no, the phone does not have a dial or a crank but it does have those little buttons that make a sound when you push them.  :P
(http://bloggingblue.com/wp-content/uploads/2012/01/Ostrich-man-head-in-sand-300x201.gif)
Remove the option you don't need it. ;D
I'm not removing it but I'm 99.9999999% sure that it will never be used.  :D
Title: Re: ARA Security Considerations
Post by: Asyn on February 25, 2012, 09:47:33 PM
IMHO,
None of this is a critical issue it's just being turned into one.

Big +1
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: FlyingRobot on February 25, 2012, 10:26:14 PM
Presumably some can comprehend this part:

Here is on user responsibility to deliver the ticket securely to other side. Avast! cannot take any responsibility if the ticket will be stolen  during the transfer. We recommend to use cellular phone, or encrypted e-mail (PGP for example) or SKYPE message or call (Skype is using strong encryption to protect session communication) to do this. Use ICQ or normal e-mail message for example is not recommended, because any e-mail can be sniffed by attacker on any part of the e-mail path.

The ARA component is as secure as secure is the Assistance ticket! Choose the communication channel which you really TRUST!

Take issue with the word "critical" if you like, but please do not dismiss something that is clearly technically important and worthy of discussion. 
Title: Re: ARA Security Considerations
Post by: bob3160 on February 25, 2012, 10:57:45 PM
Sorry if this sound rude but to me this whole discussing has been unimportant.
The only good part was the explanation of exactly how this works.  :)
Title: Re: ARA Security Considerations
Post by: itsjustme2 on February 25, 2012, 11:01:50 PM
for the guy who created this thread:
ffffffffffirst of all, before you start throwing words in the air.. remote assistance won't put the computer in any risk, as long as you're not retarded, and if you're, then avast isn't for you.
furthermore, you have the opportunity to choose not to install it, by selecting "custom" at the start of the installation.

how the hell did this thread gained 7 pages?! holy mother of avast.
Title: Re: ARA Security Considerations
Post by: Indoctor on February 26, 2012, 12:40:17 AM
Sorry if this sound rude but to me this whole discussing has been unimportant.
The only good part was the explanation of exactly how this works.  :)

What's really "rude" is that you and your friends abuse this thread for your entertainment, trying to ridicule it in a ridicule manner.

FlyingRobot and UserA789 make some important critiques which are worth answering. I suggest we wait for the expert, being Zdenek, to speak out. He said he would be available for questions so let him, and don't fill the thread with junk.
Title: Re: ARA Security Considerations
Post by: UserA789 on February 26, 2012, 06:49:19 PM
Sorry if this sound rude but to me this whole discussing has been unimportant.
The only good part was the explanation of exactly how this works.  :)
I partially disagree with you, if he didnt bring his concerns we wouldnt have the explanation you state you find as 'good'.  If a user has a valid concern, we ned to separate ourselves and calmly discuss the factors behind it.  We also need to explore their concerns as if we knew nothing about the subject ??? .  The biggest problem Iv faced in getting support (I also provide support so I try to remeber this myself) is the tech we end up dealing with dont have either the capacity or the knowledge to realise they dont understand everything.

Also, just because something is irratating to us DOES NOT mean it has no validity.  There are TONS of exploits using 'remote connection' protocols.  I, myself, am concerned if Avast is using P2P netowrking to provide this feature :-X .  However, to announce this brings GREAT resistance from those still trusting file share(s).  As well, SSL ceretifacte use brings little comfort and here is why:

http://www.zdnet.com/blog/security/ssl-broken-hackers-create-rogue-ca-certificate-using-md5-collisions/2339 (http://www.zdnet.com/blog/security/ssl-broken-hackers-create-rogue-ca-certificate-using-md5-collisions/2339)
http://betanews.com/2011/08/30/google-microsoft-block-diginotar-for-fake-ssl-cert-company-halts-all-certification-sales/ (http://betanews.com/2011/08/30/google-microsoft-block-diginotar-for-fake-ssl-cert-company-halts-all-certification-sales/)
http://www.eweek.com/c/a/Security/Fake-Google-SSL-Certificate-Emerges-With-Ability-to-Hijack-User-Accounts-270126/ (http://www.eweek.com/c/a/Security/Fake-Google-SSL-Certificate-Emerges-With-Ability-to-Hijack-User-Accounts-270126/)
http://thenextweb.com/microsoft/2011/03/23/9-fake-ssl-certificates-loose-in-the-wild-microsoft-claims/ (http://thenextweb.com/microsoft/2011/03/23/9-fake-ssl-certificates-loose-in-the-wild-microsoft-claims/)

And then there is Comod's owners remarks on the subject as well:
http://www.melih.com/2011/03/23/ (http://www.melih.com/2011/03/23/)

I suppose these hackers figured it out by going with the status quo, that it couldnt be done, eh ??? ?

Unforunatly, right now, SSL is the only thing we got.  I will state again it would be awesome to see Alwil develop a better, more secure standard, but that will never happen if things just like what the OP has brought to bear (regardless of our own thoughts on its security), simply end up riduculed and ruled out because 'we' think its impossible.  I know tech's that think the SSL fake is just rumor creted by the 'Great Media Mill' to cause paranoia... all due to thier own arrogance :'( .

It was stated in this post that there are always some group/individual trying to hack the current standards.  This is just a part of life.  But to ignore such knowledge simply because 'we' dont think it can happen is plain iggnorance.  I would hate to see my favorite company... ARGGGHHH!!!   :-* ... become the example of why 'we' need to calmly address factors like this.

All Im trying to point out is NO TOPIC should be thought of as useless.  I, myself, tried to point out to my OWN ISP that DNS hijacking; www.fbi.gov/DNS-malware.pdf (http://www.fbi.gov/DNS-malware.pdf) , was beginning or already occuring, along with the Playstaion Network and a few other vendors I trust in my network.  They laughed (not out-loud) and served me with patronizing statements  ::) .

 8) Now, they pay a bit more attention to the conrcerns I point their way.  8)

Either way, I would like to thank the OP for this subject, as it has shed light on whether I want to use this feature or not.  I have to provide assistance to a few folk that I have recommended Avast to (goin on 6-7 years now).  As well as my 60+ year old mother who cant stop from opening emails from unknown solicitors.  Im still curious as to whether this is P2P remote assistance, or Avasts own design (praying they took the time do make their own :-X )?

Anyhow, this may help others understand why sometimes the GREATEST change can be made by those that think differently because they arent pinned down by pre-existing thoughts on the matter (such as myself and my feelings about P2P).

Thank you InDoctor for helping this process be explained in depth.  Now I just worry about a hacker reading the remarks and figuring out how to fake the SSL cert(s) involved here.  Thats not your fault though so really, THANK YOU ;) .
Title: Re: ARA Security Considerations
Post by: bob3160 on February 26, 2012, 07:05:55 PM
Quote
Either way, I would like to thank the OP for this subject, as it has shed light on whether I want to use this feature or not.
You seem to have missed one very important point. Initiation of this feature always comes from the person seeking help.
You or I as the person probably in the helper position don't control anything unless we are invited.
Title: Re: ARA Security Considerations
Post by: FlyingRobot on February 26, 2012, 07:40:44 PM
Im still curious as to whether this is P2P remote assistance, or Avasts own design (praying they took the time do make their own :-X )?

Remember, the term peer-to-peer is somewhat blurry and there are different definitions/degrees.  For example:

1) AssistanceRequesterMachine<->AssistanceProviderMachine

Here, the two machines communicate directly with each other.  This is, arguably, the purest form of peer-to-peer

2) AssistanceRequesterMachine<- Peer2PeerNetwork ->AssistanceProviderMachine

Here, the two machines communicate through a Peer2Peer network.  Nearly everyone would call this peer-to-peer.

3) AssistanceRequesterMachine<- Central Server|Cloud ->AssistanceProviderMachine

Here, the two machines communicate through a central server/service.  Some would even call this peer-to-peer if the central server or service is basically just relaying/routing the traffic.

Based on Zdenek's posts, I think Avast Remote Assistance is #3.  What do you think and/or what leaves you unsure?
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Zdenek on February 27, 2012, 10:52:49 AM
When ticket is verified and both SSL connections from both user are paired on the server, then both sides goes to establish new data connections which carry the Remote desktop data. These data are shifted from one connection to other by the ARA server, but in encrypted (AES 256)form. The encryption keys are randomly generated and delivered to both sides of connection by established SSL connections, and then is granted that those keys cannot be stolen by a third party.


This makes it sound as though the Assistance Requester and Assistance Provider establish SSL connections with the avast server (over which could be transmitted the remote desktop data), but instead secondary connections to the same or another avast server are brought up to relay the remote desktop data.  Why?  Is this, for example, to lighten the load on the server by eliminating SSL on the secondary connections which utilize the AES256 encryption?

Yes, it is to lighten the load on the server.



Due this, the Remote desktop data can be only decrypted by Assistance Requestor / Provider workstations, but no one else.

I have to notice that encryption keys are visible for ARA server, because it works as proxy between both sides of the ARA session. Avast! will never decrypt any kind of communication belongs to any ARA session!

If I followed your description correctly (forgive me if I did not), the above two comments seem contradictory.  If encrypted remote desktop data is relayed through an avast server and the avast server generated or otherwise has the keys, it would seem that the avast server could decrypt the remote desktop traffic.  I don't understand why that approach would be used.  The requester must establish a direct and hopefully very private communications channel with the provider in order to pass ticket information.  Lets say the requester calls the provider.  That phone call provides an opportunity for the requester to give the provider a pass phrase that could be used to derive or modify the keys privately on requester and provider sides (thus preventing the avast server from knowing them and being able to decrypt the traffic).

I have modified the original topic to be more acurate. I tried to explain that we protect Provider/Requester traffic against evil third parties, but from ARA principles of work, ARA has access to encryption keys. But ARA do not use this to decrypt communication between Provider/Requester

The main reason why we are using ARA server as proxy is that many users haven't public IP addresses, or are not able to configure own routers and other infrastructure to allow listening on TCP protocol. ARA solves this problem because users are connected through ARA server, then is not necessary to have listening socket on user workstation and both workstations can be behind the NAT.

As I mentioned before -> If you do not trust to AVAST! infrastructure, do not use this. Any Antivirus software operates with Administrative and SYSTEM privilege on your workstation, then can do anything with your computer. If you do not trust to this piece of software, why you are using it ? 
Title: Re: ARA Security Considerations
Post by: Zdenek on February 27, 2012, 10:59:23 AM
But forbidding "remote desktop" connections at Windows level (in system properties) should prevent ARA from operating at all ... right?
Not so sure it works also for P2P (like avast ARA).

It is not true. ARA uses own Remote Desktop technology( because in some Windows editions RDP technology is not included), then is not handled by this OS setting.

But, because ARA uses connections established FROM your workstations, then is not possible to establish Remote Desktop session without your active request on ARA server by "click" on appropriate button in the AVAST! UI (and establish the connection).

Remote desktop server is never  in listening mode from your public network interface(s).
Title: Re: ARA Security Considerations
Post by: Zdenek on February 27, 2012, 11:08:01 AM
Im still curious as to whether this is P2P remote assistance, or Avasts own design (praying they took the time do make their own :-X )?

Remember, the term peer-to-peer is somewhat blurry and there are different definitions/degrees.  For example:

1) AssistanceRequesterMachine<->AssistanceProviderMachine

Here, the two machines communicate directly with each other.  This is, arguably, the purest form of peer-to-peer

2) AssistanceRequesterMachine<- Peer2PeerNetwork ->AssistanceProviderMachine

Here, the two machines communicate through a Peer2Peer network.  Nearly everyone would call this peer-to-peer.

3) AssistanceRequesterMachine<- Central Server|Cloud ->AssistanceProviderMachine

Here, the two machines communicate through a central server/service.  Some would even call this peer-to-peer if the central server or service is basically just relaying/routing the traffic.

Based on Zdenek's posts, I think Avast Remote Assistance is #3.  What do you think and/or what leaves you unsure?

Yes, we are using #3 principle in ARA technology - it allows to establish ARA session to all users, behind NAT  etc...
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: FlyingRobot on February 27, 2012, 06:31:35 PM
If I followed your description correctly (forgive me if I did not), the above two comments seem contradictory.  If encrypted remote desktop data is relayed through an avast server and the avast server generated or otherwise has the keys, it would seem that the avast server could decrypt the remote desktop traffic.  I don't understand why that approach would be used.  The requester must establish a direct and hopefully very private communications channel with the provider in order to pass ticket information.  Lets say the requester calls the provider.  That phone call provides an opportunity for the requester to give the provider a pass phrase that could be used to derive or modify the keys privately on requester and provider sides (thus preventing the avast server from knowing them and being able to decrypt the traffic).

I have modified the original topic to be more acurate. I tried to explain that we protect Provider/Requester traffic against evil third parties, but from ARA principles of work, ARA has access to encryption keys. But ARA do not use this to decrypt communication between Provider/Requester

The main reason why we are using ARA server as proxy is that many users haven't public IP addresses, or are not able to configure own routers and other infrastructure to allow listening on TCP protocol. ARA solves this problem because users are connected through ARA server, then is not necessary to have listening socket on user workstation and both workstations can be behind the NAT.

As I mentioned before -> If you do not trust to AVAST! infrastructure, do not use this. Any Antivirus software operates with Administrative and SYSTEM privilege on your workstation, then can do anything with your computer. If you do not trust to this piece of software, why you are using it ?

Regarding your second paragraph: I appreciate what you are saying and even briefly acknowledged the ease of use aspect in a much earlier post.

Regarding your third paragraph:  I use software and very many other products/services I don't... *can't*... *really* trust because I don't have enough time to build all of those things myself and my circle of life-long friends/family (the one set of people I can and do really trust) isn't producing them.  A recent very brief elaboration on the concept is at http://forum.avast.com/index.php?topic=94034.msg750020#msg750020 .  I'll only add that I do at times even consider myself "untrusted" when another party is involved.  For example, I'm designing a tool that will have access to users' sensitive information.  The solution would be much simpler, and from a business point of view have a higher market value, if that information was sent to a server for processing/storage.  I do NOT want that though... I don't have a legitimate need to receive/see their information and I don't want to create another vector through which their sensitive information might be compromised.  So I'm stubbornly pursuing a more complicated less valuable solution that will keep their sensitive information from ever leaving their machine.  Hopefully you can understand my view even if you have a different one.

Regarding your first paragraph:  I don't know that I understand all that is meant by "ARA principles of work", but I understand the system is designed such that your server has access to the Provider/Requester traffic keys.  Perhaps you are leveraging that in order to authenticate the secondary, non-SSL connections that are established to relay said data.  Point was/is though, I think you can make it so that you don't have the keys for the innermost data which communicates the provider's commands to the requester's system and the view of the requester's system back to the provider.   Please seriously consider that.  You may not be an evil third party, but you are still a third party in the context of remote assistance between requester and provider. 

PS: An explicit thank you for taking your time to read user comments and discuss such matters.
Title: Re: Unite against REMOTE AVAST SECURITY BREACH
Post by: Zdenek on February 28, 2012, 12:45:25 PM

Regarding your first paragraph:  I don't know that I understand all that is meant by "ARA principles of work", but I understand the system is designed such that your server has access to the Provider/Requester traffic keys.  Perhaps you are leveraging that in order to authenticate the secondary, non-SSL connections that are established to relay said data.  Point was/is though, I think you can make it so that you don't have the keys for the innermost data which communicates the provider's commands to the requester's system and the view of the requester's system back to the provider.   Please seriously consider that.  You may not be an evil third party, but you are still a third party in the context of remote assistance between requester and provider. 

PS: An explicit thank you for taking your time to read user comments and discuss such matters.

ARA uses the ARA server as proxy, to allow connect together workstations behind the NAT. It is the reason why ARA is designed as is, not to access crypto keys. Due this  All traffic MUST GOES THROUGH THE SERVER.

Then , here is no way to exchange crypto keys between Provider/Requester without transfer them through the server. They have to go through the server in any case.

Note about first SSL connections: We use these connections to pair TCP connections from Requestor/Provider together and protect Assistance Ticket against sniffing during this process.