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.

Synergy

A cool, free tool that you may very well find amazingly useful.

It’s called Synergy and what Synergy does is allow you to share one keyboard and mouse across many computers. But it’s not just a software KVM, Synergy makes switching to and controlling other computers feel a bit like a single computer with dual screens. Let’s say I have a desktop and laptop computer. I can put my laptop next to my desktop’s monitor, configure Synergy on both machines, and then simply move my mouse off the left of my desktop’s monitor and magically the cursor appears on my laptop screen. I can now run whatever applications I want on my laptop, then simply move the mouse cursor off the right of the laptop screen and I’m back on my desktop.

This is not a remote desktop program like VNC. You do not see a mirror of the desktop on the remote system. Instead you are controlling the remote system directly. This means whatever system(s) you’re controlling with Synergy will (typically) need to be within sight.

I use Synergy in a laptop/desktop environment like the example given above. I already have two monitors plugged into my desktop. Now I have my laptop as well for a total of three screens. I can use the laptop to handle simple tasks that don’t require constant attention such as monitoring e-mail, server status, etc., while I use my desktop screens to work on my current project. I also intend to bring an old Macbook back to life and add it to my configuration. In this way I’ll be able to test page development on a Mac without having bother moving over to the tiny Macbook keyboard and oddly-sensitive touch pad. Rather, I can use the keyboard and mouse I’m already quite comfortable with.

Maybe that sounds a bit lazy, but it sounds damn cool to me. Perhaps I’ll find another laptop, maybe a netbook or two, and wind up with an array of 6 or 10 screens surrounding me in my cube, each doing… something (just looking cool I suspect).

So if you’ve got a laptop and a desktop or a couple of desktops (maybe a homebrew HTPC) I’d say give Synergy a go. It’s very cool.

One small note:

Synergy has no encryption or authentication mechanism. Don’t use this over the internet or even your home wireless network unless you take some extra precautions, such as using SSH tunneling to encrypt the connection for you.

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!

Contuing My Case For Designing Without Javascript (or Flash).

Last week we learned of an exploit in IE6 that allows the attacker to take control of your computer simply by having you browse to a web page and get IE to execute a bit of Javascript. Microsoft urged people to upgraded to IE8 ASAP. Well it looks like IE8 is vulnerable as well. Here are the gritty details.

Microsoft won’t have a patch ready until next week at the earliest. So for at least a few days your computer is seriously vulnerable if you’re browsing the internet with IE.

But there are temporary solutions. One is to enable Data Execution Prevent (DEP) in Vista/Windows 7 for IE. You need to do this manually, but it might save you. Except it might not, as some French researches (see first article I link to) claim to have a workaround to make the exploit work while DEP is enabled.

The only other solution? Disable Javascript in IE.

And the threat is serious enough that people (read IT admins on behalf of those under their care) may resort to this very solution.

Which means any and ever web site that employs Javascript as a key means to access content and navigate the web site will become empty pits of nothing. The sites won’t work, the users won’t be able to access them, and business it lost on both sides of the equation.

However, had one designed their web site in such a way as to NOT rely on Javascript for presenting/serving content to the user, one would not be in the business of losing business every time a new Javascript exploit comes out.

So use Flash, you say.

Well, Adobe has scripting problems of its own. In fact Adobe is recommending people disable Javascript in Acrobat Reader, just like Microsoft.

Certainly seems like we’re staring at a future where Javascript can not, and should not be relied upon to deliver your web site content.

But if you take me for a cynic, that’s okay, I’ve got some cool news for you. A programmer is implementing Flash using Javascript and SVG. This could mean your future web pages could create their own animations without the need of any third-party plugin like Flash. This is kinda cool!

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.