Hi, I'm Tod Beardsley. You might remember me from other blogs such as DVLabs and Plan B Security, but now I'm here in the StrikeCenter. It's a fun gig that's about as close to "R&D" as I've gotten -- so far, it's almost exactly half research, half development.
For me, most of the research part so far has been figuring out how Oracle authentication works. If you've ever looked at the Oracle dissector for Wireshark, you've noticed it's pretty sparse. Apparently there are about four people outside of Oracle who do any work at all on the wire protocol, and the guy who wrote a custom parser isn't saying much due to "security factors." This is not surprising, because Oracle's authentication sequence takes forever, with a bunch of pre-authenticated data flying around before access is granted. The sequence goes something like this:
(Client) "Hey Oracle, can I see your database?"
(Server) "What?"
"Your database. Give it to me."
"Oh, sure."
"Great. Here's some encrypted and encoded data."
"Cool, I have some too. Here you go."
"Oh, and I'm a Windows PC."
"I'm a Linux server! We have so much in common!"
"Hmmm."
"Yes...."
"Did you want my machine name? Or my process ID's?"
"Yes, that's what I was waiting for. Here's a session key."
"Oh, okay. I'll use that to encrypt my password. By the way, here's a bunch more info about me."
"Your password? Oh yeah, I haven't authenticated you yet. Just a second."
...and so on.
Now, why there's so much traffic between an unauthenticated client and a expensive enterprise-class server is beyond me; Microsoft SQL Server is a very normal and straight-forward exchange of "Access please, here's my username and password." "Sure thing buddy!" But what do I know, I've never written an unbreakable database server, so all this extra cruft must make it extra secure, somehow.