[SecurityRatty] tag: dual-use

[OT rant] Are there any home WiFi routers that DON'T SUCK?

Fri, 22 Aug 2008 20:12:38 +0000

Warning: rant ahead, and names named.

When I'm not traveling, I like to work from home some days rather than endure the trek from Seattle to Redmond (although it's much better now that our own employee transit service has expanded into my neighborhood -- the existence of which is sad commentary on the availability and reliability of Seattle's public transit companies).

This means, of course, that I need fast and stable network connections. Comcast with their PowerBoost is working very well for me. But I just can't find a decent wireless router at all. My Lenovo T61p (with Intel 4965abgn adapter) just won't stay connected to my D-Link DIR-628 and IT'S DRIVING ME CRAZY! (Yes, I've tried various driver versions, from both Lenovo and Intel.)

My house is in an area with a lot of wireless activity -- sometimes I can see nine or ten SSIDs. I'm running draft N on 2.4GHz (which occupies two non-adjacent channels, currently 1 and 4), and I suspect the problem is collision interference. I could shift the router to 5.2GHz, which I probably would help, but then the rest of the computers in my house won't connect. Why, you ask? Well get this: the DIR-628 is part of D-Link's RangeBooster N family. So I stayed in the family and got two DWA-542 adapters for the desktop computers. Yet they only do 2.4GHz! Silly me, I assumed that being in the same family means full support of the router's capabilities.

I'm very tempted to replace my router again -- and I'm thinking that the best option is to get one with dual radios. That way I can move my T61p to 5.2GHz and replace the desktop adapters, while still having single-channel 802.11b/g on 2.4GHz for the Wii and my PlayStation Portable.

Now my request: tell me about your experience with home routers. What do you really like, and why? What should I buy?

Metrics for security and performance in low-latency anonymity systems

Mon, 21 Jul 2008 04:16:12 +0000

In Tor, and in other similar anonymity systems, clients choose a random sequence of computers (nodes) to route their connections through. The intention is that, unless someone is watching the whole network at the same time, the tracks of each user’s communication will become hidden amongst that of others. Exactly how a client chooses nodes varies between system to system, and is important for security.

If someone is simultaneously watching a user’s traffic as it enters and leaves the network, it is possible to de-anonymise the communication. This could occur if the first and last node for a connection is controlled by the same person. Tor takes some steps to avoid this possibility e.g. no two computers on the same /16 network may be chosen for each connection. However, someone with access to several networks could circumvent this measure.

Not only is route selection critical for security, but it’s also a significant performance factor. Tor nodes vary dramatically in their capacity, mainly due to their network connections. If all nodes were chosen with equal likelihood, the slower ones would cripple the network. This is why Tor weights the selection probability for a node proportional to its contribution to the network bandwidth.

Because of the dual importance of route selection, there are a number of proposals which offer an alternative to Tor’s bandwidth-weighted algorithm. Later this week at PETS I’ll be presenting my paper, co-authored with Robert N.M. Watson, “Metrics for security and performance in low-latency anonymity systems”. In this paper, we examine several route selection algorithms and evaluate their security and performance.

Intuitively, a route selection algorithm which weights all nodes equally appears the most secure because an attacker can’t make their node count any more than the others. This has been formalized by two measures: Gini coefficient and entropy. In fact the reality is more complex — uniform node selection resists attackers with lots of bandwidth, whereas bandwidth-weighting is better against attackers with lots of nodes.

Our paper explores the probability of path compromise of different route selection algorithms, when under attack by a range of different adversaries. We find that none of the proposals are optimal against all adversaries, and so summarizing effective security in terms of a single figure is not feasible. We also model the performance of the schemes and show that bandwidth-weighting offers both low latency and high resistance to attack by bandwidth-constrained adversaries.

.. and now - PIN stealing..

Thu, 19 Jun 2008 06:38:00 +0000

Once the bad guys figured out how easy it was to sniff unencrypted ATM and card authorization traffic to steal track data, and after making a killing with stolen card numbers, they began setting their sights on bank PINs. PIN numbers - thanks to ANSI's TG3 - are encrypted with a half decent algorithm (and they are looking to strengthen that even more now). Which means that sniffing the traffic will only give you an encrypted number - something which would require a decryption key. A number of security controls like requiring dual control and split knowledge for key components, strict physical security requirements and Tamper Resistant Security Modules help in securing the keys. Assuming one cannot gain access to the encryption keys, this leaves only two scenarios for an attacker to gain access to the unencrypted PINs:
1. Before the PIN is encrypted by the Tamper Resistant Security Module (an ATM in the case of bank customers). Most criminals have been using fake PIN PADs and a number of techniques like jamming cards etc steal PINs blissfully unaware that they are on camera most of the time. Nice video ? here.

2. After the PIN reaches the issuer and is decrypted. This is the scarier situation -as the attacker would have access to a database of unencrypted PIN numbers / PIN offsets coming in from all around the globe. PCI supposedly requires that issuers be compliant and not store unencrypted PANs or PINs - but no validation is required (unless they are a VisaNet processor).

Well - Kevin Poulsen at Wired wrote today about how an alleged ATM crime spree has been blamed on a Citibank hack. Though Citibank has denied the hack as the cause of the fraudulent withdrawals - all signs seem to point towards it so far.
(This definitely is not new - While testing an issuer's security I'd stumbled upon ATM log entry files - complete with PAN, PIN, full name, address, zip code and atm location - back in the day when RFP just released whisker. )

This is probably just the beginning of a new wave. Issuers really need to pull up their socks and begin to treat cardmember data with the same respect that PCI Co is requiring merchants and processors to do. - and while I'm wishing horses - can ANSI or someone start working on some standards for requiring all track data to be encrypted in transit?

Sprint's Public Safety Deal for Nextel Comes Home to Roost

Mon, 05 May 2008 10:25:10 +0000

Sprint seemed awfully clever when it navigated a public safety deal and gained new spectrum as part of its acquisition of Nextel: That's all unraveling now. The FCC and the courts are saying that a 26-June-2008 deadline for vacating its 800 MHz holdings in favor of public safety groups would hold even if the new users weren't on the band. The delays for new users getting on the band are reportedly Sprint's, given that it had the responsibility for this migration.

Nextel had splintered holdings in the 800 MHz band that were difficult to administer, and caused verifiable interference with (and vice versa) splintered public safety spectrum in that band. Sprint agreed to pay the estimated multi-billion-dollar cost of getting new equipment to public safety agencies in exchange for a hunk of spectrum that they wouldn't have to buy at auction from the FCC. The cost for a whole set of swaps, migrations, and givebacks was $4.8b, but there was technically no limit on how much Sprint would have to pay for public safety migration--as much as it cost is the true limit.

Last August, the Wall Street Journal did a lengthy update of the 2005 deal, explaining that the effort was vastly behind schedule, and was vastly underbudgeted, too. One county in Pennsylvania estimated that its costs could run $18.5m to $150m, with the low number far above Sprint's own estimates.

It would be seemingly unfair to allow Sprint's delays in moving fire, police, and first responders off the band to also delay Sprint's requirement in vacating the band. We'll see how the FCC chooses to respond. It could cost Sprint billions and further accelerate the loss of Nextel customers, because Sprint would lose a number of active iDEN sites.

They have no one to blame but themselves. Sprint's management has blundered through this merger for years. They kept separate Kansas and Virginia headquarters, failed to produce high-quality dual-network devices, gave few incentives for Nextel customers to move to Sprint's dominant CDMA network, bled employees, and botched this migration.

Now Sprint did have the problem of needing to help move incumbents in the 1.9 GHz spectrum it received and the 800 MHz spectrum it was giving up. The articles on this court decision don't note whether Sprint's 1.9 GHz network is free and clear, nor whether Sprint had been working for the last three years to get its Nextel users to get dual-band handsets that would work with the new frequency.

With the WiMax plan also on the table, Sprint was basically committed to building or rebuilding and supporting four network architectures: CDMA (for 2G), EVDO (for 3G), WiMax (for 4G), and iDEN (for 2G).

Sprint is in the position where it may variously be sold (to Deutsche Telekom to merge with its T-Mobile USA division, which would add both GSM and UMTS/HSPA to the mix!), sell off its Nextel division (to a public safety venture headed by Cyren Call), and/or spin off its WiMax division or form a broad venture with Clearwire to build and market it.

ATM Communication - How Secure ?

Fri, 21 Mar 2008 09:34:00 +0000

A while ago, I attended a class on PIN and Key Management for Payment Networks. ANSI has laid out strict guidelines (in their ANSI X9 TG-3 standards checklist, ANSI documents X9.8 and X9.24) for how a customer's PIN should be kept secure: how they should be stored on the card (store only the difference/offset of the encrypted PIN value and the natural PIN), what the minimum encryption requirements are (Triple DES), what the specifications of the devices that encrypt/decrypt the PIN are (Tamper Resistant Security Modules), how PINs should be exchanged between various Financial Institutions (exchange keys between two FIs out-of-band AND under the principles of dual control and then encrypt the keys, how should compromised - no - even "suspect" compromised PINs and Keys that encrypt the PINs be treated (securely delete the key, recreate a new key under the principles of dual control and split knowledge and re-encrypt *every* key or PIN that has been encrypted under it! and re-issue cards containing PIN offsets for PINs encrypted under the new encryption key, if applicable) etc.

It was simply awesome. To know that the Financial Institutions do their due diligence is a huge confidence booster. The fact that these guidelines are just that - guidelines, and haven't been strictly enforced by governing bodies is not my biggest concern. Neither is the fact that there are a number of papers out there that talk about the insecurities in PIN translation.

The following, however, is:

The folks at redspin (Brian Hayes, Matt Marshall) analysed ATM traffic and wrote a paper on insecurities in ATM communications.

What you see above is the raw data message format that leaves the atm connected to a network. Cleartext communication. Notice the account number and expiration date. Totally vulnerable to man-in-the-middle attacks. The response message that is supposed to come from the FI, looks something like this:

I'm not going to say what one needs to do at this point. Read up message format ISO 8583. It is scary.

Norton AntiVirus Dual Protection for Mac debuts

Tue, 11 Mar 2008 07:24:08 +0000

Symantec has released Norton AntiVirus Dual Protection for Mac, intended for users of Intel-based Macs who have both Mac OS X and Windows running on their computers.

Norton AntiVirus Dual Protection for Mac debuts

Sun, 09 Mar 2008 21:00:00 +0000

Symantec on Monday introduced Norton AntiVirus Dual Protection for Mac. It costs $69.95 (that price includes a one-year subscription for virus updates).

Dense Computing = Less Security

Tue, 12 Feb 2008 00:56:57 +0000

In case you all haven't noticed, there is a trend taking place that is all about building "GREEN" and "VIRTUAL" data centers which take advantage of dense computing architectures.

This trend is taking off for a number of reasons:

Multi-Core processing = More processing power for more applications on a single server
Blade Server = More servers with more processors in a smaller amount of rack space
Virtualization = More operating systems in a physical server.

Multi-Core + Blade Server + Virtualization = Green, less cost, easier managed, less space, less cooling, less power, etc. etc. etc.

I think we all get it! It has lots of advantages!

BUT... What we have created is "Dense Computing" which is putting a lot of security eggs into one basket. Imagine having a Blade Server with 12 blades in it, each blade having 8 CPU cores fitting into about 15U of rack space. You now have 96 CPU's to drive your operating systems and applications. Wow! In the old days that would have been a mainframe of sorts or some Cray Super Computer! Or in more recent times that would have been 96 rack mountable servers in your data center.

Now, take this one blade server and replicate it until you fill up a rack and replicate it some more until you fill up a row in a data center.

Now you have lots of "Virtual Servers" and "Virtual Desktops" running in a very very small piece of real estate. This is great news! All delivered by the power of multi-core processing technology, blade based computing technology and virtualization technology. Once again; Mutli-Core + Blade Computing + Virtualization = Green, less power, less rack space and uhhh..... LESS SECURE!

Why is this less secure? Well in the past you had physical servers and in many cases you segmented off your data center by having physical firewalls between servers or server groups. If all of these servers are now running in a virtual environment you no longer have the ability to physically isolate these servers and the problem just got worse because you have more density of them in a place where you can't secure them.

If you think about the example of one blade server environment with 96 CPU cores and virtualization layered on top of it, you can easily see an environment where one could get 960 virtual servers in a single blade server with 12 blades of dual quad core processors. Wow! Thats 960 virtual machines with no isolation between each other. You could possibly get some isolation between the blades "IF" you turned on some ACL's in the "Integrated Blade Server Switch" but the traffic definitely isn't going to touch your physical NetScreen or Checkpoint firewall unless you start routing traffic out of the box and back in.

People are starting to talk about the security problems caused by virtualization but I thought I'd point out the fact that the problems gets even bigger when you virtualize on multi-core and blade server environments.

Think twice on your security design before you deploy! Ask your security vendors to support virtualization!
<---Click to view
Gartner has something called the Hype Cycle and I think this problem is more than "Hype" and is something that companies should take a serious look at right away. The good news is that awareness and education in the market is taking place on this topic as indicated in this Graph showing Gartner now tracking "virtual security partitions". Thanks Niel McDonald of Gartner for paying attention to this space!

Dense Computing = Less Security

Tue, 12 Feb 2008 00:56:57 +0000

In case you all haven't noticed, there is a trend taking place that is all about building "GREEN" and "VIRTUAL" data centers which take advantage of dense computing architectures.

This trend is taking off for a number of reasons:

Multi-Core + Blade Server + Virtualization = Green, less cost, easier managed, less space, less cooling, less power, etc. etc. etc.

I think we all get it! It has lots of advantages!

Now, take this one blade server and replicate it until you fill up a rack and replicate it some more until you fill up a row in a data center.

Every network has a firewall, shouldnt a virtual one have the same?

Sun, 10 Feb 2008 12:07:45 +0000

If you agree with the first part of the title to this blog, then logic would indicate that you agree with the second half of the title however the reality is that this isn't the practice that most companies are taking.

Why is this? I believe this is because history proves itself time and time again and in this case history has proven that we are quick to take advantage of things that are cheaper and make our lives easier and put the "what if's" on hold.

We do this all the time in every day life. What if I die tomorrow? Well, I'll wait and get life insurance later, I'm still young and healthy. What if someone breaks into my home, should I activate this burgler alarm system came with my new home? Nah, I'll wait till later, my neighborhood is pretty safe. Should I buy the car with the dual air bags? Nah, its useually just me driving in my car.

We tend to take the cheapest and easiest route and security is always difficult and sometimes costly. It's the path of least resistance and security takes work, constant work. Therefore we deploy virtual networks, know it needs to be secure but tell ourselves "we'll cross that bridge when we come to it". Can we truely cross that bridge when we come to it? By the time you come to it, your company is on the front page of the New York times indicating something like "TJ Max Just Hacked, Millions of Customer Credit Cards Stolen!". I would think someone lost their job on that one for not thinking about security enough earlier on in the process.

The other flawed logic I hear from talking to people is: My Virtual Environment is not in production yet so I'm ok. Well, shouldn't you safeguard your non production environment also? In most of the non production environments I've seen, customers are testing new software they are developing or something that is simulating what the production environment will look like. Doesn't that data need to be protected also? What if someone hacked into a lab environment and stole all of the source code for a new application your company was developing in the labs. Wouldnt it be a pain if someone hacked your lab and caused a situation where you had to spend weeks to rebuild it again?

Enough said.. I think you get the point....

So, what is it that needs to be secured anyway? What makes the virtual network a network that is unique and calls for even more security?

Well, the answer is simple. Its a network, therefore it needs to have firewalls but what makes it more insecure is because the Virtual Switches are not equivalent to physical switches. You can at least set up ACL's (Access Control Lists) on physical switches to isolate traffic but in the Virtual Switches you can not.
So without this ACL type of isolation you are even more insecure than your physical networks. No Firewalls and no ACL capable switches.

What needs to be secured is communication between the machines within the virtual network. Think about this for a moment: If I put High Security virtual machines on the same network as Low Security Machines, are'nt those High Security Servers now in a Low Security environment? Common sense answer right? Of course they are now in a Low Security Environment!! However, if you have isolation between those types of virtual machines, you've now isoloated, partitioned, segmented and split up your virtual network into High Security and Low Security segments.

Listen to the bellow DEFCON video, it will also give you some GREAT technical visibility into what's flawed with how people are going about virtual networks.

-JP