Bit Twiddling with Ruby: PacketFu
Since I started here at BreakingPoint, I've become a huge fanboy of Ruby. The Application Simulators I write are about 90% Ruby and 10% XML, and over all, it's a pretty fun language to code in. However, outside of BreakingPoint, Ruby is almost universally perceived as a language specifically for driving web applications. As a result, it can be hard to find good libraries for non-web chores -- in my case, I couldn't come up with a good way to natively read and write raw network packets.
So, I wrote a packet library for Ruby. It's called PacketFu, and over the weekend, I talked about it at Lone Star Ruby Conf here in Austin. In my talk, I spent a fair amount of time discussing the design ideas behind PacketFu, the most excellent BinData Ruby gem, and demoing various tasks that PacketFu endeavors to assist in -- packet sniffing, parsing, and rewriting.
PacketFu, now at version 0.0.3, is triple-secret alpha pre-release level code, but the demos and example applications work, and the external interfaces are pretty much nailed down and documented here. Look for a more sane beta release in the next few weeks, and a major version release before the end of the year. If all goes well, at next year's LSRC, I'll be talking about all the fab apps written using PacketFu.
More Musings on Oracle
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.