Hiding Something In Plain View
I’ve been thinking a lot about how the Jikto code was leaked over the last few days. At first I thought it was a really easy problem to solve, then I thought it was a really hard problem to solve, and now I’ve come around full circle but not in the way I originally thought I would. The problem is that Jikto needs to be on the public internet to work (because Google needs to be able to pull the content at some point, and maybe some other reasons). Okay, given that requirement, that makes things like session tokens (cookies) or browser certificates out of the question. Bummer, because that really is the best answer. Then you have stuff like HTAccess, but unfortunately rather than popping up a 401 basic auth dialog it just gives you the standard 401 error. So that’s out the window too.
So then I started thinking this is a really hard problem. You can’t block based on IP because anyone can use the translation service. You can’t do it via time, because someone could type it in and hit enter at exactly the same second (and it would suck if you missed your window). Maybe it’s not possible after all, I think to myself.
Then I recall a conversation I had with beNi about how he was in the process of writing a worm that only allowed you to pull the worm code once based on your IP address. While that’s not a new concept, and it wouldn’t apply here (the thief could use another IP address to pull the code and maybe the translation service uses more than one IP to pull the content) there is some merit to this concept. Note: using only a single IP address is often a bad idea in worms due to proxies like AOL, and Tor, where you can actually reduce the transmission effectiveness.
What if you were to create a counter that said that you could only pull this content one time total (not based on IP). That way the code is pulled, and cached. You don’t need to ever pull it again, as long as the proxy doesn’t re-pull it it’s fine. Or better yet it can send back the unmodified headers if Google requests it again, so it doesn’t need to re-send the data.
In this way, the data is used only once, and available only once (so you had better make sure you are the first person to type that URL in since it is only protected by the fact that you are the first to grab it). You’ve effectively hidden the content in plain view, and allowed the attacker (or data theif or whatever) to know the exact location of the script, without ever giving it to them. The point being, I think there are techniques to hide information in plain sight without giving it to anyone else.
April 6th, 2007 at 5:20 pm
HTTP ought to have a TAKE method.
April 7th, 2007 at 6:19 am
This reminds me of a simple python script I wrote some time ago. Sort of a 1 shot webserver. Command line usage is similar to:
share.py -key secret -times 10 filetoshare.txt
This starts up a very very simple webserver that caches flietoshare.txt in memory and then sends it to the first 10 people who request any url that contains “secret”. It is easy to imagine many useful policy extensions - time based expiration, source address based access control, etc.
If you run share with no arguments it simply serves up copies of itself.
It was designed to make it easy to share files with people in a relatively controlled manner. The code is super simple and thus very easy to audit.
April 7th, 2007 at 2:19 pm
Why is a password-based approach not sufficient? I was recently introduced to a startup that has an interesting approach to the problem - or at least to part of the problem. To authenticate you, the solution relies on your standard password but also matches the password with how *you* type it. You first train the tool by entering your password 6 times in a row. I had a chance to try it out. Even when I gave my test password to someone else, the tool immediately flagged their entry as valid but with a suspicious keyboard rate pattern.
I think it’s a rather nice approach rather than deploying client-side certs and other unmanageable world-wide-based PKI solutions.
April 9th, 2007 at 2:13 pm
This kind of technique is useful in putting together a targeted XSS attack whilst keeping plausible deniability. You create a page with some form of innocuous content and include the XSS script, trick your target into viewing the page, and have some server-side code which removes itself and the malicious script from the server immediately after it’s first requested.
The only way the target can figure out what you’ve done is by checking the source of the page on their first visit (something that can be mitigated with an automatic refresh, for example) - if they get suspicious and revisit the page, all they’ll see is your innocuous content.