Security

ClickJacking Your Way Into Office

Joe Pruitt — Mon, 20 Oct 2008 16:58:40 GMT

I recently blogged about a new type of browser vulnerability called ClickJacking aimed at tricking you into clicking on something you weren't aware you were clicking on. The idea is that the bad guy hides a button by making it invisible and then "moves" it under you mouse right before you click thus causing you to either submit information, download something harmful, or start a process on your computer such as a webcam. Luckily there is a FireFox plugin to help protect you from those bad guys.

But what happens when the bad guys move away from the browser and into the polling booths? As far as I know this hasn't happened yet but according to a team from Rice University, ClickJacking your way into office is entirely possible.

The team of hackers from Rice University conducted a exercise to test the security of touch screen voting machines. They created an invisible touch-screen button that ensured that one contender would receive 90 percent of the vote.

As reported on MSNBC.com, Dan Wallach, an associate professor of computer science and director of Rice's Computer Security Lab, said his class's exercise reconfirmed his believe that anyone with a little know-how and the right access could easily do considerable damage. Despite the classroom setting, students said the vote tampering was eye-opening not only because of how straightforward it was to cause damage, but also because of how easy it was to get away with it — despite the scrutiny of other classmates primed to look for mischief.

At least my vote will be safe. That is, unless they find a way to ClickJack my absentee ballot.

-Joe

Technorati Tags: F5, DevCentral, ClickJacking, Voting, Joe Pruitt

Protect Yourself From ClickJacking With FireFox And NoScript

Joe Pruitt — Fri, 10 Oct 2008 16:34:27 GMT

Worried about losing your personal information? Yep, me too! The updated FireFox plugin NoScript aims to thwart the recently discovered ClickJacking class of browser based security exploits.

Less than a month ago a new class of browser based security exploits were discovered that allows an attacker to get you to click on a button without your knowledge thus executing malicious code or inadvertently exposing personal information.

Robert Hansen of SecTheory LLC and Jeremiah Grossman of WhiteHat Security Inc coined the term "ClickJacking". From Jeremiah Grossman:

Think of any button on any Web site, internal or external, that you can get to appear between the browser walls. Wire transfers on banks, Digg buttons, CPC advertising banners, Netflix queue, etc. The list is virtually endless and these are relatively harmless examples. Next, consider that an attack can invisibly hover these buttons below the users' mouse, so that when they click on something they visually see, they actually are clicking on something the attacker wants them to.

The recommended protection at this point is to use FireFox with the NoScript plugin that enables frame/plug-in blocking.

But, the latest version of NoScript goes one step further with a new feature called "ClearClick" specifically aimed at protecting users against ClickJacking attacks.

Rather than relying on frame/plug-in blocking, which were already available, I decided to move on and add a brand new feature, developed from scratch, for people who couldn't bear blocking frames outright, said Italian developer and security researcher Giorgio Maone in an interview on Computerworld.com.

In his blog, Maone spelled out what ClearClick does in greater detail:

Whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals to you the real thing in 'clear'. At that point, users can decide for themselves whether to continue clicking, or free up the mouse from underlying, and potentially exploitive, content.

So, don't wait, hop on over to the Mozilla AddIns site and protect yourself with NoScript.

As a side note, we had a great podcast a while ago with Jeremiah Grossman that you might want to check out!

-Joe

Technorati Tags: F5, DevCentral, ClickJacking, NoScript, FireFox, Robert Hansen, Jeremiah Grossman, Joe Pruitt

Google Chrome doesn't want you to visit google.com securely!

Joe Pruitt — Fri, 05 Sep 2008 15:49:52 GMT

I was playing around with Google Chrome the last few days and of course the first thing I did was login to my personal email account on Google Apps. Everything seemed to work great so I went ahead and visited a few other sites. Somewhere along the way I received an error page and clicked through it not thinking anything of it.

Yesterday on the DevCentral Podcast, Colin was talking about his recent tech tip on "Can iRules fix my cert mismatch errors?" and that reminded me of that error message. So I went back and checked it out and sure enough, it was a mismatch error. The image on the right is the security warning in Chrome and below is the same warning from FireFox 3. So I guess FireFox doesn't want you to visit google.com securely either? In fact, neither does Microsoft!

Want to try it out for yourself? Load up your browser and type in https://google.com. Not "www.google.com" but just "google.com" and make sure you put in "https" instead of "http".

As Google's own Chrome browser states:

You attempted to reach google.com, but instead you actually reached a server identifying itself as www.google.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of google.com. You should not proceed.

Google's own product is telling us that you should not proceed to google.com! What??? What the heck is going on? Is this a security issue? Has someone taken over Google's servers? Is this a fake version of Google that some hacker is trying to get me to visit? In this case, of course not, but it is an issue with the way they have configured their SSL certificates. I guess Google is assuming that their users will always type in "www." before "google.com" and didn't worry about testing the secure version of their site without the "www" prefix. Shame on you Mr. Network Guy in Google's Network group!

So what's going on? When you purchase a SSL certificate, the domain name of your site is included in the certificate along with other information such as your Organization name and other information that identifies the website that your certificate is securing. The information in Google's certificate is to the right. You'll see that the "Common Name (CN)" in this certificate is www.google.com. Google obviously has the same certificate protecting both www.google.com and plain old google.com. When you browse to the later, the browser sees that the Common Name in the certificate doesn't match the domain you are requesting. Security is important so an exact match is performed and if it's not the same, you get this standard security warning.

Looks like Google needs to pony up and spend the couple hundred bucks to buy a second certificate for those of us out here that like to save the wear-and-tear of our "w" keys.

Tsk, tsk, tsk... Rookie mistake Google!

-Joe

Technorati Tags: F5, DevCentral, Google, SSL, Certificates, Security, Chrome, Google Chrome, FireFox, Joe Pruitt

Stop Those XSS Cookie Bandits iRule Style

Joe Pruitt — Fri, 29 Aug 2008 22:18:07 GMT

In a recent post, CodingHorror blogged about a story of one of his friends attempts at writing his own HTML sanitizer for his website.

I won't bother repeating the details but it all boils down to the fact that his friend noticed users were logged into his website as him and hacking away with admin access. How did this happen? It turned out to be a Cross Site Scripting attack (XSS) that found it's way around his HTML sanitizing routines. A user posted some content that included mangled JavaScript that made an external reference including all history and cookies of the current users session to an alternate machine.

CodingHorror recommended adding the HttpOnly attribute to Set-Cookie response headers to help protect these cookies from being able to make their way out to remote machines. Per his blog post:

HttpOnly restricts all access to document.cookie in IE7, Firefox 3, and Opera 9.5 (unsure about Safari)
HttpOnly removes cookie information from the response headers in XMLHttpObject.getAllResponseHeaders() in IE7. It should do the same thing in Firefox, but it doesn't, because there's a bug.
XMLHttpObjects may only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies.

Whenever I hear about modifications made to backend servers, alarms start going off in my head and I get to thinking about how this can be accomplished on the network transparently. Well, if you happen to have a BIG-IP, then it's quite easy. A simple iRule can be constructed that will check all the response cookies and if they do not already have the HttpOnly attribute, then add it. I went one step further and added a check for the "Secure" attribute and added that one in as well for good measure.

when HTTP_RESPONSE {
  foreach cookie [HTTP::cookie names]
  {
    set value [HTTP::cookie value $cookie];
    if { "" != $value }
    {
      set testvalue [string tolower $value]
      set valuelen [string length $value]
      #log local0. "Cookie found: $cookie = $value";
      switch -glob $testvalue {
        "*;secure*" -
        "*; secure*" { }
        default { set value "$value; Secure"; }
      }
      switch -glob $testvalue {
        "*;httponly*" -
        "*; httponly*" { }
        default { set value "$value; HttpOnly"; }
      }
      if { [string length $value] > $valuelen} {
        #log local0. "Replacing cookie $cookie with $value"
        HTTP::cookie value $cookie "${value}"
      }
    }
  }
}

If you are only concerned with the Secure attribute, then you can always use the "HTTP::cookie secure" command but as far as I can tell it won't include the HttpOnly attribute.

So, if you determine that HttpOnly cookies are the way you want to go, you could manually configure these on all of your applications on your backend servers. Or... you could configure it in one place on the network. I think I prefer the second option.

-Joe

Technorati Tags: F5, DevCentral, XSS, Cookie, HttpOnly, CodingHorror, Joe Pruitt

Scaling Ruby on Rails to 1 Billion Page Views a Month

Joe Pruitt — Tue, 15 Jul 2008 17:41:57 GMT

A while ago I blogged about how F5 was making mongrels better with a Side of Mayo. I referenced a blog post on Joyent's wonderful Joyeur blog on why Joyent uses F5's BIG-IP for their customers. Well, those krazy kids at Joyent are at it again...

In a recent post, Joyent point out how LinkedIn, a customer of theirs, built a Facebook application called BumperSticker using Ruby On Rails. LinkedIn made use of Joyent's Accelerators and our very own BIG-IP to scale Ruby on Rails to some very significant numbers.

13.5 million installations
1.5 million daily active users
20-27 million canvas page views a day

All this is served by

13 web application servers running nginx and mongrel.
8 static asset servers serving over 3,500,000 stickers, soon to migrate to a CDN.
4 MySQL servers in a master/slave configuration using Rick Olson's excellent masochism plugin.

For those video inclined, Joyent has an added bonus: check out the video they put together on the subject.

So, as the Twitter's out there continue to have availability issues and the debate continues as to the scalability of Ruby on Rails, BIG-IP helps show that with a good design and infrastructure planning, big things are possible. Keep up the good work Joyent! Oh, and if you ever want to do a guest spot on the DevCentral Podcast, please let us know. Oh, and if you ever need a guest for your Quad Core podcast, let me know - I'd be glad to sit in!

Technorati Tags: F5, DevCentral, Joyent, Joyeur, LinkedIn, Ruby on Rails, Joe Pruitt

The Networking ABC's - X is for X-Forwarded-For

Joe Pruitt — Fri, 16 May 2008 16:39:57 GMT

Today's word in the Networking ABC's is the letter X. There really aren't that many words that start with X so my choices for today was limited. But, luckily for you all, there is one word that stands out as a necessity for application servers hosted behind HTTP proxies. The "X-Forwarded-For" HTTP header is used to allow a proxy server to inject the true originating IP address of a client connection into the HTTP request allowing the application server to know the callers true identity.

"X" is for X-Forwarded-For

X-Forwarded-For

Pronounced: Eks-Fôr'wərd-ed-Fawr

The X-Forwarded-For (XFF) HTTP header is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy. In this context, the caching servers are most often those of large ISPs who either encourage or force their users to use proxy servers for access to the Internet. Without the use of XFF, any connection through the proxy would reveal only the originating IP address of the proxy server, effectively turning the proxy server into an anonymizing service, thus making detection and prevention of abusive accesses significantly harder than if the originating IP address was available.

Technorati Tags: F5, DevCentral, Networking, Networking ABCs, ABCs, X-Forwarded-For, Joe Pruitt

The Networking ABC's - U is for URL

Joe Pruitt — Wed, 07 May 2008 15:51:03 GMT

Today's letter in the networking ABC's is the letter "U". UDP, UIE, and users are popular words for this letter, but I opted to a word that most folks use every day but don't necessarily know it. If you open a browser and connect to a website, you are making use of the word URL.

"U" is for URL

URL

Pronounced: yōō'är-ěl'

URL, or Uniform Resource Locator (or also known as Universal Resource Locator) is, in popular usage, a synonym for Uniform Resource Identifier (URI). A URL begins with a scheme name that defines it's namespace, purpose, and the syntax of the remaining part of the URL. Most web-enabled programs will try to dereference a URL according to the semantics of it's scheme. In it's current strict technical meaning, a URL is a URI that "in addition to identifying a resource, provides a means of locating the resource by describing it's primary access mechanism (ie, it's network location). An example of a URL is http://devcentral.f5.com/docs with "http" being the protocol, "DevCentral.f5.com" being the host that serves the resource, and "/docs" being the resource on the host.

Technorati Tags: F5, DevCentral, Networking ABCs, ABCs, URL, Joe Pruitt

The Networking ABC's - S is for SSL

Joe Pruitt — Fri, 02 May 2008 20:06:37 GMT

Today's letter in the Networking ABC's is the letter "S". For today's word I skipped SCTP, SNMP, self IPs, security, SIP, SNAT and spanning tree and opted for one that touches everyone who browses on the Internet. Today's word is SSL for Secure Sockets Layer) and forms the basis for encrypting Internet traffic.

"S" is for SSL

SSL

Pronounced: Es-Es-El

SSL (Secure Sockets Layer), and it's successor TLS (Transport Layer Security) are cryptographic protocols that provide secure communications on the Internet for such things as web browsing, email, instant messaging, and other types of data transfers. Developed by Netscape, SSL uses a cryptographic system with two keys to encrypt the data - a public key known to everyone and a private (or secret) key known only to the recipient of the data.

Technorati Tags: F5, DevCentral, Networking ABCs, ABCs, SSL, Joe Pruitt

The Networking ABC's - M is for Man in the Middle

Joe Pruitt — Tue, 22 Apr 2008 18:10:00 GMT

Today's letter of the day in the Networking ABC's is the letter "M". Unlike it's siblings MD5, MAC, and Monitor, today's word is actually a phrase that is important when privacy is concerned. Today's word(s) is(are) "Man in the Middle".

"M" is for Man in the Middle

Man in the Middle

Pronounced: Man-in-th-uh-mid-l

The man-in-the-middle attack (also known as a bucket-brigade attack and abbreviated MITM) is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. Possible defenses against MITM attacks use authentication techniques that are based on Public Key infrastructures, mutual authentication, secret keys, passwords, and other criteria such as voice recognition or other biometrics.

Technorati Tags: F5, DevCentral, Networking, ABCs, Networking ABCs, Man in the Middle, MITM, Joe Pruitt

The Networking ABC's - J is for Jabber

Joe Pruitt — Mon, 14 Apr 2008 16:32:27 GMT

Today's letter in the Networking ABC's is the letter "J". "J" was a tough one as there aren't that many networking specific terms specific to networking. I looked and looked and after catching up on twitter, I realized the app I'm using for twitter is using a "J" word under the seems. Google talk is an instant messaging client that has integration with twitter via the Jabber protocol. So, there it is: today's word is "Jabber". BTW, does anyone know why I used the shark?

"J" is for Jabber

Jabber

Pronounced: jab-er

Jabber is a broad term that refers to an open, secure technology for instant messaging services. It is an initiative to produce an open source, XML-based IM platform. Jabber operates differently than other proprietary IM systems and works in a fashion similar to e-mail using a distributed architecture. The popular Google Talk and Google Chat instant messaging products are built on top of the Jabber protocols.

Technorati Tags: F5, DevCentral, Networking, ABCs, Jabber, Jabber Jaws, Joe Pruitt