Fwd: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer
fyi -------- Original Message -------- Subject: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer Date: Wed, 27 Apr 2011 14:49:01 -0700 From: Nathan of Guardian <nathan@guardianproject.info> Organization: The Guardian Project To: guardian-dev@lists.mayfirst.org CC: tor-dev@lists.torproject.org Fantastic, Manuel. Looks like we are going to need some wine over to patch this up. This type of look at how our transproxy all rules are working (or not) is long overdue. I really appreciate your effort. The first thing that comes to mind is that we are setting up the iptables rules on an app-by-app basis, using the list of user IDs we are provided by Android API calls. It is quite possible that certain subsystems are not represented in that list. There may be a better way to implement the transproxy all implementation that is more of a "everything but tor" approach. Our transproxy configuration is based on the approach outlined here: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProx... We'll have to go through additional recommended configurations that we are not addressing in our current "all" setup, and see if they address the leakage you have found. Best, Nathan On 04/27/2011 12:40 PM, Manuel wrote:
Hi all!
Mini-intro: Hi, I'm Manuel (aka __sporkbomb), infosec researcher from Austria, got bored and asked Nathan if he wanted help with ORBot ;)
Setup: Simply an open AP, a Desire HD running CM 7.0.2 and 0.2.2.22-orbot-alpha-1.0.5.20110417a-dev plus airodump.
Methodology: The dump was started after the tor connection (and full transproxying) was established in order to reduce false positives. Total dump length is around 3h15m, around 57MB of data. Of course the phone was left idle for a quite a while, also to ensure that it didn't do nasty untorified stuff when waking up to check mails. Afterwards, I used Wireshark's 'Endpoints' statistics function to determine all TCP endpoints in the dump[0] and awk'd & uniq'd the IPs out of it[1]. As the next step, I determined which of these IPs was in my cached-consensus[2] (somewhat ill-advised, because I compared with my laptop's cached-consensus rather than the phone's, causing two false positives [false non-tor nodes] that actually were nodes). I also ran a reverse lookup on all IPs [3]. As the last step, I went through all communication with IPs that were not found in cached-consensus[4].
You can find links to most of the files I produced at the end of this mail, excluding the dump, which I can provide if requested, but would rather not hand out publicly (mostly because of the size).
All in all, the phone connected to 88 IPs during that time. 37 of those were not contained in the laptop's cached-consensus, two of which were actually legitimate nodes (according to metrics.torproject.org) that just went down throughout the duration of the test, leaving us with 35 non-Tor IPs. They can be categorized as follows:
- 27 of those nodes had no other communication than multiple TCP packets, sometimes from a few different source ports (i.e. different TCP connections), all originating from the phone and having FIN+PSH+ACK set. (PSH is the 'push flag', which requests that this data bypass buffers and be handed directly to the application)
- 4 existing connections that still transmitted data; one even contained Market HTTP (cleartext) API requests.
- 4 were completely unencrypted and newly established connections to YouTube or Revision3 video servers. This one is rather bad - it seems that the video player subsystem of Android ignores the proxy setting and leaks everything, including DNS. I also mentioned this yesterday on Twitter, but didn't want to post it yet without confirmation, but it's definitely reproducible on my end.
-------------------- Sumup of this part: Generally solid performance, but already established connections might pose a threat (a minor one I'd guess, however...unless one of you can think of a scenario where that causes Bad Things to happen?). Additionally, the video player completely ignores the proxy setting and communicates untorified. While video streaming isn't a strong point of Tor anyway, it's still not good...does anyone have good contact to CyanogenMod people and can ask about that one?
Various tidbits of slight UX annoyances plus a few suggestions: - ORBot ignores the "Transparent proxy" setting when connecting, I always have to enter the Settings menu, untick and re-tick "Transparent proxying" and press back to actually cause it to be enabled. - Related to this: Is it possible to colour-code the "Transparent proxying {DIS,EN}ABLED" notification? The bug above might have serious consequences, because if someone doesn't visit check.torproject.org to assure that he/she is actually torified, chances are that he/she will browse in clear. DISABLED and ENABLED are only three characters away from each other, whereas a red vs green notification would probably catch the eye. - Install fails when installing/uncompressing tor binary https://trac.torproject.org/projects/tor/ticket/2989 [turns out that this is only a bug on Android<2.3, but still...see comment #1 for more details] - Blank semi-permanent status box https://trac.torproject.org/projects/tor/ticket/2993 [haven't updated this one yet; the bug actually occured only before the first reboot for me, and one time afterwards when I had b0rked the network badly] - ORBot vs DroidWall: Starts with 'You don't preserve my chains like you used to :(' and ends with, if I remember correctly, ORBot flushing iptables rules. I'll have a look at that one tomorrow (or is there already some data on it?).
For now, have a nice evening!
Cheers,
__sporkbomb
[0] http://sporkbomb.eu/orbot/endpoints [1] http://sporkbomb.eu/orbot/ips [2] http://sporkbomb.eu/orbot/inconsensus (result of a grep -c - IPs with '0' in the second field are not contained in the consensus) [3] http://sporkbomb.eu/orbot/dig-result [4] http://sporkbomb.eu/orbot/not-inconsensus.notes _______________________________________________ Guardian-dev mailing list
Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro...
You are subscribed as: nathan@guardianproject.info
_______________________________________________ Guardian-dev mailing list Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro... You are subscribed as: nathan@guardianproject.info
This is great stuff. One of the things that would be interesting future work is how safe are the protocols to use over tor in terms of cleartext exposure to exit nodes. I thought all of the google apps on the phone were using SSL, and it surprises greatly me to learn that the app market uses cleartext in any way. Is that all market activity, or just some API calls? Can exit nodes (or open wifi access points) give you altered apps, for example? Or simply delay critical updates by breaking connections because they can see you are trying to update from a vulnerable version of a particular app? This seems like a huge nightmare... Thus spake Nathan Freitas (nathan@freitas.net):
Fantastic, Manuel. Looks like we are going to need some wine over to patch this up. This type of look at how our transproxy all rules are working (or not) is long overdue. I really appreciate your effort.
The first thing that comes to mind is that we are setting up the iptables rules on an app-by-app basis, using the list of user IDs we are provided by Android API calls. It is quite possible that certain subsystems are not represented in that list.
There may be a better way to implement the transproxy all implementation that is more of a "everything but tor" approach.
Our transproxy configuration is based on the approach outlined here: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProx...
We'll have to go through additional recommended configurations that we are not addressing in our current "all" setup, and see if they address the leakage you have found.
Best, Nathan
On 04/27/2011 12:40 PM, Manuel wrote:
Hi all!
Mini-intro: Hi, I'm Manuel (aka __sporkbomb), infosec researcher from Austria, got bored and asked Nathan if he wanted help with ORBot ;)
Setup: Simply an open AP, a Desire HD running CM 7.0.2 and 0.2.2.22-orbot-alpha-1.0.5.20110417a-dev plus airodump.
Methodology: The dump was started after the tor connection (and full transproxying) was established in order to reduce false positives. Total dump length is around 3h15m, around 57MB of data. Of course the phone was left idle for a quite a while, also to ensure that it didn't do nasty untorified stuff when waking up to check mails. Afterwards, I used Wireshark's 'Endpoints' statistics function to determine all TCP endpoints in the dump[0] and awk'd & uniq'd the IPs out of it[1]. As the next step, I determined which of these IPs was in my cached-consensus[2] (somewhat ill-advised, because I compared with my laptop's cached-consensus rather than the phone's, causing two false positives [false non-tor nodes] that actually were nodes). I also ran a reverse lookup on all IPs [3]. As the last step, I went through all communication with IPs that were not found in cached-consensus[4].
You can find links to most of the files I produced at the end of this mail, excluding the dump, which I can provide if requested, but would rather not hand out publicly (mostly because of the size).
All in all, the phone connected to 88 IPs during that time. 37 of those were not contained in the laptop's cached-consensus, two of which were actually legitimate nodes (according to metrics.torproject.org) that just went down throughout the duration of the test, leaving us with 35 non-Tor IPs. They can be categorized as follows:
- 27 of those nodes had no other communication than multiple TCP packets, sometimes from a few different source ports (i.e. different TCP connections), all originating from the phone and having FIN+PSH+ACK set. (PSH is the 'push flag', which requests that this data bypass buffers and be handed directly to the application)
- 4 existing connections that still transmitted data; one even contained Market HTTP (cleartext) API requests.
- 4 were completely unencrypted and newly established connections to YouTube or Revision3 video servers. This one is rather bad - it seems that the video player subsystem of Android ignores the proxy setting and leaks everything, including DNS. I also mentioned this yesterday on Twitter, but didn't want to post it yet without confirmation, but it's definitely reproducible on my end.
-------------------- Sumup of this part: Generally solid performance, but already established connections might pose a threat (a minor one I'd guess, however...unless one of you can think of a scenario where that causes Bad Things to happen?). Additionally, the video player completely ignores the proxy setting and communicates untorified. While video streaming isn't a strong point of Tor anyway, it's still not good...does anyone have good contact to CyanogenMod people and can ask about that one?
Various tidbits of slight UX annoyances plus a few suggestions: - ORBot ignores the "Transparent proxy" setting when connecting, I always have to enter the Settings menu, untick and re-tick "Transparent proxying" and press back to actually cause it to be enabled. - Related to this: Is it possible to colour-code the "Transparent proxying {DIS,EN}ABLED" notification? The bug above might have serious consequences, because if someone doesn't visit check.torproject.org to assure that he/she is actually torified, chances are that he/she will browse in clear. DISABLED and ENABLED are only three characters away from each other, whereas a red vs green notification would probably catch the eye. - Install fails when installing/uncompressing tor binary https://trac.torproject.org/projects/tor/ticket/2989 [turns out that this is only a bug on Android<2.3, but still...see comment #1 for more details] - Blank semi-permanent status box https://trac.torproject.org/projects/tor/ticket/2993 [haven't updated this one yet; the bug actually occured only before the first reboot for me, and one time afterwards when I had b0rked the network badly] - ORBot vs DroidWall: Starts with 'You don't preserve my chains like you used to :(' and ends with, if I remember correctly, ORBot flushing iptables rules. I'll have a look at that one tomorrow (or is there already some data on it?).
For now, have a nice evening!
Cheers,
__sporkbomb
[0] http://sporkbomb.eu/orbot/endpoints [1] http://sporkbomb.eu/orbot/ips [2] http://sporkbomb.eu/orbot/inconsensus (result of a grep -c - IPs with '0' in the second field are not contained in the consensus) [3] http://sporkbomb.eu/orbot/dig-result [4] http://sporkbomb.eu/orbot/not-inconsensus.notes _______________________________________________ Guardian-dev mailing list
Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro...
You are subscribed as: nathan@guardianproject.info
_______________________________________________ Guardian-dev mailing list
Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro...
You are subscribed as: nathan@guardianproject.info _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Mike Perry Mad Computer Scientist fscked.org evil labs
Got some time this evening if anyone wants or can meet up to hang and talk Tor and Android. +n8fr8 7185697272 -- Sent from my Guardian-powered Android phone with K-9 Mail. Please excuse my brevity. Mike Perry <mikeperry@fscked.org> wrote: This is great stuff. One of the things that would be interesting future work is how safe are the protocols to use over tor in terms of cleartext exposure to exit nodes. I thought all of the google apps on the phone were using SSL, and it surprises greatly me to learn that the app market uses cleartext in any way. Is that all market activity, or just some API calls? Can exit nodes (or open wifi access points) give you altered apps, for example? Or simply delay critical updates by breaking connections because they can see you are trying to update from a vulnerable version of a particular app? This seems like a huge nightmare... Thus spake Nathan Freitas (nathan@freitas.net): > Fantastic, Manuel. Looks like we are going to need some wine over to > patch this up. This type of look at how our transproxy all rules are > working (or not) is long overdue. I really appreciate your effort. > > The first thing that comes to mind is that we are setting up the > iptables rules on an app-b y-app basis, using the list of user IDs we are > provided by Android API calls. It is quite possible that certain > subsystems are not represented in that list. > > There may be a better way to implement the transproxy all implementation > that is more of a "everything but tor" approach. > > Our transproxy configuration is based on the approach outlined here: > https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProx... > > We'll have to go through additional recommended configurations that we > are not addressing in our current "all" setup, and see if they address > the leakage you have found. > > Best, > Nathan > > On 04/27/2011 12:40 PM, Manuel wrote: > > Hi all! > > > > Mini-intro: Hi, I'm Manuel (aka __sporkbomb), infosec researcher from > > Austria, got bored and asked Nathan if he wanted help with ORBot ;) > > > > Setup: Simply an open AP, a Desire HD running CM 7.0.2 and > > 0.2.2.22-orbot-alpha-1.0.5.20110417a-dev plus airodump. > > > > Methodology: The d ump was started after the tor connection (and full > > transproxying) was established in order to reduce false positives. Total > > dump length is around 3h15m, around 57MB of data. Of course the phone > > was left idle for a quite a while, also to ensure that it didn't do > > nasty untorified stuff when waking up to check mails. Afterwards, I used > > Wireshark's 'Endpoints' statistics function to determine all TCP > > endpoints in the dump[0] and awk'd & uniq'd the IPs out of it[1]. As the > > next step, I determined which of these IPs was in my cached-consensus[2] > > (somewhat ill-advised, because I compared with my laptop's > > cached-consensus rather than the phone's, causing two false positives > > [false non-tor nodes] that actually were nodes). I also ran a reverse > > lookup on all IPs [3]. As the last step, I went through all > > communication with IPs that were not found in cached-consensus[4]. > > > > You can find links to most of the files I produced at the end of this
mail, excluding the dump, which I can provide if requested, but would > > rather not hand out publicly (mostly because of the size). > > > > All in all, the phone connected to 88 IPs during that time. 37 of those > > were not contained in the laptop's cached-consensus, two of which were > > actually legitimate nodes (according to metrics.torproject.org) that > > just went down throughout the duration of the test, leaving us with 35 > > non-Tor IPs. They can be categorized as follows: > > > > - 27 of those nodes had no other communication than multiple TCP > > packets, sometimes from a few different source ports (i.e. different TCP > > connections), all originating from the phone and having FIN+PSH+ACK set. > > (PSH is the 'push flag', which requests that this data bypass buffers > > and be handed directly to the application) > > > > - 4 existing connections that still transmitted data; one even contained > > Market HTTP (cleartext) API requests. > > > > - 4 were completely unencrypted and newly established connections to > > YouTube or Revision3 video servers. This one is rather bad - it seems > > that the video player subsystem of Android ignores the proxy setting and > > leaks everything, including DNS. I also mentioned this yesterday on > > Twitter, but didn't want to post it yet without confirmation, but it's > > definitely reproducible on my end. > > > > -------------------- > > Sumup of this part: Generally solid performance, but already established > > connections might pose a threat (a minor one I'd guess, however...unless > > one of you can think of a scenario where that causes Bad Things to > > happen?). Additionally, the video player completely ignores the proxy > > setting and communicates untorified. While video streaming isn't a > > strong point of Tor anyway, it's still not good...does anyone have good > > contact to CyanogenMod people and can ask about that one? > > > > Various tidbits of slight UX annoyances plus a few suggesti ons: > - ORBot ignores the "Transparent proxy" setting when connecting, I > > always have to enter the Settings menu, untick and re-tick "Transparent > > proxying" and press back to actually cause it to be enabled. > > - Related to this: Is it possible to colour-code the "Transparent > > proxying {DIS,EN}ABLED" notification? The bug above might have serious > > consequences, because if someone doesn't visit check.torproject.org to > > assure that he/she is actually torified, chances are that he/she will > > browse in clear. DISABLED and ENABLED are only three characters away > > from each other, whereas a red vs green notification would probably > > catch the eye. > > - Install fails when installing/uncompressing tor binary > > https://trac.torproject.org/projects/tor/ticket/2989 [turns out that > > this is only a bug on Android<2.3, but still...see comment #1 for more > > details] > > - Blank semi-permanent status box > > https://trac.torproject.org/projects/tor/ticket/2993 [have n't updated > > this one yet; the bug actually occured only before the first reboot for > > me, and one time afterwards when I had b0rked the network badly] > > - ORBot vs DroidWall: Starts with 'You don't preserve my chains like you > > used to :(' and ends with, if I remember correctly, ORBot flushing > > iptables rules. I'll have a look at that one tomorrow (or is there > > already some data on it?). > > > > For now, have a nice evening! > > > > Cheers, > > > > __sporkbomb > > > > > > > > > > > > [0] http://sporkbomb.eu/orbot/endpoints > > [1] http://sporkbomb.eu/orbot/ips > > [2] http://sporkbomb.eu/orbot/inconsensus (result of a grep -c - IPs > > with '0' in the second field are not contained in the consensus) > > [3] http://sporkbomb.eu/orbot/dig-result > > [4] http://sporkbomb.eu/orbot/not-inconsensus.notes > >_____________________________________________
Guardian-dev mailing list > > > > Post: Guardian-dev@lists.mayfirst.org > > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > > > To Unsubscribe > > Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org > > Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro... > > > > You are subscribed as: nathan@guardianproject.info > >_____________________________________________ Guardian-dev mailing list > > Post: Guardian-dev@lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org > Or visit: > https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpro... > > You are subscribed as: nathan@guardianproject.info >_____________________________________________ tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- Mike Perry Mad Computer Scientist fscked.org evil labs_____________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Mike Perry -
Nathan Freitas -
nathanfreitas＠gmail.com