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.
New Apps: TDS, TNS, FIXT, and FIX
Newly implemented for BreakingPoint's Application Simulator are four new protocols, all available as part of StrikePack 24931.
For database application simulations, we've added the TDS (Tabular Data Stream) and TNS (Trasparent Network Substrate) protocols, used by Microsoft SQL Server and Oracle Database respectively. These protocols are used for both database authentication and database query requests and responses. TDS typically runs on port TCP/1433, and TNS runs on TCP/1512.
We've also added support for the Financial Information eXchange (FIX) protocol. FIX 5.0 consists of the FIX application protocol and the FIXT session protocol. The FIX Protocol is a series of messaging specifications for the electronic communication of trade-related messages between financial entities such as banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers.
For the database protocols, BreakingPoint supports the following options:
TDS
- Login: Username, password, server name, client name
- Query: Use Database: Database name
- Query: Select: SELECT modifier, column list, table name, WHERE comparison expression, ORDER BY expression
TNS
- Login: Database username, database password, server name, database name, server OS, server banner, client username, client machine name, client program path, client program name
- Query: Select: Column list, table name, WHERE comparison expression, ORDER BY expression
For FIX and FIXT, these configuration options are available:
FIXT
- Heartbeat: Test request id
- Test Request: Test request id
- Resend Request: Begin sequence number, end sequence number
- Reject: Reference sequence number, reference tag id, reference message type, session reject reason, message text Sequence Reset: Gap fill flag, new sequence number
- Logout: Text
- Logon: Heartbeat interval, reset sequence number flag, next expected sequence number, maximum message size, test message indicator, default application version id
FIX
- Business Message Reject: Referenced sequence number, referenced message type, referenced business reject id, business reject reason, text
- Network (Counterparty System) Status Request: network request type, network request id
- Network (Counterparty System) Status Response: network status response type, network request id, network response id, last network response id
- User Request: User request id, user request type, username, password, new password
- User Response: User request id, username, user status, user status text
Finally, these new protocols are now incorporated in four new default BreakingPoint superflows:
- BreakingPoint FIXT Session (FIXT)
- BreakingPoint FIX Session (FIX and FIXT)
- BreakingPoint MS-SQL Server (TDS)
- BreakingPoint Oracle Database (TNS)
SMB/CIFS AppSim Update
With the release of StrikePack 21889, the SMB/CIFS AppSim module has been improved from our first version which was released last week. Among the improvements are a number of customization options which are now exposed to the UI. First, the user can now provide their own custom data file to be used as payload data during file transfers, as well as indicate a file chunk size to be used for each request of a portion of the file being transferred. The user can also now configure session parameters for use such as client and server name, domain name, username, and password. If any of the available customization options are not modified by the user, they are randomized to provide each traffic flow with a unique set of session parameters.
Stay tuned for more upcoming improvements and expansions to the SMB/CIFS AppSim as well as the addition of new protocol modules as we continue to improve our Application Simulator component.
SMB/CIFS Application Simulator
In our recent StrikePack 21396, SMB/CIFS application traffic simulation has been improved from standard SMB traffic to a more dynamic AppSim module. With the initial release of the new module two SMB flow scenarios have been included; an SMB NULL Session and an SMB/CIFS Client File Download. The former simulates an SMB NULL client connection to the server's IPC$ share. The latter however simulates an authenticated client connection to a shared resource on the server, performs a directory listing, then retrieves information about and downloads a file found there. With the first release of this AppSim module as delivered by the StrikePack mentioned above, these two traffic flows use fairly static data such as the filenames found in the directory listing of the shared resource and the data contained within the target file, although some customizations are exposed to the UI such as client hostname, server hostname, username, etc. In a forthcoming update however, many of the parameters for the Client File Download scenario will be randomized by default, and many more parameters will be exposed to the UI for customization by the user.