Archive for the ‘Routing’ Category

XSS and geolocation fun

August 10th, 2010 Comments off
Reading Time: 2 minutes

I’m slowly getting time to digest  the goodies that came out of the recent BlackHat 2010 event.

There were a number of really interesting topics covered by awesome people like Jeremiah Grossman, Robert (RSNAKE) Hansen and of course the Hoff!

One of these was Sammy K – of MySpace worm fame –  who did a presentation called “How I met your Girlfriend” demonstrating a XSS exploit to work out where someone actually is using Google’s Location services.

If you don’t know what XSS (Cross Site Scripting) is:

From Wikipedia: Cross-site scripting holes are web application vulnerabilities that allow attackers to bypass client-side security mechanisms normally imposed on web content by modern browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.

The exploit is fairly simple. It runs an AJAX script, using an XSS exploit, to obtain the router’s MAC address and then funnels it off to Google’s Location service and gets back a set of coordinates. Once you have these you can see exactly where said person is.

He has a pretty decent, overview that is available on his site here, with functioning proof of concept code available here.

Whilst the exploit was only “tested” on a Verizon FiOS router, other routers susceptible to XSS attacks, like D-Link, Linksys, Belkin and of course CISCO, could also be exploited with a modified version.

Now if only this could be used for good and not evil. The number of times that some of my bigger customers had moved whole sites and not told people is verging on silly.

Other Links & Sources:
Sammy’s site:
XSS Cheatsheet:
Definition of XSS:

TRILL, what is it?

May 8th, 2010 Comments off
Reading Time: 2 minutes

This is a half baked post today, but it is an attempt to get back into the swing of things.

One of the things on the “lists of posts to finish” is one on the emerging Data Centre technologies and the benefits that they they offer, or could offer, to the network Architect and Engineer. There have been some great articles written lately covering off NIV, FCoE and the odd article, and I do mean odd, about the wonders of RDMA over Converged Ethernet. One of the things I wanted to write about was TRILL. In a nutshell, TRILL is a L2 path selection algorithm (link state) designed to replace our good friend spanning tree.

Rather then bore you with my version of how it works and the benefits of TRILL to today’s design issues, have a look at the awesome write up done by @bradhedlund over at Cisco.

I’m still trying to find some time to get the back log of posts out of my head an onto paper/or here.

LISP – A solution for the Internet

December 22nd, 2009 Comments off
Reading Time: 6 minutes

Digging through a bunch of half written posts and I found this one I started on LISP about the time Draft v4 came out. I’ve been watching its slow development over the last year and a bit and thought I’d take a stab at what a possible cloud, and cloud computing, application would be.

Keeping in mind that it is a draft standard, and I am working with a limited understanding based on the draft document (to be honest I fall asleep every second paragraph reading this thing each time a new draft is released), and I thought I’d jot down a couple of possible and extrapolated scenarios.

What is it?

Locator/ID separator protocol. (LISP) is a draft protocol that proposes the separation of the an internet facing host address from that of the internet routable address. Edge routers translate and then encapsulate/de-encapsulate packets from their source end-point IDs (EID) to their location (RLOC).

What does all that mean? It simply means that that internet facing routers encapsulate, or tunnel, traffic between each other dynamically (they are able to look up the EID:RLOC mapping and do not require static tunnels/mappings).

This is an overly simplistic overview, however, detailed information on the function of the protocol is available in the draft proposal.

LISP was was created to address a number of things:

  • Improve multi-homing (for both service providers and end users);
    • through allowing the control of ingress traffic, something that cannot be cleanly done today with BGP,
  • allow for provider independent addressing;
  • reduce core routing table.

LISP does this, and more, by allowing end devices to be addressed, as chosen by the administrator, and only border/edge internet routers (Egress Tunnel Router – ETR or Ingress Tunnel Router ITR) need the ability to map or translate the Route Location (RLOC) to the End point ID (EID).

Read more…