[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] [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=16930292#comment-16930292 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/16/19 7:50 AM: --- [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Note that is not just me saying that, but my legal department. Please also note that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder (probably you need to go to OCR to make it work). If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. I would also suggest to make it optional of course and just to provide the necessary hooks (eg. I could think of being able to check the stream for steganography). was (Author: bolke): [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context is basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Please also not that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder (probably you need to go to OCR to make it work). If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. I would also suggest to make it optional of course and just to provide the necessary hooks (eg. I could think of being able to check the stream for steganography). > 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
[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=16930292#comment-16930292 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/16/19 7:45 AM: --- [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context is basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Please also not that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder (probably you need to go to OCR to make it work). If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. I would also suggest to make it optional of course and just to provide the necessary hooks (eg. I could think of being able to check the stream for steganography). was (Author: bolke): [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context is basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Please also not that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder. If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. I would also suggest to make it optional of course and just to provide the necessary hooks (eg. I could think of being able to check the stream for steganography). > 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] [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=16930292#comment-16930292 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/16/19 7:44 AM: --- [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context is basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Please also not that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder. If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. I would also suggest to make it optional of course and just to provide the necessary hooks (eg. I could think of being able to check the stream for steganography). was (Author: bolke): [~nick.couch...@yahoo.com] We have all those measures in place (okay except for metal detectors and cameras are not allowed by law). Our case for improving this with Guacamole is also not having to resort to more invasive measure for the users. In GDPR context is basically means that you need to do your best to limit the possibility for data leakage. This means if I am aware of such a risk I need to mitigate that risk. The approach I am suggesting is a mitigating measure. Please also not that we did not take that website as the basis for our analysis. It was just an easy means to show what the security community thinks the attack surface to Guacamole currently is. As mentioned our teams were able to extract data really quickly. [~mike.jumper] There are things you can do to detect steganography. See: [https://incoherency.co.uk/blog/stories/image-steganography.html] . And it seems that "Actually there are properties of images that meant that the noise introduced through stego is actually, especially for LSBR, VERY easy to detect." ([https://www.cs.ox.ac.uk/teaching/materials15-16/advsec/advsec-notes-ch01234.pdf] - behind login, I'll see if I can get it open). As we control the data going out, adding noise would make steganography harder. If a detection mechanism would be in place (arguably outside Guacamole) it would be a major selling point for Guacamole. Obviously, in case of encryption industry standards should be chosen. I never suggested to create our own encryption. > 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=16930080#comment-16930080 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/15/19 8:49 PM: --- [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. Edit: or are you arguing that Guacamole should not serve this case? That would be a petty, cause it would mean it won't be too interesting in an enterprise context. However, why do you then have the possibility to disable the clipboard as that won't solev any issue either? was (Author: bolke): [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. Edit: or are you arguing that Guacamole should not serve this case? That would be a petty, cause it would mean it won't be too interesting in an enterprise context. However, why do you then have the possibility to disable the clipboard? > 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=16930080#comment-16930080 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/15/19 8:49 PM: --- [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. Edit: or are you arguing that Guacamole should not serve this case? That would be a petty, cause it would mean it won't be too interesting in an enterprise context. However, why do you then have the possibility to disable the clipboard as that won't solve any issue either? was (Author: bolke): [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. Edit: or are you arguing that Guacamole should not serve this case? That would be a petty, cause it would mean it won't be too interesting in an enterprise context. However, why do you then have the possibility to disable the clipboard as that won't solev any issue either? > 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=16930080#comment-16930080 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/15/19 8:48 PM: --- [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. Edit: or are you arguing that Guacamole should not serve this case? That would be a petty, cause it would mean it won't be too interesting in an enterprise context. However, why do you then have the possibility to disable the clipboard? was (Author: bolke): [~nick.couch...@yahoo.com] Why do you think it is a corner case? We deploy guacamole desktops to 500+ users around the globe with many more in the pipeline. I don't know all of them personally and statistically there are going to be malevolent users. It only takes _one_ user to get me a fine of up to 10Mio or 2% annual revenue (GDPR) as someone could argue the risk was raised but we did not take enough action. Besides, given the fact that a pentester tried it and succeeded quite easily it is bound to be known in less repectful communities. One employs security in a layered fashion. I see this as the equivalent of someone entering the building with a valid pass, but then to let him out carrying equipment because the gate is so wide that anything passes trough. Let's make it possible to limit the size of the gate: it won't solve the issue but someone might not even try or will get caught quicker. > 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=16930057#comment-16930057
]
Bolke de Bruin edited comment on GUACAMOLE-880 at 9/15/19 7:22 PM:
---
{quote}Doesn't the above post simply go over what can be done to any
unencrypted web application that provides a public API? Without something like
TLS to guarantee integrity, I would think it goes without saying that any
malicious third party would have the exact same capabilities as the legitimate
user.
{quote}
Correct. The aim would be to make it more difficult for a malevolent user to
parse the data that was received. Some thoughts are:
1) Add a little bit of noise to the data, which the human eye cant see but will
change the data being parsed or even prevent it from parsing
2) Encrypt the channel with a symmetric key which is hidden inside
uglified/obfuscated javascript. This is what some banks are using.
3) ?
Again it is not the aim to stop it, but rather to make it more difficult so
that anyone trying this would look "next door" first.
was (Author: bolke):
Correct. The aim would be to make it more difficult for a malevolent user to
parse the data that was received. Some thoughts are:
1) Add a little bit of noise to the data, which the human eye cant see but will
change the data being parsed or even prevent it from parsing
2) Encrypt the channel with a symmetric key which is hidden inside
uglified/obfuscated javascript. This is what some banks are using.
3) ?
Again it is not the aim to stop it, but rather to make it more difficult so
that anyone trying this would look "next door" first.
> 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=16930062#comment-16930062 ] Bolke de Bruin edited comment on GUACAMOLE-880 at 9/15/19 7:20 PM: --- [~nick.couch...@yahoo.com] you probably assume an external attacker. Now assume we have an attacker that has valid credentials. TLS doesn't really matter in that circumstance. Insider threats are the biggest worry (think Capital One for example). The analysis on that page is exactly that. This was a red/blue team exercise for us. So, you are right that it is equivalent to the other protocols. However, for these to implement capturing the data is just more difficult as the protocol is less known or harder to implement (e.g. RDP). We don't expose SSH for the same reasons: it's way to easy to download data over such a connection. I might be stretching the use case for Guacamole. However, imho it's a valid one: Use guacamole as gateway to limit the attack surface to your servers and limit possible data leakage (good sell in the enterprise world I assure you). Otherwise we could just expose SSH directly and forward ports over it? was (Author: bolke): [~nick.couch...@yahoo.com] you probably assume an external attacker. Now assume we have an attacker that has valid credentials. Insider threats are the biggest worry (think Capital One for example). The analysis on that page is exactly that. This was a red/blue team exercise for us. So, you are right that it is equivalent to the other protocols. However, for these to implement capturing the data is just more difficult as the protocol is less known or harder to implement (e.g. RDP). We don't expose SSH for the same reasons: it's way to easy to download data over such a connection. I might be stretching the use case for Guacamole. However, imho it's a valid one: Use guacamole as gateway to limit the attack surface to your servers and limit possible data leakage (good sell in the enterprise world I assure you). Otherwise we could just expose SSH directly and forward ports over it? > 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=16930056#comment-16930056
]
Nick Couchman edited comment on GUACAMOLE-880 at 9/15/19 7:10 PM:
--
{quote}
Doesn't the above post simply go over what can be done to any unencrypted web
application that provides a public API? Without something like TLS to guarantee
integrity, I would think it goes without saying that any malicious third party
would have the exact same capabilities as the legitimate user.
{quote}
+1
[~bolke]: I fail to see how, with *properly secured* connections (verified,
uncompromised TLS connections), any of the analysis on that page is possible?
I also fail to see how this differs from pretty much any other network
application out there - web (HTTPS), RDP, SSH, etc.? Can you explain why you
think that Guacamole needs this extra layer of obfuscation where RDP and SSH
don't?
was (Author: nick.couch...@yahoo.com):
{qutoe}
Doesn't the above post simply go over what can be done to any unencrypted web
application that provides a public API? Without something like TLS to guarantee
integrity, I would think it goes without saying that any malicious third party
would have the exact same capabilities as the legitimate user.
{quote}
+1
[~bolke]: I fail to see how, with *properly secured* connections (verified,
uncompromised TLS connections), any of the analysis on that page is possible?
I also fail to see how this differs from pretty much any other network
application out there - web (HTTPS), RDP, SSH, etc.? Can you explain why you
think that Guacamole needs this extra layer of obfuscation where RDP and SSH
don't?
> 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=16930017#comment-16930017 ] Michael Jumper edited comment on GUACAMOLE-880 at 9/15/19 5:38 PM: --- There is no level of obfuscation which would prevent the legitimate users of any remote desktop protocol from obtaining information from the graphical content of their own sessions, at least not without making things unusable. Obtaining information from received graphics is exactly what the human brain does when it accesses a remote desktop. You cannot prevent this. Any attempt to obfuscate things while still allowing the remote desktop to be usable would amount to [security through obscurity|https://en.wikipedia.org/wiki/Security_through_obscurity]. As far as ensuring that users external to a remote desktop session cannot capture the content of other sessions, Guacamole already supports this through encryption. It is expected that Guacamole deployments will use SSL/TLS in front of the web application in production. If needed in your use case, you can also enable SSL/TLS between the web application and guacd. was (Author: mike.jumper): There is no level of obfuscation which would prevent the legitimate users of any remote desktop protocol from obtaining information from the graphical content of their own sessions, at least without making things unusable. Obtaining information from received graphics is exactly what the human brain does when it accesses a remote desktop. You cannot prevent this. Any to obfuscate things while still allowing the remote desktop to be usable would amount to [security through obscurity|https://en.wikipedia.org/wiki/Security_through_obscurity]. As far as ensuring that users external to a remote desktop session cannot capture the content of other sessions, Guacamole already supports this through encryption. It is expected that Guacamole deployments will use SSL/TLS in front of the web application in production. If needed in your use case, you can also enable SSL/TLS between the web application and guacd. > 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)
