Author Topic: ARA Security Considerations  (Read 40058 times)

0 Members and 1 Guest are viewing this topic.

Indoctor

  • Guest
Re: ARA Security Considerations
« Reply #75 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.
« Last Edit: February 25, 2012, 03:40:16 PM by Indoctor »

Online bob3160

  • Avast Überevangelist
  • Probably Bot
  • *****
  • Posts: 48524
  • 64 Years of Happiness
    • bob3160 Protecting Yourself, Your Computer and, Your Identity
Re: ARA Security Considerations
« Reply #76 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.  :)
Free Security Seminar: https://bit.ly/bobg2023  -  Important: http://www.organdonor.gov/ -- My Web Site: http://bob3160.strikingly.com/ - Win 11 Pro v22H2 64bit, 16 Gig Ram, 1TB SSD, Avast Free 23.5.6066, How to Successfully Install Avast http://goo.gl/VLXdeRepair & Clean Install https://goo.gl/t7aJGq -- My Online Activity https://bit.ly/BobGInternet

Offline Zdenek

  • Avast team
  • Jr. Member
  • *
  • Posts: 38
Re: ARA Security Considerations
« Reply #77 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

Indoctor

  • Guest
Re: ARA Security Considerations
« Reply #78 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

Offline Gopher John

  • Avast Evangelist
  • Super Poster
  • ***
  • Posts: 2098
Re: ARA Security Considerations
« Reply #79 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.
AMD A6-5350M APU with Radeon HD Graphics, 8.0GB RAM, Win7 Pro SP1 64bit, IE11
i7-3610QM 2.3GHZ, 8.0GB Ram,  Nvidia GeForce GT 630M 2GB, Win7 Pro SP1 64bit, IE 11
Common to both: Avast Premium Security 19.7.2388, WinPatrol Plus, SpywareBlaster 5.5, Opera 12.18, Firefox 68.0.2, MBam Free, CCleaner

Offline Asyn

  • Avast Überevangelist
  • Certainly Bot
  • *****
  • Posts: 76037
    • >>>  Avast Forum - Deutschsprachiger Bereich  <<<
Re: Unite against REMOTE AVAST SECURITY BREACH
« Reply #80 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..! :)
W8.1 [x64] - Avast Free AV 23.3.8047.BC [UI.757] - Firefox ESR 102.9 [NS/uBO/PB] - Thunderbird 102.9.1
Avast-Tools: Secure Browser 109.0 - Cleanup 23.1 - SecureLine 5.18 - DriverUpdater 23.1 - CCleaner 6.01
Avast Wissenswertes (Downloads, Anleitungen & Infos): https://forum.avast.com/index.php?topic=60523.0

FlyingRobot

  • Guest
Re: Unite against REMOTE AVAST SECURITY BREACH
« Reply #81 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).   

Offline Lisandro

  • Avast team
  • Certainly Bot
  • *
  • Posts: 67195
Re: ARA Security Considerations
« Reply #82 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.
The best things in life are free.

Hermite15

  • Guest
Re: ARA Security Considerations
« Reply #83 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?
 
« Last Edit: February 25, 2012, 08:12:15 PM by logos »

UserA789

  • Guest
Re: ARA Security Considerations
« Reply #84 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

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

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'.

Offline Lisandro

  • Avast team
  • Certainly Bot
  • *
  • Posts: 67195
Re: ARA Security Considerations
« Reply #85 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).
The best things in life are free.

Hermite15

  • Guest
Re: ARA Security Considerations
« Reply #86 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.

Offline Lisandro

  • Avast team
  • Certainly Bot
  • *
  • Posts: 67195
Re: ARA Security Considerations
« Reply #87 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?
The best things in life are free.

Online bob3160

  • Avast Überevangelist
  • Probably Bot
  • *****
  • Posts: 48524
  • 64 Years of Happiness
    • bob3160 Protecting Yourself, Your Computer and, Your Identity
Re: ARA Security Considerations
« Reply #88 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.
Free Security Seminar: https://bit.ly/bobg2023  -  Important: http://www.organdonor.gov/ -- My Web Site: http://bob3160.strikingly.com/ - Win 11 Pro v22H2 64bit, 16 Gig Ram, 1TB SSD, Avast Free 23.5.6066, How to Successfully Install Avast http://goo.gl/VLXdeRepair & Clean Install https://goo.gl/t7aJGq -- My Online Activity https://bit.ly/BobGInternet

FlyingRobot

  • Guest
Re: ARA Security Considerations
« Reply #89 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.