The customer comes first at Oracle.

December 15, 2011

Even Oracle can screw up a PeopleSoft implementation.  If there was just a little more competition, say from a Tomorrow Now or a Rimini Street, would Oracle step up their game?


Blast from the past

September 1, 2011

Tomorrow Now less of a burden on SAP
What this means for Rimini Street, and the concept of entrapping your competitors for the purpose of civil litigation remains to be seen.  SAP already confessed liability, and this appears to  just mean less of a payout.

See also:  Oracle is Acting Rationally and Access Control in Real Life.


So when did RSA start shipping *your* replacement tokens?

June 7, 2011


It appears it was a seed compromise after all.  You need new tokens, and you need them months ago.  Cleartext token use is one way that someone could start gathering your tokens en masse.  An even scarier problem you are open to is a keylogger or other workstation compromise that has captured a token being used.

Pretend there was a keylogger trojan on one of your user’s workstations back in 2009.  Before it was removed/wiped/whatever, someone was able to capture a VPN login with username, tokencode, and PIN.  You know, “juser/908235123456”.  Oh, and for grins, the trojan also logged a decent timestamp:  “03/04/2009 17:34”.

Recovering the token based on this capture is a matter of grinding to find the appropriate seed.  The attacker just has to crank through each seed with nearby clock values (to account for drift), and id the seed that matches the tokencode generated…908235.  Now the attacker can simulate the correct token and pretend to be juser at will.

This breach not only put you in danger from the moment it happened (which is necessarily prior to when it was detected by RSA, which was before it  was reported by RSA…), it adds value to historical captures of SecurID authentications. Depending on when your tokens expire and how often you force PIN changes, that could be very, very bad.


Rogue CA risk.

March 30, 2011

What are you doing to mitigate the risk of untrustworthy certificate authorities?


RSA #3

March 20, 2011

Another “whoops, there go the seed files” scenario.  This one also works if for some reason you keep all your seed files lying around and someone snags them.

  • Get a good clock, as good a clock as your target has.  NTP makes this easy, of course.
  • Start running every token virtually, recording every token code that pops up.
  • Observe tokens being used.  Maybe you found a system using it to protect telnet or FTP.  Or, something else entirely.
  • Watch the logins.  If it’s a hard token, check to see where that code pops up.  Hopefully it won’t be way too fast or slow, so you’ll have a decent chance of catching it.  If it’s a soft token, you have a little brute forcing to do.

Moral of the story:  If seed records have been obtained, a compromised system or unprotected login method using SecurID can be the weakest link used to enumerate tokens.


RSA Schadenfreude #2

March 18, 2011

Here’s an interesting thought experiment for the vulnerability researchers out there.  Let’s say the signing key RSA uses for seed files has been compromised.

  • Can you “root” either the Authentication Manager or soft token by having someone load up a malformed seed file?
  • Can you “root” either the Authentication Manager or soft token by having someone load up a malformed, but properly signed seed file?

RSA Schadenfreude #1

March 18, 2011

I suspect that IF RSA’s database of seed, serial number, and customer assignation has been acquired, we will start seeing chunks of it for sale very soon.  There’s two scenarios I’m thinking of.

1.  The database was acquired specifically with the idea to sell the information.  It has a limited lifetime, and is particularly useful to potential buyers that possess other information they can use in conjunction with the db.  You’d need to make that money now before RSA replaces tokens, or comes up with a clever scheme to neutralize the threat.

2.  The database was acquired with the goal of compromising specific customers of RSA.  In that case, the same lifetime applies, but you will want a smokescreen to mask your attacks, and to potentially mask your intentions.

My friend Mike shared his ideas regarding one potential attack.  We agree that it’s nasty, but disagree (slightly) on a detail of how effective it could be made.  It *is* noisy, so a smokescreen would add beneficial confusion.

I really, really dislike soft tokens, but in this case I think that IF an attack compromised their token issue database, the length of time it will take to replace hard tokens will keep them exposed longer.

I wonder if RSA has anything interesting they can do with the way PINs are used to buy some time…if that’s what happened.


Wasn’t lies, it was just…

January 24, 2011

A friend recently posted about being stonewalled by vendors when asking them how they deal with employee turnover.  The odds are that you have procedures of your own to handle terminations and job changes.  It’s reasonable to hold vendors that run your infrastructure to a similar standard.  Read it for why.

When you outsource infrastructure administration, or when you end up hosting important data under outside control, you definitely want to set up the agreements so they follow your existing security policy.  An honest outsourcing vendor who wants your business is going to agree with some few exceptions where the two of you negotiate to a middle ground.

If you aren’t getting the right to inspect the systems (or portions thereof) moving, storing, and processing your data, there’s a chance that important security requirements you negotiated for, maybe even that you paid extra for, aren’t being met.  In fact, if you didn’t nail down the right to audit, you probably didn’t get security goals in the SLA to penalize incentivize the vendor.

I’ve had the pleasure of performing investigations on behalf of clients who entered into agreements with vendors that held all the cards.  Every single time, the vendor “had not been forthright about the security posture they claimed to hold”.  Each one was lying about their security situation, in significant ways that ranged from not patching when they said they patched to sharing infrastructure they claimed wasn’t shared.   It isn’t a large or scientific sample — there were already suspicions that led to my arrival on-scene.  Surprisingly, these weren’t small-time infrastructure outsourcers…these were the big names with the big price tags.

The moral of the story:  If they promise it to you, but won’t let you see it, smell it, or touch it…it probably doesn’t exist.  Honest vendors will be up-front about how they operate, explain the limits of how far they can conform to your policies and expectations, and most of all will want you to be able to check so there’s no ambiguity haunting anyone down the road.

Less-than-honest vendors will prevaricate, hide their operations, and when caught claim that they weren’t actually technically violating the contract, or trot out the old line that “everyone does it this way”.  They’ll pull an Elwood Blues on you.


It will come to an end.

January 12, 2011

Here’s a fun one: https://threatpost.com/en_us/blogs/infected-pc-compromises-pentagon-credit-union-011211

The days of you taking your company laptop home to do “whatever”, or browsing the internet at large from work are going to come to an end.  It’s going to come to an end soon because the costs of “blocking everything bad” overtook “only allow what is known to be good” a long time ago.  Those deferred costs (breaches, theft, etc) are now being realized because Big Time Computer Crime is starting to mature.

Some organizations have done their best to aim for the “known good” solution, but they’re in the minority.  The challenge for everyone is accommodating the proven benefits of access to the internet while trying to protect data and systems from increasingly prolific and savvy opponents.

Yes, all of this was figured out in the 1960’s and 70’s.  Somewhere in between we lost it.  Technology’s progress during the passing decades makes it conceivable that we can unearth and reinvent those old solutions …  but make them easier to carry and faster.


Yes, those are four mistakes you will make in 2011

January 6, 2011

Recap: you will make mistakes.