The new owners of the acquired HIPS products never improved to address today’s threats.  Designed to address the malware for Windows 95 and Windows 2000, these HIPS products stayed frozen in time.  As Windows evolved over a decade, with Vista and Windows 7, Microsoft introduced new protection capabilities including DEP (Data Execution Prevention), ASLR (Address Space Load Randomization), preventing arbitrary code execution in exception handling paths, and UAC. After all these changes, HIPS’s decade old defenses primarily developed for Windows 95 and Windows 2000 era malware became irrelevant. As the Windows protections improved, HIPS solutions were helpless and useless in tackling new generation malware that no longer needed local administrative rights to cause damage.

HIPS products were too focused on the antiquated application anomalies of the Windows 2000 era and on unpredictable application behaviors. This resulted in per application tuning of rules, false positives, and asking users to make advanced security decision through pop up dialog boxes. Rules and exceptions needed to be formed per application.  As the applications needed updating this created a tremendous burden on administrators to manage the thousands of applications on a day to day basis  The millions of events generated on a  daily basis paralyzed administrators of even the smallest of deployments.

THE MYTH OF WHITELISTING AND THE NEED FOR THE NEXT GENERATION OF WHITELISTING

Today, the same experts led us to HIPS Cul-de-sac are now telling audiences that the traditional White Listing is the silver bullet for malware defense. Although HIPS and the traditional White Listing are vastly different technologies, they both have the same weakness: both have significant administrative overhead for day-to-day operations to a point that the management of the product itself becomes central point as oppose to protecting the enterprise. While HIPS administrators had to worry about constantly tuning HIPS rules, traditional White Listing products require administrators to be concerned about software updates and security patches and ensuring new signatures are available to end points before the patches and updates can be applied.
The traditional White Listing solutions rely on a myth that if an application is signed and approved, the application is safe. Today malware can easily highjack perfectly legitimate and signed White Listed applications in run time. The high jacked application can encrypt user’s data and ask for ransom for an encryption key. A high jacked application can “migrate” to another perfectly White Listed application by altering Windows registries, by performing code injection, or by modifying the memory of a running process. Or a White Listed application could peek into the memory of an important financial application to steal financial data or steal content of user’s files by reading and uploading to a server on Internet.

THE NEXT GENERATION SOLUTION

Enterprises and consumers deserve to have better protection to confront today’s ever evolving malware. One that offers the dynamic White Listing that not only worries if the application is genuine to start but also protects the application in run time from being high-jacked. Draconian techniques used by HIPS and traditional White Listing solutions are not usable. The next generation solution should not hinder users from downloading and running applications of their choice.  Nor should they need to worry about if a downloaded PDF or Word document has malicious content. Next generation solutions should provide users with freedom yet protect the entire system from user downloaded content or user downloaded programs.

Application Whitelisting is a Pre-Launch Control, Allowing/Denying Application Launches

Application whitelisting determines what may launch, suppressing anything else, including malware missed by AntiVirus. This stops malicious code attacks without dependence on the hopeless race to update signature databases as rapidly as cyber criminals create and/or re-craft malware with different “fingerprints”.

Pre-Launch Application Controls Alone Miss Sophisticated Attack Vectors

All applications have inherent vulnerabilities. Malicious code attacks exploit these vulnerabilities, effectively hijacking an application. These hijacked applications are coerced into downloading and launching a malicious executable, which either installs persistent malware or conducts malicious operations itself. Pre-launch application controls typically block these launches.

However, more sophisticated attacks do not rely on launching an executable. Instead, they either coerce the hijacked application itself to do the work or they conduct memory code injections that essentially transform other whitelisted applications into something else. Pre-launch controls do not stop these attacks.

Whitelisted Applications Cannot be Trusted, Post-Launch Controls Are Needed

With commonly whitelisted applications such as Adobe Reader frequently getting exploited in many different ways, one can see why applications cannot be trusted after they launch. Application post-launch controls are needed to prevent them from harming computers. Such controls primarily block write operations to a relatively small list of common targets, which seldom changes. Hence, administration can be easy and a major protection gap in application whitelisting is closed. Look for controls that do not need to know in advance the DLLs used and the executables spawned by applications.

Executive View: Simplify Whitelisting by Dividing it into User-Space and System-Space

• System-Space: operating system, Windows registry, 3rd party software, etc.
• User-space: user’s documents, ‘Desktop’, and some software such as GotoMeeting

Over 95% of the effort to deploy a typical whitelisting product is spent enumerating and updating the system-space whitelist (i.e., what may launch). The user-space whitelist is trivial in comparison, typically less than a dozen applications and trusted publishers (i.e., allow launches of executables signed by specified software publishers). If only user-space had to be whitelisted, then deployments could be easier than enterprise email administration.

Combined Pre/Post-Launch Controls Slashes Level of Effort, Increases Protection

The net result of combined pre-launch and post-launch application controls can reduce the required level of effort to less than 10% of that of typical whitelisting products. User-space whitelisting requires less than 5%. Post-launch controls require less than 5% also. This combination actually yields a net improvement in protection assurance from even the most sophisticated, targeted malicious code attacks facing the enterprise today and tomorrow.

What if System-Space is Compromised Prior to Deployment?

If malicious code is already in system-space, then it is almost certainly rootkit malware. Third generation rootkits, are practically undetectable and are a preferred tool in targeted enterprise attacks. If attackers can penetrate system-space, then they are motivated to use third generation rootkits. Even system-space whitelisting with binary file hash checksum integrity checks are ineffective. There are promising possibilities in the future but none exist now. The executive bottom line: the operational cost of system-space whitelisting far outweighs its value in comparison to solutions that effectively combine pre-launch and post-launch controls. Prevention is critical!

Gartner has Identified Blue Ridge as an Emerging Vendor in Application Whitelisting and Control

Our advocacy of emphasizing usability in the application of cyber security is paying off. Customers can deploy and administer AppGuard Enterprise, with its pre-launch and post-launch controls, at a fraction of the effort of other application whitelisting products, yet with greater effective protection. Those that also need to monitor and enforce endpoint security postures on and off the enterprise can find all that integrated in our AppGuard Enterprise Plus centrally managed software. Both AppGuard Enterprise and AppGuard Enterprise Plus support domain and non-domain Windows computers. All of these capabilities are available as a Managed Endpoint Security Service.

The highly publicized and vaunted Stuxnet attack on Iranian nuclear infrastructure computers consisted of four exploits in a single package.  Most consumer and even targeted enterprise attacks only use one.  Some use two attack exploits.  More on that later.  Attacks with one or two exploits are typically quite sufficient for cyber criminals because the vast majority of consumer and enterprise computers are protected by software and/or network appliances that rely on virus signatures and heuristics.  These technologies limit protection to stopping malware that has been seen before by anti-virus vendors.

Cyber criminals employ easy to use software called ‘malware kits’ that alter the appearance of attack code.  The result is unsettling.  Against malware samples a week or less old, Cyveillance measured an average detection rate of just 19% for AV products.  AV-Comparatives conducted a similar test that also included heuristics, which have similar limitations.  They reported a rate of 44%.  Both used actual samples found in the wild, meaning something must have detected them.  Secunia took a different approach using unique malware samples that it created, resulting in a detection rate of under 10%.  This has caused a shift towards post-infection detection, making those AV full scans that typically run at night increasingly too important to ignore.  So, keep those PCs on at night!  This alone won’t solve the problem.  There are more and more polymorphic malware code available for sale on the black market.  This stuff changes itself periodically to avoid post-infection detection.

Check out more endpoint security articles here.

Do you know what percentage of your reported AV detections are from full scans versus real-time detections?  How long were these full scan detected infections running?  What is the average, highest, and lowest number of days between full scans for your computer population?  How often do you scan a statistically significant sample of your computers with a boot AV product to test your security posture?  These questions and others were very important long before Stuxnet was reported.  However, Stuxnet means that infections can be a lot more lethal.

Stuxnet and the ensuing copy cats are lethal because they include at least a second attack code binary that exploits a privilege escalation vulnerability.  These vulnerabilities don’t always get a high priority in patch management because many don’t consider them a major risk alone.  But combined, they enable the attackers to dig deeper into a targeted PC, rooting malware such that no host-based software can detect it (i.e., 3rd generation rootkit).  Stuxnet included not one but two privilege escalation exploits in its cocktail so they could systematically compromise any computer.

Stuxnet featured another aspect that is relevant to enterprises in many but not all industries.  It sought to hijack control software made by Siemens, presumably to damage costly nuclear infrastructure run by Iran.  This was probably accomplished this via inter-process code injections into the control software from malware running in the same PC.  This does NOT require that there be a vulnerability (i.e., programming mistake) in the control software; Windows APIs facilitate this routinely.  Very few security products effectively block these inter-process code injections either because they cannot or they are too disruptive and complex.  Inter-process code injection attacks effectively transform an application into something else, or selectively alter its behavior.  The latter requires sophisticated analysis of the targeted application’s idiosyncrasies and is uncommon but increasingly affordable in the cyber crime world.  Stuxnet-like threats are particularly relevant to energy/utility industries, which can suffer serious damage to their infrastructure.  Healthcare and manufacturing face similar risks.  In addition the already widespread online banking fraud per Banking Trojans, Stuxnet-like malware can readily compromise enterprise financial systems.

The Enterprise Needs Another Layer of Protection in its Security Posture

There are a variety of products from many vendors that might stop Stuxnet attacks. Forget about host intrusion prevention system (HIPS) standalone products or HIPS features included in an endpoint security software suite.  Deployed HIPS features/products are either disabled completely or severely under-utilized because they are too complex and disruptive.  The much hyped Aurora attacks on three dozen large enterprises in early 2010 reportedly included Symantec according to the Washington Post.  If Symantec isn’t using its HIPS capabilities to effectively stop attacks, then forget HIPS.  Many folk have, including Cisco, which end-of-lifed its HIPS product.

Application whitelisting products show greater promise than HIPS products.  Still, there are some points that IT personnel should consider.  First, what is the level of effort required to enumerate all of the things on a PC that may launch (i.e., run)?  Commercial whitelists help administrators with the daunting task of enumerating what we call pre-launch controls.  Even so, creating and maintaining whitelists for the system-space (i.e., Windows and Program Files directories) is far from a trivial effort.  Seek explicit level of effort quotes from organizations that have done this.  Second, look for application whitelisting products with post-launch controls.  As mentioned earlier, applications can be hijacked and coerced to do harm.  We cannot trust our software applications!  A few application whitelisting products provide what some call ‘write protection’.  This means that the files that make up the whitelisted applications cannot be altered.  Further narrow your search by choosing from these few that not only ‘write protect’ whitelisted ’stuff” but also prevent the addition of unknown files/code into system-space.  Third, choose a product whereby both its pre-launch and post-launch application controls are enforced by kernel-level mechanisms.  Fourth, your choice must include post-launch controls that block malicious inter-process code injections as well as block modifications to critical system resources such as the master boot record (MBR).

A point worth repeating: the level of effort to deploy and maintain is extremely important.  In deploying an application whitelisting and control product, one is NOT replacing existing security assets (e.g., anti-virus/spyware, firewall, intrusion detection/prevention, patch management, endpoint security policy enforcement, data loss prevention, information asset inventory systems, next-generation firewall, etc.) but adding an additional layer.

Why AppGuard Enterprise is Probably the Easiest and Most Effective Application Whitelisting and Control Solution

The default AppGuard Enterprise policy blocks a Stuxnet-like attack.

Over 90% of the effort required to maintain application whitelists (i.e., pre-launch controls) involves enumerating what may run in system-space.  AppGuard Enterprise radically diminishes the importance of doing this for system-space because of its extensive post-launch application controls.  Administrators still must define whitelists for user-space (i.e., where least privilege users/processes can write).  Such lists are 1000s of times smaller than system-space whitelists, typically just a few items per policy group.  Next, administrators need to view the results from a process audit that identifies applications in use that are not subject to AppGuard post-launch controls.  These prevent an application and any executable/process it spawns from harming the PC.  They also can prevent an application from stealing sensitive documents in user folders designated private.  So, assume the audit identifies a half-dozen applications in use that are not ‘guarded’.  Adding these to the ‘guard list’ merely requires their full path name.  However, not all of these applications even need to be guarded, though you can.  Essentially, one only needs to guard at-risk applications such as web browsers, email, popular productivity software (e.g., MS Office), media players, instant messengers.  But most of these are already on the ‘guard list’ by default.  Defining the pre-launch and post-launch controls for a policy group can literally take just a few minutes. And, this combination of pre-launch and post-launch controls yields more robust protection from malware and other data loss risks.

In just one phone call, we can define a highly effective protection policy for an organization as a managed service or just a free trial before doing it yourself.

Centralized Firewall vs Firewall-per-Store for Retailers

A centralized firewall for an array of stores is applied when they operate as a closed system. A closed system implements a block-all policy whereby all inbound and outbound data traffic is discarded except for explicitly specified exceptions: a ‘white list’. This benefits retailers by ensuring that unknown data traffic flows are eliminated, allowing only those approved.

Firewalls deployed at each site can be configured in a default-deny manner as well. However, they cost retailers more in hardware and operations (e.g., configuration and patch management). Even in managed services, these costs are passed on to the retailer one way or another. And, more managed firewalls means more potential for configuration mistakes.

Blue Ridge implements a closed-system via our VPN technology that we developed for military and other national security organizations over 15 years ago. It is far in the way the most time-proven VPN solution commercially available. However valuable one considers the various government certifications our VPN solutions have achieved, the most important metric is the fact that there have been no reported vulnerabilities or security breaches in all this time. This unrivaled record is absolutely attributed to the technology. We would be delighted to explain the cryptographic differences between our technology versus those developed by all other vendors.

Download our ‘Retailer Network and PoS Security Overview’

Public IP Addresses vs Private IP Addresses

PCI compliance requires periodic scans of all publicly addressable IP addresses in a retailer’s network. A third party must conduct these scans. The price they charge retailers is based on the number of public IP addresses within the scope of the PCI. Retailers save money by reducing the number of nodes that fall within the scope of this PCI requirement.

Blue Ridge significantly reduces this scope with the VPN appliances that it deploys at each store. These devices use whatever private IP address they dynamically acquire from whatever ISP router is at each store. The ISP router is considered ‘out of scope‘ because the VPN appliance represents the line of demarcation between what falls within and without of PCI scope. Retailers can gain some additional savings by not having to pay for public IP addresses from the various ISPs and carriers.

Blue Ridge is not unique in offering VPN appliances that operate with private IP addresses. However, all of the implementations by other major vendors require something called ‘Dynamic DNS’, which is easily susceptible to denial of service attacks. And, we know of at least one major vendor whose implementation is subject to more serious security vulnerabilities that can enable cyber criminals to crack their encryption. That said, we know of no publicly reported security breaches of this kind.

Download our ‘Retailer Network and PoS Security Overview’

Secure All of a Retailer’s Customer Data Traffic vs Just PAN Data Traffic

Other customer data will eventually be covered under PCI. Numerous reports from the security industry tell of cyber criminals stealing more than just primary account number (PAN) data. PAN data is the primary focus of PCI. Cyber criminals can sell PAN data at a higher price if accompanied by other customer data that facilitates data theft. We expect that the PCI Council will be compelled to expand the scope of PCI to include this other customer data. As retailers deploy new or upgrade existing store IT services and execute PCI compliance tasks, they should identity other sensitive customer data vulnerable to theft and consider securing that data before the PCI council mandates it. The incremental cost of securing this other data while doing so for PAN data can be trivial. However, retrofitting such additional security can be considerably more costly.

Blue Ridge has spent most of its 15 years serving customers that are high-value targets in government, military, finance, healthcare, and others. When it comes to high assurance security providers, there are those that ‘play it on marketing content’ and those that live it. Blue Ridge develops its own network appliances and computer security software in-house because most commercially available tools are too operationally complex to operate and they fall short of our high assurance security standards.

As Hanover Foods, TJ Maxx, Forever 21, and others can attest, mere PCI compliance does not equate to high assurance security. And with Blue Ridge, high assurance security does not equate to an unaffordable solution.

One Network Segment per Store vs Multiple Segments

Retailers can significantly reduce their PCI compliance costs through network segmentation. Consider all of the different devices in a store. Perhaps two to five of them handle PAN data. None of the others do. If all endpoints are on the same network segment, then all must be PCI compliant, and retailers must prove this is so.

As of now, PCI compliance only concerns PAN data. Therefore, retailers should create at least two network segments per store: one for point of sale (PoS) machines, and the other for all else.

Download our ‘Retailer Network and PoS Security Overview’

Single Vendor, Multiple Solutions vs Multiple Vendors with a Single Solution Each

Retailers are faced with network, network security, and computer security issues. They must ensure that the ‘data gets to payment processing on time’ by selecting ISPs/carriers that deliver the most bandwidth reliably and for the most value. These transports must be managed in real time and issue resolution often involves proving to an ISP/carrier that they are a fault. This ‘data in motion’, at least the PAN data, must be encrypted, which may or may not involve another service provider. The PoS machines in each store must be PCI compliant and free from malware. So, endpoint security represents another area requiring solutions.

Blue Ridge Retail Solutions cover all of the above. If anything goes wrong, its our job to fix it 24 x 7. In providing holistic solutions that cross multiple IT disciplines, we have been developing synergies and continue to do so between our network security appliances and computer security software. They can be inter-dependent, or simply exist in one because it offers a better approach than addressing it in the other.

Wi-Fi Risks: Detection vs Prevention

The first example of a synergistic solution was inspired by one of our retailer customers concerned with rogue Wi-Fi devices. PCI compliance requires quarterly Wi-Fi scanning of stores. Blue Ridge does not and probably never will offer Wi-Fi scanning for this purpose. Conducting such scans creates ineffective data analysis work, costs retailers thousands per year, and ultimately does not prevent data theft. Continuous Wi-Fi scanning with 24 x 7 alerts would be effective. But these services cost considerably more than quarterly scans.

Blue Ridge developed an enhancement to our computer security software, which runs in our customers’ Windows-based PoS machines to enforce PCI compliance settings and block malware attacks. The enhancement makes the presence of a rogue device irrelevant, Wi-Fi or not. It does so by leveraging its kernel-level control over the PoS to ensure that only the payment application software can access PAN data. In other words, even a rogue software process running with local admin rights on such a PoS machine cannot access the PAN data. This means that a rogue device or a rogue store clerk are prevented from accessing the PAN data. Protecting other customer data too is just a policy rule change to us and retailers.

And remember, PCI compliance requires that payment applications encrypt data transmissions. So, if a rogue software process can access the data, and a rogue store clerk cannot, and a rogue Wi-Fi device cannot, then Blue Ridge is preventing the problem at far less cost to retailers than reacting on a quarterly basis to Wi-Fi scanning reports.

Download our ‘Retailer Network and PoS Security Overview’

PoS Protection from Malware: Traditional AntiVirus Software Only vs Adding Zero-Day Protection Software

Any breach of PAN data, or any customer data, is a nightmare to any retailer, regardless of whether a PoS machine was compliant or not. In tests after tests after tests of AntiVirus products, laboratories are reporting that traditional signature-based antivirus products, essentially what nearly all retailers have, detect an average of about 20% of new malware attacks. When labs throw in some heuristics features, average detection rates double to around 45%. After 30 days, average test results on the same malware samples improve to almost 60%. Antivirus vendors enable optional features in their products for lab tests they sponsor, which achieve test results over 85%. But, security industry experts say that these features are generally too complex to use in the field, saying nearly all enterprise organizations use nothing but the default settings, even the vendors themselves. Unfortunately, many vendors get away with sponsoring lab tests where their product is tested against large amounts of old malware (more than 3 months) to inflate their detection rate.

The bottom line is simple: the antivirus software found on retailer PoS machines has at best a 50-50 chance of detecting a malware attack when it happens. For machines not running with local admin rights, their antivirus software may later detect and remove the malware weeks or months later, after it has stolen every customer records that traversed that machine. Retailers ought to be demanding better!

Blue Ridge offers computer software either as a managed service or as something retailers can manage themselves. Our AppGuard Enterprise Plus and AppGuard security software delivers nearly 100% protection from malware attacks without distracting store clerks from their jobs.

PCI compliance seems to require traditional, signature-based, antivirus software, despite lab test results. Our security software is compatible with almost all of the antivirus products that a retailer is likely to be using. Retailers can reduce costs by replacing expensive, name-brand antivirus with less expensive, sometimes more effective alternatives. Even if the less expensive is less effective, our software stops what it misses. More savings can be realized when the PCI Council rules on whether retailers may use newer, more effective anti-malware technologies in lieu of traditional ones.

Download our ‘Retailer Network and PoS Security Overview’

Managed Services vs Self-Managed

Perhaps this is the biggest benefit for you.    There is only so much time in the day, but there are many projects.   We can allow you to focus on your sales while we handle all of the above.  Our pricing includes this AND the equipment which should save you money in the long run and let you get more done.

Learn More about Blue Ridge Retail Solutions

Download our ‘Retailer Network and PoS Security Overview’

877-528-2823

There are millions of “parked” websites.  Visitors reach them by arbitrarily typing in a URL, misspelling, clicking on an erroneous link, or clicking on a search result link.  Firms such as Network Solutions Inc. will host these “parked” websites, placing advertisements and other stuff on them.  In this horror story, a Javascript “widget” called “Small Business Success Index” was hosted on these “parked” websites.  This had been altered by attackers to launch drive-by download attacks on visitors, exploiting zero day vulnerabilities in either Internet Explorer or Adobe Acrobat/Reader.  Network Solutions Inc asserts that its in-house investigation has found no examples of its hosted live websites carrying this nasty “widget”.  They dispute reports of 500,000 to 5,000,000 affected URLs, saying the figure is around 120,000 known.  Network Solutions has removed all known instances of the widget and has issued an advisory to all others to remove the “widget”.

Victims fell prey to an ordinary drive-by download attack where simply visiting a web page was all that was required of the end-user.  Once there the “widget” served an exploit of either an Internet Explorer or an Adobe Reader/Acrobat vulnerability.  This would result in Internet Explorer or Adobe Reader/Acrobat placing a “downloader” application in the visitors PC, somewhere in “user-space”.  Drive-by download attacks usually place their “downloader” in user-space because they can always do so.  They can only place the “downloader” in “system-space” if the end-user of the PC is logged in with local admin rights.  Once the “downloader” launches, it will download and install persistent malware best suited for the host and the objectives of those behind the attack.

The less than 50% of the antivirus products that detected the attack characterized it as a generic Trojan horse install or a member of the Koobface worm family.  Researchers have said the persistent malware consists of something called lsass.exe, which monitors web browsing.  When it detects certain keywords, it modifies redirects users to particular pay-per-click advertising sites.  While its doing this job, it also looks to enlist more victims by inserting malware onto file shares and into peer-to-peer file sharing directories.

AppGuard Protected Computers from these Attacks

This was an unremarkable drive-by download attack routinely stopped by AppGuard or AppGuard Enterprise but missed by half of the different antivirus software products on the market.  Depending on how polymorphic this attack code is, the antivirus products that missed these attacks may have signatures to detect them within a month.  Then again, cyber criminals are on to this and discontinuing the use of malware code samples after less than 48 hours to severely reduce the odds of there ever being a signature for detection.  AppGuard closes the gap, whether the vulnerability gap is days, weeks, or months.  AppGuard prevents these malware attacks from operating at all.  This raises a question to computer users living within this gap, what passwords, documents, or other stuff might a cyber criminal want from your computer in a typical one week or one month, or one year time period?  If there’s nothing, then no worries.  If there’s something, then your traditional antivirus is not enough.  You should add something like AppGuard.

Ultimately, the success of any security service hinges on authentication (see this classic post on authentication).

If everything that you depend upon uses some form of authentication to control who may use them, what may they do, where may they do so, etc., then the trivial level of effort to crack passwords affects everything from your email to online banking to any service that you use.  All these undoubtedly have usage controls, which may rely only on passwords for such controls.  As you walk around looking at what others are doing, at the services you rely on, at the tools/software that you use, consider how passwords may be at work in them. Imagine what harm could be done if a criminal controlled these things around you, that serve you, that may even have some control over you.  You’d see why there are so many cyber criminals: because there are so many easy ways to get ahead.

When passwords are required, everyone ought to be using passPHRASES instead, sprinkled with a few odd characters and/or numbers. Government Computer News (GCN) recently published an article on how ordinary video cards are empowering hackers. Combine the article with the notion of a botnet (thousands) of these computers and you thus see the state of the art.

As a ‘high assurance’ security vendor, as opposed to one that just plays one on ‘marketing content’, nearly all uses of authentication in our products are PKI-based. Those of you concerned with HSPD-12 must know PKI: public key infrastructure. It is the strongest form of authentication commercially available. And when employed in a mandatory, mutual manner, it is essentially uncrackable.  Contrast this with one-time pass code authentication (e.g., keyfob that displays six characters), which is only one-way (i.e., authenticates client for server but does not authenticate server for client) and subject to man-in-the-middle attacks.  Arguably, these things do more harm than good with their false sense of security.

At Blue Ridge, we practice what we preach.  The management plane of all our products is secured by PKI. Our remote access VPN and our new EdgeGuard product line are PKI based. The key exchange process for our VPN technology is enveloped within PKI. Even our enterprise software designed to stop zero-day malware attacks that your antivirus cannot…uses PKI to secure policy updates and event logs. Everything we develop is PKI based.

The real value in designing PKI based authentication into tools and workflow processes from the very beginning is how little end-users actually have to see anything PKI. The best security remains convenient and easily understood despite being highly effective. And when customers that have used our products say they didn’t realize our products used PKI, we’re deeply gratified.

Walk away point: look for PKI in all you need. Anything worth stealing that relies solely on passwords is probably cracked already.

What is PowerShell?

PowerShell is Microsoft’s task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with, the .NET Framework.  It is extremely powerful; hence it is aptly named.  Thus, if a malicious PowerShell script is allowed to run, it can do extreme harm.

What Windows Operating Systems Are Affected by this Vulnerability?

Microsoft released PowerShell v2.0 in August 2009.  It is an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms.

PowerShell Vulnerability Enables Attackers to Elude Built-in Security Restrictions

Endowing it with so much power, Microsoft wisely designed it with execution policies to prevent malicious PowerShell based attacks.  By default, execution policies are set by default to “restricted”.  Except for some specific commands, this prevents non-local PowerShell scripts from running.  A more restrictive policy called  “AllSigned” allows only signed scripts to be executed.  They must be from a trusted publisher.  A less restrictive policy called “RemoteSigned” allows signed scripts as well as local ones (i.e., already on the PC).

The crux of the researcher’s work is that these restriction mechanisms can be circumvented.  He presented and demonstrated his findings at the Black Hat and DefCon 2010 conferences.  He’s also released MetaSploit modules.  Cyber criminals are undoubtedly developing and distributing malicious PowerShell based malware attacks that researchers say cannot be stopped by antivirus, HIPS, SRP, or just about any other security software product that you may have on your computer.  Further, the researcher and cyber criminals are working on using PowerShell for process/code injection attacks, which make them even more elusive to security software.

As for security appliances/servers defeating such attacks, they’ll only stop those for which a virus signature already exists.  And as altering attack code signatures is trivial, forget it!

The obvious workaround is to remove PowerShell.exe from computers.  However, this cannot be done for Windows 7 because it is embedded in the operating system.

Expected Attack Vectors

For the most part, PowerShell attacks will piggy-back atop other vulnerabilities that are used to deliver the PowerShell payload.  For example, a vulnerability in Adobe Reader, Internet Explorer, or any other software application on a PC with a vulnerability that enables an attacker to drop a downloader into user-space.  Or, in sophisticated attacks on high value targets, the attacked software application itself is used to execute the PowerShell attack.  This means the following vectors deliver the attack (ordered according to most likely vector):

• Visit a malicious/compromised website
• Open an spiked email attachment seemingly from someone you know
• Insert an infected USB thumbdrive
• Open a document, seemingly from someone you know, with an embedded PowerShell script
• Mount a network drive with an aut0-run attack
• View a network drive, USB drive, or hard drive with a Windows LNK vulnerability exploit (patch issued by Microsoft 3 August 2010, except for Windows 2000 and Win XP SP2)

AppGuard Protects Computers from PowerShell Worm/Trojan Malware

AppGuard has always been capable of defeating PowerShell attacks.  To improve ease of use, the recently released beta of AppGuard (version 2.0.6) blocks PowerShell script (.pn1) launches from user-space by default.  This blocks the most common vector (vast majority) for PowerShell based attacks.

AppGuard Enterprise administrators and as well as AppGuard users can increase protection even more by adding powershell.exe to the ‘guard list’.  Doing so blocks a less commonly used vector whereby an application such as Adobe Reader, Internet Explorer, or others are coerced by an attack to execute a PowerShell script.  This method tends to only be employed by sophisticated attackers on high value targets such as large corporations or government organizations.

As for when the code injection variants of PowerShell attacks strike, the MemoryGuard protection feature of AppGuard blocks them even if all other protection features are disabled.

Beta Participants Get Free Lifetime License for AppGuard Zero Day Protection

Free Lifetime License to Beta Participants, up to 3 PC’s

Vulnerability/Exploit Background

The vulnerability involves those short-cuts most commonly found on a PC’s desktop and application tray. Actually, any short-cut, which is actually a file with an LNK extension, located anywhere, can be used. Most exploits in the wild are found on USB drives, and utilize the Windows Auto-Play functionality to activate the short-cut upon USB insertion. Similarly, in the enterprise, attackers drop these LNK files onto network drives to get the same Auto-play effect.

A malware name most commonly associated with this exploit is Stuxnet. There’s also a downloader (i.e., a generic malware application that attackers download and launch from user space when they have exploited a software vulnerability, it then assesses the host, downloads persistent malware and files, and finally installs them for permanent use) that implants malicious LNK files as well as an executable. This downloader also attempts to alter the Windows registry (HKCU/…/Run) to automatically launch the permanent malware executable when Windows launches. Also of interest, with each use, the hash checksum, or signature, of this download changes, making detection by traditional anti-virus/spyware highly unlikely. Names for the downloader include: W32.Changeup (Symantec), W32/Autorun.BFG (Sophos), Win32/AutoRun.VB.RD (Eset), Worm:Win32/Vobfus.R (Microsoft), Download-CJX (McAfee), TR/Dldr.Gaat.B (Avira).

The most important thing for enterprise desktop administrators or advanced home users to know is that this vulnerability enables an attacker to launch an arbitrary executable. However, the executable must already be present in the host. Otherwise, a malicious short-cut is moot. Think of this vulnerability as a trigger, which is useless without a bullet (i.e., a malicious executable). Does the LNK vulnerability alone represent a zero day threat? No. But combined with other vulnerabilities it can be zero day.

Microsoft recommends disabling short-cuts, among other workarounds. AppGuard and AppGuard Enterprise need not implement these workarounds. But, they do add another layer of protection.

How AppGuard Defeats LNK Exploits

A Stuxnet or similar malware attack usually begins somewhere in user-space, which is any hard drive or removable media location where an end-user without local admin rights can write. User-space is the preferred initial landing site for any attack because its always accessible whereas system-space is inaccessible when the target PC is running without local admin rights.

AppGuard only allows executables to launch from within user-space if they are on the ‘guard list’, which may be regarded as a white list. So, the malicious executable cannot launch from user-space, period. This includes USB drives too. AppGuard Enterprise, where PC’s frequently encounter network drives, treats these drives as user-space as well.

The attackers must therefore get their malicious executable into system-space before their LNK trigger can be of use. System-space is defined as the Windows and Program Files directories and their children. AppGuard places applications at-risk ‘under guard’. Typically one guards web browsers, email applications, Adobe Reader, Microsoft Office, and others that consumer files and communications from potentially unknown origins. ‘Guarded’ applications can neither write into system-space nor Windows registry where it can trigger executable launches.

So, attackers cannot launch malicious executables from user-space. They cannot exploit vulnerabilities in software applications to plant an advanced persistent [malware] threat (APT, i.e., malicious executable) into system-space. Therefore, the LNK Windows vulnerability poses little risk to AppGuard or AppGuard Enterprise protected computers.

Update: New Zero Day Protection Feature Called MemoryGuard Alone Kills Some Windows LNK Based Attacks

We tested the downloader mentioned above with drive-by download protection disabled (this feature prevents executable launches from user-space) and allowed the downloader to run with nothing restricting it but the MemoryGuard protection feature, currently out in beta.  The result was MemoryGuard blocking the downloader’s attempts to launch code injection attacks on all available processes in the test host.  Below is a screenshot:

Zero Day Protection from Advanced Code Injection Attacks

Can AppGuard Do Even More?

Yes, AppGuard users and administrators can add three executables to the ‘guard list’.

• rundll32.exe
• cmd.exe
• regsrv32.exe

With the forthcoming summer releases of AppGuard and AppGuard Enterprise, these will be guarded by default. We doing so because these Windows facilities are sometimes used by attackers.

Legitimate software installations and patches use these facilities too. Thus, one should suspend all AppGuard protections when doing so. Consumers need only right-click on the AppGuard tray icon and select ‘suspend all’. Enterprise users should always test installs. They have an additional feature whereby they can define power applications, such as patch management or desktop configuration software, which tells AppGuard to allow them to what they wish.

There is no password that locks AppGuard policies. We wish to avoid issues associated with lost passwords. Instead, our approach leverages the existing Windows user account credentials on a PC. So, “family” computers must have at least two Windows user accounts to utilize our parental controls, which SHOULD always be so, though it isn’t. Folks new to having a separate local admin account should make certain their password is never lost as consequences can be disastrous (a public service announcement!).

Let’s clarify something regarding this ‘two Windows user accounts’ minimum requirement for our parental controls.

• Each and every Windows (or Mac or Linux for that matter) must have at least one account with local admin rights
• Each and every Windows (or Mac or Linux for that matter) PC should have at least one non-admin account for day-to-day use of the PC
• This adds up to two unique login accounts per PC, if one follows Microsoft recommended practices
• AppGuard requires nothing more

Getting Started with Parental Controls

Until a user clicks on the AppGuard ‘Advanced’ button and activates the ‘Parental Controls’, no user is restricted in what may be done via AppGuard. Once ‘parental controls’ are activated, one must enter “super user mode” to edit parental controls. The Windows account used to first activate parental controls is endowed with “super user mode” privileges. AppGuard associates those that may run “super user mode” with Windows user accounts, which are not required to possess Windows local admin rights. To enter “super user mode”, one must click on the AppGuard “Advanced” button, answer the Windows authentication challenge (does not involve logging in or out of a Windows account), and then the parental controls dialog is displayed.  BTW, by leveraging Windows authentication and authorization infrastructure, we keep AppGuard lean.

Parental control is a variant of our TamperGuard technology. Only a Windows account with local admin rights and with “super user mode” enabled may uninstall AppGuard. If AppGuard detects that there are no longer any “super user” accounts, the uninstall feature as well as parental controls in general would be disabled.

A user that has simply logged into a Windows account that is authorized to employ “super user mode” has not yet enabled this mode. One must click on a button in the AppGuard GUI, which initiates a Windows authentication challenge prompt, “super user mode” is activated, and then one may edit parental controls, allowing one to:
- Enable, disable, and edit parental controls
- Uninstall AppGuard
- Designated specific Windows accounts as having “super user mode” privileges

Thus, from an AppGuard parental controls perspective, there are two types of AppGuard users (or Windows user accounts), those with and those without the “super user mode” privilege. Windows accounts with the “super user mode” privilege are in no way restricted by parental controls; other Windows accounts are.

If someone without “super user mode” privileges needs assistance from someone with the privileges to temporarily remove an obstacle, that person with the privileges does not have to log out of that person’s account and into their own. Instead, that person simply navigates to AppGuard, clicks on the ‘Advanced’ button, gets an authentication challenge, and then has “super user mode” enabled. When no longer needed, return there and log out of there (not the Windows account) to return things to normal.

Ideal for Families with Kids Playing Games that Require ‘Local Admin Rights’

For reasons that escape me (I’m not a computer gamer), many computer games cannot be fully utilized unless run via a Windows user account that possess local admin rights.  Maybe the game needs to be able to write something into its respective ‘Program Files’ directory, maybe something else.  Whatever the reason, this motivates folk to run a PC with local admin rights on a daily basis.  This is a very bad security practice.  AppGuard does a very good job of removing the risks.  But, as a security solutions vendor for over 15 years, we always recommend layered defenses.  And this means, try to run PC’s without local admin rights, unless installing, configuring, or updating software.

With parental controls in place, a family member can do far less harm through direct action or foolishness.  They cannot uninstall AppGuard.  And, when combined with a new feature also coming in version 2.0 called InstallGuard, they cannot install most software, even though they have local admin rights.  They also cannot launch potentially dangers applications (executables) from user-space (e.g., My Documents, Desktop, etc.) if the parental control settings of AppGuard say otherwise.

This blog post was inspired by an article at GCN (Government Computer News) called “5 Top Security Suites for Teleworks”, 17 June 2010.  The author Carlos Soto reviewed leading consumer anti-virus/spyware software so that federal agencies inclined to subsidize or somehow require the use of such software on employees telecommuting via home computers could choose the best software for the job.  On the surface, its sound advise.  A safer PC reduces federal data leak and malware intrusion risks, right?  But, what if this advice is akin to encouraging federal agencies to doing something foolish such as going into harm’s way with a target on your back and nothing but a helmet?

Employee-owned Windows PCs are more likely to be already infested than not. And those not, soon will be. Consider this, Cyveillance and AV-Comparatives measured the effectiveness of numerous antivirus products against newly created malware finding average detection rates of 25% and 44% in 2010, respectively.

And as more than half of these PCs operate with local admin rights accounts, they may well be infested with rootkit based malware. Such infestations are detectable when sloppy code is used by cyber criminals. Otherwise, where 3rd generation rootkits are used (available on the black market cheap), when the AV asks the OS for a list of files in a directory to be scanned, for example, the AV receives an incomplete list because the OS has been ‘brainwashed’ and coerced to lie on behalf of the malware.

So, if federal agencies intend to practice safe telework, its not simply a matter of are employees practicing safe-computing from now on but whether they have always practiced safe-computing.

While an employee’s computer is untrustworthy until you know otherwise, this has no bearing on the integrity of the employee itself.

I’m afraid matters are even more complicated. More and more households have multiple computers operating within a home network. One infected PC leads to infections of the others. However, from the federal agency perspective, the ‘other’ infected PCs are a severe data leak risk. They can launch a DNS poisoning attack, an SSL man-in-the-middle attack, a man-in-the-browser attack, or numerous others that effectively steal sensitive data from all other computers in the home network. In other words, federal agencies must consider home networks untrustworthy.  In short, federal telecommuting solutions must regard both the employee-owned computer as well as the employee-managed home network as untrustworthy!

There’s yet more. Each of us values convenience. What percentage of federal telecommuting employees are saving work documents on their home computers? Each employee home computer represents a potentially embarrassing security breach.  For these reasons and others, agencies that can afford to provide telecommuters with laptops. Ones hopes these include properly configured full disk encryption based on two factor authentication. Anything less means not only data loss from a lost or stolen laptop but also another potential security breach.  A key walk-away point to consider here is that any data or document that is free to leave the enterprise becomes a potential liability to it as well, or in other words, an asset to be managed but usually not.

Getting Practical

Blue Ridge offers a solution called EdgeGuard that allows for the safe use of employee-owned computers with virtually no malware or data leak risks. An employee inserts the EdgeGuard USB device into their PC, EdgeGuard generates a virtual workspace, securely connected to the enterprise via a virtual VPN appliance, and when the employee is finished doing whatever one might do from a typical Microsoft Office environment with access to all of the user’s network drives, no data or document from the telecommuting session remains on the employee’s PC. No malware from the employee’s PC sneaks in, and no sensitive data or document leaks out from the federal government leaks.  If you’d like to know more about how this works, look at this page on EdgeGuard Telework.  If you’d like to speak with another federal organization already using EdgeGuard, contact us and we’ll make an introduction.