nCircle VERT Blog

From time to time I come across a solution to a small problem that I encounter
every day in the course of my work. I thought I would start sharing some
of these tips and tricks.

For example, yesterday I stumbled across a setting in Komodo IDE pertaining to
indenting. I'm accustomed to setting the soft tab width in the
preferences but the file I was editing was not adhering to my settings
and, even though my tab width was 4, the document continued to use 8
spaces. After some poking around I discovered that each individual file
opened in the IDE has its own indent preferences, which take precedence
over the global preferences. Right-clicking on the file tab that you
are currently editing and selecting 'properties and settings' will allow
you to change the file specific settings.

There are two words that I fear more than any other, and I imagine the same is true for most other vendors. Those magical two words that send shivers down spines of support and make grown engineers cry... 'Application Interaction'. The term, used to describe a potential negative impact that one product may inadvertently have on another, is often seen as a "Red Alert, Battlestations" type of scenario. You see, when you develop a product that's designed to identify vulnerabilities, you become more familiar with this term than most other software vendors. The problem is that 99% of the time, the issue isn't yours to fix and "Application Interaction" becomes a thinly veiled way of saying "Vulnerability Discovery". Even though we know what's going on, the nature of the term and the thoughts associated with it lead to vendors squirrelling the term away and the real problem is never discussed.

So why do I consider "Application Interaction" to really mean "Vulnerability Discovery", especially in the context of vulnerability management? Imagine an attacker sending packets to remote systems and causing those remote systems to hang or crash. That would be defined as a Denial of Service and, since we're talking about a remote service, even Microsoft would issue a patch and call it a vulnerability. The problem is that small and/or specialty vendors (like SCADA solution providers) don't always see it that way, their programs start to crash and they tell the customer that the "scanner" is the issue. However, as you can see, scanner and attacker could be used interchangeably in the sentence above. Of course, everyone aims to be non-invasive and no one purposely releases code that will crash a service, but it happens; it's a fact of life that we need to live with. The question is how do we deal with this and the answer should be urging the software developer to issue a patch.

Let's consider the most popular example, printer crashes. The TCP/IP stack in most printers is notoriously fragile, googling for 'port scan printer crash' will demonstrate this, and everyone in the industry is aware of it. Yet printer vendors will point you toward the other vendor involved because nobody wants to rewrite code.

A recent example that I encountered involved some fairly important software for a very important company. The software would crash when scanned; yet when you connected to the software via telnet or netcat, it was fine. We did some fairly extensive testing and discovered something interesting: the software -- remember how important it is -- would only crash if the source port was greater than 32767. Now, when you are using your computer and connect to another device, the ephemeral port is often below 32767. This was the case, however when you're connecting to thousands of ports across potentially thousands of hosts, it's quite easy for your source port to be higher than 32767. This is exactly what was happening, connect with a source port of 32768 or greater, and the service would crash. We'd done everything we could as a company to be non-invasive, yet a programming flaw in the other application lead to an integer being signed instead of unsigned, limiting the port range from a max of 65535 to 32767. We were able to work with the vendor in this case, and they fixed the flaw and released an update. When considering this scenario, keep in mind how important this software was... we cannot forget how dangerous a denial of service in critical software is.

So the next time you encounter an "Application Interaction", work with your vendors and help your vendors work together, the odds are the product that's causing the interaction has found a 0-day in the other application and, ultimately, that's a good thing. The flaw is identified internally, rather than being exploited by a malicious attacker. A fix can be developed, and quickly tested with the two vendors working together. The most important thing to keep in mind is that your security solution, the product that you pay for to keep you secure, is doing it's job and, at that point, possibly exceeding your expectations. You may even end up with a CVE credited to you, and there's nothing wrong with that.

Prior to the release of Oracle 10g, the TNS Listener by default was not secured with a password. In the default state, anyone who could access the TNS Listener remotely could issue commands to it, including shutting it down. The TNS Listener had two security settings: 'OFF', the default state, without a password set, and 'ON' when a password was set.

Starting with 10g, Oracle made the TNS Listener a little more secure, adding a new authentication method, 'Local OS Authentication', and making it the default setting. This setting allows local administration of the TNS Listener by the user who owns the tnslsnr process.

This change split the security 'ON' setting into three different states:

Security ON: Local OS Authentication
Security ON: Password or Local OS Authentication
Security ON: Password

The 'Security ON: Local OS Authentication' and ' Security ON: Password or Local OS Authentication' settings are easy enough to reach with LSNRCTL commands, as the first is the default, and the second by simply setting a password for the listener.

The ' Security ON: Password' setting requires adding a line to the listener.ora file, which is also the same method needed to modify the more elusive setting of 'Security OFF'. The necessary line is:

LOCAL_OS_AUTHENTICATION_ = OFF

If this line is added to the listener.ora file after a listener password has been set, it will change the security status from 'Security ON: Password or Local OS Authentication' to ' Security ON: Password'. However, if you add the line before a password has been set, the security status becomes 'Security OFF'.

With security off the TNS Listener in 10g and later is just as insecure as 9i and earlier versions. While the likelihood of getting into this insecure state unintentionally is decreased since it's no longer the default setting, administrators should still be aware of this possibility. It is just as important to ensure TNS Listener is secured with a password in 10g and later as it was in previous versions.

Building sandbox functionality into applications is the new standard. Examples include: Office 2010 Protected View and the Chrome sandbox. Even the HTML5 standard includes sandboxing capabilities for iframes. This is a great way to mitigate the number of attacks that can occur by decreasing the size of the attack surface. This does not affect speed in most cases with the same performance that you’d expect from non-sandboxed application.

Users should not be any PDF Reader without the sandbox features that are enabled within them. Example: Adobe X has “Protected Mode” and Foxit 5 has its “Safe Viewer”. If you are not using a PDF viewer without a sandbox, then you are at risk for a high percentage of attacks infecting your environments. You are allowing the PDF to make system calls and write access on the filesystem.

Adobe is quick to release updates but and is vulnerable to more attacks because of their large stake in the marketplace, competitors are not targeted as consistently because of this. So ensure you are updating your Adobe from 9 and earlier to version 10. Issue is most end users in enterprise environments do not patch their systems that consistently.

Recently, I attended a security conference that included a keynote talk from Mikko Hypponen, Chief Research Officer for F-Secure. He talked about how 60% of large enterprise attacks are intended for Adobe. This type of attack consists of simply spoofing the email header; this involves the attacker changing who the email is sent from. When the target looks at the email, it will probably be someone they know or trust and have exchanged emails previously, for example, “Mike” from accounting. The email would contain an attachment that could simply be “expense report 2011.PDF” with a note explaining “this needs to be reviewed”. The target then opens the expense report attachment with Adobe, the enterprise standard PDF viewer. Adobe then tries to open the PDF, Adobe crashes, and then reloads a valid PDF that looks legitimate. The issue with most end users, if they even notice a crash, will not report it the to their I.T department. They assume everything is normal and system untouched because they are reviewing a legitimate looking PDF. The problem is the user, is already owned and infected. During the talk, one phrase he used was “I do not know why anybody uses Adobe anymore, I hate it, and there are many PDF readers out there that are not targeted”.

This made me ponder that very same question and ask around the industry a little bit by speaking with an executive who recently attended the Gartner Symposium/ITxpo 2011. This is a massive conference with over 10,000 attendees. This executive was in a room full of CIO’s who have a huge influence over their companies IT decisions. They all spoke negatively about Adobe and vented their frustrations over the product.

So let’s recap, in two weeks, at two different conferences with two very different audiences, both expressed dislike Adobe. Given this attitude, how long will it be before people abandon Adobe all together and move to a competitor such as Foxit.

While reading through a recent Microsoft Security Bulletin, I decided to take a look at the page's source code. I am not sure what prompted me to take a look, but it probably has to do with my inquisitiveness. Luckily for me, curiosity has yet to kill this cat.

After sifting through the repetitive lines of script which make up the web page, I came across an interesting tad-bit of information. The site's developers have used an external piece of JavaScript in order to have Internet Explorer properly render HTML5 elements. This JavaScript shim was written by Remy Sharp and is publicly available through Google Code. It has a simple, yet clever way to incorporate HTML5 tags that IE can't yet parse.

This leaves me wondering why Microsoft couldn't simply integrate full HTML5 support into Internet Explorer 9 properly from the get go. Surely when IE9 was being developed, the widespread use of HTML5 wasn't unforeseen. The fact that their developers are using external scripts as a work around is in a way an admission of guilt that IE9 lacks the necessary functionality required to meet today's web browsing needs.

Web applications are increasingly targeted by hackers seeking to cause havoc on networks. This is, at least partially, due to the increase in the number of automated tools that are publicly available on the internet. Not only do Hackers now have more options when carrying out attacks against corporate or government networks, they are able to orchestrate exploits with greater ease. The various exploit frameworks and live CDs can ease the process of successfully breaching the security of a network.

Exploiting known vulnerabilities becomes easier as the process becomes more automated. Web sites don't need to be targeted individually, as tools can be used to automatically scan for vulnerable sites. Public facing network infrastructure, such as web servers, will always be the easiest target. These servers have the difficult task of being secure, while allowing legitimate traffic to continue with as little inconvenience to the legitimate users as possible. Modern web servers can carry a wealth of information that may be useful to the bad guys, making them sought-after targets.

Providing web server security can be a difficult task considering the fact that web developers customize web sites based on specific project requirements. Not all web development is done the same way, making it tricky to ensure any possible vulnerability is covered. Although initial security testing is important to the development and QA teams, continued security testing in a production environment is imperative if administrators want to remain proactive.

Considering the tools that can be used by the bad guys, the good guys need to step up their game and build an arsenal of their own. This is where tools, such as nCircle's WebApp360 product, come into play. By providing a way to automate security checks in a production environment, system administrators are able to keep better track of any vulnerabilities their systems may have. A good defense only gets better if it is constantly being tested and improved.

Network tools are only going to get better and more sophisticated in the future. It is important to keep up with the latest trends as we have all seen what can happen when network administrators let their guard down.

Today I would like to talk a little about Windows shares. If you've already read some articles about how Windows handles shares, you might already know this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares

All Windows shares come from this registry key during the boot procedure, which means it controls which directories you will share with others and how they will be shared. Furthermore, it doesn't mean the change in the registry will be applied to the system instantly. It needs a reboot to make it work.

Then another problem comes out. Is that possible to have inconsistency between the registry and the working share setup (in a condition after rebooting)? The answer is yes. The reason is that the share in this registry key will tell what directory will be shared in the system during the boot procedure. However, if the directory does not exist anymore, that value will still be in the registry. But the share will not be set up in the system.

You may argue that this kind of inconsistence is not common, especially if you never manipulate that key manually, because when you want to delete a directory which is shared, Windows will delete that share for you as well. Then you might have forgotten some other common situations, such as USB drives and broken disks. For example, you have a USB drive connected as disk E, and you share some folder with others. The system will added one value into that Shares key in the registry. After using it, you might unplug it and put it into your pocket. However, one thing you don't know is that share folder name is still in the registry. So, if you got another USB drive to plug in and accidently has a same folder name in it, it will automatically be shared with others with the same permissions.

From this, we can see that regular cleaning unused share registry values is a pretty good practice for your system security. Otherwise, you might share others with some folders which are not supposed to be.

Information Technology is one sector that can change so fast it demands the ability adapt quickly. The more we evolve technology the more we see IT professionals evolving themselves to delivery on ever accelerating deadlines. During stressful times it is healthy to maintain a fun work environment that is committed to team building. In line with that belief I was really excited to see the talk on "Cubical Warfare, The next Arms Race" by Jason Kendall this year at SecTor.

This talk promoted constructive warfare among consenting peers to alleviate tension in a high stress environment. The center of attention was NERF-gun technology, how to shoot each other safely, and the various options available. Taking short entertainment breaks to recharge the mind and soul can make one more productive. Without any serious time commitment needed NERF warfare can definitely be a positive distraction.

One thing that surprized me was how serious some people are with their NERF guns. On display were a range of six-shooters to fully automatic NERF guns. It was also news to me that many people modify their NERF guns to improve range and projectile velocity. I was slightly disappointed with the depth of instruction on modifying NERF guns however; there was little information beyond what is available on YouTube.

Although not entirely security oriented this talk was able to relate with the stresses that all IT and security professionals deal with at times. I would be excited to attend other talks that go beyond security and address environmental issues in the industry.

Just a quick post here regarding Oracle Java Runtime Environment and how old versions can persist on a system after upgrading. This is made possible because Oracle JRE is updated by installing a new version instead of applying a patch. Unlike the current supported versions of Oracle JRE, previous installers did not attempt to remove obsolete versions.

As of writing this, the latest versions of Oracle JRE are 6 update 29 and 7 update 1. Prior to JRE 6 update 10, a default install will ignore previous installations; the latest version simply installs and registers itself for use by the system. Later versions of JRE 6 and 7 will replace the previous JRE installation, assuming it is JRE 6 update 10 or newer. There is one curious exception; if you install an older version of JRE than the current installed version, it will be installed alongside the existing installation and still persist after future upgrades.

Considering that Oracle JRE is frequently updated for security reasons the presence of old JRE versions on a system is a concern. Running the latest version of Oracle JRE does not prevent vulnerable code in past versions from being exploited if still present on a system. The point I would like to stress is that simply running the latest JRE may not protect your host if you have not eliminated all prior versions.

I will also mention as a reminder that installations of Oracle JDK always install JRE as a sub-component and at the same version of the JDK. You should also keep in mind that as of JRE and JDK 5 update 4 both x86 and x64 versions exist. Fortunately past versions of JRE typically show up in Add/Remove Programs and are easily removed. You can also check for old versions manually at the install directory by checking for folders like this: jre1.5.0_20, or jre1.6.0_06. If you do not require old versions of Oracle JRE for legacy application support I highly recommend their removal.