Archive for the ‘Security’ Category

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:

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!

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 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!

Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

Thursday, March 24th, 2011

If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.

Why?  This post by gimble2 about sums it up:

Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.

Indeed, this is a big problem because Java 1.6.0_24 lies to users:

Unrestricted Access, huh? Bullsh*t.

You can confirm this by viewing the Java Console when trying to run Bulk Upload:

There you’ll likely see an exception like this:

Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
Exception occurred during event dispatching: access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
at bulkupload.BulkUploadApplet. chooseFiles(
at bulkupload.BulkUploadApplet. access$100(
at bulkupload.BulkUploadApplet$ (

at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$ Source)
at java.awt.EventQueue$ Source)
at Method)
at$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at Source)


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!