Archive for September, 2009

New HTTP Access Control

September 25, 2009

So there’s a new spec for what is ambiguously called HTTP Access Control coming out of W3C and currently, I think, only supported by Firefox.  What it does is allow you to run cross-domain AJAX calls.  This means you can download a page from domain.com that has XMLHttpRequest calls to otherdomain.com.  This has always been disallowed by the Same Origin Policy.  The controls they’ve put in place are on otherdomain.com.  otherdomain.com can control which original domain’s pages can call them.  The problems are manifest.

First, otherdomain.com does its access control based on the new HTTP Header called Origin which is passed as part of the call FROM THE BROWSER.  It would be beyond trivial to fake that.  otherdomain.com doesn’t have any kind of keys set it with domain.com such that it can trust a request.  It believes whatever the user tells it.  It’s like being able to log in with no password; you just have to figure out a trusted origin domain.

Second, the only protection is for otherdomain.com.  There is none for the user, which is perhaps a bigger problem with cross domain AJAX.  Any site that’s susceptible to cross site scripting can now not only have local Javascript inserted, it can have remote calls that might do anything!  Previously, to send info to an evil server, you would have at least had to submit() a form to evil server.  The user might have noticed… even if you redirected them to a page that looked reasonable.  Now, they just pass any information you enter to their server via AJAX and allow you to continue using the same site.  No sign except the excess http requests.

Seriously, WTF?

spotthevuln.com

September 22, 2009

OK, I couldn’t resist pointing out all the problems in the code on spotthevuln.com.  Of course, they said they’re not going to post any comments until Friday so there are no spoilers.  Which points out another vulnerability, as I’m about to spoil it.  Don’t continue if you want to try it yourself.

“OK, I can’t resist.

Mainly, this script is backwards – it cleans a few known dangerous characters rather than only allowing known good characters.  In fact, it still allows most ASCII characters including things that have special meanings to shell, etc., like !, *, etc.  It allows % so could do a format string attack on printf.  It allows url encoded characters other than \n and \r.  It allows ASCII / hex encoding so you could pass a control (^), ESC, etc.  It doesn’t prevent buffer overflows.

Also, it returns the original URL, which hasn’t been cleaned.  No point in trying to clean it then accessing the tainted variable later.  Dump it.

Finally, it’s in PHP.  :-)”

</JC>

Attacks on (my) anonymity

September 18, 2009

In case you haven’t realized, Johnny Cocaine is not my real name.  If I were using my father’s actual surname, it should be Johnny Drunk-Ass-Moron.  But I digress.  I do keep my real life identity a secret on the Interwebs, mostly because my day job could suffer otherwise.  Also, not everyone I know IRL would appreciate my attitude and crude vocabulary.  Not everyone online appreciates it either, but they can always choose to stop reading / watching / following.

Anyway, I don’t go to great lengths to disguise what I do in public (Twitter, this blog, YouTube, Myspace, etc.)  I don’t use military / intelligence grade tools or tactics.  But it got me wondering, if I weren’t me, and I wanted to find out who I really was, how would I go about it?

Well, there’s pics and videos of me, right?  So one way would me to wander around the U.S. and other countries looking for me.  It could work.  It occasionally works for those kids on the milk cartons, right?

OK, not likely.  Well, there are different possible classes of people who would look for me right?  Let’s start with the most impotent – another individual who uses the same sites as me.  Maybe I offended someone with my arrogant Twitter posts.  Now, there is no way that I can figure out to find out which IP a web site user was at retroactively, for another user.  Even if there was, I proxy my traffic through an unsuspecting domain name, as mentioned previously.  So let’s ignore that and look at the semantic layer.

Well, what info does the attacker have about me?  They have my blog posts, my tweets, everything on my myspace page, my videos, any comments that Google can come up with, maybe even captures of my IRC conversations.  Possibly, at some point, code snippets.

Maybe the first thing I’d do is write a tool to organize all of the data on a timeline.  Then I could see, for example, all of Johnny Cocaine’s activity for a given day or week.  This would immediately point out something: most of my activity is during the day in the Western Hemisphere. Perhaps even a certain time zone.  That either implies that A) I work a swing shift, B) am unemployed or C) have a job where I can do some things online.  Of course, blog posts, videos, etc., could have been prepared any time; only things like tweets and forum posts are likely to be done in real time.  (This blog post is being written late at night, but I probably won’t post it until tomorrow.)  I just said I have a job, so we can rule out B).  I called it a day job, but that’s a figure of speech.  I’d rule out college student because the posts are consistent, and rare on weekends; students’ schedules tend to be more sporadic.

One can assume from the technical content of my posts that I’m a fairly competent programmer or sys admin or computer engineer or architect of some kind.  This would give me access to a computer while I’m at work, and senior technical people rarely work swing shifts.  So we lean toward an actual 9-to-5 job.

Next thing I’d look for is location – references to places, events, sports teams, weather, etc.  Anyone reading my posts might conclude that I travel a fair amount, as I’ve mentioned being in several cities on both coasts of the U.S., as well as Mexico.  That could be true, or it could be bullshit that I put out there so this kind of analysis is harder.

I could look at any pics or videos I’ve posted.  Backgrounds might give some information.  (E.g., in one video we hear a “meow” and I refer to “my cat”.)  Meta data might also contain information, e.g., the EXIF data in my photo(s).  (A fake threat to bomb a school was “thwarted” in ’07 when members of 4chan found the perp’s father’s name in EXIF info – http://en.wikipedia.org/wiki/4chan.)

All of this needs shoved in to a database, tagged, dated, etc., so you can do queries and run possible scenarios.  But, unless I, as johnny, am very stupid, you probably won’t get anything too specific.  The next thing to do – and you’re not going to like this – is to start looking at who I’m friends with, who I follow on Twitter and who follows me, whose comments I respond to, etc.  If you’re lucky, you’ll find a conversation that sounds like I really know the person in question; now you can stat attacking their identity as well.  If it’s not obvious, you can start correlating a circle of people; if I’m friends with the same 4 or 5 people on several networks, it’s likely that the know me fairly well, maybe even IRL.

The ultimate tool would be to trick me in to visiting a web site that has dangerous javascript in it.  If you’re good, you can load it in to my browser and start watching everything I do.  I’ll probably slip up at some point and pass some real personal information.

Finally, you could start doing semantic analysis on what I say.  For example, references to certain bits of pop culture might reveal my age, specific technologies could narrow down my niche in the work world, certain phrases could be slang from different areas, etc.  You could take certain phrases, links I post, etc., and google them to find out if someone else posted them – especially around the same time.  I might have posted a link to twitter and then you find the same link posted around the same time on another web site, undera different name.  Once is probably coincidence, but a few times is, as they say, enemy action.

Frankly, on the technical level, that’s about as far as you can go.  (Anyone have any more ideas?)

A web site I frequent, especially a big one like Myspace, would have better information; in addition to all of that, they could look at my IP, to try to defeat my obfuscation.  They could look at how often I log in, stay on, etc., and log every transaction I make.  Maybe the tone of one private message indicates I know that person IRL, or we share an in joke about something?

Then of course, there are ISPs.  My last hop provider can’t do much; my traffic is encrypted to a proxy and I transfered the key out-of-band to defeat the attack I talked about before.  I also connect from a lot of different places.  But given that most Internet traffic flows over one of only a few networks, at least in the U.S., we  can assume that any one of them can apture a fair amount of my traffic and correlate it across their network.  E.g., my local connection, my proxy server, and myspace’s data center may all get internet service from AT&T.

Finally, of course, there’s the FBI, NSA, CIA and anyone who has moles in those organizations.  One can assume they are building data warehouses full of every damn bit that flows across the Internet.  I’m not intending to defeat that kind of surveillance.  Oh, I could.  Maybe I do, for some activities.  But I don’t think they care that I make smart ass comments and talk about computer security issues.  They don’t have time to arrest every arrogant geek!  Plus, they’re run by people who still think that a Muslim in Iraq with a grenade is a bigger threat than a hacker with a budget.  Sigh.

OK, I have shown you the way.  First person to uncover my identity will suffer the death of a thousand (cyber) cuts.

Public key crypto = fail?

September 10, 2009

I’ve been experimenting with SSLstripper the last few days.  I highly recommend playing with it; even if you have no need to actually use it, you’ll learn a lot about SSL, https, and general security failures.

But beyond the actual tool, which can intercept and “decrypt” a lot of – but not all – existing SSL connections with little chance of being noticed, it got me thinking about the process in general.  We, and the Internet, absolutely depend on SSL to protect our passwords, financial records, etc.  One could say truthfully that eCommerce would have never taken off without it.  But there is a fundamental problem with using public key crypto in this manner.  Cryptographers have known this forever, but it’s been blown off because intercepting traffic was hard.  Now, with the proliferation of WiFi and laptops, it’s much easier to snoop on people’s traffic.

The problem is this:  If you can intercept all traffic coming from the client, you can *always* find a way to fool them in to sending you their supposedly-encrypted data in a format you can read.  SSLstripper does this by intercepting the original http request, establishing its own SSL session to the server for that request, then decrypting every response and passing it on to the client.  I don’t think this will work if someone types in https:// to start with (as opposed to clicking a link or getting a redirect from a page you’ve also intercepted) – although I have yet to try it.  But even if it does, there is another way.

You’re already proxying all their traffic (using arp spoofing, probably).  So you can intercept the initial setup of the SSL connection.  You could trick SSL in to thinking they are connecting to the server that matches the certificate… but even easier, you could just proxy their DNS traffic and create fake values that match the site they’re trying to go to.

This is not a revolutionary idea, but what it points out is that the assumption of public key crypto was always that you could disseminate the public key in a secure manner.  It doesn’t have to be confidential, but it does have to maintain its integrity.  As long as you are relying on the same network that you use to access the encrypted resource to validate the public key, you’re screwed.

PGP users have long faced this problem – it’s why people don’t use encrypted email much.  But thanks to a huge campaign by eCommerce sites 10 years ago, consumers – even security experts – tend to trust SSL.  As we move more and more from wired networks run by big telcos to wireless / WiMax / cell / mesh networks, we’re going to have to start assuming that any hop in the network may be hostile.

Anonymity vs. Speed

September 2, 2009

Anyone who wants to be really anonymous on the net either uses Tor or goes to a different open wireless hot spot every day.  I wanted to prevent the (other) bad guys from being able to easily track me back to my home PC.  But, so far at least, I don’t have the need for military grade protection.  Tor is great (yes, it has its limits, get over it) and that new darknet-over-http shows promise.  But Tor is sloooow for web browsing – in fact, I saw a talk at DefCon by one of its developers bout what they’re doing to fix it.

In the meantime, I decided to set up my own little quasi-anonymous system that would allow me to use the Web at reasonable speeds while still obfuscating where I’m coming from.  I know there are security issues with it – and there are probably more that I haven’t thought of – but it matches the risk, which is the decidign factor for security systems.  (Or should be!)

So I have root access on a server that, ahem, doesn’t have any paper trail to me.  You could do this all as non-root but root’s a plus.  C’mon, people, there’s a brand spanking new local exploit out there, get yourselves root on a linux box.  Anyway.  I set it up as a Tor node, and an exit node.  Then I set up a separate, simple web proxy (tinyproxy).  With some modification, my traffic proxied through tinyproxy is indistinguishable from traffic coming out of a Tor exit node – which the machines is registered as.  (Basically removing the Via http header.)  That gave me quick access, and my source IP shows as some domain no one’s ever heard of, in a location far from me.  To further obfuscate it, I set up webinject to quasi-randomly request various web pages, even as far as creating fake accounts and logging in to them.  This is to emulate Tor traffic; plus there’s the actual Tor traffic of course.  So basically if anyone tracks back my source IP, it will look like it’s exiting the Tor network – but it’s faster and won’t be blocked by sites like Google that blacklist Tor and open proxies.  Of course, with statistical analysis, the sites I use a lot could see that that one Tor node is the source of my traffic much more often than it should be, but I doubt anyone will care that much.

Finally, I created an ssh tunnel from my desktop to the server and redirected a port on localhost to the proxy.  That way my ISP (and by extension, the NSA and FBI) can’t snoop on my plaintext, but I don’t have to deal with certificate issues.

Now, this won’t defeat any major intelligence agencies or, I hope, law enforcement groups.  Even a savvy network engineer could at least find my source IP and contact it’s owner to get logs of my incoming (ssh) traffic.  But I thought it was a swell little piece of work.  Email me if you want more details – johnnycocaine at gawab dot com.