Posts Tagged ‘Security’

Use a BigIP iRule to further defend against ShellShock

Saturday, October 4th, 2014

By now you’ve no doubt heard about ShellShock, and have quickly worked to patch all your systems to close the most vulnerable aspects of this pervasive exploit. You may even be aware that some users are reporting that even the patch hasn’t fully closed the vulnerability (it seems that while the patch prevents execution from arbitrary code execution, aliasing commands is still possible).

The exploit is pretty simple to execute; the user-agent header here will write the text “HACKED” to a file named hack.txt in the /tmp directory on a vulnerable server:

GET /cgi-bin/anypage.html HTTP/1.1
Host: yourhost
User-Agent: () { :;}; echo HACKED >>/tmp/hack.txt 
Accept: text/xml,application/xml
Accept-Language: en-us

So, in addition to patching your servers, if you’ve got a BigIP server in front of your systems, you can also set up an iRule on your system to prevent the traffic from even getting through to your servers by looking for those characters ( “(){” ) in any of your headers:
big-ip-irule-shellshock

The details of the iRule are posted on F5’s forum and F5 even maintains a dedicated up-to-date ShellShock information page. Basically there are two versions of the iRule; one that trades off a tiny bit of performance to log the attack attempts, and one that’s designed to be slightly more performant but lacks logging.

Sure enough, within minutes of applying this iRule to our front-end servers at a client site, we started seeing attack attempts in the BigIP logs. So be warned: the bad guys are out there and they’re actively exploiting this bug, so do everything you can to secure your systems!
(more…)

Understanding SQL Injection Vulnerabilities

Thursday, April 25th, 2013

Every now and then I get a report from some security auditor that Plumtree (or ALUI or WCI) has a “SQL Injection Vulnerability“. While this blog has seen more than one security-related post, SQL Injection is not a likely attack vector.

The reason for this is simply that WebCenter Interaction (and BEA ALUI before that, and Plumtree before that – this thing has always had a very solid foundation!) uses PREPARED STATEMENTS (and, to a lesser extent, STORED PROCEDURES). The above wiki post describes how SQL injections work, and this Stackoverflow.com post describes things exceptionally well:

You can either use BAD SQL that exposes the application to SQL injection:

Statement stmt = conn.createStatement("INSERT INTO students VALUES('" + user + "')"); stmt.execute();

… or you can use GOOD CODE to avoid it:

Statement stmt = conn.prepareStatement("INSERT INTO student VALUES(?)"); stmt.setString(1, user); stmt.execute();

Now, lets say that a malicous end user enters a value of ‘Robert’); DROP TABLE students; — for their user name.

The first example would run this SQL Statement:

INSERT INTO student VALUES('Robert'); DROP TABLE students; --) 

… which would immediately delete all your students.

The “Good Code”, though, would simply insert a value of “‘Robert’); DROP TABLE students; —” into the “students” table. Not perfect, sure. But at least your database would be protected from end users being able to run SQL against your database!

Guess which type WebCenter Interaction uses? If you guessed the latter, you’d be right. And you can move on from claims of “SQL Injection Vulnerabilities” – there’s nothing to see here. Of course, there’s plenty to be seen elsewhere, but that’s another story!

Cool Tools 24: SSLLabs.com

Sunday, March 10th, 2013

A couple months back, the security team at a client reported that they used a scanner to generate a security report of their SSL-enabled portal, and the results included this little gem:

The SSL protocol encrypts data by using CBC mode with chained initialization vectors. This allows an attacker, which is has gotten access to an HTTPS session via man-in-the-middle (MITM) attacks or other means, to obtain plain text HTTP headers via a blockwise chosen-boundary attack (BCBA) in conjunction with Javascript code that uses the HTML5 WebSocket API, the Java URLConnection API, or the Silverlight WebClient API. This vulnerability is more commonly referred to as Browser Exploit Against SSL/TLS or “BEAST”.

I knew we were using SSL at the site, and because of that, we were infinitely more secure than our peers who weren’t using SSL. But, I never really focused on the fact that SSL is a complicated “beast”, and there are different grades of security. Enter Qualys SSL Labs’ Analysis Tool, which taught me more than I’d ever known about SSL certificates. It started by giving us a big fat “F”:

ssl-labs

A full analysis of WHY we were getting an “F” is beyond the scope of this post, but if you’re using SSL, I definitely suggest you check out SSL Labs to see how secure you are. The links and recommendations by SSL Lab’s report are phenomenal and it didn’t take much time at all to resolve all of the discovered issues.

In our case, two major things were counting against us:
Certificate Chain
We didn’t have the complete certificate chain installed. Using SSL Shopper’s SSL Checker, we could see where the chain was broken. Because it was a Verisign certificate, the path led use to Verisign’s Certificate Checker. The below screen shot shows a GoDaddy certificate with the proper chain installed.
ssl-checker

Weak Ciphers
Apparently not all SSL is created equally; there are different ciphers that can be used for encryption and transport. And because we were using the default BigIP configuration, we were supporting legacy ciphers that dated back to the IE6 days. By tweaking the Cipher configuration to exclude the less-secure ciphers, we were able to get that SSL Labs report back up to an “A” where it belongs…

big-ip-ssl

WCI Community Cache-building woes: Give Everyone access to your headers

Sunday, March 6th, 2011

A year ago (wow – time flies!) I promised to elaborate on some other causes of the “Error displaying Dropdown menu tabs” error in WebCenter Interaction headers (which didn’t seem to affect the Plumtree or ALUI versions that predated it).

Well, it’s time to do some more ‘splaining: In most cases I’ve seen, this has to do with the fact that the current user (guest or authenticated) doesn’t have at least SELECT access to the header portlet.  So, if you’re just looking for the executive summary of this post, the first thing to check is whether EVERYONE has at least SELECT access to the header portlet.

Ms. Cooper (my made-up 8th grade algebra teacher) always told me: “Show your work“.  Hell, even if I got the right answer the old bag would still dock me points if I didn’t.  [Before you get offended, note that I can say that because Ms. Cooper is a figment of my imagination – I have great respect for the entire teaching profession and especially every teacher I’ve ever had that wasn’t made up.  I would never refer to any of them as an “old bag”.]

So, let’s show the work:
(more…)

There’s a WCI App For That 7: LockDown

Tuesday, February 15th, 2011

LockDown is an Integryst product that has been around for years and provides the best security management functionality available in the WebCenter Interaction space.

It is a full-featured security management add-on for Oracle’s WebCenter Interaction (WCI) / AquaLogic User Interaction (ALUI), providing an intuitive user interface for managing and reporting on the security of objects within the portal in a logical way. Featuring the ability to propagate security changes to child objects and folders and export comprehensive security reports, the latest update includes manipulation and reporting of Knowledge Directory, Publisher, and Collaboration Server security in addition to Plumtree Administrative Objects.

For more information, check out our product page, and contact us if you’d like a demo!

WCI database Access Levels

Wednesday, November 10th, 2010

If you’re a regular reader of this blog, you know we like getting under the Plumtree covers and figuring out what’s going on behind the scenes.  The ALUI databases are sometimes confusing – particularly the newer half-baked ones like the security database.  But the old legacy PT tables have undergone years of refinement, and every now and then show a well-thought-out design.

Today’s post is a quick lesson in binary math and how the ALUI security tables work. 

As you know, WebCenter Interaction object security includes READ/SELECT/EDIT/ADMIN privileges, and while there are some challenges to manipulating these security settings in the database (and some products to overcome the limitations), the underlying database structure is pretty straight-forward:  In tables like PTOBJECTSECURITY and PTCARDSECURITY you’ll find records that look like this:

While ObjectID, ClassID, and GroupID might be obvious in the context of the portal, AccessLevel is a bit-wise representation of the security level for that object, and contains either a 1, 3, 7, or 15.

Why these numbers?  Binary math.  Any number can be represented in binary (a base-2 numeric system) using bits; you’d represent the number 7 with a binary number of 0111, because:

Value: 8 4 2 1
Bit: 0 1 1 1

In other words: 8*0 + 4*1 + 2*1 + 1*1 = 7.

So if we look at the above table in the context of ALUI security privileges, EDIT access would be:

Value ADMIN EDIT SELECT READ
Bit: 0 1 1 1

i.e., a value of “7” in the database means “edit”, and you can calculate the values for the other privileges.  Interestingly, you can’t have EDIT privileges without having SELECT and READ (which is why you don’t see any values of, say, “4” in these tables). I wonder what would happen in the code if you manipulated the DB to give someone edit privileges WITHOUT giving them SELECT or READ? 

I guarantee this:  if you muck up this table, you are not going to get official support any time soon…

Some musings on passwords

Thursday, August 19th, 2010

Ah, security.  Here we go again.  My thesis in this post is that we all occasionally mistake “complexity” for “security” when choosing passwords – or, as administrators, setting password policy.  An IT administrator who checks every box in the password policy configuration may not be doing much more to secure users’ accounts than his peer who sets a password to “12345” to “test things out” – and forgets to change it later.  Similarly, an admin who configures passwords to expire every two weeks may be less secure than a more pragmatic one who sets a time limit of 3 or 6 months.

Countless essays, papers, statistical analyses, and blog posts have discussed the topic of passwords (a remarkably rich subject), so hopefully I’m not just adding to the the noise by saying: All too often, I see people forget about the “Threat Matrix” (not related to, well, anything by the same name).

The “threat matrix” is really a multi-dimensional graph of vulnerabilities, responses, and new vulnerabilities caused by those responses.  But for the sake of this post, let’s look at two of the dimensions:

  1. In what ways can a password be circumvented, and
  2. How can you counter those threats in the most effective way

A password can be beaten with a random string attack, dictionary attack, network sniffer, or simply a bad guy dropping by your office after-hours and rifling through your drawers.  A common mistake is thinking that common forms of thwarting some attacks necessarily make ALL attacks less likely.  Almost by definition, decreasing the odds of one attack type increase the odds of another. 

So, to the admins out there setting security policy: consider that the security benefits to increasing password length and complexity requirements do NOT rise linearly with increased length and complexity.  In fact, they drop off pretty quickly.

  • A password that has a requirement of “10 characters, at least one lower-case and one upper-case, one number, one special character, and one ancient greek symbol that doesn’t appear on your keyboard” is NOT a more secure password.  Because, by the time the frustrated user has tried 47 different memorable-but-impossible-to-remember passwords, s/he’s gonna have to write that damned thing down – and we all know THAT isn’t secure.
  • Full l33tspeak is not a secure password strategy.  If every one of your passwords is the l33tspeak version of the username (alidbuser/@l1dbu$3r, contentdb/c0nt3ntdb), it’s not secure.
  • Dictionary attacks against a web site are impractical, and permanently locking accounts as a way to thwart them after 3 failed login attempts is ridiculous.  At very least, if you’re going to lock accounts, have them auto-unlock after 10 minutes.  This makes the effort to even try hundreds of passwords impractical, let alone the millions or billions that would be required for a full dictionary attack.

I think of all the blog posts I’ve written, this may have taken the longest.  I’ve written, re-written, and trimmed pages and pages of text to basically complain about amazingly complex password rules that some clients have in place without even knowing WHY (“because they’re more secure” is not the correct answer). 

As I’ve continually pruned this post so as not to completely bore you, I realize that the Threat Matrix is an important concept that all IT people should consider in all aspects of daily IT work.  There are plenty of real-world scenarios where the matrix of threats and responses are not fully understood, and hopefully we can make light of some of these in future posts. (more…)

Security Reminder: Stay Vigalent!

Tuesday, July 13th, 2010

Government work can be a challenge with all the rules, regulations, and procedures that come with it.  But there’s one thing I have to continually remind myself when dealing with that “way too much paperwork” thing: whether I’m administering a government web site, ALUI portal, or any other web application is that security can and MUST be taken seriously at all times. 

So, consider this a friendly reminder – especially if you’re exposing your portal on the Internet: stay vigalent, and take all threats seriously.  About 18 months ago, I got an alert in the middle of the night that we were out of drive space on a portal server at one of my semi-government clients.  No big deal; it happens all the time.  Only this time it was different.  Overnight, our logs had exploded from roughly 20MB/day to 2GB/day:  something was seriously wrong.  The logs were so big they were hard to even open, but when i did finally crack them open, here’s a snippet of what I found:

Basically, there were GIGABYTES of these requests – someone was scanning our servers, alternating in different object IDs for different spaces, looking for incorrectly secured communities or other portal objects.  They were basically just scanning different activity spaces, making all kinds of semi-random requests with different IDs a couple times a second.

It turned out that these particular baddies weren’t that sophisticated: they were making no effort to conceal their source IPs through some sort of distributed attack, and their algorithm clearly didn’t demonstrate a deep knowledge of how portal URLs are constructed.  And honestly, we were lucky for even finding this attack in the first place because at the time we didn’t regularly audit the logs, and only caught it because of that benign disk space warning.

In the end, we blocked the entire subnet (from China, a notorious hacker hangout), and the attacks stopped.  We should have reported the attempted breach, and I certainly would if it happened again, but I’m sharing this story with a single moral: no matter how “little” you think your site may be or how you think “noone cares about my little corner of the internet”, the bad guys are out there, and they don’t discriminate when they’re looking for victims.

So, take a minute today to check your security settings one more time, and keep an eye on those log files for anything suspicious!