[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931934#comment-16931934 ] Nick Couchman commented on GUACAMOLE-880: - [~bolke]: If you're willing to work on it and want to fork the code and submit a pull request, I'm happy to be part of the review process and see if it's something worth putting into the code. My primary concerns for adding something like this would be: * User experience - making sure that normal usage doesn't trigger false-positive alerts/alarms/etc. * Performance - Making sure that such changes are not going to drastically impact resource utilization/requirements on either the server or the client. I'm most concerned about this from the perspective of the AngularJS application within the web browser. I do think there is a level of practicality that will have to be considered, here - yes, multiple gigabytes of data were exfiltrated via an API; however, again, the point is that this was assuming the best case scenario for the pen tester - that is, they already had valid accounts and access to the data to do the test. I'm not sure that the gravity of the situation is really accurately reflected by the pen test. Layered security would either mitigate, detect, or correctly pinpoint the sources of these attacks, and I really do not believe that the EU is going to come after someone for GDPR violations simply because they use Guacamole and Guacamole doesn't 100% mitigate steganographic attacks. If you've properly done defense-in-depth at all layers, I believe that would be recognized and accepted by a reasonable governing body like the EU. > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931141#comment-16931141 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/17/19 7:23 AM: --- [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api within an hour. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I am willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worth a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? was (Author: bolke): [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api within an hour. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I am willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931141#comment-16931141 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/17/19 7:23 AM: --- [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api within an hour. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I am willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? was (Author: bolke): [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I am willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931141#comment-16931141 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/17/19 7:22 AM: --- [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I am willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? was (Author: bolke): [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GUACAMOLE-880) Obfuscation of guacamole client protocol
[ https://issues.apache.org/jira/browse/GUACAMOLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931141#comment-16931141 ] Bolke de Bruin commented on GUACAMOLE-880: -- [~Why4ArtThou] Unfortunately, I think you misunderstand the gravity of the situation. It was shown that multiple gigabytes could be exfiltrated in an automated fashion by using the python api. There was nothing visually required on the client side. I am aware of precious developer time: I am a Apache committer myself and contributor to several projects. The intention in this thread is to make 1) people aware if the situation, 2) see if we can get to an agreed course of action. This to ensure developer time is not wasted. Finally, I willing to put the time of my team into this or even hire someone that could address the isue that we are seeing and then bring it back to the community. I think that's worthwhile a bit of discussion right? [~nick.couch...@yahoo.com] [~mike.jumper] Another avenue we were thinking of is to enable a kind of non intrusive Turing test. Ie. by sampling of one uses the keyboard and mouse (not capturing keystrokes, but merely statistical tracking) we could determine (statistically) if a user is actually human. If not we could force reidentification or a real turing test (eg. recaptcha like). This does not interfer with the protocol and does not add noise to the images (although stenography detection could also trigger a turing test). It would require to be able to hook in to the stream (a kind of filter) that is able to trigger the follow up. What do you think? > Obfuscation of guacamole client protocol > > > Key: GUACAMOLE-880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-880 > Project: Guacamole > Issue Type: Wish > Components: guacamole-client, guacamole-server >Reporter: Bolke de Bruin >Priority: Major > Labels: security > > One of the reasons we deploy guacamole is to limit data leakage > possibilities. We recently had a audit on our infrastructure and it was shown > that it was quite easy to leak out data through the guacamole protocol by > creating special images inside the desktop and then using mitmproxy (python) > and the guacamole python modules to capture the data inside those images. > In order to limit the attack surface we would like to have obfuscation of the > protocol if configured to do so. Of course this could be done by implementing > a custom protocol, but it would be nice if Guacamole would have the > facilities (hooks) to do this. One could think of allowing a custom function > to encrypt/obfuscate the outgoing stream and attach into the javascript that > decrypts the stream. -- This message was sent by Atlassian Jira (v8.3.2#803003)
