lens searches can be unmasked by local network sniffing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unity-lens-shopping (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
first i want to say that the default nature of the amazon spam plugin really is a violation of the community trust, and I highly advocate the EFF's position on this plugin.. the user should have the choice *before* their information is reported to some entity on the internet..
issue:
while its true that the lens encrypts search queries to the productsearch.
how this works in the real world:
an "eve" precaches the search results using a word list and parses the json results and notes which and how many image results were provided for a particular word of interest.. "eve" then sniffs the network looking for bursts of image requests, the attacker then compares the block of image requests to the results that were cached earlier and and scores the results.
the search term (or closely related search term) is then revealed
an attacker can also choose to build the dictionary after the initial packet sniffing so long as the server cached contents havnt shifted significantly .. though it is likely the results would still me similar enough to score the results for a best fit.
an example:
"eve" has a database filled by requesting a list of interesting search terms, below is the query for "diapers":
phar@thing:~/ubuntu curl https:/
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
"http://
now, eve sniffs the network looking for a closly related burst of image queries:
phar@thing:~/ubuntu sudo ngrep GET -S 50 -d eth1 -q -t
interface: eth1 (192.168.
match: GET
T 2012/11/03 16:52:57.664091 192.168.1.7:53387 -> 54.240.188.195:80 [AP]
GET /images/
T 2012/11/03 16:52:57.668615 192.168.1.7:46213 -> 54.240.188.34:80 [AP]
GET /images/
T 2012/11/03 16:52:57.669380 192.168.1.7:46985 -> 54.240.188.248:80 [AP]
GET /images/
T 2012/11/03 16:52:57.693032 192.168.1.7:46922 -> 205.128.91.126:80 [AP]
GET /images/
T 2012/11/03 16:53:18.938638 192.168.1.7:57036 -> 54.240.188.68:80 [AP]
GET /images/
T 2012/11/03 16:53:19.043135 192.168.1.7:44472 -> 98.142.98.180:80 [AP]
GET /static/
T 2012/11/03 16:53:19.047354 192.168.1.7:44474 -> 98.142.98.180:80 [AP]
GET /static/
T 2012/11/03 16:53:19.050731 192.168.1.7:59410 -> 54.240.188.137:80 [AP]
GET /images/
T 2012/11/03 16:53:19.125583 192.168.1.7:44475 -> 98.142.98.180:80 [AP]
GET /static/
T 2012/11/03 16:53:19.127287 192.168.1.7:46998 -> 54.240.188.248:80 [AP]
GET /images/
T 2012/11/03 16:53:19.135532 192.168.1.7:36150 -> 54.240.188.53:80 [AP]
GET /images/
T 2012/11/03 16:53:19.137307 192.168.1.7:50431 -> 54.240.188.26:80 [AP]
GET /images/
T 2012/11/03 16:53:19.138487 192.168.1.7:39225 -> 54.240.188.129:80 [AP]
GET /images/
T 2012/11/03 16:53:19.140637 192.168.1.7:39971 -> 54.240.188.69:80 [AP]
GET /images/
T 2012/11/03 16:53:19.200223 192.168.1.7:56033 -> 216.137.35.219:80 [AP]
GET /images/
T 2012/11/03 16:53:19.215688 192.168.1.7:44482 -> 98.142.98.180:80 [AP]
GET /static/
T 2012/11/03 16:53:19.308043 192.168.1.7:34426 -> 216.137.35.57:80 [AP]
GET /images/
T 2012/11/03 16:53:19.313324 192.168.1.7:46245 -> 54.240.188.131:80 [AP]
GET /images/
i leave it to the reader to do the comparison, you'll see that there are /some/ differences between the two.. it might be due to my client string.. or some mixing function on the server, but you can see how scoring would quickly give you one or two candidate terms depending on how many matches you requre before calling it a candidate.. you can see how amazons algorithm for generating search results works for eve here... its was pretty easy to whip up a python tool for doing this using googles bad word list as a dictionary..
other side channel leakage:
since the search requests are "live" partial search results are provided - sometimes keystroke to keystroke for those that type slowly - an attacker who has a large enough database can use these intermediate results to narrow down subsequent result possibilities for increased accuracy
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: unity-lens-shopping 6.8.0-0ubuntu1
ProcVersionSign
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Sat Nov 3 16:21:42 2012
InstallationDate: Installed on 2012-11-01 (2 days ago)
InstallationMedia:
MarkForUpload: True
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: unity-lens-shopping
UpgradeStatus: No upgrade log present (probably fresh install)
Status changed to 'Confirmed' because the bug affects multiple users.