Skip to content

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 »

POODLE SSL 3.0 Vulnerability: What it is and how to deal with it

Posted: October 17th, 2014 | Filed under: IIS & HTTP

 

from our friends at Net-Square

A Vulnerability known as POODLE, an acronym for Padding Oracle On Downgraded Legacy Encryption, is making headlines this week. The bug is a vulnerability in the design of SSL version 3.0, which is more than 15 years. However, SSL 3.0 is still widely supported, and nearly 97% of SSL servers are likely to be vulnerable to the bug, according to an October Netcraft Survey.

SSL v3.0 Vulnerable Servers

 

This vulnerability allows an attacker to intercept plaintext data from secure connections. Since SSLv3 has been quiet famous in the last 15 years it has put literally millions of browsers in jeopardy. As the chart above indicates, this is a vulnerability that has a sweeping impact.

How it happens?

Though users are upgrading to latest SSL versions (TLS 1.0, 1.1, 1.2), many TLS versions are backward compatible with SSL 3.0, hence when web browsers fail at connecting on these newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they may fall back to the older SSL 3.0 connection for a smooth user experience.

The other possibility is, a user is forced to step down to SSL 3.0. If an attacker has successfully performed a Man In The Middle attack MITM and causes connection failures, including the failure of TLS 1.0/1.1/1.2 connections. They can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. Due to this down shift of the protocol the connection becomes vulnerable to the attack, eventually exploiting and intercepting user’s private data.

Google’s Bodo Möller, Thai Duong, and Krzysztof Kotowicz published the complete security advisory which can be found on openssl.org.

Possible remediation

To avoid falling prey to attackers exploiting POODLE, avoiding the use of public Wi-Fi hotspots, if user is sending valuable information (using online banking, accessing social networks via a browser, etc.), and noting this is always a risk, but the Poodle vulnerability makes it even more dangerous.

The other recommendation is disabling SSL v3 and all previous versions of the protocol in your browser settings and also on the server side will completely avoid it.  SSL v3 is 15 years old now and has been superseded by the more up-to-date and widely supported TSL protocol, supported by most modern web browsers.

DigitCert published a detailed step-by-step guide for disabling SSL 3.0.

Richard Burte also shared the command lines to disable SSL 3.0 on GitHub.

No Comments »

Zero-Day Vulnerability (CVE-2014-4114) in Windows Server Exploited by Russian Espionage Group “Sandworm”

Posted: October 14th, 2014 | Filed under: IIS & HTTP, Web and Application Security

 

A Russian espionage group is exploiting a zero-day vulnerability in Windows Server 2008 and 2012, iSIGHT Partners reported on Tuesday. Microsoft is currently working on a patch for the vulnerability (CVE-2014-4114), but a number of targets have already been hit.

When exploited, this vulnerability allows an attacker to remotely execute arbitrary code, but requires a specially crafted file and use of social engineering to convince a user to open the file. iSIGHT noted specifically that PowerPoint files were used to exploit the vulnerability.

While there are specific targets that have been named, iSIGHT is also quick to point out that the visibility of the attack is limited and there is potential for broader targeting beyond this group of targets. The known targets include:

  • NATO
  • Ukranian government organizations
  • A Western European government organization
  • Energy sector firms (specifically in Poland)
  • European telecommunications firms
  • An United States academic organization

The team behind the attacks was dubbed the “Sandworm Team,” based on encoded references in command and control URLs and malware samples that refer to the sci-fi series Dune. iSIGHT reported that it has been monitoring the Sandworm Team since late 2013, and believes they were formed sometime in 2009.

Geopolitical Tensions Creating Targets

The takeaway here seems to be that the attacks do not only target governmental entities. The Sandworm Team has instead targeted entities that are geopolitically relevant in a broader sense: energy, telecommunications, education.

This should serve as a sign of potential threats to come. Private sector businesses that are strategically sensitive in a geopolitical sense might be on some state’s list of targets. This means organizations that share information with, provide services to, or provide infrastructure utilized by governmental organizations may be at risk. State-sponsored attacks will focus on targets with strategic significance which can range from obvious ones like power grids and financial institutions to less obvious targets like research universities.

State-sponsored attacks are on the rise and the targets are becoming broader. Organizations who align themselves with sensitive entities should have a heightened sense of awareness and look to raise their defenses if needed.

We will update this post accordingly as the story continues to develop.

No Comments »

Takeaways and Questions from the Home Depot Data Breach

Posted: September 18th, 2014 | Filed under: IIS & HTTP

One of the main goals of spending time and money to implement information security is to make it difficult for hackers to get in and data to get out. When ‘hackers’ compromised Home Depot and stole upwards of 60 million credit card numbers recently, it wasn’t all that difficult.

The breach, which could be the largest in US history, occurred after a piece of malware (possibly the Backoff malware) made its way onto the point of sales at numerous Home Depot stores. When customers swipe their card at checkout, the card data was captured and sent back to a server. If this sounds familiar, that’s because this is the same technique that was used in the Target breach last December.

A line that is being repeated in news and blogs is that the hackers didn’t do anything terribly complicated or anything that required a ton of hacking skill. Lines like this usually only come out of incidents that were caused by carelessness or ineptitude. Hacking a major corporation’s POSs shouldn’t be easy; it should be hard. Stealing 60 million credit card numbers shouldn’t be easy; it should be hard. We don’t yet know all the details behind the breach, but we certainly have learned some takeaways:

  • Malware is still a potent threat - Threat signature based antivirus is not capable of detecting new types of viruses or malware. Since antivirus and anti-malware depend on signature databases to detect and eliminate threats, new threats often go unseen until an incident occurs. This leaves a huge blind spot in organization’s security infrastructure. However, this may not have been the case with Home Depot. As reported by ThreatPost, BackOff isn’t a complex Windows Trojan, it’s just re-purposed to run on a Windows-based POS and therefore should be detected by antivirus. This means that Home Depot either did not have antivirus in place or it was not updated – either scenario is bad. That leads us to our next takeaway.
  • We don’t learn – This same style attack just occurred to a major U.S. retailer and was all over the news. Everyone knew about this attack – especially IT and security people – and yet the same style of attack was even more successful in the Home Depot incident. The lessons learned from Target should have raised guard enough to at least make sure that antivirus was properly installed on the servers managing the POS machines and updated regularly. Symantec has specifically addressed how its software detects point-of-sale malware, and many antivirus vendors were quick to add signatures for BackOff variants after they were discovered.  In this instance, the vendors appear to be doing their part, but Home Depot seems to have failed to protect itself.
  • No PINs stolen, but that doesn’t matter - In a report issued by Home Depot they stated: “While the company continues to determine the full scope, scale and impact of the breach, there is no evidence that debit PIN numbers were compromised.” But unfortunately that doesn’t matter. As Brian Krebs reported, the method of PIN reset is so out of date that even a stranger can reset your PIN with enough personal information simply by using the automated voice system:

“Countless banks in the United States let customers change their PINs with a simple telephone call, using an automated call-in system known as a Voice Response Unit (VRU). A large number of these VRU systems allow the caller to change their PIN provided they pass three out of five security checks.”

  • Where does cybersecurity insurance come into play? Business Insurance reported that Home Depot has $105M in cyber insurance to cover data breaches. Cyber liability insurance is a growing industry with the threat for seriously damaging  data breaches making growing more and more. This begs the question: will organizations lean too heavily on insurance policies rather than implementing better security policies? That isn’t to say that Home Depot did this, but one has to wonder if cyber insurance will provide executives a level of comfort that will detract from investing in proper security.

Every breach that occurs is unfortunate, but it’s also a chance for everyone to learn and avoid potentially critical mistakes in the future. What do you think some of the major takeaways or questions coming out of the Home Depot breach are?

No Comments »