Author Topic: ARA Security Considerations  (Read 40052 times)

0 Members and 1 Guest are viewing this topic.

UserA789

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

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 , 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 ;) .

Offline bob3160

  • Avast Überevangelist
  • Probably Bot
  • *****
  • Posts: 48523
  • 64 Years of Happiness
    • bob3160 Protecting Yourself, Your Computer and, Your Identity
Re: ARA Security Considerations
« Reply #106 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.
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 #107 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?

Offline Zdenek

  • Avast team
  • Jr. Member
  • *
  • Posts: 38
Re: Unite against REMOTE AVAST SECURITY BREACH
« Reply #108 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 ? 

Offline Zdenek

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

Offline Zdenek

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

FlyingRobot

  • Guest
Re: Unite against REMOTE AVAST SECURITY BREACH
« Reply #111 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.
« Last Edit: February 27, 2012, 06:39:53 PM by FlyingRobot »

Offline Zdenek

  • Avast team
  • Jr. Member
  • *
  • Posts: 38
Re: Unite against REMOTE AVAST SECURITY BREACH
« Reply #112 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.