Amazon Silk

Today Amazon.com launched three new versions of their Kindle e-reader including a color tablet called Kindle Fire. In terms of hardware it’s about what you’d expect to see from something competing with the Barnes & Noble NookColor that’s launched a year later; it’s slightly better, but nothing that stands out as revolutionary.

But included with the Fire is a new web browser called Amazon Silk. And Amazon would like you to know this is a new and different browser from anything you’ve seen before.

So what’s the big deal about Silk? All you web requests go through Amazon’s servers which will handle retrieving all the content for you and optimize it wherever possible (e.g. a 3mb jpeg that’s sized to 300×200 pixels will be resized by Amazon before being sent to you as a 50k jpg). Because Amazon’s servers are sitting on some of the fattest pipes on the interwebs, it’ll be able to pull down and deliver all this content to your Kindle significantly faster and more efficiently than if your browser was doing the work all by itself.

Sounds pretty nice, but I’m a bit of a pessimist.

I wonder if the image resize example given in the above video might have unexpected consequences. For example there may be web applications that purposely load a large image into your browser and allow you to zoom in and out and move around the image. Will Amazon’s services understand that scenario and know to not shrink the image? I can think of a few examples that use image clipping and revealing the full image when hovering over the clipped area using CSS. Will Amazon know that the clipped area is not the only part of the image being displayed? Perhaps only known situations are optimized rather than Amazon using software to guess.

My biggest worry, however, is that all your web browsing is now going through a third-party. If Amazon is making requests on your behalf it will need to preset session cookies to those sites your browsing. What happens when you need to log into a system over SSL? Does Silk make the HTTPS request through Amazon’s? Does that mean all your passwords will be, at some point, on Amazon’s servers? What happens if they’re ever compromised? Does Amazon log and can they track your browsing history? What happens when I try to go to Barnes & Noble to buy something online through Amazon’s servers? Some web sites use session-hijacking prevention by comparing looking at things like your IP address. Amazon’s servers, as they point out in the video, are all over the world. Will my IP address stay the same throughout a session or will it change as requests are routed through different Amazon servers? Some web applications might break because of that.

Amazon must be logging your browsing with Silk. Imagine a scenario where someone posts some illegal material through Amazon Silk. Authorities will track down the IP which will lead them back to Amazon. Amazon must then have some mechanism to identify the user who posted the illegal material otherwise Silk becomes a giant anonymous proxy machine.

I’m very wary of Amazon Silk. I do not think I would never use it unless forced into a situation where no alternative was available. I don’t want some third-party sitting between me and the web sites I interact with, watching and recording everything I do.

A bit of vinegar to go with the SOAP.

Not long ago I wrote a 3-part series on using SOAP over HTTPS with ColdFusion. My final solution was to create Java objects directly, bypassing ColdFusion’s CFHTTP tag.

I have since found a subtle flaw with this implementation.

It’s not in the code, but in the  JVM. ColdFusion 8 ships with an older JVM. I recently upgraded our JVM to a more current version in an attempt to resolve a timezone bug. In doing so my SOAP application stopped working.

A little research led me to this article about a TLS bug in Java that could lead to a man-in-the-middle exploit. It appears the way I’m performing my SOAP operation triggers a TLS/SSL renegotiation when it receives a response from the external server.

The short answer is to add the following line to ColdFusion’s JVM arguments:

-Dsun.security.ssl.allowUnsafeRenegotiation=true

This does resolve the problem, but it apparently leaves the JVM vulnerable to MITM attacks. There is another bit of code in that article which shows how to change the allowUnsafeRenegotiation flag on-the-fly. I added this to my ColdFusion code, but changing the flag didn’t appear to have any effect.

If anyone else has played around with this particular problem I’d love to hear about it.

For now I”ve left the JVM in its vulnerable state as we only make HTTP requests from the JVM for a couple of applications and neither of them carry personally identifiable information.

Obfuscated Javascript Spam

Recently I’ve been receiving phishing-spam in the form of official-looking Amazon.com invoices. Curiosity got the better of me and I clicked on the phishing link. The page that came up was blank. A quick source view revealed a bunch of obfuscated javascript.

I wanted to see how it worked.

Here is a sample line of the code:

mGdujq[‘euvLaulm'[VvIf](/[muzLc]/g, EWgUi)] \
(ltY(mGdujq[[‘uhnKehsKcKaKpleo'[VvIf](/[oKhlE]/g, EWgUi)]](IuO)));

Now what’s going on here?

Well, plain as day in the source I see a couple very important lines that will help decode this. The lines are:

var EWgUi = ”;
var mGdujq = this;
var VvIf = ” + ‘replace’;

Armed with this information the line decodes easily before our eyes to

this[‘euvLaulm'[replace](/[muzLc]/g,”) \
(ltY(this[[‘uhnKehsKcKaKpleo'[replace](/[oKhlE]/g,”)]](IuO)));

What’s left to decode is the use of shorthand regular expressions. For example let’s look at this piece of code

‘euvLaulm'[replace](/[muzLc]/g,”)

‘euvLaulm’ is just a regular old string. You can call the string’s replace function in many different ways such as:

var str = ‘euvLaulm’; str.replace();
‘euvLaulm’.replace();
‘euvLaulm'[replace]();

The regex /[muzLc]/g simply matches any character within the square brackets. The full line of code calls for every match to be replaced with ” (an empty string) or in other words, to delete those characters from the string.

euvLaulm

The result is the string ‘eval’.

So the fully interpreted line of javascript reads as follows:

this[eval](ltY(this[[unescape]](IuO)));

Or in code more readable to my own eyes:

this.eval( ltY( this.unnescape( IuO )));

Strewn throughout the javascript are lots of variable declarations that create strings of seemingly random letters and numbers. Upon close inspection you might notice that there’s a pattern to the strings; they consist of alternating hex and non-hex characters. (A hex character or value is 0-9 and a-f).

Near the end of the code all these strings are concatenated and a series of replace operations are performed to replace all the non-hex characters with ‘%<hex character>’. The result is a string of URL escape sequences (a percent symbol followed by 2 hex characters). This string is stored in the variable IuO.

The URL escaped data is then unescaped to create an array of bytes (aka, a string, except the bytes aren’t all printable characters, so I can’t call it a string). This data is passed to the ltY function which performs a ( <byte> XOR 13 ) operation on each byte of data. The result is a string of HTML that creates a hidden iframe to some porn referral page and a META refresh that redirects the user to a male supplements web site after 4 seconds.

That was fun. A little sleuthing and puzzle solving. But what is there to take away from all this?

First was myself learning new ways to use and abuse javascript syntax such as ‘string'[function].

Also curious was the large amount of superfluous statements in the code. Variables would be created without initialization. They they’d be initialized to an empty string. Then they’d be set to their real value. Three statements to perform an operation that could be done in one. I imagine this, along with the use of random upper and lowercase letters used as variables AND data make the code more difficult to parse by hand (or by eye). But a few minutes and a bit of perseverance will overcome that. However that shows these types of scams are designed with the user who tries to perform a cursory inspection of the underlying code in mind.

The multiple decoding steps to arrive at the final “attack” HTML indicates to me the code is designed to circumvent string-comparison spam filters. That there was more than one decoding step and that there’s a bunch of extra, useless javascript (if/else blocks with one assignment to an unused variable) makes me wonder if this code was also created to circumvent spam filters that are javascript-aware. It’s working so far. My institution’s normally solid spam filtering software has let this one slip by twice in the last week.

And it’s nice to see what kinds of tricks spammers have up their sleeves.

Force Yourself To Keep It Secret

You should know by now that giving out your password is a bad thing. You should also know that system administrators would never ask you for your password as well. But perhaps you encounter occasions where you still give out your password, even though you know you’re not suppose to.

Here’s an idea for you.

Make your password something obscene, disgusting, or embarrassing. The idea is to make your password something you would never want to share under any circumstance. Then the next time you’re asked for your password you’ll be motivated to not give it away.

Interacting With SSL

Sometimes I find it useful to do a quick telnet session to port 80 of my web server and throw at it a few requests to see how it responds. However, how do you do this with an SSL connection? Obviously Telnet doesn’t do SSL, so is there something else that’s quick and dirty?

Why yes, there is!

I tend to keep a copy of OpenSSL installed on whatever machine I’m working. Usually it’s for the DLLs to let wget work with SSL connections or to split and splice SSL certs. But it turns out you can also use OpenSSL as a command-line client to open SSL connections to remove servers. It’s quite simple, just drop to a command line/terminal session and use the following command:

openssl s_client -host <server> -port 443

Now work the HTTP magic like you would were you using telnet. Let’s see that in action!

>openssl s_client -host www.microsoft.com -port 443

GET / HTTP/1.0
host: www.microsoft.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "xxxxxxxxxxxx"
Server: Microsoft-IIS/7.5
VTag: xxxxxxxxxx
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Mon, 25 Jan 2010 14:51:15 GMT
Connection: keep-alive
Content-Length: 1020

Cool stuff.

More exploits. Sun responds.

Intevydis blog has another exploit or two up today for Sun Java System Web Server.

Yesterday Sun posted an alert regarding the exploits and possible temporary solutions until a patch can be released.

Their solution is to disable WebDAV and all digest authentication.

But what if I use digest authentication? Do I really need to disable it? Possibly not. The HEAD, GET and POST methods do not seem to be affected by the overflow exploits. Therefore if I block all the other methods EXCEPT those three, I should still be able to do digest authentication. Only problem is knowing every other possible method available in Sun’s web server.

Well, maybe you don’t need to know them all. You might try this:

<If $method="(GET|POST|HEAD)"></If><Else>
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
</Else>

What this does is if the method being handled is GET, POST or HEAD then nothing happens here. But if it’s something else, it gets rejected with a “method not implemented (501)” error. I couldn’t find a logical not wildcard pattern operator in the administrator’s guide (“!=” is a numercial not and will not work on strings), which is why there’s an empty IF block. Hey, it works, and remember it’s only temporary.

So if your a SJSWS person, I hope this helps a little bit.

It makes me wonder if I should ditch SJSWS entirely.

A Third SJSWS Exploit Released This Week!

Intevydis blog has released yet another exploit for Sun Java System Web Server. This one attacks diguest authentication. “Well, I don’t use digest auth, so I’m safe, right?” Wrong! Any client can trigger digest auth handling even if the web site doesn’t require a password.

I know this, not because I am clever and well versed in SJSWS. I know this because I ran the code against a test server and successfully crashed it.

So then, you and I are vulnerable to this exploit.

However there is a workaround. One that we’ve already used to prevent the previous two exploits. It requires that you manually add a couple lines to every virtual server config file in your deployment.

That code is:

<If $method="PROPFIND" or $method="OPTIONS" or $method="PUT" or $method="DELETE" or $method="MOVE" or $method="MKDIR" or $method="RMDIR">
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
</If>

This disables all the methods you probably don’t really use. OPTIONS and PUT have already been used to exploit SJSWS. Why wait for another method to be exploited? Let’s disable them all. At least until Sun comes out with a patch.

I’d like to point out one thing. When I did crash my SJSWS test deployment, it came back up within 10-15 seconds. Sun’s watchdog process keeps tabs on your server process and, should it crash, immediately starts up another. That is really handy. Granted it’d be trivial to still execute a DoS against a vulnerable server (just send the malicious request every 30 seconds), but if someone’s just trying to muck around with your server, it won’t cause any lengthy amount of downtime.

Another SJSWS Exploit

Looks like the people behind Intevydis blog have revealed another Sun Java System Web Server exploit. This one attacks WebDAV. Not a problem for me as I have WebDAV disabled across all our web servers. However it will be a problem for people who rely on WebDAV. If I were in that position I would try to get away with disabling WebDAV until Sun releases a new patch. I don’t think disabling the OPTIONS method is possible; I believe it’s needed for WebDAV. So if you’re stuck in that situation, good luck!

Sun Java System Web Server Exploits

For the past couple weeks and at least a couple more, Intevydis blog is releasing a new, 0-day exploit every day. Today’s exploit is of particular concern for myself as it has to do with Sun Java System Web Server and I administer several servers that use SJSWS.

TRACE is used as a debugging command. The idea is you send an HTTP request using the TRACE method and the web server repeats back your entire request. Best practice is to disable this feature entirely on any production or internet-facing web server. The reason being that an attacker could potentially use TRACE to steal cookie and password information.

How?

Let’s say you log into Facebook. Someone gets your browser to run some Javascript from within the Facebook domain and send a TRACE request to the Facebook web site. The server would return the cookie information used to identify your session. An attacker could then replicate that cookie on their own computer and now have access to your Facebook account.

So if you’ve been paying attention to your web server’s security you’re probably already safe against this exploit, but if not you need to learn how to disable TRACE for your web server. That link is for SJSWS folks like myself, but there are instructions on the internet for many other servers like Apache. So hit up your nearest search engine and get your server protected.

Hypothetica

You’ve probably seen this popular feature on various search engines: As you enter your search criteria a drop-down list of suggestions appears. The way this works is that the page has a bit of javascript in it that makes AJAX calls back to the search server every time the text in the search box changes.

Now what about applying that to textarea fields such as those used to enter the body of your message on a forum? Only there’s no user-feedback. The characters you type are simply stored into the database along with your post. An admin could then replay your message entry, including the bits where you went back and deleted or corrected bits of your post before finally submitting it. Let’s say you make some comments or share some feelings that, before you hit the submit button, you think better of and delete. But they’re not deleted. Not anymore. They’ve been saved. Content you never intended to share is now in the wild.

What if we take this to its logical conclusion: a keylogger embedded in your web site. Maybe you start typing in the credentials for your e-mail account by accident, delete them, and type in your forum credentials before finally hitting submit. Or maybe you lose track of which window on your desktop has focus and you start to type your password for your e-mail account into a web page that doesn’t even have a single text input field?

And all of this would be sent in plaintext from your computer to the web server, allowing anyone inbetween to see this as well.

Is there a line here? Is it being crossed? Do you think it’d be okay to grab the data from, say, a person as they were creating their forum post, but maybe the wholesale keylogger is wrong? I wonder what the legal implications are here. Can you really have a reasonable expectation of privacy if you’re creating content that would be publicly available on the internet?

I would suspect infrequently visited sites wouldn’t get much out of such a system to begin with. But imagine a forum that might have 1,000+ users hitting the site weekly. I bet they’d get some “interesting” stuff every so often.

Which is why the paranoid among us will want to at least find a plug-in for their web browser to disable javascript on untrusted web sites, if not disabling it entirely.