Communicating Directly with WebCenter Interaction Search Server

Years ago I wrote about checking the Plumtree (ALUI?) Search Server Status The Hard Way.  And I just let it go.  A couple days ago, I told you about a great webinar on Oracle’s support site, and it took that great presentation for me to put two and two together: communicating directly with the search server is possible for more than just “checking its status the hard way”:  once you know how to connect to the port and issue commands via Telnet, you can do ALL KINDS of stuff.  Anything, in fact, that the portal can do – and more.

It turns out that WebCenter Interaction – the portal, IDK, custom code, you name it – is just building complex text queries under the covers based on the actions a user performs (such as typing a search term in the search box).  And you can see these queries when you run PTSpy (Turn on INFO for the SEARCH component):

Taking this search string and adding the (secret?) key, you can compose an identical query:

KEY redacted (((NAMESPACE english BESTBET “matt chiste”) TAG bestbet OR ((ptsearch:”matt chiste”) TAG phraseQ OR ((ptsearch:matt or ptsearch:Matt or ptsearch:Matt_) order near 25 ptsearch:chiste) TAG nearQ OR ((SPELLCORRECT (ptsearch:matt) or ptsearch:Matt or ptsearch:Matt_) and SPELLCORRECT (ptsearch:chiste)) TAG andQ)) AND (((ancestors:”dd1″)[0]) OR (((subtype:”PTUSER”)[0]) OR ((subtype:”PTCOMMUNITY”)[0]) OR ((subtype:”PTPAGE”)[0])) OR (((subtype:”PTGADGET”)[0]) AND ((gadgetsearchtype:”bannersearch”)[0])) OR ((@type:”PTCOLLAB”)[0]) OR ((@type:”PTCONTENT”)[0]))) AND (((((@type:”PTPORTAL”)[0]) OR ((@type:”PTCONTENTTEMPLATE”)[0]) OR ((@type:”PTCONTENT”)[0])) AND (((ptacl:”u200″) OR (ptacl:”212″) OR (ptacl:”211″) OR (ptacl:”207″) OR (ptacl:”202″) OR (ptacl:”201″) OR (ptacl:”51″) OR (ptacl:”1″))[0]) AND (((ptfacl:”u200″) OR (ptfacl:”212″) OR (ptfacl:”211″) OR (ptfacl:”207″) OR (ptfacl:”202″) OR (ptfacl:”201″) OR (ptfacl:”51″) OR (ptfacl:”1″))[0])) OR (((@type:”PTCOLLAB”)[0]) AND ((istemplate:”0″)[0]) AND ((collab_acl:”- \~ 1″)[0]))) METRIC logtf [1]

Then, you telnet to the search server port and paste in the text.  Search will respond with an XML formatted reply (in this case, no results):

Of course, once you have this revelation, you can see how the search text can be tuned based on the folder you’re looking for, the ACLs you want to check, or any other number of parameters.

The other startling revelation is that security is applied at the portal tier, and not the search server tier. That is, if I’m a bad guy and I know that key, and I know the query format, I can construct a query that goes against the search server to circumvent any security that has been applied to cards. Notice there are no credentials or login token passed in the query for the search service to check. Now, before you get all up in arms about this being a major security vulnerability, I offer some counter-points:

  1. Anyone with any knowledge of network sniffers or tunnel tools could easily find this key, as the traffic is not encrypted – “Security through obscurity” is not valid security.  However, I don’t consider this a fundamental design flaw or major security hole, and it is no doubt not the security that the Plumtree engineers had in mind when they implemented this. Instead, the search server should reside in a DMZ, and the port shouldn’t be open within the general network anyway. The port is NEVER to be opened to the Internet (try it on my site – “telnet 15250” doesn’t work).
  2. Even if someone did have this secret key, and they had network access to the search server port, and they knew the search format, and they knew how to craft the request to omit ACLs, the most they could get was search results they didn’t have privileges for – not the documents themselves.

How can this be applied in a real-world scenario?  Stay tuned!

Tags: ,

Leave a Reply