Covering J2EE Security and WebLogic Topics

Unconventional Warfare

Let’s get medieval.

Imagine a castle, stout and impenetrable even on this ordinary day. Guards mill about with glistening swords at their sides, anxious to try them out. Bored look-outs peer over the parapets, ever watchful for the approach of a mighty army. Prima donna archers play Uno in the towers.

Meanwhile, real life happens. Peasants and traders enter and exit the castle as part of their daily activities. The scent of steak-on-a-stake and cotton candy fills the air. All is well at our imaginary castle.

Or is it?

While the castle is certainly ready for a conventional enemy that would storm the gates and attempt to smash the walls, it was totally unprepared for what happened that fine day.

The crown jewels were stolen.

The lord of the castle is perplexed. After all, the defenses were ready — every man was at his post and ready to engage in mortal combat with enemy knights. Everyone was on the look-out. And still, the jewels are gone.

This castle scenario is what computer security seems like to me these days. We have DMZs and firewalls, intrusion detection, intrusion prevention, encryption, application resources protected by roles, and if we’re lucky, maybe even strong passwords. But more and more I’m coming to the realization that while we need those things, we as developers really need to bring out our inner guerilla. We have a handle on the conventional warfare but we almost never think like a hacker. They’re going to dress like a peasant and mimic the ways of a peasant. They’re going to be the peasant.

They’re also going to rob you blind.

The problem is, thinking like a hacker is not in our nature. Unfortunately, that needs to change. Because quite simply, unlike the crown jewels that physically disappeared, our electronic crown jewels can be stolen and yet simultaneously remain in our possession. It’s the nature of the ones and zeros.

We even need to be security conscious during non-coding activities such as writing uses cases. The reason is that even seemingly innocuous business functions can provide a covert pathway to the crown jewels.

Consider this blog post. Be sure to read the case study.

Scared?

Did you notice that conventional security techniques wouldn’t have prevented it?

This realization I had — that we need to think more like hackers to protect ourselves — did not just hit me out of the blue. I’m far too dense for that and wouldn’t have felt it. Instead, it comes from reading the blogs of the white hat hackers. In my case, Jeremiah Grossman and RSnake are the ones that scare me on a daily basis. In fact, the blog post above is the work of RSnake. It’s these guys that repeatedly hit me upside the head to make me see things in a different light. And when they hit me, I definitely feel it.

Today, more and more developers are aware of the perils of SQL injection. That doesn’t mean there’s not a lot of vulnerabilities out there but developer awareness of this particular attack is rising. That’s good. Now we need to learn more about XSS and CSRF and do what we can to avoid them. It’s all too easy to read about these attacks and yet not fully comprehend the danger because the descriptions are often too abstract. But folks like Jeremiah and RSnake make us smarter by showing us exactly what the ramifications are in all of the gory detail.

As developers, we need to be familiar with what these guys are writing about. Black hat hackers probably already know this stuff. So should we.

Find WebLogic MBeans with Ease

There was an old woman who lived in a shoe
She had so many MBeans she didn’t know what to do
— With apologies to Mother Goose

It’s hard to deny that MBeans are incredibly useful for accessing configuration and runtime data. But with so many MBeans in an application server, it’s also incredibly hard to find the needle in the haystack.

Whether you’re looking for an MBean type, a particular attribute, or the bean that goes along with a known value (domain name, for example), how do you quickly find it? I’ve already posted one trick I use for finding MBeans via the audit log. In this post, I’ll show you my bestest trick of all for finding WebLogic MBeans. I’d like to fancy myself as an Evil Genius(TM) but it’s actually quite obvious. Here we go…

The weblogic.Admin utility has several commands such as GET and QUERY. You can find MBeans by type, name, or name pattern which is useful if you already have an idea of what you want. The following command uses weblogic.Admin to print all MBeans and their attributes to the command console:

java weblogic.Admin -username weblogic -password weblogic -url t3://localhost:80 query -pretty -pattern *:*

Substitute your username, password, and URL and you’ll get a ton of output. Here’s a representative snippet:

MBeanName: "Security:Name=myrealmDefaultAuthenticator"
	ControlFlag: REQUIRED
	Description: WebLogic Authentication Provider
	EnableGroupMembershipLookupHierarchyCaching: false
	GroupHierarchyCacheTTL: 60
	GroupMembershipSearching: unlimited
	MaxGroupHierarchiesInCache: 100
	MaxGroupMembershipSearchLevel: 0
	MinimumPasswordLength: 8
	ProviderClassName: weblogic.security.providers. \
authentication.DefaultAuthenticationProviderImpl
	Realm: Security:Name=myrealm
	SupportedExportConstraints: users|groups
	SupportedExportFormats: DefaultAtn
	SupportedImportConstraints: 
	SupportedImportFormats: DefaultAtn
	UseRetrievedUserNameAsPrincipal: false
	Version: 1.0

By the way, if you’ve never used weblogic.Admin before, you must first run the setEnv (or setDomainEnv) script in your domain directory to set up environment variables and paths.

Now, that output is all well and good but it might not make finding things any easier. Time for a little redirection, my friend:

java weblogic.Admin -username weblogic -password weblogic -url t3://localhost:80 query -pretty -pattern *:* > MBeans.txt

This time, the output goes into the MBeans.txt file. You can use this file to do automated searches. When you search, you’ll get MBean names, attribute names, and attribute values. Wanna search with RegEx? More power to you! <evil-genius>Muuwhaahaaaahaaa!</evil-genius>

Anyway, like I said, it’s fairly obvious but very useful. Mother Goose’s old woman would be proud of how we spanked those MBeans soundly and sent them to bed.

Epilogue

weblogic.Admin was deprecated in WebLogic 9. It’s still there and works, but it’s being phased out in favor of WLST. I don’t know of a quick way to use WLST to dump MBeans to a file. However, WLST is clearly powerful enough to write a script that does it. I haven’t pursued a solution in WLST because I cheat and use the deprecated weblogic.Admin to dump MBeans to a file. Please don’t tell…

If anyone knows how to use WLST to the same effect, please post a comment and share the solution with everyone. Thanks!

Serious Adobe Reader (PDF) Vulnerability

There is a very serious Cross-Site Scripting (XSS) vulnerability in Windows versions of Adobe Reader less than 8.x.

If you have a website that hosts PDF files, your website is vulnerable to session hijacking since a user can have his JSESSIONID cookie stolen. There’s little you can do about it server-side since it’s a browser/plugin problem. Server-side, you can either not host PDF files or (possibly) change your MIME type to something unknown.

Users themselves can have a host of bad things happen to them with this exploit. See MSNBC for more details in general terms. For technical details, start with Jeremiah Grossman’s write-up.

The solution is to upgrade to Adobe Reader 8. Adobe says that they will have patches for older versions if people can’t upgrade for some reason. You could also turn off JavaScript or tell your browser to open Acrobat outside of the browser, but getting the new plugin is more fool-proof.

Seriously, don’t go another day without upgrading. This exploit is going to be huge… :-(

Reflections 2006

It’s hard to believe that it’s been a year since I started this blog. From its inception, my intention was to give a little something back to the massive Internet community from which I’ve acquired a wealth of information on subjects ranging from professional to personal. I also knew that I’d get a deeper knowledge of the technical subject matter by simply writing about it.

Blogging also allows me to scratch my writing itch. During the first month or so, I wrote several posts a week. Over time, that was simply not a pace I could maintain. I’m down to one or two posts a month now primarily because each post takes several hours since I usually prototype what I’m discussing and try to be very thorough.

I also thought that Google AdSense income would cover my hosting costs. Let’s just say that part hasn’t panned out. 😉 If you plan on starting a technical blog and want AdSense income, pick a subject that has broad appeal. Also keep in mind that technical websites tend to attract corporate workers who are behind ad-blocking software such as WebSense so many of your viewers won’t even see the ads. Fortunately, hosting is cheap these days.

Top 10 Posts for 2006

In case you missed them, here are my top 10 most popular posts:

  1. WebLogic Embedded LDAP
  2. The Fifteen Minute Guide to Mutual Authentication
  3. Common Problems with Authentication Provider Configuration
  4. The Mysterious CLIENT-CERT
  5. WebLogic Security Framework Overview
  6. Authentication Methods in Web Applications
  7. WebLogic 9.1 Authorization Gotcha
  8. WebLogic Auditing
  9. Security Realm Logging in WebLogic 8.1
  10. Mutual Authentication in Action

Yes, I’m also surprised that a post on WebLogic’s embedded LDAP takes the top slot. While most of its traffic is subject-specific, it also gets a lot of hits for a Firefox error message that I included in the text. Hmm, I wonder if “Britney Spears” is still the top ranking search phrase. I’ll have to start sprinkling such terms around! 😉

Another thing to note from this list is that all of the posts are WebLogic-related. I had intended to cover generic J2EE security but the reality is that there’s only so much J2EE security you can cover before getting into specific implementations of it. With this in mind, I hope to expand somewhat into the security aspects of WebSphere and JBoss in 2007. Hopefully, I’ll be able to provide meaningful content related to these servers while expanding my horizons at the same time.

Thanks for reading and please consider using the RSS feed or the email list for getting the latest posts. This isn’t a high volume blog so getting the posts sent to you sure beats checking the website for them.

Have a great new year!

 

Bookmark this page on del.icio.us