Skip navigation
All Places > Knowledge Base & Downloads > Blog
1 2 3 Previous Next

Knowledge Base & Downloads

462 posts

It happens. You're enjoying a raspberry-flavored sparkling water, mug of coffee, or cup of tea and an email comes in from InfoSec. The subject line casts a dark cloud over the rest of your day: Security Violation Remediation: Server ITSM-VA2-BPCOLL-01 (100001483652). ITSM-VA2-BPCOLL-01 is a print server running Pharos Blueprint Enterprise Collector software. It's getting print jobs, holding them, and then releasing them when the employees are at their print devices. What's the deal here?

 

What Just Happened?

Most IT organizations conduct security sweeps of their server infrastructure to eek out misconfigurations and other oversights that could potentially put the company at risk for "minor" problems like regulatory fines or sanctions to more major problems like hacking, data theft, or hijacking for another purpose (torrent servers, unregistered data stores and the like).

     "But it's a print server!" you rally. "What are they gonna do, steal company secrets?" Well...yes. A compromised system can serve as a vector for more malicious intent somewhere else; most intrusions happen on piggy-backed systems. Your Security team is just making sure that they keep a running tally of servers that don't fit their bill, and further track how quickly those identified servers are remedied.

 

What Do I Do?

That question is the first important step, and this article is the next. A lot of scanning systems borrow from a slew of resources like THE MITRE Corporation's Common Vulnerabilities and Exposures (CVE) website (cve.mitre.org) or OWASP (and many of those are software version-based. Keeping up to date with patches for installed software is a great first step in staying off the "naughty" list. Other vulnerabilities exist in web services and applications, and this is where this article is going to spend most of its time. So, on to HTTP Response Headers!

 

HTTP Response--what??

Some background may be helpful. When the W3C (the World Wide Web Consortium...the "think tank" and one of the standards organizations for the Internet) ushered in the concept of using markup language-formatted text to bring information to people worldwide, they also devised a way for those serving the information to provide additional information about the website to the user without affecting the displayed content on the page...a "meta data" vehicle of sorts: the HTTP Response Header.

     Over time, the function of the HTTP Response Header grew from a carrier of meta data (like who wrote the article, who holds the copyright, how many words it contains and all sorts of other cool, but non-essential, stuff), and could now manage how credentials were used or stored, what the underlying state of the server was, and ... security. Now, remember: a lot of web servers have public entry points (they have to, or your web experience would be awfully non-informative), so a bunch of the security-based HTTP Response Headers are driven towards keeping John Q. Public on the up-and-up, and the public web server out of hot water. And the security software that's out there looking at web servers will be designed around that. So while your internal print server hosting some Pharos software may be just that: internal, keeping it safe is the Security team's job...so they will still "call you out" when they find a violation.

Anyway, HTTP Response Headers. There are a handful of headers that can be implemented at either the server layer or the individual application or site layer that serve to keep things safe. And if your server's web server software (Microsoft IIS, Apache Tomcat, etc.) is missing them, it is likely a good time to add them. They don't affect the Pharos software's operation, and they keep your servers on the good side of the IT Security folks. Which means you get to enjoy your work beverage of choice without worrying about that incoming nasty-gram from InfoSec.

 

Good Custom HTTP Response Headers to Have

There are five (5) HTTP Response Headers that are good to have on your Microsoft Windows Server running IIS:

 

> Content-Security-Policy

The content security policy directs the browser (in this case, generally by the printer's built-in web browser) to load only certain types of content from certain sources. Here, the policy only allows loading of resources from the current web site or from the local host (the local host is required because some resources are fetched locally from the printer itself).

> Strict-Transport-Security

Strict transport security forces the use of HTTPS (encrypted HTTP) in future communications to the server. Generally, the "time to live" for this setting is a year, but some organizations may have shorter expiry periods.

> X-Frame-Options, X-Content-Type-Options, and X-XSS-Protection

These three headers prevent cross-site scripting attacks (injected code) and stop the execution of untrusted content. Web pages that allow comments or other interaction points (like the one you're reading now) are common targets for cross-site scripting attacks.

 

Where to Implement Custom HTTP Response Headers

When implementing Response Headers, one of the first questions asked is "Where?" Well, on the web server itself, of course! In practice, there are a few ways to implement Headers. Where you end up adding them will likely be up to your Security organization. I'll start at the top layer and work down.

 

> At the "Server" Layer

Implemented at the server layer, the HTTP Response Headers will be applied to all underlying Sites, virtual directories, and web applications. If implemented here, it's a "set it and forget it" type of scenario.

> At the "Site" Layer

Implemented at the site, like the Microsoft IIS "Default Web Site", applies the HTTP Response Headers to all virtual directories and web applications under the site. This is useful when a server is running multiple sites, and not each one needs custom HTTP Response Headers.

> At the Virtual Directory/Web Service Layer

Implemented at the actual web directory or application, this allows granular control over which services get the custom HTTP Response Headers and which ones don't.

 

How to Implement Custom HTTP Response Headers

There's an old maxim that states there are three ways to do anything on a computer. The same applies here, but there are more than three.

 

> Using Microsoft IIS Manager

> Using PowerShell

> Using C# or another programming language

> Editing a web application's web.config file

 

In this article, we'll cover using Microsoft IIS Manager. There are multiple resources available to discuss the other three mechanisms (hint: use a scriptable/executable method if you have multiple servers). Just launch your favorite web search tool and type "powershell add http response header" or similar and you'll be fast on your way.

 

Creating a Custom HTTP Response Header in IIS Manager

In this example, we'll be adding the "Content-Security-Policy" HTTP Response Header to the "Default Web Site" in IIS.

  1. Launch IIS Manager on the server.
  2. Click the "Default Web Site" element.
  3. In the panel on the right, locate the "IIS" section and double-click the "HTTP Response Headers" item to open it.
  4. Click the "Add..." option in the Actions panel.
  5. Type "Content-Security-Policy" in the "Name" field and "default-src 'self' 127.0.0.1; script-src 'unsafe-inline';" in the "Value" field. Do not type the double-quotes.
  6. Click the "OK" button.

 

That's it! Continue with the others. The necessary Name and suggested Value of the custom HTTP Response Headers is shown below:

 

NameValue
Content-Security-Policydefault-src 'self' 127.0.0.1; script-src 'unsafe-inline';
Strict-Transport-Securitymax-age=31536000; includeSubdomains
X-Frame-OptionsSAMEORIGIN
X-Content-Type-Optionsnosniff
X-XSS-Protection1; mode=block

 

References

The following references were utilized in this article.

Products

The following products support an SNMP (Simple Network Management Protocol) function, and may be affected by operational failure due to the cause described in this article:

 

  • Pharos Systems Device Scout
  • Pharos Systems Blueprint
  • Pharos Systems Uniprint
  • Pharos Systems Site Monitor
  • Pharos Systems Print Center

 

Symptoms

  • Printing devices are not found during discovery.
  • Discovered printing devices have no, or incomplete, associated data.
  • Released print jobs do not print out.
  • ERROR found in operational logs
    [2019/09/04 09:54:54.318 PDA4 D001 T02E e AgentDiscovery] [Messenger] (Get) Failed to get or interpret response from '10.50.0.40:161'. wrong response sequence: expected 212442588, received 212442385

 

Cause

A previous SNMP request was cancelled due to timeout, but the requested data was still received.

 

Background

The Simple Network Management Protocol (SNMP) is a stateless network application. This means that communications sent over SNMP do not necessarily have to be returned, or may take time to return. This is fine in many situations, but when an attempt is being made to add a printer to a managed pool, updated meter information is being sought, or a print job is being released, a long wait (greater than 30 seconds) may be unreasonable.

For those operations where a Pharos product utilizes SNMP (printer discovery, printer data collection, or printer status before print job release), timers have been implemented around those communications so that "sorry, this took too long, so we ended it" messages can be fed back to either the application or the user. The last symptom, above, is one such message.

 

So, What Happens?

In most cases, a timeout happens because the printer on the other side of the communication is really offline (turned off; moved, so it has a different IP address; network connection unplugged; etc.) so the timeout message is the last message found in a log file or on the user interface.

Sometimes, however, a device or the network is just slow. The "traffic lane" that SNMP uses in a lot of networks is the slow lane: bandwidth priority is given to Voice Over IP (VoIP), email, web traffic, file sharing, and other needs, so "non-essential" network apps get the left-overs. It could be that the printer is having a rough time waking up and responding to the SNMP message fast enough, or the network is experiencing high utilization and some latency ("lag") is creeping in. When something like that happens, the Pharos software ends up cancelling the initial data request and sending another. Each data request gets an identifying sequence number so that the application can keep things straight.

In the error message above, the initial sequence number, 212442385, was cancelled because the timeout was reached and it followed up with a new request with a sequence number of 212442588. While it was waiting for a response using the new sequence number, the original one (that was cancelled) came back. Since the initial request was closed, the response is rejected.

What will likely happen with this device is that the subsequent attempts will be stymied by the same problem that delayed the first connection attempt, so the device won't be added, updated, or sent the print job.

 

Resolution

The resolution is to increase the timeout value. The product documentation for your specific application (found here in Documentation & Downloads) will tell you how to increase the timeout. When increasing timeouts, remember that this may have an impact on the time required to perform a network scan (Device Scout or Site Monitor), update device data (Device Scout or Site Monitor), or get the user's print job out (Blueprint and Uniprint's Secure Release Here), so start small and make incrementally longer changes as necessary.

Problem

Depending upon the configuration of the Active Directory domain controllers, the Standard Authentication Script provided with Pharos Blueprint Enterprise may not be immediately successful, causing login attempts at devices and unauthenticated Print Scout clients to fail.

 

Symptoms

One or more of the following errors may be presented:

  • Message: Unable to authenticate user. Either user does not exist, or the password is incorrect.
  • Message: The server cannot handle directory requests.

 

Cause

 

One of the reasons Active Directory-based authentication may fail is binding. When a .Net application like Pharos Blueprint Enterprise attempts to authenticate a connection with Active Directory it has to present the correct context to the domain controller. The various bind options are discussed in ContextOptions Enum (System.DirectoryServices.AccountManagement) | Microsoft Docs (this article explains them in terms of .Net 4.8; it applies to any version of .Net).

 

In the case of the Standard Authentication Script, it does not actually specify a binding, which forces a Basic Authentication event. Many domain controllers are specifically configured to not allow Basic Authentication.

 

Resolution

To change binding to Active Directory in the Blueprint Standard Script, modify the following line, found in function ActiveDirectoryQueryWorker()

 

if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate))

 

Possible values for this can be found in the document referenced in the "Cause" above. NOTE: The only change that may generally be required is to force use of Kerberos, which is done by changing the text to:

 

if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate | ContextOptions.Sealing))

Symptoms

 

Cause

When parsing a print job for related data, Blueprint creates a "CopyLine" element in the resultant XML for each section of the print job. In most cases, print jobs only have one section, but complex jobs can have multiple sections. The most common reasons a job has multiple sections include:

 

  • Multiple paper sizes in the document
  • Multiple paper orientations in the document
  • Multiple "tray calls" for paper in the document
  • Multiple "plex" modes (simplex - single-sided; or duplex - double-sided)

 

Blueprint has been designed to support a maximum of 8 different sections in a print job. If there are more than 8 sections within the job data XML file for any print job, it will be rejected by the Blueprint Analyst when importing jobs for publication.

 

Resolution

At this time, there is no resolution for this behavior; the job data will simply be rejected by the Analyst.

Problem

When attempting to use an ID card to log into a Sentry Print-controlled Ricoh "IM" device (like an IM C3500 or IM C6000), the login attempt fails; the action times out. However, using user/password authentication works just fine.

 

Cause

Invalid Device Settings

If the terminal for the device was present on the Analyst server prior to securing the device, there is a possibility that there is a difference between what is expected for the device and what is actually present. At launch, the device-side software requests its configuration information. The server-side software catches this invalid data and quashes the request. Because the configuration is not downloaded, the device software cannot launch, causing the visual symptom described above.

 

Resolution

This usually happens because an existing Terminal is present for the device in Blueprint prior to attempting to secure the device. As part of the securing process, Sentry Print will create a terminal record that is appropriately configured (use the Secure Release Server default settings to set the Print Group and authentication script for the terminals) for the device.

 

Resolution: If a terminal was already present when the device was secured:

  1. Unsecure the device.
  2. Launch the Blueprint Administrator application on the Analyst and delete the terminal record.
  3. Within the Analyst's Blueprint Administrator, clear replicated data on the device's parent server.
  4. Launch the Blueprint Administrator application on the device's parent server.
  5. Clear replicated data on the parent server.
  6. Resecure the device.

Problem

When securing a device for Sentry Print in Blueprint, the "Status" in Pharos Print Center says "Secured" but the device, on reboot, only has a white screen with an animated "spinner" as if it is still loading.

 

Causes of the Problem

This problem has several potential causes. Each is described below.

Connectivity to the Server - Name Resolution

When securing the device, the server designated in the dialog box is sent to the device as the host name. If the DNS settings on the device cannot resolve the host name, the Pharos software installed on the printer will not load, causing the visual symptom described above.


Connectivity to the Server - Port Access

The device will attempt to reach its parent server on TCP 4321. If that port is being blocked (firewall software, switch, router, etc.), then the connection cannot complete and the Pharos software installed on the printer will not load, causing the visual symptom described above.

Invalid Device Settings

If the terminal for the device was present on the Analyst server prior to securing the device, there is a possibility that there is a difference between what is expected for the device and what is actually present. At launch, the device-side software requests its configuration information. The server-side software catches this invalid data and quashes the request. Because the configuration is not downloaded, the device software cannot launch, causing the visual symptom described above.

 

Resolution

Name Resolution Issues

Use nslookup to determine if the issue is due to failure in name resolution. If used as-is, nslookup will use the host's primary DNS server to resolve the server name. However, the command can accept another DNS server as well, making it a very flexible troubleshooting tool. In the example that follows, "bp-collector02.pharos.com" is the device's parent server and "192.168.18.35" is the DNS server defined on the device. So to check name resolution, the command to run is:

 

nslookup bp-collector02.pharos.com 192.168.18.35

 

If the response includes a "can't find <servername>" statement, then the DNS server does not contain a record for resolution.

 

Resolution: Either add the necessary record to the DNS server or reconfigure the device for a DNS server that can resolve the name.

 

TCP Port Access Issues

To determine if it is a port access issue, locate a workstation on the same subnet as the device. Engage a command prompt (it does not need to be administrative) and use telnet to reach the server over TCP 4321. In the example, the server name is bp-collector02.pharos.com. Note: you may need to install the telnet client; use "Add Windows Features" to do this.

 

telnet bp-collector02.pharos.com 4321

 

If successful, the command prompt window will change to simply be a screen with a flashing cursor. Otherwise, it cannot make a connection.

 

Resolution: Evaluate the network device path between the device and the server to determine where the 4321 TCP port is not allowed, and then open/white list it.

 

Invalid Device Settings

This usually happens because an existing Terminal is present for the device in Blueprint prior to attempting to secure the device. As part of the securing process, Sentry Print will create a terminal record that is appropriately configured (use the Secure Release Server default settings to set the Print Group and authentication script for the terminals) for the device.

 

Resolution: If a terminal was already present when the device was secured:

  1. Unsecure the device.
  2. Launch the Blueprint Administrator application on the Analyst and delete the terminal record.
  3. Within the Analyst's Blueprint Administrator, clear replicated data on the device's parent server.
  4. Resecure the device.

ENVIRONMENT

  • Pharos Blueprint Enterprise 5.3.x
  • Pharos iMFP for Konica-Minolta v1.5.x
  • Pharos iMFP for Konica-Minolta v2.x

 

SYMPTOMS

  • The service will not start.
  • Cannot secure a device.
  • ERROR: "Unable to register Secure Print because the browser certificate is not available."
  • ERROR: "User [Domain]\[User] requires full R/W permisson to use the Management console. User can't write."
  • ERROR: "UnknownMessage" on device display.

 

CAUSE

Pharos Blueprint Enterprise 5.3.x includes the MFP Site Service as part of its installation. This service creates endpoints that can listen in the range 0.0.0.0:50003 and another 0.0.0.0:50006, which are also potential endpoints used by the service running as part of the Pharos iMFP for Konica-Minolta server installation. Because there is a potential for port contention, the solution behavior is unpredictable and will cause operational problems.

 

RESOLUTION

Part I. Determine the conflicting port(s).

  1. If the  iMFP for Konica-Minolta service is running, stop it.
  2. Close the Konica-Minolta management console.
  3. Using Windows Task Manager, identify the Process ID (PID) of the “Mps.Client.Mfp.Service.exe” process (the Details tab will display this by default).
  4. Using Command Prompt running as an administrator, run the following set of commands: netstat -ano > netstat.txt notepad netstat.txt
  5. Look for the “Listening” ports associated with the PID of Mps.Client.Mfp.Service.exe. These will be found under the “Local Address” header in the netstat.txt file, expressed as 0.0.0.0:<portnumber>. Write them down.

Part II. Reconfiguring the KM Service.

Pharos iMFP for Konica-Minolta v1.5.x

  1. After installation, launch the Management Console for KM iMFP.
  2. There will be a prompt to configure the application. Continue.
  3. Using the ports from Netstat, look for the match within the Application Settings > Service Settings screen. It will likely be the Listening Port (v1.5.6 and lower) or Listening Port (Auth) (v1.5.7), as that uses TCP 50004 by default. Change it and continue to configure application settings.

 

Pharos iMFP for Konica-Minolta v2.x

  1. After installation, launch Notepad as an administrator and open [Drive]:\Program Files (x86)\PharosSystems\Pharos iMFP for Konica Minolta V2\App_Data\km\Konica-Minolta.config.
  2. Locate the lines for port configuration and identify the conflicting port assignment(s). If TCP 50006 is the conflicting port, for example, change the following line: <add key="pullPrintListeningPort" value="50006" /> to use a different port.
  3. Save the change(s).
  4. Restart the Konica-Minolta iMFP v2 service.

 

NOTE: If the server is running Windows Firewall or some other port blocking application, an exception will have to be made to allow communication against the changed port(s). Similarly, TCP port configuration may be required on switches and/or routers to enable communications between the server and the device.

Dear Pharos Customers/Partners

 

Pharos software is not susceptible to the new Apache Struts vulnerability

 

Background

Recently, a new security vulnerability was discovered inside Apache Struts:

 

            CVE-2018-11776

            https://nvd.nist.gov/vuln/detail/CVE-2018-11776

 

This vulnerability is serious because it allows a possible Remote Code Execution when the alwaysSelectFullNamespace option is enabled in a Struts 2 configuration file, and an ACTION tag is specified without a namespace attribute or a wildcard namespace. Further, it has a CVSS v3 base score of 9.8 (out of a possible 10)

 

Many organizations, including Pharos customers, are urgently investigating where this tool is used and to update/repair those instances.

 

Pharos Software and Apache Struts

Pharos has reviewed all our software and 3rd party tools/libraries that we use and can confirm that we do not use Apache Struts in any product. This includes:

 

  • Uniprint (including all web interfaces)
  • Blueprint (including all web interfaces)
  • Mobileprint
  • All Omega devices (including PS60, PS150, PS200)
  • All iMFP implementations across all manufacturers
  • Beacon – both the desktop components and the cloud infrastructure
  • Kiosks

 

Pharos products are therefore not vulnerable to the Apache Struts exploit.

 

 

Regards,

Pharos Security Team

Pharos Systems International

585-939-7000

pharossecurityteam@pharos.com

Introduction

In the wake of highly publicized vulnerabilities within SSL and early TLS versions, many organizations are aggressively working to "harden" servers by enabling TLS 1.2 as the only allowable cryptographic protocol.

 

What's at risk?

Making the move to deprecate weak cryptographic protocols can cause concern for lack of compatibility with older applications targeting framework versions earlier than .NET Framework 4.6.

 

Risk Mitigation

The Windows Registry provides some control over the security protocols used by the .NET Framework, forcing appropriately coded applications that would normally default to TLS 1.0 to use stronger cryptographic protocols.

 

Modifying the Windows Registry to Enable Strong Cryptography for .NET Applications

Add the appropriate key-value pairs into the Windows Registry.  The following .REG file sets the registry keys and their variants to their most safe values:

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

 

The server will require a reboot for these changes to take affect.

 

Where can I get more information?

For complete details regarding this and other best practices from Microsoft regarding the .NET Framework, please refer to:

Transport Layer Security (TLS) best practices with the .NET Framework | Microsoft Docs

Introduction

While the Pharos Blueprint Enterprise Planning and Installation Guide discusses the necessary prerequisites for the Windows server, it does not provide an easy step-by-step process to install those on the Windows Server operating systems that are supported. Depending on the background of the individual assisting with the server build, this may mean that necessary components are missing, resulting in a failed installation, rework of the server configuration, and other activities that stretch the time for installation.

 

Contents

This document contains two PDF files that discuss prerequisite installation. One focuses on Microsoft Windows Server 2012 R2 and the other on Microsoft Windows Server 2016. While both operating systems are very similar in what is required, there is enough difference in their respective user interfaces to warrant separate documents.

Problem

An application starts to become unstable or crash. A process dump, memory dump, or Windows Event Log application event implicates one of the following DLLs:

  • 64-bit application faults
    • AppProfiler.x64.dll
    • pt64.dll
    • ptm64.dll
  • 32-bit application faults
    • AppProfiler.x32.dll
    • pt32.dll
    • ptm32.dll

Background

Applications running in a Microsoft Windows environment augment their feature/functionality by loading additional plug-ins at the time they are launched. These plug-ins run inside the “container” of the application. At the same time, other Windows applications, like data-loss prevention software, antivirus software, or anti-malware tools often “inject” their own plug-ins into applications for their purposes, notably to prevent the spread of computer viruses or to secure the information being transmitted by the application.

The Pharos Systems Print Scout and Preton Toner Saver client software packages also can inject a plug-in into running applications for their purposes, notably to make capturing the print job’s source application easier (Pharos Systems Print Scout) or to intercept the print job to apply the toner saving algorithm (Preton Toner Saver). Operationally, this injection has been designed to occur without interfering with the user or their task at hand; the user doesn't see any difference in the operation at all, and the client software performs its work, silently, in the background.

Cause

By default, both the Pharos Print Scout and Preton Toner Saver clients "inject" their plug-in into running applications via Windows' ntdll.dll's provided "LdrLoadDll" function. Again, the Print Scout does so to capture the name of the application (winword.exe, iexplore.exe, acrord32.exe, etc.) that generates the print job. Preton Toner Saver does so to redirect the file for toner savings or otherwise identify a monitored print job. However, there are several cases where injection may cause a problem for the end user:

  1. The 64-bit DLL is injected into a 64-bit application and put into the "lower" address space (aka: the "32-bit address space", under the 4GB mark) and not the "upper" address space (above the 4GB mark). This is more of a problem after Microsoft KB 3126593 is applied and older (produced prior to April 2016) Print Scout or Toner Saver are installed. This normally just expresses itself as instability, slowness, or crashing.
  2. The 32-bit DLL is injected into a 32-bit application and the upper registers of the 4GB address space are unavailable (used by the application, used by another injected process). This normally expresses itself as instability or crashing, but will also be seen in the Windows Event Viewer Application log as an access violation:
    Faulting application name: Acrobat.exe, version: 11.0.11.18, time stamp: 0x5543b1c0
    Faulting module name: PT32.dll, version: 10.0.2.17, time stamp: 0x54a56b84
    Exception code: 0xc0000005
  3. A third-party security package (antivirus, anti-malware, data loss prevention (DLP) app, or similar) has been configured to block injection for applications, and this is causing contention.

 

Resolution

Resolving these problems is relatively straightforward, but may require "pushing" (using Microsoft SCCM, CA LanDesk, IBM Tivoli, etc.) a revised configuration or installation. Common resolution methods are found below.

  1. If the problem is the 64-bit "lower" address space injection, update your Pharos Print Scout (releases after May 2016 already have revised code to contend with KB 3126593) or Preton Toner Saver client (resolved in 3.3.2.118 and higher). Contact Pharos Technical Support for a download link for either software package.
  2. When the Preton Toner Saver injection is affected by the memory access violation (exception code 0xc0000005), it can normally be resolved by increasing the injection delay time (version 3.3.2.124 and higher) from 1000 milliseconds (the default) to 5000 milliseconds or more. If version 3.3.2.124 or higher is already installed, edit the C:\Program Files\Preton\PretonSaver\PretonService.exe.Config file, changing the value for the "InjectionDelay" key to 5000. Once saved, restart the Preton Toner Saver service for the change to take effect. If the change fails in test, just make this value higher (stepping by 1000) until successful. Slower workstations will require longer delay values. If the problem persists, the application can be Protected from toner savings using Blueprint Administrator, and the DLL will not be injected:
    1. Choose Policy Print > Application Toner Savings
    2. Change the mode to "Advanced Mode."
    3. Select the application from the list and change "Application Savings Mode" to Protect.
    4. Apply the change. The Preton Toner Saver client will update at the workstation as it gets its update from the server.
  3. When the Pharos Print Scout is affected by the memory access violation (exception code 0xc0000005), it must be resolved by excluding the application from injection, or disabling injection altogether. This is done within the Blueprint Administrator application on the Collector(s) hosting Print Scout.
    1. Choose Print Scout > Settings from the shortcut bar on the left.
    2. Select the "Application Tracking" tab.
    3. Do one of the following:
      1. Untick the "Enabled" box to completely disable Application Tracking. Click the "Apply" button when finished.
      2. Click the "Add" button and enter the name of the EXE to exclude from injection. Click the "Apply" button when finished.
    4. For the change to take effect on the Print Scout, the workstations must either be rebooted, or the "Pharos Systems Print Scout" service must be restarted.
  4. If the problem is being caused because antivirus, anti-malware, or some other data protection application is blocking injection, whitelist (or otherwise allow) injection from Print Scout or Preton Toner Saver. If that type of granular injection control is unavailable, then disable the Print Scout's function (see above) and, if applicable, uninstall the Preton Toner Saver application as its entire operation requires injection of the application.

Preton Saver is a companion product to Pharos Blueprint Enterprise that further optimizes printing costs by reducing the amount of ink or toner applied to the page (see Toner Savings for more information). As part of its operation it injects a monitoring function into launched applications to see if they do any printing; if the application prints then it is added to a list so that toner savings outside of those available to the toner policy may or may not be applied. One of the potential byproducts of injecting into an application, however, is instability within the application to the point where some function may no longer work or, in the worst case, the application crashes. In many cases, the applications that become unstable don't even print. This document discusses how to manage a non-printing application to protect it from injection.

The Basics

As mentioned in the introduction, nearly all applications on a workstation are injected for monitoring by the local Preton Saver client. The three possible states of an application within Preton Saver are:

  • Monitor. The application is injected and monitored for print, but special toner savings are not applied. However, if the logged-in user has an applicable toner savings policy, those savings are applied.
  • Save. The application is injected for print, and special toner savings are applied. For example: a general toner savings policy is applied for 35% savings, but if the application is Mozilla Firefox, savings of 50% are applied. Conversely, an application savings policy may specify lower savings; for example Adobe Photoshop CS may only be set for 10% savings.
  • Protect. The application is not injected by Preton Saver, and no toner savings are applied for print jobs that come from that application.

The following set of steps will result in a protected application because it is known that the application has no way to print a job.

Creating The Application Within Preton Saver

In general, the only time an application "bubbles up" through Preton Saver for management is if that application is actually involved in printing a job. The steps below create an entry within Preton Saver when no print jobs exist for the application.

  1. Install and launch Preton Control. It is recommended that this be installed on the server hosting Preton Coordinator.
  2. Once connected to the Preton Coordinator instance, click the Applications group.
  3. Select any one of the applications in the list.
  4. In the "Applications Settings" panel on the right, click the "Add Filter" button. It will be near the middle of the page in the "Document Association" group.
  5. In the "Filter Text" field, type the friendly name of the application. To create a filter for the RealVNC Viewer, type RealVNC Viewer.

    NOTE:
    Do not use a Regular Expression; keep that option unchecked.
  6. Under "Application Association" choose to associate a new application and type the application name shown in Windows Explorer without the "exe" extension.
  7. Click the "OK" button when done.
  8. Click the "Apply" button in the top toolbar.
  9. Locate the new application in the list (the text color will be black) and select it.
  10. In the "Application Settings" page, click the "Application setting" option and change it from "Monitor" to "Protect."
  11. Apply the change by clicking the "Apply" button in the top toolbar. The application name will change to an orange fill.

 

At this point, either exit the Preton Control application or add any other applications that you wish to protect.

Managing the Change at the Client

In most environments, the Preton Saver client installed on the Windows workstation/laptop is configured to contact the Preton Coordinator software infrequently for policy updates. To force a policy update, follow this process:

  1. Exit the application that needs protection if it is running.
  2. Browse to C:\Program Files\Preton\PretonSaver.
  3. Launch PretonTraceView.exe (it does not require launching as an administrator).
  4. Locate the "Update Policy" button in the upper-right corner of the window and click it.
  5. Exit Preton Trace View.

Affected Environments

  • Pharos Blueprint Enterprise 5.0 (any service pack level)
  • Pharos Blueprint Enterprise 5.1 (any service pack level)
  • Pharos Blueprint Enterprise 5.2 R1 (any service pack level)
  • Pharos Blueprint Enterprise 5.2 R2 (any service pack level)
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016

 

Problem Statement

When installing Blueprint 5.x the initial Tracker and EDI web service tests fail with the message "The underlying connection was closed: an unexpected error occurred on a receive." There may also be a message about "unexpected error occurred on a send."

 

TesterError.png

 

Cause

This error happens because SSL is enabled for the Tracker web service (where it is optional) and the EDI web service (where it is enabled by default and required). However, the server has not been enabled to support any cipher (TLS 1.0, 1.1, or 1.2; 1.2 is only compatible with Blueprint Enterprise 5.2 R1 Service Pack 3 or Blueprint Enterprise 5.2 R2). This is normally due to a Group Policy Object (GPO) setting or the default operating system image in the organization has disabled/removed the SChannel protocols in Windows Registry.

 

Resolution

The necessary ciphers can be enabled using Windows Registry.

  1. Launch RegEdit.
  2. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Within there, look for TLS 1.0 and TLS 1.1.
    TLS_Registry.png
  3. Expand each to expose the Client and Server subkeys. If these keys are not there, use the attached file "CreateTLS1.1.txt" as a basis for an import into the Microsoft Windows Registry.
  4. When selected, the key will have a value, "Enabled". Change it to a Hexadecimal value of 1. Ensure that each subkey's "Enabled" value is set to 1 for TLS 1.0 and 1.1. If necessary, only TLS 1.1 needs to be enabled.
  5. When completed, restart the server.

 

From this point, the SSL-enabled web services will pass their tests.

 

Reference

The following Microsoft article discusses cipher support in the various Windows operating systems and the Windows Registry settings that support them. TLS-SSL Settings | Microsoft Docs

Additionally, Pharos Blueprint Enterprise (and other Pharos Systems applications) are .NET version-dependent. This means that a specific .NET version support of an SChannel cipher must also be considered. Below follows a table listing the cipher support by operating system version. When the value is ON, this implies the default configuration unless affected by Group Policy.

 

Windows versionSSL2 ClientSSL2 ServerSSL3 ClientSSL3 ServerTLS 1.0 ClientTLS 1.0 ServerTLS 1.1 ClientTLS 1.1 ServerTLS 1.2 ClientTLS 1.2 Server
Windows Vista SP2 and Windows Server 2008 SP2OffOnOnOnOnOnN/AN/AN/AN/A
Windows 7 SP1 and Windows Server 2008 R2 SP1OffOnOnOnOnOnOffOffOffOff
Windows Server 2012OffOffOnOnOnOnOnOnOnOn
Windows 8.1 and Windows Server 2012 R2 OffOffOnOnOnOnOnOnOnOn
Windows 10OffOffOnOnOnOnOnOnOnOn
Windows 10 (1511)OffOffOnOnOnOnOnOnOnOn
Windows 10 (1607) and Windows Server 2016N/AN/AOffOffOnOnOnOnOnOn

Source: https://support.microsoft.com/en-us/help/3154519/support-for-tls-system-default-versions-included-in-the-net-framework. Note that systems utilizing .NET 3.5/2.0 will require the addition and enablement of the "SystemDefaultTlsVersions" Registry key after Service Pack 2 for this version of .NET has been applied.

Introduction

In the age of mobile, we're all thumbs (unless you have a wicked-clear voice and can never befuddle Siri or Google's attempts to transcribe your mutterings). And while thumbs are awesome things (and bilateral rotating shoulder cuffs; absolutely necessary to get us out of the savannah and into tall, glass-clad skyscrapers), typing long URLs with them is not. So I'm going to teach you how to just type https://Print.MyOrg.com and get to https://Print.MyOrg.com/MyPrintCenter.

 

How To Avoid Typing "/myprintcenter"

It's actually pretty easy. See? All done! Actually:

  1. Log into the server hosting Pharos Print Center.
  2. Launch Microsoft IIS Administrator.
  3. Expand the site hosting "MyPrintCenter" (usually, it is "Default Web Site").
  4. Select the "HTTP Redirect" object and open it.
    HTTP Redirect Icon.png
  5. In the "HTTP Redirect" configuration dialog box, fill it out exactly as shown below.
    HTTP Redirect Interface.png
  6. Apply the change.

Now, it is time to undo this global action for any other web services/virtual directories hosted by Default Web Site. As an example, we'll perform the undo on the "aspnet_client" web site. Repeat for all other remaining pages.

  1. Click the "aspnet_client" item under "Default Web Site" and launch it's HTTP Redirect interface:
    ASPNet HTTP Redirect icon.png
  2. Configure the ASP.Net Client HTTP Redirect exactly as shown below. Note that the "redirect" option is not enabled.
    ASPNet HTTP Redirect Interface.png
  3. Apply the change.
  4. Restart the web service by clicking the server name in the navigation tree on the left and then clicking the "Restart" option under the Actions > Manage Server function. Note that this does not restart the operating system, just the web services on the server.
    Restart Web Server.png

 

Complete! From any client, go to https://servername and you should be redirected automatically to the Print Center login screen:

Redirected URL.png

 

NOTE: There are other methods to accomplish the same task. See IIS Redirect for Print Center for more options.

Background

Recently, a security vulnerability was discovered inside Apache Struts:

            CVE-2018-1327

            https://nvd.nist.gov/vuln/detail/CVE-2018-1327

 

This vulnerability is reasonably serious because it allows a DoS attack when using a malicious request.

 

A security vulnerability was also discovered inside Jackson-databind:

            CVE-2018-7489

            https://nvd.nist.gov/vuln/detail/CVE-2018-7489

 

This vulnerability is serious because it allows unauthenticated remote code execution and is easy to exploit.

 

Many organizations, including Pharos customers, are urgently investigating where these tools are used and to update/repair those instances.

 

Pharos Software, Apache Struts and Jackson-databind

Pharos has reviewed all our software and 3rdparty tools/libraries that we use and can confirm that we do not use Apache Struts nor Jackson-databind in any product. This includes:

 

  • Uniprint (including all web interfaces)
  • Blueprint (including all web interfaces)
  • Mobileprint
  • All Omega devices (including PS60, PS150, PS200)
  • All iMFP implementations across all manufacturers
  • Beacon – both the desktop components and the cloud infrastructure
  • Kiosks

 

Pharos products are therefore not vulnerable to either the Apache Struts exploit nor the Jackson-databind exploit.

 

Regards,

Pharos Security Team

Pharos Systems International

585-939-7000

pharossecurityteam@pharos.com