I Ran a Security Assessment Against My Printer

Introduction

Printers have a well-earned reputation as the weak link in network security. Default credentials, ancient firmware, unnecessary exposed services, and a long history of being used as pivot points in real breaches. So after spending an evening hardening mine, I decided to actually test it properly rather than just assume it was secure because I'd configured it carefully. The results were pleasantly surprising.

Establishing the Baseline

The target: an Epson ET-2800, sitting on my wireless subnet, already hardened with a few changes beforehand:

Custom ECC certificate signed by my own private CA, replacing the vendor's self-signed cert
Unnecessary protocols disabled: SLP, WSD, LLTD, LLMNR, RAW printing, unauthenticated SNMP
Encrypted credential storage enabled
No outbound internet access, enforced at the firewall

With that baseline in place, it was time to move on to probing it rather than assuming the hardening worked.

Reconnaissance

I did a basic port scan first:

# nmap -sS -Pn 10.1.1.2

Nmap scan report for 10.1.1.2
Host is up (0.014s latency).
Not shown: 997 closed tcp ports (reset)
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https
631/tcp open  ipp

Nmap done: 1 IP address (1 host up) scanned in 4.58 seconds

Three ports open, nothing unexpected. Attack surface appears minimal.

The Full Sweep Finds Something Else

The initial targeted scan only checked the ports I expected to be open. Worth doing a full sweep too, since assuming you know what's open is exactly the kind of shortcut that misses things:

nmap -sS -Pn -p- 10.1.1.2 --disable-arp-ping

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
631/tcp  open  ipp
1865/tcp open  entp

Port 1865 went unaccounted for in my earlier checks. A service version scan came back unable to positively identify it. The other ports produced an interesting result:

nmap -sV -Pn -p 80,443,631,1865 10.1.1.2 --disable-arp-ping

Nmap scan report for 10.1.1.2
Host is up (0.078s latency).

PORT     STATE SERVICE    VERSION
80/tcp   open  tcpwrapped
443/tcp  open  tcpwrapped
631/tcp  open  tcpwrapped
1865/tcp open  entp?
1 service unrecognized despite returning data.

tcpwrapped means the port accepted a connection but didn't respond meaningfully to nmap's service-detection probes, closing the connection instead. Rather than a vulnerability, this is arguably a small point in the printer's favor: it isn't leaking version or service banner information to unexpected or malformed probe traffic, only responding properly to well-formed requests it actually expects. Not too shabby.

Rather than leave port 1865 as an unknown, a bit of research cleared it up. Port 1865 is Epson's own ENTP (Epson Network Transport Protocol), used specifically for "Scan to Computer" functionality. It's how the printer pushes scanned documents to a waiting computer on the network, and it's documented behavior in Epson's own network guides, not an unexpected exposure.

Digging a Little Deeper

With the open ports accounted for, I moved on to actually probing what these services reveal. Running nmap with default scripts and version detection enabled surfaced more than a plain port scan:

nmap -sC -sV -Pn -p 80,443,631,1865 10.1.1.2 --disable-arp-ping

PORT     STATE SERVICE    VERSION
80/tcp   open  tcpwrapped
|_http-server-header: EPSON HTTP Server
443/tcp  open  tcpwrapped
| ssl-cert: Subject: commonName=EPSONREDACTED/organizationName=Rachel Sandover/stateOrProvinceName=BC/countryName=CA
| Subject Alternative Name: DNS:EPSONREDACTED, DNS:EPSONREDACTED.local, DNS:EPSONREDACTED.home.internal, IP Address:10.1.1.2
|_http-server-header: EPSON_Linux UPnP/1.0 Epson UPnP SDK/1.0
631/tcp  open  tcpwrapped
|_http-server-header: Epson_IPP-Server/2.0.0
1865/tcp open  entp?

Jackpot. Two things worth pulling out of this.

First, three different Server headers across three ports on the same device. Useful for fingerprinting, not directly exploitable.

Second, the ssl-cert script pulled my certificate's subject and SAN details straight from the TLS handshake. Not a vulnerability; certificate details are sent in plaintext during the handshake by design, true of every TLS certificate on the internet. But it served as a good reminder that anything in a certificate's subject or SAN fields is public the moment it's deployed.

Probing the Admin Portal

With reconnaissance done, it was time to see how the admin interface actually behaves. I moved on to active vulnerability hunting. I first checked if port 80 redirected cleanly to HTTPS. The printer returned a 307 Temporary Redirect, no plaintext content served anywhere. Good sign. I checked the login page specifically too, since some devices only redirect the root path and leave other endpoints reachable over plain HTTP. This printer redirected consistently across every endpoint tested.

Authentication enforcement was solid as well. Attempting to hit an admin-only endpoint directly, bypassing the normal navigation flow, redirected straight to the login page rather than exposing the content:

curl -k https://10.1.1.2/PRESENTATION/ADVANCED/NWS_CERT_SSLTLS/TOP

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN
"http://www.w3.org/TR/html4/strict.dtd"><html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Author" content="SEIKO EPSON">
<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1.0">
<meta name="format-detection" content="telephone=no">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<SCRIPT type="text/javascript">
<!--
setTimeout("link()", 20);
function link(){
location.target='CONTENTS';
location.method="get";
location.href='/PRESENTATION/ADVANCED/PASSWORD/TOP';
}
-->
</SCRIPT>
</head>
</HTML>

This matters more than it sounds. A lot of poorly designed web interfaces only hide links to sensitive pages in the UI, without actually enforcing authentication server-side. This one enforces it properly at the endpoint level.

Session Security

The login flow sets a session cookie, EPSON_COOKIE_SESSION. Checking its properties in browser dev tools:

Secure flag: present
HttpOnly flag: present
SameSite flag: not set

The first two are solid. The missing SameSite attribute means the browser falls back to its own default behavior (Lax in most modern browsers), rather than the application explicitly enforcing it. Not a serious issue given modern browser defaults, but worth noting as a gap in the vendor's own security posture rather than something actively protecting the device.

Response Headers

Pulling the full response headers manually confirmed what nmap's scripts had already hinted at, plus a bit more:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Cache-Control: private, no-store, no-cache, must-revalidate
Server: EPSON_Linux UPnP/1.0 Epson UPnP SDK/1.0

Solid defensive headers, though X-XSS-Protection is a legacy header most modern browsers have deprecated in favor of a proper Content Security Policy, which was absent entirely. There was also no Strict-Transport-Security header, meaning nothing tells a browser to always prefer HTTPS for this host going forward. Since HTTP already redirects to HTTPS at the application level, the practical risk is low, but it's still a gap compared to how a hardened web server should behave.

The Server header confirms the same banner disclosure nmap already turned up. It doesn't hand over access to anything, but it tells anyone specifically targeting this device exactly what stack they're dealing with.

The One Real Finding

The most interesting result came from a page that requires no authentication at all: a basic status page showing printer info. On this device, that page discloses more than it probably should:

WiFi SSID
Security type (WPA2-PSK)
Full network topology: gateway, DNS servers, subnet mask
Device MAC address

The WiFi password itself is masked, so no credentials leak directly. But an unauthenticated visitor on the same network segment gets a full reconnaissance dump of the internal network layout without logging in.

I checked the Web Config settings for any option to require authentication on this page. There isn't one. This is a vendor limitation, not a misconfiguration on my end.

What I Did About It

Nothing, and that's a deliberate decision, not an oversight. Real security assessments don't end with "fix everything". They end with documented, risk-based decisions. Here, the finding is low severity: no credentials are exposed, and reaching this page in the first place requires already being on my wireless or trusted network, both of which are already segmented from everything else and have no path from the internet.

Fixing it would mean either replacing a device that otherwise works well, or building a reverse proxy specifically to add authentication in front of a printer status page, which is a lot of engineering effort for a finding that doesn't meaningfully change my risk profile.

Wrapping Up

For a consumer inkjet printer, this held up better than I expected. Proper TLS, proper server-side authentication enforcement, reasonable session cookie handling, and a minimal attack surface after hardening. The findings that did turn up are the kind you'd expect from a real assessment: informational disclosures and missing headers, nothing really exploitable here.

Relatively secure, for a printer. I give it a B-minus. Given how low the bar usually is in that category, I'll take it.