MasterCard Skimmed: Priceless
Posted by Kris Price | February 5, 2010 | No Comments
Seems my MasterCard was skimmed somewhere in my travels, winding up in the hands of some crook in the UK. What I found interesting was plotting the thief’s actions with it. Seems they bought some Jewellery (big ticket item) in Torquay, then went on a road trip to Wolverhampton, taking a shopping spree at Tesco’s, and buying lots of gas on the way. $5,305.49 all up.
View MasterCard Skimmed: Priceless in a larger map
If only there were some webcams with archives of these areas. Or the police photographed every vehicle license plate passing certain parts of the M5 as routine, could be quite easy to narrow down a list of suspect vehicles. This would be a fun database project: a system where the fraud investigator at my bank or the police could just punch in the times and locations of the events, and the computer could produce a list of vehicles that were in all of those areas at those times. A bit too 1984-esque though I suppose.
ASB Bank, compromised?
Posted by Kris Price | May 23, 2009 | No Comments
Since I got my domain name, back in 2000, I’ve been running an experiment on spam. Whenever asked for an email address, such as when signing up for a website, or making a paper application for bank account, I create and provide a unique alias for that website or company in question. It has been interesting to track where spam comes to. The most spammed address is the one I used for ICQ. There have been a few obvious cases where it appears dodgy websites have leaked the email address, but the first seriously concerning case has happened recently.
Back in April of this year I started to recieve spam to the unique email address I gave ASB Bank. What does this mean? Well the possibilities are:
- My computer or webserver was compromised, and my list of mail aliases escaped onto a spam list. But this doesn’t add up. I don’t seem to be compromised, and more tellingly there hasn’t been any other cases of this, which would be statistically strange given the list of aliases is very long.
- I somehow mucked up, and entered the same email address on a website that turned out to be dodgy. This doesn’t seem likely, because the email address is distinctly identifiable as intended for ASB Bank.
- I sent an email from that address to someone else, not at ASB Bank, where it escaped. But that one doesn’t add up either, because my records seem to show no outbound email from that address, and only a few legitimate inbound emails to it (the last in October 2008).
- An employee at ASB Bank has extracted the email addresses from their database and sold them. I hope this isn’t the case, but it always is a slim possibility.
- A computer at ASB Bank was compromised, and the email addresses were harvested that way.
This last one seems more likely.
VLAN attacks in TRILL
Posted by Kris Price | May 23, 2009 | No Comments
Without a proper understanding of TRILL’s behaviour an engineer introducing TRILL to a network may make it vulnerable to VLAN attacks.
Background
In 802.1Q networks VLANs provide isolation between different sets of end stations. An end station on one VLAN is unable to transmit a frame to an end station on another VLAN. In a VLAN attack this rule is broken by exploiting vulnerabilities in the bridge software or hardware. Over the years various such attacks have been discovered and resolved, and properly configured VLANs are now considered secure.
Today, the most important and widely used control when securing VLANs is the ability to constrain their topology. This is a well defined feature in the 802.1Q standard. A VLAN topology is constrained by configuring VLAN memberships on ports. A bridge only accepts a frame on a port when the frame’s VLAN tag matches the port’s VLAN memberships. Similarly, a bridge only transmits a frame on a port — such as in the case of a broadcast flood — when there is also a match.
Let’s consider the following simple example.
+----+ +----+ +----+ | B1 |--dot1Q--| B2 |--dot1Q--| B3 | +----+ +----+ +----+
There are three 802.1Q bridges. B1 is in an insecure location, such as a meeting room or wiring closet, where an attacker might gain physical access and compromise it. B2 and B3 are in a secure location, such as a server room, and have ports configured on VLAN 2 with servers attached. The administrator wants B1 to have access to VLAN 1, and to prevent a rogue B1 from being able to access the servers on VLAN 2. So on B2, he configures the port connected to B1 to only be a member of VLAN 1. Now, if an attacker compromises B1, he can configure VLAN 2 on the compromised bridge, but this access will not extend to the target servers. To do this the attacker would need to gain access to and compromise B2, which is considered to be in a secure location.
Enter TRILL
So how might TRILL make a network vulnerable? Essentially the problem is that TRILL bypasses the existing VLAN topology (or policy) of a network. When an Ethernet frame arrives at an RBridge it’s encapsulated with a TRILL header and an outer MAC header. But, importantly, the VLAN tag isn’t copied to the outer MAC header, and instead TRILL forwards the frame over a single common VLAN called the designated VLAN.
Going back to the example, if B1 and B3 are replaced with RBridges, one might naturally expect a TRILL VLAN to behave like an 802.1Q VLAN, so that VLAN 2 will still be constrained by the configuration on B2, but this is not the case. An attacker that compromised B1 could configure full access to any end station on VLAN 2 attached to B2 and B3. In fact, the attacker could configure full access to any VLAN which any other RBridge in the network can access. This is because B1 will encapsulate VLAN 2 frames from the attacker, forward them to B3, where they are decapsulated and forwarded appropriately. B2 is unable to recognise the encapsulated VLAN 2 frame so lets it pass.
Other scenarios in which TRILL may enable VLAN attacks may also exist. For example, consider the case where end stations exist on the designated VLAN. Can an end station then emulate or spoof an RBridge, and therefore gain access to the entire network? In some cases, yes.
Conclusion
TRILL has adopted the term VLAN, but what it calls a VLAN behaves differently from the 802.1Q definition of a VLAN. TRILL views a VLAN as a community, more like a BGP/MPLS IP VPN, and believes that all end stations in a VLAN should be able to reach each other. TRILL also takes the view that all RBridges in a network are at the same trust level. Again, this is similar to MPLS, and we see that no one ever puts an MPLS router in an insecure location for that reason. TRILL goes so far as to impose this view on existing 802.1Q networks when it is deployed incrementally.
So what could be done? Well, there are only two ways to properly fix this.
The first is for TRILL to copy the inner VLAN tag to the outer VLAN tag, so that a TRILL encapsulated frame could still only travel on the same links as before RBridges were deployed. As an advantage, the VLAN forwarding behaviour of RBridges and bridges remain similar.
The second is for TRILL to form regions of directly coupled RBridges, where TRILL is only done on RBridge-RBridge links. This would require making these TRILL regions appear to STP as though they are bridges through some clever processing of BPDUs, or making the TRILL regions transparently tunnel BPDUs. This would have the added benefit of being similar to existing systems, such as Multiple Spanning Tree, 802.1ad Provider Bridges, and VPLS.
It is likely that implementations of RBridges will allow administrative filtering of the inner VLAN, but this is not included in the specification and so may vary. (At a minimum I feel this filtering should be covered in the specification.) This will allow administrators, provided they understand TRILL properly and deploy RBridges in the right sequence, to mimic their existing policy.
It strikes me as strange that a protocol aimed at resolving many of the problems with bridges has chosen to create new, preventable problems. It has chosen to adopt existing terms but behave differently, and has opted for the best incremental optimisation outcome over respecting the existing security policy. I think it’s likely that we will see RBridges sold as drop-in replacements for bridges, and I remain concerned that in the early days, because of this, there will misunderstandings and problems.
Submission on the Broadband Investment Initiative
Posted by Kris Price | April 27, 2009 | No Comments
I haven’t been doing so well with the one post per week goal lately, but here is my submission on the Government’s Broadband Investment Initiative.
The proposal seems to believe that wholesale unbundled dark fibre is the best method to serve all customers, which is absolutely incorrect. The negative impacts identified in this submission are caused by this, and forcing LFCs to engineer the networks in such a way.
Unbundled dark fibre is only suitable for a small percentage of customers and is completely unsuitable for the remaining customers that make up the vast majority. It is important that this distinction is understood, and that the proposal targets the distinct needs of these two categories of customer.
The full 21 page submission is available in PDF format here.
Early history of the TRILL header
Posted by Kris Price | March 11, 2009 | No Comments
Stemming from my interest in why TRILL did not use MPLS, I have summarised the early history of the TRILL header. This can also be found in plain-text format here. There is still more to it, which I shall attempt to elaborate on later, but this covers the shift away from a MPLS.
An abridged history of the RBridge header
Written by Kris Price, 10 March 2009.
Note: Names and references have been excluded to prevent anyone being unwillingly associated with my interpretation of events. Naturally I have no visibility of meetings or private discussions. The details can be found by reading the TRILL mailing list archive of the period from October to December, 2006.
TRILL initially looked to use MPLS based encapsulation for RBridges, as described in draft-bryant-perlman-trill-pwe-encap-00. The approach created a global MPLS labelspace from which RBridges selected their nicknames. The MPLS header would only include egress RBridge, CoS, and TTL information. An RBridge would make additional forwarding decisions, for example to constrain delivery of a VLAN tagged frame to only those links on which that VLAN is active, by using the information in the encapsulated MAC header. This was a deviation from the general architecture of MPLS that such forwarding decisions are made at the edge by selecting the correct label switch path. The responsibility falling to the control-plane to set up the necessary label switched paths accordingly. Hence the amount of hardware re-use at the time may have been limited depending on whether this filtering became a strict requirement or an option that could be phased in as new hardware was developed. Because this type of filtering has unrelated benefits it may well find its way into many platforms anyway, and today some platforms may already have some of this capability for that reason.
A potential requirement for the inclusion of ingress RBridge information within the header was raised on the mailing list in October 2006. It was based on the need to possibly support 802.1au Congestion Notification, in which notifications must be returned to the end-station that sent the triggering frame. To do this, it was argued that an RBridge trying to send such a notification would need to know the ingress RBridge. It was suggested that the ingress RBridge could be identified by looking at the source MAC address in the encapsulated MAC header. One group felt it was inappropriate for a core RBridge to maintain all of the MAC reachability information, as would be required in order to do this lookup. Another group felt this was reasonable, as that is what core IEEE bridges to today. In the case where all of the MAC reachability information was not maintained, the approach of sending the notification over the multi-destination delivery tree (since it is then effectively an unknown destination frame) was rejected as having negative impacts.
Other fields were also proposed for inclusion in the header at this time, as described in draft-gai-perlman-trill-encap-00, but these were eventually ruled out, or incorporated in other ways. The resulting approach that was settled on was to include ingress and egress RBridge information. This was seen as more natural and flexible to future requirements. The option of continuing to use MPLS based encapsulation was raised, using a label stack, with the top label as per the original proposal, and the bottom label identifying the ingress RBridge. This appears to have received very little attention. I can only speculate that it was rejected out of a belief that MPLS based encapsulation brought little benefit, in which case a simplified 6-byte header versus an 8-byte header was more elegant.
The use of the encapsulation defined for 802.1ah Provider Backbone Bridges was raised at the IETF-67 meeting in November, 2006. At the time 802.1ah was on its way to becoming a standard, and the question was whether there were any synergies between it and RBridges that could be capitalised on. Subsequent discussions on the mailing list ultimately rejected the idea for a few reasons. There was a feeling that 802.1ah was targeted at the provider market and so unsuitable for the enterprise and data centre market, although it is unclear why this made it unsuitable. There was a larger concern that 802.1ah would require a partial move away from zero configuration, although this was never clearly detailed. The clearest arguments against the use of 802.1ah were the lack of a TTL in the header, and the lack of a next-hop address. It was suggested that a TTL could be accommodated in the header before the standard was finalised, but the lack of a next-hop address was unresolved. RBridges uses the outer MAC encapsulation to define the next-hop on each link, this allows load balancing to multiple next-hop RBridges across a shared link. It is unclear whether the benefits of this versus the benefits of a shared encapsulation were weighed.
When 802.1ah based encapsulation was proposed it was noted that by using a non-IEEE frame format TRILL would be assuming responsibility for implementing all of the features developed by IEEE.
Subsequent to this the header acquired the options fields to permit extensions, and it has resulted in the TRILL header seen today.
The end.
keep looking »
Latest: NZ FTTH Blog- Roads vs. FTTH 1 June 2009
- Point-to-point vs. PON 1 June 2009
- News Roundup 14 May 2009
- The Australian Estimate 14 May 2009
- HFC vs. PON 14 May 2009