h1

Told ya so (probably not).

June 10, 2010

Somewhere, inside the bowels of ATT/Cingular/SBMS/Ameritech/C1, there’s a security guy saying “you shouldn’t have relied on user-agent!”.  That solitary voice probably remains ignored.  The iPad masses, now compromised, will cry in pain for a while.

I await comments and commiseration from old friends in that place.

h1

No comment on Lamo and Manning.

June 8, 2010

There’s so much to say, but so little knowledge to be gained.  All I can advise is not to use world readable fileshares, be they user directories or the standard corporate-style file-dump.  Just don’t.  You will always regret it.

h1

PGP *and* Verisign. That’s disturbing.

May 21, 2010

Nice.

Looks like that web of trust is closing tighter and tighter.  You may not have trusted Symantec farther than you could throw them, but now your browser does.

What a business…renting you prime numbers for $125/yr.  And you have to come up with the primes.  I wonder how the big SYMC will restructure them.

h1

Oracle is acting rationally.

March 23, 2010

In the last post, I described what Oracle was doing and has done in relation to support customers accessing documentation for products they don’t license.  I stand by my assertion that enforcing access control in this situation is fairly trivial.  However, for Oracle, spending anything on securing access is a waste of time and money.  Here are two reasons why:

  1. Oracle suffers no harm if an actual customer reads support documentation for other products.  They cannot stop Rimini Street from accessing these materials even with strong access control…the consultants will just have to spend slightly more effort to keep up-to-date on the documentation one product at a time rather than en masse.
  2. Oracle has a business driver to eliminate the competition that Rimini Street presents.  They are going to dedicate resources to achieve this through the courts and through their business practices regardless of what ends up being their trigger event.

In my searching, I’ve not found any cases where Oracle has actually sued an end-user customer for exceeding their authorization.  I suspect that if there was never a Rimini Street or a TomorrowNow, this access control issue would not see the light of day.  Given their stance on third parties providing support for Oracle products, they’ve already allocated the money and effort to fight the competition — spending money on securing the support docs is pointless.

h1

Access control in real life.

March 12, 2010

Rimini Street offers third-party support for Siebel, PeopleSoft, SAP, and JD Edwards software.

Oracle is suing them because they claim that Rimini is gaining access to support materials surreptitiously through Rimini clients’ online support credentials.  They sued SAP’s subsidiary TomorrowNow for the same thing in 2007.  In both cases Oracle uses the same language — that the target of the suit is involved in “[c]orporate theft on a grand scale”.

Here’s the meat from page 3 of the Rimini Street Complaint (Case 2:10-cv-106, US District Court Nevada):

Rimini Street typically logs on to Oracle’s password protected Technical Support websites using a customer credential, then downloads Software and Support Materials in excess of the customer’s authorization under its license agreement.  Sometimes Rimini Street will download hundreds or even thousands of Software and Support Materials at a time, relating to entire families of software (e.g., PeopleSoft, JDE, or Siebel) that the customer does not license and for which it has no use.

The same claim was made against SAP (March, 2007) in a San Francisco district court:

Instead, SAP employees using the log-in credentials of Oracle customers with expired or soon-to-expire support rights had, in a matter of a few days or less, accessed and copied thousands of individual Software and Support Materials.  For a significant number of these mass downloads, the users lacked any contractual right even to access, let alone copy, the Software and Support Materials.  The downloads spanned every library in the Customer Connection support website.

Rimini and TomorrowNow were using their customer’s access to download support materials from Oracle.  This is a common practice across the IT industry when consultants or contractors are supporting technology on behalf of a customer who purchased the technology.  Rimini, in the complaint, appears to have leveraged that access to download everything that the customer’s ID can touch — and customer support IDs could touch everything.  In both cases, Oracle’s complaint hinges on the claim that the agent for the customer violated authorization that has no corresponding technological control in place.  The suit against SAP/TomorrowNow was settled, and TomorrowNow no longer exists.  Given Oracle’s previous victory, a similar end is possible for Rimini.

Oracle is either trying to solve an access control deficiency through litigation, or are leaving their access control open to enable litigation.  They are clearly placing the burden of determining what a customer is licensed to download on the customer themselves.

A competent sysadmin for their support site could at the very least lock down access to materials by product in a matter of weeks, even in a dysfunctional bureaucratic environment.  The fact that they are leaving a known access control deficiency open for over three years does not imply good faith in protecting support materials on the part of Oracle.

This raises an interesting question.  Should you use strong technological controls to enforce contractual authorization, making violations a criminal matter, or should you employ lax controls and pursue violations through civil litigation?

h1

Revisiting Python

March 10, 2010

Many years ago, I started trying to learn Python.  Within an hour, I switched to Ruby.  After two days of essentially rewriting Perl scripts in Ruby, I stuck with Perl.

That’s coming back to haunt me now.  The tools I need to use are all in Python.  Lucky for me, it’s never too late.

h1

Mifare 1K cards in.

March 6, 2010

I just got my new S50 1K cards in today.  They come individually wrapped and ready to go.

Here you can see the chip in the corner of the card.

A random sampling of the cards read fine in the Omnikey 5321.  They appear to have a default KeyA and KeyB of 0xFFFFFFFFFFFF.  I’m going to have to tweak some python I’ve been using (RFIDIOt) so I can write the data I want to the cards.  Hopefully it will all work as planned!

h1

Cards side-by-side

March 2, 2010

HID Prox, HID iClass, Indala ESP

From left to right, the cards are:

  • HID Prox card, clamshell form-factor
  • HID iClass card, ISO form-factor
  • Indala ESP card, clamshell form-factor

Notice the thickness of each card.  Those Indala cards were like bricks!

h1

HID Omnikey customer service proves me wrong.

March 2, 2010

After a day of back-and-forth over the weekend, HID reps in the UK and Austria were able to assure me that the OSX drivers for the Omnikey 5321 are supposed to enable the RFID functions on the reader.  Based on their insistence, I started troubleshooting and discovered that pcscd in OSX is flaky.  It cannot handle USB reconnects or machine suspends.  If you are careful to kill pcscd before connecting the reader or waking from suspend every time, it restarts, loads the driver, and works correctly.

Although their site says that contactless cards are not supported by the OSX driver, the latest one does in fact work the same as the Linux driver with the cards I have at my disposal.  Like the Linux driver, it still does not react to EMV tokens.  I can verify that it senses and IDs iClass cards just fine.

A sincere thank-you to Markus and Mike from HID, especially to Mike for getting back to me on a Sunday.

h1

The Omnikey 5321 USB

February 28, 2010

It’s been a fun time setting up my brand-new Omnikey 5321 USB smartcard/RFID reader.  I worked with one a year or so ago, and was duly impressed.  This new one is just as solid.  HID makes quality equipment, and has acquired companies that make quality equipment.

HID provides drivers for use under Windows, Linux, and Mac OS X.  The completeness of those drivers decreases in that order.  I acquired this reader to work with contactless smartcards, including Mifare and iClass cards.  The cards I have to test with at the moment are an ISO14443b card and an EMV (PayPass) token.  All of these operate on the 13.56Mhz ‘standard’ RFID frequency, but are not all equal in the eyes of the 5321.

I first borrowed a Windows laptop to make sure the reader worked.  HID provides a driver and a test application for Windows that I am familiar with.  Once it was set up and the USB driver changed to the HID factory driver, I tested the cards.  The 14443b card came up with the right Card ID and ATR.  The EMV token was detected as an ISO14443b device.  The Card ID and ATR looked right.  All is good on the Windows front.  Unfortunately, I don’t have a Windows machine of my own to do development on.  In each case, bringing the card near the reader resulted in the activity light flashing as the card was read.

My next adventure was to try out the OSX driver bundle.  Mac OS X uses pcscd to talk to smartcard readers.  HID provides a CCID-style driver bundle, currently version 1.0.0 released March 2009.  It loaded up fine, and detected the reader.  As promised by HID on their specifications page, the OSX driver does not work with contactless cards.  In fact, the reader does not respond at all when cards are brought near it … the activity light does not flash.

Finally, I loaded up the Linux driver bundle, version 2.7.0 from February 2010.  I was fortunate to have read up on installing pcsc-lite ahead of time, which kept me out of trouble by instructing me to configure with –enable-libusb and –disable-libhal.  After installing the driver and loading up pcscd, the reader was correctly identified.  The 14443b card was read without any problem.  The Card ID and ATR were both as expected.  However, the EMV token was not read at all.  Just like with the OSX driver, the activity light didn’t flash when it was brought near.

It’s clear that the Windows drivers allow the reader to use all of its capabilities.  The Linux driver fails to read at least one type of RFID token.  The HID-provided OSX driver is nearly useless — the stock PCSC-Lite CCID drivers provide the same functionality in the 5×21 series of readers.

I’m hoping that the Linux drivers will work with the Mifare and iClass cards that are on their way.  If not, I’m going to have to get a Windows machine working.  That would be a shame.