Skip to content

The End of Windows Server 2003 Support and How to Mitigate Risk If You Stay Past the Deadline

Posted: June 3rd, 2015 | Filed under: IIS & HTTP | Tags:

July 14, 2015

That date spells the end of support for Windows Server 2003. July is quickly approaching (how is it already May?!) and for many this means some extra work is in order. Microsoft has been pushing migration from Windows Server 2003 for some time now, and undoubtedly there are millions of sites that have yet to be moved.

And we aren’t pointing blame or sitting on our high horse either. We are among those who are still using Server 2003, as some of our old sites still run on Server 2003 VMs. If we had our druthers, of course we wouldn’t be on 2003, but IT can be hectic and often times other tasks take priority.

For some, July 14th won’t be a perilous drop-dead deadline. It will be a line in the sand that they’ll easily step over without much immediate penalty. While we are in the camp of urging people to migrate, we are acknowledge many will let the deadline come and go without migrating. So how will those who don’t migrate be impacted?

One major impact is that they will be without the security bulletin updates that are crucial for keeping many organizations secure. In 2013, MSFT issued 37 critical security patches. And 2014 was especially serious for major security issues (list some bad ones) for which MSFT put out patches. After July 14, those bulletin updates will be no more. But that’s not all.

The Trouble Ahead

Bye-bye Patches

The end of support means the end of security patches. This means that should a major vulnerability be found in the future- like the SSL 3.0 vulnerability or MS1305 – that Microsoft won’t be backing you up with an emergency security patch. Given the number of major vulnerabilities seen over the last year, particularly in widely and long-used pieces of code, it’s a worrying proposition to continue without Microsoft’s security patches.

Hello Breaches

When the next major vulnerability to impact all versions of Windows Server comes along and finds itself in the headlines of every tech and infosec blog, expect hackers to be out there sniffing for you. Sites that advertise (link to article on how response headers indicate your OS version) they’re running Windows Server 2003 will be guaranteed wide-open targets. It likely won’t take long after support ends for a vulnerability to emerge that leaves those still on Server 2003 in a dangerous position. For all we know, someone could have knowledge of an undisclosed vulnerability that’s waiting to be unleashed after support ends.

No More Software Updates

At this point, other software you use on Windows Server 2003 may also stop receiving updates. When MSFT ends support for an OS, many developers follow suit soon thereafter. If you have (non-proprietary) software that your organization relies on then you may find yourself no longer able to run on the latest version because it won’t be released for Server 2003.

Compliance Issues

Certain compliances or regulations may require systems to be supported from the OS to software on top of it. Running the out-of-support Server 2003 could put you in trouble with the governance bodies that regulate compliances and put your company in line for penalties. Furthermore, a lot of these security compliances (i.e. HIPAA, PCI) exist to protect customer data and the like, making it that much worse to put customers at risk with an un-supported OS.

If You’re Temporarily Staying Put

First and foremost, you should understand the risks that come with staying on Windows Server 2003. As noted, it is a perilous task that could have a range of impacts:

  • Data breaches
  • Business applications breaking/not functioning properly
  • Security compliance penalties

Hanging onto Windows Server 2003 until July 14 doesn’t necessarily spell the end of the world, but it should be understood that there are very real risks in doing so.

If you do stay on Server 2003 past  July 14, you should ensure that you have a migration plan ready to act upon — or have one that is already being put into action.

ServerDefender

If you plan to migrate servers, but won’t make the July 14 deadline, Port80 may be able to help. Using ServerDefender VP may help mitigate certain security risks until migration is complete. Every month, a range of vulnerabilities are disclosed in Microsoft’s security bulletin. For vulnerabilities those that can impact the application layer, then ServerDefender can help to mitigate the risk of running an unsupported operating system until you migrate.

Protection While You Migrate and After

ServerDefender Web application firewall will keep your sites and web apps running on Windows Server 2003 secure from hackers looking to take advantage of the unsupported operating system. And when you complete your migration, you can take your ServerDefender license with you for improved security.

Secure Migrate Move SD
Add SD to your Windows Server 2003 to secure your sites and web applications post WS2003 end of life. With SD added, you can complete your migration from WS2003 with peace of mind. After your migration is complete, you can move SD from your WS2003 server to your new server for fresh and secure new start.

 

One last plea

Migrating to a newer Windows Server before July 14 has several advantages. But adding ServerDefenderVP to the mix shares two key benefits:

  1. It allows your organization to stay compliant with security regulations
  2. It assists you in controlling your security

If you have a plan in place, even if it means toeing the line on the WS2003 deadline, you will be better prepared to weather any potential security storms. If you have any questions about how this works, please feel free to reach out to info@port80software.com, or share some general thoughts in the comments below.

 

No Comments »

Our (Signatureless) Approach to Web Application Security

Posted: February 6th, 2015 | Filed under: Web and Application Security

In a recent post, we focused on the problems with the signature-based security model. Signatures have been a staple of web application security and cyber security for some time, but are problematic in the sense that they don’t provide adequate protection in today’s landscape of ever-evolving threats.

Now, we want to explain how we approach web application security with our Web app firewall, ServerDefender.

(We encourage you to go back and read that article in full. It’s a good read, we promise!)

The Behavioral & Algorithm-based approach

Although we don’t use signatures, we still have a means for analyzing and determining whether or not a user is malicious.

Our method analyzes behavior by tracking the actions that occur over the course of a session. Activity is monitored by an algorithm that establishes what bad behavior looks like (we’ll touch on this more later), and should the user cause too many errors, the software will begin to take action. Users who repeatedly cause errors are going raise an alert and the software will begin to impede their site usage until they’re ultimately blocked temporarily, then permanently.

Behavioral scoring allows errors errors to broader or more generic (not signature matches but actual error states like 404s and 500s) because you’re not blocking every single error. By continuously tracking and monitoring and building up a sort of “threat profile” that discerns patterns and indicates misbehavior – even before anything that would match a threat signature is seen.

Whitelist vs. Blacklist = Greylist?

On top of behavioral scoring, we also employ a combination of blacklists and whitelists – a sort of greylist approach.

The signature model is inherently a blacklist approach to security. That means that everything is allowed by default unless it is on a ‘naughty list’ or list of malicious inputs or actions. This is dangerous because the default action is to allow, and only when something is known to be bad is it blocked.

The whitelist approach isn’t perfect either. This is the inverse of blacklisting, where everything is blocked by default unless it’s on a list approved inputs or actions. This might be easiest to think of as analogous to a list at an exclusive club or restaurant. With the whitelist approach only people with their name on the list are allowed in, while all others are turned away. The blacklist approach turns away anyone who is on a disallowed list, and lets everyone else in without discretion.

Here’s an example of one of the whitelists within ServerDefender’s controls. This particular example is not very permissive and shows how broad the controls can be.

Here’s an example of a blacklist in ServerDefender. This shows the specific resources that cannot be requested on a site, with all other resources being allowed.

The whitelist approach is inherently more secure, but more prone to false positives since the default action is block. However, our powerful and easy-to-use method for creating exceptions makes adding to whitelists entirely manageable.

Algorithmic Detection

We also look at a number of factors within a given user input and determines if there is an exploit contained in it. This is the algorithmic type of rule. It’s not based on a specific signature or set of signatures. Instead it looks for conditions that have to be met for a particular type of exploit to be effective, and blocks when those conditions are met. This makes it much more generic than signature based rules.

This does increase the false positive risk, so again, you do need good exception-management. This is something we built into ServerDefender in order to quickly loosen security controls for something very specific, while not compromising the overall security of the app. Plus, it is much more manageable to apply these occasional exceptions than to build up fully accurate whitelists field-by-field for an entire app, and keep them up to date as code changes.

Find the log for your false-positive by either entering the event ID, or filtering down to a specific set of parameters. Right-click and select ‘Add Input Exception’.

The add exception dialogue let’s you specify name, comment, what criteria to match, and the restrictions to make.

This allows errors to be broader or more generic (not signature matches but actual error states like 404s and 500s) because you’re not blocking on every single one. But if you track and build up a score or profile you can discern patterns that indicate misbehavior, even before anything that would match any actual threat ‘signature’ is thrown at the app. (e.g., too many ‘innocent’ looking errors from the same source, or with too great a frequency).

Philosophy

Signatures may make for a great business model, but they don’t make for a great security model. Signatures don’t account for unknown vulnerabilities, and are too easily bypassed in today’s world of advanced hackers. Our approach is and has always been to create tools that provide real security through algorithmic analysis and distrusting inputs.

If you have any questions about our approach to security, please feel free to reach out to our team. We’d love to chat!

1 Comment »

The Problem with Signature-based Web App Security

Posted: January 29th, 2015 | Filed under: IIS & HTTP

In the real world we have the benefit of being present and able to see and analyze scenarios in real-time. In the cyber world, we rely on code and algorithms to handle millions of complex tasks every day without much real-time human intervention. Unfortunately, one of the tasks that we leave in the hands of technology is web security.

This is a problem because unlike humans, code and algorithms cannot decide what is good and bad. Not from a philosophical moral perspective (humans still struggle with that), but from a security standpoint. In order for web security tools to know if a user is doing something bad it needs to be programmed to know what specifically to look for. The way that many tools know how to detect malicious actions or activity it by using attack/threat signatures. This may make for a great business model for those who sell such products, since they can sell signature updates, etc, but it makes for a dangerous security model.

What are signatures, anyway?

So what are signature-based rules, exactly? One way to envision them are as a glossary of different threats that a security tool can reference to know whether or not it should take action against inputs. A signature is typically based on an exploit that has already occurred and has been documented. The signature details the way that the exploit works using a series of parameters to indicate the specific actions that occur during the exploit.

This model depends on matching inputs to a specific signature in order to block them. This can be likened to taking a fingerprint of someone who wants access to something and comparing it against a database of fingerprints of known criminals. This will work great for stopping frequent criminals, but will never stop the first-time offenders.

Example rule:
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/
|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'8',accuracy:'8',capture,t:none,t:
htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:
'Cross-site Scripting (XSS) Attack',id:'958016',tag:'OWASP_CRS/WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

The problem with security tools that rely on fingerprint matching is that fingerprints are unique, and the fingerprints for attacks that haven’t happened yet don’t exist. That leaves a gaping hole in these tools ability to provide security.

Good luck stopping zero-days!

Since signatures only account for what has already been seen, they don’t do anything to account for what has yet to be seen. When a new, never-before-seen, zero day comes along the tool won’t find any matches in the signature database. Only after the exploit has been observed in the wild will vendors update their signature lists and send out an update to customers, who then typically need to add the update.

Yes, protecting against the known vulnerabilities that many script kiddies will try is indeed valuable. However, the script kiddies don’t pose the same threat as a well-trained hacker or even a hacker who possesses knowledge of a zero day vulnerability. Without any protection against new or unseen attacks, signature-based tools leave a wide attack surface that needs to be accounted for another way.

Signatures Everywhere!

Many organizations use automated security scanners to find vulnerabilities in their apps, and in turn can update their WAFs with the information learned from the scanner. So if the scan finds vulnerability ABC, then the security rules for that vulnerability can be automatically for the WAF to import (this isn’t the case with every tool, but is a feature than many tools highlight). The problem is that the scanner is using heuristics to find the vulnerabilities in the first place. Herein lies the vicious circle of signature-based security and the illusion of security.

 

Vulnerability scan run with signature-based tool > Rules created from scan > Rules imported into security tool > New scan rules released, prompting rescan >

 

With this type of system in place, you’re never really achieving protection against anything other than known vulnerabilities. It’s like basing all flight security off of the do-not-fly list, but not knowing you can/should stop the person with a dangerous looking item for – at the least – a further inspection.

Another issue with this approach is the constant need to update the rules. Not only does your security depend on a rule existing, but it also depends on you updating the rules (unless rules update automatically) immediately upon release. A breach could come down to: no rules existing to stop an exploit, or you not updating the rules in a timely manner.

A different approach

There are alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

The signature approach is so common that when people come to evaluate our Web application firewall, ServerDefender, they often are confused by its non-use of signatures. People often ask, “Well, if it doesn’t use signatures, then how is it providing protection?” and “How often do you update signatures? And are they free?”

There are indeed alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

Curious to see what our approach is? Learn about our innovative – signature-free – approach to application security.

1 Comment »

Exploring the LogViewer in ServerDefender VP

Posted: November 15th, 2014 | Filed under: IIS & HTTP, Web and Application Security | Tags: , , , , , ,

Security You Can See

For the least few years, we have been developing ServerDefender VP, an advanced Web application firewall for IIS. One of the features that has been evolving along with ServerDefender VP is the LogViewer. This is the hub of the WAF where users can interact with and monitor malicious traffic hitting their site. Since there is so much to do within the LogViewer it sometimes becomes easy for a feature or two to be missed, so we’ve decided to explain some of the cool tricks its capable of.

What is the LogViewer?

The LogViewer is a tool that visualizes events (blocked threats and errors) that occur in your application and allows you take a variety of different actions on them with only a few clicks. When selecting an event users can see an array of data that pertains to it such as the referrer, user-agent, IP address, session ID, GET and POST data, and other critical information.

ServerDefender VP Web app firewall LogViewer

Click to enlarge.

What Can Actions Can I take on an Event?

There are several different actions that a user can take on an event in the LogViewer. The primary actions are for security settings (blocking IP addresses and creating exceptions), forensic tools (viewing all events by IP, comparing a session against IIS logs), and exporting reports.

ServerDefender VP LogViewer Actions

Click to enlarge.

Adding Exceptions

One of the key actions available to users from the LogViewer is the ability to add an exception to event, such as a false positive. Adding an exception on an event lets users specify new settings should the same event occur. This means that users can tell a blocked action to be allowed and configure new rules for the future.

ServerDefender VP Input Exception

Click to enlarge.

Forensics

The LogViewer’s forensic tools enable users to gain further knowledge about an event and the session and IP behind it.

“View This Session in IIS Logs” displays the session logs with errors recorded by ServerDefender VP highlighted. This feature is useful to determine what occurred in a session prior to an error occurring and establishing the validity of an error, should there be any questions around it.

“View this IP Only” displays only the events in the LogViewer attributed to that IP address. This makes it easier to visualize the actions of a single IP address and understand its patterns, which can help users determine if the action they should take against the IP, if any.

Questions for Us? Ready to try?

The LogViewer is a powerful tool for viewing malicious traffic in your app and way to quickly react to events. If there’s anything else you’d like to learn about the LogViewer – or ServerDefender VP in general –  send us an email at info@prot80software.com or Tweet us @port80software. If you’d like to enjoy a 30-day free trial, go ahead and download now.

No Comments »


Patch Now: Schannel Vulnerability Poses Huge Threat

Posted: November 13th, 2014 | Filed under: IIS & HTTP

A critical vulnerability in Microsoft Schannel headlined the security bulletin released by Microsoft for November. The vulnerability is the latest in TLS vulnerabilities for 2014, and means that every major TLS stack has been impacted by a severe vulnerability this year alone, as reported by Ars Technica. The Schannel vulnerability is drawing comparisons to Heartbleed, as it similarly allows for remote code execution and data theft.

Needless to say, it is imperative that affected systems are patched immediately.


Microsoft Security Bulletin MS14-066 – Critical – Find & Install Patch


Secure Channel, also known as Schannel, is the standard security package used by SSL/TLS in Windows. The Schannel vulnerability impacts all versions of Windows dating back to Vista/Windows Server 2003.

After the Bash and Poodle Vulnerabilities earlier this year, we should not be surprised to see a vulnerability that has gone unpatched for an extended period of time. This vulnerability just underscores the fact that even very mature software may have serious bugs from time to time.

The complete November security bulletin can viewed here.

Looking for more details about the Schannel vulnerability (MS14-066)? Read More

No Comments »