You are here: Home Community BreakingPoint Labs Blog

Real Clickjacking?

After Michael Zalewski's WHATWG post spilled enough beans to show definitely that yesterday's pop-up evaders weren't "clickjacking," I put together another demo this afternoon (link below), which uses a combination of opacity and z-index settings on an iframe. Again, it's just speculation.

 

http://www.planb-security.net/notclickjacking/iframetrick.html

 

This seems to fit the bill: No Javascript required, uses iframes, and gives the ability to seemingly overlay one UI on top of another. By the way, the demo is mostly harmless -- it just turns your Myspace profile from private to public. I started down the path of masking my brokerage's trading app, but masking out keystrokes for stock orders seemed to be overkill for a simple speculative demo.

 

Posted by Tod Beardsley (2008/09/26 14:45:54.606 GMT-5)
2 comments | Tags:

Not Clickjacking (Almost Certainly)

[UPDATE: See updated post]

A couple months back, I got to thinking about how to weasel around the built-in pop up blockers for Mozilla Firefox and Microsoft Internet Explorer. I can't remember now why I started down this path, but it consumed my afternoon, and in the end I had about a dozen variations on three or so core strategies.

Since I have no fake watches or mortgages to sell, I thusly shelved it all once I was done. We couldn't think of a reasonable application for these techniques here in BreakingPoint.

Well, maybe something was in the air, because it looks like RSnake and Jeremiah Grossman were working on something similar at around the same time. Only, they were going to present their findings at OWASP this week.

Unfortunately, we can't know what the extent of their trickery is, since some vendors asked them to keep it quiet -- but it's almost certainly more devious than simply skipping around the pop up blockers.

So, in the interest of quelling any speculation on the nature of "ClickJacking," here's two or three mildly interesting examples of what it almost certainly isn't. Note, the below example links are all in an iframe from planb-security.net. So, if you have a tabbed browser, you may notice an illusion the iframe's parent window (this blog post) being replaced by the fake pop up link (in this case, example.com).



If you're in the business of speculating on what other people's findings are, then you can safely check these techniques off your list. Since they all require Javascript to work their anti-anti-pop up magic, NoScript is quite effective in preventing these attacks. Based simply on this observation, and discounting for the moment the inherent lameness of merely subverting mouse clicks, it's virtually certain Jeremiah and RSnake's stuff is much, much more interesting / dangerous.

Posted by Tod Beardsley (2008/09/25 16:13:37.133 GMT-5)
5 comments | Tags:

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.

Posted by Tod Beardsley (2008/09/09 10:22:15.830 GMT-5)

Faster, ActiveX! Kill, Kill!

If you haven't thought about ActiveX Exploitation in a while, a read-through of Warlord's January 2008 article, "ActiveX - Active Exploitation" is in order. I bring this up because the next StrikePack will feature a new strike, "Analysis: Killed ActiveX Instantiation."

As the name implies, this strike iterates through the client-side ActiveX controls that Microsoft has "killed" via the kill bit mechanism, and simulates a series of evil web pages which instantiate those controls. As of today, there are 445 kill bits set on Windows XP and Vista. These are all controls that Microsoft, in no uncertain terms, has labeled as Very Bad For Internet Explorer. If you run any of these controls, your browser will crash in horrible ways, or you risk getting commands passed directly to the shell, or your browser hands over all your personal data, or some other awful desktop fate.

Instantiating these controls is easy -- just deliver an OBJECT tag with the appropriate CLSID, reference the object with your exploitastic Javascript, and you're pretty much done. Thus, you would think that blocking these controls from instantiating in the first place would be as fundamental to malware detection as any string matching Slammer or Blaster signature.

However, informal testing of a couple devices we have around the office proved this assumption to be baseless. Rather than the forty or fifty percent detection rates I was expecting, I found rates between zero and ten percent.

Admittedly, I had low expectations to begin with, so I wasn't exactly shocked. That said, if you're in the market for a fancy expensive device that claims client-side coverage, you may want consider how that gear stacks up against vendor confirmed, publicly disclosed, easy to use browser vectors.

Posted by Tod Beardsley (2008/06/24 12:00:00 GMT+0)
0 comments | Tags:

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.

Posted by Tod Beardsley (2008-04-04 14:56:16)

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)

Posted by Tod Beardsley (2008-04-02 16:10:30)